Edisi Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Pemrograman dengan AI menjadikan pengiriman perangkat lunak yang andal sebagai tantangan rekayasa berikutnya

> Ketika AI meningkatkan jumlah keluaran kode, manajer rekayasa perlu melihat di mana perubahan tertahan, berapa biaya validasinya, dan apakah perangkat lunak yang dirilis berfungsi sebagaimana mestinya.

By BIG CHANGE Editorial

Published: 2026-09-22T05:31:05.772Z
Updated: 2026-09-22T05:31:05.772Z
Canonical: https://bigchange.ai/blog/ai-coding-ci-bottleneck-dependable-delivery

![A large stack of blank work cards waits on a conveyor before a magnifying-glass inspection station, with a smaller stack in the output tray.](https://bigchange.ai/api/media/file/validation-queue-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. More proposed changes can put pressure on validation. Conceptual illustration of a queue and inspection stage; stack sizes are not measurements, and passing checks does not guarantee dependable delivery.

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](https://linear.app/now/ci-bottleneck-reworked).

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](https://dora.dev/insights/balancing-ai-tensions/).

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](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/).

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](https://metr.org/blog/2026-02-24-uplift-update/).

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](https://docs.github.com/en/actions/concepts/workflows-and-actions/dependency-caching).

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.](/api/media/file/elapsed-aggregate-work-inline-v1.png)

## 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](https://vitest.dev/guide/recipes/disable-isolation).

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](https://linear.app/now/ci-bottleneck-reworked).

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](https://dora.dev/guides/dora-metrics/).

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.

## Sources

- [Linear: Pemrograman dengan AI dan hambatan CI](https://linear.app/now/ci-bottleneck-reworked) — 21 September 2026. Paparan penerapan oleh Mufeez Amjad memberikan angka pembuka dan contoh isolasi selektif. Pengukuran langsung ini menjelaskan sistem Linear, bukan estimasi terkontrol tentang produktivitas AI atau total pengeluaran.
- [DORA: Menyeimbangkan ketegangan AI](https://dora.dev/insights/balancing-ai-tensions/) — 10 Maret 2026. Memisahkan kaitan dalam DORA 2025 dari analisis kualitatif jawaban para insinyur Google. Studi internal ini melaporkan pengalaman, bukan dampak kausal terukur; pertanyaan sebelumnya mungkin memengaruhi jawaban.
- [METR: AI awal 2025 dan produktivitas pengembang berpengalaman](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) — 10 Juli 2025. Eksperimen acak yang melibatkan repositori sumber terbuka yang dikenal dan alat AI awal 2025. Mendukung temuan perlambatan dalam cakupan terbatas dan perbedaan persepsi. Ini bukan estimasi bagi semua pengembang atau model September 2026.
- [METR: Mengubah eksperimen produktivitas pengembang](https://metr.org/blog/2026-02-24-uplift-update/) — Pembaruan 24 Februari 2026. Menjelaskan pemilihan peserta dan tugas, perubahan kompensasi, serta masalah mengukur pekerjaan serentak. Para peneliti menilai estimasi baru tidak andal; kami tidak menyajikan angka mentahnya sebagai percepatan terkini.
- [GitHub: Caching dependensi](https://docs.github.com/en/actions/concepts/workflows-and-actions/dependency-caching) — Dokumentasi terkini diakses pada 22 September 2026. Menjelaskan penggunaan ulang pada runner bersih dan keharusan agar pekerjaan tetap berjalan tanpa cache. Dokumentasi ini tidak menetapkan kinerja atau tagihan repositori tertentu.
- [Vitest: Pengaturan isolasi per berkas](https://vitest.dev/guide/recipes/disable-isolation) — Dokumentasi terkini diakses pada 22 September 2026. Menjelaskan isolasi bawaan, konfigurasi selektif, dan dependensi status yang perlu dilindungi. Panduan teknis ini mendukung analisis kompromi; BIG CHANGE tidak menjalankan tolok ukur atau mengubah rangkaian pengujian.
- [DORA: Metrik kinerja pengiriman perangkat lunak](https://dora.dev/guides/dora-metrics/) — Diperbarui 5 Januari 2026. Mendefinisikan lima metrik pengiriman dan penerapannya pada tingkat layanan. Metrik ini mengukur hasil di luar durasi CI; contoh diagnostik dalam artikel merupakan analisis, bukan hasil eksperimen baru.