AI हमें अच्छा कोड लिखने के लिए मजबूर कर रहा है
(bits.logic.inc)- जब AI एजेंट कोड लिखने के केंद्र में आ रहे हैं, तो testing, documentation, static typing जैसी पहले की ‘वैकल्पिक’ best practices अब अनिवार्य तत्व बन रही हैं
- 100% code coverage की मांग की जा रही है, ताकि कोड की हर लाइन वास्तव में verify हो और executable examples से समर्थित हो
- directory structure और file naming को स्पष्ट बनाकर LLM के लिए codebase को navigate करना आसान किया जाता है, और छोटे-छोटे files की संरचना को प्रोत्साहित किया जाता है
- तेज़, ephemeral, और concurrent development environments बनाए जाते हैं, ताकि कई agents parallel में काम कर सकें
- static type systems और automated quality control tools के जरिए ऐसा code ecosystem बनाए रखना मुख्य है, जिस पर AI भरोसा कर सके
AI और ‘अच्छे कोड’ की अनिवार्यता
- लंबे समय से developers testing, documentation, छोटे modules, static typing को अच्छे कोड का मानक मानते रहे हैं, लेकिन व्यवहार में इन्हें अक्सर छोड़ दिया जाता था
- लेकिन AI एजेंट अपने-आप कोड को अच्छी तरह व्यवस्थित नहीं कर पाते, इसलिए ये best practices अब अनिवार्य हो गई हैं
- agents गलत दिशा में काम न करें, इसके लिए स्पष्ट guardrails सेट करना और उन्हें सख्ती से लागू करना ज़रूरी है
- मजबूत guardrails हों तो LLM सही रास्ते की ओर converge करता है, जबकि अधूरे environment में वह समस्याओं को और बढ़ा देता है
100% code coverage
- टीमें 100% code coverage को अनिवार्य बना रही हैं; इसका मकसद सिर्फ bugs रोकना नहीं, बल्कि agent द्वारा लिखे गए हर कोड के व्यवहार को verify करना है
- 95% या 99.99% coverage में untested code का स्रोत अस्पष्ट रह सकता है, लेकिन 100% पर हर unverified line को साफ़ तौर पर पहचाना जा सकता है
- coverage report को test किए जाने वाले कार्यों की सूची की तरह इस्तेमाल किया जाता है, और LLM को code change करते समय executable example ज़रूर देना चाहिए
- इस approach के अतिरिक्त लाभों में unreachable code हटाना, edge cases को स्पष्ट करना, और code review की efficiency बढ़ाना शामिल है
namespace और file structure
- agents file system के माध्यम से codebase को navigate करते हैं, इसलिए directory structure और file names एक महत्वपूर्ण interface की भूमिका निभाते हैं
- ./billing/invoices/compute.ts जैसा स्पष्ट path, ./utils/helpers.ts की तुलना में कहीं अधिक जानकारी देता है
- छोटे और अच्छी तरह परिभाषित file units को प्राथमिकता देनी चाहिए, ताकि LLM पूरे file को context में load कर सके और performance degradation से बचा जा सके
- ऐसी संरचना agent की खोज-गति और accuracy दोनों को बेहतर बनाती है
तेज़, ephemeral, और concurrent development environments
- पारंपरिक single development environment की जगह, agent-आधारित development में कई processes को parallel में manage करने वाला मॉडल अपनाया जा रहा है
- Fast: testing और verification प्रक्रियाएँ तेज़ चलनी चाहिए; टीमें 10,000 से अधिक assertions को 1 मिनट के भीतर पूरा करने के लिए optimization कर रही हैं
- उच्च स्तर की parallelization, मजबूत isolation, और third-party call caching layer के जरिए गति हासिल की जाती है
- Ephemeral:
new-feature <name>कमांड से 1–2 सेकंड में नया environment तैयार, auto-configuration और agent execution के साथ- यदि manual setup की ज़रूरत पड़े, तो उपयोग की आवृत्ति तेज़ी से गिरती है; इसलिए पूर्ण automation मुख्य है
- Concurrent: कई development environments को एक साथ चलाने के लिए ports, DB, cache आदि में conflict रोकने वाली settings चाहिए
- Docker का उपयोग किया जा सकता है, या environment variables के आधार पर isolation कॉन्फ़िगर किया जा सकता है
end-to-end type system और automated quality control
- LLM की स्वतंत्रता कम करने और consistent quality बनाए रखने के लिए, जितनी संभव हों उतनी best practices को automate किया जाता है
- auto linter और formatter को सख्ती से configure किया जाता है, ताकि LLM के काम पूरा करते ही automatic fixes लागू हो जाएँ
- static typed language के उपयोग की सिफारिश की जाती है, खासकर TypeScript के मजबूत type system के साथ
UserId,WorkspaceSlug,SignedWebhookPayloadजैसे अर्थपूर्ण type names कोड के इरादे को स्पष्ट रूप से व्यक्त करते हैं
- OpenAPI के जरिए frontend और backend के बीच type consistency बनाए रखी जाती है
- Postgres के type system और triggers का उपयोग करके data integrity सुनिश्चित की जाती है, और Kysely से type-safe client बनाया जाता है
- सभी third-party clients भी सटीक type definitions के साथ होने चाहिए, या उन्हें wrap करके इस्तेमाल किया जाना चाहिए
निष्कर्ष: AI युग में code quality की नई परिभाषा
- agents थकते नहीं और बेहतरीन coders हो सकते हैं, लेकिन उनका प्रदर्शन environment की quality पर निर्भर करता है
- ‘अच्छा कोड’ अब सिर्फ एक विकल्प नहीं, बल्कि AI के सही ढंग से काम करने की पूर्व-शर्त है
- शुरुआती setup बोझिल लग सकता है, लेकिन यह बहुत समय से टलता आया एक आवश्यक निवेश है
- development leadership के समर्थन के साथ, AI-friendly codebase बनाने को लक्ष्य बनाना चाहिए
1 टिप्पणियां
Hacker News टिप्पणियाँ
100% कवरेज हासिल करने का फंदा यह है कि अगर code और test दोनों एक ही agent लिखे, तो वह आत्म-विरोधी validation में फँस सकता है
अगर agent गलत logic बनाए और उसे verify करने वाले test भी गलत लिख दे, तो test pass हो जाएंगे, लेकिन code वास्तव में buggy होगा
ऐसी कवरेज का मतलब तभी है जब test code से पहले लिखे गए हों, या कोई इंसान उन्हें सख्ती से verify करे
वरना यह सिर्फ भरोसे का भ्रम पैदा करती है
असली बात यह है कि अलग-अलग सोच वाले लोग एक-दूसरे के blind spot verify करें
चाहे कई AI model हों, आखिरकार उन्हें एक ही ‘mind’ की तरह मानना चाहिए
इंसान के code पर AI test, AI के code पर इंसान test, या एक-दूसरे का code review करना बेहतर है
लेकिन इंसानों के बीच भी power relation की वजह से कई बार सिर्फ एक व्यक्ति की राय ही लागू होती है, और AI इसे नहीं रोकता
जानबूझकर bug डालकर देखना चाहिए कि वे fail होते हैं या नहीं
यह सिर्फ AI की समस्या नहीं है, इंसानों पर भी यही लागू होता है
फिर भी AI की वजह से बहुत से developers ठोस engineering principles सीख रहे हैं, यह अच्छी बात है
SQLite और aviation software ऐसे स्तर को लक्ष्य बनाते हैं
हालांकि यह अभी academic रूप से verified hypothesis नहीं है
इसलिए integration test या UI automation test से असली user scenario verify करने चाहिए
production environment से लिया गया data या shadow environment में testing भी मददगार है
LLM से पहले इन्हें सेट करना झंझट भरा था, लेकिन अब ROI बेहतर हो गया है
Uncle Bob ने जिस तरह ज़ोर दिया था, test को structure करने में निवेश करना महत्वपूर्ण है
LLM दोहराव वाले test लिख देता है, लेकिन कहने पर DRY principle या factory pattern भी अच्छी तरह लागू कर देता है
यह तरीका मैं कल से आज़मा रहा हूँ: पहले TLA+/PlusCal में spec लिखता हूँ, फिर Codex से कहता हूँ कि उसी spec को ज्यों-का-त्यों implement करे
मैं उसे निर्देश देता हूँ कि creativity न दिखाए, सिर्फ spec के प्रति वफादार रहे
नतीजे का code बदसूरत लेकिन सही होता है, और खुद translate करने से कहीं तेज़ है
हाँ, optimization की कमी हो या code बहुत गंदा लगे तो मैं कुछ हिस्से सुधार देता हूँ
खासकर मैं lock-free data structures पर प्रयोग कर रहा हूँ, लेकिन Codex अब भी lock इस्तेमाल करना चाहता है, इसलिए मुझे खुद ठीक करना पड़ता है
आखिर में मैं mathematical logic पर फोकस करता हूँ, और AI implementation details संभालता है
यही “spec पहले, code बाद में” का आदर्श flow है
Martin Kleppmann की पोस्ट से सहमत हूँ
नए model में यह सचमुच अच्छी तरह काम करता है, और cost efficiency भी 10~100 गुना बेहतर हुई है
यह hallucination या sales pitch जैसा लगता है
अगर असली production bug और maintenance burden अच्छे code को मजबूर नहीं कर सकते, तो AI भी नहीं कर सकता
मौजूदा स्तर का AI तो उल्टा code को और खराब बना सकता है
जब method की लंबाई तक पर सहमति नहीं है, तब universal quality standard जैसा कुछ नहीं है
test coverage जैसे metric आसानी से manipulate किए जा सकते हैं, और गलत तरीके से लागू हों तो नुकसानदेह भी हैं
खासकर जब AI test लिखता है, तो यह झूठा आत्मविश्वास दे सकता है
मुझे लगता है software development शायद LLM का इकलौता वास्तविक उपयोग क्षेत्र हो सकता है
दूसरे क्षेत्रों की तुलना में यहाँ feedback loop बहुत जल्दी बन सकता है
LLM के साथ योजना बनाओ, कुछ घंटों बाद failure देखो, फिर LLM कहता है “इसलिए ऐसा नहीं करना चाहिए”
यह वैसा है जैसे अमेरिकी electrical standard से घर बनाकर उसमें Canadian dishwasher लगाते समय समस्या पकड़ना
software अपेक्षाकृत सुरक्षित था, इसलिए anonymous development संभव था, लेकिन अब responsible sign-off culture बन रही है
आगे चलकर शायद सिर्फ high-risk, innovative code लिखने वाले लोगों को ही ज़्यादा भुगतान मिलेगा
AI बार-बार ऊल-जुलूल code देता है, हम debug करते हैं, फिर वह कुछ और ऊल-जुलूल देता है — बस एक infinite loop बन जाता है
बस current specification मिलना चाहिए, तब वह सुरक्षित है
फिर भी मुझे अच्छा लगता है कि unit test के ज़रिए reality से एक touchpoint बना रहता है
मैं LLM से RLC circuit और inerter पढ़ रहा हूँ
बहुत लोग LLM को तेजी से code बनाते देख हैरान होते हैं, लेकिन speed या volume quality का bottleneck नहीं हैं
असली क्रांति तब होगी जब AI इंसानों से ज़्यादा accurate code लिखेगा
असली value यह जानने में है कि code कैसे काम करता है
मीटिंग में जहाँ बाकी engineer सिर्फ अंदाज़ा लगाते रहते हैं, वहाँ एक व्यक्ति का असली code खोलकर दिखाना सबसे ज़्यादा मूल्यवान पल होता है
‘अच्छा code’ शायद इंसान की सीमित working memory के मुताबिक optimized code हो सकता है
model एक साथ पूरा context देख सकता है, इसलिए उस पर यह सीमा नहीं है
अगर context window 100 गुना बड़ी हो जाए, तो शायद यह बहस कम महत्वपूर्ण रह जाए
LLM से 100% कवरेज माँगने पर डर है कि गलत assumptions स्थायी न हो जाएँ
फिर भी अगर human review हो, तो शायद कहा जा सकता है “यह गलत है, test हटाओ और दोबारा लिखो”, है न?
LLM interview की तरह PRD साथ में तैयार करता है ताकि scope और expectation साफ़ हो जाएँ
“best practice” तकनीकी माहौल के हिसाब से बदलती है
अब जब code लिखना आसान हो गया है, तो 100% कवरेज LLM के लिए ज़्यादा उपयोगी हो सकती है
test, LLM को साफ़ लक्ष्य देते हैं और बाद की interaction को अधिक सुरक्षित बनाते हैं
हर test पुराने bug ticket को refer करता है और यह सुनिश्चित करता है कि fix बना रहे
LLM को scenario देने पर वह ज़्यादातर समान quality का code बनाता है
creative art के उलट, software automation के लिए विशेष रूप से उपयुक्त industry है
पोस्ट पढ़कर लगा था कि बात यह होगी कि “AI के प्रभावी होने के लिए हमें अच्छा code लिखना होगा”
सच में Claude अस्पष्ट variable name या अतार्किक code में अक्सर गलती करता है
अगर variable name “iteration_count” हो लेकिन उसमें sum रखा जा रहा हो, तो AI धोखा खा जाता है
आखिरकार clean code AI और इंसान दोनों की मदद करता है
क्योंकि AI internal docs को learning resource की तरह इस्तेमाल करता है, अब updated documentation ज़रूरी मानी जाती है
पहले इसकी priority कम थी, लेकिन अब यह model quality को सीधे प्रभावित करती है
हालाँकि समय के साथ यह हिस्सा भी सुधरेगा
तब LLM के एक ही बार में सही implementation देने की संभावना बढ़ जाती है
यह लेख prompt companies की उथली engineering समझ दिखाता है
100% कवरेज सभी input combinations verify नहीं कर सकती
यह सिर्फ कुछ उदाहरणों से सभी lines को चला देने भर है
आखिरकार formal proof चाहिए, लेकिन उसकी लागत खगोलीय है और LLM वहाँ बेकार है
उल्टा test के ज़रिए responsive development environment बनाना एक नए golden age की शुरुआत कर सकता है
कवरेज में समस्या आए तो बाद में उसे बढ़ाया जा सकता है
शुरुआत से जितना हो सके उतना thorough test setup करना बेहतर है
पहले से ही proof assistant के साथ जोड़कर इस्तेमाल करने की कई कोशिशें हो रही हैं
भले spec में थोड़ी-बहुत गलती हो, फिर भी ज़्यादातर मामलों में काम का नतीजा मिल जाता है