Bottleneck AI Code Review: Temuan CMU dan Stanford

Angka yang membuat saya berhenti bukan throughput 2,09x, tapi 39% ke 21%. Dalam studi yang saya bahas di sini, porsi pull request yang menerima komentar tertulis dari human reviewer hampir separuh dalam kurang dari dua tahun, sementara merge rate dan revert rate tetap datar. Semua dashboard yang biasa dipantau tim tetap hijau, padahal fungsi utama review sedang menipis di bawahnya.

Post ini membaca paper-nya langsung, bukan ringkasannya: Hao He, Shyam Agarwal, Yegor Denisov-Blanch, Pavel Azaletskiy, Sanmi Koyejo dan Bogdan Vasilescu, arXiv 2607.01904, diajukan 2 Juli 2026. Saya mengambil PDF-nya dan membaca bagian methods serta threats to validity, lalu membandingkannya dengan cara esai Semgrep 9 Oktober 2026 memakainya. Sudutnya berbeda dari post saya sebelumnya tentang AI review sebagai CI gate dan temuan DORA soal throughput dan instability: fokus di sini adalah kapasitas reviewer, apa yang bisa dan tidak bisa dibuktikan datanya, dan apa yang perlu disiapkan sebelum antrean review Anda penuh.

Apa yang sebenarnya diukur studi ini, dan pada siapa

Ini adalah longitudinal case study pada satu perusahaan software B2B menengah dengan organisasi R&D beberapa ratus engineer. Pada Juni 2025 CTO-nya mengumumkan mandat 2x: menggandakan produktivitas engineering lewat adopsi AI dalam dua belas bulan, dengan merged pull request per engineer per bulan sebagai metrik. Perusahaan memberi peneliti akses ke riwayat PR dan log penggunaan Cursor dan Claude Code. Penulis menyatakan perusahaan tidak ikut dalam analisis maupun penulisan, dan tidak ada karyawannya yang menjadi penulis.

Panelnya mencakup 802 developer dan 196.212 PR non-bot di 364 repository aktif, Januari 2024 sampai April 2026. Sebanyak 30,2% PR itu membawa label created-by-ai milik perusahaan, dan penulis memperlakukan setiap perbandingan PR AI versus manusia sebagai korelasional karena label itu tidak mereka tetapkan sendiri. Klaim kausal bertumpu pada desain staggered difference-in-differences yang membandingkan tiap developer dengan output mereka sendiri sebelumnya.

Dua pilihan data penting untuk semua yang berikutnya. Review bot dipisahkan: akun otomatis menyumbang sekitar 38% baris review, sehingga penulis menghitung review non-author non-bot pertama sebagai awal fase review. Dan perusahaannya sengaja tidak representatif. Paper menyebutnya muda, AI-forward dan permisif, mendanai tool AI tanpa batas per seat atau budget token, dan menyatakan efeknya lebih tepat dibaca sebagai batas atas ketimbang rata-rata industri.

Angka-angkanya, dengan definisi dari paper sendiri

Berikut setiap angka yang saya pakai, diambil dari teks dan tabel paper, bukan dari tulisan sekunder. Kolom kanan sama pentingnya dengan kolom tengah, karena beberapa angka ini mudah salah kutip kalau definisinya dibuang.

Perhatikan apa yang tidak ada di tabel: jumlah defect yang terukur. Paper tidak punya angka itu. Ketiadaan itu adalah topik bagian lima.

Silent approval: ke mana beban tambahan sebenarnya jatuh

Mekanismenya aritmetika sederhana. Volume tumbuh 3,1x dan jumlah orang yang me-review tumbuh 1,5x, sehingga tiap reviewer memikul sekitar dua kali kerja. Organisasi tidak menambah orang untuk menyelesaikannya dan tidak membiarkan antrean membengkak tanpa batas. Mereka melakukan dua hal: mengalihkan review ke otomasi, dan human review yang tersisa menjadi lebih tipis.

Penipisan ini terukur di dua level. Per PR, feedback tertulis turun dari sekitar 39% ke sekitar 21%. Per reviewer, orang median tetap meninggalkan sekitar tiga review berkomentar per bulan, sama seperti sebelumnya, sementara review approve-only mereka sekitar berlipat. Dalam kata penulis, beban tambahan jatuh pada approval kosong, bukan review substantif.

Hati-hati dengan satu frasa dari esai Semgrep. Esai itu menyebut silent approval per reviewer berlipat, yang cocok dengan median per reviewer di paper. Tetapi sebagai porsi PR, silent approval relatif datar di sekitar 50%. Keduanya benar; menjawab pertanyaan yang berbeda. Yang pertama: seseorang menekan approve dua kali lebih sering. Yang kedua: proporsi PR yang hanya mendapat satu klik tidak banyak berubah, karena proporsi yang tidak mendapat human sama sekali bertambah.

Latensi 20%: baca sebagai sinyal antrean, bukan sinyal kualitas

Di level PR, penulis membandingkan PR berbasis AI dan PR manusia dalam author dan bulan kalender yang sama, dengan kontrol ukuran perubahan. PR AI butuh sekitar 20% lebih lama dari review human pertama sampai merge pasca-mandat, dan sekitar 22% lebih lama dalam total cycle time. Pickup, yaitu waktu tunggu sebelum human pertama melihat, juga lebih panjang di Tabel IV paper, dan fase review lebih panjang lagi.

Pembacaan paper adalah bahwa ini antrean, bukan rework. Jumlah review round dan change request datar, dan PR AI tidak lebih kecil kemungkinannya mendapat human review. Yang memanjang adalah jeda antara review pertama dan merge, di mana PR AI menarik sekitar 9% lebih banyak komentar tanpa lebih banyak revision round. Penulis menyebutnya lebih banyak keterlibatan reviewer, bukan lebih banyak perbaikan.

Dua batasan dari paper menjaga kejujurannya. Estimasinya korelasional karena label created-by-ai bisa mengikuti kompleksitas yang tidak terukur. Dan di akhir periode perusahaan mulai merutekan PR lewat review berbasis AI dan auto-approval, yang menghilangkan latensi human untuk porsi PR yang makin besar. Penulis menyatakan hal itu membiaskan premi terukur ke arah nol, jadi 20% bersifat konservatif untuk rezim di mana human masih me-review.

Apa yang tidak bisa dikatakan data: dashboard hijau, tanpa angka defect

Penenang utamanya adalah merge rate tetap datar dan revert rate sedikit turun, jadi volume tambahan terkirim, bukan menumpuk. Penulis sendiri lalu melemahkannya. Merge rate dan revert rate adalah proksi kasar berjangka pendek yang tidak menangkap defect, incident dan maintainability, dan mereka menyatakan hasilnya dibaca sebagai bukti melawan keruntuhan kualitas akut, bukan surat keterangan sehat. Perusahaan juga men-deploy setiap PR secara otomatis, jadi defect yang tidak memicu revert tidak terlihat oleh kedua metrik.

Itulah kegagalan bernama dalam cerita ini: proses review bisa menurun sementara setiap metrik yang dipantau tim tetap datar, karena metrik itu dipilih untuk pipeline berkecepatan manusia. Diskusi paper sendiri menyebut DORA dan SPACE mencatat percepatan tetapi melewatkan ke mana pekerjaan pergi. Kalau jumlah merge adalah target, seperti di sini, tekanannya adalah menjaga angka naik sementara biaya di sisi reviewer tidak terukur.

Dua catatan kecil lagi. Kaitan adopsi dan pemakaian dengan throughput dibaca sebagai asosiasi karena developer memilih seberapa intens memakai AI, jadi paper tidak mengklaim ukuran kausal yang pasti. Dan saya membuang satu angka yang diatribusikan esai Semgrep ke studi review ICSE 2022, yaitu tingkat tangkap human 3% sampai 61%. Saya membaca abstrak paper itu dan isinya melaporkan 150 partisipan serta peningkatan deteksi delapan kali lipat bila reviewer diminta fokus ke keamanan; rentang 3% sampai 61% tidak bisa saya konfirmasi dari yang saya baca, jadi tidak dipakai di sini.

Model exception-only Semgrep, dan apa yang masih harus dibuktikan

Esai Semgrep, ditulis Daghan Altas dan bertanggal 9 Oktober 2026, mengusulkan membalik default: setiap perubahan di-review agent untuk correctness, keamanan dan keselarasan arsitektur, perubahan rutin lanjut jika bukti memenuhi policy, dan human dipanggil hanya untuk yang konsekuensial seperti batas service baru, dependency besar atau perubahan threat model. Target steady-state-nya adalah kurang dari 1% PR yang butuh human. Semgrep menjual tooling keamanan, jadi baca ini sebagai usulan vendor, bukan hasil.

Bagian yang menurut saya kredibel adalah rollout-nya, bukan target 1%. Pilot Semgrep menjalankan agent dalam shadow mode di samping human reviewer, melacak false approval, coverage, biaya dan kecepatan, serta mensyaratkan empat check semuanya lulus: knowledge transfer, product, design dan correctness. Check yang gagal dicoba ulang agent, dan setelah gagal berulang human mengambil alih. Ahli melabeli PR nyata sebagai test case terlebih dahulu. Itu pengukuran sebelum kepercayaan.

Playbook SDLC AI-native dari Anthropic mengarah ke hal yang sama tetapi mempertahankan gerbang human: playbook itu menggambarkan lapisan agentic review dengan human review dicadangkan untuk kode teregulasi dan kritis, menyatakan temuan tidak meng-approve atau memblokir PR sendiri, dan branch protection tetap mensyaratkan approval dari code owner. Separation of duties terjaga karena agent yang menulis kode tidak bisa meng-approve-nya. Perhatikan perbedaan desain: target Semgrep menyingkirkan human dari sebagian besar PR, sedangkan playbook mempertahankan approval code owner sebagai kontrol terakhir.

Ukur beban review Anda sendiri sebelum meniru solusi siapa pun

Metrik studi ini bisa direproduksi dalam skala lebih kecil dari GraphQL API GitHub. Script ini mengambil N PR merged terakhir dari sebuah repository dan mencetak porsi dengan feedback tertulis human, silent approval per reviewer, dan median jam dari review human pertama sampai merge. Saya menulisnya mengikuti definisi paper: human adalah user non-author non-bot, dan feedback tertulis adalah body review yang tidak kosong atau minimal satu komentar inline. Saya belum menjalankannya pada repository live dari environment ini, jadi coba dulu di repo kecil.

// Usage: node review-load.mjs OWNER REPO [N]
// Measures, for the last N merged PRs: share with any written human feedback,
// silent approvals per reviewer, and hours from first human review to merge.
import { execFileSync } from "node:child_process";

const [owner, repo, n = "100"] = process.argv.slice(2);
const query = `
query($owner: String!, $repo: String!, $n: Int!) {
  repository(owner: $owner, name: $repo) {
    pullRequests(states: MERGED, last: $n, orderBy: {field: UPDATED_AT, direction: ASC}) {
      nodes {
        mergedAt
        author { login __typename }
        reviews(first: 50) {
          nodes { state body submittedAt author { login __typename } comments { totalCount } }
        }
      }
    }
  }
}`;
const raw = execFileSync("gh", ["api", "graphql", "-f", `query=${query}`,
  "-F", `owner=${owner}`, "-F", `repo=${repo}`, "-F", `n=${n}`], { encoding: "utf8" });
const prs = JSON.parse(raw).data.repository.pullRequests.nodes;

let withFeedback = 0, reviewed = 0;
const silentBy = new Map();
const hours = [];
for (const pr of prs) {
  const human = pr.reviews.nodes.filter(
    (r) => r.author && r.author.__typename === "User" && r.author.login !== pr.author?.login);
  if (human.length === 0) continue;
  reviewed++;
  // "Written feedback" = a review body or at least one inline comment.
  if (human.some((r) => r.body.trim() !== "" || r.comments.totalCount > 0)) withFeedback++;
  for (const r of human) {
    const silent = r.state === "APPROVED" && r.body.trim() === "" && r.comments.totalCount === 0;
    if (silent) silentBy.set(r.author.login, (silentBy.get(r.author.login) ?? 0) + 1);
  }
  const first = Math.min(...human.map((r) => Date.parse(r.submittedAt)));
  hours.push((Date.parse(pr.mergedAt) - first) / 36e5);
}
hours.sort((a, b) => a - b);
const median = hours.length ? hours[Math.floor(hours.length / 2)].toFixed(1) : "n/a";
console.log({
  mergedPrs: prs.length,
  withAnyHumanReview: reviewed,
  withWrittenFeedbackPct: reviewed ? Math.round((100 * withFeedback) / reviewed) : null,
  silentApprovalsByReviewer: Object.fromEntries(silentBy),
  medianHoursFirstReviewToMerge: median,
});

Jalankan tiap bulan dan simpan hasilnya. Sinyal yang berguna adalah tren feedback tertulis dan silent approval per orang, bukan nilai absolutnya, dan tim lima orang akan berisik. Jika jumlah reviewer datar sementara volume PR naik, Anda mereproduksi setup paper, dan pertanyaannya adalah apakah Anda menyadarinya sebelum incident.

Apa yang dilakukan hari Senin

Semua ini tidak butuh platform agent. Lima langkah berurutan, masing-masing murah dan bisa dibatalkan.

1. Jalankan script di atas pada tiga repository tersibuk Anda dan catat porsi feedback tertulis, silent approval per reviewer dan median jam review pertama sampai merge. Itu baseline Anda.
2. Hitung reviewer terhadap volume PR, bukan terhadap headcount. Rasio 1,5x versus 3,1x di paper adalah rasio yang perlu dipantau.
3. Tuliskan trigger eskalasi Anda: path, dependency dan jenis perubahan mana yang selalu butuh human bernama. Kodekan di CODEOWNERS agar ditegakkan, bukan diingat.
4. Aktifkan required code owner review dan dismissal stale approval, agar approval tidak bertahan melewati diff yang di-approve.
5. Jika Anda menambahkan AI reviewer, jalankan dalam shadow mode dulu. Bandingkan putusannya dengan human pada PR nyata selama beberapa minggu, dan catat setiap miss serta eskalasi yang tidak perlu sebelum ia boleh meng-approve apa pun.

# .github/CODEOWNERS: escalation triggers as files, not memory.
# The last matching pattern wins, so keep the broad default first.
*                           @acme/reviewers

# Consequential changes: new service boundaries, dependencies, threat model.
/services/*/api/            @acme/architecture
package.json                @acme/architecture @acme/security
package-lock.json           @acme/security
/infra/                     @acme/platform
/.github/workflows/         @acme/platform @acme/security
/docs/threat-model/         @acme/security

# Branch protection with code owner review and stale-approval dismissal.
# All four top-level fields are required by the API; null switches one off.
cat > protection.json <<'JSON'
{
  "required_status_checks": { "strict": true, "contexts": ["ci"] },
  "enforce_admins": true,
  "required_pull_request_reviews": {
    "require_code_owner_reviews": true,
    "dismiss_stale_reviews": true,
    "require_last_push_approval": true,
    "required_approving_review_count": 1
  },
  "restrictions": null
}
JSON
gh api -X PUT repos/acme/monorepo/branches/main/protection --input protection.json

File CODEOWNERS bisa berada di .github, root repository atau docs, pola yang cocok terakhir menang, dan satu approval dari salah satu owner yang terdaftar sudah memenuhi syarat, menurut dokumentasi GitHub. Pemanggilan branch protection di bawah memakai nama field dari REST reference GitHub; keempat field tingkat atas wajib, dan null menonaktifkan salah satunya.

Aturan yang saya ambil dari paper: ketika output per developer berlipat dan reviewer tidak, review tidak berhenti, ia menipis, dan metrik yang dibuat untuk pipeline berkecepatan manusia tidak akan menunjukkannya. Ukur feedback tertulis dan silent approval di samping jumlah merge, tuliskan trigger eskalasi sebelum agent harus menebaknya, dan perlakukan review exception-only sebagai hipotesis yang dijalankan dalam shadow mode sampai angka Anda sendiri membuktikannya.