Agentic Engineering Patterns

 (simonwillison.net)
82 पॉइंट द्वारा GN⁺ 2026-03-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Claude Code और Codex जैसे coding agents के युग में development के तरीके को व्यवस्थित करने वाली गाइड, जो agents के साथ सहयोग के लिए नए engineering patterns प्रस्तुत करती है
  • ऐसे माहौल में जहाँ code लिखने की लागत तेज़ी से कम हो गई है, development habits और workflow को कैसे बदलना चाहिए इसे विभिन्न patterns के माध्यम से समझाया गया है
  • principles, testing, code understanding, prompt design जैसे agent-centric development के मुख्य क्षेत्रों को संरचित रूप में व्यवस्थित किया गया है
  • हर pattern में वास्तविक code examples, काम करने के तरीके, और prompt उपयोग के उदाहरण शामिल हैं, यानी यह व्यावहारिक pattern documentation के रूप में तैयार किया गया है
  • coding agent के युग में developers के लिए agent-based coding environment को व्यवस्थित रूप से डिज़ाइन करने और quality बनाए रखने हेतु उपयोगी संदर्भ सामग्री

Agentic Engineering Patterns अवलोकन

  • coding agents (Claude Code, OpenAI Codex आदि) के साथ development करते समय प्रभावी engineering तरीकों को व्यवस्थित करने वाली गाइड
  • Writing about Agentic Engineering Patterns परिचय लेख देखें
    • पारंपरिक “Design Patterns” फ़ॉर्मेट की तरह कई patterns (chapters) को लगातार जोड़े जाने वाली संरचना वाला दस्तावेज़
    • ऐसे वातावरण में जहाँ code लिखने की लागत बहुत कम हो गई है, developers के workflow और decision-making style में बदलाव को केंद्रीय विषय बनाया गया है
    • यह blog post नहीं बल्कि अपडेट किया जा सकने वाला guide-format content है, जिसे आगे भी लगातार विस्तार दिया जाएगा

1. Principles

  • Writing code is cheap now

    • AI coding agents के आने से शुरुआती code लिखने की लागत लगभग नगण्य स्तर तक घट गई है
    • पहले code लिखना महंगा था, इसलिए development design और planning-केंद्रित होता था, लेकिन अब ideas को तुरंत code में परखने वाला approach संभव है
    • code generation की लागत कम हुई है, लेकिन अच्छा code (testing, maintainability आदि) अब भी लागत मांगता है

  • Hoard things you know how to do

    • developer की महत्वपूर्ण संपत्ति है “क्या संभव है, इस ज्ञान का संचय”
    • विभिन्न problem-solving cases और छोटे code experiments को सहेजकर reusable रूप में जमा करने की आदत पर ज़ोर
    • इस तरह जमा किए गए code और examples को coding agents को नई functionality बनाने का निर्देश देते समय शक्तिशाली input material के रूप में उपयोग किया जा सकता है

  • Anti-patterns: things to avoid

    • agent द्वारा बनाए गए code को भी review के बिना share करना या PR submit करना बचने योग्य anti-pattern है
    • agent द्वारा लिखे गए PR description को भी इंसान को खुद verify और edit करना चाहिए
    • code reviewer का समय बर्बाद न हो, इसके लिए tests, verification process, और implementation choices के कारण भी साथ देने चाहिए

2. Testing and QA

  • Red/green TDD

    • test-first development (TDD) coding agents के साथ उपयोग करने पर विशेष रूप से प्रभावी development pattern है
    • test पहले लिखने पर agent tests को satisfy करने वाली दिशा में code generate कर सकता है
    • बहुत कम prompts के साथ भी सटीक और भरोसेमंद code generation में मदद मिलती है

  • First run the tests

    • coding agents के साथ काम करते समय automated tests विकल्प नहीं बल्कि आवश्यक तत्व हैं
    • ऐसे वातावरण में जहाँ tests लिखने की लागत कम हो गई है, agent tests को तेज़ी से generate और modify कर सकता है
    • जब तक code वास्तव में run न हो जाए, उसके सही काम करने की गारंटी नहीं दी जा सकती, इसलिए tests महत्वपूर्ण हैं

3. Understanding code

  • Linear walkthroughs

    • agent द्वारा बनाए गए code या project को शुरू से अंत तक क्रम से पढ़कर उसकी संरचना समझने का pattern
    • छोटे project में भी code flow का अनुसरण करते हुए नई technologies और structure सीखे जा सकते हैं
    • AI code generation सीखने की गति धीमी कर देगा, इस चिंता के जवाब में code exploration स्वयं सीखने का अवसर बन सकता है

  • Interactive explanations

    • code या system को समझते समय agent से बातचीत करते हुए explanation माँगने का तरीका
    • सवालों को दोहराते हुए code के काम करने के सिद्धांत और structure को धीरे-धीरे समझा जा सकता है
    • code understanding की प्रक्रिया को interactive learning style तक विस्तारित करने वाला pattern

4. Annotated prompts

  • GIF optimization tool using WebAssembly and Gifsicle

    • WebAssembly और Gifsicle-आधारित GIF optimization tool बनाने का prompt example शामिल
    • HTML, JavaScript, CSS सहित single-page tool implementation का तरीका प्रस्तुत
    • वास्तविक prompts और code examples के माध्यम से coding agents के उपयोग का तरीका समझाया गया है

5. Appendix

  • Prompts I use

    • वास्तव में उपयोग किए जा रहे coding agent prompt examples का संग्रह
    • विभिन्न कार्यों में उपयोग होने वाले व्यावहारिक prompt patterns को व्यवस्थित किया गया है
    • agent के साथ सहयोग करते समय इस्तेमाल किए जा सकने वाले उपयोगी templates प्रदान किए गए हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-03-05
Hacker News की राय

  • लगता है हम फिर वही काम दोहराने वाले हैं
    सरल और तर्कसंगत अवधारणाएँ — जैसे "पहले tests लिखो", "छोटे और composable modules बनाओ" — को किसी जटिल नाम में पैक करके, उससे फिर एक consultant industry खड़ी कर दी जाएगी
    बस इस बार लक्ष्य है "बोलने वाली मशीनें"। जैसे बस उनसे बोलकर काम करवा लो

    • COBOL ने भी कुछ ऐसा ही वादा किया था। कहा गया था कि यह इंसानों के लिए पढ़ने में आसान भाषा है, इसलिए programmers की ज़रूरत नहीं रहेगी। लेकिन आखिरकार समस्याओं को तोड़कर हल करने के लिए इंसान को programmer की तरह सोचना ही पड़ा। यानी भाषा human-friendly होने से programmer गायब नहीं हो जाते
    • इस बार भी शायद AI boom का cycle दोहराया जाएगा। अभी अगर आलोचना करो तो जवाब मिलता है कि "आप समझते नहीं हैं", लेकिन जल्दी ही समस्याएँ सामने आने लगेंगी। खासकर "AI इतना ज़्यादा code generate करेगा कि न इंसान, न AI उसे संभाल पाएँगे" जैसी स्थिति आएगी। तब फिर से patterns और anti-patterns, और उन्हें सुलझाने का दावा करने वाले consultants प्रकट होंगे
    • AI अंग्रेज़ी में बात करता है और समझता भी है, इसलिए interface की स्पष्टता कम हो जाती है। यह CLI जितना ताकतवर है, लेकिन कौन-सा तरीका असरदार है यह साफ़ नहीं है। इसलिए "क्या और कैसे कहने पर अच्छे नतीजे मिलते हैं" इसे document और share करना ज़रूरी है। बस यह फिर से OOP coaching industry जैसा विकृत रूप न ले ले
    • हाँ, ऐसा फिर होगा, और इस बार बहुत तेज़ी से होगा। blogger → speaker → book → consultant → certification body वाला 10 साल का cycle कुछ ही वर्षों में compress होकर दिखाई देगा
    • मैं इस बात से सहमत नहीं हूँ कि लेख का शीर्षक ज़रूरत से ज़्यादा जटिल है। लेकिन "बस बोलकर कह दो और हो जाएगा" वाली गलतफ़हमी समस्या है। असल में लोगों के नतीजे बहुत अलग-अलग आते हैं। अंततः सबक यही निकल रहा है कि "जो development habits इंसानों के लिए अच्छी हैं, वही AI के लिए भी अच्छी हैं"। AI इंसानों जैसा लगता है, लेकिन इंसान नहीं है। इसलिए उसे ज़्यादा स्पष्ट निर्देश चाहिए

  • मैं Simon से पूछना चाहता हूँ — "code सस्ता हो जाने वाली दुनिया में code review कैसे किया जाए?"
    team members structure समझे बिना "चल रहा है तो ठीक है" वाले अंदाज़ में काम कर रहे हैं। reviews लगातार बड़े होते जा रहे हैं, और bottleneck मैं बन रहा हूँ। मैंने AI reviewer को delegate की तरह इस्तेमाल करने का भी सोचा, लेकिन मुझे यह पसंद नहीं कि उसमें मानवीय संवेदना गायब हो जाए

    • यह वाकई दिलचस्प विषय है। अगर code generation की रफ़्तार बढ़ती है, तो review bottleneck बन जाता है। अगर code सस्ता है तो review standards कम किए जा सकते हैं, लेकिन मैं तो उल्टा और बेहतर quality चाहता हूँ। खासकर security review को कभी छोड़ा नहीं जा सकता। शायद बड़े संगठनों की security teams जैसी व्यवस्थित approach चाहिए होगी
    • अगर agent-based review इस्तेमाल करना है, तो context setting बहुत महत्वपूर्ण है। plan → execute → test/fix → review/refactor → QA guide generation वाला loop चलाने पर सिर्फ code ही नहीं, बल्कि documentation और test guidelines भी साथ में evolve करते हैं
    • "चल रहा है तो ठीक है" तकनीकी समस्या नहीं, बल्कि organizational culture की समस्या है। कुछ कंपनियाँ अब भी readable code को महत्व देती हैं। वही उनकी प्रतिस्पर्धी बढ़त भी बन सकती है
    • मैं static·dynamic analysis automation में निवेश करता हूँ। custom lint rules, strong type checking, mutation testing जैसे quality tools का सक्रिय उपयोग करता हूँ। सिर्फ review पर निर्भर रहना धीमा और अप्रभावी है, इसलिए early feedback automation ही कुंजी है
    • ऐसा रवैया आसानी से नहीं बदलता। शायद software quality को महत्व देने वाली team में चले जाना ही बेहतर हो सकता है

  • मैं AI का इस्तेमाल मुख्यतः boilerplate code या documentation से जुड़ी समस्याएँ सुलझाने के लिए करता हूँ
    agentic तरह के काम भी किए हैं, लेकिन output अभी भी भरोसेमंद नहीं लगता। फिर भी कुछ लोग कहते हैं कि "अब वे लगभग code लिखते ही नहीं"। यह अंतर दिलचस्प है

    • मेरे लिए कई बार खुद coding करना AI से तेज़ होता है। planning, execution और verification का process ही उल्टा धीमा पड़ जाता है। लेकिन large-scale refactoring में AI बहुत तेज़ है
    • पिछले कुछ महीनों में agents की performance तेज़ी से बढ़ी है। अब यह सिर्फ simple autocomplete से आगे बढ़कर पूरे feature implementation तक पहुँच गया है
    • शायद इसे उन developers और बाकी लोगों के बीच के फ़र्क से समझा जा सकता है, जो AI code देखकर 'अजीब-सा eww एहसास' महसूस करते हैं या नहीं करते
    • अंततः काम के प्रकार के अनुसार साफ़ बँटवारा है कि कहाँ AI फ़िट बैठता है और कहाँ नहीं
    • मुझे भी पहला output पसंद नहीं आता, लेकिन review loop कई बार चलाने पर quality निश्चित रूप से बेहतर हो जाती है। अगर AI से AI का review कराया जाए या test criteria स्पष्ट किए जाएँ, तो नतीजे बहुत बेहतर होते हैं

  • मैं हाल में agentic coding loop पर प्रयोग कर रहा हूँ
    उदाहरण के लिए, fesh project में लक्ष्य था "Linux binaries को और छोटा compress करना"। यह स्पष्ट tests वाला problem था, इसलिए AI loop के लिए उपयुक्त था
    सीखी गई बातें ये हैं:

    • test harness ही सब कुछ है। verification loop न हो तो दिशा भटक जाती है
    • AI को प्रयोगात्मक तरीके से कोशिश करने देना महत्वपूर्ण है
    • sessions के बीच .md scratchpad छोड़ना चाहिए ताकि learning जारी रह सके
    • tests वाकई बहुत महत्वपूर्ण हैं। AI अजीब तरीकों से fail होता है, इसलिए test auto-generation का सक्रिय उपयोग करना चाहिए
    • tests के बिना loop के नतीजों पर भरोसा नहीं किया जा सकता। deterministic verification procedure अनिवार्य है
    • decision log और rejection log को अलग-अलग रिकॉर्ड करना उपयोगी रहा। खासकर rejections.md ज़्यादा मूल्यवान था। "इस approach को क्यों छोड़ा गया" यह दर्ज रहना चाहिए, ताकि AI वही गलती बार-बार न दोहराए
    • browser automation में भी ऐसा ही है। सिर्फ functional verification नहीं, बल्कि behavioral verification (क्या यह इंसान जैसा दिखता है?) भी जोड़ना पड़ता है, तभी चीज़ उपयोगी बनती है। और .md logs अगले session की quality को काफ़ी बढ़ा देते हैं

  • अच्छा होता अगर test section में LLM द्वारा बनाए गए 'self-fulfilling tests' की समस्या भी शामिल होती
    कई बार tests असल में कुछ verify ही नहीं करते, या फिर hardcoded values की वजह से pass हो जाते हैं। इंसानों को AI को सख़्त testing habits की ओर धकेलना होगा

    • मैं ठोस उदाहरण जानना चाहूँगा। शायद बात सिर्फ simple logical errors की नहीं, बल्कि ऐसे tests की है जो ऊपर-ऊपर ठीक लगते हैं लेकिन वास्तव में निरर्थक होते हैं
    • खराब tests, tests न होने से भी ज़्यादा ख़तरनाक हैं। एक बार भरोसा टूट जाए, तो पूरे test suite पर विश्वास ही खत्म हो जाता है
    • इसलिए mutation testing महत्वपूर्ण है। अगर code बदलने पर भी tests pass हो जाएँ, तो वह खराब test है
    • AI से code के कुछ हिस्से जानबूझकर बदलवाकर देख सकते हैं कि test fail होता है या नहीं। अगर fail नहीं होता, तो वह बेकार test है
    • बेशक इंसानों से भी ऐसे tests लिखवाना आसान नहीं है

  • LLM की हर नई पीढ़ी आने पर लगता है कि पहले के सबक पूरी तरह अमान्य हो जाते हैं
    LangChain जैसी जटिल संरचनाएँ, जो पुराने models की सीमाओं को bypass करने के लिए बनाई गई थीं, GPT-3.5 के बाद अनावश्यक हो गईं। संभव है कि जल्द ही एक single agent भी सब कुछ संभालने के लिए काफ़ी हो

    • इसलिए मैं model version पर निर्भर न रहने वाले patterns को व्यवस्थित करने की कोशिश कर रहा हूँ। उदाहरण के लिए red/green TDD शायद जल्द ही model खुद करने लगे, लेकिन अवधारणा अपने आप में अब भी उपयोगी है
    • आखिर में सब कुछ शायद ClaudeVM जैसी किसी दिशा में converge कर सकता है
      संबंधित लेख देखें

  • agent engineering की चर्चा में एक बात अक्सर छूट जाती है
    ज़्यादातर सीखों को सार्वभौमिक सत्य की तरह बताया जाता है, लेकिन वास्तव में वे team size, codebase maturity, testing level, और risk tolerance के अनुसार बदलती हैं। महत्वपूर्ण बात यह स्पष्ट करना है कि "यह pattern कब काम करता है"

    • इसलिए मैं किताब की जगह website के रूप में patterns को व्यवस्थित कर रहा हूँ। इसे लगातार update करूँगा और लागू होने की सीमा भी बताऊँगा
    • consultant के रूप में कई codebases के साथ काम करते हुए देखा है कि Claude Code की performance codebase quality के अनुसार चरम स्तर तक बदलती है। strong typing और tests वाले projects में यह लगभग पूरी तरह काम करता है, लेकिन loose JavaScript environment में इतना अच्छा नहीं
    • फिर भी कुछ patterns सार्वभौमिक हैं। उदाहरण के लिए independent source of truth (harness) रखना हर जगह उपयोगी है। showboat, rodney जैसे tools उसी में मदद कर रहे हैं

  • आजकल "agent team frameworks" हर दिन दर्जनों की संख्या में सामने आ रहे हैं
    यह शुरुआती software engineering की तरह अव्यवस्थित प्रयोग का दौर है। लेकिन अंततः कुछ patterns standard बन जाएँगे।
    हमारी team के लिए human team जैसी approach कारगर रही — पहले product spec लिखो, फिर AI से उसे refine कराओ, और फिर उसी के आधार पर role-separated agent flow को सौंप दो

  • आज मैंने undergraduate class में CPU·GPU architecture के evolution पर lecture दिया
    पहले Moore’s Law की वजह से hardware लगभग सब कुछ संभाल लेता था, लेकिन अब parallelism ही कुंजी है।
    Simon का कहा हुआ "code सस्ता है" वाला विचार भी इसी तरह का paradigm shift है।
    जैसे parallel hardware के युग में efficient code पूरी तरह बदल गया, वैसे ही AI के युग में development process खुद बदल जाएगा। जो लोग इसे पहले समझेंगे, उन्हें 10~100x का लाभ मिलेगा

  • हमारी team में 'बीच-बीच में human validation डालने वाला loop' सबसे व्यावहारिक रहा
    पूरी तरह autonomous agents कई बार tests तो pass कर देते हैं, लेकिन implicit invariants तोड़ देते हैं।
    इसलिए irreversible decisions से ठीक पहले इंसान को intervene कराया जाता है।
    लेकिन "क्या irreversible है" यह AI को समझाना अपने आप में एक अलग चुनौती है।
    CLAUDE.md जैसे documents के अलावा हम implicit codebase rules को पहुँचाने का कोई व्यवस्थित तरीका ढूँढ रहे हैं