मैं LLM के साथ सॉफ़्टवेयर कैसे बनाता हूँ

• LLM का उपयोग करके सॉफ़्टवेयर डेवलपमेंट में architect-developer-reviewer मल्टी-एजेंट workflow के ज़रिए दसियों हज़ार लाइनों वाले प्रोजेक्ट्स को कम defect rate के साथ बनाए रखने की एक ठोस methodology साझा की गई है
• लेखक की रुचि प्रोग्रामिंग से ज़्यादा कुछ बनाना में थी, और अब जब LLM coding में अच्छे हो गए हैं, तो वे बनाने पर फ़ोकस कर पा रहे हैं
• कोड लिखने की क्षमता से अधिक system architecture design और सही decisions लेना जैसी engineering skills अब कहीं ज़्यादा महत्वपूर्ण हो गई हैं
• अलग-अलग models को मिलाकर code review की गुणवत्ता बढ़ाई जाती है, और हर मॉडल की ताकत और कमज़ोरी को भूमिका के अनुसार अलग करके इस्तेमाल किया जाता है
• ईमेल फ़ीचर जोड़ने का एक पूरा वास्तविक सत्र साझा किया गया है, जिसमें architecture decision से लेकर QA तक मानव-नेतृत्व वाले LLM collaboration process को विस्तार से दर्ज किया गया है

---

LLM के साथ बनाने के फ़ायदे

• लेखक को लगता था कि उन्हें programming पसंद है, लेकिन वास्तव में उन्हें कुछ बनाना पसंद था; अब जब LLM programming अच्छी तरह करने लगे हैं, वे लगातार चीज़ें बना रहे हैं
• Codex 5.2 के रिलीज़ के आसपास, और हाल में Opus 4.6 तक आते-आते, बहुत कम defect rate के साथ software लिखना संभव हो गया है। हाथ से सीधे code लिखने की तुलना में defect rate काफ़ी कम हो सकता है
• पहले 2~3 दिन काम करने के बाद code maintain न किए जा सकने वाली स्थिति में पहुँच जाता था, लेकिन अब कई हफ़्तों तक लगातार काम करते हुए दसियों हज़ार लाइनों का उपयोगी code स्थिर रूप से बढ़ाया जा रहा है
• Engineering skills बेकार नहीं हुईं, बल्कि उनकी जगह बदल गई है: code को सही लिखने की क्षमता की बजाय system को सही तरह architect करना और उसे उपयोगी बनाना अब असली कौशल है
• जिन projects में आधारभूत technology की अच्छी समझ है, जैसे backend, उनमें दसियों हज़ार SLoC पर भी समस्या नहीं होती; लेकिन जिन technologies की समझ कम है, जैसे mobile apps, वहाँ अब भी गलत फ़ैसलों का जमाव codebase को बिगाड़ देता है
• LLM के शुरुआती दौर (davinci के बाद) में हर code line को देखना पड़ता था, फिर बाद की पीढ़ियों में function level पर review काफ़ी था, और अब अक्सर पूरे architecture level पर ही जाँचना पर्याप्त होता है। अगले साल शायद इसकी भी ज़रूरत न रहे

इस तरीके से बनाए गए प्रोजेक्ट्स

• Stavrobot: security पर केंद्रित एक LLM personal assistant। यह calendar management, availability judgment, research, code लिखकर self-extension, reminders, घर के कामों का autonomous management आदि करता है। इसकी मुख्य value किसी एक killer feature में नहीं, बल्कि हज़ारों छोटी परेशानियों को कम करने में है
• Middle: voice memo रिकॉर्ड करके उसे text में बदलने और webhook से भेजने वाला एक छोटा pendant device। इसका मुख्य बिंदु है कि इसे हमेशा साथ रखा जा सकता है और बिना friction के इस्तेमाल किया जा सकता है
• Sleight of Hand: एक wall clock art project जो सेकंड के स्तर पर अनियमित टिक-टिक करती है, लेकिन मिनट के स्तर पर हमेशा सटीक रहती है। इसमें 500ms~1500ms variable tick, महसूस करना कठिन speed variation के बाद random stop, फिर double speed से चलकर 30 सेकंड रुकना जैसे कई modes हैं
• Pine Town: एक infinite multiplayer canvas, जिसमें हर व्यक्ति को छोटी-सी ज़मीन मिलती है और वह उस पर चित्र बना सकता है; एक interactive meadow project
• ये सभी projects LLM की मदद से बनाए गए हैं, और लेखक ने इनमें से ज़्यादातर code ख़ुद कभी पढ़ा भी नहीं, फिर भी हर project की architecture और internal working को अच्छी तरह समझते हैं

Harness tool

• लेखक अभी harness के रूप में OpenCode इस्तेमाल कर रहे हैं, और Pi के साथ भी अच्छा अनुभव रहा है
• Harness की दो अनिवार्य शर्तें:
  • कई कंपनियों के अलग-अलग models का उपयोग संभव होना चाहिए: ज़्यादातर first-party harnesses (Claude Code, Codex CLI, Gemini CLI) सिर्फ़ अपने ही models को support करते हैं, इसलिए यह शर्त पूरी नहीं होती
  • custom agents एक-दूसरे को autonomously call कर सकें

कई models की ज़रूरत क्यों

• किसी खास model को एक व्यक्ति की तरह देखा जा सकता है; context reset करने पर भी वह अक्सर अपनी वही राय, ताकत और कमज़ोरी बनाए रखता है
• अगर model से उसी के लिखे code का review कराया जाए, तो उसमें self-agreement bias होता है और उसका फ़ायदा लगभग नहीं के बराबर होता है; लेकिन किसी दूसरे model से review कराने पर गुणवत्ता काफ़ी बढ़ जाती है
• मौजूदा स्थिति में Codex 5.4 बहुत बारीक और सख़्त होने के कारण review के लिए उपयुक्त है, Opus 4.6 लेखक के अपने निर्णयों से सबसे ज़्यादा मेल खाता है, और Gemini 3 Flash कभी-कभी दूसरे models से छूटी हुई बेहतर approach सुझा देता है
• सबसे अच्छे नतीजों के लिए सभी models का मिश्रित उपयोग ज़रूरी है

Workflow: architect → developer → reviewer

• यह workflow architect, developer, और 1~3 reviewers से मिलकर बनता है। इन्हें OpenCode agents (skill files) के रूप में सेट किया गया है
• कई agents इस्तेमाल करने के तीन कारण:
  • महंगे models (Opus) को planning के लिए और सस्ते models (Sonnet) को code writing के लिए इस्तेमाल करके tokens बचाए जा सकते हैं
  • अलग-अलग models से review कराने पर अलग-अलग समस्याएँ पकड़ी जाती हैं
  • role-based permission separation संभव है, जैसे read-only बनाम write access
• एक ही model और एक ही permissions वाले दो agents का इस्तेमाल करना ऐसा है जैसे एक ही व्यक्ति ने बस अलग टोपी पहन ली हो; इसका ज़्यादा मतलब नहीं
• Skill files ख़ुद हाथ से लिखी जाती हैं। अगर LLM से skill लिखवाई जाए, तो वह ऐसा है जैसे किसी से “एक बेहतरीन engineer कैसे बनें” लिखवाकर फिर वही निर्देश उसे लौटाकर कहा जाए, “अब बेहतरीन बन जाओ”

Architect की भूमिका

• Architect (फ़िलहाल Claude Opus 4.6) इकलौता agent है जिससे सीधे बातचीत की जाती है, और यही सबसे शक्तिशाली model होना चाहिए
• इसमें बहुत specific feature या bug fix goal दिया जाता है, और goal, constraints, और trade-offs तय होने तक लगभग 30 मिनट तक बातचीत चलती है
• इसका output individual files और functions के स्तर तक जाने वाली काफ़ी low-level plan होती है
• यह सिर्फ़ prompting नहीं है, बल्कि LLM की मदद से plan को आकार देने की प्रक्रिया है। जहाँ LLM ग़लत हो या लेखक के तरीके से अलग जाए, वहाँ बहुत correction किया जाता है; यही project को “अपना” बनाने का मुख्य हिस्सा है
• इसे ऐसा सेट किया गया है कि जब तक “approved” शब्द साफ़ तौर पर न कहा जाए, यह implementation शुरू न करे। कुछ models ऐसा मानते ही कि वे समझ गए हैं, जल्दबाज़ी में implementation शुरू कर देते हैं
• Approval के बाद architect काम को tasks में बाँटता है, plan file में विस्तार से लिखता है, और developer को बुलाता है

Developer की भूमिका

• Developer के लिए अपेक्षाकृत कमज़ोर लेकिन token-efficient model (Sonnet 4.6) इस्तेमाल किया जा सकता है
• Plan में विवेक की गुंजाइश कम छोड़ी जाती है, इसलिए इसकी भूमिका सख़्ती से plan के अनुसार changes implement करने की होती है
• Implementation पूरा होने के बाद यह reviewer को बुलाता है

Reviewer की भूमिका

• हर reviewer स्वतंत्र रूप से plan और diff की समीक्षा करके आलोचनात्मक टिप्पणी देता है
• कम से कम Codex हमेशा इस्तेमाल किया जाता है, कभी-कभी Gemini जोड़ा जाता है, और महत्वपूर्ण projects में Opus भी
• Feedback वापस developer के पास जाता है, और reviewers के बीच मतभेद होने पर architect को escalate किया जाता है
• Opus सही feedback चुनने में अच्छा है, और जो feedback बहुत ज़्यादा सख़्त हो लेकिन implementation की तुलना में वास्तविक समस्या बनने की संभावना कम हो, उसे कभी-कभी नज़रअंदाज़ भी किया जाता है

समग्र approach और failure modes

• इस तरीके से function level से ऊपर के लगभग सभी decisions पर पकड़ बनी रहती है, और बाद के काम में उसी ज्ञान का उपयोग किया जा सकता है
• जब LLM codebase के किसी खास हिस्से को नज़रअंदाज़ करने वाली blind spot दिखाता है, तो “Y का उपयोग करना चाहिए” जैसा निर्देश देने पर LLM को Y के अस्तित्व का ध्यान आता है और वह बेहतर दिशा में मुड़ सकता है
• अगर किसी technology की समझ कम हो, तो LLM के ग़लत decisions पकड़ में नहीं आते, और उन पर गलत decisions की परतें चढ़ती जाती हैं, जब तक कि स्थिति असुलझी न हो जाए
• “Code काम नहीं कर रहा” यह बार-बार कहने पर LLM का “समझ गया! मैं ठीक करता हूँ” कहना और उसे और ज़्यादा बिगाड़ देना एक सामान्य failure pattern है
• इसलिए किसी technology से अपरिचित होने पर भी planning stage में जितना संभव हो उतना समझने की कोशिश की जाती है

वास्तविक सत्र: Stavrobot में email support जोड़ना

• एक वास्तविक annotated session का पूरा पाठ साझा किया गया है; tool calls और बहुत लंबी बातों को हटाया गया है, लेकिन conversation और decision-making process को जस का तस रखा गया है
• शुरुआती बातचीत: high-level goal दिया गया (“मैं इस bot में email support जोड़ना चाहता हूँ”) → LLM ने code पढ़कर मौजूदा pattern (inbound webhook → enqueueMessage → LLM processing → response) समझा और design questions पेश किए
  • inbound method (IMAP polling, webhook, SMTP server), outbound method, two-way support, architecture (separate container बनाम in-process), HTML email handling, thread tracking, attachments आदि
• Design decisions: inbound के लिए Cloudflare Email Worker webhook, outbound के लिए SMTP client, पूरी two-way conversation, in-process handling, markdown conversion, emails को independent मानना, attachment support
• LLM का detailed design proposal: MIME parsing (mailparser का उपयोग), webhook authentication (shared secret), outbound subject line की ज़रूरत, HTML-only emails handling, From address identity, forwarded emails handling, outbound attachments आदि कुल 7 concerns और उनके concrete design proposals
  • Worker payload को { from, to, raw } तक सरल बनाकर server side पर parsing करने का सुझाव
  • Config structure, inbound/outbound flow, modified files list, और स्पष्ट non-goals (YAGNI) को व्यवस्थित किया गया
• Plan refinement: README.md और config.example.toml update करना, email allowlist page में E.164 validation हटाना जैसी छूटी बातें इंसान ने इंगित कीं → LLM ने उन्हें plan में शामिल किया
• 6 tasks में विभाजन: Config/dependencies, allowlist, allowlist UI/backend validation, inbound email, outbound email, README/tests
• अतिरिक्त सुधार: यह विचार दिया गया कि SMTP settings के बिना भी केवल inbound email काम करे, इसलिए SMTP fields को optional बनाया गया → लागू किया गया
• QA में मिला bug: owner email register न होने की वजह से messages drop हो रहे थे → कारण यह था कि seedOwnerInterlocutor में email channel छूट गया था → इसे ठीक किया गया
• Code improvement proposal: channel-specific hardcoded if blocks की जगह shared channel list को iterate करने वाला refactor। Telegram के numeric conversion वाले special case पर चर्चा के बाद तय हुआ कि loop सिर्फ़ seedOwnerInterlocutor पर लगाया जाए, जबकि getOwnerIdentities को वैसे ही रखा जाए क्योंकि उसके type differences मूलभूत हैं
• Wildcard email allowlist: *@example.com जैसे domain-level wildcard support जोड़ा गया। disposable email addresses इस्तेमाल करने वाले वास्तविक use case के लिए इसकी ज़रूरत थी
  • Security concern: "[e-mail]"@evildomain.com जैसे हमलों से बचने के लिए * को [^@]* में बदला गया ताकि वह @ boundary पार न कर सके
  • myusername+*@gmail.com जैसे partial wildcard भी support किए गए
  • इंसान ने बताया कि regex इस्तेमाल करते समय email address के बाकी सभी characters को escape करना चाहिए
• Owner field और allowlist दोनों में wildcard के सही काम करने की पुष्टि हुई, और दोनों जगह एक ही matchesEmailEntry helper function इस्तेमाल किया गया
• पूरे feature को लागू करने में लगभग 1 घंटा लगा

Epilogue

• सेटअप बहुत ज़्यादा चमकदार नहीं है, लेकिन यह बहुत अच्छी तरह काम करता है, और लेखक इस process की reliability से संतुष्ट हैं
• Stavrobot लगभग एक महीने से 24/7 चल रहा है और बहुत स्थिर है