- vibe coding और agentic engineering को पहले code review और जवाबदेही के मानकों के आधार पर अलग माना जाता था, लेकिन coding agents की विश्वसनीयता बढ़ने के साथ वास्तविक production काम में इनकी सीमा धुंधली होती जा रही है
- vibe coding वह तरीका है जिसमें code को लगभग देखे बिना, मनचाहा नतीजा मिल जाए तो उसे स्वीकार कर लिया जाता है; यह personal tools के लिए उपयोगी हो सकता है, लेकिन ऐसे software के लिए जिसमें दूसरे लोगों की जानकारी और user experience जुड़ा हो, यह गैर-जिम्मेदाराना लगता है
- Claude Code जैसे agents JSON API endpoints, SQL queries, tests और documentation को बार-बार अच्छी तरह संभाल लेते हैं, जिससे generated code की हर पंक्ति की review न करने की स्थिति बनती है; और यह human teams से अलग, प्रतिष्ठा या जवाबदेही रहित किसी इकाई पर भरोसा करने का जोखिम पैदा करता है
- अब 100 commits, अच्छा README और पूरे tests वाला repository भी 30 मिनट में बनाया जा सकता है, इसलिए सिर्फ बाहरी रूप देखकर quality का आकलन करना मुश्किल हो गया है; असली कसौटी यह बनती है कि क्या किसी ने उस software को लगातार इस्तेमाल किया है
- AI tools software engineers के अनुभव की जगह नहीं लेते, बल्कि उसे बढ़ाते हैं; और जब code production की रफ्तार 200 lines per day से 2,000 lines per day हो जाती है, तो bottleneck design, validation, operations और वास्तविक usage की ओर खिसक जाता है
Vibe coding और agentic engineering की सीमा
- Heavybit High Leverage podcast Ep. #9 में AI coding tools पर चर्चा करते हुए यह दिखा कि vibe coding और agentic engineering वास्तविक काम में एक-दूसरे के और करीब आ रहे हैं
- इससे पहले Not all AI-assisted programming is vibe coding (but vibe coding rocks) में vibe coding और ज़िम्मेदार AI-assisted programming के बीच साफ़ अंतर किया गया था, और बाद वाले को बाद में agentic engineering कहा जाने लगा
- vibe coding की पहचान यह है कि user, जिसे programming का ज्ञान भी न हो सकता है, code को लगभग देखे बिना मनचाहा output माँगता है, और अगर वह चल जाए तो स्वीकार कर लेता है, नहीं तो दोबारा कहता है
- personal tools जैसे मामलों में, जहाँ bug का नुकसान केवल खुद को होता है, vibe coding उपयोगी हो सकता है; लेकिन जब ऐसा software बनाया जा रहा हो जिसमें दूसरे लोगों की जानकारी और user experience शामिल हो, तब यह गैर-जिम्मेदाराना लगता है
- agentic engineering वह तरीका है जिसमें एक professional software engineer security, maintainability, operations और performance जैसी सीमाओं को समझते हुए AI tools का अपनी क्षमता की चरम सीमा तक उपयोग करता है
- लक्ष्य कम quality वाले नतीजे को तेज़ी से बनाना नहीं, बल्कि उच्च गुणवत्ता वाले production systems को ज़्यादा तेज़ी से बनाना है
- समस्या यह है कि coding agents अधिक भरोसेमंद होते जाने के साथ, production-level काम में भी generated code की हर पंक्ति की review अब नहीं की जा रही है
भरोसा जो code review को छोड़ने पर मजबूर करता है
- Claude Code से JSON API endpoint बनवाना, SQL query चलवाना और result को JSON में output करवाना — इन सबके ठीक तरह से हो जाने को लेकर एक भरोसा बनने लगता है
- अगर उससे automated tests और documentation जोड़ने को भी कहा जाए, तो भी यह उम्मीद बनने लगती है कि output ठीक होगा, और इसी दौरान कई बार वास्तविक code की review नहीं की जाती
- अगर code की review नहीं की गई, तो उसे production में इस्तेमाल करना क्या ज़िम्मेदाराना है — यह अपराधबोध बना रहता है
- इसे बड़े संगठन में engineering manager रहते हुए दूसरी team के software को इस्तेमाल करने के तरीके जैसा भी देखा जा सकता है
- अगर दूसरी team image resize service देती है, तो आम तौर पर उस team द्वारा लिखी गई code की हर पंक्ति नहीं पढ़ी जाती
- documentation देखकर image resize करके देखा जाता है, फिर अपनी feature launch की जाती है
- bug या performance problem दिखने पर ही Git repository को देखा जा सकता है
- ज़्यादातर मामलों में उस service को आधे black box की तरह माना जाता है
- agents के साथ भी धीरे-धीरे वैसा ही व्यवहार होने लगता है, लेकिन human teams के विपरीत Claude Code के पास न professional reputation है और न accountability
- human teams पहले अच्छा software बनाकर reputation जमा सकती हैं, और उन पर यह दबाव रहता है कि खराब परिणाम उनकी professional reputation को प्रभावित करेगा
- Claude Code ऐसी reputation नहीं रख सकता, लेकिन simple और दोहराए जाने वाले कामों को पसंदीदा शैली में लगातार सही ढंग से संभालते हुए भरोसा ज़रूर बना रहा है
- इसमें विचलन का सामान्यीकरण जैसा तत्व है
- हर बार जब model बिना नज़दीकी निगरानी के भी सही code लिखता है, भरोसा बढ़ता है
- और बाद में किसी गलत क्षण में ज़रूरत से ज़्यादा भरोसा कर लेने का जोखिम भी साथ बढ़ता है
software का मूल्यांकन और कठिन हो गया है
- पहले GitHub repository में 100 commits, अच्छा README और automated tests हों, तो यह मान लेना आसान था कि project में काफ़ी मेहनत और सावधानी लगी है
- अब 100 commits, सुंदर README और code की हर पंक्ति को cover करने वाले tests वाला Git repository 30 मिनट में बनाया जा सकता है
- ऐसा repository ऊपर-ऊपर से किसी लंबे समय की मेहनत और सावधानी वाले project जैसा ही दिख सकता है
- वह वास्तव में उतना अच्छा भी हो सकता है, लेकिन सिर्फ़ दिखावे से पता लगाना मुश्किल है, और अपने project पर भी यही समस्या लागू होती है
- tests और docs की quality से भी ज़्यादा महत्वपूर्ण कसौटी यह है कि क्या किसी ने उस software को वास्तव में इस्तेमाल किया है
- चाहे परिणाम vibe coded ही क्यों न हो, अगर बनाने वाले ने उसे पिछले 2 हफ्तों से हर दिन इस्तेमाल किया है, तो वह उस output से कहीं अधिक मूल्यवान है जो लगभग चलाकर भी नहीं देखा गया और बस निकाल दिया गया
bottleneck code लिखने से हटकर दूसरे चरणों में जाता है
- जब एक दिन में 200 lines of code बनाने की स्थिति से 2,000 lines बनाने की क्षमता आ जाती है, तो software development lifecycle के दूसरे हिस्से टूटने लगते हैं
- मौजूदा software development lifecycle इस धारणा पर बना था कि एक दिन में कुछ सौ lines of code बनती हैं
- bottleneck में यह बदलाव केवल downstream चरणों को नहीं, upstream चरणों को भी प्रभावित करता है
- Jenny Wen की प्रस्तुति के अनुसार, मौजूदा design process इस धारणा पर आधारित है कि “design को सही बैठाना ही होगा”
- क्योंकि engineer को सौंपने के बाद अगर 3 महीने तक गलत चीज़ बनाई जाए, तो वह विनाशकारी होगा
- design एक महँगे काम की ओर ले जाता है, इसलिए व्यापक design process रखा जाता है
- लेकिन अगर build में 3 महीने नहीं लगते, तो गलत होने की लागत बहुत घट जाती है, और design process कहीं अधिक जोखिम ले सकता है
फिर भी software engineer career खत्म नहीं हुआ है — ऐसा क्यों नहीं लगता
- agents के साथ बातचीत ज़्यादातर लोगों को किसी समझ से बाहर “moon language” जैसी लगती है
- computer अब खुद code लिख सकते हैं, फिर भी software engineer career खत्म नहीं हुआ है — ऐसा न मानने की एक वजह यह है कि ये tools मौजूदा अनुभव को amplify करते हैं
- जिसे पता है कि वह क्या कर रहा है, वह AI tools के साथ बहुत तेज़ी से आगे बढ़ सकता है
- AI tools का जितना अधिक उपयोग होता है, उतनी बार यह पुष्टि होती है कि software बनाना अपने आप में बेहद कठिन है
- सारे AI tools उपलब्ध होने पर भी जो हासिल करना है, वह अभी भी कठिन ही रहता है
- Matthew Yglesias ने tweet में लिखा, “5 महीने बाद मुझे लगता है कि मैं vibecode नहीं करना चाहता. मैं चाहता हूँ कि professionally managed software companies AI coding assistance का उपयोग करके ज़्यादा, बेहतर और सस्ता software products बनाएँ और मुझे बेचें,” और इससे सहमति जताई गई
- इसे इस तुलना से समेटा गया है कि plumbing पर पर्याप्त YouTube videos देखकर शायद कोई अपने घर की plumbing खुद ठीक कर ले, लेकिन फिर भी plumber को hire करना ज़्यादा पसंद करेगा
SaaS और in-house development का जोखिम
- इस आशंका पर भी कि कंपनियाँ SaaS का उपयोग करने के बजाय अपना खुद का solution बना सकती हैं, वही कसौटी लागू होती है कि प्राथमिकता उस software को दी जाएगी जो वास्तविक उपयोग से साबित हो चुका हो
- personal projects में भी कम से कम कुछ hफ्तों तक खुद बनाने वाले द्वारा इस्तेमाल किया गया tool अधिक पसंद किया जाता है
- enterprise version में इसे ऐसे देखा जाता है कि अगर कोई CRM कम से कम दो अलग बड़ी कंपनियों द्वारा 6 महीने तक सफलतापूर्वक इस्तेमाल न किया गया हो, तो उसे अपनाना नहीं चाहेंगे
- जोखिम लेने से पहले ऐसा solution चाहिए जो वास्तव में काम करता हो, यह साबित हो चुका हो
1 टिप्पणियां
Hacker News की राय
vibe coding और LLM ने अनुशासनहीन engineering organizations या engineers बनाए नहीं हैं; इन्होंने सिर्फ मौजूदा समस्याओं को उजागर और तेज़ किया है
बहुत से engineers के code writing standards और practices ढीले हैं या बिल्कुल नहीं हैं, और बहुत सी teams के production environment में code deploy करने के मानदंड भी कमज़ोर हैं
यह कोई नया phenomenon नहीं है; इसका मतलब सिर्फ इतना है कि software development lifecycle में standards को कभी ठीक से न निभाने वाले individuals और teams अब बहुत ज़्यादा code बना सकते हैं और ideas को concretize करना उनके लिए आसान हो गया है
मैंने कभी किसी colleague को सिर्फ जल्दी code लिखने की वजह से अच्छा engineer बनते नहीं देखा
मेरे जानने वाले सबसे अच्छे engineers वे थे जिन्होंने अपने experience और careful judgment के आधार पर team के साथ महत्वपूर्ण insights साझा किए और system की direction को बेहतर बनाया
“Claude, एक system बना दो। लेकिन अच्छे से बना देना। धन्यवाद!”
पहले, जब codebase feature development के खिलाफ resistance दिखाने लगता था, तब हम बस तत्काल bottleneck ठीक करते थे और अगली resistance point तक टाल देते थे
features बनाते हुए कुछ हद तक refactoring करने का यही तरीका था, लेकिन frontier models उस “समस्या बनने वाले क्षण” को आगे खिसका देते हैं
क्योंकि वे दिए गए code pile को एक हद तक संभाल लेते हैं, इसलिए यह LLM द्वारा और regressions पैदा करने या requirements ज़्यादा miss करने के रूप में सामने आता है, लेकिन इंसान को काम ज़्यादा कठिन हुआ हो ऐसा कम महसूस होता है
फिर एक समय आता है जब चीज़ें इतनी टूट जाती हैं कि उन्हें ठीक करना पड़ता है, और पूरा codebase उन decisions की fractal layers बन चुका होता है जो मैंने लिए ही नहीं थे, इसलिए उसे सुलझाना कठिन हो जाता है
क्योंकि आप code को सीधे edit नहीं कर रहे होते, इसलिए “इसे इस तरह जोड़ने पर tension बढ़ेगी” वाला शारीरिक एहसास भी खत्म हो जाता है, और refactoring का breakthrough पकड़ना मुश्किल हो जाता है
code को कभी भी refactor किया जा सकता है, और agents को छोटे, modular pieces और files लिखने के लिए मजबूर किया जा सकता है
agent ने लिखा हो या इंसान ने, अच्छी engineering अच्छी engineering ही है
अभी भी कम से कम architecture को इंसान को समझना और lead करना होगा, और agents reconnaissance और suggestions में बहुत अच्छी मदद कर सकते हैं
अगर मैंने कुछ हफ्तों की progress मिस नहीं की है, तो AI ज़्यादा reliable नहीं हुई है; बल्कि इसकी errors और सूक्ष्म हो गई हैं
अगर code compile नहीं होता, तो उसे ढूँढना आसान है; और compile हो जाए लेकिन काम न करे, तब भी उसे एक हद तक ढूँढना आसान है
लेकिन अगर वह compile भी हो जाए और काम भी करे, फिर कुछ edge cases में गलत निकले, security vulnerabilities हों, या technical debt और questionable architecture decisions साथ ले आए, तो उसे पकड़ना बहुत कठिन होता है, और review burden बिल्कुल कम नहीं होता
उल्टा, plausible code का review करना स्पष्ट रूप से खराब code के मुकाबले मानसिक रूप से ज़्यादा थकाने वाला होता है
उससे पहले कई tests लिखवाइए, फिर check कीजिए कि code उनसे मेल खाता है या नहीं, और agent को code को सही तरह organize करने के लिए कहिए
लेकिन अभी ऊपर से आने वाला pressure इतना ज़्यादा है कि माहौल यह है कि इसे हर जगह व्यापक रूप से लागू करो, और अगर आप इसका विरोध करें तो यह बहुत निराशाजनक होता है और career पर भी बंदिश जैसा महसूस होता है, जिससे मानसिक थकान बढ़ती है
जैसे ही आप किसी स्पष्ट समस्या की ओर इशारा करते हैं, उतने ही workaround सामने आ जाते हैं, और उन workarounds में जल्द ही दूसरी समस्याएँ निकल आती हैं, जिससे लगातार नए solutions पैदा होते रहते हैं
एक समय के बाद यह सब machine के लिए machine जैसा काम लगने लगता है
बहुत सी companies में असली goal धुंधला हो गया है, और लगता है कि अब सिर्फ LLM itself ही बचा है
जो लोग company के future को दाँव पर लगाकर इस vision को implement कर रहे हैं, क्या उन्हें परिणामों से बच निकलने का कोई नरम exit मिल जाता है, या फिर rationality ही पूरी तरह छोड़ी जा रही है, मुझे नहीं पता
sound engineering principles से समस्याओं को कुछ हद तक कम किया जा सकता है, लेकिन cognitive load, developer time, money, और finite resources के हिसाब से असल efficiency gain क्या है, इस पर संदेह है
“अगर आप रोज़ 200 lines से 2,000 lines तक बनाने लगें, तो क्या टूटेगा?” — इस वाक्य में engineering output के metric के रूप में lines of code का इस्तेमाल करना शर्मनाक है
200 lines review करना और 2,000 lines review करना पूरी तरह अलग workload है
वही program मैंने अपने दिमाग से फिर बनाया और ChatGPT को सिर्फ search और autocomplete की तरह इस्तेमाल किया, तो वही result 1,500 lines में आ गया
effort का अंतर ईमानदारी से बहुत बड़ा नहीं था, लेकिन hand-written approach को यह फायदा मिला होगा कि पहले vibe coding version की वजह से मैं पहले से सोच चुका था कि मुझे बनाना क्या है
software review के input value के रूप में lines of code का उपयोग समझ में आता है
क्योंकि शाब्दिक रूप से हर line पढ़नी पड़ती है
बस developer productivity के अकेले metric के रूप में यह बहुत खराब है, और दिक्कत तब होती है जब इसे उसी तरह इस्तेमाल करने की कोशिश की जाती है
फिर भी यह लगभग अकेला ऐसा metric है जो अलग-अलग companies, teams, languages, और application contexts में तुरंत intuitively समझ आता है और तुलना योग्य है, इसलिए उपयोगी है
एक ही team एक ही product पर काम कर रही हो, तब भी 1,000-line change जल्दी खत्म हो सकता है, जबकि 1-line bug fix में कई दिन debugging लग सकती है
इसलिए PR, feature, या story points को context के बाहर compare करना कठिन है, और अगर industry-standard developer productivity metric संभव होता तो सब उसका उपयोग करते, लेकिन स्वभावतः यह कठिन है
ऐसी तुलना करते समय अगर हम मान लें कि context वही है, तो यह मदद करता है
उदाहरण के लिए, अगर किसी specific company के किसी specific product पर, specific tech stack और quality process के साथ काम करने वाली team ने कल N1 lines और आज AI के साथ N2 lines बनाई हैं, तो समय के साथ N1 और N2 का अंतर वास्तविक प्रभाव का एक approximation देता है
AI-assisted development productivity पर अधिक rigorous studies भी आमतौर पर उसी group में AI use से पहले और बाद के PRs की तुलना करने वाले A/B test-जैसे measurements का उपयोग करती रही हैं
मेरे हिसाब से फर्क pipeline की quality और strictness का है
vibe coding में आप एक या कुछ बार कोशिश करते हैं, result को हल्का-सा check करते हैं, और फिर उसके टूटने तक इस्तेमाल करते रहते हैं
यह हल्के proof of concept या low-risk personal, family, या small-team apps के लिए उपयुक्त है
agentic engineering functional correctness, performance, infrastructure, resilience/availability, scalability, और maintainability जैसी व्यापक चिंताओं का ध्यान रखती है
इसमें workflow manage करने वाली multi-stage pipeline होती है, और project intake, selection, specification, epic breakdown, story breakdown, coding, documentation, deployment जैसे चरण हो सकते हैं
हर चरण में test pass या performance thresholds जैसे decisive quality gates होते हैं, साथ ही business value, specification completeness, code elegance, और ubiquitous language की strictness और simplicity जैसी adversarial review भी शामिल होती है
यह भी एक slider है
कभी-कभी आप किसी feature को deploy करने के लिए interviews करना, tokens जलाना, तीन adversarial reviews, value estimation, और detailed specification नहीं करना चाहते, और बस ticket system में डाल देना चाहते हैं
मैं रोज़ Opus, GPT-5.5, और छोटे models का उपयोग करता हूँ, लेकिन पूरा काम उन्हें नहीं सौंपता
specification को define और refine करने में अच्छी-खासी मेहनत करने के बाद भी, वे अब भी बहुत सी बेवकूफी भरी चीज़ें कर देते हैं जिन्हें मैं human PR review में pass नहीं होने देता
अगर मैं output पर भरोसा कर लेता या एक बड़ा agent pipeline बनाकर false sense of security हासिल कर लेता, तो शायद उन्हें codebase में बस बह जाने देता
10 साल बाद चीज़ें बेहतर हो सकती हैं, लेकिन आज की vibe coding और agentic engineering pipelines दोनों ही LLM को पूरा काम सौंप देने वाले एक ही theme की variations लगती हैं
आज सुबह भी लगा था कि single file में Opus on Max को changes दे सकता हूँ, लेकिन लगभग हर turn पर उसने या तो गलती की या कुछ miss किया, जिसे मुझे ठीक करना पड़ा
उसका सुझाया code शायद काम कर जाता, लेकिन वह बहुत complex था, और जिन हिस्सों को मैं पहले ही हाथ से simplify कर चुका था, उन्हें फिर से regress कर गया
जब यह चीज़ हज़ारों agent commits पर multiply होती है, तो codebase तेज़ी से खराब होता जाता है
design, testing, और review जैसी सही process के बिना build करने की कोशिश करने पर development teams मुश्किल में पड़ती हैं
agent coding से पहले भी ऐसा था, लेकिन अब खास तौर पर ज़्यादा है, और जो teams इस process में agents का उपयोग करना समझ जाएँगी, वे सबसे सफल होंगी
क्या आपने यह महसूस नहीं किया कि coding agents पहली कोशिश में solution के बहुत करीब पहुँच जाते हैं, लेकिन आख़िरी 10% या 5% सही करने में बहुत भारी काम लगता है
अगर आप problem approach बदल दें, तो agents उस gap को भर सकते हैं
10 साल पहले हम हर 10~15 मिनट में coding रोककर refactoring, testing, और analysis करते थे, ताकि यकीन हो सके कि सब सही है
क्योंकि bugs बाद के पूरे code को contaminate कर देते हैं
coding agents ऐसा कर ही नहीं पाते, और bug या गलत architecture को साथ लेकर आगे बढ़ते रहते हैं
instinctively तो मन करता है कि agents को बीच-बीच में रोकें, लेकिन कई वजहों से यह संभव नहीं है
उसकी जगह, क्योंकि cost बहुत सस्ती है, agent ने पहली गलती जहाँ की थी उसे ढूँढिए, prompt को ठीक कीजिए, और code edit करने के बजाय सब हटाकर शुरू से फिर चलाइए
prompt तब तक दोहराइए जब तक वह perfect code न दे दे
इस पर लोग कहेंगे कि इसमें भी इंसान को बहुत काम करना पड़ता है, लेकिन बात वही है
इंसान अभी भी ज़रूरी है, और अगर tool का उपयोग इस तरह किया जाए तो code writing speed 10x हो जाती है
“कुछ ऐसा जो काम करे” जल्दी बन जाता है, लेकिन दूसरे विकल्पों को evaluate, refine, और test करके confidence बनाने में लंबा समय लगता है
बात सही है, लेकिन boundary कहाँ है यह कोई नहीं जानता
आने वाला लगभग 1 साल सबके लिए वही दौर होगा जब वे इसे खोज रहे होंगे, और इसी वजह से “GitHub को फिर से reinvent करना होगा” जैसी बातें भी बहुत सुनने को मिल रही हैं
कई बार उस आख़िरी हिस्से तक mechanize करने के लिए निवेश करना आर्थिक रूप से सही नहीं होता
मुझे लगता है LLM providers ने शुरुआत से ही गलत approach चुनी
उन्हें labor replace करने पर नहीं, बल्कि labor augment करने पर focus करना चाहिए था, और लगता है उन्होंने यह महँगा सबक सीख लिया है
शायद शुरू से फिर शुरू करना बेहतर होता, लेकिन शुरुआत में मुझे पता ही नहीं था कि जो architecture चाहिए वह कैसा दिखना चाहिए
सिर्फ इसलिए कि LLM मौजूदा architecture में feature फिट करने में संघर्ष कर रहा है, आप पूरे working codebase को मिटाकर फिर से शुरू नहीं कर सकते
यह एक बेहतरीन लेख है, किसी ऐसे व्यक्ति का लिखा हुआ जो smart, humble, और लगातार सीखता रहता है
मुझे यह वाक्य पसंद आया: “मुझे डर नहीं है कि अब जब computer अपना code खुद लिख सकते हैं, तो software engineer career खत्म हो गया है। इसके कई कारण हैं। आंशिक रूप से इसलिए कि ये चीज़ें मौजूदा experience की amplifiers हैं। अगर आपको पता है कि आप क्या कर रहे हैं, तो आप बहुत तेज़ दौड़ सकते हैं।”
और यह हिस्सा भी अच्छा लगा: “इन tools का उपयोग करते हुए हमें बार-बार याद आता है कि हम जो काम करते हैं वह कितना कठिन है। software बनाना बेहद कठिन है। दुनिया के सारे AI tools दे दीजिए, तब भी यहाँ जो हासिल करना है वह अब भी सचमुच कठिन है।”
यह बात सही है कि upstream work भी साथ-साथ बदल रहा है
design-side tools खास तौर पर बहुत तेज़ evolve हो रहे हैं, इसलिए अब Figma side में रहने वाली translation cost उठाना शायद worthwhile नहीं लगता
डरावनी बात यह है कि codebase पर AI complexity की layers जमा होती जाएँगी, और इंसान code को समझना बंद कर देंगे, जिससे latest models के लिए भी उसे decode और change करना बहुत महँगा हो जाएगा
जल्द ही code reuse गायब हो सकता है, और हम पहिया बार-बार फिर से invent करने में पैसे जलाते रहेंगे
शुरुआती Android apps बनाते समय IDE का उपयोग अनिवार्य था, और एक button click के बाद “Hello World” notification दिखाने के लिए बेहिसाब boilerplate code लिखना पड़ता था, जिससे आत्मा निकलती हुई महसूस होती थी
मेरे साथ दोहराइए: ज़्यादातर software अपनी ज़िंदगी का अधिकांश समय maintenance phase में बिताता है
इसलिए software जो ज़्यादातर पैसा कमाता है, वह भी maintenance phase में ही कमाता है
industry को लगभग 100 साल बाद भी यह समझ नहीं आया है
Alan Kay का यह कहना कि computer revolution अभी तक हुई ही नहीं है, 100% सही है
आज की सारी progress के बावजूद tools अभी भी ज़्यादातर stone age स्तर के हैं
मेरी बड़ी आशा यह है कि AI हमें इतना तेज़ आगे धकेले कि वह मौजूदा paradigm को irreversibly पूरी तरह तोड़ दे, ताकि अंततः हम कुछ नया, अलग, और बेहतर कर सकें
इसलिए अभी software development lifecycle को AI से jetpack लगाकर खुलकर प्रयोग कीजिए
तेज़ चलिए, और सचमुच चीज़ें तोड़िए
यह समयानुकूल observation है और मुझे भी सटीक लगता है
मुझे अपेक्षाकृत सरल bulk download → conversion → API endpoint खड़ा करना था, और मैंने काफ़ी detailed prompt लिखा, लेकिन implementation details जैसे data source को बहुत हद तक खुला छोड़ दिया
Opus 4.7 ने इसे लगभग 90% वैसे ही बनाया जैसे मैं खुद करता, और convenience methods व step-by-step validation कहीं ज़्यादा जोड़े
यह बहुत अच्छा था, और इसने मुझे अधिक कठिन समस्याओं पर सोचने की जगह दी
मैं मुख्यतः Python developer हूँ, लेकिन Rust या Go जैसी दूसरी backend languages भी लगातार इस्तेमाल करता हूँ जिनसे मैं परिचित तो हूँ, पर उसी स्तर पर नहीं
एक language में लगभग 13 साल का गहरा अनुभव और दूसरी languages की formal learning होने से LLM को direct करना बहुत आसान हो जाता है
syntax, basic building blocks, package manager, testing, आदि सीखने का बोझ पुराने programming तरीकों की तुलना में बड़ा नहीं है
कुछ समय पहले मैंने Claude cowork/code के साथ reporting automation कर रहे एक non-developer colleague की मदद की
वह colleague business intelligence को अच्छी तरह समझता था, लेकिन RDP खोलकर vendor DB के ऊपर MS Access abstraction में values भरने वाले pyautogui wrapper को vibe coding करने के लिए ज़रूरी बुनियादी अभिव्यक्ति में उसे कठिनाई हो रही थी
पेशे के रूप में developer की नौकरी अभी 5~10 साल तक तो ठीक लगती है