AI को कम नहीं, बल्कि ज़्यादा engineering discipline की ज़रूरत है
(charitydotwtf.substack.com)- AI code generation की quality बेहतर हुई है, यह code review छोड़ देने का संकेत नहीं है; बल्कि ऐसे माहौल में जहाँ code सस्ता और तेज़ी से दोबारा generate किया जा सकता है, validation और operational discipline की और अधिक मज़बूत ज़रूरत होती है
- 2025 के अंत में Opus 4.5 के बाद, AI कम-से-कम सामान्य patterns में mid-level software engineer के क़रीब quality वाला code कहीं तेज़ और सस्ते में बना सकता है, और agentic harness, tool use, function calling, MCP ने इस बदलाव को सहारा दिया
- code production की लागत लगभग 0 के क़रीब आते ही, code lines अब संभालकर रखने वाली कीमती asset नहीं रहीं, बल्कि मौजूदा समझ को materialize करने वाला regenerable cache बनती जा रही हैं
- जैसे immutable infrastructure ने running servers को ठीक करने के बजाय replace करना सिखाया, वैसे ही AI युग के application code में changes से ज़्यादा behavior validation, characterization test, capture/replay, traffic splitting, observability अहम हो गए हैं
- non-deterministic systems, trace, production eval, fast feedback loop जैसे engineering discipline की माँग करते हैं; केवल इंसानों को quality gate बनाकर टिके रहने का तरीका काफ़ी नहीं है, और AI इस तथ्य को नहीं बदलता कि software को अब भी technologist और discipline की ज़रूरत है
2025 में उलटी हुई code production की economics
- 2025 के ज़्यादातर समय तक यह मानना तर्कसंगत और mainstream था कि AI-generated code “slop” है और शायद आगे भी ऐसा ही रहेगा
- 2025 के नवंबर में Opus 4.5 के बाद, AI कम-से-कम सामान्य patterns में mid-level software engineer जैसी quality का code बहुत तेज़ और कम लागत में generate करने लगा
- Opus 4.5 किसी एक कारण से ज़्यादा एक tipping point के क़रीब है
- agentic harness ऐसा code structure है जो LLM को tools के साथ loop में रखता है
- ऐसे harness 2025 के मध्य तक व्यावहारिक रूप लेने लगे, और इनके शुरुआती संकेत 2024 के अंत तक जाते हैं
- tool use, function calling, MCP 2025 भर परिपक्व होते गए और साल के अंत तक general-purpose usability तक पहुँच गए
- पहले बदलाव में “देखूँगा तब मानूँगा” जैसी शंका स्वीकार्य हो सकती थी, लेकिन जब उसी गति से बदलाव फिर दिख रहा हो, तो वही रुख बनाए रखना कठिन है
code कीमती asset से regenerable output में बदल रहा है
- 2025 में हुआ मूल बदलाव code production की economics का उलट जाना है
- code generate करना जो पहले कठिन, समय लेने वाला और महँगा था, वह लगभग तुरंत और सस्ता हो गया
- code lines reuse और care करने की चीज़ से हटकर discard करके फिर से बनाई जा सकने वाली चीज़ बन गईं
- software engineering teams के असली output को shared understanding मानने का भी एक नज़रिया है
- यह understanding लोगों के दिमाग़ में cache की तरह रहती है, और GitHub commits व production deploys के रूप में disk पर उतरती है
- लेकिन इंसानी याददाश्त भूलने वाली होती है, दोहराव से सुस्त पड़ती है, और छोटी details छूट जाती हैं
- दिमाग़ में बने models लगातार उस दुनिया से mismatch होते रहते हैं जिसका सामना users सचमुच करते हैं
- SRE नज़रिए से, अच्छी software teams का असली output production में होता है
- “Only prod is prod”
- production को development के बाद की जगह नहीं, बल्कि development के एक चरण की तरह treat किया जाना चाहिए
Phoenix Architecture और immutable infrastructure की समानता
- Honeycomb ने 2025 के अगस्त में AI mandate जारी किया, क्योंकि devtools company होने के नाते उसने माना कि उसे नई technology की कठिन समस्याओं से जूझना चाहिए
- Chad Fowler की Phoenix Architectures AI code युग को immutable infrastructure से जोड़ती है
- Chad Fowler वही व्यक्ति हैं जिन्होंने 2013 में “immutable infrastructure” शब्द गढ़ा था
- Relocating Rigor वह लेख है जिसका उल्लेख Martin Fowler ने Thoughtworks meetup summary में किया
- The Death and Rebirth of Programming का मूल सिद्धांत है: जो चल रहा है उसे ठीक मत करो, उसे replace करो
- immutable infrastructure, stateless services, containers, blue-green deployments, infrastructure as code — सब इसी साझा धारणा पर टिके हैं
- AI इस धारणा को infrastructure से application code तक बढ़ा देता है
- जब rewrite की लागत घटती है, तो in-place fixes ज़्यादा risky हो जाते हैं, mutation entropy जोड़ता है, और replacement उसे reset करता है
- The Deletion Test आपको पूरी implementation को delete करके सोचने को कहता है
- delete करने से डर इसलिए लगता है क्योंकि code की वजह से नहीं, बल्कि इसलिए कि ज़रूरी behavior, unacceptable failures, हमेशा बनाए रखने वाले invariants, और नई version की correctness को जाँचने के मानदंड साफ़ नहीं होते
- कौन-से bug fixes भूले हुए edge cases के लिए थे, यह न जानना भी उसी समस्या का हिस्सा है
- यह code की नहीं, evaluation की समस्या है
- जब code ही knowledge के रहने की एकमात्र जगह होता है, तब code कीमती बन जाता है
- पहले code बनाने की मेहनत ही bottleneck थी, इसलिए code को स्थायी asset की तरह treat करना तर्कसंगत था
- जब regeneration आसान हो जाए, तो code ऐसी समझ का materialized view बन जाता है जो अभी उपयोगी है, लेकिन पुराना होने पर फेंका जा सकता है
जैसे servers regenerate होते हैं, वैसे code भी regenerate होना चाहिए
- handcrafted server pets से immutable infrastructure cattle तक जाने का अनुभव यह सिखाता है कि mutability, understanding की दुश्मन है
- running artifacts को in-place ठीक करने से drift पैदा होता है
- drift systems को maintain करना कठिन बनाता है
- Honeycomb हर मंगलवार cron के ज़रिए सबसे पुराने Kafka node को मार देता है
- इस तरीके से उसे भरोसा रहता है कि bootstrapping और balancing process दोहराने योग्य हैं
- data regenerable है, और असली commitments कहीं और मौजूद हैं
- अगर code को भी इसी तरह regenerate नहीं किया जा सकता, तो यह संकेत है कि उस code को पर्याप्त रूप से समझा नहीं गया
- कौन-से commitments किए गए हैं, यह पता नहीं
- कौन-सी dependencies टूटेंगी, यह पता नहीं
- ज़्यादातर बातें तोड़कर ही पता चलती हैं
- लंबे और पीड़ादायक migration, rewrite, legacy code replacement, strangler fig ऐसे उदाहरण हैं जहाँ code lines पर बहुत ज़्यादा ज़िम्मेदारी लाद दी गई थी
- code के भीतर developer intent, user expectations, implicit और explicit behavior, और पुराने bugs के निशान सब एक साथ बँधे थे
review का विषय सिर्फ code lines नहीं हैं
- code lines को maintain और modify करने की लागत अधिक होने की वजह से दूसरे artifacts उतने विकसित नहीं हो पाए
- architecture कैसे बदल रही है, इसे समझने और इस पर चर्चा करने वाले artifacts कम हैं
- कई बार architecture ख़ुद code से बस धुँधले तौर पर infer की जाती है
- आदर्श दिशा यह है कि पहले architecture diagrams पर चर्चा और सहमति हो, फिर उन बदलावों से code को regenerate किया जाए
- यह मान लेना उचित नहीं कि सारा code human understanding को bypass करके AI सिर्फ spec के अनुसार generate कर देगा
- संभावनाओं की पूरी सीमा इस बात पर निर्भर करती है कि spec क्या है, या क्या हो सकती है
- जिसने भी painful database migration झेला है, वह जानता होगा कि user expectations को replayable और automatable रूप में extract व formalize करना कठिन है
- tools अभी मौजूद नहीं हैं, लेकिन संबंधित ideas पहले से हैं
- operations और QA से आए behavioral test, characterization test, capture/replay, traffic splitter इसके उदाहरण हैं
- ये techniques इस पर कम और इस पर ज़्यादा केंद्रित हैं कि “क्या सही होना चाहिए” नहीं, बल्कि “असल में क्या हो रहा है” को observe और encode किया जाए
- अच्छे अर्थ में observability भी इसमें शामिल है
इंसान validation के quality gate के रूप में उपयुक्त नहीं हैं
- production का non-deterministic code हमें वह करने पर मजबूर करता है जो पहले से किया जाना चाहिए था
- trace instrumentation
- production में test और eval
- production को development के बाद नहीं, development चरण की तरह treat करना
- इंसानी दिमाग़ validation के लिए उपयुक्त नहीं है
- बार-बार छोटे और मामूली फ़र्कों की जाँच करने में वह machines से कमज़ोर है
- अगर इंसानों की भूमिका सिर्फ quality gate क्षमता तक सीमित हो, तो software quality नाज़ुक हो जाती है
- creativity, inspiration, logical leaps जैसी चीज़ों में इंसानों की भूमिका लंबे समय तक बनी रह सकती है, लेकिन validation में machines से बेहतर निर्णायक के रूप में उन्हें रखना कठिन है
AI युग का निष्कर्ष: discipline की वापसी
- पिछले 2 वर्षों की AI चर्चा कई engineers को इसलिए अजनबी और डरावनी लगी, क्योंकि AI की कुछ आवाज़ें ऐसा कहती दिखीं मानो software अब engineering problem ही नहीं रहा
- “SaaS is dead”
- “Making AI great at coding was the strategy that unlocks everything else”
- Adam Jacob को software jobs में बड़े बदलाव की भविष्यवाणी करने वाले व्यक्ति के रूप में देखा जाता है
- अगर 2025 vibe coding का वर्ष था, तो 2026 discipline की वापसी जैसा दिखता है
- AI जब mid-level software engineer जितनी क्षमता से code lines generate करने लगता है, तो संभावित futures की सीमा अस्थिर ढंग से बहुत चौड़ी हो जाती है
- दिमाग़ के भीतर का knowledge तब तक AI के काम नहीं आता, जब तक वह systems में encode न हो जाए
- बहुत कम software teams तेज़ और छोटे feedback loops में काम करती हैं
- इसका अनुपात लगभग 5% बताया जाता है, और निश्चित रूप से 10% से कम
- AI tools इस तरीके को पहले से ज़्यादा सुलभ बना सकते हैं
- engineering discipline के बिना सिर्फ AI से बहुत बड़ा ROI आ जाएगा, निकट भविष्य में यह प्रमुख चिंता का विषय नहीं है
- कई teams कोशिश करेंगी, लेकिन असली value disposability से नहीं, durability से समर्थित होती है
- users यह नहीं चाहते कि हर दिन Slack में login करने पर buttons और menus हल्के-हल्के बदल जाएँ
- वे यह भी नहीं चाहते कि financial transactions सिर्फ ज़्यादातर मामलों में ही पूरे हों
- determinism ग़ायब नहीं होगा
- AI जादू नहीं है, और software अब भी engineering है
- technology को technologist की ज़रूरत रहती है
- आगे जिन artifacts की समीक्षा करनी होगी, उनका दायरा सिर्फ code lines से बढ़कर दूसरे engineering artifacts तक जाएगा
1 टिप्पणियां
Hacker News की राय
अब यह पहचानना बहुत कठिन हो गया है कि कौन सिस्टम को समझता है और AI का प्रभावी इस्तेमाल करता है, और कौन कुछ भी समझे बिना सिर्फ LLM से कॉपी-पेस्ट उगल रहा है
2025 से पहले कम प्रदर्शन करने वाले या बस टिके रहने वाले लोग अपेक्षाकृत साफ दिख जाते थे क्योंकि उनका योगदान कम होता था, लेकिन अब हर इंजीनियर भरोसेमंद दिखने वाले PR, code review, technical design docs वगैरह की बाढ़ ला रहा है
इसमें C-level का यह कड़ा दबाव भी बड़ा कारण है कि AI का अधिकतम इस्तेमाल करो, और हर इंजीनियर के नज़रिए से भी जितना हो सके उतना ज़्यादा निकालना फायदेमंद game-theoretic response है
हम दिखने में विश्वसनीय दस्तावेज़ों और कोड में पूरी तरह डूबते जा रहे हैं, और उस मात्रा को संभालने के लिए फिर से AI पर निर्भर हो रहे हैं
लगता है इस दौर का backlash पैमाने के लिहाज़ से खास तौर पर उभरने वाले एक अजीब तरह के technical debt में बदलेगा
LLM को बहुत कुछ बनाना और कुछ जोड़ते जाना पसंद है, लेकिन सचमुच सक्षम इंजीनियर कम code और कम moving parts के साथ ज़्यादा business outcomes देते हैं
मैं अक्सर सुनता हूँ: “हम process automate करने के लिए AI इस्तेमाल करना चाहते हैं, लेकिन process docs पूरी नहीं हैं, इसलिए उम्मीद है AI मदद करेगा”
मैं समझाता हूँ कि शून्य से नतीजा नहीं निकाला जा सकता, फिर भी हर AI चर्चा आखिरकार उसी दिशा में लौट जाती है
और उस AI automation में डालने के लिए दस्तावेज़ बनाने का समाधान भी AI ही बता दिया जाता है, तो यह ऐसा ouroboros बन जाता है जहाँ AI से docs बनाओ, AI से उन्हें summarize कराओ, और AI ही समझाए
code में भी यही होगा: AI से हज़ारों lines बनवाओ, फिर AI से ही समझवाओ
आजकल LLM की वजह से केवल output देखकर मेहनती दिखना बहुत आसान हो गया है
फर्क अब यह है कि अयोग्य व्यक्ति शाब्दिक रूप से सावधान और अनुभवी इंजीनियर से कई orders of magnitude ज़्यादा output पैदा कर सकता है
PR कोई परफ़ेक्ट gate नहीं है, लेकिन अभी हमारे पास बचे लगभग इकलौते gates में से एक है, और कौन मेहनत कर रहा है और कौन नहीं, यह काफी साफ दिखता है
interview stage के algorithm questions ने सिस्टम knowledge होने का दिखावा करने वालों को पूरी तरह छाँट ही दिया होगा, है न?
“यह code की समस्या नहीं बल्कि evaluation की समस्या है”, “code तभी मूल्यवान बनता है जब knowledge सिर्फ code के अंदर रहती है” — इस बात से सहमत हूँ
पूरे दिन AI द्वारा लिखा गया code पढ़ना कष्टदायक है, और यह उन पलों में दिमाग पिघला देने वाला भयानक तरीका है जब इंसान को सबसे सक्षम होना चाहिए
manual programming में एक उत्पादक और संतोषजनक feedback loop होता है: code पढ़ो, लिखो, compile या run करो, और जब तक मनचाहा behavior न मिले तब तक सुधारते रहो
AI code न सिर्फ उसका आधा हिस्सा अपने ऊपर ले लेता है, बल्कि आख़िर का वह “click” वाला क्षण भी कम संतोषजनक बना देता है। क्योंकि यह पक्का नहीं होता कि वहाँ पहुँचने के लिए कहीं कुछ हल्का-सा cheat तो नहीं किया गया
AI-generated code को programming का एकमात्र स्थायी output मान लेना इस industry की dead end है
Charity जिस चीज़ को दिलचस्प workspace और सही तरीके से फेंक देने योग्य मानती हैं, वह architecture diagrams और specs हैं
मेरा शक है कि यह इंसान द्वारा सीधे लिखे गए prompts, Markdown plans, और guide text के और करीब है
हमें उसी पर ध्यान देना चाहिए जो हमने इंसान के तौर पर खुद बनाया है, क्योंकि वही इस मूल loop की नींव है: “क्या AI ने मेरे निर्देशों का पालन किया?” और code review में भी वही ज़्यादा leverage देता है
जब तक आप PR तक पहुँचते हैं, तब तक शायद आपने Claude को इतना input दे दिया होता है कि वह code फिर से generate कर सके, लेकिन industry का मौजूदा default यह है कि पूरा session फेंक दो और सिर्फ code deploy करो। यह उल्टा है
code के बड़े ढेर का इंसान असल में review नहीं कर सकता, लेकिन LLM शामिल होते ही बहुत लोग यह बात भूल जाते हैं
हर दिन review के लिए code का विशाल ढेर आ जाता है, और यह सचमुच थका देने वाला है
फिर भी AI बेहतर लगता है, क्योंकि अगर नियम लिख दिए जाएँ तो वह कम-से-कम उनका पालन करने की प्रवृत्ति रखता है
offshore developers में से काफ़ी लोग वही गलतियाँ हर दिन दोहराते हैं
लगता है हमारी कंपनी को बेहतर offshore developers रखने चाहिए
पहले system के mental model का जो हिस्सा coding के ज़रिए बनता था, अब उसे बनाने के लिए हम code review पर निर्भर हो रहे हैं
system की details को समझना और याद रखना और कठिन होता जा रहा है, और यह सोचकर हैरानी नहीं होती कि जो जानकारी हम खुद “generate” करते हैं, वह सिर्फ पढ़ी गई जानकारी से बेहतर याद रहती है
मैं pedagogy से मिली सीख को code review scaling पर लागू कर रहा हूँ, और अगर यह बात आपसे resonate करती है तो इस पर बात करना चाहूँगा
एक अस्थायी उपाय के तौर पर Claude से session summary को commit message के हिस्से के रूप में लिखवाया जा सकता है, लेकिन जानना चाहता हूँ कि क्या इससे ज़्यादा structured और high-level tools मौजूद हैं
अगर आपको किसी अच्छी तरह designed plan के मुताबिक verifiable code चाहिए, तो असल में आपको pseudocode लिखकर AI से उसका translation कराना पड़ेगा
अगर ऐसा ही करना है, तो फिर शुरू से AI से code लिखवाने की ज़रूरत ही क्यों है, यह सवाल उठता है
व्यक्तिगत रूप से मुझे खुद plan करना, लिखना और debug करना ज़्यादा मज़ेदार लगता है। वही तो वह हिस्सा था जिसकी वजह से मुझे शुरुआत में programming पसंद आई थी
हाल में मैं इस बारे में सच में बहुत सोच रहा हूँ
software development को लेकर मेरी intuition का बड़ा हिस्सा 25 साल के उस अनुभव पर आधारित है कि “किसी code को लिखने में कितना समय लगता है”
जब मैं यह सोचता हूँ कि कोई edge case validation जोड़ूँ या नहीं, जो पूरी चीज़ को तोड़ती तो नहीं है लेकिन कोई उस पर ठोकर खाए तो थोड़ा messy हो सकती है, तो अगर उसमें कुछ घंटे extra code लगें तो शायद मैं उसे छोड़ दूँ
लेकिन अगर एक prompt से हो जाए, तो फिर क्यों न करूँ?
किसी नए feature को समझना आसान बनाने के लिए एक dedicated API explorer अच्छा होता, लेकिन पहले शायद उसके लिए निवेश को justify नहीं किया जा सकता था
लेकिन अगर Codex से वह 10 मिनट में हो जाए तो बात बदल जाती है, और वास्तव में ऐसा हुआ भी: https://tools.simonwillison.net/datasette-extras-explorer#ur... release notes में भी लिंक है https://docs.datasette.io/en/latest/changelog.html#extra-sup...
बड़े पैमाने पर भी ऐसे project हैं जिन्हें पहले मैं consider ही नहीं करता था। एक custom SQLite SELECT query parsing library की ज़रूरत तो थी, लेकिन उसके लिए एक हफ्ते से ज़्यादा देना सही नहीं लगता था
लेकिन अब यह संभव है: https://github.com/simonw/sqlite-ast
अगर आप कहें कि code की lines को तेज़ी से produce कर पाना value रखता है, तो लोग बहुत नाराज़ होते हैं और उसे तुच्छ समझते हैं
बेशक, output को “lines of code” से नापना बेवकूफ़ी है
लेकिन ऐसी verified code lines जो value deliver करती हैं उन्हें नापना बेवकूफ़ी नहीं है, और अब हम उसे ज़्यादा तेज़ी से कर सकते हैं
Google की value इसलिए है क्योंकि वह data को खींचकर ad revenue बनाता है, और revenue के मुकाबले उसका spend कम है
वे सारे “bets”? मज़ाक है, तो उनका क्या हुआ?
engineering for engineering का अर्थव्यवस्था के लिए कोई value नहीं है, यानी वह निरर्थक है
वह कड़वा सच जिसे कोई सुनना नहीं चाहता, यह है कि किसी भी समय की economy में सिर्फ वही चीज़ें मौजूद रह सकती हैं जो सीमित हों, value रखती हों, और आर्थिक रूप से sustainable हों; वही बचती हैं
बहुत से लोग परवाह नहीं करते, लेकिन कुछ करते हैं
यह लेख मुझे अच्छा लगा, और क्योंकि लगता है कि कई दूसरे कमेंट्स इससे सहमत नहीं हैं, मैं अपनी सोच लिख रहा हूँ
जब मैं किसी नए codebase पर काम शुरू करता हूँ, तो जितनी जल्दी हो सके उपयोगी contributor कैसे बनूँ? मैं सीधे लोगों और लोगों द्वारा लिखे गए docs की तरफ जाता हूँ
मैं देखता हूँ कि यह system मूल रूप से किस समस्या को हल करने के लिए बनाया गया था, इसका मूल design क्या था, सबसे बड़ी समस्या क्या रही है, और आज इसे कौन इस्तेमाल कर रहा है
यह जान लेने पर अंदाज़ा लग जाता है कि इसे इस तरह क्यों बनाया गया, और code पढ़ना बहुत आसान हो जाता है
इस blog post को भी काफ़ी लोकप्रियता मिली: https://blog.gpkb.org/posts/just-send-me-the-prompt/
Charity शायद बहुत पुराने problems को देखकर उम्मीद कर रही हैं कि नई technology कोई नया solution लेकर आएगी
मेरा नहीं मानना कि मौजूदा generation के tools ही AI software development की कहानी का अंत हैं
मेरा मतलब यह भी नहीं है कि design docs Claude code को देकर चले जाओ। design docs भी पूरी नहीं होतीं, इसलिए onboarding के दौरान लोगों से बात करनी पड़ती है, पुराने tickets और postmortems भी पढ़ने पड़ते हैं
production में हमें यह पसंद नहीं कि यह समझना मुश्किल हो कि infrastructure अपनी मौजूदा स्थिति तक कैसे पहुँचा, इसलिए अब हम infrastructure as code करते हैं
codebase में भी “यह अपनी मौजूदा स्थिति तक क्यों पहुँचा, यह समझना मुश्किल है” डिफ़ॉल्ट स्थिति होती है, और यह “Programming as Theory Building” से भी पहले से देखा गया problem है
इसलिए infrastructure की तरह, शायद software development भी ऐसे tools की तरफ बदलेगा जो “code अपनी मौजूदा स्थिति तक क्यों पहुँचा” इसे ज़्यादा साफ़ करें
नए codebase में जाते समय पहले लोगों और लोगों द्वारा लिखे docs देखना सही तरीका है, लेकिन बहुत-सी engineering teams में ऐसे docs होते ही नहीं
फ़ैसले किसी engineer के दिमाग़ में या ऐसे chats में लिए जाते हैं जो save नहीं होते, और specs या तो साफ़-सफ़ाई में delete हुए tickets की कुछ lines थीं, या tracking tool बदलने पर गायब हो गईं
codebase या feature का कोई map नहीं, कोई ADR नहीं, और observability भी न्यूनतम
आख़िर में सिर्फ code बचता है, इसलिए code पढ़कर समझना पड़ता है कि क्या हो रहा है, और किसी ऐसे engineer से पूछना पड़ता है जिसने उस हिस्से में हाल में commit किया हो कि क्या उसे याद है यह ऐसे क्यों किया गया
कोई एक बदलाव करता है और codebase के दूसरे छोर पर, जिसे आप बिल्कुल असंबंधित समझते थे, कुछ टूट जाता है
AI के साथ ज़्यादा discipline चाहिए, यह सही है, लेकिन सैद्धांतिक रूप से वह discipline एक अच्छे engineer बनने की तुलना में कहीं आसान सीखी जा सकती है
20 साल पहले अच्छा scalable C code लिखने के लिए या तो जीनियस होना पड़ता था, या technology के प्रति बहुत समर्पित
ASan, LSan, UBSan, TSan, GDB जैसे ढेर सारे tools हाथ की रेखाओं की तरह जानने पड़ते थे, और अगर DWARF files खुद पढ़नी पड़ें तो और भी बुरा
इन्हें कम समय में master करना व्यवहारिक रूप से कठिन था, और साथ ही system design भी सीखना पड़ता था, जो लगभग orthogonal एक अलग skill थी
अब बस यह जानना काफ़ी है कि आप जिस language और framework का उपयोग कर रहे हैं उसमें क्या pitfalls हैं, LLM को उन्हें test करने के लिए कहना है, यह जाँचने की infrastructure रखनी है कि उसने पर्याप्त testing की या नहीं, और फिर असली tests और implementation पढ़ लेने हैं
Rust को पढ़कर समझना, Rust development के दौरान आने वाली जादुई errors को debug करने से कहीं आसान है
यह पहचानना कि किसी scenario के लिए Loom tests चाहिए, और यह detect करने वाला tool बनाना कि वे सच में लिखे गए हैं या नहीं, यह भी आसान है
चाहे आप C या Zig ही इस्तेमाल करते रहें, हर tool को अलग-अलग सीखने से आसान यह है कि कब किसका उपयोग करना है यह जानें और उसे detect कर सकें
SQL पढ़ना मुश्किल नहीं है और लगभग आधे business लोग भी यह कर सकते हैं। Python बस थोड़ा ज़्यादा कठिन है, और Rust भी 50-page की reading guide देखकर समझी जा सकती है; trial and error में 10 साल लगाने की लागत की तुलना में यह बहुत छोटी कीमत है
“LLM ऐसे तरीक़े से काम करते हैं जिसे जाना नहीं जा सकता” से “इसलिए ज़्यादा discipline चाहिए” होते हुए “सब कुछ ठीक है” तक पहुँचने का रास्ता स्पष्ट नहीं है
मैं इस बात से सहमत हूँ कि सब कुछ ठीक है, लेकिन यह सोचने की प्रक्रिया मुझे कोई साफ़ रास्ता नहीं लगती
अगर किसी में चीज़ों को सचमुच काम कराने की इच्छा है, और थोड़ा समय लगाकर यह समझना चाहता है कि चीज़ें fail क्यों होती हैं, तो वह LLM का उपयोग करके बहुत बड़े काम कर सकता है
LLM जटिल चीज़ें बनाने की लागत लगभग मुफ़्त के क़रीब कर देते हैं, इसलिए वे हालात को उल्टा बहुत ज़्यादा जटिल बना देंगे
engineering हमेशा discipline और चीज़ों को काम कराने का काम रही है, लेकिन पहले मूल्यवान बनने के लिए पहले से कौशलों का एक set चाहिए होता था
उसका ज़्यादातर हिस्सा अब गायब हो चुका है, और चीज़ें पहले से बहुत आसान हो गई हैं
discipline अब भी चाहिए, लेकिन आग में 10 साल लुढ़कने की तुलना में discipline सस्ता है
मैंने अभी-अभी लगभग 200-line वाले इस PR की review करने में एक हफ़्ता लगाया: https://github.com/ncruces/wasm2go/pull/37
इसे एक अनुभवी user ने submit किया था, और संभव है कि उसने frontier LLMs से भी पूछा हो
फिर भी इसमें कुछ ग़लत-सा लगा। मैं इसे समझ नहीं पा रहा था, और बिना समझे इसे merge करने का मेरा कोई इरादा नहीं था
मुझे शक भी था कि यह ऐसे तरीक़े से ग़लत होगा जो आगे चलकर समस्याएँ पैदा करेगा
इसलिए मैंने इसकी चार तरह से review की: समझकर सुधारना, बेहतर algorithm से करना, upstream में problem ठीक करके इससे बचना, और अपने दिमाग़ के हिसाब से इसे शुरू से फिर लिखना
मुझे उम्मीद थी कि जवाब दूसरा या तीसरा होगा, लेकिन दूसरा भले सही जवाब था, उसे अपनाने के लिए project को शुरुआत से फिर करना पड़ता, और तीसरे के काम करने की मैंने सच में उम्मीद की थी, लेकिन वह नहीं हुआ
आख़िर में मुझे पहले और चौथे का मिश्रण करना पड़ा, और अभी भी मैं पूरी तरह आश्वस्त नहीं हूँ, लेकिन अब मैं problem और solution दोनों समझता हूँ
मुझे यह लगना स्वाभाविक है कि मेरा approach बेहतर है
फिर भी मैंने दोनों versions से comments हटाकर LLM से उनकी review करवाई
LLM ने जवाब दिया कि मूल PR साफ़ तौर पर बेहतर है, और जब मैंने समझाया कि ऐसा क्यों नहीं है, तो उसने कहा कि मैं सही हूँ
comments जोड़कर कोशिश करो तो LLMs कहते हैं कि मेरा वाला बेहतर है। क्योंकि मैंने असली problem ढूँढ ली थी
लेकिन मुझे नहीं पता कि वह यह इसलिए कह रहे हैं कि मेरा वाला सच में बेहतर है, या इसलिए कि मैंने उन्हें ऐसा कहने के लिए lead किया
यह पढ़कर लगा कि “सभी models गलत होते हैं” वाली कहावत को भुला दिया गया है
यह “realistic” “simulation” RPG पसंद करने वालों की भी एक आम गलती होती है
अगर आप किसी चीज़ को पर्याप्त व्यापक रूप से model कर दें, तो वह model बस वही चीज़ बन जाता है
किसी वास्तविक स्थान के हर विवरण को शामिल करने वाला location model बनाने के लिए 1:1 scale model चाहिए होगा, और वह आखिरकार उस जगह की एक copy ही होगा
किसी system की functionality का 100% भरोसेमंद पुनरुत्पादन कर सकने लायक पर्याप्त plan, यानी model के लिए prompt, शायद उस system का source code ही होगा
मैं अक्सर सोचता था कि IT और programming का बड़ा हिस्सा बस अच्छी तरह समझे गए टुकड़ों को जोड़ना ही तो है
8 साल पहले मैं सोचता था कि LLVM को एक कहीं अधिक simple system से, और hand-tuned optimization को एक simple AI “optimizer” से क्यों नहीं बदला जा सकता
मुझे लगा था कि बस simple compiled code को “optimized” code में बदलने के लिए train कर देना चाहिए, लेकिन उस समय आम सहमति यही थी कि AI systems के लिए इतना reliably सही code बनाना कठिन है कि उन्हें उपयोग में लाया जा सके
अगर AI ऐसे low-level code को भी replace नहीं कर सकता, तो high-level problems तो स्वाभाविक रूप से उससे बहुत दूर होनी चाहिए थीं
लेकिन लोग high-level problems पर AI का उपयोग करते हैं
मेरा hypothesis यह है कि modern digital engineering का बड़ा हिस्सा plug and play है
मुझे याद है कि 2023 से पहले HN पर सब लोग lines of code कम करना ही सबसे ताकतवर senior indicator बताकर उसकी बहुत प्रशंसा करते थे
बस LLM-generated code की बाढ़ के उलट तैरकर race जीतने के लिए धारा बहुत तेज़ है
और मैं इस लेख की उस धारणा से भी सहमत नहीं हूँ कि LLM अच्छा code लिख सकता है
वह काम करने वाला code तो लिखता है, लेकिन ऐसा लगता है जैसे उसे Demogorgon ने लिखा हो, इसलिए देखकर थोड़ा मन खराब हो जाता है
वह बुरा है, लेकिन उस तरह बुरा है जिस तरह इंसान कभी नहीं लिखेगा
यह नए developer के लिखे spaghetti code को पढ़ने वाली असहजता से अलग है; यह वैसी घिन है जैसे पेट के भीतर कहीं Cthulhu का अंडा फूट रहा हो
मुझे याद है कि जिस कंपनी में मैं पहले था, वहाँ एक senior ने joining से लेकर manager बनने तक लगभग सिर्फ code हटाने का ही काम किया था
यह लेख पढ़ने में मज़ेदार नहीं था
अलग-अलग वाक्य या पैराग्राफ ठीक थे, लेकिन पूरे रूप में यह बिखरा हुआ लगा और, कहूँ तो, अर्थहीन भी
शब्द बहुत थे, लेकिन वास्तव में कहा बहुत कम गया था
उदाहरण के लिए, यह कहना कि 2025 में code production की economics उलट गई है, सही नहीं है
पहले अगर manufacturing process 3D printing की तरह सख्ती से additive थी, तो अब यह CNC milling जैसी subtractive प्रक्रिया के जुड़ जाने के ज़्यादा करीब है
जिस “shape” की ज़रूरत है वह ज़्यादा नहीं बदली, और अगर आप किसी खास tolerance की परवाह करते हैं, तो human effort भी नहीं बदला
बाज़ार जितनी माँग करता है, उतनी ही अब भी products को महत्व देना, reuse करना, maintain करना और curate करना पड़ता है
मैं इस बात से भी सहमत नहीं हूँ कि “lines of code review करने के लिए आदर्श output नहीं हैं”
यहाँ “आदर्श” से मतलब क्या है?
बचपन में हर परीक्षा में नियम होता था, “अपना काम दिखाओ”
वजह यह थी कि लक्ष्य केवल कल ship होने वाला product नहीं, बल्कि अगली पीढ़ी के mental models और thought process को बेहतर बनाना भी था
भाषा के साथ बने रहना सच में मुश्किल था और लेख की core point भी नज़र नहीं आ रही थी
ऐसे लेख देखकर मुझे यह दावा और भी संदिग्ध लगता है कि software engineering jobs गायब हो जाएँगी
2026 का software engineer का काम 2020 से भी अलग है, और 1990 से तो तुलना ही नहीं, फिर हमें यह झूठा द्वंद्व क्यों मान लेना चाहिए कि 2026 का काम या तो जस का तस रहेगा या पूरी तरह खत्म हो जाएगा?
बहुत पहले जब मैं Google में काम करता था, तब हर code review होने का विचार मेरे लिए नया था
उससे पहले MS में code CD पर burn होकर box में चला जाता था, इसलिए project के अंत के उस high-risk बिंदु तक ज़्यादातर चीज़ों का review नहीं होता था
2000 से 2004 के बीच software engineers अपना समय कैसे लगाते थे, यह बहुत तेज़ी से बदला, और मुझे लगता है यह बेहतर हुआ क्योंकि इससे shared understanding बढ़ी और collaboration को बढ़ावा मिला
अगर AI code लिखे और इंसान review पर ज़्यादा समय लगाए, तो यह पूरी तरह बुरी बात नहीं हो सकती
लेकिन अगर AI code काफ़ी अच्छा हो गया, तो thorough review को optional समझा जाने लगेगा
तब software engineer का काम पहले से बहुत अलग हो जाएगा, और न वे इतना code लिखेंगे न review में इतना समय देंगे
IDE शायद dodo की तरह गायब भी हो सकता है
फोकस goals और tests set करने पर शिफ्ट हो सकता है ताकि AI coding team काम से भटके नहीं
जो software engineer अच्छी तरह जानता हो कि project कहाँ जा रहा है, वह architecture पर ज़्यादा समय दे सकता है, क्योंकि जब target उचित रूप से बदलता है तो आप नहीं चाहेंगे कि AI हर बार चीज़ें फिर से लिखता रहे
exploration पर भी ज़्यादा समय लगाया जा सकता है: एक तरीके से बनाना, फिर दूसरे तरीके से, फिर तीसरे तरीके से, उसके बाद तुलना करना, और अलग-अलग approaches से नए ideas निकालना
मेरे पास किसी से बेहतर भविष्यवाणी नहीं है, लेकिन मैं इस बात का मज़बूती से विरोध करता हूँ कि यह role गायब हो जाएगा, और इस विचार के पक्ष में हूँ कि यह evolve करेगा, जैसा कई बार पहले हो चुका है। बस शायद इस बार गति पहले से ज़्यादा तेज़ हो
“code को स्थायी चीज़ की तरह इसलिए माना गया क्योंकि code produce करने वाला labor bottleneck था” — मुझे यह सही नहीं लगता
code को स्थायी मानने की वजह यह थी कि code को source of truth माना जाता था
computer documentation नहीं, code execute करता है
अगर requirements document code से टकराता है, तो default यही माना जाता था कि requirements document गलत है
आप code को specification से अलग नहीं कर सकते। code ही specification है