बड़े codebase के लिए LLM को स्केल करना

 (blog.kierangill.xyz)
9 पॉइंट द्वारा GN⁺ 2025-12-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • बड़े codebase में LLM का प्रभावी उपयोग करने के लिए ‘guide’ और ‘oversight’ में निवेश सबसे महत्वपूर्ण है
  • Guide संदर्भ और वातावरण प्रदान करता है ताकि LLM बेहतर निर्णय ले सके, और oversight परिणामों की पुष्टि करने और दिशा देने की भूमिका निभाता है
  • Prompt library बनाना महत्वपूर्ण है ताकि LLM codebase के नियम, documentation और best practices को समझ सके
  • Technical debt management, code structure की सरलता, modularization और consistency सीधे तौर पर LLM की code समझ और productivity सुधार से जुड़े हैं
  • Automated oversight और verification system के जरिए LLM को सुरक्षित और consistent code generate करने में सहायता देना दीर्घकालिक scalability की कुंजी है

LLM स्केलिंग के लिए मुख्य अवधारणाएँ

  • बड़े codebase में LLM को लागू करने का तरीका अभी पूरी तरह स्थापित नहीं है, लेकिन guide और oversight में निवेश को सबसे प्रभावी दृष्टिकोण के रूप में प्रस्तुत किया गया है
  • Guide(Guidance) का अर्थ है वह संदर्भ और वातावरण जो LLM को सही निर्णय लेने में मदद करे, जबकि oversight की भूमिका generated परिणामों की पुष्टि करना और दिशा समायोजित करना है

Guide में निवेश

  • यदि LLM से एक ही प्रयास में high-quality code generate कराने वाला ‘one-shotting’ हासिल करना है, तो स्पष्ट guide आवश्यक है
    • इसके विपरीत, जब परिणाम अनुपयुक्त हो और manual correction की जरूरत पड़े, तो वह rework बन जाता है और अक्षम होता है
  • क्योंकि LLM code के भीतर हर चुनाव (variable name, function structure, tech stack आदि) generate करता है, इसलिए आदर्श स्थिति यह है कि prompt में केवल business requirements हों और बाकी बातें inferable या encoded हों

Prompt library बनाना

  • Prompt library LLM के लिए संदर्भों का एक संग्रह है, जिसमें codebase की documentation, best practices और structural map शामिल होते हैं
    • जब भी LLM का output गलत दिशा में जाए, तब यह समीक्षा करें कि “क्या अधिक स्पष्ट किया जाना चाहिए था” और उसे library में जोड़ें
    • व्यापकता और संक्षिप्तता के बीच संतुलन महत्वपूर्ण है
  • उदाहरण में @prompts/How_To_Write_Views.md, @prompts/The_API_File.md जैसे दस्तावेज़ LLM को देकर feature development को निर्देशित किया गया है
  • Prompt पर्याप्त रूप से specific होना चाहिए, लेकिन generated code की हर पंक्ति की समीक्षा करनी चाहिए

Environment और code quality

  • Technical debt अधिक होने वाला codebase, LLM के उपयोग की दक्षता को कम कर देता है
    • Meta के उदाहरण में कहा गया है कि technical debt के कारण automation लक्ष्य हासिल करना कठिन था
  • Clean code, modularization, clear naming, simple structure LLM की समझ और accuracy को बेहतर बनाते हैं
  • Django उदाहरण में, हर app का entry point _api.py file में रखकर ऐसी संरचना बनाई गई है जिससे LLM आवश्यक functionality जल्दी खोज सके
    • उदाहरण: visit_api.handoff_to_doctor(user) के रूप में external access को एकीकृत करना
    • _api pattern को prompt library में स्पष्ट रूप से लिखकर LLM को सही स्थान संदर्भित करने के लिए प्रेरित किया जाता है

Oversight में निवेश

  • LLM automation को engineer की जगह लेने के बजाय टीम को मजबूत करने की दिशा में देखा जाना चाहिए
  • Oversight का अर्थ team, alignment और workflow में निवेश भी है
    • Team स्तर पर design capability को बढ़ाना महत्वपूर्ण है, और यही architecture quality से जुड़ता है
  • Design capability बढ़ाने के तरीकों में किताबें·ब्लॉग·code पढ़ना, masterwork को दोहराना, और स्वयं implementation का अभ्यास करना शामिल है
    • उदाहरण: TLDraw, SerenityOS Jakt जैसे code का विश्लेषण करके design intuition का विस्तार करना

Automated oversight

  • Design verification का कुछ हिस्सा programmatically automate किया जा सकता है
    • उदाहरण: type error या rule violation पर environment में तुरंत feedback देना
  • ‘Safety’ का मतलब abstraction की रक्षा करना है
    • Pierce की परिभाषा के अनुसार, एक safe language यह सुनिश्चित करती है कि programmer अनजाने में abstraction को न तोड़े
  • उदाहरण: Django app के बीच internal file पर direct access को प्रतिबंधित करने वाले नियम को AST-आधारित inspection script से automate करना
    • from visit import logic.internal_file जैसे अवैध access का पता लगाना

Verification

  • Design और implementation के अलावा verification चरण (code review, QA) भी quality सुनिश्चित करने के लिए आवश्यक है
  • जैसे-जैसे workload बढ़ता है, review speed bottleneck बन सकती है, इसलिए निम्न सुधार सुझाए गए हैं
    • Development environment के बिना भी QA संभव बनाने के लिए entry barrier कम करना
    • Test data generation जैसी चीज़ों सहित ऐसा environment बनाना जिसमें test लिखना आसान हो
    • बार-बार दोहराए जाने वाले PR feedback को दस्तावेज़ित करके LLM को कुछ review अपने-आप करने में सक्षम बनाना
    • Security rules को framework defaults में शामिल करना

निष्कर्ष और अतिरिक्त अवलोकन

  • LLM खासकर नए (greenfield) project में बहुत अच्छा काम करता है
    • क्योंकि वहाँ पहले से संदर्भ नहीं होता और consistency की मांग भी कम होती है
  • जैसे-जैसे project बड़ा होता है, consistency और modularization productivity तय करते हैं
    • Verified components के पुन: उपयोग पर आधारित modular structure कुशल विकास की कुंजी है

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

1 टिप्पणियां

 
GN⁺ 2025-12-24
Hacker News की राय

  • जैसे-जैसे मॉडल बेहतर होते गए, वे जटिल codebase या लंबी files को भी संभालने लगे
    इसलिए मैंने बार-बार इस्तेमाल होने वाला एक सरल framework loop बनाया

    1. Research: मौजूदा functionality को explain करवाकर संबंधित files को context में load करना
    2. Plan: नई feature implementation या refactoring की best practices पर brainstorming करवाना। उसका result एक md file में लिखवाना
    3. Clear: context को पूरी तरह reset करना। सिर्फ compress करने से यह बेहतर result देता है
    4. Execute plan: सिर्फ plan को फिर से load करके execute करवाना। ज़रूरत पड़ने पर सवाल दोहराना
    5. Review & test: फिर context reset करके review करवाना कि plan ठीक से apply हुआ या नहीं। इस समय test code, lint, typecheck आदि भी जोड़ना
      इस loop को 20~30 मिनट चलाने पर काफ़ी उपयोगी result मिलते हैं। आख़िरकार असली बात context management और test feedback loop बनाना है
    • दिसंबर 2025 तक Sonnet/Opus, GPTCodex जैसे models में पहले से subagent exploration feature built-in है
      “explore” keyword से exploration शुरू करने पर अलग से plan लिखने या context reset किए बिना भी Research संभव है
      लेकिन ये अक्सर code language को C या Python मान लेते हैं, इसलिए state को object में encapsulate करने के बजाय पाँच functions में बाँट देने जैसी unstructured code generate कर देते हैं
      और Claude अक्सर CLAUDE.md को ignore कर देता है, इसलिए पहले वह file पढ़वाकर फिर “explore” करवाना ज़्यादा stable रहता है
      नए models बेकार context को अच्छी तरह discard कर देते हैं, लेकिन पुराने models में अभी भी plan document आधारित approach बेहतर पड़ सकती है
    • अगर model बुनियादी reasoning ability में ही fail हो जाए, तो कोई भी workflow काम नहीं आता
      वह plan और guidelines को बिल्कुल उल्टा follow करता है, या वही sentence फिर पढ़कर भी उल्टा conclusion निकाल देता है
      कुछ समय तक मुझे लगा था कि LLM-केंद्रित process बनाया जा सकता है, लेकिन अब मेरा भरोसा कम हो गया है
      model जब “अच्छी state” में होता है तब ठीक काम करता है, लेकिन उसे उस state में लाना अब भी किस्मत पर निर्भर है
    • मैं भी मिलती-जुलती approach इस्तेमाल करता हूँ। HumanLayer की Advanced Context Engineering guidelines से प्रेरणा मिली थी
      मैंने Claude Code में /research_codebase, /create_plan, /implement_plan जैसे custom commands जोड़े हैं
      ध्यान से review और correction करने पर यह बहुत अच्छा काम करता है, लेकिन पूरी team में फैल नहीं पाया
    • मैं ऐसी प्रक्रिया लगभग इस्तेमाल नहीं करता। GitHub Copilot और Claude Sonnet 4.5 के साथ सिर्फ स्पष्ट निर्देश ही काफ़ी अच्छे साबित होते हैं
      पूरी तरह नई feature बनाते समय ही मैं context reset करता हूँ। Codespaces में ठीक है, लेकिन Tasks feature लगभग बेकार है
      बड़े काम देने पर यह कभी-कभी पूरी तरह गलत दिशा में चला जाता है, इसलिए हमेशा नज़र रखनी पड़ती है
    • मैं भी लगभग यही workflow इस्तेमाल करता हूँ। plan md file को repository में छोड़ देता हूँ ताकि नई feature जोड़ते समय उसका reference लिया जा सके
      यह context re-priming में भी उपयोगी है, इसलिए अक्सर काम आता है

  • prompt library को उपयोगी बनाना है तो iterative improvement ज़रूरी है
    जब भी LLM थोड़ा भटकता है, मैं खुद से पूछता हूँ “मुझे और क्या स्पष्ट करना चाहिए था?” और उसका जवाब prompt में जोड़ देता हूँ
    सिर्फ Enter दबा देना या auto-approve कर देना बस tokens बर्बाद करता है। उसकी बजाय यह देखना चाहिए कि LLM कहाँ अटक रहा है, और उसे CLAUDE.md में छोटा-सा नोट कर देना चाहिए
    जब context file बड़ी हो जाए तो उसे काम के प्रकार के हिसाब से अलग कर देना चाहिए
    मेरा मुख्य use case codebase exploration, execution path tracing, और ज़रूरी files का summary देना है। सवाल के प्रकार के हिसाब से result delivery format तय कर देने से efficiency काफ़ी बढ़ जाती है

    • “मुझे और क्या स्पष्ट करना चाहिए था?” से भी बेहतर तरीका है LLM से खुद पूछवाना
      मैं इसे “Student Pattern (Fresh Eyes)” कहता हूँ। इसमें subagent beginner की नज़र से document या code पढ़ता है और confusion points, contradictions, missing information ढूँढता है
      यह developer से छूट जाने वाले implicit knowledge को पकड़ने में बेहतरीन है। नई documentation review या prompt evaluation से पहले के चरण में बहुत उपयोगी है
    • मैं भी ऐसा करता हूँ, लेकिन Claude Code में अक्सर prompt या documentation को ignore करने की समस्या बहुत होती है
      CLAUDE.md पढ़ने को कई बार कहने पर भी वह अक्सर नहीं पढ़ता, और session शुरू होने के तुरंत बाद भी random तरीके से छूट जाता है
      document और commands सब तैयार होने पर भी वह अक्सर “भूल” जाता है

  • मैं बड़े codebase को agent-friendly structure में ढालने का प्रयोग कर रहा हूँ
    project को nix flakes आधारित directed graph में तोड़ दिया है ताकि हर node का अपना independent development environment हो
    Claude Code को flake devshell में चलाने पर वह सिर्फ उसी scope को देखता है, जिससे context overload रोका जा सकता है
    flakes के बीच input/output के ज़रिए collaboration करवाते हैं, और वे एक-दूसरे को feature requests और tests भेजते हैं
    मुझे लगता है कि यही context partitioning token explosion की समस्या घटाने की कुंजी है

    • यह approach दिलचस्प है। मैं भी software structure और properties के correlation पर सोच रहा हूँ
      सिर्फ मौजूदा workflow को सुधारने के बजाय, ऐसी नई structure design करनी होगी जिसे LLM आसानी से scale कर सके
      मैं “testability, scalability, security” जैसी properties और code structure के रिश्ते को explore कर रहा हूँ
    • context partitioning के अलावा reproducibility और dependency pinning के नज़रिए से भी यह दिलचस्प है
      मैंने भी Docker आधारित project में ऐसा प्रयोग किया है, लेकिन काश इसे automate करने वाला कोई tool होता

  • LLM उन विषयों को शानदार ढंग से समझाता है जिन्हें मैं कम जानता हूँ, लेकिन मेरे विशेषज्ञता वाले क्षेत्र में वह पूरे भरोसे के साथ गलत होता है

    • यह Gell-Mann Amnesia effect जैसा लगता है
    • topic के हिसाब से काफ़ी फर्क पड़ता है। web domain में यह मेरे लिए सही था, लेकिन Hare जैसी दुर्लभ language में पूरी तरह खराब निकला
    • शायद इसलिए ऐसा लगता है क्योंकि जिन क्षेत्रों को हम नहीं जानते वहाँ हम सरल सवाल पूछते हैं, और जिन क्षेत्रों को जानते हैं वहाँ कहीं कठिन सवाल पूछते हैं
    • सच यह भी हो सकता है कि जिन क्षेत्रों को हम नहीं जानते, वहाँ हम बकवास को पहचान ही नहीं पाते

  • मेरा नज़रिया अलग है। LLM की performance बढ़ाने का सबसे अच्छा तरीका है codebase में ही meaning embed करना
    यानी DDD(Domain-Driven Design) की तरह structured code, LLM के लिए भी समझना आसान होता है
    जटिल code को tools के सहारे ज़बरदस्ती संभालने की कोशिश पैसों की बर्बादी है
    आख़िरकार LLM ने यही साबित किया है कि “language और meaning” पर ज़ोर देने वाला DDD दर्शन सही था
    संबंधित लेख: DDD & the Simplicity Gospel

    • मैं भी दो बड़े codebase संभालता हूँ, और structured वाला हिस्सा LLM कहीं बेहतर समझता है

  • “LLM greenfield project में अच्छा क्यों काम करता है?” इस सवाल पर मेरा अनुभव उल्टा है
    जब codebase में कोई pattern 2~3 बार दोहराया जाता है, तो LLM उसे सीखकर लगातार उसी तरह reproduce करता है
    लेकिन “consistency” का मतलब “quality” नहीं होता। अगर सिर्फ consistency के पीछे भागा जाए और standards न हों, तो maintain न हो सकने वाला code बनता है

  • “जिस code को engineer नहीं समझ सकता, उसे LLM भी नहीं समझ सकता” यह बात सही है, लेकिन इसका उल्टा सही नहीं है
    कई बार इंसान समझ लेता है, लेकिन agent नहीं समझ पाता
    codebase को इंसान से ज़्यादा agent के लिए समझने लायक बनाना और भी कठिन है
    यह भी कहा जाता है कि “feedback को computer में डाल दो तो one-shot success rate बढ़ जाता है”, लेकिन यह दावा P=NP कहने जैसा है
    verification आसान होने का मतलब यह नहीं कि solution ढूँढना भी आसान हो जाता है
    ATS या Idris जैसी languages में correctness proofs को code के साथ लिखा जा सकता है
    अगर यह दावा सही होता, तो ऐसी languages में LLM को सबसे अच्छा perform करना चाहिए था
    लेकिन हक़ीक़त ऐसी नहीं है। इसलिए अभी के लिए model improvement का इंतज़ार करना बेहतर है

  • इन समस्याओं की वजह से मुझे लगता है कि opinionated frameworks AI coding productivity बढ़ाएँगे
    framework के rules LLM पहले से जानता है, इसलिए अलग guidelines की ज़रूरत नहीं पड़ती

    • मैं 16 लाख lines वाले codebase पर काम करता हूँ, और जहाँ pattern mismatch बहुत था, वहाँ LLM लगभग बेकार साबित हुआ
    • मैंने एक ही app को कई languages में बनाया है; Rails में यह लगभग तुरंत बन गया, और Bun भी ठीक था
      वहीं Go, Rust, Elixir, C# में कहीं ज़्यादा dependencies और निर्देशों की ज़रूरत पड़ी
      Rust में result अच्छा था, लेकिन उसने 200 से ज़्यादा packages खींच लिए, जो भारी पड़ता है

  • “Garbage in, garbage out” सिद्धांत सही है, लेकिन LLM पर पूरी तरह लागू नहीं होता
    यह पूरे internet के noisy data पर train हुआ है, फिर भी काफ़ी अच्छा काम करता है
    hallucination साधारण noise की तुलना में गलत context से ज़्यादा पैदा होती है
    codebase का structure खराब हो तब भी, अगर उसमें जानकारी भरपूर हो, तो वह अब भी उपयोगी context दे सकता है

  • आख़िर में लोग फिर से बुनियादी सिद्धांत सीख रहे हैं
    documentation(=prompt library) और साफ़-सुथरा code structure development speed बढ़ाते हैं, यह बात लोग फिर से समझ रहे हैं

    • फिर भी, अगर इसकी वजह से ज़्यादा लोग tests लिखना शुरू करें, तो मुझे इसमें कोई बुराई नहीं लगती