2026 के लिए मेरा LLM कोडिंग वर्कफ़्लो

• AI coding assistants ने 2025 के दौरान वास्तविक development के लिए एक मुख्य tool के रूप में जगह बना ली है, और इन्हें प्रभावी ढंग से इस्तेमाल करने के लिए structured workflow और इंसानी स्तर पर जिम्मेदार हस्तक्षेप ज़रूरी है
• सीधे code generation माँगने के बजाय पहले स्पष्ट spec और planning करना, और उसके आधार पर चरणबद्ध implementation आगे बढ़ाना, quality और productivity दोनों को बेहतर बनाता है
• काम को छोटे हिस्सों में बाँटने और पर्याप्त context व constraints देने से LLM की errors और consistency से जुड़ी समस्याएँ काफ़ी कम की जा सकती हैं
• किसी एक model पर निर्भर रहने के बजाय कई LLMs और tools को उद्देश्य के अनुसार चुनने और पूरे development lifecycle में AI का सहायक रूप में इस्तेमाल करने का तरीका फैल रहा है
• अंततः testing, review, version control के ज़रिए जब इंसान नियंत्रण बनाए रखता है, तब AI एक शक्तिशाली productivity multiplier की तरह काम करता है

---

अवलोकन

• 2025 के दौरान AI coding assistants का वास्तविक product code लिखने में बड़े पैमाने पर इस्तेमाल शुरू हुआ
• Anthropic के engineers ने Claude Code को सक्रिय रूप से अपनाया, और अब स्थिति यह है कि Claude Code के code का लगभग 90% Claude Code खुद लिखता है
• programming में LLM का उपयोग किसी एक button दबाने वाला जादू नहीं है; इसके लिए नए patterns सीखना और critical thinking ज़रूरी है
• AI का आक्रामक रूप से उपयोग किया जा सकता है, लेकिन बने हुए software की ज़िम्मेदारी आखिरकार developer की ही होती है
• मुख्य बात यह है कि LLM को किसी autonomous decision-maker की तरह नहीं, बल्कि स्पष्ट दिशा, context और supervision चाहने वाले एक शक्तिशाली pair programmer की तरह देखा जाए

स्पष्ट योजना से शुरुआत करें (पहले spec, बाद में code)

• LLM को अस्पष्ट request देने के बजाय, पहले problem definition और solution planning से शुरुआत करनी चाहिए
• नए project के मामले में idea समझाकर LLM से बार-बार सवाल पूछने के लिए कहना requirements और edge cases को ठोस बनाने में मदद करता है
• अंत में requirements, architecture decisions, data model और test strategy को शामिल करते हुए उसे spec.md में व्यवस्थित किया जाता है
• इस spec को reasoning-capable model में देकर implementation को तार्किक और छोटे task units में बाँटने वाला project plan बनाया जा सकता है
• Les Orchard के शब्दों में, "15 मिनट में waterfall" जैसी तेज़ लेकिन structured planning phase के बाद coding काफ़ी आसान हो जाती है
• स्पष्ट spec और plan होने पर इंसान और LLM दोनों क्या और क्यों बनाया जा रहा है, इसे ठीक से समझते हैं, जिससे rework और बेकार cycles से बचाव होता है

काम को छोटे और दोहराए जा सकने वाले chunks में बाँटें

• LLM से एक बार में बहुत बड़ा output माँगने के बजाय, project को दोहराए जा सकने वाले चरणों या tickets में बाँटकर क्रम से संभालें
  • उदाहरण: “plan के Step 1 को implement करो” जैसे prompt देकर, coding और testing के बाद Step 2 पर जाना
• एक बार में बहुत बड़ा scope दे देने पर model उलझ सकता है या बेतरतीब नतीजे दे सकता है, और सुधार की लागत तेज़ी से बढ़ जाती है
• जब app के बड़े हिस्से एक साथ generate करवाए गए, तो consistency टूटने और duplicate code की समस्या बढ़ी, यहाँ तक कि यह टिप्पणी भी आई कि “जैसे बिना बातचीत के 10 लोगों ने मिलकर बनाया हो”
• हर iteration में पहले से बने context को आगे बढ़ाते हुए धीरे-धीरे जोड़ना TDD (test-driven development) approach के साथ भी अच्छी तरह मेल खाता है
• कुछ coding agent tools इस chunk workflow को स्पष्ट रूप से support करते हैं और prompt plan files बनाकर उन्हें क्रमवार चलाने देते हैं

व्यापक context और guidance दें

• LLM उसे दिए गए context की सीमा तक ही अच्छा प्रदर्शन करता है, इसलिए संबंधित code, documents और constraints पर्याप्त मात्रा में देने चाहिए
• Claude, Projects mode में पूरे GitHub repo को context के रूप में ला सकता है, और Cursor या Copilot जैसे IDE assistants खुले हुए files को अपने-आप शामिल कर लेते हैं
• brain dump शैली में model को पहले से वह जानकारी दे देना, जो उसे जाननी चाहिए, प्रभावी होता है; इसमें high-level goals, वांछित solution के examples और जिन approaches से बचना है, वे भी शामिल हो सकते हैं
• gitingest या repo2txt जैसे tools से codebase के ज़रूरी हिस्सों को text file में dump करके LLM को दिया जा सकता है
• Claude Skills बार-बार prompting पर निर्भर रहने के बजाय, instructions, scripts और domain expertise को टिकाऊ और reusable modules में बाँधने का तरीका है
  • community द्वारा curated Skills collection भी उपलब्ध है
  • frontend-design skill, LLM द्वारा बनाए गए UI में आम तौर पर दिखने वाली बैंगनी-प्रधान design aesthetics को सुधारने में भी मदद कर सकती है
• prompt के भीतर comments और rules को सीधे शामिल करके AI को guide करना काफ़ी प्रभावी है
  • उदाहरण: “यहाँ X का मौजूदा implementation है। इसे Y तक extend करो, लेकिन Z को मत तोड़ो”
• LLM में निर्देशों को शाब्दिक रूप से मानने की literal tendency होती है, इसलिए जितने अधिक विस्तृत और context-स्पष्ट निर्देश दिए जाएँ, hallucination और अजीब सुझाव उतने कम होते हैं

सही model चुनें (ज़रूरत हो तो कई models का उपयोग करें)

• सभी coding LLM एक जैसे नहीं होते; task की प्रकृति के अनुसार model या service को सोच-समझकर चुनना महत्वपूर्ण है
• कुछ स्थितियों में दो या अधिक LLMs को parallel चलाकर, एक ही समस्या पर अलग-अलग approaches का cross-validation करना प्रभावी हो सकता है
• हर model की अपनी प्रवृत्ति और strengths होती हैं, इसलिए अगर एक model अटक जाए या साधारण नतीजा दे, तो दूसरे model पर जाना समझदारी है
• एक ही prompt को अलग services में ज्यों का त्यों देकर जाँचने वाली ‘model musical chair’ शैली से किसी खास model की blind spots से बचा जा सकता है
• जहाँ संभव हो, latest pro-tier models का उपयोग quality के लिहाज़ से स्पष्ट लाभ देता है
• अगर लंबे समय तक साथ काम करना हो, तो AI pair programmer का "vibe" — यानी उसका response tone और interaction style आपके अनुकूल है या नहीं — भी एक अहम चयन मानदंड है

पूरे lifecycle में AI coding का उपयोग करें

• command-line environment में Claude Code, OpenAI Codex CLI, Google Gemini CLI जैसे AI agents उभरे हैं, जो project directory के भीतर files पढ़ने, tests चलाने और multi-step modifications करने में सक्षम हैं
• Google का Jules और GitHub का Copilot Agent, repo को cloud VM में clone करके काम करने और फिर PR खोलने वाले asynchronous coding agents के रूप में इस्तेमाल किए जा सकते हैं
• ये tools अभी पूर्ण नहीं हैं, इसलिए इनकी सीमाओं को समझकर ही इस्तेमाल करना ज़रूरी है
  • boilerplate generation, दोहराए जाने वाले बदलाव, और automated tests चलाने जैसे यांत्रिक कामों में ये बड़ा acceleration देते हैं, लेकिन quality अब भी इंसानी guidance पर निर्भर करती है
• agents का उपयोग करते समय शुरुआत में ही plan या todo list साथ दे देने से सही task order समझने में बहुत मदद मिलती है
• AI agents अभी उस स्तर पर नहीं पहुँचे हैं जहाँ वे पूरी feature को बिना निगरानी implement करके perfect result दे सकें; supervised उपयोग ही व्यावहारिक approach है
• Conductor जैसे orchestration tools की मदद से कई agents को parallel चलाकर, अलग-अलग features पर एक साथ काम कराने के प्रयोग जारी हैं

Human-in-the-loop बनाए रखें - वैलिडेशन, टेस्टिंग, रिव्यू पूरी तरह करें

• AI बिना झिझक भरोसेमंद दिखने वाला कोड बना देता है, लेकिन क्वालिटी और नतीजों की ज़िम्मेदारी पूरी तरह डेवलपर की होती है
• Simon Willison के शब्दों में, LLM pair programmer को अतिआत्मविश्वासी और गलती करने में आसान इकाई की तरह समझना चाहिए, जो बग या बेकार कोड भी पूरे भरोसे के साथ लिख देता है
• AI द्वारा बनाए गए code snippet को junior developer के कोड की तरह ट्रीट करना चाहिए, और कोड को खुद पढ़ना, चलाना, और ज़रूरत पड़ने पर टेस्ट करना चाहिए
• टेस्टिंग को वर्कफ़्लो में स्वाभाविक रूप से शामिल करें, और planning stage से ही हर चरण के लिए test list और testing plan साथ में डिज़ाइन करें
• Claude Code जैसे टूल्स को task implementation के बाद test suite चलाने का स्पष्ट निर्देश दें, और failure होने पर root cause analysis व fix तक जाएँ
• coding agent का सबसे अच्छा उपयोग आमतौर पर वही टीमें और व्यक्ति कर पाते हैं जिनकी मज़बूत testing culture होती है
• जिन environments में टेस्टिंग नहीं है, वहाँ agent कई हिस्से वास्तव में तोड़ देने के बाद भी सब ठीक है मानकर आगे बढ़ने का जोखिम रहता है
• automation tests के अलावा code review को अनिवार्य चरण बनाए रखें, और manual review के साथ AI-based review भी करें
  • अलग AI session या दूसरे model का उपयोग करके पहले AI द्वारा लिखे गए कोड की आलोचना या समीक्षा करने को कहें
  • उदाहरण: Claude कोड लिखने के बाद Gemini से उस function में error या improvement की संभावना जाँचने को कहना
• Chrome DevTools MCP को debugging और quality loop के मुख्य टूल के रूप में इस्तेमाल करें, ताकि static analysis और वास्तविक browser execution के बीच की दूरी घटे
  • AI agent को DOM structure, performance trace, console log और network request सीधे देखने की access दें
  • context को हाथ से इधर-उधर ले जाए बिना LLM-based automated UI testing की जा सकती है
  • वास्तविक runtime data के आधार पर बग को सटीक रूप से diagnose और fix करने वाला flow संभव होता है
• एक डेवलपर ने कहा कि जल्दबाज़ी वाले प्रोजेक्ट में AI generation पर ज़रूरत से ज़्यादा निर्भर रहने का नतीजा असंगत और बिखरा हुआ mess था
  • duplicate logic, अलग-अलग method names, और unintegrated architecture जमा होते गए
  • उन्होंने माना कि वे बस लगातार बनवाते रहे, लेकिन AI द्वारा जोड़ी गई पूरी संरचना की जाँच करने के लिए एक कदम पीछे नहीं हटे
  • अंत में बड़े पैमाने पर refactoring करनी पड़ी और इस निष्कर्ष पर पहुँचे कि अब कभी बिना निगरानी के इसे नहीं छोड़ेंगे
• AI के उपयोग की मात्रा चाहे जो हो, डेवलपर को अंत तक ज़िम्मेदार engineer बने रहना चाहिए
• व्यवहारिक रूप से, कोड को समझ लेने के बाद ही merge या deploy करें, और अगर AI जटिल implementation दे तो explanation comments जोड़ने या उसे अधिक सरल रूप में फिर से लिखने को कहें

बार-बार commit करें और version control को safety net की तरह इस्तेमाल करें

• AI के साथ जितना तेज़ी से और जितनी बड़ी मात्रा में कोड बनता है, उतनी ही सघन version control आदतें ज़रूरी होती हैं
• हर छोटे task के पूरा होने पर या automated fix सफल होने पर स्पष्ट अर्थ वाले message के साथ git commit करें, ताकि अगला बदलाव समस्या पैदा करे तो तुरंत rollback के लिए checkpoint हो
• commit को गेम के save point की तरह समझें, ताकि LLM session पटरी से उतर जाए तो कभी भी आख़िरी stable state पर लौटा जा सके
• AI के साथ collaboration में भी version control महत्वपूर्ण है, क्योंकि context window की सीमा के कारण वह सभी बदलाव याद नहीं रख पाता, और ऐसे में git history एक भरोसेमंद work log बन जाती है
• हाल के commits को देखकर बदलावों का AI या खुद को जल्दी briefing दिया जा सकता है
• अगर prompt में git diff या commit log शामिल किया जाए, तो LLM नए कोड और पिछली स्थिति को सही तरह समझ पाता है
• LLM diff समझने और git bisect जैसे टूल्स इस्तेमाल करने में सक्षम होता है, इसलिए commit history के सहारे बग के आने की जगह को डटे रहकर ट्रेस किया जा सकता है
• छोटे-छोटे commits और स्पष्ट messages विकास प्रक्रिया को स्वाभाविक रूप से रिकॉर्ड करते हैं, जो code review में बहुत मददगार होते हैं
• जब AI agent एक साथ कई बदलाव करता है, तब भी अगर बदलाव commit इकाइयों में अलग हों तो समस्या पैदा करने वाले बिंदु को सटीक रूप से पहचानना आसान होता है
• branch या worktree का उपयोग करके AI experiments को production code से अलग रखें
  • Jesse Vincent से प्रेरित तरीके में, हर नए feature या sub-project के लिए fresh git worktree बनाया जाता है
  • उसी repo में कई AI coding sessions को बिना आपसी हस्तक्षेप के parallel चलाकर बाद में नतीजों को चुनिंदा रूप से merge किया जा सकता है
  • यह ऐसा है मानो हर AI task अपनी sandbox branch में हो, इसलिए असफल experiment को फेंक देने पर भी main पर असर नहीं पड़ता
• ऐसा कोड कभी commit न करें जिसे आप समझते नहीं या समझा नहीं सकते

नियमों और उदाहरणों से AI का व्यवहार customize करें

• AI की default style या approach को वैसे ही स्वीकार करने के बजाय, स्पष्ट guidelines देने भर से output की quality और consistency पर बड़ा असर पड़ता है
• CLAUDE.md फ़ाइल को नियमित रूप से मैनेज करें ताकि Claude जिन process rules और preferences का पालन करे वे स्पष्ट हों, और Gemini CLI इस्तेमाल करते समय उसी तरह GEMINI.md का उपयोग करें
  • उदाहरण: project style के अनुसार कोड लिखना, lint rules का पालन, कुछ specific functions का उपयोग न करना, OOP की जगह functional style को प्राथमिकता देना आदि
  • session शुरू होने पर वह फ़ाइल Claude को देकर पूरे काम को उन नियमों के अनुसार रखना
  • Jesse Vincent के अनुसार, इस तरीके से AI के अनचाही दिशा में भटकने या अपरिचित patterns लाने की आवृत्ति कम होती है
• अलग rule file न होने पर भी custom instructions या system prompt के ज़रिए overall tone और behavior सेट किया जा सकता है
  • GitHub Copilot और Cursor दोनों project स्तर पर AI behavior को globally सेट करने की सुविधा देते हैं
  • coding style को छोटे paragraph में लिखें: “4 space indentation का उपयोग करें, React में arrow function से बचें, descriptive variable names लिखें, कोड को ESLint pass करना चाहिए”
  • Ben Congdon ने कहा कि Copilot के custom instructions feature का लगभग उपयोग न होना उन्हें हैरान करता है, और उनका कहना था कि पहले से कुछ examples और preferences देने भर से टीम की प्रचलित शैली के अनुरूप कोड आउटपुट मिल सकता है
• inline examples देना खास तौर पर बहुत प्रभावशाली तकनीक है
  • अगर किसी function को किसी खास तरीके से implement कराना हो, तो पहले codebase में पहले से मौजूद मिलता-जुलता function दिखाकर कहें, “X को ऐसे implement किया गया है, इसलिए Y में भी यही approach इस्तेमाल करो”
  • अगर comment style मिलानी हो, तो पहले खुद एक line लिखकर उसी style को आगे जारी रखने को कहें
  • अंततः यह model को किसी pattern से prime करने का तरीका है, और LLM इस तरह की नकल में बहुत मज़बूत होता है
• community में LLM behavior को बेहतर बनाने के लिए कई तरह के ruleset साझा किए जाते हैं
  • "Big Daddy" नियम या prompt में “hallucination·deception निषिद्ध” जैसी धारा जोड़ने का तरीका
  • ये ऐसे उपाय हैं जो AI द्वारा अस्तित्वहीन कोड गढ़ने या ज़रूरत से ज़्यादा आत्मविश्वास दिखाने वाले व्यवहार को कम करते हैं
  • उदाहरण: “अगर अनिश्चित हो या codebase context न हो, तो जवाब मत गढ़ो, बल्कि clarification माँगो” को prompt की शुरुआत में जोड़ने से hallucination कम होती है
  • एक और नियम यह हो सकता है: “bug fix करते समय हमेशा comment में संक्षेप में कारण समझाओ”, ताकि AI // Fixed: spec के अनुसार Z को रोकने के लिए X को Y में बदला जैसे explanation comments भी छोड़े

टेस्टिंग और ऑटोमेशन को फ़ोर्स मल्टिप्लायर की तरह अपनाना

• CI/CD, linter, और code review bot का जितना ज़्यादा सक्रिय उपयोग होगा, AI उतना ही ऐसे वातावरण में सबसे बेहतर काम करता है जहाँ गलतियाँ अपने-आप पकड़ ली जाती हैं
• जिन repositories में AI coding का अनुपात ज़्यादा है, उनमें मज़बूत continuous integration environment अनिवार्य है
  • हर commit या PR पर automated tests चलाना, ESLint·Prettier जैसे code style checks को अनिवार्य करना, और संभव हो तो branch-wise staging deployment तक शामिल करना
  • इसे इस तरह भी सेट किया जा सकता है कि AI खुद इन्हें trigger करे और परिणामों का आकलन करे
  • उदाहरण: Jules या GitHub Copilot Agent PR खोलते हैं, CI tests चलाता है और failure report करता है → failure logs AI को देकर इसे “integration test XYZ पर fail हुआ, चलो मिलकर debug करें” से जोड़ा जा सकता है
  • bug fix की प्रक्रिया तेज़ feedback वाले collaborative loop में बदल जाती है, और AI इसमें खास तौर पर अच्छा जवाब देता है
• automated code quality checks भी AI के लिए दिशा-सूचक का काम करते हैं
  • linter output को prompt में जस का तस शामिल करें; अगर AI ने lint में फँसने वाला code लिखा है, तो error messages कॉपी करके कहें “इन समस्याओं को हल करो”
  • इसका असर वैसा होता है जैसे कोई सख़्त शिक्षक AI के कंधे के ऊपर से नज़र रख रहा हो
  • AI जब test failures या linter warnings जैसे tool output को देखता है, तो वह लगातार सुधार करने की कोशिश करता है
• AI coding agents खुद भी धीरे-धीरे automation hooks built-in कर रहे हैं
  • कुछ agents तब तक काम को “complete” नहीं मानते जब तक सभी tests pass न हो जाएँ
• code review bots, चाहे AI हों या इंसान, अतिरिक्त filter के रूप में भी उपयोगी हैं
  • review comments को सीधे improvement prompt की तरह इस्तेमाल किया जा सकता है
  • उदाहरण: अगर CodeRabbit या कोई दूसरा reviewer लिखे कि “यह function X कर रहा है, लेकिन यह आदर्श नहीं है”, तो AI से पूछा जा सकता है, “क्या तुम इस feedback को लागू करते हुए refactor कर सकते हो?”
• AI और automation को मिलाने पर एक सकारात्मक feedback loop बनता है
  • AI code लिखता है → automation tools समस्या पकड़ते हैं → AI सुधार करता है → दोहराव चलता रहता है, और developer सिर्फ high-level दिशा की निगरानी करता है
  • मानो एक बेहद तेज़ junior developer का काम कोई कभी न थकने वाला QA engineer तुरंत verify कर रहा हो
  • लेकिन यह वातावरण developers को खुद बनाना पड़ता है, और जिन projects में tests या automation नहीं हैं, वहाँ AI के subtle bugs या quality degradation बहुत बाद में सामने आने का ख़तरा रहता है
• 2026 की ओर जाते हुए लक्ष्यों में से एक है AI code contributions के आसपास quality gates को और मज़बूत करना
  • ज़्यादा tests, ज़्यादा monitoring, और ज़रूरत पड़े तो ऐसी संरचना भी जिसमें AI, AI का review करे
  • वास्तव में ऐसे मामले देखे गए हैं जहाँ एक model से छूटी समस्या को दूसरे model ने पकड़ लिया

सतत सीखना और अनुकूलन (AI स्किल्स को बढ़ाता है)

• अगर हर AI coding session को सीखने के अवसर की तरह लिया जाए, तो ज्ञान बढ़ने के साथ AI की मदद भी बढ़ती है और एक सकारात्मक चक्र बनता है
• development में LLM का उपयोग करते हुए स्वाभाविक रूप से नई languages, frameworks, और techniques से परिचय होता है, जिन्हें शायद सामान्य तौर पर आज़माया न जाता
• जब software engineering की बुनियाद मज़बूत हो, तो AI productivity को कई गुना बढ़ा सकता है; लेकिन बुनियाद कमज़ोर हो, तो उलझन भी उसी तरह बढ़ती है
• अनुभवी developers का एक साझा अवलोकन है कि LLMs में मौजूदा best practices को मज़बूत करने की प्रवृत्ति होती है
  • स्पष्ट specs लिखना, अच्छे tests रखना, और नियमित code review करना—AI के शामिल होने पर इनका असर और बड़ा हो जाता है
• जब AI boilerplate संभाल लेता है, तो developer design, interfaces, और architecture जैसी high-level abstractions पर ध्यान दे सकता है, लेकिन इसके लिए ये क्षमताएँ पहले से होनी चाहिए
• Simon Willison के अनुसार, लगभग हर वह चीज़ जो किसी engineer को senior बनाती है—system design, complexity management, automation और manual work के बीच निर्णय—अब AI के साथ मिलकर सबसे अच्छे परिणाम देती है
• AI का उपयोग वास्तव में engineering capability को बेहतर बनाने को प्रेरित कर सकता है
  • planning stage में व्यक्ति अधिक सख़्त हो जाता है और architecture के बारे में अधिक सजग होकर सोचता है
  • AI की भूमिका एक बहुत तेज़ लेकिन कुछ हद तक भोले coder की तरह होती है, और उसे manage करते हुए निर्णय क्षमता मज़बूत होती है
• इस चिंता के जवाब में कि AI कौशल घटा सकता है, सही उपयोग होने पर नतीजा उलटा भी हो सकता है
  • AI code reviews के ज़रिए नए idioms और problem-solving approaches सीखी जा सकती हैं
  • AI की गलतियों को debug करते हुए language और problem domain की समझ गहरी होती है
  • उससे code या fixes के कारण समझाने को कहकर, मानो किसी candidate का interview ले रहे हों, लगातार सवाल पूछे जा सकते हैं और insights निकाले जा सकते हैं
  • जब library या approach स्पष्ट न हो, तो AI को research assistant की तरह इस्तेमाल कर options और trade-offs की तुलना की जा सकती है
• बड़े परिप्रेक्ष्य में AI tools विशेषज्ञता को amplify करते हैं
  • 2026 के करीब जाते हुए नौकरियाँ छिनने के डर से ज़्यादा यह उम्मीद है कि repetitive और नीरस कामों से मुक्ति मिलेगी और creative व complex problems पर अधिक समय लगाया जा सकेगा
  • इसके उलट, अगर मज़बूत आधार न हो, तो AI steroid लगे Dunning-Kruger effect की तरह भी काम कर सकता है
• सलाह यही है कि skills को लगातार निखारते रहें, AI से learning और productivity को तेज़ करें, और समय-समय पर AI के बिना coding भी करें ताकि fundamentals तेज़ बने रहें
• अंततः developer और AI का संयोजन अकेले किसी एक से कहीं ज़्यादा शक्तिशाली है, और इस संयोजन में developer को अपनी भूमिका पूरी ज़िम्मेदारी से निभानी होगी

निष्कर्ष

• AI को development workflow के पूरे दायरे में सक्रिय रूप से अपनाया गया है, लेकिन सावधान और expert-led approach बनाए रखी गई है
• लक्ष्य ऐसा development नहीं है जहाँ AI सब कुछ automate कर दे, बल्कि “AI-augmented software engineering” है
• सबसे अच्छे परिणाम तब मिलते हैं जब AI के साथ सहयोग में भी पारंपरिक software engineering discipline को ज्यों का त्यों लागू किया जाए
• design के बाद coding, tests लिखना, version control, और code standards बनाए रखना जैसी कठिनाई से विकसित की गई सभी practices अब भी वैध हैं, और जब AI आधा code लिख रहा हो तब वे और भी ज़्यादा महत्वपूर्ण हो जाती हैं
• tools लगातार आगे बढ़ेंगे, और workflow भी उनके साथ विकसित होगा
  • पूरी तरह autonomous “AI development intern” अधिक simple tasks संभाल सकता है, जबकि इंसान high-level समस्याओं पर ध्यान देगा
  • debugging के नए तरीके और code exploration के नए paradigms उभर सकते हैं
• किसी भी बदलाव के बीच हमेशा loop के भीतर बने रहने का रवैया बनाए रखना ज़रूरी है
  • AI को guide करें, results को verify करें, उस प्रक्रिया से सीखें, और ज़िम्मेदारी के साथ productivity बढ़ाएँ
• अंतिम निष्कर्ष स्पष्ट है: AI coding assistants शक्तिशाली amplifiers हैं, लेकिन मंच का director अंत तक मानव engineer ही रहता है