Software Factory, रोशनी और अंधेरा

 (substack.com/addyo)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • Software Factory context इकट्ठा करने, action लेने और validation दोहराने वाले loop को harness में लपेटकर बड़े पैमाने पर चलाती है; यह इंसानों के निर्णय वाली bright factory और code review तक मशीनों को सौंपने वाली dark factory में बँटती है
  • code generation, test और scan लगभग बिना लागत के scale हो सकते हैं, लेकिन इंसानी review और judgment को scale करना मुश्किल है; इसलिए generation की मात्रा से ज़्यादा, नतीजों को सस्ते और भरोसेमंद तरीके से verify करने की रफ़्तार bottleneck बन जाती है
  • अगर लोग code नहीं पढ़ते, तो code के आकार और इंसानी समझ के बीच comprehension debt जमा होती जाती है; test लगातार pass होने पर भी लंबे समय से चल रहे जटिल systems में maintenance समस्याएँ बाद में सामने आ सकती हैं
  • पूरी automation सिर्फ़ उन छोटे loops में देनी चाहिए जिनके judgment criteria तुरंत मिलते हों, drift न करते हों और जिनसे छेड़छाड़ करना कठिन हो; authentication, payments और public API जैसे कामों में, जहाँ गलत फैसले की लागत और असर का दायरा बड़ा है, वहाँ इंसानी review बनाए रखना चाहिए
  • engineer की भूमिका हर बदलाव खुद लिखने से हटकर external loop को design और protect करने की तरफ़ जाती है; agent द्वारा किए गए diagnosis, implementation और testing के evidence को verify करना, approval देना और नतीजों की ज़िम्मेदारी लेना इसी का हिस्सा है

Loop से Software Factory तक

  • software को दोहराने योग्य और मापने योग्य production process बनाने का विचार Bob Bemer के 1968 के पेपर 「The economics of program production」 तक जाता है
    • ideas को car parts की तरह mass-produce करना मुश्किल था, इसलिए पिछले आधे century में ऐसे प्रयास ज़्यादातर उम्मीदों पर खरे नहीं उतरे
    • पिछले 2 साल के बदलाव इतने बड़े रहे हैं कि इस पुराने software factory vision पर फिर से विचार किया जा सकता है, लेकिन अतीत के pitfalls को नए अवसर की तरह पेश किया जा सकता है
  • पूरा ढाँचा loop, harness, factory की तीन layers से बना है
    • loop सबसे छोटी work unit है, जिसमें एक agent context इकट्ठा करता है, action लेता है, फिर result जाँचता है और termination condition पूरी होने तक इसे दोहराता है
    • loop engineering वह तरीका है जिसमें हर बार इंसान prompt डालने के बजाय agent को prompt देने वाला एक छोटा system design किया जाता है
    • harness में वह sandbox शामिल होता है जहाँ loop चलता है, उपलब्ध tools, runs के बीच बनी रहने वाली memory, और completion तय करने वाले gates शामिल होते हैं
    • harness के बिना model अंतहीन दोहराव में फँस सकता है, इसलिए harness loop को उपयोगी और सुरक्षित बनाता है
  • software factory वह structure है जो work queue से items लेकर कई harness-based loops को एक साथ चलाती है, review gates से गुज़ारती है और फिर production में भेजती है
    • यह कोई एक बड़ा agent नहीं, बल्कि loops से बना एक संगठनात्मक ढाँचा है
    • engineer की work unit भी individual code changes से हटकर loop, harness और loops के बीच flow तक शिफ्ट हो जाती है

Factory का workflow और bottleneck

  • engineering leadership का vision, engineers का intent, incidents और user requests से आए signals एक work queue में जाते हैं
    • harness items चुनता है, changes बनाता है, और CI, tests, static analysis और तरह-तरह के scans उन changes को साथ-साथ जाँचते हैं
    • review gate approval दे तो change deploy होता है, और production monitoring data फिर से काम शुरू कराने वाले signal के रूप में लौट आता है
  • generation, testing और scanning नगण्य लागत पर scale हो सकते हैं, लेकिन review gate पर इंसानी judgment को scale करना मुश्किल है
    • development speed और deployment frequency बढ़ेगी या नहीं, यह इसी judgment bottleneck को संभालने पर निर्भर है

Dark Factory और comprehension debt

  • manufacturing की dark factory वह facility है जो lights बंद करके चलती है क्योंकि machines को रोशनी की ज़रूरत नहीं होती
  • dark software factory में लोग code नहीं पढ़ते, और machine द्वारा बनाए गए code को उसी machine की validation के आधार पर deploy कर दिया जाता है
    • यहाँ darkness का मतलब नकारात्मक माहौल नहीं, बल्कि यह है कि diff लिखने, review करने और deploy करने की मानवीय प्रक्रिया गायब हो गई है
  • इंसानी review हटाने पर interruptions कम हो जाते हैं, और टीम की vertical throughput तेज़ी से बढ़ती हुई महसूस हो सकती है
    • लेकिन छिपी हुई लागतों की वजह से ऐसा workflow लंबे समय तक चलाना दिखने से ज़्यादा कठिन है
  • orchestration, sandbox-based prototyping और tool calling आगे भी शक्तिशाली होते रहेंगे, लेकिन सिर्फ़ harness के भरोसे लंबे समय तक codebase quality बनाए रखना काफ़ी नहीं है
  • comprehension debt उस अंतर को कहते हैं जो मौजूद code की मात्रा और इंसानों द्वारा सच में समझे गए code की मात्रा के बीच होता है
    • dark factory tests pass होते रहने पर भी comprehension debt तेज़ी से जमा करती है
    • छोटे code area में तुरंत होने वाले changes या weekend projects के विपरीत, 10+ साल से विकसित जटिल existing systems को expert speed से लगातार maintain करना पड़ता है
    • automation project को 3–6 महीने चलाने के बाद unread code की मात्रा भारी पड़ सकती है
  • जब Dex Horthy ने लगभग 4 महीने तक ऐसी fully automated factory चलाई जहाँ इंसान generated code नहीं देखते थे, तब समस्याओं की जड़ तक पहुँचने के लिए थकाऊ manual debugging करनी पड़ी
    • token usage जितना अधिक maximize किया गया, system को इंसान कितना समझते हैं यह उतना ही चुपचाप घटता गया
    • failure इस तरह भी आ सकता है कि tests pass करते रहने वाला पूरा system अचानक नहीं, बल्कि धीरे और चुपचाप टूटने लगे

Generation से ज़्यादा constraint verification क्यों है

  • back pressure वह सिद्धांत है जिसमें loops को उतनी ही autonomy दी जाती है जितनी सस्ते और भरोसेमंद verification की सीमा अनुमति देती है
    • लगभग असीम generation क्षमता और सीमित मानवीय attention के बीच का gap ही मूल समस्या है
    • verification window नहीं बढ़ती तो changes जमा होते जाते हैं, और भरोसेमंद gates के बिना सिर्फ़ volume बढ़ाने से low-quality PRs और manufactured defects पैदा होते हैं
  • model performance में सुधार generation और verification के बीच के gap को अपने-आप कम नहीं करता
    • अच्छी architecture की value seconds या minutes में नहीं, बल्कि महीनों और सालों में सामने आती है
    • architectural excellence के लिए साफ़ cost function या immediate evaluation signals निकालना कठिन है, इसलिए complex design decisions पर models को अच्छे examples से train करना भी मुश्किल है

रोशनी फिर से कैसे जलाएँ

  • bright factory में भी agents ज़्यादातर implementation करते हैं, लेकिन जहाँ गलत judgment की लागत बड़ी हो वहाँ रोशनी चालू रखी जाती है और इंसान output पढ़ने के बाद deploy करते हैं
  • इंसानी judgment को सिर्फ़ आख़िरी code review तक सीमित नहीं रखना चाहिए; इसे product, design और architecture stage तक ले जाना चाहिए, agent के loop शुरू करने से पहले
    • अगर पहले ही 1 घंटे में 200-line plan review कर लिया जाए, तो implementation के बाद 2,000 lines के generated code में design decisions ढूँढने वाली लंबी review कम हो सकती है
    • जितने costly और long-lasting decisions हों, implementation से पहले उतनी ही ज़रूरी है इंसानी भागीदारी; pre-review होने पर भी ज़रूरत पड़ने पर diff सीधे देखना चाहिए
  • safety net कोई नई technique नहीं, बल्कि जानी-पहचानी architectural practices से बनती है
    • अच्छे types और method signatures errors को production के बजाय compiler में पकड़ लेते हैं
    • test seams behavior को स्थिर रखते हैं और changes को observe करने देते हैं
    • code को ऐसे organize किया जाता है कि इंसान और model दोनों ज़रूरी हिस्से आसानी से ढूँढ सकें
    • call stack को छोटा और पढ़ने योग्य रखा जाता है
    • component boundaries को साफ़ रखा जाता है ताकि change impact सीमित रहे
    • dependency injection से components को बदला जा सके
  • ऐसी architecture automated coding agents की गलतियों को सस्ते और छेड़छाड़-प्रतिरोधी तरीके से रोकने की दूसरी भूमिका निभाती है
    • Claude Code और Codex जैसे agents अपने harness और tool usage पर reinforcement learning से trained हैं, लेकिन वे long-term maintainability अपने-आप नहीं देते
    • safety net model के बाहर मौजूद होना चाहिए, और architecture में investment अधिक autonomy को सुरक्षित तरीके से हासिल करने का साधन बनता है
  • सुरक्षित infrastructure के साथ कुछ छोटे और कम-risk वाले loops बिना इंसानी दखल के चल सकते हैं
    • उदाहरण के लिए, हर रात GitHub Actions cron anti-patterns, lint violations, या अनावश्यक रूप से optional किसी prop में ठीक एक issue fix करके commit कर सकता है और एक छोटा PR खोल सकता है
    • authentication systems, payment engines और public API contracts जैसे targets, जहाँ failure cost बड़ी होती है, वहाँ इंसानों को system knowledge और judgment के साथ review करना चाहिए

वे loops जो automation के योग्य हैं

  • किसी loop को पूरी तरह automate करने के लिए checks सस्ते हों, बार-बार चल सकें, और ऐसे criteria पर आधारित हों जिनसे आसानी से छेड़छाड़ न की जा सके
    • इसमें clear true/false लौटाने वाले judges, type gates, property-based tests, और real rubrics के साथ जुड़े review agents शामिल हैं
    • judgment तुरंत आना चाहिए और समय के साथ drift नहीं करना चाहिए
    • automation तभी संभव है जब completion state को सिर्फ़ इंसान नहीं, machine भी साबित कर सके
  • छोटे loops को लंबे loops की तुलना में verify करना आसान होता है
    • Dex के rule of thumb के अनुसार agents 3–10 steps में अच्छा काम करते हैं, लेकिन 20 steps पार करते ही flow खोने लगते हैं
    • context जमा होने के साथ agent के path से भटकने की संभावना बढ़ती है, और लंबे loops कोनों में errors छिपा देते हैं
  • अगर गलत जवाब की लागत बड़ी है और उसे सिर्फ़ इंसान ही पकड़ सकता है, तो रोशनी जलानी चाहिए
    • tests से न पकड़े जाने वाले subtle production bugs, व्यापक impact, या 1 साल से ज़्यादा का असर डालने वाले decisions ऐसे मामले हैं
    • ऐसे में मानवीय attention ही असली product है, और यह महँगा होने पर भी ज़रूरी resource है
  • सभी loops को एक ही mode में सेट करने से दोनों तरफ़ विफलता मिलती है
    • सब कुछ dark mode में चलाया तो कुछ महीनों बाद system को dismantle करना पड़ सकता है
    • सब कुछ bright mode में चलाया तो reviews बहुत बड़ा bottleneck बन जाएँगे
    • हर loop में किस बिंदु पर रोशनी जलानी है, यही मूल कौशल है

Loop को घेरने वाले graph और state machine

  • agent work को चाहे finite state machine कहा जाए या conditional service calls, अंततः इसके directed graph के रूप में बनने की संभावना ज़्यादा है
    • हर node एक explicit stage है, और nodes के बीच की edges explicit conditions हैं
    • हर code को control flow graph के रूप में दिखाया जा सकता है, इसलिए यह structure अपने-आप में नया नहीं है
    • agent की autonomy पूरे graph में नहीं, बल्कि हर node के अंदर सीमित रहती है
  • नई कोशिश यह थी कि flowchart हटा दिया जाए और model को हर tool call पर अपना path चुनने दिया जाए, फिर वह खुद completion घोषित करे
    • लेकिन पुराने codebase से टकराने के बाद control flow को फिर से अपने हाथ में लेने की दिशा, loop के आसपास पुराने graph को बहाल करने जैसी लगती है
  • bug fix work pure loop और graph में अलग तरह से आगे बढ़ता है
    • pure loop में issue investigation, code change, test selection और execution order, retries और completion judgment सब कुछ चलते-चलते तय होता है
    • graph में bug reproduction या अतिरिक्त जानकारी का अनुरोध, root cause identification, fix, test और review पहले से path के रूप में define होते हैं
    • test failure होने पर flow fix stage पर लौटता है, success होने पर review में जाता है, और approval मिलने पर ही completion होता है
    • agent हर node के भीतर बुद्धिमानी से काम करता है, लेकिन अनधिकृत path पर भटक नहीं सकता
  • graph, back pressure की visualization है
    • agent की कुछ freedom छोड़ने के बदले ज़रूरी checks और पढ़े जा सकने वाले failure points मिलते हैं
    • execution fail हो तो यह पहचाना जा सकता है कि किस node ने उसे रोका
  • 12-factor agents के approach की तरह, कई agent systems “ज़्यादातर deterministic code जिसमें सही जगहों पर LLM steps मिलाए गए हों” जैसे दिखते हैं
    • यही pattern LangGraph, LlamaIndex Workflows, Jerry Liu के agents के ऊपर बने hybrid workflow graphs, और David Khourshid द्वारा जोड़े गए state machines तथा actor model में भी दिखाई देता है
  • यहाँ graph का मतलब knowledge graph नहीं, बल्कि workflow और conditional edges पहले से define करने वाला directed graph है

इंसान external loop के मालिक रहते हैं

  • factory में इंसान गायब नहीं होते; वे execution line से हटकर external loop में चले जाते हैं
    • agents bug investigation, diagnosis लिखना, fix implement करना, tests चलाना और result report करना जैसे internal loops चलाते हैं
    • engineers तय करते हैं कि समस्या सही तरीके से हल हो रही है या नहीं, diagnosis और implementation को verify करते हैं, changes approve करते हैं और गलत results की ज़िम्मेदारी लेते हैं
  • internal loop और external loop की सीमा पर diff, tests, logs और उन्हें जोड़ने वाली छोटी explanation जैसे evidence रखे जाते हैं
    • अगर types, test seams और evaluation rubrics मौजूद हों, तो हर change पर भारी manual काम किए बिना भी agent execution की निगरानी की जा सकती है
  • engineer की position production line पर सीधे changes लिखने वाली भूमिका से हटकर line को design करने और gates की रक्षा करने वाली भूमिका में बदलती है
    • models और harness बेहतर हो सकते हैं, लेकिन लंबे समय में महँगी समस्याओं की पहचान करने वाले इंसानी judgment को automate करना कठिन है
    • सबसे खतरनाक स्थिति वह है जब पूरा workspace dark कर दिया जाए और इंसान न देख पाएँ कि क्या चल रहा है, यहाँ तक कि light switch भी न मिले

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.