20 ವರ್ಷ ಹಳೆಯ ವಿಮೆ ಪ್ಲಾಟ್ಫಾರ್ಮ್ನ ಲೇಖಕರು 108 ಸಪೋರ್ಟ್ ಟಿಕೆಟ್ಗಳನ್ನು ಕಸ್ಟಮ್ AI-ಏಜೆಂಟ್ ಪೈಪ್ಲೈನ್ ಮೂಲಕ ನಡೆಸಿದ್ದಾರೆ ಮತ್ತು ಅದರ ಫಲಿತಾಂಶವು ಹಿರಿಯ-ಡೆವಲಪರ್ ಮಾಡುವ ಹಲವಾರು ಗಂಟೆಗಳ ಕೆಲಸವನ್ನು ಕೆಲವೇ ನಿಮಿಷಗಳ ಕೆಲಸವನ್ನಾಗಿ ಮಾಡುವ ವರ್ಕ್ಫ್ಲೋ ಆಗಿದೆ. ಇದು ಎಂಟರ್ಪ್ರೈಸ್ಗಳು ತಮ್ಮ ಲೆಗಸಿ (legacy) ಕೋಡ್ ಅನ್ನು ಹೇಗೆ ಜೀವಂತವಾಗಿಡುತ್ತವೆ ಎಂಬುದನ್ನು ಮರುರೂಪಿಸುವ ಬದಲಾವಣೆಯಾಗಿದೆ.
ಹೊಸ ಕೋಡ್ಗಿಂತ ಲೆಗಸಿ ಸಿಸ್ಟಮ್ಗಳು ಏಕೆ ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿವೆ
ಇಲ್ಲಿ ಉಲ್ಲೇಖಿಸಲಾದ ವಿಮೆ ಅಪ್ಲಿಕೇಶನ್ 2.3 ಮಿಲಿಯನ್ ಸಾಲುಗಳ ಕೋಡ್ ಮತ್ತು ಸುಮಾರು 1,000 PL/SQL ಪ್ಯಾಕೇಜ್ಗಳಿರುವ ಒಂದು ಮೊನೊಲಿತ್ (monolith). ಅದರ ಗಾತ್ರವೇ ಯಾವುದೇ ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಇಡೀ ಕೋಡ್ಬೇಸ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದನ್ನು ಅಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ. ಅದರ ಜೊತೆಗೆ ಗ್ರಾಹಕ-ನಿರ್ದಿಷ್ಟ ಕಾನ್ಫಿಗರೇಶನ್ ಪ್ಯಾರಾಮೀಟರ್ಗಳ ಗೋಜಲು, ಚದುರಿಹೋಗಿರುವ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಮತ್ತು 2017 ರಿಂದ ವಿಸ್ತರಿಸಿರುವ ಟಿಕೆಟ್ ಆರ್ಕೈವ್ ಇರುವುದರಿಂದ, ನಿಜವಾದ ಸವಾಲು ಕೋಡ್ ಬರೆಯುವುದಲ್ಲ, ಬದಲಾಗಿ "ಸಂದರ್ಭವನ್ನು (context) ಹುಡುಕುವುದು" ಆಗಿರುತ್ತದೆ.
ಸಾಮಾನ್ಯ ಆಧುನಿಕ AI ಪ್ರಚಾರವು ಗ್ರೀನ್ಫೀಲ್ಡ್ (greenfield) ಪ್ರಾಜೆಕ್ಟ್ಗಳಿಗಾಗಿ ಹೊಸ ಕೋಡ್ ಜನರೇಟ್ ಮಾಡುವುದರ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಕಷ್ಟದ ಭಾಗ PL/SQL ನ ಸಿಂಟ್ಯಾಕ್ಸ್ (syntax) ಅಲ್ಲ, ಬದಲಾಗಿ ನಿಖರವಾದ ಲಾಜಿಕ್, ಸಂಬಂಧಿತ ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಮೊದಲು ವಿವರಿಸಿದ ಐತಿಹಾಸಿಕ ಟಿಕೆಟ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು. ಅನುಭವಿ ಡೆವಲಪರ್ GitLab, SVN, ವಿಕಿಗಳು ಮತ್ತು ಹಳೆಯ ಸಪೋರ್ಟ್ ಟಿಕೆಟ್ಗಳಿಂದ ಸುಳಿವುಗಳನ್ನು ಜೋಡಿಸಲು ಗಂಟೆಗಟ್ಟಲೆ ಸಮಯ ವ್ಯಯಿಸಬಹುದು. AI ಏಜೆಂಟ್ ಇದೇ ಕೆಲಸವನ್ನು ನಿಮಿಷಗಳಲ್ಲಿ ಮಾಡುತ್ತದೆ.
ಅನುಷ್ಠಾನದಲ್ಲಿನ ವರ್ಕ್ಫ್ಲೋ
ಹೊಸ ಟಿಕೆಟ್ ಬಂದಾಗ, ಲೇಖಕರು ಕೇವಲ ಒಂದು ಕಮಾಂಡ್ ರನ್ ಮಾಡುತ್ತಾರೆ. ನಂತರ ಏಜೆಂಟ್ ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಮಾಡುತ್ತದೆ:
- ಟಿಕೆಟ್-ಸಿಸ್ಟಮ್ API ಮೂಲಕ ಟಿಕೆಟ್ ಪಠ್ಯ ಮತ್ತು ಲಗತ್ತಿಸಲಾದ ಯಾವುದೇ ಫೈಲ್ಗಳನ್ನು ಪಡೆಯುತ್ತದೆ.
- ಹಿಂದಿನ ಸಮಾನ ಪ್ರಕರಣಗಳನ್ನು ಹೊರತರಲು ಇಡೀ ಟಿಕೆಟ್ ಆರ್ಕೈವ್ನಲ್ಲಿ ಕೀವರ್ಡ್ ಮತ್ತು ವೆಕ್ಟರ್ ಸರ್ಚ್ ಮಾಡುತ್ತದೆ.
- ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ SQL ಸ್ಕ್ರಿಪ್ಟ್ಗಳ ವೈಯಕ್ತಿಕ ಲೈಬ್ರರಿಯನ್ನು ಪ್ರಶ್ನಿಸುತ್ತದೆ (queries).
- ವರ್ಷನ್-ಕಂಟ್ರೋಲ್ ಸಿಸ್ಟಮ್ಗಳಲ್ಲಿ (GitLab ಅಥವಾ SVN) ಕೋಡ್ ಇತಿಹಾಸವನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ.
ಎಲ್ಲಾ ಸಂಶೋಧನೆಗಳನ್ನು ಒಂದು ಫೈಲ್ನಲ್ಲಿ ಸಂಕಲಿಸಲಾಗುತ್ತದೆ, ಇದು ಮುಂದಿನ ಹಂತವನ್ನು ಸಹ ಸೂಚಿಸುತ್ತದೆ—ಸಾಮಾನ್ಯವಾಗಿ ಕೋಡ್ ಫಿಕ್ಸ್, ಗ್ರಾಹಕರಿಗೆ ಕಳುಹಿಸಲು ಕರಡು ಉತ್ತರ ಅಥವಾ ಹೆಚ್ಚಿನ ರೋಗನಿರ್ಣಯಕ್ಕಾಗಿ (diagnostics) ವಿನಂತಿ.
ಬಿಲ್ಟ್-ಇನ್ ಸಾಮರ್ಥ್ಯಗಳು
ಲೇಖಕರು ಏಜೆಂಟ್ಗಾಗಿ 24 "ಕೌಶಲಗಳನ್ನು" (skills) ವ್ಯಾಖ್ಯಾನಿಸಿದ್ದಾರೆ, ಇವುಗಳನ್ನು ನಾಲ್ಕು ವರ್ಗಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ:
- ಸಂದರ್ಭದ ಪ್ರವೇಶ (Context access) – ಸಂಬಂಧಿತ ಸತ್ಯಗಳನ್ನು ಪಡೆಯಲು APIಗಳು, ಮ್ಯಾನುಯಲ್ಗಳು ಮತ್ತು ಡೇಟಾಬೇಸ್ಗಳನ್ನು ಓದುವುದು.
- ಡೊಮೇನ್ ಜ್ಞಾನ (Domain knowledge) – ವಿಮೆ ಅಕೌಂಟಿಂಗ್ ನಿಯಮಗಳು ಮತ್ತು ಸಿಸ್ಟಮ್ನ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಅರ್ಥೈಸಿಕೊಳ್ಳುವುದು.
- ಬರವಣಿಗೆ (Writing) – PL/SQL ಸ್ನಿಪ್ಪೆಟ್ಗಳನ್ನು (snippets) ಜನರೇಟ್ ಮಾಡುವುದು ಮತ್ತು ಅವುಗಳನ್ನು ನಿಯೋಜನೆಗಾಗಿ (deployment) ಪ್ಯಾಕೇಜ್ ಮಾಡುವುದು.
- ಮೆಟಾ (Meta) – ಮಾದರಿಗಳನ್ನು (patterns) ಗುರುತಿಸುವುದು ಮತ್ತು ಅಗತ್ಯವಿದ್ದಾಗ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೊಸ ಕೌಶಲಗಳನ್ನು ರಚಿಸುವುದು.
ಈ ಕೌಶಲಗಳು ಏಜೆಂಟ್ ಅನ್ನು ಎಂದೂ ಮಲಗದ ಜೂನಿಯರ್ ಇಂಜಿನಿಯರ್ನಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತವೆ, ಇದು ಟಿಕೆಟ್ ಉಲ್ಲೇಖಿಸುವ ನಿಖರವಾದ ಕೋಡ್ ಸಾಲು ಅಥವಾ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ತಕ್ಷಣವೇ ತೋರಿಸುತ್ತದೆ.
ಲೂಪ್ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಸುರಕ್ಷತಾ ಜಾಲಗಳು
ಪ್ರೊಡಕ್ಷನ್ ಪರಿಸರದಲ್ಲಿ ಆಟೊಮೇಷನ್ ಸುರಕ್ಷತಾ ಕ್ರಮಗಳನ್ನು ಬಯಸುತ್ತದೆ. ಲೇಖಕರು ಎರಡು ಸರಳ ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸುತ್ತಾರೆ:
- ಸ್ಟ್ಯಾಟಿಕ್ ವ್ಯಾಲಿಡೇಶನ್ (Static validation) – ಪ್ರತಿಯೊಂದು ಜನರೇಟ್ ಮಾಡಿದ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಲೈವ್ ಸ್ಕೀಮಾದ ವಿರುದ್ಧ
EXPLAIN PLANಮೂಲಕ ರನ್ ಮಾಡಲಾಗುತ್ತದೆ. ಇದು ಕೋಡ್ ಅನ್ನು ವಾಸ್ತವವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸದೆ ಸಿಂಟ್ಯಾಕ್ಸ್ ಅಥವಾ ತಾರ್ಕಿಕ ದೋಷಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. - ಡ್ಯುಯಲ್-ಮೋಡಲ್ ಕನ್ಫರ್ಮೇಶನ್ (Dual-model confirmation) – ಅಪಾಯಕಾರಿ ಎಂದು ಪರಿಗಣಿಸಲಾದ ಯಾವುದೇ ಬದಲಾವಣೆಯನ್ನು ಎರಡನೇ, ಸ್ವತಂತ್ರ AI ಏಜೆಂಟ್ ಪರಿಶೀಲಿಸುತ್ತದೆ. ಎರಡೂ ಮಾಡೆಲ್ಗಳು ಒಂದೇ ತೀರ್ಮಾನಕ್ಕೆ ಬಂದರೆ, ಲೇಖಕರು ಮುಂದುವರಿಯುತ್ತಾರೆ; ಇಲ್ಲದಿದ್ದರೆ, ಟಿಕೆಟ್ ಅನ್ನು ಮ್ಯಾನುಯಲ್ ಪರಿಶೀಲನೆಗಾಗಿ ಏಸ್ಕಲೇಟ್ ಮಾಡಲಾಗುತ್ತದೆ.
ಈ ಪರಿசோதனೆಗಳು ಪ್ರಕ್ರಿಯೆಯು ಕಪ್ಪು ಪೆಟ್ಟಿಗೆಯಾಗದಂತೆ (black box) ತಡೆಯುತ್ತವೆ, ಇದರಿಂದಾಗಿ ಅನಿರೀಕ್ಷಿತವಾಗಿ ವಿಮೆಯ ಪ್ರಮುಖ ವಹಿವಾಟುಗಳಿಗೆ ತೊಂದರೆಯಾಗುವುದಿಲ್ಲ.
ಸಂಕಲಿತ ಪ್ರಯೋಜನಗಳು
ಪ್ರತಿಯೊಂದು ಟಿಕೆಟ್ನ ಔಟ್ಪುಟ್ ಅನ್ನು ಟಿಕೆಟ್ ರೆಕಾರ್ಡ್ಗೆ ಮರಳಿ ಲಗತ್ತಿಸಲಾಗುತ್ತದೆ, ಇದು ಒಂದು ಜೀವಂತ ಜ್ಞಾನ ಕೋಶವನ್ನು (knowledge base) ಸೃಷ್ಟಿಸುತ್ತದೆ. ತಿಂಗಳುಗಳು ಅಥವಾ ವರ್ಷಗಳ ನಂತರ ಇದೇ ರೀತಿಯ ಸಮಸ್ಯೆ ಮತ್ತೆ ಎದುರಾದಾಗ, ಏಜೆಂಟ್ ಹಿಂದಿನ ಪರಿಹಾರವನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ಅದಕ್ಕೆ ಕಾರಣವಾದ ತರ್ಕವನ್ನೂ ಓದಬಲ್ಲದು. ಪರಿಣಾಮಕಾರಿಯಾಗಿ, ಪ್ರತಿಯೊಂದು ಪರಿಹರಿಸಿದ ಟಿಕೆಟ್ ಮುಂದಿನ ಟಿಕೆಟ್ಗಳಿಗಾಗಿ ತರಬೇತಿ ಡೇಟಾ ಆಗುತ್ತದೆ, ಇದು ಚಕ್ರವನ್ನು ಮತ್ತಷ್ಟು ವೇಗಗೊಳಿಸುತ್ತದೆ.
ಪ್ರಾಮಾಣಿಕ ಮಿತಿಗಳು
- ಮ್ಯಾನುಯಲ್ ಟೆಸ್ಟಿಂಗ್ ಇಂದಿಗೂ ಇದೆ – ಲೇಖಕರು ಬದಲಾವಣೆಗಳನ್ನು ನಿಯೋಜಿಸುವ ಮೊದಲು ಇನ್ನೂ ಟೆಸ್ಟ್ ಎನ್ವಿರಾನ್ಮೆಂಟ್ನಲ್ಲಿ ಪರಿಶೀಲಿಸುತ್ತಾರೆ.
- ಕಠಿಣ-ನಿಲುಗಡೆ ಮೆಟ್ರಿಕ್ಸ್ ಇಲ್ಲ (No hard-stop metrics) – ಉಳಿತಾಯವಾದ ಸಮಯವು ಗಣನೀಯವಾಗಿ ಕಂಡರೂ, ಲೇಖಕರು ನಿಖರವಾದ ಗಂಟೆಗಳ ಕಡಿತವನ್ನು ಪ್ರಮಾಣೀಕರಿಸಿಲ್ಲ.
- ವೈಯಕ್ತಿಕ ಸೆಟಪ್ – ಪ್ರಸ್ತುತ ಅನುಷ್ಠಾನವು ಒಂದೇ ವರ್ಕ್ಸ್ಟೇಷನ್ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ; ಇದನ್ನು ಒಂದು ತಂಡದಾದ್ಯಂತ ವಿಸ್ತರಿಸಲು ಹೆಚ್ಚುವರಿ ಎಂಜಿನಿಯರಿಂಗ್ ಅಗತ್ಯವಿರುತ್ತದೆ.
ಈ ನಿರ್ಬಂಧಗಳು ಈ ವಿಧಾನವನ್ನು ತಕ್ಷಣವೇ ಬಳಸಬಹುದಾದ (turnkey) ಉತ್ಪನ್ನವಾಗದಂತೆ ತಡೆಯುತ್ತವೆ, ಆದರೆ ಅವು ಮೂಲ ಒಳನೋಟವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದಿಲ್ಲ: AI ಸಂದರ್ಭ ಸಂಗ್ರಹಣೆಯನ್ನು ಗಂಟೆಗಳಿಂದ ನಿಮಿಷಗಳಿಗೆ ಕುಗ್ಗಿಸಬಲ್ಲದು.
ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು
ಲೇಖಕರ ಪ್ರಯೋಗವು ವಾಣಿಜ್ಯ ಕೊಡುಗೆಗಿಂತ ಹೆಚ್ಚಾಗಿ ಒಂದು ಪ್ರೂಫ್-ಆಫ್-ಕನ್ಸೆಪ್ಟ್ (proof-of-concept) ಆಗಿದೆ. ಮುಂದಿನ ತಾರ್ಕಿಕ ಹಂತಗಳು ಇವುಗಳನ್ನು ಒಳಗೊಂಡಿವೆ:
- Formalizing metrics – tracking ticket resolution time before and after the AI pipeline to build a business case.
- Team deployment – packaging the agent as a shared service so that multiple engineers can benefit from the same knowledge base.
- Integration with CI/CD – feeding validated scripts directly into a continuous-integration pipeline could close the loop from ticket to production without manual hand-off.
If these extensions succeed, the model could become a template for other enterprises wrestling with massive, entrenched codebases.
Takeaway
The real value of AI in legacy environments is not in auto-writing new code but in instantly surfacing the right context. By turning a senior developer’s hours of detective work into a few minutes, an AI-agent workflow can keep aging systems functional, reduce support costs, and gradually build a self-reinforcing knowledge repository. The experiment shows that, for legacy software, the biggest productivity boost comes from collapsing the search for answers, not from generating fresh code.