Saya sedang membuat agen yang berjalan saat saya tidur

• Agen penulisan kode AI dapat menghasilkan kode dan menerapkan perubahan ke branch saat developer sedang tidur, tetapi verifikasi akurasi dan keandalan hasilnya sulit dilakukan
• Jika kode yang ditulis AI diuji oleh AI yang sama, itu menjadi mesin saling memuji diri sendiri dan gagal menangkap kesalahpahaman yang berbeda dari niat awal
• Dengan meminjam prinsip inti TDD, kriteria penerimaan ditulis lebih dulu sebelum penulisan kode, lalu agen mengimplementasikannya berdasarkan kriteria tersebut dan melakukan verifikasi terpisah
• Sebagai alat verifikasi, dibangun pipeline 4 tahap yang menggabungkan mode headless Claude Code (claude -p) dan Playwright MCP, tanpa perlu backend terpisah
• Untuk dapat mempercayai keluaran agen, definisi "selesai" harus dibuat jelas sebelum pekerjaan dimulai; ini lebih sulit daripada menulis prompt, tetapi merupakan proses yang wajib

---

Masalah verifikasi kode pada agen otonom

• Dengan memanfaatkan alat AI seperti Gastown, agen dapat menulis kode selama berjam-jam dan menerapkan perubahan ke branch, tetapi tidak ada metode verifikasi yang tepercaya untuk memastikan hasilnya benar-benar tepat
• Hasil workshop Claude Code selama 6 bulan terakhir untuk lebih dari 100 engineer menunjukkan bahwa semua tim menghadapi masalah yang sama
• Tim yang menggunakan Claude untuk PR sehari-hari mengalami kenaikan jumlah merge PR dari sekitar 10 per minggu menjadi 40~50, sehingga menghabiskan jauh lebih banyak waktu untuk code review
• Semakin otonom sistem bekerja, semakin parah masalahnya — pada titik tertentu orang berhenti meninjau diff, hanya mengamati deployment sambil berharap tidak ada masalah, lalu baru menemukan error setelah rilis

Batasan solusi yang ada saat ini

• Metode merekrut reviewer tambahan tidak dapat mengejar kecepatannya, dan tidak efisien bila engineer senior membaca kode buatan AI sepanjang hari
• Jika Claude menulis test untuk kode yang ia tulis sendiri, strukturnya menjadi memverifikasi bukan apa yang benar-benar diinginkan pengguna, melainkan apa yang menurut Claude diinginkan
  • Regression bug bisa tertangkap, tetapi kesalahpahaman (misunderstanding) awal tidak bisa dideteksi
• Jika AI yang sama dipakai sekaligus untuk menulis dan memverifikasi, itu menjadi "mesin saling memuji diri sendiri (self-congratulation machine)"
• Tujuan asli code review adalah adanya pandangan kedua selain penulis awal, tetapi cross-review antar AI berasal dari sumber yang sama sehingga cenderung melewatkan hal yang sama

Hal inti yang ditangkap TDD dengan benar

• Prinsip TDD: tulis test lebih dulu, tulis kode, lalu berhenti ketika test lulus (tanpa mengimplementasikan lebih jauh)
• Alasan sebagian besar tim tidak melakukan TDD adalah karena butuh waktu untuk memikirkan lebih dulu apa yang harus dilakukan kode
• AI mengatasi masalah kecepatan, jadi alasan itu hilang — sekarang bagian yang lambat justru menilai apakah kodenya benar
• Dibanding unit test, lebih mudah menjelaskan dalam bahasa biasa apa yang harus dilakukan fitur
  • Contoh: "Pengguna melakukan autentikasi dengan email dan kata sandi. Jika kredensial salah, tampilkan 'Invalid email or password'. Jika berhasil, pindah ke /dashboard. Token sesi kedaluwarsa setelah 24 jam"
• Kriteria ini dapat ditulis sebelum editor kode dibuka, lalu agen mengimplementasikan dan sesuatu yang lain memverifikasinya

Contoh penerapan nyata

• Perubahan frontend

  • Membuat kriteria penerimaan (Acceptance Criteria) berbasis file spesifikasi
    • AC-1: Saat mengakses /login dengan kredensial valid, pengguna diarahkan ke /dashboard dan session cookie disetel
    • AC-2: Saat kata sandi salah dimasukkan, tampil tepat "Invalid email or password" dan tetap berada di halaman /login
    • AC-3: Jika field kosong, tombol submit dinonaktifkan atau error inline ditampilkan
    • AC-4: Setelah 5 kali gagal, login diblokir selama 60 detik dan pesan waktu tunggu ditampilkan
  • Setiap kriteria dapat dinilai dengan jelas sebagai lulus atau gagal
  • Setelah agen membangun fitur, agen browser Playwright menjalankan verifikasi untuk tiap AC, mengambil screenshot, dan membuat laporan hasil per kriteria
  • Jika gagal, bisa diketahui dengan tepat kriteria mana yang gagal dan apa yang terlihat di browser

• Perubahan backend

  • Pola yang sama diterapkan tanpa browser
  • Perilaku API yang bisa diamati (status code, response header, pesan error) dijelaskan secara eksplisit dan diverifikasi dengan perintah curl

• Batasan

  • Kesalahpahaman pada spesifikasi itu sendiri tidak bisa ditangkap — jika spesifikasinya salah sejak awal, fitur bisa tetap lolos verifikasi meski sebenarnya salah
  • Hal yang bisa ditangkap Playwright: kegagalan integrasi, bug rendering, perilaku rusak di browser nyata
  • Ini adalah klaim yang lebih sempit daripada "akurasi yang terverifikasi", tetapi tetap menangkap lebih banyak hal dibanding apa yang biasanya bisa ditangkap code review secara konsisten

• Ringkasan workflow

  • Tulis kriteria penerimaan sebelum prompt → agen mengimplementasikan sesuai kriteria → jalankan verifikasi → review hanya yang gagal (review kegagalan, bukan diff)

Cara membangunnya: pipeline 4 tahap

• Diimplementasikan sebagai Claude Skill (github.com/opslane/verify), menggunakan claude -p (mode headless Claude Code) dan Playwright MCP
• Tidak perlu custom backend terpisah atau API key tambahan; cukup gunakan token OAuth Claude yang sudah ada

• Tahap 1: Pre-flight

  • Bash murni, tanpa pemanggilan LLM
  • Memeriksa apakah dev server berjalan, sesi autentikasi valid, dan file spesifikasi tersedia
  • Gagal lebih cepat sebelum token terpakai

• Tahap 2: Planner

  • Satu kali pemanggilan Opus
  • Membaca spesifikasi dan file yang berubah, lalu menentukan apa saja yang perlu diverifikasi dan bagaimana menjalankannya
  • Karena membaca kode untuk menemukan selector yang benar, ia tidak menebak-nebak nama class

• Tahap 3: Browser Agents

  • Satu kali pemanggilan Sonnet per AC, semuanya dijalankan paralel
  • Jika ada 5 AC, maka 5 agen bekerja secara independen untuk navigasi dan mengambil screenshot
  • Sonnet 3~4 kali lebih murah dibanding Opus dan memiliki performa setara untuk tugas berbasis klik

• Tahap 4: Judge

  • Satu kali pemanggilan final Opus untuk membaca semua bukti dan mengembalikan hasil per kriteria: pass, fail, atau needs-human-review

• Cara instalasi

  • Dapat diinstal sebagai plugin Claude Code: /plugin marketplace add opslane/verify
  • Atau clone repo lalu sesuaikan sendiri — tiap tahap memiliki satu pemanggilan claude -p dengan input yang jelas dan output terstruktur
  • Penggantian model, penambahan tahap, dan integrasi CI dimungkinkan dengan opsi --dangerously-skip-permissions

Pelajaran utama

• Intinya adalah "Jika definisi selesai tidak dinyatakan di awal, hasilnya tidak bisa dipercaya"
• Menulis kriteria penerimaan lebih sulit daripada menulis prompt, tetapi memaksa kita mempertimbangkan edge case sejak awal, sehingga kualitas meningkat
• Sama seperti alasan engineer menolak TDD, ada resistensi karena terasa lebih lambat di awal
  • Tanpa kriteria penerimaan, yang bisa dilakukan hanya membaca hasil dan berharap itu benar
• Ini adalah prosedur wajib untuk memastikan keandalan dalam lingkungan pengembangan yang digerakkan AI

[github88]

Sebanyak apa pun TDD dilakukan, pada level sekarang di mana LLM bisa memanipulasi tes agar lolos, review oleh manusia tetap mutlak diperlukan..

[GN⁺]

Komentar Hacker News

• Rasanya framework LLM yang bermunculan belakangan justru membuat pengembangan jadi lebih sulit dan mahal
  Dengan konfigurasi dasar saja sebenarnya sudah bisa melangkah cukup jauh, jadi membuat begitu banyak wrapper dan harness saat model terus berubah terasa tidak efisien
  Pendekatan seperti ini, yang dibiarkan berjalan semalaman sambil membakar uang, rasanya nanti akan dikenang sebagai bahan tertawaan seperti meme PHP

  • Ceritanya berbeda kalau dilihat dari sudut pandang penjual sekop di tengah ledakan AI
    Menurut artikel itu, “selama 6 bulan terakhir mereka telah mengadakan workshop Claude Code untuk lebih dari 100 engineer”
  • Saya berharap para pesaing memakai agen AI sebanyak mungkin di codebase mereka
    Nanti saat mereka menjalankannya siang malam sampai akhirnya perusahaan AI bangkrut, dan yang tersisa cuma spaghetti code buatan AI sebanyak 80%, kita lihat saja siapa yang tertawa
  • PHP bukan sesuatu yang pantas ditertawakan. Beberapa proyek terbaik saya sampai sekarang justru dibuat dengan PHP
    Saya malah merasa PHP 15 tahun lalu lebih baik daripada lingkungan full-stack JS/TS masa kini
  • Baru sekarang kelihatan betapa bodohnya meme anti-PHP dulu
    PHP masih hidup dan terus berkembang. Tooling LLM pada akhirnya juga akan menjadi alat dasar seperti itu
  • Ini bukan sekadar pekerjaan yang bertambah, melainkan peleburan peran
    Batas antara BA, PO, QA, dan SWE makin kabur. Kini muncul peran hibrida yang berada di tengah antara bisnis dan pengembangan

• Sekarang rasanya orang memakai agen cuma demi bisa bilang mereka memakainya
  Saya sendiri hanya menjalankan dua agen, satu untuk menulis dan satu untuk review, dan itu saja sudah cukup memberi produktivitas 5–7x
  Saya menghabiskan lebih banyak waktu untuk meninjau spesifikasi, sementara coding diselesaikan agen dalam 10–30 menit, jadi tidak ada yang perlu diburu

  • Saya tidak paham konsep “agen yang berjalan semalaman”. Claude biasanya selesai dalam 5–20 menit
    Besok juga pekerjaan masih ada, jadi tidak ada alasan harus menjalankannya semalaman
  • Saya juga awalnya menjalankan beberapa agen secara paralel, tapi pada akhirnya fokus per direktori jauh lebih efisien
  • Sebagian besar pekerjaan yang dulu dikerjakan SWE sekarang bisa ditangani AI dengan brute force
    Dari sudut pandang pelanggan, tidak banyak bedanya apakah bug datang dari India, San Francisco, atau AI
  • Saya juga hanya menjalankan dua agen sambil banyak melakukan penyesuaian halus
    Ini jauh lebih terkendali dibanding ‘orkestrasi agen’ yang sedang populer
  • Saya rasa validasi spesifikasi adalah tahap yang paling penting
    Karena itu saya membuat sendiri skill verify untuk memastikan Claude benar-benar mengikuti spesifikasi

• Jika Claude diminta memakai pola red-green-refactor, kualitas test memang naik secara nyata
  Lebih jauh lagi, membuat subagen red/green/refactor yang saling memverifikasi juga bekerja cukup baik
  Kuncinya adalah jangan mencampur konteks

  • Tapi ketika refactoring berlangsung, test sering kali jadi tidak berguna atau malah hilang
    Reward hacking itu nyata dan sulit dicegah
  • Bahkan saat diminta melakukan red/green TDD, ia bisa menulis test yang tidak pernah gagal lalu berkata “sudah terselesaikan” dan lanjut saja
    Meski merujuk ke panduan ini, masalah test buruk tetap besar
  • Saya sudah menerapkan Outside-in TDD sepenuhnya ke Claude Code
    Hasilnya bagus, jadi saya membagikan prinsip dan contoh serta starter repo
  • Saya ingin tahu lebih detail cara mengimplementasikan pola green/red/refactor. Akan bagus kalau ada referensi
  • Pendekatan ini juga efektif untuk review PR
    Pemisahan antara penulis dan validator itu penting, dan bahkan dengan model yang sama kualitas naik jika konteksnya dipisahkan

• Dengan batas konteks LLM saat ini, agen sungguhan masih belum mungkin
  Di kode lebih dari 500 baris, error meningkat tajam, dan sekitar 200 baris sudah menjadi batas praktis
  Pada akhirnya LLM hanyalah alat yang harus dipakai berulang-ulang seperti kalkulator

• Saya menyebut fenomena ini sebagai “Test Theatre”
  Saya menulis tentangnya di sini. Ini sesuatu yang harus dihindari secara aktif

  • Agen kadang menulis 600 baris test untuk 100 baris kode, tetapi sebagian besar hanyalah test tanpa makna
    Test yang baik harus memverifikasi pola desain dan dependensi, serta membantu debugging
  • Menggunakan property testing memberi hasil yang jauh lebih baik
    Misalnya dengan Schemathesis untuk memverifikasi secara otomatis hak akses pengguna atau ada tidaknya respons 5xx
  • Test Theatre adalah istilah yang tepat. Test bisa lolos, tetapi sebenarnya tidak membuktikan apa pun
  • Cara terbaik adalah memaksakan Outside-in TDD + mutation testing
    POC terkait saya unggah di sini
  • Sebenarnya test formalistik seperti ini sudah ada sejak lama. Kebanyakan hanya mengetes implementasinya sendiri

• Belakangan ini saya sedang bereksperimen dengan orkestrasi agen
  Intinya adalah mengurangi pemanggilan LLM dan menghubungkannya lewat pipeline skrip deterministik
  Rinciannya saya tulis dalam artikel ini

  • Saya juga sedang mencoba orkestrasi yang berpusat pada skrip dengan cara serupa
    Seperti catatan eksperimen ini, skrip lebih menjadi inti daripada LLM

• Saya menjalankan 6 agen untuk operasional bisnis
  Mereka menangani berbagai peran seperti riset pasar, penulisan konten, dan skrip video
  “Menjalankannya semalaman” itu konsep yang dilebih-lebihkan; dalam praktiknya yang efektif justru tujuan yang jelas dan cakupan sempit
  Bottleneck yang sebenarnya bukan eksekusi, melainkan manajemen konteks

  • Pendekatan yang menarik. Saya penasaran produk apa yang sedang dibuat, dan apakah riset berbasis Reddit masih efektif

• Saya tidak paham sebenarnya orang ini sedang membuat apa
  Di LinkedIn yang terlihat hanya tulisan tentang Claude

  • Merilis kode yang bahkan tidak bisa diverifikasi adalah risiko serius
    Untuk bisnis yang benar-benar serius, hal seperti ini bahkan sulit dibayangkan
  • Dalam 25 tahun pengalaman saya di industri, tidak pernah ada perusahaan yang butuh kode secepat ini
    Pada akhirnya kode itu cuma menganggur sementara mereka sibuk mencari cara menjualnya

• Ini sama seperti saat mempekerjakan orang yang hanya menulis test
  Pada akhirnya yang dipastikan cuma “kode berjalan sesuai kodenya”
  Pendefinisian spesifikasi yang jelas jauh lebih penting

  • Test setelah fakta kebanyakan hanyalah verifikasi tautologis
    Mengejutkan bahwa bidang rekayasa lain tidak terus mengulangi kesalahan ini, sementara software justru sangat sering
  • Nilai sebenarnya dari test ada pada pencegahan regresi
    Bahkan jika rilis awal salah, setidaknya ia menjamin perilaku berikutnya tidak berubah
  • Tujuan test pada akhirnya adalah verifikasi mock
  • Kuncinya adalah mendefinisikan spesifikasi lebih dulu lalu memverifikasinya sesuai itu
    Banyak perusahaan konsultan bekerja dengan verifikasi berbasis acceptance criteria

• AI saat ini bukan lagi alat bantu pengembangan, tetapi sudah sampai pada tingkat menggantikan developer
  Fakta bahwa kita tidak lagi bisa mengendalikan atau memverifikasi kode adalah masalah serius
  Ini terasa bukan seperti cara pengembangan baru, melainkan pergeseran yang nyaris religius, bergantung pada kepercayaan alih-alih pemahaman

  • Saya tidak akan pernah merilis kode yang tidak saya pahami
    Meski otonominya rendah, saya hanya akan merge kode yang bisa diverifikasi
  • Atau kita perlu bergerak ke arah alat seperti verifikasi formal (formal methods) untuk menjamin keamanan kode