स्टार्टअप्स के लिए ज़रूरी product engineering को गहराई से समझना अच्छी बात है, लेकिन मेरा मानना है कि तकनीक को उसकी चरम सीमा तक ले जाकर उसे लगातार तराशने और निखारने का रास्ता भी अब भी उतना ही सार्थक है. सरल web applications बनाने वाला development भले ही AI से replace हो जाए, लेकिन किसी न किसी को Kubernetes की परिकल्पना करनी होगी और ElasticSearch को design करना होगा.
यह JDK23 में शामिल हो गया है।
टेस्ट करके देखा तो, प्रोजेक्ट का JDK version 23 से कम होने पर भी अगर IDE या Javadoc EXPORT tool इसे सपोर्ट करे, तो यह सामान्य रूप से काम करता है।
Linux Landlock एक kernel-native security module है जो unprivileged processes को खुद को sandbox करने देता है - लेकिन इसका इस्तेमाल लगभग कोई नहीं करता क्योंकि API ... मुश्किल है!
Landlock के बारे में पहली बार सुना, दिलचस्प लग रहा है
AI के साथ coding करते समय मुझे यह महसूस हुआ कि, अगर code का सिर्फ़ एक हिस्सा भी AI को दिया जाए, तो वह context समझ सके—इसके लिए Single Responsibility Principle + TDD जैसी unit-level splitting करते-करते यह ज़रूरी हो जाता है कि उसे इतना अच्छी तरह structured किया जाए कि बड़े context को पढ़ने की ज़रूरत न पड़े, और सिर्फ़ हिस्से के context से भी वह काफ़ी कुछ समझ ले।
मैं AI का सबसे ज़्यादा इस्तेमाल अपने शौक के तौर पर web game बनाने में करता हूँ, और मैं इससे सहमत हूँ। जब प्रोजेक्ट एक निश्चित स्तर से बड़ा हो जाता है, तो किसी बिंदु पर AI की, कहें तो, फोकस बनाए रखने की क्षमता काफ़ी कम होती हुई दिखती है। मैं इसका इस्तेमाल इस तरह करता हूँ: गेम के पूरे tree और source code को TOC सहित एक ही फ़ाइल में जोड़ देता हूँ, फिर एक नया thread बनाकर वह फ़ाइल अपलोड करता हूँ और काम आगे बढ़ाता हूँ। और जब भी सवाल पूछता हूँ, तो हमेशा मौजूदा project का नाम साफ़-साफ़ और स्पष्ट रूप से बताकर जवाब माँगता हूँ। इसके बावजूद अब भी कुछ हिस्से असंतोषजनक हैं, लेकिन... अतीत में real life की व्यस्तता के कारण जिन शौकिया कामों की शुरुआत करने की भी हिम्मत नहीं होती थी, उन्हें अब अपेक्षाकृत कम समय में पूरा कर पा रहा हूँ—इस बात से मैं बहुत संतुष्ट हूँ।
अभी भी high-level problem solving के लिए, deep research सहित LLMs उपयोगी नहीं हैं। (उदाहरण के लिए, paper-level algorithm development)
अत्यधिक optimization, और ऐसी coding जिसमें विभिन्न system characteristics और technical issues को समझना ज़रूरी हो, उनमें भी अभी इंसानी हाथ की ज़रूरत है। डेवलपर सिर्फ साधारण programmer नहीं, बल्कि problem solver है। कभी न कभी end-to-end problem solving भी संभव हो जाएगी, लेकिन अभी यह typing और simple programming में लगने वाला समय बचाकर ज़्यादा कठिन समस्याओं तक पहुँचने के तरीकों में निवेश करने देता है, इसलिए productivity के लिहाज़ से यह सकारात्मक लगता है।
Tech lead के रूप में मैं ऐसे काम काफ़ी ज़्यादा करता हूँ। Story point-आधारित quantification की कोशिश करना भी कुछ ऐसा ही है, लेकिन अच्छी बात यह है कि कंपनी इतनी बड़ी नहीं है, इसलिए executives सहित बाकी लोग यह समझते हैं कि मैं क्या भूमिका निभाता हूँ, इसलिए अभी के लिए कोई समस्या होती नहीं दिख रही है.
अगर संगठन बड़ा होता है, तो quantification के तरीकों पर भी सोचना पड़ेगा।
स्टार्टअप्स के लिए ज़रूरी product engineering को गहराई से समझना अच्छी बात है, लेकिन मेरा मानना है कि तकनीक को उसकी चरम सीमा तक ले जाकर उसे लगातार तराशने और निखारने का रास्ता भी अब भी उतना ही सार्थक है. सरल web applications बनाने वाला development भले ही AI से replace हो जाए, लेकिन किसी न किसी को Kubernetes की परिकल्पना करनी होगी और ElasticSearch को design करना होगा.
"ASO का सपना" वाली टिप्पणी प्रभावशाली लगी।
जानकारी के लिए, Vibe coding से बनाया गया गेम यह है: https://www.stdy.blog/vibe-go-stone/
यह JDK23 में शामिल हो गया है।
टेस्ट करके देखा तो, प्रोजेक्ट का JDK version 23 से कम होने पर भी अगर IDE या Javadoc EXPORT tool इसे सपोर्ट करे, तो यह सामान्य रूप से काम करता है।
इसमें अच्छी अंतर्दृष्टि है। धन्यवाद।
"वर्तमान स्तर"वाले हिस्से पर नज़र जाती है। क्या हम LLM को इंसानी समय की अवधारणा से देख रहे हैं?लगता है कि इसे standard में शामिल कर लिया गया है।
Linux Landlock एक kernel-native security module है जो unprivileged processes को खुद को sandbox करने देता है - लेकिन इसका इस्तेमाल लगभग कोई नहीं करता क्योंकि API ... मुश्किल है!
Landlock के बारे में पहली बार सुना, दिलचस्प लग रहा है
AI के साथ coding करते समय मुझे यह महसूस हुआ कि, अगर code का सिर्फ़ एक हिस्सा भी AI को दिया जाए, तो वह context समझ सके—इसके लिए Single Responsibility Principle + TDD जैसी unit-level splitting करते-करते यह ज़रूरी हो जाता है कि उसे इतना अच्छी तरह structured किया जाए कि बड़े context को पढ़ने की ज़रूरत न पड़े, और सिर्फ़ हिस्से के context से भी वह काफ़ी कुछ समझ ले।
मैं AI का सबसे ज़्यादा इस्तेमाल अपने शौक के तौर पर web game बनाने में करता हूँ, और मैं इससे सहमत हूँ। जब प्रोजेक्ट एक निश्चित स्तर से बड़ा हो जाता है, तो किसी बिंदु पर AI की, कहें तो, फोकस बनाए रखने की क्षमता काफ़ी कम होती हुई दिखती है। मैं इसका इस्तेमाल इस तरह करता हूँ: गेम के पूरे tree और source code को TOC सहित एक ही फ़ाइल में जोड़ देता हूँ, फिर एक नया thread बनाकर वह फ़ाइल अपलोड करता हूँ और काम आगे बढ़ाता हूँ। और जब भी सवाल पूछता हूँ, तो हमेशा मौजूदा project का नाम साफ़-साफ़ और स्पष्ट रूप से बताकर जवाब माँगता हूँ। इसके बावजूद अब भी कुछ हिस्से असंतोषजनक हैं, लेकिन... अतीत में real life की व्यस्तता के कारण जिन शौकिया कामों की शुरुआत करने की भी हिम्मत नहीं होती थी, उन्हें अब अपेक्षाकृत कम समय में पूरा कर पा रहा हूँ—इस बात से मैं बहुत संतुष्ट हूँ।
टाइटल ने फँसा लिया था। हा हा, सहमत हूँ~~
अभी भी high-level problem solving के लिए, deep research सहित LLMs उपयोगी नहीं हैं। (उदाहरण के लिए, paper-level algorithm development)
अत्यधिक optimization, और ऐसी coding जिसमें विभिन्न system characteristics और technical issues को समझना ज़रूरी हो, उनमें भी अभी इंसानी हाथ की ज़रूरत है। डेवलपर सिर्फ साधारण programmer नहीं, बल्कि problem solver है। कभी न कभी end-to-end problem solving भी संभव हो जाएगी, लेकिन अभी यह typing और simple programming में लगने वाला समय बचाकर ज़्यादा कठिन समस्याओं तक पहुँचने के तरीकों में निवेश करने देता है, इसलिए productivity के लिहाज़ से यह सकारात्मक लगता है।
लगभग बनाकर बाकी details को बाद में ठीक करने वाला पैटर्न मुझे सच में पसंद है।
मेरा मानना है कि सिर्फ व्यक्तियों को ही नहीं डरना चाहिए, बल्कि संगठनों को भी ऐसे मूर्खतापूर्ण(?) सवाल पूछने को प्रोत्साहित करना चाहिए।
असल में schema सेट करके प्राप्त करके, काफ़ी लोग उसे इसी तरह इस्तेमाल करते हैं।
लगता है Vibe coding कोई मीम नहीं, बल्कि डेवलपमेंट की एक नई methodology थी।
यह शास्त्रों जैसी संकेत-पद्धति इस्तेमाल करने वाले दूसरे तरह के अध्ययन में मददगार हो सकता है। जैसे Plato की किताबें...
Tech lead के रूप में मैं ऐसे काम काफ़ी ज़्यादा करता हूँ। Story point-आधारित quantification की कोशिश करना भी कुछ ऐसा ही है, लेकिन अच्छी बात यह है कि कंपनी इतनी बड़ी नहीं है, इसलिए executives सहित बाकी लोग यह समझते हैं कि मैं क्या भूमिका निभाता हूँ, इसलिए अभी के लिए कोई समस्या होती नहीं दिख रही है.
अगर संगठन बड़ा होता है, तो quantification के तरीकों पर भी सोचना पड़ेगा।
अरे... ऐसा तो नहीं कि हमें छोड़कर ये अकेले ही निर्वाण में चले गए हों?