DORA AI-Assisted Development: Throughput Naik, Instability Naik

Pertanyaan yang terus muncul di perencanaan Q4 kira-kira begini: kalau agent bisa membuka pull request sepanjang hari, apakah pipeline tinggal dibuka saja untuk mereka? Jawaban umumnya mengutip DORA, dan kutipannya biasanya satu kalimat bahwa AI membuat tim lebih cepat. Kalimat itu tidak lengkap, dan separuh yang hilang adalah bagian yang harus dibayar platform team.

Post ini membaca halaman DORA sendiri dan dua ulasan InfoQ secara dekat, memisahkan apa yang benar-benar diukur tiap laporan, lalu mengubah temuannya menjadi query metrik, CI gate, dan checklist hari Senin. Saya belum menjalankan studi gaya DORA pada fleet agent sendiri. Semua angka di bawah berasal dari sumber yang saya baca, sedangkan SQL dan workflow adalah sketsa saya dan diberi label begitu.

Laporan mana yang mengatakan apa

Kebanyakan tulisan tentang temuan DORA 2026 mencampur tiga dokumen berbeda. Hasil throughput dan instability berasal dari survei State of AI-assisted Software Development 2025. Materi 2026 dibangun di atasnya, jadi ketiganya perlu dipisahkan sebelum mengutip apa pun.

Satu catatan berlaku untuk semuanya. Sampel Balancing AI tensions hanya engineer Google, dan DORA sendiri mencatat responden mungkin terpancing membahas code generation oleh pertanyaan survei sebelumnya. Anggap ini pengamatan dekat pada satu lingkungan, bukan sensus.

Arti throughput dan instability menurut DORA

DORA mengelompokkan lima metrik software delivery ke dalam dua keluarga. Pasangan ini penting karena temuan utamanya adalah AI menggerakkan kedua keluarga ke arah yang sama, yang berbeda dari hasil tahun sebelumnya.

Perhatikan apa yang pertama kali digelembungkan oleh fleet agent. Deployment frequency dan lead time adalah angka yang paling mudah diperbaiki dengan otomasi, dan keduanya ada di keluarga throughput. Dua metrik instability baru bergerak ketika sesuatu sampai ke production dan rusak, sehingga dashboard yang hanya memakai keluarga pertama bisa tampak sangat bagus sementara yang kedua diam-diam memburuk.

Temuannya: throughput naik dan instability juga naik

Ringkasan Google atas laporan 2025 menyebut adopsi AI di kalangan profesional software mencapai 90%, naik 14% dari tahun sebelumnya, dan lebih dari 80% responden mengatakan AI meningkatkan produktivitas mereka. Ringkasan itu juga menyebut adopsi AI kini terkait software delivery throughput yang lebih tinggi, yang disebutnya pembalikan dari temuan tahun sebelumnya.

Liputan InfoQ atas laporan yang sama menambahkan separuh lainnya: software delivery instability terus naik. Para peneliti juga menguji apakah kecepatan AI bisa mengimbangi instability lewat gagal cepat dan perbaikan cepat, dan tidak menemukan manfaat dari itu. Recovery yang cepat tidak menghapus kegagalan tambahan.

InfoQ juga melaporkan hasil yang lebih senyap dan layak dibaca dua kali oleh platform team: internal platform berkualitas tinggi berkorelasi dengan sedikit kenaikan instability, yang oleh peneliti disebut risk compensation. Pembacaan saya, dan ini hanya pembacaan, adalah pipeline yang terasa lebih aman mengundang perubahan yang lebih besar atau lebih berisiko. Artinya agent di balik platform yang bagus justru alasan untuk menambah guardrail, bukan argumen untuk menolaknya.

Dari mana instability berasal

Artikel Balancing AI tensions menyebut tiga tensi. Yang pertama adalah verification tax: artikel mengutip laporan 2025 bahwa 30% developer melaporkan sedikit atau tidak ada kepercayaan pada kode hasil AI, dan menyebut waktu yang dihemat saat menulis kode dihabiskan lagi untuk verifikasi dan prompting. Ringkasan Google sendiri menaruh sisi sebaliknya di angka 24% yang melaporkan kepercayaan besar atau cukup besar.

Kalimat paling tajam di artikel itu adalah bahwa verifikasi pada dasarnya tugas kognitif yang berbeda dari menciptakan. Reviewer yang sekadar memindai diff yang tampak masuk akal adalah mekanisme bagaimana bug halus, technical debt, dan dokumentasi kosong sampai ke production, yang oleh penulis ditandai sebagai risiko jangka pendek yang diperkirakan mengecil seiring tool yang matang.

Dua tensi lainnya adalah expertise paradox, ketika AI menurunkan hambatan masuk tetapi bisa melewati productive struggle, dan workflow gap, ketika prototype datang cepat tetapi integrasi production dengan sistem internal dan edge case bisa lebih lama daripada menulis kodenya manual. Artikel mengaitkan gap itu dengan AI yang sejauh ini lebih banyak melayani pekerjaan inner-loop, dan memperkirakan gap menyempit ketika agent menjangkau workflow outer-loop seperti CI/CD.

J-curve dan instability tax

Laporan ROI 2026 adalah tempat sisi biaya diberi harga. Menurut ringkasan InfoQ, kebanyakan organisasi sebaiknya mengharapkan penurunan produktivitas sementara sebelum keuntungan jangka panjang, akibat kurva belajar, verification tax, dan kebutuhan menyesuaikan testing serta change approval dengan volume kode yang lebih tinggi. Laporan menyebutnya tuition cost of transformation, dan memperingatkan bahwa pemimpin yang menganggap penurunan itu kegagalan berisiko menarik pendanaan sebelum hasilnya tiba.

Kalkulator contohnya mengubah instability menjadi uang. InfoQ melaporkan bahwa contoh itu mengasumsikan change failure rate naik dari 5% ke 6% setelah adopsi, yang menghasilkan dampak downtime negatif sebesar $344,000. Penulis menyajikannya sebagai alasan untuk berinvestasi pada automated testing, continuous integration, dan small batch, bukan alasan menunda adopsi.

Ada dua peringatan. Laporan sendiri menyebut perhitungannya estimasi berketidakpastian tinggi yang dimaksudkan memancing diskusi, jadi $344,000 adalah ilustrasi metode, bukan prakiraan untuk perusahaan Anda. Dan sisi produktivitasnya tidak merata: InfoQ mengutip temuan Stanford berupa kenaikan 35 sampai 40% pada tugas greenfield sederhana tetapi sering 10% atau kurang pada kode legacy yang kompleks, yang justru tempat kebanyakan platform team bekerja.

Ukur sendiri sebelum menambah agent

Definisi DORA baru berguna kalau bisa dipecah per penulis. Query di bawah mengasumsikan tabel deployments, yang bisa dibangun kebanyakan tim dari riwayat CD tool, dan kolom author_kind yang diisi dari label pull request. Bentuk query-nya buatan saya; lima definisi metriknya adalah yang ada di tabel di atas.

-- Wrong: this is the number an AI rollout makes look wonderful, and it
-- says nothing about whether the changes held.
SELECT date_trunc('week', deployed_at) AS week, count(*) AS deployments
FROM deployments
GROUP BY 1 ORDER BY 1;

-- Right: the five DORA software delivery metrics, split by who authored
-- the change. Assumes one row per production deployment:
--   committed_at, deployed_at   timestamptz
--   author_kind                 'human' | 'agent' (set from a PR label)
--   needs_intervention          bool  (rollback, hotfix or manual fix)
--   is_rework                   bool  (unplanned deploy caused by an incident)
--   recovered_at                timestamptz, null when the deploy was fine
SELECT
  date_trunc('week', deployed_at)                         AS week,
  author_kind,
  count(*)                                                AS deployment_frequency,
  percentile_cont(0.5) WITHIN GROUP
    (ORDER BY deployed_at - committed_at)                 AS median_change_lead_time,
  percentile_cont(0.5) WITHIN GROUP
    (ORDER BY recovered_at - deployed_at)
    FILTER (WHERE needs_intervention)                     AS median_failed_deploy_recovery,
  round(100.0 * count(*) FILTER (WHERE needs_intervention)
        / count(*), 1)                                    AS change_fail_rate_pct,
  round(100.0 * count(*) FILTER (WHERE is_rework)
        / count(*), 1)                                    AS deployment_rework_rate_pct
FROM deployments
WHERE deployed_at >= now() - interval '90 days'
GROUP BY 1, 2
ORDER BY 1, 2;

Jalankan dulu untuk baseline human-only, lalu jalankan ulang setelah agent diaktifkan di satu repository. Kalau deployment frequency naik dan change fail rate atau rework rate ikut naik, Anda sudah mereproduksi temuan DORA secara lokal dan tahu tuas mana yang ditarik. Kalau hanya kolom throughput yang bergerak, itulah hasil baik yang digambarkan kerangka amplifier.

Guardrail di CI, dan harganya

Saran DORA untuk bekerja dengan small batch agar perubahan hasil AI tetap bisa direview dan diuji bisa ditegakkan secara mekanis. Workflow ini menolak pull request berlabel agent yang melebihi batas changed line. Angka 400 baris adalah titik awal sembarang dari saya, dipilih agar bisa direview dalam satu sesi, dan tidak ada di materi DORA yang mendukung angka persisnya.

# .github/workflows/agent-batch-gate.yml
# Keeps agent-authored changes small enough for a human to verify.
# The 400-line ceiling is MY starting policy, not a DORA number: tune it
# against your own change fail rate.
name: agent-batch-gate
on:
  pull_request:
    types: [opened, synchronize, labeled]

jobs:
  size:
    if: contains(github.event.pull_request.labels.*.name, 'agent-authored')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0   # the three-dot diff needs the merge base
      - name: Fail when an agent PR is too big to review
        env:
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
          MAX_CHANGED_LINES: "400"
        run: |
          CHANGED=$(git diff --numstat "$BASE_SHA"...HEAD \
            | awk '{ s += $1 + $2 } END { print s + 0 }')
          echo "changed lines: $CHANGED (limit $MAX_CHANGED_LINES)"
          if [ "$CHANGED" -gt "$MAX_CHANGED_LINES" ]; then
            echo "::error::Split this change. Small batches stay verifiable."
            exit 1
          fi

Trade-off-nya nyata. Batas keras mendorong agent memecah pekerjaan menjadi banyak pull request kecil, yang menaikkan jumlah review dan waktu antrean, yaitu beban verifikasi yang digambarkan tensi pertama. Gate yang menurunkan instability tetapi menggandakan interupsi reviewer hanya memindahkan biayanya, jadi pantau median change lead time setelah gate diaktifkan.

Batas kedua: label penanda pekerjaan agent hanya sejujur orang yang memasangnya. Kalau agent membuka pull request lewat akun bot bersama, tandai berdasarkan identitas itu dan jangan mengandalkan label manual, atau pemisahan di SQL di atas akan diam-diam mencampur kedua populasi.

Yang dilakukan hari Senin

Mulai dari pengukuran, karena semua keputusan lain bergantung pada baseline yang belum Anda punya.

1. Ambil deployment 90 hari terakhir dan hitung kelima metrik DORA hanya untuk perubahan buatan manusia. Simpan sebagai baseline.
2. Tambahkan penanda agent-authored pada pull request, sebaiknya dari identitas bot, dan pecah dashboard menurut author_kind.
3. Aktifkan batch-size gate di satu repository dalam mode warning dulu, lalu tegakkan setelah reviewer sepakat batasnya masuk akal.
4. Ganti tile dashboard yang menampilkan lines atau suggestions yang diterima dengan change fail rate, deployment rework rate, dan review turnaround.
5. Beri tahu pimpinan untuk mengharapkan penurunan. Tuliskan J-curve sebelum rollout pertama supaya kuartal yang lambat tidak dibaca sebagai kegagalan.

Baca ulang hasil pemisahan setelah satu bulan penuh. Rework rate yang naik dengan lead time yang datar menunjukkan test Anda yang jadi bottleneck, bukan agent-nya.

Aturan yang saya ambil dari DORA: kenaikan throughput bukan bukti pipeline yang sehat. Adopsi agent seperti mengadopsi perubahan apa pun yang menaikkan volume deployment: dengan metrik instability di dashboard yang sama, baseline yang diambil lebih dulu, dan batch yang cukup kecil untuk diverifikasi manusia.