Agent Harness: Bagaimana Saya Membangun Portfolio Ini dengan Agen AI Otonom

Masalah dengan Vibe-Coding di Proyek Besar

Ketika saya memutuskan untuk membangun ulang portfolio dari awal, saya menghadapi masalah yang sudah akrab: proyek besar dengan banyak komponen cenderung berantakan ketika diserahkan ke agen AI tanpa struktur. Agen berhalusinasi tentang dependensi, melupakan batasan yang ditetapkan tiga percakapan lalu, dan menghasilkan kode yang bekerja secara terisolasi tapi rusak begitu menyentuh hal lain di sekitarnya.

Saya sudah terlalu sering melihat pola ini. Jawabannya bukan model yang lebih pintar — melainkan proses yang lebih cerdas.

Apa yang Saya Sebut Agent Harness

Agent harness adalah loop SDLC berbasis spesifikasi yang saya bangun di sekitar Kiro, sekumpulan skill VS Code yang saya port ke Claude Code. Loop ini memiliki tiga fase:

Discovery — kiro-discovery mengambil ide mentah dan menulis brief.md beserta roadmap.md yang memetakan fitur ke dependensinya.
Spesifikasi — per fitur, kiro-spec-init → kiro-spec-requirements → kiro-spec-design → kiro-spec-tasks menghasilkan empat dokumen terstruktur: persyaratan dalam notasi EARS, desain arsitektur dengan komitmen batasan yang eksplisit, dan rincian tugas dengan kriteria penyelesaian yang dapat diamati.
Implementasi — kiro-impl mengirimkan sub-agen, satu per tugas. Setiap sub-agen hanya membaca tugasnya ditambah dokumen desain. Ia tidak bisa menyimpang ke ruang lingkup yang berdekatan karena batasannya sudah tertulis.

Harness tidak menggantikan penilaian manusia. Ia memastikan penilaian itu terjadi di awal — saat pembuatan spesifikasi — bukan diimprovisasi di tengah implementasi.

Discovery: Mengubah Satu Kalimat Menjadi Grafik Dependensi

Portfolio ini dimulai dari: "rebuild situs Publii statis saya sebagai aplikasi TanStack Start dengan dukungan dwibahasa, chatbot AI, dan blog."

kiro-discovery mengembangkan ini menjadi sembilan spesifikasi fitur yang diorganisir dalam tiga gelombang dependensi:

Gelombang 0: design-system (token, primitif)
Gelombang 1: site-foundation (pipeline MDX, i18n, routing, SEO)
Gelombang 2 (paralel): home-about, experience-education, achievements-publications, projects-skillset, blog-articles, services-showcase, contact, ai-chatbot

Struktur gelombang ini penting. Agen spesifikasi di gelombang 2 tahu bahwa mereka dapat menggunakan API foundation tanpa mendefinisikannya ulang. Batasan itu tidak diberlakukan oleh kode — melainkan oleh bagian komitmen batasan di setiap dokumen desain.

Spesifikasi: Menulis Kontrak Sebelum Kode

Setiap spesifikasi menghasilkan empat file:

requirements.md — Ditulis dalam EARS (Easy Approach to Requirements Syntax): "Sistem harus X ketika Y sehingga Z." Format ini memaksa kekhususan. "Tambahkan validasi" menjadi "Ketika field wajib kosong, form harus menampilkan pesan error yang dilokalisasi di sebelah field tersebut."

design.md — Dokumen terpenting. Ini menentukan: apa yang dimiliki spesifikasi ini, apa yang tidak dimilikinya, apa yang bisa diandalkan. Dokumen ini mencantumkan setiap file yang akan dibuat spesifikasi, setiap komponen beserta kontrak props-nya, setiap model data. Dokumen ini menyertakan non-goals yang eksplisit. Ketika sub-agen keluar dari batasannya, dokumen desain adalah artefak yang memunculkan kesalahan tersebut.

tasks.md — Daftar tugas bernomor yang diturunkan dari desain, masing-masing dengan kriteria penyelesaian yang dapat diamati. "Halaman listing merender post terbaru di urutan pertama" adalah kriteria yang dapat diamati. "Implementasikan blog" bukan.

Pekerjaan ini dilakukan oleh agen, tetapi hasilnya saya tinjau sebelum implementasi dimulai. Peninjauan itu adalah jam yang paling bernilai dalam seluruh proses.

Implementasi: Sub-Agen Membaca Satu Tugas

kiro-impl menjalankan setiap tugas sebagai sub-agen terpisah. Sub-agen mendapat:

Deskripsi tugas dan kriteria penyelesaian yang dapat diamati
design.md fitur (untuk batasan)
File foundation yang diizinkan untuk dibaca

Sub-agen tidak mendapatkan riwayat percakapan penuh, tugas-tugas sebelumnya, atau spesifikasi fitur lain. Isolasi itu disengaja. Sub-agen yang bisa melihat segalanya akan mencoba "membantu" dengan menyentuh hal-hal yang tidak dimintanya.

Ketika tugas selesai, kiro-review berjalan: seorang reviewer adversarial memeriksa implementasi terhadap dokumen desain. Jika implementasi menyimpang — misalnya, sebuah komponen mengimplementasikan ulang utilitas yang sudah ada di foundation — reviewer menandainya. Implementer memperbaikinya. Baru kemudian tugas ditutup.

Apa yang Benar-Benar Rusak (dan Bagaimana Spesifikasi Menangkapnya)

Tugas 6.3 dari spesifikasi site-foundation gagal. Kriteria yang dapat diamati adalah: "Toggle bahasa mengalihkan locale tanpa reload halaman penuh." Implementasinya bekerja secara lokal, tetapi mekanisme createServerFn + cookie dari TanStack Start dan versi @tanstack/start di lockfile memiliki inkompatibilitas yang menyebabkan hidrasi SSR berbeda.

Karena kriteria sudah eksplisit, kegagalan tidak ambigu. Agen tidak mengirimkan implementasi yang rusak dan menandai tugas selesai — evaluasi kriteria menangkapnya. Tugas 6.3 ditandai sebagai terblokir dalam spesifikasi, bukan selesai, dan dicakupkan ke pembaruan dependensi berikutnya.

Itulah harness yang bekerja dengan benar: jujur, spesifik, dapat diverifikasi.

Pelajaran

Spesifikasi murah; pengerjaan ulang mahal. Empat dokumen spesifikasi untuk blog-articles membutuhkan sekitar dua jam waktu agen dan satu jam tinjauan saya. Implementasinya membutuhkan kurang dari sehari dan menghasilkan nol pengerjaan ulang pada fitur yang berdekatan. Tanpa spesifikasi, saya akan menghabiskan tiga hari membangun dan seminggu mengurai masalah.

Kriteria yang dapat diamati adalah satuan kepercayaan. "Tugas selesai" tidak berarti apa-apa. "SSR HTML halaman listing berisi judul dan tautan post" dapat diperiksa. Setiap tugas di portfolio ini memiliki kriteria yang bisa saya verifikasi secara manual.

Isolasi adalah fitur. Sub-agen yang tidak bisa melihat seluruh proyek membuat lebih sedikit keputusan kreatif. Kedengarannya seperti keterbatasan. Ini sebenarnya cara mencegah scope creep terakumulasi di tiga puluh tugas.

Harness tidak membuat agen lebih pintar. Harness membuat kesalahan mereka lebih kecil dan lebih terlihat. Spesifikasi membatasi radius dampak dari setiap satu keputusan buruk. Itulah model mental yang benar.

Jika Anda membangun sesuatu yang lebih besar dari proyek akhir pekan dengan agen AI, tulis spesifikasi terlebih dahulu. Harness adalah perbedaan antara proyek yang jadi dan proyek yang runtuh di bawah strukturnya sendiri yang diimprovisasi.