Desain Harness untuk Mengembangkan Aplikasi yang Berjalan Lama

• Anthropic mengembangkan arsitektur multi-agent yang terinspirasi dari GAN untuk sekaligus menyelesaikan dua masalah: meningkatkan kualitas desain frontend dan coding otonom jangka panjang
• Dengan memisahkan generator dan evaluator, kualitas desain yang subjektif dapat dinilai menggunakan kriteria yang konkret, sehingga mengatasi masalah bias evaluasi diri pada agent
• Melalui arsitektur 3-agent yang terdiri dari planner-generator-evaluator, mereka dapat menyelesaikan aplikasi full-stack dalam sesi coding otonom multi-jam, termasuk negosiasi kontrak sprint dan QA berbasis Playwright
• Saat beralih dari Opus 4.5 ke Opus 4.6, model menjadi mampu coding konsisten selama lebih dari 2 jam tanpa pembagian sprint, sehingga kompleksitas harness bisa dikurangi sambil mempertahankan performa
• Bahkan ketika performa model meningkat, ruang kombinasi harness yang menarik tidak mengecil, melainkan bergeser, dan tugas utama AI engineer adalah menemukan kombinasi baru tersebut

---

Mengapa implementasi sederhana mencapai batasnya

• Dalam eksperimen sebelumnya, mereka memakai pendekatan di mana agent inisialisasi memecah spesifikasi produk menjadi daftar tugas, lalu agent coding mengimplementasikan fitur satu per satu sambil meneruskan konteks antarsesi melalui artifact
  • Di komunitas developer juga muncul pendekatan serupa seperti gaya "Ralph Wiggum", yang menjaga agent tetap berada dalam loop berulang jangka panjang lewat hook atau script
• Pada tugas yang kompleks, agent terus menunjukkan masalah keluar jalur seiring waktu, dan mereka mengamati dua mode kegagalan yang umum
• Mode kegagalan pertama: saat context window terisi, model kehilangan konsistensi, dan beberapa model menunjukkan fenomena "context anxiety", yaitu cenderung menutup pekerjaan terlalu cepat ketika merasa telah mencapai batas konteksnya
  • Context reset — mengosongkan seluruh context window lalu memulai agent baru dengan handoff terstruktur berisi status agent sebelumnya dan langkah berikutnya — menyelesaikan kedua masalah ini sekaligus
  • Ini berbeda dari compaction, yaitu meringkas bagian awal percakapan agar agent yang sama bisa terus berjalan; compaction menjaga kontinuitas tetapi tidak memberi clean slate, sehingga context anxiety bisa tetap ada
  • Pada Claude Sonnet 4.5, context anxiety terlalu kuat sehingga compaction saja tidak cukup untuk menjamin performa tugas jangka panjang; karena itu context reset menjadi elemen inti dalam desain harness
• Mode kegagalan kedua: masalah self-evaluation, di mana agent yang menilai hasil buatannya sendiri cenderung memujinya dengan percaya diri meskipun kualitasnya jelas biasa saja
  • Ini sangat serius terutama pada tugas subjektif seperti desain, karena tidak ada pemeriksaan biner seperti pada software test yang bisa diverifikasi
  • Memisahkan agent pekerja dan agent evaluator adalah tuas yang kuat, dan menyetel evaluator independen agar lebih skeptis jauh lebih mudah daripada membuat generator menjadi lebih kritis terhadap dirinya sendiri

Desain frontend: membuat kualitas subjektif bisa dinilai

• Tanpa intervensi, Claude cenderung menghasilkan layout yang aman dan mudah ditebak: fungsional secara teknis, tetapi biasa saja secara visual
• Ada dua wawasan utama yang membimbing desain harness
  • Estetika tidak bisa sepenuhnya diberi skor, tetapi masih bisa ditingkatkan lewat rubrik penilaian yang mengodekan prinsip desain dan preferensi — menilai "apakah desain ini indah?" kurang konsisten dibanding menilai "apakah desain ini mengikuti prinsip desain yang baik?"
  • Dengan memisahkan pembuatan frontend dan penilaiannya, mereka membuat loop umpan balik yang mendorong generator menuju hasil yang lebih kuat
• Empat kriteria penilaian yang diberikan kepada generator dan evaluator:
  • Design quality: apakah warna, tipografi, layout, dan gambar menyatu menjadi keseluruhan yang konsisten dengan suasana dan identitas yang jelas
  • Originality: apakah ada bukti keputusan kustom, atau justru hanya layout template, default library, atau pola khas hasil AI — tanda seperti kartu putih di atas gradasi ungu dianggap gagal
  • Craft: kualitas eksekusi teknis seperti hierarki tipografi, konsistensi jarak, harmoni warna, dan rasio kontras — ini menguji kemampuan, bukan kreativitas
  • Functionality: usability yang terpisah dari estetika — apakah pengguna bisa memahami fungsi antarmuka dan menemukan aksi utama
• Design quality dan originality diberi bobot lebih tinggi daripada craft dan functionality, karena Claude pada dasarnya sudah mendapat nilai tinggi di dua kriteria terakhir tetapi masih menghasilkan desain yang biasa pada dua kriteria pertama
  • Rubrik tersebut juga secara eksplisit mengurangi nilai untuk pola "AI slop" yang sangat umum, agar model terdorong mengambil risiko estetis
• Orkestrasi dibangun dengan Claude Agent SDK, di mana generator membuat frontend HTML/CSS/JS, lalu evaluator memakai Playwright MCP untuk berinteraksi langsung dengan halaman live, mengambil screenshot, meninjau implementasi secara teliti, lalu memberi skor dan kritik rinci
  • Proses ini diulang 5 hingga 15 kali per generasi, dengan generator merespons kritik evaluator pada tiap iterasi dan bergerak ke arah yang lebih unik
  • Satu proses penuh dapat memakan waktu hingga 4 jam
  • Generator diarahkan untuk mengambil keputusan strategis setelah tiap evaluasi: jika tren skor membaik, perbaiki arah saat ini; jika pendekatan tidak berhasil, beralihlah ke estetika yang sepenuhnya berbeda
• Frasa dalam rubrik ternyata memengaruhi generator dengan cara yang tak terduga — ungkapan seperti "desain terbaik setara kualitas museum" mendorong konvergensi visual tertentu; bahasa pada rubrik dan prompting terkait langsung membentuk karakter hasil
• Skor umumnya meningkat sepanjang iterasi, tetapi tidak selalu linear, dan mereka cukup sering lebih menyukai iterasi tengah daripada iterasi terakhir
  • Kompleksitas implementasi cenderung naik seiring iterasi, karena model mengejar solusi yang lebih ambisius sebagai respons terhadap masukan evaluator
  • Bahkan pada iterasi pertama, hasilnya sudah jauh lebih baik daripada baseline tanpa prompting, karena bahasa dalam rubrik itu sendiri sudah mendorong model keluar dari default generik bahkan sebelum umpan balik evaluator diberikan
• Contoh situs museum seni Belanda: hingga iterasi ke-9, model membuat landing page dark theme yang rapi; lalu pada iterasi ke-10, ia membuang total pendekatan itu dan membayangkannya ulang sebagai pengalaman spasial dengan ruang 3D yang dirender lewat perspektif CSS, lantai kotak-kotak, karya seni yang tergantung bebas di dinding, serta navigasi antargaleri melalui pintu — lompatan kreatif jenis ini tidak terlihat pada generasi sekali jalan

Meluas ke coding full-stack

Arsitektur

• Pada harness jangka panjang sebelumnya, mereka sudah menyelesaikan masalah coding multi-sesi yang konsisten melalui agent inisialisasi, agent coding per fitur, dan context reset antarsesi
  • Pada Sonnet 4.5, context reset menjadi kunci karena context anxiety, tetapi pada Opus 4.5 perilaku ini sebagian besar hilang, sehingga seluruh build bisa dikerjakan dalam satu sesi kontinu tanpa context reset
  • Auto-compaction dari Claude Agent SDK menangani pertumbuhan konteks
• Mereka membangun sistem 3-agent:
  • Planner: memperluas prompt singkat 1–4 kalimat menjadi spesifikasi produk lengkap — prompt-nya diarahkan agar fokus pada konteks produk dan desain teknis tingkat tinggi, bukan implementasi teknis detail, karena penetapan detail teknis terlalu dini bisa menyebarkan kesalahan ke tahap berikutnya
    • Planner juga diarahkan untuk mencari peluang menenun fitur AI ke dalam spesifikasi produk
  • Generator: mengambil satu fitur dari spesifikasi untuk tiap sprint, lalu mengimplementasikannya dengan stack React/Vite/FastAPI/SQLite (kemudian PostgreSQL), melakukan self-review di akhir sprint, menyerahkan ke QA, dan mengelola versi dengan git
  • Evaluator: memakai Playwright MCP untuk mengklik aplikasi yang sedang berjalan seperti pengguna sungguhan, menguji fungsi UI, endpoint API, dan status database — lalu memberi skor berdasarkan kedalaman produk, fungsionalitas, desain visual, dan kualitas kode; jika ada kriteria yang tidak mencapai ambang keras, sprint dinyatakan gagal
• Sebelum tiap sprint, generator dan evaluator menegosiasikan sprint contract — menyepakati definisi "selesai" untuk potongan pekerjaan tersebut sebelum kode ditulis
  • Karena spesifikasi produk sengaja dibuat pada level tinggi, tahap ini menjembatani jarak antara user story dan implementasi yang bisa diuji
  • Komunikasi dilakukan berbasis file — satu agent menulis file, agent lain membacanya dan merespons

Hasil eksekusi harness: pembuat game retro

• Mereka menguji dengan prompt: "Buat 2D retro game maker yang mencakup level editor, sprite editor, perilaku entitas, dan mode uji yang dapat dimainkan"
• Agent solo: 20 menit / $9 vs harness penuh: 6 jam / $200 — harness lebih dari 20 kali lebih mahal, tetapi perbedaan kualitas hasil langsung sangat jelas
• Hasil agent solo: layar awal tampak sesuai harapan, tetapi masalah muncul saat diklik — layout boros ruang, workflow kaku, pengguna harus membuat sprite dan entitas lebih dulu namun UI tidak membimbing, dan yang paling penting game yang sebenarnya tidak berjalan (entitas muncul di layar tetapi tidak merespons input, karena pengkabelan antara definisi entitas dan runtime game terputus)
• Hasil harness: planner memperluas prompt satu kalimat menjadi 16 spesifikasi fitur dalam 10 sprint — termasuk sistem animasi sprite, template perilaku, efek suara dan musik, generator sprite berbantuan AI dan level designer, serta ekspor game melalui tautan yang bisa dibagikan
  • Planner juga membaca kemampuan desain frontend dan menghasilkan bahasa desain visual aplikasi sebagai bagian dari spesifikasi
  • Canvas memanfaatkan seluruh viewport, ukuran panel masuk akal, dan identitas visual konsisten mengikuti arah desain dalam spesifikasi
  • Sprite editor lebih kaya dan lengkap, dengan tool palette yang lebih rapi, color picker yang lebih baik, dan kontrol zoom yang lebih usable
  • Integrasi AI mempercepat workflow dengan menghasilkan berbagai bagian game melalui prompting
• Perbedaan utama pada play mode: pada eksekusi solo game tidak berjalan, sedangkan pada eksekusi harness entitas benar-benar bisa digerakkan dan game dapat dimainkan — meski masih ada sedikit kekasaran pada physics engine (platform dan karakter saling bertumpuk) serta keterbatasan komposisi level oleh AI (tembok besar yang tak bisa dilompati), fungsi intinya bekerja
• Evaluator menjaga implementasi tetap sesuai spesifikasi — bahkan pada Sprint 3 saja, kontraknya sudah sangat rinci dan mencakup 27 kriteria untuk level editor
  • Contoh masalah yang ditemukan: alat isi persegi panjang hanya menaruh tile pada titik awal/akhir drag, kesalahan kondisi pada key handler penghapusan entitas, dan urutan route FastAPI yang membuat reorder diparse sebagai integer sehingga mengembalikan error 422
• Penyetelan evaluator membutuhkan usaha besar — dalam kondisi default, Claude adalah agent QA yang buruk: ia sering menemukan isu yang valid lalu meyakinkan dirinya sendiri bahwa itu "bukan masalah besar" dan meloloskannya, serta melewatkan bug halus karena pengujian yang dangkal
  • Mereka harus mengulang loop pengembangan beberapa kali dengan membaca log evaluator, mencari kasus saat penilaiannya menyimpang, lalu memperbarui prompt QA hingga penilaiannya cukup masuk akal

Iterasi perbaikan harness

• Hasil awal cukup menjanjikan, tetapi karena besar, lambat, dan mahal, langkah berikutnya adalah menyederhanakan harness tanpa menurunkan performa
  • Setiap komponen dalam harness mengodekan asumsi tentang hal yang belum bisa dilakukan model sendiri, dan asumsi seperti ini layak diuji tekan karena bisa cepat usang saat model membaik
  • Prinsip yang mereka ikuti: "cari solusi paling sederhana yang mungkin, lalu tambahkan kompleksitas hanya saat diperlukan"
• Upaya penyederhanaan radikal gagal mereplikasi performa awal, dan sulit mengetahui komponen mana yang benar-benar menopang beban, sehingga mereka beralih ke pendekatan sistematis dengan menghapus satu komponen pada satu waktu
• Rilis Opus 4.6 menjadi motivasi tambahan untuk mengurangi kompleksitas harness — model ini merencanakan dengan lebih hati-hati, mampu mempertahankan tugas agentic lebih lama, lebih stabil pada codebase besar, kemampuan code review/debugging untuk menangkap kesalahan sendiri meningkat, dan retrieval konteks panjang juga jauh lebih baik

Menghapus struktur sprint

• Mereka menghapus struktur sprint sepenuhnya — berkat peningkatan kemampuan Opus 4.6, model dapat menangani pekerjaan secara konsisten tanpa perlu dipecah
• Planner dan evaluator tetap dipertahankan — tanpa planner, generator kekurangan cakupan, memulai build hanya dari raw prompt tanpa spesifikasi dan menghasilkan aplikasi dengan fitur yang lebih sedikit
• Evaluator dipindahkan dari penilaian per sprint menjadi satu pass di akhir eksekusi
  • Jika tugas masih berada dalam jangkauan kemampuan model sendirian, evaluator hanyalah overhead yang tidak perlu; tetapi untuk tugas di batas kemampuan model, evaluator masih memberi peningkatan yang nyata
  • Jadi evaluator bukan pilihan tetap ya/tidak, melainkan bernilai sepadan dengan biaya ketika ingin melampaui batas yang dapat dicapai model secara andal sendirian
• Mereka juga menambahkan prompting untuk memperbaiki pembangunan fitur AI — generator membutuhkan cukup banyak iterasi agar bisa membangun agent yang tepat dan mengoperasikan fitur aplikasi itu sendiri melalui tool, karena pengetahuan terkait masih relatif baru sehingga cakupan dalam data pelatihan Claude masih tipis

Hasil harness yang diperbarui: DAW di browser

• Mereka mengujinya dengan prompt: "Bangun DAW yang berfungsi penuh di browser menggunakan Web Audio API"
• Total memakan sekitar 4 jam, $124.70
  • Planner 4,7 menit/$0.46, build ronde 1 2 jam 7 menit/$71.08, QA ronde 1 8,8 menit/$3.24, build ronde 2 1 jam 2 menit/$36.89, QA ronde 2 6,8 menit/$3.09, build ronde 3 10,9 menit/$5.88, QA ronde 3 9,6 menit/$4.06
• Builder berjalan konsisten lebih dari 2 jam tanpa dekomposisi sprint
• Umpan balik awal dari agent QA: fidelity desain, agent AI, dan backend sangat baik, tetapi kelengkapan fungsi menjadi titik gagal utama — klip tidak bisa di-drag/dipindahkan di timeline, panel UI instrumen (knob synth, drum pad) belum ada, editor efek visual (kurva EQ, meter kompresor) juga belum ada
• Umpan balik QA kedua: perekaman audio masih berupa stub, resize dan split klip belum diimplementasikan, dan visualisasi efek hanya berupa slider angka, bukan grafik
• Aplikasi akhirnya belum setara program produksi musik profesional, dan kemampuan agent dalam membuat lagu masih perlu ditingkatkan; Claude juga tidak benar-benar bisa mendengar suara, sehingga loop umpan balik QA kurang efektif untuk urusan selera musikal
  • Namun aplikasi ini tetap memiliki elemen inti program produksi musik yang fungsional, termasuk arrangement view, mixer, dan transport yang bekerja
  • Melalui prompting saja, aplikasi bisa membuat potongan lagu pendek — agent dapat mengatur tempo dan key, menempatkan melodi, membuat track drum, menyesuaikan level mixer, dan menambahkan reverb

Prospek ke depan

• Seiring model membaik, mereka memperkirakan model akan mampu menangani tugas yang lebih lama dan lebih kompleks, dan dalam beberapa kasus pentingnya scaffold di sekitar model akan berkurang sehingga beberapa masalah tertentu bisa terselesaikan secara alami hanya dengan menunggu model berikutnya
• Di sisi lain, makin baik modelnya, makin luas pula ruang untuk mengembangkan harness yang mampu mencapai tugas kompleks di atas baseline
• Pelajaran utamanya:
  • Bereksperimen dengan model yang akan dipakai untuk build, membaca trace pada masalah nyata, dan menyetel performa agar sesuai dengan hasil yang diinginkan selalu merupakan praktik yang baik
  • Pada tugas yang lebih kompleks, memecah tugas dan menerapkan agent yang terspesialisasi untuk tiap aspeknya dapat membuka ruang tambahan
  • Saat model baru dirilis, praktik yang baik adalah meninjau ulang harness: hapus bagian yang tidak lagi menopang performa, dan tambahkan bagian baru untuk mencapai kemampuan yang lebih besar yang sebelumnya mustahil
• Bahkan ketika model meningkat, ruang kombinasi harness yang menarik tidak mengecil, tetapi bergeser; tugas AI engineer adalah terus menemukan kombinasi baru berikutnya