अनंत Sloptember

• AI एजेंट प्रोग्रामिंग करने के बजाय प्रोग्रामिंग के वितरण की नकल करते हैं, और टूटा हुआ आउटपुट धीरे-धीरे पहचानना और कठिन होता जाता है
• इसे tinygrad के कुछ हिस्से लिखने और USB <-> PCIe चिप reverse करने में इस्तेमाल किया गया, लेकिन यह शक बना रहा कि इसे सीधे खुद करना बेहतर और तेज़ हो सकता था
• एजेंट शुरुआती प्रगति तेज़ कर देते हैं, लेकिन अंत में slot machine lever की तरह बार-बार कोशिशों पर निर्भर करा देते हैं और काम को आखिर तक नहीं पहुँचा पाते
• बड़े संगठन धीमे feedback loop और self-check के बिना 10x output के कारण, उच्च-प्रदर्शन वाले व्यक्तियों की तुलना में गुणवत्ता को अधिक नुकसान पहुँचा सकते हैं
• AI search और तेज़ prototyping में उपयोगी है, लेकिन इसे वास्तविक software engineer मानना कठिन है, और असली बात यह जानना है कि इसे कब इस्तेमाल न किया जाए

---

AI एजेंटों पर मुख्य आलोचना

• software development में AI एजेंट अपनाने की प्रवृत्ति बहुत costly गलती साबित हो सकती है, और एजेंट प्रोग्रामिंग स्वयं नहीं बल्कि प्रोग्रामिंग के वितरण की नकल करने वाले परिष्कृत statistical model के अधिक करीब हैं
• आउटपुट टूटा हुआ होता है, लेकिन ऐसे तरीके से टूटता है जिसे पहचानना लगातार कठिन होता जाता है, और statistical model जितने अधिक सटीक होते जाते हैं, यह समस्या उतनी ही कम दिखाई देती है
• पिछले 6 महीनों में एजेंटों से tinygrad के कुछ हिस्से लिखवाए और USB <-> PCIe चिप reverse की, लेकिन यह संदेह बना रहा कि अगर सीधे खुद किया होता तो शायद बेहतर और तेज़ होता
• एजेंट शुरुआती प्रगति को आगे बढ़ाते हैं, लेकिन finishing चरण में slot machine lever खींचने की तरह बार-बार यह उम्मीद बँधाते हैं कि अगला परिणाम बेहतर होगा, और फिर भी मंज़िल तक नहीं पहुँचते
• कई model, harness और prompt आज़माए गए, इसलिए “इसे गलत तरीके से इस्तेमाल किया गया” वाला प्रतिवाद कमज़ोर लगता है, और यह उस दावे जैसा सुनाई देता है कि slot machine में किसी खास तरीके से दाँव लगाकर जीता जा सकता है
• AI स्वयं उपयोगी है; कई search में यह बेहतर Google की तरह काम करता है, और जहाँ polish की ज़्यादा चिंता नहीं होती वहाँ तेज़ prototype बनाने में बेहद तेज़ है
• लेकिन इसे software engineer कहना मुश्किल है, और यह उन किसी भी company standards के करीब नहीं है जिनके साथ लेखक ने काम किया है; असली बात यह जानना है कि इसे कब इस्तेमाल करना है और कब नहीं

संगठनों और गुणवत्ता पर प्रभाव

• AFL ने LLM की तुलना में अधिक bug खोजे, लेकिन developers ने status खोने का डर नहीं दिखाया, और chess व Go भी AI के बाद और लोकप्रिय हुए; इसलिए AI की आलोचना को सिर्फ status anxiety मानना कठिन है
• ऐसा भविष्य आकर्षक है जहाँ भरोसेमंद robotic assistant code को व्यवस्थित करे, लेकिन बड़े संगठनों को चलाने के लिए loss aversion का इस्तेमाल एजेंट बेचने में किया जा रहा है, ऐसा लगता है
• बड़े संगठन उच्च-प्रदर्शन वाले व्यक्तियों या छोटे संगठनों की तुलना में एजेंटों से अधिक नुकसान झेल सकते हैं
  • उच्च-प्रदर्शन वाले लोग त्रुटियाँ ठीक कर सकते हैं, ढीले-ढाले output को पहचान लेते हैं, और सीमित क्षेत्र न हो तो हर line को ध्यान से पढ़ने और समझने की आदत बनाए रखते हैं
  • बड़े संगठनों में feedback loop धीमे और alignment कमज़ोर होते हैं, इसलिए जब कम-प्रदर्शन वाले लोग self-check के बिना एजेंटों से 10x output बनाते हैं, तो औसत output quality गिर सकती है
• एजेंट पहले से अधिक code, app और feature बनाएँगे, लेकिन यह उच्च-गुणवत्ता वाले रत्नों की तुलना में बड़ी मात्रा में ढीले-ढाले output के जमाव का युग बन सकता है
• यह खबर कि Apple अपने सभी engineers पर AI के उपयोग के लिए दबाव डाल रहा है, इसे अमूर्त उम्मीद की तरह नहीं बल्कि इस ठोस सवाल से देखना चाहिए कि “अगले 2 वर्षों में macOS बेहतर होगा या बदतर”
• लोग किसी output को देखते समय चुपचाप मान लेते हैं कि उसके रचनाकार ने मानवीय मानसिक अवस्था और प्रक्रिया से होकर काम किया है, लेकिन AI output के मामले में यह मान्यता अब सही नहीं रहती
• grammar और syntax जैसे तत्व, जो पहले quality के proxy indicator माने जाते थे, AI output के सामने कम उपयोगी हो जाते हैं; अंतर तब दिखता है जब इंसानी तरीके से उसके साथ interact किया जाए या उसके ऊपर कुछ बनाया जाए
• LLM को लेकर दृष्टिकोण LeCun/Marcus वाले रुख के अधिक करीब आ गया है, और निष्कर्ष यह है कि ऐसे model प्रोग्रामिंग नहीं कर सकते और process महत्वपूर्ण है
• deep learning अब भी समाधान हो सकता है, लेकिन वास्तविक programming agent के लिए failing test को comment out करके फिर यह कह देने वाला RLVR नहीं, बल्कि world model चाहिए
• इस दौर का मूल प्रश्न यह हो सकता है कि AI को लेकर सामूहिक overhype के बीच कौन लोग खुद को नुकसान पहुँचाए बिना टिके रहते हैं

[GN⁺]

Hacker News की राय

• मौजूदा विमर्श की बड़ी समस्या यह है कि यह बहुत ज़्यादा काले-सफेद वाली सोच पर टिका है। अगर आप LLM पर शक करें तो आप लुडाइट हैं, और अगर भरोसा करें तो “ai pilled” हैं
  ज़्यादातर मामलों में LLM आपको 80~95% तक पहुँचा देता है, और कभी-कभी इससे कम या ज़्यादा अच्छा भी करता है। कभी-कभी तो यह आपको पूरी तरह गलत दिशा में भी ले जाता है
  लेकिन सब लोग मानो सिर्फ इस बात पर लड़ रहे हैं कि क्या LLM अकेले किसी अलमारी में बैठकर एक परफेक्ट software engineer बन सकता है, और उसी के आधार पर दूसरे scenarios में उसकी विशाल संभावनाओं तक को नकार रहे हैं
  अगर सिर्फ इंटरनेट ने जो दिया है, उसी से सोचें कि ज़्यादातर संगठन आज से कितने अधिक productive हो सकते थे, तो असली कंपनियाँ अक्सर संभव चीज़ों का बहुत छोटा हिस्सा भी नहीं कर पातीं। LLM को भी मैं उसी नज़र से देखता हूँ
  गलती language model की नहीं, हमारी अपनी है

  • असली लुडाइट्स के बारे में जितना अधिक जानता हूँ, उनका नज़रिया उतना अधिक समझ में आता है
    मूल लुडाइट वे लोग थे जो उन मशीनों का विरोध कर रहे थे जो घटिया सामान को “धोखाधड़ी और भ्रामक” तरीके से बनाती थीं, श्रम मानकों को दरकिनार करती थीं, और कुशल कारीगरों की रोज़ी-रोटी छीन लेती थीं
  • इसे तर्कसंगत बहस बन पाने से रोकने के लिए यहाँ बहुत ज़्यादा पैसा लगा हुआ है
  • लेख खास तौर पर एजेंट्स की बात करता है: “software development में AI agents को लाना इस क्षेत्र के इतिहास की सबसे महंगी गलतियों में से एक हो सकता है”
    मैं agents का उपयोग नहीं करता, बल्कि साधारण chat interface और लगातार चलने वाली बातचीत के जरिए function स्तर पर software बनाता हूँ। नतीजे का workflow काफ़ी “chimera-जैसा” है, और उसे मेरे अनुभव और विशेषज्ञता से बड़ा लाभ मिलता है। LLM बस प्रक्रिया को smooth बनाता है
    मेरे लिए यह अच्छी तरह काम कर रहा है, और मैं पुराने तरीके पर वापस नहीं जाना चाहता
  • geohot की बात भी कुछ ऐसी ही लगती है। न तो पूरी तरह “ai pilled” हो जाना, न ही लुडाइट बन जाना, बल्कि AI को एक tool की तरह इस्तेमाल करना
  • लुडाइट सिर्फ साधारण “अविश्वासी” नहीं थे, बल्कि हिंसक कार्यकर्ता थे
    आज के विमर्श में जिन्हें “लुडाइट” कहा जाता है, वे आमतौर पर वे लोग हैं जो “AI” hype पर सवाल उठाने की हिम्मत करते हैं। आम तौर पर ऐसे लोग कार्यकर्ता भी नहीं होते

• AI की मौजूदा क्षमता के स्तर पर, इसे मौजूदा ज्ञान के ऊपर काम करने वाली बहुत अच्छी search के रूप में देखना मुझे निजी तौर पर उपयोगी लगा। यह reference books, Stack Overflow, और GitHub तक फैली searchable knowledge की अगली अवस्था जैसा लगता है
  programmers शायद मेरी कल्पना में आने वाले किसी भी पेशे से ज़्यादा बार वही techniques दोबारा इस्तेमाल करते और फिर से invent करते हैं, इसलिए prior art को बहुत अच्छी तरह खोजने वाला tool उनके लिए स्वाभाविक रूप से उपयुक्त था। और यह कि AI उस prior art को किसी खास use case के हिसाब से ढाल सकता है, इसे और शक्तिशाली बनाता है
  लेकिन जैसे Stack Overflow से कॉपी किए गए code snippets जोड़ देने भर से बड़ी सफलता नहीं मिलती, वैसे ही मौजूदा AI भी पूरा project ठीक से बनाकर नहीं दे सकता

  • यह साफ़ होता जा रहा है कि जवाब reusable libraries में बहुत अच्छे से package करने से ज़्यादा, दोबारा लिखने और re-invent करने की लागत घटाने वाले tools में है
  • मैं 100% सहमत हूँ कि मौजूदा AI Stack Overflow और Google के मज़बूत संस्करण के अधिक करीब है। मेरे अनुभव में, शुरुआती skeleton को छोड़ दें तो यह full-scale applications अच्छी तरह build नहीं कर पाता
    अगर कोई पुराना और कम इस्तेमाल होने वाला legacy codebase हो, तो उदाहरण के लिए “application X, Y कैसे करता है” जैसे सवाल के लिए AI agent से code पढ़वाया जा सकता है। लेकिन मैं उससे features धड़ाधड़ बनवाने या refactoring करवाने की ज़िम्मेदारी नहीं दूँगा
    ऐसा करने पर commits बहुत ज़्यादा हो जाते हैं और dev team में भ्रम पैदा होता है, जिससे नतीजा उस मौजूदा खिचड़ी से भी बदतर हो सकता है जिसे वे पहले से संभाल रहे हैं। हाल में मैं AI से कुछ निराश रहा हूँ, और यह व्याख्या मेरे अनुभव को अच्छी तरह समेटती है
  • “AI prior art को किसी खास use case के हिसाब से ढाल सकता है” — यही तो आखिर सब लोग कह रहे हैं

• software engineering में सबसे मुश्किल काम सही समस्या को हल करना है। मुझे लगता है कि कौन-सी समस्या हल की जानी चाहिए, यह पहचानने की क्षमता ही top senior engineers को अलग करती है
  यहाँ सरल करके कहें तो, वह समस्या सही है जिसे हल करने पर product में जुड़ने वाला value उसकी complexity और सहायक लागतों की तुलना में सबसे अधिक हो
  बहुत पहले मैं एक web product पर काम करता था, जहाँ एक junior designer को लगा कि backend को LDAP tool से manage कर पाना अच्छा होगा। इसलिए product की database schema और संरचना OpenLDAP की नकल में बनी, composite CN keys का इस्तेमाल हुआ, और पूरा codebase हर बार DB पढ़ते-लिखते उस संरचना से जूझता रहा। DB schema design करते समय LDAP compatibility वह सही समस्या नहीं थी जिसे हल किया जाना चाहिए था
  सही समस्या हल करने वाला software पहचानना मुश्किल हो सकता है। अक्सर वह इतना स्वाभाविक लगता है कि यह दिखता ही नहीं कि कोई दूसरी design भी चुनी जा सकती थी
  समय के साथ गलत समस्या हल करने वाली design के blast radius को सीमित करने वाली चीज़ आम तौर पर वही friction होती है जो वह design पैदा करती है। development धीमा हो जाता है, और गलत समस्याओं को और ज़्यादा हल करने वाला development भी धीमा पड़ जाता है। यह एक self-limiting phenomenon है
  LLM coding agents को लेकर मेरी सबसे बड़ी चिंता यही है। वे उस friction को ढक देते हैं। उसे ठीक नहीं करते, बस उसकी लागत को आगे के लिए टाल देते हैं
  नतीजा यह हो सकता है कि value के मुकाबले complexity अनंत तक बढ़ती जाए और codebase पर नियंत्रण रखने का कोई तंत्र ही न बचे
  juniors उन feedback loops से वंचित रह जाते हैं जो उनकी engineering instinct और taste को विकसित करते हैं, ताकि वे समझ सकें कि किसी खास design में कौन-सी समस्या वास्तव में हल करने लायक है
  पूरे क्षेत्र के पैमाने पर, शायद हम यह तक भूल जाएँ कि सही समस्या हल करना जैसी कोई अवधारणा भी होती थी
  क्या करना चाहिए, मुझे नहीं पता। शायद जल्दी retirement की योजना ही बनानी पड़े

• अभी ऐसे लोग हैं जो grey-market peptides खरीदते हैं और "मानव उपभोग के लिए नहीं" लिखे पदार्थों को सिर्फ संदिग्ध किस्सों और एहसासों के भरोसे इंजेक्ट कर लेते हैं। मकसद होता है त्वचा साफ़ करना और मांसपेशियों का द्रव्यमान बढ़ाना
  क्या वे अचानक सब ज़ॉम्बी बन रहे हैं? नहीं। क्या उन्हें ठीक-ठीक पता है कि कुछ साल बाद उनके शरीर में क्या होगा? वह भी नहीं। क्या यह विनाशकारी हो सकता है? हो सकता है
  पिछले लगभग 6 महीनों में इंडस्ट्री ने जिस उग्रता से AI को code का मुख्य जनरेटर बना दिया है, उसे देखते हुए यही उपमा याद आती है। AI peptide है, और codebase शरीर है। यह तरीका कितना maintainable है, यह सचमुच किसी को नहीं पता। क्योंकि यह जानने लायक समय अभी बीता ही नहीं है
  हो सकता है सब ठीक निकले, और यह भी हो सकता है कि पूरी तरह अफरातफरी बन जाए। पूरी engineering team स्टीयरिंग छोड़कर सो जाए, यह सोचते हुए कि वे समझते हैं कि क्या बना रहे हैं जबकि वे वास्तव में नहीं समझते, और फिर जिस पल LLM इसे संभालना बंद कर दे, उस समय उनके पास उसे ठीक करने या maintain करने की क्षमता ही न बचे
  https://www.bbc.co.uk/news/articles/cdr268m5pxro
  अपने निजी codebase में मैं अब ऐसा नहीं करता, जब तक कि मुझे maintainability या lifespan की सच में परवाह न हो

  • लगता है समझदार developer isolated modules बनाएंगे, ताकि AI-निर्मित module बार-बार fail हो तो उसे काटकर नया बनाया जा सके

• अभी मैं उस तरफ हूँ जहाँ "कुछ समय से मैंने खुद code नहीं लिखा"। मैं ऐसा उदाहरण देखना चाहता हूँ जहाँ समस्या इतनी बड़ी हो कि manual coding पर लौटना पड़े
  मेरी मुख्य समस्या यह है कि हर model release के साथ quality ऊपर-नीचे होती रहती है, और खासकर command-line tools में पुरानी API या documentation घुसा देने की प्रवृत्ति रहती है
  मैं समझ सकता हूँ कि 10 साल के कचरे से भरे दस लाख लाइनों वाले monolithic codebase में model को दिक्कत हो। लेकिन नए codebase में यह इतना कष्टदायक क्यों होगा, यह मुझे साफ़ नहीं दिखता

  • ज़रूरी नहीं कि समस्या "बहुत बड़ी" ही हो। वह इतनी छोटी भी हो सकती है कि इस्तेमाल करने लायक ही न हो
    coding इतनी कठिन नहीं है कि अंग्रेज़ी पढ़ने-लिखने के बजाय सीधे coding करना ज़्यादा आसान न लगे। हालांकि मैं सिर्फ Haskell इस्तेमाल करता हूँ, इसलिए मेरा नज़रिया biased हो सकता है
  • अगर "कुछ समय से खुद code नहीं लिखा" वाली स्थिति चलती रहे, तो आपके हिसाब से कितने समय बाद अभ्यास की कमी से code लिखना ही नहीं आएगा?
    engineering management का एक जोखिम यह है कि वह आपको ऐसा व्यक्ति बना सकती है जो वह काम अब कर ही नहीं सकता
    क्या यह सच में मायने रखता है?
  • अगर हर prompt पर हज़ार-लाइन की PR निकल रही है, तो आप एक और दस लाख लाइनों वाली monolith से बहुत दूर नहीं हैं
    फिर भी मैं लेखक से थोड़ा ज़्यादा आशावादी हूँ। मुझे लगता है कि उस स्थिति से बचने के लिए process को manage करना संभव है
  • हाल में front page पर आया एक उदाहरण: https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/
  • आप किस तरह के project पर काम कर रहे हैं, यह मायने रखता है। खासकर यह कि उसमें novelty कितनी है, search से मुश्किल से मिलने वाले data points कितने हैं, और industry standard से हटकर project-specific non-obvious फर्क कितने हैं

• agent execution environments आए हुए मुश्किल से एक साल हुआ है, और उन्हें काफ़ी भरोसेमंद बने हुए लगभग आधा साल, लेकिन थकान अभी से बहुत है। मेरे हिसाब से यह इस बात से ज़्यादा जुड़ा है कि AI-assisted programming की मानसिक थकावट कैसी है, बजाय इसके कि LLM वास्तव में programming कर सकता है या नहीं
  अगर आपको ठीक से ट्रैक करना है कि agent codebase में क्या कर रहा है, तो decision frequency बढ़ जाती है, और आपको code और गद्य की खगोलीय मात्रा पढ़नी पड़ती है
  यह निजी और मनोवैज्ञानिक थकान, और उससे जुड़ी नकारात्मक भावनाएँ, तकनीक की संभावनाओं पर एक निराशावादी नज़रिए में ग़लत तरीके से बदल रही हैं

  • https://evilmartians.com/chronicles/ai-assisted-engineers-ar...
  • तकनीक इस बात से अलग कोई चीज़ नहीं है कि लोग उसका इस्तेमाल कैसे करते हैं
    अगर जो लोग इसे सही तरह से इस्तेमाल करते हैं वे सब निराश हो रहे हैं, और जिन्हें यह पसंद है वे maintain न किए जा सकने वाले खिचड़ी-जैसे ढेर पहाड़ की तरह बना रहे हैं, तो हम जल्द ही इसे इतिहास के कूड़ेदान में फेंक देंगे
    बहुत-सी चीज़ों में "potential" होता है, लेकिन बहुत-सी अंत में कुछ भी नहीं बनतीं
    मैं LLM का इस्तेमाल करता रहूँगा, लेकिन मेरे हिसाब से agent-style coding की उपयोगिता शायद पहले ही अपनी चोटी पार कर चुकी है

• मेरे काम का एक हिस्सा यह ढूँढना है कि जिस बड़े enterprise में मैं काम करता हूँ वहाँ इन मॉडलों को उत्पादक कैसे बनाया जाए। यह कुछ हद तक दीवार पर टमाटर फेंकने जैसा है, और कुछ मामलों में मुझे भी वैसी समस्याएँ दिखती हैं जैसा उसने कहा — जैसे output की कुछ खास सीमाएँ होती हैं।
  साथ ही, उसके लेख में कहीं भी ऐसा कोई code snippet या ठोस उदाहरण नहीं है जिसे पकड़कर कहा जा सके, “मॉडल ने यहाँ बहुत खराब किया, और इसे असल में ऐसे करना चाहिए था।” इस तरह की आलोचना मुझे blog और Twitter पर बार-बार दिखने वाले “LLM कभी काम नहीं करते” प्रकार के पोस्टों जैसा पैटर्न लगती है।
  मॉडल साफ़ तौर पर autocomplete से बेहतर हैं, और मेरी रोज़मर्रा की development में ये codebase के बड़े हिस्से बना देते हैं, जैसा कोई junior या mid-level engineer करता।
  अगर कोई यह ठोस रूप से उद्धृत ही न करे कि वास्तव में गलती क्या हुई, तो हम इसकी असली क्षमता का आकलन कैसे करें?

  • LLM जो गलतियाँ करते हैं वे काफ़ी सूक्ष्म होती हैं। LLM के साथ coding करना फिल्म Whiplash के एक सीन जैसा लगता है। जैसे, “मेरे tempo में नहीं”, “18वीं beat पर downbeat”, “तुम तेज़ हो”, “धीमे”।
    यह लगभग हमेशा ऐसा code बनाता है जो चलता है, और आम तौर पर वही करता है जो आपने कहा था। लेकिन यह थोड़ा-थोड़ा गलत होता है, वह भी बेहद झुंझलाहट भरे तरीके से, जिससे कुर्सी फेंक देने का मन हो। और ऊपर से इसे इतना भी sense नहीं होता कि क्या और कैसे गलत है।
  • जब लोग किसी खास task में LLM की विफलता पर blog post लिखते हैं, तो समर्थकों की प्रतिक्रिया लगभग हमेशा यही होती है: “कोई दूसरा मॉडल इस्तेमाल करो”, “prompt को ऐसे बदलो”, “तुम्हारी skill कम है। किसी एक उदाहरण से AI के बारे में बुनियादी दावा नहीं किया जा सकता।”
    फिर मतलब यह कि ठोस उदाहरण दो तो भी गलत, और ठोस उदाहरण न दो तो भी गलत। फिर तो खेल ख़त्म ही है।
    मुझे पता है कि मैं group attribution error कर रहा हूँ, लेकिन फिर भी बात यही है।
  • यह बात बहुत अच्छी है। LLM की वजह से, एक beginner के नज़रिए से भी जो अब ऐसे project कर पा रहा है जिनके बारे में पहले सोच भी नहीं सकता था, मैं यह ढूँढना चाहता हूँ कि agent ने ठीक-ठीक क्या गलत लिखा और इंसान उसे कैसे बेहतर कर सकता था — इसके उदाहरण और सबूत।
    ऐसा material ज़रूर कहीं होगा, तो अगर किसी को अच्छे उदाहरण दिखाने वाला content पता हो तो बताना चाहिए।
    मुझे ज़रा भी शक नहीं कि top कुछ प्रतिशत coder, Claude या Codex से कहीं बेहतर लिख सकते हैं। लेकिन मैं यह जानना चाहता हूँ कि औसत साधारण developer की तुलना में यह कितना कमज़ोर है।
  • यह लेख काफ़ी विस्तार से उदाहरण देता है, जिनमें खराब architecture दिखाने वाले code snippet भी शामिल हैं: https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/

• मेरा अनुमान है कि मॉडल आगे भी बेहतर होते रहेंगे।
  1~2 साल पहले जब मैंने agent-style coding शुरू की थी, तब मुझे पूरा यक़ीन था कि यह सिर्फ autocomplete जितना ही उपयोगी है। इस साल की शुरुआत में कुछ हुआ, और मॉडल क्षमता के एक नए स्तर पर पहुँच गए।
  अब जिन लोगों को मैं जानता हूँ वे सब agent-style coding कर रहे हैं, और यह सचमुच चौंकाने वाला है। मुझे लगता है कि इसे जहाँ तक हो सके वहाँ तक धकेलकर देखना चाहिए। ऐसा लगता है जैसे मानवता की acceleration आँखों के सामने आ गई हो।

  • हम पहले से ही कुछ logistical limitations से टकरा रहे हैं। भले ही Transformer में कोई मूलभूत capability plateau न हो, फिर भी सुधार के लिए उपलब्ध GPU और बिजली सीमित हैं, और उस infrastructure को scale करना भी बहुत मुश्किल साबित हो रहा है।
    पिछले 2 साल में लगभग 6GW के नए data center घोषित किए गए, लेकिन वास्तव में चालू होकर service देने लगे हैं 1GW से भी कम। बाकी सबकी delivery timeline लगातार खिसक रही है।
    और data center ऐसे बात करते हैं मानो उनके अंदर के chip 6 साल तक चलेंगे, लेकिन वह भी अवास्तविक होता जा रहा है।
  • अगर हम तेज़ी से दीवार की तरफ़ बढ़ रहे हों तो?
  • “मानवता की acceleration” इस साल देखा गया सबसे बड़ा self-soothing वाक्य है।
  • हाँ, कुछ तो हुआ है। autocomplete बेहतर हो गया है। उसके अलावा क्या? base model बदले नहीं हैं।
    “मानवता की acceleration” जैसी बातें बंद होनी चाहिए। LLM से cancer, climate change, inequality, या दूसरी महत्वपूर्ण वास्तविक समस्याएँ कोई हल नहीं कर रहा।
    अगर यह tech आपकी productivity बढ़ाने लायक ठीक-ठाक है, तो उसकी वजह यह है कि आप कोई नया, cutting-edge, या सचमुच innovative काम नहीं कर रहे। LLM आपके काम को सिर्फ इसलिए कर पाता है क्योंकि वह code training data में पहले से इतना ज़्यादा मौजूद है कि वह लगभग शब्दशः लिखा जा चुका है।
    LLM से C++26, HDL, या किसी बहुत niche stack में लिखवाकर देखो, अच्छा reality check मिल जाएगा।

• ऐसा नहीं है कि AFL ने LLM से ज़्यादा vulnerabilities ढूँढीं। vulnerabilities AFL और अनुभवी practitioners ने मिलकर ढूँढीं।
  AFL faults trigger करता है, और उनमें से काफ़ी या ज़्यादातर exploitable नहीं होतीं। इंसानों को — और अब agents को — इन्हें छाँटना और evaluate करना पड़ता है।
  और यह काम AFL से पहले के memory-unsafe software corpus पर किया गया था। AFL का prime लगभग 10 साल पहले था, और अब हर target पहले से ज़्यादा कठिन हो चुका है।

• थोड़ा और context दें तो, इस लेख के लेखक George “geohot” Hotz हैं। उनके पास exploits का लंबा इतिहास है, और शायद वे सबसे ज़्यादा इस बात के लिए जाने जाते हैं कि असली AI vibe coding आने से बहुत पहले, कम बजट में उन्होंने self-driving car के लिए comma.ai को लगभग vibe coding की तरह बना लिया था।
  https://en.wikipedia.org/wiki/George_Hotz