दो चीज़ें जिनमें LLM coding agents अब भी कमजोर हैं

 (kix.dev)
8 पॉइंट द्वारा GN⁺ 2025-10-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • LLM coding agents copy-paste जैसे code moving tasks को स्वाभाविक रूप से नहीं कर पाते
  • code refactoring के दौरान याददाश्त पर निर्भर code writing शैली की वजह से consistency सुनिश्चित करना मुश्किल होता है
  • समस्या सुलझाने की प्रक्रिया में ये लगभग सवाल नहीं पूछते और अनुमान-आधारित कोशिशें करते रहते हैं
  • मानव developers स्थिति अस्पष्ट होने पर सवाल पूछकर समस्या को स्पष्ट करते हैं, लेकिन LLM दीवार से टकराने तक कोशिश दोहराता रहता है
  • इन विशेषताओं की वजह से LLM agents को मानव developer का विकल्प नहीं, बल्कि सिर्फ़ आत्मविश्वास से भरे intern स्तर का माना जाता है

LLM coding agents की प्रमुख सीमाएँ

हाल में LLM को coding सहायता टूल के रूप में इस्तेमाल करने की कोशिशें बढ़ी हैं, लेकिन अभी भी कई बातें मानव developers को अस्वाभाविक लगती हैं। यह लेख खास तौर पर उन दो कारणों को साफ़ तौर पर समझाता है जिनकी वजह से LLM coding agents असहज अनुभव देते हैं

1. code moving और refactoring के तरीके की अस्वाभाविकता

  • LLM असल 'copy-paste' क्रिया नहीं करता
    • उदाहरण के लिए, किसी बड़े file को छोटे files में refactor करने को कहने पर LLM code block के कुछ हिस्सों को 'याद' रखता है, फिर मूल file में delete कमांड इस्तेमाल करते हुए नए file में उस 'याद रखे' code को write कमांड से लिखता है
    • 'cut' या 'paste' टूल का उपयोग करने के बजाय, सारे बदलाव memory से पुनर्निर्मित होते हैं
    • मानव developer code move करते समय 'copy-paste' के ज़रिए code match होने का भरोसा रखता है, लेकिन LLM यह गारंटी नहीं देता
    • अब तक सिर्फ़ Codex ने sed या awk कमांड का इस्तेमाल करके मानव के 'copy-paste' व्यवहार की नकल करने की कुछ कोशिश दिखाई है, लेकिन वह भी पूरी तरह सफल नहीं है

2. बिना सवाल पूछे समस्या हल करने का तरीका

  • LLM की problem-solving प्रक्रिया भी मानव से बहुत अलग है
    • LLM लगभग कोई सवाल नहीं पूछता और कई assumptions के आधार पर समस्या हल करने की कोशिश करता है
    • मानव developers बड़े बदलावों या अस्पष्ट स्थिति में हमेशा सवाल पूछकर स्थिति की पुष्टि करते हैं, और 'कोई सवाल बुरा नहीं होता' जैसी सोच के साथ काम करते हैं
    • इसके उलट LLM लगातार कोशिश दोहराता रहता है, और समस्या आने पर उसी को और ज़ोर से दोहराता है
    • prompts को बहुत अधिक design करके उससे सवाल पूछवाए जा सकते हैं, लेकिन Roo जैसे कुछ tools को छोड़कर ऐसा व्यवहार कम ही दिखता है
    • मूल कारण यह भी हो सकता है कि LLM बनाने वाली कंपनियों ने 'तेज़ी से code लिखने' पर केंद्रित RL (reinforcement learning) लागू किया है

निष्कर्ष

  • इन विशेषताओं की वजह से LLM अभी मानव developers की जगह लेने के लिए पर्याप्त नहीं हैं
  • वास्तविक काम में इनकी क्षमता 'ज़रूरत से ज़्यादा आत्मविश्वासी intern' जैसी दिखती है
  • यही वजह है कि LLM के साथ collaboration का अनुभव अब भी पूरी तरह स्वाभाविक नहीं लगता

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-10
Hacker News राय

  • कुछ समय पहले एक दिलचस्प अनुभव हुआ। यह कोड से जुड़ा नहीं था, लेकिन कोड या उससे जुड़े क्षेत्रों में आसानी से हो सकने वाली बात थी (असल में एक सहकर्मी के साथ भी ऐसा हुआ)। HN पर इस बात पर चर्चा चल रही थी कि 15 साल पहले पारित एक regulation को अधिक सामान्य रूप से क्यों नहीं अपनाया गया। मैंने अनुमान लगाया कि उस समय की तकनीकी क्षमता सामान्य मामलों को संभालने के लिए पर्याप्त नहीं थी, इसलिए शायद regulation सिर्फ उन्हीं हिस्सों पर लागू किया गया जो तब संभव थे (संबंधित टिप्पणी)। कुछ घंटों बाद जब मैंने चर्चा फिर देखी, तो कुछ लोग कह रहे थे कि उस दौर में भी वह तकनीक पर्याप्त सस्ती थी। इसलिए मैंने LLM से इस विषय पर evidence ढूँढने को कहा, और उसने जवाब दिया कि कारण तकनीकी सीमाएँ थीं। जब मैंने उसके cited sources जाँचे, तो वास्तव में तकनीकी सीमाओं की बात सिर्फ एक ही source में थी — और वह source HN पर मेरी अपनी टिप्पणी थी। जब मैंने यह बात दफ़्तर में बताई, तो एक सहकर्मी ने कहा कि उसने GitHub पर “Windows पर X कैसे काम करता है” इस बारे में एक राय लिखी थी, और बाद में Google search करने पर LLM-आधारित उत्तर उसी राय को आधार बनाकर वही बात दोहरा रहे थे। इसलिए अब मन करता है कि LLM से “X कैसे काम करता है?” न पूछकर, “अगर कोई X के काम करने के तरीके के बारे में पूछे, तो cite करने लायक links की सूची दिखाओ” जैसा पूछा जाए

    • मुझे लगता है कि इस तरह प्रश्न पूछना "sorting prompt" जैसा है। यह technique मैंने Mike Caulfield की इस पोस्ट से सीखी, और मैं इसे कोड लिखते समय भी इस्तेमाल करता हूँ (उदा.: Claude code slash command)। अगर LLM से सिर्फ जवाब न माँगकर research, classification और evaluation करवाया जाए, तो परिणाम कहीं अधिक सटीक मिलते हैं

    • ज़्यादातर लोग भी HN पर किसी विषय की टिप्पणियाँ पढ़ते समय इस तरह भरोसा कर लेते हैं कि “लगता है यह व्यक्ति कुछ जानता है, तो अभी के लिए इसे तथ्य मान लेते हैं।” प्रत्यक्ष अनुभव या verified knowledge हासिल करना वास्तव में बहुत महँगा पड़ता है, इसलिए मुझे लगता है कि इस तरह का 'सस्ता ज्ञान' भी आखिरकार मूल्यवान है

    • मैंने LLM से evidence माँगकर देखा है, लेकिन अब तक ऐसा एक भी मौका नहीं आया जब उसने वास्तव में अपनी कही बात को support करने वाला असली evidence दिया हो

    • LLM कभी-कभी links तक गढ़ लेता है। इसे सच में research करवाने के लिए deep research mode चाहिए, और फिर भी link में दी गई जानकारी की उसकी व्याख्या अंततः उसके training से प्रभावित रहेगी

    • हाल ही में मैंने NotebookLM में 6–8 भरोसेमंद sources (IETF, OpenID specs और अतिरिक्त दस्तावेज़) डाले और एक बहुत सरल सवाल पूछा: “OID4VP कौन-कौन से credential formats की अनुमति देता है?” जवाब का 90% सही था, लेकिन उसने पूरे आत्मविश्वास के साथ एक बिल्कुल random format भी जोड़ दिया जिसका कोई आधार नहीं था, जैसे वह खुद spec का लेखक हो। मुझे शक हुआ तो मैंने खुद spec देखा, और तुरंत समझ आ गया कि वह झूठ था। अब तो "grounded" LLM पर भी तथ्यात्मक भरोसा पूरी तरह टूट चुका है

  • हाल ही में मैंने Codex CLI से एक HTML file refactor करवाई, लेकिन उसने मेरी अपेक्षा के अनुसार code copy-paste नहीं किया। उसकी जगह LLM ने याददाश्त के आधार पर code फिर से लिखा और comments भी हटा दिए। एक section में लगातार 40 complex links थे। deploy से ठीक पहले अंतिम जाँच के लिए मैंने उन्हें एक-एक करके खोला। शुरू के links ठीक थे, लेकिन बीच से 31 links सब के सब 404 दे रहे थे। domain सही था, सिर्फ URL path बदल गया था। जब मैंने git commit में पुराना URL देखा, तो पता चला कि LLM ने URL को "hallucinate" करके ऐसे path में बदल दिया था जो अस्तित्व में ही नहीं था। इस तरह की सूक्ष्म और चुपचाप घुस आने वाली गलती सच में खतरनाक है। बहुत सावधान रहना चाहिए

    • मुझे लगता है कि आख़िरी point बहुत महत्वपूर्ण है। “बहुत सूक्ष्म और चुपचाप घुस आने वाली गलतियों” की वजह से, भले ही LLM इंसान जितना या उससे बेहतर काम कर ले, उसे उसी तरह process नहीं किया जा सकता। खासकर code review पारंपरिक रूप से समस्याओं को रोकने की महत्वपूर्ण परत रही है, लेकिन अगर यहाँ review की जाने वाली error types बदल जाएँ, तो पुरानी code review पद्धति अप्रभावी हो जाती है। पहले जब बड़े पैमाने पर code move होता था, तो यह मान लेना संभव था कि block जस का तस move हुआ है और review में ऊँचे स्तर की बातों पर ध्यान दिया जा सकता है। लेकिन LLM refactor में "moved" code वास्तव में summarized/reconstructed "नया" code हो सकता है, इसलिए हर character देखना पड़ता है। इसीलिए मुझे लगता है कि Pull Request description में "AI usage" section होना चाहिए, ताकि यह hint मिले कि कहाँ और कैसे AI का इस्तेमाल हुआ और review में किन हिस्सों पर ज़्यादा ध्यान देना है

    • मुझे भी कोड और research questions में ऐसा अक्सर हुआ है। LLM शुरुआत में अच्छा काम करता है, लेकिन Nवीं बार के बाद मनमाने तरीके से चीज़ें गढ़ने लगता है। हाल ही में यात्रा से पहले मैंने Gemini से breweries की updated list माँगी, लेकिन उसने ऐसी जगहें भी शामिल कर दीं जो बंद हो चुकी थीं या सिर्फ अस्थायी रूप से चल रही थीं। मैंने उससे opening hours links जोड़ने और बंद हो चुकी जगहें हटाने को कहा, तो उसने list के शुरुआती हिस्से में ही बदलाव किए, बाकी हिस्से में या तो पूरी तरह असंबंधित edits किए या बंद जगहों को हटाया ही नहीं। फिर भी हर बार पूरे आत्मविश्वास से कहता रहा कि उसने सब कुछ ठीक से research किया है

    • यह कोड की बात नहीं है, लेकिन एक बार मैंने LLM से सिर्फ event notice की spelling/grammar जाँचने को कहा। उसने हल्का-सा edited version भेजा, लेकिन चुपके से तारीख़ एक दिन आगे खिसका दी। शुक्र है मैंने देख लिया और ठीक कर दिया। इससे यही सीख मिली कि बहुत सरल कामों में भी आँख बंद करके भरोसा नहीं करना चाहिए। एक आसान और स्पष्ट one-line prompt होने पर भी, LLM कभी चौंकाने वाली चीज़ें कर देता है, और कभी सबसे सरल बात में भी अप्रत्याशित गलती कर देता है

    • 5 मिनट पहले मैंने Claude से सिर्फ code में debug statements जोड़ने को कहा था, और उसने चुपचाप regex बदल दिया। diff में तो पकड़ में आ गया, लेकिन बड़े changes में यह आसानी से छूट सकता है

    • deploy से ठीक पहले 40 links दोबारा जाँचना समझदारी थी। लेकिन यह सुनकर थोड़ा आश्चर्य हुआ कि Codex के पूरा करने के बाद तुमने 'git diff' देखे बिना सीधे master पर push कर दिया

  • मैं उस पोस्ट के दावे से सहमत हूँ। लेकिन मेरे हिसाब से सबसे बड़ी समस्या यह है कि agent code repository का बहुत छोटा हिस्सा ही देखता है। उसे पहले से मौजूद helper functions का पता नहीं होता और वह वही चीज़ बार-बार नई बना देता है। UI development में वह पूरे UI structure की तुलना नहीं कर पाता, इसलिए inconsistent code बार-बार बनता है। आखिरकार इंसान को ही सही context देना पड़ता है, जैसे “इस file के helper functions देखो”, “इसी implementation की तरह करो”, “यह document ज़रूर पढ़ो”। अगर आप खुद उचित context दे दें, तो agent की उपयोगिता काफ़ी बढ़ जाती है। एक और समस्या यह है कि बड़े monorepo में folder structure explore करने में यह बहुत कमजोर होता है; उदाहरण के लिए subdirectory से 'npm test' चलाना भी कई बार ठीक से नहीं कर पाता

    • यह ठीक वही समस्या है जो मैं भी झेलता हूँ। हाल ही में मैंने Cursor से implement कराया हुआ करीब 200 lines का नया feature review किया, और असल में ज़रूरी code बहुत कम निकला। utility library में पहले से मौजूद functions ढूँढना बहुत झंझट भरा होता है, इसलिए अक्सर उसे जाने देता हूँ। 5 साल पहले ऐसे review का बड़ा हिस्सा नए developers के onboarding जैसा होता था, इसलिए उन्हें यह दिखाना महत्वपूर्ण होता था। लेकिन आजकल Cursor जैसी चीज़ों की वजह से code की मात्रा बढ़ती जा रही है, जबकि developer खुद भी structure समझता है और कभी-कभी company policy के कारण जानबूझकर ऐसा किया जाता है, इसलिए productivity गिरती हुई लगती है

    • 'npm test' जैसे commands को subfolder से चलाना हमेशा समस्या रहा है। Vite/React frontend और .NET backend में बँटे repo में, अगर npm command fail हो जाए तो यह panic mode में चला जाता है और कई बार दोहराने के बाद भी हल नहीं करता, बस बेकार troubleshooting करता रहता है। एक बार मैंने 'CLAUDE.md' में यह निर्देश भी लिखा कि हमेशा पहले current directory check करे, लेकिन फिर भी यह random तरीके से path भूलता रहा। इसलिए मैंने 'run-dev server restart', 'run-dev client npm install' जैसे aliases जोड़ दिए जो किसी भी directory से काम करें, और शुद्ध dotnet/npm जैसे commands को deny list में डाल दिया, ताकि AI को project docs देखकर वही aliases इस्तेमाल करने पड़ें। यह तरीका कुछ हद तक stable रहा, लेकिन यहाँ तक पहुँचने में बहुत समय, मेहनत और stress लगा

    • मुझे लगता है कि बड़े context models अगर tool calls के साथ इस्तेमाल हों तो अच्छा होगा। Gemini chat पूरे GitHub repo को ingest कर सकता है। क्या ऐसा 'not-invented-here' tool हो सकता है जो नया function लिखने से पहले यह जाँच ले कि वही चीज़ codebase में पहले से मौजूद तो नहीं? हालाँकि, पहले यह भी देखना पड़ेगा कि शायद किसी ने ऐसा tool पहले ही बना दिया हो

    • यही वजह है कि claude.md जैसे documents की ज़रूरत पड़ती है। अगर हमें अपने नियमों का पालन करवाना है, तो documentation अनिवार्य है

    • सच कहूँ तो यह स्थिति वैसी ही है जैसी किसी senior engineer को वास्तविक काम में साथियों के साथ काम करते हुए अक्सर झेलनी पड़ती है

  • पोस्ट में उद्धृत हिस्से से मैं पूरी तरह सहमत हूँ। मैं भी मानता हूँ कि LLM अभी top-level developers की जगह नहीं ले सकता। कोई भी समझदार व्यक्ति इस समय ऐसा दावा करे, यह मुझे बेतुका लगता है। लेकिन मेरे हिसाब से कमज़ोर या औसत स्तर के developers पहले ही replace हो रहे हैं। उदाहरण के लिए, हमारे संगठन में 6 महीने के bootcamp से आए 3 लोग थे। उस समय अच्छे developers मिलना बहुत मुश्किल था, इसलिए हमने उन्हें hire किया। लेकिन व्यवहार में वे बहुत आसान tasks में भी संघर्ष करते थे, और हर बार मुझे review में उनका code लगभग पूरा साफ़-सुथरा करना पड़ता था। बाद में AI tools बहुत तेज़ी से बेहतर हुए और उन्होंने इन लोगों के performance को पीछे छोड़ दिया। अंततः 2 लोगों को निकाल दिया गया और 1 ने खुद इस्तीफ़ा दे दिया। हाल के दिनों में हम junior developers को लगभग hire ही नहीं कर रहे, और bootcamp graduates को तो बिल्कुल नहीं लेने वाले। आसपास भी हालात ऐसे ही हैं, शायद इसी वजह से bootcamp industry खुद ही सिमटती जा रही है। AI आगे चलकर अच्छे developers तक को replace कर पाएगा या नहीं, यह नहीं पता, लेकिन मौजूदा डेटा साफ़ दिखाता है कि प्रगति बेहद तेज़ है। नकारात्मक राय देना वास्तविकता से मुँह मोड़ना है। अमेरिका के शुरुआती दौर में 90% आबादी agriculture में थी, आज 2% है। फिर भी food production और diversity पहले से कहीं ज़्यादा है। यह सब technological progress का परिणाम है। मुझे लगता है कि बहुत तेज़ी से ऐसा ही कुछ software development industry में भी हो सकता है

    • बेशक technology ने food production बढ़ाई है, लेकिन सच यह भी है कि पोषण मूल्य घटा है और toxicity बढ़ी है

    • मुझे जिज्ञासा है कि आपके हिसाब से bootcamp graduates आगे क्यों नहीं बढ़ पाए

  • इससे भी बड़ा सबक यह है कि LLM काफ़ी साधारण tasks में भी पर्याप्त निर्देश और supervision के बिना बहुत नाज़ुक साबित होता है। मेरे छोटे project (2.5K lines) में मैंने parser refactor करने को कहा। योजना ऊपर-ऊपर से ठीक लग रही थी। मैंने step-by-step checkpoints बनाकर क्रम से काम कराया, लेकिन हर बार जब मैंने पूछा, “क्या पुरानी structure हटाई गई?”, “क्या उसे नई structure से replace किया गया?”, जवाब यही मिला: “नहीं, वह वैसे ही बनी हुई है।” 80% tests fail हो गए, और जब मैंने ठीक-ठीक correction direction भी बताया, तब भी "refactor" जैसे abstract task में यह बार-बार उसी तरह fail होता रहा। आख़िरकार इतना detailed निर्देश देना पड़ता है कि “कौन-सी class में क्या बदलना है” तक लिखना पड़े। अगर हालत यह है, तो इसे independently काम नहीं दिया जा सकता, और LLM इस्तेमाल करने का मतलब ही काफी कम हो जाता है

    • मेरा अनुभव थोड़ा अलग है। मैंने TypeScript में बना expression tree parser (tinqerjs.org) खुद एक भी line लिखे बिना, सिर्फ Codex+Claude की मदद से 2 हफ्तों (part-time) में पूरा किया, और सैकड़ों tests (duplicates सहित) भी जुड़ गए। मैंने ORM भी बनाया है, और LLM से कम-से-कम 4–10x समय की बचत हुई। लगभग supervision की ज़रूरत नहीं पड़ी। इसलिए मुझे लगता है कि नतीजे इस बात पर निर्भर करते हैं कि उपयोग का उद्देश्य क्या है और process कितना स्थापित है। LLM का अच्छा उपयोग करने वाले developers अपने-अपने unique workflows बना रहे हैं, लेकिन उनमें एक common बात है: testing, documentation और code review पर ज़ोर

    • “अगर refactor instruction इतना detailed देना पड़े तो उपयोग का मतलब नहीं” वाली समस्या को शायद इस तरह देखना चाहिए कि “अगर मैं high-level steps को अच्छी तरह तोड़कर निर्देश दूँ, तो यह मेरे अकेले करने से कहीं तेज़ है”

    • यह भी उसी बात से जुड़ता है जो पोस्ट में कही गई थी कि AI cut-paste नहीं करता, बल्कि delete/regenerate करता है। वास्तव में code का थोड़ा-थोड़ा drift होना शायद अपरिहार्य है

    • जानना चाहूँगा कि आपने कौन-सा model/tool इस्तेमाल किया। Cursor या Copilot के साथ भी मैंने ऐसे छोटे refactor में लगातार supervision की ज़रूरत महसूस की है

  • LLM की उपयोगिता निश्चित रूप से है। उदाहरण के लिए, आज सुबह मैंने PDF Metadata parser का bug LLM की मदद से बिना PDF spec में गहराई तक उतरे ही ठीक कर लिया। लेकिन ज़्यादातर मामलों में output मेरे खुद करने की तुलना में कम efficient होता है। पहले मैंने Codex Code से unit tests लिखवाने की कोशिश की थी। मैंने कई setups बनाए थे, लेकिन data mocking झंझट वाला था इसलिए उससे करवाया। 8 बार कोशिश करनी पड़ी, manual fixes भी करने पड़े, और वह यह तक नहीं समझ पाया कि entity obsolete हो चुकी है और service में अब उपयोग ही नहीं होती। कुल मिलाकर अनुभव निराशाजनक था। यह developers को पूरी तरह replace करने के लिए पर्याप्त नहीं, लेकिन जैसे Stack Overflow पहले करता था, वैसे unfamiliar topics में knowledge exposure और solution direction देने में यह काफ़ी अच्छा है

    • मुझे लगता है कि अभी भी LLM अपने आप में काफ़ी संभावनाशील है। लेकिन असली जादू coding agents के साथ उसके मेल से आता है। अगर सही tools तैयार हों, model integration और iteration हो, तो copy-paste भी लागू किया जा सकता है, और आज की ज़्यादातर कमियाँ अच्छे context, स्पष्ट instructions, iterative validation और मज़बूत agent architecture से पूरी की जा सकती हैं। तेज़ response, बड़ा context, और instructions पर अच्छी पकड़ रखने वाला model हो तो अनुभव और बेहतर हो जाता है। और इंसान की prompting skill भी बहुत महत्वपूर्ण है। अंततः अच्छी software engineering capability, खासकर दूसरे developers को काम सौंपने की क्षमता, और codebase के भीतर AGENTS.md (या CLAUDE.md) जैसे निर्देश तथा best practices की documentation चाहिए। निष्कर्ष यह है कि “AI/LLM developers को replace कर पाएगा / नहीं कर पाएगा” जैसी बहस अब उबाऊ हो गई है। असली सवाल यह है: “मैं अपने LLM के लिए क्या कर सकता हूँ?”

  • मुझे नहीं लगता कि “ऐसे prompts जो प्रश्न को अधिक स्पष्ट बनवाएँ” को over-engineering कहना चाहिए। उल्टा, prompt में यह design करना कि ‘अगर बात स्पष्ट न हो तो पहले सवाल पूछो’, बहुत प्रभावी साबित हुआ है। एक अच्छा programmer खुद समझ सकता है कि specification पूरी तरह दी गई है या और clarification चाहिए, और AI को पहले से ज़रूरी follow-up questions पूछने के लिए प्रेरित किया जा सकता है

    • आप यह भी तय कर सकते हैं कि उसे कितने सवाल पूछने हैं। जटिल विषयों में मैं पहले से 20–30 सवाल माँगता हूँ, और नतीजे काफ़ी संतोषजनक होते हैं। ऐसी QnA को अलग file में सहेजकर अगली session या किसी दूसरे agent के साथ reuse करना भी उपयोगी है

    • इसी वजह से अब मैं पहले की तरह लंबे prompts नहीं लिखता। बस idea फेंक देता हूँ और लिखता हूँ, “ज़रूरत हो तो सवाल पूछो”, और यह अक्सर उन बिंदुओं को पकड़ लेता है जिनके बारे में मैंने सोचा भी नहीं होता

  • पोस्ट में copy-paste वाली बात देखकर प्रेरणा मिली और मैंने clippy (macOS utility) में agent buffer tool जोड़ दिया। clippy के पास MCP server है जो system clipboard के साथ interact करता है, लेकिन इस बार अलग private buffer उपयुक्त लगा। जो features जोड़े गए वे हैं: buffer_copy (file से specific line range copy करके private buffer में सहेजना), buffer_paste (buffer में मौजूद exact bytes को target file में insert/replace करना), और buffer_list (buffer की सामग्री देखना)। उदाहरण के लिए, अगर agent कहे “auth.py की line 50–75 copy करो”, तो server सीधे file I/O करता है; token generation या hallucination की कोई गुंजाइश ही नहीं रहती। system clipboard भी प्रभावित नहीं होता। पहले AI-generated code को सीधे clipboard में copy करके उपयोग किया जा सकता था। clippy का मूल उद्देश्य macOS pbcopy को बेहतर बनाना है — यानी वास्तविक file content copy करके terminal से Slack या email में असली file को paste करना। macOS पर Claude जैसे MCP-compatible agents इस्तेमाल करने वाले लोग यहाँ देख सकते हैं। इसे brew install neilberkman/clippy/clippy से install किया जा सकता है

  • ज़्यादातर developers भी सवाल ठीक से नहीं पूछ पाते। वे बहुत-सी चीज़ों को obvious मानकर छोड़ देते हैं। 25 साल के development अनुभव में मुझे लगा कि आधे से ज़्यादा सहकर्मियों में दूसरी कमी थी। मैं खुद भी अपने career के आधे हिस्से तक ऐसा ही था, इसलिए यह बात ज़्यादा resonate करती है

    • फिर भी, लोगों का self-driving cars या AI से इंसानों से भी ऊँची reliability चाहना एक स्वाभाविक बात है। “इंसान भी यह नहीं कर सकते” जैसा बचाव ऐसे लोगों पर खास असर नहीं डालता। व्यक्तिगत रूप से मुझे यह रवैया काफ़ी समझ में आता है

  • जैसा पोस्ट में कहा गया कि "LLMs copy-paste (या cut-paste) नहीं करते", वे कोड को याद करके delete करते हैं और नया लिखते हैं, इसलिए हर बार यह ऐसा लगता है जैसे बस नया write command दे रहे हों। refactor में वास्तव में शाब्दिक copy/paste इतना अधिक नहीं होता, इसलिए context-based recall से ही काम ज़्यादा चलता है। वास्तविक काम में copy/paste command खुद कितनी उपयोगी है, यह भी स्पष्ट नहीं लगता (कम-से-कम मेरी testing में इससे बड़ा फर्क नहीं पड़ा)। उल्टा, जो हिस्से repetitive हों और context बहुत खाएँ, वहाँ fastmod जैसे tools का इस्तेमाल करके codex या claude से “यह हिस्सा batch में बदलने” में मदद लेना ज़्यादा प्रभावी होता है। समस्या हल करने का इनका तरीका इंसानों से अलग है, इसलिए अटपटा लग सकता है, लेकिन अगर योजना बनाकर अच्छी तरह संवाद किया जाए तो approach काफ़ी बदल सकती है

    • IDE कई files में function signatures या names तुरंत बदल सकता है, लेकिन LLM agent जब यह कोशिश करता है, तो कई मिनट लगाकर भी अक्सर ठीक से नहीं कर पाता। मुझे लगता है कि असली copy/paste support का लाभ स्पष्ट है

    • copy/paste context explosion को कम करने में बहुत मदद करता है। इससे model को code blocks की सामग्री याद रखने की ज़रूरत नहीं रहती, क्योंकि ज़रूरत पड़ने पर वह उसे कभी भी फिर से access कर सकता है