Catatan Editor: Saat AI generatif semakin cepat masuk ke dunia rekayasa perangkat lunak, sentimen industri bergeser dari "kekaguman akan kemampuan" menuju "kecemasan akan efisiensi". Menulis tidak cukup cepat, menggunakan tidak cukup banyak, otomatisasi tidak cukup menyeluruh—semuanya seolah menimbulkan tekanan akan tersingkir. Namun ketika Agent pengkodean benar-benar masuk ke lingkungan produksi, masalah yang lebih nyata mulai muncul: kesalahan diperbesar, kompleksitas tak terkendali, sistem semakin tak terpahami, peningkatan efisiensi tidak berbanding lurus dengan peningkatan kualitas.
Artikel ini, berdasarkan praktik langsung, memberikan refleksi tenang atas demam "agentic coding" terkini. Penulis menegaskan, Agent tidak akan belajar dari kesalahan seperti manusia; tanpa mekanisme hambatan dan umpan balik, masalah kecil akan dengan cepat membesar. Dan dalam basis kode yang kompleks, perspektif lokal dan kemampuan penarikan kembali (recall) yang terbatas semakin memperparah kekacauan struktur sistem. Inti masalahnya bukan pada teknologinya sendiri, melainkan pada manusia yang, didorong kecemasan, terlalu cepat menyerahkan penilaian dan kendali.
Oleh karena itu, alih-alih terjebak kecemasan "haruskah sepenuhnya merangkul AI", lebih baik menyesuaikan kembali hubungan antara manusia dan alat: biarkan Agent menangani tugas-tugas yang lokal dan terkendali, sementara desain sistem, penjaga kualitas, dan pengambilan keputusan kunci tetap dipegang erat. Dalam proses ini, "melambat" justru menjadi sebuah kemampuan, yang berarti Anda masih memahami sistem, mampu membuat pertimbangan, dan masih memiliki rasa kendali atas pekerjaan.
Di era di mana alat terus berevolusi, yang benar-benar langka mungkin bukanlah kemampuan menghasilkan yang lebih cepat, melainkan kemampuan menilai kompleksitas, dan keteguhan hati untuk memilih antara efisiensi dan kualitas.
Berikut adalah artikel aslinya:
Sekitar setahun yang lalu, Agent pengkodean yang benar-benar bisa membantu Anda "mengerjakan proyek lengkap dari awal hingga akhir" mulai bermunculan. Sebelumnya juga sudah ada alat seperti Aider, Cursor versi awal, tetapi mereka lebih mirip asisten, bukan "agen". Alat-alat generasi baru ini sangat menarik, dan banyak orang menghabiskan banyak waktu luang mereka untuk mengerjakan semua proyek yang selalu ingin dilakukan tetapi tidak sempat.
Menurut saya ini tidak masalah. Menggunakan waktu luang untuk membuat sesuatu memang menyenangkan, dan sebagian besar waktu Anda juga tidak perlu terlalu mempedulikan kualitas kode dan kemudahan pemeliharaannya. Ini juga memberi Anda jalur untuk mempelajari tumpukan teknologi (tech stack) baru.
Selama liburan Natal, Anthropic dan OpenAI bahkan membagikan beberapa "kredit gratis", seperti mesin slot yang menyedot orang masuk. Bagi banyak orang, ini adalah pengalaman pertama kali merasakan keajaiban "Agent menulis kode". Yang terlibat semakin banyak.
Kini, Agent pengkodean juga mulai masuk ke basis kode produksi. 12 bulan telah berlalu, kita mulai melihat konsekuensi dari "kemajuan" ini. Berikut adalah pandangan saya saat ini.
Semuanya Rusak
Meskipun sebagian besar ini hanya berdasarkan pengalaman, perangkat lunak saat ini memang memberi kesan "siap pecah kapan saja". Ketersediaan (availability) 98%, yang dulu merupakan pengecualian, kini menjadi norma, bahkan untuk layanan besar sekalipun. Antarmuka pengguna dipenuhi berbagai bug yang keterlaluan, jenis yang seharusnya bisa langsung ditangkap oleh tim QA.
Saya akui, situasi seperti ini sudah ada sebelum Agent muncul. Tapi sekarang, masalahnya jelas semakin cepat.
Kita tidak melihat kondisi internal perusahaan yang sebenarnya, tetapi sesekali ada informasi yang bocor, seperti kabar yang sempat beredar tentang "pemadaman AWS yang disebabkan AI". Amazon Web Services kemudian langsung "meluruskan" pernyataannya, tetapi tak lama setelahnya meluncurkan program perbaikan internal selama 90 hari.
Satya Nadella (CEO Microsoft) belakangan juga terus menekankan bahwa semakin banyak kode di perusahaannya yang ditulis oleh AI. Meskipun tidak ada bukti langsung, memang ada perasaan bahwa kualitas Windows menurun. Bahkan dari beberapa blog yang dirilis Microsoft sendiri, mereka sepertinya mengakui hal ini secara implisit.
Perusahaan-perusahaan yang mengklaim "100% kode produk dihasilkan oleh AI" hampir selalu menghasilkan produk terburuk yang bisa Anda bayangkan. Bukan bermaksud menyinggung siapa pun, tetapi kebocoran memori yang bisa mencapai GB, UI yang kacau, fungsionalitas yang cacat, sering crash... ini semua sama sekali bukan "jaminan kualitas" yang mereka kira, apalagi contoh positif dari "biarkan Agent melakukan segalanya untukmu".
Secara pribadi, Anda akan semakin sering mendengar, baik dari perusahaan besar maupun tim kecil, mengatakan satu hal: mereka telah terjebak dalam jalan buntu oleh "Agent menulis kode". Tanpa tinjauan kode, menyerahkan keputusan desain kepada Agent, lalu menumpuk banyak fitur yang tidak dibutuhkan siapa pun — akhirnya tentu tidak baik.
Mengapa Kita Seharusnya Tidak Menggunakan Agent seperti Ini
Kita hampir telah meninggalkan semua disiplin teknik dan penilaian subjektif, beralih ke cara kerja yang "adiktif": tujuannya hanya satu — menghasilkan kode sebanyak-banyaknya dalam waktu sesingkat mungkin, konsekuensinya bagaimana, sama sekali tidak dipertimbangkan.
Anda memasang lapisan orkestrasi, untuk memimpin pasukan Agent otomatis. Anda memasang Beads, tetapi sama sekali tidak tahu bahwa pada dasarnya itu hampir seperti "perangkat lunak berbahaya" yang tidak bisa dicopot. Hanya karena internet bilang "semua orang melakukannya". Jika tidak melakukannya, Anda "akan celaka" (ngmi).
Anda terkuras dalam "siklus nested" yang berulang.
Lihat — Anthropic menggunakan sekelompok Agent untuk membuat kompiler C, meskipun sekarang masih bermasalah, tetapi model generasi berikutnya pasti akan memperbaikinya, bukan?
Lihat lagi — Cursor menggunakan banyak Agent untuk membuat browser, meskipun sekarang pada dasarnya tidak dapat digunakan dan masih perlu intervensi manual sesekali, tetapi model generasi berikutnya pasti akan menyelesaikannya, bukan?
"Terdistribusi", "bagi dan taklukkan", "sistem otonom", "pabrik gelap gulita", "selesaikan masalah perangkat lunak dalam enam bulan", "SaaS sudah mati, nenek saya baru saja membuat Shopify menggunakan Claw"...
Narasi-narasi ini terdengar menyenangkan.
Tentu, cara ini untuk proyek sampingan Anda yang hampir tidak ada yang menggunakan (termasuk Anda sendiri), mungkin memang "masih bisa jalan". Mungkin, memang ada seorang jenius yang bisa membuat produk perangkat lunak yang tidak sampah dan benar-benar digunakan dengan cara ini. Jika Anda adalah orang itu, saya sungguh mengagumi.
Setidaknya di lingkaran pengembang di sekitar saya, saya belum pernah melihat metode ini benar-benar berhasil. Tentu, mungkin saja kami semua terlalu payah.
Kesalahan Terus Bertumpuk Tanpa Pembelajaran, Tanpa Hambatan, Meledak Tertunda
Masalah Agent adalah: mereka melakukan kesalahan. Ini sendiri tidak masalah, manusia juga melakukan kesalahan. Mungkin hanya beberapa kesalahan kebenaran, mudah diidentifikasi, mudah diperbaiki, ditambah pengujian regresi就更稳了 (akan lebih stabil). Bisa juga是一些 halus kode yang tidak tertangkap linter: di sini sebuah metode yang tidak berguna, di sana sebuah tipe yang tidak masuk akal,还有 kode duplikat semacamnya. Secara terpisah, ini semua tidak terlalu merugikan, pengembang manusia juga membuat kesalahan kecil seperti ini.
Tapi "mesin" bukan manusia. Setelah manusia mengulangi kesalahan yang sama beberapa kali, biasanya akan belajar untuk tidak mengulanginya —要么是因为被骂醒了 (entah karena dimarahi sampai sadar),要么是在真正的学习过程中改掉了 (entah melalui proses belajar yang sebenarnya).
Dan Agent tidak memiliki kemampuan belajar seperti ini, setidaknya secara default tidak. Ia akan mengulangi kesalahan yang sama berulang-ulang, bahkan mungkin "menciptakan" kombinasi kesalahan yang berbeda berdasarkan data pelatihan.
Anda tentu bisa mencoba "melatih"nya: menulis aturan di AGENTS.md, agar tidak melakukan kesalahan seperti ini lagi; merancang一套 sistem memori yang kompleks, agar dapat menanyakan kesalahan historis dan praktik terbaik. Ini memang efektif untuk jenis masalah tertentu. Tapi syaratnya — Anda harus mengamati terlebih dahulu bahwa ia melakukan kesalahan ini.
Perbedaan yang lebih krusial adalah: manusia adalah hambatan,而 Agent bukan.
Manusia tidak mungkin mengeluarkan dua puluh ribu baris kode dalam beberapa jam. Meskipun frekuensi kesalahan tidak rendah, hanya dapat memperkenalkan sejumlah kesalahan yang terbatas dalam sehari, akumulasi kesalahan ini lambat. Biasanya, ketika "rasa sakit akibat kesalahan" terkumpul sampai一定程度 (tingkat tertentu), manusia (karena本能厌恶痛苦 / naluri menjauhi rasa sakit) akan berhenti sebentar untuk memperbaiki. Atau orangnya diganti, diperbaiki oleh orang lain. Singkatnya, masalah akan ditangani.
Tapi ketika Anda menggunakan sepasukan Agent yang telah diorkestrasi, tidak ada hambatan, juga tidak ada "rasa sakit". Kesalahan-kesalahan kecil yang原本微不足道 (pada awalnya sepele) ini akan bertumpuk dengan kecepatan yang tidak berkelanjutan. Anda telah dikeluarkan dari循环 (lingkaran), bahkan tidak tahu bahwa masalah-masalah kecil yang tampak tidak berbahaya ini telah tumbuh menjadi raksasa. Ketika Anda benar-benar merasakan sakitnya, seringkali sudah terlambat.
Sampai suatu hari, Anda ingin menambah fitur baru, tetapi menemukan bahwa arsitektur sistem saat ini (pada dasarnya已经是错误的堆积 / sudah menjadi tumpukan kesalahan) sama sekali tidak mendukung modifikasi; atau pengguna mulai mengeluh marah-marah, karena rilis terbaru bermasalah, bahkan kehilangan data.
Pada saat itulah Anda menyadari: Anda sudah tidak bisa mempercayai kode ini lagi.
Lebih buruk lagi, pengujian unit, pengujian snapshot, pengujian end-to-end yang berjumlah ribuan yang dihasilkan Agent, juga tidak dapat dipercaya lagi. Satu-satunya cara yang tersisa untuk menilai "apakah sistem bekerja正常 (dengan normal)" adalah pengujian manual.
Selamat, Anda telah mencelakakan diri sendiri (dan perusahaan).
Pedagang Kompleksitas
Anda sudah benar-benar tidak tahu apa yang terjadi dalam sistem, karena Anda menyerahkan kendali kepada Agent. Dan Agent, pada dasarnya adalah "pedagang kompleksitas". Mereka telah melihat banyak keputusan arsitektur yang buruk dalam data pelatihan, dan terus memperkuat pola-pola ini selama proses pembelajaran penguatan (reinforcement learning). Anda memintanya untuk mendesain sistem, hasilnya bisa ditebak.
Yang akhirnya Anda dapatkan adalah: se整套 (seluruh set) sistem yang极其复杂 (sangat kompleks), campur aduk berbagai tiruan拙劣 (buruk) dari "praktik terbaik industri", dan Anda, sebelum masalah lepas kendali, tidak memberlakukan batasan.
Tapi masalahnya tidak berhenti di situ. Agent-Anda彼此之间 (satu sama lain) tidak berbagi proses eksekusi, juga tidak melihat basis kode lengkap, apalagi memahami keputusan yang dibuat oleh Anda atau Agent lain sebelumnya. Oleh karena itu, keputusan mereka始终是 "局部的" (selalu "lokal").
Ini langsung menyebabkan masalah-masalah yang disebutkan sebelumnya: banyak kode duplikat, struktur yang diabstraksi untuk abstraksi, berbagai ketidakkonsistenan. Masalah-masalah ini terus menumpuk, akhirnya membentuk sistem kompleks yang tidak dapat diselamatkan.
Ini sebenarnya mirip dengan basis kode enterprise yang ditulis manusia. Hanya saja kompleksitas seperti itu biasanya adalah hasil akumulasi bertahun-tahun: rasa sakit tersebar pada banyak orang, setiap orang tidak sampai pada titik kritis "harus diperbaiki", toleransi organisasi本身 (sendiri)又很高 (juga tinggi), sehingga kompleksitas dan organisasi "berevolusi bersama".
Tapi dalam kombinasi manusia + Agent, proses ini akan sangat dipercepat. Dua orang, ditambah segelintir Agent, dalam beberapa minggu就能达到这种复杂度 (bisa mencapai tingkat kompleksitas seperti ini).
Penelusuran Agentic Memiliki Tingkat Penarikan Kembali (Recall) yang Rendah
Anda mungkin berharap pada Agent untuk "membereskan kekacauan", membantu Anda melakukan refaktor, optimasi, membuat sistem menjadi bersih. Tapi masalahnya adalah: mereka sudah tidak bisa melakukannya.
Karena basis kode terlalu besar, kompleksitas terlalu tinggi, dan mereka始终只能看到局部 (selalu hanya bisa melihat secara lokal). Ini bukan hanya soal jendela konteks yang tidak cukup besar, atau mekanisme konteks panjang yang gagal di hadapan kode sejuta baris. Masalahnya lebih tersembunyi.
Sebelum Agent mencoba memperbaiki sistem, ia harus menemukan semua kode yang perlu dimodifikasi, serta implementasi yang sudah ada yang dapat digunakan kembali. Langkah ini, kita sebut agentic search (penelusuran agentik).
Bagaimana Agent melakukan ini, tergantung pada alat yang Anda berikan: bisa Bash + ripgrep, bisa indeks kode yang dapat ditanyakan, layanan LSP, basis data vektor...
Tapi无论用什么工具 (alat apa pun yang digunakan), esensinya sama: semakin besar basis kode, tingkat penarikan kembali (recall) semakin rendah. Dan recall yang rendah berarti: Agent tidak dapat menemukan semua kode terkait,自然也无法做出正确修改 (secara alami juga tidak dapat membuat modifikasi yang benar).
Ini juga mengapa一开始 (pada awalnya)那些 "代码味道" (bau kode)的小错误 (kesalahan kecil)会出现 (muncul), ia tidak menemukan implementasi yang sudah ada,于是 (lalu) mengulang造轮子 (menciptakan roda), memperkenalkan ketidakkonsistenan. Pada akhirnya, masalah-masalah ini akan terus menyebar, menumpuk, mekar menjadi一朵极其复杂的 "烂花" (bunga busuk yang sangat kompleks).
Lalu bagaimana kita menghindari semua ini?
Bagaimana Seharusnya Kita Berkolaborasi dengan Agent (Setidaknya untuk Saat Ini)
Agent pengkodean就像海妖 (bagaikan sirene), menarik Anda dengan kecepatan generasi kode yang sangat cepat dan kecerdasan yang "terputus-putus namun sesekali menakjubkan". Mereka sering dapat menyelesaikan beberapa tugas sederhana dengan kecepatan dan kualitas yang mencengangkan. Masalah benar-benar mulai muncul, adalah ketika Anda memiliki pemikiran seperti ini — "ini terlalu hebat, komputer, kerjakan untukku!"
Menyerahkan tugas kepada Agent本身 (sendiri) tentu tidak masalah. Tugas Agent yang baik biasanya memiliki beberapa karakteristik: cakupannya dapat dibatasi dengan baik, tidak perlu memahami seluruh sistem; tugasnya adalah闭环的 (lingkaran tertutup), artinya Agent dapat mengevaluasi hasilnya sendiri; keluarannya bukan jalur kritis, hanya是一些 alat sementara atau perangkat lunak untuk penggunaan internal, tidak mempengaruhi pengguna nyata atau pendapatan; atau Anda hanya需要一个 "橡皮鸭" (bebek karet) untuk辅助思考 (membantu pemikiran) — pada dasarnya adalah membawa ide Anda untuk bertabrakan dengan pengetahuan terkompresi internet dan data sintetis dalam satu putaran.
Jika kondisi ini terpenuhi, maka ini adalah tugas yang cocok diserahkan kepada Agent, dengan syarat, Anda sebagai manusia, tetap成为最终的质量把关者 (menjadi penjaga kualitas akhir).
Misalnya, menggunakan metode auto-research yang diusulkan Andrej Karpathy untuk mengoptimalkan waktu mulai aplikasi? Bagus. Tapi dengan syarat Anda清楚 (tahu jelas), bahwa kode yang dikeluarkannya绝对不具备生产可用性 (sama sekali tidak memiliki kelayakan produksi). Auto-research之所以有效 (alasan efektif),是因为 (adalah karena) Anda memberinya fungsi evaluasi, agar dapat mengoptimalkan围绕某个指标 (sekitar metrik tertentu) (seperti waktu mulai atau loss). Tapi fungsi evaluasi ini hanya mencakup dimensi yang非常狭窄 (sangat sempit). Agent akan dengan tegas mengabaikan semua metrik yang tidak ada dalam fungsi evaluasi, seperti kualitas kode, kompleksitas sistem, bahkan dalam某些情况下 (beberapa kasus) kebenaran pun可以忽略 (bisa diabaikan) — jika fungsi evaluasi Anda本身就有问题 (sendiri memang bermasalah).
Inti pemikirannya其实很简单 (sebenarnya sederhana): biarkan Agent melakukan hal-hal yang membosankan, yang tidak membuat Anda belajar hal baru, atau那些探索性工作 (pekerjaan eksplorasi) yang本来没时间尝试 (pada awalnya tidak sempat dicoba). Kemudian由你来评估结果 (oleh Anda untuk mengevaluasi hasil), memilih bagian yang真正合理 (benar-benar masuk akal)、正确 (benar), lalu menyelesaikan implementasi akhir. Tentu, langkah terakhir ini juga bisa dibantu Agent.
Tapi yang lebih ingin saya tekankan adalah:真的,该慢下来一点了 (Sungguh, sudah waktunya melambat sedikit).
Beri diri sendiri waktu untuk berpikir, apa sebenarnya Anda lakukan, mengapa melakukannya. Beri diri sendiri kesempatan untuk mengatakan "tidak", "tidak, ini tidak kita perlukan." Beri Agent batas yang jelas: berapa banyak kode yang diizinkan untuk dihasilkannya per hari, jumlah ini harus sesuai dengan kemampuan yang sebenarnya能够审查 (bisa Anda tinjau). Semua bagian yang menentukan "bentuk整体" (keseluruhan) sistem, seperti arsitektur, API等 (dll)都应该亲自写 (seharusnya ditulis sendiri). Anda bisa menggunakan pelengkapan otomatis untuk mendapatkan "rasa menulis kode", juga bisa berpasangan编程 (pemrograman) dengan Agent, tapi kuncinya adalah: Anda必须在代码里 (harus berada dalam kode).
Karena, menulis kode sendiri, atau melihatnya dibangun langkah demi langkah, proses ini本身会带来一种 "摩擦感" (sendiri akan membawa perasaan "gesekan"). Gesekan inilah yang membuat Anda lebih清楚 (jelas) apa yang sebenarnya ingin dilakukan, bagaimana sistem beroperasi, "rasa" keseluruhan如何 (bagaimana). Inilah tepatnya di mana pengalaman dan "selera"发挥作用 (berperan), dan ini恰恰是 (justru adalah) yang belum bisa digantikan oleh model paling canggih saat ini. Melambat,承受一点摩擦 (menerima sedikit gesekan),恰恰是 (justru adalah) cara Anda belajar dan tumbuh.
Pada akhirnya, yang Anda dapatkan akan是一个依然可维护的系统 (sebuah sistem yang masih dapat dipelihara) — setidaknya tidak lebih buruk daripada sebelum Agent muncul. Ya, sistem masa lalu juga tidak sempurna. Tapi pengguna Anda akan berterima kasih, karena produk Anda "berguna",而不是 (bukan)一堆糊出来的垃圾 (sampah yang dijejal).
Fitur yang Anda buat akan lebih sedikit, tetapi更正确 (lebih benar). Belajar mengatakan "tidak",本身就是一种能力 (sendiri adalah一种 kemampuan). Anda juga bisa tidur nyenyak, karena setidaknya Anda masih tahu apa yang terjadi dalam sistem, Anda masih memegang inisiatif. Pemahaman inilah yang memungkinkan Anda弥补 (mengatasi) masalah recall agentic search, membuat output Agent lebih dapat diandalkan, membutuhkan更少修补 (lebih sedikit perbaikan).
Ketika sistem bermasalah, Anda bisa turun tangan memperbaikinya; ketika desain一开始就不合理 (pada awalnya sudah tidak masuk akal), Anda juga bisa memahami di mana masalahnya, dan merefaktornya menjadi bentuk yang lebih baik. Adapun有没有 (ada atau tidak) Agent,其实没那么重要 (sebenarnya tidak那么 penting).
Semua ini membutuhkan disiplin. Semua ini, tidak bisa lepas dari manusia.







