- बड़े production codebase में नवीनतम language models से बेहतर नतीजे पाने के लिए context engineering के सिद्धांत और व्यावहारिक workflow पेश करने वाला लेख
- इसका मुख्य बिंदु Frequent Intentional Compaction है, जिसमें development की पूरी प्रक्रिया के दौरान context को structured और compressed रखा जाता है ताकि agent के निर्णय की गुणवत्ता और प्रगति की trajectory स्थिर रहे
- Research→Plan→Implement के 3 चरणों के जरिए पूर्व-शोध deliverables और planning documents बनाए जाते हैं, और human review को high-leverage बिंदुओं पर रखकर slop और rework कम किया जाता है
- Rust-आधारित 300,000 LOC वाले BAML में bug fixes तथा cancellation/WASM support जैसे जटिल कार्य कम समय में पूरे करने के उदाहरण के जरिए यह दिखाया गया है कि यह brownfield environment में भी प्रभावी है
- निष्कर्ष यह है कि AI coding कोई खिलौना नहीं, बल्कि सूक्ष्म engineering craftsmanship है, और team स्तर पर process/culture transformation ही प्रतिस्पर्धात्मक बढ़त की कुंजी है
पृष्ठभूमि: जटिल codebase में AI की सीमाएँ और समस्या-बोध
- अधिकांश developers अच्छी तरह जानते हैं कि AI coding tools वास्तविक production codebase में अपेक्षा के अनुसार अच्छी तरह काम नहीं करते
- ऐसे शोध मौजूद हैं जिनमें दिखाया गया है कि AI coding tools बड़े codebase और जटिल कार्यों में productivity घटा सकते हैं
- Stanford के शोध के अनुसार, AI tools द्वारा जोड़ा गया काफी code बाद में उसी AI द्वारा बनाए गए कमजोर code को फिर से सुधारने में खर्च होता है, जिससे दोहराव वाला काम बढ़ता है
- AI coding agents नए projects या छोटे बदलावों में प्रभावी हो सकते हैं, लेकिन बड़े codebase में वे developer productivity घटा भी सकते हैं
- इसी वजह से field में अक्सर ऐसी सतर्क प्रतिक्रिया दिखती है: “अभी कठिन है, जब थोड़ा और स्मार्ट model आएगा तब”
- लेकिन वास्तविक 300,000 LOC के बड़े Rust codebase में context engineering लागू करने पर यह पाया गया कि मौजूदा models से भी productivity और quality दोनों को market level से ऊपर ले जाया जा सकता है
- इसका केंद्र frequent intentional compaction है, यानी development process के दौरान AI को दिया जाने वाला context हमेशा structured और managed रूप में रखना
- अंततः ‘AI coding’ एक ऐसा क्षेत्र है जहाँ तकनीकी craftsmanship की ज़रूरत होती है
वैचारिक आधार: “Specs are the new code” और productivity research
- AI Engineer 2025 की दो प्रस्तुतियों ने सोचने का तरीका बदलने में बड़ी भूमिका निभाई
- Sean Grove की "Specs are the new code" प्रस्तुति में कहा गया कि conversational prompts को छोड़कर specs को code की तरह सुरक्षित रखना चाहिए
- prompts को छोड़ देना और केवल generated code commit करना, source के बिना सिर्फ binary check-in करने जैसा है
- Stanford के AI का developer productivity पर प्रभाव वाले शोध से संकेत मिलता है कि AI भले short-term output बढ़ाए, लेकिन quality गिरने और rework के कारण net effect कम हो सकता है
- 100,000 developers के commits के विश्लेषण में देखा गया कि AI tools rework बढ़ाते हैं और इस तरह productivity gains को संतुलित कर देते हैं
- greenfield में यह प्रभावी हो सकता है, लेकिन brownfield और उच्च-कठिनाई वाले कामों में इसके उलटे असर अक्सर देखे गए
सिद्धांत: Frequent Intentional Compaction की अवधारणा
- context window को हमेशा 40–60% स्तर पर रखते हुए, अधिकता, कमी और गलत जानकारी को न्यूनतम करने वाली continuous compression strategy अपनाई जाती है
- compression के लक्ष्य होते हैं file search logs, code flow tracing, change history, test/build logs, बड़े JSON जैसी noise
- हर चरण के outputs को structured artifacts के रूप में छोड़ दिया जाता है ताकि अगले turn के input की quality बनी रहे
- उदाहरण: progress document जिसमें summary, goal और approach, completed steps, और current failure point दर्ज हो
workflow: Research → Plan → Implement
- Research चरण में संबंधित files, flow और root-cause hypotheses की जाँच करके summary research document तैयार किया जाता है
- ज़रूरत पड़ने पर sub-agents fresh context के साथ scope exploration और summarization करते हैं
- Plan चरण में target files, बदलाव की विधि, और verification/testing procedure का विस्तार से वर्णन करने वाली implementation plan लिखी जाती है
- plan को code review से भी अधिक high-leverage review point के रूप में इस्तेमाल किया जाता है
- Implement चरण में plan को step-by-step लागू किया जाता है, और हर verification के बाद plan document में status को फिर से compress करके जोड़ा जाता है
- जटिल tasks में हर चरणीय मिलन-बिंदु पर context realignment किया जाता है
anti-patterns और क्रमिक परिष्कार
- naive approach में chat-style flow के दौरान context दूषित हो जाता है, जिससे apology loop या भटकाव जैसी समस्याएँ पैदा होती हैं
- थोड़ा बेहतर तरीका session reset और “additional instruction prompts” है, लेकिन इसमें मूल noise control अभी भी कमजोर रहता है
- intentional compaction progress summaries (files) और commit messages का उपयोग करके context को फिर से बनाता है, जो एक बेहतर तरीका है
- आदर्श compression output format के उदाहरण दिए गए हैं, जिनका लक्ष्य accuracy/completeness/size/trajectory को optimize करना है
context optimization पर तकनीकी दृष्टिकोण
- LLM एक stateless function है, इसलिए उसकी quality पूरी तरह input context पर निर्भर करती है
- सबसे खराब स्थिति का क्रम है गलत जानकारी > जानकारी की कमी > अत्यधिक noise
- context जितना छोटा हो उतना बेहतर, इसलिए minimal input से maximum consistency पाना compression का मुख्य उद्देश्य है
- सरल loop-based agent execution strategies (जैसे “Ralph” process) जैसी वैकल्पिक दृष्टियाँ भी उल्लेखित हैं
sub-agents की भूमिका: role-play नहीं, context control
- sub-agents खोज/सारांश/व्यवस्था का काम स्वतंत्र context में करके main agent की window को साफ रखते हैं
- आदर्श response एक structured compressed output होता है, जिसमें goal/status/path स्पष्ट रूप से व्यवस्थित हों
- sub-agents के जरिए exploration cost को localize किया जाता है और मुख्य कार्य context का focus बढ़ाया जाता है
मामला 1: BAML bug fix पहली बार में pass
- 300,000 LOC वाले Rust BAML में एक नए contributor ने कुछ ही घंटों में bug-fix PR जमा किया और उसे approve भी करा लिया
- research document को कई बार दोहराकर उसकी quality बढ़ाई गई, और अंतिम plan के आधार पर implementation करके first pass हासिल किया गया
- इसने brownfield suitability, slop removal, और alignment maintenance जैसे कई लक्ष्यों को पूरा किया
मामला 2: BAML में cancellation/WASM support, 35k LOC
- दो लोगों ने 7 घंटे में cancellation feature और WASM compilation support जोड़ने जैसा बड़ा बदलाव दिखाया
- टीम के अनुमान के अनुसार 3–5 दिन प्रति व्यक्ति लगने वाला काम research/plan/implementation pipeline से बहुत छोटा हो गया
- कुछ PR तुरंत merge हुए, और कुछ को working demo स्तर पर खुला रखा गया, जिससे उच्च-कठिनाई वाले कार्यों के समाधान की संभावना साबित हुई
सीमाएँ और विफलताओं से सीख
- Parquet Java में Hadoop dependency removal का प्रयास dependency tree में पर्याप्त गहराई तक न जाने के कारण विफल रहा
- निष्कर्ष: हर समस्या 7 घंटे की prompting से हल नहीं होती; domain experts की भागीदारी भी ज़रूरी है
- human review का leverage research>plan>code के क्रम में बढ़ता है, और research की एक गलत पंक्ति हज़ारों पंक्तियों की त्रुटि में बदल सकती है
team alignment के लिए document-first दृष्टिकोण
- यह दृष्टि रखी गई कि code review का मूल उद्देश्य mental alignment बनाए रखना है
- बड़े PR की श्रृंखला team में product understanding की हानि और असुरक्षा पैदा कर सकती है, इसलिए specs/plan/research के जरिए alignment cost घटाई जाती है
- engineers 2,000 lines of code की तुलना में 200-line plan document को अधिक बार और अधिक सटीकता से पढ़ सकते हैं
- अपरिचित क्षेत्रों के issues में भी research prompt तेज़ मार्गदर्शन का काम करता है
समग्र निष्कर्ष और cost structure
- सभी प्रमुख लक्ष्य पूरे होते दिखे: brownfield compatibility, complex problem solving, slop minimization, और team alignment maintenance
- operational cost के हिसाब से 3 लोगों की team इसे Opus token cost लगभग $12k प्रति माह पर चला रही है
- अपवाद मौजूद हैं, लेकिन समग्र रूप से इसे काम करने वाली methodology के रूप में रेखांकित किया गया है
आगे के बदलाव और productization
- coding agents अंततः commoditized हो जाएँगे; असली चुनौती organization और workflow transformation है
- उस दुनिया में जहाँ AI 99% code लिखेगा, collaboration model का पूर्ण पुनर्गठन ही प्रतिस्पर्धात्मक बढ़त तय करेगा
- इसे समर्थन देने के लिए CodeLayer नामक एक “post IDE” tool को private beta में जारी किया गया है
- इसका लक्ष्य Superhuman for Claude Code बनना है और यह spec-first agentic development को तेज़ करता है
3 टिप्पणियां
विज्ञापन समाप्त...
CodeLayerनाम की एक सेवा के परिचय के साथ समापन...Hacker News राय
पढ़ने में दिलचस्प था और इसमें कुछ नए आइडिया भी थे। लेकिन मुझे लगता है कि इस तरह के दावों में समस्या है। Sean ने अनुमान लगाया कि AI इतना आगे बढ़ जाएगा कि आगे चलकर स्पेक दस्तावेज़ ही असली कोड बन जाएंगे। उनका कहना है कि अगले 2 साल में लोग IDE में Python फ़ाइलें उतनी ही कम देखेंगे, जितना आजकल कोई assembly देखने के लिए hex editor खोलता है। उनका कहना था कि शुरुआत में उन्हें असहज लगा, लेकिन बाद में उन्होंने PR के कोड को लाइन-दर-लाइन पढ़ने के बजाय टेस्ट पर ध्यान देना और स्पेक को असली source मानना स्वीकार कर लिया। लेकिन LLM की non-determinism समस्या के कारण, चाहे prompt कितना भी अच्छा हो, हमेशा एक तर्कसंगत implementation की उम्मीद नहीं की जा सकती। Compiler deterministic होते हैं, और bug हो तो reproduce व debug किया जा सकता है, लेकिन LLM के साथ ऐसा नहीं है
जूनियर डेवलपर के साथ काम करते समय भी implementation कुछ हद तक deterministic होता है। लेकिन AI मॉडल में, साफ निर्देश देने पर भी बार-बार पूरी तरह अलग implementation निकल आता है
दिलचस्प बात यह है कि स्पेक दस्तावेज़ खुद भी पहले से non-deterministic होते हैं। अगर आप requirements को ऐसी English में लिखना चाहें जिसे कोई गलत न समझ सके, तो वह आखिरकार programming language जैसी बन जाती है
मैं इस चिंता से सहमत हूँ कि "prompt परफेक्ट हो सकता है, लेकिन LLM उसे तर्कसंगत implementation में बदलेगा, इसकी कोई गारंटी भी नहीं है"। बल्कि natural language में लिखे गए prompt स्वभाव से ही अक्सर अस्पष्ट और अधूरे होते हैं। इसलिए जहाँ creative output चाहिए, वहाँ यह अच्छी दिशा है, लेकिन अगर software requirements को define करने के लिए natural language पर्याप्त होती, तो software engineering यह समस्या दशकों पहले ही हल कर चुकी होती। मैं LLM को लेकर बहुत उत्साहित रहा हूँ, लेकिन यह सोचना कि इससे हर समस्या हल हो जाएगी, कुछ ज़्यादा ही है। requirements specification के मामले में यह पुराने formal systems और mathematical verification की कोशिशों जैसा लगता है, लेकिन एकदम उल्टे छोर पर। भले यह भी आंशिक विफलता पर खत्म हो, फिर भी यह software development पर नए insight देने वाला प्रयोग है। कुछ domains में इससे असली value बनेगी, और कुछ में यह पूरी तरह छोड़ दिया जाएगा। दिलचस्प समय है
सच तो यह है कि लोग साफ और विस्तार से technical specs या documentation लिखते ही बहुत कम हैं। और अगर लिखते भी हों, तब भी मुझे नहीं लगता कि यह 2 साल में आम हो जाएगा। क्या software engineering को बहुत गहराई से समझने वाला technical writer, बिना actual code देखे सिर्फ AI agent को अच्छे prompt देकर संतुष्ट हो जाएगा? मैं इससे सहमत नहीं हूँ। यह कुछ हद तक वही सामान्य सोच है जिसमें "engineer इंसानों को मशीन की तरह देखता है"
यह दावा भी कि "compiler की वजह से हमें हर build पर hex editor में assembly देखने की ज़रूरत नहीं पड़ती", निश्चित ही tools बेहतर होने का नतीजा है, लेकिन असल में HPC scientific research में अक्सर यह देखने के लिए assembly को सीधे खंगाला जाता था कि compiler ने critical loops की vectorization ठीक की या नहीं, जैसे Intel VTune से
मैंने यह पैटर्न दो अलग codebase में इस्तेमाल किया है। एक 5 लाख लाइन वाला apache airflow का बड़ा monolithic repo था, और दूसरा flutter में शुरू से बनाया जा रहा मेरा निजी side project। मुझे flutter और dart की लगभग कोई जानकारी नहीं थी। फिर भी मुझे लगा कि यह तरीका काम करता है। greenfield project में तो लगभग सिर्फ /create_plan चलाना काफी था, और agent की पूरी मदद ली जा सकती थी। अहम बात यह है कि AI द्वारा बनाए गए दस्तावेज़ों को ध्यान से review किया जाए। बस यह देखना होता है कि जिन edge cases की मुझे चिंता है, वे कवर हुए हैं या नहीं, और technical choices सही हैं या नहीं। उदाहरण के लिए, अगर sqlite pattern तोड़कर postgres सुझाया जाए, तो मैं तुरंत समझ सकता हूँ कि यह गलत निर्णय है। आम तौर पर मैं agent से सीधे chat करके plan वहीं सुधार देता हूँ। कंपनी में हमें GitHub Copilot इस्तेमाल करना पड़ता है, इसलिए prompt थोड़ा अलग लिखना पड़ता है, लेकिन चरणों के बीच जानबूझकर किया गया summary compaction अभी भी करता हूँ। Copilot, Claude Code की तरह sub-agents को support नहीं करता, लेकिन फिर भी productivity बनी रहती है.
मैं एक निजी अनुभव भी साझा करना चाहता हूँ। AI coding support के दौर से ठीक पहले, मैं इस बात से बहुत अवसादग्रस्त था कि मेरा काम बहुत उबाऊ होता जा रहा है। कई repos, teams और लोगों की अलग-अलग कार्यशैलियों के कारण बड़े codebase पर काम करना हमेशा छोटी-छोटी झंझटों से भरा रहता था। AI coding की सबसे अच्छी बात यह रही कि इसने ऐसे छोटे-मोटे कामों को बहुत सहज बना दिया। मुझे कुछ ऐसा बनाने में बहुत संतोष मिलता है जो अच्छे से काम करे, लेकिन बार-बार ऐसे बारीक कामों में अटककर वह खुशी गायब हो जाती थी। अब मैं लगातार अच्छे परिणाम दे रहा हूँ, और खुद पर गर्व भी महसूस करता हूँ
मैंने बड़े codebase में काम करने के लिए एक package बनाया है [GitHub.com/iambateman/speedrun]। पहले /feature में feature description डालते ही यह codebase analysis शुरू करता है और सवाल पूछता है। मैं जवाब देता हूँ, फिर यह markdown format में plan लिखता है। इस प्रक्रिया में 8~10 markdown फ़ाइलें बनती हैं, जिनमें क्या करना है और example code तक शामिल होता है। उसके बाद "code critic" चरण आता है, जो errors ढूँढने की कोशिश करता है, लेकिन सच कहूँ तो लगभग 60% गलत होता है। मैं इस feedback में से बेकार errors छाँट देता हूँ। तब तक मेरे पास एक साफ-सुथरा folder तैयार हो जाता है जिसमें मनचाहे changes और feature description होती है। अब Claude Code से सिर्फ “आगे बढ़ो” कहना होता है, और वह step-by-step काम शुरू कर देता है। इस तरीके से दिशा भटकने से बचाव होता है और output पर भरोसा बनता है। मैं इस workflow को दिन में कई बार बड़े कामों के लिए इस्तेमाल करता हूँ, और अपेक्षाकृत specific tasks के लिए सामान्य Claude code का उपयोग करता हूँ। मुझे यह काफी efficient workflow लगता है
मैं बिल्कुल नहीं समझ पाता कि कोई इतना जटिल process क्यों अपनाना चाहेगा। मुझे लगता है कि LLM की थोड़ी मदद लेकर सामान्य coding करना, इस तरीके से ज़्यादा productive है
बड़े codebase में LLM का एक बड़ा मसला यह है कि यह वही गलतियाँ बार-बार दोहराता है। मैं जानना चाहता हूँ कि हर task में architecture से जुड़े decisions को context के भीतर लगातार कैसे track किया जाता है
यह सच में बहुत बढ़िया लग रहा है। बीच में pseudo code का चरण है, तो मैं जानना चाहता हूँ कि क्या पहले से workflow या process definition होना वास्तव में मददगार रहा। और मैंने यह भी सुना है कि हर file को 100 lines के अंदर रखना ज़रूरी है; क्या आपको भी ऐसा ही लगा?
यह लेख मुझे उस पल का टाइम-कैप्सूल लगता है जब मैंने अपने Claude code में context management पर लगभग पूरी तरह हार मान ली थी। मैंने code के हर हिस्से के लिए folder के भीतर अलग specs बनाए थे और feature-wise logs रखे थे। मैं Python में API server के कई subsystems—accounts, notifications, subscriptions वगैरह—मैनेज कर रहा था। जैसे-जैसे स्थिति जटिल हुई, Claude business logic को ठीक से समझ नहीं पा रहा था और context management बेहद मुश्किल हो गया। उदाहरण के लिए, एक साधारण RBAC system बनवाने के लिए भी मुझे account-profile relationship समझाने वाला UML diagram और example देना पड़ता था, तभी जाकर आउटपुट कुछ हद तक उम्मीद के मुताबिक आता था
AI के इस्तेमाल पर तरह-तरह के दावे और घोषणाएँ बहुत हैं, लेकिन शायद ही कोई अपना ठोस process या prompt सार्वजनिक करता है। सिर्फ बातें बनाना आसान है; अगर कुछ सच में उपयोगी है, तो prompt logs उपलब्ध होने चाहिए। AI-generated commits में यह log भी होना चाहिए कि कौन-से prompt इस्तेमाल हुए, ताकि जैसे हम commit log देखते हैं, वैसे prompt log देखकर code लिखे जाने की प्रक्रिया भी समझ सकें
लेखक यह कहकर शेखी बघार रहा है कि उसने 35K lines of code को 7 घंटे में investigate और implement कर दिया, जबकि असल में 7 दिनों में 40 commits दिख रहे हैं। समझ नहीं आता कि क्या उसने हर दिन सिर्फ एक घंटा काम किया था। और यह भी मज़ेदार है कि हाल के commits में से एक का नाम "कुछ tests ignore करो" है
एक पंक्ति थी: "कुछ हफ्तों बाद, @hellovai के साथ मिलकर हमने BAML में 35k LOC जोड़े, जिसमें cancellation support और WASM compilation जैसे नए features शामिल थे। मौजूदा टीम ने अनुमान लगाया था कि हर feature में 3~5 दिन लगेंगे।" तो क्या इसका मतलब है कि वे सोच रहे थे कि एक senior engineer रोज़ 4~6KLOC लिखेगा? (genAI से पहले भी?)
यहाँ छूटी हुई बात यह है कि senior engineer शायद वास्तव में सिर्फ 2KLOC में ही यह समस्या हल कर देता
और वास्तव में लेखक ने कहीं और यह स्वीकार किया है कि इस काम में असल में एक हफ्ता लगा था https://news.ycombinator.com/item?id=45351546
मैं इस हिस्से से पूरी तरह सहमत हूँ: "शुरुआत में असहज लगा, लेकिन मैंने PR के सारे code को पढ़ना छोड़ दिया और सिर्फ tests को ध्यान से देखना शुरू किया। स्पेक ही असली source बन गया।" मुझे भी लगता है कि हमारी भूमिका implementation details खुद लिखने से हटकर behavior को define और verify करने की ओर जा रही है। हाल ही में मुझे S3-to-SFTP Python operator में recursive upload जोड़ना था, और इसमें कई जटिल path flags थे। मेरा process यह था - 1) मौजूदा behavior को एक स्पष्ट spec के रूप में निकालना, यानी unit tests पास करवाते हुए 2) नई feature के हिसाब से spec को बढ़ाना 3) समस्या और tests coding agent को सौंपना। आखिर में मुझे एहसास हुआ कि पुराना code समझना ज़रूरी ही नहीं था। मेरा पूरा ध्यान सिर्फ इस बात पर था कि नया code spec को सही से follow करता है या नहीं। आगे चलकर हमारी value correctness verify करने में होगी, और actual code agent के लिए बस implementation detail रह जाएगा
मैं इस बात से सहमत हूँ कि "हमारी भूमिका implementation details लिखने से behavior define और verify करने की ओर जा रही है"। बल्कि कई बार लगता है कि मुख्य काम पहले से यही था। high-level languages, compilers और दूसरी abstractions की वजह से implementation details लिखने में लगने वाला समय लगातार घटता गया है
"मेरा फ़ोकस इस पर था कि नया code spec के मुताबिक काम करता है या नहीं" — इससे मुझे Postel's Law याद आती है। व्यापक रूप से इस्तेमाल होने वाले systems में observed behavior ही अक्सर उस system का public interface और spec बन जाता है, जिसमें उसकी सारी गलतियाँ और implementation bugs भी शामिल हो जाते हैं। यह भी test करना पड़ता है कि code के client हिस्से वास्तव में spec को सही से follow करते हैं या नहीं, और अगर deviation हो तो उसे detect और handle करना पड़ता है
Claude Plays Pokemon ने भी यही दिखाया। AI यह तय करने में कमजोर है कि कुछ सही चल रहा है या नहीं। उल्टा यह अक्सर एक ही जगह अटका रहता है। लेकिन अगर इंसान बीच-बीच में दिशा सुधारता रहे, तो यह बहुत शक्तिशाली संयोजन बन सकता है
अगर आप behavior के हर पहलू को define करने की कोशिश करेंगे, तो आखिरकार आप लगभग पूरा code ही लिख रहे होंगे। अगर PR की किसी एक line का भी अर्थ तुरंत साफ नहीं है, तो शायद पूरे behavior को पर्याप्त रूप से define नहीं किया गया है
यह दावा भी था कि "अगले कुछ वर्षों में स्पेक दस्तावेज़ ही वास्तविक code बन जाएंगे, और Python फ़ाइलें शायद ही कभी खोलनी पड़ेंगी"। ऐसा होने के लिए AI code generation को 99.9% तक सही होना होगा, और hallucination लगभग न के बराबर होनी चाहिए। हम compiler पर भरोसा करके assembly code नहीं देखते, क्योंकि हमें भरोसा है कि उसका output हर बार एक जैसा और सही होगा (कभी-कभार bugs या optimization issues हो सकते हैं, लेकिन वे आमतौर पर जल्दी ठीक हो जाते हैं)। अभी की स्थिति में, अगर AI-generated code spec यानी मूल code से अलग व्यवहार करता है, तो अंत में इंसान को ही उसे ठीक करना पड़ेगा
implementation को छोटे work units में बाँटकर handle या review करने की सलाह मुझे बहुत प्रभावशाली लगी।