Riset ICSE 2026: Muncul Kelas Baru Pembuat Aplikasi yang Bisa Bikin tapi Tidak Bisa Memperbaiki

Ada istilah baru yang muncul dari dunia riset rekayasa perangkat lunak tahun ini, dan istilah itu kemungkinan besar menggambarkan banyak orang yang sekarang membangun aplikasi dengan bantuan AI. Namanya vulnerable developer class, kelas pembuat perangkat lunak yang rentan. Definisinya cukup tajam: orang yang mampu menghasilkan software yang berjalan, tapi tidak mampu men-debug atau mengamankannya sendiri.

Istilah itu datang dari riset Fawzy dan rekan-rekannya berjudul "Vibe Coding in Practice: Motivations, Challenges, and a Future Outlook", yang dipresentasikan di ICSE-SEIP 2026, salah satu konferensi rekayasa perangkat lunak paling mapan di dunia. Peneliti menelusuri 101 sumber tulisan praktisi dan menarik 518 catatan pengalaman langsung tentang bagaimana orang benar-benar memakai AI untuk menulis kode. Bukan survei opini, melainkan rekaman perilaku dari orang-orang yang sudah menjalaninya.

Kesenjangan antara kode yang jalan dan kode yang dipahami

Temuan intinya disebut peneliti sebagai paradoks pertukaran kecepatan dan kualitas. Orang tertarik ke cara kerja ini karena cepat dan mudah diakses, dan biasanya memang langsung merasakan keberhasilan instan di awal. Alur kerjanya khas: jelaskan yang diinginkan dengan bahasa sehari-hari, langsung jalankan kode yang dihasilkan, lalu ulangi dengan coba-coba sampai kelihatan benar.

Yang jadi soal adalah bagian terakhirnya. Riset itu membedakan cara kerja ini dari pemrograman berbantuan AI pada umumnya justru pada satu titik: kode yang dihasilkan dijalankan tanpa ditinjau dan tanpa benar-benar dipahami. Selama hasilnya kelihatan bekerja, prosesnya dianggap selesai.

Selama aplikasinya sederhana, ini tidak jadi masalah besar. Yang berubah adalah ketika aplikasi itu mulai dipakai orang sungguhan, menyimpan data pelanggan, dan menerima pembayaran. Pada titik itu, hal-hal yang tidak dipahami di dalam kode berubah dari sekadar utang teknis menjadi risiko bisnis.

Angka yang menunjukkan pola ini bukan cuma perasaan

Beberapa pengukuran independen mengarah ke arah yang sama. Sebuah analisis terhadap 8,1 juta pull request menemukan utang teknis naik 30 sampai 41 persen setelah tim mengadopsi AI coding tools. Analisis GitClear menemukan tingkat duplikasi kode empat kali lebih tinggi, sementara porsi refactoring turun dari 25 persen baris yang diubah pada 2021 menjadi di bawah 10 persen pada 2024. Artinya kode baru bertambah jauh lebih cepat daripada kode lama dirapikan.

Dari sisi operasional, laporan State of Infrastructure Automation 2026 dari Spacelift menyebut 93 persen organisasi mengalami masalah infrastruktur ketika memakai AI untuk vibe coding, dan mengaitkannya dengan lemahnya tata kelola serta kontrol keamanan di tengah dorongan untuk serba cepat.

Pola ini juga sejalan dengan yang kami bahas sebelumnya soal kesenjangan kepercayaan developer terhadap hasil AI dan temuan riset Apiiro bahwa bug yang muncul makin menyusup ke level arsitektur, bukan sekadar salah ketik yang gampang ketahuan.

Amazon sudah melewati fase ini, dan jalan keluarnya bukan berhenti pakai AI

Bagian yang paling instruktif justru datang dari perusahaan yang punya sumber daya teknis paling besar. Menurut laporan Financial Times yang kemudian dikutip luas, Amazon menggelar tinjauan mendalam wajib setelah empat insiden Sev-1 terjadi dalam satu pekan. Dokumen internal yang beredar mengaitkan tren insiden berdampak luas itu dengan perubahan kode yang dibantu AI generatif. Sekitar 1.500 engineer Amazon bahkan menandatangani petisi internal yang mempersoalkan dorongan adopsi tool AI di perusahaan.

Perlu dicatat, sebagian detail insiden ini beredar lewat pemberitaan sekunder dan angka kerugiannya bervariasi antar sumber, jadi sebaiknya diperlakukan dengan hati-hati. Yang konsisten dilaporkan adalah responsnya. Amazon tidak melarang pemakaian AI. Mereka justru menambahkan lapisan pemeriksaan, yaitu mewajibkan persetujuan senior engineer untuk perubahan kode yang dibantu AI sebelum masuk ke produksi.

Kesimpulan yang bisa ditarik cukup jelas. Masalahnya bukan pada AI yang menulis kode, melainkan pada hilangnya tahap pemeriksaan yang dulu selalu ada. Ketika kecepatan produksi kode melonjak tapi kapasitas meninjaunya tidak ikut naik, selisihnya menumpuk di produksi.

Apa artinya kalau kamu memang bukan developer

Di sinilah letak masalah yang sebenarnya buat pemilik bisnis. Solusi Amazon, yaitu menaruh senior engineer sebagai penjaga gerbang, tidak tersedia buat kamu yang tidak punya tim teknis sama sekali. Kamu tidak bisa meminta persetujuan dari orang yang tidak ada.

Karena itu pertanyaannya bergeser. Bukan lagi "AI mana yang paling pintar menulis kode", tapi "tool ini punya tahap pemeriksaan bawaan atau tidak". Tool yang cuma menyerahkan kode jadi ke tangan kamu sebenarnya sedang memindahkan seluruh beban peninjauan ke orang yang paling tidak siap menanggungnya.

Pendekatan ini yang kami pegang di TanpaNgoding AI. Kode yang dihasilkan tidak langsung dianggap selesai begitu kelihatan jalan. Ada quality gate otomatis yang memeriksa hasil build sebelum dinyatakan beres, plus batasan di lapisan eksekusi supaya AI tidak bisa menjalankan perintah sembarangan di project kamu. Tujuannya sederhana, yaitu mengembalikan tahap pemeriksaan yang hilang tanpa mengharuskan kamu bisa membaca kodenya sendiri.

Meski begitu, ada bagian yang tetap jadi tanggung jawab pemilik project, dari pengelolaan API key sampai password admin. Kami sudah merangkumnya terpisah di panduan membuat web dengan AI yang tetap aman.

Riset ICSE tadi menutup dengan nada yang tidak menghakimi, dan itu bagian yang penting. Masuk ke kelas pembuat aplikasi yang rentan bukan tanda kamu tidak becus. Itu konsekuensi wajar dari alat yang membuat pembuatan software jadi terbuka buat siapa saja. Yang perlu kamu pastikan cuma satu hal, yaitu ada yang memeriksa hasilnya sebelum sampai ke pengguna, entah itu manusia atau sistem.