एजेंट्स के साथ प्रोग्राम करने का तरीका

• यह लेख मौजूदा प्रोग्रामिंग अनुभव को संवादी कंप्यूटर (LLM, एजेंट) की दुनिया के अनुसार ढालने की प्रक्रिया पर दूसरी कड़ी है
• पहले भाग "LLM के साथ प्रोग्राम करने का तरीका" में बताया गया था कि LLM को मौजूदा टूल्स के साथ जोड़कर auto-complete या search के विकल्प के रूप में कैसे इस्तेमाल किया जा सकता है
• इस बार लेखक agent-based programming के अधिक कठिन लेकिन अधिक संतोषजनक, व्यावहारिक अनुभव और अंतर्दृष्टि साझा करता है

एजेंट की परिभाषा और वास्तविकता

• LLM (large language model) के संदर्भ में "एजेंट" शब्द को परिभाषित करना सार्थक है
• यह AI उद्योग के buzzword की तरह लंबे समय से इस्तेमाल होता रहा है, लेकिन वास्तव में उपयोगी संरचना के रूप में इसकी जगह हाल में बनी है
• इस दौरान इसके ऊपर बहुत-सी marketing भाषा और रहस्यवाद चढ़ा दिया गया था

• एक इंजीनियर के नज़रिए से अब इसे स्पष्ट और सरल रूप में परिभाषित किया जा सकता है: एजेंट 9 पंक्तियों का कोड है, यानी LLM call वाला for loop
• इस loop के भीतर LLM निर्देशों को execute करता है, उनके परिणाम सीधे देख सकता है, और मानव हस्तक्षेप के बिना बार-बार काम करता है
• यह साधारण लग सकता है, लेकिन व्यवहार में इसे इस तरह बनाने पर सिर्फ LLM इस्तेमाल करने की तुलना में प्रोग्रामिंग क्षमता में बहुत बड़ी छलांग मिलती है

व्हाइटबोर्ड प्रोग्रामिंग और एजेंट में अंतर

• मान लीजिए आप व्हाइटबोर्ड के सामने खड़े होकर marker से C भाषा में UTF-8 string की validity जाँचने वाला function लिख रहे हैं
  • (यह लेखक का वास्तविक interview अनुभव भी था और एक आम interview task भी है)
  • इस काम की सफलता काफी हद तक आपके programmer अनुभव और बाहरी सामग्री का सहारा न ले पाने की सीमा को संभालने की क्षमता पर निर्भर करती है
  • आपको UTF-8 encoding नियम याद होने चाहिए, और यह भी ध्यान रखना होगा कि C syntax दूसरी C-family languages से गड़बड़ न हो जाए (name-type, type-name क्रम आदि)
  • जबकि रोज़मर्रा के वास्तविक काम में compiler feedback, documentation search, printfs जैसी कई विधियों से code verify और error ढूँढी जा सकती है
• एजेंट के बिना LLM से code लिखवाना व्हाइटबोर्ड पर बिना बाहरी मदद code लिखने जैसा है
  • इसमें धुंधली याददाश्त से चीज़ें निकालनी पड़ती हैं, syntax को अनाड़ी तरीके से मिलाने की कोशिश करनी पड़ती है, और गलत interface कल्पना कर लेने जैसी त्रुटियों से बचना पड़ता है
  • LLM का बिल्कुल नया program बना लेना तकनीकी उपलब्धि के रूप में चौंकाने वाला है, लेकिन GPU से जुड़े virtual whiteboard भर से वास्तविक प्रोग्रामिंग productivity में बड़ा उछाल नहीं आता
• लेकिन अगर LLM को virtual whiteboard से अधिक दिया जाए तो?
  • उदाहरण के लिए उसे compiler चलाने दिया जाए, compile errors देखने दिए जाएँ, और खुद उन्हें सुधारने दिया जाए?
  • अगर वह grep, cat से मौजूदा files पढ़ सके, कई files (unit tests सहित) patch कर सके, और बार-बार test भी चला सके?
• एजेंट दरअसल ऐसा ही feedback-based LLM है।

एजेंट = feedback environment में काम करने वाला LLM

• इंसान की तरह feedback environment में अच्छी तरह काम करने वाला LLM, कुछ परिचित tools के साथ ही वास्तविक प्रोग्रामिंग क्षमता दिखा सकता है
  • bash(cmd): terminal command चलाना (find, cat, grep आदि)
  • patch(hunks): file patch करना, code changes लागू करना
  • todo(tasks): काम की सूची प्रबंधित करना
  • web_nav(url), web_eval(script), web_logs(), web_screenshot() आदि: web navigation, evaluation, logs, screenshots
  • keyword_search(keywords): keyword search
  • codereview(): code review
• bash tool का उपयोग कर यह codebase को दक्षता से explore करता है, और git add/commit जैसे version control काम भी automate करता है
• ऐसे tools के बिना सिर्फ code generation करने वाले LLM से अलग, एजेंट के पास ये विशिष्ट फायदे होते हैं
  • API usage accuracy में बड़ा सुधार (documentation खोजकर सीधे context में शामिल करना)
  • compiler feedback से syntax errors और interface mistakes में कमी
  • dependency/version management की बेहतर क्षमता (विशिष्ट version की विशेषताएँ पहचानना)
  • test failures के जरिए bug detection और test code लिखने की आदत मजबूत होना
  • context window limits से आगे codebase handling (ज़रूरत के हिस्से ही चुनकर पढ़ना)
  • execution results के साथ सीधे प्रयोग: code चलाना, browser page screenshot feedback लेना, CSS auto-adjust करना, server logs से issue trace करना और test जोड़ना
• इसके नुकसान भी हैं
  • एक sentence की request पर ही दसियों हज़ार intermediate tokens (tool calls, web search, repeated tests आदि) बन सकते हैं, और काम में कई मिनट या उससे ज़्यादा लग सकते हैं
  • API cost भी आती है, हालांकि hardware प्रगति के साथ यह धीरे-धीरे कम होने की उम्मीद है
• अंततः बीच का श्रम CPU/GPU कर देता है, जिससे developer का समय बचता है और वह ज़्यादा ऐसे program पूरे कर पाता है जिन्हें वह बनाना चाहता था
• व्यवहार में project में एजेंट लाकर छोटे काम देकर परिणाम देखना आसान है

उदाहरण: Github App authentication development

• यह एजेंट की मदद से sketch.dev के Github App authentication flow को लागू करने का वास्तविक उदाहरण है
  • सिर्फ 3~4 feedback rounds में पूरा authentication flow तेज़ी से पूरा हो गया
  • गलती या requirement सामने आने पर एक साधारण sentence में बताने भर से उसने तुरंत code और behavior सुधार दिए
  • बार-बार होने वाले उबाऊ API integration काम, build system/package management/library setup जैसी व्यावहारिक "छोटी-मोटी मेहनत" को कम करके productivity momentum बनाए रखने में बहुत मदद मिली
• शुरुआती requirement में यह शामिल था कि "प्रति-user token store किए बिना app की global authentication info ही इस्तेमाल करनी है", और एजेंट ने उसी के अनुसार implementation किया
  • लेकिन इसके परिणामस्वरूप गंभीर security vulnerability पैदा हुई (कोई भी सभी repos देख सकता था)
  • समस्या को एक sentence में बताने पर उसने तुरंत user-level permission check जोड़कर fixed commit तैयार कर दिया
• इसके बाद performance problem सामने आई
  • नीचे जैसी संरचना के कारण हर user-repo संयोजन पर API call हो रही थी, इसलिए scalability की समस्या थी

    for install := range allAppInstallations {  
    	for r := range install.Repositories() {  
    		if r.IsCollaborator(user) {  
    			// add to available repositories  
    		}  
    	}  
    }  
    

  • तब समझ आया कि इस समस्या की जड़ मेरी ही requirement थी: "प्रति-user token store नहीं करना"
  • requirement बदलने पर (प्रति-user token store की अनुमति देने पर) एजेंट ने अधिक efficient API call pattern के साथ दोबारा design किया
• इस पूरी प्रक्रिया को लिखकर समझाने में जितने शब्द लगे, उससे कम शब्द लेखक ने Sketch में authentication code पाने के लिए कुल मिलाकर टाइप किए थे
• एक वाक्य में कहें तो, एजेंट आज developers की जगह लेने के स्तर पर नहीं हैं, लेकिन जो दोहराव वाले काम पारंपरिक रूप से कई दिन लेते, उन्हें एक दिन में पूरा कराने में मदद करते हैं
• automation का स्तर ऐसा है कि developer "बच्चे का कमरा साफ़ करते हुए" भी काम आगे बढ़ा सकता है

उदाहरण: JSON-आधारित SQL नियम लागू करना

• एजेंट जिस तरह के काम अक्सर करता है, उनमें से एक था Tailscale से सीखी गई एक अनोखी SQL style को लागू करना
  • हर table में वास्तविक column सिर्फ एक (JSON data) होता था, और बाकी columns JSON से निकले generated columns होते थे
  • उदाहरण table structure:

    CREATE TABLE IF NOT EXISTS Cookie (  
      Cookie   TEXT    NOT NULL AS (Data->>'cookie')  STORED UNIQUE, -- PK  
      UserID   INTEGER NOT NULL AS (Data->>'user_id') STORED REFERENCES User (UserID),  
      Created  INTEGER NOT NULL AS (unixepoch(Data->>'created')) STORED,  
      LastUsed INTEGER AS (unixepoch(Data->>'last_used')) CHECK (LastUsed>0),  
      Data     JSONB   NOT NULL  
    );  
    

  • यह तरीका एक तरह के poor man’s ORM की तरह काम करता है, schema विस्तार आसान बनाता है, और SQL constraints JSON data quality validation में मदद करते हैं
  • नुकसान यह है कि प्रति-row stored data बढ़ जाता है, और सभी INSERT/UPDATE JSON इकाई के रूप में करने पड़ते हैं
• लेकिन एजेंट हमेशा इस style का लगातार एकसमान पालन नहीं कर पाया
  • नया table बनाते समय वह आम तौर पर ठीक करता था, लेकिन exceptions आने पर भ्रमित हो जाता या मनमाने ढंग से style बदल देता
• सरल समाधान: SQL schema file के शीर्ष पर 3 वाक्यों का विवरण जोड़ना
  • एक key sentence जोड़ना कि "हर table में सिर्फ एक वास्तविक Data JSON column होता है, बाकी सभी columns उसी से निकले होते हैं"
  • जो tables इस नियम का पालन नहीं करते, उनमें अलग comment से स्पष्ट करना कि वे exception हैं
  • इसके बाद एजेंट का behavior स्पष्ट रूप से बेहतर हो गया
• दिलचस्प बात यह है कि ऐसे विवरण और comments को वास्तविक human engineers अक्सर नज़रअंदाज़ कर देते हैं या कम उपयोगी मानते हैं,
  • लेकिन LLM-आधारित एजेंट code लिखते समय comments और explanations को सक्रिय रूप से शामिल करते हैं
  • सिर्फ अच्छे विवरण लिख देने से ही code generation quality साफ़ तौर पर बेहतर हो जाती है

“संपत्ति” और “ऋण” code model

• LLM-आधारित code generation tools पर एक आम आलोचना यह है कि code generation अपने आप में पूरे software cost का बहुत छोटा हिस्सा है
  • वास्तविक समय का बड़ा भाग मौजूदा code की dependencies, उलझाव, और जटिल interfaces को संभालने में जाता है
  • बड़े पैमाने, पुराने और बहुत-से users वाले products में maintenance cost अत्यधिक होती है
  • ऐसे वातावरण में LLM से "bubble sort Fortran में लिख दो" कहना खिलौने जैसा या असुविधाजनक व्यवधान जैसा लग सकता है
  • finance के "asset/liability" विचार से तुलना भी की जाती है, लेकिन वह भी पूरी तरह सटीक नहीं बैठती
• लेकिन सारी software engineering सिर्फ ऐसे बड़े, दीर्घकालिक projects तक सीमित नहीं है
  • अधिकांश programs कम users वाले होते हैं या अल्पजीवी projects होते हैं
  • बड़े maintenance अनुभव को पूरे उद्योग की प्रकृति मान लेना ठीक नहीं
• एजेंट का मूल्य सिर्फ code generation तक सीमित नहीं है
  • एजेंट tools और LLM को मिलाकर code पढ़ना, files edit करना, code हटाना/बदलना जैसी change process को automate करता है
  • सिर्फ code जोड़ना ही नहीं, code deletion/refactoring भी स्वाभाविक रूप से कर सकता है
• आखिरकार engineer का लक्ष्य change है
  • change process में driver को बदलाव समझने का अतिरिक्त काम ज़रूर रहता है, लेकिन एजेंट मध्यम आकार के projects तक में gradual change लाने की क्षमता दिखा रहे हैं
  • अभी यह पर्याप्त न भी हो, एजेंट तेज़ी से सही दिशा में विकसित हो रहे हैं
• एक और मत यह भी है कि जटिल languages और build systems project के entry barrier की तरह काम करते हैं
  • code लिखना आसान बनाने वाले tools (LMM, type safety, garbage collection, package management, एजेंट आदि) barrier कम करें तो quality गिरने की आशंका जताई जाती है
  • यदि लक्ष्य change की गति धीमी करना या control बढ़ाना है, तो एजेंट जैसे automation tools उपयुक्त नहीं होंगे

अभी एजेंट क्यों?

• transformer जैसे जटिल AI सिद्धांतों के विपरीत, LLM में feedback loop जोड़ना सहज रूप से स्पष्ट विचार है
  • developer tools के दृष्टिकोण से यह विकास की एक स्वाभाविक दिशा लगती है
  • वास्तव में 1 साल पहले sketch.dev का पहला version भी बस इतना था कि LLM से go tools जोड़े गए थे, लेकिन उपयोगिता में वह आज के एजेंट से बहुत अलग था
  • ML क्षेत्र में भी reinforcement learning (feedback-based learning) 50 साल से अधिक समय से एक मूल सिद्धांत रहा है
• एजेंट का व्यावहारिक उदय LLM के विकास से सीधा जुड़ा है
  • 2023 के LLM में tool calling क्षमता कमज़ोर थी, इसलिए agent की भूमिका सीमित थी
  • 2025 के LLM tool calling और repeated tasks के लिए optimized हैं, इसलिए व्यावहारिक agent उपयोग संभव हो गया है
  • Frontier (अत्याधुनिक commercial) models, tool usage में open models से काफी आगे हैं
  • उम्मीद है कि आने वाले 6 महीनों में open models भी क़रीब पहुँच जाएँगे
  • उपयोगी repeated tool calling की क्षमता ही नवीनतम LLM की सबसे बड़ी बदलती विशेषता है

आगे की दिशा: containers और parallel execution

• LLM एजेंट क्षेत्र अभी भी ऐसा प्रारंभिक और तेज़ बदलाव वाला चरण है जिसे अधिकांश engineers ने वास्तव में अपनाया नहीं है
• इस समय एजेंट मुख्यतः IDE या local repository में चलाने के लिए इस्तेमाल किए जाते हैं
  • VSCode fork या command-line tool install करके आसानी से शुरुआत की जा सकती है
  • लेकिन दो महत्वपूर्ण सीमाएँ हैं
    • पहली, safeguards की कमी: वास्तविक कंप्यूटर में रखे production credentials जैसी sensitive information के exposed होने का जोखिम
      • यदि एजेंट deployment script जैसी कोई अनचाही command चला दे तो गंभीर security incident हो सकता है
      • हर command execution पर manual confirmation माँगा जाता है, फिर भी गलती से sensitive info leak होने की संभावना बनी रहती है
    • दूसरी, parallel execution और automation की सीमा: हर developer को अपने environment में एक बार में एक ही एजेंट चलाना पड़ता है
      • एजेंट की एक run में कई मिनट लग सकते हैं, इसलिए कई tasks साथ चलाना कठिन और अक्षम होता है
• sketch.dev इन सीमाओं का समाधान container environment से करने की कोशिश कर रहा है
  • हर task के लिए isolated development container बनाना, source code की copy रखना, और केवल git commit जैसी चीज़ें बाहर निकालना
  • इससे कई agents एक साथ चलाए जा सकते हैं, और दूसरे agent systems भी इसी दिशा को explore कर रहे हैं
• वास्तविक उदाहरण: Github authentication task के साथ-साथ form UI improvement को अलग agent session में कराना
  • अलग issue tracker entry बनाए बिना, screenshot और एक छोटी request line से form design feedback प्रोसेस करना
  • सिर्फ 30 seconds के निवेश से भी एक निश्चित स्तर से बेहतर परिणाम मिलना
• पिछले 6 महीनों के UX experiments का निष्कर्ष:
  • agent-based development में container (isolated execution environment) सबसे व्यावहारिक विकल्प है

IDE क्या बनेगा?

• agent-based development environment में IDE (integrated development environment) की भूमिका क्या होगी, यह अब भी एक खुला प्रश्न है
  • एजेंट को instruction देकर काम शुरू करना, उसे container environment में चलाना, changes को diff में देखना, और branch/PR में push करना—यह वास्तविक workflow बन सकता है
• व्यवहार में एजेंट द्वारा बनाए गए अधिकांश commits को कुछ न कुछ human cleanup चाहिए होता है
  • शुरुआत में लगभग हर commit में manual fixes चाहिए होती थीं, लेकिन prompt लिखने का कौशल बढ़ने पर edits धीरे-धीरे कम होते गए
  • edits comments बदलने, variable names सुधारने जैसे छोटे कामों से लेकर अधिक जटिल refactoring तक हो सकते हैं
  • container environment में इन सुधारों को कैसे कुशलता से किया जाए, यही मुख्य प्रश्न है
• sketch.dev आदि में परखे जा रहे workflows
  • ऐसा diff view interface जिसमें सीधे edit किया जा सके
    • Sketch के diff screen के दाईं ओर code सीधे edit करने पर वह उसी commit में शामिल होकर तुरंत push हो जाता है
    • छोटे एक-पंक्ति edits के लिए यह बेहद efficient है
  • container पर SSH access देना
    • shell में सीधे जाना या web terminal से code संभालना
    • vscode:// URL से खोलकर पारंपरिक IDE में काम करना
  • code review style comments को सीधे diff पर छोड़ना ताकि वे एजेंट के लिए feedback बन जाएँ
    • code review अनुभव का उपयोग कर आवश्यक विवरण/requirements बहुत कम input में देना
• कुल मिलाकर
  • container environment code generation-modification-validation-review को एकीकृत करता है,
    और सिर्फ code writing से आगे बढ़कर वास्तविक agent-based development संभव बनाता है
  • पहले लेखक container में development नहीं करना चाहता था,
    लेकिन एजेंट द्वारा बनाए गए diff को container में साफ़-सुधारना और बदलना बहुत रोचक और उत्पादक अनुभव निकला

समापन

• LLM-आधारित तकनीकों को सीखने और उन पर प्रयोग करने की प्रक्रिया विनम्रता सीखने का समय रही है
  • पहले multicore, SSD adoption, network scaling जैसी चीज़ों से programming की प्रकृति बदलने पर खुशी मिलती थी,
    लेकिन LLM, खासकर एजेंट, coding की "पूरी प्रक्रिया" को ही बिल्कुल नया बना रहे हैं
  • algorithms, languages, libraries के चयन को प्रभावित करने वाले बदलावों से अलग,
    एजेंट काम करने के तरीके की बुनियादी धारणाओं को ही जड़ से पुनर्विचार कराने पर मजबूर करते हैं
  • कभी-कभी तो ऐसा लगता है कि "अगर programming के बारे में कुछ भी न पता हो और शुरुआत से फिर सीखें, तो शायद बेहतर हो"—इतना बड़ा बदलाव है
  • और यह बदलाव अभी भी जारी है
• जिस तरीके का हम अभी अनुभव कर रहे हैं, वह 6 महीने पहले से भी पूरी तरह अलग है, और अभी स्थिर भी नहीं हुआ है
  • team collaboration, review जैसी development culture की standards भी जल्द बहुत बदल सकती हैं
  • उदाहरण के लिए, सिर्फ औपचारिकता भर रह गए code reviews अब वास्तविक समस्याएँ हल नहीं कर पा रहे हैं
    • code review process को ही नए सिरे से invent करने का समय आ गया है
  • IDE भी, उसकी कथित integration के बावजूद, अब पूरी तरह फिर से गढ़े जाने के मोड़ पर है
  • उद्योग इस बदलाव को पहचान रहा है, लेकिन agent-centric approach अभी बस शुरुआती चरण में है
  • आगे और बड़े बदलाव आने वाले हैं,
    और जिज्ञासा और विनम्रता ही उन्हें अच्छे से पार करने का रास्ता हैं
  • बल्कि अभी तो शायद tech internet forums से दूर रहना,
    और ऐसी चर्चाएँ और summaries भी एजेंट को ही सौंप देना बेहतर हो सकता है

[GN⁺]

Hacker News राय

• मैं ज़्यादातर सिर्फ़ अपने tools के लिए coding करता हूँ, इसलिए मुझे बहुत ज़्यादा merit नज़र नहीं आता कि कोई दूसरा व्यक्ति या कोई और चीज़ मेरी जगह code लिख दे और फिर मैं उसे पढ़ूँ, समझूँ और ठीक करूँ। हाँ, अगर API docs में से मुझे जो चाहिए वह LLM ढूँढ दे तो वह काफ़ी useful है और समय बचाता है। इसलिए LLM का भविष्य का performance बेहतर होगा या नहीं, इससे अलग भी मुझे दूसरों का code पढ़ना अपने-आप में ज़्यादा पसंद नहीं है।

  • मेरे लिए कुछ cases ऐसे हैं जहाँ LLM मददगार है। उदाहरण के लिए, formalized code में macro या code generator की ज़रूरत कम हो जाती है। यह धीमा है और macro की तरह एक बार में सब कुछ update करना मुश्किल है, लेकिन जहाँ code में थोड़े-थोड़े फ़र्क के साथ repeating structure हो, वहाँ macro से भी ज़्यादा LLM काम आता है। और जब कोई ऐसा API इस्तेमाल करना हो जिससे मैं परिचित तो हूँ लेकिन code याद नहीं है, तब Google search करके docs खंगालने की बजाय तुरंत काम किया जा सकता है। मैं typed language इस्तेमाल करता हूँ, इसलिए अगर LLM बकवास भी करे तो type checker या tests उसे पकड़ लेते हैं, इस वजह से ज़्यादा चिंता नहीं होती। और जब 10 से ज़्यादा files में changes चाहिए हों, तब Markdown में change plan बनवा लेना सच में बहुत बड़ा time saver है। आख़िर में, थकान होने पर style या naming rules को नज़रअंदाज़ करना आसान होता है, लेकिन LLM project की existing style को अच्छी तरह बनाए रखता है।
  • आजकल इस तरह काम करना मुझे धीरे-धीरे और अच्छा लगने लगा है। पहले पूरे coding design की planning करता हूँ, फिर LLM को specific steps समझा देता हूँ, और जब तक मैं code पढ़ रहा हूँ, समझ रहा हूँ, ठीक कर रहा हूँ और अगला step plan कर रहा हूँ, तब तक LLM अगले section का code पहले से तैयार करता रहता है। यानी एक तरह से मैं और LLM parallel में काम करते हैं। यह वैसा है जैसे किसी restaurant का chef order आते ही पूरी dish के steps सोच ले और steak पकने का इंतज़ार करने की बजाय दूसरी तैयारी भी साथ-साथ करता रहे। LLM oven या food processor जैसे cooking tool के ज़्यादा क़रीब है। जैसे cheese हाथ से भी grate की जा सकती है, लेकिन food processor में डाल दो तो कुछ मिनट बच जाते हैं। Professional chefs तरह-तरह के tools से multitasking करके efficiency बढ़ाते हैं, और मुझे लगता है आगे चलकर coding भी line-by-line step process की बजाय multitasking structure में बदल सकती है।
  • इस सवाल पर कि मैं अपने code लिखने की ज़िम्मेदारी किसी और चीज़ पर डालकर फिर उसे दोबारा पढ़ने, समझने और ख़ुद ठीक करने में क्या फ़ायदा देखता हूँ, मैं "friction" शब्द इस्तेमाल करता हूँ। बहुत से लोगों को नया काम शुरू करना मुश्किल लगता है, writer’s block की तरह। अगर कोई solution पहले से बना हुआ मिल जाए, तो उसे अपने तरीके से बदलना और modularize करना entry barrier बहुत कम कर देता है। मेरे और मेरे साथियों में कई लोग project को 0 से setup करते समय toolchain configuration और bootstrap से काफ़ी दबाव महसूस करते हैं। LLM को पर्याप्त context और resources मिलें तो वह पूरे codebase को जल्दी scan करके यह भी बता सकता है कि "इस code में audit mechanism पहले से दो जगह हैं, common हिस्सा निकालते हैं" जैसी बातें पकड़ सकता है। जो चीज़ें मैं ख़ुद miss कर देता, उन्हें भी यह अपने-आप ढूँढ सकता है।
  • जिस codebase पर मैं काम करता हूँ, उसमें कई tasks ऐसे होते हैं जहाँ बहुत-सी files में बार-बार छोटे-छोटे changes करने पड़ते हैं। यह काम creativity या challenge से ज़्यादा कई files खोलकर edit करने वाली repetitive labor है। पहले इसमें 3–4 घंटे लगते थे, लेकिन AI agent को task समझा दो तो वह 99% काम अपने-आप कर देता है, और समय सिर्फ़ 3–4 मिनट लगता है।
  • कुछ लोग ऐसे होते हैं जो tools के बिना कुछ कर ही नहीं पाते। यही लोग early adopter और power user बनते हैं और नई खोजें फैलाते हैं। GitHub की value यह थी कि उसने average developers को PR, review, green squares, todo lists वगैरह के ज़रिए productive दिखने का environment दिया। LLM भी average developers को छोटे-मोटे tools और agents चलाकर productive दिखाई देने देता है, इसलिए managers को यह पसंद आता है।

• लेखक ने जो कहा कि code review कमज़ोर है और लगभग सही ढंग से काम नहीं करता, उससे मैं पूरी तरह सहमत हूँ। Agents के code लिखने वाले दौर में असली bottleneck writing नहीं बल्कि code पढ़ना है। अगर लोग review बस सरसरी तौर पर करें या उसे अपनी पसंद दिखाने का माध्यम बना दें, तो agent आसानी से गंभीर security या performance issues डाल सकता है। सच कहूँ तो असली problems सिर्फ़ code पढ़ने से दिखती भी नहीं; उनके लिए ख़ुद debugging करनी पड़ती है या assumptions को manual तरीके से verify करना पड़ता है।

  • सवाल यह है कि agent/AI code इस "कमज़ोर review" problem को किस तरह solve करता है, यह साफ़ नहीं है। लोग ख़ुद code review करना नहीं चाहते और उसे boring मानते हैं। मुझे डर है कि कहीं ऐसा न हो कि मज़ेदार हिस्सा यानी "code लिखना" AI को दे दिया जाए और बदले में हमें endless code reading और verification करनी पड़े।
  • अभी market में सबसे बड़ी कमी यह है कि LLM द्वारा बनाए गए code, diff और पूरे codebase को efficient तरीके से कैसे पढ़ें, ठीक से review करें और समझें। अगर project में इंसान वैसे ही कम हैं, तो चिंता यह है कि बचे हुए लोग code सच में पढ़ भी रहे हैं या बस आगे बढ़ा दे रहे हैं।
  • agent की असली ताकत यह है कि अगर test coverage काफ़ी हो, तो AI code लिख सकता है और साथ ही safety/performance feedback भी पा सकता है। और वही AI tests लिखने में भी मदद कर सकता है।

• आख़िरकार LLM पर कोई यथार्थवादी analysis पढ़ने को मिला। "agent" शब्द से थोड़ी झुंझलाहट होती है क्योंकि यह असल में recursively LLM को call करने वाले for loop को नाम देने जैसा है, लेकिन naming sense इस industry में औसतन पहले भी ख़ास नहीं रही, तो इसे मान ही लेते हैं।

  • "agent" की definition पर मेरी राय लेखक से अलग है। असल में यह LLM है जो tools और resources को (बार-बार) call करते हुए loop में चलता है। फ़र्क़ सूक्ष्म है, लेकिन सवाल यह है कि असली actor किसे माना जाए।
  • "agent यानी loop में tool" — यह phrasing मुझे पसंद आई। याद है Simon ने ऐसा कहा था।
  • OP की agent definition पर मुझे थोड़ी असहमति है। सिर्फ़ इतना नहीं कि LLM loop में है, बल्कि असली बात यह है कि LLM की actions को दूसरे logical components constrain या guide करते हैं। इनमें कुछ deterministic होते हैं और कुछ ML-based होते हैं, LMMs समेत। यानी किसी designed system के भीतर LLM को plan बनाने के लिए मजबूर करना, या code edit के बाद test build और execution trigger करना जैसी चीज़ों से extra usefulness मिलती है। "agent अपने-आप input लेकर चलता है" यह पूरी तरह ग़लत नहीं, लेकिन असल सार यह है कि कई components लगातार LLM के behavior की निगरानी और दिशा-निर्देशन करते हैं।
  • "Agent" नाम अपने-आप में ठीक है क्योंकि लोग इसे सहज रूप से समझ लेते हैं, लेकिन एक वैकल्पिक नाम के तौर पर LoopGPT कैसा रहेगा, ऐसा भी सोचा।

• "हम मानते हैं कि containers programming में useful और necessary हैं" — इस हिस्से के संदर्भ में यह समझाया गया कि Docker बनाने वाले Solomon Hykes ने हाल में Container Use नाम का project open source क्यों किया: ताकि agents को parallel और safely चलाया जा सके। Sketch जैसी कुछ platforms isolated local development environments built-in देती हैं, लेकिन दूसरे coding agents ऐसा नहीं करते। अतिरिक्त जानकारी के लिए YouTube वीडियो भी सुझाया गया है।

• Agentic loop, machine के अंदर दिमाग़, और लगभग rules engine का replacement जैसा लगता है। अभी इसकी अपनी कमियाँ हैं, लेकिन कई experts ने इसकी core nature को ठीक पकड़ा है। "agent को tools से जोड़ो, user request पर prompt दो, बस चलने दो और repeat कराओ, और prompt भी context के हिसाब से dynamically बदलता रहे" — इस तरह human-like interaction या problem solving style की नकल किए बिना भी orchestration/multi-step, vague tasks के replacement या automation में यह काफ़ी useful है। पहले ambiguity को ख़ुद code में implement करना पड़ता था, अब शायद उसकी ज़रूरत कम हो जाए। Production environment में dry run के बिना इसे चलाने को लेकर चिंता रहती है, लेकिन tools और services ख़ुद evolve होंगी, ऐसा लगता है। अगर 100 से ज़्यादा similar services consistent interface के साथ बाहरी दुनिया (e.g. SMS, mail, weather, social आदि) से जुड़ जाएँ, तो आज से कहीं ज़्यादा powerful assistant या उससे भी आगे की चीज़ निकल सकती है।

  • calendar, weather जैसी कई services से agent को जोड़कर game interface बनाने वाला एक दिलचस्प toy project है: लिंक
  • अगर इस्तेमाल होने वाले सभी tools के लिए abstraction एकसमान हो जाए, तो यह मौजूदा assistants से बहुत बेहतर हो सकता है, लेकिन उतनी ही बड़ी outages और errors की संभावना भी स्वीकार करनी होगी। Reliability engineering, quality assurance, access control, security और privacy जैसे मुद्दे आगे और ज़्यादा महत्वपूर्ण होंगे। शायद यही risk management वजह हो सकती है कि Apple ने अभी तक Siri की सीमाओं से आगे जाने वाला modern voice assistant जारी नहीं किया।

• code पढ़ना हमेशा से writing जितना important था, लेकिन अब यह और भी important होता जा रहा है। यह मेरा nightmare है। code लिखना कभी-कभी मज़ेदार होता है, लेकिन code पढ़ना हमेशा labor ही रहता है।

  • फिर भी, "ठीक करने का मज़ा" शायद बना रह सकता है, या उल्टा बढ़ भी सकता है।

• मुझे जिज्ञासा है कि agents इस्तेमाल करने वालों में कितने लोग सच में "programming" — यानी problem-solving style पर सोचना और उसे code में व्यक्त करने की ख़ुशी — को पसंद करते हैं। आजकल agent-based work में तो वह process ही ग़ायब होता दिखता है, और उसकी जगह natural language में requirements समझाकर बस यह उम्मीद की जाती है कि LLM bugs न बनाए।

  • मैं ख़ुद coding को enjoy करता हूँ, और जब LLM ने एक parser एक ही बार में बना दिया जो मुझे मज़ेदार लगता, तो थोड़ा खालीपन भी महसूस हुआ। फिर भी, समय खा जाने वाला parser लिखने की बजाय बड़े goals पर ध्यान दे पाना फ़ायदेमंद रहा। सिर्फ़ मनचाहे type/function signatures लिखकर LLM से detailed implementation भरवा लेना और फिर तुरंत अगले step पर बढ़ जाना — यह काफ़ी प्रभावशाली था। पहले जो बड़े-scale edits "करना चाहिए लेकिन बहुत झंझट है" वाले स्तर पर अटक जाते थे, अब code polishing, test generation, README sync और refactoring ideas तक में LLM मदद कर देता है, इसलिए project की completeness और ambition दोनों बढ़ जाते हैं। सही mindset हो तो software बनाने का मज़ा लेने वाले builders के लिए यह लगभग स्वर्ग जैसा हो सकता है।
  • दूसरी तरफ़, जिन problems को हज़ारों बार implement किया जा चुका है, उन्हें मैं अपने हाथ से फिर से लिखना ज़रूरी नहीं मानता। ऐसे में मैं dictionary इस्तेमाल करूँगा, नई hashtable नहीं बनाऊँगा। अगर मैं कहूँ "इस language compiler को बना दो" या "DFS से solve करो" और perfect result मिल जाए, तो भी शायद programming का मज़ा कम न हो। हाँ, natural language में computing process को describe करना complex स्तर पर inaccurate या contradictory हो सकता है — यह उसकी सीमा है। फिर भी, किसी भी पक्ष का कोई व्यक्ति LLM को बिना सोचे-समझे इस्तेमाल करने की सलाह नहीं दे रहा; आख़िरकार result की ज़िम्मेदारी मुझे ही लेनी है।
  • natural language programming के लिए उपयुक्त नहीं है, इसके प्रमाण के तौर पर EWD667 का हवाला दिया गया। सच है कि LLM अभी stackoverflow-style question-answer में उपयोगी है, लेकिन आगे चलकर अगर SO का data कम हो गया, तो उस उपयोगिता की भी सीमा आ सकती है।
  • मैं इससे सहमत नहीं हूँ। LLM जो काम करता है, उसका बड़ा हिस्सा repetitive और boring implementation work होता है। मैं अब भी project architecture और वे creative या difficult हिस्से, जो LLM के लिए भी कठिन हों, ख़ुद design करता हूँ। एक साल बाद स्थिति कुछ और हो सकती है, लेकिन फ़िलहाल मैं उन हिस्सों पर focus कर पा रहा हूँ जिन पर सच में सोचना पड़ता है, और इससे संतुष्ट हूँ।
  • लेखक ख़ुद बोल रहा हूँ: मुझे programming भी पसंद है, और agents भी।

• coding करते समय कुछ areas हैं जहाँ मुझे AI इस्तेमाल करना पसंद है (यह सचमुच मैंने ही लिखा है!):

  • CSS: किसी भी website में CSS work मुझे नापसंद था, लेकिन AI को complex CSS tricks तक सब याद रहता है, इसलिए काम का समय घट जाता है। उदाहरण के लिए, किसी complex WordPress setup में किसी specific div को center align करना भी कुछ trial-and-error के बाद जल्दी हो जाता है।
  • unit tests: जब AI का embedded code data बहुत पुराना न हो, तब test generation भी एक मज़ेदार अनुभव हो सकता है।
  • commit summary: first draft तक के लिए काफ़ी usable है।
  • बहुत छोटे first-year स्तर के assignments भी तेज़ी से कर सकता है।
  • दिलचस्प बात यह है कि मेरे अनुभव में AI CSS उतना अच्छा नहीं लिखता, इसलिए कभी-कभी बेकार लगा। लेकिन जो काम आपको पसंद नहीं, उसे यह संभाल ले — इस बात से पूरी तरह सहमत हूँ। मेरे लिए ऐसा काम ticket descriptions लिखना है, और उसमें AI मुझसे कहीं बेहतर है।
  • अगर मैं ग़लत समझा हूँ तो माफ़ कीजिए, लेकिन अगर आप recent CSS trends से अपडेट नहीं हैं, तो आज का CSS पहले की तुलना में काफ़ी कम complex और ज़्यादा manageable हो गया है। कुछ घंटे लगाकर modern CSS देखना recommend करूँगा। फिर भी, मैं ख़ुद styling के लिए AI बहुत इस्तेमाल करता हूँ।

• "assets" और "liabilities" वाला हिस्सा दिलचस्प था, लेकिन मैं उससे सहमत नहीं हूँ। बहुत से programs कुछ ही users के लिए शुरू हुए और बाद में बड़े projects बन गए। अतीत में मैंने बार-बार देखा है कि one-off के तौर पर जल्दी में लिखा गया scientific code अनजाने में बहुत लंबे समय और बड़े दायरे तक फैल गया। इसलिए मैं अपना code इस सोच के साथ लिखता हूँ कि वह ज़्यादा समय तक और ज़्यादा व्यापक रूप से इस्तेमाल हो सकता है, और ऐसा मैं अपने लिए और दूसरों के लिए consideration के साथ करता हूँ। अगर आपने कभी किसी सहकर्मी का personal side project manager द्वारा team project में बदला हुआ देखा है, तो आप इस समस्या को समझेंगे।

  • फिर भी सवाल रहता है: "विकल्प क्या है?" लोग अच्छी तरह भविष्यवाणी नहीं कर पाते कि क्या व्यापक रूप से अपनाया जाएगा। अक्सर मेहनत से बनाया गया project कहीं इस्तेमाल नहीं होता, जबकि ढीले-ढाले लेकिन जल्दी बने project के सफल होने की evolution pressure ज़्यादा होती है। इस संदर्भ में "worse is better" वाला classic essay याद आता है (लिंक)।

• मुझे लगता है कि LLM का असली killer feature code writing/design नहीं बल्कि code review हो सकता है। अभी code review ख़ुद कई मायनों में टूटा हुआ है, और आगे security, undefined behavior, feature misuse, compiler warnings की double-checking जैसी चीज़ों में LLM की उपयोगिता और बढ़ सकती है। मैं ख़ुद LLM को search-engine style में error diagnosis या debugging के लिए ज़्यादा इस्तेमाल करता हूँ, जहाँ accuracy लगभग 50% रहती है — और मेरे लिए यह काफ़ी संतोषजनक है।

  • ChatGPT उन debugging मामलों में पहले से काफ़ी शानदार है जो web पर बहुत discuss हो चुके हैं। यह stack overflow के ज्ञान को summarize और consolidate कर देता है, इसलिए individual cases ढूँढने का समय बचता है। हालाँकि LLM के answers में hallucination की वजह से कुछ noise रहता है, और अगर पूरे code की review कराई जाए तो यह error patterns या problematic functions/calls अच्छी तरह पकड़ सकता है, लेकिन false positives भी काफ़ी होंगे। सच में लोग LLM को automated code review में कितनी अच्छी तरह उपयोग कर रहे हैं, यह जानने की जिज्ञासा है।
  • अगर आप बार-बार "इस code को review करो" जैसा prompt देते हैं, तो chatbot कभी X को Y में बदलने को कहता है और थोड़ी देर बाद फिर Y को X करने को कह देता है। code review में कुछ हद तक फ़ायदा होता है, लेकिन किस suggestion को मानना है और किसे नहीं, यह निर्णय ख़ुद लेना पड़ता है। जिन लोगों में पर्याप्त discernment है, उनके लिए यह वास्तव में candidate changes सुझाकर productivity बढ़ा सकता है।
  • हैरानी होती है कि इस विषय पर और ज़्यादा चर्चा क्यों नहीं होती। मेरे आसपास developers का technology में interest अलग-अलग स्तर का है। आमतौर पर कम experience वाले लोग इसे ज़्यादा actively इस्तेमाल करते हैं और senior लोग कम दिलचस्पी दिखाते हैं। code review/verification में AI उपयोग की चर्चा लगभग सुनने को नहीं मिलती; शायद commit के समय अपने-आप चलने वाली functionality की ज़रूरत होगी।
  • code review/design से अलग, code review-specialized LLM पहले से Github Copilot में reviewer mode के रूप में मौजूद है। यह अभी top-tier नहीं है, लेकिन loop में रखकर इस्तेमाल करने लायक़ quality ज़रूर है।
  • सहमत, हम sourcery.ai पर इसी तरह की चीज़ पर काम कर रहे हैं।