Coding agent ने मेरे इस्तेमाल किए जाने वाले सभी framework की जगह ले ली
(blog.alaindichiappari.dev)> "Software engineering वापस आ गया है"
- frontier AI model और coding agent की प्रगति के साथ automated programming का युग शुरू हो रहा है, जिसमें कोड को पंक्ति-दर-पंक्ति हाथ से टाइप करने का काम गायब हो रहा है और software engineer फिर से मूलभूत design और सोच पर ध्यान दे सकते हैं
- पिछले साल के अंत से tools और models की maturity नाटकीय रूप से बढ़ी है, जिससे अच्छी तरह से व्यवस्थित environment में architect की भूमिका पर केंद्रित रहते हुए भी ज़रूरत पड़ने पर सीधे हस्तक्षेप कर सुधार करने वाला workflow संभव हुआ है
- web, mobile और desktop development में जमा हुई अनावश्यक framework और abstraction layer की परतें वास्तविक जटिलता को हल नहीं कर सकीं, बल्कि उल्टा समस्याएँ बढ़ाती रही हैं
- framework जिन तीन समस्याओं को हल करने का दावा करते हैं—simplification, automation, labour cost reduction—उनमें automation ही एकमात्र वैध मूल्य था, लेकिन AI automation अब इसे भी बदल सकता है
- Google, Meta, Vercel जैसे hyperscaler द्वारा डिज़ाइन किए गए system के operator बनकर रह जाने के बजाय, अपनी खुद की design और product बनाने वाली असली engineering की ओर लौटना चाहिए
automated programming का उदय
- Antirez द्वारा दिया गया "automated programming" वाला framing, "vibe coding" की तुलना में सार को कहीं बेहतर पकड़ता है
- printing press, loom और assembly line की तरह automation ऐतिहासिक innovation का केंद्र रहा है, और यह बदलाव भी उसी निरंतरता का हिस्सा है
- 2025 के दिसंबर के बाद frontier model और coding agent की क्षमता में नाटकीय बदलाव आया है, और जो लोग ध्यान से देख रहे हैं उनके लिए यह पहले से स्पष्ट है
engineer की भूमिका में बदलाव
- architecture, trade-off, product decision, edge case जैसे गहरी सोच की मांग करने वाले काम अब भी बने हुए हैं
- जो चीज़ गायब हुई है, वह है हर code line को खुद टाइप करने वाला थकाऊ और खर्चीला manual work
- साफ़-सुथरे और पूरी तरह व्यवस्थित environment में model और tools का उपयोग करके, ईंटें खुद लगाए बिना भी architect की भूमिका निभाई जा सकती है
- इसके पीछे 20 साल तक सीधे code लिखने का अनुभव होना चाहिए, ताकि कुछ पसंद न आए तो आप खुद अंदर जाकर समझ सकें, सुधार सकें और फिर configuration अपडेट कर सकें
- ज़रूरी tools तुरंत बनाए जा सकते हैं, इसलिए कल्पित तकनीक को वास्तविकता में बदलने में अधिक समय दिया जा सकता है
framework और अनावश्यक जटिलता
- web, mobile और desktop development में वर्षों से framework, library और tooling का भारी प्रदूषण जमा होता गया है
- ऐसे abstraction layer की परत-दर-परत जमावट हुई है जो किसी सार्थक चीज़ को abstract नहीं करतीं; वे एक समस्या हल करने का दावा करती हैं, लेकिन दस नई समस्याएँ पैदा कर देती हैं
- पूरे industry ने software निर्माण की असली जटिलता के सामने अपनी सोच को तेज़ करने के बजाय, तैयारशुदा सोच खरीदने का रास्ता चुना
- यह टूटी हुई टांग को रेशम से लपेटने जैसा है; बाहर से अच्छा दिखता है, लेकिन टांग अब भी टूटी हुई है
framework जिन तीन समस्याओं को हल करने का दावा करते हैं
- "simplification": engineer का खुद design करने से डरना और दूसरों की संरचना को आँख मूंदकर स्वीकार कर लेना
- लक्ष्य से उल्टी दिशा में design करने के बजाय, one-size-fits-all design को हर जगह लागू कर देना
- यह simplification नहीं, बल्कि intellectual surrender है
- automation: boilerplate code हटाना ही इसका एकमात्र स्वीकार्य मूल्य था
- ORM, CRUD management, code generation, API documentation जैसी दोहराव वाली लेकिन ज़रूरी गतिविधियों का automation
- लेकिन ठीक इसी जगह AI सब कुछ बदल रहा है
- labour cost: conference slide पर न दिखने वाला शांत कारण
- अगर Google, Meta, Vercel यह तय करें कि product कैसे बनेंगे और code कैसे deploy होगा, तो software engineer की जगह "React developer" को hire किया जा सकता है
- बिना training, plug-and-play, और आसानी से बदले जा सकने वाले cog जैसे workforce
- यह engineering नहीं, बल्कि operating है
नए कार्य-तरीके की वास्तविकता
- 2 साल से अधिक समय से इस तरीके से लगभग बिना दोष के development किया जा रहा है, और असली क्रांति पिछले साल दिसंबर से शुरू हुई
- अब अनावश्यक जटिलता हटाकर idea-केंद्रित जटिलता पर ध्यान देने का अवसर खुला है
- boilerplate हटाने की लागत लगभग 0 के करीब, और एक ही code को दो बार लिखने की ज़रूरत नहीं
- समस्या के बिल्कुल अनुरूप purpose-built छोटे tools तुरंत बनाए जा सकते हैं
- किसी चमकदार monorepo manager के बिना भी साधारण Makefile 99% use case को पूरा कर सकता है
- जब समस्या वास्तव में बहुत जटिल हो जाए, तब उसके बारे में सोचना; उससे पहले कभी पहले से हल करने की कोशिश न करना ही engineering है
- conference stage पर किसी के यह कहने से नहीं कि कोई समस्या कभी भविष्य में आएगी, बल्कि अभी मौजूद समस्या को हल करना ज़रूरी है
Bash और बुनियादी tools की पुनर्खोज
- agent उन basic tools में बेहद सक्षम हैं जो दशकों से मौजूद हैं
- Bash 1989 में बना था, और आज का सबसे साधारण model भी Bash को दुनिया के किसी भी व्यक्ति से बेहतर जानता है
- coding agent जटिल और महंगे MCP configuration से हटकर Bash-आधारित सरल agent loop की ओर बढ़ रहे हैं
- सबसे पुराने tools ही सबसे अधिक future proof हैं
framework पर निर्भरता की लागत
- ज़्यादातर use case में किसी महंगे और त्रुटिपूर्ण framework तथा उससे जुड़ी library की ज़रूरत नहीं, जिनकी सिर्फ 10% functionality ही इस्तेमाल होती है
- maintenance, security update, design constraint जैसी अदृश्य लागतें बहुत बड़ी होती हैं, और यह developer की स्वतंत्रता सीमित करती हैं
- अगर इस trade-off को लगातार स्वीकार किया गया, तो दशकों में आई सबसे बड़ी opportunity खो दी जाएगी
- Google, Meta, Vercel जैसी बड़ी कंपनियों की design philosophy के अधीन हो जाने वाली संरचना से सावधान रहना चाहिए
- developer को अपनी सोच और aesthetic sense पर भरोसा करना चाहिए, और अपने tools और product खुद बनाने चाहिए
> “टूटी हुई टांग को रेशम से मत लपेटिए, अपनी सचमुच की चीज़ खुद बनाइए”
- developer को अपनी सोच और aesthetic sense पर भरोसा करना चाहिए, और अपने tools और product खुद बनाने चाहिए
5 टिप्पणियां
यही तो सच में ऐसा डेवलपमेंट मेथडोलॉजी है जो maintenance को मुश्किल बना देती है। AI युग के हिसाब से नए दौर में अपनी जगह जीवनभर सुरक्षित रखने का तरीका अमल में लाने वाले व्यक्ति हैं।
“ज़्यादातर use cases में सिर्फ 10% फीचर्स इस्तेमाल होने वाले महंगे और खामियों से भरे framework और सहायक libraries” — इस बात से मैं सच में सहमत नहीं हूँ.. क्या प्रोजेक्ट के हिसाब से सही आकार का environment चुनना ही अच्छी प्रैक्टिस नहीं था? अगर लगता है कि बहुत ज़्यादा फीचर्स नहीं बनाने हैं, तो express जैसा हल्का विकल्प इस्तेमाल कर सकते हैं। क्या सच में express का विकल्प शुरू से ही खुद बनाना ज़रूरी है..
अगर कहना ही हो कि फीचर्स बहुत हैं लेकिन इस्तेमाल कम होता है, तो बल्कि Apache या nginx जैसे web server उस पर ज़्यादा फिट बैठते हैं; लेकिन क्या उन्हें भारी कहकर लोग web server शुरू से बनाते हैं? नहीं, बस configure करके इस्तेमाल करते हैं।
Framework जैसे अच्छी तरह व्यवस्थित और AI द्वारा खूब सीखी गई सामग्री मौजूद है, तो क्या सच में मुझे अपना बिल्कुल नया कुछ बनाने की ज़रूरत है? उल्टा यह productivity घटाने वाला काम लगता है.
मुझे नहीं लगता कि उस चीज़ को फिर से छोड़ने की ज़रूरत है, जिसने architecture बनाने की लागत कम की और हमें मूल बात यानी service पर फोकस करने लायक बनाया.
उम्... क्या ऐसी प्रैक्टिस तब की नहीं है जब Cursor अनलिमिटेड usage देता था...? बल्कि कम से कम फिलहाल तो आगे की दिशा यह लगती है कि टोकन कैसे बचाए जाएँ और AI की अच्छी तरह मदद कैसे ली जाए।
महंगे token price के बिना भी duplication हटाया जा सकता है, तो framework न इस्तेमाल करने की क्या वजह है?
Hacker News की राय
लगता है निकट भविष्य में बहुत से developers और companies को AI की दिखावटी हवा की वजह से बड़ा झटका लगेगा
अभी AI से बहुत कुछ बनाया जा सकता है, लेकिन असली समस्या वे हिस्से हैं जिन्हें सीधे टकराए बिना समझा नहीं जा सकता
आखिरकार सिर्फ़ ‘vibe coding’ करने वाले लोग वास्तविक सीमाओं से टकराएँगे, और वही लोग बचेंगे जो system के सचमुच काम करने का तरीका समझते हैं
2 मिनट में bug fix करके merge भी किया जा सका, और “system को समझना” तथा “खुद code न लिखना” ये दोनों बातें साथ-साथ संभव हैं
AWS इस दिशा में बहुत बड़ा दांव लगा रहा है, और non-deterministic tools जैसे-जैसे ज़्यादा स्थिर हो रहे हैं, उनके human-level quality से आगे निकलने की संभावना भी बड़ी है
समझ के बिना काम सौंपने पर output की accuracy, maintainability या scalability की गारंटी नहीं दी जा सकती
लेकिन अगर ऐसे लोगों के साथ काम करना पड़े, तो यह सवाल उठता है कि उन्हें और उनके LLM subscription fee को देने के लिए लाखों डॉलर क्यों खर्च किए जाएँ
हाँ, ‘vibe coding’ से बनी apps के टूटने के उदाहरण आएँगे, लेकिन जो teams testing, version control और documentation साथ लेकर चलेंगी, वे उल्टा और ज़्यादा फलेंगी-फूलेंगी
आखिर में संतुलित approach ही महत्वपूर्ण है
हो सकता है किसी दिन ‘de-slopper bot’ भी आ जाए
frameworks इस्तेमाल करने की वजह यह है कि उनके designers मुझसे ज़्यादा समस्याओं और scale issues से गुज़रे हैं
project की शुरुआत में सब आसान लगता है, लेकिन scale बढ़ने पर redesign बहुत दर्दनाक होता है
ऐसे लेख पढ़ते समय अक्सर लगता है कि खुद लेख भी LLM ने लिखा होगा
‘ईंटें काटकर सिलने’ जैसी उपमा उल्टा उसी विरोधाभास को दिखाती है
पूरा stack खुद बनाना अब भी अक्षम है, और maintenance cost बहुत ज़्यादा है
हाँ, अब फर्क यह है कि समस्या के हिसाब से custom components आसानी से बनाए जा सकते हैं
कुछ नया सीखने की ज़रूरत नहीं, familiar frameworks से ही काम चल जाता है
मेरी समस्या, platform की समस्या, और framework को bypass करने की समस्या
code लिखने के दर्द की बात करने वाला लेख अजीब लगता है। coding तो उल्टा आसान हिस्सा है
अगर Tolkien ने AI इस्तेमाल किया होता, तो शायद वह prompts को तराशने में ही समय बर्बाद करते
खासकर जितना कठिन हिस्सा हो, AI की मदद उतनी ही ज़्यादा नुकसानदेह हो सकती है
लेकिन AI पर लिखते समय कहा जाता है कि “AI code लिख देगा तो सोचने पर ध्यान दे सकेंगे”
अगर वही लोग यह दोनों बातें कह रहे हैं, तो यह विरोधाभासी है
आजकल Claude Code को दे दो तो ज़्यादातर मामलों में वह कुछ ही मिनटों में ठीक कर देता है
लेकिन मैं अपने लिखे code पर ज़्यादा भरोसा करता हूँ। आखिरकार speed से ज़्यादा समझ की गहराई महत्वपूर्ण है
Warhol की तरह अगर कोई नए tools का अच्छा इस्तेमाल करे, तो वह भी कला है
LLM रचनात्मकता के शुरुआती चरण में मदद करने वाला tool भर है, प्रतिभा अब भी इंसान से ही आती है
Node.js security patch को झंझट समझना गलतफ़हमी है
वह विशेषाधिकार है। खुद बनाए गए solution के पास न security community होती है, न कम vulnerabilities
React developers आसानी से मिल जाते हैं, लेकिन “AI से बना proprietary framework” developer नहीं मिलता
यह कोई बहुत बड़ी बात नहीं है
coding agents और frameworks के बीच का एक मध्य बिंदु मौजूद है
मैं अब भी वही tools इस्तेमाल करता हूँ, लेकिन repetitive काम agent करता है
और मैं architecture और edge cases पर ध्यान देता हूँ
agents को नज़रअंदाज़ करना भी, और उन पर अंधा भरोसा करना भी, दोनों अतिशय हैं
असली skill यह जानने में है कि steering wheel कब अपने हाथ में लेना है
इस लेख की समस्या यह है कि यह frameworks और ‘real engineering’ को एक-दूसरे के विरोध में रखता है
Vercel, Next.js, Firebase जैसी platforms instant deployment और CI/CD को संभव बनाती हैं
Jenkins के ज़माने को याद करें, जब यह सब खुद setup करना पड़ता था, तो यह सचमुच क्रांतिकारी है
असली engineering का मतलब ‘फिर से आविष्कार’ नहीं, बल्कि ग्राहक तक तेज़ी से पहुँचाना है
AI द्वारा मौजूदा frameworks को battle-tested हुए बिना दोबारा implement करना अक्षम है
ecosystem और common patterns न हों तो collaboration कठिन हो जाता है
अनुभवहीन developers का AI का गलत इस्तेमाल करना कोई नई बात नहीं है
खुद बनाने पर documentation, middleware, maintenance सब खो जाते हैं
वे अभी इस स्तर पर हैं कि “API को जोड़ा जा सकता है” यह फिर से खोज रहे हैं
लेकिन ऐसी खोज अपने-आप trade-offs की समझ नहीं लाती
मैं पिछले 6 महीनों से Cursor + Opus 4.x के साथ embedded development कर रहा हूँ
LLM सिर्फ़ software ही नहीं, बल्कि circuit design, CAD, CNC में भी मदद करता है
उदाहरण के लिए, ST7789 आधारित display के लिए wrapper function मैंने सिर्फ़ तीन prompts में पूरा कर लिया
अब LVGL, TinyUSB, compression, encryption के अलावा मैं लगभग कोई library इस्तेमाल नहीं करता
LLM द्वारा बनाए गए purpose-built functions छोटे, तेज़ और बेकार abstraction से मुक्त होते हैं
मुझे लगता है कि अब बहुत-सी libraries के हटने का समय आ गया है
.NET जैसी चीज़ें replace नहीं की जा सकतीं, लेकिन general-purpose function collections को काफ़ी हद तक बदला जा सकता है
और उसने double frame buffer समेत पूरा code तुरंत दे दिया
coding का कठिन हिस्सा typing नहीं, बल्कि लोगों के साथ collaboration, testing, और design thinking है
हाल में सबसे मुश्किल काम lock-free data structure design करना था
LLM के दौर में frameworks की value और भी बढ़ जाती है
LLM training data की वजह से React जैसे familiar patterns में मज़बूत होता है
यह भी महत्वपूर्ण है कि इंसान बीच में आकर debug कर सकता है
AGI आ भी जाए, तब भी efficient frameworks को दोबारा न सीखने की कोई वजह नहीं है
ऐसी बातचीत खुद में एक दिलचस्प प्रयोग है