AI coding agent menurunkan biaya membuat draft implementasi, sehingga permintaan yang dulu langsung ditolak kini dapat diuji secara terbatas. Namun kode yang di-merge membawa maintenance, on-call, security, dokumentasi, kompatibilitas, dan ekspektasi pengguna. GitHub mengusulkan engineer memakai agen untuk menghasilkan artefak kecil di bawah constraint, lalu menilai biaya ownership dengan evidence, bukan tebakan atau antusiasme pada kecepatan menulis kode.
Biaya implementasi dan biaya ownership berbeda
Menulis patch hanyalah bagian awal. Fitur mengubah kontrak, test, observability, support, dan jalur upgrade. Bug muncul ketika dependensi atau kebutuhan berubah. AI dapat menghemat jam coding, tetapi tidak otomatis mengambil pager, menjelaskan keputusan, atau menjamin kompatibilitas beberapa tahun.
Ketika biaya draft turun, organisasi berisiko meng-merge lebih banyak hal daripada yang dapat dipelihara. Backlog tidak hilang; ia berpindah dari implementasi menuju review dan ownership. Kecepatan produksi kode harus dipasangkan dengan disiplin menghapus, menolak, atau membatasi scope.
- Siapa owner setelah merge?
- Kontrak publik apa yang berubah?
- Test serta monitoring apa yang dibutuhkan?
- Bagaimana fitur dihentikan atau di-rollback?
Gunakan agen untuk mem-pricing uncertainty
Daripada berdebat abstrak apakah permintaan kecil, berikan agen assignment terbatas: patch sekecil mungkin, di balik feature flag, tanpa mengubah public contract, dengan test, daftar file, dan risiko. Hasil yang bersih menunjukkan jalur mungkin sederhana; kegagalan menunjukkan kompleksitas sebelum tim berkomitmen.
Eksperimen harus disposable. Jangan menganggap patch agen layak merge hanya karena berjalan. Nilainya adalah informasi: dependensi apa tersentuh, test apa gagal, dan asumsi apa muncul. Engineer tetap menilai arsitektur, keamanan, produk, serta dampak operasi.
Review menjadi bottleneck baru
Agen dapat menghasilkan kode lebih cepat daripada manusia memahami perubahan. Review yang dangkal menciptakan illusion of velocity. Tim perlu batas ukuran PR, test otomatis, static analysis, provenance, dan penjelasan keputusan. Kode yang tidak dipahami tidak boleh menjadi tanggung jawab produksi.
Pisahkan review correctness, design, security, operability, dan product fit. Lulus test tidak berarti requirement benar. Minta agen menjelaskan constraint dan alternatif, tetapi verifikasi dengan source. Untuk perubahan berisiko, gunakan pair review serta canary.
- Batasi diff dan satu tujuan per PR.
- Minta test yang gagal sebelum fix bila memungkinkan.
- Periksa dependency serta generated code.
- Jangan auto-merge perubahan sensitif.
Kapan mengatakan ya, tidak, atau coba dulu
Katakan ya ketika masalah jelas, kontrak kecil, owner ada, dan rollback mudah. Katakan tidak ketika fitur menambah permukaan permanen tanpa nilai yang sepadan atau melanggar arah produk. Pilih coba dulu ketika implementasi dapat dibatasi dan hasil memberi informasi keputusan.
Feature flag bukan alasan menyimpan kode selamanya. Tetapkan tanggal evaluasi, metrik, dan removal path. Prototype di branch dapat dibuang. Semakin mudah agen mencoba, semakin penting definisi kapan eksperimen selesai dan siapa yang membersihkan.
Praktik untuk tim Indonesia
Mulai dari workflow berisiko rendah: test, dokumentasi, refactor kecil, atau reproduksi bug. Ukur cycle time, review time, defect, dan rollback. Jangan membeli keberhasilan berdasarkan jumlah baris. Dokumentasikan policy data serta repository yang boleh diakses agen.
TenFourSeven menyarankan memasukkan ownership cost dalam template proposal: maintenance, support, monitoring, migration, security, dan deletion. AI dapat membuat artefak untuk memperkirakan biaya tersebut. Engineer terbaik bukan yang menerima semua permintaan, melainkan yang cepat mengubah ketidakpastian menjadi evidence.
Praktik ini juga berlaku pada tim kecil yang belum memiliki platform engineering. Sebelum menerima patch agen, tulis definisi selesai yang mencakup dokumentasi, telemetry, batas biaya, kompatibilitas, dan penanggung jawab. Setelah rilis, bandingkan estimasi dengan waktu review, jumlah koreksi, tiket support, dan pekerjaan lanjutan. Jika fitur hanya memindahkan beban ke orang lain, kecepatan awal bukan penghematan. Retrospektif singkat setiap bulan dapat mengungkap jenis pekerjaan yang memang cocok dibantu agen serta jenis perubahan yang tetap memerlukan eksplorasi manusia lebih dulu. Dengan begitu, adopsi AI menjadi keputusan operasi yang terukur, bukan lomba menghasilkan commit.
AI mengubah biaya mencoba implementasi, bukan kewajiban memiliki software. Patch cepat tetap membawa review, maintenance, security, kontrak, dan support. Gunakan agen dalam assignment sempit untuk menguji uncertainty, lalu putuskan berdasarkan artefak serta ownership jangka panjang. Batasi diff, pertahankan feature flag dan rollback, ukur review time serta defect, dan berani membuang eksperimen. Kecepatan coding hanya bernilai bila sistem tetap dapat dipahami serta dipelihara. Ownership harus tetap eksplisit.