AI Agentik Membutuhkan Lebih Banyak Penguji, Bukan Lebih Sedikit

AI agentik mengubah cara perangkat lunak dirilis. Asisten menyusun pull request, agen memulai migrasi, dan bot peninjau menyatakan bahwa suatu perubahan aman bahkan sebelum manusia selesai minum kopi. Industri sering menggambarkan hal ini sebagai jalan untuk mengurangi jumlah orang yang menangani kualitas. Anggapan itu terbalik. Ketika mesin menulis lebih banyak bagian basis kode, keterampilan yang langka bukanlah menghasilkan kode, melainkan memverifikasinya secara independen.

Survei Pengembang Stack Overflow 2025 menemukan bahwa 84% responden menggunakan atau berencana menggunakan alat AI dalam pengembangan, dan 51% pengembang profesional menggunakannya setiap hari. Sentimen positif turun menjadi 60%, dan lebih banyak pengembang yang secara aktif meragukan keakuratan AI (46%) daripada memercayainya (33%). Keluhan utama, yang disampaikan oleh 66% responden, adalah solusi yang hampir benar, tetapi tetap tidak tepat. Riset DORA Google Cloud 2025 melaporkan bahwa tingkat adopsi AI di kalangan profesional pengembangan perangkat lunak mencapai 90%; lebih dari 80% mengatakan AI meningkatkan produktivitas, tetapi hanya 24% yang melaporkan tingkat kepercayaan yang sangat besar atau tinggi. Kegunaan tanpa kepercayaan justru kondisi yang memperluas tugas penguji, bukan mempersempitnya.

Kecepatan Bukan Bukti

Saya bekerja sebagai Insinyur Kualitas Perangkat Lunak, dengan fokus pada pengujian agentik dan gerbang CI untuk kode yang ditulis AI. Di internal, kami merilis peninjau PR dan pembuat kasus uji. Keduanya adalah alat untuk menyusun draf. Tak satu pun menilai hasil kerjanya sendiri. Aturan itu penting karena agen berbicara dengan penuh keyakinan. Keyakinan bukanlah ketepatan.

Kami mempelajarinya dengan cara yang mahal. Dalam uji coba peninjau PR yang dibuat dengan AI, sebuah perubahan lolos CI dalam waktu kurang dari 4 menit. Dua hari kemudian, dasbor hilir menampilkan suhu yang mustahil. Pembalikan skala Celsius ke Fahrenheit terjadi pada salah satu jalur kode yang tidak pernah diuji oleh rangkaian pengujian. Pipeline menunjukkan status hijau. Produknya salah. CI yang hijau tetapi tidak pernah mengajukan pertanyaan sulit hanyalah sandiwara.

Insiden itu merupakan bagian dari pola yang lebih luas. Laporan CodeRabbit, Laporan Status Pembuatan Kode oleh AI vs Manusia, menganalisis 470 pull request GitHub sumber terbuka (320 ditulis bersama AI, 150 hanya oleh manusia). Perubahan yang ditulis dengan AI menghasilkan sekitar 1,7× lebih banyak masalah secara keseluruhan, dengan masalah logika dan ketepatan 75% lebih sering terjadi serta temuan keamanan hingga 2,74× lebih tinggi. Laporan Keamanan Kode GenAI Veracode 2026 menguji model dalam berbagai tugas keamanan dan menemukan tingkat kelulusan keamanan rata-rata sebesar 56%, nyaris tidak berubah dari 55% pada laporan sebelumnya, sementara sekitar 44% tugas pembuatan kode AI menghasilkan kerentanan yang diketahui. Sintaks hampir tidak lagi menjadi masalah. Perilaku yang aman dan tepat belum teratasi. Penguji adalah orang-orang yang menolak menyamakan keduanya.

Dependensi Halusinasi Merupakan Masalah Pengujian

Proses pembuatan kode juga menciptakan pasokan paket fiktif. Riset USENIX Security 2025, Kami Punya Paket untuk Anda!, mengevaluasi halusinasi paket pada 16 LLM pembuat kode dan 576.000 sampel. Rata-rata, model komersial berhalusinasi tentang paket setidaknya 5,2% dari waktu; rata-rata model sumber terbuka mencapai 21,7%, dengan 205.474 nama fiktif yang unik. Paket fiktif yang terus beredar menciptakan sasaran empuk bagi praktik slop squatting: penyerang mendaftarkan nama yang diciptakan itu lalu menunggu pengembang atau agen memasangnya.

Pemeriksaan asal-usul dependensi harus berada pada tingkat yang sama dengan pengujian fungsional. Jika agen menciptakan paket NuGet atau npm, proses penggabungan harus gagal sebelum siapa pun memperdebatkan apakah pengujian unit sudah menyeluruh. Memastikan asal-usul bukan sekadar praktik kebersihan yang opsional. Ini adalah gerbang kualitas untuk perubahan yang ditulis AI.

Gerbang yang Dapat Mengimbangi Skala Penggunaan Agen

Saat kami menjalankan pemutakhiran .NET 8 ke .NET 10 untuk seluruh organisasi dalam waktu sekitar dua minggu dengan otomatisasi berbantuan AI, saya bertanggung jawab atas gerbang kualitas. Kecepatannya nyata. Begitu pula kebutuhan akan pemeriksaan yang tidak begitu saja memercayai ringkasan agen. Gerbang yang saya terapkan pada kode yang diubah mencakup:

• Target skor mutasi pada kisaran 60% hingga 70% untuk logika yang diubah, sehingga rangkaian pengujian harus menggagalkan mutan yang nyata, bukan sekadar mencakup baris kode
• Pengujian berbasis properti untuk logika berisiko tinggi, ketika contoh saja tidak cukup menjelaskan perilaku yang diharapkan
• Pemeriksaan asal-usul dependensi untuk mencegah slop squatting dan paket halusinasi
• Sinyal duplikasi dan perubahan berulang yang menandai pekerjaan agen yang berputar-putar dengan menyalin dan menempel
• Verifikasi independen atas klaim agen seperti “migrasi selesai”, karena klaim tetap merupakan hipotesis sampai ada bukti

Skor mutasi bukan metrik untuk sekadar terlihat bagus. Metrik ini menguji apakah pengujian Anda mendeteksi kesalahan yang sengaja dimasukkan. Cakupan dapat meningkat sementara rangkaian pengujian tetap luput dari jalur Celsius. Pemeriksaan berbasis properti memastikan model sistem tetap berlaku di berbagai rentang, bukan hanya pada satu jalur yang berjalan mulus. Pemeriksaan asal-usul menutup celah masuknya paket. Perubahan berulang dan duplikasi menangkap kebiasaan agen menulis ulang gagasan yang sama dengan tiga cara berbeda. Secara keseluruhan, semua ini membentuk prinsip kerja: anggap agen keliru sampai rangkaian pengujian membuktikan sebaliknya. Saya mempertahankan kalibrasi itu dalam peninjauan.

Semua ini tidak menggantikan pengujian API, pengujian autentikasi, pengujian dasar, atau otomatisasi UI. FlaUI dan PowerShell tetap menangkap masalah yang luput dari API. Pengemasan melalui NuGet, MSI, dan MSM tetap memerlukan validasi instalasi dan jalur senyap. Alur kerja agentik memperbesar volumenya. Alur tersebut tidak menghapus kebutuhan akan disiplin-disiplin itu.

Lebih Banyak Penguji, Pekerjaan yang Berbeda

Yang dikhawatirkan adalah agen menulis pengujian dan manusia menjadi tidak lagi diperlukan. Agen dapat menyusun kasus pengujian. Namun, agen tidak seharusnya mengesahkan drafnya sendiri. Responden Stack Overflow yang berencana menggunakan AI untuk pengujian di masa mendatang tetap menempatkan ketidakpercayaan manusia sebagai salah satu pertimbangan utama: alasan paling umum mereka meminta bantuan orang lain adalah karena tidak memercayai jawaban AI. Naluri itu adalah aset profesi ini.

Merekrut dan memberdayakan orang-orang yang menempuh jalur nontradisional juga penting. Saya beralih ke bidang penjaminan mutu setelah berkarier di bidang operasional SDM dan data, menyelesaikan gelar magister Sistem Informasi di UMBC pada Mei 2024, dan kini menghabiskan hari-hari saya untuk membuat gerbang berbasis agen dapat diterapkan secara praktis. AI agentik tidak akan menunggu orang-orang dengan satu latar belakang tertentu. Bidang ini membutuhkan lebih banyak orang yang mampu merancang bukti, bukan lebih sedikit orang yang asal menyetujui hasil build berstatus hijau.

Pertanyaan tentang produk ini sederhana. Jika agen merilis produk lebih cepat daripada kemampuan Anda untuk memverifikasinya, itu bukan peningkatan produktivitas. Itu hanya insiden yang tertunda. Berinvestasilah pada penguji yang mencurigai setiap klaim agen, yang mengintegrasikan pengujian mutasi dan keterlacakan ke dalam CI, serta yang tetap menggunakan penilaian independen saat model paling fasih sekaligus paling tidak dapat diandalkan. AI agentik membutuhkan lebih banyak penguji, bukan lebih sedikit.