15 पॉइंट द्वारा GN⁺ 2026-02-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • code लिखने की लागत में आई तेज़ गिरावट पूरी engineering आदतों को हिला रही है
  • पहले code बनाना महंगा था, इसलिए design, estimation और planning-केंद्रित efficient development culture विकसित हुई थी
  • coding agents के आने से अब एक developer एक साथ कई काम—implementation, refactoring, testing, documentation—कर सकता है
  • लेकिन ‘अच्छा code’ बनाना अब भी high quality standards और developer के judgment की मांग करता है
  • इसके चलते नई व्यक्तिगत और organizational development habits बनाने की चुनौती उभर रही है

code लिखने की लागत में बदलाव

  • पहले सैकड़ों lines का clean और tested code लिखने में एक दिन या उससे ज़्यादा लग जाता था
    • इसी वजह से developers सीमित समय और लागत के आधार पर features की value और priority तय करते थे
    • project design, schedule estimation, feature planning—सब कुछ ‘coding time के efficient use’ के इर्द-गिर्द होता था
  • coding agents के आने से code input की लागत तेज़ी से घट गई है, और पुराने निर्णय मानदंड डगमगा रहे हैं
    • एक engineer कई agents को parallel में चलाकर एक साथ कई development tasks कर सकता है
    • यह बदलाव पुराने समय बनाम value judgment structure की दोबारा समीक्षा करने पर मजबूर करता है

फिर भी महंगा है ‘अच्छा code’

  • नया code बनाना लगभग मुफ्त के करीब हो गया है, लेकिन ‘अच्छा code’ बनाना अब भी महंगा है
  • अच्छे code की शर्तें इस प्रकार हैं
    • सही तरह से काम करे और बिना bug के अपना उद्देश्य पूरा करे
    • verification process से गुज़रकर यह साबित करे कि code भरोसेमंद है
    • उपयुक्त problem solving पर फोकस करे और error situations को predictably handle करे
    • simple और minimal structure बनाए रखे ताकि maintainability और समझ बेहतर हो
    • tests और documentation updated रहनी चाहिए
    • भविष्य में बदलाव की संभावना को ध्यान में रखे, लेकिन अनावश्यक complexity न जोड़े
    • accessibility, security, scalability, maintainability जैसी non-functional quality properties को पूरा करे
  • coding agents इस प्रक्रिया के कुछ हिस्सों में मदद कर सकते हैं, लेकिन अंतिम quality assurance की ज़िम्मेदारी developer की ही रहती है

नई development habits की ज़रूरत

  • agentic engineering environment में पुरानी development habits अब वैध नहीं रह गई हैं
  • व्यक्ति और organization—दोनों को काम करने के नए तरीके और नए judgment criteria बनाने होंगे
  • अभी पूरी industry में ऐसी best practices स्थापित की जा रही हैं
  • सुझाया गया तरीका यह है कि जब भी लगे कि “समय बर्बाद होगा”, तब भी asynchronous agent sessions चलाकर experiment करके देखें
    • सबसे खराब स्थिति में, 10 मिनट बाद देखकर पता चलेगा कि बस tokens की बर्बादी हुई

Agentic Engineering Patterns guide में इसकी जगह

  • यह लेख Agentic Engineering Patterns guide के पहले chapter “Principles” का हिस्सा है
  • अगले chapter में code understanding विषय के तहत Linear walkthroughs जारी रहता है
  • इसके बाद Testing and QA section में Red/green TDD, First run the tests जैसे विषय शामिल हैं
  • हर हफ्ते 1–2 chapters जोड़ने की योजना है; यह किताब जैसा है, लेकिन “guide” के रूप में तैयार किया जा रहा है

1 टिप्पणियां

 
GN⁺ 2026-02-26
Hacker News की राय
  • मुझे नहीं पता कि “कोड हमेशा महंगा था” कहना सही है या नहीं
    असल में महंगी चीज़ कोड खुद नहीं, बल्कि उसके आसपास की पूरी प्रक्रिया थी — correctness सुनिश्चित करना, maintenance, टीमों के बीच coordination, long-term support आदि ही असली cost drivers थे
    अगर testing या approval process ज़रूरत से ज़्यादा हो जाए, तो उल्टा process ही ज़्यादातर लागत खा जाता है
    LLM ने short term में working code बनाने की लागत काफ़ी घटाई है, लेकिन long term में maintenance, security और testing का बोझ बढ़ भी सकता है
    आख़िरकार सच में बदलाव आया है या नहीं, यह long-term data देखकर ही पता चलेगा

    • मैं “महंगा तो कोड के आसपास की बाकी सब चीज़ें हैं” वाली बात से सहमत हूँ
      पहले कुछ सौ lines का code लिखना भी महंगा पड़ता था
      2000s-शैली के SLOCount tool (WebAssembly version) में 256 lines का JavaScript डालकर देखा, तो उस समय के हिसाब से लगभग $6,461 की लागत का अनुमान आया
      बेशक, उस संख्या को बस मज़े के लिए ही देखना चाहिए
    • मेरे अनुभव में सिर्फ coding ही नहीं, बल्कि DevOps, data analysis, support work जैसे हर क्षेत्र को AI ने मज़बूत किया है
      अब मैं खुद काम करने से ज़्यादा, अपने काम को manage करने वाला self-manager बन गया हूँ
      productivity पहले की तुलना में लगभग 2.5 गुना बढ़ी हुई लगती है
    • software development life cycle (SDLC) को देखें तो coding सिर्फ एक चरण है
      requirements gathering, design, testing, deployment, maintenance अब भी ज़रूरी हैं, और ज़्यादातर लागत maintenance phase में आती है
      Amdahl’s law की तरह, coding cost लगभग शून्य हो जाए तब भी बाकी चरणों की लागत सीमा बन जाती है
    • असली cost reduction तब आती है जब user “वास्तव में क्या चाहता है” यह ठीक-ठीक पता हो
      समस्या यह है कि इंसानी स्वभाव की वजह से यह मुश्किल है
    • कोड पहले भी महंगा था, अब भी है, और आगे भी रहेगा
      correctness, maintainability, performance जैसे quality factors ऐसे hidden costs हैं जो सिर्फ अनुभव से सीखे जाते हैं
  • मैं “कोड हमेशा महंगा था” वाले दावे से सहमत नहीं हूँ
    दरअसल कोड इसलिए महंगा था क्योंकि हम ‘अच्छा code’ लिखने की कोशिश करते थे
    अगर standards नीचे कर दिए जाएँ, तो generated code तेज़ और सस्ता होगा, लेकिन उसे वापस अच्छे code में बदलने की मेहनत अब भी उतनी ही है
    agent coding का समर्थन करना है तो दूसरी दलील देनी होगी

    • मेरे अनुभव में AI agent इस्तेमाल करने पर उल्टा अच्छा code सुनिश्चित करना और मुश्किल हो जाता है
      जब खुद लिखते हैं, तो हर line के पीछे की वजह समझते हैं, लेकिन AI के बनाए code में हर statement को verify करना पड़ता है
      पिछले एक महीने में ज़्यादातर काम agents से किया, और बार-बार ऐसे edge-case bugs आए जो इंसान शायद न बनाता
      आख़िर में review cost इतनी बढ़ जाती है कि short-term gain गायब हो जाता है
    • मैंने थोड़ा सावधानी से कहा था कि “अच्छा code अब भी costly है”
      लेकिन coding agents की वजह से वह लागत काफ़ी कम हो जाती है
      fine-grained edits agent कर देता है, इसलिए बेहतर quality का code तेज़ी से बनाया जा सकता है
    • simple code सस्ता है, लेकिन complex code अब भी महंगा है
      complexity जुड़ती जाती है, इसलिए शुरुआत में उसे ध्यान से संभालना सबसे सस्ता पड़ता है
      अभी short-term gains बड़े हैं, लेकिन long term में noise 10 गुना भी बढ़ सकता है
    • असली बात यह है कि programming सस्ती है, लेकिन software engineering महंगी है
    • Ousterhout की tactical vs strategic programming वाली अवधारणा याद आती है
      LLM tactical programming, यानी तेज़ feature implementation, में खास तौर पर अच्छे हैं
      इसलिए system-level complexity management और भी ज़्यादा महत्वपूर्ण हो जाता है
  • code generation उतना सस्ता है जितना लोग कहते हैं, लेकिन उसे valuable outcome में बदलने की skill ही असली काबिलियत है
    Agentic engineering आख़िरकार सस्ते input को मूल्यवान output में बदलने की कला है

    • मैं “सस्ते input को मूल्यवान नतीजे में बदलने की skill” वाली बात से पूरी तरह सहमत हूँ
      Agentic engineering सिर्फ software लिखना नहीं, बल्कि किसी खास समस्या को जल्दी हल करने वाले tools बनाना है
      लेकिन समस्या हल हो जाने के बाद AI खुद में दिलचस्प नहीं रह जाता
      बहुत से लोग AI को ही लक्ष्य बना लेते हैं, जबकि असली value problem solving में है
      Alan Watts के शब्दों में, संदेश मिल जाए तो फ़ोन काट देना चाहिए
    • excavator आ जाने से यह नहीं होता कि कहीं भी गड्ढा खोदकर अमीर बन जाओ
      tool सस्ता हो जाने से अपने-आप value पैदा नहीं होती
    • असल में code type करना value नहीं है
      design और structuring की क्षमता ही असली value है
    • अगर output एक ही दिमाग़ से आया है, तो चाहे बारीकी से निर्देश देकर निकला हो या किस्मत से एक बार में, quality लगभग समान होगी
      आख़िर में decision-making की quality ही अहम है
    • $100 million raise कर लेने से कोई idea अच्छा साबित नहीं हो जाता
      funding value का प्रमाण नहीं है
  • मुझे “कोड हमेशा महंगा था” वाले दावे पर शक है
    clean और tested code की परिभाषा ही अस्पष्ट है
    testing ज़रूरत से ज़्यादा हो जाए तो लागत फट पड़ती है, और organizational approval processes भी बड़ा cost factor हैं
    LLM short-term cost घटाते हैं, लेकिन long-term maintenance cost बढ़ सकती है

    • कोड हमेशा महंगा था
      internship के दौरान मैं startup में सस्ते में काम करता था, लेकिन outages, data corruption, technical debt जमा होते गए
      ऊपर से सस्ता लगता था, लेकिन hidden cost बहुत बड़ी थी
      LLM की वजह से अब ऐसा लगता है कि अच्छी quality का code सस्ते में मिल सकता है, लेकिन मैं अब भी उसके साथ adjust कर रहा हूँ
    • startup के नज़रिए से पहले product ship करने के लिए 6 महीने से ज़्यादा developers को hire करना पड़ता था
      अब v1 बनाना सस्ता है, लेकिन mature product के complex decisions अब भी महंगे हैं
  • software की economic value कोड में समाई हुई information में होती है
    code लिखना बस उस information को map करने की प्रक्रिया है; information की quality ही असली value तय करती है
    code जल्दी लिख लेने से information की quality बेहतर नहीं हो जाती
    यह वैसा ही है जैसे consulting में slides जल्दी बना लेने से value पैदा नहीं हो जाती

    • यह विचार हाल में चर्चा में रहे cognitive debt से जुड़ता है
      implementation speed बहुत तेज़ हो जाए तो developer का mental model code से अलग होने लगता है
      संबंधित लेख: Cognitive Debt by Simon Willison
    • मैंने भी coding agents का इस्तेमाल करते हुए information और code के mapping quality में सुधार का अनुभव किया है
      क्योंकि refactoring को तेज़ी से बार-बार दोहराया जा सका
    • आख़िरकार bottleneck intent को machine तक पहुँचाने की प्रक्रिया है
      AI धीरे-धीरे context को बेहतर समझेगा, लेकिन उसी अनुपात में इंसान को अपना judgment छोड़ना पड़ेगा
      जिस दिन machine intent को पूरी तरह समझने लगेगी, इंसान loop के बाहर धकेल दिया जाएगा
  • हर development methodology के केंद्र में यह तथ्य है कि requirements हमेशा बदलती रहती हैं
    इसलिए अच्छा code वही है जिसे “बदलना आसान हो”
    मौजूदा LLM agents ऐसा code बनाते हैं या नहीं, इस पर संदेह है
    जब तक उन पर पूरी तरह भरोसा नहीं किया जा सकता, वे शायद prototype level तक ही सीमित रहेंगे

    • असली bottleneck code लिखना नहीं, बल्कि intent को साफ़-साफ़ communicate करने की लागत है
      spec अस्पष्ट हो तो testing और value validation दोनों मुश्किल हो जाते हैं
    • मानव engineers भी 100% सुरक्षित तरीके से बदलाव नहीं करते
      tests होने पर भी लगभग 70% confidence ही होता है
    • मैं LLM को बारीकी से guide करते हुए उससे feature changes और bug fixes अक्सर करवाता हूँ
      यह सीधे coding करने से तेज़ है, और नतीजा maintainable code के रूप में आता है
    • मेरे यहाँ तो अब हर commit agent द्वारा 100% generated होता है
      अगर clean code और good practices स्पष्ट कर दिए जाएँ, तो पर्याप्त रूप से maintainable परिणाम मिलते हैं
      आख़िर में बात वही है: Garbage in, garbage out
    • लेकिन कुछ लोगों को लगता है कि LLM demo level तक अच्छे हैं, पर छोटे बदलावों पर भी बिखर जाते हैं
  • जैसा मैंने अपने लेख(The Final Bottleneck) में कहा था,
    code लिखने की गति बढ़ी है, लेकिन उसके बाद के चरण साथ नहीं दे पा रहे
    यह सिर्फ आदत का सवाल नहीं है; responsibility structures, language design, और पूरे system architecture को बदलना होगा

    • हर company के लिए नए तरीके से काम करना आसान नहीं है
      अगर productivity सच में 10 गुना बढ़ गई होती, तो अब तक startups बाज़ार उलट चुके होते
    • जब LLM काफ़ी छोटे और सस्ते हो जाएँगे, तब शायद वे apps में embed होकर हर user के हिसाब से code adjust करेंगे
    • यह सवाल भी है: “इतनी तेज़ी से code लिखने की ज़रूरत ही क्यों है?”
      सिर्फ इसलिए कि कुछ संभव है, यह ज़रूरी नहीं कि वह किया ही जाए
    • open source developers को ऐसे दौर का नेतृत्व करना चाहिए जहाँ non-developers भी builders बनें
      AI evals(measure-first-optimize-last, ai-evals.io) जैसी approaches उसी दिशा में हैं
    • “क्या हमें उसी रफ़्तार से deploy करते रहना चाहिए?”
      feature bloat कोई नहीं चाहता
  • code की हर line एक liability है
    LLM के code उगलने वाले दौर में यह liability विस्फोटक रूप से बढ़ रही है
    tool खुद बुरा नहीं है, लेकिन बिना ज़िम्मेदारी वाले programs द्वारा codebase rewrite करने की संरचना खतरनाक है

    • हमने दशकों में code deployment के लिए verification, review, rollback systems खड़े किए हैं
      “code सस्ता है” का मतलब सिर्फ generation सस्ता होना है; deployment approval cost अब भी बहुत बड़ी है
      अगर judgment step हटा दिया जाए, तो productivity gain नहीं बल्कि control gap पैदा होता है
      सिर्फ इसलिए कि कुछ तेज़ है, उसे master key दे देना खतरनाक है
    • लिखना भी अब भी महंगा है, और maintenance भी
      दोनों में से कोई भी सच में सस्ता नहीं हुआ है
  • मैं भी इस राय से लगभग पूरी तरह सहमत हूँ
    code writing सस्ती हुई है, लेकिन review और verification cost अब भी बड़ी है
    ख़ासकर million-line monorepo में testability बढ़ाना ही असली कुंजी है
    ट्विटर जैसे overhyped माहौल में इस तरह की चर्चा संतुलन लाती है, इसलिए अच्छा लगता है

    • मैंने भी यही देखा है
      code churn आसान हुआ है, लेकिन quality verification नई चुनौती बन गई है
      LLM द्वारा किए गए बड़े पैमाने के changes subtle failures पैदा करते हैं, और वह प्रवाह रुकता नहीं
  • code सस्ता नहीं है
    token cost भी है, और असली cost structure अभी भी अनिश्चित है
    revenue न रखने वाले startups GPU supply chain पर कब्ज़ा किए हुए हैं, इसलिए data की कमी है

    • लिखना सस्ता हुआ है, लेकिन maintenance वही है
      LOC बढ़ने के साथ liability भी बढ़ती है
      thought से execution तक की दूरी कम हुई है, लेकिन code अब भी ज़िम्मेदारी है
    • local models cost floor दिखाते हैं
      अभी subsidy की वजह से चीज़ें सस्ती हैं, लेकिन hardware, power, और staffing cost घटे तो यह और भी सस्ता हो सकता है