कोड ऐसा लिखें जैसे कोई इंसान उसकी मेंटेनेंस करेगा

• भले ही LLM लगातार आपकी जगह कोड लिखता रहे, अगर duplicate conditionals और अस्थायी implementations को वैसे ही merge कर दिया जाए, तो बाद में generated code उस तरीके को project rule की तरह follow कर सकता है
• access permission check logic को route handler, background job, API endpoint, webhook वगैरह में बार-बार डालने पर tests तो pass हो सकते हैं, लेकिन maintenance burden जस का तस रहता है
• model खुली files, existing patterns और recent changes देखकर अगला code बनाता है, इसलिए किसी copied conditional की 4 copies पांचवीं copy को बुलाने वाला signal बन जाती हैं
• बाद में refactoring मांगने पर भी यह guarantee करना मुश्किल है कि LLM सभी existing copies को ठीक से साफ कर देगा, और खराब pattern एक बार की गलती से ज्यादा codebase की style जैसा बन जाता है
• duplicate conditionals, “god” functions, और “बाद में साफ करेंगे” वाले merges जमा होते जाएं, तो सिर्फ prompt से उन्हें वापस पलटना मुश्किल हो जाता है और आखिरकार इंसान को खुद ठीक करना पड़ता है

---

LLM जिस चीज़ को reference करता है, वह मौजूदा codebase है

• LLM code को “vacuum” में नहीं लिखता, बल्कि user का codebase पढ़ता है
  • खुली files
  • पहले से मौजूद patterns
  • recent changes
• codebase में merge किए गए shortcuts “यहां ऐसा ही किया जाता है” जैसा learning signal बन जाते हैं
• वही access control condition कई जगह दोहराई जा सकती है

if (user.isActive && user.hasPermission('read') &&
!user.isSuspended && account.status === 'open') {
  // do a thing
}

• इस conditional को shared helper में extract किया जा सकता है, लेकिन LLM का बनाया code काम करता है और tests pass होते हैं, इस वजह से इसे वैसे ही merge किया जा सकता है
• जब आप उसी rule वाला पांचवां endpoint मांगते हैं, तो model के शुरुआत से design करने के बजाय repository के अंदर मौजूद पुरानी copies को follow करने की संभावना ज्यादा होती है

maintenance को LLM पर छोड़ देने का भ्रम

• “बाद में बदलना होगा तो LLM कर देगा” वाला विचार duplication और code smells को अनदेखा करवाता है
• कुछ duplicate conditionals घातक नहीं हो सकते, लेकिन ऐसे code smells लगातार जमा होते रहते हैं
  • duplicate conditionals
  • “god” functions
  • “बाद में साफ करेंगे” कहकर किए गए merges
• खराब patterns बढ़ने पर अगली prompt के result पर भी असर पड़ता है, और यह भरोसा करना मुश्किल हो जाता है कि बाद में LLM सभी instances को बिना छोड़े ठीक कर देगा
• maintenance को LLM को outsource करने जैसा सोचने पर भी, असल में आप उसे लगातार बिगड़ती आदतों को repeat करने की स्थिति में डाल सकते हैं
• code ऐसा लिखना चाहिए जैसे कोई इंसान उसकी maintenance करेगा, और LLM जिन code patterns को absorb करके वापस देगा, उन्हें अच्छी स्थिति में बनाए रखना चाहिए

[GN⁺]

Hacker News की रायें

• .claude/commands/review.md में एक खाली Markdown फ़ाइल के रूप में /review command बनाकर, उसमें agent के लिए चेक करने वाली checklist डाल देना अच्छा रहता है
  जब code review चाहिए हो, तो /review टाइप करने पर वह checklist देखकर सुधारने लायक items की योजना बनाता है और फिर पूछता है
  मेरी फ़ाइल “plan mode में जाओ। इस branch और main के बीच का अंतर देखो। ध्यान देने वाली बातें: ...” से शुरू होती है, और code review के दौरान मिलीं वे बातें, जिन्हें मैंने agent से ठीक करवाया, लगातार जोड़ता गया तो अब करीब 200 हो गई हैं
  agent को सामान्य feedback की दीवार मिले तो भी वह परवाह नहीं करता और items को एक-एक करके देखता है; जब मैंने “जाँचो कि नई बनाई चीज़ें मौजूदा code से duplicate तो नहीं हैं” जोड़ा, तो वह सच में cleanup work की योजना बनाने लगा, यह देखकर हैरानी हुई
  अभी यह बस सतह खुरचने जैसा है, और tool को बेहतर tool बनाने के लिए tool के लिए tool देना होगा

  • सूची में जितने ज़्यादा items डालता गया, agent की performance उतनी ही खराब होने के करीब लगी
    अभी भी काफ़ी सरल instructions ही इस्तेमाल करता हूँ, लेकिन Claude अक्सर “बिना अनुमति git में commit न करना”, “commit message में signature न जोड़ना” जैसे शुरुआती निर्देश तोड़ देता है
    पूछने पर वह जवाब देता है, “हाँ, वह निर्देश था लेकिन मैंने ignore किया,” और session में विनम्रता से सुधारने पर समझ तो जाता है, लेकिन बाद में कभी-कभी बिल्कुल commit न कर पाने की स्थिति में पहुँच जाता है
    200-item checklist review करवाने पर उनमें से काफ़ी कुछ वह चुपचाप छोड़ रहा हो, इसकी संभावना ज़्यादा है
  • AI tools को लेकर मेरी हमेशा की शिकायत यही रही है कि quality expectations समझना मुश्किल होता है
    किसी human engineer के लिए, अगर मौजूदा 200 tests एक assertion library इस्तेमाल कर रहे हों, तो वह नए test में बिल्कुल अलग library नहीं लगाएगा; लेकिन Claude ने ऐसा कई बार किया
    इसलिए “लिखने से पहले test conventions देखो” जैसे items लगातार जोड़ने पड़ते हैं
    दूसरी तरफ़, function क्या होता है या tests को change diff handle करना चाहिए जैसी basics बताने की ज़रूरत नहीं होती; लेकिन क्या बताना है और क्या ठीक है, इसकी कोई स्पष्ट सूची नहीं है, इसलिए trial and error से कामचलाऊ तरीका बनाने जैसा लगता है
  • जिज्ञासा है कि क्या आप वह सूची share कर सकते हैं
    मेरे मामले में agent के साथ आते-जाते “जब तक मेरी नज़र और पसंद को ठीक न लगे” तब तक polish करने का काम बहुत होता है, लेकिन मैंने अभी ऐसी list नहीं बनाई है
    project के हिसाब से छोटी-मोटी समस्याएँ या magic numbers allow किए जाते हैं, और किसी दूसरे project में SECONDS_IN_A_DAY = 24 * 60 * 60 जैसे meaningful नाम वाले constants enforce किए जाते हैं, इसलिए यह context-dependent है
  • open-code-review आज़माया और अच्छे results मिले
    https://github.com/alibaba/open-code-review
    https://layandreas.github.io/personal-blog/posts/beyond-vide...
  • मैं अपनी review skill इस्तेमाल कर रहा हूँ, और description में एक चीज़ जोड़ूँ तो: पहले पूरे code को देख लेने के बाद changes के हिसाब से multi-role review फिर से कराने को कहना अच्छा है
    उदाहरण के लिए Senior Engineer, Security Engineer, WCAG specialist जैसी लंबी roles list में से change के लिए सबसे उपयुक्त N roles चुनवाता हूँ
    Claude उन reviews को parallel में चलाता है और फिर feedback मिला देता है
    मैं specification-based development करता हूँ, इसलिए मिली हुई issues को specification में जोड़कर issues और decisions का trail छोड़ रहा हूँ

• यह अजीब है कि यहाँ इतने सारे इंजीनियर एक और prompt जोड़ रहे हैं
  मेरे अनुभव में ऐसा करने से हालात और खराब हुए हैं: abstraction तो बनता है, लेकिन गलत abstraction; comments जरूरत से ज्यादा हो जाते हैं और बाद की LLM calls तक भ्रमित हो जाती हैं
  अच्छे codebase में यह जैसे-तैसे काम कर लेता है, लेकिन code को धीरे-धीरे बदतर बनाता है; और लगातार इस्तेमाल करते-करते जब किसी समय यह काम नहीं करता, तो तब आपको वह कीमत चुकाकर ठीक करना पड़ता है कि आपने इसे खुद नहीं बनाया था
  किसी नए codebase में agent डालें तो आम तौर पर code को लेकर एक mental model होता है और code भी कुछ हद तक concise होता है, लेकिन iterations जमा होते ही दोनों गायब हो जाते हैं और LLM की performance भी गिरती है
  इसलिए मैं LLM का इस्तेमाल exploration और review के लिए करता हूँ, code खुद लिखता हूँ
  Coding में बहुत ज्यादा समय भी नहीं लगता और वही सबसे मजेदार हिस्सा है; लोग इसे टालना क्यों चाहते हैं, यह समझना मुश्किल है। कभी-कभी /bug prompt से AI के साथ साथ-साथ debugging race करके देखता हूँ, तो AI हमेशा तेज भी नहीं होता

  • “Code मैं खुद लिखता हूँ। इतने सारे इंजीनियर इसे टालना क्यों चाहते हैं, यकीन करना मुश्किल है” — इससे सहमत हूँ
    पिछले कुछ वर्षों में software का काम जिज्ञासु tinkerers और puzzle addicts के लिए व्यावहारिक engineering refuges में से एक होने से बदलकर, finance·law·medicine की तरह पैसे के पीछे आने वाले होशियार लोगों का career path बन गया है
    आज “software engineer” title रखने वाले बहुत से लोगों ने शुरुआत से ही इस काम का आनंद कभी नहीं लिया; वे बस होशियार और जिम्मेदार थे, इसलिए employer द्वारा दिए गए ठीक-ठाक goals हासिल कर पाए
    ऐसे लोग सबसे ज्यादा चाहते हैं कि AI agents कठोर design और puzzle work से उन्हें बचा लें और उनकी नैसर्गिक बुद्धिमत्ता को और आलसी तरीके से इस्तेमाल करने दें
    क्योंकि coding और engineering principles उन्होंने भीतर तक नहीं अपनाए, उसी mindset वाले सहकर्मियों से घिरे होने पर यह तरीका आगे क्या परिणाम देगा, इसका अनुमान लगाना कठिन है
    अगर coding खुद शुरुआत से ही बहुत frustrasting और friction-भरा अनुभव रहा हो, तो यह महसूस करना आसान है कि AI ज्यादा तेज है
  • Agents code “बेहतर” लिखते हों ऐसी दुनिया में भी लोगों को खुद code लिखना चाहिए—मुझे इसका कारण यही लगता है
    Code को सिर्फ पढ़ना पर्याप्त नहीं है; दर्द झेलकर ही वह भीतर उतरता है
    Agents अक्सर यह पूछने के बजाय कि कोई मौजूदा path अब भी होना चाहिए या नहीं, पुराने code को defensive तरीके से wrap कर देते हैं, जिससे भारी मात्रा में defensive code रूसी गुड़ियों की तरह परत-दर-परत जमा होने का असर पैदा होता है
    https://softwaredoug.com/blog/2026/07/09/write-code
  • मैं काफी समय से AI के साथ “debugging race” करता आया हूँ, और Opus 4.8 से पहले जरा भी जटिलता आते ही तुलना नहीं थी
    Opus 4.8 turning point था, और खासकर complex problems में अब मैं Opus 4.8 के खिलाफ ज्यादा बार नहीं जीतता
    अगर हर कोई हर काम और सवाल के लिए Opus 4.8 या उससे ऊपर इस्तेमाल करे, तो कुल माहौल बहुत अलग होगा, और शायद AI skeptics भी ज्यादा नहीं बचेंगे
  • अगर quality की परवाह किए बिना ticket बंद करने के लिए जितनी जल्दी हो सके code उगलना है, तो AI हमेशा तेज है
  • मैं भी मिलते-जुलते flow में काम करता हूँ
    अब भी code हाथ से खुद लिखता हूँ, हालांकि सब नहीं—कुछ हिस्सा Opus generate करता है

• यह अटपटा विचार हो सकता है, लेकिन बस code खुद लिखिए
  AI युग में यह अविश्वसनीय concept लग सकता है, लेकिन अगर code इंसानों को पढ़ना और maintain करना है, तो बेहतर है कि आप उन लोगों के लिए खुद लिखें
  बहुत verbose और copy-pasted code पढ़ते-पढ़ते आपको झुंझलाहट होगी, और दूसरों को भी
  खुद लिखेंगे तो खुद सुधारेंगे, और ऐसा लिखेंगे जो किसी और के maintain करने के लिहाज से समझ में आए
  वरना आप future maintainers की अपेक्षित code shape को agent और loop से समझाने के लिए Markdown files का एक जटिल जाल भी बना सकते हैं
  लंबे समय में कौन-सा रास्ता आसान होगा, नहीं जानता; और जानना चाहूँगा कि क्या किसी ने loop-based agent-driven codebase विरासत में लेकर उसे समझा है

• “अगली बार जब आप LLM से समान access rules वाला endpoint माँगते हैं, तो model शुरुआत से नहीं सोचता, बल्कि repository में पहले से मौजूद चार copies से शुरू करता है” — यह कितना सही है, मुझे पक्का नहीं
  असल में लगता है कि basic structure को दोहराने और reuse या abstraction कम करने की एक built-in bias है
  मौजूदा pattern ऐसा हो तो यह लगता है कि वह उसका पालन कर रहा है, लेकिन वास्तव में संभावना है कि वह किसी भी हालत में ऐसा ही करता
  पहले से strict abstraction और usage examples रखकर, सिर्फ किसी खास abstraction API का इस्तेमाल करने और मेरे लिखे तरीके तक copy करने को साफ निर्देश देने पर भी, latest LLMs ने कई बार दोनों नहीं किया; नीचे से basic structure फिर implement किया और abstraction को आंशिक या पूरी तरह ignore किया
  यह क्यों होता है, ठीक-ठीक नहीं जानता, लेकिन शायद training code में इस तरह का code इतना ज्यादा है कि weights इस तरीके से output देना बेहतर “जानते” हैं

  • आज की दुखद reality यही है, और इससे बचना हो तो model को implementation का तरीका बहुत specific होकर बताना पड़ता है
    फिर भी LLM को तेज implementation engine की तरह इस्तेमाल करना ठीक लगता है
    challenge यह है कि model गलत दिशा में भागने से पहले ऐसे implementation decisions सामने कैसे लाए

• बड़े बदलाव के बाद मुझे इस prompt से अच्छे नतीजे मिले
  “अब final code review करो। क्या सब कुछ tidy है और components separation of concerns principle का पालन करते हैं? क्या यह समझने योग्य और maintainable स्थिति में है? क्या इसमें ऐसी assumptions हैं जो अब सच न भी हों? क्या previous edits या experiments से बचा code codebase में रह गया है? क्या docs अभी भी current code state को reflect करते हैं?”

  • आम तौर पर मैं बस इतना कहता हूँ: “देखो कि यह code senior engineer द्वारा deliver करने लायक professional state में है या नहीं”
    तब यह ऊपर कही बातों और उससे आगे की चीजों को आम तौर पर infer कर लेता है
    लेकिन एक चीज लगातार सीधे बतानी पड़ती है: “progress tracking” वाले सारे comments हटाओ, और सिर्फ long-term maintenance के लिए उपयोगी comments छोड़ो
    Claude कभी-कभी “button click अब save trigger करता है और अब onBlur नहीं इस्तेमाल होता” जैसे comments छोड़ देता है, जबकि असल code ने कभी onBlur इस्तेमाल किया ही नहीं होता; वह बस उसी task/branch में Claude पहले जो करने जा रहा था, उसे मैंने वापस मोड़ा था—उसका निशान होता है
  • यह verbose “गलती मत करना” जैसा है; बल्कि पिछले दिन के काम को scan करके उसी तरह का morning task बनाने वाली nightly cron job रखना शायद ज्यादा समझदारी हो सकती है
    Model अपनी मर्जी से interpret करेगा, लेकिन फिर भी कई बार कुछ न करने से बेहतर होगा
  • यह AI-native सोच का अच्छा उदाहरण है
    तरीका यह है कि AI को सब कुछ सिखाओ और पूछो कि उसने ठीक से सीखा या नहीं; results हैरानी की बात है कि अच्छे आते हैं
    मैं भी इस लेख जैसे steps follow कर रहा हूँ
    https://www.lucasfcosta.com/blog/backpressure-is-all-you-nee...

• एक पुरानी कहावत है
  “कोड में comments ऐसे लिखो जैसे अगला maintainer कोई कातिल पागल हो जिसे पता हो कि तुम कहाँ रहते हो”

  • आजकल जो comment सबसे ज़्यादा गुस्सा दिलाते हैं, वे LLM-स्टाइल की ज़रूरत से ज़्यादा जानकारी वाली comments हैं, जो function definition के ठीक ऊपर उस function के मौजूदा किसी खास caller के behavior को बताकर encapsulation तोड़ देती हैं
    हाल ही में PR review में ऐसी चीज़ कईवीं बार दिखी तो मैंने गुस्से में comment कर दिया, और खुद भी चौंक गया
    मुझे नहीं पता था कि मैं ऐसी प्रतिक्रिया दे सकता हूँ
  • पहले साथ काम करने वाला एक व्यक्ति अक्सर कहता था, “comments माफी हैं”
    यानी comment इसलिए है क्योंकि code खुद स्पष्ट नहीं है; ऐसे मामले होते हैं, लेकिन सामान्य तौर पर मुझे लगता है कि कम comments से ज़्यादा comments बेहतर हैं
    खासकर अगर वे यह समझाएँ कि code वास्तविक business या feature requirements से कैसे जुड़ता है, और सिर्फ code क्या कर रहा है उसे दोहराएँ नहीं
    कुछ साल पहले मैं पहले comments लिखा करता था
    पहले पूरे goal को समझाता, फिर उसे routines और कामों के क्रम में बाँटता, और जब संतुष्ट हो जाता तो comments के बीच code blocks भरता था
    यह कुछ हद तक literate programming जैसा है, लेकिन मैं यह उस शब्द को जानने से पहले से कर रहा था; यह goal की ओर खुद को prompt देने जैसा था
    कमी यह है कि comments अंत में code क्या कर रहा है उसे अंग्रेज़ी में समझाने भर तक सीमित हो सकती हैं, इसलिए भविष्य के maintainers के लिए बहुत उपयोगी न हों
  • हत्या वाली भावना सबसे ज़्यादा बिना comments वाले code से नहीं, बल्कि पुरानी या गलत comments से आती है
  • यह जरूरत से ज़्यादा comments को बढ़ावा देने वाली prescription जैसी लगती है
    code को खुद अपनी व्याख्या करनी चाहिए, और comments वहाँ लिखने चाहिए जहाँ dragons हैं

• इसी संदर्भ में मेरा पसंदीदा prompt है: “तुमने जो tests लिखे हैं उन्हें review करो। क्या ये tests सच में वही test कर रहे हैं जो intended है? अगर code टूटे तो क्या tests भी fail होंगे?”
  हैरानी होती है कि LLM कितनी बार ऐसे खाली tests लिख देता है जो कुछ भी verify नहीं करते

  • मैंने इंसानों द्वारा लिखे tests में भी कई बार देखा है कि वे असल code को verify नहीं करते, सिर्फ test framework को verify करते हैं
  • मेरा workflow है: पहले test लिखना और उसका fail होना verify करना, फिर उस test को pass कराने वाला न्यूनतम code लिखना, और फिर green है यह confirm करना

• अब भी इस तरह की बात को गंभीरता से discuss करना पड़ रहा है, यह सोचकर अजीब लगता है
  अगर LLM के साथ इस तरह “experiment” करके देख लिया है, तो अब इसे स्वाभाविक रूप से स्वीकार कर लेना चाहिए, ऐसा लगता है
  पता नहीं कब हम hand-coding को फिर से किसी taboo की तरह treat किए बिना उस पर बात कर पाएँगे
  LLM कई तरह से उपयोगी है, लेकिन जब लोगों को पूरा source code type करना agents को सौंपते देखता हूँ तो यह वैसा ही महसूस होता है जैसे कोई कहे कि web अच्छा है, इसलिए हमें खुश होना चाहिए

• मैं codebase को लगातार कई models पर चलाकर duplicate code जैसी bad smells ढूँढवा रहा हूँ
  यह काफ़ी प्रभावी रहा है, और अगर समय के साथ लगातार maintain न किया जाए तो यह गंदे ढेर में बदल जाएगा और जमा होता रहेगा, ऐसा लगता है

  • cyclic complexity या code duplication को निर्णायक रूप से पकड़ने वाले SonarQube, Rubocop जैसे AST-based static analyzers के बारे में आपका क्या विचार है, यह जानना चाहूँगा
    उन्हें build pipeline में भी डाला जा सकता है, और वे tokens भी बिल्कुल इस्तेमाल नहीं करते
  • क्या आपको लगता है कि अलग models का इस्तेमाल करना ज़रूरी है?
    या review process और context reset ज़्यादा अहम हैं?

• मैंने 20 साल तक maintain किए गए code में भी इस तरह का duplication और उससे भी बुरी चीज़ें बहुत देखी हैं
  सच कहूँ तो ज़्यादातर मामलों में इंसानों द्वारा लिखा और maintain किया गया code, आज LLM जो बनाता है उससे भी बदतर रहा है
  कभी यह अनुभव की कमी के कारण होता है, कभी जानबूझकर की गई लापरवाही के कारण, लेकिन आम तौर पर वजह tight schedule और अभी तुरंत खत्म करने का pressure होता है
  लोग जानते हैं कि बेहतर कैसे करना है, लेकिन असल में वैसा करने के लिए समय और budget नहीं होता
  LLM ने भी यही सीखा है

  • LLM से पहले Copilot बहुत दोहराता था, और उससे पहले copy-paste और Stack Overflow थे