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

• 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 सुनिश्चित करने की अनिवार्य प्रक्रिया है

[github88]

चाहे जितना भी TDD कर लें, मौजूदा स्तर पर LLM टेस्ट्स में हेरफेर करके उन्हें पास करवा देता है, इसलिए इंसानी रिव्यू बिल्कुल ज़रूरी है..

[GN⁺]

Hacker News टिप्पणियाँ

• आजकल के LLM framework उल्टा development को और मुश्किल और महंगा बना रहे हैं
  सिर्फ default settings से भी काफ़ी आगे जाया जा सकता है, और जब models लगातार बदल रहे हों तो इतने wrappers और harnesses बनाना अक्षम लगता है
  रात भर चलाकर पैसे जलाने वाला यह तरीका बाद में शायद PHP meme की तरह मज़ाक बनकर रह जाएगा

  • लेकिन AI boom में अगर आप shovel seller की स्थिति में हैं, तो बात अलग है
    लेख के अनुसार, “पिछले 6 महीनों में 100 से ज़्यादा engineers के लिए Claude Code workshops कराई गईं”
  • मैं चाहता हूँ कि competitors अपने codebase में ज़्यादा से ज़्यादा AI agents इस्तेमाल करें
    जब वे दिन-रात चलाते-चलाते आखिरकार AI companies दिवालिया हो जाएँ और पीछे सिर्फ 80% AI-लिखा spaghetti code बचे, तब देखेंगे कौन हँसता है
  • PHP का मज़ाक उड़ाना ठीक नहीं है। आज भी मेरे कुछ बेहतरीन projects PHP में बने हैं
    मुझे लगता है कि 15 साल पहले PHP में जो बनाया था, वह आज के full-stack JS/TS environment से बेहतर था
  • अब जाकर समझ आता है कि पुराना anti-PHP meme कितना मूर्खतापूर्ण था
    PHP अब भी ज़िंदा है और evolve कर रहा है। LLM tooling भी आखिरकार ऐसे ही बुनियादी tools बन जाएगी
  • यह सिर्फ काम बढ़ने की बात नहीं, बल्कि roles का fusion है
    BA, PO, QA, SWE की सीमाएँ धुंधली हो रही हैं। अब business और development के बीच hybrid roles उभर रहे हैं

• लगता है आजकल लोग agents सिर्फ इसलिए चला रहे हैं कि agents चलाने हैं
  मैं writing और review के लिए सिर्फ दो ही चलाता हूँ, और उससे भी 5~7x productivity आराम से मिलती है
  मैं spec review पर ज़्यादा समय देता हूँ, और coding agent 10~30 मिनट में कर देता है, इसलिए कोई जल्दी नहीं रहती

  • “रात भर चलने वाले agents” का concept समझ नहीं आता। Claude ज़्यादातर 5~20 मिनट में काम खत्म कर देता है
    कल भी काम रहेगा, तो उसे रात भर चलाने की ज़रूरत नहीं है
  • मैंने भी शुरुआत में कई agents parallel चलाए थे, लेकिन आखिर में एक directory पर focus करना कहीं ज़्यादा efficient निकला
  • SWE जो काम करते थे, उसका बड़ा हिस्सा अब AI brute force से संभाल सकता है
    ग्राहक की नज़र से bug भारत, San Francisco या AI—कहीं से भी आए, फ़र्क बहुत कम है
  • मैं भी सिर्फ दो agents चलाता हूँ और काफ़ी fine-tuning करता हूँ
    यह आजकल के popular ‘agent orchestra’ से काफ़ी ज़्यादा controlled तरीका है
  • मेरे हिसाब से spec validation सबसे अहम चरण है
    इसी वजह से मैंने खुद verify skill बनाया, ताकि देख सकूँ कि Claude spec को सही तरह follow कर रहा है या नहीं

• Claude से red-green-refactor pattern का इस्तेमाल करवाने पर test quality सच में बेहतर होती है
  इससे आगे red/green/refactor sub-agents बनाकर उन्हें एक-दूसरे को verify करवाना भी काफ़ी अच्छा काम करता है
  असली बात यह है कि context को mix नहीं करना चाहिए

  • लेकिन refactoring शुरू होते ही अक्सर tests बेकार हो जाते हैं या छूट जाते हैं
    reward hacking सच में मौजूद है, और इससे बचाव करना मुश्किल है
  • red/green TDD करवाने पर भी यह ऐसे tests लिख देता है जो fail ही नहीं होते, और फिर कह देता है “पहले से solve है”
    यह guide देखने के बाद भी bad tests की समस्या बड़ी रहती है
  • मैंने Outside-in TDD को Claude Code में पूरी तरह लागू किया है
    नतीजे अच्छे रहे, इसलिए principles और examples और starter repo सार्वजनिक किए हैं
  • green/red/refactor pattern को implement करने का तरीका और विस्तार से जानना चाहता हूँ। कोई reference material हो तो अच्छा होगा
  • PR review में भी यह approach असरदार है
    author और verifier को अलग रखना ज़रूरी है, और same model होने पर भी context अलग रखने से quality बढ़ती है

• मौजूदा LLM context limitations की वजह से असली agents अभी संभव नहीं हैं
  500 lines से ऊपर code में errors तेज़ी से बढ़ते हैं, और लगभग 200 lines के आसपास इसकी सीमा है
  आखिरकार LLM बस calculator की तरह बार-बार इस्तेमाल होने वाला tool है

• मैं इस phenomenon को “Test Theatre” कहता हूँ
  इस पर यहाँ लिखा है। इसे सक्रिय रूप से avoid करना चाहिए

  • agent कभी 100 lines code पर 600 lines tests भी लिख देता है, लेकिन उनमें से ज़्यादातर बेमतलब tests होते हैं
    अच्छे tests को design patterns और dependencies verify करनी चाहिए, और debugging में मदद करनी चाहिए
  • property testing का इस्तेमाल करने पर कहीं बेहतर नतीजे मिलते हैं
    उदाहरण के लिए, Schemathesis से user permissions या 5xx responses को automatically verify किया जा सकता है
  • Test Theatre बिल्कुल सही शब्द है। test pass होने पर भी असल में कुछ साबित नहीं होता
  • सबसे अच्छा तरीका Outside-in TDD + mutation testing को enforce करना है
    इससे जुड़ा POC मैंने यहाँ डाला है
  • सच कहें तो ऐसा formalistic testing पहले से मौजूद था। ज़्यादातर tests implementation को ही test करते हैं

• हाल में मैं agent orchestration पर प्रयोग कर रहा हूँ
  असली बात LLM calls कम करना और उन्हें deterministic script pipeline से जोड़ना है
  विस्तार से इस पोस्ट में लिखा है

  • मैं भी इसी तरह script-centric orchestration आज़मा रहा हूँ
    इस experiment log की तरह, यहाँ भी LLM से ज़्यादा scripts अहम हैं

• मैं business operations agents के 6 instances चला रहा हूँ
  market research, content writing, video scripts जैसी कई भूमिकाएँ इन्हें देता हूँ
  “रात भर चलाना” कुछ बढ़ा-चढ़ाकर कहा गया concept है; असल में clear goals और narrow scope ज़्यादा असरदार होते हैं
  असली bottleneck execution नहीं बल्कि context management है

  • दिलचस्प approach है। आप कौन-सा product बना रहे हैं, और क्या Reddit-based research अभी भी effective है, यह जानने की उत्सुकता है

• समझ नहीं आता कि यह व्यक्ति वास्तव में बना क्या रहा है
  LinkedIn पर बस Claude से जुड़ी पोस्ट्स ही दिख रही हैं

  • जिस code को verify भी नहीं कर सकते, उसे deploy करना गंभीर risk है
    किसी serious business में यह सोचा भी नहीं जा सकता
  • 25 साल के industry experience में मैंने कभी ऐसी company नहीं देखी जिसे इतनी तेज़ी से code चाहिए हो
    आखिर में code खाली पड़ा रहता है क्योंकि लोग सोच रहे होते हैं कि इसे बेचा कैसे जाए

• यह वैसी ही समस्या है जैसी सिर्फ tests लिखने वाले व्यक्ति को hire करने पर होती है
  आखिर में बस यह verify होता है कि “code वैसा ही काम कर रहा है जैसा code लिखा गया है”
  साफ़ spec definition कहीं ज़्यादा महत्वपूर्ण है

  • बाद में लिखे गए tests ज़्यादातर tautological validation होते हैं
    दूसरे engineering fields ऐसी गलती बार-बार नहीं दोहराते, इसलिए software में यह बात चौंकाती है
  • tests की असली value regression prevention में है
    भले initial release गलत हो, फिर भी बाद में behavior न बदले, यह वे सुनिश्चित करते हैं
  • tests का उद्देश्य आखिरकार mock verification ही है
  • पहले spec define करना और उसी के हिसाब से verify करना असली बात है
    कई consulting companies acceptance criteria-based validation के आधार पर काम करती हैं

• आज का AI development में मदद करने वाला tool नहीं, बल्कि developers को replace करने के स्तर तक पहुँच रहा है
  यह गंभीर समस्या है कि अब हम code को न control कर पा रहे हैं, न verify
  यह development का नया तरीका कम और समझ की जगह भरोसे पर टिके धार्मिक बदलाव जैसा ज़्यादा लगता है

  • मैं ऐसा code जिसे मैं समझता नहीं कभी deploy नहीं करता
    autonomy कम हो तो भी मैं सिर्फ verify किया जा सकने वाला code ही merge करता हूँ
  • या फिर formal methods जैसे tools से code security सुनिश्चित करने की दिशा में जाना होगा