Kode selesai lebih cepat, tetapi rilis masih tertahan oleh review, regresi, dan perubahan yang menyentuh banyak modul. Coding velocity mengukur pembuatan kode; software delivery velocity mencakup kebutuhan bisnis sampai perubahan aman digunakan. Keduanya perlu diukur terpisah.
AI tetap berguna pada arsitektur yang belum rapi: arahkan ke dokumentasi, pengujian perilaku, dan pemetaan dependency pada modul dengan batas jelas. Validasi peta yang dihasilkan dengan developer yang memahami sistem. Untuk pembangunan modul baru, pilar BUILD Sagara menekankan fondasi yang mengikuti proses bisnis. Pembayaran debt pada sistem yang berjalan dibahas dalam risiko technical debt akibat AI coding.
Kecepatan Bergantung pada Tugas dan Konteks
Eksperimen Copilot tahun 2023 menemukan waktu penyelesaian 55,8% lebih singkat untuk tugas HTTP server JavaScript. Sebaliknya, METR pada 2025 menemukan 16 developer berpengalaman menyelesaikan 246 tugas pada repositori yang mereka kenal 19% lebih lama saat AI diizinkan. Setelah percobaan, mereka masih merasa 20% lebih cepat. Persepsi saja tidak cukup untuk keputusan investasi.
Pembaruan METR Februari 2026 melihat indikasi percepatan dengan alat baru, tetapi bias seleksi dan kendala pengukuran membatasi kesimpulannya. Uji manfaat dalam pekerjaan tim sendiri.
DORA 2025 menggambarkan AI sebagai penguat kekuatan dan kelemahan organisasi. Salah satu mekanismenya adalah konteks: pola kode menjadi contoh bagi AI, sementara alasan desain yang tidak tertulis tidak tersedia baginya. Paper METR membahas kurangnya pengetahuan implisit repositori sebagai faktor yang mungkin menjelaskan hasil studi.
Contoh: Menambah Notifikasi Pembayaran
Dalam ilustrasi ini, AI diminta menambah notifikasi status pembayaran. Tanpa batas modul, implementasinya membaca tabel Payment langsung dan menyalin aturan status. Fitur tampak bekerja, tetapi perubahan skema atau aturan Payment kini harus diikuti tim Notification.
Dengan kontrak jelas, Notification memakai API atau event yang disediakan Payment. Tim Payment tetap memiliki aturan transaksi. AI mendapat konteks tentang sumber status yang sah dan cara menangani retry.
Code debt berada pada implementasi lokal, seperti duplikasi fungsi. Architectural debt melintasi batas modul dan kepemilikan data. Merapikan fungsi tidak otomatis memperbaiki hubungan tersebut.
| Fondasi | Sinyal bahaya | Tindakan pada contoh pembayaran |
|---|---|---|
| Batas modul | Satu fitur kecil mengubah banyak modul | Tetapkan Payment sebagai pemilik status |
| Kepemilikan data | Tidak jelas siapa berwenang menulis | Larang Notification menulis tabel Payment |
| Kontrak | Integrasi dibuat tanpa spesifikasi | Dokumentasikan API/event dan versinya |
| Kebutuhan operasional | Retry dan logging disalin per fitur | Sediakan template, library, dan timeout standar |
Modularitas dapat diterapkan pada monolit; microservices bukan prasyarat. Desain berkembang bertahap, tetapi batas dan aturan yang sedang berlaku harus dapat ditemukan.
Beri AI Konteks dan Uji Batasnya
Catat alasan desain dalam ADR. Sertakan batas modul, pemilik data, konvensi, dan tautan ADR dalam file instruksi repositori yang didukung alat AI tim. Keputusan tentang akses tabel Payment tidak perlu ditebak dari kode.
Jalankan architecture test atau pemeriksaan dependency di CI untuk menolak impor dan akses lintas modul yang dilarang. Lengkapi dengan test kontrak, skenario timeout, retry, dan otorisasi. Template operasional membantu kode baru mewarisi standar yang sering tidak tertulis dalam prompt.
Batasi perubahan agar reviewer dapat menilainya. Standar minimal review tetap sama; pembuat PR bertanggung jawab dan harus mampu menjelaskan kode AI. Perubahan otorisasi serta transaksi memerlukan pemeriksaan sesuai risiko.
Periksa juga risiko khas AI: dependency yang disarankan harus benar-benar ada, berasal dari penerbit yang tepat, dan memiliki versi yang sesuai. Studi USENIX Security 2025 mendokumentasikan rekomendasi package fiktif dari model pembuat kode. Pemindaian keamanan tidak menggantikan pemeriksaan asal dependency.
Uji pada Satu Tim dan Satu Modul
Catat baseline sebelum memperluas AI. Bandingkan pekerjaan yang sebanding melalui metrik DORA: change lead time, change fail rate, deployment rework rate, serta waktu review dan defect setelah rilis. Catat perubahan ukuran tugas dan kapasitas tim agar perbandingan tidak menyesatkan.
Mulai dari modul Notification dengan kontrak Payment yang jelas. Perluas setelah manfaat delivery terbukti dan biaya pengerjaan ulang tidak meningkat. Jumlah baris kode atau PR bukan ukuran hasil bisnis.
FAQ
Haruskah arsitektur selesai dibenahi sebelum memakai AI?
Tidak. Pilih tugas terbatas yang dapat diverifikasi, dan perjelas batas modul yang disentuh. Risiko lintas sistem tetap memerlukan keputusan manusia.
Bagaimana mengetahui AI benar-benar mempercepat tim?
Bandingkan baseline sampai rilis, termasuk review dan rework, pada tugas yang sebanding. Pisahkan hasil terukur dari kesan developer.
Apakah AI menggantikan architect?
AI dapat membantu eksplorasi dan dokumentasi. Pemilik sistem tetap menentukan tradeoff, batas data, dan risiko operasional.
Siapkan Fondasi Modul Baru
Sagara Xinix – Solusi Teknologi Terintegrasi dan Terpercaya menyediakan perancangan sistem, pengembangan aplikasi, integrasi, dan CI/CD. Bawa satu modul yang akan dibangun, kontrak yang terdampak, serta baseline delivery untuk mendiskusikan fondasi pengembangannya bersama Sagara.