ಪರೀಕ್ಷೆಯು ಏಕೆ ಮುಖ್ಯ

AI-ಚಾಲಿತ ಕೋಡ್ ಅಸಿಸ್ಟೆಂಟ್‌ಗಳು ಹೆಚ್ಚಾಗಿ ತಂಡಗಳು ರೆಪೊದಲ್ಲಿ (repo) ಒಂದು “rules” ಫೈಲ್ ಅನ್ನು ಇರಿಸಲು ಮತ್ತು ಪ್ರತಿ ವಿನಂತಿಯಲ್ಲೂ (request) ಮಾದರಿಯು ಅದರ ನಿರ್ದೇಶನಗಳನ್ನು ಪಾಲಿಸುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸುತ್ತವೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಮಾದರಿಯು ಆ ಫೈಲ್ ಅನ್ನು ಎಂದಿಗೂ ನೋಡದೇ ಇರಬಹುದು ಅಥವಾ ನೋಡಿದರೂ ಅದರ ಒಳಗಿರುವ ವಿಷಯಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದು. Claude Code ನೊಂದತ್ತ ಇತ್ತೀಚಿನ ಪ್ರಯೋಗವು ಈ ಎರಡೂ ಸಮಸ್ಯೆಗಳನ್ನು ತೋರಿಸಿದೆ. ಆ ಸಾಧನವು 72 KB AGENTS.md ಫೈಲ್ ಅನ್ನು ಮೌನವಾಗಿ ಬಿಟ್ಟುಬಿಟ್ಟಿತು; ಅದೇ ಫೈಲ್ ಅನ್ನು CLAUDE.md ಎಂದು ಮರುನಾಮಕರಣ ಮಾಡಿದಾಗ, ಅಸಿಸ್ಟೆಂಟ್ ಅದನ್ನು ಲೋಡ್ ಮಾಡಿತು ಮತ್ತು ಪ್ರತಿ ವಿನಂತಿಗಾಗಿ ಟೋಕನ್ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಿತು. ಆ ಹೆಚ್ಚುವರಿ ಟೋಕನ್ ಬಜೆಟ್ ಲ್ಯಾಟೆನ್ಸಿ (latency) ಮತ್ತು ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಮತ್ತು ವಿನಂತಿಯನ್ನು ಮಾದರಿಯ ಮಿತಿಗಿಂತ (limit) ಹೆಚ್ಚು ಮಾಡಬಹುದು.

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

ಕೇಳಬೇಕಾದ ಮೂರು ಪ್ರಶ್ನೆಗಳು

  1. Configured – ಅಸಿಸ್ಟೆಂಟ್ ಹುಡುಕುವ ಜಾಗದಲ್ಲಿ ಫೈಲ್ ಅನ್ನು ಇರಿಸಲಾಗಿದೆಯೇ? ವಿವಿಧ ಸಾಧನಗಳು ಪಥಗಳನ್ನು (paths) ಅಥವಾ ಫೈಲ್ ಹೆಸರಿನ ಸಂಪ್ರದಾಯಗಳನ್ನು ಹಾರ್ಡ್-ಕೋಡ್ ಮಾಡಲಾಗಿರುತ್ತವೆ; ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿದ್ದರೆ ಫೈಲ್ ಪ್ರಾಂಪ್ಟ್ ಪೈಪ್‌ಲೈನ್‌ಗೆ ಎಂದಿಗೂ ಪ್ರವೇಶಿಸುವುದಿಲ್ಲ.
  2. Loaded – ಅಸಿಸ್ಟೆಂಟ್ ಫೈಲ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದೆ ಎಂಬುದಕ್ಕೆ ಯಾವುದೇ ಪುರಾವೆಯನ್ನು ನೀಡುತ್ತದೆಯೇ? ಹ್ಯಾಶ್ (hash) ಡಿಸ್ಕ್‌ನಲ್ಲಿರುವ ಫೈಲ್‌ನ ಗುರುತನ್ನು ಖಚಿತಪಡಿಸಬಹುದು, ಆದರೆ ಡೆಲಿವರಿ ಟ್ರೇಸ್ (ಉದಾಹರಣೆಗೆ, ಲಾಗ್ ಲೈನ್ ಅಥವಾ ಟೋಕನ್ ಸಂಖ್ಯೆ) ಮಾತ್ರ ಮಾದರಿಯು ಅದನ್ನು ನಿಜವಾಗಿಯೂ ಗಮನಿಸಿದೆ ಎಂಬುದನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.
  3. Useful – ಫೈಲ್‌ನ ಉಪಸ್ಥಿತಿಯು ಕಾರ್ಯದ ಫಲಿತಾಂಶವನ್ನು ಸುಧಾರಿಸುತ್ತದೆಯೇ? ಟೋಕನ್‌ಗಳನ್ನು ಹೆಚ್ಚಿಸಿ ಫಲಿತಾಂಶವನ್ನು ಬದಲಿಸದ ಲೋಡ್ ಆದ ಫೈಲ್ ನಷ್ಟವಷ್ಟೇ.

ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುವುದು

ಯಾವುದೇ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಇದನ್ನು ಪುನರಾವರ್ತಿಸಲು ಅನುಕೂಲವಾಗುವಂತೆ ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಕನಿಷ್ಠ ಮಟ್ಟದಲ್ಲಿ ಇರಿಸಲಾಗಿದೆ.

  1. ಕಾಣಿಸುವ ನಿಯಮವನ್ನು ರಚಿಸಿ – ಸರಳವಾದ, ಗಮನಿಸಬಹುದಾದ ಸೂಚನೆಯನ್ನು ಬರೆಯಿರಿ. ಉದಾಹರಣೆಗೆ: “ಎಡಿಟ್ ಮಾಡುವ ಮೊದಲು ನಿಖರವಾಗಿ ಎರಡು ಫೈಲ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ.” ನಿಯಮದ ಪರಿಣಾಮವನ್ನು ಅಸಿಸ್ಟೆಂಟ್‌ನ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ಪರಿಶೀಲಿಸಬಹುದು.

  2. ಸಾಧನದ ಆವೃತ್ತಿ ಮತ್ತು ಮಾದರಿಯನ್ನು ಪರಿಶೀಲಿಸಿ – ಹೊಸ ಸೆಷನ್ ತೆರೆಯಿರಿ, ಆವೃತ್ತಿ ಸ್ಟ್ರಿಂಗ್ ಮತ್ತು ಮಾದರಿಯ ಗುರುತನ್ನು (model identifier) ಗಮನಿಸಿ. ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳು ಅವು ಗುರುತಿಸುವ ಫೈಲ್ ಹೆಸರನ್ನು ಬದಲಾಯಿಸಬಹುದು.

  3. ಎರಡು ರನ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ Run A: ಸಾಧನವು ಗುರುತಿಸದ ಫೈಲ್ ಹೆಸರನ್ನು ಬಳಸಿ (ಉದಾಹರಣೆಗೆ, AGENTS.md). Run B: ಸಾಧನದ ಮೂಲ (native) ಫೈಲ್ ಹೆಸರನ್ನು ಬಳಸಿ (ಉದಾಹರಣೆಗೆ, CLAUDE.md).

    ದಾಖಲಿಸಿ:

    • ಫೈಲ್‌ನ ಮೂಲ ಹ್ಯಾಶ್ (ಡಿಸ್ಕ್‌ನಲ್ಲಿರುವ ವಿಷಯ ಬದಲಾಗಿಲ್ಲ ಎಂದು ಸಾಬೀತುಪಡಿಸಲು).
    • ಬಳಸಿದ ನಿಖರವಾದ ಪಥ (path).
    • ಫೈಲ್ ಲೋಡ್ ಆಗಿರುವ ಬಗ್ಗೆ ಅಸಿಸ್ಟೆಂಟ್ ನೀಡಿದ ಯಾವುದೇ ಪುರಾವೆ (ಟೋಕನ್ ಸಂಖ್ಯೆಯ ಏರಿಕೆ, ಸ್ಪಷ್ಟವಾದ “loaded X.md” ಸಂದೇಶ ಇತ್ಯಾದಿ).
    • ಪ್ರತಿ ವಿನಂತಿಗಾಗಿ ಟೋಕನ್ ಸಂಖ್ಯೆ.
    • ಕಾರ್ಯದ ಫಲಿತಾಂಶ (ಅಸಿಸ್ಟೆಂಟ್ ನಿಖರವಾಗಿ ಎರಡು ಫೈಲ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿತೇ?).

ಒಂದು ವೇಳೆ Run B ನಲ್ಲಿ ನಿಯಮವನ್ನು ಪಾಲಿಸಲಾಗುತ್ತಿದೆ ಮತ್ತು ಟೋಕನ್ ಸಂಖ್ಯೆಯು ನಿರೀಕ್ಷಿತ ಪ್ರಮಾಣದಲ್ಲಿ ಏರಿಕೆಯಾಗಿದ್ದರೆ, ಫೈಲ್ ಲೋಡ್ ಆಗಿದೆ ಮತ್ತು ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂದರ್ಥ. ಟೋಕನ್ ಏರಿಕೆಯಾಗಿದ್ದರೂ ನಿಯಮವನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದರೆ, ಫೈಲ್ ಅನ್ನು ಓದಲಾಗುತ್ತಿದೆ ಆದರೆ ಮಾದರಿಯ ಪ್ರಾಂಪ್ಟ್ ಪಾರ್ಸಿಂಗ್ (prompt parsing) ಸೂಚನೆಯನ್ನು ಕೈಬಿಡುತ್ತಿದೆ ಎಂದರ್ಥ. ಅಂತಹ ಸಂದರ್ಭದಲ್ಲಿ, ಫೈಲ್‌ಗೆ ಹೆಚ್ಚಿನ ಪಠ್ಯವನ್ನು ಸೇರಿಸುವುದು ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ; ಬದಲಾಗಿ ನಿಯಮವನ್ನು ಹಾರ್ಡ್-ಕೋಡ್ ಮಾಡಲಾದ ಪಾಲಿಸಿ ಗೇಟ್ ಅಥವಾ ಟೆಸ್ಟ್ ಹಾರ್ನೆಸ್‌ಗೆ (test harness) ವರ್ಗಾಯಿಸಿ.

ದತ್ತಾಂಶವು ಏನನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ

Claude Code ಪ್ರಕರಣವು ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ಲೋಡಿಂಗ್ ನಡುವಿನ ದೊಡ್ಡ ವ್ಯತ್ಯಾಸವನ್ನು ತೋರಿಸಿಕೊಟ್ಟಿತು. 72 KB ಫೈಲ್ ಇತ್ತು, ಸರಿಯಾದ ಹ್ಯಾಶ್ ಇತ್ತು ಮತ್ತು ರೆಪೊಗೆ ಸಿಂಕ್ ಆಗಿತ್ತು, ಆದರೂ ಅಸಿಸ್ಟೆಂಟ್ ಅದನ್ನು ಎಂದಿಗೂ ಉಲ್ಲೇಖಿಸಲಿಲ್ಲ. ಫೈಲ್ ಅನ್ನು ಮೂಲ CLAUDE.md ಗೆ ಮರುನಾಮಕರಣ ಮಾಡಿದ್ದು ಲೋಡಿಂಗ್ ಅನ್ನು ಪ್ರಚೋದಿಸಿತು, ಆದರೆ ಗಮನಾರ್ಹವಾದ ಟೋಕನ್ ಓವರ್‌ಹೆಡ್ ಅನ್ನು ಕೂಡ ಸೇರಿಸಿತು. ಪ್ರತಿ ಹೆಚ್ಚುವರಿ ಟೋಕನ್ ಕಂಪ್ಯೂಟ್ ಸೈಕಲ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ವಿನಂತಿಯನ್ನು ರೇಟ್ ಲಿಮಿಟ್‌ಗಳ (rate limits) ಮೀರುವಂತೆ ಮಾಡಬಹುದು.

ಮೂರು ಹಂತದ ಪರೀಕ್ಷೆಯು ಇಂತಹ ಅಡಗಿರುವ ವೆಚ್ಚಗಳನ್ನು ಉತ್ಪಾದನಾ ಅಡೆತಡೆಗಳಾಗುವ ಮೊದಲೇ ಹೊರಹಾಕುತ್ತದೆ. ಟೋಕನ್ ವ್ಯತ್ಯಾಸವನ್ನು (token delta) ಪತ್ತೆಹಚ್ಚುವ ಮೂಲಕ, ನಿಯಮದ ಪ್ರಯೋಜನವು ಅದರ ವೆಚ್ಚಕ್ಕಿಂತ ಹೆಚ್ಚಿದೆಯೇ ಎಂಬುದನ್ನು ತಂಡಗಳು ನಿರ್ಧರಿಸಬಹುದು.

ಸಾರಾಂಶ

ಕೇವಲ ರೆಪೊದಲ್ಲಿ ಇರುವುದರಿಂದ ನಿಯಮದ ಫೈಲ್ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂದು ಎಂದಿಗೂ ಭಾವಿಸಬೇಡಿ. ಆ ಊಹೆಯನ್ನು ಅಳೆಯಬಹುದಾದ ಪುರಾವೆಯನ್ನಾಗಿ ಮಾಡಲು ಮೂರು ಹಂತದ ಪರೀಕ್ಷೆಯನ್ನು ಬಳಸಿ—ಕಾನ್ಫಿಗರ್ ಮಾಡಿ, ಲೋಡ್ ಮಾಡಿ, ಉಪಯುಕ್ತತೆಯನ್ನು ಸಾಬೀತುಪಡಿಸಿ. ಪುರಾವೆಯು ಫೈಲ್ ಕೇವಲ ಟೋಕನ್ ವ್ಯರ್ಥ ಮಾಡುವ ಮೂಲವಾಗಿದೆ ಎಂದು ತೋರಿಸಿದಾಗ, ತರ್ಕವನ್ನು (logic) ಪ್ರಾಂಪ್ಟ್‌ನಿಂದ ಹೊರತೆಗೆದು ನಿರ್ಣಾಯಕ ಗೇಟ್‌ಗೆ (deterministic gate) ವರ್ಗಾಯಿಸಿ. ಇದರ ಫಲಿತಾಂಶವು ಹೆಚ್ಚು ಸುಸಜ್ಜಿತವಾದ, ವೇಗವಾದ ಮತ್ತು ಹೆಚ್ಚು ನಿರೀಕ್ಷಿತವಾದ AI ಕೋಡಿಂಗ್ ವರ್ಕ್‌ಫ್ಲೋ ಆಗಿ