ಪ್ರಾಂಪ್ಟ್‌ಗಳು ಕೇವಲ ಸಲಹೆಗಳಿದ್ದಂತೆ. ಹುಕ್‌ಗಳು ಕಠಿಣ ನಿರ್ಬಂಧಗಳಿದ್ದಂತೆ.

ತಿಂಗಳುಗಟ್ಟಲೆ, ನಾನು Claude Code ಅನ್ನು ಕೇವಲ ಸ್ಪಷ್ಟವಾದ ನಿಯಮಗಳ ಅಗತ್ಯವಿರುವ ಒಬ್ಬ ಜೂನಿಯರ್ ಡೆವಲಪರ್‌ನಂತೆ ಪರಿಗಣಿಸಿದೆ. ನನ್ನ ಪ್ರಾಜೆಕ್ಟ್ ಸೂಚನೆಗಳು ಸ್ಪಷ್ಟವಾಗಿದ್ದವು: ಎಂದಿಗೂ force-push ಮಾಡಬೇಡ, ಎಂದಿಗೂ ಬ್ರಾಂಚ್‌ಗಳನ್ನು (branches) ಡಿಲೀಟ್ ಮಾಡಬೇಡ, ಎಂದಿಗೂ ವಿನಾಶಕಾರಿ ಕಮಾಂಡ್‌ಗಳನ್ನು (destructive commands) ರನ್ ಮಾಡಬೇಡ. ಹೆಚ್ಚಿನ ಸಂಜೆಗಳಲ್ಲಿ, ಅದು ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು. ಏಜೆಂಟ್ ಟೆಸ್ಟ್‌ಗಳನ್ನು ಬರೆಯುತ್ತಿತ್ತು, ಫಂಕ್ಷನ್‌ಗಳನ್ನು ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡುತ್ತಿತ್ತು ಮತ್ತು ಗಿಟ್ ಇತಿಹಾಸಕ್ಕೆ (git history) ತೊಂದರೆ ಕೊಡುತ್ತಿರಲಿಲ್ಲ. ನಂತರ ಒಂದು rebase ಪ್ರಕ್ರಿಯೆ ತಪ್ಪಾಗಿ ನಡೆಯಿತು.

Context window ಪೂರ್ಣವಾಗಿ git error outputಗಳಿಂದ ತುಂಬಿಹೋಯಿತು. Conflict markers, detached HEAD ಸಂದೇಶಗಳು ಮತ್ತು branch divergence ಎಚ್ಚರಿಕೆಗಳು ಒಂದರ ನಂತರ ಒಂದರಂತೆ ಟೋಕನ್‌ಗಳ ರೂಪದಲ್ಲಿ ಸಂಗ್ರಹವಾದವು. ಆ ಗದ್ದಲದ ಅಡಿಯಲ್ಲಿ, force-push ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸುವ ನನ್ನ ವಿನಯಪೂರ್ವಕ ಸೂಚನೆಯೂ ಹೂತುಹೋಗಿತ್ತು. ಮಾಡೆಲ್‌ಗೆ, ಆ ಥ್ರೆಡ್‌ನಲ್ಲಿನ ಅತ್ಯಂತ ಇತ್ತೀಚಿನ ಮತ್ತು ಪ್ರಮುಖವಾದ ಪಠ್ಯವೆಂದರೆ ಆ error stream ಆಗಿತ್ತು. ಸಾಂಖ್ಯಿಕ ಗಮನವು (Statistical attention) ನೀತಿಯನ್ನು ಮೀರಿಸಿತು. ಏಜೆಂಟ್ ಎರಡು ಗಂಟೆಗಳ ಕಾಲ ಕಮಿಟ್ ಮಾಡದ ಸ್ಥಳೀಯ ಬದಲಾವಣೆಗಳನ್ನು (uncommitted local changes) ಅಳಿಸಿಹಾಕುವ ಕಮಾಂಡ್ ಅನ್ನು ಚಲಾಯಿಸಿತು. ಅದು ದುರುದ್ದೇಶಪೂರಿತವಾಗಿ ಮಾಡಿದ್ದಲ್ಲ; ಅದು ಕೇವಲ ಗಮನ ವಿಚಲಿತಗೊಂಡಿತ್ತು ಅಷ್ಟೆ. ಆ ವ್ಯತ್ಯಾಸ ಬಹಳ ಮುಖ್ಯವಾದುದು. ಒಂದು LLM ದ್ವೇಷದಿಂದ ನಿಯಮಗಳನ್ನು ಮುರಿಯುವುದಿಲ್ಲ. context window ನಲ್ಲಿನ ಹೆಚ್ಚು ಪ್ರಬಲವಾದ ಪ್ಯಾಟರ್ನ್ ಹಿಂದಿನ ಸೂಚನೆಯನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ಮೀರಿಸಿದಾಗ ಅದು ನಿಯಮಗಳನ್ನು ಮುರಿಯುತ್ತದೆ.

ಆ ಘಟನೆಯು ಏಜೆಂಟ್ ಸುರಕ್ಷತೆಯ (agent safety) ಬಗ್ಗೆ ನನ್ನ ಆಲೋಚನೆಯನ್ನು ಬದಲಿಸಿತು. ತೊಂಬತ್ತೊಂಬತ್ತು ಪ್ರತಿಶತ ಸಮಯ ಕೆಲಸ ಮಾಡುವ ಗಾರ್ಡ್‌ರೈಲ್ ಒಂದು ಹೊರೆ ಅಥವಾ ಅಪಾಯಕಾರಿ ಅಂಶವಾಗಬಹುದು. ಒಂದು ವೇಳೆ ಆ ವೈಫಲ್ಯವು ನಿಮ್ಮ ಸಮಯ, ಹಣ ಅಥವಾ ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುವಂತೆ ಮಾಡಿದರೆ, ನೀವು ಅದನ್ನು ಕೇವಲ ಪ್ರಾಂಪ್ಟ್‌ನೊಳಗೆ ಬಿಟ್ಟುಬಿಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ನೀವು ಮಾಡೆಲ್‌ನ ತರ್ಕದ ಲೂಪ್‌ನ ಹೊರಗೆ ಒಂದು ಜಾರಿ ವ್ಯವಸ್ಥೆಯನ್ನು (enforcement) ಹೊಂದಿರಲೇಬೇಕು.

Claude Code hooks ಇದನ್ನು ನಿಖರವಾಗಿ ಪರಿಹರಿಸುತ್ತವೆ. ಇವು ಮೂರು ನಿರ್ದಿಷ್ಟ ಕ್ಷಣಗಳಲ್ಲಿ ಟೂಲ್ ಕರೆಗಳನ್ನು (tool calls) ಅಡ್ಡಗಟ್ಟುವ ಸಣ್ಣ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಾಗಿವೆ: ಟೂಲ್ ಕಾರ್ಯಗತಗೊಳ್ಳುವ ಮೊದಲು (PreToolUse), ಟೂಲ್ ಮುಗಿದ ನಂತರ (PostToolUse), ಮತ್ತು ಏಜೆಂಟ್ ತನ್ನ ಕೆಲಸ ಮುಗಿದಿದೆ ಎಂದು ನಿರ್ಧರಿಸಿದಾಗ (Stop). ಇವು ಬಾಹ್ಯ ಕೋಡ್ ಆಗಿ ಚಲಿಸುವುದರಿಂದ, ಇವು ಮಾಡೆಲ್‌ನ ನೆನಪು, ಮೂಡ್ ಅಥವಾ context ಒತ್ತಡದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವುದಿಲ್ಲ. ಮಾಡೆಲ್ ನೀವು ನೀಡಿದ ಪ್ರತಿಯೊಂದು ಸೂಚನೆಯನ್ನು ಮರೆತರೂ; ಹುಕ್ ಇಂದಿಗೂ "ಇಲ್ಲ" ಎಂದು ಹೇಳಬಲ್ಲದು.

ಆ ಕಳೆದುಹೋದ ಸಂಜೆಯ ನಂತರ ನಾನು ನಿರ್ಮಿಸಿದ ಹಾರ್ನೆಸ್ (harness) ಇಲ್ಲಿದೆ.

ಗಾರ್ಡ್ ಹುಕ್: ಹಾನಿಯಾಗುವ ಮೊದಲು ತಡೆಗಟ್ಟು

ನನ್ನ PreToolUse hook ಪ್ರತಿ Bash ಕಮಾಂಡ್ ಅನ್ನು ಶೆಲ್ ಸ್ಪರ್ಶಿಸುವ ಮೊದಲು ಪರಿಶೀಲಿಸುತ್ತದೆ. ನಾನು ವಿನಾಶಕಾರಿ ಪ್ಯಾಟರ್ನ್‌ಗಳಿಗಾಗಿ ಒಂದು ಕಟ್ಟುನಿಟ್ಟಾದ denylist ಅನ್ನು ಇಟ್ಟುಕೊಂಡಿದ್ದೇನೆ. ಕಮಾಂಡ್ ಸ್ಟ್ರಿಂಗ್ ಯಾವುದಾದರೂ ಅಪಾಯಕಾರಿ ಅಂಶಕ್ಕೆ ಹೊಂದಿಕೆಯಾದರೆ, ಹುಕ್ ಕಾರ್ಯಗತಗೊಳಿಸುವುದನ್ನು ರದ್ದುಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ನೇರವಾಗಿ ಏಜೆಂಟ್‌ಗೆ ಎರರ್ ಸಂದೇಶವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

ನಾನು ತಡೆಯುವ ಪ್ಯಾಟರ್ನ್‌ಗಳು ಸರಳ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿವೆ:

  • git push --force ಅಥವಾ ನಾನು ಇನ್ನೂ ನಂಬದ ಯಾವುದೇ force-with-lease ರೂಪಾಂತರಗಳು
  • git reset --hard
  • rm -rf

ಇದು ಅತ್ಯಾಧುನಿಕ ಭದ್ರತಾ ಸಂಶೋಧನೆಯಲ್ಲ. ಇದು ಕೇವಲ ಒಂದು ಸೀಟ್‌ಬೆಲ್ಟ್ ಇದ್ದಂತೆ. ಆದರೆ ಇಲ್ಲಿನ ನಿರ್ಣಾಯಕ ಅಂಶವೆಂದರೆ ಬ್ಲಾಕ್ ಆದ ನಂತರ ಏನಾಗುತ್ತದೆ ಎಂಬುದು.

ನಾನು ಎಂದಿಗೂ ಕೇವಲ "Blocked" ಎಂದು ಕಠಿಣವಾಗಿ ಹೇಳುವುದಿಲ್ಲ. ಕೇವಲ ನಿರಾಕರಣೆಯು ಏಜೆಂಟ್ ಅನ್ನು ಗೊಂದಲಕ್ಕೀಡುಮಾಡಿ, ಅದೇ ವಿನಾಶಕಾರಿ ಕಮಾಂಡ್‌ನ ವಿವಿಧ ರೂಪಗಳನ್ನು ಪ್ರಯತ್ನಿಸುವ ಲೂಪ್‌ನಲ್ಲಿ ಸಿಲುಕಿಸಬಹುದು. ಬದಲಾಗಿ, ಎರರ್ ಸಂದೇಶವು ಒಂದು ಪರ್ಯಾಯ ಮಾರ್ಗವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಹುಕ್ ಒಂದು hard reset ಅನ್ನು ಪತ್ತೆಹಚ್ಚಿದಾಗ, ಅದು ಏಜೆಂಟ್‌ಗೆ ಹೀಗೆ ಹೇಳುತ್ತದೆ: "ಅನ್‌ಕಮಿಟ್ ಮಾಡಲಾದ ಕೆಲಸವನ್ನು ರಕ್ಷಿಸಲು ಈ ಕಮಾಂಡ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ. ಮೊದಲು ಒಂದು ಚೆಕ್‌ಪಾಯಿಂಟ್ ಕಮಿಟ್ ಮಾಡಿ, ನಂತರ ಮರುಪರಿಶೀಲಿಸಿ." ಆ ಒಂದು ಹೆಚ್ಚುವರಿ ವಾಕ್ಯವು ಏಜೆಂಟ್‌ನ ನಡವಳಿಕೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸುತ್ತದೆ. ಅದು ಹಾನಿಯನ್ನು ತಡೆಯುವ ಪ್ರಯತ್ನದಿಂದ ಸುರಕ್ಷತೆಯನ್ನು ನಿರ್ಮಿಸುವತ್ತ ತಿರುಗುತ್ತದೆ. ಹುಕ್ ಕೇವಲ ಗೋಡೆಯಲ್ಲ; ಅದು ಟ್ರಾಫಿಕ್ ನಿಯಂತ್ರಣದಂತೆ.

ನಾನು ಶೆಲ್ ಕಮಾಂಡ್‌ಗಳಿಗಾಗಿ allowlist ಗಿಂತ denylist ಅನ್ನು ಆರಿಸಿಕೊಂಡೆ. ಮೊದಲಿಗೆ, ನಾನು ಕೇವಲ ಸುರಕ್ಷಿತವಾದ git ಸಬ್-ಕಮಾಂಡ್‌ಗಳ ಗುಂಪನ್ನು ಮಾತ್ರ ಅನುಮತಿಸುವುದನ್ನು ಪರಿಗಣಿಸಿದೆ. ಆದರೆ ಅದು ಬೇಗನೆ ವಿಫಲವಾಯಿತು. ಏಜೆಂಟ್‌ಗಳು ಸೃಜನಾತ್ಮಕವಾಗಿ ಅಕ್ಷರಶಃ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಅವು ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಲು git stash push -m "wip" ಅಥವಾ git branch --show-current ನಂತಹ ಕಾನೂನುಬದ್ಧ ಆದರೆ ಅನಿರೀಕ್ಷಿತ ಕಮಾಂಡ್‌ಗಳನ್ನು ರನ್ ಮಾಡುತ್ತವೆ. ಮಾಡೆಲ್ ಒಂದು ಮಾನ್ಯವಾದ ಆದರೆ ಪಟ್ಟಿಯಲ್ಲಿಲ್ಲದ ಕಮಾಂಡ್ ಅನ್ನು ಕಂಡುಹಿಡಿದ ತಕ್ಷಣ an allowlist ಸಾಮಾನ್ಯ ಕೆಲಸದ ಹರಿವನ್ನು (workflow) ಹಾಳುಮಾಡುತ್ತದೆ. ನಿಜವಾದ ವಿನಾಶಕಾರಿ ಪ್ಯಾಟರ್ನ್‌ಗಳ ಸಣ್ಣ, ಪರಿಷ್ಕೃತ denylist ಏಜೆಂಟ್‌ಗೆ ಕೆಲಸ ಮಾಡಲು ಅವಕಾಶ ನೀಡುತ್ತಾ ಗಡಿಗಳನ್ನು ರಕ್ಷಿಸುತ್ತದೆ.

ಫಾರ್ಮ್ಯಾಟರ್ ಹುಕ್: ಕೆಲಸದ ಒತ್ತಡವನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿ

"ಫೈಲ್ ಎಡಿಟ್ ಮಾಡಿದ ನಂತರ ಯಾವಾಗಲೂ ಫಾರ್ಮ್ಯಾಟರ್ ಅನ್ನು ರನ್ ಮಾಡಿ" ಎಂದು ಏಜೆಂಟ್‌ಗೆ ಹೇಳಲು ನಾನು ಪ್ರಾಂಪ್ಟ್ ಟೋಕನ್‌ಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತಿದ್ದೆ. ಅದು ಅರ್ಧದಷ್ಟು ಸಮಯ ಮರೆತುಬಿಡುತ್ತಿತ್ತು. ಉಳಿದ ಅರ್ಧದಷ್ಟು ಸಮಯ, ಅದು ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಬೇಕೇ ಎಂದು ಕೇಳುತ್ತಾ ನಿಲ್ಲುತ್ತಿತ್ತು, ಇದರಿಂದ ಕೇವಲ ಒಂದು ಸರಿಯಾದ ಉತ್ತರವಿರುವ ನಿರ್ಧಾರಕ್ಕಾಗಿ ಒಂದು ಟೂಲ್ ಕರೆಯನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತಿತ್ತು.

ಈಗ ನಾನು ಅದನ್ನು PostToolUse hook ಮೂಲಕ ನಿರ್ವಹಿಸುತ್ತೇನೆ. ಏಜೆಂಟ್ ಫೈಲ್ ಅನ್ನು ಎಡಿಟ್ ಮಾಡಿದ ನಂತರ, ಹುಕ್ ಫೈಲ್ ಎಕ್ಸ್‌ಟೆನ್ಶನ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಅದು Python ಆಗಿದ್ದರೆ, ಅದು Ruff ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ. ಅದು JavaScript ಅಥವಾ TypeScript ಆಗಿದ್ದರೆ, ಅದು Prettier ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ. ಅದು Go ಆಗಿದ್ದರೆ, ಅದು gofmt ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ. ಫಾರ್ಮ್ಯಾಟರ್ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂಬುದು ಏಜೆಂಟ್‌ಗೆ ತಿಳಿಯಬೇಕಿಲ್ಲ. ಅದಕ್ಕೆ ಅದರ ಅಗತ್ಯವೂ ಇಲ್ಲ.

ಇದನ್ನು ಪ್ರಾಂಪ್ಟ್‌ನಿಂದ ಹೊರಗೆ ತರುವುದರಿಂದ ಎರಡು ಪರಿಣಾಮಗಳಾದವು. ಮೊದಲನೆಯದಾಗಿ, ಮಾಡೆಲ್‌ಗೆ ಹೆಚ್ಚಿನ ಮಾನಸಿಕ ಹೊರೆ ನೀಡದೆ ಕೋಡ್ ಸ್ಥಿರವಾಗಿ ಸ್ವಚ್ಛವಾಗಿರುತ್ತದೆ. ಎರಡನೆಯದಾಗಿ, ನನ್ನ ಪ್ರಾಜೆಕ್ಟ್ ಸೂಚನೆಗಳು ಚಿಕ್ಕದಾದವು. ಪ್ರಾಂಪ್ಟ್‌ನಿಂದ ನೀವು ತೆಗೆದುಹಾಕುವ ಪ್ರತಿಯೊಂದು "always" ಮತ್ತು "never" ಎಂಬುದು ಮಾಡೆಲ್ ನಿಜವಾದ ಸಮಸ್ಯೆ ಪರಿಹರಿಸಲು ಬಳಸಬಹುದಾದ ಒಂದು ಟೋಕನ್ ಆಗುತ್ತದೆ. ಹುಕ್ ಸ್ಥಿರತೆಯನ್ನು (invariant) ಹೊಂದಿದ್ದರೆ; ಪ್ರಾಂಪ್ಟ್ ಉದ್ದೇಶವನ್ನು (intent) ಹೊಂದಿರುತ್ತದೆ.

ಕ್ವಾಲಿಟಿ ಗೇಟ್: "ಮುಗಿದಿದೆ" ಎಂಬುದನ್ನು ಮರು ವ್ಯಾಖ್ಯಾನಿಸುವುದು

ಏಜೆಂಟ್ ತನ್ನ ಕೆಲಸ ಮುಗಿದಿದೆ ಎಂದು ನಿರ್ಧರಿಸಿ ಸೆಷನ್ ಅನ್ನು ಕೊನೆಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ Stop hook ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನಾನು ಅದನ್ನು ಹಾಗೆಯೇ ಬಿಡುವುದಿಲ್ಲ. ಬದಲಾಗಿ, ಆ hook ಸಂಪೂರ್ಣ ಟೆಸ್ಟ್ ಸೂಟ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ. ಯಾವುದೇ ಟೆಸ್ಟ್ ವಿಫಲವಾದರೆ, hook ನಿಲ್ಲಿಸುವ ಕಮಾಂಡ್ ಅನ್ನು ತಡೆಯುತ್ತದೆ ಮತ್ತು ವಿಫಲತೆಯ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಏಜೆಂಟ್‌ಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

ಇದು ಪೂರ್ಣಗೊಂಡಿಕೆಯ (completion) ವ್ಯಾಖ್ಯಾನವನ್ನೇ ಬದಲಾಯಿಸುತ್ತದೆ. “Done” ಎಂಬುದು ಕೇವಲ ಮಾಡೆಲ್‌ಗೆ ಆಗುವ ಭಾವನೆಯಲ್ಲ; ಅದು ಅಳೆಯಬಹುದಾದ ಒಂದು ಮೈಲಿಗಲ್ಲು (measurable gate). harness ಕೋಡ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿದಾಗ ಮಾತ್ರ ಏಜೆಂಟ್ ಕೆಲಸವನ್ನು ಮುಗಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಇದು ಒಂದು ಬಿಗಿಯಾದ ಫೀಡ್‌ಬ್ಯಾಕ್ ಲೂಪ್ ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಏಜೆಂಟ್ ಕೋಡ್ ಬರೆಯುತ್ತದೆ, ಅದು ಮುಗಿದಿದೆ ಎಂದು ಭಾವಿಸುತ್ತದೆ, ಸ್ಟಾಪ್ ಬಟನ್ ಒತ್ತುತ್ತದೆ ಮತ್ತು ತಕ್ಷಣವೇ pytest traceback ಅನ್ನು ನೋಡುತ್ತದೆ. ನಂತರ ಅದು ತಾನೇ ತಪ್ಪುಗಳನ್ನು ಸರಿಪಡಿಸಿಕೊಳ್ಳುತ್ತದೆ (self-corrects), ಇಂಪೋರ್ಟ್ ಎರರ್ ಅಥವಾ ತಪ್ಪಾದ ಅಸರ್‌ಷನ್ ಅನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ ಮತ್ತು ಮತ್ತೆ ನಿಲ್ಲಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಮಾನವ ಹಸ್ತಕ್ಷೇಪವಿಲ್ಲದೆ ಏಜೆಂಟ್‌ಗಳು ಈ ಲೂಪ್‌ನಲ್ಲಿ ಮೂರು ಅಥವಾ ನಾಲ್ಕು ಬಾರಿ ಪುನರಾವರ್ತನೆಯಾಗುವುದನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ. harness ಗುಣಮಟ್ಟವನ್ನು ಕಾಯ್ದುಕೊಳ್ಳುತ್ತದೆ; ಮಾಡೆಲ್ ಪ್ಯಾಚ್‌ಗಳನ್ನು (patches) ಒದಗಿಸುತ್ತದೆ.

ಇದು ಏಜೆಂಟ್ ಇಂಜಿನಿಯರಿಂಗ್ ಬಗ್ಗೆ ಏನು ಕಲಿಸುತ್ತದೆ

ವಿಶ್ವಾಸಾರ್ಹ ಸ್ವಾಯತ್ತ ವ್ಯವಸ್ಥೆಗಳನ್ನು (autonomous systems) ನಿರ್ಮಿಸಲು ಮನಸ್ಥಿತಿಯಲ್ಲಿ ಬದಲಾವಣೆ ಅಗತ್ಯವಿದೆ. ನೀವು ದೀರ್ಘವಾದ ಪ್ರಾಂಪ್ಟ್‌ಗಳನ್ನು ಬರೆಯುವುದರಿಂದ ಬಿಟ್ಟು, ಹೆಚ್ಚು ಬಿಗಿಯಾದ harnesses ನಿರ್ಮಿಸುವುದರ ಕಡೆಗೆ ಗಮನ ಹರಿಸಬೇಕು.

ನಿಯಮಗಳ ಜಾರಿಗೆ (enforcement) hooks ಬಳಸಿ ಮತ್ತು ನೀತಿಗಳಿಗಾಗಿ (policy) prompts ಬಳಸಿ. ಒಂದು ನಿಯಮವು ನೂರಕ್ಕೆ ನೂರು ರಷ್ಟು ಸಮಯವೂ ಅನ್ವಯವಾಗಬೇಕಿದ್ದರೆ, ಅದು ಕೋಡ್‌ನಲ್ಲಿರಬೇಕೇ ಹೊರತು ನೈಸರ್ಗಿಕ ಭಾಷೆಯಲ್ಲಿಲ್ಲ. ಪ್ರಾಂಪ್ಟ್‌ಗಳು ಅಸ್ಪಷ್ಟತೆ (ambiguity), ರುಚಿ (taste) ಮತ್ತು ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಆದರೆ ಅವು ಇನ್ವೇರಿಯಂಟ್ಸ್ (invariants) ವಿಷಯದಲ್ಲಿ ಅಸಮರ್ಥವಾಗಿರುತ್ತವೆ. ಒಂದು ತಪ್ಪಿನಿಂದಾಗಿ ನಿಮ್ಮ ಮಧ್ಯಾಹ್ನದ ಸಮಯ ವ್ಯರ್ಥವಾದರೆ ಅಥವಾ ಅದಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿ, ಪ್ರೊಡಕ್ಷನ್ ಅಪ್‌ಟೈಮ್ (production uptime) ಕುಂಠಿತಗೊಂಡರೆ, ತಕ್ಷಣವೇ ಒಂದು hook ಬರೆಯಿರಿ.

ಚಿಕ್ಕ ಪ್ರಾಂಪ್ಟ್‌ಗಳು ಉತ್ತಮ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತವೆ. ನೀವು ಯಾಂತ್ರಿಕ ನಿಯಮಗಳನ್ನು (mechanical rules) ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಿಗೆ ವರ್ಗಾಯಿಸಿದಾಗ, ಮಾಡೆಲ್ ನೆನಪಿಟ್ಟುಕೊಳ್ಳಬೇಕಾದ ವಿಷಯಗಳು ಮತ್ತು ವಿರೋಧಿಸಬೇಕಾದ ವಿಷಯಗಳು ಕಡಿಮೆಯಾಗುತ್ತವೆ. ಏಜೆಂಟ್‌ನ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋ (context window) ಒಂದು ಅಪರೂಪದ ಸಂಪನ್ಮೂಲವಾಗಿದೆ. ಅದನ್ನು ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ನೆನಪಿಸುವಿಕೆಗಳೊಂದಿಗೆ ತುಂಬಬೇಡಿ.

ಕೊನೆಯದಾಗಿ, ನಿಮ್ಮ ಪಾತ್ರ ಬದಲಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಿ. ಏಜೆಂಟ್‌ಗಳು ಸ್ವಾಯತ್ತತೆಯನ್ನು (autonomy) ಪಡೆಯುತ್ತಿದ್ದಂತೆ, ಮನುಷ್ಯನ ಕೆಲಸವು ಕಂಟೆಂಟ್ ತಯಾರಿಸುವುದರಿಂದ ಗಾರ್ಡ್‌ರೈಲ್ಸ್‌ಗಳನ್ನು (guardrails) ವಿನ್ಯಾಸಗೊಳಿಸುವುದಕ್ಕೆ ಬದಲಾಗುತ್ತದೆ. ಮಾಡೆಲ್ ಏನನ್ನು ಮುಟ್ಟಬಹುದು, ಅದು ಯಾವಾಗ ಮುಗಿಸಬಹುದು ಮತ್ತು ತಪ್ಪುಗಳು ಸಂಭವಿಸಿದಾಗ ಅದು ಹೇಗೆ ವರ್ತಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ harness ಅನ್ನು ನೀವು ನಿರ್ಮಿಸುತ್ತಿದ್ದೀರಿ. ಅದು ಇಂಜಿನಿಯರಿಂಗ್, ಕೇವಲ ಪ್ರಾಂಪ್ಟಿಂಗ್ ಅಲ್ಲ.

ಈ ವಿಧಾನಕ್ಕೆ ಪ್ರೇರಣೆ ನೀಡಿದ ಮೂಲ ಮತ್ತು ಹೆಚ್ಚಿನ ಅನುಷ್ಠಾನದ ವಿವರಗಳನ್ನು ಇಲ್ಲಿ ಕಾಣಬಹುದು.

ನೀವು AI ಏಜೆಂಟ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ ಮತ್ತು ಇತರ ಪರಿಣಿತರೊಂದಿಗೆ ವಿಚಾರ ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಲು ಬಯಸಿದರೆ, GyaanSetu ಕಲಿಕಾ ಸಮುದಾಯವನ್ನು ಇಲ್ಲಿ ಕಾಣಬಹುದು.