Tim teknik Agoda menghabiskan banyak waktu untuk mempromosikan alat coding AI, lalu melakukan evaluasi. Kesimpulannya cukup meresahkan:
Produktivitas pengembang individu meningkat, tetapi kecepatan pengiriman proyek secara keseluruhan hampir tidak bergerak.
Ini bukan hanya masalah Agoda. Faros AI mengumpulkan data dari berbagai perusahaan dan menyajikan serangkaian angka yang mencolok:
Tim dengan adopsi AI tinggi mengalami peningkatan volume penggabungan PR sebesar 98% dan penyelesaian tugas sebesar 21%. Namun pada saat yang sama, waktu tinjauan PR meningkat sebesar 91%.
Lebih banyak keluaran, tetapi Review lebih lambat. Kedua efek ini hampir saling meniadakan.
Apa Hambatan Sebenarnya
Tim teknik Agoda menyimpulkan bahwa masalahnya terletak pada kenyataan bahwa "coding tidak pernah menjadi hambatan utama dalam pengiriman perangkat lunak."
Pelengkapan otomatis AI membuat penulisan kode lebih cepat. Tetapi menulis kode hanyalah satu langkah dalam jalur produksi. Sebelumnya ada analisis kebutuhan, desain sistem, dan penyelarasan teknis. Setelahnya ada Review Kode, pengujian, integrasi, dan penerapan.
Meningkatkan kecepatan langkah tengah tiga kali lipat tidak berarti seluruh jalur produksi menjadi tiga kali lebih cepat.
Ketika AI menyebabkan lonjakan keluaran kode, kemampuan untuk "mencerna kode tersebut" justru menjadi titik hambatan baru:
- Setiap PR berisi lebih banyak kode (kode yang dihasilkan AI seringkali kurang ringkas)
- Review Kode memiliki lebih banyak hal untuk diperiksa
- Tapi waktu insinyur senior terbatas
Hambatan telah bergeser dari "lambat menulis kode" menjadi "lambat meninjau kode," dan kecepatan pengiriman aktual tidak membaik.
Masalah yang Lebih Dalam: Spesifikasi
Insinyur Agoda, Leonardo Stern, melangkah lebih jauh dengan berargumen bahwa sumber daya yang benar-benar langka telah bergeser ke atas: bukan Review, melainkan Spesifikasi—kemampuan untuk menerjemahkan kebutuhan bisnis yang samar menjadi spesifikasi teknis yang jelas dan dapat dijalankan.
Sebelumnya, insinyur menghabiskan banyak waktu untuk menulis kode, sehingga spesifikasi bisa agak kabur karena "akan menjadi jelas saat menulis."
Sekarang, jika Anda memberikan kebutuhan yang samar kepada AI, AI akan menghasilkan kode yang "terlihat bisa digunakan" tetapi melenceng arahnya. Kemudian Anda kembali merevisi spesifikasi, AI menghasilkan ulang, dan Anda mengulangi siklus ini. Di permukaan, keluaran kode tinggi, tetapi pada kenyataannya, Anda melakukan trial-and-error dengan kode, dan efisiensinya rendah.
Spesifikasi kebutuhan dengan ketelitian tinggi sedang menjadi hasil rekayasa inti. Bukan kode itu sendiri, tetapi "bagaimana mendeskripsikan apa yang diinginkan."
Pendekatan "Kotak Abu-abu" Stern
Stern mengusulkan metode kerja yang disebut "Kotak Abu-abu," yang berada di antara dua ekstrem:
- Kotak Putih: Tinjau setiap baris kode yang dihasilkan AI; Anda bertanggung jawab penuh atas detail implementasi
- Kotak Hitam: Terapkan kode yang ditulis AI secara langsung; Anda bertanggung jawab atas hasil tetapi tidak atas prosesnya
- Kotak Abu-abu: Intervensi pada dua titik kunci—menulis spesifikasi yang tepat dan memverifikasi hasil terhadap spesifikasi tersebut
Logika inti Kotak Abu-abu adalah: Anda tidak perlu memahami metode apa yang digunakan AI untuk memecahkan masalah, tetapi Anda harus dapat menyatakan dengan jelas "apa yang dianggap sebagai solusi" dan memverifikasi bahwa masalah tersebut memang terpecahkan.
Inti dari metode ini adalah memfokuskan waktu dan perhatian insinyur pada bagian yang paling tidak dikuasai AI—mendefinisikan maksud dan memverifikasi hasil—bukan pada detail implementasi.
Ke Mana Arah Peran Insinyur
Asumsi peran insinyur perangkat lunak tradisional menyatakan bahwa "menulis kode yang baik" adalah kompetensi inti.
Sekarang asumsi itu mulai goyah. Ketika AI dapat menulis kode yang berkualitas memadai, dari mana datangnya kelangkaan insinyur?
Berdasarkan praktik di perusahaan seperti Agoda, jawabannya bergerak ke arah ini:
- Orang yang dapat menerjemahkan masalah bisnis menjadi spesifikasi teknis yang tepat
- Orang yang dapat merancang rencana verifikasi yang efektif
- Orang yang dapat menilai apakah kode yang dihasilkan AI benar-benar memecahkan masalah yang tepat
Ini tidak berarti "kemampuan menulis kode tidak lagi penting"—melainkan kemampuan menulis kode telah bergeser dari sumber daya langka menjadi persyaratan dasar, dengan diferensiasi sejati terjadi di hulu yang lebih tinggi.
Dalam kata-kata Stern: Otoritas manusia sedang bermigrasi dari "menulis kode" ke "mendefinisikan maksud." Ini adalah pergeseran ke atas dalam tingkat abstraksi, bukan hilangnya keterampilan.
Bagaimana Manajemen Harus Melihat Hal Ini
Bagi manajer teknik, penelitian Agoda memberikan saran tindakan langsung: Jangan mengukur nilai AI berdasarkan keluaran kode.
Jumlah PR, baris kode, dan penyelesaian tugas semuanya akan terlihat lebih baik berkat alat AI. Tetapi jika fitur yang dikirimkan tidak bertambah, tidak lebih cepat, dan kualitasnya tidak membaik, angka-angka ini hanyalah angka.
Metrik yang benar-benar layak dilacak adalah: siklus peluncuran fitur, tingkat cacat produksi, dan waktu ujung-ke-ujung dari kebutuhan hingga pengiriman. Angka-angka ini memberi tahu Anda apakah AI benar-benar membantu tim, atau hanya membantu tim menggembungkan data di GitHub.
Lain kali seseorang melaporkan volume penggabungan PR sebagai ROI alat AI, Anda dapat bertanya: Lalu bagaimana dengan waktu Review?
Sumber: CocoLoop, AI Coding Assistants Haven't Sped Up Delivery Because Coding Was Never the Bottleneck (InfoQ)