ಕಳೆದ ತಿಂಗಳು, ಒಂದು AI ಅಸಿಸ್ಟೆಂಟ್ ಪ್ರೊಡಕ್ಷನ್ ಪ್ರಾಜೆಕ್ಟ್ಗಾಗಿ ಪೈಥಾನ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ತಯಾರಿಸಿತು. ಔಟ್ಪುಟ್ ಯಾವುದೇ ದೋಷಗಳಿಲ್ಲದೆ ಚಲಿಸಿತು. ಡೇಟಾ ಸರಿಯಾಗಿ ಕಂಡಿತು. ಆದರೆ ಮ್ಯಾನುಯಲ್ ರಿವ್ಯೂ ಮಾಡಿದಾಗ ಡೇಟಾಬೇಸ್ ಕಾಲ್ಗಳಲ್ಲಿ N+1 ಕ್ವೆರಿ ಪ್ಯಾಟರ್ನ್ ಅಡಗಿರುವುದು ಕಂಡುಬಂದಿತು. ಸಣ್ಣ ಡೇಟಾ ಸೆಟ್ಗೆ ಕೋಡ್ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡಿತು. ಆದರೆ ಸಾವಿರಾರು ರೆಕಾರ್ಡ್ಗಳಿಗೆ ಇದನ್ನು ಹೆಚ್ಚಿಸಿದಾಗ, ಅಪ್ಲಿಕೇಶನ್ ಪೇರೆಂಟ್ ಆಬ್ಜೆಕ್ಟ್ಗಳಿಗಾಗಿ ಒಂದು ಕ್ವೆರಿ ಮತ್ತು ಸಂಬಂಧಿತ ಡೇಟಾಕ್ಕಾಗಿ ಸಾವಿರಾರು ಫಾಲೋ-ಅಪ್ ಕ್ವೆರಿಗಳನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ ಅತಿ ದೊಡ್ಡ ಮಟ್ಟದ ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಕುಸಿತ ಉಂಟಾಗುತ್ತದೆ, ಇದನ್ನು ಯಾವುದೇ ಯೂನಿಟ್ ಟೆಸ್ಟ್ ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಇದು ಆಧುನಿಕ ಸಾಫ್ಟ್ವೇರ್ ಅಭಿವೃದ್ಧಿಯ ವಾಸ್ತವ. AI ಪರಿಕರಗಳು ಈಗ ಮನುಷ್ಯರಿಗಿಂತ ವೇಗವಾಗಿ ಕೋಡಿಂಗ್, ಡಿಬಗ್ಗಿಂಗ್ ಮತ್ತು ಆರ್ಕಿಟೆಕ್ಚರಲ್ ಸಲಹೆಗಳನ್ನು ನೀಡುತ್ತವೆ. ಆ ವೇಗ ನಿಜವಾಗಿಯೂ ಅದ್ಭುತವಾಗಿದೆ. ಆದರೆ ಇದು ನಿಮ್ಮ ಕೆಲಸದ ಸ್ವರೂಪವನ್ನೇ ಮೂಲಭೂತವಾಗಿ ಬದಲಾಯಿಸುತ್ತದೆ. ನೀವು ಕೇವಲ ಸಿಂಟ್ಯಾಕ್ಸ್ ಟೈಪ್ ಮಾಡಲು ಹಣ ಪಡೆಯುತ್ತಿಲ್ಲ. ನೀವು ಆಡಿಟ್ ಮಾಡಲು, ಆರ್ಕಿಟೆಕ್ಟ್ ಮಾಡಲು ಮತ್ತು ಇಂತಹ ಅದೃಶ್ಯ ಬಲೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಹಣ ಪಡೆಯುತ್ತಿದ್ದೀರಿ.
"ತಾರ್ಕಿಕವಾಗಿ ಸರಿಯಾದ ಆದರೆ ತಪ್ಪು" ಎಂಬ ಮೌನ ಅಪಾಯ
AI-ಜನರೇಟೆಡ್ ಕೋಡ್ ಸಾಮಾನ್ಯವಾಗಿ ಸರಿಯಾಗಿ ಕಾಣಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಅದು ಕಾಂಪೈಲ್ ಆಗುತ್ತದೆ, ರನ್ ಆಗುತ್ತದೆ ಮತ್ತು ನಿರೀಕ್ಷಿತ ಮೌಲ್ಯವನ್ನು ನೀಡುತ್ತದೆ. ಮೇಲ್ನೋಟಕ್ಕೆ ಲಾಜಿಕ್ ಸರಿಯಾಗಿರುತ್ತದೆ. ಆದರೆ ಅದರ ಒಳಗಡೆ ಅದು ಮೌನವಾಗಿ ದೋಷಪೂರಿತವಾಗಿರಬಹುದು.
ರೆಗ್ಯುಲರ್ ಎಕ್ಸ್ಪ್ರೆಶನ್ಗಳನ್ನು (regular expressions) ತೆಗೆದುಕೊಳ್ಳಿ. ಇಂಗ್ಲಿಷ್ನಲ್ಲಿ ಇಮೇಲ್ ವಿಳಾಸಗಳು ಅಥವಾ ಐಡೆಂಟಿಫೈಯರ್ಗಳನ್ನು ನಿಖರವಾಗಿ ಹೊಂದಿಕೆಯಾಗುವ ಪ್ಯಾಟರ್ನ್ ಅನ್ನು AI ನಿಮಗೆ ನೀಡಬಹುದು. ಅದೇ ಎಕ್ಸ್ಪ್ರೆಶನ್ ಅನ್ನು ಜರ್ಮನ್ ಉಮ್ಲೌಟ್ಗಳು (German umlauts), ಅರೇಬಿಕ್ ಸ್ಕ್ರಿಪ್ಟ್ಗಳು ಅಥವಾ ಯೂನಿಕೋಡ್ ನಾರ್ಮಲೈಸೇಶನ್ ಎಡ್ಜ್ ಕೇಸ್ಗಳ ವಿರುದ್ಧ ಬಳಸಿದಾಗ, ಅದು ಮೌನವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ. ಕೋಡ್ ಎಕ್ಸೆಪ್ಶನ್ ಎಸೆಯುವ ರೀತಿಯಲ್ಲಿ ತಪ್ಪಾಗಿರುವುದಿಲ್ಲ. ಅದು ಕೇವಲ ನೈಜ ಪ್ರಪಂಚದ ಮಾನ್ಯ ಡೇಟಾವನ್ನು ಹೊರಗಿಡುತ್ತದೆ.
ಡೇಟಾಬೇಸ್ ಕ್ವೆರಿಗಳು ಸಹ ಇದೇ ರೀತಿಯ ಅಪಾಯವನ್ನು ಹೊಂದಿವೆ. AI ಒಂದು PostgreSQL ಕ್ವೆರಿಯನ್ನು ಬರೆಯಬಹುದು, ಅದು ಟೆಸ್ಟಿಂಗ್ ಸಮಯದಲ್ಲಿ ಸರಿಯಾದ ಸಾಲುಗಳನ್ನು ನೀಡಬಹುದು, ಆದರೆ ನಿಮ್ಮ ಟೇಬಲ್ಗಳನ್ನು 'ಡೆಡ್ ಟ್ಯೂಪಲ್ಗಳಿಂದ' (dead tuples) ತುಂಬಿಸಬಹುದು, ಇಂಡೆಕ್ಸ್ ಬಳಕೆಯನ್ನು ತಪ್ಪಿಸಬಹುದು ಅಥವಾ ಪ್ರೊಡಕ್ಷನ್ ವರ್ಕ್ಲೋಡ್ಗಳನ್ನು ಕುಂಠಿತಗೊಳಿಸುವ ಸೀಕ್ವೆನ್ಷಿಯಲ್ ಸ್ಕ್ಯಾನ್ಗಳಿಗೆ (sequential scans) ಒತ್ತಾಯಿಸಬಹುದು. ಡೆಮೊ ಡೇಟಾ ಸೆಟ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಂತದ್ದು ಮತ್ತು ನೈಜ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಂತದ್ದು ಎಂಬುದು ಎರಡು ವಿಭಿನ್ನ ವಿಷಯಗಳು. ಯಂತ್ರಕ್ಕೆ ಲೇಟೆನ್ಸಿ (latency) ಅಥವಾ ಕ್ಲೌಡ್ ಬಿಲ್ನ ಅರಿವಿರುವುದಿಲ್ಲ.
ಬರೆಯುವುದರಿಂದ ಪರಿಶೀಲಿಸುವವರೆಗೆ
ಮುಖ್ಯವಾದ ಬದಲಾವಣೆಯೆಂದರೆ "ನಾನು ಇದನ್ನು ಹೇಗೆ ಬರೆಯಲಿ?" ಎಂಬುದರಿಂದ "ನಾನು ಇದನ್ನು ಹೇಗೆ ಪರಿಶೀಲಿಸಲಿ?" ಎಂಬುದರ ಕಡೆಗೆ ಸಾಗುವುದು. AI ಮೊದಲ ಡ್ರಾಫ್ಟ್ ಅನ್ನು ನಿರ್ವಹಿಸಿದಾಗ, ನಿಮ್ಮ ಜ್ಞಾನಾತ್ಮಕ ಹೊರೆ (cognitive load) ಮುಂದಿನ ಹಂತಕ್ಕೆ ಸಾಗಬೇಕು. ನೀವು ಕೋಡ್ ಅನ್ನು ಒಬ್ಬ ಸುಸ್ತಾದ ಲೇಖಕನು ತನ್ನ ಕೆಲಸವನ್ನು ಮೇಲೋಗರದಲ್ಲಿ ಓದುವಂತೆ ಓದಬಾರದು, ಬದಲಾಗಿ ಒಬ್ಬ ಸೆಕ್ಯೂರಿಟಿ ಆಡಿಟರ್ ಓದುವ ರೀತಿಯಲ್ಲಿ ಓದಬೇಕು.
ಇದು ವಿಭಿನ್ನ ರೀತಿಯ ಶಿಸ್ತನ್ನು ಬಯಸುತ್ತದೆ. 'ಆಟೊಮೇಷನ್ ಬಯಾಸ್' (Automation bias) ಎಂಬುದು ನಿಜವಾದ ಸವಾಲು. ಒಂದು ಪರಿಕರವು ಸುಲಲಿತವಾದ, ಸಿಂಟ್ಯಾಕ್ಟಿಕಲಿ ಪರಿಪೂರ್ಣವಾದ ಔಟ್ಪುಟ್ ನೀಡಿದಾಗ, ಮಾನವ ಮೆದುಳು ಸಡಿಲಗೊಳ್ಳುತ್ತದೆ. ಪ್ರೆಸೆಂಟೇಶನ್ ಆಕರ್ಷಕವಾಗಿರುವುದರಿಂದ ನೀವು ಅದು ಸರಿಯಾಗಿದೆ ಎಂದು ಭಾವಿಸುತ್ತೀರಿ. ಆ ಪ್ರವೃತ್ತಿಯನ್ನು ತಡೆಯುವುದೇ ಈಗಿನ ಪ್ರಮುಖ ಕೌಶಲ್ಯವಾಗಿದೆ. ಪ್ರತಿ ಸಲಹೆಯೂ ಸಾಬೀತಾಗುವವರೆಗೆ ಅದು ಕೇವಲ ಒಂದು ಕಲ್ಪನೆ (hypothesis) ಎಂದು ನೀವು ಭಾವಿಸಬೇಕು.
ಯಂತ್ರದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು
AI ಕೋಡಿಂಗ್ ಅಸಿಸ್ಟೆಂಟ್ನಿಂದ ಉಪಯುಕ್ತ ಔಟ್ಪುಟ್ ಪಡೆಯುವುದು ವೇಗವಾಗಿ ಟೈಪ್ ಮಾಡುವುದರ ಬಗ್ಗೆ ಅಲ್ಲ. ಅದು ಯಂತ್ರದ ತರಬೇತಿ ಡೇಟಾ (training data) ಮತ್ತು ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ವಾಸ್ತವದ ನಡುವಿನ ಅಂತರವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದರ ಬಗ್ಗೆ ಆಗಿದೆ. ಕೆಲವು ನಿರ್ದಿಷ್ಟ ಅಭ್ಯಾಸಗಳ ಮೂಲಕ ನೀವು ಆ ಅಂತರವನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.
ನಿಮ್ಮ ಪ್ರಾಂಪ್ಟ್ಗಳಲ್ಲಿ ನಿಖರವಾಗಿರಿ. ಇಲ್ಲಿ ಅಸ್ಪಷ್ಟತೆ ಕವಿತೆಯನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ; ಬದಲಾಗಿ ಬಗ್ಗಳನ್ನು (bugs) ಸೃಷ್ಟಿಸುತ್ತದೆ. "optimize this function" ಎಂಬ ಪ್ರಾಂಪ್ಟ್ ಸಾಮಾನ್ಯ ಸಲಹೆಗಳನ್ನು ನೀಡುತ್ತದೆ. ಬದಲಾಗಿ, "iterated saves ಬದಲಿಗೆ ಒಂದೇ ಬಲ್ಕ್ ಡೇಟಾಬೇಸ್ ಅಪ್ಡೇಟ್ ಬಳಸಲು ಈ Python loop ಅನ್ನು refactor ಮಾಡಿ" ಎಂದು ಬರೆಯಿರಿ. ನಿಖರತೆಯು ಸಾಧ್ಯತೆಗಳ ವ್ಯಾಪ್ತಿಯನ್ನು ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ.
ನೈಜ ಸಂದರ್ಭವನ್ನು (context) ಒದಗಿಸಿ. ನೀವು ಹೇಳದ ಹೊರತು, ನೀವು Kubernetes ಕ್ಲಸ್ಟರ್ನಲ್ಲಿ PostgreSQL 15 ಮೇಲೆ Django 4.2 ಅನ್ನು ರನ್ ಮಾಡುತ್ತಿದ್ದೀರಿ ಅಥವಾ 30 ಸೆಕೆಂಡ್ಗಳ ಸ್ಟ್ರಿಕ್ಟ್ ರಿಕ್ವೆಸ್ಟ್ ಟೈಮೌಟ್ ಹೊಂದಿದ್ದೀರಿ ಎಂಬುದು AI ಗೆ ತಿಳಿಯುವುದಿಲ್ಲ. ನಿಮ್ಮ dependency versions, ನಿಮ್ಮ ಇಂಟರ್ನಲ್ ಲೈಬ್ರರಿಗಳು ಮತ್ತು ನಿಮ್ಮ ಕಡ್ಡಾಯ ಮಿತಿಗಳನ್ನು (constraints) ಅದಕ್ಕೆ ನೀಡಿ. ಸಂದರ್ಭವು ಕೇವಲ ಅಲಂಕಾರವಲ್ಲ; ಅದು ಸುರಕ್ಷತಾ ತಡೆಗೋಡೆಗಳು (guardrails).
ನಿಮ್ಮ ಸ್ವಂತ ದಾಖಲೆಗಳೊಂದಿಗೆ ಉತ್ತರಗಳನ್ನು ಭದ್ರಪಡಿಸಿ. Retrieval-Augmented Generation ಅಥವಾ RAG ಎಂಬುದು ಕೇವಲ ಚಾಟ್ಬಾಟ್ಗಳಿಗಾಗಿ ಬಳಸುವ ಪದವಲ್ಲ. ನಿಮ್ಮ ಅಸಿಸ್ಟೆಂಟ್ ಅನ್ನು ನಿಮ್ಮ ನೈಜ API ಸ್ಪೆಸಿಫಿಕೇಶನ್ಗಳು, ನಿಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರ್ ನಿರ್ಧಾರದ ದಾಖಲೆಗಳು (architecture decision records) ಮತ್ತು ನಿಮ್ಮ ಕೋಡ್ಬೇಸ್ ನಿಯಮಗಳತ್ತ (codebase conventions) ಗಮನಹರಿಸುವಂತೆ ಮಾಡಿ. ಮಾಡೆಲ್ ತರಬೇತಿ ಡೇಟಾದಿಂದ ಊಹಿಸುವ ಬದಲು ನಿಮ್ಮ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ನಿಂದ ಸತ್ಯಗಳನ್ನು ಪಡೆದಾಗ, ಸಾಮಾನ್ಯ ಸಲಹೆ ಮತ್ತು ಬಳಕೆಯ ಮಾಡಬಹುದಾದ ಕೋಡ್ ನಡುವಿನ ಅಂತರವು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ.
ಸಂಕೀರ್ಣ ಕೆಲಸವನ್ನು ಪ್ರತ್ಯೇಕ ಕಾರ್ಯಗಳಾಗಿ ವಿಂಗಡಿಸಿ. ಪ್ರತಿಯೊಂದು ಹಂತವು ಕಿರಿದಾದ ವ್ಯಾಪ್ತಿಯನ್ನು ಹೊಂದಿದ್ದಾಗ ಏಜೆಂಟ್ ಪ್ಯಾಟರ್ನ್ಗಳು (Agent patterns) ಉತ್ತಮವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಒಂದೇ ಬಾರಿಗೆ ಸಂಪೂರ್ಣ ಮೈಕ್ರೋಸರ್ವಿಸ್ ರಿಫ್ಯಾಕ್ಟರ್ (microservice refactor) ಕೇಳಬೇಡಿ. ಮೊದಲು ಡೇಟಾ ಸ್ಕೀಮಾವನ್ನು (data schema) ಕೇಳಿ. ಅದನ್ನು ಪರಿಶೀಲಿಸಿ. ನಂತರ ಮೈಗ್ರೇಷನ್ ಸ್ಕ್ರಿಪ್ಟ್ ಕೇಳಿ. ಅದನ್ನು ಪರಿಶೀಲಿಸಿ. ನಂತರ ಸರ್ವಿಸ್ ಲೇಯರ್ಗೆ (service layer) ಹೋಗಿ.