पाठ 15 / 29
छोटे चरण, योजनाएँ और समीक्षा चौकियाँ
हर बदलाव को समीक्षा-योग्य रखें और तय करें मनुष्य कहाँ देखे।
योजना, अनुमोदन, कार्यान्वयन, समीक्षा
भरोसेमंद लय है खोजें → योजना → कार्यान्वयन → सत्यापन → समीक्षा। पहले agent को संपादन किए बिना पढ़ने और योजना प्रस्तावित करने दें; कोड लिखने से पहले योजना सुधारें, जो सस्ता है, कोड जिसे पलटना महँगा है। फिर पास होते tests वाले छोटे commits में लागू करें। जहाँ ग़लती की क़ीमत ऊँची है वहाँ मानव चौकियाँ जोड़ें: योजना अनुमोदित करें; कोई नई dependency, schema बदलाव या सुरक्षा-संवेदनशील संपादन अनुमोदित करें; अंतिम diff की समीक्षा करें। ऐसे pull requests का लक्ष्य रखें जिन्हें व्यक्ति मिनटों में समीक्षा कर सके (दसियों बदली पंक्तियाँ, एक उद्देश्य); 2,000-पंक्ति का agent diff प्रभावी रूप से अनसमीक्षित कोड है। Diff बहुत बड़ा हो तो agent से उसे तार्किक commits या अलग PRs में बाँटने को कहें। Agent को तेज़ junior सहकर्मी की तरह मानें: मज़बूत आउटपुट, पर समीक्षा के बिना कुछ merge नहीं।
मनुष्य कहाँ देखे
चौकियाँ वहाँ रखें जहाँ ग़लतियाँ महँगी या पलटने में कठिन हैं।
Stage Agent does Human does
explore reads, searches, summarises (optional) answers questions
plan proposes steps, files, tests APPROVES or corrects the plan
implement small edits, runs tests, commits watches diffs; approves risky actions
verify full tests, lint, type checks checks the results are real, not claimed
review writes summary + PR REVIEWS the diff; merges or requests changesक्या और क्यों बदला उसका सार माँगें
Diff के पास छोटी व्याख्या समीक्षा तेज़ करती है, पर उसे diff से मिलाकर जाँचें।
त्वरित जाँच: संपादन से पहले agent से योजना क्यों माँगें?
- योजना सुधारना सस्ता है; ग़लत कोड पलटना महँगा
- योजनाएँ बिना कारण मॉडल को धीमा करती हैं
- योजनाएँ tests की जगह लेती हैं
- योजनाएँ git के लिए ज़रूरी हैं
Answer
योजना सुधारना सस्ता है; ग़लत कोड पलटना महँगा — ग़लतफ़हमियाँ बड़े diffs बनने से पहले पकड़ें।