पाठ 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 बनने से पहले पकड़ें।