LLM युग की इंजीनियरिंग

• यह Reindeer में पिछले डेढ़ साल की सोच का संकलन है कि LLM युग में प्रोडक्ट और डेवलपमेंट संगठन कैसे बनाए जाएँ, और इसकी हर अंतर्दृष्टि इस समझ से शुरू होती है कि human context सबसे दुर्लभ संसाधन है
• कंटेंट उत्पादन की मात्रा विस्फोटक रूप से बढ़ गई है, लेकिन इंसानी उपभोग की गति वैसी ही है; यह अंतर अब नया bottleneck है — slop feeds slop के दुष्चक्र को रोकना होगा
• modeling और API design जैसे structural decisions अब भी इंसानों का क्षेत्र हैं, और LLM द्वारा बनाए गए output पर "no" कहने वाला कोई इंसान होना चाहिए
• केवल code review से LLM को नहीं हराया जा सकता, इसलिए linters, LLM judges, और छोटे PRs जैसी automated और discipline-based defense layers बनानी होंगी
• डेवलपर की मुख्य क्षमता गहरा तकनीकी ज्ञान नहीं, बल्कि context switching और अपनी context window का आकार है; जो अनुकूलित हो जाते हैं वे अत्यधिक उत्पादक बनते हैं, लेकिन जो नहीं हो पाते वे टीम के लिए net negative बन जाते हैं

---

Human context एक दुर्लभ संसाधन है

• 25 साल से उद्योग में एक बात नहीं बदली — सबसे महँगा संसाधन human context है; इंसानों के पास भी LLM की तरह सीमित context window और attention mask होता है
• अभी जो बदलाव आया है, वह यह है कि हर दिशा से LLM slop बरस रहा है — उत्पादन की गति और इंसानी उपभोग की गति का अनुपात नया bottleneck बन गया है
• समस्या यह है कि slop feeds slop
  • LLM से फूले हुए code comments, लंबी-चौड़ी PR descriptions, और ऐसे documents जो परिणाम की जगह history बिखेरते हैं
  • अगला LLM इन्हें पढ़ता है, उसका context noise से भर जाता है, और वह भी उसी तरह आगे बढ़ता है
• संगठन के भीतर text content compressed होना चाहिए, और उसमें केवल वही होना चाहिए जो code और उसके behavior से स्पष्ट नहीं है

वे क्षेत्र जिन्हें इंसान replace नहीं कर सकते

• Modeling इंसानों का काम है
  • CUJ(Critical User Journey) को API flow में बदलना, यह तय करना कि components क्या हैं, उनकी concerns क्या हैं, और boundaries कहाँ हैं
  • LLM बहुत तेज़ी से code निकाल देता है, इसलिए खराब modeling भी तेज़ी से फैलती है, और ऐसे टेढ़े dependencies बनाती है जिन्हें बाद में ठीक नहीं किया जा सकता
  • execution cost जितनी सस्ती होती जाती है, अंतिम value में structure पर इंसानी निर्णयों का हिस्सा उतना ही बढ़ता है
  • modeling असल में संगठन की सच्चाई है, और यह एक ऐसी जगह जीवित होनी चाहिए जहाँ उससे पहुँचा जा सके
• API definitions में सख्त इंसानी अनुशासन चाहिए
  • LLM किसी खास task के लिए सुविधाजनक fields बार-बार जोड़ने की प्रवृत्ति रखता है, और हर ऐसा field API को स्थायी रूप से गंदा कर देता है
  • API एक public contract है, scratch pad नहीं — "no" कहने के लिए इंसान चाहिए

Slop के खिलाफ बड़े पैमाने पर रक्षा

• इंसानी code review से LLM को नहीं हराया जा सकता — यह scalable नहीं है और अंत में स्थिति सबकी आँखें बंद कर approval देने तक पहुँच जाती है
• Reindeer अंततः automated enforcement layers पर पहुँचा
  • Linters: services के बीच प्रतिबंधित dependencies, architecture boundaries जैसे absolute logical rules
  • LLM judges: वे चीज़ें जिन्हें code में लिखना कठिन है लेकिन model जाँच सकता है, जैसे implicit contracts
• लेकिन अगर API छू रही हो या modeling में बदलाव हो रहा हो, तो वास्तविक human review ज़रूरी है
• रोज़मर्रा के स्तर का नियम है: "एक-दूसरे पर slop मत फेंको"
  • छोटे PRs, और ज़रूरत हो तो stacked PRs
  • 2,000-line वाले slop PR फेंकने के प्रलोभन और reviewer के आँख बंद करके approve कर देने की संभावना — दोनों का विरोध करना होगा
  • PR, attention की मूल इकाई है — अगर वह किसी इंसान की context window से बड़ा है, तो approval तो मिल सकता है, पढ़ा नहीं जाएगा

Padded rooms — वे क्षेत्र जहाँ LLM को खुला छोड़ा जा सकता है

• ऊपर की संरचना होने पर उन क्षेत्रों की पहचान की जा सकती है जहाँ LLM खुलकर दौड़ सकता है, यानी "padded rooms"
  • जहाँ modeling पर असर नहीं पड़ता और कोई long-term dependency नहीं होती
  • जहाँ slop पैदा भी हो जाए तो उसे आसानी से बदला जा सके और वह पूरे codebase में न फैले
  • यह कंपनी के code का बड़ा हिस्सा हो सकता है, लेकिन load bearing नहीं होना चाहिए
• customer customization का जवाब भी यहीं है
  • customization को 100% padded rooms के अंदर रहना चाहिए
  • जैसे ही वह core में रिसता है, core टूटने लगता है और हर नए customer के साथ risk पैदा होता है
  • padded rooms वह infrastructure हैं जो architecture में भारी कीमत चुकाए बिना customer को तेज़ी से "yes" कहने देते हैं

Technical debt का आर्थिक उलटफेर

• load-bearing क्षेत्र और padded क्षेत्रों का विभाजन technical debt के साथ संबंध भी बदल देता है
• पहले: अगर development के दौरान modeling की समस्या मिलती थी, तो उसे भविष्य के अपने ऊपर टाल दिया जाता था; rewrite की लागत ऊँची होने से बड़े काम के बीच debt निगल लिया जाता था
• अब: rewrite cost लगभग 0 के करीब पहुँच गई है
  • असली निवेश typing में नहीं, बल्कि modeling में था
  • फेंक देना, modeling को ठीक करना, और फिर से लिखना सस्ता है
  • टालना अब बहुत महँगा है — गलत code के पास से गुजरने वाला हर LLM उसे अपना लेता है, slop feeds slop, इसलिए modeling की गलती को तुरंत ठीक न करने पर वह बहुत कम समय में कई गुना जटिल debt बन जाती है

इस युग का PM

• PM की भूमिका बदल रही है — उसे modeling करने वालों के साथ बहुत नज़दीकी से काम करना होगा ताकि CUJ को API और components में बदलते समय वह टूटे नहीं
• अगर PM और modeler sync में नहीं हैं, तो
  • या तो तकनीकी रूप से काम करने वाला लेकिन CUJ को पूरा न करने वाला प्रोडक्ट बनता है, या
  • साफ़-सुथरा CUJ होता है लेकिन ऐसा नतीजा जिसे व्यावहारिक रूप से बनाया नहीं जा सकता
• Reindeer में PM अलग repo में सीधे MVP बनाते हैं
  • यह मानकर कि यह code कभी production तक नहीं जाएगा
  • LLM के साथ तेज़ी से आगे बढ़ने और customers को कुछ दिखाने की आज़ादी मिलती है
  • जो चीज़ सफल हो या customer तक जानी हो, उसे औपचारिक modeling और development process से गुजरना होता है
  • core में निवेश करने से पहले तेज़ी से demo खड़ा करके customer validation किया जा सकता है — idea testing की गति और प्रोडक्ट में जाने वाली चीज़ों पर surgical strictness के बीच संतुलन

ऐसा infrastructure जो loop से मुक्त करे

• agent का हाथ पकड़कर चलाने और कई tasks को parallel चलाकर सो जाने के बीच का फर्क अच्छे reward function का है
  • उसके बिना LLM ऐसी यात्रा पर निकल जाता है जहाँ से वह वापस नहीं आता
  • उसके साथ वह खुद समझ सकता है कि वह कब लक्ष्य के पास है और कब दूर
• development में अच्छा reward function, अच्छे tests में बदलता है
  • platform के लिए E2E tests सहित
  • LLM को उस mock-dependent बुरी आदत से हटाना जिसमें कुछ भी वास्तव में test नहीं होता
  • LLM-आधारित output के लिए Evals
  • clean context वाले LLM judges automated review loop चलाते हैं — ताकि code लिखने वाले agent की तरह judge भी उसी hallucination में न फँसे
• संगठन स्तर पर इस infrastructure का shared होना ज़रूरी है
  • Reindeer में category के हिसाब से बँटा हुआ एक central skill marketplace repo है, जिसमें सभी internal skills शामिल हैं
  • Claude Code, Codex सभी harnesses में इसका automatic support है, और जो लोग खुद की तरह बहुत गहराई तक unhinged हैं उनके लिए pi.dev support भी है
  • नए डेवलपर्स को तुरंत संगठन की सभी skills मिल जाती हैं, जिनमें onboarding और setup करने वाली skills भी शामिल हैं

भविष्य का डेवलपर

• इस युग के डेवलपर की निर्णायक क्षमता गहरा ज्ञान नहीं, बल्कि context switching और अपनी context window/attention mask का आकार है
  • जो बड़ा context बनाए रख सकता है, focus खोए बिना tasks के बीच जा सकता है, और कई agents को parallel manage कर सकता है, वही जीतता है
  • नुकीली तकनीकी गहराई कम महत्वपूर्ण हो जाती है क्योंकि LLM उसे भर देता है
• अतिरिक्त क्षमता है modeling ability, system architecture की अच्छी समझ, और यह संवेदना कि design चरण में किन चीज़ों से सावधान रहना है
• नई दुनिया डेवलपर्स को दो हिस्सों में बाँटती है
  • जो अनुकूलित हो जाते हैं वे super-productive बन जाते हैं
  • जो अनुकूलित नहीं हो पाते वे तटस्थ नहीं, बल्कि टीम के लिए net negative बन जाते हैं
  • LLM एक multiplier है — जो इसे संभालना जानते हैं उनके लिए productivity, और जो नहीं जानते उनके लिए high-speed damage
  • reward के लिहाज़ से दूसरे तरह के डेवलपर की salary 0 हो जाती है — उनके लिए काम नहीं बचेगा
• बहुत कम लोगों के साथ बहुत ज़्यादा काम किया जा सकता है, लेकिन growth बहुत कठिन हो जाती है; बेहद चयनात्मक होना पड़ेगा

Token cost पर

• बार-बार पूछा जाने वाला सवाल: अगर token cost 5–10 गुना बढ़ जाए तो क्या होगा
• समय के साथ यह चिंता अवास्तविक लगती है
  • AI में accelerated Moore's Law है; प्रति dollar quality लगातार बढ़ रही है
  • पर्याप्त open models मौजूद हैं, इसलिए cartel बनाना संभव नहीं
• tokens सस्ते रहने का कारण यह है कि अगर Claudex अचानक अव्यावहारिक रूप से महँगा हो जाए, तो सब लोग किसी neocloud के Qwen पर चले जाएँगे