LLM के पिछले 6 महीने 5 मिनट में
(simonwillison.net)- नवंबर 2025 हालिया LLM बदलावों का एक संदर्भ बिंदु बन गया, और coding agents का व्यावहारिक उपयोग तथा laptop पर चलने वाले models की तेज प्रगति इसके मुख्य बिंदु थे
- Claude Sonnet 4.5 के बाद GPT-5.1, Gemini 3, Claude Opus 4.5 ने तेज़ी से प्रतिस्पर्धा की, और Opus 4.5 कुछ महीनों तक आगे दिखा
- OpenAI और Anthropic की Reinforcement Learning from Verifiable Rewards ने Codex और Claude Code जैसे harnesses में code quality सुधार के रूप में असर दिखाया
- छुट्टियों के मौसम के प्रयोगों ने micro-javascript जैसे दिलचस्प नतीजे दिए, लेकिन bugs, speed, और safety की वजह से वास्तविक ज़रूरत सीमित रही
- Gemma 4, GLM-5.1, Qwen3.6-35B-A3B जैसे open weight models frontier models से कमजोर होने के बावजूद उम्मीदों से कहीं बेहतर प्रदर्शन करने लगे
6 महीनों को अलग करने वाली दो धाराएँ
- नवंबर 2025 का turning point हालिया 6 महीनों के LLM बदलावों को देखने के लिए एक अच्छा संदर्भ बिंदु है, और खासकर coding क्षेत्र में यह एक महत्वपूर्ण महीना था
- पिछले 6 महीनों के मुख्य बदलाव दो बिंदुओं in समेटे जा सकते हैं
- coding agents इतने बेहतर हो गए कि उन्हें रोज़मर्रा के वास्तविक काम में इस्तेमाल किया जा सके
- laptop पर चल सकने वाले models frontier models से कमजोर होते हुए भी उम्मीदों से कहीं आगे निकलने लगे
- models की तुलना के लिए बाइक चलाते pelican का SVG बनाना टेस्ट इस्तेमाल किया गया
- इस टेस्ट की पृष्ठभूमि यह है कि pelican बनाना मुश्किल है, bicycle बनाना भी मुश्किल है, pelican bicycle चला नहीं सकता, और किसी भी AI lab ने संभवतः ऐसे task के लिए models को train नहीं किया होगा
नवंबर में frontier models की प्रतिस्पर्धा
- नवंबर की शुरुआत में व्यापक रूप से “सर्वश्रेष्ठ” माना जाने वाला model 29 सितंबर को जारी Claude Sonnet 4.5 था
- इसके बाद “सर्वश्रेष्ठ” model की जगह तीन बड़े providers के बीच तेज़ी से बदलती रही
- Gemini 3 ने इस तुलना समूह में सबसे अच्छा pelican चित्र बनाया, लेकिन सिर्फ pelican test के आधार पर पूरे model का मूल्यांकन नहीं किया जा सकता
- Claude Opus 4.5 उसके बाद कई महीनों तक आगे रहने वाला model दिखा
coding agents ने quality barrier पार किया
- नवंबर का असली बदलाव coding agents की quality में सुधार था
- OpenAI और Anthropic ने 2025 का अधिकांश समय models द्वारा लिखे गए code की quality बढ़ाने के लिए Reinforcement Learning from Verifiable Rewards में लगाया
- यह सुधार खास तौर पर Codex और Claude Code जैसे agent harnesses के साथ जुड़ने पर और स्पष्ट दिखा
- नवंबर में coding agents “कभी-कभी काम करते हैं” के स्तर से “ज़्यादातर काम करते हैं” के स्तर पर पहुँचे
- वे रोज़मर्रा के tools के उस स्तर तक पहुँच गए जहाँ users को अपना अधिकांश समय बेवकूफ़ी भरी गलतियाँ ठीक करने में नहीं लगाना पड़ता और वे उन्हें वास्तविक काम सौंप सकते हैं
छुट्टियों के मौसम के प्रयोग और अतिउत्साह
- दिसंबर से जनवरी तक कई users ने छुट्टियों का समय यह प्रयोग करने में लगाया कि नए models और coding agents क्या-क्या कर सकते हैं
- models और agents ने बहुत कुछ किया, और कुछ users ने तेज़ी से महत्वाकांक्षी projects बनाना शुरू कर दिया
- micro-javascript MicroQuickJS का loosely Python में port किया गया JavaScript implementation था
- browser playground की संरचना ऐसी थी कि JavaScript code, micro-javascript library पर चलता था; वह Python code, Pyodide के भीतर, WebAssembly के भीतर, JavaScript के भीतर, browser के भीतर चलता था
- नतीजा दिलचस्प था, लेकिन buggy, slow, और unsafe आधा-अधूरा JavaScript का Python implementation वास्तव में किसी को चाहिए नहीं था, और उसी अवधि में बने दूसरे projects भी चुपचाप रिटायर हो गए
OpenClaw और personal AI assistants का उभार
- नवंबर के अंत में पहला commit आने के समय ज़्यादा चर्चित न रहने वाला repository “Warelay” बाद में तेज़ी से ध्यान खींचने लगा
- दिसंबर और जनवरी के बीच कई बार नाम बदलने के बाद, फरवरी में इसे अंतिम नाम OpenClaw के रूप में बड़ा ध्यान मिला
- OpenClaw एक “personal AI assistant” है, और NanoClaw व ZeroClaw जैसे projects को शामिल करने वाले सामान्य नाम के रूप में Claws शब्द उभरा
- Silicon Valley के आसपास लोग Claw चलाने के लिए Mac Mini खरीदने लगे, जिससे Mac Mini स्टॉक से बाहर होने लगे
- Drew Breunig ने Claw की तुलना एक नए digital pet से की और मज़ाक में कहा कि Mac Mini, Claw के लिए एकदम सही aquarium है
- Claws के रूपक के लिए 2004 की फिल्म Spider-Man 2 में Alfred Molina द्वारा निभाया गया Doc Ock उदाहरण के रूप में दिया गया
- उसके claws AI से संचालित थे और जब तक suppressor chip खराब नहीं हुई थी तब तक वे सुरक्षित थे, लेकिन chip खराब होने के बाद वे बुरे हो गए और उसी पर हावी हो गए
Gemini 3.1 Pro और pelican test का विस्तार
- फरवरी में Gemini 3.1 Pro जारी हुआ और उसने bicycle चलाते pelican को बहुत अच्छी तरह बनाया
- नतीजे में टोकरी में मछली भी शामिल थी
- Google के Jeff Dean ने bicycle चलाते animated pelican का video पोस्ट किया
- उसी video में penny-farthing चलाता मेंढक, छोटी कार चलाती giraffe, roller skates पहने ostrich, skateboard पर kickflip करता कछुआ, और stretch limousine चलाता dachshund भी शामिल थे
- इस नतीजे ने मज़ाक में यह कल्पना करना आसान बना दिया कि AI labs ने pelican test जैसे अजीब tasks पर भी ध्यान दिया होगा
अप्रैल के open weight models
- Google ने Gemma 4 model series जारी की
- Gemma 4 को अमेरिकी कंपनी से आए open weight models में सबसे सक्षम model माना गया
- चीन की AI lab GLM ने GLM-5.1 जारी किया
- GLM-5.1 1.5TB आकार का open weight model है
- यदि आप इसे चलाने लायक hardware संभाल सकते हैं, तो यह बहुत प्रभावी model है
- GLM-5.1 ने bicycle चलाते pelican को काफ़ी कुशलता से बनाया, लेकिन animation प्रयास में bicycle ऊपर की ओर उछलती और विकृत हो जाती है
- Bluesky पर Charles द्वारा सुझाए गए “electric scooter चलाता North Virginia Opossum” task में इसने ऐसा नतीजा दिया जिसके आसपास दूसरे models भी नहीं पहुँच सके
- नतीजे में “Cruising the commonwealth since dusk” वाक्य भी शामिल था
- यह परिणाम animation के रूप में भी उपलब्ध है
laptop पर चलने वाले models ने उम्मीदों को पार किया
- अप्रैल का एक और उल्लेखनीय चीनी open weight model Qwen से आया
- Qwen3.6-35B-A3B ने laptop पर Claude Opus 4.7 से बेहतर pelican बनाया
- यह model 20.9GB open weight model है और laptop पर चल सकता है
- इस नतीजे ने यह भी दिखाया कि “bicycle चलाता pelican” एक उपयोगी benchmark के रूप में अपनी सीमाओं से आगे निकल चुका है
- laptop पर चल सकने वाले models frontier models से काफ़ी कमजोर हैं, लेकिन पिछले 6 महीनों में उन्होंने उम्मीदों से बहुत बेहतर नतीजे देने शुरू कर दिए हैं
1 टिप्पणियां
Hacker News की प्रतिक्रियाएँ
लोग कहते हैं कि यह पेलिकन साइकिल टेस्ट एक बेतुका मेट्रिक है, लेकिन शायद उन्हें ठीक से याद नहीं कि इसे लगभग 3 साल पहले Microsoft की शुरुआती GPT रिपोर्ट "Sparks of Artificial General Intelligence: Early experiments with GPT-4" [1] में पेश किया गया था
इसके बाद प्रमोशनल अकाउंट्स के नेटवर्क ने इसे तुरंत फैलाया, और यह उन लोगों का पसंदीदा “टेस्ट” बन गया जो AI hype करते हैं जब भी वे किसी मॉडल को “टेस्ट” करते हैं
यह 100% मार्केटिंग, 0% साइंस है
[1] https://arxiv.org/pdf/2303.12712
मुझे पेपर में “साइकिल चलाते पेलिकन” प्रॉम्प्ट के विशेष रूप से टेस्ट किए जाने का उदाहरण[1] नहीं पता, लेकिन GPT पेपर में कई SVG और tikz टेस्ट थे और असल इमेज काफ़ी मनमानी थीं
किसी एक खास इमेज पर optimize करना अच्छा नहीं है, लेकिन अगर training कुछ हद तक सही हुई हो तो साइकिल चलाता पेलिकन इतना मुश्किल नहीं होना चाहिए, और [0] के कई पेज देखें तो काफ़ी अच्छे उदाहरण भी हैं
[0] https://simonwillison.net/tags/pelican-riding-a-bicycle/?pag...
[1] Simon की प्रसिद्धि को देखते हुए यह कहीं न कहीं ज़रूर होगा
अभी ChatGPT के बेस मॉडल (5.5) से चलाकर देखा, तो बूढ़ा आदमी एक पुरानी साइकिल चला रहा था, साइकिल एक ढीली रस्सी पर थी, वह रस्सी नदी के ऊपर जा रही थी, और पीछे मध्ययुगीन शहर था
असली बात यह है कि प्रॉम्प्ट में सूक्ष्म द्विअर्थीपन है। “बूढ़ा आदमी नदी कैसे पार कर रहा है?” इस हिस्से पर ज़्यादातर इंसान तुरंत एक सामान्य पुल की कल्पना करेंगे जिस पर सड़क नदी को पार करती हो, और ऐसा भी सोचेंगे कि नदी का इलाक़ा इतना विकसित है कि वहाँ ऐसा पुल हो
इसलिए मुझे लगता है कि ऐसे मॉडल शर्तों को मोटे तौर पर पूरा करने वाली चीज़ ढूँढने या बनाने में बेहतर हो रहे हैं, लेकिन वे अब भी उन commonsense assumptions को मिस करते हैं जो इंसान स्वाभाविक रूप से निकाल लेते हैं
मुझे उत्सुकता है कि “inflection point” सचमुच कोई वास्तविक घटना है या सिर्फ मार्केटिंग
मॉडल कुछ हद तक बेहतर हुए हैं, यह सही है, लेकिन अभी भी अगर आप लेटेस्ट मॉडल्स (Codex + gpt5.5, gpt5.3-codex कॉम्बो) से गेम vibe coding के ज़रिए बनवाने की कोशिश करें, तो वे काफ़ी जूझते हैं
वे एक शुरुआती ढाँचा ज़रूर बना देते हैं जो चल भी जाता है, लेकिन polished application से अभी भी दूर हैं
Enigma cipher machine कैसे काम करती है, यह सीखने के लिए मैंने ख़ुद कुछ लिखा था, लेकिन वह सीखने के उद्देश्य से था
काम के लिहाज़ से कहें तो नवंबर से मैंने coding बंद ही कर दी
जब किसी विशेष उपयोग के लिए “काफ़ी अच्छा” होने की threshold crossing हो जाती है, तब अचानक नई क्षमताएँ खुल जाती हैं
पुराने nail gun भारी होते थे, मोटी power cable चाहिए होती थी, और बहुत महंगे थे
फिर वे हल्के हुए, सस्ते हुए, battery pack इस्तेमाल करने लगे, और एक बिंदु पर जाकर वे roofers के workflow में स्वाभाविक रूप से फिट हो गए और काम की मात्रा नाटकीय रूप से बढ़ा दी
उसके बाद की incremental improvements शायद उसी स्तर का “unlock” न ला पाएँ, क्योंकि threshold पहले ही पार हो चुकी थी
कुंजी यह थी कि शुरुआत में कुल architecture document पर काफ़ी समय लगाया जाए, और उसे ठोस, सीमित चरणों में तोड़ा जाए
उस दस्तावेज़ को दोनों मॉडलों के बीच आगे-पीछे घुमाकर तब तक refine किया जब तक दोनों संतुष्ट न हो गए
हर चरण के लिए implementation plan बनाता था, और ख़त्म होने पर क्या deliver हुआ और क्या पाया गया, उसका summary document छोड़ता था। वही अगले चरण का input बनता था
डॉक्यूमेंट और असली काम, दोनों को verify करता था, tests भी देखता था, और कुछ हिस्सों को ज़्यादा ध्यान से भी देखता था। code structure पसंद आ रहा है या नहीं, यह भी आंशिक रूप से जाँचता था
ज़्यादातर coding के लिए Claude, और design व चरण-दर-चरण code review के लिए Codex इस्तेमाल किया, और हर चरण के अंत में दोनों से test coverage जँचवाई
इस तरीके से मैंने बिना एक भी लाइन ख़ुद लिखे tools और libraries implement कर लीं, और यह वास्तव में काफ़ी उपयोगी रहा
यह asynchronous तरीके से चलता है, इसलिए जब मॉडल धीरे-धीरे प्रोसेस कर रहे होते हैं तब मैं दूसरे काम कर सकता हूँ
फिर भी मुझे नहीं लगता कि यह हर जगह लागू होता है। जिन कामों में test करना आसान हो, लक्ष्य स्पष्ट हो लेकिन उसे पाने का सटीक तरीका पहले से तय न हो—वहाँ यह प्रभावशाली था
मैं websites और social से text/image मिले-जुले unstructured event data को scrape करने के लिए LLMs का इस्तेमाल कर रहा हूँ, और वाजिब लागत पर 100% consistent परिणाम पाने के लिए मुझे काम को बहुत छोटे टुकड़ों में बाँटना पड़ा ताकि error surface काफ़ी घटे
अभी moderately complex कामों में Codex/Claude आसानी से यूज़र को महँगे dead end में कोड करवा सकते हैं
GPT 5.5, GPT 5.4 से काफ़ी बेहतर है, लेकिन मैं उसे inflection point नहीं कहूँगा
जब लोग कहते हैं “coding agents सचमुच बहुत अच्छे हो गए हैं”, तो मुझे यह जानने की जिज्ञासा है कि 2025 नवंबर के तथाकथित “inflection point” के बाद भी वे वास्तव में किसके लिए बहुत अच्छे हुए हैं
मेरी देखी बातों में tool calling और बड़े codebase पर सवाल-जवाब, ख़ासकर ऐसे सवाल जिनमें ढूँढे जाने वाले patterns अस्पष्ट हों, उनमें वे बेहतर हुए हैं, और उस उपयोग में बहुत काम के हैं
लेकिन ढेर सारे निर्देश और देखभाल के बाद भी production code generation के स्तर पर वे बिल्कुल नहीं पहुँचे हैं; मेरे निजी अनुभव में तो उसके आसपास भी नहीं
मार्केटिंग के उन्माद में चीज़ों को 1 और 0 की तरह पेश करना बंद होना चाहिए। agents की क्षमता एक continuous spectrum है, और यह काफी हद तक इस बात पर निर्भर करती है कि आप जिस codebase पर काम कर रहे हैं, उसकी complexity कैसी है
मुझे लगता है कि हम सभी अभी भी यह सीख रहे हैं कि अपने रोज़मर्रा के काम में इन tools को बेहतर तरह से कैसे लागू करें
लेकिन यह मौजूदा narrative से टकराता है। वह narrative हमारे काम को हमेशा एक जैसा और आसानी से automate होने वाला बताकर समतल कर देता है, जबकि असलियत में ऐसा नहीं है
इसलिए मुझे लगता है कि बहस इतनी polarized हो जाती है। कोई shared experience ही नहीं है
उदाहरण के लिए मेरा अनुभव बिलकुल उल्टा रहा है, और मैंने Claude के साथ बहुत high-quality काम बनाया है(https://github.com/kstenerud/yoloai)
जिन technologies का मैं इस्तेमाल कर रहा था, उनके bugs और quirks को संभालने की प्रक्रिया में agent बहुत मददगार रहे—उन्होंने implementation चरण में बार-बार ठोकर खाने से बचने के लिए इन्हें ढूँढा और सूचीबद्ध किया: https://github.com/kstenerud/yoloai/blob/main/docs/dev/backe...
agents लगातार बेहतर हो रहे हैं। सिर्फ पिछले महीने में भी research, design, architecture, planning documents बनाते समय समस्याओं का अनुमान लगाने और उनके implications ठीक से infer करने की उनकी क्षमता काफ़ी प्रभावशाली रही
coding चरण पर पहुँचने के बाद ज़्यादातर काम mechanical रह जाता है, और Sonnet को दे दें तब भी defect rate बहुत कम रहता है
मेरे अनुभव में Claude Code, ख़ासकर Opus 4.6, इस काम में शानदार है। कम-से-कम JS, TS, Elixir और Ruby में तो ज़रूर
देखभाल तो निश्चित रूप से चाहिए, और मेरे दिमाग़ में इसका मॉडल “junior developer” नहीं बल्कि exoskeleton के ज़्यादा करीब है। लेकिन अनुभव के स्तर पर यह बेहद ताकतवर exoskeleton है, जो ज़्यादातर कामों में मेरी रफ़्तार आसानी से 10x कर देता है
ख़ास बात यह है कि मैं
--dangerously-skip-permissionsभी नहीं इस्तेमाल करता, और Claude Code का auto mode भी नहीं। मैं लिखी जा रही लगभग हर लाइन को हल्के से review करता हूँ और बारीक नियंत्रण रखता हूँ, इसलिए एक साथ generate होने वाले sessions आमतौर पर 2 से ज़्यादा नहीं होतेमुझे शक है कि निराशा तब ज़्यादा पैदा होती है जब लोग इसे delegate करना चाहते हैं और मान लेते हैं कि यह पटरी से नहीं उतरेगा। उसने अभी तक मेरे लिए उस तरह का भरोसा नहीं कमाया है, और सच कहूँ तो अभी इसकी ज़रूरत भी नहीं पड़ी
हालाँकि मैं ज़्यादातर 20k–30k लाइन वाले छोटे-मध्यम codebases पर काम करता हूँ, tests सहित। शायद सकारात्मक अनुभव का एक कारण यह भी हो सकता है
असल में (a) लोग AI के साथ काम करने के तरीके में असंख्य छोटे द्वीपों की तरह अलग-अलग हैं, और (b) bottleneck developer और codebase/काम के हिसाब से बहुत अलग होते हैं
साथ ही मुझे लगता है कि हमारे दौर में एक अंतर्निहित पूर्वाग्रह है: बदलाव = प्रगति, productivity
1990–2000 की “network computing revolution” देखें तो कंप्यूटर हर डेस्क और जेब तक पहुँच गए और administrative कामों के लिए बेहद ताकतवर साबित हुए
लेकिन अंतिम नतीजा “बदलाव” था। हम चिट्ठियों की तुलना में बहुत ज़्यादा emails भेजने लगे, बहुत ज़्यादा communicate करने लगे, secretaries ग़ायब हो गए, लेकिन “administration” ख़ुद बढ़ गया
विश्वविद्यालयों में faculty के साथ आमतौर पर और ज़्यादा admin staff है, और कंपनियाँ accounting, HR, project managers ज़्यादा रखती हैं
शायद administration शुरू से ही असली bottleneck नहीं था
code में भी ऐसा बहुत है। हर किसी के पास roadmap और wishlist है, और “code बनाने की क्षमता” bottleneck जैसी लगती है
लेकिन ज़्यादातर कंपनियाँ शायद सिर्फ और software बना लेने से ज़्यादा value पैदा नहीं कर सकतीं
अनुभवजन्य रूप से लगता है कि कई mid-tier कंपनियाँ stack migration या modernization जैसे काम कर रही हैं। features की बौछार कर revenue या prices बढ़ाने की बातें कम सुनाई देती हैं
ज़्यादातर bottlenecks बस किसी और bottleneck के upstream होते हैं; असली “dam” बहुत कम मिलते हैं
मेरा हाल का personal project Wasm से Go में कन्वर्ट करने वाला transpiler है, और यह बहुत प्रभावशाली है कि latest models (मैंने Sonnet, Opus, Gemini इस्तेमाल किए, और वे GPT से कहीं ज़्यादा सफल रहे) पूरे प्रोजेक्ट को पकड़कर कई layers पर काम कर सकते हैं
वे transpiler को implement करने वाला Go code (Wasm parsing, AST construction), AST को
.gofiles के रूप में serialize कर बना हुआ Go code, AST को manipulate कर optimization करने वाला Go code और उसका generated code पर असर, generated code में graft किए जाने वाले Go code और AST के साथ उसका interaction ताकि advanced instructions लागू हों, C code का Wasm में compile होना, फिर Go में translate होना और Go से call होना, C standard library को implement करने के लिए उस C code द्वारा call किया जाने वाला Go code, यहाँ तक कि Wasm spec tests के लिए WAT/WAST files तक—सब सँभाल लेते हैंइन सारी layers के बारे में एक साथ सोचना मेरे लिए भी मेहनत माँगता है, और मुझे लगता है बहुत से programmers को भी कठिन लगेगा, इसलिए यह प्रभावशाली है
और कई बार “मैं ऐसा code generate करना चाहता हूँ, इसलिए वह AST बना दो जो यह करे” लिखना Go code में parentheses गिनने से कहीं आसान होता है। थोड़ी LISP background होने पर भी यह आसान लगता है
code review या आलोचना स्वागतयोग्य है। यह vibe coding नहीं है, लेकिन generative AI की मदद खूब ली गई है
https://github.com/ncruces/wasm2go
यह एक छोटा browser game है, इसलिए security और perfection की माँग बहुत कम है, लेकिन “वास्तव में इसे बना कर देखना” और “मज़ेदार होना” की माँग ऊँची है, इसलिए एक अर्थ में इसे production code कहा जा सकता है
generated code में compile errors शून्य थे, और अगर मैं किसी task में 10 काम गिना दूँ, तो वह सब पर काम करता चला गया
उपयोगी होने के लिए इसे बहुत ज़्यादा बेहतर होने की ज़रूरत नहीं है। जो लोग research-style गणित में हों जहाँ वैसे भी verify करना पड़ता है, या जो test data filtering, transformation, execution code लिखने में बहुत अच्छे नहीं हैं, उनके लिए यह पहले से बहुत उपयोगी है
छोटे websites, मज़ेदार projects, helper tools जैसी चीज़ों के लिए भी यह अभी से अच्छा है
साथ ही background में ज़्यादा compute, बेहतर algorithms, और ज़्यादा reinforcement learning जैसे काम चलते रहेंगे
हो सकता है कि हम जाने बिना ही “AI coding jobs ले लेगा” वाले बिंदु के 95% तक पहले ही पहुँच चुके हों। क्योंकि बचे हुए 5% की अहमियत बहुत ज़्यादा है
कहीं न कहीं अभी कोई मानव कलाकार ऐसी साइकिल चलाते पेलिकन की तस्वीर बना रहा होगा जो किसी बड़े AI lab के training data में चली जाएगी
इस टेस्ट का असली बिंदु है image को दर्शाने वाला SVG text generate करना, और वह ज़्यादा जटिल है
raster images को SVG में बदलकर training data में इस्तेमाल करने के तरीके मौजूद हैं, लेकिन यह किसी के समय का अच्छा उपयोग नहीं है
बस यह नहीं पता कि उन्होंने खास तौर पर पेलिकन को target किया था या केवल SVG को
पिछले 6 महीने ऐसे लगते हैं जैसे मानवता ने LLMs पर नियंत्रण खो दिया हो
स्थानीय AI adoption को संतुलित कर सकने वाले बेहतरीन open models आने के बावजूद memory market capture हुआ, और दुनिया भर की कंपनियों में intellectual property leakage tools तेज़ी से घुस गए
developers उतना code बना रहे हैं जितना वे पढ़ भी नहीं सकते
autonomous agents attention economy को सोखकर open source को मार रहे हैं, online communities (HN सहित) को बिगाड़ रहे हैं, और युद्ध में भी इस्तेमाल हो रहे हैं (targeting, propaganda आदि)
व्यापक vulnerabilities मिल रही हैं, और बड़े supply-chain attacks लगातार हो रहे हैं
बढ़ती असमानता, perception का विभाजन, और हरे metrics के साथ काली हक़ीक़त—सब साथ दिख रहे हैं
लेकिन निजी तौर पर मैंने biotech में अविश्वसनीय चीज़ें होती देखी हैं। यह विश्वास करना कठिन है कि हम ऐसे भविष्य में जी सकते हैं
AlphaFold की मदद से विकसित असली treatments पहले से वास्तविक clinical trials में टेस्ट हो रही हैं, और अगले 3–5 साल में trials में जाने वाली अगली पीढ़ी की चीज़ें जबरदस्त होंगी
शायद बाद में हम आज की medicine को वैसे देखें जैसे आज हम मध्ययुग को देखते हैं
आदर्श रूप से उम्मीद है कि हम इस hype cycle से गुज़रकर बेहतर practices सीखकर निकलेंगे
“दुनिया भर की कंपनियों में intellectual property leakage tools तेज़ी से घुस गए” मुझे तो फ़ायदे वाली श्रेणी में लगता है
attention economy से जुड़ी चीज़ों का गायब होना मेरे लिए तो क़रीब-क़रीब पूरा का पूरा “अच्छा छुटकारा” है
गैर-प्रोग्रामर के नज़रिए से पिछले 6 महीने कैसे रहे, यह जानने की जिज्ञासा है
दूसरे क्षेत्रों के लोगों ने किस तरह के collaboration tools या मिलते-जुलते optimizations देखे होंगे?
वे हाल में हमारी टीम में पढ़ाने आए हैं और 2-हफ़्ते के कोर्स में शामिल हैं, और पहले ही दिन उन्हें कहा गया कि AI से सारे lesson plans लिखवाओ, फिर उन्हीं plans को वापस AI में डालकर slides बनवाओ
मैं चाहता हूँ कि वे इस बात को सख़्ती से ठुकराएँ, क्योंकि अगर नहीं, तो trainees को उस व्यक्ति का अनुभव, उसकी मानवीयता, और वह सब कुछ नहीं मिलेगा जो वह दे सकता है
एक प्रशिक्षक के रूप में मेरा हर 6 महीने review होता है, और हर बार वही बात सुनने को मिलती है: “हम class में AI का इस्तेमाल कैसे कर सकते हैं?”
यह भी समझाने की ज़रूरत वे महसूस नहीं करते कि यह क्यों वांछनीय है या क्यों ज़रूरी है। यह शुद्ध trend chasing है
विश्वास करना मुश्किल है, लेकिन मेरे ज़्यादातर सहकर्मी AI को लेकर बहुत सकारात्मक हैं, फिर भी class preparation के अलावा वे इसका उपयोग कहाँ करते हैं, यह किसी ने नहीं बताया
वे बस इसलिए इस्तेमाल करते हैं कि सोचने या तैयारी करने में समय न लगे—जबकि वही तो नौकरी का सबसे महत्वपूर्ण हिस्सा है
मुझे यह बिल्कुल भी समझ नहीं आता
बहुत होशियार लोग मॉडलों से कुछ नतीजे निकाल लेते थे, लेकिन हमेशा इसके लिए गंभीर काम और बहुत उपयुक्त समस्याएँ चाहिए होती थीं
बेशक यह homework problems हल कर सकता था, लेकिन पढ़ाने वाले की नज़र से वह मुझे उलटे नुकसान जैसा लगता था
GPT-5.4 (मार्च 2026) के बाद चीज़ें “वाह” जैसी लगीं। यह अचानक MathOverflow-स्तर की समस्याओं का जवाब देने लगा, जिन पर पहले experts अटक जाते थे
hallucinations अब भी थीं, लेकिन जब संभव होता तो छोटे examples से दावों को verify करने के लिए इसकी built-in Python capability का इस्तेमाल करने लायक यह काफ़ी समझदार था
यह अमूर्त और “philosophical” गणित की तुलना में formula-heavy गणित में कहीं ज़्यादा मजबूत लगता है
GPT-5.5 ने MO-स्तर की कठिन समस्याओं पर बेहद रोचक, काफ़ी non-trivial, और बहुत शिक्षाप्रद book-style proof दिए, और मैं अभी उन्हें लिखित रूप दे रहा हूँ
यह किस्मत और अच्छे prompting की वजह भी हो सकती है। यह 5.4 से कोई qualitative leap नहीं लगा, लेकिन quantitative improvement भी हमेशा स्वागतयोग्य है
अब भी उपयुक्त समस्या चाहिए, लेकिन शुरुआत से ही किसी समस्या को अनुपयुक्त मानकर अलग कर देना अब काफ़ी कठिन हो गया है
Claude और Gemini पहले भी second-tier थे और अब भी हैं। Claude को मैं secretary जैसे कामों के लिए इस्तेमाल करता हूँ, और कभी-कभी आसान proofs खोजने के लिए, लेकिन अक्सर वह इसलिए क्योंकि मुझसे कोई स्पष्ट बात छूट गई होती है
और GPT, तथा कुछ कम हद तक Claude भी, गणितीय गलतियाँ ढूँढने में बेहतरीन हैं। अब तक मेरे लगभग 90% prompts शायद मेरी अपनी writing को proofread कराने में गए हैं
औसत office worker Copilot से प्रभावित है। IDE वाले Copilot से नहीं, बल्कि Windows में bundled app से
वे मुख्यतः materials को कंपनी द्वारा उपलब्ध ChatGPT/Gemini में copy-paste करते हैं, और Facebook/Instagram से “काम की productivity बढ़ाने वाले 5 सबसे अच्छे prompts” जैसी tips लेते हैं
जब आप उन्हें बड़े पैमाने पर काम automate करने वाले agents दिखाते हैं, तो वे उसे लगभग जादू की तरह लेते हैं
अब सबके slide decks साफ़-सुथरे दिखते हैं, और finance टीम को BI से मदद बहुत कम चाहिए होती है। काफ़ी प्रभावशाली है
निजी तौर पर, मेरी पत्नी अपनी मातृभाषा उन K-12 छात्रों को पढ़ाती हैं जिनकी वह मातृभाषा नहीं है, और अब बच्चे ऐसे tools से स्कूल के lesson plan के अनुरूप नया अभ्यास-सामग्री generate करते हैं
कुछ महीने पहले की तुलना में बच्चों की प्रगति अब कहीं तेज़ है
Simon का ब्लॉग इतना प्रसिद्ध है कि अब यह पूरे भरोसे से कहना कठिन है कि कोई AI lab ऐसे बेतुके task के लिए मॉडल को train नहीं करेगी
अब बारी है electric scooter चलाते opossum की
इस thread को पढ़कर लगता है कि inflection point पर काफी बहस इसलिए है क्योंकि लोग एक-दूसरे से अलग चीज़ों के बेहतर होने की बात कर रहे हैं
मेरी व्याख्या में नवंबर के आसपास models की core capability में बहुत बड़ी छलाँग नहीं आई, बल्कि उनके आसपास का harness कहीं ज़्यादा stable हो गया, और 2025 की शुरुआत के RLVR काम ने models को उसी harness के भीतर अच्छी तरह व्यवहार करना सिखाया
इसलिए जब दोनों मिले, तो अलग-अलग देखने पर कुछ बहुत नाटकीय नहीं था, लेकिन संयुक्त प्रभाव से वह step-change जैसा लगा हो सकता है
यही वजह लगती है कि इस thread में अनुभव इतने अलग हैं। जो लोग model से code पूछकर copy-paste करने वाले flow का इस्तेमाल करते थे, उन्हें improvement gradual लगी होगी, और वे वाजिब रूप से सोच सकते हैं कि इतना हंगामा क्यों है
इसके उलट जो लोग पहले से agents को 20-step loop में चला रहे थे, उन्हें कहीं बड़ा बदलाव महसूस हुआ होगा। पहले समस्या यह थी कि step 12 की विफलता step 20 तक पहुँचते-पहुँचते कूड़े में बदल जाती थी, और वही हिस्सा बहुत सुधरा है
Simon द्वारा हल्के से छुआ गया local models वाला बिंदु भी इसी वजह से रोचक है। laptop पर चलने वाला 20GB model अगर एक decent पेलिकन बना दे, तो अपने-आप में वह बस एक प्यारा data point है
असल में ध्यान देने वाली बात यह है कि एक अच्छे harness में रखा सक्षम local model अब harness के बिना frontier model चलाने की तुलना में frontier performance के कहीं ज़्यादा करीब आ गया है
मैंने Gemini से “Hyde Park में unicycle चलाते पेलिकन” का वीडियो माँगा, और नतीजा देखकर काफ़ी हैरान हुआ
https://gemini.google.com/share/55e250c99693
इस बिंदु पर मुझे लगता है कि प्रतिद्वंद्वी AI labs अब इतने प्रसिद्ध हो चुके इस “टेस्ट” पर training क्यों नहीं करेंगी?
पेलिकन का center of mass साफ़ तौर पर पहिए के पीछे है। उसे पहिए के ऊपर या बस थोड़ा आगे होना चाहिए
https://grok.com/imagine/post/8d1eab88-737f-4d46-ba92-9b6502...
दिलचस्प बात यह है कि image generation की तुलना में video generation में पेलिकन को pedals चलाते हुए बेहतर बनाया गया है
मैंने Claude से landscaping photo में mulch जोड़ने को कहा, तो वह MS Paint के नारंगी spray tool से रंगे हुए जैसा लग रहा था
Nano Banana ने काफ़ी वास्तविक नतीजा दिया
इसमें लिखा है, “मैंने PyCon US 2026 में एक 5-minute lightning talk के लिए annotated slides बनाए,” तो जिज्ञासा है कि क्या इस presentation का कोई video या audio उपलब्ध है?