Agen pemrograman AI dapat menyelesaikan patch ketika pemeriksaan atas patch sebelumnya masih berjalan. Bagi manajer rekayasa, hal ini menimbulkan pembedaan yang janggal: tim telah menghasilkan lebih banyak kode, tetapi pelanggan belum menerima apa pun.

Linear memberikan contoh yang berguna. Dalam paparan rekayasa pada 21 September, Mufeez Amjad melaporkan bahwa jumlah rangkaian pengujiannya hampir empat kali lipat sejak awal 2026, sementara waktu tunggu pull request untuk continuous integration turun dari lebih dari enam menit menjadi sedikit di atas lima menit. Waktu runner per pengujian kira-kira berkurang separuh. Itu merupakan perbaikan yang terpisah; angka terakhir tidak berarti total tagihan CI ikut berkurang separuh. Linear mengaitkan meningkatnya tekanan pada validasi dengan pengembangan yang dibantu agen, tetapi paparannya bukan eksperimen terkontrol yang membuktikan dampak AI terhadap produktivitas. Paparan rekayasa Linear.

Continuous integration, atau CI, menjalankan pemeriksaan otomatis atas perubahan perangkat lunak yang diusulkan. CI berada di antara patch yang tampak masuk akal dan perubahan yang siap diterima tim. Ketika pemrograman dengan AI meningkatkan pasokan patch, kapasitas pemeriksaan menjadi urusan bisnis: berapa banyak pekerjaan berguna yang dapat diserap organisasi dengan aman?

Menurut kami, manajer perlu melihat tiga hasil secara bersamaan: waktu untuk memperoleh umpan balik yang dapat dipercaya, total komputasi yang digunakan, dan keandalan perubahan yang dirilis. Jawaban yang lebih cepat hanya berguna jika tim memahami apa yang dibuktikannya.

Waktu tunggu yang lebih singkat bisa memerlukan pekerjaan lebih banyak

Bayangkan rangkaian pengujian yang membutuhkan dua belas menit di satu mesin. Jika pekerjaan dibagi rata ke empat mesin, proses itu dapat selesai dalam tiga menit. Ini contoh hipotetis yang mengandaikan pembagian sempurna dan mengabaikan faktor lainnya. Total pekerjaan yang dijalankan mesin tetap dua belas menit.

Sekarang, tambahkan satu menit persiapan untuk setiap mesin. Versi empat mesin selesai dalam empat menit dan memakai total enam belas menit-runner. Versi satu mesin selesai dalam tiga belas menit dan memakai tiga belas menit-runner. Waktu tunggu membaik tajam, sementara total penggunaan mesin meningkat. Biaya sebenarnya juga bergantung pada jenis runner, harga, dan aturan penagihan.

Pembedaan ini penting ketika dasbor merayakan batang hijau yang lebih pendek. Manajer yang membeli kapasitas paralel sedang membeli umpan balik lebih dini, mungkin dengan biaya tambahan. Itu bisa menjadi kompromi yang sangat baik jika menghilangkan kendala nyata. Manfaatnya lebih sulit dibenarkan jika perubahan yang sudah selesai kemudian menunggu berjam-jam untuk ditinjau.

Unit analisis perlu mencakup lebih dari satu proses CI. Patch yang memicu revisi berulang, pengujian ulang, dan putaran peninjauan kedua dapat menyerap jauh lebih banyak pekerjaan daripada yang terlihat dari proses tercepatnya saja. Hitung upaya yang dibutuhkan sampai perubahan diterima, termasuk upaya yang ditinggalkan. Jika tidak, alur kerja yang tampak efisien dapat menyembunyikan proses pengembangan yang mahal.

Selain itu, setiap menit tunggu tidak selalu setara dengan biaya tenaga kerja. Pengembang yang memulai tugas berguna lainnya selama pemeriksaan berjalan belum tentu kehilangan seluruh waktu itu. Gangguan berulang dan keharusan kembali ke pekerjaan yang belum selesai tetap dapat merugikan. Untuk mengukurnya, amati cara tim bekerja; jangan sekadar mengalikan menit yang berlalu dengan gaji.

Riset menunjukkan gambaran yang beragam

Analisis DORA pada Maret 2026 melaporkan dua kumpulan bukti yang berbeda. Risetnya pada 2025 mengaitkan adopsi AI yang lebih tinggi dengan peningkatan throughput pengiriman perangkat lunak sekaligus ketidakstabilan yang lebih besar. Secara terpisah, para peneliti menganalisis 1.110 jawaban terbuka dari para insinyur Google yang dikumpulkan pada kuartal ketiga 2025. Para insinyur menggambarkan bantuan untuk menyusun draf dan tugas lain, sekaligus beban verifikasi. Studi kualitatif internal itu bukan populasi yang mendasari kaitan DORA yang lebih luas, dan tidak satu pun membuktikan bahwa AI menyebabkan masalah rilis pada tim tertentu. Analisis dan metodologi DORA.

Ada pula bukti eksperimental yang lebih kuat dengan cakupan lebih sempit. Uji acak METR pada Juli 2025 membagikan 246 tugas kepada 16 pengembang sumber terbuka berpengalaman yang bekerja di repositori yang sudah mereka kenal. Dengan alat AI awal 2025 diizinkan, penyelesaian tugas memakan waktu 19% lebih lama. Meski demikian, para peserta berpendapat bahwa AI membantu mereka bekerja lebih cepat. Temuan itu berlaku bagi para pengembang, tugas, dan alat tersebut; hasilnya tidak dapat menentukan manfaat setiap agen pemrograman yang tersedia saat ini. Eksperimen asli METR.

Pada Februari 2026, METR menyatakan bahwa tindak lanjutnya menghasilkan estimasi dampak produktivitas saat ini yang tidak andal. Para pengembang semakin sering menolak pekerjaan tanpa AI atau memilih tugas yang akan diajukan; agen yang berjalan bersamaan juga mempersulit pengukuran waktu. Para peneliti menganggap percepatan yang lebih besar masuk akal, tetapi menyatakan bahwa data hanya memberi bukti lemah tentang besarnya. Mengulang angka perlambatan lama tanpa kualifikasi ini akan menyesatkan pembaca. Tindak lanjut METR.

Bagi manajer, studi-studi ini mendukung pendekatan praktis: pertahankan alat yang berguna, selidiki dampaknya, dan jangan mengubah antusiasme maupun skeptisisme menjadi rumus kepegawaian universal. Tim dapat memperoleh manfaat besar untuk satu jenis pekerjaan dan kehilangan waktu pada pekerjaan lain. Proses pengirimannya perlu memperlihatkan perbedaan itu.

Berikan solusi yang tepat untuk setiap kendala

Sebelum membeli kapasitas CI tambahan, petakan satu perubahan dari patch usulan pertama hingga masuk produksi. Pisahkan pekerjaan yang sedang berjalan dari yang menunggu. Kenali pemeriksaan yang benar-benar menunda keputusan, peninjau yang perlu mencurahkan perhatian, dan syarat rilis yang tetap berlaku setelahnya.

Catatan waktu sederhana sering kali cukup untuk mengungkap investasi yang keliru. Jika sebagian besar keterlambatan terjadi sebelum peninjauan dimulai, memangkas beberapa detik dari pengujian tidak akan menyelesaikannya. Jika peninjau berulang kali menunggu pemeriksaan wajib yang lama, memperbaiki pemeriksaan itu punya tujuan langsung. Jika kegagalan terutama muncul setelah penerapan, tim perlu menelaah hal yang luput dari validasi.

Caching dependensi menunjukkan mengapa optimasi yang sudah dikenal tetap perlu diukur. GitHub menjelaskan bahwa caching dapat menggunakan kembali berkas yang mahal dibuat ulang pada runner yang bersih. GitHub juga menyatakan bahwa pekerjaan harus dapat membuat ulang atau mengunduh berkas tersebut jika cache tidak tersedia. Karena itu, perilaku cache perlu dinilai saat cache tersedia maupun tidak. Dokumentasi caching dependensi GitHub.

Bagi manajer, pertanyaan bergunanya adalah seberapa konsisten umpan balik dapat diperoleh. Rata-rata yang sangat baik masih dapat menyembunyikan waktu tunggu sesekali yang cukup lama hingga mengganggu rilis. Lacak bagian distribusi yang paling lambat dan bedakan kegagalan pengujian yang nyata dari unduhan yang gagal atau runner yang kehabisan sumber daya. Masing-masing memerlukan tanggapan berbeda.

Umpan balik yang andal dan cepat memberi manusia maupun agen kesempatan lebih awal untuk memperbaiki kesalahan. Infrastruktur bersama yang ditingkatkan dapat bermanfaat bagi berbagai jenis pekerjaan pengembangan, termasuk perubahan yang ditulis tanpa AI. Karena itu, manajer punya alasan untuk mendanainya meski pilihan alat pemrograman mereka berubah.

One large stopwatch beside a task card contrasts with three separate worker trays, each with its own small clock.
AI-generated conceptual illustration by BIG CHANGE. Left: elapsed time waiting for a run. Right: machine work accumulated across its workers. Parallel checks can shorten the wait without reducing total work. Clock positions, sizes and worker counts are schematic, not measured times or a cost ratio.

Pengujian yang lebih cepat tetap harus menemukan kesalahan

Beberapa perubahan kinerja mengubah kondisi saat pengujian berjalan. Hal ini perlu dicermati lebih saksama daripada sekadar prosesor yang lebih cepat.

Vitest, alat pengujian JavaScript dan TypeScript, secara bawaan mengisolasi setiap berkas pengujian agar status satu berkas tidak memengaruhi berkas lainnya. Dokumentasinya menjelaskan bahwa isolasi dapat dihapus secara selektif untuk pengujian yang sesuai, sekaligus menyebut status modul yang berubah-ubah, global yang dimodifikasi, dan dependensi lain sebagai alasan untuk mempertahankannya. Jadi, pengaturan yang memangkas waktu persiapan dapat mengubah batas kebenaran. Panduan isolasi Vitest.

Linear memilih pendekatan ikut serta untuk status bersama, menambahkan pembersihan, dan mempertahankan isolasi bagi berkas yang tidak dapat dipindahkan dengan aman. Peningkatan kinerjanya bergantung pada penentuan pengujian mana yang dapat berbagi lingkungan dengan aman. Penerapan oleh Linear.

Tantangan terpisah muncul ketika agen menulis perubahan sekaligus pengujiannya. Bayangkan aturan diskon hipotetis yang hanya berlaku untuk langganan tahunan. Agen dapat keliru menerapkannya juga pada paket bulanan, lalu menulis pengujian yang mengonfirmasi tafsirnya sendiri. Kelulusan pengujian tersebut hanya membuktikan konsistensi dengan kekeliruan itu.

Peninjau memerlukan bukti yang bersumber dari luar implementasi tersebut: persyaratan yang disepakati, contoh perilaku yang dimaksud, dan kasus yang seharusnya gagal. Meminta agen membuat lebih banyak pengujian dapat membantu, tetapi jumlah pengujian yang lebih besar saja tidak menunjukkan bahwa kesalahpahaman terhadap persyaratan sudah diuji. Manusia tetap bertanggung jawab memutuskan apa yang seharusnya dilakukan perangkat lunak dan apakah buktinya menjawab pertanyaan itu.

Tim yang menghargai banyaknya pengujian tanpa menelaah apa yang dibuktikan pengujian berisiko memberi peninjau lebih banyak materi sekaligus lebih sedikit keyakinan. Saat membagi pekerjaan, manajer perlu menyediakan waktu untuk penelaahan tersebut, alih-alih menganggapnya sebagai keterlambatan tanpa alasan setelah agen selesai.

Ukur perubahan yang sampai kepada pelanggan

Metrik pengiriman DORA menawarkan pemeriksaan lanjutan yang berguna. Metrik ini mencakup waktu dari kode yang di-commit hingga masuk produksi, frekuensi penerapan, pemulihan setelah penerapan yang gagal, proporsi penerapan yang memerlukan intervensi segera, dan proporsi yang berupa pengerjaan ulang tak terencana akibat insiden. Metrik-metrik ini menggambarkan hasil pengiriman di luar satu rangkaian pengujian yang lulus. Definisi metrik DORA.

Bagi tim yang menyelidiki alur kerja pemrograman AI mereka, kami akan memasangkan hasil-hasil tersebut dengan catatan diagnostik singkat:

  • Umpan balik: waktu yang berlalu hingga pemeriksaan wajib selesai, termasuk proses lambat dan waktu tunggu kapasitas.
  • Konsumsi: total pekerjaan runner dan upaya berulang yang terkait dengan perubahan yang diterima.
  • Peninjauan: waktu menunggu perhatian, permintaan revisi besar, dan alasan tiap revisi.
  • Dampak pada pelanggan: apakah perubahan yang dirilis menghasilkan perilaku yang dimaksud dan memerlukan pekerjaan korektif.

Gunakan catatan itu untuk menyelidiki alur kerja tertentu. Penyuntingan dokumentasi kecil dan migrasi basis data bukan satuan produktivitas yang dapat disamakan. Jika memungkinkan, bandingkan pekerjaan serupa dari waktu ke waktu dan catat perubahan lain, seperti penyedia runner baru atau proses rilis yang diperbarui. Perbaikan yang terjadi bersamaan dengan adopsi AI tidak membuktikan penyebabnya.

Dengan begitu, manajer dapat membuat pilihan konkret: danai kendala yang menghalangi perubahan bermanfaat sampai kepada pelanggan dengan tingkat keyakinan memadai. Kadang solusinya adalah kapasitas komputasi tambahan. Di waktu lain, yang dibutuhkan adalah persyaratan lebih jelas, pengujian lebih baik, atau waktu peninjauan yang cukup dari tenaga berpengalaman untuk memahami usulan yang sudah masuk.