ಎಂಜಿನಿಯರಿಂಗ್ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವ ಸಾಮರ್ಥ್ಯವು (Engineering Judgment) ಅತ್ಯಂತ ಅಪರೂಪದ ಸಂಪನ್ಮೂಲವಾಗುತ್ತಿದೆ
ಅನುಷ್ಠಾನವು (Implementation) ಅಗ್ಗವಾಗುತ್ತಿದೆ. ಇದು ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವ ಸಾಮರ್ಥ್ಯವನ್ನು ದುಬಾರಿಯಾಗಿಸುತ್ತದೆ.
ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವುದು ಎಂದರೆ ಕೇವಲ ಅಂತಃಪ್ರಜ್ಞೆ ಅಥವಾ ಅಭಿಪ್ರಾಯವಲ್ಲ. ಇದು ಅನಿಶ್ಚಿತತೆಯ ನಡುವೆ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಸಾಮರ್ಥ್ಯವಾಗಿದೆ. AI ಈ ಕೌಶಲವನ್ನು ಹಿಂದೆಂದಿಗಿಂತಲೂ ಹೆಚ್ಚು ಎದ್ದು ಕಾಣುವಂತೆ ಮಾಡಿದೆ.
ಇಬ್ಬರು ಎಂಜಿನಿಯರ್ಗಳಿಗೆ ಒಂದೇ ಕೆಲಸ ಸಿಗಬಹುದು: ಇನ್ವಾಯ್ಸ್ ಹೊಂದಾಣಿಕೆಗಾಗಿ (invoice reconciliation) ಒಂದು API ಅನ್ನು ನಿರ್ಮಿಸುವುದು. AI ಎರಡಕ್ಕೂ ಕೋಡ್ ಬರೆಯಬಲ್ಲದು. ಸಿಂಟ್ಯಾಕ್ಸ್ (syntax) ಮತ್ತು ಫ್ರೇಮ್ವರ್ಕ್ಗಳು ಒಂದೇ ರೀತಿ ಕಾಣಿಸಬಹುದು.
ಅಂತಿಮ ವ್ಯವಸ್ಥೆಗಳು (systems) ಭಿನ್ನವಾಗಿರುತ್ತವೆ. ಒಬ್ಬ ಎಂಜಿನಿಯರ್ ನಿರ್ವಹಿಸಲು ಕಷ್ಟವಾಗುವಂತಹ ಅಸ್ತವ್ಯಸ್ತವಾದ ಸೇವೆಯನ್ನು (service) ನಿರ್ಮಿಸಬಹುದು. ಇನ್ನೊಬ್ಬರು ವ್ಯವಹಾರದ ನಿಯಮಗಳು (business rules) ಮತ್ತು ತರ್ಕವನ್ನು (logic) ಸ್ವತಂತ್ರ ಘಟಕಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು.
ಆ ಆಯ್ಕೆಯನ್ನು AI ಮಾಡಲಿಲ್ಲ. ಎಂಜಿನಿಯರ್ ಮಾಡಿದರು.
ಆರ್ಕಿಟೆಕ್ಚರ್ (Architecture) ಇನ್ನೂ ಮುಖ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ ಅನುಷ್ಠಾನವು (implementation) ಈಗ ವ್ಯತ್ಯಾಸವನ್ನು ಉಂಟುಮಾಡುವ ಅಂಶವಾಗಿ ಉಳಿದಿಲ್ಲ. ಕೋಡ್ನ ಹಿಂದಿರುವ ನಿರ್ಧಾರಗಳೇ ವ್ಯತ್ಯಾಸವನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ.
AI ಬಂದಿದ್ದರಿಂದ ಸಂಕೀರ್ಣತೆ (Complexity) ಮಾಯವಾಗುವುದಿಲ್ಲ. ಅದು ಕೇವಲ ಸ್ಥಳಾಂತರಗೊಳ್ಳುತ್ತದೆ.
ಹಿಂದೆ, ಎಂಜಿನಿಯರ್ಗಳು ಕಲ್ಪನೆಗಳನ್ನು ಕೋಡ್ ಆಗಿ ಪರಿವರ್ತಿಸಲು ಸಮಯ ವ್ಯಯಿಸುತ್ತಿದ್ದರು. ಈಗ, AI ಆ ಪರಿವರ್ತನೆಯನ್ನು ಮಾಡುತ್ತದೆ. ಕಠಿಣ ಕೆಲಸವು ನೀವು ಒಂದು ಸಾಲು ಕೋಡ್ ಬರೆಯುವ ಮೊದಲೇ ನಡೆಯುತ್ತದೆ.
ನೀವು ಈ ಕೆಳಗಿನ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಲೇಬೇಕು:
- ನಾವು ಯಾವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತಿದ್ದೇವೆ?
- ಯಾವ ಡೇಟಾ ಸತ್ಯದ ಮೂಲವಾಗಿದೆ (source of truth)?
- ವ್ಯವಹಾರದ ನಿಯಮಗಳು ಎಲ್ಲಿ ಇರಬೇಕು?
- ನಾವು ಯಶಸ್ಸನ್ನು ಹೇಗೆ ಅಳೆಯುತ್ತೇವೆ?
ಆಟೋಕಂಪ್ಲೀಟ್ (Autocomplete) ಇವುಗಳಿಗೆ ಉತ್ತರಿಸಲಾರದು. ಇವುಗಳಿಗೆ ಸಂದರ್ಭದ (context) ಅಗತ್ಯವಿದೆ.
ಸಾಫ್ಟ್ವೇರ್ ಅಭಿವೃದ್ಧಿಯು ಈಗ ಮಾಹಿತಿ ಎಂಜಿನಿಯರಿಂಗ್ನಂತೆ ಕಾಣುತ್ತಿದೆ. ಅಡಚಣೆಯು (bottleneck) ಕೋಡ್ ಅಲ್ಲ. ಅಡಚಣೆಯು ಮಾಹಿತಿ.
ನೀವು ಎದುರಿಸುವ ಸವಾಲುಗಳು:
- ಅಪೂರ್ಣ ಅವಶ್ಯಕತೆಗಳು (Missing requirements).
- ಅಪೂರ್ಣ ದಾಖಲಾತಿ (Incomplete documentation).
- ಪರಸ್ಪರ ವಿರೋಧಾಭಾಸವಿರುವ ವ್ಯವಹಾರದ ನಿಯಮಗಳು.
- ಅನಿರ್ದಿಷ್ಟ ಮಾಲೀಕತ್ವ (Undefined ownership).
ಮಾಹಿತಿಯನ್ನು ವ್ಯವಸ್ಥಿತವಾಗಿ ಜೋಡಿಸುವ ಎಂಜಿನಿಯರ್, ವೇಗವಾಗಿ ಕೋಡ್ ಬರೆಯುವ ಎಂಜಿನಿಯರ್ನಿಗಿಂತ ಹೆಚ್ಚು ಮೌಲ್ಯವನ್ನು ಸೃಷ್ಟಿಸುತ್ತಾರೆ.
ಕೆಲಸದ ಹರಿವು (Workflow) ಬದಲಾಗಿದೆ. ಹಿಂದೆ ಅದು ಹೀಗಿತ್ತು: Requirement -> Design -> Code -> Debug -> Deploy.
ಈಗ ಅದು ಹೀಗಿದೆ: Business Problem -> Context -> Architecture -> AI Implementation -> Human Review -> Security -> Evaluation -> Production.
ಕೋಡಿಂಗ್ ಈಗ ಪ್ರಕ್ರಿಯೆಯ ಒಂದು ಸಣ್ಣ ಭಾಗವಾಗಿದೆ. ಅದರ ಸುತ್ತಲಿನ ಚಟುವಟಿಕೆಗಳೇ ಆದ್ಯತೆಯಾಗಿವೆ.
ಹೆಚ್ಚಿನ ಪ್ರಭಾವ ಬೀರುವ ನಿರ್ಧಾರಗಳು ಕೋಡ್ ಎಡಿಟರ್ನ ಹೊರಗೆ ನಡೆಯುತ್ತವೆ. ನೀವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಕೇಳಿದಾಗ ಅವು ಸಂಭವಿಸುತ್ತವೆ:
- ಇದು ಪ್ರತ್ಯೇಕ ಸೇವೆಯಾಗಬೇಕೇ?
- ನಾವು ಈ ನಿರ್ಧಾರವನ್ನು ಪರಿಶೀಲಿಸಬಹುದೇ (audit)?
- AI ತಪ್ಪಾದರೆ ಏನಾಗುತ್ತದೆ?
- ಈ ಆರ್ಕಿಟೆಕ್ಚರ್ ವಿಕಸನಗೊಳ್ಳಬಹುದೇ?
AI ಎಂಜಿನಿಯರಿಂಗ್ ಎಂದರೆ ಕೇವಲ ಪ್ರಾಂಪ್ಟ್ಗಳು (prompts) ಅಥವಾ ಮಾಡೆಲ್ ಆಯ್ಕೆ ಮಾತ್ರವಲ್ಲ. ಅವು ಕೇವಲ ಒಂದು ಹಂತವಾಗಿವೆ.
ನಿಜವಾದ ಸವಾಲುಗಳು ಆರ್ಕಿಟೆಕ್ಚರಲ್ ಆಗಿವೆ:
- ನಾವು ವ್ಯವಹಾರದ ಜ್ಞಾನವನ್ನು ಹೇಗೆ ಮಾಡೆಲ್ ಮಾಡುತ್ತೇವೆ?
- ನಾವು ಅಸ್ಪಷ್ಟತೆಯನ್ನು (ambiguity) ಹೇಗೆ ಪರಿಹರಿಸುತ್ತೇವೆ?
- ನಾವು ನಂಬಿಕೆಯನ್ನು ಹೇಗೆ ಕಾಪಾಡಿಕೊಳ್ಳುತ್ತೇವೆ?
ಮಾಡೆಲ್ಗಳು ಪ್ರತಿ ಕೆಲವು ತಿಂಗಳಿಗೊಮ್ಮೆ ಬದಲಾಗುತ್ತವೆ. ಆರ್ಕಿಟೆಕ್ಚರ್ಗಳು ವರ್ಷಗಟ್ಟಲೆ ಉಳಿಯುತ್ತವೆ. ಕೆಟ್ಟ ಆರ್ಕಿಟೆಕ್ಚರ್ ಬಹಳ ಬೇಗನೆ ದುಬಾರಿಯಾಗುತ್ತದೆ.
ಅತ್ಯುತ್ತಮ ತಂಡಗಳು ವಿವಿಧ ತಲೆಮಾರುಗಳ ಮಾಡೆಲ್ಗಳಿಗೆ ತಡೆದುಕೊಳ್ಳುವ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತವೆ. ಅವು ಹೊಂದಾಣಿಕೆಗೆ (adaptability) ಒತ್ತು ನೀಡುತ್ತವೆ.
AI ಎಂಬುದು ಕೇವಲ ಅಬ್ಸ್ಟ್ರಾಕ್ಷನ್ನ (abstraction) ಮತ್ತೊಂದು ಹಂತವಾಗಿದೆ. ಹೆಚ್ಚಿನ ಅಬ್ಸ್ಟ್ರಾಕ್ಷನ್ಗೆ ಬಲವಾದ ತರ್ಕದ (reasoning) ಅಗತ್ಯವಿದೆ, ದುರ್ಬಲ ತರ್ಕದಲ್ಲಲ್ಲ.
ಅತ್ಯಂತ ಬಲಿಷ್ಠ ಎಂಜಿನಿಯರ್ಗಳು ವೇಗವಾಗಿ ಪ್ರೋಗ್ರಾಮ್ ಮಾಡುವವರಲ್ಲ. ಅವರು ಸ್ಪಷ್ಟತೆಯನ್ನು ಸೃಷ್ಟಿಸುವವರು. ಅವರು ಆರ್ಕಿಟೆಕ್ಚರ್ಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತಾರೆ, ಡೇಟಾವನ್ನು ಪ್ರಮಾಣೀಕರಿಸುತ್ತಾರೆ ಮತ್ತು ಅಸ್ಪಷ್ಟತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತಾರೆ.
ಒಂದು ಉತ್ತಮ ವ್ಯವಸ್ಥೆಯು ಮಾನವರು ಮತ್ತು AI ಏಜೆಂಟ್ಗಳು ಒಟ್ಟಾಗಿ ಕೆಲಸ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಕೆಟ್ಟ ವ್ಯವಸ್ಥೆಯು ತಪ್ಪುಗಳು ವೇಗವಾಗಿ ಸಂಭವಿಸುವಂತೆ ಮಾಡುತ್ತದೆ ಅಷ್ಟೆ.
ಸ್ಪಷ್ಟತೆಯನ್ನು ಸೃಷ್ಟಿಸುವ ಎಂಜಿನಿಯರ್ ಹೆಚ್ಚಿನ ಪ್ರಭಾವವನ್ನು (leverage) ಸೃಷ್ಟಿಸುತ್ತಾರೆ.
Source: https://dev.to/uigerhana/engineering-judgment-is-becoming-the-scarcest-resource-1a5l
Optional learning community: https://t.me/GyaanSetuAi
