AI युग में प्रोग्रामर: कोड जनरेशन से non-determinism के नियंत्रण तक भूमिका का बदलाव

सारांश

• AI कोड लिखने का बड़ा हिस्सा ऑटोमेट कर रहा है, इसलिए डेवलपर की मुख्य भूमिका सीधे implementation से हटकर डिज़ाइन, verification और control की ओर जा रही है।
• प्रोग्रामर का मूल काम बहुत सारा कोड टाइप करना नहीं, बल्कि अस्पष्ट requirements की details भरना और उन्हें reusable रूप में abstract करना है।
• AI को implementation की बारीकियाँ बताने के बजाय लक्ष्य और context देना और निर्णय सौंपना अधिक प्रभावी है।
• AI के काम को एक बार में पूरा कराने के बजाय specification, testing, implementation, refactoring और verification में output अलग करना quality बढ़ाने के लिए बेहतर है।
• AI का output non-deterministic होता है, इसलिए test, compiler, linter और verification gate जैसे deterministic harness की ज़रूरत होती है।
• भविष्य का डेवलपर केवल कोड लिखने वाला नहीं, बल्कि AI agents और verification systems को जोड़ने वाला system designer और harness engineer बनने की ओर बढ़ सकता है।

---

परिचय

AI ने डेवलपर की पहचान को कैसे झकझोरा

• AI अब केवल natural language instructions से सैकड़ों lines का कोड बना सकता है, जिससे पारंपरिक development skills के मानक बदल रहे हैं।

• पहले खाली editor में तेज़ी से कोड लिख पाने की क्षमता को डेवलपर की बड़ी प्रतिस्पर्धी ताकत माना जाता था।

• अब जब knowledge और implementation के तरीके AI दे रहा है, तो कुछ सवाल उभरते हैं।

  • क्या बिना खुद कोड लिखे भी इसे development कहा जा सकता है।
  • अगर AI implementation की details संभाल ले, तो डेवलपर की क्या भूमिका बचती है।
  • क्या पारंपरिक computer science knowledge और programming history आज भी ज़रूरी हैं।

• यह लेख इन सवालों को details, abstraction, non-determinism और harness जैसे concepts के आधार पर समझाता है।

प्रोग्रामिंग इतिहास का महत्व

• पुराने programming knowledge को केवल तकनीकों की सूची नहीं, बल्कि डेवलपर्स द्वारा समस्याएँ हल करने और नई abstraction layers बनाने की प्रक्रिया के रूप में देखना चाहिए।
• machine language, assembly language, structured programming, object-oriented programming और frameworks सब निचली layers की complexity छिपाने के लिए बने।
• भले ही पुरानी technologies को सीधे इस्तेमाल न किया जाए, उनका इतिहास समझने से यह पता चलता है कि डेवलपर की भूमिका बार-बार कैसे बदली है।

---

मुख्य भाग

1. डेवलपर वह है जो details को ठोस रूप देता है

• planning आमतौर पर product का उद्देश्य और बड़ी दिशा बताती है, लेकिन actual implementation के लिए ज़रूरी हर condition को स्पष्ट नहीं करती।

• उदाहरण के लिए, ‘nickname edit’ जैसी साधारण feature में भी ये details होती हैं।

  • क्या empty string की अनुमति होगी या नहीं
  • special characters और emoji को कैसे handle किया जाएगा
  • network error और response delay को कैसे handle किया जाएगा
  • edit के दौरान screen छोड़ने पर क्या होगा
  • error message कहाँ और किस रूप में दिखेगा

• डेवलपर का काम इन्हीं gaps को logical rules और exception handling के रूप में ठोस बनाना है।

• इसलिए डेवलपर की विशेषज्ञता केवल feature implement करने में नहीं, बल्कि अस्पष्ट requirements को complete system behavior में बदलने की क्षमता में है।

2. abstraction का मतलब हल की गई details को छिपाना है

• डेवलपर्स दोहराव कम करने के लिए एक बार हल की गई समस्याओं को function, module, library और framework के रूप में पैक करते हैं।

• abstraction का सार यह है।

  • दोहराए जाने वाले internal behavior को छिपाना
  • बाहर से केवल ज़रूरी functionality को expose करना
  • क्या बदला जा सकता है और क्या स्थिर रहेगा, इसकी boundary तय करना

• जब मजबूत abstractions जमा होती हैं, तो एक नई layer बनती है, और ऊपर की layer पर काम करने वाले डेवलपर्स को नीचे की implementation पूरी तरह जानने की ज़रूरत नहीं होती।

• आज का development environment पिछली पीढ़ियों के डेवलपर्स द्वारा बनाई गई abstraction layers पर चलता है।

3. डेवलपर को कितनी depth चाहिए, यह उसकी position पर निर्भर करता है

• हर abstraction पूरी तरह completed नहीं होती।

• जो layer अंदर की implementation को स्थिर रूप से छिपा सके, उसे ‘completed abstraction’ कहा जा सकता है।

• जिन layers में internal details performance issues या bugs के रूप में बार-बार बाहर आ जाती हैं, वे ‘abstraction in progress’ हैं।

• एक ही technology की स्थिति भी डेवलपर की भूमिका के अनुसार बदलती है।

  • सामान्य web developer के लिए browser अपेक्षाकृत completed layer है।
  • browser engine developer के लिए rendering process एक सीधी detail problem है जिसे खुद संभालना पड़ता है।

• डेवलपर के लिए ज़रूरी depth का मतलब हर technology जानना नहीं, बल्कि अपने जिम्मे की layer की leakage और limitations को समझ पाने का स्तर है।

4. AI एक नई abstraction layer के रूप में उभरा है

• AI वह code writing और repetitive implementation तेज़ी से कर रहा है जिसे पहले डेवलपर खुद करते थे।
• इस वजह से AI अब सिर्फ productivity tool नहीं, बल्कि development process को abstract करने वाली नई layer की तरह काम करने लगा है।
• लेकिन AI के code generate करने भर से requirements interpretation, structure design, quality verification और operational responsibility अपने आप हल नहीं हो जाती।
• उल्टा, implementation cost कम होने से generated code को assemble और verify करने की लागत का महत्व और बढ़ जाता है।

5. बहुत ज़्यादा detailed instructions AI की performance सीमित कर सकती हैं

• लेखक ने accessibility UI side project में खुद code टाइप किए बिना केवल AI से development करने की कोशिश की।

• शुरुआत में AI को implementation का specific तरीका बताया गया, लेकिन AI उसी approach में फँस गया और बार-बार exception handling जोड़ता रहा।

• नतीजतन code complex होता गया, कई side effects आए, और बेहतर standard approach बाद में लागू हुई।

• यह उदाहरण दिखाता है कि user द्वारा दिया गया शुरुआती तरीका AI के judgment को सीमित करने वाला anchor बन सकता है।

• solution और code structure को ज़्यादा निर्देशित करने के बजाय यह देना अधिक प्रभावी है।

  • समस्या की background और उद्देश्य
  • मौजूदा system का context
  • वह result जो हर हाल में satisfy होना चाहिए
  • वे constraints जिन्हें बदला नहीं जा सकता

6. निर्देशों से ज़्यादा लक्ष्य और context delegate करना चाहिए

• जैसे-जैसे AI की capability बढ़ती है, detailed procedures तय करने के बजाय goal-centric delegation ज़्यादा प्रभावी हो सकता है।

• delegation वाले तरीके में डेवलपर ‘कैसे implement करना है’ यह सब तय करने के बजाय ‘यह क्यों ज़रूरी है’ और ‘क्या हासिल करना है’ यह स्पष्ट करता है।

• लेकिन पूरी autonomy देने पर AI user intent की बजाय code modification पर ही ज़्यादा फोकस कर सकता है।

• इसलिए ज़रूरी है कि workflow को सीमित किया जाए ताकि AI पहले ये काम करे।

  • request intent का analysis
  • missing information पर सवाल
  • solution plan पेश करना
  • user approval के बाद execution

• यहाँ मुख्य बात साधारण prohibition नहीं, बल्कि मौजूदा चरण में कौन-सा output allowed है इसे साफ़-साफ़ तय करना है।

7. एक बार के काम में केवल एक output तय करना चाहिए

• LLM एक response में जितना output और reasoning संभाल सकता है, उसकी सीमा होती है।

• अगर testing और implementation एक साथ कहे जाएँ, तो final goal यानी code completion पर resources ज़्यादा लग सकते हैं और tests की quality गिर सकती है।

• लेखक ने TDD workflow को इस तरह अलग किया।

  • /red: केवल failing tests लिखना
  • /green: tests pass कराने वाली minimum implementation लिखना
  • /refactor: tests बनाए रखते हुए code structure बेहतर करना

• हर step में output को एक तक सीमित करने से AI द्वारा बीच की प्रक्रिया छोड़ देने या उसे केवल औपचारिक रूप से निपटाने की समस्या कम हो सकती है।

• इसका मतलब है कि prompt design का सार behavior को लंबा-चौड़ा समझाना नहीं, बल्कि एक बार के task में बनने वाले result को define करना है।

8. Markdown documents और skills नया code बन रहे हैं

• specification, testing, implementation, verification और commit tasks को अलग-अलग skills में बाँटने पर ऐसा pipeline बनाया जा सकता है।

  • specification लिखना
  • failing tests generate करना
  • feature implement करना
  • refactoring
  • verification
  • commit

• हर skill के input, output और constraints होते हैं, इसलिए वह function की तरह काम करती है।

• skills और rules लिखे हुए Markdown documents केवल manuals नहीं, बल्कि AI के behavior को तय करने वाले executable rules की तरह काम करते हैं।

• इस प्रक्रिया पर पारंपरिक software design principles भी लागू किए जा सकते हैं।

  • एक skill को एक ही responsibility देने वाला single responsibility principle
  • knowledge और rules को अलग files में बाँटने वाली modularity
  • core skills बदले बिना external knowledge files से विस्तार करने वाला open-closed principle

• platform भले IDE से बदलकर Markdown documents हो गया हो, लेकिन काम को तोड़ना और जोड़ना अब भी programming ही है।

9. AI coding का सबसे बड़ा जोखिम non-determinism है

• पारंपरिक programs एक ही input पर अधिकतर एक जैसा output लौटाते हैं।

• AI एक ही request पर अलग-अलग code और judgments दे सकता है।

• जब AI बड़े स्तर का refactoring करता है, तो feature चलने के बावजूद ये समस्याएँ रह जाती हैं।

  • बदले गए code की correctness की समीक्षा
  • हटाए गए code के वास्तव में अनावश्यक होने का judgment
  • नए side effects की संभावना
  • maintenance और deployment की responsibility

• AI code generation को तेज़ करता है, लेकिन result की stability और responsibility अपने आप नहीं देता।

• production environment में generation ability से ज़्यादा change scope को control करने और result को verify करने की क्षमता महत्वपूर्ण है।

10. AI low-ceiling problems में मज़बूत है

• AI जिन समस्याओं को आसानी से हल करता है, वे आमतौर पर ऐसी ‘well-defined problems’ होती हैं जिनकी requirements और solution patterns पहले से काफी ज्ञात होते हैं।

• ऐसी समस्याओं को existing libraries, frameworks और patterns जैसे पहले से बने abstraction elements को जोड़कर हल किया जा सकता है।

• AI इंसानियत द्वारा जमा किए गए code और problem-solving patterns को probabilistic तरीके से combine करने में मजबूत है।

• लेकिन नीचे जैसी high-difficulty problems में अतिरिक्त human judgment की ज़रूरत पड़ती है।

  • अधूरी requirements वाली समस्याएँ
  • complex domain rules
  • large-scale systems की interactions
  • operating environment की exception situations
  • security, performance, regulation और accountability से जुड़ी संयुक्त समस्याएँ

• simple implementation की value खत्म नहीं होती, लेकिन implementation खुद धीरे-धीरे ऐसा क्षेत्र बन सकता है जिसे सामान्य user भी कर सके।

11. डेवलपर की details अब AI control की ओर शिफ्ट हो रही हैं

• पहले डेवलपर्स deterministic code लिखकर unpredictable user input और operating environment से बचाव करते थे।

• AI युग में non-deterministic AI का उपयोग करके deterministic products बनाने होंगे।

• डेवलपर को संभालनी वाली details अब इन क्षेत्रों में जा रही हैं।

  • AI को गलत goal पर अटकने से रोकने के लिए task scope तय करना
  • step-by-step input और output formats define करना
  • context और knowledge documents manage करना
  • large-scale changes की सीमा तय करना
  • error होने पर recovery procedures design करना
  • result की quality और safety verify करना

• जैसे-जैसे simple implementation ऑटोमेट होगी, development work में exception handling और control का हिस्सा और बढ़ सकता है।

12. AI के outputs को deterministic tools से verify करना चाहिए

• AI से बने results को किसी दूसरी AI से verify कराने भर से पर्याप्त reliability पाना कठिन है।

• system का output सही है या नहीं, यह तय करने के लिए एक स्पष्ट correct-answer standard यानी oracle चाहिए।

• अगर non-deterministic AI verification standard भी मनमाने ढंग से बनाए, तो सही result को गलत ढंग से बदलने या verification standard को विकृत करने का खतरा होता है।

• इसलिए verification standards को जहाँ तक संभव हो deterministic tools पर आधारित होना चाहिए।

  • compiler और type checker
  • automated tests
  • linter और static analysis
  • schema validation
  • performance और security standards
  • approval procedures और change-scope limits

• AI का judgment सहायक साधन हो सकता है, लेकिन final pass/fail को reproducible standards से जोड़ा जाना चाहिए।

13. harness AI development का मुख्य infrastructure बन रहा है

• harness वह verification mechanism है जो AI को काम के दौरान errors accumulate करने या scope से बाहर जाने से रोकने के लिए step-by-step लगाया जाता है।

• इसके मुख्य components ये हैं।

  • task stages अलग करने वाला pipeline
  • हर stage के input/output formats
  • automated tests और static analysis
  • failure पर रुकने वाले verification gates
  • बदली जा सकने वाली files और scopes की सीमाएँ
  • human approval और review procedures

• harness एक step की छोटी error को अगले step में बढ़ने से रोकता है।

• AI का उपयोग करने की क्षमता का मूल्यांकन केवल अच्छे prompts लिखने से नहीं, बल्कि unpredictable outputs को stable system के भीतर बाँधने की क्षमता से किया जा सकता है।

---

निष्कर्ष

डेवलपर गायब नहीं हो रहा, उसकी भूमिका बदल रही है

• AI simple code writing और repetitive implementation को तेज़ी से automate कर रहा है।

• लेकिन product-level results बनाने के लिए अब भी इन भूमिकाओं की ज़रूरत है।

  • समस्या और goal define करना
  • system structure design करना
  • work stages और outputs को अलग करना
  • AI agents के बीच flow coordinate करना
  • verification standards और harness बनाना
  • operational results की अंतिम responsibility लेना

• डेवलपर के काम में सीधे कोड टाइप करने का हिस्सा कम हो सकता है, और AI द्वारा बनाए गए code को system के रूप में organize और control करने का हिस्सा बढ़ सकता है।

prompt लिखना programming का नया रूप है

• बार-बार इस्तेमाल होने वाले instructions को skills और rules में बदलकर pipeline से जोड़ने की प्रक्रिया function और module design करने जैसी है।
• Markdown documents AI के context, behavior और output format को define करने वाली नई code layer की तरह काम कर सकते हैं।
• डेवलपर्स को अपने अनुभव और implicit judgment standards को document करके ऐसे abstract करना होगा कि AI उन्हें reuse कर सके।
• यह केवल existing systems को abstract करना नहीं, बल्कि डेवलपर के अपने working style और judgment process को भी abstract करने का काम है।

भविष्य के डेवलपर की core capabilities

• समस्याओं को सटीक रूप से define करने की क्षमता
• goal और context केंद्रित delegation की क्षमता
• complex work को छोटे outputs में तोड़ने की क्षमता
• skills और agents को pipeline के रूप में compose करने की क्षमता
• deterministic verification standards design करने की क्षमता
• non-deterministic results के जोखिम को control करने वाला harness बनाने की क्षमता
• AI द्वारा बनाए गए results को समझने और उनकी अंतिम responsibility लेने लायक technical depth

समग्र मूल्यांकन

• AI development के सार को खत्म नहीं कर रहा, बल्कि उस abstraction layer को बदल रहा है जिसे डेवलपर संभालता है।
• पहले का डेवलपर code और system की details संभालता था, तो भविष्य का डेवलपर AI के behavior और outputs से पैदा होने वाली details संभालेगा।
• code generation की लागत घटेगी, लेकिन verification, assembly, operation और control का महत्व और बढ़ सकता है।
• प्रोग्रामर का सार typing नहीं, बल्कि details को पहचानना, उन्हें abstract करना और उन्हें भरोसेमंद systems में बदलना है।