यह कुछ वैसा ही सवाल लगता है जैसे कहना कि "FSD अब इतना स्मार्ट हो गया है, इसलिए ड्राइवर सो भी जाए तो चलेगा।"
तकनीकी रूप से लगता है कि धीरे-धीरे ऐसा दौर आ सकता है, लेकिन असली बात यह होगी कि जवाबदेही जैसी बाधा को हम कैसे पार करेंगे।
मुझे लगता है कि code review कम से कम एक न्यूनतम सुरक्षा उपाय तो है।
यह वह विषय है जिस पर मैं भी कंपनी में अक्सर सोचता रहा हूँ, और यह अच्छा है। मुझे लगता है कि इसे उस हार्नेस में भी लागू करके देखना चाहिए जिसे मैं व्यक्तिगत रूप से बना रहा हूँ।
अब तक LLM/Agentic Coding एक बेहतरीन tool है, लेकिन बेहतरीन Engineer नहीं। जैसे Agentic coding में अच्छा Plan महत्वपूर्ण होता है, वैसे ही अंततः उपयोगकर्ता के पास code को समझने और उस पर निर्णय लेने की क्षमता होनी चाहिए। उदाहरण के लिए, fastrender और CCC ने Agentic Coding की संभावनाएँ दिखाईं, लेकिन साथ ही इसकी स्पष्ट सीमाएँ भी दिखाईं।
यह सिर्फ़ कोड रिव्यू को हटा देने की बात नहीं लगती, बल्कि उससे ऊपर के कॉन्सेप्ट—यानी intent—और यह कि वह intent सही तरह से काम कर रहा है या नहीं, इसे स्पष्ट रूप से verify कर सकने वाले output के आधार पर review करने की बात लगती है.
मौजूदा समय में, design या architecture level के बजाय code implementation की details को black box की तरह बनाए रखना वांछनीय है, ऐसा मेरा मानना है.
लगता है Rust और Zig ecosystem लगातार फैल रहे हैं.
पता नहीं AI के लिए JavaScript कब तक ठीक रहेगा.
लगता है दूसरी programming में कोई उच्चतर मूल्य होता है।
यह कुछ वैसा ही सवाल लगता है जैसे कहना कि "FSD अब इतना स्मार्ट हो गया है, इसलिए ड्राइवर सो भी जाए तो चलेगा।"
तकनीकी रूप से लगता है कि धीरे-धीरे ऐसा दौर आ सकता है, लेकिन असली बात यह होगी कि जवाबदेही जैसी बाधा को हम कैसे पार करेंगे।
मुझे लगता है कि code review कम से कम एक न्यूनतम सुरक्षा उपाय तो है।
मैं भी planning Sonnet में और code implementation Opus में करता हूँ, लेकिन हो सकता है कि लेखक का तरीका ज़्यादा efficient हो।
मैं भी योजना बनाने के लिए Opus इस्तेमाल करता हूँ, रिव्यू के लिए Codex high, और असली coding के लिए sonet या codex medium चलाता हूँ।
उससे भी ऊपरी कॉन्सेप्ट, यानी intent validation, इंसान ही क्यों करता है..?
वाह, धन्यवाद!!
यह किस रास्ते से लीक हुआ? या सार्वजनिक हुआ? यह जानने की जिज्ञासा है।
> महंगे मॉडल (Opus) को planning के लिए, सस्ते मॉडल (Sonnet) को code लिखने के लिए इस्तेमाल करके token बचाए जाते हैं
कई लोग planning के लिए Sonnet और code implementation के लिए Opus इस्तेमाल करते हैं, लेकिन यहां इसका उलटा है
सेटअप थोड़ा अस्पष्ट है..
यह वह विषय है जिस पर मैं भी कंपनी में अक्सर सोचता रहा हूँ, और यह अच्छा है। मुझे लगता है कि इसे उस हार्नेस में भी लागू करके देखना चाहिए जिसे मैं व्यक्तिगत रूप से बना रहा हूँ।
ओह .... यह अच्छा है .... ?
मुझे भी यह असुविधाजनक लगा था, इसलिए खोजते-खोजते OpenUsage मिला और मैं उसका इस्तेमाल कर रहा हूँ, और अब तक उससे काफ़ी संतुष्ट हूँ।
यह टिप्पणी देखकर मैंने इसे इस्तेमाल न करने का फैसला किया.. लगता है statusline ही काफी है
मुझे लगता है कि धीरे-धीरे हम review को और सरल करते हुए और testing को ज़्यादा सख्त बनाने की दिशा में बढ़ेंगे।
अब तक LLM/Agentic Coding एक बेहतरीन tool है, लेकिन बेहतरीन Engineer नहीं। जैसे Agentic coding में अच्छा Plan महत्वपूर्ण होता है, वैसे ही अंततः उपयोगकर्ता के पास code को समझने और उस पर निर्णय लेने की क्षमता होनी चाहिए। उदाहरण के लिए, fastrender और CCC ने Agentic Coding की संभावनाएँ दिखाईं, लेकिन साथ ही इसकी स्पष्ट सीमाएँ भी दिखाईं।
मेरा लॉगिन बार-बार साइन आउट हो जाता है, इसलिए मैं इसे ज़्यादा इस्तेमाल नहीं कर पाता। क्या बाकी लोगों के साथ भी ऐसा ही हो रहा है?!
लगता है लाइब्रेरी का नाम भी मूल को ध्यान में रखकर ही
pymathरखा गया है।यह सिर्फ़ कोड रिव्यू को हटा देने की बात नहीं लगती, बल्कि उससे ऊपर के कॉन्सेप्ट—यानी intent—और यह कि वह intent सही तरह से काम कर रहा है या नहीं, इसे स्पष्ट रूप से verify कर सकने वाले output के आधार पर review करने की बात लगती है.
मौजूदा समय में, design या architecture level के बजाय code implementation की details को black box की तरह बनाए रखना वांछनीय है, ऐसा मेरा मानना है.
अरे, माफ़ कीजिए