AI का उपयोग करके प्रोग्रामिंग क्षमता बढ़ाने के तरीके

• AI coding tools का इस्तेमाल करके उन conversion tasks को, जिनमें इंसान को 1~2 घंटे लगते थे, 15~20 मिनट के review स्तर तक घटाना चाहते हैं
• लेकिन, अभी AI द्वारा बनाया गया code quality, सीधे खुद लिखे गए code के 90% तक भी नहीं पहुँचता, इसलिए लगता है कि यह व्यावहारिक रूप से ज़्यादा मददगार नहीं है
• इसलिए यह जानना चाहते हैं कि AI का उपयोग कैसे किया जाए ताकि productivity और code quality दोनों को एक साथ बढ़ाया जा सके

AI से programming efficiency और quality बढ़ाने के लिए व्यावहारिक टिप्स का संग्रह

1. AI को केवल दोहराए जा सकने वाले कामों पर केंद्रित करें

• AI एक जैसे प्रकार के कामों को कई बार दोहराने में सबसे अधिक प्रभावी है
• एक बार इंसान स्वयं सर्वोत्तम quality के साथ implementation करे, और उसे reference example के रूप में इस्तेमाल करे
• उसके बाद उसी pattern वाले काम AI को देकर bulk processing कराएँ
• जिन कामों में सोच और निर्णय की ज़रूरत होती है, वहाँ अपेक्षित efficiency तेज़ी से घट जाती है

2. coding से पहले योजना बनाना अनिवार्य करें

• तुरंत code generate न करें; पहले solution plan लिखें
• planning चरण में सभी अस्पष्ट हिस्सों और प्रश्नों को सामने लाएँ
• अगर योजना संतोषजनक न हो, तो execution चरण में आगे न बढ़ें
• परिणाम की quality, prompt से अधिक plan document की स्पष्टता पर निर्भर करती है

3. काम की इकाई को बहुत छोटे हिस्सों में बाँटें

• एक file, एक component, या कुछ functions की इकाई में request करें
• “पूरी refactoring”, “idiomatic तरीके से सुधारो” जैसी requests के असफल होने की संभावना अधिक होती है
• structure design इंसान करे, और केवल दोहराव वाले implementation AI को सौंपें

4. context को जमा न होने दें, उसे बार-बार reset करें

• बातचीत जितनी लंबी होती जाती है, rules का पालन और quality उतनी तेज़ी से गिरती है
• एक session में केवल एक ही काम करें
• दिशा बदल जाए तो नए session में फिर से शुरू करें
• लंबे कामों में state को document (plan.md आदि) के रूप में सुरक्षित रखकर फिर से inject करें

5. rules document को छोटा और machine-friendly रखें

• CLAUDE.md / AGENTS.md को 500~1000 tokens के भीतर रखें
• घोषणात्मक निर्देशों की बजाय ठोस और verify किए जा सकने वाले rules पर ज़ोर दें
• केवल वही बातें न्यूनतम रूप में लिखें जो बार-बार गलत होती हैं
• बाकी सब code और automated checks से enforce करें

6. tests, linter और build को feedback loop की तरह इस्तेमाल करें

• “अच्छा बनाओ” कहने के बजाय pass conditions स्पष्ट रूप से बताइए
• test pass, build success, और linter errors 0 को लक्ष्य बनाएँ
• feedback loop होने पर AI खुद convergence की ओर जाता है
• मौजूदा behavior को verify करने वाले tests, refactoring की कठिनाई को काफी कम कर देते हैं

7. execution के दौरान patching न करें; plan सुधारकर फिर से चलाएँ

• यदि परिणाम पसंद न आए, तो बार-बार code modification request न दोहराएँ
• plan document को संशोधित करने के बाद नए session में फिर से चलाएँ
• execution चरण में दिशा मोड़ने से quality जल्दी टूटने लगती है

8. उदाहरण-आधारित तरीके से style सिखाएँ

• “अच्छा code” जैसी अमूर्त हिदायतें लगभग बेअसर होती हैं
• Before / After examples साथ में दें
• अच्छे और खराब examples को स्पष्ट रूप से अलग करके दिखाएँ
• examples को केंद्र में रखकर rules का विस्तार करें

9. समझ से समझौता न करें और ज़िम्मेदारी की सीमा स्पष्ट रखें

• AI द्वारा generated code को इंसान को ज़रूर समझना और review करना चाहिए
• prototype और low-risk code के अलावा बिना review के उपयोग की अनुमति नहीं होनी चाहिए
• security, operations, और long-term maintenance code में समझ quality की पूर्वशर्त है

10. पहले जाँचें कि यह काम AI के लिए उपयुक्त भी है या नहीं

• जिन कामों में कोई एक सही उत्तर नहीं होता और सौंदर्य या structural judgment अधिक होता है, वे AI के लिए प्रतिकूल हैं
• UI refactoring, जहाँ visual result को automatically verify करना कठिन हो, विशेष रूप से मुश्किल है
• ज़रूरत पड़ने पर:
  • चरण 1: behavior को बनाए रखने के उद्देश्य से mechanical conversion
  • चरण 2: quality refactoring इंसान द्वारा किया जाए

11. अपेक्षा “10% सुधार” से शुरू करें

• शुरुआत से ही 10x की उम्मीद न करें
• छोटे-छोटे सुधारों को जमा करने की रणनीति लंबे समय में अधिक प्रभावी होती है
• design और quality standards से समझौता न करना ही मुख्य बात है

[GN⁺]

Hacker News की राय

• मैं Claude Code टीम का Boris हूँ। कुछ टिप्स साझा कर रहा हूँ

  1. Claude जिन हिस्सों में अक्सर गलती करता है या समझ नहीं पाता, उन्हें CLAUDE.md में लिखकर रखना अच्छा है। Claude इस फ़ाइल को अपने-आप पढ़ता है
  2. Plan mode (Shift+Tab दो बार) का सक्रिय रूप से उपयोग करके पहले योजना बनवाएँ और फिर उसे चलाएँ, तो मुश्किल कामों में 2~3 गुना बेहतर नतीजे मिल सकते हैं
  3. काम को verify करने का तरीका देना अच्छा रहता है। उदाहरण के लिए Svelte में Puppeteer MCP server का उपयोग करके ब्राउज़र में नतीजा चेक कराया जा सकता है
  4. मॉडल के लिए Opus 4.5 की सिफारिश करता हूँ। यह Sonnet 4.5 से साफ़ तौर पर एक स्तर बेहतर लगता है
     उम्मीद है इससे मदद मिलेगी
  • मुझे भी Plan mode की वजह से productivity में बड़ा सुधार मिला। लेकिन हाल के version में ऐसा bug आ गया है कि Plan mode session की पहली योजना को ही बार-बार reference करता रहता है, जिससे workflow बिगड़ गया। सोच रहा हूँ कि कहीं मैं इसे असामान्य तरीके से तो इस्तेमाल नहीं कर रहा
  • काम के दौरान Claude को सुधारने के बाद self-reflection prompt चलाना अच्छा रहता है। यह प्रक्रिया मैन्युअली व्यवस्थित की गई बातों को CLAUDE.md में अपने-आप लागू कर देती है
  • ऊपर की सलाहों से सहमत हूँ। खासकर (3) वाला feedback loop बहुत महत्वपूर्ण है। मॉडल को ख़ुद बदलाव करने और नतीजा जाँचने देना चाहिए। उससे logs लिखवाएँ, या pseudocode plan बनवाएँ, तो जटिल समस्याएँ भी जल्दी सुलझ जाती हैं
  • Opus 4.5 सच में game changer है। पुराने React project को refactor करते समय इससे बहुत मदद मिली। अगर prompt बारीकी से लिखा जाए और CLAUDE.md ठीक से सेट किया जाए, तो असर काफ़ी बड़ा होता है
  • CLAUDE.md लगभग 4~5 बार तक ही ठीक से काम करता है, उसके बाद निर्देश भूल जाता है। उदाहरण के लिए, अगर कहो कि मुझे “Mr. bcherny” कहकर बुलाओ, तो वह जल्द ही भूल जाता है
  • Google Jules से तुलना करें तो Claude Code काफ़ी ज़्यादा professional developer जैसा लगा। लेकिन Claude Code Web में project feature नहीं है, इसलिए मुझे .clinerules फ़ाइल इस्तेमाल करने को कहा गया। CLAUDE.md से इसका अंतर जानना चाहता हूँ
  • CLAUDE.md में एक उपयोगी feature @import है। फ़ाइल नाम के आगे @ लगाने पर उसे ज़बरदस्ती context में शामिल किया जा सकता है। लेकिन इसे बहुत ज़्यादा इस्तेमाल करना inefficient है

• voice input का उपयोग करने पर मॉडल इरादे को ज़्यादा सटीक समझता है। मैं लगभग 500 शब्द का prompt बोलकर देता हूँ। typing की तुलना में बोलते समय सोच ज़्यादा स्वाभाविक रूप से आगे बढ़ती है।
  अगर कहो, “योजना बनाओ और सवाल हों तो पूछो,” तो Claude सच में सवाल पूछता है। उसे पहले के code style की नकल करने को कहना भी असरदार है

  • मैंने भी आवाज़ के ज़रिए laboratory.love लगभग पूरा बना लिया। shortcut key से “कोड लिखने से पहले समस्या और requirements का विश्लेषण करो और जो अस्पष्ट हो वह पूछो” जैसी पंक्ति अक्सर इस्तेमाल करता हूँ
  • तेज़ बोलना यह नहीं दिखाता कि कोई बिना सोचे बोल रहा है। बल्कि कम सोचकर बोलना असली समस्या हो सकती है
  • जब कोई सुन रहा हो तब AI से बात करना थोड़ा अजीब लगता है, लेकिन लंबे वाक्य मैं भी आवाज़ से input करता हूँ
  • जानना चाहूँगा कि आप कौन-सी speech recognition service इस्तेमाल करते हैं

• prompt में loop condition शामिल करनी चाहिए। उदाहरण: “yarn test pass होने तक दोहराते रहो”।
  आखिरकार LLM एक agent है जो tools को बार-बार चलाता है, इसलिए उसे उसी तरह संभालना चाहिए
  संदर्भ: Prompting the Agent Loop

• मैं अपने बनाए हुए nori-profiles settings की सिफारिश करता हूँ।
  4 महीने के प्रयोग के बाद Claude Code की performance में स्पष्ट सुधार दिखा।
  संबंधित लेख: Averaging 10 PRs a Day with Claude

  • Claude Code की skills से तुलना करें तो अंतर क्या है, यह जानना चाहूँगा

• कंपनी में हम Golang के बड़े codebase के साथ काम करते हैं। Cursor, Claude Code, Gemini CLI जैसे कई tools आज़माए, लेकिन ज़्यादातर कोड की मात्रा से दब गए।
  लेकिन aider को नियंत्रित करना काफ़ी आसान था और उसकी accuracy भी ज़्यादा थी। फ़ाइलें जोड़ना मैन्युअली करना पड़ता है, लेकिन सटीकता लगभग 100% रहती है।
  नए Claude Sonnet या Gemini 2.5 Pro के साथ इस्तेमाल करने पर यह सबसे ज़्यादा सटीक लगता है

  • aider का फ़ायदा यह है कि यह पूरी तरह agent-style नहीं है। context को मैन्युअली मैनेज करने से ग़लत फ़ाइलों में बदलाव नहीं होता। token बचत और speed के लिहाज़ से भी यह बेहतर है

• Cursor में काम करते समय पहले एक route को refactor करवाकर rules file बनवाई जाती है। उसके बाद बाकी routes में सिर्फ़ “refactor” कहना काफ़ी होता है

  • लंबे prompts से मत डरिए। यही असल में context engineering है। conversation history ख़ुद context को समृद्ध बना देती है।
    हमेशा बचे हुए context capacity का ध्यान रखें, और ज़रूरत पड़े तो जल्दी context clear कर देना बेहतर है

• agent को टीम के सदस्य की तरह देखने का नज़रिया महत्वपूर्ण है। एक-दूसरे की ताकत और कमज़ोरी देखकर सहयोग का तरीका समायोजित करना चाहिए।
  मैं agent की क्षमता को उन्हीं समस्याओं या experimental code पर केंद्रित करता हूँ जिन्हें verify किया जा सके।
  Svelte के बारे में ज़्यादा नहीं जानता, लेकिन TDD style के disposable tests से rewrite करवाना अच्छा तरीका हो सकता है।
  कभी-कभी पुराने ग़लत context को छोड़कर नए workspace से फिर शुरू करना सबसे अच्छा होता है

  • उस “cognitive style और teamwork” वाले टेक्स्ट का सार साझा करें तो अच्छा होगा

• मैं LLM को searcher की तरह देखता हूँ। अगर सवाल छोटे और ठोस हों तो खोज आसान होती है, और training data से जितना दूर जाते हैं, गलती की संभावना उतनी बढ़ती है।

  1. project को Zed में खोलो
  2. Gemini CLI, Qwen code, Claude में से किसी एक को जोड़ो
  3. फ़ाइल बदलने को कहो और test करो
  4. न चले तो Grok या Gemini 3 Chat में कोशिश करो
  5. फिर भी न हो तो मैन्युअली हल करो
     नया project one-shot prompt से भी काफ़ी हद तक हो सकता है
  • लेकिन बहुत छोटे prompts underspecification की समस्या पैदा करते हैं। इससे बस compute cost कम होती है, quality के लिहाज़ से यह नुक़सानदेह है

• मेरा पसंदीदा Claude Code toolset superpowers है

  1. पहले brainstorming session में feature समझाता हूँ
  2. Claude design document और implementation plan लिखकर disk पर save करता है
  3. नए Claude window में Execute Plan command से step-by-step execution और commit करता है
  4. हर तीन चरण पर self-review करवाकर code quality बेहतर बनाता है
     मैं इसे दो हफ़्तों से इस्तेमाल कर रहा हूँ और लगभग कभी असफलता नहीं मिली

• AI programming के लिए मेरे सिद्धांत सरल हैं

  1. one-shot में पूरा करना असफल होता है
  2. काम को verify किए जा सकने वाले units में बाँटो
  3. पूरी योजना को Markdown फ़ाइल में व्यवस्थित करो
  4. हर चरण को नए session में चलाओ, review करो, फिर commit करो
     मुख्य बात है “Less is more”। context window जितनी नई हो उतना अच्छा, और लगभग 500~750 शब्द आदर्श हैं। हर चरण verify किया जा सकना चाहिए

• Java से जुड़े कामों में Claude लगातार दिशा बदलता रहता है या विरोधाभासी सुझाव देता है। मुझे ChatGPT इससे काफ़ी बेहतर लगा

  • prompt में और ठोस निर्देश देने से शायद सुधार हो सकता है
  • क्या आपने Claude Code version भी आज़माया है

• अगर आपको “Idiomatic code” चाहिए, तो पहले यह बहुत विस्तार से तय करना होगा कि आपके हिसाब से वह style क्या है। अच्छे/बुरे उदाहरणों को छोटे हिस्सों में बाँटें, फिर उन्हें Opus 4.5 के Plan mode में डालकर योजना बनवाएँ और उसके अनुसार चलाएँ। अगर एक बार में पूरी तरह सही न हो, तो plan document बदलकर फिर कोशिश करें। जूनियर डेवलपर की तरह हर छोटी बात समझाने की कोशिश करना उल्टा inefficient है

  • किसी और ने अनुभव साझा किया कि “आजकल के models में हर बार नया session शुरू करना ज़रूरी नहीं,” और inline refactoring से भी काफ़ी स्थिर नतीजे मिलते हैं