49 पॉइंट द्वारा spilist2 2025-06-30 | 5 टिप्पणियां | WhatsApp पर शेयर करें
  • Kent Beck ने हाल ही में Augmented Coding: Beyond the Vibes नाम से एक लेख लिखा
  • यह कहानी है कि Kent Beck ने खुद AI की मदद से Rust और Python में उच्च-प्रदर्शन और production level के काफ़ी करीब एक B+ Tree लाइब्रेरी (BPlusTree3) लिखी
  • इसमें खास तौर पर उपयोगी और अंतर्दृष्टिपूर्ण लगे 3 बिंदुओं का सार और अनुवाद प्रस्तुत है

Augmented Coding, vibe coding से कैसे अलग है?

  • vibe coding में आप code पर ध्यान नहीं देते, सिर्फ system behavior पर ध्यान देते हैं. अगर error हो, तो आप बस कहते हैं कि 'ऐसी error है' और उम्मीद करते हैं कि वह उसे ठीक कर देगा
  • Augmented Coding में आप code पर ध्यान देते हैं. code की complexity, test, और test coverage महत्वपूर्ण हैं.
  • Augmented Coding में भी पारंपरिक coding की तरह "Tidy Code That Works", यानी 'चलने वाला साफ-सुथरा code' महत्वपूर्ण है. बस पहले की तरह बहुत ज़्यादा typing नहीं करनी पड़ती

3 संकेत कि AI ग़लत दिशा में जा रहा है

Augmented Coding में AI के बीच के परिणामों को देखते रहना और यह जाँचना महत्वपूर्ण है कि क्या ये 3 संकेत दिख रहे हैं, ताकि समय पर हस्तक्षेप किया जा सके

  • समान behavior को बार-बार दोहराना (जैसे infinite loop)
  • ऐसी functionality implement करना जो मैंने नहीं माँगी. भले ही वह तार्किक अगला कदम क्यों न लगे.
  • test को delete या disable करना जैसी, या कोई भी दूसरी ऐसी निशानी जिससे लगे कि AI cheating कर रहा है.

TDD में मदद करने वाला system prompt

  • मूल लेख का पूरा text कॉपी करना थोड़ा असुविधाजनक था, इसलिए उसे gist में रखा गया है
  • अंत में सिर्फ Rust syntax को अपनी programming language/framework के मुताबिक बदल दें, तो यह हर जगह बहुत अच्छे से दोबारा इस्तेमाल किया जा सकने वाला prompt लगता है.

अंत में

> मुझे पता है कि इस बात का काफ़ी डर है कि हमारा प्रिय पेशा गायब हो जाएगा और code के साथ काम करने का आनंद खत्म हो जाएगा. चिंतित होना स्वाभाविक है. हाँ, 'genie' के साथ programming करना निश्चित रूप से बदलाव लाता है, लेकिन यह अब भी programming ही है. कुछ मायनों में यह कहीं बेहतर programming experience है. मैं प्रति घंटे जितने निर्णय लेता हूँ, उनकी संख्या और गुणवत्ता को देखें, तो उबाऊ और घिसे-पिटे निर्णय कम हुए हैं और अधिक महत्वपूर्ण programming निर्णय बढ़े हैं.

> तथाकथित 'yak shaving' कहलाने वाले, यानी मूल उद्देश्य से दूर छोटे-मोटे झंझट वाले ज़्यादातर काम गायब हो जाते हैं. मैंने 'genie' से coverage tester चलाने और code की विश्वसनीयता बढ़ाने वाले tests सुझाने को कहा. 'genie' के बिना यह काम बहुत कठिन लगता. क्योंकि पहले यह पता लगाना पड़ता कि tester चलाने के लिए किस library का कौन-सा version चाहिए. शायद मैं लगभग दो घंटे जूझता और फिर छोड़ देता. इसके बजाय, मुझे सिर्फ 'genie' से कहना होता है, और 'genie' खुद विवरण संभाल लेता है.

5 टिप्पणियां

 
passerby 2025-07-01

हमेशा 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 आदि) का उपयोग करें।

 
crawler 2025-07-01

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

 
jwh926 2025-07-01

vibe coding ❌️
virtual coding ⭕️

 
ifmkl 2025-06-30

मेटावर्स के बाद है हम्म.. माउथ-कोडिंग?

 
zihado 2025-06-30

अब लगता है अगला नंबर metaverse coding का है।