GitHub CEO, AI बूम के बीच भी “मैनुअल कोडिंग अब भी अहम”
(techinasia.com)- GitHub CEO Thomas Dohmke ने AI टूल्स के बढ़ते इस्तेमाल के बावजूद मैनुअल कोडिंग स्किल्स के महत्व पर ज़ोर दिया
- उनका कहना है कि AI कोड जनरेट कर दे, तब भी डेवलपर को खुद उसे एडिट और रिव्यू करना चाहिए ताकि काम अधिक प्रभावी रहे
- अगर सिर्फ ऑटोमेशन पर निर्भर रहा जाए, तो वास्तविक अक्षमताएँ और प्रोडक्टिविटी में गिरावट का जोखिम बढ़ता है; वहीं "Vibe coding" की तरह AI कोड के अत्यधिक उपयोग से क्वालिटी और सिक्योरिटी रिस्क भी बढ़ते हैं
- उन्होंने इंडस्ट्री ट्रेंड्स और उदाहरणों के साथ समझाया कि AI और मानव डेवलपर के हाइब्रिड अप्रोच सबसे प्रभावी है
- डेवलपर की भूमिका खत्म नहीं हो रही, बल्कि AI के साथ मिलकर रणनीतिक समस्या-समाधान और डिज़ाइन क्षमता की ज़रूरत वाली दिशा में विकसित हो रही है
GitHub CEO ने AI युग में भी मैनुअल कोडिंग के महत्व पर ज़ोर दिया
GitHub CEO Thomas Dohmke ने कहा कि सॉफ्टवेयर डेवलपमेंट के क्षेत्र में AI टूल्स का इस्तेमाल बढ़ने के बावजूद, मैनुअल कोडिंग क्षमता को बनाए रखना बहुत ज़रूरी है
- “The MAD Podcast with Matt Turck” में उन्होंने समझाया कि डेवलपर्स के पास AI द्वारा जनरेट किए गए कोड को खुद संशोधित करने की क्षमता होनी चाहिए, ताकि प्रोडक्टिविटी में गिरावट को रोका जा सके
- एक प्रभावी वर्कफ़्लो यह है कि AI टूल कोड जनरेट करके Pull Request सबमिट करे, और डेवलपर अपनी स्किल्स से उसे तुरंत सुधार दे
- अगर पूरी तरह ऑटोमेशन एजेंट्स पर निर्भर हुआ जाए, तो साधारण बदलाव को प्राकृतिक भाषा में समझाने में अनावश्यक समय खर्च हो सकता है, जिससे अक्षमता पैदा होने का जोखिम है
- Dohmke ने कहा कि “जिस काम को आप पहले से किसी प्रोग्रामिंग भाषा में सीधे कर सकते हैं, उसे बेवजह प्राकृतिक भाषा में समझाने की कोशिश करना सबसे अक्षम विकल्प है”
- OpenAI के सह-संस्थापक Andrej Karpathy द्वारा इस्तेमाल किया गया “vibe coding” शब्द AI-जनरेटेड कोड पर अत्यधिक निर्भरता को दर्शाता है, और Dohmke ने इस पर भी सावधानी बरतने की बात कही
इनसाइट्स और इंडस्ट्री ट्रेंड्स
1. AI कोडिंग का सबसे बेहतर तरीका है हाइब्रिड रणनीति
- Dohmke का नज़रिया उस इंडस्ट्री कंसेंसस से मेल खाता है जो कहता है कि AI ऑटोमेशन और मानव प्रोग्रामिंग स्किल्स का संयोजन सबसे बेहतर है
- Deloitte की एक स्टडी के मुताबिक डेवलपर्स AI टूल्स का इस्तेमाल मुख्य रूप से boilerplate code लिखने के लिए करते हैं, लेकिन अंतिम मानव समीक्षा बनाए रखने से उन्हें 10~20 मिनट की प्रोडक्टिविटी बढ़त मिलती है
- AI द्वारा जनरेट किए गए कोड के करीब आधे हिस्से में आंशिक त्रुटियाँ होती हैं, इसलिए “trust but verify” रणनीति इंडस्ट्री स्टैंडर्ड बनती जा रही है
- Google में कुल कोड का 25% से अधिक हिस्सा AI द्वारा जनरेट किया जाता है, लेकिन वहाँ भी मानव डेवलपर्स की सक्रिय समीक्षा और सुधार अनिवार्य है
- यह संतुलित अप्रोच दिखाती है कि इंडस्ट्री AI की सीमाओं को समझते हुए डेवलपर की विशेषज्ञता को प्रतिस्थापन नहीं, बल्कि वृद्धि के रूप में देख रही है
2. डेवलपर की भूमिका बदल रही है, खत्म नहीं हो रही
- AI की वजह से प्रोग्रामिंग नौकरियाँ खत्म होने के बजाय, डेवलपर की भूमिका शुद्ध कोडर से AI-आधारित डेवलपमेंट प्रोसेस मैनेजर की ओर बदल रही है
- विशेषज्ञों का मानना है कि डेवलपमेंट भूमिकाएँ आगे चलकर AI का उपयोग करने वाले प्रोडक्ट इंजीनियर और उच्च-स्तरीय सिस्टम क्वालिटी/सिक्योरिटी सुनिश्चित करने वाले आर्किटेक्ट्स में बँट सकती हैं
- इस बदलाव का मतलब है कि AI का प्रभावी उपयोग, रणनीतिक समस्या-समाधान, और उच्च-स्तरीय डिज़ाइन क्षमता जैसी नई स्किल्स की ज़रूरत बढ़ेगी
- सॉफ्टवेयर इंजीनियर्स की कमी और AI टूल्स के जूनियर डेवलपर्स को सपोर्ट देने वाले प्रभाव के साबित होने से, अनुभवी डेवलपर्स के लिए भी नई ग्रोथ के अवसर खुल रहे हैं
- यह संकेत देता है कि जैसे पहले डेवलपमेंट टूल्स और abstraction technologies के आने पर हुआ था, वैसे ही मानव रचनात्मकता अब भी आवश्यक बनी हुई है
3. “Vibe coding” का प्रोडक्टिविटी-क्वालिटी दुविधा
- “Vibe coding” का ट्रेंड AI-जनरेटेड कोड के प्रोडक्टिविटी लाभ और क्वालिटी/सिक्योरिटी सीमाओं दोनों को उजागर करता है
- AI टूल्स तेज़ prototyping और iterative development को सपोर्ट करते हैं, लेकिन इसके साथ कोड क्वालिटी में गिरावट और सिक्योरिटी रिस्क की चिंता भी बढ़ती है
- वास्तविक मामलों में AI कोड का बिना सत्यापन इस्तेमाल करने से सिक्योरिटी कमजोरियाँ भी सामने आई हैं
- नॉन-टेक फाउंडर्स द्वारा चलाए जा रहे startups में AI कोड का अत्यधिक उपयोग तकनीकी कर्ज़ बढ़ाकर लंबी अवधि की ग्रोथ को नुकसान पहुँचा सकता है
- बड़ी IT कंपनियों के अनुभव के अनुसार, ऑटोमेशन और सख्त क्वालिटी कंट्रोल के बीच संतुलन ही AI अपनाने की कुंजी है, और startups के लिए भी यह सबक महत्वपूर्ण है
1 टिप्पणियां
Hacker News राय
मुझे बहुत हैरानी होती है कि लोग अब सिस्टम की मौलिक जटिलता के बारे में बात ही क्यों नहीं करते
Fred Brooks की No Silver Bullet यह बताती है कि software engineering की असली कठिनाई मूल problem space को समझने, स्पष्ट करने और model करने में है। टूल्स की सीमाओं जैसी आकस्मिक जटिलता द्वितीयक है
हाल में बहुत बात होती है कि AI agents इंजीनियरों की जगह natural language prompts से पूरा codebase बना देंगे। लेकिन यह मान लेना कि specification की समस्या पहले ही हल हो चुकी है, एक भ्रम है। वास्तव में, धुंधले ideas को विस्तारपूर्ण और मजबूत systems में बदलना अब भी इंजीनियर की मुख्य भूमिका है
अगर कोई व्यक्ति detailed specification दे और AI के साथ बार-बार काम करके software बनाए, तो असल में वह AI से आकस्मिक जटिलता को हटा रहा है। यह वैसा ही है जैसे developers assembly से high-level languages पर आए थे। यह इंजीनियरों को replace नहीं करता, सिर्फ productivity बढ़ाता है। दोहराए जाने वाले काम की लागत घटती है और प्रभाव का दायरा भी बढ़ता है
अगर कोई agent सिर्फ prompt से product बना देता है, तो इसका मतलब है कि किसी ने system को पहले ही बहुत स्पष्ट रूप से define कर दिया था। और अगर AI से सिर्फ existing products की नकल हो रही है, तो वह technical problem solving नहीं बल्कि distribution या cost competition का मामला है, जो engineering innovation नहीं बल्कि business innovation है
सोच रहा हूँ कि क्या मैं कुछ मिस कर रहा हूँ
असली मुद्दा यह है कि specification का काम AI आने से बहुत पहले से ही नज़रअंदाज़ किया जाता रहा है
stakeholders (customers, managers) पहले से ही बस अंदाज़े के आधार पर coding करवाते रहे हैं। एक मोटा-सा idea देते हैं और उम्मीद करते हैं कि कोई चमत्कारिक रूप से उसके मुताबिक solution दे देगा। किसी को ठीक से पता भी नहीं होता कि solution पूरी तरह काम करता है या नहीं। बस लगभग काम करता दिखे तो बात आगे बढ़ जाती है
ज़्यादातर मामलों में programmer खुद domain knowledge के आधार पर चीज़ें concrete बनाता है, जैसे यह सहज रूप से जानना कि सही form submission page कैसा दिखना चाहिए
अब बस सामने वाला इंसान नहीं, AI हो गया है। यह तरीका वैसे ही दोहराया जा सकता है या नहीं, यह देखना बाकी है
मौलिक/आकस्मिक जटिलता का फर्क यह समझने के लिए बेहद अहम insight है कि AI software development में कितनी दूर तक जा सकता है
बहुत-से developers शब्दों में यह समझा नहीं पाते कि वे AI से replace क्यों नहीं होंगे, लेकिन भीतर से उन्हें यही बात महसूस होती है
मैंने भी Claude जैसे agents से बहुत complex, external business logic से भरे बड़े codebase की समस्याएँ सुलझाने की कोशिश की है। लेकिन AI business requirements या context को ठीक से intuit नहीं कर पाता, इसलिए business-oriented code changes नहीं कर पाता। वह बस सीमित context वाले code changes में मदद कर सकता है। यानी वह आकस्मिक जटिलता तक तो संभाल सकता है, लेकिन असली developer का काम, यानी वास्तविक requirements को system में translate करना, उसकी सीमा है
जोड़कर कहूँ तो, कई developers जिन समस्याओं को हल कर रहे होते हैं, वे technical नहीं बल्कि distribution/market problems भी हो सकती हैं। AI से junior को replace करना अभी भी असहज लगता है। सबसे बड़ी समस्या यह है कि AI अपने-आप self-correction नहीं कर पाता। फिर भी AI-आधारित businesses पुराने businesses की लागत घटाने की कोशिश करते रहेंगे। वह बदलाव अच्छा होगा या बुरा, नौकरी से बाहर धकेले गए व्यक्ति के लिए यह सवाल अर्थहीन है
“क्या मैं कुछ मिस कर रहा हूँ?” का एक जवाब है
वास्तव में software का इस्तेमाल करना न जानने वाले developers बहुत ज़्यादा हैं। इन्हें AI आसानी से replace कर देगा
अपने पिछले करियर में मैंने JavaScript पर काम किया, और सचमुच कमाल का काम करने वाले लोग वही थे जो शौक से development करते रहे थे। कंपनी में ज़्यादातर लोग screen पर text दिखाना भी मुश्किल से कर पाते थे। यह मज़ाक नहीं है
बहुत-से लोग बड़े frameworks में कूद पड़े, लेकिन आखिर में बस copy-paste करके किसी तरह चीज़ें चलाने की स्थिति में थे। वे ऊँची जटिलता हल करने का दिखावा करते हैं, लेकिन ज़्यादातर काम अनावश्यक होता है या सिर्फ code दिखावा
original app बनाना, documentation लिखना, और वास्तविक usability मापना—इनकी क्षमता लगभग नहीं होती
इसका समाधान? वकीलों के bar exam जैसी ऊँची कसौटी लानी होगी, ताकि जो लोग उस मानक तक नहीं पहुँचते उन्हें साफ़ तौर पर अलग किया जाए, और उन्हें सिर्फ juniors या apprentices के रूप में रखा जाए। तभी developers की अगली पीढ़ी ठीक से बढ़ सकेगी
‘मिस हो रही बात’ का आसान जवाब यह है कि industry में किसी ने "No Silver Bullet" पढ़ी ही नहीं है
technical debt और system architecture पर लिखने वाले लोग वास्तव में टीम/बिज़नेस को चलाने वाले decision-makers नहीं होते, और ऐसी किताबें भी engineers के लिए वैकल्पिक मानी जाती हैं
AI से coding replace होने की बात आगे बढ़ाने वाले लोग अक्सर MVP बनाना और 10 साल तक codebase को scale करना और legacy को सुधारना—इन दोनों में फर्क ही नहीं समझते
उदाहरण के लिए, एक manager ने कभी एक दिन में 3 projects को 33% समय बाँटने जैसा क्लासिक गलत सुझाव दिया था। resource allocation और time structuring manager की क्षमता होनी चाहिए, लेकिन आखिर में उसे सही तरीके से संभालना engineers के हिस्से आता है
अब वही managers कहते हैं, “AI से सारा technical debt/test solve करवा लेते हैं,” और जब बात ठीक से नहीं चलती तो उसका explanation भी engineer को ही देना पड़ता है
complexity की यह चर्चा दरअसल खराब management की समस्या की पुनरावृत्ति है। ज़्यादातर अनुभवी engineers पहले से ही नहीं मानते कि उनका काम किसी आसान prompt से replace हो जाएगा
असली चर्चा यह होनी चाहिए कि “software engineering में management की समस्या गंभीर है, और AI उसे और उजागर कर रहा है”
बहुत-से non-developers या students को लगता है कि software development में जटिल tools सीखने पड़ते हैं, इसलिए वे इस वादे से आकर्षित होते हैं कि “अगर specification अच्छी हो तो कोई भी software बना सकता है” — जबकि यह छोड़ दिया जाता है कि specification बनाना खुद बहुत कठिन काम है और इसके लिए सहायक तकनीक चाहिए
पहले no-code भी इसी तरह पेश किया गया था, और वास्तव में no-code tools सीमित होते हैं; और जितने ज़्यादा powerful होते हैं, उतनी ही ज़्यादा complexity और specialist learning माँगते हैं
LLM के जरिए SWE replacement की दलील भी आखिरकार यही version है: “system सीखने के बजाय natural language में prompt करो, model खुद tools इस्तेमाल कर लेगा”
इस नज़रिए से देखें तो आजकल की vibe coding असल में इसी लक्ष्य का चरम रूप है, भले ही उसमें maintainability जैसी व्यावहारिक कमजोरियाँ हों
मुझे लगता है managers SWE को हटाना इसलिए भी चाहते हैं क्योंकि वे SWE के साथ ठीक से communicate नहीं कर पाते
LLM का इस्तेमाल करके उन्हें लगता है कि “nerds (developers)” के बिना भी मशीन से बात की जा सकती है, यानी समस्या हल हो गई
programming languages इच्छित program की सटीक specification के लिए उपयुक्त माध्यम हैं। natural language कभी उस स्तर की स्पष्टता नहीं दे सकती
इसलिए AI द्वारा generate किए गए परिणामों को review और edit करना स्वाभाविक है। कई बार changes को समझाने से ज़्यादा आसान उन्हें सीधे ठीक करना होता है
सोचता हूँ क्या Copilot से error rate बढ़ने वाली independent studies ने स्वाभाविक रूप से अधिक सावधानीपूर्ण रवैया फैलाने में भूमिका निभाई है
AI बेचने वाले लोग अक्सर दावा करते हैं कि human authors की जल्द ज़रूरत नहीं रहेगी
Transformer को automated testing, specification expansion, नए projects की गति बढ़ाने, अनजान APIs को explore करने, शुरुआती features बनाने, code review जैसी बहुत-सी चीज़ों में इस्तेमाल किया जा सकता है
भले ही code specification का सही माध्यम हो, Transformer natural language और उस medium (code) के बीच automated interface की तरह काम करता है
हाल के Transformer models के पास विशाल ज्ञान होने के कारण code generation में कोई बड़ी दिक्कत नहीं है
जैसे इंसान programming में automation की तलाश करते हैं, वैसे Transformer एक बहुत बड़ी छलांग है
भविष्य में किसी समय AI के कारण programmers का replacement वास्तविकता बन सकता है, जैसे automatic loom, printing press, और electronic calculators ने मानव श्रम को replace किया था
लेकिन यह अभी तुरंत, या शायद 10 साल में भी न हो; hallucination, accuracy, tooling, infrastructure जैसे मुद्दे अभी बाकी हैं
programming jobs का भविष्य domain, skill, और compensation expectations पर निर्भर कर सकता है
AI tools को गंभीरता से लेना और adapt करना ज़रूरी है। नहीं तो personal computing या internet adoption के दौर की तरह बदलाव से पीछे छूटने का खतरा है
मुझे लगता है AI की pseudo-creativity की सीमाएँ हैं
अगर सभी LLM training outputs फिर से सिर्फ LLM inputs के रूप में ही घूमते रहें, तो नए ideas की सीमा कभी चौड़ी नहीं होगी
इंसान लगातार उस सीमा के बाहर जाने वाली creativity दिखाते हैं
भविष्य में LLM शायद उस दीवार को पार कर लें, लेकिन फिलहाल यह ‘monkey typewriter’ से बहुत अलग नहीं लगता
मेरे अनुभव में LLM सबसे प्रभावी तब होते हैं जब उन्हें scaffolding टूल की तरह इस्तेमाल किया जाए
मैं जो feature बनाना चाहता हूँ, उसे brain dump की तरह बता देता हूँ, और फिर model से उस model और उसके लिए ज़रूरी base controller बनाने को कहता हूँ
उसके बाद मैं सिर्फ views और वास्तविक business logic पर ध्यान देता हूँ, इसलिए काम का बँटवारा साफ़ रहता है
जब high-level languages पहली बार आई थीं, तब शुरुआती दौर में उन पर भी कुछ वैसी ही आलोचनाएँ हुई थीं जैसी आज LLM या natural-language coding पर होती हैं, जैसे “memory को सीधे control करना मुश्किल है इसलिए precision कम है”
समस्या यह नहीं है कि natural language में precision असंभव है, बल्कि यह है कि ज़्यादातर लोग अपनी माँगें precision के साथ बताते ही नहीं, या वे सिर्फ यह जानते हैं कि उन्हें क्या चाहिए, लेकिन यह नहीं समझा पाते कि computer को वास्तव में क्या करना है
नतीजा यह होता है कि engineer business requirements को translate करते समय बहुत अनुमान लगाता है, या LLM वही भूमिका निभाते हुए और भी कम context समझ पाता है
AI का सबसे अच्छा उपयोग मेरे लिए यह है कि किसी नए API या किसी उबाऊ feature पर अटकने की बजाय flow state बना रहे
AI पूरे code में common patterns को तेज़ी और कुशलता से लागू कर सकता है, लेकिन मूल रूप से 'उसे खुद नहीं पता होता कि वह क्या कर रहा है'
हाल का एक अनुभव साझा करूँ: popup size calculation और positioning से जुड़े code को मैंने LLM से refactor करवाना चाहा
एक जगह "if" था, दूसरी जगह "switch"। LLM दोनों approaches के अंतर पर बिल्कुल लचीला नहीं रहा, और साफ़ समझाने के बाद भी उसने दोनों जगह if या switch में एकरूपता ला दी
LLM में पिछले tokens के pattern को जारी रखने की प्रवृत्ति होती है
यहाँ यह बड़ी समस्या नहीं थी, लेकिन थोड़ी और जटिल स्थिति में यह बारीकी छोड़कर ऊपर-ऊपर से भरोसेमंद दिखने वाला code दे देता है
इसके बजाय अगर छोटे हिस्सों में बाँटकर साफ़ निर्देश दिए जाएँ, तो LLM काफ़ी प्रभावी होता है। उदाहरण के लिए, “m_StateStorage में size store करो और render phase में apply करो” जैसी हिदायत वह आसानी से कर लेता है
खासकर Cerebras जैसे models के साथ, जो कुछ kilobytes के code को भी तेज़ी से process कर सकते हैं, मेरे विचारों को सीधे code के रूप में टाइप करने से यह कहीं तेज़ लगता है
आखिरकार आज जो मूल्यांकन हो रहा है, वह सिर्फ Transformer models की वर्तमान क्षमता की आलोचना है
यह industry इतनी तेज़ी से बदलती है कि आज की सीमाएँ एक महीने बाद अप्रासंगिक हो सकती हैं
“LLM” भी सख्ती से देखें तो धुंधला शब्द है। नवीनतम Transformer models multimodal हैं और सिर्फ text नहीं, कई तरह के data से निपटते हैं
इसलिए आलोचना करनी हो तो किस model/tool/paradigm की बात हो रही है, इसे ठोस रूप से बताना ज़रूरी है, तभी चर्चा उपयोगी होगी
“software engineers की कमी” और “AI खासकर junior developers के लिए मददगार है” जैसी research के बारे में
मेरी दुनिया में, यानी जिस reality में मैं हूँ, tech job market बेहद खराब है, और AI उल्टा juniors के बढ़ने के लिए ज़रूरी अनुभव ही छीन रहा है
हाल में Claude के साथ मज़ेदार अनुभव हुआ। Zed में मैंने कहा, “line 71 की error ठीक करो,” तो उसने line 91 पर बेकार formatting बदल दी
ऐसा लगा जैसे LLM के साथ telephone game खेल रहा हूँ
इतना simple fix भी खुद करना ज़्यादा तेज़ है। इस अनुभव ने फिर याद दिलाया कि “LLM सच में सोचते नहीं हैं”
LLM की line numbers पहचानने की क्षमता बहुत खराब है
इस अनुभव से मैंने यह सीखा कि “LLM line numbers गिन नहीं सकता”
अगली बार “function XYZ में error ठीक करो” कहना, या वही line सीधे paste करना, ज़्यादा बेहतर होगा
और हाँ, LLM सोचता नहीं है। वह बस एक बहुत बड़ी equation है
इस thread में बहुत-से लोग शायद पहली बार AI से coding कर रहे हैं
यह operator error भी हो सकता है
LLM को सही context देना पड़ता है। line numbers अच्छा context नहीं हैं
मेरी नज़र में software engineer की भूमिका requirements को software में बदलना है
software सिर्फ code नहीं होता, और requirements भी सिर्फ simple natural language में नहीं आतीं
इस समय, AI के साथ काम करने पर भी मैं AI से तेज़ नहीं हो पाता, सिवाय simple tasks और छोटे software के
अभी की AI मेरे हिसाब से junior/mid-level developer जैसी है
पिछले 2 साल में AI मुझे अनुभव के स्तर पर क्रांतिकारी रूप से बेहतर नहीं लगी
ज़्यादातर requirements साफ़-साफ़ document होकर नहीं आतीं
business logic क्या है, यह जानने वाले लोग भी बहुत कम होते हैं
इसलिए अक्सर software engineer को खुद जाकर पूछना पड़ता है
software किस दिशा में बढ़ेगा और उसे इस तरह कैसे design किया जाए कि वह उस growth को संभाल सके, इसके लिए experience और intuition भी चाहिए
मुझे कल्पना भी नहीं होती कि LLM इस भूमिका का थोड़ा भी हिस्सा निभा पाएगा
मैंने कभी ऐसा software project नहीं देखा जिसमें requirements पूरी तरह स्पष्ट हों
project का आधा हिस्सा तो यह समझने में जाता है कि ‘वास्तव में चाहिए क्या’
LLM अभी junior level तक भी नहीं पहुँचा है
अगर मौजूदा AI आपकी कंपनी के mid-level developer जितनी अच्छी है, तो यह आपकी कंपनी की hiring problem है
computer की सबसे बड़ी खूबियों में से एक विश्वसनीय और दोहराई जा सकने वाली automation है
programming languages जैसी formal languages desired automation requirements को बिना अस्पष्टता के स्पष्ट रूप से व्यक्त कर सकती हैं
natural language उतनी precise नहीं होती
program की असली ground truth आखिरकार code ही है
अगर इंसान program के व्यवहार को सही-सही नियंत्रित करना चाहता है, तो code को समझने और बदलने की क्षमता सबसे महत्वपूर्ण है
“manual” शब्द में नकारात्मक अर्थछाया है
उस लेख का आशय शायद यह था कि "human coding अब भी core है"
यह स्पष्ट नहीं कि GitHub CEO ने सचमुच “manual” शब्द ही इस्तेमाल किया था। अगर कोई और neutral या अधिक सटीक wording वाला source हो तो अच्छा होगा
human coding को “manual” कहकर छोटा करना ठीक नहीं है। human developers भी AI के अलावा कई तरह के automation toolkits इस्तेमाल करते हैं
यह “manual thinking” जितना ही नकारात्मक लग सकता है
“manual” के नकारात्मक अर्थ के बारे में अभी पता चला
क्या आजकल लोग manual work को सचमुच इतना नापसंद करते हैं?
“manual coding” और “human coding” में फर्क क्या है, यह जानने की जिज्ञासा है
“अगर आप सिर्फ AI agents पर निर्भर रहें, तो यह अक्षम हो सकता है”
उदाहरण के लिए, कई बार simple change को natural language में लंबा समझाने की तुलना में code को सीधे edit करना बहुत तेज़ होता है
इसलिए AI agents के साथ सक्रिय interaction ही सबसे अच्छा workflow हो सकता है
अक्सर मैं change को natural language में सोच ही रहा होता हूँ कि उसे टाइप करने से पहले ही दिमाग में direct fix आ जाता है
जितना ज़्यादा context वाला change होता है, उतना ही लगता है कि मैं खुद agent से पहले उसे ठीक कर सकता हूँ
कितनी सक्रिय interaction ठीक मानी जाए, यह जानना चाहूँगा
मैं हाल में एक agent tooling startup से जुड़ा हूँ, और अंदर हम इस पर बहुत चर्चा करते हैं
मुझे लगता है agent को लगातार यह feedback देना कि “सच कहूँ तो तुम यह ठीक से नहीं कर रहे!” ठीक है, लेकिन कुछ स्तर के बाद यह थकाऊ हो सकता है
आप क्या सोचते हैं? workflow को लेकर आपकी कल्पना या feedback और जानना चाहूँगा
AI अभी उम्मीद के स्तर तक नहीं पहुँची है
उदाहरण के लिए, मैं अक्सर गलत reference materials या specifications की वजह से जूझता हूँ। शायद इसलिए कि AI पुराने data पर train हुई है और real-time updates की क्षमता सीमित है
मौजूदा LLM और GI solutions सभी n-step समस्याओं को एक ही बार में हल करना चाहते हैं, और इससे उनकी उपयोगिता घट जाती है
अगर वे सिर्फ step 1 से step i तक ही ठीक से संभाल लें, तो इंसानों के लिए कहीं ज़्यादा उपयोगी होंगे
अभी तक मुझे ऐसी पूरी तरह modular AI नहीं दिखी जो, जैसे, मेरी github style को reflect करे और सिर्फ a, b, c resources देखकर समस्या x हल करे
और मैं ऐसी coding AI की उम्मीद करता हूँ जो समस्या को क्रमवार explore करे, बीच-बीच में और सवाल पूछे, और बातचीत जारी रखे
यह देखकर अच्छा लगा कि कोई CEO AI और coding पर थोड़ी अलग दिशा में राय दे रहा है
आम तौर पर CEOs या investors कहते हैं कि “कुल code का 30% से ज़्यादा AI लिख रही है,” और इससे developers की भूमिका घटने का अनुमान लगाते हैं। लेकिन यहाँ निदान यह है कि वही developers सिर्फ tools की मदद से code तेज़ी से लिख पा रहे हैं
यह भी रेखांकित किया गया कि code लिखना अपने आप में software development के काम का सिर्फ एक हिस्सा है