Cek Pemahaman Kode AI vs Tes: Kapan Masing-masing Menang

Ini skenario yang makin sering terjadi: coding agent-mu menulis 600 baris di empat file, tesnya lolos, linter-nya senang, dan kamu melakukan merge. Dua minggu kemudian kode itu rusak di produksi dan kamu menatap diff-nya seperti kode buatan orang asing, padahal secara fungsional memang orang lain yang menulisnya. Kegagalannya bukan ada di kodenya. Kegagalannya ada di celah antara kode dan model mental kamu tentangnya. Celah inilah yang coba ditutup oleh cek pemahaman kode AI, yaitu gerbang yang memberi kuis tentang diff sebelum kode dikirim. Sebuah Git hook open-source baru bernama Sphinx ramai dibicarakan minggu ini karena melakukan persis itu: sebelum push-mu diteruskan, ia membaca diff dan mengajukan pertanyaan tentang apa yang dilakukan kode saat terjadi kegagalan.

Insting saya sebagai mantan ML engineer adalah skeptis. Gerbang lagi? Ritual lagi? Tapi makin saya pikirkan mode kegagalan yang benar-benar saya temui pada kode hasil agent, makin saya yakin ide ini menyasar sesuatu yang secara struktural tidak bisa dijangkau tes. Jadi mari kita bandingkan secara jujur: cek pemahaman versus jaring pengaman otomatis yang sudah kamu punya, yaitu tes, linter, type checker, dan CI, serta kapan masing-masing benar-benar menang.

Apa Sebenarnya yang Diverifikasi Tes dan Linter

Pemeriksaan otomatis menjawab satu pertanyaan: apakah kode berperilaku sesuai yang diharapkan pemeriksaan? Ini adalah loop yang sepenuhnya tertutup di dalam mesin. Sebuah tes merekam keyakinan seseorang tentang perilaku yang benar; kode memenuhinya atau tidak, dan tidak diperlukan pemahaman manusia saat merge. Ini justru fitur. Inilah yang memungkinkan seratus engineer mengirim kode ke repo yang sama tanpa harus membaca pekerjaan satu sama lain.

Masalahnya ada pada asumsi yang melekat di model itu: bahwa orang yang melakukan merge punya model mental yang akurat tentang apa yang seharusnya dilakukan kode, dan bahwa suite tes mencerminkannya. Pada kode yang ditulis tangan, asumsi itu sebagian besar terpenuhi. Kamu yang menulisnya, kamu yang bergulat dengannya, dan kamu tahu di mana bangkai-bangkainya dikubur. Pada kode hasil agent, asumsi itu diam-diam runtuh. Kamu mendeskripsikan tujuan, agent menghasilkan implementasi, dan tesnya lolos karena agent juga yang menulisnya. Centang hijau kini hanya memastikan bahwa kode agent cocok dengan tes agent. Pemahamanmu tidak pernah ikut dalam loop.

Ini jebakan yang sama seperti yang saya bahas di mengapa benchmark AI melewatkan sebagian besar pekerjaan nyata: sebuah metrik hanya bisa memvalidasi apa yang diukurnya. Suite tes mengukur kesesuaian perilaku pada kasus-kasus yang kebetulan dipikirkan seseorang untuk ditulis. Tes tidak bisa memberi tahu apakah logika retry-mu menagih pelanggan dua kali saat timeout Stripe, apakah agent memilih endpoint yang salah sama sekali, atau apakah 'perbaikan' itu menutupi race condition dengan menelan exception. Itu semua kegagalan pemahaman, dan semuanya lolos dari CI begitu saja.

Yang Ditangkap Cek Pemahaman tapi Terlewat Tes

Cek pemahaman membalik arah verifikasi. Alih-alih bertanya 'apakah kode ini berfungsi?', ia bertanya 'apakah manusia yang mengirim kode ini tahu apa yang terjadi saat keadaan memburuk?' Contoh ilustratif dari Sphinx cukup bagus: handler webhook-mu sekarang menyimpan ID event Stripe sebelum memanggil charge(). Apa yang terjadi saat retry setelah timeout? Kalau kamu menjawab 'pelanggan ditagih dua kali', kamu salah, karena ID yang tersimpan memotong retry. Tapi lanjutannya: jika charge() itu sendiri gagal, apa yang dilakukan retry berikutnya? Ia melewati charge. Pelanggan tidak pernah ditagih, dan tidak ada tes yang gagal, karena ini adalah pola idempotency yang terlihat benar tapi diterapkan dengan urutan yang salah.

Perhatikan jenis bug ini. Ini bukan syntax error, type error, atau assertion yang gagal. Ini cacat desain yang baru muncul di urutan kegagalan tertentu, dan satu-satunya cara murah untuk menangkapnya sebelum produksi adalah manusia yang menalar jalur kegagalannya. Tes bisa menangkapnya, kalau seseorang menulis tes untuk 'charge gagal setelah ID event tersimpan'. Tapi orang yang akan menulis tes itu adalah orang yang memahami risiko urutan tersebut, dan kalau orang itu ada, kita tidak akan sampai di sini. Cek pemahaman justru menggali pemahaman persis yang akan menghasilkan tes yang hilang itu.

Ada manfaat kedua yang kurang soal menangkap bug dan lebih soal membalik kebocoran skill yang lambat. Banyak developer menggambarkan pengalaman yang sama: memaksa agent sampai menghasilkan hasil yang berfungsi menguras energi tapi tidak meninggalkan apa pun yang dipelajari. Kamu makin banyak mengirim dan makin sedikit memahami, dan celahnya makin membesar. Kuis saat push memaksa setidaknya rekonstruksi dangkal atas logika diff, dan itu sering cukup untuk mengubah 'kode yang saya setujui' kembali menjadi 'kode yang saya miliki'. Saya pernah berargumen bahwa alat AI diam-diam mengubah cara developer berpikir; gerbang seperti ini adalah salah satu alat pertama yang mendorong ke arah sebaliknya.

Kapan Tes Otomatis Menang

Jangan romantisasi gerbang manusia. Tes menang telak di beberapa arena, dan berpura-pura sebaliknya adalah cara tercepat untuk berakhir dengan kuis sebagai satu-satunya jaring pengaman.

• Deteksi regresi dalam skala besar. Tidak ada model mental yang bertahan dari refactor 30.000 baris. Tes memverifikasi ulang ribuan perilaku per commit dengan biaya receh. Cek pemahaman mungkin hanya mencakup tiga pertanyaan untuk satu diff.
• Kebenaran mekanis. Off-by-one error, format string yang salah, dan time zone yang tertangani keliru. Mesin jauh lebih baik memeriksa ini secara menyeluruh daripada manusia yang menjawab pertanyaan di bawah tekanan waktu.
• Keterulangan. Tes berjalan identik selamanya. Kualitas pertanyaan kuis bergantung pada model yang membuatnya dan seberapa segar kamu di jam 5 sore hari Jumat.
• Kepercayaan saat refactor. Ketika perilaku seharusnya sama sekali tidak berubah, tes adalah satu-satunya pemeriksaan yang bermakna. Memahami kode tidak membantumu memverifikasi bahwa kamu tidak mengubahnya.

Ada juga jenis kode di mana cek pemahaman hanya menambah gesekan tanpa nilai: boilerplate hasil generate, migrasi mekanis, bump dependency, dan perubahan konfigurasi. Memberi kuis tentang apa yang dilakukan reformat Prettier itu bukan gerbang, melainkan pajak. Alat apa pun di ruang ini perlu jawaban yang baik untuk diff berisiko rendah, atau orang akan mencari jalan memutar. Menariknya, Sphinx mengantisipasi ini dengan jalan keluar sphinx yolo yang mencatat setiap lewatan. Pencatatan itu lebih penting dari kelihatannya; gerbang yang diam-diam dilewati semua orang lebih buruk daripada tidak ada gerbang sama sekali.

Kapan Cek Pemahaman Menang

Cek pemahaman menang tepat di tempat manusia adalah mata rantai terlemah, yang dalam pengembangan berbantuan agent terjadi lebih sering daripada yang ingin kita akui.

• Penalaran jalur kegagalan. Retry, timeout, penulisan parsial, dan transaksi terdistribusi adalah jalur kode yang hanya jalan saat ada hal lain yang sudah rusak. Agent cukup bagus untuk happy path dan sembrono untuk sad path.
• Diff dengan radius dampak tinggi. Pembayaran, auth, migrasi data, atau apa pun yang menyentuh sistem yang harus tahan terhadap bencana. Biaya jawaban yang salah di sini jauh lebih besar daripada dua menit gesekan kuis.
• Kode yang tidak kamu tulis dan hampir tidak kamu review. PR 1.500 baris dari rekan non-developer, atau branch otonom semalam dari agent. Seorang praktisi melaporkan memakai prompt 'beri aku kuis tentang PR ini' hanya untuk tetap fokus saat melakukan review terstruktur atas kode semacam ini.
• Onboarding dan pemeliharaan skill. Jika timmu mengirim kode agent lebih cepat daripada ada orang yang mempelajari domainnya, gerbang pemahaman adalah forcing function termurah yang tersedia.

Benang merahnya: cek pemahaman layak dipakai saat diff berdampak besar dan model mental manusia patut dicurigai. Itu niche yang spesifik, bukan solusi universal.

Mode Kegagalan dari Gerbang Itu Sendiri

Saya akan berbuat tidak adil kalau tidak menyertakan daftar jujur tentang cara ini bisa salah, karena para skeptis punya poin yang valid.

Pertama, kelelahan konfirmasi. Kita sudah pernah ke sini: banner cookie, dialog 'yakin?', dan pertanyaan keamanan yang semua orang klik begitu saja. Gerbang yang aktif di setiap push melatih orang untuk menjawab cepat alih-alih berpikir, dan dalam sebulan kuis itu menjadi teater ritual. Mitigasinya adalah pembatasan cakupan: jalankan di protected branch dan jalur berisiko tinggi, bukan di setiap commit ke feature branch.

Kedua, kualitas pertanyaan. Kuis dibuat oleh LLM yang membaca diff, yang berarti ia mewarisi mode kegagalan LLM: pertanyaan dangkal, jawaban 'benar' yang keliru, dan terobsesi pada perubahan yang jelas sambil melewatkan yang halus. Seorang reviewer mencatat bahwa versinya membantu menyusun review tapi tidak menangkap keputusan buruk seperti memanggil endpoint yang salah. Pertanyaan yang buruk lebih berbahaya daripada tidak ada pertanyaan, karena ia memberi sertifikat pemahaman yang sebenarnya tidak diuji. Ini keterbatasan nyata dan saya tidak yakin bisa sepenuhnya diselesaikan; alasan yang sama mengapa desain agent harness lebih penting daripada pilihan model di banyak alat semacam ini.

Ketiga, dan yang ini membuat saya tertawa karena memang benar, suatu saat seseorang pasti akan mengarahkan agent ke gerbang itu untuk menjawab pertanyaannya. Desain alat ini menunjukkan kesadaran akan hal tersebut: jawabanmu tidak pernah sampai ke coding agent, dan secret tetap tertutup. Tapi tidak ada yang mencegah developer yang bertekad menempelkan pertanyaan ke jendela chat. Pada titik itu, alat tersebut sebenarnya mengukur kesediaan untuk curang, yang merupakan masalah budaya yang tidak bisa diperbaiki oleh hook mana pun.

Gerbang pemahaman tidak memverifikasi kode. Ia memverifikasi bahwa manusia dengan konteks dan tanggung jawab benar-benar terlibat dengannya, dan itulah hal yang diam-diam dihilangkan oleh alur kerja agent.

Memasang Gerbang ke Alur Kerja Nyata

Kalau kamu ingin mencobanya, ada dua opsi praktis. Jalur berfriksi rendah adalah skill berbasis prompt di agent-mu yang sudah ada: 'beri aku kuis tentang branch saat ini sebelum aku membuka PR'. Beberapa orang sudah membuatnya persis begini dan melaporkan hasilnya bagus untuk menyusun review. Tapi perhatikan bahwa ini bergantung pada kamu yang memilih untuk menjalankannya, dan itu gagal justru saat kamu paling terburu-buru.

Jalur yang dipaksakan adalah Git hook. Sphinx terpasang dalam semenit: npm install -g sphinx-understand, lalu sphinx install, yang menghubungkan Git dan coding agent-mu serta menanyakan model mana yang sebaiknya mereview. Ia bekerja dengan Claude Code, Codex, Cursor, dan lainnya, atau Git biasa, dan bisa berjalan di endpoint apa pun yang kompatibel dengan OpenAI. Kalau kamu lebih suka membuat sendiri, kerangkanya adalah hook pre-push:

#!/usr/bin/env bash
# .git/hooks/pre-push — quiz gate for protected branches
protected_branch="main"
current_branch=$(git rev-parse --abbrev-ref HEAD)
if [ "$current_branch" != "$protected_branch" ]; then
exit 0  # only gate the branches that matter
fi
diff=$(git diff origin/main...HEAD)
if [ -z "$diff" ]; then
exit 0
fi
# Send the diff to your model of choice, get a scenario question,
# check the answer. Pseudocode for the core loop:
question=$(quiz_generate "$diff")
echo "$question"
read -r answer
if ! quiz_verify "$diff" "$question" "$answer"; then
echo "Not quite — here's why. Push blocked; try again."
exit 1
fi

Dua keputusan desain lebih penting daripada kodenya. Pasang gerbang di branch, bukan push: aktifkan pada push ke main dan release branch, dan idealnya juga saat 'request review', karena menangkap kode asal-asalan sebelum ia menyita perhatian rekan satu tim mungkin adalah penempatan dengan nilai tertinggi. Dan catat setiap bypass. Jalan keluar itu perlu; jejak audit yang membuatnya tetap jujur.

Pertimbangkan juga posisinya terhadap review manusia. Saya pernah menulis tentang bagaimana setiap lapisan review membuat tim melambat, dan saya masih memegang itu, jadi jangan menambahkan ini di atas semuanya. Gunakan untuk menggantikan lapisan review pertama dan paling dangkal: pemeriksaan 'apakah penulisnya tahu apa yang dilakukan kode ini'. Itulah satu-satunya pemeriksaan yang benar-benar bisa diotomatisasi oleh cek pemahaman.

Rekomendasi

Tes dan cek pemahaman bukan pesaing; mereka memverifikasi subjek yang berbeda. Tes memverifikasi kodenya; cek pemahaman memverifikasi orang yang bertanggung jawab atasnya. Pengembangan berbantuan agent memecahkan asumsi implisit bahwa keduanya adalah hal yang sama, dan gerbang ini adalah tambalan yang pragmatis, bukan gimmick.

Rekomendasi saya: pertahankan suite tes sebagai jaring pengaman utama, karena tidak ada yang di sini menggantikannya, dan tambahkan gerbang pemahaman secara sempit, di protected branch dan jalur berisiko tinggi, dengan jalan keluar yang tercatat. Kalau sebagian besar kodemu kamu tulis sendiri, kamu tidak butuh ini; nilai gerbangnya bergantung pada seberapa banyak diff-mu yang tidak kamu tulis. Dan kalau kuis mulai terasa seperti beban yang terus kamu hindari, itu juga sinyal: artinya kamu mengirim kode yang tidak kamu pahami lebih cepat daripada jeda dua menit terasa murah. Renungkan itu. Versi yang tidak nyaman dari tesis alat ini adalah yang benar: kamu boleh mengalihkan pemikiran, tapi pemahaman harus tetap milikmu, karena pada jam 3 pagi saat loop retry menagih tanpa ada yang tahu, agent tidak sedang on call. Kamulah yang on call.