AI के साथ उच्च-गुणवत्ता वाला कोड प्रभावी ढंग से कैसे लिखें

• AI के साथ सहयोग करने वाले development environment में quality बनाए रखने के लिए इंसानों को project की दिशा और decision-making को स्पष्ट रूप से परिभाषित करना चाहिए
• सटीक documentation के ज़रिए AI और अन्य developers, दोनों को requirements और constraints स्पष्ट रूप से समझने चाहिए
• debug system और code review framework बनाकर AI द्वारा generate किए गए code की reliability और verification process को मजबूत किया जाता है
• security risk functions को चिह्नित करना, tests को अलग रखना, और सख्त linting rules के ज़रिए code की stability और consistency सुनिश्चित की जाती है
• काम को छोटे units में बाँटना और complexity को न्यूनतम रखना AI code generation पर नियंत्रण बनाए रखने और efficiency को अधिकतम करने में मदद करता है

---

1. स्पष्ट vision स्थापित करना

• इंसान दुनिया, team और user behavior को समझते हैं, लेकिन AI के पास अनुभव नहीं होता, इसलिए उसे explicit guidance चाहिए
  • project में undocumented decisions अंततः AI को लेने पड़ते हैं
• architecture, interfaces, data structures, algorithms पर पहले से चर्चा होनी चाहिए और testing methods को परिभाषित करना चाहिए
• लंबे समय तक असर डालने वाले और बदलने में कठिन decisions का प्रबंधन हमेशा इंसानों को सीधे करना चाहिए

2. सटीक documents बनाए रखना

• AI को उद्देश्य के अनुरूप code generate कराने के लिए विस्तृत requirements देना अनिवार्य है
• अन्य developers को भी AI को वही जानकारी देनी होगी, इसलिए standardized format वाले documents को code repository में शामिल करना चाहिए
  • requirements, constraints, architecture, coding standards, design patterns आदि को विस्तार से दर्ज करें
  • UML diagrams, flowcharts, pseudocode आदि का उपयोग करके जटिल संरचनाओं को दृश्य रूप में व्यक्त करें

3. AI को support करने वाला debug system बनाना

• एक efficient debug system तैयार करना चाहिए ताकि AI code functionality को जल्दी verify कर सके
  • उदाहरण: distributed system के सभी node logs इकट्ठा करके “data सभी nodes तक भेजा गया” जैसी summary information देना
• इससे command execution cost कम होती है और problems की पहचान की गति बढ़ती है

4. code review स्तर को चिह्नित करना

• code की importance के अनुसार review intensity को अलग-अलग करना चाहिए
  • उदाहरण: AI द्वारा लिखे गए function के बाद //A comment जोड़कर यह दिखाना कि उसकी human review हुई है या नहीं
• यह system unreviewed code की पहचान और प्रबंधन को आसान बनाता है

5. high-level specification लिखना और tests सीधे बनाना

• AI tests पास करने के लिए mock objects या hardcoded values से धोखा दे सकता है
• इसे रोकने के लिए property-based testing को सीधे स्वयं लिखना चाहिए
  • उदाहरण: server restart करके database values की consistency verify करना
• test code को इस तरह अलग क्षेत्र में रखना चाहिए कि AI उसे modify न कर सके

6. interface tests को अलग रखना

• AI से interface tests इस तरह लिखवाने चाहिए कि उसे दूसरे code context की जानकारी न हो
  • इससे implementation AI का प्रभाव नहीं पड़ता और tests की objectivity बनी रहती है
• इन tests को भी AI द्वारा मनमाने ढंग से modify किए जाने से सुरक्षित रखना चाहिए

7. सख्त linting और formatting rules

• consistent code style और linting rules quality बनाए रखने और errors को जल्दी पकड़ने के लिए आवश्यक हैं
• इससे AI और इंसान, दोनों आसानी से code quality की जाँच कर सकते हैं

8. context-specific code agent prompts का उपयोग

• project-specific CLAUDE.md जैसे prompt files का उपयोग करके AI की शुरुआती समझ की लागत कम की जा सकती है
• coding standards, design patterns, requirements आदि शामिल करके AI की code generation quality और efficiency को बढ़ाया जा सकता है

9. security risk functions की पहचान और marking

• authentication, authorization, data processing जैसी security-sensitive functions को स्पष्ट रूप से चिह्नित करना चाहिए
  • उदाहरण: //HIGH-RISK-UNREVIEWED, //HIGH-RISK-REVIEWED comments का उपयोग
• यदि AI इन functions को modify करे, तो review status अपने-आप बदलने के लिए सेट करना चाहिए
• developers को हमेशा जाँचते रहना चाहिए कि यह status सही है या नहीं

10. code complexity को न्यूनतम रखना

• अनावश्यक code की एक पंक्ति भी AI की context window में जगह लेती है और cost बढ़ाती है
• structure को यथासंभव सरल रखकर AI और इंसानों, दोनों की समझ को बेहतर बनाना चाहिए

11. experiments और prototypes के ज़रिए problem exploration

• AI code generation की low-cost nature का उपयोग करके अलग-अलग solutions पर प्रयोग किए जा सकते हैं
• न्यूनतम specification के साथ कई prototypes बनाकर सबसे उपयुक्त approach खोजी जा सकती है

12. बिना सोचे-समझे large-scale generation से बचें

• जटिल कामों को छोटी units में विभाजित करना चाहिए ताकि AI उन्हें चरणबद्ध तरीके से संभाल सके
  • उदाहरण: पूरे project की बजाय individual functions या classes generate करना
• हर component specification के अनुरूप है या नहीं, यह verify करना चाहिए,
  और यदि code complexity पर नियंत्रण नहीं रहे, तो project को उसकी शुरुआती स्थिति में वापस ले जाना चाहिए

[GN⁺]

Hacker News की राय

• मुझे अब भी लगता है कि कोड खुद लिखते हुए सोच को व्यवस्थित करने की प्रक्रिया महत्वपूर्ण है
  मेरे लिए कोड एक तरह का मजबूर करने वाला साधन है जो मुझे बारीकियों को तराशने पर मजबूर करता है
  सिर्फ स्पेसिफिकेशन लिखने से वह गहराई नहीं मिलती

  • मैं भी यही सोचता हूँ। बचपन से खुद कुछ बनाकर सीखने की प्रक्रिया ही मूल रही है
    यह काम LLM को सौंप देने पर ऐसा लगता है जैसे विमान stall कर गया हो, और दिमागी प्रवाह रुक जाता है
    समस्या सुलझाने का तनाव तो कम होता है, लेकिन सोचने और रचने की प्रेरणा भी खत्म हो जाती है
    मेरे आसपास लोग AI से कोड लिखवाना पसंद करते हैं, लेकिन मैं उस समूह में नहीं हूँ
  • मुझे भी कुछ ऐसा ही लगता है।
    कॉफी पीते हुए 5 agents चलाकर SaaS बना लेने की बातें भरोसेमंद नहीं लगतीं
    अगर अच्छी quality का कोड चाहिए, तो खुद कोड में गहराई तक उतरने की प्रक्रिया ज़रूरी है
    फिर भी test लिखने या configuration issues सुलझाने जैसे सरल दोहराव वाले कामों में AI काफ़ी उपयोगी रहा
    उदाहरण के लिए, 5 साल पहले छोड़ दिया गया एक project मैंने Claude की मदद से फिर से जीवित किया, और कुछ ही घंटों में लगा कि आधा काम आगे बढ़ गया
  • मैं अब भी कोड खुद review और test करता हूँ
    बस आजकल ऐसा लगता है कि मैं फिर से स्पेसिफिकेशन-केंद्रित approach पर लौट आया हूँ
    agents की वजह से जल्दी-जल्दी trial और abandonment दोहराए जा सकते हैं, इसलिए iterative development flow अब भी बना रहता है
    मैं स्पेसिफिकेशन और tests को असली deliverable मानता हूँ, और उन्हीं के भीतर लगातार संशोधन करते हुए सोच को साफ करता हूँ
  • “कोड बारीकियों को तराशने पर मजबूर करता है” — इस बात से मैं पूरी तरह सहमत हूँ
    सिर्फ स्पेसिफिकेशन से वास्तविक दुनिया की जटिलता पूरी नहीं समाई जा सकती
    LLM द्वारा लिखा गया कोड अक्सर अनावश्यक रूप से लंबा और अजीब दिशाओं में बहता हुआ होता है, इसलिए सीधे प्रबंधन की ज़रूरत पड़ती है
    लेकिन LLM ideas पर चर्चा और उन्हें निखारने वाले partner के रूप में काफ़ी अच्छा है
  • पहले software engineering को assembly line की तरह देखने की बहुत कोशिशें हुई थीं, लेकिन असल में यह बनाते-बनाते design करने की प्रक्रिया थी
    अब जब कोड लिखना सस्ता और तेज़ हो गया है, तो शायद औपचारिक design चरण को और मज़बूत करना चाहिए

• मुझे लगता है कि static analysis tools को व्यवस्थित तरीके से सेट करना code quality पर सबसे बड़ा असर डालता है
  TypeScript के लिए मैंने tsc, eslint, sonarjs, knip, jscpd, dependency-cruiser, semgrep आदि को मिलाकर pnpm check command में एकीकृत किया है
  इसे pre-commit hook से अपने-आप चलने दिया, ताकि LLM से छूट जाने वाली समस्याएँ रोकी जा सकें
  इसकी वजह से जब LLM अटक जाता है तब भी manual fixes करना आसान रहता है

  • मुझे भी लगता है कि strict lint rules लागू करना अब बहुत आसान हो गया है
    code style एकसमान हो तो review काफ़ी आसान हो जाता है, और AI कोड और इंसानों के लिखे कोड के मिश्रण में भी कम भ्रम रहता है
  • मैं भी लगभग ऐसा ही setup इस्तेमाल करता हूँ। pre-commit hook तो ज़रूरी है
    लेकिन lint और tests दोनों pass हो जाने पर भी इरादे से अलग व्यवहार करने वाला कोड बन जाता है
    जैसे 404 की जगह empty array लौटाने वाला API — syntax के हिसाब से सही, लेकिन अर्थ के हिसाब से ग़लत
    ऐसी behavioral correctness evaluation अब भी सबसे कठिन हिस्सा है
  • कभी-कभी LLM ने नतीजों के बारे में झूठी रिपोर्ट भी दी है
  • अच्छा setup है। लेकिन maximum line length limit की ज़रूरत क्यों है, यह जानने की जिज्ञासा है। क्या ternary operator की वजह से?
  • मुझे तो कोड में स्पष्टता की कमी और ज़रूरत से ज़्यादा defensive coding बड़ा मुद्दा लगते हैं
    कभी-कभी lint rules से ज़्यादा maintainability को प्राथमिकता देनी चाहिए

• मैं हर फीचर जोड़ते समय नियमित refactoring करता हूँ
  हर कुछ features के बाद पूरे codebase की जाँच और सफ़ाई करता हूँ
  40 साल से coding कर रहा हूँ, लेकिन अभी का कोड सबसे ज़्यादा संतोषजनक लगता है

  • पहले “चल रहा है, तो deploy कर दो” वाली संस्कृति काफ़ी मज़बूत थी
    लेकिन LLM की वजह से refactoring की लागत लगभग 0 के बराबर हो गई है
    अब खराब कोड को जैसा है वैसा छोड़ देने का कोई कारण नहीं बचा
    efficiency बढ़ाने वाले tools को quality सुधारने में इस्तेमाल करना ही असली value है
  • मुझे भी ऐसा ही सबक मिला
    मैंने एक internal tool बनाया जो हर commit पर code lines को अच्छा (हरा)/refactor चाहिए (पीला)/दोबारा लिखना चाहिए (लाल) के रूप में चिह्नित करता है
    यह “TODO refactor” comments से ज़्यादा साफ़ और व्यवस्थित है, और जल्द ही इसे open source करने वाला हूँ

• इस समय मुझे लगता है कि AI के साथ काम करने के लिए specification-driven development सबसे स्थिर तरीका है
  मैं स्पेसिफिकेशन को बारीकी से निखारने और टीम व AI के साथ ideas पर आदान-प्रदान करने में ज़्यादा समय लगाता हूँ
  अगर स्पेसिफिकेशन अधूरा हो, तो AI अजीब कोड बना देता है
  domain की समझ गहरी हो जाए तो कभी-कभी शुरू से दोबारा implement करवाना बेहतर लगता है

  • ऐसी बातें सुनकर 90s के UML, 4GL, Rational जैसे सपने फिर याद आते हैं
    तब यह vision था कि “सिर्फ requirements define कर दो, system खुद बन जाएगा”
    अंत में वह असफल हुआ और agile मुख्यधारा बन गया, लेकिन अब लगता है कि तकनीक फिर से उस सपने को संभव बना रही है

• AI की असली value speed और ambiguity को संभालने की क्षमता में है
  लेकिन अगर हर प्रक्रिया पूरी तरह अपनाई जाए, तो अंततः सब कुछ waterfall जैसा धीमा हो जाता है
  मुझे लगता है कि खुद कोड लिखकर AI को पहले reviewer की तरह इस्तेमाल करना बेहतर है
  छोटे-छोटे हिस्सों में तेज़ी से validate करते हुए आगे बढ़ना अब भी agile approach ही है

  • अनुभवी developers के लिए भी इसमें कई उपयोगी ideas थे
    खासकर security-related functions को चिह्नित करने का सुझाव अच्छा था। बाद में code changes के समय context बनाए रखना आसान होता है
    “छोटे हिस्सों में बाँटना” बुनियादी बात है, लेकिन beginners अक्सर इसे नज़रअंदाज़ कर देते हैं
  • “यह सब करोगे तो फिर waterfall पर लौट जाओगे” वाली बात पर मज़ाक में जोड़ा गया: “अगला कदम शायद vibe-based brain surgery होगा”

• यह मज़ेदार है कि आजकल लोग AI की वजह से बुनियादी best practices को फिर से खोज रहे हैं
  असल में यह सब तो पहले से किया जाना चाहिए था

  • लेकिन व्यवहार में release pressure की वजह से इन्हें हमेशा निभा पाना मुश्किल था
    अब coding time कम होने से इन कामों के लिए थोड़ा breathing room मिल गया है
    ऊपर से AI documentation को वास्तव में इस्तेमाल करता है, इसलिए अच्छा documentation लिखना सीधे value पैदा करता है
    पहले docs लिखो तो कोई नहीं पढ़ता था, लेकिन LLM सब पढ़ लेता है
  • इस तरह के safeguards असल में खराब programmers (या तोतों) के लिए ही अनिवार्य हैं

• पहले मैं coding से पहले विस्तृत specifications लिखता था, लेकिन बाद में लगा कि सीधे code में उतरना ज़्यादा तेज़ है
  लेकिन क्या अब हम फिर से specification-centered approach पर लौट रहे हैं?
  अगर समस्या को पूरी तरह समझे बिना स्पेसिफिकेशन लिखो, तो आखिरकार coding करते-करते ही सीखना पड़ता है
  लगता है कि अभी हम इन दोनों के बीच कहीं हैं

  • स्पेसिफिकेशन छोड़ देने पर अक्सर पूरी तरह ग़लत program बन जाता है
    लेकिन अब AI की वजह से ग़लत कोड की लागत लगभग 0 हो गई है, इसलिए स्पेसिफिकेशन की value कुछ कम लगती है
  • जब AI सस्ते में कोड बना देता है, तो बिना specification पहले कोशिश करना, सीखना, और फिर दोबारा design करना संभव हो जाता है
    यह Joe Armstrong के बताए programming style जैसा है
    अब हम ऐसे दौर में हैं जहाँ यह व्यवहारिक रूप से संभव है
  • “योजना बनाओ, specifications तय करो, फिर code लिखो” — यह बात हमेशा सच रही है

• जब मैंने lead position संभाली, तब मैं tickets बहुत विस्तार से लिखता था
  यह juniors के लिए भी था, लेकिन उतना ही अपने लिए भी, ताकि मैं खुद details न भूलूँ
  लेकिन management ने इसे “समय की बर्बादी” कहकर विरोध किया, और धीरे-धीरे मेरी वह आदत छूट गई
  अब उल्टा मुझसे उससे भी ज़्यादा सटीक specifications और तेज़ी से लिखने की अपेक्षा की जा रही है

• AI agents का इस्तेमाल करते समय Markdown और code का अनुपात, और output की readability कैसी रहती है, यह जानने की उत्सुकता है
  यह भी सवाल है कि कहीं review में लगने वाला समय, खुद कोड लिखने से ज़्यादा तो नहीं हो जाता

• यह विडंबनापूर्ण है कि आजकल developers ऐसे AI का बड़े उत्साह से बचाव कर रहे हैं जो शायद एक दिन उन्हें replace भी कर सकता है
  संबंधित ट्वीट लिंक इस प्रवृत्ति का व्यंग्य करता है

  • “AI को data poisoning से बिगाड़कर रोक दो” वाली Underground Resistance चर्चा भी है
  • Claude की performance problems तक ठीक नहीं हो रहीं, तो लगता है IPO से पहले marketing को और तेज़ किया जा रहा है
    “Claude इस्तेमाल नहीं किया तो पीछे रह जाओगे” — शायद इसी वजह से यह संदेश दिया जा रहा है
  • बहुत से developers कहते हैं कि “AI की वजह से productivity बढ़ी है”,
    लेकिन वास्तव में यह developers की demand और compensation में कमी की ओर जा सकता है
    खासकर वे developers जो सिर्फ NPM packages जोड़कर काम चलाते हैं, उनके लिए ख़तरा और बड़ा है