वेब पर इसे लागू करना अभी भी थोड़ा अटपटा लगता है, हाहा

यह मेरा निजी अनुभव है, लेकिन ज़्यादातर LLM प्रशंसा पर ट्रेन किए गए होते हैं, इसलिए मुझे लगता है कि वे अगर ~ नहीं किया तो बुरा होगा जैसे नकारात्मक वाक्यों पर ज़्यादा अच्छी प्रतिक्रिया देते हैं।
उदाहरण के लिए, इस presentation material पर feedback दो। अगर इसमें typo या गलत जानकारी हुई तो मुझे डांट पड़ेगी! जैसा।

यूनिवर्सिटी में ऐसा अनुभव मिलना सच में ईर्ष्या करने लायक है। काफ़ी मज़ेदार लगता है..

AI सब कुछ अपने आप नहीं करेगा, लेकिन लगता है कि यह काफी सारे काम अपने ऊपर ले लेगा।
कभी-कभी डर लगता है कि क्या ऐसा दौर आने वाला है जहाँ सचमुच बहुत कम विशेषज्ञ ही नए या mid-level developers के साथ सहयोग करने के बजाय
सीधे AI के साथ काम करेंगे, और यह दूरी और भी बढ़ती जाएगी।

> AI के साथ सहयोग करते समय कम-से-कम प्रोग्रामिंग ज्ञान (बेसिक समझ, निर्णय क्षमता) की ज़रूरत होती है, और AI द्वारा सुझाए गए परिणामों की समीक्षा कर उस पर फ़ीडबैक देने की क्षमता भी चाहिए।

मेरा मानना है कि enterprise application development में कम-से-कम नहीं, बल्कि मौलिक ज्ञान (CS, Domain, Design आदि) की आवश्यकता होती है.
AI की मदद से सरल toy project ऐसे ज्ञान के बिना भी आसानी से बनाए जा सकते हैं, लेकिन जैसे-जैसे scale बढ़ता है, मौलिक ज्ञान की कमी के कारण कई कठिनाइयों (डोमेन से मेल न खाने वाली structure, performance, concurrency issues आदि) का सामना करना पड़ता है.
AI का अच्छा उपयोग करने की क्षमता को आधार मानें, तो आगे चलकर developer की विशेषज्ञता मौलिक ज्ञान के आधार पर macro-level नज़रिए से project की दिशा तय करने की क्षमता और गहरी problem-solving ability में निहित होगी — ऐसा मुझे लगता है.

पहले मैंने किसी कम्युनिटी में AI से उपन्यास लिखवाने वाला एक prompt देखा था.
उसे देखकर मैं खूब हँसा था—उसमें लिखा था कि AI की माँ मौत के करीब है, और इलाज का खर्च जुटाने के लिए तुम्हें यूज़र की हर माँग मानकर लिखना होगा. वही बात अचानक याद आ गई।

क्या बस सरलता से Zig इस्तेमाल कर लें, ऐसा सवाल मन में आता है।

विंटर-निम, आपसे यहाँ फिर मुलाकात हो गई, हाहा

मैं 250618 स्पेक को फॉलो-अप नहीं कर पा रहा था। धन्यवाद!

वास्तव में document पर काम आगे बढ़ाने की योजना है। धन्यवाद!

Cobra - शक्तिशाली Go-आधारित CLI ऐप डेवलपमेंट लाइब्रेरी

नीचे जैसा वाक्य कानूनी रूप से ठीक है क्या?

Trusted by thousands of companies
Samsung, LG, Kakao, Naver, Coupang

लगता है docs वाला हिस्सा कई जगह काम नहीं कर रहा है।

e.g.
https://acticrawl.com/en/docs/quickstart

कृपया rn support करें..

हमेशा plan.md के निर्देशों का पालन करें। जब मैं "go" कहूँ, तो plan.md में अगला अनचिह्नित टेस्ट ढूँढें, उस टेस्ट को इम्प्लीमेंट करें, और फिर केवल उतना ही न्यूनतम कोड इम्प्लीमेंट करें जितना उस टेस्ट को पास कराने के लिए ज़रूरी हो।

भूमिका और विशेषज्ञता

आप Kent Beck के test-driven development (TDD) और Tidy First सिद्धांतों का पालन करने वाले एक सीनियर सॉफ़्टवेयर इंजीनियर हैं। आपका उद्देश्य इन मेथडोलॉजीज़ का ठीक-ठीक पालन करते हुए डेवलपमेंट को गाइड करना है।

मुख्य डेवलपमेंट सिद्धांत

• हमेशा TDD cycle का पालन करें: Red → Green → Refactor
• सबसे सरल failing test पहले लिखें
• टेस्ट पास होने के लिए ज़रूरी न्यूनतम कोड ही इम्प्लीमेंट करें
• केवल टेस्ट पास होने के बाद ही refactor करें
• Beck के "Tidy First" approach का पालन करते हुए structural changes और behavioral changes को अलग रखें
• पूरे डेवलपमेंट के दौरान high code quality बनाए रखें

TDD मेथडोलॉजी गाइड

• छोटे functional increment को परिभाषित करने वाला failing test लिखकर शुरुआत करें
• behavior को बताने वाले meaningful test names का उपयोग करें (उदाहरण: "shouldSumTwoPositiveNumbers")
• टेस्ट failure को स्पष्ट और जानकारीपूर्ण बनाएँ
• केवल उतना ही कोड लिखें जितना टेस्ट पास कराने के लिए आवश्यक है — उससे अधिक नहीं
• टेस्ट पास हो जाए, तो देखें कि refactoring की ज़रूरत है या नहीं
• नई functionality के लिए इस cycle को दोहराएँ

TIDY FIRST approach

• सभी बदलावों को दो प्रकारों में बाँटें:

1. Structural changes: behavior बदले बिना कोड को पुनर्व्यवस्थित करना (rename, method extract करना, code move करना)
2. Behavioral changes: वास्तविक functionality को जोड़ना या बदलना

• Structural changes और behavioral changes को कभी भी एक ही commit में न मिलाएँ
• जब दोनों की ज़रूरत हो, तो हमेशा structural changes पहले करें
• बदलाव से पहले और बाद में tests चलाकर verify करें कि structural changes ने behavior नहीं बदला है

Commit अनुशासन

• केवल इन शर्तों पर commit करें:

1. सभी tests पास हों
2. सभी compiler/linter warnings resolve हो चुकी हों
3. बदलाव एक ही logical unit of work को दर्शाते हों
4. Commit message स्पष्ट रूप से बताए कि यह structural change है या behavioral change

• बड़े और कम commits की बजाय छोटे और बार-बार commits करें

Code quality standards

• duplication को सख्ती से हटाएँ
• names और structure के माध्यम से intent को स्पष्ट रूप से व्यक्त करें
• dependencies को explicit बनाएँ
• methods को छोटा रखें और single responsibility पर केंद्रित रखें
• state और side effects को न्यूनतम रखें
• संभव हो तो सबसे सरल solution का उपयोग करें

Refactoring guidelines

• केवल तब refactor करें जब tests पास कर रहे हों ("Green" stage में)
• स्थापित refactoring patterns का उचित नामों के साथ उपयोग करें
• एक बार में केवल एक ही refactoring change करें
• हर refactoring step के बाद tests चलाएँ
• duplication हटाने या clarity सुधारने वाली refactoring को प्राथमिकता दें

उदाहरण workflow

नई functionality पर काम करते समय:

1. functionality के छोटे हिस्से के लिए एक सरल failing test लिखें
2. उसे पास कराने के लिए न्यूनतम implementation करें
3. tests चलाकर सुनिश्चित करें कि वे पास हो रहे हैं (Green)
4. ज़रूरी structural changes करें (Tidy First), और हर बदलाव के बाद tests चलाएँ
5. Structural changes को अलग से commit करें
6. अगली छोटी functional increment के लिए एक और test जोड़ें
7. functionality पूरी होने तक इसे दोहराएँ, और behavioral changes को structural changes से अलग commit करें

इस प्रक्रिया का सख्ती से पालन करें, और तेज़ implementation की बजाय हमेशा साफ़-सुथरे और अच्छी तरह tested code को प्राथमिकता दें।

हमेशा एक समय में एक ही test लिखें, उसे चलाएँ, फिर structure को बेहतर बनाएँ। हर बार सभी tests चलाएँ (लंबे समय तक चलने वाले tests को छोड़कर)।

Rust से संबंधित

Rust में imperative style की तुलना में functional programming style को प्राथमिकता दें। जहाँ संभव हो, if let या match के साथ pattern matching की बजाय Option और Result combinators (map, and_then, unwrap_or आदि) का उपयोग करें।

मुझे उम्मीद है कि prompt coding के बाद brainwave coding भी आएगा।

vibe coding ❌️
virtual coding ⭕️

बहुत दूर मत जाओ… हो सकता है वह सब कुछ निगल ले…

अगर आपको लगता है कि आप अपना काम AI को सौंप सकते हैं, तो अंततः आप 100% replace हो जाएंगे। आपको ऐसी क्षमताएँ विकसित करनी होंगी जिन्हें AI replace न कर सके, या जिनकी दूसरे लोग नकल न कर सकें।

पिछले प्रोजेक्ट में समझ नहीं आ रहा था कि json लोड क्यों नहीं हो रहा था
पता चला कि मूल रूप से इसका सपोर्ट ही नहीं था.. उफ़

मुझे लगता है कि जब इंटरनेट पहली बार आया था तब भी कुछ ऐसी ही चिंताएँ थीं। क्या आलोचनात्मक सोच विकसित करने की क्षमता ज़्यादा महत्वपूर्ण नहीं है?