Jangan Review Kerjaan Agent dari Diff Kodenya — Suruh Dia Buktiin Dulu
Minggu ini gw berhenti scroll gara-gara satu thread di X dari Guillermo Rauch, CEO-nya Vercel. Dia lagi ngasih satu bug ke agent-nya: ada yang salah render di browser dalam-aplikasi waktu dibuka di mobile.
Yang bikin gw mikir bukan bug-nya. Tapi cara agent itu nyelesaiin.
Alih-alih langsung nebak-nebak di kode, agent-nya reproduksi dulu masalahnya, bikin ephemeral deployment di Vercel, lempar hasilnya ke simulator iPhone buat dites beneran, baru fix. Habis itu deploy, dan verifikasi lagi sampe bener-bener beres. Rauch nyebut prosesnya "the absolute grind on these things," dan dia bilang manusia gabisa nandingin level intensitas kayak gitu.
Post-nya dapet 376 likes dalam sehari. Angkanya gede, tapi yang bikin gw lama mikir justru polanya, bukan angka-nya.
Pola Lama: Agent Nulis, Manusia yang Ngecek
Selama ini cara kerja yang gw pake — dan kayaknya lo juga — kira-kira gini: agent nulis kodenya, terus manusia yang nyari tau apakah hasilnya jalan apa nggak.
Artinya kerjaan verifikasi ada di lo. Lo buka preview, lo klik-klik manual, lo nebak-nebak bagian mana yang berubah dan apakah perubahan itu beneran nyentuh akar masalahnya. Kalo ada yang aneh, lo balik lagi ke agent, jelasin ulang, tungguin lagi. Terus ulang dari awal.
Ini persis titik mentok yang paling sering gw temuin di project hasil vibe coding: app-nya jalan, tapi lo udah gak berani nyentuh. Bukan karena kodenya jelek, tapi karena lo gak punya cara murah buat tau perubahan lo rusak apa nggak. Makin lama didiemin, makin numpuk.
Kenapa Ini Berat: Verifikasi Itu Kerjaan yang Gak Ada Habisnya
Masalahnya bukan cuma capek. Masalahnya, tiap kali lo harus ngecek manual, lo sebenernya jadi bagian dari proses yang harus bolak-balik.
Satu perubahan kecil, satu kali review manual. Dua perubahan, dua kali. Skalanya gak pernah nambah, karena yang jadi penentu cepet-lambatnya adalah seberapa cepet lo bisa ngeceknya sendiri. Dan review manual itu gak murah — bukan cuma waktunya, tapi juga rasa takutnya. Akhirnya lo jadi makin enggan nyentuh project yang sebenernya jalan.
(Dan jujur aja, sebagian dari kita "review"-nya cuma scroll diff cepet, mikir "yaudah kayaknya bener", terus doa pas deploy. Candaaa. Tapi lo tau itu bener.)
Yang Rauch Lakuin: Verifikasi Jadi Syarat di Depan
Yang bikin pola Rauch beda: agent-nya gak boleh lapor balik cuma dengan kode. Dia wajib ngebuktiin perubahannya jalan di lingkungan nyata dulu, dan baru setelah itu manusia ngeliat.
Jadi urutannya kebalik. Bukan "agent nulis, manusia verifikasi", tapi "agent nulis, agent verifikasi di lingkungan nyata, manusia baru review yang udah keuji."
Ini bukan cuma soal Vercel atau deployment yang mahal. Ini soal di mana lo naruh syaratnya. Kalo verifikasi jadi syarat yang lo minta di depan, agent-nya yang tanggung jawab ngebuktiin. Kalo verifikasi jadi kerjaan yang lo kejar di belakang, lo yang tanggung jawab nebak.
Cara Paling Sederhana Buat Mulai Minggu Ini
Lo gak perlu punya pipeline sekompleks Vercel buat nyoba ini. Yang berubah cuma satu kalimat di instruksi lo.
Mulai minggu ini, tiap lo minta agent ngerjain sesuatu, jangan berhenti di "tulis kodenya". Tambahin satu syarat sebelum dia lapor balik:
- Reproduksi dulu masalahnya — buktiin lo ngerti apa yang salah, bukan cuma nebak.
- Jalanin di lingkungan nyata — preview deployment sementara, test suite, atau simulator. Apa aja yang bisa diakses agent lo.
- Tunjukin buktinya — screenshot, output test, atau URL preview. Bukan sekadar "udah gw benerin".
Gw sendiri belum punya setup sejago itu. Tapi versi kecilnya udah bisa gw jalanin: minta agent bikin preview, jalanin test-nya, dan tempelin hasilnya sebelum gw buka. Lo gak perlu nunggu punya infrastruktur gede buat mulai nanya "mana bukti kalau ini jalan?".
Verifikasi bukan hal yang lo tambahin belakangan kalau sempet. Dia yang nentuin kerjaan mana yang aman lo serahin ke agent.
Kalo lo mau ngobrolin cara naruh verifikasi di depan buat project lo sendiri, mampir ke aibuilders.id.
Sumber:
