Tutorial 4 Prompting and Reviewing kn

ಟ್ಯುಟೋರಿಯಲ್ 4 · ಪ್ರಾಂಪ್ಟಿಂಗ್ ಮತ್ತು ರಿವ್ಯೂ

ಗುರಿ: ಮೆಟಾ-ಕೌಶಲ್ಯ. ನೀವು ಈಗ ಒಂದು ಏಜೆಂಟ್ ಜೊತೆ ಒಂದು feature ಕಟ್ಟಬಲ್ಲಿರಿ — ಈ ಅಧ್ಯಾಯ ಅದನ್ನು ಸುಗಮವಾಗಿ ಮತ್ತು ಪುನರಾವರ್ತಿಸಬಹುದಾಗಿ ಮಾಡುವ ಬಗ್ಗೆ: ಮೊದಲ ಬಾರಿಗೇ ಹೊಂದುವ prompt ಬರೆಯುವುದು, diff ಗಳನ್ನು ದಕ್ಷವಾಗಿ review ಮಾಡುವುದು, ವಿಷಯಗಳು ಎಡವಿದಾಗ iterate ಮಾಡುವುದು, ಮತ್ತು ಹಲವು session ಗಳ ಉದ್ದಕ್ಕೂ ವೇಗ ಉಳಿಸಿಕೊಳ್ಳುವುದು.

← ಹಿಂದಿನದು: ಟ್ಯುಟೋರಿಯಲ್ 3 ನಿಮ್ಮ ಮೊದಲ ಏಜೆಂಟ್ ಟಾಸ್ಕ್ · ಮುಂದೆ: ಟ್ಯುಟೋರಿಯಲ್ 5 ಲೋಕಲೈಸೇಶನ್

---

ಒಂದು search box ನಂತೆ ಅಲ್ಲ, ಒಬ್ಬ lead ನಂತೆ prompt ಮಾಡಿ

ಏಜೆಂಟ್ ಒಬ್ಬ ವೇಗದ, ಶಬ್ದಾರ್ಥದ, ಉತ್ಸಾಹಿ junior ಎಂಜಿನಿಯರ್. ಒಬ್ಬ ಒಳ್ಳೆಯ junior ಅನ್ನು ನೀವು ಹೇಗೆ lead ಮಾಡುತ್ತೀರೋ ಹಾಗೆಯೇ ಇದನ್ನೂ lead ಮಾಡಿ:

• ಗುರಿ ಮತ್ತು constraint ಗಳನ್ನು ಹೇಳಿ. "endorse ಸೇರಿಸು" ದುರ್ಬಲ. "connect pattern ಅನ್ನು follow ಮಾಡುತ್ತಾ endorse ಸೇರಿಸು, ಕೇವಲ seeded RNG, test ಗಳ ಜೊತೆ, ಗೇಟ್ ಹಸಿರಾಗಿ ಉಳಿಯುತ್ತದೆ" ಬಲಿಷ್ಠ. Constraint ಗಳೇ ನಿಮಗೆ ಹೊಂದುವ ಕೋಡ್ ಸಿಗುವ ಮಾರ್ಗ.
• ಉದಾಹರಣೆಗಳತ್ತ ತೋರಿಸಿ. "renderConnect ಬಳಸುವ pattern ಅನ್ನು follow ಮಾಡು" ಒಂದು ಪ್ಯಾರಾಗ್ರಾಫ್ ವಿವರಣೆಗಿಂತ ಉತ್ತಮ. ಅಸ್ತಿತ್ವದ ಕೋಡ್ ಅತ್ಯುತ್ತಮ spec.
• edit ಗಳ ಮೊದಲು ಒಂದು plan ಕೇಳಿ ಯಾವುದೇ non-trivial ವಿಷಯದ ಮೇಲೆ. ಒಂದು plan ಅನ್ನು redirect ಮಾಡುವುದು ಅಗ್ಗ; ಹತ್ತು edit ಆದ ಫೈಲ್‌ಗಳನ್ನು undo ಮಾಡುವುದು ದುಬಾರಿ.
• ಪ್ರತಿ prompt ಗೆ ಒಂದು task. "endorse ಸೇರಿಸು, RNG ಅನ್ನೂ refactor ಮಾಡು, README ಅನ್ನೂ update ಮಾಡು" ಎಂದು bundle ಮಾಡುವುದು review ಮಾಡಲು ಕಷ್ಟವಾದ ಜಟಿಲ diff ಕೊಡುತ್ತದೆ.
• ಅದಕ್ಕೆ test ಗೇಟ್ ಕೊಡಿ. "npm test ಚಲಾಯಿಸು ಮತ್ತು ಹಸಿರಾಗುವ ತನಕ ಅದನ್ನು ಮುಗಿದಿದೆ ಎಂದು ಪರಿಗಣಿಸಬೇಡ" ಎಂಬುದು ಏಜೆಂಟ್ ಅನ್ನು ತನ್ನ ಕೆಲಸವನ್ನು ತಾನೇ ಪರಿಶೀಲಿಸುವಂತಹದ್ದಾಗಿ ಮಾಡುತ್ತದೆ.

ಪ್ರತಿ ಬಾರಿ diff review ಮಾಡಿ

ವೇಗವೇ ಏಜೆಂಟ್‌ನ ಇಡೀ ಉದ್ದೇಶ — ಆದರೆ ಓದದ ವೇಗವೇ bug ಗಳು ship ಆಗುವ ಮಾರ್ಗ. ಒಂದು ವೇಗದ, ಸ್ಥಿರವಾದ review ಪ್ರತಿವರ್ತನೆ ಕಟ್ಟಿಕೊಳ್ಳಿ:

1. Scope: ಅದು ಬದಲಾಯಿಸಬೇಕಾದದ್ದನ್ನು ಮಾತ್ರ ಬದಲಾಯಿಸಿತೇ? ಸಂಬಂಧವಿಲ್ಲದೆ ಚಲಿಸಿದ ಸಾಲುಗಳು ಒಂದು smell.
2. Pattern ಗಳು: ಅದು ಸುತ್ತಲಿನ ಕೋಡ್‌ಗೆ ಹೊಂದುತ್ತದೆಯೇ, ಯಾವುದೇ ಹೊಸ dependency ಇಲ್ಲದೆ ಮತ್ತು src/ ಒಳಗೆ ಯಾವುದೇ I/O ಇಲ್ಲದೆ?
3. ಪ್ರಾಜೆಕ್ಟ್‌ನ ನಿಯಮಗಳು: ಈ repo ಗೆ, ಅದು ಕೇವಲ seeded RNG (diff ನಲ್ಲಿ Math.random grep ಮಾಡಿ), user-visible text language bundle ಗಳಲ್ಲಿ (hardcode ಅಲ್ಲ), ಮತ್ತು card ಸಾಲುಗಳು ಎಂದಿಗೂ layout pad ಮಾಡುವ width ಅನ್ನು ಮೀರುವುದಿಲ್ಲ.
4. Accessibility: ಹೊಸ output --accessible ನಲ್ಲಿ ಉಳಿಯುತ್ತದೆಯೇ? lockedin --accessible <your command> ಚಲಾಯಿಸಿ ಮತ್ತು ಅದು ಶುದ್ಧ plain text ಆಗಿ ಓದುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ — a11yFilter ದಾಟಿ ಯಾವುದೇ ಹೊಸ decorative glyph ನುಸುಳುತ್ತಿಲ್ಲ.
5. Test ಗಳು: ಒಂದು ಹೊಸ 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 column ಇರಬೇಕೆಂದು ನಿರೀಕ್ಷಿಸುತ್ತದೆ. test ಅನ್ನು ದುರ್ಬಲಗೊಳಿಸದೆ ಇದನ್ನು fix ಮಾಡು."

ನಿಜವಾದ error text paste ಮಾಡಿ. "ಇದು ಮುರಿದಿದೆ" ಎಂಬುದು ಏಜೆಂಟ್‌ಗೆ ಊಹಿಸಲು ಬಿಡುತ್ತದೆ; stack trace ಅದಕ್ಕೆ fix ಮಾಡಿಸುತ್ತದೆ. ಮತ್ತು ಹೊಸದಾಗಿ ಆರಂಭಿಸುವ ಬದಲು ಅದೇ conversation ಮುಂದುವರಿಸಲು ಆದ್ಯತೆ ನೀಡಿ — ಏಜೆಂಟ್‌ಗೆ ಅದು ಈಗಷ್ಟೇ ಬರೆದದ್ದರ context ಈಗಾಗಲೇ ಇದೆ. ಎರಡು-ಮೂರು iteration ಗಳು converge ಆಗದಿದ್ದರೆ, ಹಿಂದೆ ಸರಿದು re-scope ಮಾಡಿ: task ಒಂದು prompt ಗೆ ಬಹುಶಃ ತುಂಬಾ ದೊಡ್ಡದಿರಬಹುದು.

session ಗಳ ಉದ್ದಕ್ಕೂ ವೇಗ ಉಳಿಸಿಕೊಳ್ಳಿ

ನಿಜವಾದ ಕೆಲಸ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕೂರುವಿಕೆಗಳಲ್ಲಿ ಹರಡುತ್ತದೆ. ಎರಡು ಅಭ್ಯಾಸಗಳು ಏಜೆಂಟ್ ಅನ್ನು ಕಾಲಾಂತರದಲ್ಲಿ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಇಡುತ್ತವೆ:

• Memory / convention ಗಳು. ನಿಮ್ಮ ಏಜೆಂಟ್ ಬಾಳಿಕೆಯ 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 ಇಡಲು ಏಜೆಂಟ್‌ಗೆ ಹೇಳಿ.

ಇಟ್ಟುಕೊಳ್ಳಲು ಯೋಗ್ಯ Guardrail ಗಳು

• ಗೇಟ್ ರಾಜಿ ಇಲ್ಲದ್ದು. ಏನೂ ship ಆಗುವ ಮೊದಲು ಹಸಿರು test ಗಳು. ಇದೇ ನಿಮಗೆ ವೇಗವಾಗಿ ಚಲಿಸಲು ಮತ್ತು output ಅನ್ನು ನಂಬಲು ಬಿಡುತ್ತದೆ.
• ನೀವೇ ದಾಖಲೆಯ reviewer. ಏಜೆಂಟ್ ಬರೆಯುತ್ತದೆ; ನೀವು ನಿರ್ಧರಿಸುತ್ತೀರಿ. ಒಂದು diff ಅನ್ನು ಸ್ವೀಕರಿಸುವುದೆಂದರೆ ನೀವು ಅದಕ್ಕೆ ಜವಾಬ್ದಾರರಾಗುತ್ತೀರಿ.
• ಚಿಕ್ಕ, verifiable ಹೆಜ್ಜೆಗಳು ಒಂದು ದೈತ್ಯ ನೆಗೆತಕ್ಕಿಂತ ಉತ್ತಮ. ಪ್ರತಿ ಸ್ವೀಕೃತ ಬದಲಾವಣೆ ಆ್ಯಪ್ ಅನ್ನು ಕೆಲಸ ಮಾಡುವ ಸ್ಥಿತಿಯಲ್ಲಿ ಬಿಡಬೇಕು.

---

✅ ನಿಮ್ಮ ಏಜೆಂಟ್ ಜೊತೆ ಪ್ರಯತ್ನಿಸಿ

1. ಒಂದು mentor ಕಮಾಂಡ್ ("ಕೇಳದ ಸಲಹೆಯನ್ನು ಹಂಚುತ್ತದೆ") ಗಾಗಿ ಒಂದು-ಪ್ಯಾರಾಗ್ರಾಫ್ spec ಬರೆಯಿರಿ, constraint ಗಳ ಸಹಿತ, ಮತ್ತು ಏಜೆಂಟ್‌ನಿಂದ ಅದನ್ನು test-first ರೀತಿಯಲ್ಲಿ ಕಟ್ಟಿಸಿ — plan, test ಗಳು, code, ಗೇಟ್ — ಪ್ರತಿ ಹಂತದಲ್ಲೂ review ಮಾಡುತ್ತಾ.
2. ಏಜೆಂಟ್‌ಗೆ docs/HANDOFF.md ಅನ್ನು update ಮಾಡಲು ಹೇಳಿ ಇದರಿಂದ ಹೊಸ ಕಮಾಂಡ್ ಉಲ್ಲೇಖವಾಗುತ್ತದೆ.
3. ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಏನಾದರೂ ಮುರಿಯಿರಿ (ಉದಾ. ಒಂದು pool entry delete ಮಾಡಿ), npm test ಚಲಾಯಿಸಿ, ಮತ್ತು ಏಜೆಂಟ್‌ಗೆ ನಿಖರ failure ಅನ್ನು ಕೊಟ್ಟು fix ಮಾಡಿಸುವ ಅಭ್ಯಾಸ ಮಾಡಿ.

---

ಮುಂದೆ ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕು

• src/lockedin.js ನ ನಿಜವಾದ ಕೋಡ್ ಅನ್ನು skim ಮಾಡಿ — ನೀವು ಈಗ ಅದರ ಆಕಾರ ತಿಳಿದಿದ್ದೀರಿ.
• ಪ್ರಾಜೆಕ್ಟ್‌ನ ಸ್ವಂತ status ಮತ್ತು architecture ಟಿಪ್ಪಣಿಗಳಿಗಾಗಿ docs/HANDOFF.md ಅನ್ನು ಓದಿ.
• ಕಮಾಂಡ್ ರೆಫರೆನ್ಸ್ ನಲ್ಲಿ ತಮಾಷೆಗಳನ್ನು ಆನಂದಿಸಿ.

ಅದೇ ಟ್ಯುಟೋರಿಯಲ್. ನೀವು ಈಗ ಒಂದು AI ಏಜೆಂಟ್‌ಗೆ ಒಂದು test ಗೇಟ್‌ನ ಹಿಂದೆ ನಿಜವಾದ software ಕಟ್ಟಲು ಮತ್ತು ಬದಲಾಯಿಸಲು ನಿರ್ದೇಶಿಸಬಲ್ಲಿರಿ — ಊಹಿಸಬಹುದಾದ ಅತ್ಯಂತ ಅತಿ-ಆತ್ಮವಿಶ್ವಾಸದ ಉದಾಹರಣೆಯೊಂದಿಗೆ. Agree? 👇