मैं जिस क्षेत्र में काम करता हूँ वह इतना चरम स्तर का तो नहीं है, लेकिन मैं AI क्षेत्र में research और development कर रहा हूँ.
आम तौर पर बहुत इस्तेमाल होने वाले framework के अलावा, कई बार जिस target environment में मॉडल को वास्तव में deploy किया जाता है, वह training वाले environment से अलग होता है.
कभी-कभी कुछ specific operation support नहीं करते, इसलिए platform के हिसाब से custom operation बनाना पड़ता है. ऐसे मामलों में कई बार development environment में ही तुरंत test करना संभव नहीं होता.
कई बार हम सीधे मॉडलिंग भी करते हैं. किसी खास data के साथ test code लिखा जा सकता है, लेकिन dataset के अनुसार values probabilistically बदलती रहती हैं, और किसी खास समय पर values का explode हो जाना जैसी घटनाओं को test code से cover करना मुश्किल होता है.
शायद मुझसे भी ज़्यादा testing कठिन होने वाले environment काफी होंगे.
SQLite का अप्रोच वाकई बहुत प्रभावशाली है। कोड के मुकाबले 590 गुना बड़े test suite को private रखना, आखिरकार यही बताता है कि "software की असली value उसके behavior specification में होती है।"
वास्तव में आजकल AI coding tools से project बनाकर देखें, तो अगर किसी मौजूदा project का README + API docs + test code ही मौजूद हो, तो उसकी core functionality को हैरान कर देने वाली तेजी से replicate किया जा सकता है। मैं खुद 7 projects चलाते हुए यह महसूस कर चुका हूँ कि जिन projects में tests अच्छे होते हैं, उन्हें विडंबना यह है कि replicate करना भी उतना ही आसान होता है।
लेकिन Cloudflare vs Vercel उदाहरण में एक बात नजरअंदाज हुई है: "replication" और "operations" पूरी तरह अलग समस्याएँ हैं। Next.js के edge cases, plugin ecosystem, और community dependency तक दोबारा तैयार करनी हो, तो सिर्फ test code काफी नहीं है। आखिर में moat शायद test code + community + operational know-how का संयोजन ही होता है।
मुझे नहीं लगता कि इस प्रोजेक्ट में GC इतनी बड़ी समस्या बनेगी। "हाल के ज़्यादातर प्रोजेक्ट्स" में वास्तव में programming language अपनाना किसी खास language की खूबियों या सीमाओं से ज़्यादा अक्सर पसंद का मामला होता है, लेकिन फिर भी अगर मुझसे पूछा जाए कि एक general-purpose programming language के रूप में Rust को Go पर क्या comparative advantage मिलता है, तो मैं कहूँगा कि Rust का abstraction level और compile time पर कई तरह की errors पकड़ लेने की क्षमता उसकी बड़ी ताकत है। बेशक, Go के भी Rust की तुलना में आसान asynchronous programming, तेज compile time, और संक्षिप्त syntax जैसी खूबियाँ हैं।
Rust में compile के समय errors पकड़े जाने की हिस्सेदारी काफ़ी ज़्यादा होती है, इसलिए compile fail होना भी उल्टा ऐसा महसूस होता है कि AI को सही दिशा में जाने में मदद मिल रही है।
खैर, यह सिर्फ़ एक अनुमान है, लेकिन शायद इसलिए कि Rust में एंट्री बैरियर कम हो गया है।
सबसे बड़ी मुश्किल यह होती है कि कोड लिखने के बाद भी compile बार-बार fail होता रहता है, लेकिन अब AI उसे संभाल लेता है।
DIY, मेकर आंदोलन, indie, punk, open source—ये सब industrialization, capitalism और consumerism के खिलाफ़ एक तरह की प्रतिक्रिया हैं, लेकिन इनकी सीमाओं से पार पाने का तरीका अगर consumerism को स्वीकार करना ही है, तो यह विडंबनापूर्ण है।
मैं इस बात से सहमत हूँ कि vibe coding उपभोग के फ्रेम में फिट बैठती है। मुझे लगता है कि यह हाल में चलन में रहे Temu-kkang, Ali-kkang (https://www.asiae.co.kr/article/2024053117460950053) का coding वर्ज़न है.
लेकिन अगर यह कहा जाए कि उपभोग का फ्रेम maker movement की विफलता को दोहराने से बचने का तरीका है, तो HN की टिप्पणी की तरह मैं कई मायनों में इससे सहमत नहीं हो सकता।
Vibe coding नागरिक डेवलपर्स के ऐतिहासिक सिलसिले को आगे बढ़ा रही है.
अब मुझे लगता है कि vibe coding coding को बिजली की तरह आसान, तेज़ और अपरिहार्य बना रही है.
पहले से ही कई कंपनियों के प्रतिभाशाली प्रोग्रामर बिना एक भी लाइन code लिखे, prompts और agents के ज़रिये coding जारी रख रहे हैं.
इसे कमतर दिखाने की कोशिश करने वाले लोग भी हैं, लेकिन मेरा मानना है कि Andrej Karpathy की vibe coding कंप्यूटर इतिहास में एक मील का पत्थर है, इस पर आपत्ति करना मुश्किल है.
अच्छा सवाल है। दरअसल, हमारे प्रयोग में "हाइब्रिड" शर्त ठीक इसी दिशा में थी — यानी व्यवस्थित summary के साथ raw अनुभव logs भी दिए गए थे।
नतीजे में हाइब्रिड 4.95/5.0 के साथ सबसे ऊपर था। सिर्फ summary देने पर यह 2.65 था, लेकिन उसमें "असफल हुआ", "कारण अज्ञात" जैसे process records जोड़ने पर summary की कमज़ोरियाँ उलटे काफी हद तक पूरी हो गईं।
इसलिए निष्कर्ष यह है कि "summary अपने-आप में खराब नहीं है, लेकिन उसमें process और uncertainty को साथ में शामिल करना चाहिए।"
हालाँकि N=1 होने की वजह से यह अलग-अलग user groups पर सामान्य रूप से लागू होगा या नहीं, इसके लिए आगे और research की ज़रूरत है.
सही बात है। मैंने भी शुरुआत में सोचा था कि synthetic memory कम से कम baseline से तो बेहतर होगी, लेकिन नतीजे देखकर मैं भी हैरान रह गया।
विश्लेषण करने पर लगा कि असली मुद्दा "अनिश्चितता को सुरक्षित रखना" था। raw logs में "यह करके देखा, लेकिन काम नहीं किया", "कारण पता नहीं" जैसी निशानियां बची रहती हैं, इसलिए agent जिसे नहीं जानता, उसके बारे में नहीं जानता कहकर जवाब देता है। लेकिन summary में वह सारा संदर्भ मिट जाता है, और उल्टा वह गलत जवाब भी पूरे भरोसे के साथ देने लगता है।
मैं हमेशा आपकी सामग्री ध्यान से पढ़ता/पढ़ती हूँ, धन्यवाद।
लगता है कि ऐसे मामले इसलिए हो रहे हैं क्योंकि x के लिए crawl करना थोड़ा मुश्किल हो गया है। हम इसे बेहतर बनाने की कोशिश करेंगे।
यह पहली बार है कि मैंने "कोई सामग्री नहीं" वाला सारांश त्रुटि देखी है..
मैं जिस क्षेत्र में काम करता हूँ वह इतना चरम स्तर का तो नहीं है, लेकिन मैं AI क्षेत्र में research और development कर रहा हूँ.
आम तौर पर बहुत इस्तेमाल होने वाले framework के अलावा, कई बार जिस target environment में मॉडल को वास्तव में deploy किया जाता है, वह training वाले environment से अलग होता है.
कभी-कभी कुछ specific operation support नहीं करते, इसलिए platform के हिसाब से custom operation बनाना पड़ता है. ऐसे मामलों में कई बार development environment में ही तुरंत test करना संभव नहीं होता.
कई बार हम सीधे मॉडलिंग भी करते हैं. किसी खास data के साथ test code लिखा जा सकता है, लेकिन dataset के अनुसार values probabilistically बदलती रहती हैं, और किसी खास समय पर values का explode हो जाना जैसी घटनाओं को test code से cover करना मुश्किल होता है.
शायद मुझसे भी ज़्यादा testing कठिन होने वाले environment काफी होंगे.
SQLite का अप्रोच वाकई बहुत प्रभावशाली है। कोड के मुकाबले 590 गुना बड़े test suite को private रखना, आखिरकार यही बताता है कि "software की असली value उसके behavior specification में होती है।"
वास्तव में आजकल AI coding tools से project बनाकर देखें, तो अगर किसी मौजूदा project का README + API docs + test code ही मौजूद हो, तो उसकी core functionality को हैरान कर देने वाली तेजी से replicate किया जा सकता है। मैं खुद 7 projects चलाते हुए यह महसूस कर चुका हूँ कि जिन projects में tests अच्छे होते हैं, उन्हें विडंबना यह है कि replicate करना भी उतना ही आसान होता है।
लेकिन Cloudflare vs Vercel उदाहरण में एक बात नजरअंदाज हुई है: "replication" और "operations" पूरी तरह अलग समस्याएँ हैं। Next.js के edge cases, plugin ecosystem, और community dependency तक दोबारा तैयार करनी हो, तो सिर्फ test code काफी नहीं है। आखिर में moat शायद test code + community + operational know-how का संयोजन ही होता है।
वाह
मुझे नहीं लगता कि इस प्रोजेक्ट में GC इतनी बड़ी समस्या बनेगी। "हाल के ज़्यादातर प्रोजेक्ट्स" में वास्तव में programming language अपनाना किसी खास language की खूबियों या सीमाओं से ज़्यादा अक्सर पसंद का मामला होता है, लेकिन फिर भी अगर मुझसे पूछा जाए कि एक general-purpose programming language के रूप में Rust को Go पर क्या comparative advantage मिलता है, तो मैं कहूँगा कि Rust का abstraction level और compile time पर कई तरह की errors पकड़ लेने की क्षमता उसकी बड़ी ताकत है। बेशक, Go के भी Rust की तुलना में आसान asynchronous programming, तेज compile time, और संक्षिप्त syntax जैसी खूबियाँ हैं।
एक ही स्तर का कॉन्ट्रैक्ट हो, फिर भी भरोसे या इमेज का एहसास सच में बहुत अलग लगता है.
लगता है अब मुझे gpt subscription cancel कर देनी चाहिए.
मूड खराब कर दिया, माफ़ करना
वाह, कमाल है। लगता है यह RustPython की वजह से संभव हुआ है। आशा है कि आपको अच्छे नतीजे मिलें!
Rust में compile के समय errors पकड़े जाने की हिस्सेदारी काफ़ी ज़्यादा होती है, इसलिए compile fail होना भी उल्टा ऐसा महसूस होता है कि AI को सही दिशा में जाने में मदद मिल रही है।
मैंने आवेदन करके देखा है
खैर, यह सिर्फ़ एक अनुमान है, लेकिन शायद इसलिए कि Rust में एंट्री बैरियर कम हो गया है।
सबसे बड़ी मुश्किल यह होती है कि कोड लिखने के बाद भी compile बार-बार fail होता रहता है, लेकिन अब AI उसे संभाल लेता है।
लगता है वह Joke टेस्ट था।
DIY, मेकर आंदोलन, indie, punk, open source—ये सब industrialization, capitalism और consumerism के खिलाफ़ एक तरह की प्रतिक्रिया हैं, लेकिन इनकी सीमाओं से पार पाने का तरीका अगर consumerism को स्वीकार करना ही है, तो यह विडंबनापूर्ण है।
मैं इस बात से सहमत हूँ कि vibe coding उपभोग के फ्रेम में फिट बैठती है। मुझे लगता है कि यह हाल में चलन में रहे Temu-kkang, Ali-kkang (https://www.asiae.co.kr/article/2024053117460950053) का coding वर्ज़न है.
लेकिन अगर यह कहा जाए कि उपभोग का फ्रेम maker movement की विफलता को दोहराने से बचने का तरीका है, तो HN की टिप्पणी की तरह मैं कई मायनों में इससे सहमत नहीं हो सकता।
Vibe coding नागरिक डेवलपर्स के ऐतिहासिक सिलसिले को आगे बढ़ा रही है.
अब मुझे लगता है कि vibe coding coding को बिजली की तरह आसान, तेज़ और अपरिहार्य बना रही है.
पहले से ही कई कंपनियों के प्रतिभाशाली प्रोग्रामर बिना एक भी लाइन code लिखे, prompts और agents के ज़रिये coding जारी रख रहे हैं.
इसे कमतर दिखाने की कोशिश करने वाले लोग भी हैं, लेकिन मेरा मानना है कि Andrej Karpathy की vibe coding कंप्यूटर इतिहास में एक मील का पत्थर है, इस पर आपत्ति करना मुश्किल है.
अच्छा सवाल है। दरअसल, हमारे प्रयोग में "हाइब्रिड" शर्त ठीक इसी दिशा में थी — यानी व्यवस्थित summary के साथ raw अनुभव logs भी दिए गए थे।
नतीजे में हाइब्रिड 4.95/5.0 के साथ सबसे ऊपर था। सिर्फ summary देने पर यह 2.65 था, लेकिन उसमें "असफल हुआ", "कारण अज्ञात" जैसे process records जोड़ने पर summary की कमज़ोरियाँ उलटे काफी हद तक पूरी हो गईं।
इसलिए निष्कर्ष यह है कि "summary अपने-आप में खराब नहीं है, लेकिन उसमें process और uncertainty को साथ में शामिल करना चाहिए।"
हालाँकि N=1 होने की वजह से यह अलग-अलग user groups पर सामान्य रूप से लागू होगा या नहीं, इसके लिए आगे और research की ज़रूरत है.
तो क्या अगर हम synthetic memory को इस तरह संरचित करें कि उसमें उन कार्यों की प्रक्रिया, विफलताएं और सफलताएं शामिल हों, तो कुछ फर्क पड़ेगा?
सही बात है। मैंने भी शुरुआत में सोचा था कि synthetic memory कम से कम baseline से तो बेहतर होगी, लेकिन नतीजे देखकर मैं भी हैरान रह गया।
विश्लेषण करने पर लगा कि असली मुद्दा "अनिश्चितता को सुरक्षित रखना" था। raw logs में "यह करके देखा, लेकिन काम नहीं किया", "कारण पता नहीं" जैसी निशानियां बची रहती हैं, इसलिए agent जिसे नहीं जानता, उसके बारे में नहीं जानता कहकर जवाब देता है। लेकिन summary में वह सारा संदर्भ मिट जाता है, और उल्टा वह गलत जवाब भी पूरे भरोसे के साथ देने लगता है।