Bagaimana build memverifikasi dirinya sendiri

0:00 — sebuah build selesai. Agen mengatakan sudah selesai, yang merupakan klaim tentang penulisan kode, bukan tentang apakah kode itu berfungsi. Setiap pengguna builder AI pernah merasakan celah antara kedua klaim itu setidaknya sekali: preview dibuka, tombol ketiga diklik, tidak terjadi apa-apa. Saya pernah melihat ruang demo tiba-tiba sunyi tepat di momen itu. Jadi sebelum ada manusia yang melihat build, ia melewati sekitar enam menit di mana sebuah rantai proses berdebat dengan dirinya sendiri. Beginilah wujud nyatanya, ditelusuri lewat satu build yang kami amati saat bermasalah lalu diperbaiki.

0:02 — tinjauan kode dimulai. Bukan agen yang menulis kode itu membaca ulang tugasnya sendiri — melainkan agen terpisah, dengan prompt berbeda, tanpa kepentingan agar build itu lolos. Pemisahan ini penting lebih dari yang terdengar. Agen yang memutuskan pada pukul 14:14 bahwa pemanggilan fetch tanpa penanganan error itu tidak masalah, masih akan berpikir begitu pada pukul 14:15 jika diminta memeriksa pekerjaannya sendiri. Peninjau baru yang diberi tahu "cari yang rusak, sebutkan filenya" bertindak layaknya insinyur senior yang cerewet yang justru Anda inginkan untuk tugas ini. Pada build sebelumnya, ia menemukan total keranjang belanja yang diam-diam tidak pernah diperbarui — `updateTotal` didefinisikan di `Cart.jsx` tetapi tidak pernah dihubungkan ke handler perubahan kuantitas, jadi fungsi itu ada namun tidak pernah dijalankan. Itulah kategori yang ditangani oleh tinjauan kode — hal-hal yang diabaikan begitu saja oleh compiler.

0:04 — audit keamanan. Sengaja dibuat lebih sempit dari kedengarannya — ini bukan pentest, melainkan pencarian pola untuk sejumlah kesalahan yang benar-benar sering muncul di kode buatan AI. SQL yang disusun dari penggabungan string. Validasi hanya di sisi klien yang dipercaya seolah itu sudah cukup. Dan yang paling khas: API key yang di-hardcode, karena agen yang menulis fitur itu tidak punya konvensi environment variable di depannya, jadi ia mengambil jalan yang berhasil. Kami cukup sering menemukan yang satu ini sampai nyaris tidak lagi mengejutkan.

0:07 — tautan dan SEO. Tidak glamor, dan menangkap hal-hal yang tidak disadari siapa pun sampai pelanggan menyadarinya: tautan navigasi yang mengarah ke /pricing padahal halaman itu sebenarnya dihasilkan di /price, entri sitemap untuk halaman yang menampilkan 404, deskripsi meta yang masih menyimpan teks placeholder template. Tidak satu pun dari itu merusak build. Tapi semuanya diam-diam menggagalkan hal utama yang ingin dicapai sebagian besar pengguna kami dengan membangun situs mereka — ditemukan, diklik.

0:09 — aksesibilitas. Ini adalah pemeriksaan otomatis axe-core, bukan audit manual penuh, dan penting untuk jujur soal apa yang didapat dari trade-off ini. axe-core menangkap rasio kontras, alt text yang hilang, input formulir tanpa label, jebakan urutan tab — lapisan mekanis, sekitar 30-40% dari yang akan ditemukan oleh tinjauan WCAG penuh. Ia tidak akan menangkap pengalaman pembaca layar yang secara teknis sudah sesuai standar tetapi sebenarnya membingungkan untuk digunakan. Kami memilih otomatis saja karena berjalan dalam hitungan detik dan sebagian besar yang dirilis lewat sini adalah situs pemasaran dan alat kecil, bukan jenis aplikasi di mana audit sebagian menjadi risiko nyata bagi seseorang.

0:11 — kesesuaian. Lapisan ini bukan bertanya "apakah ini bagus," melainkan "apakah ini sesuai dengan yang dijanjikan." Rencana bilang empat halaman, build merilis tiga — kesesuaian yang menyadari itu. Rencana menjanjikan formulir kontak yang berfungsi, yang dirilis adalah formulir tanpa aksi submit — lapisan yang sama, temuan yang sama. Ini adalah pemeriksaan yang paling langsung bertanggung jawab kepada pengguna, karena mengukur terhadap maksud yang dinyatakan pengguna, bukan gagasan abstrak tentang kualitas.

0:13 — pemeriksaan langsung di browser, dan di sinilah build kami sebenarnya bermasalah. Lapisan ini paling sulit dicurangi karena tidak membaca kode, melainkan menjalankan browser sungguhan — mengklik, mengetik, menunggu, memeriksa apakah DOM berubah sebagaimana mestinya. Build yang dimaksud adalah game idle, dan game mendapat pemeriksaan tambahan di sini karena sebuah game bisa tampil sempurna piksel demi piksel namun tetap tidak bisa dimainkan — tampilan skor bisa terlihat sempurna sementara sama sekali terputus dari logika penilaian. Verifier memainkannya. Skor terupdate dengan baik. Audionya tidak berbunyi sama sekali.

Tiga ronde, lalu eskalasi

Temuan itu tidak sampai ke kami sebagai laporan bug — langsung masuk ke tahap perbaikan, dan rantai proses melakukan verifikasi ulang, hingga tiga ronde di dalam build. Ronde pertama: perbaikan menyentuh inisialisasi mixer, yang sebenarnya sudah baik-baik saja, sehingga audio tetap diam. Ronde kedua: perbaikan lain menangani kasus tepi status loading yang terlihat berhubungan, dan — ini lebih sering terjadi daripada dugaan Anda — memunculkan masalah kecil baru tanpa menyelesaikan masalah aslinya. Ronde ketiga: masih diam, dan pada titik ini biasanya Anda menghadapi sesuatu yang benar-benar sulit atau alarm palsu, dan ini termasuk jenis yang sulit.

Jadi platform ini melakukan eskalasi dengan sendirinya. Ia menjadwalkan proses perbaikan lanjutan yang seluruhnya difokuskan pada temuan yang masih bertahan, bekerja pada salinan build, bukan build itu sendiri — artinya proses eskalasi itu bisa gagal tanpa mengorbankan versi yang sudah berfungsi yang sudah kami miliki. Proses itu menemukan penyebab sebenarnya: flag mute yang diset selama sesi debug sebelumnya dan tidak pernah dikembalikan, berada di file yang sama sekali berbeda dari dua perbaikan sebelumnya. Flag itu dibersihkan, diverifikasi ulang, lolos. Tidak ada seorang pun yang melihat build ini sampai ia benar-benar berfungsi.

Apa yang akan saya lewati lain kali

Beberapa bulan sebelum game idle itu berjalan, kami mencoba versi sistem yang lebih longgar — verifier boleh mengangkat masalah apa pun, dengan kata-kata bebas. Hasilnya adalah temuan seperti "pertimbangkan untuk mengekstrak ini menjadi helper" dan "nama variabel ini bisa lebih jelas," yang terlihat seperti ketelitian tapi tidak memperbaiki apa pun. Proses perbaikan menghabiskan seluruh ronde untuk memoles teks alih-alih memperbaiki yang benar-benar rusak. Kami memperketat aturannya menjadi: sebutkan sebuah file, jelaskan kegagalannya, atau diam saja. Output verifier turun sekitar separuhnya dan hampir semua yang tersisa bisa ditindaklanjuti. Kalau saya membangun ulang ini dari awal, saya akan langsung lewati versi yang longgar itu dan langsung ke aturan bukti — kami tidak perlu belajar pelajaran itu dengan cara yang mahal, tapi kami melakukannya juga.

Aturan ini punya biaya nyata, dan saya tidak akan berpura-pura sebaliknya: kekhawatiran yang samar tapi benar seperti "desain API ini akan menggigit seseorang enam bulan lagi" sekarang diabaikan begitu saja, karena verifier tidak bisa mengaitkannya dengan kegagalan konkret. Kami sudah menerima trade-off itu. Rantai proses yang juga melakukan tinjauan arsitektur tidak cukup cepat untuk dijalankan pada setiap build, dan kecepatan adalah inti dari menjalankan ini secara otomatis, bukan meminta manusia melakukannya.

Saya juga akan melewatkan penambahan ronde keempat, kalau ada yang bertanya. Kami menyetel jumlah ronde berdasarkan build nyata, dan nilai tambahan setelah ronde ketiga menurun drastis — ronde pertama menyelesaikan sebagian besar temuan yang bisa diperbaiki, ronde kedua sebagian besar membereskan masalah yang muncul akibat ronde pertama, dan pada ronde ketiga yang tersisa adalah hal yang benar-benar sulit atau memang tidak pernah benar-benar rusak. Ronde keempat sebagian besar hanya membeli waktu tunggu lebih lama untuk hasil yang sama.

Semua ini tidak gratis, dan tidak ada yang sempurna. Enam lapisan ditambah berapa pun ronde perbaikan yang diperlukan menambah waktu nyata pada setiap build — bedanya antara selesai dalam waktu kurang dari satu menit dan selesai dalam beberapa menit. Kami rasa itu trade-off yang tepat untuk apa pun yang akan Anda tunjukkan pada pelanggan sendiri, tapi "cepat" dan "terverifikasi" saling tarik ke arah berlawanan, dan kami memilih terverifikasi. Verifier juga adalah LLM, jadi sesekali mereka menandai sesuatu yang sebenarnya tidak rusak, atau melewatkan sesuatu yang rusak. Aturan bukti dan loop multi-ronde adalah jaminan pengaman untuk itu, bukan garansi.

Yang Anda dapatkan di akhir adalah sebuah catatan: lapisan mana yang berjalan, apa yang ditemukan, apa yang diperbaiki, dan apa yang masih perlu penilaian Anda sendiri. Catatan itu lebih mendekati produk sesungguhnya dibanding kodenya sendiri — itulah bedanya mempercayai sebuah build karena terlihat selesai, dan mempercayainya karena sesuatu yang bersifat menguji berusaha merusaknya lebih dulu dan gagal.