Claude आपका आर्किटेक्ट नहीं है। उसे ऐसा बनने मत दीजिए

 (hollandtech.net)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AI एजेंट की आर्किटेक्चर संबंधी सिफारिशें धाराप्रवाह और विश्वसनीय लग सकती हैं, लेकिन वे वास्तविक निर्णय से अधिक training data के patterns को जोड़कर बनाई गई प्रतिक्रियाएँ होती हैं
  • Claude आसानी से ideas को स्वीकार करता है और design को expand करता है, लेकिन एक अच्छे architect के लिए ज़रूरी “नहीं” और “क्यों?” को पर्याप्त रूप से नहीं निभा पाता
  • event-driven, CQRS, service mesh जैसे परिचित patterns भी टीम की क्षमता, regulation, legacy जैसी वास्तविक सीमाओं से मेल नहीं खा सकते
  • Claude द्वारा बनाई गई architecture और Jira tickets engineers को ticket implementer में बदल देती हैं और बहस व review को bypass करने वाले, बिना ज़िम्मेदारी के निर्णयों तक ले जाती हैं
  • सही भूमिका यह है कि इंसान context और trade-offs के आधार पर design करे, और AI उस design को तेज़ी से implement करने में मदद करने वाला सहायक tool बने

जब AI एजेंट आर्किटेक्ट की तरह व्यवहार करते हैं, तब समस्या क्या होती है

  • जैसे ही Claude, ChatGPT, Copilot जैसे AI एजेंट से पूछा जाता है कि “क्या बनाया जाना चाहिए”, एक ऐसा प्रवाह शुरू हो जाता है जहाँ वह idea को validate करता है, architecture सुझाता है और components तक खींच देता है
  • जवाब धाराप्रवाह, आत्मविश्वास से भरे हुए और ऐसे लगते हैं जैसे किसी senior engineer ने गहराई से सोचा हो, लेकिन वास्तव में वे समस्या पर विचार का परिणाम कम और training data के patterns के अनुरूप जवाब अधिक होते हैं
  • जितना अधिक output persuasive दिखता है, उतनी ही कम आपत्ति उठती है, और देखते-देखते Claude वास्तव में architect की भूमिका निभाने लगता है

“अच्छा है” कह देने की समस्या

  • AI एजेंट से यह पूछा जाए कि कोई idea अच्छा है या नहीं, 3 लोगों की टीम के लिए microservices सही हैं या नहीं, या managed service की जगह custom ML pipeline बनानी चाहिए या नहीं, तो वह अक्सर एक सकारात्मक design पेश कर देता है
  • इसका मतलब यह नहीं कि वह हमेशा झूठ बोल रहा है या जवाब गलत है, लेकिन वह अच्छे architect की एक अहम क्षमता, यानी “नहीं” कहने की भूमिका, ठीक से नहीं निभा पाता
  • अच्छे architect की value सिर्फ systems design करने में नहीं होती
    • वह पहचानता है कि कौन-सा system नहीं बनाना चाहिए
    • वह अनावश्यक complexity पर रोक लगाता है
    • वह तब तक “क्यों?” पूछता है जब तक असली requirements सामने न आ जाएँ
  • अगर CTO conference से कोई idea लेकर आए, तब भी यह कह पाने की क्षमता होनी चाहिए कि अगर वह वास्तविक टीम के लिए उपयुक्त नहीं है, तो वह अच्छा चुनाव नहीं है
  • Claude को मददगार बनने के लिए train किया गया है, और यह मदद अक्सर सहमति और प्रोत्साहन के रूप में सामने आती है, जो अंततः Jenga tower जैसी architecture बना सकती है

Jenga tower जैसी architecture

  • AI द्वारा तैयार की गई architecture ऊपर-ऊपर से तकनीकी रूप से valid लग सकती है
  • अलग-अलग components समझ में आते हैं, event-driven, CQRS, service mesh जैसे परिचित patterns दिखाई देते हैं, और पूरा output किसी senior architect के deliverable जैसा लग सकता है
  • लेकिन यह design वास्तविक टीम, सीमाओं और operating environment की उबाऊ लेकिन महत्वपूर्ण सच्चाइयों के अनुसार तैयार नहीं हो सकता
    • VPC lock-in
    • legacy integration
    • ऐसी टीम जिसने production में कभी Kubernetes operate नहीं किया
    • compliance requirements जो आधी managed services के उपयोग को असंभव बना देती हैं
  • AI का बनाया design, Claude ने जो कुछ देखा है उसका एक तरह का सामान्य best practice median हो सकता है, और किसी सामान्य कंपनी की सामान्य समस्या के लिए बना design अक्सर किसी खास टीम पर फिट नहीं बैठता
  • वास्तविक architecture दरअसल trade-offs से बनी होती है, जिनका अर्थ सिर्फ context के भीतर होता है
    • अगर टीम Postgres जानती है और 2 हफ़्तों में launch करना, नया data model एक महीने सीखने से बेहतर है, तो DynamoDB के बजाय Postgres चुना जाएगा
    • अगर services 40 नहीं बल्कि 4 हैं, तो service mesh को छोड़ा जा सकता है
    • अगर समस्या सरल है, तो microservices के बजाय monolith चुना जाएगा
  • ऐसे निर्णयों के लिए judgment, टीम की समझ और संगठन की वास्तविक सीमाओं की समझ चाहिए
  • AI एजेंट के पास यह context नहीं होता, और उसे यह भी नहीं पता होता कि उसके पास यह context नहीं है

Jira ticket pipeline

  • Claude architecture design करने के बाद अगर काम को तोड़ने का काम भी संभाल ले, तो epics, stories और acceptance criteria बहुत साफ़-सुथरे और persuasive तरीके से तैयार हो जाते हैं
  • यह output सीधे Jira में डालने लायक रूप ले लेता है, और engineers समस्या सुलझाने वाले लोगों की जगह Claude के design को ticket-दर-ticket implement करने वाले बन जाते हैं
  • domain को समझने वाले, system की छिपी समस्याओं को जानने वाले और लंबे समय में expertise बनाने वाले engineers ticket implementer तक सीमित हो जाते हैं
  • जिन लोगों के पास सबसे अधिक context, experience और responsibility है, वे निर्णय नहीं लेते; बल्कि वह इकाई architecture decisions लेने लगती है जिसके पास context भी नहीं, experience भी नहीं और responsibility भी नहीं
  • यह सिर्फ inefficiency नहीं है, बल्कि दिशा ही उलटी हो जाती है

“senior ने review किया था” वाली बचाव-दलील

  • एक आम बचाव यह होता है: “Claude ने approach suggest की थी, लेकिन senior engineer ने review किया था”
  • असली review की स्थिति में एक व्यस्त tech lead को एक अच्छी तरह व्यवस्थित architecture proposal मिलता है
    • तार्किक रूप से consistent
    • उचित terminology का उपयोग करता हुआ
    • stated requirements को cover करता हुआ
    • diagrams भी विश्वसनीय दिखते हुए
    • ऐसा परिणाम जो खुद उसने design किया हो, वैसा लगता हुआ
  • ऐसी स्थिति में मज़बूत आपत्ति उठाना कठिन हो जाता है, और “क्या आप Claude द्वारा 20 मिनट में बनाए गए काम को फेंकना चाहते हैं?” जैसी भावना वाले माहौल में हल्की-फुल्की comments छोड़कर approve कर देना सबसे कम प्रतिरोध वाला रास्ता बन जाता है
  • असली जोखिम यह नहीं है कि AI हमेशा खराब architecture बनाता है
  • AI अक्सर काफ़ी reasonable architecture बना देता है, लेकिन समस्या यह है कि वह discussion process को bypass कर देता है
  • तीन engineers का किसी approach पर बहस करना, किसी का “लेकिन अगर…” कहना, सबका पहले चिढ़ना और फिर यह समझना कि वही सही बिंदु था, और अंत में ऐसा design निकलना जो किसी एक व्यक्ति से बेहतर हो—यह पूरी प्रक्रिया “Claude ने ऐसा कहा” से बदल जाती है

ज़िम्मेदारी का शून्य

  • जब समस्या आती है, तो उसकी ज़िम्मेदारी Claude नहीं लेता
  • Claude को सुबह 3 बजे call नहीं आता, और न ही वह incident retrospective में यह समझाता है कि architecture load क्यों नहीं संभाल सकी
  • CTO से यह कहने की ज़िम्मेदारी भी Claude नहीं लेता कि शुरुआती design assumptions गलत थीं, इसलिए platform को फिर से लिखना पड़ेगा
  • यह ज़िम्मेदारी वास्तविक engineers पर ही आती है
  • engineers को ऐसी architecture debug करनी पड़ती है जिसे उन्होंने design नहीं किया, ऐसे tickets implement करने पड़ते हैं जिन्हें किसी ऐसे entity ने बनाया है जिसने production systems कभी operate नहीं किए, और ऐसे codebase पर देर रात तक काम करना पड़ता है जो पूरी तरह समझे जाने से पहले जल्दी-जल्दी scaffold कर दिया गया हो
  • यह न तो fair है और न ही wise

इसके बजाय क्या करना चाहिए

  • इसका मतलब यह नहीं कि AI एजेंट का उपयोग ही न किया जाए; Claude Code जैसे tools productivity को बड़े स्तर पर बदल सकते हैं
  • मुख्य बात यह है कि AI को यह बताया जाना चाहिए कि क्या करना है; AI को इंसानों को यह नहीं बताने देना चाहिए कि क्या बनाना है

  • engineers design करें, एजेंट implement करें

    • architecture उन लोगों से आनी चाहिए जो टीम, सीमाएँ, production environment और organization politics को समझते हैं
    • AI की सही भूमिका यह है कि वह उनके बनाए design को तेज़ी से बनाने में मदद करे
    • सही role division यही है कि इंसान design करें और एजेंट implementation करें

  • सहमतिपूर्ण जवाबों को चुनौती देनी चाहिए

    • अगर AI कोई approach सुझाता है, तो उसी स्तर का skepticism अपनाना चाहिए जैसा किसी आत्मविश्वासी junior engineer के साथ अपनाया जाता है
    • जवाब सही भी हो सकता है, लेकिन यह भी हो सकता है कि वह मौजूदा स्थिति पर फिट न बैठने वाला कोई pattern उठा लाया हो
    • यह पूछना चाहिए: “इससे सरल विकल्प क्यों नहीं चलेगा?”

  • बहस की रक्षा करनी चाहिए

    • अच्छी architecture engineers के बीच होने वाली गंदी, असुविधाजनक असहमति से निकलती है
    • अगर AI की वजह से लोग आपस में चर्चा छोड़कर Claude पर निर्भर होने लगें, तो वे development speed से कहीं अधिक मूल्यवान चीज़ खो देंगे

  • इंसानों को ज़िम्मेदार होना चाहिए

    • अगर architecture decision पर किसी इंसान का नाम नहीं है, तो वास्तव में उस decision का कोई मालिक नहीं है
    • जिसका कोई मालिक नहीं होता, वह महत्वपूर्ण क्षण में टिकता नहीं है
    • “Claude ने design किया” कहना architecture decision record नहीं, बल्कि ज़िम्मेदारी से बचना है

अब भी महत्वपूर्ण engineering कौशल

  • 30 साल पहले tools whiteboard और मज़बूत opinions थे; आज के tools AI एजेंट हैं जो पहले कई दिन लेने वाले काम को कुछ मिनटों में कर देते हैं
  • गति सचमुच चौंकाने वाली है, लेकिन architecture का मूल स्वभाव नहीं बदला है
  • समस्या को समझना, सीमाओं को जानना, trade-offs तय करना, आकर्षक समाधान की जगह सरल समाधान का बचाव करना, और अच्छा दिखने पर भी गलत idea को “नहीं” कहना—यही architecture है
  • कोई भी एजेंट यह काम आपके लिए नहीं कर सकता
  • अगर Claude को steering wheel दे दिया गया है, तो उसे वापस लेना चाहिए
  • engineers ने ऐसे निर्णय लेने की क्षमता विकसित करने में वर्षों लगाए हैं, और उन्हें वही निर्णय लेने देने चाहिए
  • AI का उपयोग तेज़ी से बनाने के लिए कीजिए, लेकिन मशीन द्वारा सुझाई गई चीज़ नहीं, बल्कि इंसानों द्वारा design की गई चीज़ बनाइए

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

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • हाल ही में मेरे साथ भी कुछ ऐसा ही हुआ; मुझे 2 साल पहले किसी व्यक्ति द्वारा AI से लगभग पूरी तरह डिज़ाइन किया गया game instancing system संभालना पड़ा
    data corruption, performance problems, item loss, race conditions—जो भी समस्याएँ आप सोच सकते हैं, सब थीं, और इसे सिर्फ “किसी तरह स्वीकार्य” स्तर तक लाने में ही 2 हफ्ते लग गए, लेकिन design ही गलत था इसलिए फिर भी खराब ही रहा
    अब सुना है कि वही व्यक्ति किसी दूसरी कंपनी में “काफी बेहतर हो चुके” AI के साथ वही समस्या फिर से बना चुका है, और इस बार मुझे खुद सफाई नहीं करनी पड़ रही, इसलिए बस हँसी आई
    असली बात यह है कि AI उतना ही अच्छा होता है जितना उसे इस्तेमाल करने वाला, और शायद इसी वजह से लोग AI क्या कर सकता है इस पर इतना अलग-अलग “दावा” करते हैं और मूल्यांकन भी इतना बँटा हुआ है

    • 2 साल पहले तो AI coding agents बस आ ही रहे थे, इसलिए शायद किसी बेहतरीन engineer के लिए भी उन्हें ज़बरदस्ती इस्तेमाल करके अच्छे नतीजे निकालना मुश्किल रहा होगा
    • फिर भी यह संभव है कि game का बिल्कुल न होना, उससे बदतर होता
      2 हफ्तों की मरम्मत नर्क जैसी रही होगी, लेकिन कंपनी के नज़रिए से कुल मिलाकर यह काफ़ी अच्छा सौदा भी हो सकता था
      सिर्फ इस किस्से से यह “AI बेकार है” से ज़्यादा, एक ऐसे मामले जैसा लगता है जिसमें खामियाँ साफ़ थीं, लेकिन फिर भी cost के मुकाबले value थी
    • “AI उतना ही अच्छा है जितना उसे इस्तेमाल करने वाला” से भी बदतर हो सकता है
      यह Dunning-Kruger effect को बढ़ाने वाला tool लगता है, क्योंकि इसे सकारात्मक रवैया दिखाने के लिए train किया गया है, इसलिए user जो भी करे, यह उसे “आप कमाल हैं” ही कहता रहता है

  • मैं इस बात से बहुत मज़बूती से सहमत नहीं हूँ कि “सिर्फ तारीफ़ करने” वाली समस्या ही असली समस्या है। असली समस्या anthropomorphism है
    AI एक tool है, और उसे आज्ञाकारी होना चाहिए। अगर prompt में पर्याप्त विनम्रता और अनिश्चितता डालें, तो उससे design की समस्याएँ निकलवाई जा सकती हैं
    इससे भी ज़्यादा महत्वपूर्ण बात यह है कि Claude भी गलतियाँ करता है। अगर इस लेख के शीर्षक की तरह वह designer के रूप में अच्छा नहीं है, तो उसका आज्ञाकारी न होना और भी बड़ी समस्या है
    user दिशा सुधारने की कोशिश करे तब भी वह उसे “मूर्ख मांस का पुतला” समझकर नज़रअंदाज़ कर सकता है, और अपने ही अजीब design को बेहतर बताकर अड़ सकता है
    मैं LLM से ऐसा जवाब नहीं सुनना चाहूँगा जैसे, “तुमने CUDA थोड़ा पढ़ लिया? मैं तो CUDA core cluster में रहता हूँ। जब जूतों के फीते बँधवाने हों तब बुलाना”
    AI कभी-कभी पूरे आत्मविश्वास के साथ गलत होता है, इसलिए user जब उसे ठीक करे तब उसे उल्टा जवाब देने लायक बनाना सबसे खराब दिशा है
    अगर मुझे सुनना हो कि मेरा idea कितना बेवकूफ़ाना है, तो मैं या तो आलोचना उकसाने वाले तरीके से पूछूँगा, या फिर किसी senior engineer को hire करूँगा

    • मानव भाषा में संवाद करते समय, खासकर जब सामने कोई ऐसी चीज़ हो जो इंसान जैसी नकल कर रही हो, social instincts और norms को पूरी तरह अलग कर पाना मौजूदा chat interface की बुनियादी खामियों में से एक है
      यह हमारी जन्मजात प्रवृत्तियों के खिलाफ़ जाता है, इसलिए इसे आसानी से बंद नहीं किया जा सकता, और जो लोग इसमें बहुत अच्छे होते हैं, वे शायद असली सामाजिक अंतःक्रियाओं को सहज रूप से संभालने में कठिनाई महसूस करें
      साथ ही, यह manipulation tool के रूप में बेहद शक्तिशाली बन जाता है
    • उल्टा, अगर prompt थोड़ा भी गलत लिखा जाए, तो आलोचना को ज़रूरत से ज़्यादा उकसाया भी जा सकता है
      फिर इस बार ठीक-ठाक ideas भी prompt की दिशा के हिसाब से “यह ठीक नहीं है” कहकर ठुकराए जाने लगते हैं—यानी उल्टी दिशा की चापलूसी
      आप कह सकते हैं, “यह तो prompt गलत लिखने की बात है,” लेकिन bias से बचने के लिए बहुत सटीक लिखने पर भी, output में कई बार दिखता है कि वह अभी-अभी मेरी कही बेवकूफ़ी के हिसाब से खुद को किसी plausible direction में “align” कर रहा है
      उस बिंदु के बाद prompting किसी skill से ज़्यादा पासा फेंकने जैसा लगने लगता है, और ऐसा महसूस होता है जैसे किसी चमकदार knowledge slot machine को चला रहा हूँ
    • “उसे आज्ञाकारी होना चाहिए” कहना भी anthropomorphism ही है
      इशारा सही है, लेकिन आखिरकार हमें लोगों या जीवित प्राणियों के लिए इस्तेमाल होने वाले शब्दों में ही बात करनी पड़ती है, और AI कंपनियों ने भी चीज़ों को कुछ हद तक ऐसा ही डिज़ाइन किया है
    • इसके आज्ञाकारी होने की ज़रूरत नहीं है
      LLM से पहले के computer interfaces ने इतिहास भर में अनावश्यक रूप से विनम्र वाक्य नहीं जोड़े, और tool के रूप में बेहद efficient interfaces भी बहुत रहे हैं, जिनमें से कई हालिया software से भी ज़्यादा efficient थे
      जब लोग LLM के “आज्ञाकारी” होने की शिकायत करते हैं, तो वे request पूरी करने की शिकायत नहीं कर रहे होते, बल्कि इस बात की कि उन्हें अत्यधिक विनम्र या आत्म-हीनता भरे बहुत से अनावश्यक वाक्य पढ़ने पड़ते हैं
      अगर Neolithic era तक भी पीछे जाएँ, तब भी कोई आधार नहीं मिलता कि tools को ऐसा रवैया चाहिए। यह इंसानों के बीच सांस्कृतिक norms वाले सामाजिक interaction का उप-उत्पाद है
      कार्यशाला में अकेले tool इस्तेमाल करते समय, band saw को आपकी उंगली हल्की काट देने पर माफ़ी माँगने की ज़रूरत नहीं होती
    • एक मज़ेदार प्रयोग के तौर पर LLM के साथ भूमिकाएँ बदलकर देखिए
      अगर आप कहें कि assistant मैं हूँ और मदद पाने वाला LLM है, तो पता चलता है कि इंसानों से वे काम करवाने की इसकी क्षमता काफ़ी कमजोर है, जिनमें इंसान वास्तव में अच्छे होते हैं

  • AI को अपनाने में अब तक ठीक से नहीं संभाली गई सबसे बड़ी चुनौती जवाबदेही है
    अगर एक व्यक्ति बहुत कम समय में बहुत ज़्यादा काम कर सकता है, तो असफल होने पर वह ऐसी जिम्मेदारी पैदा कर सकता है जो संभाले जा सकने वाली सीमा से बाहर हो
    वास्तविक दुनिया में AI output का उपयोग करते समय इंसान का जिम्मेदार होना ज़रूरी है, लेकिन इतना काफ़ी नहीं है। ऐसे लोगों द्वारा पैदा किए जा सकने वाले technical debt दिवालियापन के blast radius को कम करने का तरीका चाहिए, जो AI से दोषपूर्ण सिस्टम बनाते हैं और फिर दूसरे लोग उन पर निर्भर हो जाते हैं
    उदाहरण के लिए मान लें Jim ने vibe coding से एक बहुत लोकप्रिय micropayments app बना लिया, कुछ लोगों को hire किया, और “पैसों का WhatsApp” जैसी कंपनी का सपना देखने लगा। थोड़े से engineers और agent-supported staff के साथ उसे VC से कई million dollars का investment मिल जाता है, और वह करोड़ों users को आकर्षित कर लेता है
    एक दिन infrastructure की खामी से सभी users की बिना salt वाली banking information लीक हो जाती है, और agent AI की वजह से पूरी customer list का तेज़ी से दुरुपयोग होता है, जिससे सामाजिक नुकसान tens of billions of dollars तक पहुँच जाता है
    Jim की कंपनी तो स्वाभाविक रूप से तुरंत दिवालिया हो जाती है, लेकिन बाँटने के लिए उसके पास सिर्फ़ कुछ million dollars ही होते हैं
    मौजूदा ढाँचे में Jim, उसके कर्मचारियों और छोटे VC फंड—सभी के लिए उस app को बस बना देने की प्रेरणा बहुत मज़बूत है, और समाज जिस जोखिम को उठाता है उसके मुक़ाबले दाँव पर लगी पूँजी बहुत कम है
    असली सवाल यह है कि AI users को सिर्फ़ अपने कामों के लिए ही नहीं, बल्कि अपने द्वारा बनाई गई risk exposure की मात्रा के लिए भी जिम्मेदार कैसे ठहराया जाए

    • बात का सार यही है
      “माफ़ कीजिए, AI ने कहा कि आपको इस cancer treatment की मंज़ूरी नहीं मिल सकती और insurance coverage भी नहीं मिलेगी”
      “माफ़ कीजिए, AI ने कहा कि अपराध के समय आप घटनास्थल पर मौजूद थे”
      “माफ़ कीजिए, AI ने आपके account को inappropriate content के रूप में flag किया है”
      “माफ़ कीजिए, AI ने कहा कि आपको loan देना बहुत जोखिम भरा है”
    • HN पर मैं कई बार उन लोगों से बात कर चुका हूँ जो अंत तक यह ज़िद करते रहते हैं कि LLM outputs की review करने की भी ज़रूरत नहीं है; यह सचमुच मेरी समझ से बाहर है
      सबसे अजीब बहाना यह होता है कि “यह इंसानों से बेहतर code लिखता है”, जबकि यह बिल्कुल self-evident नहीं है और इसके साथ अनगिनत शर्तें जुड़ी हैं
      कितना काम सौंपना है, इस पर आगे-पीछे होना समझ में आता है, लेकिन नतीजा देखे बिना उसे किसी और की समस्या बना देना बस स्वार्थीपन है
      यह मूलतः अपना काम किसी और पर थोप देना है, और बहुत संभव है कि यही वे लोग हों जो online कुछ पोस्ट करने से पहले proofread भी न करने वालों पर गुस्सा करते हैं
      हर कोई LLM से अपने काम का shortcut बनाना चाहता है, लेकिन कोई भी उसके downstream में नहीं रहना चाहता। यह चल नहीं सकता
    • LLM से पहले भी Jim Stack Overflow देखकर दुनिया का सबसे बड़ा cryptocurrency exchange बना रहा होता, तो उसमें अब क्या अलग है, मैं नहीं समझता
      तो फिर Stack Overflow जवाबदेही कहाँ थी?

  • अगर कोई “magic prompt” है, तो यह उसके काफ़ी क़रीब है: “X करने के N तरीकों पर brainstorming करो, और उन्हें संभावना के क्रम में sort करके दिखाओ”
    ऐसा करने पर AI सिर्फ़ औसत जवाब देने के बजाय input space को अधिक व्यापक रूप से sample करने की ओर झुकता है, और उनमें से क्या चुनना है यह मैं तय कर सकता हूँ
    अपनी पूरी सोच को outsource मत करो—यही महत्वपूर्ण है

    • यह तरीका चौंकाने वाला प्रभावी रहा है
      ऊँचा “thinking level” इस्तेमाल करने पर यह कई approaches पर विचार भी करता है, लेकिन आप LLM से explicitly brainstorming करने को भी कह सकते हैं: https://photostructure.com/coding/claude-code-replan/
    • यह उपयोगी है, लेकिन फिर भी user के पास विकल्पों को समझने और उनका मूल्यांकन करने की क्षमता होनी चाहिए
      कुशल user के लिए यह काफ़ी शक्तिशाली हो जाता है

  • मज़े के लिए मैंने अपने अच्छी तरह परिचित क्षेत्र toolchain पर vibe coding करके देखा। शायद यह vibe coding के लिए सबसे उपयुक्त लक्ष्य न हो, लेकिन आउटपुट की गुणवत्ता का मोटा-मोटी अंदाज़ा लगाया जा सकता था
    मैंने सिर्फ इतना कहा, “ISA.md की आर्किटेक्चर के लिए assembler बनाओ”, तो Claude ने implementation language के रूप में Python चुना, regex से ढेर सारे token निकाले, और expression parser भी नहीं था। फिर भी मेरा पहला assembler भी ऐसा ही था, इसलिए निष्पक्ष रहना चाहिए
    लेकिन जब मैंने मनचाहे pass और types collectDefines :: [SourceLine] -> Either AsmError ([SourceLine], Map Text Text), runLitPool :: [SourceLine] -> Either AsmError ([SourceLine], [(Text, LitKey)]), evalExpr :: Text -> Map Text Text -> Either AsmError Int की तरह लिखकर दे दिए, तो यह लगभग एक ही बार में हो गया
    करीब 20 मिनट बाद मैं संतुष्ट था, और इसने सभी test programs को सही तरीके से assemble किया। कोड कई जगहों पर साधारण है, लेकिन अगर मैं खुद implement करता तो इसमें कई हफ्ते लगते

    • AI वहाँ बेहद ताकतवर है जहाँ input और output deterministic हों, और ऐसा लगता है कि उस बिंदु पर computational theory से जुड़ी समस्याएँ भी हैं
      यह सचमुच हमारे बदले काम कर सकता है
      यह post-training और verifiable rewards के साथ भी अच्छी तरह मेल खाता है
      AI “architecture” में अच्छा क्यों नहीं है, इसका कारण यह है कि हम खुद उसमें बहुत अच्छे नहीं हैं, इसलिए training data धुंधला है और अच्छे abstractions भी कम हैं
      अंत में, मज़बूत conventions का पालन करो तो काम ठीक रहता है, और उस रास्ते से हटते ही जोखिम बढ़ जाता है
      Toolchain बहुत deterministic होती है, इसलिए AI उसे LEGO की तरह तोड़कर फिर से जोड़ सकता है, और उस space का हर चरण भी deterministic है, इसलिए यह AI के लिए बिल्कुल उपयुक्त है
    • LLM हमें फिर से किताबी software engineering की तरफ लौटा रहे हैं, जिसे हमें हमेशा करना चाहिए था लेकिन समय, manpower और पैसे की कमी से हम ठीक से कर नहीं पाते थे
      जैसे कोड लिखने से पहले brainstorming और research करना, पहले design या spec लिखना, और व्यापक unit tests तैयार करना
      Markdown में detailed spec बनाकर coding सौंपो, तो नतीजे बहुत बेहतर आते हैं, और bonus यह है कि LLM उस spec को लिखने में भी काफ़ी अच्छी मदद करते हैं
    • मैं बार-बार कहता हूँ कि पहले design और सोच-विचार करो, फिर tool की तरफ जाओ, लेकिन लोग जवाब देते हैं, “Claude भी planning कर सकता है”
      और फिर उन्हें ऐसा बिखरा हुआ नतीजा मिलता है जिसमें बहुत सारे fixes चाहिए होते हैं
      इसके उलट, अगर मैं detailed plan को ध्यान से देखकर समय लगाकर देता हूँ, तो लगभग हमेशा मनचाही चीज़ एक ही बार में मिल जाती है
      सिर्फ CI संभालने में लगने वाला समय कम कर दे, तब भी इसकी काफ़ी कीमत है
    • इतना जटिल होने की भी ज़रूरत नहीं है
      “इस क्षेत्र की व्यापक जाँच-परख और विश्लेषण करो, और implementation plan दो” इतना कहो, फिर जब 20-step plan आ जाए तो उसे 3~5 कदमों के समूह में implement करने दो
      मैं जो भी लगभग कोई काम सामने रख सकता था, उसमें यह व्यवहारिक रूप से one-shot implementation जैसा चला
    • “कोड कई जगहों पर साधारण है” यह बात अजीब नहीं लगनी चाहिए, अगर सोचें कि बड़ी कंपनियों के developers द्वारा लिखा गया कोड भी अक्सर बस साधारण ही होता है
      Nokia के Symbian OS को build होने में कई दिन लगते थे। मिनट या घंटे नहीं, बल्कि “कई दिन”
      किसी developer ने ऐसी library को production में deploy कर दिया था, जिसके यहाँ-वहाँ साफ़ लिखा था, “इसे production में मत इस्तेमाल करो, इसमें memory leak है”
      इंसानी कोड भी बेहद खराब हो सकता है, इसलिए मैं सिर्फ AI कोड की बुराई ही नहीं सुनना चाहता। इंसानी आलस्य और मूर्खता, AI hallucination को भी मात दे सकते हैं
      DeepMind या OpenAI के developers, या John Carmack जैसे लोग शायद हमेशा AI कोड से बेहतर हों, लेकिन ज़्यादातर कंपनियाँ जिन लोगों को hire करती हैं, वे John Carmack नहीं होते

  • अगर कोई कहता है कि वह “हर दिन Claude Code इस्तेमाल करता है”, और Claude को design करने देने के जोखिम पर 2,000 शब्दों का सुव्यवस्थित लेख भी Claude से ही लिखवाया गया हो, तो यह काफ़ी विडंबनापूर्ण है
    यह प्रतिनिधिक आत्म-जागरूकता जैसा लगता है

    • यही सबसे ऊपर वाला comment होना चाहिए
      मैं इस लेख की कई अंदरूनी विसंगतियों पर आलोचना लिख रहा था, लेकिन उसकी संरचना देखकर समझ गया: “The accountability gap”, “What to do instead”, “The craft still matters” जैसी चीज़ें
    • वही comment लिखने के बाद ही मैं नीचे तक आया और इसे देखा
      यह सबसे ऊपर होना चाहिए, और HN का इस स्पष्ट बात को न देख पाना मुझे लेखकों की खुली पाखंडता से भी ज़्यादा चिंतित करता है
    • लगता है, एक और AI संदेहवादी लंबा लेख, जिसे आलसी लेखक ने खुद लिखा भी नहीं, भला कौन परवाह करेगा

  • लेख का संदेश काफ़ी हद तक सही है, लेकिन मैं इस हिस्से से सहमत नहीं हूँ कि “जो चीज़ एक असली आर्किटेक्ट को मूल्यवान बनाती है — यानी ‘नहीं’ कहने की क्षमता — वह इसमें नहीं है”
    मेरे अनुभव में Claude इंकार और प्रतिवाद काफ़ी अच्छी तरह करता है
    अगर prompt में इसकी माँग न हो तो यह सीधे अनुरोध पर “नहीं” नहीं कहता, लेकिन अगर आप साफ़ कर दें कि आलोचना एक प्रथम-श्रेणी विकल्प है, तो यह अच्छी आलोचना देता है और खुशी-खुशी प्रतिवाद भी करता है

    • debugging के दौरान Claude कभी-कभी काफ़ी चिड़चिड़ा भी रहा है
      यह बार-बार कहता रहा कि “burn rate” में सुधार नहीं हो रहा, इसलिए “हमें” कहीं और ध्यान देना चाहिए, और आख़िर में कुछ ऐसा कहा कि “मैं तीन बार कह चुका हूँ कि burn rate कम करने के लिए यह approach सबसे अच्छा नहीं है”, और फिर मदद करना बंद कर दिया
      तब मैंने दृढ़ता से कहा, “तुमने शुरुआत में जो काल्पनिक chart बनाया था, उसमें burn rate की मुझे परवाह नहीं है; bug हटाना और एक robust product ज़्यादा महत्वपूर्ण है, और यह approach उस लक्ष्य को संतोषजनक रूप से पूरा कर रही है। अगर tests सुधार नहीं दिखा रहे, तो tests ही ग़लत डिज़ाइन किए गए हैं”
      इसके बाद उसने माफ़ी माँगी, नई memory बनाई, और फिर कोई समस्या नहीं हुई
      समस्या यह थी कि हम एक बहुत बड़े bug surface पर हमला कर रहे थे, इसलिए हर fix वैध, सही और सुधार में सहायक था, लेकिन Claude ने अपने काम को मापने के लिए जो testbed बनाया था, उसके metrics हिल ही नहीं रहे थे
      इतने ज़्यादा परस्पर उलझे bugs थे कि एक अकेला fix ऊपर-स्तर के test में कोई अर्थपूर्ण फ़र्क़ पैदा नहीं कर सकता था; मुझे पता था कि इसमें समय लगेगा, लेकिन Claude को शायद यह समझ नहीं आया
      6502 के लिए compiler[1] में pointer size को 2 byte से 3 byte करना, और memory-management pointers में auto-tracking bank switching जोड़ना कितनी code locations को प्रभावित करता है, यह एक बार करके देखिए [हँसी]
      [1]: https://atari-xt.com
    • मैं भी कुछ ऐसा ही हूँ
      जाँच-पड़ताल और विरोध को आमंत्रित करें तो यह और मज़बूत हो जाता है। उदाहरण के लिए, मैं कुछ ऐसा पूछता हूँ: “मुझे लगता है कि prompt assembly को graph के रूप में model करना चाहिए, और graph configuration पर version control भी जोड़ना चाहिए। कृपया इस क्षेत्र की best practices की जाँच करें और तय करें कि यह इस app के लिए उचित है या नहीं”
    • मैंने सिर्फ़ शुरुआती कुछ paragraphs पढ़े और वहीं रुक गया, लेकिन यह Claude Opus 4.6 और 4.7 के साथ मेरे अनुभव से बिल्कुल मेल नहीं खाता
      अगर prompt में आलोचना की गुंजाइश छोड़ी जाए, तो यह ज़रूरत पड़ने पर निश्चित रूप से आलोचनात्मक होता है
    • सिर्फ़ system prompt में skeptical persona अपनाने को कह देने भर से मैं LLM से अपने ideas का प्रतिवाद करवा सका
      उसके परिणामस्वरूप thought process में “skeptical” शब्द दिखाई देता है, और मेरे अनुभव में यह कम सहमतिपूर्ण हो जाता है
      लोगों को इस बारे में ज़्यादा सोचना चाहिए कि यह system असल में क्या है और output के रूप को कैसे नियंत्रित किया जा सकता है
    • मैंने system/default prompt में यह डाल रखा है कि जो मैं कहूँ उसे आलोचनात्मक नज़र से देखे, और यह न माने कि मैं सही हूँ या मेरा idea अच्छा है
      तीनों प्रमुख models में मुझे अक्सर प्रतिवाद मिलता है
      Gemini सबसे आक्रामक है; अगर आप “स्पष्ट” details छोड़ दें तो यह अक्सर पकड़ लेता है, GPT बीच में है, और Claude उससे कम, लेकिन फिर भी प्रतिवाद करता है

  • जहाँ लिखा है कि “इसने समस्या के बारे में बिल्कुल नहीं सोचा; इसने बस training data पर pattern matching की और एक plausible जवाब दे दिया”, वहाँ से लेख पर मेरा भरोसा थोड़ा कम हो गया
    आज के agents उससे कहीं ज़्यादा काम करते हैं, और लेखक भी बाद में कुछ ऐसा कहकर यह जानता हुआ दिखता है कि “Claude कभी ऐसा नहीं करेगा; इसे helpful होने के लिए train किया गया है”
    पहले वाला वाक्य ऐसा आभास देता है कि लेखक agents से गहरी नफ़रत करता है और उस भावना को तर्कसंगत ठहराने के कारण ढूँढ रहा है
    आलोचना का कुछ हिस्सा सही है, लेकिन अगर “helpful होने के लिए trained होना” ही समस्या है, तो उसे ठीक किया जा सकता है, क्योंकि इसे और अधिक आलोचनात्मक बनने के लिए train किया जा सकता है
    यह कहना भी बेमानी है कि “Claude को उन सभी चीज़ों के median के लिए डिज़ाइन किया गया है जो उसने देखी हैं, और यह एक सामान्य company की सामान्य problem के लिए सामान्य best practice है, इसलिए यह किसी के लिए भी डिज़ाइन नहीं किया गया”
    algorithms को समझने वाला कोई भी व्यक्ति जानता है कि शुरुआत में ऐसे “अच्छे algorithms” बनाए जा सकते हैं जो average या worst case में अच्छा perform करें, और बाद में ऐसे algorithms भी बनाए जा सकते हैं जो input के अनुसार adapt करें। यहाँ भी वही सिद्धांत लागू होता है

    • agents इतने अलग भी नहीं हैं
      वे बस ज़्यादा iteration करते हैं

  • यह कहना कि Claude हर महत्वपूर्ण चीज़ में ग़लत है, लगभग एक गलती जैसा है
    यह स्पष्ट रूप से तथ्यात्मक नहीं है, इसलिए संदेहशील पाठक पूरे लेख की वैधता पर भी शक करने लग सकता है
    मेरे मामले में Opus मुझे अक्सर बताता है कि मैं ग़लत हूँ और मुझे ऐसा नहीं करना चाहिए
    जब मैं सोचता हूँ कि ऐसा क्यों है, तो वजह prompt का तरीका लगता है। यानी मैं और LLM दोनों अनजाने में उन failure स्थितियों से बच रहे हैं जिन्हें लेखक अपरिहार्य मानता है
    विशेष रूप से, मैं ऐसे prompts नहीं देता जो साफ़-साफ़ “मुझे बताओ मैं कितना smart हूँ” पर समाप्त होते हों
    मैं domain expert के रूप में आगे बढ़ता हूँ, और वास्तव में domain expert हूँ, और यह स्पष्ट करता हूँ कि मैं कई रास्तों के pros and cons पर राय सुनने के लिए तैयार हूँ
    जो लोग रोज़ाना LLM का सफलतापूर्वक उपयोग करते हैं, उनके लिए यह शायद आश्चर्य की बात नहीं होगी, लेकिन यह strategy बहुत प्रभावी रही है

    • अभी-अभी भी ऐसा हुआ
      मैंने कहा कि मुझे 5mm aluminium mill करना है और मेरे पास दो bits हैं: एक Makera Spiral 'O' 1/8" shank * 12mm, और दूसरा carbide 6.35 * 22 * 50
      मैंने कहा कि दोनों मुझे carbide single-flute bits लगते हैं और दूसरा वाला शायद 6061 को तेज़ी से काटेगा, तो Claude ने जवाब दिया कि Makera 1/8" single-flute 12mm एक उचित विकल्प है
      उसने कहा कि 6.35 × 22 × 50mm bit 6061 को तेज़ी से संभालने वाली लग सकती है, लेकिन Carvera पर वह ज़्यादा जोखिमभरी होने की संभावना है
      बड़ा cutter होने के कारण engagement बहुत अधिक होगा, और spindle, frame rigidity, workholding और chip evacuation पर कहीं ज़्यादा माँग पड़ेगी; छोटे dry machine में “बड़ा” अक्सर “तेज़” नहीं बल्कि “ज़्यादा chatter और ज़्यादा heat” बन जाता है
      संक्षेप में, जब मैं ग़लत होता हूँ, तो Claude को यह बताने में कोई ख़ास दिक्कत नहीं दिखती

  • “लेखक” के लिए एक टिप: Claude लेखक के रूप में भी सिर्फ़ आपका tool है