- प्रभावी software engineer requirements और code का एक स्पष्ट mental model बनाते और बनाए रखते हैं, और इसे बार-बार तुलना व अपडेट करने वाले loop में काम करते हैं
- LLM code लिखना और संशोधित करना, test लिखना, debugging करना जैसे काम कर सकते हैं, लेकिन सटीक mental model बनाए रखने की क्षमता की कमी के कारण जटिल कामों में भ्रमित हो जाते हैं
- मौजूदा LLM में context omission, recency bias, और hallucination जैसी समस्याओं के कारण code और requirements के बीच अंतर को सही तरह पहचानने और उपयुक्त रूप से सुधारने में सीमाएँ हैं
- इंसान परिस्थिति के अनुसार पूरे context को अस्थायी रूप से याद में रख सकता है, या details को थोड़ी देर छिपाकर बड़ी तस्वीर देख सकता है, लेकिन LLM यह नहीं कर पाते
- LLM सरल requirements वाले कामों में उपयोगी हैं, लेकिन जटिल software development में अंततः software engineer को ही requirements की स्पष्टता और code के व्यवहार की ज़िम्मेदारी लेनी होती है, और LLM की भूमिका सहायक tool की होती है
Software engineering loop
- अनुभवी engineer नीचे दिए गए चरणों को दोहराते हुए काम करते हैं
1. requirements का mental model बनाना
2. उस model के अनुसार code लिखना
3. यह समझना कि लिखा गया code वास्तव में क्या करता है
4. अंतर पहचानकर code या requirements में सुधार करना - इस loop का मूल सटीक और टिकाऊ mental model रखने की क्षमता है
LLM की सीमाएँ
- LLM code लिखना, समस्या पहचानकर उसे ठीक करना, test लिखना और चलाना, logging जोड़ना, debugger का उपयोग करना जैसे काम कर सकते हैं
- लेकिन mental model बनाए रखने में असफल होने के कारण नीचे जैसी समस्याएँ होती हैं
- यह मान लेना कि उनके द्वारा लिखा गया code ठीक से काम कर रहा है
- test fail होने पर code और test में से किसे ठीक करना है, यह अनुमान से तय करना
- भ्रम होने पर पूरा code हटाकर फिर से शुरू से लिखना
- इंसानों के विपरीत, test fail होने पर model की जाँच कर सही सुधार दिशा तय करना, या निराशा की स्थिति में बातचीत के माध्यम से समस्या सुलझाना जैसी लचीलापन उनमें कम है
- software engineer काम के बीच में test चलाते हैं और समस्या आने पर स्पष्ट रूप से तय कर सकते हैं कि किस हिस्से को सुधारना चाहिए
- कभी-कभी पूरे काम को फिर से शुरू करने पर भी समस्या की समझ और गहरी हो जाती है
आगे की संभावनाएँ
- भविष्य में model अधिक विकसित होने पर स्थिति बदल सकती है, लेकिन software engineering सिर्फ code generation से कहीं अधिक की माँग करती है
- इंसान महत्वपूर्ण समस्याएँ हल करते समय पूरे context को अस्थायी रूप से memory से निकालकर देख सकते हैं, किसी issue पर केंद्रित हो सकते हैं, या बड़ी तस्वीर देख सकते हैं
- सिर्फ context information को लगातार बढ़ाते जाने के बजाय, ज़रूरी जानकारी को चुनकर संभालने का सोचने का तरीका अधिक महत्वपूर्ण है
- इंसानों की तरह context को अस्थायी रूप से store और restore करना, या बड़ी तस्वीर और details के बीच आना-जाना करके सोचना, ऐसी क्षमता LLM में नहीं है
- मौजूदा LLM की मुख्य सीमाएँ
- प्रसंग छूटना (Context omission): ज़रूरी जानकारी छूट गई है या नहीं, इसे ठीक से पहचान नहीं पाते
- हालिया-प्रभाव पक्षपात (Recency bias): context window के भीतर सबसे हाल की जानकारी पर अत्यधिक निर्भरता
- मतिभ्रम (Hallucination): ऐसी details गढ़ लेना जो वास्तव में मौजूद नहीं हैं
- memory features जुड़ने पर कुछ सुधार संभव है, लेकिन जटिलता बढ़ने पर फिर भी context की समझ और model बनाए रखने में विफलता होती है
- दो मिलते-जुलते mental model को साथ बनाए रखकर उनका अंतर विश्लेषित करना, और requirements या code में कहाँ बदलाव करना चाहिए यह तय करना—इस क्षमता की कमी है
वर्तमान भूमिका और उपयोग
- LLM तेज code generation और requirements व documentation को एकीकृत करने में मजबूत हैं, इसलिए सरल और स्पष्ट कामों में पर्याप्त उपयोगी हैं
- लेकिन गैर-सरल समस्याओं में पर्याप्त context बनाए रखना और दोहरावदार सुधार करना कठिन है
- इसलिए requirements को स्पष्ट करना, code verification करना आदि अब भी software engineer की ज़िम्मेदारी है
- ऐसे माहौल की दिशा में बढ़ा जा रहा है जहाँ इंसान और agent (LLM) मिलकर software बनाते हैं, लेकिन अभी के लिए engineer को नेतृत्व करना चाहिए और LLM को tool की तरह उपयोग करना चाहिए
2 टिप्पणियां
क्यों 'वर्तमान' के LLM..
Hacker News राय
हम केवल context window में और ज़्यादा शब्द जोड़कर समस्या हल नहीं करते; ऐसा करें तो हमारा दिमाग़ ठीक नहीं रहेगा
जब समस्या आती है, तो हम उसे सिर्फ़ text के रूप में भी नहीं देखते
debugger में authentication error आया तो हम यह नहीं सोचते कि "क्या code से token validation ही हटा दें?"
हम असल root cause समझने के लिए पूरे हालात को एक क़दम पीछे हटकर देखते हैं
उदाहरण के लिए, authentication error आया हो तो token validation process, call करने वाले user permissions आदि सब दोबारा देखते हैं, और यह भी समझ सकते हैं कि test ख़ुद ही ग़लत था
इस प्रक्रिया में केवल error हटाना ही नहीं, बल्कि यह भी पता चलता है कि "401 सिर्फ़ unauthenticated होने के लिए है या insufficient permissions के लिए अलग distinction चाहिए" जैसी बातों को और बारीकी से अलग करना ज़रूरी है
Grugbrain.dev देखें
मेरा मानना है कि programmer का काम business rules को ऐसे सख़्त रूप में translate करना है जिसे computer समझ सके
यह translation हमेशा आसान नहीं होता, क्योंकि rules का मतलब क्या है और computer — या इस्तेमाल हो रहे framework और abstraction layers — कैसे काम करते हैं, यह दोनों साथ समझना पड़ता है
ख़ासकर जब नई requirements पहले की सारी assumptions तोड़ दें या एक-दूसरे से टकराएँ, तब कई बार वापस जाकर सुधार करना पड़ता है
इंसानों की language translation भी ambiguity की वजह से जटिल होती है, और computer तो जो कहा गया है वही ठीक-ठीक करता है, इसलिए छोटी गलती भी बड़ा issue बन सकती है
मेरे हिसाब से इंसानों की लगातार, iterative involvement वाला तरीका ही व्यावहारिक approach है
इसी तरीके से काम तेज़ और बेहतर quality में हो पाता है, इसलिए मैं इसे इस्तेमाल करता रहता हूँ
मैं व्यक्तिगत रूप से बहुत बड़ा context अपने दिमाग़ में रख सकता हूँ
code text ख़ुद जल्दी ही छूट जाता है, और मेरा दिमाग़ code को AST (abstract syntax tree) जैसी structure, उससे भी आगे spatial graph की तरह parse करता है
मैं program को logical model के रूप में देखता हूँ, text से बिल्कुल अलग structure के तौर पर
इस नज़रिए से LLM software structure को समझ नहीं पाते, क्योंकि वे text पर अटके रहते हैं और program का logical model नहीं बना पाते
बड़े system architecture, जहाँ abstract thinking चाहिए, वहाँ बहुत ज़्यादा mental effort लगता है, लेकिन LLM में ऐसी abstraction क्षमता कमज़ोर है
मेरा तरीका यह है
जब test failure report होती है, तो पहले उस component की पहचान करता हूँ, फिर उसके purpose, internal control flow, state changes, और आसपास के context के assumptions तक का गहरा analysis करके Markdown notes बनाता हूँ (
<컴포넌트명>-mental-model.md)उसके बाद test issues पर काम करते समय हमेशा उसी mind model को reference करता हूँ
अगर यह analysis Claude prompt में paste कर दूँ, तो LLM बेहतर नतीजे दे सकता है
यहाँ तक कि LLM ने जो mind model बनाया हो, उसे मैं ख़ुद पढ़कर edit भी कर सकता हूँ
AI शायद यह सलाह दे कि insufficient permissions के मामले में 401 की जगह 403 इस्तेमाल करना चाहिए
लगता है लेख के लेखक LLM और coding tools की मौजूदा क्षमता को ठीक से नहीं समझते
यह दावा कि test fail होने पर LLM बस अंदाज़ा लगाते हैं कि code सही है या test ग़लत, और frustrate होने पर पूरा code ही मिटा देते हैं — मेरे वास्तविक अनुभव से मेल नहीं खाता
software engineers हमेशा अपने mental model के आधार पर test failure का ठोस कारण समझने की कोशिश करते हैं
मैं Cline और Anthropic Sonnet 3.7 के साथ Rails में TDD style से development करता हूँ, और LLM से हमेशा पहले test लिखवाता हूँ, फिर code
काम को छोटे हिस्सों में बाँट देता हूँ ताकि मैं हर भाग review कर सकूँ, और test fail होने पर वह काफ़ी अच्छी तरह infer करके सही हिस्से में fix भी कर देता है
LLM perfect नहीं हैं, लेकिन कई बार junior engineer जितने या उनसे बेहतर results भी दे देते हैं
कभी-कभी bug fix नहीं कर पाते, लेकिन नए human developers भी ऐसा ही करते हैं
LLM ख़ासकर Rails जैसे well-established framework के अंदर CRUD कामों में बहुत अच्छे चलते हैं
लेकिन जब मैंने Direct2D और Rust से native Windows app बनवाने की कोशिश की, तब अनुभव बहुत ख़राब था
अच्छा होगा अगर अलग-अलग cases पर ज़्यादा खुला आकलन हो
failed tests को pass कराने के लिए models का hacks और tricks — जैसे hardcoding — इस्तेमाल करना एक बहुत जाना-पहचाना phenomenon है
मेरे अनुभव में इस्तेमाल की जा रही language, platform, और domain के हिसाब से काफ़ी अंतर आता है
हाल में मैंने Rails पर experiment नहीं किया क्योंकि Ruby ख़ुद भी अब मैं नहीं चलाता, लेकिन Rails ecosystem में programming culture बहुत consistent है, इसलिए LLM वहाँ ठीक-ठाक अच्छा कर सकते हैं
इसके उलट Python में अलग-अलग coding styles का मिश्रण इतना होता है कि LLM कई patterns मिला देते हैं और tests unstable हो जाते हैं
बार-बार code बदलना पड़ता है, और असली bug अगर "query results sorting missing" हो, तो LLM उल्टा SqlAlchemy हटाकर Django पर switch करने जैसी अजीब सलाह भी दे सकता है
R language में specification के मुताबिक़ सही code लेना ही मुश्किल स्तर का काम है
अगर LLM को junior engineer स्तर का मानें, तो जिन समस्याओं जैसी चीज़ें वह पहले देख चुका है उनमें वह बहुत तेज़ी से solution ढूँढकर apply कर देता है
लेकिन जिन समस्याओं को उसने पहले नहीं देखा, उनमें उसे ज़्यादा explanation और guidance चाहिए होती है; ऐसे में मेरी भूमिका बस mentor जैसी रह जाती है
हमारी team लंबे समय से backlog में पड़े छोटे refactoring या secondary analysis systems जैसे well-known repetitive tasks में ‘claude-code’ style से LLM का सक्रिय उपयोग कर रही है
मैं व्यक्तिगत रूप से code blocks drag करके "इसे 5 साल के बच्चे की तरह समझाओ" या "देखो इसमें race condition का risk है या नहीं" जैसी queries बहुत पसंद से इस्तेमाल करता हूँ
generated code अक्सर existing code और style से अलग होता है, इसलिए मुझे उसे style के हिसाब से हाथ से ठीक करना पड़ता है
आजकल तो यह भी सुनने को मिलता है कि 'AI को पढ़ने में आसान code लिखा जा रहा है', लेकिन अतिरिक्त overhead के मुक़ाबले अभी मुझे फ़ायदा बहुत बड़ा नहीं लगता
"LLM कभी-कभी junior से बेहतर या बराबर होता है" इस दावे पर मुझे लगता है कि शायद यह हाल के developer hiring standards का भी प्रतिबिंब हो सकता है
अगर मैंने Sonnet 3.7 से कमज़ोर junior hire किया हो, तो वह सचमुच निराशाजनक होगा
LLM पर की जाने वाली ज़्यादातर आलोचनाएँ सही हो सकती हैं, लेकिन कई साल के investing experience से मैंने सीखा है कि उन technologies और companies पर ध्यान देना चाहिए जो अभी कमज़ोर लगती हैं, फिर भी लगातार grow करती रहती हैं
90 के दशक की शुरुआत और मध्य में internet को लेकर बहुत शिकायतें थीं, फिर भी लोग उसका इस्तेमाल करते रहे; Twitter भी अक्सर down होता था, फिर भी news platform बन गया
electric vehicles, smartphones वगैरह भी असुविधाजनक थे, लेकिन उनमें value थी, इसलिए वे लगातार बेहतर होते गए
LLM अभी कई कामों में perfect नहीं हैं, लेकिन 2022 की तुलना में वे पहले ही 10 गुना आगे बढ़ चुके हैं, और मेरा मानना है कि अगले 5 साल में यहाँ उठाई गई ज़्यादातर समस्याएँ भी हल हो जाएँगी
लेकिन ऊपर दिए गए हर उदाहरण में कई बार expectations और reality का मेल नहीं बैठा
internet तेज़ हुआ, फिर भी metaverse मुख्यधारा नहीं बना; VR sickness जैसी physical limits अब भी हल नहीं हुईं
उस समय लोग यह शिकायत नहीं कर रहे थे कि phone धीमे हैं; expected use case ही अलग था
सिर्फ़ यह देखकर कि कुछ technologies एक दिशा में बढ़ीं, यह पक्का नहीं कहा जा सकता कि LLM भी उसी pattern पर evolve करेंगे
यह भी ध्यान में रखना चाहिए कि कोई नई technology बेहतर solution लेकर आ सकती है
पिछले साल application areas ज़रूर बढ़े हैं, लेकिन जिसे असली breakthrough कहा जाए वैसी चीज़ अभी नहीं आई
पुराने mobile phones धीमे थे, camera quality भी कमज़ोर थी, लेकिन अपने समय के मुख्य काम — कहीं भी, कभी भी संपर्क कर पाना — की वजह से वे तब भी ज़रूरी थे
बड़ी प्रगति बस 'bonus' थी; लोग यह सोचकर इंतज़ार नहीं कर रहे थे कि 'देखें यह phone कब अच्छा होगा'
मुझे लगता है इसमें memory distortion भी है
90 के दशक के internet को लेकर आम जनता की शिकायतों की बात अलग है, पर users बहुत कम थे और mainstream बनने में काफ़ी समय लगा
असल में internet के धीमे होने पर बड़े पैमाने पर public complaints थीं, इसका सबूत बहुत कम है
हम अक्सर केवल उन्हीं कुछ products को याद रखते हैं जो सफलतापूर्वक आगे बढ़े; ज़्यादातर तो जल्दी भुला दिए गए या बिना सुधरे ग़ायब हो गए
मैं technology के भविष्य के वादों से ज़्यादा उसकी वर्तमान स्थिति के आधार पर आकलन करना पसंद करता हूँ
पिछले कुछ वर्षों में LLM की तेज़ प्रगति आगे भी उसी तरह जारी रहेगी — इस सीधी रेखा वाले तर्क से मैं सहमत नहीं हूँ
growth limits आ सकती हैं, और मुझे ख़ासकर लगता है कि नई knowledge discovery या unknown information पर reasoning की कमी LLM की निर्णायक सीमा है
मैं यह नहीं कह रहा कि वे बेकार tools हैं, लेकिन अतिशयोक्तिपूर्ण उम्मीदों में शामिल नहीं होऊँगा
LLM से बस कुछ वाक्य सुनाकर तुरंत prototype तक code कर देने की उम्मीद करना अपने-आप में अवास्तविक है
अगर किसी human dev team से भी ऐसे काम करवाएँ, तो वे भी कुछ ढंग का नहीं बना पाएँगे; फिर LLM से ऐसी उम्मीद क्यों की जाती है, यह सवाल है
LLM software development output की quality को बहुत बेहतर बनाना हो, तो existing dev teams के processes और tools का सक्रिय उपयोग करना पड़ेगा
autonomous-software लेख
मैंने steadytext नाम का एक project शुरू किया, जहाँ code पूरी तरह autonomous और vibe-driven तरीके से लिखा गया; LLM ने 7,000 lines के जटिल project (Python library, CLI, Postgres extension) तक लिखे और issues व feature requests भी ख़ुद ही संभाले
मैंने code का 90% तो ख़ुद देखा तक नहीं, फिर भी full test coverage, CI pass, और production use तक सब बिना समस्या चला
ज़रूरी यह है कि CLAUDE.md में बहुत सावधानी से plan हो, और issues व requests स्पष्ट व ठोस हों; इतनी तैयारी हो तो यह अच्छी तरह काम करता है
coding agent को efficiently manage/write कराना आसान नहीं है, लेकिन मेरा अनुभव सकारात्मक रहा है
steadytext GitHub
आलोचनात्मक नज़रिए मैं मानता हूँ, लेकिन ambiguous problem solving में आख़िरकार core बात यह है कि पूरी team बहुत सारा context साझा करे
सबसे creative solutions भी explicit और implicit constraints से निकलते हैं
LLM ऐसी constraints को पहचानने, या अच्छी तरह define न की गई constraints के भीतर नया solution गढ़ने में सक्षम नहीं हैं
problem definition, scope समझना, और constraints समझना — यह सब humans के बाद ही LLM implementation assist करने वाले tool बन सकते हैं
अभी के लिए यह बस "code पूरा करने के लिए कौन-सा tool इस्तेमाल करें?" जैसी एक और choice भर है
इस बहस को absolute single-solution यानी all-or-nothing की तरह ले जाना ही शायद ज़्यादा अवास्तविक है
सच तो यह है कि ऐसी परिस्थितियों में ठीक-ठाक काम करने वाले human engineers भी बहुत हैं
अगर LLM को निर्देश देना ही इतना आसान नहीं है, तो फिर उनके होने का मतलब क्या है — यह सवाल उठता है
Kiro इस approach को अपना रहा है; अभी शुरुआती दौर है इसलिए perfect नहीं, लेकिन अगर उसके intended flow में काम करें तो काफ़ी ठीक लगता है
"LLM साफ़ mind model नहीं बना पाते" — claude code इस्तेमाल करते हुए मुझे यह बात दिनोंदिन ज़्यादा frustrating लगती है
यक़ीन नहीं कि text-based LLM इस समस्या को सच में हल कर पाएँगे
इससे मुझे Google Genie 3 का वह case याद आता है जहाँ वह लगभग 1 minute के भीतर internal state खो देता है
सहज रूप से लगता है कि यह समस्या तभी हल होगी जब transformer स्तर से आगे कोई नई architecture आए, जो short-term और long-term context के साथ self-weight adjustment — एक तरह की learning imitation — संभाल सके
संदर्भ: संबंधित चर्चा
हाल में मुझे लगने लगा है कि hierarchical agent structure शायद एक व्यावहारिक विकल्प हो सकता है
अगर top-level agent सिर्फ़ overall mind model बनाए रखे और नीचे के agents आपस में काम बाँट लें, तो यह अच्छा हो सकता है
अभी भी शायद Code tool के agent features से ऐसा कुछ बनाया जा सकता है; अगर किसी के पास strategy हो तो साझा करे
claude-code-requirements-builder आज़माया, तो थोड़ी मदद मिली, लेकिन अभी भी संतोषजनक नहीं लगा
व्यवहारिक रूप से देखें तो कामकाजी माहौल में 'औसत' junior developer भी नीचे लिखी बातों से बहुत अलग नहीं होता
उसे लगता है कि जो code उसने बनाया वही सही है, test fail हो तो घबरा जाता है, और दिशा न मिले तो सबसे बुरे हाल में पूरा code मिटाकर फिर से शुरू कर देता है
StackOverflow से copy-paste, compiler को दोष, यहाँ तक कि 'cosmic radiation' जैसी बातें भी सुनने को मिलती हैं
LLM का इस्तेमाल करते-करते मुझे ख़ुद भी महसूस हुआ है कि planning और design की कमान आख़िरकार मुझे ही संभालनी पड़ती है
low-level repetitive work और tests LLM को दे देना, और ख़ुद बड़े चित्र पर सोचने का समय निकाल पाना — यह मुझे अच्छा लगता है
बस मैं चाहता हूँ कि LLM के output review, change suggestions आदि कहीं ज़्यादा interactive तरीके से बेहतर हों
मुझे लगता है कि AI startups की दिशा ही अभी असली मुद्दा है
सिर्फ़ chat interface नहीं, बल्कि IDE के भीतर स्वाभाविक रूप से integrated AI workflow चाहिए
Visual Studio, InteliJ, Android Studio जैसी दिशा ही trend बन रही है
मैं ऐसा tool चाहता हूँ जिसमें मैं अपनी मातृभाषा में voice से command दूँ, AI पूरे project context को समझे, refactoring, static analysis, AI feedback तक सब करे, sketch से UI बनाए, handwriting से coding हो, और code changes से commit message भी बना दे — यानी सचमुच programmer जैसा tool
मैं सहमत हूँ कि junior-level tasks में LLM काफ़ी उपयोगी हैं
हाल में मुझे पुराना दावा — कि 'typing speed बहुत महत्वपूर्ण नहीं है' — फिर से सोचने पर मजबूर होना पड़ा
पहले code टाइप करने की speed से ज़्यादा overall design और structuring महत्वपूर्ण होते थे, इसलिए input time ख़ुद इतना बड़ा factor नहीं था
लेकिन Claude इस्तेमाल करके मुझे लगा कि जो code changes पहले झंझट की वजह से टाल देता था, वे अब बिना ज़्यादा concentration के आसानी से हो जाते हैं
पहले enum में एक value जोड़ो तो हर matching जगह manually ध्यान देकर बदलना पड़ता था, लेकिन LLM वह हिस्सा अपने-आप बदल सकता है
compiler errors एक-एक करके ठीक करना भी झंझट था; अब Claude से बार-बार fix करवाया जा सकता है
कई agents एक साथ code के अलग-अलग हिस्सों पर काम कर दें, तो उस समय मैं बड़े structure पर सोच सकता हूँ या HN पर comment भी लिख सकता हूँ
यानी compile errors ठीक करने में समय न जाने से ज़्यादा changes तेज़ी से apply हो पाते हैं, और जो काम पहले junior पूरे दिन करता, वह एक बार में निपट सकता है
इसलिए मैं overall architecture पर ज़्यादा ध्यान दे पाता हूँ, और लंबे समय से टल रहे coding chores भी निपटा लेता हूँ, जो motivation के लिए बहुत मददगार है
मैं इस बात से सहमत हूँ कि "typing तेज़ होने पर भी goal तक जल्दी न पहुँचने का कारण यह है कि bottleneck design होता है"
LLM अच्छे design बनाने में अक्सर कमज़ोर हैं, और छोटे-छोटे functions तक भी almost हमेशा refactoring की ज़रूरत पड़ती है
implementation stage में productivity gains ज़रूर हैं, लेकिन वे ज़्यादातर उन ideas को concretize करने तक सीमित हैं जो पहले से मेरे दिमाग़ या docs में थे
brainstorming के लिए वे ठीक हैं
अगर आप code और tests सब दे दें और पूछें "कोई edge case छूटा है क्या", तो 10 में से 1-2 बार उपयोगी सुझाव मिल जाते हैं
short-term working fix और long-term structural excellence दो बहुत अलग चीज़ें हैं; LLM दूसरी चीज़ तक पहुँच पाएँगे या नहीं, यह अभी अनिश्चित है
"codebase में करने के लिए ढेर सारा काम है" — इस पर मुझे सच में लगता है कि bottleneck code changes नहीं, review है
अगर "जो काम junior को पूरा दिन लगे, वह LLM जल्दी कर देता है" का नतीजा यह हुआ कि juniors के सीखने के मौके ही कम हो जाएँ और hiring घटे, तो फिर उन्हें आगे बढ़ाएगा कौन — यह चिंता जायज़ है
"test fail होने पर code ठीक करना है या test, यह तय नहीं कर पाता" जैसी स्थिति में
"Red-Green-Refactor" भाषा का इस्तेमाल मदद करता है
अब मैं LLM को साफ़ बताता हूँ: यह RED phase है (test fail होना सामान्य है), यह GREEN phase है (minimum code से success बनाओ), यह REFACTOR phase है (test तोड़े बिना code improve करो)
इससे LLM सिर्फ़ "टूटा code ठीक करो" नहीं सोचता, बल्कि TDD के mind model को भी समझ पाता है
मुझे साफ़ लगता है कि "मेरा अपना Facebook बना दो" स्तर के पूरे नए project में LLM अभी सक्षम नहीं हैं
लेकिन "यह modal जोड़ दो, existing code देखकर style match कर दो" जैसे ज़्यादा specific tasks में मुझे कई बार मनचाहा परिणाम मिला है
समस्या को छोटे हिस्सों में बाँटकर एक-एक करके दें, तो नतीजे कहीं बेहतर मिलते हैं
existing code को copy करके मनमुताबिक़ बदलना तो मैं वैसे भी ख़ुद कर सकता हूँ
मेरा system clipboard, LLM के उलट, हमेशा deterministic तरीके से काम करता है और LLM की तरह अनंत अप्रत्याशित नई समस्याएँ पैदा नहीं करता
v0 जैसे नए tools ऐसे अनुरोधों का कैसे जवाब देंगे, यह देखना दिलचस्प होगा
लेख की शुरुआत में दिया गया 4-step process Deutsch की "The Beginning of Infinity" से बहुत मिलता-जुलता लगा
हमारे theories 'guess' से शुरू होते हैं, और knowledge 'guess और criticism के चक्र' से बनती है
code लिखना एक तरह का 'guess' है, और tests बनाना उस guess की 'criticism'
दोनों ही हमारे दिमाग़ में मौजूद explanation — एक तरह के Platonist ideal — के और क़रीब जाने की कोशिश हैं