ನಿಮ್ಮ AI ಕೋಡಿಂಗ್ ಸೆಟಪ್ ಒಂದು 'Complicated' ಸಾಧನವಾಗಿದೆ. ನಿಮ್ಮ ಕೋಡ್ಬೇಸ್ 'Complex' ಆಗಿದೆ.
ಹೊಸ AI ಕೋಡಿಂಗ್ ಪರಿಕರಗಳು ಏಜೆಂಟ್ಗಳನ್ನು ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿಸುವ ಭರವಸೆ ನೀಡುತ್ತವೆ. ನೀವು ಕೌಶಲ್ಯಗಳು (skills), ಸೂಪರ್ಪವರ್ಗಳು ಮತ್ತು ಸ್ಪೆಕ್-ಡ್ರಿವನ್ (spec-driven) ಅಭಿವೃದ್ಧಿಗಾಗಿ ಚೌಕಟ್ಟುಗಳನ್ನು (frameworks) ನೋಡುತ್ತೀರಿ. ಈ ಪರಿಕರಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಅವು ಏಜೆಂಟ್ಗಳು ಕೇವಲ ಊಹಿಸುವ ಬದಲು ಒಂದು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅನುಸರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತವೆ.
ಆದರೆ ಇಲ್ಲಿ ಒಂದು ಬಲೆ ಇದೆ. ಒಂದು ಕೆಲಸಕ್ಕಾಗಿ ಉತ್ತಮ ಸೆಟಪ್ ಮಾಡುವುದು ಒಂದು ಸುಸಂಬದ್ಧ ವ್ಯವಸ್ಥೆಯನ್ನು (coherent system) ಸೃಷ್ಟಿಸುತ್ತದೆ ಎಂದು ಜನರು ಭಾವಿಸುತ್ತಾರೆ. ಅದು ನಿಜವಲ್ಲ.
ಏಕೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, Cynefin ಚೌಕಟ್ಟನ್ನು (framework) ಬಳಸಿ. ಇದು ಸಮಸ್ಯೆಗಳನ್ನು ಎರಡು ವಿಧಗಳಾಗಿ ವಿಂಗಡಿಸುತ್ತದೆ: Complicated ಮತ್ತು Complex.
Complicated ಸಮಸ್ಯೆಗಳು ಇವುಗಳಿಗೆ ತಿಳಿದುಕೊಳ್ಳಬಹುದಾದ ಉತ್ತರವಿರುತ್ತದೆ. ಅದನ್ನು ಕಂಡುಹಿಡಿಯಲು ನೀವು ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ಕೌಶಲ್ಯವನ್ನು ಬಳಸುತ್ತೀರಿ. ಉದಾಹರಣೆಗೆ, ಒಂದು ಮಾಡ್ಯೂಲ್ ಅನ್ನು ರಿಫ್ಯಾಕ್ಟರ್ (refactoring) ಮಾಡುವುದು ಅಥವಾ ವ್ಯಾಲಿಡೇಶನ್ ಫಂಕ್ಷನ್ (validation function) ಬರೆಯುವುದು. ಒಮ್ಮೆ ನೀವು ಉತ್ತರವನ್ನು ಕಂಡುಕೊಂಡರೆ, ಅದನ್ನು ಮತ್ತೆ ಮಾಡಬಹುದು. ಹೆಚ್ಚಿನ AI ಕೋಡಿಂಗ್ ಪರಿಕರಗಳು ಇಲ್ಲೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಅವು ಕೆಲಸದ ಘಟಕದ (unit of work) ಮೇಲೆ ಗಮನ ಹರಿಸುತ್ತವೆ. ಅವು ಕಾರ್ಯಗಳನ್ನು ಪುನರಾವರ್ತಿತ ಮತ್ತು ಪರಿಶೀಲಿಸಬಹುದಾದಂತೆ ಮಾಡುತ್ತವೆ.
Complex ಸಮಸ್ಯೆಗಳು ಇವುಗಳಿಗೆ ಮುನ್ಸೂಚನೆ ನೀಡಬಹುದಾದ ಉತ್ತರ ಇರುವುದಿಲ್ಲ. ವ್ಯವಸ್ಥೆಯು ವಿವಿಧ ಭಾಗಗಳ ಜಾಲದಂತಿದೆ. ನೀವು ಕ್ರಮ ಕೈಗೊಂಡ ನಂತರವಷ್ಟೇ ಫಲಿತಾಂಶಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ. ನಲವತ್ತು ಮರ್ಜ್ ಮಾಡಿದ ಬದಲಾವಣೆಗಳು (merged changes) ಆರು ತಿಂಗಳ ನಂತರ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಹಾಳುಮಾಡುತ್ತವೆಯೇ? ಏಜೆಂಟ್ A, ಏಜೆಂಟ್ B ಗೆ ವಿರುದ್ಧವಾಗಿ ವರ್ತಿಸುತ್ತದೆಯೇ? ನೀವು ಕೇವಲ ಒಂದು ಫೈಲ್ ಅನ್ನು ನೋಡಿ ಈ ಉತ್ತರಗಳನ್ನು ಕಂಡುಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ. ಭಾಗಗಳು ಹೇಗೆ ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸುತ್ತವೆ ಎಂಬುದರಿಂದ ಇವು ಹೊರಹೊಮ್ಮುತ್ತವೆ.
ನೀವು Complicated ಪರಿಕರಗಳು Complex ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತವೆ ಎಂದು ನಿರೀಕ್ಷಿಸಿದಾಗ ಈ ಹೊಂದಾಣಿಕೆಯ ಕೊರತೆ (mismatch) ಉಂಟಾಗುತ್ತದೆ.
ಒಂದು ಪರಿಕರವು ಏಜೆಂಟ್ ಅನ್ನು ಪರಿಪೂರ್ಣವಾದ ಫಂಕ್ಷನ್ ಬರೆಯುವಂತೆ ಮಾಡಬಹುದು. ಆದರೆ ಒಂದು ಕೆಲಸವು userId ಅನ್ನು ಬಳಸಿದರೆ ಮತ್ತು ಇನ್ನೊಂದು user_id ಅನ್ನು ಬಳಸಿದರೆ, ವ್ಯವಸ್ಥೆಯು ಕುಸಿಯುತ್ತದೆ. ಪ್ರತ್ಯೇಕವಾಗಿ ನೋಡಿದಾಗ ಎರಡೂ ಕಾರ್ಯಗಳು "ಸರಿಯಾಗಿದ್ದವು". ವೈಫಲ್ಯವು ಹೊರಹೊಮ್ಮುವ ಗುಣವಾಗಿದೆ (emergent). ಅದು ಘಟಕದಲ್ಲಿಲ್ಲ, ಬದಲಾಗಿ ಸಂವಹನದಲ್ಲಿ (interaction) ಅಡಗಿದೆ.
ಬೃಹತ್ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋಗಳು (context windows) ಕೂಡ ಇದನ್ನು ಪರಿಹರಿಸಲಾರವು. ದೊಡ್ಡ ವಿಂಡೋವು ನೀವು ಹೆಚ್ಚು ನೋಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಆದರೆ ನೋಡುವುದು ಎಂದರೆ ತರ್ಕಬದ್ಧವಾಗಿ ನಿರ್ಧರಿಸುವುದು (deducing) ಎಂದಲ್ಲ. ನೀವು ಇಡೀ ಕೋಡ್ಬೇಸ್ ಅನ್ನು ಓದಬಹುದು, ಆದರೂ ಪ್ರೊಡಕ್ಷನ್ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಅದು ডেಡ್ಲಾಕ್ (deadlock) ಆಗುತ್ತದೆಯೇ ಎಂದು ತಿಳಿಯಲು ಸಾಧ್ಯವಾಗದಿರಬಹುದು. ಅದು ರನ್ಟೈಮ್ ಗುಣಲಕ್ಷಣವಾಗಿದೆ (runtime property).
ಎರಡನ್ನೂ ಹೇಗೆ ನಿಭಾಯಿಸುವುದು:
- Complicated ಪದರಕ್ಕಾಗಿ: ಕೌಶಲ್ಯಗಳು (skills), ಸ್ಪೆಕ್ಸ್ (specs) ಮತ್ತು TDD ಬಳಸಿ. ಇವು ಏಜೆಂಟ್ನ ವೈಯಕ್ತಿಕ ಔಟ್ಪುಟ್ ಅನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿದ್ದಂತೆ ಮಾಡುತ್ತವೆ.
- Complex ಪದರಕ್ಕಾಗಿ: probe-sense-respond ವಿಧಾನವನ್ನು ಬಳಸಿ. ಯಾವುದು ಮುರಿಯುತ್ತದೆ ಎಂದು ನೀವು ಊಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ನೀವು ಮರ್ಜ್ ಮಾಡಬೇಕು, ಡಿಪ್ಲಾಯ್ ಮಾಡಬೇಕು ಮತ್ತು ಗಮನಿಸಬೇಕು. ಭಾಗಗಳು ಒಂದಕ್ಕೊಂದು ಸೇರಿದಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ತಿಳಿಯಲು ಇಂಟಿಗ್ರೇಷನ್ ಟೆಸ್ಟ್ಗಳು (integration tests) ಮತ್ತು ಅಬ್ಸರ್ವೇಬಿಲಿಟಿ (observability) ಬಳಸಿ.
ಉತ್ತಮ ಸ್ಪೆಕ್ (spec) ನಿಮ್ಮ ವ್ಯವಸ್ಥೆಯನ್ನು ಸ್ಥಿರವಾಗಿಸುತ್ತದೆ ಎಂಬ ಭರವಸೆಗೆ ಮರುಳಾಗಬೇಡಿ. ಸ್ಪೆಕ್ಗಳು ಘಟಕವನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿಸುತ್ತವೆ. ಅವು ವ್ಯವಸ್ಥೆಯನ್ನು ಸುಸಂಬದ್ಧವಾಗಿಸುವುದಿಲ್ಲ.
ನಿಮ್ಮ ವಿಧಾನವನ್ನು ಡೊಮೇನ್ಗೆ (domain) ಅನುಗುಣವಾಗಿ ಹೊಂದಿಸಿ. ಘಟಕವನ್ನು ಪರಿಪೂರ್ಣಗೊಳಿಸಲು ಪರಿಕರಗಳನ್ನು ಬಳಸಿ. ವ್ಯವಸ್ಥೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಯೋಗಗಳನ್ನು (experimentation) ಬಳಸಿ.
Optional learning community: https://t.me/GyaanSetuAi
