2026ರ Sonar ಸಮೀಕ್ಷೆಯ ಪ್ರಕಾರ, 88% ಡೆವಲಪರ್ಗಳು AI-ಜನರೇಟೆಡ್ ಕೋಡ್ ತಾಂತ್ರಿಕ ಸಾಲವನ್ನು (technical debt) ಹೆಚ್ಚಿಸುತ್ತಿದೆ ಎಂದು ಹೇಳಿದ್ದಾರೆ, ಮತ್ತು spec-driven development ಬೆಂಬಲಿಗರು ಶಿಸ್ತುಬದ್ಧವಾದ specification ಹಂತವು ಈ ಪ್ರವೃತ್ತಿಯನ್ನು ತಡೆಯಬಲ್ಲದು ಎಂದು ವಾದಿಸುತ್ತಾರೆ.
ಈ ಸಮಸ್ಯೆ ಏಕೆ ಮುಖ್ಯ
ಒಬ್ಬ ಮನುಷ್ಯನಿಗೆ ಅಸ್ಪಷ್ಟವಾದ ಟಿಕೆಟ್ ಬಂದಾಗ, ಅವರು ಸ್ಪಷ್ಟೀಕರಣಕ್ಕಾಗಿ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುತ್ತಾರೆ. ಇದಕ್ಕೆ ವ್ಯತಿರಿಕ್ತವಾಗಿ, ஓர் AI ಏಜೆಂಟ್ ತನ್ನ ಅಂದಾಜಿನ ಮೂಲಕ ಅಸ್ಪಷ್ಟತೆಗಳನ್ನು ತುಂಬುತ್ತದೆ ಮತ್ತು ನಂಬಲರ್ಹವಾಗಿ ಕಾಣುವ ಕೋಡ್ ಅನ್ನು ನೀಡುತ್ತದೆ. ಈ ಸರಿಯಾಗಿದೆ ಎಂಬ ಭ್ರಮೆ ದುಬಾರಿಯಾಗುತ್ತದೆ: ಅದೇ Sonar ಸಮೀಕ್ಷೆಯ ಪ್ರಕಾರ, ಅರ್ಧಕ್ಕಿಂತ ಹೆಚ್ಚು ಪ್ರತಿಕ್ರಿಯೆದಾರರು ಮೂಲಭೂತ ಪರಿசோதனೆಗಳಲ್ಲಿ (basic checks) ಪಾಸಾದರೂ, ಸೂಕ್ಷ್ಮ ದೋಷಗಳನ್ನು ಹೊಂದಿರುವ ಕೋಡ್ ಅನ್ನು ನೋಡಿದ್ದಾರೆ. ಅಂತಹ ದೋಷಗಳು ತಾಂತ್ರಿಕ ಸಾಲವಾಗಿ (technical debt) ಸಂಗ್ರಹವಾಗುತ್ತವೆ, ಇದು ನಂತರದ ಸಮಯದಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ಮರುಸಂಸ್ಕರಿಸುವ (refactor) ಅಗತ್ಯವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಫೀಚರ್ ವಿತರಣೆಯನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ನಿರ್ವಹಣಾ ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.
Spec-driven development ಹೇಗಿರುತ್ತದೆ
Spec-driven development (SDD) ಪ್ರಸ್ತುತ ಕ್ರಮವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. AI ಮಾಡೆಲ್ಗೆ ಕೇವಲ ಒಂದು ಸಂಕ್ಷಿಪ್ತ user story ನೀಡುವ ಬದಲು, ತಂಡವು ವಿವರವಾದ, ಏಜೆಂಟ್-ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ (agent-executable) specification ಅನ್ನು ಬರೆಯುತ್ತದೆ, ಇದು ಕೋಡ್ ಇರುವ ಅದೇ version-control system ನಲ್ಲಿ ಇರುತ್ತದೆ. ಈ spec ಒಂದು 'ಏಕೈಕ ಸತ್ಯದ ಮೂಲ' (single source of truth) ಆಗುತ್ತದೆ—ಇದು ಉದ್ದೇಶ (intent), edge cases, ಕಾರ್ಯಕ್ಷಮತೆಯ ನಿರೀಕ್ಷೆಗಳು ಮತ್ತು AI ಮಾಡೆಲ್ ಪಾಲಿಸಬೇಕಾದ ಯಾವುದೇ ನಿರ್ಬಂಧಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ.
ಈ ಪ್ರಕ್ರಿಯೆಯು ಮನುಷ್ಯನ ವಿನ್ಯಾಸದ ಕೆಲಸವನ್ನು (design work) ಬದಲಿಸುವುದಿಲ್ಲ; ಬದಲಾಗಿ ಅದನ್ನು ಸಂಹಿತೀಕರಿಸುತ್ತದೆ (codifies). ನಿರ್ಧಾರಗಳನ್ನು ಡೆವಲಪರ್ನ ನೆನಪಿನಿಂದ ಒಂದು ನಿರ್ದಿಷ್ಟ ದಾಖಲೆಗೆ ವರ್ಗಾಯಿಸುವ ಮೂಲಕ, ಮನುಷ್ಯರು ಮತ್ತು ಭವಿಷ್ಯದ AI ಏಜೆಂಟ್ಗಳು ಒಂದು ಕೋಡ್ ಒಂದು ನಿರ್ದಿಷ್ಟ ರೀತಿಯಲ್ಲಿ ಏಕೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪತ್ತೆಹಚ್ಚಬಹುದು. Spec ಅನ್ನು ಸಿದ್ಧಪಡಿಸಲು ಆರಂಭದಲ್ಲಿ ಶ್ರಮ ಬೇಕಾಗಬಹುದು, ಆದರೆ ಅಸ್ಪಷ್ಟವಾದ AI ಔಟ್ಪುಟ್ ಅನ್ನು ಡಿಬಗ್ ಮಾಡುವುದು ನಂತರ ಹೆಚ್ಚಿನ ವೆಚ್ಚವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ವರ್ಕ್ಫ್ಲೋ (Workflow) ಬದಲಾವಣೆ
Product backlog – ಐಟಂಗಳನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿರಿಸಿ, ಕೇವಲ ಉದ್ದೇಶ ಮತ್ತು ಉನ್ನತ ಮಟ್ಟದ ಸ್ವೀಕಾರಾರ್ಹ ಮಾನದಂಡಗಳನ್ನು (acceptance criteria) ಮಾತ್ರ ದಾಖಲಿಸಿ. ಈ ಪಟ್ಟಿಯು ಆದ್ಯತೆಗಳನ್ನು (prioritization) ನಿರ್ಧರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
Sprint planning – ತಂಡಗಳು ಒಟ್ಟಾರೆ ಗುರಿಯನ್ನು ಚರ್ಚಿಸಿ Sprint Goal ಅನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ, ಆದರೆ spec ಸಿದ್ಧವಾಗುವವರೆಗೆ ವಿವರವಾದ ಅನುಷ್ಠಾನವನ್ನು (implementation) ಮುಂದೂಡುತ್ತವೆ.
During the sprint – ಕಾರ್ಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ವ್ಯಕ್ತಿಯು ನಿಖರವಾದ, ಮಷೀನ್-ರೀಡಬಲ್ (machine-readable) spec ಅನ್ನು ಬರೆಯುತ್ತಾರೆ. ಈ spec ಇನ್ಪುಟ್ ಫಾರ್ಮ್ಯಾಟ್ಗಳು, ನಿರೀಕ್ಷಿತ ಔಟ್ಪುಟ್ಗಳು, ಎರರ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ ಮತ್ತು ಯಾವುದೇ non-functional ಅಗತ್ಯತೆಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. Spec ಅನ್ನು version-control ಮಾಡುವುದರಿಂದ, ರಿವ್ಯೂಯರ್ಗಳು ಕೋಡ್ನಂತೆಯೇ ಕಾಮೆಂಟ್ ಮಾಡಬಹುದು, ತಿದ್ದುಪಡಿಗಳನ್ನು ಸೂಚಿಸಬಹುದು ಮತ್ತು ಬದಲಾವಣೆಗಳನ್ನು ಅನುಮೋದಿಸಬಹುದು.
Definition of Done – ಕ್ವಾಲಿಟಿ ಗೇಟ್ಗೆ (quality gate) “Spec reviewed and approved” ಎಂಬ ಅಂಶವನ್ನು ಸೇರಿಸಿ. Spec ಅನುಷ್ಠಾನದಂತೆಯೇ (implementation) ಸಮಾನವಾದ ರಿವ್ಯೂ ಮಾನದಂಡಗಳನ್ನು ಪೂರೈಸುವವರೆಗೆ ಯಾವುದೇ ಕೋಡ್ ಪೂರ್ಣಗೊಂಡಿಲ್ಲ ಎಂದು ಪರಿಗಣಿಸಬೇಡಿ.
Kanban adaptation – ಎರಡು ಹೊಸ ಕಾಲಂಗಳನ್ನು ಸೇರಿಸಿ: “Spec Drafted” ಮತ್ತು “Spec Approved.” ಈಗ ಕೆಲಸದ ಐಟಂಗಳು backlog → Sprint Goal → Spec Drafted → Spec Approved → In Progress → Done ಎಂಬ ಹಂತಗಳಲ್ಲಿ ಸಾಗುತ್ತದೆ. ಈ ದೃಶ್ಯ ಬದಲಾವಣೆಯು ಈ ಮೊದಲು ಅಸ್ಪಷ್ಟವಾಗಿದ್ದ ಸಮನ್ವಯ ಹಂತವನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ.
ಈಗಾಗಲೇ specs ಅನ್ನು ಜಾರಿಗೆ ತರುವ ಪರಿಕರಗಳು (Tools)
GitHub Spec Kit ಮತ್ತು AWS Kiro ನಂತಹ ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗಳು ಯಾವುದೇ AI ಕೋಡ್ ಜನರೇಷನ್ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಅಗತ್ಯವಿರುವ ದಾಖಲೆಯನ್ನು (requirements document) ಕೇಳುವಂತಹ ಗೇಟ್ಗಳನ್ನು ಸೇರಿಸಿವೆ. ಇವು AI ಮಾಡೆಲ್ ಅನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ; ಬದಲಾಗಿ ಅಕ್ಷರಶಃ ಅರ್ಥೈಸುವ ಏಜೆಂಟ್ಗಳನ್ನು ಮನುಷ್ಯನ ಉದ್ದೇಶದೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆ ಮಾಡುತ್ತವೆ. Spec ಅನ್ನು ಪೂರ್ವಭಾವಿ ಅಗತ್ಯವನ್ನಾಗಿ (prerequisite) ಮಾಡುವ ಮೂಲಕ, ಈ ಪರಿಕರಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ CI/CD ಪೈಪ್ಲೈನ್ಗಳನ್ನು ಹಾಳುಮಾಡದೆ ಈ ಬದಲಾವಣೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುತ್ತವೆ.
ಸಂಭಾವ್ಯ ವಿರೋಧಗಳು
ವಿಮರ್ಶಕರು, spec ಬರೆಯುವುದು ಈಗಾಗಲೇ ವೇಗವಾಗಿ ಚಲಿಸುತ್ತಿರುವ agile ಕಾರ್ಯದಕ್ಷತೆಯಲ್ಲಿ (cadence) ಅಡೆತಡೆ ಉಂಟುಮಾಡುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತಾರೆ. ಇದಕ್ಕೆ ಪ್ರತಿಯಾಗಿ ನೀಡುವ ವಾದವೆಂದರೆ: ಅಸ್ಪಷ್ಟವಾದ ಪ್ರಾಂಪ್ಟ್ನಿಂದ ಉಂಟಾದ AI-ಜನರೇಟೆಡ್ ಕೋಡ್ ಅನ್ನು ಡಿಬಗ್ ಮಾಡಲು ನಂತರ ವ್ಯಯಿಸುವ ಸಮಯಕ್ಕಿಂತ, spec ಸಿದ್ಧಪಡಿಸಲು ವ್ಯಯಿಸುವ ಸಮಯವು ಬಹಳ ಕಡಿಮೆ ಇರುತ್ತದೆ.
ಅಗತ್ಯತೆಗಳು ಬದಲಾದಂತೆ specifications ಹಳೆಯದಾಗಬಹುದು ಎಂಬುದು ಇನ್ನೊಂದು ಕಳವಳವಾಗಿದೆ. Version-control ಏಕೀಕರಣವು ಇದನ್ನು ಪರಿಹರಿಸುತ್ತದೆ: spec ನಲ್ಲಿನ ಯಾವುದೇ ಬದಲಾವಣೆಯು ಹೊಸ commit ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ, ರಿವ್ಯೂ ಅನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ ಮತ್ತು ತಂಡವು ಸಂಬಂಧಿತ ಕೋಡ್ ಅನ್ನು ಮರು-ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಒತ್ತಾಯಿಸುತ್ತದೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, spec ಅನ್ನು ಕೋಡ್ನಂತೆ ಪರಿಗಣಿಸುವುದು ದಾಖಲಾತಿಯನ್ನು (documentation) ಅಪ್-ಟು-ಡೇಟ್ ಆಗಿಡುತ್ತದೆ.
ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು
ಇದರ ಅಳವಡಿಕೆಯು ಇನ್ನೂ ಆರಂಭಿಕ ಹಂತದಲ್ಲಿದೆ, ಆದರೆ ಇದರ ವೇಗವು ಸ್ಪಷ್ಟವಾಗಿ ಕಾಣಿಸುತ್ತಿದೆ. AI ಕೋಡ್ ಜನರೇಟರ್ಗಳು ಹೆಚ್ಚು ಸಾಮರ್ಥ್ಯಶಾಲಿಯಾಗುತ್ತಿದ್ದಂತೆ, ನಿಖರವಾದ, ಮಷೀನ್-ರೀಡಬಲ್ ಉದ್ದೇಶದ ಅಗತ್ಯವು ಮತ್ತಷ್ಟು ಹೆಚ್ಚಾಗುತ್ತದೆ.
Bottom line: ಅಸ್ಪಷ್ಟ ಪ್ರಾಂಪ್ಟ್ಗಳನ್ನು ನಿರ್ದಿಷ್ಟವಾದ, ರಿವ್ಯೂ ಮಾಡಿದ specifications ಆಗಿ ಪರಿವರ್ತಿಸುವುದು ಒಂದು ಹೆಚ್ಚುವರಿ ಹಂತದಂತೆ ಅನಿಸಬಹುದು, ಆದರೆ ಇದು ಕೇವಲ ಅಂದಾಜನ್ನು ಜವಾಬ್ದಾರಿಯುತ ನಿರ್ಧಾರಗಳನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.