AI bisa bikin fitur dalam 10 menit. Masalahnya: kode itu bisa tinggal di repo lu selama 10 bulan, bahkan 10 tahun.
Artikel ini ngebahas kenapa AI coding menurunkan biaya menulis kode, tapi tidak otomatis menurunkan biaya memiliki kode. Buat developer dan builder, pertanyaan pentingnya bukan lagi “bisa dibikin cepat nggak?”, tapi “siapa yang bakal merawat, mengamankan, menjelaskan, dan menanggung efek sampingnya nanti?”. Kalau lu mulai pakai Copilot, Codex, Claude Code, Cursor, atau AI coding agent lain, mindset ini penting biar workflow lu tetap produktif tanpa bikin codebase makin mahal.
AI mengubah biaya menulis kode, bukan biaya memiliki kode
GitHub menulis satu kalimat yang menurut gua pas banget buat era sekarang: the cost of writing code dropped; the cost of owning it didn’t. Biaya mengetik kode memang turun. Boilerplate bisa dibuat cepat. Test awal bisa digenerate. Refactor kecil bisa disiapkan dalam beberapa menit.
Tapi ownership code tidak ikut hilang. Kode yang masuk repo tetap perlu dibaca orang lain, direview, dites, dipantau di production, diamankan, dan dijelaskan saat ada bug. Kalau fitur itu nyentuh billing, auth, permission, data user, deployment, atau dependency baru, biaya sebenarnya sering baru muncul setelah PR terlihat “selesai”.
Definisi sederhananya: code ownership adalah tanggung jawab jangka panjang atas sebuah bagian codebase. Bukan cuma siapa yang pertama menulis, tapi siapa yang paham tradeoff-nya, siapa yang bisa memperbaiki saat rusak, dan siapa yang berani bilang “jangan merge dulu” saat risikonya belum jelas.
Masalahnya: AI bikin “yes” terasa terlalu murah
Sebelum AI coding mainstream, banyak tim lebih hati-hati menerima request kecil karena biaya implementasinya kelihatan. Ada developer yang harus duduk, mikir, nulis, test, dan bikin PR. Sekarang, request yang sama bisa kelihatan murah karena AI bisa langsung menghasilkan diff.
Di sinilah jebakannya. Kalau biaya membuat diff turun, tim bisa kebanyakan bilang “yes” ke perubahan yang sebenernya menambah utang operasional. Satu opsi setting baru. Satu mode khusus buat client tertentu. Satu integrasi tambahan. Satu dependency baru karena AI menyarankan library yang “mempermudah”. Semuanya kecil kalau dilihat sendiri-sendiri. Tapi saat dikumpulkan, codebase jadi penuh jalur khusus yang harus dipahami orang berikutnya.
Gua bukan anti-AI. Justru gua pakai AI buat mempercepat banyak kerja teknis. Tapi makin sering gua pakai AI, makin kerasa bahwa value terbesar developer bukan sekadar “bisa menghasilkan kode”, melainkan bisa memutuskan kode mana yang layak hidup di repo.
Checklist sebelum lu bilang yes ke kode AI
Kalau AI coding agent bikin perubahan yang kelihatan benar, jangan langsung merge cuma karena test hijau. Coba pakai checklist ini dulu.
- Owner: siapa yang bakal paham dan merawat bagian ini setelah merge?
- Scope: apakah perubahan ini menyelesaikan problem utama, atau cuma nambah cabang logika baru?
- Test: apakah test-nya membuktikan behavior penting, atau cuma test kosmetik biar coverage naik?
- Rollback: kalau fitur ini rusak di production, bisa dimatikan cepat nggak?
- Security: apakah ada permission, secret, input user, file access, atau dependency baru?
- Observability: kalau error muncul, lu punya log, metric, atau trace buat nyari sumbernya?
- Documentation: apakah keputusan pentingnya ditulis, atau cuma “terlihat jelas” di kepala orang yang merge?
Checklist ini bukan buat memperlambat semua PR. Ini buat membedakan perubahan yang memang murah dari perubahan yang cuma kelihatan murah karena AI cepat nulisnya.
Contoh konkret: fitur kecil yang diam-diam mahal
Bayangin lu punya SaaS kecil, lalu user minta “export data ke format custom”. AI bisa bantu bikin endpoint, query, serializer, dan tombol export dengan cepat. Dari luar, ini kelihatan seperti fitur 30 menit.
Tapi ownership cost-nya bisa lebih panjang:
- Kalau schema database berubah, export custom itu ikut harus disesuaikan.
- Kalau data user besar, endpoint bisa jadi lambat atau makan memory.
- Kalau export berisi data sensitif, permission harus benar.
- Kalau format custom dipakai client, perubahan kecil bisa jadi breaking change.
- Kalau tidak ada telemetry, lu baru tahu rusak setelah user komplain.
AI membantu bagian implementasi, tapi tidak otomatis menjawab pertanyaan produk, operasional, dan risiko. Di sinilah developer yang bagus tetap dibutuhkan: bukan buat mengetik lebih cepat dari model, tapi buat menjaga sistem tetap bisa dipercaya.
Duplikasi kadang lebih murah daripada abstraksi yang salah
Era AI juga bikin satu kebiasaan lama muncul lagi: terlalu cepat merapikan kode. AI sering menyarankan helper, abstraction, service layer, generic function, atau pattern yang terlihat profesional. Masalahnya, abstraksi yang salah bisa lebih mahal daripada sedikit duplikasi.
Sandi Metz pernah menulis soal wrong abstraction: saat abstraksi mulai salah arah, developer sering menambah parameter, flag, dan branching sampai abstraksi itu jadi tempat semua kasus aneh berkumpul. Di era AI, risiko ini makin terasa karena AI bisa membuat abstraksi kompleks dengan cepat dan rapi secara permukaan.
Prinsip praktisnya: kalau lu belum yakin dua logic itu benar-benar punya alasan berubah yang sama, jangan buru-buru disatukan. Sedikit duplikasi yang jelas kadang lebih mudah dirawat daripada abstraksi pintar yang bikin semua orang takut menyentuhnya.
Maintainer cost itu nyata, bukan drama open source
GitHub juga pernah membahas bagaimana pull request limits membantu maintainer mengurangi noise. Ini nyambung banget dengan AI coding. Saat biaya membuat PR turun, biaya review bisa naik. Maintainer tetap harus membaca diff, mengecek konteks, memverifikasi bug, dan memastikan perubahan tidak merusak bagian lain.
Di kantor pun sama. Kalau satu developer bisa menghasilkan lima PR AI-assisted per hari, bukan berarti tim otomatis lima kali lebih produktif. Bisa jadi bottleneck pindah ke reviewer. Bisa jadi senior engineer capek membaca output yang banyak tapi tidak semuanya penting. Bisa jadi bug surface naik karena terlalu banyak perubahan kecil yang tidak punya owner jelas.
Produktivitas tim bukan jumlah kode yang berhasil masuk. Produktivitas tim adalah perubahan berguna yang bisa dipertahankan dengan biaya wajar.
Cara pakai AI coding biar tetap sehat
Menurut gua, AI coding paling aman dipakai saat lu tetap memegang keputusan desain. Jangan serahkan “apa yang harus dibangun” sepenuhnya ke agent. Beri dia tugas sempit, minta output yang bisa direview, lalu pakai test dan diff sebagai kontrak kerja.
Workflow yang lebih sehat kira-kira seperti ini:
- Tulis problem dan batasan sebelum minta AI ngoding.
- Minta rencana singkat, bukan langsung diff besar.
- Pecah task jadi perubahan kecil yang bisa dibatalkan.
- Review file yang berubah, bukan cuma baca summary chat.
- Minta test untuk behavior penting, bukan test yang cuma mengikuti implementasi.
- Catat keputusan non-obvious di README, AGENTS.md, ADR kecil, atau komentar yang tepat.
- Kalau perubahan terasa terlalu besar buat direview, berarti task-nya terlalu besar.
Dengan cara ini, AI tetap jadi multiplier. Tapi multiplier-nya bekerja di atas judgment developer, bukan menggantikannya.
Kesimpulan singkat
AI bikin coding lebih cepat, tapi codebase tetap punya gravitasi. Setiap fitur, dependency, abstraction, dan jalur logika baru akan menarik biaya di masa depan. Developer yang kuat di era AI bukan yang paling cepat menerima semua output model, tapi yang paling jeli memilih perubahan mana yang layak dipelihara.
Kalau lu mau menjadikan AI coding bagian dari workflow harian, simpan satu pertanyaan ini sebelum merge: “Kode ini cepat dibuat, tapi apakah murah untuk dimiliki?”
FAQ singkat
Apakah ini berarti kode AI sebaiknya ditolak?
Nggak. Kode AI bisa sangat membantu. Yang perlu ditolak adalah perubahan yang tidak jelas owner, test, risiko, dan alasan bisnisnya.
Apa bedanya typing cost dan ownership cost?
Typing cost adalah biaya membuat kode pertama kali. Ownership cost adalah biaya merawat kode setelah masuk repo: review, test, bugfix, security, dokumentasi, dan migrasi.
Kenapa test hijau belum cukup?
Test hijau cuma membuktikan hal yang memang dites. Kalau test-nya dangkal, tidak mencakup edge case, atau hanya mengikuti implementasi, kode tetap bisa rapuh di production.
Apa satu kebiasaan paling penting saat pakai AI coding agent?
Review diff dengan serius. Jangan percaya summary chat sebagai audit trail. Lihat file yang berubah, pahami tradeoff-nya, lalu pastikan ada bukti bahwa behavior penting benar.
