Ada satu jebakan kecil dari AI coding tools yang jarang dibahas: rasanya seperti kita sedang mempercepat pekerjaan, padahal bisa jadi kita sedang mempercepat datangnya utang teknis.
Beberapa tahun lalu, memakai autocomplete yang pintar sudah terasa seperti sihir kecil. Sekarang levelnya naik. Kita bisa minta agent membuat fitur, memperbaiki bug, menulis test, membaca codebase, bahkan membuat pull request. Di titik tertentu, programmer tidak lagi cuma mengetik kode. Programmer mulai menjadi orang yang memberi arahan, mengecek hasil, dan memutuskan mana yang layak masuk ke sistem.
Kedengarannya menyenangkan. Dan memang menyenangkan.
Tapi di balik semua demo yang terlihat mulus, ada pertanyaan yang lebih membosankan tapi jauh lebih penting: apakah AI coding agent benar-benar mengurangi beban maintenance, atau cuma membuat kita menghasilkan lebih banyak kode yang nanti harus kita rawat?
Kecepatan menulis kode bukan metrik utama
Masalahnya, software jarang mahal di hari pertama ia dibuat. Yang mahal biasanya datang setelahnya: bug kecil yang muncul di edge case, dependency yang perlu di-upgrade, desain yang ternyata susah diperluas, test yang rapuh, naming yang membingungkan, dan keputusan teknis yang dulu terasa “sementara” tapi akhirnya tinggal bertahun-tahun.
AI sangat bagus dalam membuat sesuatu terlihat jadi. Dalam hitungan menit, ia bisa menghasilkan file baru, endpoint baru, komponen UI baru, atau script baru. Buat developer yang sedang dikejar deadline, ini terasa seperti cheat code.
Namun software bukan cuma soal “jadi”. Software juga soal “masih bisa dipahami tiga bulan lagi”.
Kalau sebuah agent membuat fitur dua kali lebih cepat, tapi kodenya membuat maintenance dua kali lebih berat, kita sebenarnya tidak sedang menang. Kita cuma memindahkan biaya dari hari ini ke masa depan. Lebih parah lagi, biaya masa depan itu biasanya dibayar oleh orang yang berbeda: future you, teammate, atau developer baru yang belum tahu konteks keputusan awalnya.
AI bisa membuat kita terlalu mudah berkata “ya”
Salah satu efek paling halus dari AI coding agent adalah menurunnya rasa “mahal” saat menambah kode.
Dulu, kalau kita ingin membuat fitur baru, ada gesekan alami. Kita harus memikirkan struktur, menulis implementasi, menulis test, membaca error, dan memperbaiki bagian yang rusak. Gesekan ini kadang menyebalkan, tapi ia juga berfungsi sebagai rem. Ia memaksa kita bertanya: fitur ini perlu atau tidak? Solusinya harus sekompleks ini atau bisa lebih sederhana?
Dengan agent, gesekan itu berkurang. Kita bisa bilang: “tambahkan fitur export”, “buat dashboard admin”, “integrasikan payment”, “refactor modul ini”, lalu menunggu hasilnya. Karena biaya awal terasa murah, kita jadi lebih mudah menyetujui kompleksitas baru.
Padahal kompleksitas tidak hilang. Ia hanya datang dalam bentuk yang lebih rapi.
PR yang terlihat lengkap bisa menyembunyikan asumsi yang tidak cocok. Test yang terlihat banyak bisa mengetes hal yang kurang penting. Abstraksi yang terlihat profesional bisa jadi terlalu dini. Dan kode yang “jalan” bisa tetap sulit dirawat.
Peran developer bergeser: dari penulis kode menjadi editor sistem
Menurut saya, cara paling sehat melihat AI coding agent bukan sebagai pengganti developer, tapi sebagai junior developer yang sangat cepat, tidak gampang lelah, dan kadang terlalu percaya diri.
Ia bisa membantu luar biasa banyak. Tapi tetap butuh editor.
Developer yang memakai AI dengan baik bukan cuma orang yang jago prompt. Ia juga orang yang tahu kapan harus menolak hasil AI. Ia bisa membaca diff dengan curiga. Ia tahu bagian mana yang harus dibuat eksplisit. Ia tahu kapan sebuah solusi terlalu besar untuk masalah kecil. Ia tahu bahwa “works on my machine” bukan akhir cerita.
Dalam workflow seperti ini, skill yang naik nilainya justru bukan sekadar mengetik cepat. Yang naik nilainya adalah judgement.
Apakah desain ini masuk akal?
Apakah naming-nya menjelaskan domain?
Apakah test-nya melindungi behavior penting?
Apakah perubahan ini membuat codebase lebih mudah dipahami?
Pertanyaan-pertanyaan itu tidak sekeren demo agent yang bisa membuat aplikasi dalam 10 menit. Tapi di production, pertanyaan seperti itulah yang menentukan apakah project akan tetap sehat atau pelan-pelan menjadi hutan.
Agent yang bagus harus mengurangi maintenance, bukan cuma menambah output
Kalau kita serius memakai AI untuk software development, targetnya seharusnya bukan “berapa banyak kode yang bisa dibuat hari ini”. Target yang lebih bagus adalah: “berapa banyak masalah masa depan yang berhasil kita hindari?”
Agent yang benar-benar berguna harus membantu kita melakukan hal-hal seperti:
- menemukan bagian kode yang rawan sebelum bug muncul,
- menulis test yang benar-benar mengunci behavior penting,
- menyederhanakan desain yang mulai melebar,
- menjelaskan konsekuensi dari sebuah perubahan,
- membuat dokumentasi teknis yang tidak basi dalam dua hari,
- dan memberi sinyal saat solusi yang kita minta sebenarnya terlalu kompleks.
Dengan kata lain, AI tidak boleh hanya menjadi mesin penambah file. Ia harus menjadi alat untuk menjaga codebase tetap masuk akal.
Ini juga berarti kita perlu mengubah cara memberi tugas ke AI. Jangan hanya bilang, “buatkan fitur X”. Coba tambahkan constraint seperti:
- “buat solusi paling sederhana yang bisa bekerja”,
- “hindari abstraksi baru kecuali benar-benar perlu”,
- “jelaskan trade-off dari pendekatan ini”,
- “tambahkan test untuk behavior, bukan implementasi”,
- “tunjukkan bagian yang berisiko sebelum menulis kode”.
Prompt seperti ini mungkin terasa kurang ajaib, tapi hasilnya biasanya lebih sehat.
Masalah baru: review manusia bisa jadi bottleneck
Ada satu paradoks menarik. Semakin cepat AI menghasilkan kode, semakin besar beban manusia untuk mereview.
Jika satu developer sekarang bisa membuat tiga PR dalam waktu yang dulu hanya cukup untuk satu PR, apakah tim juga punya kapasitas review tiga kali lebih besar? Biasanya tidak. Akhirnya review menjadi lebih dangkal. Orang mulai approve karena diff terlalu panjang. Test hijau menjadi alasan untuk percaya. Dan perlahan, standar turun bukan karena tim tidak peduli, tapi karena volume pekerjaan melewati kapasitas perhatian manusia.
Ini alasan kenapa AI coding agent perlu dibatasi dengan sistem, bukan cuma niat baik.
Tim perlu aturan: PR harus kecil, perubahan harus punya konteks, test harus jelas, dan agent tidak boleh membuat keputusan arsitektur besar tanpa diskusi. Boring? Iya. Tapi software yang bertahan lama biasanya dibangun dari kebiasaan boring yang dilakukan konsisten.
Jadi, harus pakai AI coding agent atau tidak?
Menurut saya: pakai. Tapi jangan mabuk.
AI coding agent adalah salah satu lompatan paling menarik dalam cara kita membangun software. Ia membuat eksperimen lebih murah. Ia membantu melewati blank page. Ia bisa mempercepat pekerjaan repetitif yang sebelumnya menghabiskan energi. Untuk solo builder, indie hacker, atau tim kecil, ini bisa jadi leverage besar.
Tapi leverage selalu punya dua sisi. Ia bisa mengangkat beban yang berat, atau memperbesar kesalahan kecil sampai efeknya terasa jauh lebih mahal.
Yang perlu kita kejar bukan hanya “ngoding lebih cepat”. Itu terlalu dangkal. Yang perlu kita kejar adalah “membangun software yang lebih mudah diubah”. Jika AI membantu kita sampai ke sana, bagus. Jika AI hanya membuat kita menumpuk kode lebih cepat, mungkin kita sedang membangun masalah dengan produktivitas tinggi.
Di masa depan, developer yang paling terbantu AI mungkin bukan yang paling sering menyuruh agent menulis kode. Mungkin justru yang paling disiplin menyuruh agent berpikir, mengecek, menyederhanakan, dan kadang berhenti.
Karena pada akhirnya, kode terbaik bukan kode yang paling cepat dibuat. Kode terbaik adalah kode yang masih bisa dimengerti saat semangat awalnya sudah hilang.
Referensi:
