Judul Asli: Pemikiran tentang memperlambat, sialan
Penulis Asli: Mario Zechner
Disusun: Peggy, BlockBeats
Catatan Redaksi: Di tengah percepatan AI generatif yang masuk ke rekayasa perangkat lunak, suasana industri sedang bergeser dari “kagum akan kemampuan” menuju “kecemasan akan efisiensi”. Menulis tidak cukup cepat, memakai tidak cukup banyak, otomatisasi tidak cukup tuntas—semuanya seolah akan membuat orang merasa terancam tersingkir. Tetapi ketika agent pengkodean benar-benar masuk ke lingkungan produksi, beberapa masalah yang lebih realistis mulai muncul: kesalahan diperbesar, kompleksitas lepas kendali, sistem berangsur menjadi tidak dapat dipahami, dan peningkatan efisiensi tidak berbanding lurus dengan peningkatan kualitas.
Artikel ini didasarkan pada praktik di garis depan, menawarkan refleksi yang tenang terhadap gelombang panas “agentic coding” ini. Penulis menegaskan bahwa Agent tidak “belajar dari kesalahan” seperti manusia. Dalam ketiadaan bottleneck dan mekanisme umpan balik, masalah kecil akan dengan cepat diperbesar; dan dalam basis kode yang kompleks, perspektif lokal serta kemampuan penarikan kembali (recall) yang terbatas justru semakin memperparah kekacauan struktur sistem. Esensi dari masalah-masalah ini bukan terletak pada teknologinya sendiri, melainkan pada manusia yang, didorong oleh kecemasan, menyerahkan penilaian dan kontrol terlalu dini.
Karena itu, daripada terjebak dalam kecemasan “apakah kita harus sepenuhnya merangkul AI”, lebih baik menata ulang hubungan antara manusia dan alat: biarkan Agent menangani tugas yang bersifat lokal dan dapat dikendalikan, sementara desain sistem, penjagaan kualitas, dan keputusan-keputusan kunci tetap kuat di tangan Anda. Dalam proses ini, “melambat” justru menjadi sebuah kemampuan—artinya Anda masih memahami sistem, mampu membuat pilihan, dan tetap memiliki rasa kendali atas pekerjaan.
Di era ketika alat terus berkembang, kelangkaan yang sesungguhnya mungkin bukan kemampuan generatif yang lebih cepat, melainkan kemampuan menilai kompleksitas, serta keteguhan untuk membuat pilihan di antara efisiensi dan kualitas.
Berikut naskah asli:
Wajah kura-kura itu, itulah ekspresi yang saya lihat ketika memandang industri ini
Sekitar setahun yang lalu, agent pengkodean yang benar-benar bisa membantu Anda “mengerjakan proyek lengkap dari awal sampai akhir” mulai bermunculan. Sebelum itu juga ada alat seperti Aider dan Cursor generasi awal, tetapi alat-alat tersebut lebih mirip asisten, bukan “agen”. Generasi alat berikutnya sangat menarik; banyak orang juga meluangkan waktu luang yang cukup banyak untuk menyelesaikan semua proyek yang selama ini ingin mereka buat, tetapi tidak punya waktu.
Saya rasa itu sendiri tidak masalah. Senang bisa membuat sesuatu dengan waktu luang, dan kebanyakan waktu Anda juga tidak terlalu perlu memedulikan kualitas kode dan maintainability. Ini juga memberi Anda jalur untuk mempelajari tumpukan teknologi baru.
Selama libur Natal, Anthropic dan OpenAI juga merilis beberapa “kuota gratis”, seperti mesin slot yang menarik orang masuk. Bagi banyak orang, ini pertama kalinya benar-benar mengalami “sihir agent menulis kode”. Jumlah peserta semakin banyak.
Kini, agent pengkodean juga mulai masuk ke basis kode produksi. Setelah 12 bulan berlalu, kita mulai melihat konsekuensi dari “kemajuan” ini. Berikut adalah pandangan saya saat ini.
Semuanya rusak
Meskipun sebagian besar ini hanyalah pengalaman, saat ini perangkat lunak memang memberi rasa “setiap saat bisa hancur”. Ketersediaan 98% berubah dari pengecualian menjadi kebiasaan; bahkan layanan besar pun tidak terkecuali. Antarmuka pengguna dipenuhi berbagai bug yang absurd—bug yang seharusnya bisa langsung ditangkap oleh tim QA.
Saya akui kondisi ini sudah ada bahkan sebelum agent muncul. Tetapi sekarang, masalahnya jelas sedang dipercepat.
Kita tidak melihat kondisi sebenarnya di dalam perusahaan, tetapi kadang ada informasi yang bocor, misalnya dugaan tentang “AWS down akibat AI”. Amazon Web Services kemudian dengan cepat “mengoreksi” klaim itu, tetapi langsung setelahnya mereka menjalankan rencana penataan ulang internal selama 90 hari.
Satya Nadella (CEO Microsoft) baru-baru ini juga terus menekankan bahwa semakin banyak kode di perusahaan ditulis oleh AI. Walaupun tidak ada bukti langsung, ada perasaan bahwa kualitas Windows sedang menurun. Bahkan dari beberapa blog yang dipublikasikan Microsoft sendiri, mereka tampaknya mengasumsikan hal itu.
Perusahaan yang mengklaim “produk 100% kodenya dihasilkan oleh AI” hampir selalu menghasilkan produk terburuk yang bisa Anda bayangkan. Bukan untuk menyerang siapa pun, tetapi kebocoran memori dalam hitungan GB, kekacauan UI, fitur yang tidak lengkap, crash yang sering… Semua ini jelas bukan “jaminan kualitas” yang mereka kira, apalagi contoh positif “biarkan agent mengerjakan semuanya untuk Anda”.
Secara pribadi, Anda akan semakin sering mendengar satu hal: baik perusahaan besar maupun tim kecil sama-sama mengatakan bahwa mereka sudah didorong ke jalan buntu oleh “agent menulis kode”. Tanpa code review, menyerahkan keputusan desain kepada Agent, lalu menumpuk tumpukan fitur yang tidak diperlukan siapa pun—akhirnya tentu tidak akan baik.
Mengapa kita tidak seharusnya menggunakan Agent seperti ini
Kita hampir sudah menyerahkan semua disiplin rekayasa dan pertimbangan subjektif, lalu terjebak dalam cara kerja yang adiktif: satu-satunya tujuan—menghasilkan sebanyak mungkin kode dalam waktu sesingkat mungkin, sementara konsekuensinya sama sekali tidak dipertimbangkan.
Anda membangun lapisan orkestrasi untuk memerintah sebuah “pasukan” agent otomatis. Anda memasang Beads, tetapi Anda sama sekali tidak tahu bahwa pada dasarnya itu hampir seperti “malware” yang tidak bisa dilepas. Hanya karena di internet orang bilang “semua orang melakukan itu”. Kalau tidak melakukannya, Anda “bakal tamat” (ngmi).
Anda terus menghabiskan diri dalam “loop seperti boneka bersarang” (套娃式循环) yang berulang.
Coba lihat—Anthropic membuat sebuah kompiler C dengan sekumpulan agent; meskipun masih ada masalah sekarang, pasti generasi model berikutnya akan memperbaikinya, kan?
Lihat lagi—Cursor membuat sebuah browser dengan banyak agent; meskipun pada dasarnya tidak bisa digunakan sekarang dan perlu intervensi manual kadang-kadang, generasi model berikutnya pasti bisa menanganinya, kan?
“Terdistribusi”, “pecah dan kuasai”, “sistem otonom”, “pabrik lampu-mati (black lights)”, “enam bulan menyelesaikan masalah perangkat lunak”, “SaaS sudah mati, nenek saya baru saja pakai Claw untuk bikin Shopify”……
Narasi seperti ini terdengar sangat menyenangkan.
Tentu saja, cara seperti ini mungkin memang masih bisa “berjalan” untuk side project Anda yang hampir tidak dipakai siapa pun (termasuk Anda sendiri). Mungkin memang ada seorang jenius yang bisa membuat produk perangkat lunak yang tidak sampah, benar-benar dipakai orang, dengan cara seperti ini. Jika Anda memang orang itu, saya benar-benar mengagumi.
Tapi setidaknya di komunitas lingkar pengembang di sekitar saya, saya belum pernah melihat contoh yang benar-benar efektif dengan metode seperti ini. Tentu, mungkin saja kami semua terlalu kurang.
Kesalahan terus bertumpuk: tanpa pembelajaran, tanpa bottleneck, dan ledakan keterlambatan
Masalah agent adalah: mereka akan membuat kesalahan. Itu sendiri tidak masalah—manusia juga membuat kesalahan. Mungkin ini hanya kesalahan tentang kebenaran (correctness) yang mudah dikenali dan mudah diperbaiki; lalu tambah regresi test saja biar lebih stabil. Atau mungkin ini semacam “code smells” yang tidak tertangkap oleh linter: di sini ada metode yang tidak berguna, di sana ada tipe yang tidak masuk akal, dan ada kode duplikat, dan semacamnya. Jika dilihat satu per satu, kesalahan-kesalahan itu tidak berbahaya—pengembang manusia juga melakukan kesalahan kecil seperti ini.
Tapi “mesin” bukan manusia. Setelah manusia mengulangi kesalahan yang sama beberapa kali, biasanya mereka belajar untuk tidak melakukannya lagi—entah karena dimarahi orang, atau karena memang proses belajar yang nyata.
Sedangkan agent tidak punya kemampuan belajar seperti itu, setidaknya secara default tidak ada. Ia akan mengulang kesalahan yang sama berkali-kali, bahkan mungkin “menciptakan” kombinasi kesalahan yang luar biasa berbeda berdasarkan data pelatihan.
Anda tentu bisa mencoba “melatihnya”: menulis aturan di AGENTS.md agar ia tidak melakukan kesalahan seperti itu lagi; merancang sistem memori yang rumit agar ia bisa mencari riwayat kesalahan dan best practice. Ini memang efektif untuk beberapa jenis masalah tertentu. Tetapi syaratnya—Anda harus terlebih dahulu menyadari bahwa ia melakukan kesalahan tersebut.
Perbedaan yang lebih penting ada pada: manusia memiliki bottleneck, sedangkan agent tidak.
Manusia tidak mungkin mengeluarkan 20.000 baris kode dalam beberapa jam. Bahkan jika frekuensi kesalahan tidak rendah, dalam sehari hanya ada sejumlah terbatas kesalahan yang diperkenalkan, dan akumulasinya berjalan lambat. Biasanya, ketika “rasa sakit akibat kesalahan” menumpuk sampai tingkat tertentu, manusia (karena naluri menghindari rasa sakit) akan berhenti lalu memperbaiki. Atau orangnya digantikan, dan pihak lain yang memperbaiki. Intinya, masalah akan ditangani.
Tetapi ketika Anda memakai satu paket lengkap agent “tentara” yang diorkestrasi, tidak ada bottleneck, dan juga tidak ada “rasa sakit”. Kesalahan-kesalahan kecil yang awalnya remeh ini justru menumpuk dengan kecepatan yang tidak berkelanjutan. Anda sudah dikeluarkan dari loop, bahkan tidak tahu bahwa masalah-masalah kecil yang tampak tidak berbahaya ini sudah tumbuh menjadi monster besar. Ketika Anda akhirnya merasakan “rasa sakit”, biasanya sudah terlambat.
Sampai suatu hari, Anda ingin menambah fitur baru, tetapi Anda mendapati bahwa arsitektur sistem yang ada (pada dasarnya sudah merupakan tumpukan kesalahan) sama sekali tidak mendukung perubahan; atau pengguna mulai mengeluh hebat karena rilis terbaru bermasalah, bahkan sampai kehilangan data.
Baru saat itulah Anda menyadari: Anda sudah tidak bisa lagi mempercayai basis kode tersebut.
Lebih buruk lagi, ribuan unit test, snapshot test, end-to-end test yang dihasilkan oleh agent juga tidak lagi dapat dipercaya. Satu-satunya cara untuk menilai apakah “sistem bekerja normal” tinggal tes manual.
Selamat—Anda sudah menggali lubang untuk diri Anda (dan perusahaan) sendiri.
Para “penjual kompleksitas”
Anda sama sekali tidak tahu apa yang sebenarnya terjadi di dalam sistem, karena Anda menyerahkan kendali kepada agent. Dan pada dasarnya, agent sedang “memasarkan kompleksitas”. Mereka telah melihat banyak keputusan arsitektur yang buruk dalam data pelatihan, dan selama reinforcement learning juga terus memperkuat pola-pola tersebut. Anda memintanya mendesain sistem—hasilnya bisa Anda tebak.
Pada akhirnya, yang Anda dapat adalah: satu paket sistem yang sangat kompleks, dicampur dengan imitasi yang buruk dari “best practice industri”, sementara Anda tidak memberi batasan apa pun sebelum masalah lepas kendali.
Tapi masalahnya tidak berhenti di situ. Agent Anda tidak saling berbagi proses eksekusi, tidak melihat seluruh basis kode, dan bahkan tidak mengetahui keputusan yang Anda atau agent lain buat sebelumnya. Karena itu, keputusan mereka selalu “lokal”.
Ini langsung mengarah pada masalah yang tadi disebutkan: banyak kode duplikat, struktur yang abstraknya dibuat hanya demi abstrak itu sendiri, berbagai ketidakkonsistenan. Masalah-masalah ini terus bertumpuk, hingga akhirnya membentuk sistem kompleks yang tidak bisa diperbaiki lagi.
Ini sebenarnya mirip dengan basis kode enterprise yang ditulis manusia. Hanya saja kompleksitas semacam itu biasanya merupakan akumulasi bertahun-tahun: rasa sakitnya tersebar ke banyak orang, masing-masing tidak mencapai titik ambang “harus diperbaiki”, toleransi organisasi pun tinggi, lalu kompleksitas berevolusi bersama organisasi dalam bentuk simbiosis.
Namun pada kombinasi manusia + agent, proses ini akan dipercepat secara drastis. Dua orang, ditambah sekumpulan agent, dalam hitungan minggu bisa mencapai tingkat kompleksitas seperti itu.
Recall dalam agentic search sangat rendah
Anda mungkin berharap agent bisa “membereskan kekacauan”—melakukan refaktor, mengoptimalkan, dan membuat sistem menjadi bersih. Tetapi masalahnya: mereka sudah tidak mampu lagi.
Karena basis kode terlalu besar, kompleksitasnya terlalu tinggi, dan mereka selalu hanya bisa melihat bagian tertentu. Ini bukan sekadar karena konteks window tidak cukup besar, atau karena mekanisme long context gagal menghadapi jutaan baris kode. Masalahnya lebih tersembunyi.
Sebelum agent mencoba memperbaiki sistem, mereka harus terlebih dahulu menemukan semua kode yang perlu diubah, serta implementasi yang ada yang bisa digunakan kembali. Langkah inilah yang kita sebut agentic search (pencarian oleh agent).
Cara agent melakukan hal ini bergantung pada tool yang Anda berikan: bisa Bash + ripgrep, bisa indeks kode yang bisa ditanya, layanan LSP, database vektor……
Namun apa pun tool yang digunakan, intinya sama: semakin besar basis kode, semakin rendah recall. Recall yang rendah berarti: agent tidak dapat menemukan semua kode terkait, sehingga secara otomatis tidak bisa melakukan perubahan yang benar.
Inilah juga mengapa sejak awal kesalahan-kesalahan kecil “code smell” muncul: ia tidak menemukan implementasi yang sudah ada, lalu membuat ulang roda, sehingga menimbulkan ketidakkonsistenan. Akhirnya, masalah-masalah ini terus menyebar, bertumpuk, dan bermuara menjadi “hamparan bunga” yang sangat kompleks.
Lalu bagaimana cara mencegah semuanya?
Bagaimana seharusnya bekerja sama dengan Agent (setidaknya saat ini)
Agent pengkodean seperti peri laut (sea witch): dengan kecepatan generasi kode yang sangat cepat dan semacam kecerdasan yang “putus-putus tapi kadang sangat mengagumkan”, mereka membuat Anda tertarik. Mereka sering bisa menyelesaikan tugas-tugas sederhana dengan kecepatan dan kualitas yang mengesankan. Masalah yang benar-benar mulai muncul adalah ketika Anda sampai pada pemikiran seperti ini—“Ini terlalu kuat; komputer, kerjakan saja untukku!”
Menyerahkan tugas kepada agent itu sendiri tentu tidak masalah. Tugas agent yang baik biasanya memiliki beberapa karakteristik: ruang lingkupnya bisa dibatasi dengan baik, tidak perlu memahami seluruh sistem; tugasnya tertutup (closed loop), artinya agent bisa menilai hasilnya sendiri; outputnya bukan jalur kritis—hanya beberapa alat sementara atau perangkat lunak untuk pemakaian internal yang tidak memengaruhi pengguna asli atau pendapatan; atau Anda hanya membutuhkan “papan pantul karet” (umpai duck/itik karet) untuk membantu berpikir—intinya, ide Anda dicocokkan dengan tabrakan sekali putaran antara pengetahuan terkompresi internet dan data sintetis.
Jika syarat-syarat ini terpenuhi, maka ini adalah tugas yang cocok untuk diserahkan ke agent—dengan catatan Anda sebagai manusia tetap menjadi penanggung jawab utama kualitas.
Misalnya, mengoptimalkan waktu startup aplikasi dengan metode auto-research yang diajukan Andrej Karpathy? Baik. Tapi dengan syarat: kode yang keluar dari situ sama sekali tidak memiliki kelayakan produksi. Auto-research efektif karena Anda memberinya fungsi evaluasi, sehingga ia bisa mengoptimalkan sekitar sebuah metrik (misalnya waktu startup atau loss). Tetapi fungsi evaluasi itu hanya mencakup dimensi yang sangat sempit. Agent lalu dengan logis akan mengabaikan semua metrik yang tidak ada dalam fungsi evaluasi—seperti kualitas kode, kompleksitas sistem, bahkan dalam beberapa kasus kebenaran sekalipun bisa diabaikan—jika fungsi evaluasi Anda memang bermasalah sejak awal.
Inti idenya sebenarnya sederhana: biarkan agent mengerjakan hal-hal membosankan yang tidak membuat Anda belajar hal baru, atau pekerjaan eksploratif yang seharusnya tidak Anda sempat coba. Lalu Anda mengevaluasi hasilnya, memilih bagian yang benar-benar masuk akal dan benar, kemudian menyelesaikan implementasi akhir. Tentu, langkah terakhir pun bisa Anda bantu dengan agent.
Tapi yang ingin saya tekankan lebih kuat adalah: sungguh, kita perlu memperlambat sedikit.
Luangkan waktu untuk berpikir tentang apa yang sebenarnya Anda kerjakan dan mengapa Anda melakukannya. Beri diri Anda kesempatan untuk berkata “tidak”, “tidak, ini tidak perlu.” Beri agent batas yang jelas: berapa banyak kode yang diizinkan dihasilkan setiap hari—jumlahnya harus sesuai dengan kemampuan aktual Anda untuk melakukan review. Bagian-bagian yang menentukan “bentuk keseluruhan” sistem, seperti arsitektur dan API, harus Anda tulis sendiri. Anda bisa menggunakan auto-complete untuk mencari sedikit “rasa” menulis manual, atau berpasangan programming (pair programming) dengan agent, tetapi yang penting: Anda harus berada di dalam kodenya.
Karena, menulis kode sendiri, atau melihatnya dibangun langkah demi langkah, proses itu sendiri menghadirkan semacam “gesekan” (friction). Justru gesekan inilah yang membuat Anda lebih jelas tentang apa yang benar-benar ingin Anda buat, bagaimana sistem bekerja, dan seperti apa “hand feel” keseluruhannya. Di sinilah pengalaman dan “selera” (taste) berperan—dan justru hal inilah yang masih belum bisa digantikan oleh model paling canggih saat ini. Memperlambat, menanggung sedikit gesekan, justru adalah cara Anda belajar dan bertumbuh.
Pada akhirnya, Anda akan mendapatkan sistem yang tetap dapat dipelihara—setidaknya tidak lebih buruk dibanding sebelum munculnya agent. Ya, sistem lama juga tidak sempurna. Tetapi pengguna Anda akan berterima kasih karena produk Anda “berguna”, bukan sekumpulan sampah yang dibuat asal jadi.
Fitur yang Anda buat akan lebih sedikit, tetapi lebih benar. Belajar berkata “tidak” itu sendiri adalah sebuah kemampuan. Anda juga bisa tidur nyenyak tanpa khawatir, karena Anda setidaknya masih tahu apa yang terjadi di dalam sistem, dan Anda tetap memegang kendali penuh. Pemahaman inilah yang memungkinkan Anda menutup masalah recall dalam agentic search, membuat output agent lebih andal, dan membutuhkan lebih sedikit perbaikan.
Ketika sistem bermasalah, Anda bisa turun langsung untuk memperbaiki; ketika desain sejak awal tidak masuk akal, Anda juga bisa memahami masalahnya, lalu merekonstruksikannya menjadi bentuk yang lebih baik. Adapun ada atau tidaknya agent, sebenarnya tidak terlalu penting.
Semuanya ini membutuhkan disiplin. Semuanya ini tidak bisa lepas dari manusia.
[Tautan Asli]
Klik untuk mempelajari rekrutmen BlockBeats yang sedang membuka posisi
Selamat bergabung dengan komunitas resmi BlockBeats:
Grup Telegram untuk berlangganan: https://t.me/theblockbeats
Grup Telegram: https://t.me/BlockBeats_App
Akun resmi Twitter: https://twitter.com/BlockBeatsAsia
