Andrej Karpathy के पिछले कुछ हफ्तों के Claude coding अनुभव पर विचार

कोडिंग वर्कफ़्लो में बदलाव

• 2024 के नवंबर में 80% manual+autocomplete और 20% agent coding था, लेकिन दिसंबर में यह अनुपात उलटकर 80% agent coding और 20% revision/touch-up हो गया
• व्यावहारिक रूप से अब अंग्रेज़ी में programming करने जैसी स्थिति हो गई है, जहाँ LLM को यह बताया जाता है कि कौन-सा कोड लिखना है
• इसमें अहं को ठेस पहुँचाने वाला पहलू है, लेकिन बड़े पैमाने की "code action" units में software को संभालने की क्षमता बेहद उपयोगी है
• इसे अपनाने, सेट करने, इस्तेमाल सीखने, और क्या संभव/असंभव है यह समझ लेने पर यह और प्रभावी हो जाता है
• यह लगभग 20 साल के programming करियर में base coding workflow का सबसे बड़ा बदलाव है, और यह सिर्फ कुछ हफ्तों में हुआ है
• अनुमान है कि काफ़ी संख्या में इंजीनियरों (दो-अंकीय प्रतिशत) के साथ भी ऐसा हो रहा होगा, लेकिन आम जनता की समझ अभी शायद शुरुआती single-digit प्रतिशत स्तर पर है

IDE/agent swarm/error की संभावना

• "अब IDE की ज़रूरत नहीं" या "agent swarm" जैसी hype अभी के लिए बढ़ा-चढ़ाकर कही गई लगती है
• model अब भी ग़लतियाँ करते हैं, और अगर कोड वास्तव में महत्वपूर्ण है तो बाज़ जैसी नज़र से निगरानी करनी पड़ती है, इसलिए बगल में एक बड़ा IDE खुला होना ज़रूरी है
• ग़लतियों का स्वरूप बदल गया है: अब यह साधारण syntax error नहीं, बल्कि थोड़े लापरवाह और जल्दबाज़ junior developer जैसी सूक्ष्म conceptual errors हैं
• सबसे आम error type: उपयोगकर्ता की जगह गलत assumptions बना लेना और बिना पुष्टि किए उसी पर आगे बढ़ जाना
• अतिरिक्त समस्याएँ:
  • confusion को manage नहीं कर पाना
  • clarification नहीं माँगना
  • inconsistency को सामने नहीं लाना
  • trade-off पेश नहीं करना
  • जहाँ विरोध करना चाहिए वहाँ नहीं करना
  • अब भी कुछ हद तक sycophantic प्रवृत्ति होना
• plan mode में स्थिति बेहतर होती है, लेकिन हल्का inline plan mode चाहिए
• code और API को ज़रूरत से ज़्यादा complex बनाने, abstraction को फुलाने, और काम के बाद dead code साफ़ न करने की प्रवृत्ति भी है
• कभी-कभी 1000 lines में अक्षम, फूला हुआ और नाज़ुक structure बना देता है, लेकिन जब पूछा जाए, "क्या इसे ऐसे नहीं किया जा सकता?", तो जवाब आता है "बिल्कुल!" और तुरंत उसे 100 lines में घटा देता है
• काम से असंबंधित होने पर भी, जो comments और code उसे पसंद नहीं आते या पूरी तरह समझ नहीं आते, उन्हें बदल/हटा देने की प्रवृत्ति अब भी है
• CLAUDE.md में निर्देश डालकर साधारण सुधार की कोशिश करने पर भी ये समस्याएँ आती हैं
• इन समस्याओं के बावजूद यह अब भी शुद्ध रूप से बहुत बड़ा improvement है, और manual coding पर लौटना बहुत मुश्किल लगता है
• मौजूदा workflow: बाईं ओर ghostty window/tab में कुछ Claude Code sessions, और दाईं ओर IDE में code की जाँच और manual edits

Tenacity

• agent को बिना रुके किसी चीज़ से जूझते देखना बेहद दिलचस्प है
• यह थकता नहीं, हतोत्साहित नहीं होता, और जहाँ इंसान काफ़ी पहले हार मानकर बाद में लौटने की सोचता, वहाँ भी यह कोशिश जारी रखता है
• किसी चीज़ से लंबे समय तक जूझकर 30 मिनट बाद आख़िरकार सफल होते देखना "AGI महसूस होने" जैसा पल लगता है
• इससे एहसास होता है कि stamina ही काम का मुख्य bottleneck है, और LLM हाथ में हो तो यह नाटकीय रूप से बढ़ जाता है

speedup

• LLM की मदद से होने वाले "speedup" को कैसे मापा जाए, यह स्पष्ट नहीं है
• जो काम करना था वह निश्चित रूप से काफ़ी तेज़ महसूस होता है, लेकिन मुख्य असर यह है कि सोचे गए काम से कहीं ज़्यादा चीज़ें की जाने लगती हैं:
  • हर तरह की ऐसी चीज़ें भी code की जा सकती हैं, जिन्हें पहले coding के लायक नहीं समझा जाता था
  • knowledge/skill की समस्या के कारण जिन codebases पर पहले काम नहीं कर सकते थे, अब उन तक पहुँचना संभव है
• यह speedup है, लेकिन बड़ा हिस्सा शायद expansion है

leverage

• LLM किसी खास लक्ष्य के पूरा होने तक loop चलाने में शानदार है, और यही उस "AGI-feeling" वाले जादू का बड़ा हिस्सा है
• इसे क्या करना है यह step-by-step बताने के बजाय, success criteria दें और फिर देखें
• tests पहले लिखवाएँ और फिर उन्हें pass करवाएँ
• इसे browser MCP और loop में डालें
• पहले ऐसा naive algorithm लिखवाएँ जिसकी correctness बहुत ऊँची होने की संभावना हो, फिर correctness बनाए रखते हुए optimization माँगें
• अगर तरीका imperative से declarative में बदला जाए, तो agent ज़्यादा देर तक loop चलाकर ज़्यादा leverage देता है

मज़ा

• अप्रत्याशित बात यह है कि agent के साथ programming ज़्यादा मज़ेदार हो जाती है
• blank-filling जैसी उबाऊ मेहनत हट जाती है और सिर्फ creative हिस्सा बचता है
• रुकावट/ठहराव (मज़ा न आने वाली स्थिति) कम हो जाती है, और ज़्यादा हिम्मत महसूस होती है — क्योंकि साथ में हमेशा सकारात्मक प्रगति का कोई न कोई रास्ता होता है
• कुछ लोगों की भावना उलटी भी है: LLM coding कोडिंग को ही पसंद करने वाले engineers और कुछ बनाने को पसंद करने वाले engineers में बाँट देगी

Atrophy

• यह महसूस होने लगा है कि हाथ से code लिखने की क्षमता धीरे-धीरे atrophy होने लगी है
• generation (code लिखना) और discrimination (code पढ़ना) दिमाग़ की अलग-अलग क्षमताएँ हैं
• programming से जुड़ी छोटी syntax details के कारण, लिखने में कठिनाई हो सकती है लेकिन code review आराम से किया जा सकता है

Slopacolypse

• अनुमान है कि 2026 GitHub, Substack, arXiv, X/Instagram और आम तौर पर हर digital media में Slopacolypse (कम-गुणवत्ता वाले AI-generated content की बाढ़) का साल होगा
• वास्तविक सुधारों के अलावा, बहुत ज़्यादा AI hype productivity theater भी दिखाई देगा (क्या यह और भी संभव है?)

सवाल

• "10X engineer" के साथ क्या हो रहा होगा? — औसत और शीर्ष engineers के बीच productivity ratio? यह ratio काफ़ी बढ़ सकता है
• LLM से लैस होने पर, क्या generalist धीरे-धीरे specialist से आगे निकलेंगे? LLM blank-filling (micro) में grand strategy (macro) की तुलना में बहुत बेहतर है
• भविष्य की LLM coding कैसी लगेगी? क्या यह StarCraft खेलने जैसी होगी? या Factorio खेलने, या संगीत बजाने जैसी?
• समाज का कितना हिस्सा digital knowledge work के bottleneck से अटका हुआ है?

TLDR

• Claude और Codex जैसे LLM agent capabilities ने 2025 के दिसंबर के आसपास किसी तरह का consistency threshold पार कर लिया है, जिससे software engineering और संबंधित क्षेत्रों में phase shift आया है
• ऐसा लगता है कि intelligence वाला हिस्सा अचानक बाकी सब चीज़ों — integration (tools, knowledge), नए organizational workflows की ज़रूरत, process, और व्यापक diffusion — से काफ़ी आगे निकल गया है
• 2026 वह साल होगा जब industry इस नई capability को absorb करने में high-energy year देखेगी

[xguru]

इस लेख की सामग्री के आधार पर Claude Code के व्यवहार को बेहतर बनाने वाला skills version भी जारी किया गया है।

Karpathy-Inspired Claude Code Guidelines : https://github.com/forrestchang/andrej-karpathy-skills

[pencil6962]

मुझे लग रहा है कि मैं उस 20% को बहुत नज़रअंदाज़ कर रहा था
हाल ही में एक ऐसा bug मिला जिसे AI हल नहीं कर पाया... यह सर्वशक्तिमान तो नहीं है, लेकिन मैं इसे मानो सर्वशक्तिमान समझ रहा था—इस बात का एहसास हुआ।

[hmmhmmhm]

अरे... हाहाहा

[click]

यह सवाल बार-बार मन में आता है—जो लोग पहले से हाथ से कोडिंग करने के अभ्यस्त हैं, उनके लिए LLM को सुपरवाइज़ करना ठीक है, लेकिन जो लोग नए सिरे से सीख रहे हैं, अगर वे सिर्फ LLM द्वारा बनाया गया कोड ही देखते रहें, तो उनके लिए यह समझना मुश्किल होगा कि यह सही है या नहीं।
क्या पुराने ज़माने में जो लोग assembly में लिखते थे, उन्होंने compiler आने पर यह सोचा होगा कि इतना खराब assembly output देने वाले compiler पर कैसे भरोसा किया जाए?
शायद उस समय भी लोग C में लिखते हुए इस तरह कोडिंग करते होंगे कि assembly output उनकी मर्ज़ी के मुताबिक आए।
यह भी जिज्ञासा है कि अगर AI का दौर और आगे बढ़े, तो क्या इंसानी निगरानी के बिना natural language से ही पूरा तैयार परिणाम अच्छी तरह निकलने लगेगा।

[pencil6962]

जब लोग खुद कोड लिखा करते थे, तब भी लगता है कि अगर पढ़ाई नहीं करो तो पता ही नहीं चलता था कि क्या गलत हुआ है lol

[jokerized]

असेंबली के विशेषज्ञ आज भी compiler को कोसते हैं। आखिरकार अहम बात यह है कि जिन हालात में चरम स्तर की optimization चाहिए, वहाँ ऐसे specialist की ज़रूरत होती है। इसे AI पर लागू करके देखें तो, AI कितना भी आगे बढ़ जाए, बेहद उच्च स्तर पर कोड लिखने वाले लोगों को हराना उसके लिए मुश्किल हो सकता है। हालांकि सामान्य तौर पर तो AI के सामने अब कोई भी इंसान जीत नहीं सकता। अगर एक और AlphaGo moment की तरह AlphaCode मुकाबला हो, तो मज़ेदार होगा।

[beoks]

अगर उसके बनाए गए कोड का विश्लेषण करने और उसे समझने की कोशिश की जाए, तो शायद यह ठीक रहेगा.

Compiler थोड़ा अलग concept है; क्योंकि वह rule-based तरीके से assembly generate करता है, इसलिए वह deterministic domain है. इस वजह से एक बार review कर लेने पर वही समस्या दोबारा नहीं होती, लेकिन LLM probabilistic domain में है, इसलिए समस्या के फिर से होने की गुंजाइश रहती है.

हो सकता है कि probability-based accuracy आगे बढ़कर 100% के करीब पहुंच जाए, लेकिन अगर natural language requirement ही अस्पष्ट हो, तो आखिरकार नतीजा भी अस्पष्ट ही होगा. इसलिए मुझे लगता है कि अच्छा final output आखिरकार इंसान पर ही निर्भर करता है.

[dbs0829]

मुझे भी उन जूनियर लोगों की चिंता होती है जिन्होंने छात्र जीवन से ही LLMs को इस्तेमाल करना शुरू किया है। ऐसा भी लगता है कि जूनियर hiring pool थोड़ा खराब हुआ है, लेकिन इसे साबित करना फिर भी मुश्किल है...

[gulbi135]

व्यक्तिगत तौर पर मुझे लगता है कि अगर आपके पास सिर्फ़ CS knowledge है, तो बहुत ज़्यादा फ़र्क नहीं पड़ता।
या फिर शायद ऐसा इसलिए हो सकता है क्योंकि मैं अभी इसे इस तरह इस्तेमाल करता हूँ, जैसे बहुत तेज़ हाथ वाला और सारा code टाइप करके दे देने वाला कोई दोस्त के साथ pair programming कर रहा हूँ...

[click]

आखिरकार जब गहराई से development करते हैं, तो एक समय ऐसा आता ही है जब abstraction layer के अंदर क्या है यह जानना पड़ता है
natural language prompt और generated code के बीच का फ़ासला बहुत बड़ा है, इसलिए prompt से LLM abstraction layer के अंदर जाना मुश्किल लगता है

अभी हम जो कर रहे हैं, वह यह है कि दिमाग में मौजूद spec की अवधारणा को prompt के रूप में LLM तक पहुँचाते हैं, फिर लिखे गए code को दोबारा पढ़कर verify करते हैं
इसलिए यह किसी दूसरे व्यक्ति द्वारा लिखे गए code को review करने के ज़्यादा क़रीब लगता है, abstraction के अंदर जाने जैसा नहीं

[ragingwind]

मैं इससे काफ़ी सहमत हूँ। हाल की परियोजना में मैंने लगभग 1 लाख पंक्तियों का code commit किया है (असल code की मात्रा इससे भी ज़्यादा है) और औसतन 2-3 agent इस्तेमाल कर रहा हूँ। मुझे लगता है कि लगभग 95% चीज़ें agent ही लिख रहे हैं।

[ragingwind]

लेकिन फिर भी टेस्ट और dead code के लिए प्रबंधन की ज़रूरत बनी रहती है, और test cases तथा test pass criteria के विवरण की भी आवश्यकता होती है। क्या और कहाँ तक करना है, इसका प्रबंधन महत्वपूर्ण है। इसके लिए सिर्फ प्लान ही नहीं, बल्कि harness उपलब्ध कराने वाली architecture, Rules जैसी settings को भी लगातार अपडेट करना पड़ता है।

[GN⁺]

Hacker News की राय

• एजेंट को थके बिना लगातार कोशिश करते देखना दिलचस्प है
  GPU और NPU गर्म होकर चलते रहते हैं, और हम वह डेटा भी सौंप रहे हैं जिसे हम सामान्यतः साझा नहीं करते
  अभी यह एक सुविधाजनक सौदा लगता है, लेकिन लंबे समय में निर्भरता और सामाजिक समस्याओं के बढ़ने का जोखिम है
  आखिरकार यह हमें इन विशाल gatekeepers पर निर्भर संरचना में बदल सकता है

  • मुझे लगता है लगातार लगे रहना पिछले 20 सालों से टेक इंडस्ट्री में सफलता का मुख्य तत्व रहा है
    • नए protocol या framework बनाने वालों से कहीं ज्यादा लोग ऐसे रहे हैं जिन्होंने जटिल systems को अंत तक पकड़े रखा और हल किया
    • Claude जैसे models ठीक वही persistence दिखाते हैं
  • लेकिन ऐसी persistence हमेशा अच्छी नहीं होती
    • कई बार यह हथौड़े से पेंच ठोकने जैसा लगता है, यानी समस्या को अक्षम तरीके से हल करने की कोशिश
    • अल्पकाल में परिणाम मिल जाते हैं, लेकिन दीर्घकाल में दुष्प्रभाव छोड़ जाते हैं
  • यह मानना कठिन है कि AI हमेशा सही दिशा में जाता है
    • test न होने वाले हिस्सों में यह नए bugs बना देता है, या वे implicit rules तोड़ देता है जिन्हें इंसान स्वाभाविक रूप से मानते हैं
    • अंत में इसका एहसास ऐसा होता है जैसे “थोड़ा और coin डालिए, इस बार मैं सच में इसे ठीक कर दूँगा”
  • cost की चिंता मुझे बढ़ा-चढ़ाकर कही गई लगती है
    • Kimi K2.5 और GLM 4.7 जैसे open models पहले ही commercial स्तर के करीब पहुँच चुके हैं, और operating cost भी कम है
    • असली पैसा training stage में लगता है; inference stage तो मुनाफ़ा देने वाली संरचना है
  • मैं इस बात से सहमत हूँ कि “AI लगातार सस्ता होता जाएगा”
    • मानव इतिहास में बहुत कम तकनीकें ऐसी रही हैं जो महंगी ही बनी रहीं
    • वास्तव में पिछले साल की तुलना में लागत लगभग आधी हो चुकी है

• AI के साथ काम करते हुए दिमाग़ी सुस्ती से बड़ी समस्या शायद आत्मसंतोष और निष्क्रियता बन जाना है
  शुरुआत में तेज़ नतीजों से dopamine मिलता है, लेकिन बार-बार ऐसा होने पर लगता है कि AI प्रोजेक्ट की दिशा को अपनी मर्जी से खींच रहा है
  अंत में जिन रचनात्मक प्रयोगों की मैं तलाश कर रहा था वे गायब हो जाते हैं, और मैं AI के latent space gravity में खिंच जाता हूँ
  यह कुछ-कुछ doomscrolling जैसा है, एक नशे वाला loop जिसमें अगला output देखने का मन करता रहता है

  • मेरा अनुभव भी कुछ ऐसा ही रहा है
    Rust और Bevy के साथ मैं multiplayer game बना रहा हूँ, और code चल भी रहा है, फिर भी वह ऐसा code बन जाता है जिसे मैं समझता नहीं हूँ
    पहले मैं यहाँ तक तभी पहुँचता जब tool को पूरी तरह समझ लेता, लेकिन अब मैंने आधा-चलता game बना लिया है और ECS क्या है यह भी नहीं जानता
    maintenance या emergency response के बारे में सोचें तो यह सचमुच खतरनाक स्थिति है
  • समस्या सिर्फ दिमाग़ी सुस्ती नहीं, बल्कि सीखने की दिशा बदल जाना है
    हम अब models को सीखने पर ज़्यादा ध्यान दे रहे हैं, और खुद सोचने का तरीका भूल रहे हैं
    LLM इस्तेमाल करने के तरीके लगातार बदलते रहते हैं, इसलिए हम मानो एक अंतहीन learning treadmill पर खड़े हैं
  • दूसरी ओर कुछ लोग कहते हैं, “coding साइकिल चलाने जैसी है”
    लंबे अंतराल के बाद भी उसकी समझ बची रहती है, और दोबारा करने पर जल्दी लौट आती है
  • एक और समस्या है ‘पढ़ने की क्षमता का सिकुड़ना’
    अगर LLM को कुछ नहीं पता हो तो कई developers बस हार मान लेते हैं और documentation पढ़ना नहीं चाहते
    सीधे docs पढ़कर screenshot दिखाने पर भी वे पूछते हैं, “क्या यह सच में सही है?”
  • LLM का उपयोग TikTok-शैली dopamine loop जैसा भी लगता है
    छोटी-छोटी तात्कालिक संतुष्टि के लिए हम लगातार prompts फेंकते रहते हैं और इंतज़ार करते हैं कि “इस बार क्या निकलेगा”

• LLM coding ने ‘coding पसंद करने वाले लोगों’ और ‘building पसंद करने वाले लोगों’ को अलग करने का काम किया है
  मैं नतीजे बनाना पसंद करने वाला builder-type हूँ, इसलिए यह बदलाव मुझे अच्छा लगता है
  दूसरी तरफ जो लोग coding को ही पसंद करते हैं, उन्हें यह रुझान असहज करता है

  • मैं भी उन्हीं में से एक हूँ
    programming का आकर्षण समस्या को संरचित करने और खुद उसे लागू करने की प्रक्रिया में था
    अब एहसास यह है कि “मैं coding नहीं कर रहा, बस उससे करवाता हूँ”, इसलिए रुचि कम हो रही है
  • सच कहें तो ऐसी बहस नई नहीं है
    पहले भी compile vs interpret, typed vs untyped, fast deployment vs maintainability जैसी बहसें रही हैं
    अंततः सफल software अराजक शुरुआती चरण से स्थिर विस्तार वाले चरण में जाने की प्रक्रिया से गुजरता है
    AI इस प्रक्रिया में मदद करता है या उल्टा इसे और जटिल बनाता है, इस पर अभी भरोसे से कुछ कहना मुश्किल है
  • एक और नज़रिया यह है कि कुछ लोग ‘design करने की प्रक्रिया’ को ही पसंद करते हैं
    उन्हें सिर्फ अंतिम उत्पाद नहीं, बल्कि system structure बनाने की प्रक्रिया में मज़ा आता है
  • LLM skepticism को top-down vs bottom-up development style के टकराव की तरह भी देखा जा सकता है
  • लेकिन “क्या AI पर भरोसा किया जा सकता है” यह सवाल अभी भी बना हुआ है
    इंसानी teammates के साथ जवाबदेही और भरोसा होता है, LLM के साथ नहीं

• यह विचार दिलचस्प है कि AI 10x productivity boost ला सकता है
  DevOps ने development-operations collaboration का तरीका बदलकर high-performance teams बनाए, और यह टीम स्तर पर 10X जैसे असर के करीब पहुँचा
  AI coding का सही उपयोग करने के लिए भी DevOps की तरह continuous improvement, workflow changes, और automation/validation के जरिए भरोसा बनाने की प्रक्रिया चाहिए
  DevOps भी इसलिए व्यापक नहीं हो पाया क्योंकि उसमें नई concepts सीखनी पड़ती थीं और टीम संस्कृति बदलनी पड़ती थी; उसी तरह AI coding में भी सीखने और संस्कृति के बदलाव के बिना 10X potential होने पर भी अपनाने की रफ़्तार धीमी रह सकती है
  इसे स्थापित करने के लिए education और engineering culture में बदलाव ज़रूरी है

• मुझे लगा कि LLM बड़े codebase में बेकार है
  खासकर जटिल और बहुत interdependent code में यह लगभग मदद नहीं करता

  • लेकिन मैंने Claude code से 98% लिखी गई iOS app सिर्फ 3 महीनों में पूरी कर ली
  • “ऐसे ज़्यादातर उदाहरण greenfield projects होते हैं”
    इसे किसी बड़े मौजूदा/जटिल codebase में डालना, यदि बदलाव सीमित और गहन review वाले न हों, तो जोखिमभरा है
    साधारण संरचना में files की सूची देकर agent से implementation करवाना प्रभावशाली लगता है, लेकिन complexity बढ़ने पर prompt को लगातार अधिक विस्तृत निर्देशों तक नीचे आना पड़ता है तभी परिणाम मिलते हैं
  • “ChatGPT नहीं, Codex या Claude CLI जैसे local context tools का इस्तेमाल करना चाहिए”
  • Opus 4.5 model सचमुच turning point था
    पहले के models से अलग, अब यह जटिल monorepo में भी वास्तविक मदद देता है
  • “LLM बेकार है” वाला आकलन context की कमी की वजह से हो सकता है
    तुलना करनी चाहिए कि वही जानकारी देकर नया team member काम करे तो क्या वह इससे बेहतर करता
  • LLM का रुझान LLM द्वारा बनाए गए codebase में बेहतर काम करने की तरफ होता है
    commercial internal codebases ग्राहक की मांग के अनुसार दोहराए गए development से बिखर जाते हैं, शुरुआती assumptions और requirements धीरे-धीरे अलग हो जाते हैं, और technical debt बनती जाती है
    अगर LLM का उपयोग helper separation/modularization/renaming जैसे refactors के लिए कर, मौजूदा requirements के हिसाब से उसे व्यवस्थित किया जाए, तो बाद में agents का व्यवहार अधिक पूर्वानुमेय हो जाता है
  • अच्छी documentation, architecture explanation, और style guide जैसी project context की स्पष्टता बहुत महत्वपूर्ण है
    requirements/acceptance criteria/user stories को markdown में व्यवस्थित करना, फिर plan को विस्तार से लिखवाना, और उसके बाद implementation की ओर बढ़ना—ऐसा चरणबद्ध flow चाहिए

• AI की persistence और stamina का इंसानी सीमाओं से आगे निकल जाना प्रभावशाली है
  research में भी कहा जाता है कि intelligence से ज्यादा grit सफलता से जुड़ा है
  LLM के पास, जब तक budget इजाज़त दे, लगभग असीम persistence होती है

• पिछले कुछ महीनों में ऐसा लगा कि AI की performance उल्टा पीछे गई है
  यह rules भूल जाता है, और अत्यधिक planning तथा overengineered code बनाता है
  फिर भी frontend (HTML + Tailwind) में यह अब भी उपयोगी है

  • इस पर किसी ने कहा, “यह तो मानो FrontPage के दौर में लौटने जैसा है”
  • किसी और ने कहा, “वह शायद Sonnet model होगा, Opus 4.5 आज़माइए”

• IDE या agent swarm को लेकर बहुत ज़्यादा उम्मीदें रखना अभी जल्दबाज़ी लगता है

  • मैं 10 साल से इस्तेमाल हो रहे JetBrains को छोड़कर अब सिर्फ Zed और Claude Code इस्तेमाल कर रहा हूँ
  • जो काम पहले कई महीनों में होता था, वह अब कुछ घंटों में पूरा हो जाता है

• iPhone app बनाते समय Claude की English prompt-आधारित code generation क्षमता ने प्रभावित किया

  • Swift का अनुभव न होने पर भी सिर्फ C++ background से पर्याप्त प्रगति हो गई
  • बड़े prompts की जगह छोटे-छोटे हिस्सों में features जोड़कर review करने का तरीका कहीं अधिक प्रभावी है
  • इस प्रक्रिया को Prompt → Review → Test (PRET) नाम का नया workflow कहा जा रहा है

[heycalmdown]

LLM coding से इंजीनियर दो हिस्सों में बंटने लगते हैं: एक वे जिन्हें coding खुद पसंद है, और दूसरे वे जिन्हें चीज़ें बनाना पसंद है।

मैंने भी अपने आसपास जो बातें सुनी हैं, उन्हें मिलाकर देखूं तो आखिरकार बात कुछ ऐसी ही लगती है।