ವರ್ಷಗಳಿಂದ, ಕೃತಕ ಬುದ್ಧಿಮತ್ತೆ (AI) ಎಡಿಟರ್ನಲ್ಲಿ ನಿಮ್ಮ ಪಕ್ಕದಲ್ಲಿ ಕುಳಿತು ಮುಂದೇನಾಗಬಹುದು ಎಂದು ಊಹಿಸುತ್ತಿತ್ತು. ನೀವು ಒಂದು ಸಾಲನ್ನು ಬರೆಯುತ್ತಿದ್ದರೆ; ಅದು ಮುಂದಿನ ಸಾಲನ್ನು ಸೂಚಿಸುತ್ತಿತ್ತು. ಆದರೆ ಆರ್ಕಿಟೆಕ್ಚರ್ (architecture), ಡಿಬಗ್ಗಿಂಗ್ (debugging) ಮತ್ತು ಸಿಂಟ್ಯಾಕ್ಸ್ (syntax) ಎಲ್ಲವೂ ನಿಮ್ಮ ವಶದಲ್ಲೇ ಇರುತ್ತಿದ್ದವು. ಆ ವ್ಯವಸ್ಥೆಯು ಈಗ ಮುಕ್ತಾಯಗೊಂಡಿದೆ.
ನಾವು 'Intent-Driven Development' ಕಡೆಗೆ ಸಾಗುತ್ತಿದ್ದೇವೆ. ನೀವು ಲೂಪ್ಗಳು (loops) ಮತ್ತು ಕಂಡಿಷನಲ್ಗಳನ್ನು (conditionals) ಟೈಪ್ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತೀರಿ. ಬದಲಾಗಿ, ನಿಮಗೆ ಬೇಕಾದ ಫಲಿತಾಂಶವನ್ನು ವಿವರಿಸುತ್ತೀರಿ. ಒಂದು ಏಜೆಂಟ್ (agent) ಆ ಗುರಿಯನ್ನು ಗ್ರಹಿಸುತ್ತದೆ, ಹಂತಗಳನ್ನು ಯೋಜಿಸುತ್ತದೆ, ಕೋಡ್ ಬರೆಯುತ್ತದೆ, ಪರೀಕ್ಷೆಗಳನ್ನು (tests) ನಡೆಸುತ್ತದೆ ಮತ್ತು ನೀವು ಫಲಿತಾಂಶವನ್ನು ನೋಡುವ ಮೊದಲೇ ತನ್ನದೇ ಆದ ತಪ್ಪುಗಳನ್ನು ಸರಿಪಡಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಕೀಬೋರ್ಡ್ ಇನ್ನು ಮುಂದೆ ಪ್ರಾಥಮಿಕ ಸಾಧನವಲ್ಲ; ಸ್ಪಷ್ಟವಾದ ಆಲೋಚನೆಯೇ (Clear thinking) ಮುಖ್ಯ ಸಾಧನವಾಗುತ್ತದೆ.
ಸಾಲು-दर-ಸಾಲು ಕೋಡಿಂಗ್ನ ಅಂತ್ಯ (The End of Line-by-Line Coding)
ಹಳೆಯ ಕೆಲಸದ ವಿಧಾನವು ಪ್ರತಿಯೊಂದು ಉದ್ದೇಶವನ್ನು ಕಂಪೈಲರ್ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಒಂದು ನಿರ್ದಿಷ್ಟ ಭಾಷೆಗೆ ಅನುವಾದಿಸಲು ನಿಮ್ಮನ್ನು ಒತ್ತಾಯಿಸುತ್ತಿತ್ತು. ನೀವು ವ್ಯವಹಾರದ ಅಗತ್ಯತೆಯನ್ನು (business requirement) ನಿಮ್ಮ ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಂಡು, ನಂತರ ಅದನ್ನು ಮ್ಯಾನುಯಲ್ ಆಗಿ ಫಂಕ್ಷನ್ಗಳು, ಇಂಪೋರ್ಟ್ಗಳು, ಎರರ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ ಮತ್ತು ಟೆಸ್ಟ್ ಕೇಸ್ಗಳಾಗಿ ವಿಭಜಿಸುತ್ತಿದ್ದಿರಿ. Intent-Driven Development ಆ ಅನುವಾದದ ಹಂತವನ್ನು ಇಲ್ಲದಂತೆ ಮಾಡುತ್ತದೆ.
ಉದಾಹರಣೆಗೆ, ನೀವು ಪೇಮೆಂಟ್ ವೆಬ್ಹೂಕ್ (payment webhook) ಅನ್ನು ಇಂಟಿಗ್ರೇಟ್ ಮಾಡಬೇಕೆಂದು ಭಾವಿಸೋಣ. ಹಿಂದೆ, ನೀವು ರೂಟ್ ಹ್ಯಾಂಡ್ಲರ್ ಬರೆಯುತ್ತಿರಿ, ಪೇಲೋಡ್ ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡುತ್ತಿರಿ, ಸಿಗ್ನೇಚರ್ ಅನ್ನು ವ್ಯಾಲಿಡೇಟ್ ಮಾಡುತ್ತಿರಿ, ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಒಳಗಡೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡುತ್ತಿರಿ ಮತ್ತು ರಸೀದಿ ಇಮೇಲ್ ಅನ್ನು ಕ್ಯೂ (queue) ಮಾಡುತ್ತಿರಿ. ಈಗ ನೀವು ಕೇವಲ ಅಗತ್ಯತೆಯನ್ನು ವಿವರಿಸಿದರೆ ಸಾಕು: “ಬರುತ್ತಿರುವ Stripe webhook ಅನ್ನು ವ್ಯಾಲಿಡೇಟ್ ಮಾಡಿ, ಈvent ಅನ್ನು ಐಡೆಂಪೊಟೆಂಟ್ ಆಗಿ (idempotently) ದಾಖಲಿಸಿ ಮತ್ತು ರಸೀದಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿ. ಡೇಟಾಬೇಸ್ ಬರೆಯುವಿಕೆ ವಿಫಲವಾದರೆ ರೋಲ್ ಬ್ಯಾಕ್ (Roll back) ಮಾಡಿ.” ಏಜೆಂಟ್ ಹ್ಯಾಂಡ್ಲರ್ ಅನ್ನು ಬರೆಯುತ್ತದೆ, ಪಾರ್ಸಿಂಗ್ ಸ್ಟ್ರಾಟಜಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ರಿಟ್ರೈ ಲಾಜಿಕ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಟೆಸ್ಟ್ಗಳನ್ನು ತಯಾರಿಸುತ್ತದೆ. ನಿಮ್ಮ ಪಾತ್ರವು ಲೇಖಕನಿಂದ (author) ನಿರ್ದೇಶಕನಾಗಿ (director) ಬದಲಾಗುತ್ತದೆ.
ಇದು ಕೆಲಸ ಮಾಡುವುದು ಏಜೆಂಟ್ ಕೇವಲ ಕೋಡ್ ಜನರೇಟ್ ಮಾಡುವುದಕ್ಕೆ ನಿಲ್ಲಿಸದ ಕಾರಣದಿಂದಾಗಿ ಮಾತ್ರ. ಅದು ಒಂದು ಲೂಪ್ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಏಜೆಂಟ್ ಲೂಪ್ನ ಒಳಗಡೆ (Inside the Agent Loop)
ಮುಖ್ಯ ಕೆಲಸವು ಈಗ ಮನುಷ್ಯನ ಟೈಪಿಂಗ್ ಅಥವಾ ಮ್ಯಾನುಯಲ್ ಡಿಬಗ್ಗಿಂಗ್ ಅಲ್ಲ. ಇದು ಜನರೇಷನ್ (generation) ಮತ್ತು ವ್ಯಾಲಿಡೇಶನ್ (validation) ನಡುವಿನ ಒಂದು ಬಿಗಿಯಾದ ಚಕ್ರವಾಗಿದೆ. ಏಜೆಂಟ್ ಕೋಡ್ ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಅದನ್ನು ನಿಮ್ಮ ಟೆಸ್ಟ್ ಸೂಟ್ ಮೂಲಕ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ, ಔಟ್ಪುಟ್ ಅನ್ನು ಓದುತ್ತದೆ ಮತ್ತು ವಿಫಲತೆಗಳನ್ನು ತಾನೇ ಸರಿಪಡಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಮಿಸ್ಸಿಂಗ್ ಇಂಪೋರ್ಟ್ ಆಗಿರಲಿ, ಟೈಪ್ ಮಿಸ್ಮ್ಯಾಚ್ ಆಗಿರಲಿ ಅಥವಾ ಫೈಲಿಂಗ್ ಅಸರ್ಷನ್ ಆಗಿರಲಿ — ಏಜೆಂಟ್ ಸ್ಟ್ಯಾಕ್ ಟ್ರೇಸ್ ಅನ್ನು ನೋಡಿ, ಫೈಲ್ ಅನ್ನು ಎಡಿಟ್ ಮಾಡಿ ಮತ್ತು ಸೂಟ್ ಅನ್ನು ಮರುಪ್ರದರ್ಶಿಸುತ್ತದೆ. ನೀವು ಆ ಲೂಪ್ನಲ್ಲಿದ್ದೀರಾ? ಇಲ್ಲ, ಈ ಚಕ್ರವು ಯಂತ್ರದ ವೇಗದಲ್ಲಿ ನಡೆಯುತ್ತದೆ.
ಲೂಪ್本身 ವಿಫಲವಾದಾಗ ಮಾತ್ರ ನೀವು ಮಧ್ಯಪ್ರವೇಶಿಸುತ್ತೀರಿ. ಬಹುಶಃ ಏಜೆಂಟ್ ಎರಡು ಡಿಪೆಂಡೆನ್ಸಿಗಳ ನಡುವಿನ ಸಂಘರ್ಷವನ್ನು ಪರಿಹರಿಸಲು ಸಾಧ್ಯವಾಗದಿರಬಹುದು, ಅಥವಾ ಅದು ಯೂನಿಟ್ ಟೆಸ್ಟ್ಗಳನ್ನು ಪಾಸಾಗಿಸುವ ಆದರೆ ಉನ್ನತ ಮಟ್ಟದ ವ್ಯವಹಾರ ನಿಯಮಗಳನ್ನು ಉಲ್ಲಂಘಿಸುವ ಕೋಡ್ ಅನ್ನು ಪದೇ ಪದೇ ಸೃಷ್ಟಿಸುತ್ತಿರಬಹುದು. ಅಂತಹ ಗಡಿಗಳಲ್ಲಿ ಮಾನವ ನಿರ್ಧಾರವು (human judgment) ಇಂದಿಗೂ ಮುಖ್ಯವಾಗಿದೆ.
ನಿಮ್ಮ ನಿಜವಾದ ಕೆಲಸ: ನಿರ್ಬಂಧಗಳ ವಿನ್ಯಾಸಕ ಮತ್ತು ಎಡ್ಜ್-ಕೇಸ್ ಹುಡುಕುವವರು
ಯಂತ್ರವೇ ಫಂಕ್ಷನ್ಗಳನ್ನು ಬರೆಯುತ್ತಿದ್ದರೆ, ನಿಮಗಾಗಿ ಏನು ಉಳಿದಿದೆ? ಎರಡು ವಿಷಯಗಳು, ಮತ್ತು ಅವು ಸಿಂಟ್ಯಾಕ್ಸ್ ಟೈಪ್ ಮಾಡುವುದಕ್ಕಿಂತ ಕಠಿಣವಾಗಿವೆ.
ಮೊದಲನೆಯದಾಗಿ, ಏಜೆಂಟ್ ಸರಿಯಾದ ಹಾದಿಯಲ್ಲಿರುವಂತೆ ನೀವು ನಿರ್ಬಂಧಗಳನ್ನು (constraints) ಬರೆಯುತ್ತೀರಿ. ಏಜೆಂಟ್ ಬಳಿ ವಿಶಾಲವಾದ ಜ್ಞಾನವಿರುತ್ತದೆ ಆದರೆ ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಪರಿಸರದ ಬಗ್ಗೆ ತಿಳುವಳಿಕೆ ಇರುವುದಿಲ್ಲ. ನೀವು ಅದಕ್ಕೆ ಹೀಗೆ ಹೇಳಬೇಕು: “ಕೇವಲ ಇಂಟರ್ನಲ್ ಬಿಲ್ಲಿಂಗ್ API ಅನ್ನು ಬಳಸಿ, ಎಂದಿಗೂ ರ ಕಾರ್ಡ್ ಟೋಕನ್ಗಳನ್ನು ಲಾಗ್ ಮಾಡಬೇಡಿ ಮತ್ತು ರೆಸ್ಪಾನ್ಸ್ ಲೇಟೆನ್ಸಿಯನ್ನು ಇನ್ನೂರಿ ಮಿಲಿಸೆಕೆಂಡ್ಗಳಿಗಿಂತ ಕಡಿಮೆ ಇರಿಸಿ.” ಈ ಗಡಿಗಳು ಕೇವಲ ಸಾಧಾರಣ ಪ್ರಾಂಪ್ಟ್ಗಳಲ್ಲ. ಅವು ಯಶಸ್ಸು ಅಥವಾ ವೈಫಲ್ಯವನ್ನು ನಿರ್ಧರಿಸುವ ಸ್ಪೆಸಿಫಿಕೇಶನ್ಗಳು (specifications).
ಎರಡನೆಯದಾಗಿ, ಏಜೆಂಟ್ ವಿಫಲವಾಗುವ ಹತ್ತು ಪ್ರತಿಶತ ಪ್ರಕರಣಗಳನ್ನು (edge cases) ನೀವು ಪತ್ತೆಹಚ್ಚುತ್ತೀರಿ. ಏಜೆಂಟ್ಗಳು ಸಾಮಾನ್ಯ ಹಾದಿಯನ್ನು ಚೆನ್ನಾಗಿ ನಿರ್ವಹಿಸುತ್ತವೆ. ಆದರೆ ಅವು ಸೂಕ್ಷ್ಮವಾದ ರೇಸ್ ಕಂಡಿಷನ್ಗಳು (race conditions), ಅಸ್ಪಷ್ಟ ವ್ಯವಹಾರ ತರ್ಕದ ಎಡ್ಜ್ ಕೇಸ್ಗಳು ಮತ್ತು ಅವುಗಳ ತರಬೇತಿ ಡೇಟಾದಲ್ಲಿ ಅಡಗಿರುವ ಭದ್ರತಾ ಊಹೆಗಳ ಮೇಲೆ ಎಡವಿ ಬೀಳುತ್ತವೆ. ವೆಬ್ಹೂಕ್ ಹ್ಯಾಂಡ್ಲರ್ ಮತ್ತು ರಿಫಂಡ್ ಕ್ರೋನ್ ಜಾಬ್ ನಡುವಿನ ಸ್ಪರ್ಧೆಯನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು ಅಥವಾ ಜನರೇಟ್ ಮಾಡಲಾದ ರಿಟ್ರೈ ಲಾಜಿಕ್ ಚಾರ್ಜ್ಗಳನ್ನು ಡ್ಯುಪ್ಲಿಕೇಟ್ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ಗುರುತಿಸುವುದು ನಿಮ್ಮ ಶಕ್ತಿಯಾಗಲಿದೆ. ಯಂತ್ರವು ಪ್ರಮಾಣಿತ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ನೀವು ಅಪಾಯಕಾರಿ ವಿನಾಯಿತಿಯನ್ನು (dangerous exception) ಪತ್ತೆಹಚ್ಚುತ್ತೀರಿ.
ಕೋಡ್ ರಿವ್ಯೂ ಬದಲಿಗೆ ಪರಿಶೀಲನಾ ಹಾರ್ನೆಸ್ ಬಳಸಿ (Replace Code Review with a Verification Harness)
ಒಂದು ಏಜೆಂಟ್ ರಾತ್ರೋರಾತ್ರಿ ಐವತ್ತು ಫೈಲ್ಗಳನ್ನು ಸಿದ್ಧಪಡಿಸಬಲ್ಲಾಗಿದ್ದಾಗ, ಅವು "ಸರಿಯಾಗಿ ಕಾಣಿಸುತ್ತಿವೆಯೇ" ಎಂದು ಕೇವಲ ಡಿಫ್ಗಳನ್ನು (diffs) ನೋಡಿ ನೀವು ರಿವ್ಯೂ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅಷ್ಟು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಕೋಡ್ ಅನ್ನು ಮನುಷ್ಯರು ಕಣ್ಣಿನಿಂದ ಪರೀಕ್ಷಿಸುವುದು ಅಸಾಧ್ಯ. ಕೋಡ್ ನಿಮ್ಮನ್ನು ತಲುಪುವ ಮೊದಲೇ ತಪ್ಪುಗಳನ್ನು ಹಿಡಿಯುವ ಒಂದು 'ಹಾರ್ನೆಸ್' (harness) ನಿಮಗೆ ಬೇಕು.
ಈ ಹಾರ್ನೆಸ್ ಮೂರು ಸ್ತಂಭಗಳ ಮೇಲೆ ನಿಂತಿದೆ.
ಸುಸ್ಥಿರ ಅನುಷ್ಠಾನ (Durable execution). ಏಜೆಂಟ್ ಕಾರ್ಯಗಳು ಹೆಚ್ಚಾಗಿ ಒಂದೇ ರಿಕ್ವೆಸ್ಟ್ ಟೈಮ್ಔಟ್ ಅವಧಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ನಡೆಯುತ್ತವೆ. ತಾತ್ಕಾಲಿಕ ನೆಟ್ವರ್ಕ್ ಸಮಸ್ಯೆಯಿಂದಾಗಿ ಒಂದು ಹಂತ ವಿಫಲವಾದರೆ, ಹಾರ್ನೆಸ್ ಸ್ಥಗಿತಗೊಂಡು, ಮರುಪ್ರಯತ್ನಿಸಿ, ಸ್ಟೇಟ್ (state) ಹಾಳಾಗದಂತೆ ಕೆಲಸವನ್ನು ಪುನರಾರಂಭಿಸುತ್ತದೆ. ಕೆಲಸವು ಅಡಚಣೆಯ ನಡುವೆಯೂ ಉಳಿಯುತ್ತದೆ.
ರಚನಾತ್ಮಕ ಔಟ್ಪುಟ್ಗಳು (Structured outputs). ಏಜೆಂಟ್ ಸರಿಯಾದ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ನೀಡುತ್ತದೆ ಎಂದು ಕಾಯುವ ಬದಲು, ನೀವು ಮೊದಲೇ ಒಪ್ಪಂದವನ್ನು (contract) ಜಾರಿಗೆ ತರುತ್ತೀರಿ. JSON Schema ನಂತಹ ಪರಿಕರಗಳು ಔಟ್ಪುಟ್ ಅನ್ನು ತಕ್ಷಣವೇ ವ್ಯಾಲಿಡೇಟ್ ಮಾಡುತ್ತವೆ. ಏಜೆಂಟ್ ಅಗತ್ಯವಾದ ಫೀಲ್ಡ್ ಅನ್ನು ಬಿಟ್ಟರೆ ಅಥವಾ ತಪ್ಪಾದ ಡೇಟಾ ಪ್ರಕಾರವನ್ನು ಬಳಸಿದರೆ, ಕೋಡ್ ನಿಮ್ಮ ರೆಪೊಸಿಟರಿಗೆ ತಲುಪುವ ಮೊದಲೇ ಹಾರ್ನೆಸ್ ಅದನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ.
ಡೈನಾಮಿಕ್ ಗಾರ್ಡ್ರೈಲ್ಗಳು (Dynamic guardrails). ಏಜೆಂಟ್ಗೆ ಸೀಕ್ರೆಟ್ಗಳನ್ನು ಓದಲು ಅಥವಾ ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾಬೇಸ್ಗಳಿಗೆ ಬರೆಯಲು ಮುಕ್ತ ಅವಕಾಶವಿರಬಾರದು. ಹಾರ್ನೆಸ್ ಅನುಮತಿಗಳನ್ನು ಡೈನಾಮಿಕ್ ಆಗಿ ನಿಯಂತ್ರಿಸುತ್ತದೆ, ಏಜೆಂಟ್ ಅನ್ನು ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ (sandboxing) ಮಾಡುತ್ತದೆ ಇದರಿಂದ ಅದು ಕೇವಲ ನಿಗದಿಪಡಿಸಿದ ಟೆಸ್ಟ್ ಡೇಟಾಬೇಸ್ಗಳು ಮತ್ತು ಇಂಟರ್ನಲ್ ಎಂಡ್ಪಾಯಿಂಟ್ಗಳನ್ನು ಮಾತ್ರ ಬಳಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ನೀವು ಪ್ರತಿಯೊಂದು ಸಾಲನ್ನು ರಿವ್ಯೂ ಮಾಡುತ್ತಿಲ್ಲ; ನೀವು ಏಜೆಂಟ್ ಸುತ್ತಲಿನ ಬೇಲಿಯನ್ನು (fence) ಆಡಿಟ್ ಮಾಡುತ್ತಿದ್ದೀರಿ.
ಕೋಡ್ ಕೆಲಸ ಮಾಡಿದರೂ ಉತ್ಪನ್ನ ವಿಫಲವಾದಾಗ
ಇಲ್ಲಿದೆ ಒಂದು ವಿರೋಧಾಭಾಸ. ಹಾರ್ನೆಸ್ (harness) ಕೆಟ್ಟ ಕೋಡ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತದೆ. ಆದರೆ ಅದು ಕೆಟ್ಟ ಉದ್ದೇಶವನ್ನು (bad intent) ಪತ್ತೆಹಚ್ಚಲಾರದು.
ನಿಮ್ಮ ಸ್ಪೆಸಿಫಿಕೇಶನ್ (specification) "ಪ್ರತಿ ಹೊಸ ಬಳಕೆದಾರರಿಗೆ ಸ್ವಾಗತದ ಇಮೇಲ್ ಕಳುಹಿಸಿ" ಎಂದು ಹೇಳಿದರೆ, ಏಜೆಂಟ್ ಆ ಇಮೇಲ್ ಕಳುಹಿಸುವ ಸ್ವಚ್ಛವಾದ ಮತ್ತು ಪರೀಕ್ಷಿತವಾದ ಕೋಡ್ ಅನ್ನು ಬರೆಯುತ್ತದೆ. ಆದರೆ ನಿಮ್ಮ ನಿಜವಾದ ಉದ್ದೇಶ ಹೀಗಿರಬಹುದು: "ಬಳಕೆದಾರರು ತಮ್ಮ ವಿಳಾಸವನ್ನು ಪರಿಶೀಲಿಸಿದರೆ, ಮಾರ್ಕೆಟಿಂಗ್ಗೆ ಒಪ್ಪಿಗೆ ನೀಡಿದ್ದರೆ ಮತ್ತು ಅವರ ಸ್ಥಳೀಯ ಸಮಯ ವಲಯದ ವ್ಯವಹಾರದ ಸಮಯದಲ್ಲಿ ಸೈನ್ ಅಪ್ ಮಾಡಿದ್ದರೆ ಮಾತ್ರ ಸ್ವಾಗತದ ಇಮೇಲ್ ಕಳುಹಿಸಿ." ಈ ಕೋಡ್ ತಾಂತ್ರಿಕವಾಗಿ ದೋಷರಹಿತವಾಗಿರಬಹುದು, ಆದರೆ ವಾಣಿಜ್ಯ ದೃಷ್ಟಿಯಿಂದ ಅಪಾಯಕಾರಿಯಾಗಿದೆ.
Intent-Driven Development ನಲ್ಲಿ ನಿಜವಾದ ಅಪಾಯವೆಂದರೆ ಅಸ್ಪಷ್ಟವಾದ ಸ್ಪೆಸಿಫಿಕೇಶನ್. ಅಸ್ಪಷ್ಟ ಉದ್ದೇಶವು ತಪ್ಪು ಸಮಸ್ಯೆಯನ್ನು ಅತ್ಯಂತ ಸುಂದರವಾಗಿ ಪರಿಹರಿಸುವ ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಅದಕ್ಕಾಗಿಯೇ ನೀವು ನಿಮ್ಮ ಸ್ಪೆಸಿಫಿಕೇಶನ್ಗಳನ್ನು ನಿಜವಾದ ಆಸ್ತಿಗಳೆಂದು ಪರಿಗಣಿಸಬೇಕು. ಅವುಗಳಿಗೆ ವರ್ಷನ್ (version) ನೀಡಿ. ಸ್ಟೇಕ್ಹೋಲ್ಡರ್ಗಳೊಂದಿಗೆ (stakeholders) ಅವುಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಏಜೆಂಟ್ ನಿರ್ಮಾಣ ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಅವುಗಳನ್ನು ನೈಜ ಕೆಲಸದ ಹರಿವುಗಳೊಂದಿಗೆ (workflows) ಮೌಲ್ಯೀಕರಿಸಿ. ಚಾಟ್ ಬಾಕ್ಸ್ನಲ್ಲಿ ಬರೆದ ಒಂದು ಪ್ರಾಂಪ್ಟ್ (prompt) ಸ್ಪೆಸಿಫಿಕೇಶನ್ ಅಲ್ಲ; ಅದು ಒಂದು ಹೊರೆ (liability).
ಎಂಜಿನಿಯರಿಂಗ್ ತೀರ್ಮಾನವು ಮೇಲ್ಮಟ್ಟಕ್ಕೆ ಚಲಿಸುತ್ತಿದೆ
ಎಂಜಿನಿಯರಿಂಗ್ ತೀರ್ಮಾನವು ಮಾಯವಾಗುತ್ತಿಲ್ಲ. ಅದು ಉನ್ನತ ಮಟ್ಟಕ್ಕೆ ಸ್ಥಳಾಂತರಗೊಳ್ಳುತ್ತಿದೆ.
ನೀವು ಇನ್ನು ಮುಂದೆ ಮ್ಯಾಪ್ ಅನ್ನು ಹೇಗೆ ಇಟರೇಟ್ ಮಾಡಬೇಕು ಅಥವಾ ಕ್ಲಾಸ್ ಹೈರಾರ್ಕಿ (class hierarchy) ಅನ್ನು ಹೇಗೆ ರಚಿಸಬೇಕು ಎಂಬುದರ ಮೇಲೆ ಮಾನಸಿಕ ಶಕ್ತಿಯನ್ನು ವ್ಯಯಿಸುವುದಿಲ್ಲ. ಬದಲಾಗಿ, ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಸಿಸ್ಟಮ್ ಏನು ಮಾಡಬೇಕು, ಯಾವ ಡೇಟಾವನ್ನು ಎಂದಿಗೂ ಬಹಿರಂಗಪಡಿಸಬಾರದು ಮತ್ತು ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಸರ್ವಿಸ್ಗಳಲ್ಲಿ (distributed services) ಯಾವ ಇನ್ವೇರಿಯಂಟ್ಸ್ (invariants) ಕಡ್ಡಾಯವಾಗಿರಬೇಕು ಎಂಬುದರ ಮೇಲೆ ಶ್ರಮಿಸುತ್ತೀರಿ. ಕೋಡಿಂಗ್ ಕಲೆಯು ಈಗ ಅವಶ್ಯಕತೆಗಳ (requirements) ಕಲೆಯಾಗಿ ಬದಲಾಗುತ್ತಿದೆ.
ಇದರರ್ಥ ನಿಮ್ಮ ಸ್ಪೆಸಿಫಿಕೇಶನ್ಗಳು ನೀವು ಹಿಂದೆ ನಿಮ್ಮ ಕೋಡ್ಗೆ ಅನ್ವಯಿಸುತ್ತಿದ್ದಷ್ಟೇ ಕಟ್ಟುನಿಟ್ಟಿನತಾಗಿರಬೇಕು. ನಿಮ್ಮ ನಿರ್ಬಂಧಗಳನ್ನು (constraints) ನಿಖರವಾಗಿ ಹೆಸರಿಸಿ. ವೈಫಲ್ಯದ ವಿಧಾನಗಳನ್ನು (failure modes) ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಿ. ನೀವು ಹಿಂದೆ ನಿಮ್ಮ ಟೈಪ್ಗಳನ್ನು (types) ಘೋಷಿಸಿದಷ್ಟೇ ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯವಹಾರದ ನಿಯಮಗಳನ್ನು ತಿಳಿಸಿ. ಏಜೆಂಟ್ ಅನುಷ್ಠಾನವನ್ನು (implementation) ನಿರ್ವಹಿಸುತ್ತದೆ. ಆದರೆ ಆ ಅನುಷ್ಠಾನವು ನಿರ್ಮಿಸಲು ಯೋಗ್ಯವಾಗಿದೆ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು.
ನಿಮ್ಮ ಗುಣಮಟ್ಟದ ಮಾನದಂಡವನ್ನು (quality bar) ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್ನಿಂದ (pull request) ಪ್ರಾಂಪ್ಟ್ಗೆ ಬದಲಾಯಿಸಿ. ಮೊದಲು ಹಾರ್ನೆಸ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. ಎರಡನೆಯದಾಗಿ ಸ್ಪೆಸಿಫಿಕೇಶನ್ ಬರೆಯಿರಿ. ನಂತರ, ಸಮಸ್ಯೆ ಸರಿಯಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲ್ಪಟ್ಟಿದೆಯೇ ಮತ್ತು ಮಿತಿಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಗುರುತಿಸಲಾಗಿದೆಯೇ ಎಂಬುದರ ಮೇಲೆ ನೀವು ಗಮನಹರಿಸುವಾಗ, ಸಿಂಟ್ಯಾಕ್ಸ್ (syntax) ಅನ್ನು ಯಂತ್ರಕ್ಕೆ ಬಿಡಿ.
ಈ ಬದಲಾವಣೆಯ ಹಿಂದಿನ ವಿಚಾರಗಳನ್ನು ಇನ್ನಷ್ಟು ಆಳವಾಗಿ ತಿಳಿಯಲು, Intent-Driven Development ಕುರಿತಾದ ಮೂಲ ಚರ್ಚೆಯನ್ನು ಇಲ್ಲಿ ನೋಡಬಹುದು. AI-native ಎಂಜಿನಿಯರಿಂಗ್ ಕುರಿತಾದ ನಿರಂತರ ಸಂವಾದಗಳಿಗಾಗಿ, ನೀವು GyaanSetu ಸಮುದಾಯವನ್ನು ಸೇರಬಹುದು.