- Dalam beberapa waktu terakhir, penyebaran agen coding AI memang mempercepat pengembangan, tetapi juga memperparah penurunan kualitas perangkat lunak dan ketidakstabilan
- Agen menumpuk kesalahan yang sama tanpa kemampuan belajar berulang, dan pada codebase besar muncul penurunan recall pencarian serta ledakan kompleksitas
- Jika seluruh sistem diserahkan tanpa kendali manusia, hasilnya akan menuju kode duplikat, pola desain yang keliru, dan codebase yang tak bisa dipelihara
- Untuk saat ini, agen sebaiknya digunakan secara terbatas pada pekerjaan non-inti atau area eksperimental, dan manusia harus tetap menjadi gerbang mutu terakhir
- Memperlambat laju dan memulihkan agensi manusia adalah kunci bagi pembelajaran, pertumbuhan, dan ekosistem perangkat lunak yang berkelanjutan
Semuanya sedang rusak
- Dalam setahun terakhir, agen coding telah berkembang hingga mampu menyelesaikan proyek nyata, tetapi akibatnya penurunan kualitas perangkat lunak makin menonjol
- Bahkan pada layanan besar, uptime 98% menjadi hal yang umum, dan bug UI sering terjadi
- Disebutkan pula kasus gangguan terkait AI di AWS dan pernyataan Microsoft tentang meningkatnya porsi kode AI
- Beberapa perusahaan mengklaim bahwa 100% kode produk mereka ditulis oleh AI, tetapi hasilnya tetap berkualitas rendah, dengan kebocoran memori, error UI, dan fungsi yang tidak stabil
- Sejumlah developer melaporkan bahwa pengembangan yang berpusat pada agen membuat mereka terjebak dalam codebase yang tak bisa dipelihara, karena tidak ada code review, tidak ada desain yang matang, dan fitur berlebih yang tidak perlu
Cara yang seharusnya tidak dipakai saat bekerja dengan agen
- Para developer sudah kecanduan pada kecepatan dan volume kode, sampai-sampai melepaskan kualitas dan kendali
- Dengan slogan “terdistribusi, otonom, otomatis”, mereka mencoba orkestrasi agen skala besar, tetapi pada praktiknya hanya memproduksi hasil yang tidak stabil
- Beberapa proyek bahkan sulit dijalankan, dan tidak bisa dipelihara tanpa campur tangan manusia
- Mungkin ini masih bisa dilakukan pada proyek pribadi, tetapi untuk produk dengan basis pengguna nyata, sebagian besar justru berakhir gagal
-
Akumulasi error dan ketiadaan pembelajaran, tanpa bottleneck, rasa sakit yang tertunda
- Agen tidak memiliki kemampuan belajar berulang, sehingga terus membuat kesalahan yang sama
- Manusia belajar dari kesalahan, tetapi agen mengulang kekeliruan yang sama tanpa henti
- Kecepatan menulis kode manusia terbatas sehingga akumulasi error berjalan lambat, tetapi pasukan agen tidak punya bottleneck sehingga error menumpuk secara eksplosif
- Akibatnya, codebase menjadi tidak bisa dipercaya, bahkan pengujian otomatis pun tak lagi dapat diandalkan
- Pada akhirnya, pengujian manual menjadi satu-satunya sarana verifikasi, dan tim pengembang menjebak diri mereka sendiri
-
Para pedagang yang mempelajari kompleksitas
- Agen hanya membuat keputusan lokal tanpa melihat konteks seluruh sistem
- Akibatnya, kode duplikat, abstraksi yang tidak perlu, dan kekacauan struktural menumpuk dengan cepat
- Dalam organisasi manusia, kompleksitas seperti ini terakumulasi perlahan selama bertahun-tahun, tetapi tim berbasis agen bisa mencapai tingkat kekacauan yang sama hanya dalam beberapa minggu
- Agen mereproduksi pola desain yang salah yang dipelajari dari data pelatihan, dan tanpa kendali manusia, mereka menciptakan kompleksitas yang tak dapat dipulihkan
-
Recall pencarian agen yang rendah
- Saat agen mencoba memperbaiki kode atau melakukan refactoring, mereka gagal menemukan seluruh kode yang dibutuhkan
- Semakin besar codebase, recall pencarian (recall) turun tajam, sehingga muncul duplikasi dan ketidakkonsistenan
- Meski menggunakan berbagai alat seperti Bash, LSP, dan vector DB, tetap ada batasan pada codebase berskala besar
- Karena itu, code smell dan kompleksitas yang tidak perlu makin memburuk
Cara bekerja dengan agen yang seharusnya dipakai (untuk saat ini)
- Agen memang menarik karena mampu menghasilkan kode dengan cepat dan kualitas awal yang tinggi, tetapi jika seluruh sistem diserahkan kepada mereka, hasilnya runtuh
- Kasus penggunaan yang tepat adalah tugas non-inti dengan cakupan kecil, tugas yang memungkinkan loop evaluasi mandiri, dan tugas yang tidak fatal jika gagal
- Contohnya, pembuatan alat internal, eksperimen ide, dan riset otomatis berbasis pengukuran performa (auto-research)
- Manusia harus tetap menjadi gerbang mutu terakhir, dan hasil dari agen harus ditinjau, diperbaiki, dan diintegrasikan
- Jika fungsi evaluasi hanya mencerminkan metrik yang sempit, agen bisa mengabaikan kualitas kode, kompleksitas, dan akurasi
- Memperlambat laju adalah kuncinya
- Sediakan waktu untuk memikirkan apa yang dibuat dan mengapa, lalu tolak dengan tegas fitur yang tidak perlu
- Batasi jumlah kode yang bisa dihasilkan agen per hari hingga level yang masih bisa direview
- Arsitektur, API, dan bentuk esensial sistem harus tetap ditulis langsung oleh manusia
- Lakukan pair programming dengan agen, agar ada gesekan dan kesempatan untuk memahami selama proses penulisan kode
- Pendekatan seperti ini membantu membangun codebase yang bisa dipelihara, meningkatkan kepuasan pengguna, dan membuat tim fokus pada fitur inti alih-alih fitur yang tidak perlu
- Jika pemahaman manusia tetap ada, masalah recall pada pencarian agen juga bisa berkurang, dan ketika masalah muncul pun manusia dapat memperbaikinya langsung
- Sekalipun desain awalnya keliru, kemampuan untuk memahami alasannya dan memperbaikinya tetap terjaga
- Pada akhirnya, yang dibutuhkan adalah disiplin dan agensi manusia
- Kualitas dan keberlanjutan sistem bergantung pada campur tangan dan penilaian manusia
- “Berjalan lebih lambat” justru merupakan satu-satunya jalan untuk menjaga pembelajaran dan pertumbuhan, serta ekosistem perangkat lunak yang sehat
2 komentar
Pi – harness coding terminal yang ringkas
Jadi ini orang yang membuat itu ya
Komentar Hacker News
Setiap kali membaca tulisan reflektif seperti ini belakangan ini, rasanya aku juga sampai di titik lelah
Pada akhirnya yang penting adalah “apa yang sedang kita bangun” dan “apakah alat itu benar-benar membantu”
Di era Ruby, PHP, Lotus Notes, dan Visual BASIC pun kita mengulang kesalahan yang sama
Kita harus memakai alat dengan bijak, dan bekerja dengan kecepatan yang cukup agar bisa memahami realitas kompleks yang benar-benar sedang dibangun tim
Agile atau waterfall, Docker atau Podman, itu bukan inti persoalannya
Sekarang kita hidup di zaman ketika LLM menghapus DB produksi lalu bahkan menggambar ilustrasi untuk blog postmortem-nya, tapi aku tidak yakin itu benar-benar engineering
Mungkin pengembangan perangkat lunak memang dari awal bukanlah disiplin rekayasa
Selama 10 tahun terakhir, industri perangkat lunak dipenuhi pekerjaan meta — framework baru, tool, lapisan virtualisasi, struktur organisasi, dan seterusnya
Tapi justru tidak jelas semua ini dibuat “untuk apa”
Rasanya seperti struktur skema piramida, seolah kita menciptakan pekerjaan baru demi mempertahankan industrinya
Meski begitu, engineering yang sesungguhnya tetap ada — saat kita merumuskan pertanyaan secara ilmiah dan membuat keputusan berdasarkan jawabannya
Sebaliknya, bekerja berdasarkan ‘feeling’ dan cuma mengikuti kata CEO itu bukan engineering
Dulu banyak tim bahkan tidak punya version control, dan kalaupun punya biasanya buruk
Kalau melihat Joel Test milik Joel Spolsky, pada masa itu kebanyakan perusahaan jawabannya adalah “tidak”
Jembatan menghitung beban, material, umur pakai, dan lain-lain secara presisi, tapi untuk website bahkan trafik pun sulit diprediksi
Tidak ada standar untuk memperlakukan batas kapasitas server atau framework secara kuantitatif
Mungkin suatu hari software bisa menjadi engineering sungguhan, tapi jalannya masih panjang
Rasanya label “engineer” ditempelkan hanya agar bisa dibayar lebih mahal
Engineer sungguhan menekankan pembuktian dan verifikasi, sedangkan kita menikmati pola baru dan berbagai percobaan
Karena itu, istilah ‘engineer’ justru terasa kurang nyaman
Ia mengkritiknya sebagai “metodologi bagi orang-orang yang tidak bisa memrogram untuk mencoba memrogram”, dan rasanya itu masih relevan sampai sekarang
Belakangan proses pengembangan berbasis AI makin mengeras di sekitar perusahaan besar, dan ketergantungan vendor makin parah
Jika codebase berubah menjadi berpusat pada agent, pada akhirnya hanya agent itulah yang akan memahami kodenya
Saat itu terjadi, harga akan naik, dan ini bisa menjadi transisi satu arah yang membuat developer manusia sulit kembali
Kaum optimis berkata “teknologi selalu makin murah dan makin baik”, tapi bisa saja jadinya seperti pasar minyak
Seperti saat dulu pindah dari DVD ke streaming, kita seakan membeli film yang sama dua kali
Model seperti Claude Opus 4.6 sekarang sudah semahal $1 per menit, dan prompt engineering tidak lagi cukup untuk mengoreksinya
Pada akhirnya layanan AI juga sedang terbagi ke dalam lapisan murah–menengah–premium
Prompt engineering sekarang hampir diperlakukan seperti jailbreaking yang licik
Berbahaya jika kemampuan kerja pengetahuan kita ‘disewakan’ kepada perusahaan AI
Kalimat “biayanya tidak akan naik lagi” adalah akhir dari percakapan — mereka sudah melempar dadu
Perusahaan AI besar juga akan menempuh jalan yang sama
Pada akhirnya kita mungkin akan terjebak di pasar pecandu token
Tangan tak terlihat dari open source pada akhirnya akan membuat semuanya gratis
Seiring hardware dan software berkembang, biaya komputasi per unit terus menurun
Teknologi tanpa penggunaan nyata akan lenyap seperti saat boom blockchain, tapi AI punya pengguna nyata
Layanan yang dulu dikritik seperti Uber pada akhirnya juga menemukan bentuk sebagai bisnis yang berkelanjutan
Tidak seperti minyak, komputasi setiap tahun makin murah dan makin cepat
Penulis artikel ini adalah orang yang membuat framework coding agent open source bernama Pi
Itu juga dipakai di OpenClaw
Tulisan blog tentang Pi miliknya juga layak dibaca
Dia adalah orang yang sudah mendalami LLM dan agent lebih dalam daripada kebanyakan orang
Semakin sering sebuah perusahaan mengklaim bahwa “AI menulis 100% kode kami”, semakin sering juga mereka merilis produk yang berantakan
Di era DOS atau MacOS dulu, kode seperti itu bisa menjatuhkan seluruh sistem, jadi kualitas jauh lebih penting
Sekarang OS lebih toleran, jadi kode yang ceroboh bisa tetap bertahan
Berkat update OTA, orang mudah merilis produk yang belum matang demi meluncur lebih cepat daripada kompetitor
Hanya saja, yang kita ingat hanyalah sedikit produk yang dibuat dengan baik
Sekarang selama ada koneksi jaringan, bahkan OS pun bisa di-update semudah game
Coding agent itu seperti ‘sirene yang menggoda’
Pada awalnya ia tampak cepat dan cerdas, tapi begitu kita mulai berpikir “komputer, kerjakan tugasku”, semuanya runtuh
Namun ini hanya sementara — AI sudah melampaui manusia di area-area yang bisa diukur
Masalah sebenarnya adalah HCI (interaksi manusia–komputer)
Tantangan utama ke depan adalah merancang antarmuka yang selaras dengan nilai manusia
Saat ini kita sedang berada di puncak fase hype AI
Seperti dulu saat MongoDB atau NoSQL berteriak bahwa “SQL sudah mati”, pada akhirnya orang akan kembali ke titik keseimbangan yang realistis
NoSQL tidak hilang, tapi sekarang dipakai hanya di tempat yang memang membutuhkannya
Aku setuju dengan pernyataan bahwa “software zaman sekarang rapuh dan berantakan”, tapi sebenarnya softwarenya sendiri tidak berubah
Dulu karena tidak ada kepercayaan, manusia memeriksa semuanya secara langsung, dan kecepatan yang lambat itulah yang mengurangi masalah
Inti DevOps adalah bergerak cepat dengan dasar kepercayaan, sambil tetap menjaga kualitas
Seperti Andon cord di Toyota, saat masalah ditemukan kita harus segera berhenti dan menyelesaikan akar penyebabnya
Ini bukan masalah teknologi, melainkan masalah budaya dan proses
Kita harus menemukan lebih awal antarmuka yang salah atau ketidakselarasan dengan konteks bisnis
Karena semua orang memakai GitHub, AWS, dan Cloudflare, saat satu tempat berhenti seluruh dunia ikut berhenti
Jika bug ditemukan tepat sebelum tape-out, mereka tidak menyalahkan pembawa pesan, melainkan menilainya dengan hati-hati
Hasil dari pemrograman bukan hanya kode, tapi juga programmer itu sendiri
Model mental dan memori otot yang terbentuk saat menulis kode adalah aset yang sebenarnya
Jika AI menggantikan proses ini, pada akhirnya pertumbuhan programmer juga akan hilang
“Preventing the Collapse of Civilization” dari Jonathan Blow juga membahas masalah yang sama
Lihat “Programming as Theory Building”
Kemarin aku membicarakan hal serupa dengan seorang rekan
Kami melihat demo AI yang membaca log, memperbaiki bug, bahkan menulis postmortem,
tapi masalahnya adalah manusia tidak punya waktu untuk menginternalisasi proses itu
Seperti ungkapan “mobil bisa melaju cepat karena punya rem”,
kita perlu mempertahankan gesekan belajar pada kecepatan yang masih bisa dipahami manusia
Jika agent dapat menyadari dan memulihkan sendiri, apakah manusia masih perlu belajar?
Tentu akar masalah bisa terlewat, tetapi jika sistem pemulihan otonom cukup tangguh, apakah itu benar-benar masalah?
Dari sudut pandang desain produk, aku merasakan masalah yang mirip
Kecepatan pengembangan terlalu tinggi sehingga tidak ada waktu untuk benar-benar memakainya dan memvalidasinya
Jika kita terus menumpuk fitur di atas desain yang salah, nantinya akan sulit untuk kembali
Pada akhirnya yang penting bukan kecepatan, melainkan keseimbangan antara kualitas dan pembelajaran
Proses seperti ini pasti membutuhkan waktu