Tutorial 4 Prompting and Reviewing hi

ट्यूटोरियल 4 · प्रॉम्प्टिंग और रिव्यू

लक्ष्य: मेटा-कौशल। अब आप एक एजेंट के साथ एक feature बना सकते हैं — यह अध्याय उसे सहजता से और बार-बार करने के बारे में है: ऐसे prompts लिखना जो पहली बार में सही उतरें, diffs को कुशलता से review करना, चीज़ें बिगड़ने पर iterate करना, और कई sessions में गति बनाए रखना।

← पिछला: ट्यूटोरियल 3 आपका पहला एजेंट टास्क · अगला: ट्यूटोरियल 5 लोकलाइज़ेशन

---

एक search box की तरह नहीं, एक lead की तरह prompt दें

एजेंट एक तेज़, शाब्दिक, उत्साही junior इंजीनियर है। जैसे आप एक अच्छे junior को lead करते, वैसे ही इसे lead करें:

• लक्ष्य और constraints बताएँ। "endorse जोड़ो" कमज़ोर है। "connect pattern को follow करते हुए endorse जोड़ो, सिर्फ़ seeded RNG, tests के साथ, गेट हरा रहे" मज़बूत है। Constraints ही वह तरीका हैं जिससे आपको फिट बैठने वाला कोड मिलता है।
• उदाहरण की ओर इशारा करें। "renderConnect द्वारा इस्तेमाल किए pattern को follow करो" एक पैराग्राफ़ के वर्णन से बेहतर है। मौजूदा कोड सबसे अच्छा spec है।
• edits से पहले एक plan माँगें किसी भी non-trivial चीज़ पर। एक plan को redirect करना सस्ता है; दस edited फ़ाइलों को undo करना महँगा।
• प्रति prompt एक task। "endorse जोड़ो, RNG भी refactor करो, README भी update करो" को bundle करना एक उलझा diff देता है जिसे review करना कठिन है।
• इसे test गेट दें। "npm test चलाओ और जब तक हरा न हो तब तक इसे पूरा मत मानो" एजेंट को ऐसी चीज़ में बदल देता है जो अपना काम खुद जाँचती है।

हर बार diff review करें

गति ही एजेंट का पूरा मकसद है — पर बिना पढ़ी गति ही वह तरीका है जिससे bugs ship होते हैं। एक तेज़, सुसंगत review प्रतिवर्त बनाएँ:

1. Scope: क्या इसने सिर्फ़ वही बदला जो बदलना चाहिए था? असंबंधित हिली लाइनें एक smell हैं।
2. Patterns: क्या यह आस-पास के कोड से मेल खाता है, बिना किसी नई dependency और src/ के अंदर बिना किसी I/O के?
3. प्रोजेक्ट के नियम: इस repo के लिए, वह है सिर्फ़ seeded RNG (diff में Math.random grep करें), user-visible text language bundles में (hardcoded नहीं), और card लाइनें कभी उस width से ज़्यादा नहीं जिस तक layout pad करता है।
4. Accessibility: क्या नया output --accessible में टिकता है? lockedin --accessible <your command> चलाएँ और जाँचें कि यह साफ़ plain text की तरह पढ़ता है — कोई नया decorative glyph a11yFilter से छिपकर नहीं निकल रहा।
5. Tests: क्या कोई नया test है, और अगर feature टूटे तो क्या वह सचमुच fail होगा? पूछें: "इस नए test को fail कराने के लिए मैं कौन-सी line बदलूँगा?"
6. इसे चलाएँ: npm test, फिर कमांड चलाएँ और output को देखें।

आपको हर character समझने की ज़रूरत नहीं — पर आपको हर निर्णय समझना होगा। अगर आप किसी बदलाव को समझा नहीं सकते, तो स्वीकार करने से पहले एजेंट से उसे समझाने को कहें।

हरा न हो तो iterate करें

एक लाल गेट एक सामान्य चरण है, विफलता नहीं। इलाज है सटीक feedback:

"npm test इससे fail होता है: [paste the exact error]। renderEndorse width test उम्मीद करता है कि हर card line ≤ 60 visible columns हो। test को कमज़ोर किए बिना इसे fix करो।"

असली error text paste करें। "यह टूटा है" एजेंट को अनुमान लगवाता है; stack trace उसे fix करवाता है। और नए सिरे से शुरू करने के बजाय उसी conversation को जारी रखना पसंद करें — एजेंट के पास वह जो अभी लिखा उसका context पहले से है। अगर दो-तीन iterations converge न हों, पीछे हटें और re-scope करें: task एक prompt के लिए शायद बहुत बड़ा है।

sessions में गति बनाए रखें

असल काम एक बैठक से ज़्यादा में फैलता है। दो आदतें एक एजेंट को समय के साथ प्रभावी रखती हैं:

• Memory / conventions। अगर आपका एजेंट durable memory या एक project instructions फ़ाइल सपोर्ट करता है, तो वहाँ वे नियम दर्ज करें जिन्हें उसे हमेशा follow करना चाहिए (जैसे "सारी randomness को pick/shuffle इस्तेमाल करना चाहिए", "पूरा घोषित करने से पहले npm test चलाओ")। आप एक convention हर prompt के बजाय एक बार बताते हैं।
• एक handoff note। यह repo एक छोटा, sanitized status doc रखता है docs/HANDOFF.md पर: प्रोजेक्ट क्या है, कैसे बना है, कैसे test होता है, और आगे क्या। जब आप लौटते हैं (या किसी teammate — या किसी दूसरे एजेंट को handoff करते हैं), वह note सेकंडों में context फिर बना देता है। एजेंट से कहें कि किसी बदलाव के हिस्से के रूप में इसे up to date रखे।

रखने लायक Guardrails

• गेट पर समझौता नहीं। कुछ भी ship होने से पहले हरे tests। यही आपको तेज़ चलने और output पर भरोसा करने देता है।
• आप ही रिकॉर्ड के reviewer हैं। एजेंट लिखता है; आप तय करते हैं। एक diff स्वीकार करने का मतलब है कि आप उसकी ज़मानत लेते हैं।
• छोटे, verifiable कदम एक विशाल छलांग से बेहतर हैं। हर स्वीकृत बदलाव को ऐप को चलती हालत में छोड़ना चाहिए।

---

✅ अपने एजेंट के साथ आज़माएँ

1. एक mentor कमांड ("बिन माँगी सलाह बाँटता है") के लिए एक-पैराग्राफ़ spec लिखें, constraints सहित, और एजेंट से उसे test-first तरीके से बनवाएँ — plan, tests, code, गेट — हर चरण पर review करते हुए।
2. एजेंट से docs/HANDOFF.md update करने को कहें ताकि नए कमांड का ज़िक्र हो।
3. जानबूझकर कुछ तोड़ें (जैसे एक pool entry delete करें), npm test चलाएँ, और एजेंट को ठीक failure खिलाकर fix करवाने का अभ्यास करें।

---

आगे कहाँ जाएँ

• src/lockedin.js का असली कोड स्किम करें — अब आप उसकी बनावट जानते हैं।
• प्रोजेक्ट के अपने status और architecture नोट्स के लिए docs/HANDOFF.md पढ़ें।
• कमांड रेफरेंस में मज़ाक का आनंद लें।

यही ट्यूटोरियल है। अब आप एक AI एजेंट को एक test गेट के पीछे असली software बनाने और बदलने के लिए निर्देशित कर सकते हैं — कल्पनीय सबसे ज़्यादा आत्मविश्वासी उदाहरण के साथ। Agree? 👇