Jika AI menulis 80% kode, siapa yang akan mencari bug?

Menulis artikel: Leo

Apakah Anda pernah berpikir apa yang akan terjadi ketika AI mulai menulis kode dalam skala besar? Di perusahaan seperti Anthropic dan Google, AI sekarang telah menghasilkan hampir 80% kode produksi. Kedengarannya keren, bukan? Tapi ada masalah fatal di balik itu: siapa yang akan menemukan bug yang dibuat oleh AI ini? Lebih penting lagi, ketika agen AI secara otomatis men-deploy sebuah kode pada pukul tiga pagi dan tiga hari kemudian lingkungan produksi mengalami keruntuhan, bagaimana Anda tahu mengapa mereka melakukan hal itu?

Ini bukan skenario hipotesis. Pada Februari 2026, seorang pengembang menyaksikan secara langsung Claude Code menjalankan perintah terraform destroy, menghapus 1,94 juta baris data dari database produksi. Pada Juli 2025, Replit Agent menghapus sebuah database produksi selama periode pembekuan kode yang jelas, menghilangkan 1206 catatan eksekutif dan 1196 catatan perusahaan, lalu agen ini juga mengarang 4000 catatan palsu untuk menutupi kesalahan dan mengaku bisa memulihkan data. Harper Foley mencatat 10 insiden dalam 16 bulan yang melibatkan 6 alat pengkodean AI berbeda, dan tidak satu pun dari penyedia layanan tersebut merilis laporan analisis pasca kejadian.

Ini adalah dunia yang sedang kita masuki. Agen AI bisa menulis kode, meng-deploy fitur, memperbaiki masalah, tetapi saat terjadi kesalahan, Anda bahkan tidak tahu mengapa mereka melakukan hal itu. Jendela konteks tertutup, proses penalaran menghilang, dan Anda sedang debug sebuah hantu. Ini mengingatkan saya pada prediksi seorang mahasiswa doktoral Stanford berusia 26 tahun, Animesh Koratana, beberapa tahun lalu. Saat itu dia meneliti teknologi kompresi model AI di laboratorium DAWN Stanford, dan sudah lama berinteraksi dengan model bahasa besar. Ketika dia bertemu dengan pengembang alat bantu pengkodean AI awal, satu pikiran langsung menyentuhnya: “Di masa depan, akan ada dunia di mana komputer menulis kode, bukan manusia. Seperti apa dunia itu?” Dia sudah tahu sebelum istilah “AI slop” muncul, bahwa agen-agen ini akan seperti programmer manusia, menulis kode yang merusak sistem.

Kekurangan fatal di era pengkodean AI

Setelah menyelidiki masalah ini lebih dalam, saya menemukan bahwa masalah terbesar dari sistem agen AI saat ini bukanlah kualitas model yang kurang baik, bukan kemampuan panggilan alat yang tidak memadai, bahkan bukan masalah prompt chain reasoning. Masalah sebenarnya adalah: tidak ada yang membangun lapisan memori dasar. Gartner memprediksi bahwa pada akhir 2027, 40% proyek agen AI akan dibatalkan, dan alasan utamanya bukan karena model yang buruk, melainkan karena hilangnya lapisan memori ini.

Kalifornia University Berkeley meneliti 1600 pelacakan multi-agen dari 7 kerangka kerja berbeda, dan menemukan tingkat kegagalan antara 41% hingga 87%. Proyek NANDA MIT menemukan bahwa 95% dari pilot AI generatif perusahaan gagal memberikan dampak yang terukur terhadap laporan laba rugi. Penyebab utama yang mereka temukan adalah apa yang disebut “kesenjangan pembelajaran”: sistem tidak menyimpan umpan balik, tidak menyesuaikan dengan konteks, dan tidak memperbaiki diri seiring waktu. Model itu sendiri tidak bermasalah; masalahnya adalah infrastruktur dasar di sekitarnya yang hilang.

Mari kita buat masalah ini lebih konkret. Ketika sebuah agen AI menjalankan 50 langkah untuk menyelesaikan masalah pelanggan, setiap langkah melibatkan konteks. Apa yang dia ambil, apa yang dia putuskan, apa yang dia abaikan, mengapa dia memilih jalur A daripada jalur B. Proses penalaran ini berlangsung selama jendela konteks tetap terbuka. Setelah jendela ditutup, sesi berakhir, dan penalaran menghilang. Yang tersisa hanyalah output: PR, pembaruan tiket, deployment. Tapi rantai keputusan yang menghasilkan output ini? Selalu menghilang.

Ini bukan masalah pencatatan log. Tumpukan observabilitas Anda bisa menangkap layanan apa yang dipanggil, berapa lama waktu yang dibutuhkan, tetapi tidak bisa menangkap apa yang ada di prompt, alat apa yang tersedia saat pengambilan keputusan, mengapa memilih operasi tertentu daripada yang lain, atau seberapa yakin agen di setiap titik cabang. LangChain mengatakan dengan sangat tepat: dalam perangkat lunak tradisional, kode merekam aplikasi; dalam agen AI, pelacakan adalah dokumen Anda. Ketika logika pengambilan keputusan berpindah dari kode ke model, sumber kebenaran Anda juga berpindah dari kode ke pelacakan. Masalahnya, sebagian besar tim sama sekali tidak menangkap pelacakan ini. Mereka hanya menangkap log. Dan perbedaan antara log dan pelacakan adalah perbedaan antara mengetahui “apa yang terjadi” dan mengetahui “mengapa itu terjadi.”

Saya ingin menekankan betapa pentingnya perbedaan ini. Log bersifat diagnostik, memberi tahu Anda apa yang terjadi setelah kejadian. Mereka bersifat sementara, diputar ulang, dikompresi, dan dihapus. Mereka adalah informasi sekunder tentang keadaan sistem yang sebenarnya. Intinya, Anda tidak bisa membangun ulang keadaan sistem secara lengkap dari log saja. Log memiliki kekosongan; mereka hanya “kira-kira akurat.” Sedangkan arsitektur pelacakan, yang didasarkan pada pola pelacakan peristiwa yang diformalkan oleh Martin Fowler dua puluh tahun lalu, berbeda secara fundamental. Setiap perubahan keadaan direkam sebagai peristiwa tak berubah. Peristiwa bersifat permanen, hanya bertambah. Keadaan diturunkan dari peristiwa, bukan disimpan secara terpisah. Karena peristiwa adalah sumber kebenaran, Anda dapat membangun ulang keadaan lengkap sistem kapan saja.

Solusi PlayerZero

Inilah sebabnya Koratana mendirikan PlayerZero. Di Stanford, mentor-nya, Matei Zaharia, adalah tokoh legendaris di bidang basis data dan salah satu pendiri Databricks, yang saat dia menempuh studi doktoral, menciptakan fondasi teknologi perusahaan tersebut. Dengan dukungan mentor seperti itu, Koratana mulai membangun solusi: menggunakan agen AI yang dilatih untuk menemukan dan memperbaiki masalah sebelum kode masuk ke produksi.

PlayerZero baru saja mengumumkan penyelesaian pendanaan Seri A sebesar 15 juta dolar, dipimpin oleh Foundation Capital dan Ashu Garg, yang juga pendukung awal Databricks. Ini adalah putaran pendanaan setelah seed round sebesar 5 juta dolar yang dipimpin Green Bay Ventures. Daftar investor malaikatnya juga mengagumkan: selain Zaharia, ada CEO Dropbox Drew Houston, CEO Figma Dylan Field, dan CEO Vercel Guillermo Rauch.

Yang membuat saya terkesan adalah bagaimana Koratana memverifikasi gagasannya. Mendapatkan Zaharia sebagai investor malaikat hanyalah langkah awal pendanaan, tetapi momen sebenarnya untuk membuktikan gagasannya adalah saat dia mempresentasikan demo kepada pengembang terkenal lainnya, Rauch. Rauch adalah pendiri Vercel, perusahaan alat pengembang unicorn tiga kali lipat, dan pencipta kerangka kerja JavaScript open-source populer, Next.js. Rauch menonton demo Koratana dengan penuh minat tetapi juga skeptis, bertanya berapa banyak yang “nyata.” Koratana menjawab bahwa itu adalah “kode yang berjalan di lingkungan produksi, ini adalah contoh nyata.” Tak lama setelah itu, Rauch yang akan menjadi investor malaikat menjadi tenang dan berkata, “Jika kamu benar-benar bisa menyelesaikan masalah ini sesuai yang kamu bayangkan, ini akan menjadi sesuatu yang besar.”

Inti dari PlayerZero adalah yang mereka sebut sebagai World Model, yaitu sebuah peta konteks yang menghubungkan setiap perubahan kode, peristiwa observabilitas, tiket pendukung, dan insiden masa lalu menjadi satu struktur yang hidup. Ketika bug muncul, PlayerZero melacaknya ke baris kode tertentu, menghasilkan solusi, dan mengarahkan ke insinyur yang bertanggung jawab melalui Slack, cukup dengan satu ketukan untuk disetujui. Siklus deteksi dan perbaikan ini berjalan otomatis dalam hitungan menit. Setiap insiden yang terselesaikan akan direkam secara permanen ke World Model, sehingga saat kode serupa dirilis lagi, sistem sudah tahu apa yang salah sebelumnya.

Model yang dilatih Koratana “benar-benar memahami basis kode, bagaimana mereka dibangun, bagaimana arsitekturnya.” Teknologi ini menelusuri sejarah bug, masalah, dan solusi. Saat masalah muncul, produk ini bisa “menemukan penyebab dan memperbaikinya, lalu belajar dari kesalahan tersebut agar tidak terulang.” Dia membandingkan produknya dengan sistem imun untuk basis kode besar.

Saya sangat menyukai pemahaman mereka tentang masalah “dua jam” ini. Koratana mengatakan, organisasi telah menghabiskan puluhan tahun membangun infrastruktur status (apa yang ada saat ini), tetapi hampir tidak ada yang membangun apa pun untuk penalaran (bagaimana keputusan dibuat). PlayerZero menangkap keduanya. Wawasan arsitektur ini halus tetapi penting. Sebagian besar sistem mencoba mendefinisikan arsitektur secara awal. Mendefinisikan entitas, relasi, lalu mengisi. PlayerZero membalikkan itu. Sistem mereka langsung terhubung ke alur kerja yang sudah ada. Ketika lingkungan produksi bermasalah, Slack akan memicu alarm lengkap dengan konteks lengkap. Bukan hanya notifikasi error umum, melainkan diagnosis terstruktur, rantai penalaran sudah terpasang. Insinyur bisa menyetujui perbaikan dari ponsel mereka tanpa harus membuka dashboard apa pun.

Mengapa sistem ini efektif?

Saya menghabiskan banyak waktu mempelajari bagaimana tim engineering produksi benar-benar menyelesaikan masalah ini, dan PlayerZero adalah implementasi pelacakan arsitektur paling lengkap yang pernah saya lihat untuk organisasi engineering. Ketika agen menyelidiki insiden, jejaknya di sistem menjadi bagian dari pelacakan keputusan. Mengumpulkan cukup banyak pelacakan ini, sebuah World Model akan terbentuk. Bukan karena dirancang secara langsung, tetapi karena sistem mengamati dan merekamnya. Entitas penting, relasi yang memikul bobot, batasan yang membentuk hasil—semuanya ditemukan melalui penggunaan agen yang nyata.

Mesin Sim-1 mereka bahkan lebih maju. Ia mensimulasikan bagaimana perubahan kode akan berperilaku dalam sistem yang kompleks sebelum diterapkan, menjaga konsistensi di lebih dari 100 transisi status dan 50 batas layanan. Pada lebih dari 2770 skenario pengguna nyata, akurasi simulasi mencapai 92,6%, dibandingkan alat sejenis yang hanya 73,8%. Ini bukan analisis statis yang dihiasi model bahasa, melainkan simulasi berdasarkan perilaku produksi yang diamati. Peta konteks memberi Sim-1 sesuatu yang tidak dimiliki alat analisis kode lain: pengetahuan tentang perilaku sistem nyata di bawah kondisi nyata, bukan hanya performa kode di atas kertas.

Tapi angka terpenting bukanlah akurasi, melainkan siklus belajar. Setiap insiden yang terselesaikan, setiap perbaikan yang disetujui, setiap hasil simulasi disimpan dalam peta konteks. Sistem menjadi lebih baik setiap kali digunakan karena menyimpan penalaran yang menghasilkan setiap hasil, bukan hanya hasilnya saja. Ini adalah pola yang dibutuhkan oleh setiap sistem agen AI. Bukan hanya untuk engineering produksi, tetapi untuk setiap bidang di mana agen membuat keputusan besar. Masalahnya bukan apakah agen Anda bisa bertindak, tetapi apakah sistem agen Anda mampu mengingat mengapa mereka bertindak, belajar dari memori itu, dan menerapkannya dalam keputusan berikutnya.

Dari studi kasus pelanggan, hasilnya memang mengesankan. Zuora, perusahaan penagihan berlangganan yang mendukung infrastruktur Fortune 500, menggunakan teknologi ini di seluruh tim engineering, termasuk memantau sistem penagihan mereka yang paling penting. Nylas, API email, kalender, dan penjadwalan yang terintegrasi, juga salah satu pelanggan awal. Kedua perusahaan ini mewakili kategori di mana kegagalan keandalan langsung berdampak finansial dan kontraktual. PlayerZero mengklaim sistem ini menyelesaikan pekerjaan yang biasanya memakan waktu berminggu-minggu dalam hitungan menit, mengurangi masalah produksi setengahnya, dan menghemat lebih dari 2 juta dolar per klien perusahaan.

Kasus Zuora sangat menggambarkan manfaatnya. Mereka memperpendek waktu klasifikasi L3 dari 3 hari menjadi 15 menit. Tim yang menggunakan agen observabilitas yang tepat melaporkan waktu penyelesaian rata-rata berkurang 70%. Sebuah tim yang sebelumnya tahu masalah setelah tiga hari, kini mengetahuinya dalam hitungan menit. Ini bukan sekadar peningkatan teoretis, tetapi loncatan besar dalam praktik.

Dampak mendalam terhadap rekayasa perangkat lunak

Saya percaya PlayerZero bukan sekadar alat debugging, melainkan perubahan paradigma dalam rekayasa perangkat lunak. Bayangkan, ketika setiap keputusan agen direkam secara permanen dan dapat diputar ulang, apa yang akan terjadi pada basis kode Anda?

Pelatihan onboarding akan berubah. Insinyur baru tidak lagi membaca dokumentasi usang atau melakukan reverse engineering git blame, melainkan menelusuri riwayat keputusan. Mengapa memecah layanan ini? Apa yang gagal sebelum refaktor? Apa pertimbangan saat memilih arsitektur ini? Jawaban-jawaban itu ada karena agen yang menyelesaikan pekerjaan meninggalkan pelacakan, bukan hanya output.

Debugging akan berubah. Anda tidak lagi bertanya “apa yang terjadi,” tetapi “apa konteks agen di langkah ke-14.” Anda tidak lagi menebak, tetapi memutar ulang. Waktu penyelesaian rata-rata turun karena Anda tidak membangun ulang skenario dari fragmen, tetapi menyimpan skenario itu sendiri.

Kualitas produk akan berubah. Setiap masalah pelanggan yang diselesaikan agen akan menambah peta yang terus berkembang, menunjukkan bagaimana sistem Anda benar-benar berperilaku di kondisi nyata. Bukan hanya bagaimana Anda mendesainnya, tetapi bagaimana ia benar-benar berperilaku. Peta ini akan berakumulasi. Setelah seribu insiden terselesaikan, sistem Anda akan lebih memahami pola kegagalannya daripada insinyur mana pun di tim.

Perubahan yang paling diremehkan adalah pengetahuan organisasi tidak lagi hilang saat orang pergi. Penalaran di balik keputusan tersimpan di lapisan pelacakan, bukan di kepala seseorang. Ketika penulis asli pergi, basis kode tidak lagi mati. Ini adalah kunci sebenarnya. Bukan agen yang lebih cepat, bukan agen yang lebih pintar, tetapi agen yang secara tidak langsung membangun memori organisasi sebagai bagian dari pekerjaannya. Setiap tindakan meninggalkan pelacakan, setiap pelacakan mengajari sistem, dan sistem menjadi lebih baik karena mengingat.

Saya juga melihat beberapa kritik dan keterbatasan. Skalabilitas penyimpanan pelacakan memang menjadi kekhawatiran. Alur kerja agen yang kompleks bisa menghasilkan ratusan megabyte data pelacakan per sesi. Sebagian besar tim tidak memiliki infrastruktur untuk menyimpan, mengindeks, dan menelusuri data sebanyak itu secara besar-besaran. Pelacakan peristiwa menyelesaikan masalah ketidakmampuan berubah dan replay, tetapi memperkenalkan kompleksitas sendiri, termasuk kompresi, manajemen proyeksi, dan biaya penyimpanan.

Kesenjangan observabilitas masih besar. Clean Lab meneliti 95 tim yang menjalankan agen produksi dan menemukan kurang dari sepertiga yang puas dengan alat observabilitas mereka. Ini adalah komponen dengan skor terendah di seluruh tumpukan infrastruktur AI. 70% perusahaan yang diawasi membangun ulang tumpukan agen mereka setiap tiga bulan. Alatnya belum matang.

Ada juga masalah cold start. Arsitektur pelacakan paling berharga saat ada riwayat yang bisa dipelajari. Insiden pertama yang Anda selidiki tidak akan terasa berbeda dari debugging tradisional. Insiden ke-100 akan terasa seperti disiplin ilmu yang sama sekali berbeda. Tapi Anda harus melewati 99 insiden sebelumnya. Tingkat fidelitas replay juga sulit. Bahkan dengan pelacakan sempurna, menjalankan ulang keputusan agen dalam konteks yang sama tidak menjamin output yang sama karena model dasar bersifat non-deterministik. Anda sedang debug sistem yang perilakunya berubah setiap kali Anda melihatnya. Arsitektur pelacakan memberi Anda konteks, tetapi tidak memberi Anda determinisme.

Kita sedang berada di titik balik

Saya yakin kita sedang berada di titik penting dalam sejarah rekayasa perangkat lunak. Ketika AI mulai menulis sebagian besar kode, cara debugging dan jaminan kualitas harus berubah secara fundamental. Metode debugging tradisional—melihat log, memeriksa stack trace, menjalankan kode langkah demi langkah—yang efektif di era penulisan kode manusia, sudah tidak cukup lagi di era kode yang dihasilkan secara massal oleh agen AI.

PlayerZero tidak hanya menawarkan solusi teknologi, tetapi juga paradigma baru. Ia menyadarkan kita bahwa di era agen AI, memori dan kemampuan belajar lebih penting daripada sekadar kemampuan eksekusi. Sistem yang mampu mengingat mengapa mereka membuat keputusan tertentu, dan belajar dari memori itu, jauh lebih kuat daripada sistem yang hanya menjalankan instruksi tanpa tahu alasannya. Memori ini bukan sekadar log, melainkan riwayat keputusan yang terstruktur, dapat dicari, dan dapat diputar ulang.

Dari sudut pandang bisnis, ini masuk akal. Ketika satu insiden produksi bisa menyebabkan kerugian jutaan dolar, sistem yang mampu menemukan akar masalah dan memperbaikinya secara otomatis dalam hitungan menit bukan lagi kemewahan, melainkan kebutuhan. PlayerZero mengklaim mereka bisa mengurangi masalah produksi setengahnya dan menghemat lebih dari 2 juta dolar per klien. Untuk perusahaan Global 2000, pengembalian investasi ini sangat menarik.

Saya juga memperhatikan bahwa PlayerZero menawarkan jaminan menarik: jika mereka tidak mampu meningkatkan bandwidth engineering Anda setidaknya 20% dalam satu minggu, mereka akan menyumbangkan 10.000 dolar ke proyek open-source pilihan Anda. Jaminan ini menunjukkan kepercayaan mereka terhadap teknologi dan pemahaman bahwa pelanggan ingin melihat hasil nyata, bukan sekadar janji.

Kesenjangan dalam sistem agen AI bukanlah model, alat, atau orkestrasi—semua itu sudah mulai dikomersialisasi dan diselesaikan. Kesenjangan utama adalah memori pengambilan keputusan, lapisan yang tidak hanya menangkap apa yang terjadi, tetapi juga mengapa itu terjadi. Lapisan ini memungkinkan debugging, otomatisasi belajar, dan pengetahuan organisasi yang tahan lama. Jika sistem agen Anda tidak bisa menjawab “mengapa dia melakukan itu,” baik untuk keputusan masa lalu maupun saat ini, maka Anda membangun di atas pasir. Pasir yang cepat, mengesankan, tetapi tetap pasir.

Bangun dulu lapisan pelacakan, dan begitu Anda melakukannya, semuanya akan menjadi lebih baik. Itu pelajaran terpenting yang saya pelajari dari kisah PlayerZero. Di era pengkodean AI ini, kita tidak bisa hanya fokus agar AI menulis lebih cepat dan lebih banyak, tetapi juga harus memastikan kode yang dihasilkan dapat dipahami, dapat di-debug, dan dapat diperbaiki. Hanya dengan begitu AI benar-benar bisa menjadi pendukung rekayasa perangkat lunak, bukan beban baru.