ಪ್ರತಿಯೊಂದು AI ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ ಕೂಡ ಒಂದು diff ಅನ್ನು ನೀಡಬಲ್ಲದು. ಆದರೆ ನಿಜವಾದ ಸಮಸ್ಯೆ ಎಂದರೆ, ಆ diff ಒಂದು ಕೇಂದ್ರೀಕೃತ ಮತ್ತು ಉದ್ದೇಶಪೂರ್ವಕ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಬಂದಿದೆಯೇ ಅಥವಾ ನಿಮ್ಮ ರೆಪೊಸಿಟರಿಯಾದ್ಯಂತ ಅಸ್ತವ್ಯಸ್ತವಾಗಿ ಹುಡುಕುತ್ತಾ ಅಕಸ್ಮಾತ್ ಸರಿಯಾದ ಫಲಿತಾಂಶಕ್ಕೆ ತಲುಪಿದೆಯೇ ಎಂದು ತಿಳಿಯುವುದು. ಪ್ರಸ್ತುತ, ಹೆಚ್ಚಿನ ತಂಡಗಳಿಗೆ ಈ ವ್ಯತ್ಯಾಸವನ್ನು ಗುರುತಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತಿಲ್ಲ.
ಇದು ತಾಂತ್ರಿಕ ಮಿತಿಯಲ್ಲ. ಇದು ದೃಶ್ಯೀಕರಣದ (visibility) ಸಮಸ್ಯೆ.
ಒಂದು ಏಜೆಂಟ್ ಮೂರು ಸಾಲುಗಳ ಪ್ರೊಡಕ್ಷನ್ ಕೋಡ್ ಬರೆಯುವಾಗ, ಅದು ಕೇವಲ ಮೂರು ಫೈಲ್ಗಳನ್ನು ಓದಿ ಮತ್ತು ಟೆಸ್ಟ್ಗಳನ್ನು ರನ್ ಮಾಡಿರಬಹುದು. ಅಥವಾ ಅದು ಸಂಬಂಧವಿಲ್ಲದ ನಲವತ್ತು ಫೈಲ್ಗಳನ್ನು ಮುಟ್ಟಿ, ಡಜನ್ಗಟ್ಟಲೆ ವಿಫಲವಾದ ಕಮಾಂಡ್ಗಳನ್ನು ಚಲಾಯಿಸಿ, ಡಿಪೆಂಡೆನ್ಸಿ ಇನ್ಸ್ಟಾಲ್ ಆಗದ ಕಾರಣ ನಿಮ್ಮ ಟೆಸ್ಟ್ ಸೂಟ್ ಅನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟಿರಬಹುದು ಮತ್ತು ಅದಕ್ಕಾಗಿ ನಿಮಗೆ ಹಣವನ್ನೂ ವಿಧಿಸಿರಬಹುದು. ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ diff ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತದೆ. ಆ ಪ್ರಕ್ರಿಯೆಯ ದಾಖಲೆ ಇಲ್ಲದಿದ್ದರೆ, ಅಂತಿಮ ಫಲಿತಾಂಶದ ಗುಣಮಟ್ಟದ ಬಗ್ಗೆ ನೀವು ಕೇವಲ ಊಹಿಸಬೇಕಾಗುತ್ತದೆ.
ಚಾಟ್ ಲಾಗ್ಗಳು ಏಕೆ ರಸೀದಿಗಳಲ್ಲ (Receipts)?
ಅನೇಕ ಪರಿಕರಗಳು ಕೆಲಸದ ಪುರಾವೆಯಾಗಿ ಚಾಟ್ ಟ್ರಾನ್ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ನೀಡುತ್ತವೆ. ಆದರೆ ಟ್ರಾನ್ಸ್ಕ್ರಿಪ್ಟ್ ಎಂಬುದು ರಸೀದಿ ಅಲ್ಲ. ಅದು ನಿಮ್ಮ ಮೇಜಿನ ಮೇಲೆ ಸುರಿದಿರುವ ಬಿಡಿಭಾಗಗಳ ಪೆಟ್ಟಿಗೆಯಿದ್ದಂತೆ. ಅದರಲ್ಲಿ ಪ್ರತಿಯೊಂದು ಆಲೋಚನಾ ಕ್ರಮ, ಪ್ರತಿಯೊಂದು ವಿಫಲ ಪ್ರಯತ್ನ, ಪ್ರತಿಯೊಂದು ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ ಮತ್ತು ಪ್ರತಿಯೊಂದು ಅಪ್ರಸ್ತುತ ಟೂಲ್ ಕಾಲ್ ಇರುತ್ತದೆ. ಕೇವಲ ಮೂರು ಸಾಲುಗಳ ಪ್ಯಾಚ್ ಅನ್ನು ಪರಿಶೀಲಿಸಲು ನೀವು ಸಾವಿರಾರು ಸಾಲುಗಳ ಸಂಭಾಷಣೆಯನ್ನು ಓದಬೇಕಿದ್ದರೆ, ನಿಮ್ಮ ರಿವ್ಯೂ ವರ್ಕ್ಫ್ಲೋ ಈಗಾಗಲೇ ಹಾಳಾಗಿದೆ ಎಂದರ್ಥ.
ಮಾನವನ ಗಮನವು ಸೀಮಿತವಾಗಿದೆ. ಏಜೆಂಟ್ನ ಉದ್ದೇಶವು ಮಾನಸಿಕ ಶ್ರಮವನ್ನು ಉಳಿಸುವುದೇ ಹೊರತು, ಹೊಸ ಮನೆಗೆಲಸವನ್ನು (homework) ನೀಡುವುದಲ್ಲ. ಟ್ರಾನ್ಸ್ಕ್ರಿಪ್ಟ್ ರಿವ್ಯೂವರ್ ಅನ್ನು ಒಬ್ಬ ಪತ್ತೆದಾರನನ್ನಾಗಿ ಮಾಡಬೇಕೆಂದು ಕೇಳುತ್ತದೆ. ಆದರೆ ರಸೀದಿಯು ಒಂದು ನೋಟದಲ್ಲೇ ಉತ್ತರವನ್ನು ನೀಡುತ್ತದೆ.
ಉಪಯುಕ್ತ ರಸೀದಿಯು ಒಂದು ಪ್ರಾಯೋಗಿಕ ಸಾರಾಂಶವಾಗಿರುತ್ತದೆ. ಏಜೆಂಟ್ಗೆ ಏನು ಮಾಡಲು ಹೇಳಲಾಗಿತ್ತು, ಅದು ವಾಸ್ತವವಾಗಿ ಏನು ಮಾಡಿತು ಮತ್ತು ಅದು ಹೇಗೆ ತನ್ನ ತೀರ್ಮಾನಕ್ಕೆ ಬಂದಿತು ಎಂಬುದನ್ನು ಅದು ನಿಮಗೆ ತಿಳಿಸುತ್ತದೆ. ಅದು ವೈಫಲ್ಯವನ್ನು ಮರೆಮಾಚುವುದಿಲ್ಲ, ಬದಲಾಗಿ ಅದನ್ನು ಎತ್ತಿ ತೋರಿಸುತ್ತದೆ.
ಒಂದು ಉತ್ತಮ ರಸೀದಿ ಹೇಗಿರಬೇಕು?
ಪರಿಶೀಲಿಸಬಹುದಾದ ರಸೀದಿಯು ಹೆಚ್ಚು ಹುಡುಕಾಟ ನಡೆಸದೆ ಈ ಕೆಳಗಿನ ನಿರ್ದಿಷ್ಟ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಬೇಕು:
- ಕಾರ್ಯವೇನು? ಉದ್ದೇಶಿತ ಬದಲಾವಣೆಯ ಸ್ಪಷ್ಟ ವಿವರಣೆ ಇರಲಿ, ಕೇವಲ ಅಸ್ಪಷ್ಟ ಪ್ರಾಂಪ್ಟ್ನ ಪ್ರತಿಧ್ವನಿಯಲ್ಲ.
- ಯಾವ ಫೈಲ್ಗಳನ್ನು ಓದಲಾಯಿತು? ಇದರಿಂದ ಏಜೆಂಟ್ ಸರಿಯಾದ ಮೂಲಗಳಿಂದ ಸಂದರ್ಭವನ್ನು (context) ರೂಪಿಸಿದೆಯೇ ಎಂದು ನೀವು ನಿರ್ಧರಿಸಬಹುದು.
- ಯಾವ ಫೈಲ್ಗಳನ್ನು ಎಡಿಟ್ ಮಾಡಲಾಯಿತು? ಬದಲಾವಣೆಯ ಅಂತಿಮ ಹೆಜ್ಜೆಗುರುತುಗಳು.
- ಯಾವ ಕಮಾಂಡ್ಗಳನ್ನು ರನ್ ಮಾಡಲಾಯಿತು? ಬಿಲ್ಡ್ ಹಂತಗಳು, ಲಿಂಟರ್ಗಳು, ಫಾರ್ಮ್ಯಾಟ್ಗಳು ಅಥವಾ ಏಜೆಂಟ್ ಬಳಸಿದ ಕಸ್ಟಮ್ ಸ್ಕ್ರಿಪ್ಟ್ಗಳು.
- ಯಾವ ಕಮಾಂಡ್ಗಳು ವಿಫಲವಾದವು? ಕೇವಲ ಯಶಸ್ವಿ ಕೆಲಸಗಳಲ್ಲ. ವೈಫಲ್ಯಗಳು ಏಜೆಂಟ್ ಎಲ್ಲಿ ಅನಿವಾರ್ಯವಾಗಿ ಬದಲಾವಣೆ ಮಾಡಬೇಕಾಯಿತು ಅಥವಾ ಎಲ್ಲಿ ಕೈ ಬಿಟ್ಟಿತು ಎಂಬುದನ್ನು ತಿಳಿಸುತ್ತವೆ.
- ಯಾವ ಟೆಸ್ಟ್ಗಳು ಪಾಸಾದವು ಅಥವಾ ಬಿಟ್ಟುಬಿಡಲ್ಪಟ್ಟವು? ಬಿಟ್ಟುಬಿಡಲ್ಪಟ್ಟ ಟೆಸ್ಟ್ಗಳು ಎಚ್ಚರಿಕೆಯ ಸಂಕೇತ (red flag). ಅವುಗಳನ್ನು ಏಕೆ ಬಿಟ್ಟುಬಿಡಲಾಯಿತು ಎಂಬುದನ್ನು ರಸೀದಿಯು ತಿಳಿಸಬೇಕು.
- ಒಟ್ಟು ವೆಚ್ಚ ಎಷ್ಟು? ಟೋಕನ್ಗಳು, API ಕಾಲ್ಗಳು ಮತ್ತು ಕಂಪ್ಯೂಟ್ ಸಮಯ. ಇದು ಕೇವಲ ಮಾಡೆಲ್ನ ಬೆಲೆಯನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ನಿಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರ್ನ ವೆಚ್ಚವನ್ನೂ ಒಳಗೊಂಡಿರಬೇಕು.
ಈ ಫಾರ್ಮ್ಯಾಟ್ ರಿವ್ಯೂ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪುರಾತತ್ವ ಉತ್ಖನನದಂತೆ ಮಾಡದೆ, ಒಂದು ಕ್ಷಿಪ್ರ ಪರಿಶೀಲನೆಯನ್ನಾಗಿ (sanity check) ಬದಲಾಯಿಸುತ್ತದೆ. ಒಬ್ಬ ಹಿರಿಯ ಎಂಜಿನಿಯರ್ ರಸೀದಿಯನ್ನು ಕೇವಲ ಒಂದು ನಿಮಿಷದ ಒಳಗೇ ಸ್ಕ್ಯಾನ್ ಮಾಡಿ "ಇದು ಸರಿಯಾಗಿದೆ" ಅಥವಾ "ಇದು ಅನುಮಾನಾಸ್ಪದವಾಗಿದೆ" ಎಂದು ಹೇಳಲು ಸಾಧ್ಯವಾಗಬೇಕು.
ಕೇವಲ ಇತಿಹಾಸವನ್ನಲ್ಲ, ಹೆಜ್ಜೆಗುರುತುಗಳನ್ನು ಓದಿ
ಏಜೆಂಟ್ ರನ್ನ ಹೆಜ್ಜೆಗುರುತುಗಳು ಕೆಲಸದ ಸ್ವರೂಪವನ್ನು ತೋರಿಸುತ್ತವೆ. ಏಜೆಂಟ್ ಟಿಕೆಟ್ನ ಮಿತಿಯೊಳಗೆ ಉಳಿದಿದೆಯೇ? ಅಥವಾ ಸಂಬಂಧವಿಲ್ಲದ ಮಾಡ್ಯೂಲ್ಗಳಿಗೆ ಹೋಗಿ ಯಾರೂ ಕೇಳದ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದೆಯೇ? "Files Read" ಜೊತೆಗೆ "Files Edited" ಅನ್ನು ಪಟ್ಟಿ ಮಾಡುವ ರಸೀದಿಯು ಇದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ.
ಹೆಜ್ಜೆಗುರುತುಗಳು ಪುನರಾವರ್ತನೆಯನ್ನು ಸಹ ಬಹಿರಂಗಪಡಿಸುತ್ತವೆ. ಒಂದೇ ತಪ್ಪು ಹಾದಿಯಲ್ಲಿ ಪದೇ ಪದೇ ಹೋಗುವ ಏಜೆಂಟ್—ಅಂದರೆ ಒಂದೇ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ಮೂರು ಬಾರಿ ಓದುವುದು ಅಥವಾ ವಿಫಲವಾದ ಟೆಸ್ಟ್ ಅನ್ನು ಪದೇ ಪದೇ ರನ್ ಮಾಡುವುದು—ಕಂಪ್ಯೂಟ್ ಮತ್ತು ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ. ಆ ಮಾದರಿಯು (pattern) ಗೋಚರಿಸಬೇಕು. ಒಂದು ಮಿಗ್ರೇಷನ್ ಸ್ಕ್ರಿಪ್ಟ್ ರನ್ ಮಾಡಲು ಏಜೆಂಟ್ ಒಂಬತ್ತು ಪ್ರಯತ್ನಗಳನ್ನು ಮಾಡಬೇಕಾಗಿದ್ದರೆ, ರಸೀದಿಯು ಅದನ್ನು ತಿಳಿಸಬೇಕು. ಆ ಮಾಹಿತಿ ನೀವು ಫಲಿತಾಂಶವನ್ನು ಹೇಗೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತೀರಿ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಅಸ್ತವ್ಯಸ್ತವಾಗಿ ಕೆಲಸ ಮಾಡಿ ಬಂದ "ಸರಿಯಾದ" diff ಮತ್ತು ವ್ಯವಸ್ಥಿತವಾಗಿ ಕೆಲಸ ಮಾಡಿ ಬಂದ "ಸರಿಯಾದ" diff ಒಂದೇ ಆಗಿರಲಾರವು.
ಕಳಪೆ ವಿನ್ಯಾಸದ ಗುಪ್ತ ವೆಚ್ಚ
ವೆಚ್ಚ ಎಂದರೆ ಕೇವಲ ಪ್ರತಿ ಟೋಕನ್ಗೆ ನೀಡುವ ಬೆಲೆಯಲ್ಲ. ಕಳಪೆ ವಿನ್ಯಾಸದ ವರ್ಕ್ಫ್ಲೋವು ಏಜೆಂಟ್ ಒಂದು ಅಕ್ಷರವನ್ನು ಸೃಷ್ಟಿಸುವ ಮೊದಲೇ ಅದನ್ನು ದುಬಾರಿ ಮಾಡುತ್ತದೆ. ಅತಿಯಾದ ಟೂಲ್ ಸ್ಕೀಮಾಗಳು, ಅನಗತ್ಯ ಫೈಲ್ ಇಂಡೆಕ್ಸಿಂಗ್ ಮತ್ತು ಅತಿಯಾದ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ಗಳು ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋವನ್ನು ಹೆಚ್ಚಿಸುತ್ತವೆ. ರಸೀದಿಯು ಈ ಹೆಚ್ಚಿನ ವೆಚ್ಚವನ್ನು (overhead) ಎತ್ತಿ ತೋರಿಸಬೇಕು.
ಒಂದು ವೇಳೆ ಕೋಡ್ ಜನರೇಟ್ ಮಾಡುವುದು ಅಗ್ಗವಾಗಿ ಮತ್ತು ರಿವ್ಯೂ ಮಾಡುವುದು ಕಷ್ಟವಾಗಿದ್ದರೆ, ನೀವು ಏನನ್ನೂ ಗಳಿಸಿಲ್ಲ ಎಂದರ್ಥ. ನೀವು ಕೇವಲ ಸಮಸ್ಯೆಯನ್ನು ಮತ್ತೊಂದು ಕಡೆಗೆ ವರ್ಗಾಯಿಸಿದ್ದೀರಿ. ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ತಂಡದಲ್ಲಿ ಎಂಜಿನಿಯರ್ ಸಮಯವು ಅತ್ಯಂತ ಅಪರೂಪದ ಸಂಪನ್ಮೂಲವಾಗಿದೆ. ಪ್ರತಿ ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್ಗೆ ಮೂವತ್ತು ನಿಮಿಷಗಳ ರಿವ್ಯೂ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸಿ, ಕೇವಲ ಐದು ಡಾಲರ್ API ವೆಚ್ಚವನ್ನು ಉಳಿಸುವುದು ಅತ್ಯಂತ ಕೆಟ್ಟ ವ್ಯವಹಾರ. ಈ ವ್ಯವಹಾರವನ್ನು ನೇರವಾಗಿ ಪರಿಶೀಲಿಸಲು ರಸೀದಿಯು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಪ್ರಾಮಾಣಿಕತೆಯೇ ಒಂದು ವೈಶಿಷ್ಟ್ಯ (Feature)
ಉಪಯುಕ್ತ ರಸೀದಿಯು ಅಗತ್ಯವಿದ್ದಾಗ ಅಸಮಾಧಾನಕಾರಿಯಾಗಿರಬೇಕು. ಅದು ಏಜೆಂಟ್ ಅನ್ನು ಅಸಮರ್ಥವಾಗಿ ತೋರಿಸುವ ಸತ್ಯಗಳನ್ನು ವರದಿ ಮಾಡಬೇಕು, ಏಕೆಂದರೆ ಆ ಪ್ರಾಮಾಣಿಕತೆಯು ಮುಂದಿನ ಮಾನವ ನಿರ್ಧಾರವನ್ನು ವೇಗವಾಗಿ ಮತ್ತು ಉತ್ತಮವಾಗಿ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಉದಾಹರಣೆಗಳು ಮುಖ್ಯವಾಗಿವೆ:
- "ಒಂದು ಸಾಲಿನ ಬದಲಾವಣೆಗಾಗಿ 37 ಫೈಲ್ಗಳನ್ನು ಓದಿದೆ."
- "
npm installಪೀರ್ ಡಿಪೆಂಡೆನ್ಸಿ ಸಂಘರ್ಷದಿಂದ (peer dependency conflict) ವಿಫಲವಾದ ಕಾರಣ ಪರೀಕ್ಷೆಗಳನ್ನು ಬಿಟ್ಟುಬಿಡಲಾಗಿದೆ." - "ಏಜೆಂಟ್ ಪರಿಚಯಿಸಿದ ಇಂಪೋರ್ಟ್ ಅನ್ನು ಸರಿಪಡಿಸಲು, ವಿನಂತಿಸಿದ ವ್ಯಾಪ್ತಿಯ ಹೊರಗೆ
utils.pyಅನ್ನು ಎಡಿಟ್ ಮಾಡಲಾಗಿದೆ." - "ಲಿಂಟರ್ ಅನ್ನು 4 ಬಾರಿ ಚಲಾಯಿಸಲಾಗಿದೆ; ಮೊದಲ ಮೂರು ಬಾರಿ ಪಾತ್ ಮಿಸ್ಕನ್ಫಿಗರೇಶನ್ನಿಂದಾಗಿ ವಿಫಲವಾಗಿವೆ."
ಇವು ರಸೀದಿಯಲ್ಲಿನ (receipt) ದೋಷಗಳಲ್ಲ. ಇವು ಸಂಕೇತಗಳು. ವಿಮರ್ಶಕರು ಎಲ್ಲಿ ಸಂಶಯ ವ್ಯಕ್ತಪಡಿಸಬೇಕು ಎಂಬುದನ್ನು ಇವು ತಿಳಿಸುತ್ತವೆ. ಅಲ್ಲದೆ, ವರ್ಕ್ಫ್ಲೋ ಅನ್ನು ಎಲ್ಲಿ ಬಲಪಡಿಸಬೇಕೆಂದು ಇವು ಪ್ಲಾಟ್ಫಾರ್ಮ್ ತಂಡಕ್ಕೆ ತಿಳಿಸುತ್ತವೆ.
ಸಣ್ಣ ಚಾಲನೆಗಳು, ಸ್ಪಷ್ಟ ಮೇಲ್ವಿಚಾರಣೆ
ಏಜೆಂಟ್ಗಳನ್ನು ದೊಡ್ಡ ಮಟ್ಟದ ಕೆಲಸಗಳಲ್ಲಿ ಅತಿಕ್ರಮವಾಗಿ ಬಿಡಲು ನೈಸರ್ಗಿಕ ಪ್ರಲೋಭನೆ ಇರುತ್ತದೆ. ಇಡೀ ಸೇವೆಯನ್ನು (service) ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡಲು ಒಂದು ದೊಡ್ಡ ಪ್ರಾಂಪ್ಟ್ ನೀಡುವುದು ವೇಗವಾಗಿ ಅನಿಸಬಹುದು. ಆದರೆ ಅದು ಅಷ್ಟೊಂದು ವೇಗವಾಗಿಲ್ಲ. ಇದು ಪರಿಶೀಲಿಸಲು ಅಸಾಧ್ಯವಾದ ಕೆಲಸದ ರಾಶಿಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಬದಲಾದ ಎಂಭತ್ತು ಫೈಲ್ಗಳಲ್ಲಿ ಯಾವುವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಬದಲಾಯಿಸಲಾಗಿದೆ ಎಂದು ಪತ್ತೆಹಚ್ಚುವಲ್ಲೇ ನಿಮ್ಮ ಮಧ್ಯಾಹ್ನ ಕಳೆದುಹೋಗುತ್ತದೆ.
ಸಣ್ಣ ಮತ್ತು ಪರಿಶೀಲಿಸಬಹುದಾದ ಚಾಲನೆಗಳು ಉತ್ತಮವಾಗಿವೆ. ಕಾರ್ಯಕ್ಕಾಗಿ ಸ್ಪಷ್ಟ ಮಿತಿಗಳನ್ನು ನಿಗದಿಪಡಿಸಿ. ಏಜೆಂಟ್ ಓದಬಹುದಾದ ಫೈಲ್ಗಳ ಪಟ್ಟಿಯನ್ನು ಅದು ಬರೆಯಬಹುದಾದ ಪಟ್ಟಿಯಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ. ವಿಫಲವಾದ ಕಮಾಂಡ್ಗಳ ಇತಿಹಾಸವನ್ನು ದಾಖಲಿಸಿ, ಇದರಿಂದ ವಿಫಲವಾದ ಹಾದಿಗಳು (dead ends) ಸ್ಪಷ್ಟವಾಗಿ ಕಾಣಿಸುತ್ತವೆ. ಬಿಟ್ಟುಬಿಡಲಾದ ಪರಿಶೀಲನೆಗಳನ್ನು (skipped verifications) ಸ್ಪಷ್ಟವಾಗಿ ಗುರುತಿಸಿ. ಸರ್ಚ್ APIಗಳಿಂದ ಹಿಡಿದು ಟೆಸ್ಟ್ ರನ್ನರ್ಗಳವರೆಗೆ ಪ್ರತಿಯೊಂದು ಬಾಹ್ಯ ಸಾಧನಗಳ ಬಳಕೆಯನ್ನು ಗಮನಿಸಿ.
ಗುರಿ ಸಂಪೂರ್ಣ ಸ್ವಾಯತ್ತತೆಯಲ್ಲ (autonomy). ಮನುಷ್ಯನಿಂದ ಪರಿಶೀಲಿಸಲು ಸಾಧ್ಯವಾಗದ ಸಂಪೂರ್ಣ ಸ್ವಾಯತ್ತತೆಯು ಕೇವಲ ಹೊಣೆಗಾರಿಕೆಯೊಂದಿಗೆ ಬರುವ ಆಟೋಮೇಷನ್ ಆಗಿದೆ. ನಿಜವಾದ ಗುರಿ ಪರಿಶೀಲಿಸಬಹುದಾದ ಸಾಮರ್ಥ್ಯ (reviewability). ಪ್ರತಿಯೊಂದು ಏಜೆಂಟ್ ಔಟ್ಪುಟ್ ಅನ್ನು ಅನುಮೋದಿಸುವುದು ಅಥವಾ ತಿರಸ್ಕರಿಸುವುದು ಸುಲಭವಾಗಿರಬೇಕು. ತನಿಖೆ ಮಾಡಲು ಸುಸ್ತಾಗಿರುವುದರಿಂದ ನೀವು ಕೋಡ್ ಅನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುವಂತಹ ಯಾವುದೇ ಅಸ್ಪಷ್ಟ ಮಧ್ಯಮ ಮಾರ್ಗವಿರಬಾರದು.
ಯಾವುದೇ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ಗಾಗಿ ಪರೀಕ್ಷೆ
ಯಾವುದೇ ಏಜೆಂಟ್ ಅಥವಾ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವ ಮೊದಲು, ಒಂದು ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳಿ: ಮನುಷ್ಯನು ಮುಂದಿನ ಹಂತವನ್ನು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಅನುಮೋದಿಸಲು ಇದು ಸಾಕಷ್ಟು ಪುರಾವೆಗಳನ್ನು ಬಿಡಬಲ್ಲದೇ?
ಉತ್ತರ 'ಹೌದು' ಎಂದಾದರೆ, ಆ ಸಾಧನವು ವೃತ್ತಿಪರ ವರ್ಕ್ಫ್ಲೋಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ. ಉತ್ತರ 'ಅಲ್ಲ' ಎಂದಾದರೆ, ನೀವು ಉತ್ಪಾದಕತೆಯನ್ನು ಖರೀದಿಸುತ್ತಿಲ್ಲ. ನೀವು ಸಾಂದರ್ಭಿಕವಾಗಿ ಕಂಪಿಲ್ ಆಗುವ ಒಂದು ರಹಸ್ಯವನ್ನು ಖರೀದಿಸುತ್ತಿದ್ದೀರಿ. ಇದು ವೀಕೆಂಡ್ ಸೈಡ್ ಪ್ರಾಜೆಕ್ಟ್ಗೆ ಸರಿಹೊಂದಬಹುದು, ಆದರೆ ಪ್ರೊಡಕ್ಷನ್ ಇಂಜಿನಿಯರಿಂಗ್ಗೆ ಇದು ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲ.
ಏಜೆಂಟ್ ಔಟ್ಪುಟ್ಗಳನ್ನು ಪರಿಶೀಲಿಸದ ಉಡುಗೊರೆಗಳೆಂದು ಪರಿಗಣಿಸುವ ತಂಡಗಳು, ಅನಿರೀಕ್ಷಿತ ವ್ಯಾಪ್ತಿ ವಿಸ್ತರಣೆಯಿಂದ (scope creep) ಉಂಟಾದ ಸೂಕ್ಷ್ಮ ದೋಷಗಳನ್ನು ಅಂತಿಮವಾಗಿ ಬಿಡುಗಡೆ ಮಾಡುತ್ತವೆ. ಡಿಫ್ (diff) ಮುಗ್ಧವಾಗಿ ಕಾಣಿಸಬಹುದು. ರಸೀದಿಯು ಸತ್ಯವನ್ನು ಹೇಳುತ್ತಿತ್ತು.
ರಸೀದಿಗಳನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸಿ. ಪರಿಶೀಲನೆಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿ. ನಂಬಿಕೆಯು ತಂತ್ರವಲ್ಲ, ಪುರಾವೆಯೇ ತಂತ್ರ.
AI ಟೂಲಿಂಗ್ ಮತ್ತು ಡೆವಲಪರ್ ವರ್ಕ್ಫ್ಲೋಗಳ ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ಪ್ರಾಯೋಗಿಕ ಚರ್ಚೆಗಳಿಗಾಗಿ, ನೀವು GyaanSetu on Telegram ನಲ್ಲಿ ಸಮುದಾಯವನ್ನು ಸೇರಬಹುದು.