ಸಾಫ್ಟ್ವೇರ್ ಎಂಜಿನಿಯರಿಂಗ್ ಅಂತ್ಯವಾಗಿದೆ. ಟೆಕ್ ಟ್ವಿಟರ್ನಲ್ಲಿ ಅತಿ ಹೆಚ್ಚು ಧ್ವನಿ ಎತ್ತುವವರು ನಿಮಗೆ ನಂಬಿಸಲು ಬಯಸುತ್ತಿರುವುದು ಇದನ್ನೇ. ಕೇವಲ ಒಂದು ಪ್ಯಾರಾಗ್ರಾಫ್ ಪ್ರಾಂಪ್ಟ್ನಿಂದ ಪೂರ್ಣ ಪ್ರಮಾಣದ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುವ ಎಐ (AI) ಪರಿಕರಗಳ ಸ್ಕ್ರೀನ್ ರೆಕಾರ್ಡಿಂಗ್ಗಳನ್ನು ಅವರು ಹಂಚಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಒಬ್ಬ ಮನುಷ್ಯನಿಗೆ ಕೋಡ್ ಬರೆಯಲು ಇನ್ನು ಮುಂದೆ ಏಕೆ ಹಣ ನೀಡಬೇಕು ಎಂದು ಕೇಳುತ್ತಾರೆ. ಈ ಆತಂಕವು ಅರ್ಥವಾಗುವಂತಿದೆ, ಆದರೆ ಇದು ಮೂಲ ವಿಷಯವನ್ನೇ ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಿಸಿಕೊಳ್ಳುತ್ತಿದೆ.
ಎಐ ಎಂಜಿನಿಯರ್ಗಳ ವಿರುದ್ಧ ಬರುತ್ತಿಲ್ಲ. ಟೈಪಿಂಗ್ ವೇಗವನ್ನು ತಾಂತ್ರಿಕ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವ ಸಾಮರ್ಥ್ಯ ಎಂದು ತಪ್ಪಾಗಿ ಭಾವಿಸುವವರ ವಿರುದ್ಧ ಅದು ಬರುತ್ತಿದೆ. ಕೋಡಿಂಗ್ ಮತ್ತು ಎಂಜಿನಿಯರಿಂಗ್ ನಡುವೆ ದೊಡ್ಡ ಅಂತರವಿದೆ, ಮತ್ತು ಆ ಅಂತರದಲ್ಲೇ ಇಡೀ ವೃತ್ತಿ ಅಡಗಿದೆ.
ನೀವು ಕಾಫಿ ಕುಡಿಯುವುದನ್ನು ಮುಗಿಸುವ ಮೊದಲೇ, ಒಂದು ಫೀಚರ್ ಅನ್ನು ಅಳವಡಿಸಲು ಎಐ ಅಸಿಸ್ಟೆಂಟ್ ನಿಮಗೆ ಐದು ವಿಭಿನ್ನ ಮಾರ್ಗಗಳನ್ನು ನೀಡಬಲ್ಲದು. ಅಡಚಣೆಯ ಕೇಂದ್ರಬಿಂದು ಬದಲಾಗಿದೆ. ನಾವು ಹೇಗೆ ಪ್ರಾರಂಭಿಸಬೇಕು ಎಂದು ಯೋಚಿಸುತ್ತಾ ಖಾಲಿ ಫೈಲ್ ಅನ್ನು ದಿಟ್ಟಿಸಿ ನೋಡುವ ಕಾಲ ಮುಗಿದಿದೆ. ನೈಜ ಟ್ರಾಫಿಕ್ ಬಂದ ತಕ್ಷಣ ಯಾವುದು ಕುಸಿಯುವುದಿಲ್ಲ ಎಂದು ಯೋಚಿಸುತ್ತಾ ನಾವು ಐದು ಸಂಭವನೀಯ ಪರಿಹಾರಗಳನ್ನು ನೋಡುತ್ತೇವೆ. ಆ ನಿರ್ಧಾರವೇ ಎಂಜಿನಿಯರಿಂಗ್. ಉಳಿದೆಲ್ಲವೂ ಕೇವಲ ಸಿಂಟ್ಯಾಕ್ಸ್ (syntax).
ಡೆಮೊ ಎಂಬುದು ಉತ್ಪನ್ನವಲ್ಲ
ಯಾವುದೇ ಎಐ ಕೋಡಿಂಗ್ ಡೆಮೋವನ್ನು ನೋಡಿ, ಕೆಲವೇ ನಿಮಿಷಗಳಲ್ಲಿ ಒಂದು ಸುಂದರವಾದ ಇಂಟರ್ಫೇಸ್ ಸಿದ್ಧವಾಗುವುದನ್ನು ನೀವು ಕಾಣುವಿರಿ. ಆದರೆ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಕನೆಕ್ಷನ್ ಪೂಲ್ (database connection pool) ಖಾಲಿಯಾಗುವುದನ್ನು ನೀವು ಕಾಣಲಾರಿರಿ. API ಎಂಡ್ಪಾಯಿಂಟ್ನಲ್ಲಿ ರೇಟ್ ಲಿಮಿಟ್ಗಳ ಕೊರತೆ, ಆಡಿಟ್ ಲಾಗ್ಗಳ ಅನುಪಸ್ಥಿತಿ, ಅಥವಾ ಎಐ ಅದನ್ನು ಸ್ಟೇಟ್ (state) ಸಂಗ್ರಹಿಸಲು ಅನುಕೂಲಕರ ಸ್ಥಳ ಎಂದು ಭಾವಿಸಿ ಪ್ರತಿಯೊಂದು ಬಳಕೆದಾರರ ಸಂವಹನವನ್ನು ಆಬ್ಜೆಕ್ಟ್ ಬಕೆಟ್ಗೆ ಲಾಗ್ ಮಾಡುವುದರಿಂದ ಉಂಟಾಗುವ ಸ್ಟೋರೇಜ್ ವೆಚ್ಚಗಳನ್ನು ನೀವು ಕಾಣಲಾರಿರಿ.
ಪ್ರೊಡಕ್ಷನ್ ಸಿಸ್ಟಮ್ಗಳು ಸ್ಕೇಲೆಬಿಲಿಟಿ, ಸೆಕ್ಯೂರಿಟಿ, ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಮತ್ತು ವೆಚ್ಚದ ನಿಯಂತ್ರಣವನ್ನು ಬಯಸುತ್ತವೆ. ಈ ಗುಣಲಕ್ಷಣಗಳು ಸ್ಪ್ರಿಂಟ್ ರಿವ್ಯೂನಲ್ಲಿ (sprint review) ಗೋಚರಿಸುವುದಿಲ್ಲ. ನೈಜ ಬಳಕೆದಾರರು ತಮ್ಮ ಅನಿರೀಕ್ಷಿತ ನಡವಳಿಕೆ, ಎಡ್ಜ್ ಕೇಸ್ಗಳು (edge cases) ಮತ್ತು ನೀವು ನಿರೀಕ್ಷಿಸಿದ ಕ್ರಮದಲ್ಲಿ ಬಟನ್ಗಳನ್ನು ಕ್ಲಿಕ್ ಮಾಡಲು ನಿರಾಕರಿಸುವ ಮೂಲಕ ಬಂದಾಗ ಮಾತ್ರ ಇವುಗಳು ಹೊರಬರುತ್ತವೆ. QA ನಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಂಡ ಎಐ-ಸಹಾಯಿತ ಪ್ರಾಜೆಕ್ಟ್ಗಳು ಲಾಂಚ್ ಆದ ಒಂದು ವಾರದ ನಂತರ ದುಬಾರಿ ಪಾಠಗಳಾಗಿ ಬದಲಾಗುವುದನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ.
ಕೆಲಸ ಮಾಡುವ ಕೋಡ್ ಈಗ ಅಗ್ಗವಾಗಿದೆ. ಆದರೆ ಉತ್ತಮ ಎಂಜಿನಿಯರಿಂಗ್ ಅಷ್ಟಾಗಿ ಅಗ್ಗವಾಗಿಲ್ಲ.
ಈಗ ಯಾವುದು ಮುಖ್ಯ
ಈ ಬದಲಾವಣೆಯಲ್ಲಿ ಯಶಸ್ವಿಯಾಗುತ್ತಿರುವ ಎಂಜಿನಿಯರ್ಗಳು ಅತಿ ವೇಗವಾಗಿ ಟೈಪ್ ಮಾಡುವವರಲ್ಲ. ಒಂದು ಸಾಲು ಕೋಡ್ ಜನರೇಟ್ ಆಗುವ ಮೊದಲೇ ಯಾವ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಬೇಕು ಎಂದು ತಿಳಿದಿರುವವರೇ ಯಶಸ್ವಿಯಾಗುತ್ತಿದ್ದಾರೆ.
ಅವರು ಸಮಸ್ಯೆಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತಾರೆ. ನೀವು ಬಿಟ್ಟರೆ, ಎಐ ಮಾಡೆಲ್ ಸಂತೋಷದಿಂದ ತಪ್ಪು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಕೇವಲ ಆರು ಆಂತರಿಕ ವಿಶ್ಲೇಷಕರು ಬಳಸುವ ರೀಡ್-ಹೆವಿ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗಾಗಿ ಅದು ಒಂದು ಸಂಕೀರ್ಣ ಕ್ಯಾಷಿಂಗ್ ಲೇಯರ್ ಅನ್ನು ನಿರ್ಮಿಸಬಹುದು. ನಿಜವಾದ ಸಮಸ್ಯೆ ಡೇಟಾಬೇಸ್ ಇಂಡೆಕ್ಸ್ ಇಲ್ಲದಿರುವುದೇ ಅಥವಾ ಮೂಲಭೂತವಾಗಿ ದೋಷಪೂರಿತ ಡೇಟಾ ಮಾಡೆಲ್ ಆಗಿದೆಯೇ ಎಂದು ಕೇಳಲು ಅದು ನಿಲ್ಲುವುದಿಲ್ಲ. ಪರಿಹಾರವು ಕೋಡ್ಗೆ ಸಂಬಂಧಿಸಿದ್ದಾಗಲಿ ಅಥವಾ ಇಲ್ಲದಿರಲಿ, ಪರಿಹಾರವು ಸ್ಪಷ್ಟವಾಗುವವರೆಗೆ ಒಬ್ಬ ನುರಿತ ಎಂಜಿನಿಯರ್ ಸಮಸ್ಯೆಯನ್ನು ಮರುರೂಪಿಸುತ್ತಾರೆ.
ಅವರು ದೊಡ್ಡ ಸಿಸ್ಟಮ್ಗಳನ್ನು ಸಣ್ಣ ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುತ್ತಾರೆ. ಎಐ ಸ್ಥಳೀಯ ಸಂದರ್ಭಗಳಲ್ಲಿ (local context) ಅತ್ಯುತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಅದು ಒಂದು ಸಿಂಗಲ್ ಫಂಕ್ಷನ್, ಒಂದು ಸಿಂಗಲ್ ಕಾಂಪೊನೆಂಟ್ ಅಥವಾ ಒಂದು ಸಿಂಗಲ್ ಟೆಸ್ಟ್ ಅನ್ನು ಬರೆಯಬಲ್ಲದು. ಆದರೆ ಇಡೀ ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಲು ಅದು ಕಷ್ಟಪಡುತ್ತದೆ. ಮೊನೊಲಿತ್ ಅನ್ನು ವಿಭಜಿಸಬಲ್ಲ, ಸರ್ವಿಸ್ಗಳ ಸುತ್ತ ಗಡಿಗಳನ್ನು ಗುರುತಿಸಬಲ್ಲ ಮತ್ತು ತಂಡಗಳ ನಡುವೆ ಒಪ್ಪಂದಗಳನ್ನು (contracts) ವ್ಯಾಖ್ಯಾನಿಸಬಲ್ಲ ಎಂಜಿನಿಯರ್ಗಳು ಮಾತ್ರ ಜನರೇಟ್ ಆದ ಸ್ನಿಪೆಟ್ಗಳನ್ನು ಸುಸ್ಥಿರ ಸಿಸ್ಟಮ್ಗಳನ್ನಾಗಿ ಪರಿವರ್ತಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಅವರು ಎಐ ಸಲಹೆಗಳನ್ನು ಪ್ರಶ್ನಿಸುತ್ತಾರೆ. ಮಾಡೆಲ್ನ ಆತ್ಮವಿಶ್ವಾಸವು ಕೇವಲ ಭ್ರಮೆ. ಅದು ನೆಟ್ವರ್ಕ್ ಲೇಟೆನ್ಸಿಯನ್ನು (network latency) ನಿರ್ಲಕ್ಷಿಸುವ ಆರ್ಕಿಟೆಕ್ಚರ್ಗಳನ್ನು ಪ್ರಸ್ತಾಪಿಸಬಹುದು, ವರ್ಷಗಳಿಂದ ಬಳಕೆಯಲ್ಲಿಲ್ಲದ (deprecated) ಲೈಬ್ರರಿಗಳನ್ನು ಶಿಫಾರಸು ಮಾಡಬಹುದು ಅಥವಾ ಅಗತ್ಯತೆಗಳಲ್ಲಿ ಇಲ್ಲದ ಫೀಚರ್ಗಳನ್ನು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸಬಹುದು.