Loop Engineering - Addy Osmani

AI coding agents के अगले चरण के रूप में प्रस्तावित ‘Loop engineering’

यह लेख Addy Osmani के “Loop engineering” पर केंद्रित है और इस विचार पर चर्चा करता है कि coding agents को हर बार इंसान द्वारा सीधे निर्देश देने के तरीके से आगे बढ़कर, ऐसे iterative system डिज़ाइन किए जा सकते हैं जिनमें agent खुद काम ढूँढे, उसे बाँटे, सत्यापित करे, और अगला काम तय करे। यहाँ loop का मतलब लगभग “किसी तय लक्ष्य की ओर AI द्वारा कई बार दोहराया जाने वाला workflow” है। हालांकि, लेख इसे किसी सर्वसमर्थ समाधान की तरह नहीं देखता। यह token cost, verification की ज़िम्मेदारी, और developers की समझ में गिरावट जैसी वास्तविक लागतों पर भी ज़ोर देता है.

मुख्य सार

Loop engineering का मतलब

अब तक developer coding agent को prompt लिखता था, नतीजा पढ़ता था, और फिर दोबारा निर्देश देता था। लेख के अनुसार loop engineering इस प्रक्रिया को automated structure में बदलने का एक तरीका है। यानी हर बार इंसान के निर्देश देने की जगह, “क्या खोजना है, कैसे process करना है, और कब रुकना है” — इसे system के रूप में डिज़ाइन किया जाता है।

घटक

लेखक loop बनाने के लिए automated execution, worktree, skills, plugins और connectors, sub-agents, और external memory जैसे तत्वों का प्रस्ताव करते हैं। Worktree एक Git फीचर है जो एक ही repository को कई workspaces में बाँटकर conflicts कम करता है। Skills वह व्यवस्था है जिसमें project rules और knowledge को दस्तावेज़ित किया जाता है ताकि agent को हर बार अनुमान न लगाना पड़े। Connectors वे रास्ते हैं जो Linear, Slack, database जैसे external tools से जोड़ते हैं।

फायदे

दोहराए जाने वाले काम कम करने के लिहाज़ से CI failure summary, issue classification, और हाल की commits की समीक्षा जैसे काम automate किए जा सकते हैं। Parallel processing के लिहाज़ से कई agents अलग-अलग worktree में काम करके file conflicts कम कर सकते हैं। Knowledge reuse के लिहाज़ से project practices और build procedures को skills के रूप में सहेजकर हर session में वही बातें दोहराने की ज़रूरत नहीं रहती।

कमियाँ और जोखिम

Verification का बोझ खत्म नहीं होता। Loop द्वारा बनाए गए नतीजों की जाँच अब भी इंसान को करनी होगी। Token cost भी बढ़ सकती है। Sub-agents बढ़ने पर हर agent अलग से model और tools का उपयोग करता है। समझ की देनदारी भी एक समस्या है। अगर developer नतीजों को पढ़े बिना स्वीकार करता जाए, तो codebase भले बड़ा होता जाए, लेकिन इंसान की वास्तविक समझ का दायरा घट सकता है।

अंतर

जहाँ सामान्य prompt engineering का फोकस “एक बार में अच्छा सवाल” पर होता है, वहीं loop engineering “दोहराए जा सकने वाले task system” को डिज़ाइन करने के अधिक करीब है। लेखक का मानना है कि Codex और Claude Code में automation, skills, MCP-आधारित connections, और sub-agents जैसे मिलते-जुलते components होने के साथ, अब tools से ज़्यादा loop design एक महत्वपूर्ण चिंता बनती जा रही है।

विशेषताएँ

लेखक और verifier को अलग करना इसकी एक अहम विशेषता है। जो agent code बनाता है, अगर वही अपने नतीजों का मूल्यांकन करे तो वह नरम पड़ सकता है, इसलिए अलग sub-agent से review करवाने वाली संरचना सुझाई गई है। External memory को बनाए रखना भी मुख्य बात है। Markdown files या issue board की तरह, conversation के बाहर state को बचाकर रखना पड़ता है ताकि अगली run में उसे आगे बढ़ाया जा सके।

Loop engineering को developers की जगह लेने की कहानी की तरह नहीं, बल्कि developers के हस्तक्षेप के बिंदु बदलने की कहानी की तरह पढ़ा जा सकता है। लगातार सीधे prompt लिखने के काम से हटकर, ज़ोर iterative structure, verification conditions, task distribution, और record-keeping के डिज़ाइन पर शिफ्ट होता है। लेकिन अच्छा loop भी अच्छे judgment की जगह नहीं ले सकता। अगर code पढ़ने, verify करने, और system की सीमाओं को समझने की engineering क्षमता नहीं है, तो automation गति से पहले जोखिम को बढ़ा सकती है।