अब code लिखना सस्ता है
(simonwillison.net)- code लिखने की लागत में आई तेज़ गिरावट पूरी engineering आदतों को हिला रही है
- पहले code बनाना महंगा था, इसलिए design, estimation और planning-केंद्रित efficient development culture विकसित हुई थी
- coding agents के आने से अब एक developer एक साथ कई काम—implementation, refactoring, testing, documentation—कर सकता है
- लेकिन ‘अच्छा code’ बनाना अब भी high quality standards और developer के judgment की मांग करता है
- इसके चलते नई व्यक्तिगत और organizational development habits बनाने की चुनौती उभर रही है
code लिखने की लागत में बदलाव
- पहले सैकड़ों lines का clean और tested code लिखने में एक दिन या उससे ज़्यादा लग जाता था
- इसी वजह से developers सीमित समय और लागत के आधार पर features की value और priority तय करते थे
- project design, schedule estimation, feature planning—सब कुछ ‘coding time के efficient use’ के इर्द-गिर्द होता था
- coding agents के आने से code input की लागत तेज़ी से घट गई है, और पुराने निर्णय मानदंड डगमगा रहे हैं
- एक engineer कई agents को parallel में चलाकर एक साथ कई development tasks कर सकता है
- यह बदलाव पुराने समय बनाम value judgment structure की दोबारा समीक्षा करने पर मजबूर करता है
फिर भी महंगा है ‘अच्छा code’
- नया code बनाना लगभग मुफ्त के करीब हो गया है, लेकिन ‘अच्छा code’ बनाना अब भी महंगा है
- अच्छे code की शर्तें इस प्रकार हैं
- सही तरह से काम करे और बिना bug के अपना उद्देश्य पूरा करे
- verification process से गुज़रकर यह साबित करे कि code भरोसेमंद है
- उपयुक्त problem solving पर फोकस करे और error situations को predictably handle करे
- simple और minimal structure बनाए रखे ताकि maintainability और समझ बेहतर हो
- tests और documentation updated रहनी चाहिए
- भविष्य में बदलाव की संभावना को ध्यान में रखे, लेकिन अनावश्यक complexity न जोड़े
- accessibility, security, scalability, maintainability जैसी non-functional quality properties को पूरा करे
- coding agents इस प्रक्रिया के कुछ हिस्सों में मदद कर सकते हैं, लेकिन अंतिम quality assurance की ज़िम्मेदारी developer की ही रहती है
नई development habits की ज़रूरत
- agentic engineering environment में पुरानी development habits अब वैध नहीं रह गई हैं
- व्यक्ति और organization—दोनों को काम करने के नए तरीके और नए judgment criteria बनाने होंगे
- अभी पूरी industry में ऐसी best practices स्थापित की जा रही हैं
- सुझाया गया तरीका यह है कि जब भी लगे कि “समय बर्बाद होगा”, तब भी asynchronous agent sessions चलाकर experiment करके देखें
- सबसे खराब स्थिति में, 10 मिनट बाद देखकर पता चलेगा कि बस tokens की बर्बादी हुई
Agentic Engineering Patterns guide में इसकी जगह
- यह लेख Agentic Engineering Patterns guide के पहले chapter “Principles” का हिस्सा है
- अगले chapter में code understanding विषय के तहत Linear walkthroughs जारी रहता है
- इसके बाद Testing and QA section में Red/green TDD, First run the tests जैसे विषय शामिल हैं
- हर हफ्ते 1–2 chapters जोड़ने की योजना है; यह किताब जैसा है, लेकिन “guide” के रूप में तैयार किया जा रहा है
1 टिप्पणियां
Hacker News की राय
मुझे नहीं पता कि “कोड हमेशा महंगा था” कहना सही है या नहीं
असल में महंगी चीज़ कोड खुद नहीं, बल्कि उसके आसपास की पूरी प्रक्रिया थी — correctness सुनिश्चित करना, maintenance, टीमों के बीच coordination, long-term support आदि ही असली cost drivers थे
अगर testing या approval process ज़रूरत से ज़्यादा हो जाए, तो उल्टा process ही ज़्यादातर लागत खा जाता है
LLM ने short term में working code बनाने की लागत काफ़ी घटाई है, लेकिन long term में maintenance, security और testing का बोझ बढ़ भी सकता है
आख़िरकार सच में बदलाव आया है या नहीं, यह long-term data देखकर ही पता चलेगा
पहले कुछ सौ lines का code लिखना भी महंगा पड़ता था
2000s-शैली के SLOCount tool (WebAssembly version) में 256 lines का JavaScript डालकर देखा, तो उस समय के हिसाब से लगभग $6,461 की लागत का अनुमान आया
बेशक, उस संख्या को बस मज़े के लिए ही देखना चाहिए
अब मैं खुद काम करने से ज़्यादा, अपने काम को manage करने वाला self-manager बन गया हूँ
productivity पहले की तुलना में लगभग 2.5 गुना बढ़ी हुई लगती है
requirements gathering, design, testing, deployment, maintenance अब भी ज़रूरी हैं, और ज़्यादातर लागत maintenance phase में आती है
Amdahl’s law की तरह, coding cost लगभग शून्य हो जाए तब भी बाकी चरणों की लागत सीमा बन जाती है
समस्या यह है कि इंसानी स्वभाव की वजह से यह मुश्किल है
correctness, maintainability, performance जैसे quality factors ऐसे hidden costs हैं जो सिर्फ अनुभव से सीखे जाते हैं
मैं “कोड हमेशा महंगा था” वाले दावे से सहमत नहीं हूँ
दरअसल कोड इसलिए महंगा था क्योंकि हम ‘अच्छा code’ लिखने की कोशिश करते थे
अगर standards नीचे कर दिए जाएँ, तो generated code तेज़ और सस्ता होगा, लेकिन उसे वापस अच्छे code में बदलने की मेहनत अब भी उतनी ही है
agent coding का समर्थन करना है तो दूसरी दलील देनी होगी
जब खुद लिखते हैं, तो हर line के पीछे की वजह समझते हैं, लेकिन AI के बनाए code में हर statement को verify करना पड़ता है
पिछले एक महीने में ज़्यादातर काम agents से किया, और बार-बार ऐसे edge-case bugs आए जो इंसान शायद न बनाता
आख़िर में review cost इतनी बढ़ जाती है कि short-term gain गायब हो जाता है
लेकिन coding agents की वजह से वह लागत काफ़ी कम हो जाती है
fine-grained edits agent कर देता है, इसलिए बेहतर quality का code तेज़ी से बनाया जा सकता है
complexity जुड़ती जाती है, इसलिए शुरुआत में उसे ध्यान से संभालना सबसे सस्ता पड़ता है
अभी short-term gains बड़े हैं, लेकिन long term में noise 10 गुना भी बढ़ सकता है
LLM tactical programming, यानी तेज़ feature implementation, में खास तौर पर अच्छे हैं
इसलिए system-level complexity management और भी ज़्यादा महत्वपूर्ण हो जाता है
code generation उतना सस्ता है जितना लोग कहते हैं, लेकिन उसे valuable outcome में बदलने की skill ही असली काबिलियत है
Agentic engineering आख़िरकार सस्ते input को मूल्यवान output में बदलने की कला है
Agentic engineering सिर्फ software लिखना नहीं, बल्कि किसी खास समस्या को जल्दी हल करने वाले tools बनाना है
लेकिन समस्या हल हो जाने के बाद AI खुद में दिलचस्प नहीं रह जाता
बहुत से लोग AI को ही लक्ष्य बना लेते हैं, जबकि असली value problem solving में है
Alan Watts के शब्दों में, संदेश मिल जाए तो फ़ोन काट देना चाहिए
tool सस्ता हो जाने से अपने-आप value पैदा नहीं होती
design और structuring की क्षमता ही असली value है
आख़िर में decision-making की quality ही अहम है
funding value का प्रमाण नहीं है
मुझे “कोड हमेशा महंगा था” वाले दावे पर शक है
clean और tested code की परिभाषा ही अस्पष्ट है
testing ज़रूरत से ज़्यादा हो जाए तो लागत फट पड़ती है, और organizational approval processes भी बड़ा cost factor हैं
LLM short-term cost घटाते हैं, लेकिन long-term maintenance cost बढ़ सकती है
internship के दौरान मैं startup में सस्ते में काम करता था, लेकिन outages, data corruption, technical debt जमा होते गए
ऊपर से सस्ता लगता था, लेकिन hidden cost बहुत बड़ी थी
LLM की वजह से अब ऐसा लगता है कि अच्छी quality का code सस्ते में मिल सकता है, लेकिन मैं अब भी उसके साथ adjust कर रहा हूँ
अब v1 बनाना सस्ता है, लेकिन mature product के complex decisions अब भी महंगे हैं
software की economic value कोड में समाई हुई information में होती है
code लिखना बस उस information को map करने की प्रक्रिया है; information की quality ही असली value तय करती है
code जल्दी लिख लेने से information की quality बेहतर नहीं हो जाती
यह वैसा ही है जैसे consulting में slides जल्दी बना लेने से value पैदा नहीं हो जाती
implementation speed बहुत तेज़ हो जाए तो developer का mental model code से अलग होने लगता है
संबंधित लेख: Cognitive Debt by Simon Willison
क्योंकि refactoring को तेज़ी से बार-बार दोहराया जा सका
AI धीरे-धीरे context को बेहतर समझेगा, लेकिन उसी अनुपात में इंसान को अपना judgment छोड़ना पड़ेगा
जिस दिन machine intent को पूरी तरह समझने लगेगी, इंसान loop के बाहर धकेल दिया जाएगा
हर development methodology के केंद्र में यह तथ्य है कि requirements हमेशा बदलती रहती हैं
इसलिए अच्छा code वही है जिसे “बदलना आसान हो”
मौजूदा LLM agents ऐसा code बनाते हैं या नहीं, इस पर संदेह है
जब तक उन पर पूरी तरह भरोसा नहीं किया जा सकता, वे शायद prototype level तक ही सीमित रहेंगे
spec अस्पष्ट हो तो testing और value validation दोनों मुश्किल हो जाते हैं
tests होने पर भी लगभग 70% confidence ही होता है
यह सीधे coding करने से तेज़ है, और नतीजा maintainable code के रूप में आता है
अगर clean code और good practices स्पष्ट कर दिए जाएँ, तो पर्याप्त रूप से maintainable परिणाम मिलते हैं
आख़िर में बात वही है: Garbage in, garbage out
जैसा मैंने अपने लेख(The Final Bottleneck) में कहा था,
code लिखने की गति बढ़ी है, लेकिन उसके बाद के चरण साथ नहीं दे पा रहे
यह सिर्फ आदत का सवाल नहीं है; responsibility structures, language design, और पूरे system architecture को बदलना होगा
अगर productivity सच में 10 गुना बढ़ गई होती, तो अब तक startups बाज़ार उलट चुके होते
सिर्फ इसलिए कि कुछ संभव है, यह ज़रूरी नहीं कि वह किया ही जाए
AI evals(measure-first-optimize-last, ai-evals.io) जैसी approaches उसी दिशा में हैं
feature bloat कोई नहीं चाहता
code की हर line एक liability है
LLM के code उगलने वाले दौर में यह liability विस्फोटक रूप से बढ़ रही है
tool खुद बुरा नहीं है, लेकिन बिना ज़िम्मेदारी वाले programs द्वारा codebase rewrite करने की संरचना खतरनाक है
“code सस्ता है” का मतलब सिर्फ generation सस्ता होना है; deployment approval cost अब भी बहुत बड़ी है
अगर judgment step हटा दिया जाए, तो productivity gain नहीं बल्कि control gap पैदा होता है
सिर्फ इसलिए कि कुछ तेज़ है, उसे master key दे देना खतरनाक है
दोनों में से कोई भी सच में सस्ता नहीं हुआ है
मैं भी इस राय से लगभग पूरी तरह सहमत हूँ
code writing सस्ती हुई है, लेकिन review और verification cost अब भी बड़ी है
ख़ासकर million-line monorepo में testability बढ़ाना ही असली कुंजी है
ट्विटर जैसे overhyped माहौल में इस तरह की चर्चा संतुलन लाती है, इसलिए अच्छा लगता है
code churn आसान हुआ है, लेकिन quality verification नई चुनौती बन गई है
LLM द्वारा किए गए बड़े पैमाने के changes subtle failures पैदा करते हैं, और वह प्रवाह रुकता नहीं
code सस्ता नहीं है
token cost भी है, और असली cost structure अभी भी अनिश्चित है
revenue न रखने वाले startups GPU supply chain पर कब्ज़ा किए हुए हैं, इसलिए data की कमी है
LOC बढ़ने के साथ liability भी बढ़ती है
thought से execution तक की दूरी कम हुई है, लेकिन code अब भी ज़िम्मेदारी है
अभी subsidy की वजह से चीज़ें सस्ती हैं, लेकिन hardware, power, और staffing cost घटे तो यह और भी सस्ता हो सकता है