Cara saya membangun portofolio ini spec-first dengan Claude Code

#Jawaban singkat

Portofolio ini (resume, studi kasus, CMS tulisan, dan skill tracker privat) berjalan dari repositori kosong pada 5 Oktober 2026 sampai production dalam sekitar dua minggu, di free tier dengan biaya $0/bulan (Next.js di Vercel, Supabase untuk Postgres, autentikasi, dan storage). Saya membangunnya dengan spec-driven development: spec tertulis menjadi sumber kebenaran, setiap requirement punya ID, setiap keputusan arsitektur dicatat sebagai ADR, dan Claude Code mengerjakan setiap task secara test-first. Semua keputusan produk dan persetujuan di setiap gerbang ada di tangan saya.

Inti metode ini bukan kecepatan, tetapi memastikan kode, test, dan dokumentasi tidak pernah diam-diam saling bertentangan.

#Kenapa spec-first, dan kenapa dengan AI coding agent

AI coding agent itu cepat, dan justru di situ risikonya: ia bisa menghasilkan banyak kode yang tampak masuk akal padahal tidak diminta. Spec mengubah "buatkan saya portofolio" menjadi keputusan yang bisa dicek:

• Apa yang dibangun dan untuk siapa (PRD dengan ID requirement seperti FR-RES-04).
• Bagaimana tampilannya (dokumen desain dengan token dan komponen).
• Bagaimana semuanya tersambung (dokumen arsitektur dengan keputusan bernomor).
• Bagaimana kita tahu ia bekerja (strategi testing yang terikat ke setiap requirement).

Saat agent mengusulkan sesuatu, saya membandingkannya dengan spec, bukan dengan ingatan saya. Disiplin yang sama sedang saya pelajari lebih formal di kursus Spec-Driven Development dari Dicoding; situs ini tempat saya mempraktikkannya dari awal sampai akhir.

#Dokumen yang menjalankan proyek

Repositori punya folder docs/ berisi 12 dokumen: PRD, desain, arsitektur, spesifikasi teknis, spec skill tracker, inventaris konten, keamanan dan privasi, testing dan QA, deployment dan operasional, roadmap dengan matriks traceability, panduan proyek, dan release log.

Tiga aturan menjaga semuanya tetap jujur:

1. Perilaku berubah ⇒ spec berubah di pull request yang sama, dengan kenaikan versi dan baris changelog.
2. Keputusan arsitektur adalah ADR, dan ADR yang sudah diterima tidak pernah diedit; ADR baru yang menggantikannya. Sejauh ini ada 18 ADR.
3. ID requirement ikut ke mana-mana: muncul di pesan commit, pull request, dan matriks traceability, sehingga setiap baris kode bisa ditelusuri ke alasan keberadaannya.

#Perjalanan satu fitur dari ide sampai production

Buka ukuran penuh

Perhatikan gerbang di bawah setiap kotak. Setiap langkah menghasilkan sesuatu yang bisa saya baca dan setujui sebelum langkah berikutnya dimulai:

1. Brainstorm. Agent mengusulkan dua atau tiga pendekatan beserta rekomendasi; saya memilih salah satunya.
2. Spec. Keputusan ditulis: apa yang berubah, apa yang tetap privat, bagaimana ia akan diuji.
3. Plan. Spec dipecah menjadi task kecil, masing-masing dengan file, interface, dan test-nya.
4. Build. Setiap task dikerjakan test-first: test gagal, kode minimal, hijau, commit.
5. Review. Setiap task di-review, lalu seluruh branch. Temuan diperbaiki sebelum merge.
6. Rilis. Quality gate lengkap dijalankan, lalu pull request dan runbook tertulis untuk production.

Garis putus-putus itu yang paling penting. Saat demo menunjukkan ada yang perlu diubah, perubahannya kembali masuk ke spec di pull request yang sama.

#Contoh nyata: honeycomb Skill Atlas

Halaman utama menampilkan ringkasan publik skill tracker privat saya dalam bentuk honeycomb heksagon. Fitur ini memperlihatkan metodenya dalam praktik:

• Keputusan produk yang ditulis. Menampilkan mastery per skill tree secara publik adalah pilihan saya yang eksplisit, dicatat sebagai ADR-018. Progres per node tetap privat.
• Privasi ditegakkan di database, bukan di UI. Row-level security di Postgres menentukan apa yang bisa dibaca pengunjung anonim; halaman publik hanya pernah melihat tabel ringkasan.
• Perubahan setelah demo masuk ke spec. Setelah melihat demo lokal, saya meminta detail saat hover (kode seperti SOL dan ARCH kurang jelas) dan grid yang otomatis menambah cincin saat ada tree ke-13. Keduanya dibangun test-first dan ditulis ke spec sebagai amandemen di pull request yang sama, sehingga spec tetap menggambarkan apa yang dirilis.
• Rilis yang aman sejak desain. Perubahan database bersifat aditif dan kompatibel mundur, jadi ketika pull request ter-merge sebelum migration dijalankan, production tetap berjalan dan menampilkan cincin placeholder sampai ringkasan diterbitkan ulang.

#Apa yang dikerjakan agent, dan apa yang saya kerjakan

Claude Code	Saya
Mengusulkan opsi beserta trade-off	Memilih di antaranya
Menulis spec, plan, kode, dan test	Menyetujui spec dan plan; menilai demo
Menjalankan quality gate dan melaporkan kegagalan	Memutuskan apa yang dirilis dan kapan
Menjalankan review di setiap task	Merge pull request dan menyetujui setiap langkah production
Menjaga dokumen, ADR, dan changelog tetap sinkron	Memegang konten, data, dan akses akun

Agent tidak pernah memegang secret production atau membuat akun; langkah-langkah itu tetap di tangan saya.

#Angkanya, dua minggu berjalan

Item	Jumlah
Commit	267
Architecture decision record	18
Migration database (append-only)	11
Unit dan integration test	sekitar 2.400
End-to-end test (Chromium + WebKit mobile)	324
Test database (pgTAP)	206
Biaya hosting	$0/bulan

#Apa yang salah, dan apa yang saya pelajari

• Uji di browser yang dipakai pengunjung. Orbit CSS 3D terlihat benar di Chromium tetapi menjadi datar di WebKit mobile. Akhirnya diganti efek 2D yang bekerja di mana saja.
• Ukur dulu sebelum menyimpulkan. Saya mengira foto profil adalah largest contentful paint halaman; ternyata judulnya. Test-nya dikoreksi sesuai kenyataan.
• Urutan rilis penting, jadi rancang untuk urutan yang salah. Sebuah pull request ter-merge sebelum migration-nya. Tidak ada yang rusak karena perubahannya aditif, tetapi pelajarannya masuk ke runbook.
• Changelog paralel saling bentrok. Dua branch yang menaikkan versi dokumen yang sama memblokir merge. Merge main ke branch sebelum membuka pull request mencegahnya.
• Test yang flaky adalah utang. Beberapa test yang sensitif waktu masih sesekali gagal saat mesin sibuk; mereka dicatat, bukan diabaikan.

#FAQ

Apa itu spec-driven development? Spec-driven development berarti menulis requirement, desain, dan rencana test sebelum kode, lalu memperlakukan spec tertulis itu sebagai sumber kebenaran. Setiap perubahan perilaku ikut memperbarui spec dalam perubahan yang sama, sehingga dokumentasi tetap akurat.

Apakah AI menulis semua kodenya? Claude Code menulis sebagian besar kode dan test, tetapi hanya berdasarkan spec dan plan yang sudah disetujui, dan setiap task di-review. Keputusan produk, persetujuan, merge, konten, dan akses production tetap di tangan saya.

Apakah portofolio seperti ini benar-benar bisa gratis? Bisa, dalam batas free tier: Vercel meng-hosting aplikasi Next.js dan Supabase menyediakan Postgres, autentikasi, dan storage. Backup terenkripsi mingguan berjalan di GitHub Actions, dan restore drill memastikan backup itu bisa dipulihkan.

Di mana saya bisa melihatnya? Anda sedang berada di sana. Portofolio berisi studi kasus, dan bagian tulisan ini adalah CMS-nya yang sedang dipakai.

---

Stack: Next.js 16, React 19, Supabase (Postgres, Auth, Storage, RLS), Vercel, Playwright, Vitest, pgTAP. Terakhir diperbarui: 20 Oktober 2026.