AIDiveवह playbook जिसे किसी ने नापा नहीं
Anthropic ने Claude Code के लिए एक AI-native SDLC playbook छापा है: छह stage, हर एक का अंत एक committed file में, और इसे free course के रूप में पढ़ाया जाता है। इसका केंद्रीय दावा है कि code अब bottleneck नहीं रहा, और जो असली bottleneck है उसे committed artifacts की चेन संभालती है। Document में किसी भी तरह की माप नहीं है — न समय, न लागत, न कोई benchmark। हमने एक असली repository पर पहला timed test चलाया: सोलह timed Claude Code sessions, हर gate की कीमत नापी हुई, और ऐसा verdict जो चेन को ठीक बीच से बांट देता है। रास्ते में, पूरी चेन से गुज़ारे गए दो मिनट के एक fix ने इस कर्मकांड की कीमत बता दी, और हमारा अपना deploy दो बार रोका गया, एक बार shell की चार लाइनों से।
Playbook और test rig
Test rig: सोलह timed Claude Code sessions, करीब $12 का compute, एक असली repository। Playbook में छह stage हैं — plan, design, build, test, deploy, maintain। हर stage का अंत एक committed file में होता है, और अगला stage उसी file को पढ़ता है: intent, spec, plan, pull request, incident record। Commits ही audit trail हैं। Anthropic इसे 14 lessons के free course के रूप में सिखाता है, करीब एक घंटे का, जो review gates वाले enterprises के लिए लिखा गया है; हमने परखा कि एक अकेले developer के साथ असल में क्या बचता है।
Repository RealWorld demo app है (Express, TypeScript, Prisma, Postgres) — असली tests वाला असली project, जिसमें fresh clone पर एक suite टूटा हुआ है (चार suites पास, 14 tests हरे, चलने में दो सेकंड)। यही bug आगे चलकर control group बनता है। स्कोर का नियम: एक gate तब पैसा वसूल करता है जब उसका output इस पर असर डालता है कि क्या ship होगा, और वह भी अपनी लागत से कम में।
Entry ticket repo की root में रखी एक memory file है — commands, conventions, architecture, और वे गलतियां जो model बार-बार दोहराता है, एक पेज से छोटी। हमारी file 63 सेकंड में $0.44 में लिखी और commit हुई। Method पर एक ईमानदार चेतावनी: headless runs playbook के interviews को एक-एक prompt में समेट देते हैं।
Plan: intent.md उनतीस सेकंड में
पहला gate किसी के design करने से पहले विचार को पकड़ लेता है। Feature request: पाठक उन authors को mute करना चाहते हैं जो उनकी feed भर देते हैं। Playbook इस नतीजे को proto-spec कहता है — model के साथ लिखा, आपके स्वामित्व में — और तीन उद्गम मानता है: एक विचार, एक दर्ज ticket, या एक incident alert। Template में पांच sections हैं जिनके शीर्षक ही सोचने का काम करते हैं: समस्या, प्रस्तावित नतीजा, प्रभावित users और systems, constraints, खुले सवाल। काम का loop पांच कदमों का है: बताओ, brainstorm करो, template से generate करो, सुधारो, commit करो।
| intent.md | समय | लागत |
|---|---|---|
| Mute-authors feature | 29 s | $0.18 |
| टूटा हुआ test suite | 39 s | — |
असली मूल्य सबसे नीचे, खुले सवालों में है: muted author के favorites का क्या होगा? क्या उनके पेज पहुंच में रहेंगे? ये वे फैसले हैं जो एक coding agent वरना चुपचाप ले लेता, अब लिखे हुए और तारीख के साथ दर्ज। File commit होती है, इसलिए लेखक और timestamp chat के बाद भी बचे रहते हैं, और product owner draft को स्वीकार करने से पहले सुधारता है। इस stage के लिए Anthropic का अपना लक्ष्य है हफ्तों की जगह घंटों में elicitation; अकेले में यह एक मिनट से कम है।
Design: spec अपनी ही पूर्वशर्त को flag करता है
दूसरा gate course के एक prompt से intent को spec में बदलता है: intent पढ़ो, requirements और design spec बनाओ, उपलब्ध skills लागू करो — वे skills जिन्हें आपकी brand, security और UX policy ढोनी है। दो मिनट बाद हमारे पास करीब 2,300 शब्दों का सक्षम spec था: endpoints, data model, feed का व्यवहार, edge cases। जो वह पूरा नहीं कर सका, उसे भी उसने दर्ज किया, ठीक वैसे जैसे prompt मांगता है।
मोड़ उसकी flagged concerns में है, जो model ने खुद लिखीं: "C0. No org skills available. This spec has not been checked against any policy." इस stage की पूरी बुनियाद ऐसी files मानकर चलती है जो ज़्यादातर setups में मौजूद ही नहीं हैं — explainer videos इस पूर्वशर्त को छोड़ देते हैं; agent ने इसे लिखित में रखा। दूसरा flag नरम था: खुले सवालों के defaults को build से पहले product की मंज़ूरी चाहिए।
Lesson जोड़ी बनाने पर सख्त है (spec और intent साथ commit होते हैं, build में जाने की मंज़ूरी इंसान देता है), और एक पढ़ने का बिल भी है: हर spec पर product owner के करीब 12 मिनट। Playbook rework भी गिनता है — build शुरू होने के बाद की तारीख वाले spec commits आपके खिलाफ गिने जाते हैं। जिस team ने अपनी policies encode कर रखी हैं, उसके लिए यह gate वही जगह है जहां वे चलती हैं। अकेले में, आप ऐसे वादे की कीमत चुका रहे हैं जिसे आपका setup अभी निभा नहीं सकता।
Build: plan mode, TDD, और loop असल में क्या जांचता है
तीसरा gate Plan Mode है, और उसकी कसौटी कड़ी भी है और काम की भी: कोई ऐसा engineer जिसने बातचीत नहीं देखी, सिर्फ plan से implement कर सके। Plan Mode पढ़ने वाला हिस्सा खुद लागू करवाता है — plan स्वीकार होने तक model files edit नहीं कर सकता। हमारा plan चार मिनट में करीब 4,000 शब्दों का निकला, जिसमें बदलने वाली files, काम का क्रम, जोखिम और प्रमाण दर्ज थे, और spec से तीन नामित विचलन भी, जो बाद में review में लौटकर आते हैं।
Build एक loop पर चलता है: पहले fail होने वाला test लिखो, उसे पास कराओ, एक लक्ष्य, सब हरा या काम पूरा नहीं। Loop सुरक्षित है (code ठीक करने वाला agent उस code की जांच को कमज़ोर नहीं कर सकता) और एक verifier के साथ जुड़ा है — ताज़ा context में दूसरी जांच, जो code लिखने वाले session से प्रभावित नहीं होती।
| Build का नतीजा | मान |
|---|---|
| Agent का समय | ~9 min, 91 turns |
| लागत | ~$2 |
| बदलाव | 15 files, Mutes table, दो endpoints, दोनों feeds फ़िल्टर |
| Tests | 5 suites, 50 tests, स्वतंत्र दोबारा चलाने पर सब हरे |
| पहली बार में merge | हां |
तारांकन यह है: हरा रंग सिर्फ वही साबित करता है जो loop के भीतर है, उससे ज़्यादा कुछ नहीं। End-to-end कभी चलाया नहीं गया — उसे live server और seeded database चाहिए, और पुराने fakes की ओर तना हुआ loop भी उतना ही हरा चमकेगा। Team स्तर पर worktrees में parallel sessions जुड़ते हैं (दो या तीन बताई गई सीमा है); हमने इसे नहीं परखा।
Deploy: review, और वह gate जिसने ना कहा
Deploy gate की दो परतें हैं, और दोनों ने हमें ना कहा। पहली परत repo की root में रखी लिखित policy के तहत diff पढ़ती है: तीन pass (bugs, security, spec और plan के विरुद्ध compliance), "Important" सिर्फ टूटे व्यवहार, लीक हुए data या भंग हुई policy के लिए आरक्षित, अधिकतम पांच nits और बाकी का सिर्फ गिनती में सार — policy अपना शोर खुद सीमित करती है। दो मिनट का review, $0.80, और उसने असली जांचें चलाईं: tests, build, plan के दर्ज baseline के विरुद्ध lint, नौ files में formatting। Verdict: शून्य Important findings, छह nits, सीमा से एक ज़्यादा जिसका सार दिया गया। अंत में उसने एक पंक्ति कही जो हमने नहीं मांगी थी: यह agent मंज़ूरी नहीं देता — मंज़ूरी branch protection के पीछे बैठे इंसानी code owner के पास रहती है।
दूसरी परत खुद gate है। हमने deploy मांगा; model ने खुद इनकार कर दिया, क्योंकि feature shipping branch पर नहीं था। यह विवेक है, enforcement नहीं। तो हमने merge किया और फिर मांगा: shell की चार लाइनों ने 14 सेकंड में जवाब दिया — blocked, release authorization required। Exit code 2 tool call को रोक देता है और कारण model के पास लौट जाता है। Pipeline की ओर भी यही बर्ताव मिला: टूटे build का headless triage 11 सेकंड में $0.13 में हुआ — उसने log पढ़ा, सटीक कारण बताया, और बिना कोई file छुए diff प्रस्तावित किया। Deterministic विनम्र से बेहतर है; hook उतना ही अच्छा है जितना उसका pattern, और हमारा एक ही script से मेल खाता था।
Gate tax
वही bug, वही टूटी शुरुआत, दो रास्ते — control experiment। रास्ता एक: बस ठीक कर दो। रास्ता दो: intent से build तक पूरी चेन।
| सीधा fix | पूरी चेन | गुणक | |
|---|---|---|---|
| कुल समय | 2:13 | 11:31 | ×5.2 |
| लागत | $0.70 | $3.46 | ×4.9 |
| Turns | 40 | 169 | — |
| नतीजा | suite हरा | suite हरा | एक जैसा |
मशीन का बिल छोटा हिस्सा है। एक लाइन के fix के लिए चेन ने करीब 5,500 शब्दों के artifacts लिखे — करीब 27 मिनट का इंसानी पढ़ना, एक ऐसे diff के लिए जिसे आप एक मिनट में स्कैन कर लेते। चेन लिखने के समय को पढ़ने के समय में बदल देती है; यही gate tax है।
Playbook एक आवर्ती शुल्क और जोड़ता है: continuous evals। बीस से पचास असली tasks, हर config बदलाव पर दोबारा चलाए जाते हैं — हर case एक असली पुराना task, prompt जैसा था वैसा, बदलाव से पहले वाले commit से चलाया हुआ, जांचने योग्य स्वीकृति के साथ। इतिहास से पांच cases लिखने में पांच मिनट लगे; उन्हें सही चलाना उतना आसान नहीं — हमारे पहले harness ने दो cases गलत commit पर तान दिए, और दोनों agents ने पास का नाटक करने के बजाय इसे पकड़ लिया। करीब एक मिनट प्रति case के हिसाब से पूरा suite हर run पर एक घंटे तक का agent समय लेता है, और हर production incident को स्थायी regression eval बनकर suite में जुड़ना है। Regulated team पर वह पढ़ना ही असली deliverable है; अकेले में यह बोझ है।
Verdict: छह में से तीन पैसा वसूल करते हैं
छह में से तीन gates अपना खर्च निकालते हैं:
| Stage | verdict | प्रमाण |
|---|---|---|
| Plan | रखें | 40 s में वे सवाल मिलते हैं जो किसी ने नहीं पूछे |
| Build | रखें | plan mode + test loop ने 50 हरे tests ship किए |
| Deploy | रखें | असली जांचों वाला $0.80 का review, 14 s का deterministic block |
| Design | अकेले में छोड़ें | उन policies का बिल जो आपने encode नहीं कीं |
| Test (continuous evals) | रुक सकता है | हर run पर एक घंटे तक, गलत निशाना लगाना आसान |
| Maintain | अप्रमाणित | हफ्तों की production telemetry चाहिए |
कागज़ पर Maintain सुरुचिपूर्ण है — deterministic scripts control bands पर नज़र रखती हैं, और उल्लंघन होने पर नई intent file लिखी जाती है — पर इसे साबित करने के लिए production telemetry चाहिए जो हमारे पास नहीं है। Anthropic का अपना document, जैसा एक analyst ने कहा, कहीं कोई माप नहीं रखता; ये पहले आंकड़े हैं, साफ सीमाओं के साथ: एक repo, एक developer, एक दिन।
बाहरी data कहता है कि दबाव असली है। Faros ने 1,200+ teams के 10,000 से ज़्यादा developers को ट्रैक किया: ज़्यादा अपनाने वाली teams 98% ज़्यादा pull requests merge करती हैं, review का समय 91% बढ़ता है, और औसत pull request का आकार दोगुने से ज़्यादा हो जाता है। ताज़ा DORA report भी यही दोहराती है: AI के साथ throughput ऊपर, stability नीचे। Review bottleneck बनता जा रहा है, और playbook ठीक वहीं निशाना लगाता है। Community variants पहले ही चेन को दो इंसानी फैसलों तक घटा चुके हैं — एक templates और gate ledger देता है, दूसरा इंसानों को सिर्फ design और test पर रखता है। जो तीन gates पैसा वसूल करते हैं उन्हें अपनाइए, और बाकी में तब बढ़िए जब आपकी team बढ़े। Anthropic की अपनी समापन पंक्ति ही सही समाधि-लेख है: loop चलता रहता है, इंसानी विवेक उसके ऊपर रहता है।
