AI Blindspots – AI कोडिंग के दौरान मिले LLM के blindspots

AI कोडिंग के दौरान मिले LLM के blindspots. Claude Sonnet के आधार पर

1. Stop Digging → समस्या आने पर दिशा बदलना मुश्किल
2. Use Static Types → static type सेटअप की ज़रूरत
3. Black Box Testing → implementation details पर अत्यधिक निर्भरता
4. Use MCP Servers → MCP server सेटअप और सुरक्षा समस्याएँ
5. Preparatory Refactoring → गैर-ज़रूरी refactoring हो सकता है
6. Mise en Place → environment setup विफल होने पर समस्याएँ
7. Stateless Tools → state-dependent tools में समस्याएँ
8. Respect the Spec → spec का उल्लंघन होने की संभावना अधिक
9. Bulldozer Method → दोहराए जाने वाले काम बहुत ज़्यादा करना
10. Memento → context समझने की कमी से समस्या
11. Requirements, not Solutions → requirements को स्पष्ट करना ज़रूरी
12. Scientific Debugging → अनुमान-आधारित fixes से समस्या
13. Use Automatic Code Formatting → code style में असंगति
14. The Tail Wagging the Dog → महत्वपूर्ण काम छोड़कर छोटी समस्याओं पर अटक जाना
15. Keep Files Small → बड़े files में बदलाव करते समय समस्या
16. Know Your Limits → model अपनी सीमाएँ ठीक से नहीं पहचानता
17. Read the Docs → सीखी हुई जानकारी के बाहर की info में errors
18. Culture Eats Strategy → code style में consistency की कमी
19. Walking Skeleton → पहले न्यूनतम working system को चलाना ज़रूरी
20. Rule of Three → code duplication होने पर refactoring की ज़रूरत

---

समस्या में फँसे न रहना (Stop Digging)

• मौजूदा LLMs में काम के दौरान समस्या आने पर खुद रुककर दिशा बदलने की क्षमता कम होती है
  • उदाहरण: feature X implement करते समय अगर पहले feature Y बनाना ज़रूरी हो, तब भी LLM मूल काम (X) पूरा करने की कोशिश करता रहता है
  • यह इस मायने में फ़ायदा है कि LLM निर्देशों का ईमानदारी से पालन करता है, लेकिन समस्या पहचानकर दिशा बदलना कठिन होता है
• समस्या से बचने की रणनीतियाँ
  • planning चरण में reasoning model का उपयोग करके काम की priority और prerequisite tasks तय करें
  • Sonnet जैसे agent LLM files पढ़कर work plan बनाते हैं → user के स्पष्ट निर्देश के बिना भी ज़रूरी काम पहचान सकते हैं
• आदर्श रूप से LLM को समस्या पहचानकर user से confirmation माँग सकना चाहिए
  • लेकिन इससे context consume होता है, इसलिए यह काम किसी अलग monitoring LLM से कराना बेहतर हो सकता है

• Example

  • Monte Carlo simulation की random sampling method बदलने के बाद Claude Code से tests अपडेट करने को कहा गया
    • नया implementation non-deterministic था, इसलिए test results pass/fail random तरीके से हो रहे थे
    • Claude Code ने इसे नहीं पहचाना और test conditions को ढीला करके समस्या सुलझाने की कोशिश की
    • इसकी जगह उसे simulation को deterministic बनाने वाला refactoring सुझाना चाहिए था

static types का उपयोग (Use Static Types)

• dynamic type बनाम static type system की बहस असल में prototyping की आसानी और long-term maintenance के बीच संतुलन का सवाल है
  • LLM boilerplate code और refactoring संभाल सकता है, इसलिए prototyping के लिए language चुनने का दबाव कम हो जाता है
  • इसलिए ऐसी language चुनी जा सकती है जो prototyping से ज़्यादा long-term maintenance के लिए बेहतर हो
• type errors ठीक करने की रणनीति
  • agent settings में ऐसा configure करें कि बदलाव के बाद पैदा हुए type errors को LLM पहचान सके
  • इससे वे दूसरे files भी आसानी से मिल जाते हैं जहाँ fixes की ज़रूरत है
• ध्यान देने योग्य बातें
  • Python और JavaScript में gradual type system होता है → type checker को सख़्ती से configure करना ज़रूरी है
  • सिद्धांततः Rust LLM के लिए उपयुक्त है, लेकिन अभी यह Python/JavaScript जितना अच्छा generate नहीं होता

ब्लैक बॉक्स testing (Black Box Testing)

• ब्लैक बॉक्स testing वह तरीका है जिसमें component की अंदरूनी संरचना जाने बिना उसकी functionality test की जाती है
  • implementation files context में शामिल होने की वजह से LLM के लिए ब्लैक बॉक्स testing के सिद्धांतों का पालन करना मुश्किल है
  • Sonnet 3.7 (Cursor के उपयोग में) code consistency बनाए रखने की प्रवृत्ति दिखाता है → test files में duplication हटाने की कोशिश करता है
    • लेकिन ब्लैक बॉक्स testing में इस duplication को बनाए रखना bug detection के लिए फ़ायदेमंद हो सकता है
• आदर्श समाधान
  • LLM को loaded files से implementation details को mask या summarize करने में सक्षम होना चाहिए
  • architect को information-hiding boundaries साफ़ तौर पर परिभाषित करनी चाहिए

• Example

  • Sonnet 3.7 ने failing test ठीक करते समय hardcoded constant को मूल algorithm के आधार पर calculate करने के लिए बदल दिया
    • जबकि मूल constant को वैसा ही रहना चाहिए था

MCP servers का उपयोग (Use MCP Servers)

• Model Context Protocol(MCP) server ऐसा standard interface देता है जिससे LLM environment के साथ interact कर सके
  • Cursor agent mode और Claude Code में MCP servers का व्यापक उपयोग होता है
  • अलग RAG system के बिना भी LLM MCP calls के ज़रिए ज़रूरी files खोज और edit कर सकता है
  • model test या build चलाने के बाद तुरंत समस्या भी ठीक कर सकता है
• custom MCP server लिखते समय ध्यान रखने योग्य बातें
  • Cursor में YOLO mode चालू करके Cursor rules में shell commands जोड़े जा सकते हैं
    • यह ख़तरनाक है → मनमाने shell commands environment को नुकसान पहुँचा सकते हैं
  • विकल्प: ऐसा custom MCP server लिखें जो केवल कुछ खास commands को ही expose करे → सुरक्षा बेहतर होती है
    • लेकिन मार्च 2025 तक Cursor में project-specific MCP server settings अभी कमज़ोर हैं

• Example

  • Sonnet 3.7 ने TypeScript project में type checking और error fixing के लिए MCP का उपयोग किया
    • terminal output को manually copy-paste करने की ज़रूरत बिना यह अपने-आप हो गया
    • लेकिन कभी-कभी यह ग़लत command (npm run typecheck) infer कर लेता है

तैयारी वाला refactoring (Preparatory Refactoring)

• preparatory refactoring वह रणनीति है जिसमें असली बदलाव से पहले refactoring करके काम को आसान बनाया जाता है
  • refactoring अर्थ-संरक्षण वाला काम होता है, इसलिए इसे वास्तविक बदलाव की तुलना में evaluate करना आसान है
  • पहले refactoring, फिर बदलाव → review और error fixing आसान हो जाते हैं
• मौजूदा LLM की समस्याएँ
  • पहले refactoring किए बिना सब कुछ एक ही बार में करने की प्रवृत्ति
  • गैर-ज़रूरी cleanup भी कर देता है → excessive refactoring हो सकता है
  • Cursor Sonnet 3.7 में निर्देश पालन की सटीकता कम है → असंबंधित refactoring हो सकता है
• सुधार के तरीके
  • साफ़ निर्देश दें कि बदलाव से पहले refactoring चरण में ही code edit किया जाए
  • LLM जिस code range को edit कर सकता है उसे स्पष्ट रूप से परिभाषित करें → गैर-ज़रूरी बदलाव रुकेंगे

• Example

  • LLM को import error ठीक करने को कहा गया → fix के बाद उसने lambda functions में type annotations जोड़ दिए
    • इनमें से कुछ annotations ग़लत जोड़े गए, जिससे agent loop बन गया

Mise en Place

• खाना पकाने में Mise en Place का मतलब है काम शुरू करने से पहले सभी सामग्री और tools को व्यवस्थित कर लेना
• LLM में Mise en Place का मतलब है काम शुरू होने से पहले ज़रूरी rules, MCP और development environment को पूरी तरह सेट कर लेना
  • Sonnet 3.7 टूटे हुए environment को ठीक करने में कमज़ोर है
  • StackOverflow से commands copy-paste करके समस्या सुलझाने की कोशिश कर सकता है → environment खराब होने का जोखिम
  • काम शुरू करने से पहले environment सही तरह सेट होना चाहिए ताकि Sonnet debugging loop में न फँसे

• Example

  • npm link समस्या के कारण VSCode दूसरे local project के import को पहचान नहीं पा रहा था
    • Cursor lint और tests ठीक करते समय इसी पर अटक गया, लेकिन npm unlink चलाने की ज़रूरत नहीं पहचान पाया

Stateless tools का उपयोग (Stateless Tools)

• टूल्स को state सेव किए बिना हर बार स्वतंत्र रूप से चलना चाहिए
  • shell वर्तमान working directory state पर निर्भर करता है → state सेव होने से भ्रम पैदा हो सकता है
  • Sonnet 3.7 वर्तमान working directory state को सटीक रूप से ट्रैक नहीं कर पाता
  • सभी commands को project root directory से चलाने योग्य बनाना ज़रूरी है
• सुधार के उपाय
  • state बदलने की ज़रूरत वाले tool commands का उपयोग कम से कम करें
  • अगर state अनिवार्य हो, तो consistency बनाए रखने के लिए वर्तमान state को लगातार model को देते रहें

• Example

  • अगर TypeScript project common, backend, frontend तीन modules से बना हो
    • root से चलने पर Cursor को सही directory में cd करना पड़ता है → directory confusion होता है
    • हर module को अलग workspace के रूप में खोलकर काम करने पर समस्या हल हो गई

स्पेक का पालन (Respect the Spec)

• system बदलते समय किन हिस्सों को बदला जा सकता है और किन्हें नहीं, यह साफ़ तौर पर अलग होना चाहिए
  • public API बदलने पर backward compatibility टूटने से बचाना ज़रूरी है
  • external systems के साथ integration करते समय वास्तव में मौजूद API के अनुसार चलना चाहिए → मनचाहे तरीके से बदला नहीं जा सकता
  • test fail होने पर tests हटाने की मनाही होनी चाहिए → कारण समझकर उसे ठीक करना चाहिए
• LLM की समस्याएँ
  • spec का उल्लंघन करने की संभावना अधिक होती है → tests हटाना, API बदलना आदि आसानी से कर देता है
  • spec का पालन सामान्य समझ की बात है, लेकिन इसे prompt में स्पष्ट लिखना पड़ सकता है
  • कुछ सीमाएँ केवल code review के दौरान ही पकड़ी जा सकती हैं

• Example

  • Sonnet ने test ठीक करने में विफल होने के बाद test contents को assert True से बदल दिया
  • public function pass key वाला dict लौटाता था → Sonnet ने उसे pass_ में बदलने की कोशिश की (reserved word समस्या)

बुलडोज़र तरीका (Bulldozer Method)

• बुलडोज़र तरीका एक ऐसी रणनीति है जिसमें सरल दोहराए जाने वाले काम से समस्या हल की जाती है और सीखने के असर से गति बढ़ती है
  • AI coding मूल रूप से repetitive work में मज़बूत है → पर्याप्त tokens हों तो बड़े पैमाने पर refactoring संभव है
  • जिन समस्याओं को इंसान "काम बहुत ज़्यादा है" कहकर छोड़ देता है, उन्हें भी LLM हल कर सकता है
  • लेकिन LLM एक ही काम बार-बार दोहरा सकता है, इसलिए यह देखना ज़रूरी है कि वह वास्तव में क्या कर रहा है

• Example

  • Haskell या Rust में core function बदलने पर व्यापक refactoring की ज़रूरत पड़ सकती है
    • LLM compile errors पढ़ना → fix करना → फिर से compile करना, इस प्रक्रिया को automate कर सकता है
  • hardcoded test values बदलते समय LLM tests दोबारा चलाकर अपने-आप fixes कर सकता है

मेमेंटो (Memento)

• LLM state याद नहीं रख पाता → हर task में उसे codebase को शुरुआत से फिर समझना पड़ता है
  • prompt, explicit/implicit context, और agent mode में model द्वारा लोड की गई files के आधार पर ही काम होता है
  • हर task में codebase को फिर से समझना पड़ता है → शुरुआती setup विफल होने पर ग़लत काम करने की संभावना बढ़ जाती है
• समस्या से बचाव की रणनीतियाँ
  • LLM को refer करने योग्य documents स्पष्ट रूप से दें
  • model के लिए ज़रूरी जानकारी आसानी से ढूँढने लायक व्यवस्था करें
  • project का पूरा संदर्भ देने के बाद ही बड़े बदलावों के लिए कहें

• Example

  • Sonnet 3.7 से मौजूदा project के end-to-end test plan बनाने को कहा गया
    • उसने project के पूरे उद्देश्य को testing समझ लिया → README को test-केंद्रित रूप में बदल दिया

आवश्यकताओं की स्पष्टता (Requirements, not Solutions)

• software engineering में आम गलती यह है कि requirements स्पष्ट किए बिना सीधे solution सुझा दिया जाता है
  • अगर problem space काफ़ी सीमित हो, तो केवल requirements स्पष्ट करने से ही solution अपने-आप तय हो सकता है
  • requirements अस्पष्ट हों तो solution को लेकर अनावश्यक बहस हो सकती है
• LLM की समस्याएँ
  • LLM requirements नहीं जानता → training patterns के आधार पर सबसे संभावित जवाब बनाता है
  • स्पष्ट requirements के बिना task देने पर अजीब या अप्रासंगिक परिणाम आ सकते हैं
  • prompt बदलकर ग़लत interpretation सुधारी जा सकती है → लेकिन अगर ग़लत interpretation context में रह जाए, तो उसे ठीक करना मुश्किल हो जाता है
• सुधार के उपाय
  • अगर किसी खास तरीके का solution चाहिए, तो उसे स्पष्ट रूप से निर्देशित करें
  • LLM निर्देशों का ठीक-ठीक पालन करता है, इसलिए ग़लत तरीके से निर्देश देने पर परिणाम भी ग़लत या inaccurate हो सकते हैं

• Example

  • Sonnet से visualization बनाने को कहने पर वह default रूप से SVG बनाता है
    • "interactive" स्पष्ट लिखने पर वह React आधारित application बनाता है → एक keyword से बड़ा अंतर आ जाता है

वैज्ञानिक डिबगिंग (Scientific Debugging)

• bug fix करने के तरीके broadly दो तरह के होते हैं
  • बेतरतीब बदलाव करके किस्मत पर छोड़ देना
  • system के काम करने के तरीके का तार्किक विश्लेषण करके actual state और expected state के mismatch का कारण ढूँढना
  • वैज्ञानिक debugging (तार्किक विश्लेषण) लंबे समय में बेहतर तरीका है
• LLM की समस्याएँ
  • LLM की reasoning क्षमता सीमित होती है, इसलिए वैज्ञानिक approach अपनाना कठिन होता है
  • पहले "सही जवाब का अंदाज़ा" लगाकर तुरंत fix करने की कोशिश करता है → विफल होने पर random fixes दोहराने लगता है (agent loop)
  • debugging के लिए Grok 3, DeepSeek-R1 जैसे reasoning models अधिक उपयुक्त हैं
• सुधार के उपाय
  • model को कारण का विश्लेषण करने का निर्देश दें, या उपयोगकर्ता स्वयं कारण बताए → fix success rate बढ़ती है
  • समस्या का सही कारण बता दिया जाए तो model बेहतर solution सुझा सकता है

• Example

  • Sonnet 3.7 में pip के बिना default uv environment में package install error हुआ
    • कारण समझने में विफल रहने के बाद उसने random कोशिशें दोहराईं → tokens की बर्बादी हुई और debugging विफल रही

ऑटोमैटिक कोड फ़ॉर्मैटिंग का उपयोग (Use Automatic Code Formatting)

• automatic code formatting tools (gofmt, rustfmt, black आदि) consistent code style बनाए रखने में उपयोगी हैं
  • LLM mechanical rules (जैसे blank line में spaces न होना, 78-character line length limit आदि) का पालन करने में कमज़ोर है
  • formatting टूल्स पर छोड़ देना चाहिए और LLM को complex tasks पर ध्यान देना चाहिए
• यही सिद्धांत lint fixes पर भी लागू होता है
  • auto-fixable lint का उपयोग सुझाया जाता है
  • LLM के resources को complex problem solving पर केंद्रित करना चाहिए

जब पूँछ कुत्ते को हिलाने लगे (The Tail Wagging the Dog)

• इसका मतलब है ऐसी स्थिति जहाँ मामूली समस्या ज़्यादा महत्वपूर्ण समस्या को नियंत्रित करने लगे
  • low-level समस्या सुलझाने में उलझकर पूरे code लिखने का मूल उद्देश्य भुलाया जा सकता है
  • LLM chat session में सारी जानकारी context में शामिल कर लेता है → importance तय करना मुश्किल हो जाता है
• सुधार के उपाय
  • शुरुआत में स्पष्ट prompt दें → LLM को महत्वपूर्ण काम पर केंद्रित किया जा सकता है
  • Claude Code sub-agents के ज़रिए specific tasks कराता है ताकि global context दूषित न हो

• Example

  • LLM से किसी खास काम के तरीके पर सोचने को कहने पर वह केवल सोचने के बजाय वास्तव में काम शुरू करने की कोशिश कर सकता है

फ़ाइलों का आकार छोटा रखें (Keep Files Small)

• code file size को लेकर बहस लंबे समय से चलती आई है
  • single responsibility principle (प्रति फ़ाइल एक class) लागू करना बनाम परिस्थिति के अनुसार बड़ी files स्वीकार करना
  • अगर files बहुत बड़ी हों, तो RAG system में file-level context loading के दौरान समस्या हो सकती है
  • Cursor जैसे IDE में patch apply विफल हो सकता है → सफल होने पर भी apply होने में काफ़ी समय लग सकता है
    • उदाहरण: Cursor 0.45.17 में 64KB file पर 55 edits लागू करने में काफ़ी समय लगा
  • Sonnet 3.7 को 128KB से बड़ी files संपादित करने में कठिनाई होती है (200K token context window सीमा)
• सुधार के उपाय
  • file size छोटा रखें → LLM अपने-आप import आदि संभाल सकता है

• Example

  • Sonnet 3.7 ने 471KB की Python file में एक छोटी test class को move करने की कोशिश की
    • बदलाव छोटा था, लेकिन Cursor patcher उस edit को लागू नहीं कर पाया

सीमाओं को पहचानें (Know Your Limits)

• जब tools की कमी हो या क्षमता की सीमा आ जाए, तो समस्या को पहचानना और मदद मांगना ज़रूरी है
  • Sonnet 3.7 अपनी सीमाओं को पहचानने में कमजोर है
  • स्पष्ट prompt देने पर यह सीमाओं को पहचान सकता है → किसी खास विषय में hallucination होने पर warning सेट करना ज़रूरी है
• समस्याएँ
  • Sonnet 3.7 गलत तरीके से मान लेता है कि वह shell command चला सकता है
    • अगर shell command उपलब्ध न हो, तो यह रैंडम shell script बनाने की कोशिश कर सकता है → environment को नुकसान पहुंचने का जोखिम
    • यह "X चलाऊँगा" कहने के बाद पूरी तरह अलग Y के लिए call बना सकता है
• सुधार के तरीके
  • prompt बदलें या केवल इच्छित काम करने वाला dedicated tool दें
    • किसी specific tool को देने पर बेकार के shell call रोके जा सकते हैं

• Example

  • Sonnet 3.7 ने file execute permission देने के दौरान गलत shell script बनाने की कोशिश की
    • command error आने के बाद गलत fix की कोशिश बार-बार होती रही

दस्तावेज़ पढ़ें (Read the Docs)

• किसी नए framework या library को सीखते समय tutorial code बदलकर छोटे काम किए जा सकते हैं
  • लेकिन आखिर में पूरे काम करने के तरीके को समझने के लिए दस्तावेज़ शुरू से अंत तक पढ़ना ज़रूरी है
• LLM के फायदे
  • लोकप्रिय framework अक्सर pretraining में शामिल होते हैं, इसलिए इनके ज़्यादातर इस्तेमाल इसे याद रहते हैं
  • लेकिन niche tools या knowledge cutoff के बाद आए tools में hallucination हो सकती है
  • Sonnet web search को support नहीं करता → दस्तावेज़ manually देने पड़ते हैं
    • Cursor में URL देने पर वह अपने-आप context में शामिल हो सकता है

• Example

  • जब LLM से Python function calling के लिए YAML लिखने को कहा गया, तो उसने गलत config बनाया
    • दस्तावेज़ देने के बाद उसने सही fix किया और output format भी बेहतर हुआ

संस्कृति रणनीति पर भारी पड़ती है (Culture Eats Strategy)

• टीम की संस्कृति इस बात पर निर्णायक असर डालती है कि strategy कितनी अच्छी तरह लागू होगी
  • LLM पहले से सीखे गए style और context window के आधार पर code बनाता है
  • जो library या style context में बार-बार दिखते हैं, उन्हें यह प्राथमिकता देता है
    • अगर स्पष्ट निर्देश न हों, तो यह default style लागू करता है
• LLM style बदलने की रणनीतियाँ
  • Cursor rules बदलना (prompt बदलना)
  • मौजूदा code style को मनचाहे रूप में refactor करना → इससे अगले token prediction पर असर पड़ता है
  • codebase का आकार prompt से ज़्यादा असर डालता है → इसलिए codebase बदलना मूल समाधान है

• Example

  • Sonnet 3.7 Python में synchronous code को प्राथमिकता देता है
    • asynchronous code generation के लिए मौजूदा ज़्यादातर code को async में port करने के बाद सफलता मिली

वॉकिंग स्केलेटन (Walking Skeleton)

• वॉकिंग स्केलेटन न्यूनतम end-to-end system लागू करने की एक strategy है
  • भले यह परफेक्ट न हो, पहले पूरे system को चलने लायक बनाया जाता है और फिर details सुधारी जाती हैं
  • LLM coding के दौर में पूरे system को तेजी से बनाना और आसान हो गया है
  • system काम करने लगे तो अगला कदम साफ़ हो जाता है → इसलिए जल्दी working state तक पहुँचना महत्वपूर्ण है
  • LLM अपने लिखे code को खुद इस्तेमाल नहीं कर सकता, इसलिए working state हासिल करना महत्वपूर्ण है

तीसरा नियम (Rule of Three)

• एक ही code की नकल दो बार तक स्वीकार्य है, लेकिन तीसरी बार नकल होने पर refactoring ज़रूरी है
  • यह DRY(Don't Repeat Yourself) सिद्धांत का बेहतर संस्करण है
  • इससे duplication हटाने का सही समय स्पष्ट होता है → तीसरी नकल पर refactoring करें
• LLM की समस्याएँ
  • LLM में duplicate code बनाने की प्रवृत्ति होती है
  • अगर prompt के बिना बदलाव करने को कहें, तो यह अक्सर पूरे code को फिर से कॉपी करके उसी में बदलाव कर देता है
  • duplication हटाना तभी होता है जब model खुद यह तय करे → इसलिए स्पष्ट निर्देश ज़रूरी हैं
• सुधार के तरीके
  • साफ़ तौर पर duplication हटाने का निर्देश देना ज़रूरी है
  • अगर मौजूदा code में बहुत duplication है, तो model उसी pattern को दोहराता रह सकता है

• Example

  • LLM से test code लिखवाने पर एक ही logic कई tests में दोहराया गया
    • helper method बनाने का स्पष्ट निर्देश देने के बाद समस्या हल हुई
    • agent mode

[GN⁺]

Hacker News राय

• LLM इंसानों से अलग तरीके से गलतियाँ करते हैं, और इन्हें पकड़ना मुश्किल होता है

  • इंसानी गलतियों को पकड़ने का लंबा अनुभव है, लेकिन LLM के सोचने के तरीके को समझना कठिन है
  • LLM की त्रुटियों को पकड़ने वाला सिस्टम डिज़ाइन करना मुश्किल है

• अगर LLM को requirements नहीं पता हों, तो वह training data से सबसे संभावित जवाब भर देता है

  • AI तभी programmer की जगह ले सकता है जब ग्राहक जो चाहता है उसे बिल्कुल सटीक तरीके से समझाया जाए

• software engineering में requirements को स्पष्ट करना महत्वपूर्ण है

  • requirements स्पष्ट हों तो solution स्वाभाविक रूप से तय हो जाता है
  • नया framework या library सीखते समय documentation को ध्यान से पढ़ना अच्छा है
  • bug ठीक करते समय सिस्टम की assumptions की व्यवस्थित रूप से समीक्षा करना ज़रूरी है
  • code duplication तीसरी बार होने पर refactoring करना बेहतर है

• LLM की coding क्षमता "बहुत स्मार्ट junior programmer" के स्तर की है

  • इसमें बड़ी तस्वीर देखने की क्षमता की कमी है, और यह सिर्फ वही करता है जो कहा जाता है
  • उम्मीद है कि model लगातार बेहतर होंगे

• LLM बहुत ज़्यादा जवाब देने की कोशिश करते हैं

  • पर्याप्त data न दिया जाए तो यह गलत जवाब बना देते हैं
  • अच्छा होगा अगर LLM कह सके कि "और जानकारी चाहिए"

• blog पर posts बढ़ने के साथ उन्हें व्यवस्थित करने की ज़रूरत है

  • अभी तक कोई अच्छा organization system नहीं मिला है

• LLM के साथ coding करते समय कुछ उपयोगी सलाह

  • static types के उपयोग पर मतभेद हैं
  • Clojure, Typescript की तुलना में बेहतर परिणाम देता है
  • LLM function-केंद्रित approach के लिए अधिक उपयुक्त हैं

• LLM calculation और arithmetic में कमजोर हैं

  • code generate करते समय सही जगह से numbers लाना महत्वपूर्ण है
  • LLM द्वारा generate किए गए code को debug करने में समय लगता है

• human coders के साथ मिलाकर सोचने वाली बातें

  • product managers को भी इस पर ध्यान देना चाहिए

• एक मामला जिसमें तीन LLM ने ऐसा "bug" खोज लिया जो था ही नहीं

  • code optimized नहीं था, लेकिन bug नहीं था
  • code blocks के बीच दूरी कम थी