जिनी को साधना: "Kent Beck की तरह"

• यह परखने के लिए एक प्रयोग किया गया कि AI कोडिंग टूल (जिनी) को "Kent Beck की तरह कोड करो" जैसा persona prompt देने पर क्या code quality बेहतर होती है; नतीजे में test style और variable naming बेहतर हुए, लेकिन architecture design में बदलाव नहीं आया
• Rope data structure को implement करने वाले एक project के जरिए persona prompt और design constraints के प्रभाव की तुलना कर सत्यापन किया गया
• persona ने micro behavior (test करने का तरीका, naming) को बेहतर किया, जबकि explicit constraints ने macro architecture (class hierarchy) तय की
• 4 समूहों के प्रयोग में persona और constraints को मिलाकर बनाया गया prompt सबसे अच्छा परिणाम लाया
• Rich Sutton के "The Bitter Lesson" का हवाला देते हुए यह संकेत दिया गया कि मानवीय विशेषज्ञता को encode करने की बजाय computing resources का उपयोग अधिक प्रभावी है

---

मौजूदा AI coding tools की अवस्था

• मौजूदा AI coding tools (जिनी) अभी "घोड़े के बिना गाड़ी" वाले चरण में हैं
• हर तकनीकी नवाचार को पहले मौजूदा ढांचे में समझा जाता है, फिर उसके मूलभूत बदलाव को पहचाना जाता है
  • घोड़े के बिना गाड़ी → automobile
  • wireless telegraph → radio
  • electronic mail → messaging
• नई तकनीक के second-order effects, reinforcement loops और inhibition loops को समझने के लिए उसे काफी समय तक इस्तेमाल करना पड़ता है

प्रयोग: Rope data structure

• Rope data structure बहुत लंबी strings में बीच के character को कुशलता से delete करने के लिए इस्तेमाल होने वाली संरचना है
• साधारण तरीका दाईं ओर के सभी characters को shift करता है, जिससे O(n) समय लगता है
• Rope structure substring objects और concatenation objects का उपयोग करके deletion को constant time में संभालती है
  • delete करते समय 3 objects allocate होते हैं
  • traversal O(operations) होता है, लेकिन यह string length से छोटा रहता है और periodic compression संभव है

प्रयोग की प्रक्रिया

Phase 1: persona ("Code like Kent Beck")

• यह जांचा गया कि "Code like Kent Beck" prompt जोड़ने से code quality बेहतर होती है या नहीं
• परिणाम: code style में सुधार की पुष्टि हुई
  • variable names बेहतर हुए
  • test strategy monolithic script से modular unit tests (TDD style) में बदल गई
• अप्रत्याशित खोज: architecture नहीं बदला
  • Rope को standard binary tree के रूप में implement किया गया
  • Kent Beck द्वारा इस्तेमाल किया जाने वाला Composite pattern नजरअंदाज कर दिया गया

Phase 2: design guide जोड़ना

• Control group का code इतना verbose था कि token limit exceed होने से syntax error आ गया
  • token limit बढ़ाकर इसे हल किया गया
  • ज्यादा computing एक सरल समाधान हो सकता है
• prompt में explicit constraints जोड़ी गईं
  • "Composite pattern का उपयोग करो"
  • "behavior को छोटे, specialized classes में बांटो"
• परिणाम: अपेक्षित design implement हुआ
  • Substring और Concatenation के लिए अलग classes
  • single class की तुलना में ज्यादा सरल संरचना
  • वास्तव में इससे और सरल design निकला: Null Object (EmptyString) या native string wrapper के बिना Substring 0..size से handle किया गया

Phase 3: 4 समूहों का अलग प्रयोग

• कौन-सा intervention असर पैदा कर रहा था, यह जांचने के लिए cross experiment design किया गया
  1. Control: standard assistant
  2. Kent Beck: केवल persona लागू
  3. Composite: केवल architecture constraints लागू
  4. Combined: persona + constraints

प्रयोग का निष्कर्ष

• 2x2 matrix effect की पुष्टि हुई
  1. persona micro behavior तय करती है: "Kent Beck" prompt ने test style और naming को लगातार बेहतर किया, लेकिन structural decisions पर असर नहीं डाला
  2. constraints macro architecture तय करती हैं: "Composite Pattern" prompt ने class hierarchy को enforce किया, और persona के बिना भी granular design तैयार किया
  3. मिलाजुला तरीका सबसे बेहतर: Combined group ने सही architecture (Composite) और सही development habits (TDD/Unit Tests) दोनों दिए

The Bitter Lesson का अनुप्रयोग

• छिपा हुआ लक्ष्य: जिनी functionality और future के बीच संतुलन बनाते हुए बेहतर development करे
• आजमाए गए तरीके: सावधानी से prompting, जिनी के सुझाए बदलावों की बारीकी से समीक्षा, छोटे/बड़े कदम आदि
• Rich Sutton के "The Bitter Lesson" का हवाला
  • 70 साल के AI research का सबक: मानवीय विशेषज्ञता को encode करने से बेहतर है computing resources का उपयोग
  • style को encode करने की कोशिश वही सामान्य गलती थी जो सब कर रहे थे

computing का उपयोग कर प्रभावी development style का प्रस्ताव

• countless repositories की खराब code style कॉपी करने वाले अनाड़ी coding जिनी में फँसे रहने की जरूरत नहीं है
• computing का उपयोग करने का तरीका प्रस्तावित है
  1. एक large repository चुनो
  2. दस लाख जिनी अगला feature implement करें, लेकिन हर जिनी refactoring के तरीके और मात्रा को अलग तरह से चुने
  3. सबसे कम लागत (समय, tokens, बिजली, खर्च आदि) में feature जोड़ने में सफल जिनी को चुनो
  4. इसे कई जिनी, कई features, कई repositories में दोहराओ
• यह coding को "waste" करने जैसा दिख सकता है, लेकिन वास्तव में ऐसा नहीं है
• Jessica Kerr इसे "Design Contest" कहती हैं