मैं ऐसे एजेंट बना रहा हूँ जो मेरे सोते समय काम करते हैं

• AI code-writing agent डेवलपर के सोते समय भी कोड जनरेट करता है और branch में बदलाव लागू करता है, लेकिन परिणाम की सटीकता और विश्वसनीयता की पुष्टि करना कठिन है
• अगर AI द्वारा लिखे गए कोड को वही AI टेस्ट करे, तो वह self-congratulation machine बन जाता है और मूल इरादे से अलग हुई गलतफहमियों को पकड़ नहीं पाता
• TDD के मुख्य सिद्धांत से प्रेरणा लेकर, कोड लिखने से पहले acceptance criteria लिखे जाते हैं, और एजेंट इन्हें आधार बनाकर implementation के बाद अलग से verification करता है
• verification tool के रूप में Claude Code के headless mode (claude -p) और Playwright MCP को जोड़कर 4-स्टेप pipeline बनाई गई, जिसमें अलग backend की ज़रूरत नहीं
• एजेंट के output पर भरोसा करने के लिए काम शुरू करने से पहले "done" की परिभाषा साफ़ होनी चाहिए, और यह prompt लिखने से कठिन लेकिन अनिवार्य प्रक्रिया है

---

स्वायत्त एजेंटों में कोड verification की समस्या

• Gastown जैसे AI tools का उपयोग करके एजेंट कई घंटों तक कोड लिखते हैं और branch में बदलाव जोड़ते हैं, लेकिन यह विश्वसनीय तरीके से verify करने का कोई तरीका नहीं है कि परिणाम वास्तव में सही है या नहीं
• पिछले 6 महीनों में 100 से अधिक इंजीनियरों के लिए Claude Code workshops चलाने पर, हर टीम में यही समस्या दिखी
• जो टीमें रोज़मर्रा के PR में Claude का उपयोग करती हैं, उनमें प्रति सप्ताह merged PR की संख्या 10 से बढ़कर 40~50 हो गई, जिससे code review पर कहीं अधिक समय लगने लगा
• सिस्टम जितना ज़्यादा autonomous होता है, समस्या उतनी गहरी हो जाती है — एक बिंदु पर लोग diff को review किए बिना deployment देखते रहते हैं और उम्मीद करते हैं कि कुछ न टूटे; गलती का पता deployment के बाद चलता है

मौजूदा समाधानों की सीमाएँ

• और reviewers भर्ती करने का तरीका speed के साथ नहीं चल पाता, और senior engineers का पूरा दिन AI-generated code पढ़ने में लगाना अक्षम है
• जब Claude अपने लिखे कोड के लिए खुद tests लिखता है, तो वह इस बात को verify करता है कि Claude को क्या सही लगा, न कि उपयोगकर्ता वास्तव में क्या चाहता था
  • regression bugs पकड़े जा सकते हैं, लेकिन मूल गलतफहमी (misunderstanding) को पकड़ना संभव नहीं
• अगर एक ही AI से writing और verification दोनों करवाए जाएँ, तो वह "self-congratulation machine" बन जाता है
• code review का मूल उद्देश्य लेखक के अलावा दूसरी नज़र पाना है, लेकिन AI-to-AI cross-review एक ही स्रोत से आने के कारण वही चीज़ें छोड़ देता है

TDD ने जिस मूल बात को सही पकड़ा

• TDD का सिद्धांत: पहले test लिखो, फिर code लिखो, और test pass होते ही रुक जाओ (ज़्यादा implementation मत करो)
• ज़्यादातर टीमें TDD इसलिए नहीं करतीं क्योंकि code को क्या करना चाहिए, यह पहले से सोचने में समय लगता है
• AI speed की समस्या हल कर देता है, इसलिए यह बहाना खत्म हो जाता है — अब धीमा हिस्सा है यह तय करना कि code सही है या नहीं
• unit tests की जगह feature को क्या करना चाहिए, इसे plain language में लिखना ज़्यादा आसान है
  • उदाहरण: "उपयोगकर्ता email और password से authenticate करता है। गलत credentials होने पर 'Invalid email or password' दिखे। सफल होने पर /dashboard पर जाए। session token 24 घंटे बाद expire हो।"
• code editor खोलने से पहले ही ये criteria लिखे जा सकते हैं, फिर एजेंट implementation करता है और कोई दूसरी चीज़ verification करती है

वास्तविक उपयोग के उदाहरण

• frontend बदलाव

  • spec file के आधार पर acceptance criteria बनाए जाते हैं
    • AC-1: valid credentials के साथ /login पर जाने पर /dashboard पर redirect हो और session cookie सेट हो
    • AC-2: गलत password डालने पर ठीक वही संदेश "Invalid email or password" दिखे और /login page पर ही रहे
    • AC-3: अगर fields खाली हों तो submit button disabled हो या inline error दिखे
    • AC-4: 5 बार असफल होने के बाद 60 सेकंड तक login block हो और waiting message दिखे
  • हर criterion को साफ़ तौर पर pass या fail में जाँचा जा सकता है
  • एजेंट feature बनाने के बाद, Playwright browser agent हर AC के लिए verification चलाता है, screenshots लेता है और criterion-वार report बनाता है
  • failure होने पर यह ठीक-ठीक पता चलता है कि कौन सा criterion fail हुआ और browser में क्या दिखा

• backend बदलाव

  • browser के बिना भी यही pattern लागू होता है
  • observable API behavior (status code, response headers, error messages) को define करके curl commands से verify किया जाता है

• सीमाएँ

  • spec की अपनी गलतफहमी को यह नहीं पकड़ सकता — अगर spec शुरू से गलत है, तो verification pass होने पर भी feature गलत हो सकता है
  • Playwright जिन चीज़ों को पकड़ता है: integration failures, rendering bugs, और real browser में टूटने वाला behavior
  • यह "verified correctness" जितना व्यापक दावा नहीं है, लेकिन code review आम तौर पर जितना reliably पकड़ पाता था, उससे अधिक चीज़ें पकड़ लेता है

• workflow सारांश

  • prompt से पहले acceptance criteria लिखो → एजेंट criteria के अनुसार implementation करे → verification चलाओ → सिर्फ failed चीज़ों को review करो (diff नहीं, failure review)

इसे बनाने का तरीका: 4-स्टेप pipeline

• Claude Skill के रूप में implementation (github.com/opslane/verify), claude -p (Claude Code headless mode) और Playwright MCP का उपयोग
• अलग custom backend या अतिरिक्त API keys की ज़रूरत नहीं, सिर्फ मौजूदा Claude OAuth token का उपयोग

• स्टेप 1: Pre-flight

  • pure bash, कोई LLM call नहीं
  • dev server चल रहा है या नहीं, auth session valid है या नहीं, spec file मौजूद है या नहीं — यह जाँचा जाता है
  • token खर्च होने से पहले जल्दी fail कर दिया जाता है

• स्टेप 2: Planner

  • Opus को एक बार call
  • spec और बदली गई files पढ़कर तय करता है कि हर verification के लिए क्या चाहिए और कैसे चलाना है
  • code पढ़कर सही selectors ढूँढता है, इसलिए class names का अनुमान नहीं लगाता

• स्टेप 3: Browser Agents

  • हर AC पर Sonnet को एक बार call, और सब parallel में चलते हैं
  • अगर 5 AC हैं, तो 5 agents स्वतंत्र रूप से navigation और screenshot capture करते हैं
  • Sonnet, Opus की तुलना में 3~4 गुना सस्ता है और click-आधारित tasks में समान performance देता है

• स्टेप 4: Judge

  • Opus की एक अंतिम call सभी evidence पढ़ती है और हर criterion के लिए निर्णय देती है: pass, fail, या needs-human-review

• installation

  • Claude Code plugin के रूप में install किया जा सकता है: /plugin marketplace add opslane/verify
  • या repo clone करके customize किया जा सकता है — हर step एक single claude -p call है, जिसमें साफ़ input और structured output होता है
  • model swap करना, steps जोड़ना, और --dangerously-skip-permissions option के साथ CI integration भी संभव है

मुख्य सीख

• सबसे महत्वपूर्ण बात यह है: "अगर आप पहले से done की definition स्पष्ट नहीं करते, तो आप परिणाम पर भरोसा नहीं कर सकते"
• acceptance criteria लिखना prompt लिखने से कठिन है, लेकिन यह edge cases पर पहले से सोचने के लिए मजबूर करता है और quality बढ़ाता है
• इंजीनियर TDD को जिस कारण ठुकराते थे, वही यहाँ भी है — शुरुआत में यह धीमा लगता है, इसलिए resistance होता है
  • acceptance criteria के बिना आप सिर्फ output पढ़कर उसके सही होने की उम्मीद कर सकते हैं
• यह AI-driven development environment में reliability सुनिश्चित करने की अनिवार्य प्रक्रिया है