Playbook yang belum pernah diukur
Anthropic menerbitkan playbook SDLC AI-native untuk Claude Code: enam tahap, masing-masing berakhir dengan satu file yang di-commit, diajarkan sebagai kursus gratis. Klaim utamanya: kode bukan lagi bottleneck, dan rantai artefak yang di-commit-lah yang mengelola bottleneck yang sebenarnya. Dokumennya sendiri tidak memuat pengukuran apa pun — tanpa waktu, tanpa biaya, tanpa benchmark. Kami menjalankan uji berwaktu pertama pada repositori sungguhan: enam belas sesi Claude Code yang diukur waktunya, setiap gate dihitung biayanya, dan sebuah verdict yang membelah rantai itu tepat di tengah. Sepanjang jalan, perbaikan dua menit yang dilewatkan lewat seluruh rantai memperlihatkan harga seremoninya, dan deploy kami sendiri dihentikan dua kali, salah satunya oleh empat baris shell.
Playbook dan rig pengujiannya
Rig pengujian: enam belas sesi Claude Code berwaktu, sekitar $12 biaya komputasi, satu repositori sungguhan. Playbook ini terdiri dari enam tahap — plan, design, build, test, deploy, maintain. Setiap tahap berakhir dengan satu file yang di-commit, dan tahap berikutnya membaca file itu: intent, spec, plan, pull request, catatan insiden. Commit-commit itu adalah jejak auditnya. Anthropic mengajarkannya sebagai kursus gratis 14 pelajaran, sekitar satu jam, ditulis untuk perusahaan dengan review gate; kami menguji apa yang bertahan ketika berhadapan dengan satu developer.
Repositorinya adalah aplikasi demo RealWorld (Express, TypeScript, Prisma, Postgres) — proyek nyata dengan test nyata, dan satu suite yang rusak pada clone baru (empat suite lulus, 14 test hijau, dua detik untuk menjalankannya). Bug itu nanti menjadi kelompok kontrol. Aturan penilaiannya: sebuah gate sepadan jika outputnya mengubah apa yang dirilis, dengan biaya lebih rendah daripada nilainya.
Tiket masuknya adalah file memori di root repo — perintah, konvensi, arsitektur, kesalahan yang terus diulang model, dijaga kurang dari satu halaman. File kami ditulis dan di-commit dalam 63 detik seharga $0,44. Satu catatan jujur soal metode: eksekusi headless memadatkan wawancara dalam playbook menjadi satu prompt.
Plan: intent.md dalam dua puluh sembilan detik
Gate pertama menangkap ide sebelum siapa pun mulai mendesain. Permintaan fiturnya: pembaca ingin membisukan (mute) penulis yang membanjiri feed mereka. Playbook menyebut hasilnya proto-spec — ditulis bersama model, dimiliki oleh Anda — dan mengizinkan tiga asal: sebuah ide, tiket yang sudah dibuat, atau alert insiden. Templatenya punya lima bagian yang judulnya sudah ikut berpikir: masalah, hasil yang diusulkan, pengguna dan sistem yang terdampak, batasan, pertanyaan terbuka. Alur kerjanya lima langkah: deskripsikan, brainstorm, buat dari template, koreksi, commit.
| intent.md | waktu | biaya |
|---|---|---|
| Fitur mute-authors | 29 s | $0.18 |
| Suite test yang rusak | 39 s | — |
Nilainya ada di bagian bawah, di pertanyaan terbuka: apa yang terjadi pada favorit dari penulis yang di-mute? Apakah halaman mereka tetap bisa diakses? Ini keputusan yang kalau tidak ditulis akan diambil diam-diam oleh coding agent, kini tertulis dan bertanggal. File-nya di-commit, sehingga penulis dan stempel waktunya bertahan melampaui chat, dan product owner mengoreksi draf sebelum menerimanya. Target Anthropic sendiri untuk tahap ini adalah elisitasi dalam hitungan jam, bukan minggu; kalau dikerjakan sendiri, kurang dari semenit.
Design: spec menandai prasyaratnya sendiri
Gate kedua mengubah intent menjadi spec dengan satu prompt dari kursus: baca intent, hasilkan spec kebutuhan dan desain, terapkan skill yang tersedia — skill yang seharusnya membawa kebijakan brand, keamanan, dan UX Anda. Dua menit kemudian kami mendapat sekitar 2.300 kata spec yang kompeten: endpoint, model data, perilaku feed, edge case. Spec itu bahkan mencatat apa yang tidak bisa dipenuhinya, persis seperti yang diminta prompt.
Kejutannya ada pada concern yang ditandainya, ditulis oleh model sendiri: "C0. No org skills available. This spec has not been checked against any policy." Seluruh premis tahap ini mengandaikan file yang tidak ada di sebagian besar setup — video penjelasan melewatkan prasyarat itu; agent justru menuliskannya. Flag kedua lebih ringan: default pertanyaan terbuka perlu persetujuan produk sebelum build.
Pelajarannya ketat soal pemasangan (spec dan intent di-commit bersama, manusia menyetujui peralihan ke build), dan ada tagihan membaca: sekitar 12 menit waktu product owner per spec. Playbook bahkan melacak rework — commit spec yang bertanggal setelah build dimulai dihitung sebagai poin minus. Di tim yang sudah meng-encode kebijakannya, gate ini adalah tempat kebijakan itu dijalankan. Kalau sendiri, Anda membayar untuk janji yang belum bisa ditepati setup Anda.
Build: plan mode, TDD, dan apa yang sebenarnya diperiksa loop
Gate ketiga adalah Plan Mode, dan standarnya keras tapi berguna: seorang engineer yang tidak pernah melihat percakapan harus bisa mengimplementasikan hanya dari plan. Plan Mode sendiri yang memaksakan bagian membacanya — model tidak bisa mengedit file sebelum plan diterima. Plan kami keluar sekitar 4.000 kata dalam empat menit, menyebutkan file yang berubah, urutan pekerjaan, risiko, dan pembuktiannya, serta mencatat tiga deviasi berlabel dari spec yang muncul lagi saat review.
Build berjalan dalam sebuah loop: tulis test yang gagal, buat lulus, satu target, semua hijau atau tugas belum selesai. Loop itu dilindungi (agent yang memperbaiki kode tidak boleh melemahkan pengecekan atas kode tersebut) dan dipasangkan dengan verifier — pengecekan kedua dalam konteks baru, tidak terpengaruh oleh sesi yang menulis kodenya.
| Hasil build | nilai |
|---|---|
| Waktu agent | ~9 menit, 91 turn |
| Biaya | ~$2 |
| Perubahan | 15 file, tabel Mutes, dua endpoint, kedua feed terfilter |
| Test | 5 suite, 50 test, semua hijau pada rerun independen |
| Merge di percobaan pertama | ya |
Tanda bintangnya: hijau hanya membuktikan apa yang ada di dalam loop, tidak lebih. End-to-end tidak pernah dijalankan — itu butuh server live dan database yang sudah di-seed, dan loop yang diarahkan ke fake yang usang akan menyala hijau sama terangnya. Pada skala tim, ada sesi paralel di worktree (dua atau tiga adalah batas yang disebutkan); itu tidak kami uji.
Deploy: review, dan gate yang berkata tidak
Gate deploy punya dua lapisan, dan keduanya berkata tidak kepada kami. Lapisan pertama membaca diff berdasarkan kebijakan tertulis di root repo: tiga pass (bug, keamanan, kepatuhan terhadap spec dan plan), "Important" dicadangkan untuk perilaku yang rusak, data yang bocor, atau kebijakan yang dilanggar, maksimal lima nit dan sisanya diringkas sebagai jumlah — kebijakan itu membatasi noise-nya sendiri. Dua menit review, $0,80, dan ia menjalankan pengecekan sungguhan: test, build, lint terhadap baseline yang dicatat di plan, format di sembilan file. Verdict: nol temuan Important, enam nit, satu di atas batas diringkas. Ia menutup dengan satu kalimat yang tidak kami minta: agent ini tidak menyetujui — persetujuan tetap di tangan code owner manusia di balik branch protection.
Lapisan kedua adalah gate itu sendiri. Kami meminta deploy; model menolak atas inisiatifnya sendiri, karena fiturnya belum ada di branch rilis. Itu penilaian, bukan penegakan. Jadi kami merge lalu bertanya lagi: empat baris shell menjawab dalam 14 detik — diblokir, otorisasi rilis diperlukan. Exit code 2 menghentikan tool call dan alasannya dikembalikan ke model. Sisi pipeline mendapat perlakuan yang sama: build yang rusak ditriase secara headless dalam 11 detik seharga $0,13 — ia membaca log, menyebut penyebab persisnya, dan mengusulkan diff tanpa menyentuh satu file pun. Deterministik mengalahkan sopan; sebuah hook hanya sebaik pattern-nya, dan milik kami hanya cocok dengan satu script.
Pajak gate
Bug yang sama, awal yang rusak sama, dua jalan — eksperimen kontrol. Jalan pertama: langsung perbaiki. Jalan kedua: seluruh rantai, dari intent sampai build.
| perbaikan langsung | rantai penuh | pengali | |
|---|---|---|---|
| Waktu total | 2:13 | 11:31 | ×5.2 |
| Biaya | $0.70 | $3.46 | ×4.9 |
| Turn | 40 | 169 | — |
| Hasil | suite hijau | suite hijau | identik |
Tagihan mesin hanyalah separuh yang kecil. Rantai itu menulis sekitar 5.500 kata artefak untuk perbaikan satu baris — kira-kira 27 menit membaca oleh manusia untuk sebuah diff yang bisa dipindai dalam sekali lihat. Rantai ini mengubah waktu menulis menjadi waktu membaca; itulah pajak gate.
Playbook menambahkan biaya berulang: eval berkelanjutan. Dua puluh sampai lima puluh tugas nyata, dijalankan ulang untuk setiap perubahan konfigurasi — tiap kasus adalah tugas nyata dari masa lalu, prompt apa adanya, dijalankan dari commit sebelum perubahan, dengan kriteria penerimaan yang bisa dicek. Menulis lima kasus dari riwayat memakan lima menit; menjalankannya dengan benar tidak semudah itu — harness pertama kami mengarahkan dua kasus ke commit yang salah, dan kedua agent menangkapnya alih-alih memalsukan kelulusan. Pada sekitar satu menit per kasus, satu suite penuh memakan waktu agent hingga satu jam per eksekusi, dan setiap insiden produksi seharusnya masuk ke suite sebagai eval regresi permanen. Di tim yang diatur regulasi, membaca itu adalah deliverable-nya; kalau sendiri, itu overhead.
Verdict: tiga dari enam sepadan
Tiga dari enam gate sepadan dengan biayanya:
| Tahap | verdict | bukti |
|---|---|---|
| Plan | pertahankan | 40 s membeli pertanyaan yang tidak ditanyakan siapa pun |
| Build | pertahankan | plan mode + loop test merilis 50 test hijau |
| Deploy | pertahankan | review $0.80 dengan pengecekan nyata, blokir deterministik 14 s |
| Design | lewati jika sendiri | menagih Anda untuk kebijakan yang belum Anda encode |
| Test (eval berkelanjutan) | bisa menunggu | hingga satu jam per eksekusi, mudah salah arah |
| Maintain | belum terbukti | butuh telemetri produksi berminggu-minggu |
Maintain elegan di atas kertas — script deterministik mengawasi control band, dan pelanggaran menulis file intent baru — tetapi membuktikannya membutuhkan telemetri produksi yang tidak kami miliki. Dokumen Anthropic sendiri, seperti kata salah satu analis, tidak memuat pengukuran di mana pun; ini adalah angka-angka pertama, dengan keterbatasan yang jelas: satu repo, satu developer, satu hari.
Data dari luar menunjukkan tekanannya nyata. Faros melacak lebih dari 10.000 developer di 1.200+ tim: tim dengan adopsi tinggi me-merge 98% lebih banyak pull request, waktu review naik 91%, dan rata-rata ukuran pull request lebih dari dua kali lipat. Laporan DORA terbaru senada: throughput naik dengan AI, stabilitas turun. Review menjadi bottleneck, dan playbook ini membidik tepat ke sana. Varian dari komunitas sudah memangkas rantai menjadi dua keputusan manusia — satu menyediakan template dan gate ledger, yang lain hanya menempatkan manusia di design dan test. Adopsi tiga gate yang sepadan, dan tumbuhlah ke yang lain saat tim Anda siap. Kalimat penutup Anthropic sendiri adalah epitaf yang tepat: loop terus berjalan, penilaian manusia tetap berada di atasnya.
AIDive