Menggunakan AI untuk mempercepat pengiriman perangkat lunak. Di mana AI bekerja dan di mana AI mengalami hambatan

AI coding tools dapat mempercepat pengiriman perangkat lunak, tetapi keuntungan tersebut tergantung sepenuhnya pada di mana dan bagaimana mereka digunakan. Bagi pemimpin teknik, CTO, dan tim produk, pertanyaan sebenarnya bukanlah apakah AI dapat menghasilkan kode. Pertanyaannya adalah di mana AI menciptakan nilai yang terukur, di mana ia menambah gesekan, dan bagaimana membangun kebijakan yang berfungsi sebelum utang tinjauan mulai menumpuk.

Di mana AI benar-benar membantu?

Angka-angka utama sangat mengesankan.
Dalam uji coba terkontrol GitHub Copilot, pengembang menyelesaikan tugas standar 55,8% lebih cepat. Dalam uji coba acak Google, insinyur sekitar 21% lebih cepat pada tugas perusahaan yang kompleks. Di seluruh eksperimen lapangan di Microsoft, Accenture, dan sebuah perusahaan Fortune 100, pengembang menyelesaikan 26% lebih banyak tugas dengan asisten pengkodean.

Tetapi ada sisi lain dari gambaran tersebut.
METR menemukan bahwa pengembang open-source berpengalaman yang bekerja pada repositori besar dan matang 19% lebih lambat dengan alat AI awal 2025. Mereka hanya menerima 44% dari kode yang dihasilkan AI dan menghabiskan 9% dari waktu mereka untuk meninjau atau membersihkannya.

Temuan ini tidak saling bertentangan. Mereka mencerminkan berbagai jenis pekerjaan.

AI berkinerja baik ketika tugasnya lokal, niatnya jelas, outputnya mudah diuji, dan biaya salahnya rendah. Ia menjadi kurang berguna ketika pekerjaan bergantung pada konteks arsitektural, pengetahuan mendalam tentang basis kode, atau ambang batas tinjauan yang tinggi. Dalam sistem yang matang, pengembang berpengalaman sering kehilangan waktu karena mereka harus memverifikasi, memperbaiki, dan menyesuaikan output yang tidak sepenuhnya cocok dengan konteks.

Kapan alat AI meningkatkan kecepatan pengiriman?

Kasus penggunaan terkuat adalah tugas dengan definisi selesai yang jelas dan dapat diuji:

• pembuatan tes dan perlengkapan
• dokumentasi dan penjelasan kode
• adaptor API dan boilerplate
• pemetaan data dan refaktor berulang
• perbaikan bug yang dimulai dari tes yang gagal

Penelitian juga menunjukkan bahwa alur kerja penting. Satu studi menemukan bahwa pengembang yang menggunakan pendekatan berbasis tes lebih mungkin untuk menilai kode yang dihasilkan AI dengan benar dan melaporkan beban kognitif yang lebih rendah. Studi lain menemukan bahwa memberikan model tes yang gagal bersamaan dengan prompt meningkatkan kualitas kode yang dihasilkan.

Tes memberi AI kontrak yang jelas. Itu membuat output lebih mudah diverifikasi dan mengurangi beban pada peninjau senior.

Desain prompt juga penting. Alih-alih meminta AI untuk menulis fungsi, lebih efektif untuk memberikan persyaratan, kasus tepi, dan tes yang gagal. Mintalah tambalan sekecil mungkin, asumsi yang dibuat, dan file yang terpengaruh. Ini menjaga output tetap sempit dan membuat tinjauan lebih mudah dikelola.

Biaya tersembunyi dari kode yang dihasilkan AI

Beban tinjauan adalah tempat banyak tim kepemimpinan salah menilai ekonomi. Jika pengembang menerima kurang dari setengah apa yang dihasilkan AI dan menghabiskan hampir sepersepuluh waktu mereka untuk membersihkannya, biaya itu nyata. Biasanya itu akan dibebankan pada insinyur yang paling berpengalaman.

Risiko keamanan membuat gambaran ini lebih serius. Satu studi besar menemukan rata-rata tingkat paket yang terhalusinasi setidaknya 5,2% untuk model komersial dan 21,7% untuk model open source. Studi lain dari 733 cuplikan yang dihasilkan AI menemukan kelemahan keamanan dalam 29,5% sampel Python dan 24,2% sampel JavaScript. Di fintech, pembayaran, dan lingkungan teratur lainnya, satu ketergantungan yang lemah atau jalur kode yang tidak aman dapat menghapus setiap peningkatan produktivitas yang tampak.

Penelitian DORA 2025 menambahkan peringatan yang lebih luas. Peningkatan 25% dalam adopsi AI dikaitkan dengan pengurangan 1,5% dalam throughput pengiriman dan pengurangan 7,2% dalam stabilitas pengiriman. AI sering berfungsi sebagai penguat. Sistem teknik yang kuat menjadi lebih efisien. Sistem yang lemah menjadi lebih bising dan sulit dikendalikan.

Bagaimana menghindari perangkap pemeliharaan?

Mengetik kode lebih cepat tidak sama dengan mengirimkan perubahan yang benar lebih cepat. Pertanyaan sebenarnya adalah apakah tim dapat memberikan perubahan yang benar lebih cepat setelah tinjauan, pengujian, pembersihan, dan pembatalan semuanya termasuk.

Itu mengarah pada model operasi praktis.

Pendekatan berbasis risiko untuk alokasi tugas

Bagi pekerjaan menjadi tiga zona dan terapkan secara konsisten.

Zona Hijau

AI dapat bekerja lebih bebas dalam tugas-tugas berisiko rendah seperti:

• tes
• dokumentasi
• adaptor
• boilerplate
• alat internal
• skrip pelaporan
• refaktor berisiko rendah

Zona Kuning

AI dapat membantu, tetapi hanya dengan tes yang kuat dan tinjauan manusia, di area seperti:

• logika bisnis bersama
• pekerjaan integrasi
• refaktor lintas modul

Zona Merah

AI harus dibatasi hanya untuk dukungan draf, dengan kepenulisan manusia yang diperlukan, di area seperti:

• alur pembayaran
• rekonsiliasi
• otorisasi
• penanganan rahasia
• kontrol kepatuhan
• kriptografi
• infrastruktur inti

Ini bukan peringatan teoritis. Dalam sistem teratur, ketergantungan yang terhalusinasi atau jalur otorisasi yang lemah menciptakan eksposur komersial dan hukum, bukan hanya utang teknis.

Mengukur apa yang benar-benar penting

Lacak alur pengiriman penuh, bukan hanya seberapa cepat kode muncul.

Metrik yang penting:

• waktu tunggu untuk perubahan
• waktu tinjauan per permintaan tarik
• tingkat pembukaan kembali
• tingkat kegagalan build
• tingkat pembatalan
• cacat yang lolos
• temuan keamanan per rilis

Volume kode dan kecepatan mengetik adalah sinyal yang lemah. Pengembang dapat merasa lebih cepat saat sistem yang lebih luas melambat. Peningkatan lokal tidak otomatis meningkatkan hasil pengiriman.

Jaga permintaan tarik tetap kecil. AI meningkatkan volume perubahan, dan itu hanya membantu jika sisa sistem dapat menyerapnya dengan aman. Batch kecil, CI yang kuat, pengujian otomatis, tinjauan manusia, dan pembatalan yang mudah menjadi lebih penting setelah adopsi AI.

Daftar periksa untuk mengimplementasikan alat pengkodean AI dengan aman

• Identifikasi tugas dalam backlog yang lokal, terdefinisi dengan baik, dan mudah untuk diuji

• Tulis atau konfirmasikan tes yang gagal sebelum menggunakan AI untuk menghasilkan perbaikan atau fitur

• Definisikan zona hijau, kuning, dan merah secara tertulis dan bagikan dengan tim

• Tetapkan batas ukuran permintaan tarik dan tegakkan melalui CI

• Ukur waktu tunggu, waktu tinjauan, dan tingkat pembatalan sebelum dan setelah adopsi

• Tugaskan seorang insinyur senior untuk meninjau output yang dihasilkan AI dalam pekerjaan zona kuning

• Audit ketergantungan yang dihasilkan AI sebelum menggabungkan, terutama di basis kode yang teratur

• Perlakukan setiap perubahan yang dihasilkan AI yang tidak dapat dijelaskan, diuji, dan dibatalkan sebagai tidak siap untuk produksi

Alat akan terus berkembang. Pada Februari 2026, METR mencatat bahwa alat-agentik baru kemungkinan lebih unggul dibandingkan versi awal 2025, meskipun ukuran peningkatan yang tepat sulit diukur. Angka-angkanya akan berubah. Prinsip manajemen tidak akan. Percayalah pada hasil yang terukur daripada demo atau klaim vendor.

AI bekerja paling baik sebagai pasangan junior yang cepat tetapi tidak merata. Berikan tugas yang terbatas, tekankan pada tes, jaga perubahan tetap kecil, dan jangan pernah membingungkan generasi draf dengan penilaian teknik.