ಆಟವನ್ನೇ ಬದಲಿಸಿದ ಆ ಎರಡು ವಾರಗಳ ಮಹಾಪೂರ
ಜುಲೈ 1 ಮತ್ತು ಜುಲೈ 16, 2026 ರ ನಡುವೆ, AI ವಲಯವು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿತು. ಇದು ಕ್ರಮೇಣವಾಗಿ ನಡೆದಲ್ಲ, ಏಕಕಾಲದಲ್ಲಿ ಸಂಭವಿಸಿತು.
Anthropic ತನ್ನ Claude Fable 5 ಅನ್ನು ಜಾಗತಿಕ ಮಾರುಕಟ್ಟೆಗಳಿಗೆ ಮರಳಿಸಿತು. SpaceXAI ತನ್ನ Grok 4.5 ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿತು. OpenAI ತನ್ನ GPT-5.6 ಕುಟುಂಬವಾದ Sol, Terra, ಮತ್ತು Luna ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ಮೂಲಕ, ಬಿಲ್ಡರ್ಗಳಿಗೆ ಒಂದೇ ಅಡಿಯಲ್ಲಿ ಮೂರು ಹೊಸ ಆಯ್ಕೆಗಳನ್ನು ನೀಡಿತು. Meta ತನ್ನ ವಾಣಿಜ್ಯ API ಮೂಲಕ Muse Spark 1.1 ಅನ್ನು ಮುಕ್ತಗೊಳಿಸಿತು. ಮತ್ತು Moonshot AI ತನ್ನ Kimi K3 ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿತು.
ಐದು ಫ್ರಾಂಟಿಯರ್ ಮಾಡೆಲ್ಗಳು. ಹದಿನಾರು ದಿನಗಳು. ಇದು ಕೇವಲ ಉತ್ಪನ್ನ ಚಕ್ರವಲ್ಲ (product cycle). ಇದು ಅತಿ ವೇಗದ ಪ್ರವಾಹದಂತೆ.
ನೀವು ಒಬ್ಬ ಡೆವಲಪರ್, ಪ್ರಾಡಕ್ಟ್ ಮ್ಯಾನೇಜರ್ ಅಥವಾ ಈ ವ್ಯವಸ್ಥೆಗಳ ಮೇಲೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಫೌಂಡರ್ ಆಗಿದ್ದರೆ, ಈ ವೇಗವು ರೋಮಾಂಚನಕಾರಿಯಲ್ಲ, ಬದಲಾಗಿ ಇದು ದಣಿವಿನಿಂದ ಕೂಡಿದೆ. ಹೊಸ ಸಂಖ್ಯೆಯನ್ನು ಬೆನ್ನಟ್ಟುವ, ಮೈಗ್ರೇಟ್ ಮಾಡುವ ಮತ್ತು ಪರೀಕ್ಷಿಸುವ ಮಾನಸಿಕ ಒತ್ತಡವು ನಿಜವಾಗಿದೆ. ಆದರೆ ಪ್ರತಿಯೊಂದು ಬಿಡುಗಡೆಯನ್ನೂ ಬೆನ್ನಟ್ಟುವುದು ಈಗ ಅಧಿಕೃತವಾಗಿ ಒಂದು ಕೆಟ್ಟ ತಂತ್ರವಾಗಿದೆ.
ಮಾಡೆಲ್ ಯುದ್ಧಗಳಿಂದ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಯುದ್ಧಗಳಿಗೆ
ನಾವು ಏಕಮಾತ್ರ ನಾಯಕನ ಯುಗವನ್ನು ದಾಟಿದ್ದೇವೆ. ವರ್ಷಗಳ ಕಾಲ ಮಾದರಿಯು ಸರಳವಾಗಿತ್ತು: ಒಂದು ಲ್ಯಾಬ್ ಒಂದು ದೊಡ್ಡ ಸಾಧನೆಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತಿತ್ತು, ಉಳಿದವುಗಳು ಅದನ್ನು ತಲುಪಲು ಹೆದರುತ್ತಿದ್ದವು ಮತ್ತು ಆ ನಾಯಕನು ತಿಂಗಳುಗಟ್ಟಲೆ ಮಾರುಕಟ್ಟೆಯನ್ನು ತನ್ನ ವಶದಲ್ಲಿಟ್ಟುಕೊಳ್ಳುತ್ತಿದ್ದನು. ಈಗ ಆ ತಿಂಗಳುಗಳು ದಿನಗಳಾಗಿ ಕುಸಿದಿವೆ.
ಒಂದೇ ಹದಿನೈದು ದಿನಗಳಲ್ಲಿ ಐದು ನಿಜವಾದ ಸಾಮರ್ಥ್ಯವುಳ್ಳ ಮಾಡೆಲ್ಗಳು ಬಂದಾಗ, ಮೊದಲ ಮತ್ತು ಐದನೇ ಸ್ಥಾನದ ನಡುವಿನ ವ್ಯತ್ಯಾಸವು ಅತ್ಯಲ್ಪವಾಗುತ್ತದೆ. ಸಾಮರ್ಥ್ಯವು ಇನ್ನು ಮುಂದೆ ವ್ಯತ್ಯಾಸವನ್ನು ಉಂಟುಮಾಡುವ ಅಂಶವಲ್ಲ. ಯುದ್ಧಭೂಮಿಯು ಈಗ ಸ್ಟ್ಯಾಕ್ನ (stack) ಮೇಲ್ಭಾಗಕ್ಕೆ ಸ್ಥಳಾಂತರಗೊಂಡಿದೆ. ನಾವು ಮಾಡೆಲ್ ಯುದ್ಧಗಳಿಂದ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಯುದ್ಧಗಳಿಗೆ ಬದಲಾಗುತ್ತಿರುವುದನ್ನು ನೋಡುತ್ತಿದ್ದೇವೆ.
ಇದು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಏನನ್ನು ಸೂಚಿಸುತ್ತದೆ ಎಂದು ಯೋಚಿಸಿ. ನಿಮ್ಮ ಬೆಂಚ್ಮಾರ್ಕ್ನಲ್ಲಿ GPT-5.6 Terra ಮತ್ತು Grok 4.5 ಒಂದೇ ಅಂಕದ ಹತ್ತಿರವಿದ್ದರೆ, ವಿಜೇತೆಯನ್ನು ನಿರ್ಧರಿಸುವುದು ಬುದ್ಧಿವಂತಿಕೆಯಲ್ಲ. ಬದಲಾಗಿ, Terra ನ ವಿಳಂಬತೆ (latency) ನಿಮ್ಮ ರಿಯಲ್-ಟೈಮ್ ಚಾಟ್ ಬಜೆಟ್ಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆಯೇ ಅಥವಾ Grok ನ Cursor ನೊಂದಿಗೆ ಇರುವ ಸಂಯೋಜನೆಯು (integration) ನಿಮ್ಮ ತಂಡದ ಕೆಲಸವನ್ನು ಉಳಿಸುತ್ತದೆಯೇ ಎಂಬುದು ಮುಖ್ಯವಾಗುತ್ತದೆ. ಲ್ಯಾಬ್ನಲ್ಲಿರುವ ಅತ್ಯಂತ ಬುದ್ಧಿವಂತ ಮಾಡೆಲ್ ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ (production) ಅದೆಷ್ಟೋ ಬಾರಿ ತಪ್ಪಾದ ಮಾಡೆಲ್ ಆಗಿರಬಹುದು.
ಈಗ ನಿಜವಾಗಿಯೂ ಮುಖ್ಯವಾದುದು ಯಾವುದು?
ಕಾರ್ಯಕ್ಷಮತೆಯು ಸಮಾನವಾಗಿದಾಗ, ಇತರ ಅಂಶಗಳು ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಪಡೆಯುತ್ತವೆ. ನಿಮ್ಮ ಮೌಲ್ಯಮಾಪನ ಮಾನದಂಡಗಳು ಸಂಶೋಧನಾ ಪ್ರಬಂಧದಂತೆ ಇರಬಾರದು, ಬದಲಾಗಿ ಒಂದು ಖರೀದಿ ಪಟ್ಟಿಯಂತೆ (procurement sheet) ಇರಬೇಕು.
ಮೊದಲು ಪ್ರತಿ ಟೋಕನ್ನ ವೆಚ್ಚವನ್ನು ನೋಡಿ. ತರ್ಕಬದ್ಧವಾಗಿ (reasoning) 10% ಉತ್ತಮವಾಗಿರುವ ಆದರೆ ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ಬಳಸಿದಾಗ 3 ಪಟ್ಟು ಹೆಚ್ಚು ವೆಚ್ಚವಾಗುವ ಮಾಡೆಲ್, ನಿಮ್ಮ ಉತ್ಪನ್ನವನ್ನು ಸುಧಾರಿಸುವ ಮೊದಲೇ ನಿಮ್ಮ ಲಾಭದ ಪ್ರಮಾಣವನ್ನು (margin) ನಾಶಪಡಿಸುತ್ತದೆ.
ವಿಳಂಬತೆ (latency) ಮತ್ತು ವೇಗವನ್ನು ಗಮನಿಸಿ. ನೀವು ಲೈವ್ ಕೋಡಿಂಗ್ ಅಸಿಸ್ಟೆಂಟ್ ಅಥವಾ ರಿಯಲ್-ಟೈಮ್ ಅನುವಾದ ಸಾಧನವನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, 500ms ವಿಳಂಬವು ಉತ್ಪನ್ನವನ್ನು ವಿಫಲಗೊಳಿಸುತ್ತದೆ. 50ms ನಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯಿಸುವ ಸ್ವಲ್ಪ ಕಡಿಮೆ ಬುದ್ಧಿವಂತ ಮಾಡೆಲ್ ಬಳಕೆದಾರರನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ.
ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ನೋಡಿ. ಅಪ್ಟೈಮ್ ಗ್ಯಾರಂಟಿಗಳು, ರೇಟ್ ಲಿಮಿಟ್ಗಳು ಮತ್ತು ಸ್ಥಿರವಾದ ಔಟ್ಪುಟ್ ರಚನೆಯು ಸೈದ್ಧಾಂತಿಕ ಸಾಮರ್ಥ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿವೆ. 2% ಕಡಿಮೆ ಹ್ಯಾಲ್ಯುಸಿನೇಷನ್ (hallucination) ಮಾಡುವ ಆದರೆ ಪ್ರತಿ ಮಂಗಳವಾರ ಆಫ್ ಲೈನ್ ಆಗುವ ಮಾಡೆಲ್ ನಿಮ್ಮ ನಂಬಿಕೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.
ಕಾನ್ಟೆಕ್ಸ್ ಉದ್ದವನ್ನು (context length) ಗಮನಿಸಿ. ಇದು ನಿಮ್ಮ ಇಡೀ ಕೋಡ್ಬೇಸ್ ಅನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಬಲ್ಲದೇ? ನಿಮ್ಮ ಕಾನೂನು ಒಪ್ಪಂದವನ್ನಾ? ನಿಮ್ಮ ಬಹು ವರ್ಷಗಳ ರೋಗಿಗಳ ದಾಖಲೆಗಳನ್ನಾ? ಉತ್ತರ 'ಇಲ್ಲ' ಎಂದಿದ್ದರೆ, ಉಳಿದ ಯಾವುದೂ ಮುಖ್ಯವಲ್ಲ.
ವರ್ಕ್ಫ್ಲೋ ಸಂಯೋಜನೆಯನ್ನು ನೋಡಿ. ಇದು ನಿಮ್ಮ ಅಬ್ಸರ್ವೇಬಿಲಿಟಿ ಸ್ಟ್ಯಾಕ್ಗೆ (observability stack) ಹೊಂದಿಕೆಯಾಗುತ್ತದೆಯೇ? ಇದು ನಿಮ್ಮ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ರಾಂಪ್ಟ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಸಿಸ್ಟಮ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ? ಅತ್ಯುತ್ತಮ ಮಾಡೆಲ್ ಎಂದರೆ ನಿಮ್ಮ ಇಂಜಿನಿಯರ್ಗಳು ವಾಸ್ತವವಾಗಿ ಬಳಸುವ ಮಾಡೆಲ್.
ಬುದ್ಧಿವಂತಿಕೆಯು ಮೂಲಸೌಕರ್ಯವಾಗಿ ಬದಲಾಗುತ್ತಿದೆ
OpenAI ತನ್ನ GPT-5.6 ಕುಟುಂಬಕ್ಕೆ ಹಂತ ಹಂತದ ಬೆಲೆಗಳನ್ನು (tiered pricing) ನೀಡುವ ಮೂಲಕ ಪ್ರೊಡಕ್ಷನ್ ಸಿದ್ಧತೆಯತ್ತ ಗಮನ ಹರಿಸುತ್ತಿದೆ. Meta ಈಗ ಸಂಶೋಧನೆಗಾಗಿ ಮಾಡೆಲ್ಗಳನ್ನು ಉಚಿತವಾಗಿ ನೀಡುವುದಿಲ್ಲ; ಬದಲಾಗಿ ವಾಣಿಜ್ಯ APIಗಳ ಮೂಲಕ ಡೆವಲಪರ್ಗಳ ಖರ್ಚನ್ನು ಗುರಿಯಾಗಿಸಿಕೊಂಡಿದೆ. SpaceXAI ತನ್ನ Grok ಅನ್ನು Cursor ನಂತಹ ಡೆವಲಪರ್ಗಳು ಈಗಾಗಲೇ ಬಳಸುವ ಪರಿಕರಗಳಲ್ಲಿ ಅಳವಡಿಸುವ ಮೂಲಕ ವಿತರಣೆಯು (distribution) ಕೇವಲ ತಾಂತ್ರಿಕ ವಿಶೇಷತೆಗಳಿಗಿಂತ (specs) ಮೇಲು ಎಂಬ ನಂಬಿಕೆಯ ಮೇಲೆ ಪಣ ತೊಟ್ಟಿದೆ. Moonshot AI ತನ್ನ Kimi K3 ನಂತಹ ಓಪನ್-ವೇಟ್ ಬಿಡುಗಡೆಗಳು, ಬಿಲಿಯನ್ ಡಾಲರ್ ಬೆಲೆಯ ಕ್ಲೋಸ್ಡ್ API ಇಲ್ಲದೆಯೇ ಮುಂಚೂಣಿಯಲ್ಲಿರಬಲ್ಲವು ಎಂದು ತೋರಿಸಿಕೊಡುತ್ತಿದೆ.
ಇದು ನಿಮಗೆ ಪರಿಚಿತವಾಗಿರಬಹುದು. ನಾವು ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್ನಲ್ಲಿ ಇದೇ ಚಿತ್ರಣವನ್ನು ನೋಡಿದ್ದೇವೆ. AWS, Azure, ಮತ್ತು GCP ವೇಗವಾದ CPU ಯನ್ನು ಹೊಂದಿದ್ದಕ್ಕೆ ಗೆಲ್ಲುವುದಿಲ್ಲ. ಅವು ಬಿಲ್ಲಿಂಗ್ನ ಮುನ್ಸೂಚನೆ (predictability), ಪ್ರಾದೇಶಿಕ ಲಭ್ಯತೆ ಮತ್ತು IAM ಸಂಯೋಜನೆಯ ಮೇಲೆ ಗೆಲ್ಲುತ್ತವೆ. ಬುದ್ಧಿವಂತಿಕೆಯೂ ಸಹ ಇದೇ ಹಾದಿಯನ್ನು ಅನುಸರಿಸುತ್ತಿದೆ. ಇದು ಒಂದು ಕಮೋಡಿಟಿ ಯುಟಿಲಿಟಿಯಾಗಿ (commodity utility) ಬದಲಾಗುತ್ತಿದೆ. ಈಗ ಯಾವುದೇ ವಿಶೇಷ ಅಡ್ವಾಂಟೇಜ್ (moat) ಉಳಿದಿಲ್ಲ.
ಬದಲಾವಣೆಯ ಅಡಗಿರುವ ತೆರಿಗೆ
ಬಿಡುಗಡೆಯ ಟಿಪ್ಪಣಿಗಳು (release notes) ನಿಮಗೆ ಹೇಳದ ವಿಷಯ ಇಲ್ಲಿದೆ. ಪ್ರತಿಯೊಂದು ಮಾಡೆಲ್ ಮೈಗ್ರೇಷನ್ ಕೂಡ ಒಂದು ಅಡಗಿರುವ ತೆರಿಗೆಯನ್ನು ಹೊರುತ್ತದೆ.
ನೀವು ಪ್ರಾಂಪ್ಟ್ಗಳನ್ನು ಮರುಬರೆಯಬೇಕಾಗುತ್ತದೆ. ಟ್ರೈನಿಂಗ್ ಡೇಟಾ ಅಥವಾ ಟೋಕನೈಸರ್ ವರ್ತನೆಯಲ್ಲಿನ ಸಣ್ಣ ಬದಲಾವಣೆಗಳು ಕೂಡ ಪ್ರೊಡಕ್ಷನ್-ರೆಡಿ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಗೊಂದಲಮಯವಾಗಿಸಬಹುದು. ನೀವು ವರ್ಕ್ಫ್ಲೋಗಳನ್ನು ಮರುಪರೀಕ್ಷಿಸಬೇಕಾಗುತ್ತದೆ. ನೀವು ನಂಬಿದ್ದ ಆ JSON ಔಟ್ಪುಟ್? ಹೊಸ ಮಾಡೆಲ್ ಅರ್ಧದಷ್ಟು ಸಮಯ ಅದನ್ನು ಮಾರ್ಕ್ಡೌನ್ನಲ್ಲಿ (markdown) ನೀಡಬಹುದು. ನೀವು ಸಂಯೋಜನೆಗಳನ್ನು (integrations) ಅಪ್ಡೇಟ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. SDKಗಳು ಬದಲಾಗುತ್ತವೆ. ಎರರ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ ಬದಲಾಗುತ್ತದೆ. ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಒಂದು ವಾರ ವಿಳಂಬವಾಗುತ್ತದೆ.
ಇದರ ಲೆಕ್ಕಾಚಾರವು ಕಠಿಣವಾಗಿದೆ. ಇನ್ಫರೆನ್ಸ್ ವೆಚ್ಚದಲ್ಲಿ (inference costs) 15% ಉಳಿಸಲು ಎರಡು ವಾರಗಳ ಕಾಲ ಮೈಗ್ರೇಷನ್ ಮಾಡುವ ಐದು ಇಂಜಿನಿಯರ್ಗಳ ತಂಡವು, ಉಳಿಸುವ ಟೋಕನ್ಗಳಿಗಿಂತ ಹೆಚ್ಚಾಗಿ ಸಂಬಳದಲ್ಲಿಯೇ ನಷ್ಟ ಅನುಭವಿಸುತ್ತದೆ. ಅದಕ್ಕಿಂತ ಕೆಟ್ಟದೇನೆ, ಆ ಎರಡು ವಾರಗಳನ್ನು ಬಳಕೆದಾರರು ಕೇಳಿದ ಫೀಚರ್ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಬಳಸಲಾಗುವುದಿಲ್ಲ. ಅವಕಾಶದ ವೆಚ್ಚವು (Opportunity cost) ಬೆಂಚ್ಮಾರ್ಕ್ ಸ್ಕೋರ್ಗಳಿಗಿಂತ ವೇಗವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ.
ಇದು ಅಲಸತನಕ್ಕಾಗಿ ಮಾಡುವ ವಾದವಲ್ಲ. ಇದು ನಿಖರವಾದ ಅಪ್ಗ್ರೇಡ್ಗಳಿಗಾಗಿ ಮಾಡುವ ವಾದ.
ಯಾವಾಗ ಬದಲಾಗಬೇಕು: ಒಂದು ಪ್ರಾಯೋಗಿಕ ಮಾನದಂಡ
ಮುಂದಿನ ಬಾರಿ ಯಾವುದಾದರೂ ಮುಂಚೂಣಿ ಮಾಡೆಲ್ (frontier model) ಬಿಡುಗಡೆಯಾದಾಗ—ಮತ್ತು ಈ ವೇಗದಲ್ಲಿ ನೋಡುವುದಾದರೆ, ಅದು ಮುಂದಿನ ಮಂಗಳವಾರವೇ ಆಗಬಹುದು—ನಿಮ್ಮ ಕೋಡ್ಬೇಸ್ ಅನ್ನು ಬದಲಾಯಿಸುವ ಮೊದಲು ಈ ನಾಲ್ಕು ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಿ.
ಮೊದಲನೆಯದಾಗಿ, ನಿಮ್ಮ ಪ್ರಸ್ತುತ ಮಾಡೆಲ್ ನಿಜವಾಗಿಯೂ ಪರಿಹರಿಸಲಾಗದ ಸಮಸ್ಯೆಯನ್ನು ಇದು ಪರಿಹರಿಸುತ್ತದೆಯೇ? ಇದು ಕೇವಲ ಸೈದ್ಧಾಂತಿಕ ಸಮಸ್ಯೆಯಲ್ಲ, ಬಳಕೆದಾರರು ಎದುರಿಸುತ್ತಿರುವ ನೈಜ ಅಡಚಣೆಯಾಗಿರಬೇಕು. ನಿಮ್ಮ ಗ್ರಾಹಕರು ತಾರ್ಕಿಕ ಆಳದ (reasoning depth) ಬಗ್ಗೆ ದೂರು ನೀಡುತ್ತಿಲ್ಲದಿದ್ದರೆ, ತಾರ್ಕಿಕ ಸಾಮರ್ಥ್ಯದ ಅಪ್ಗ್ರೇಡ್ ಮಾಡುವುದು ಕೇವಲ ನಾಟಕವಷ್ಟೇ.
ಎರಡನೆಯದಾಗಿ, ಇದು ವೆಚ್ಚವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆಯೇ ಅಥವಾ ದಕ್ಷತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆಯೇ? "ಗಮನಾರ್ಹವಾಗಿ" ಎಂದರೆ, ಒಂದು ತ್ರೈಮಾಸಿಕದ ಒಳಗಾಗಿ ಈ ಮೈಗ್ರೇಷನ್ನ ವೆಚ್ಚವನ್ನು ಇದು ಸರಿದೂಗಿಸಬೇಕು. ಅದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವ ಯಾವುದೇ ನಿರ್ಧಾರವು, ಹದಿನಾರು ದಿನಗಳಲ್ಲಿ ಮತ್ತೆ ಬದಲಾಗುವ ಮಾರುಕಟ್ಟೆಯ ಮೇಲಿನ ಕೇವಲ ಊಹೆಯಾಗಿರುತ್ತದೆ.
ಮೂರನೆಯದಾಗಿ, ಇದು ನಿಮ್ಮ ಪ್ರಸ್ತುತ ಕೆಲಸದ ಕ್ರಮಕ್ಕೆ (workflow) ಹೊಂದಿಕೆಯಾಗುತ್ತದೆಯೇ? ಒಂದು ವೇಳೆ ಇದಕ್ಕೆ ಹೊಸ ಇನ್ಫರೆನ್ಸ್ ಪ್ರೊವೈಡರ್, ಕಸ್ಟಮ್ ಪ್ರಾಕ್ಸಿ ಮತ್ತು ನಿಮ್ಮ ಇವ್ಯಾಲ್ಯೂಯೇಶನ್ ಪೈಪ್ಲೈನ್ ಅನ್ನು ಮರುಬರೆಯುವ ಅಗತ್ಯವಿದ್ದರೆ, ಆ ಮಾಡೆಲ್ ಸುಲಭವಾಗಿ ಅಳವಡಿಸಿಕೊಳ್ಳಬಹುದಾದ ಅಪ್ಗ್ರೇಡ್ ಅಲ್ಲ. ಅದು ಕೇವಲ ಒಂದು ಸೈಡ್ ಪ್ರಾಜೆಕ್ಟ್ ಆಗಿ ಉಳಿಯುತ್ತದೆ.
ನಾಲ್ಕನೆಯದು, ಮತ್ತು ಅತ್ಯಂತ ಪ್ರಮುಖವಾದುದು: ಮೈಗ್ರೇಷನ್ನ ವೆಚ್ಚವು ನಿರೀಕ್ಷಿತ ಲಾಭಕ್ಕಿಂತ ಕಡಿಮೆ ಇರುತ್ತದೆಯೇ? ಎಂಜಿನಿಯರಿಂಗ್ ಕೆಲಸದ ಸಮಯದ ಬಗ್ಗೆ ಪ್ರಾಮಾಣಿಕವಾಗಿರಿ. ಟೆಸ್ಟಿಂಗ್, ಮಾನಿಟರಿಂಗ್ ಮತ್ತು ಅನಿವಾರ್ಯವಾದ ರೋಲ್ಬ್ಯಾಕ್ ಪ್ಲಾನ್ ಅನ್ನು ಕೂಡ ಪರಿಗಣಿಸಿ. ಒಂದು ವೇಳೆ ಲಾಭಕ್ಕಿಂತ ನಷ್ಟ ಹೆಚ್ಚಿದ್ದರೆ, ಅಲ್ಲಿಯೇ ಇರಿ.
ಇವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರ 'ಇಲ್ಲ' ಎಂದಾದರೆ, ಅತಿಯಾದ ಪ್ರಚಾರವನ್ನು (hype) ನಿರ್ಲಕ್ಷಿಸಿ. ನಿಮ್ಮ ಪ್ರಸ್ತುತ ಸ್ಟ್ಯಾಕ್ ಸರಿಯಾಗಿದೆ.
ಬೆಂಚ್ಮಾರ್ಕ್ ಮಾಡಬೇಡಿ, ಬಿಡುಗಡೆ ಮಾಡಿ (Ship)
ಇವ್ಯಾಲ್ಯೂಯೇಶನ್ಗಳನ್ನು ಮಾಡುವುದು ಒಂದು ರೀತಿಯ ನೆಮ್ಮದಿಯನ್ನು ನೀಡುತ್ತದೆ. ಅದು ಪ್ರಗತಿಯಂತೆ ಭಾಸವಾಗಬಹುದು. ಆದರೆ ಅದು ಪ್ರಗತಿಯಲ್ಲ.
ಬೆಂಚ್ಮಾರ್ಕ್ಗಳು ಕೇವಲ ಕ್ಷಣಿಕ ಚಿತ್ರಗಳಿದ್ದಂತೆ. ನಿಮ್ಮ ಉತ್ಪನ್ನವು ನಿರಂತರವಾಗಿ ಬದಲಾಗುತ್ತಿರುವ ಗುರಿಯಾಗಿದೆ. ಜುಲೈ ತಿಂಗಳಲ್ಲಿ ಐದು ಮಾಡೆಲ್ಗಳ ನಡುವೆ ಮುಖಾಮುಖಿ ಹೋಲಿಕೆಗಳನ್ನು ಮಾಡಲು ಸಮಯ ವ್ಯಯಿಸುವ ತಂಡವು, ಆಗಸ್ಟ್ ತಿಂಗಳಿನಲ್ಲಿ ಏನನ್ನೂ ಬಿಡುಗಡೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗದೆ ಕುಳಿತುಕೊಳ್ಳುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಜೂನ್ನಲ್ಲಿ ಒಂದು ಮಾಡೆಲ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿ, ಜುಲೈ ತಿಂಗಳಲ್ಲಿ ಅದನ್ನು ಬಳಕೆದಾರರ ಮುಂದೆ ತರಲು ಶ್ರಮಿಸಿದ ತಂಡವು, ಬೆಂಚ್ಮಾರ್ಕ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗದಂತಹ ನೈಜ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು (feedback) ಪಡೆಯುತ್ತದೆ.
ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯು (Execution) ಪರಿಣಾಮವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಆಯ್ಕೆ ಮಾಡಿದ ಮಾಡೆಲ್ ಅನ್ನು ಇಂಟಿಗ್ರೇಟ್ ಮಾಡುವುದು, ಮಾನಿಟರ್ ಮಾಡುವುದು ಮತ್ತು ಅದರಲ್ಲಿ ನಿರಂತರ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವುದರಲ್ಲಿ ಕಳೆಯುವ ಪ್ರತಿಯೊಂದು ಗಂಟೆಯು, ಯಾವುದೇ ಲೀಡರ್ಬೋರ್ಡ್ನಲ್ಲಿ ಸಿಗದಂತಹ ಕಾರ್ಯಾಚರಣೆಯ ಜ್ಞಾನವನ್ನು (operational knowledge) ನೀಡುತ್ತದೆ. ನಿಮ್ಮ ಪ್ರಾಂಪ್ಟ್ಗಳು ಎಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ ಎಂಬುದನ್ನು ನೀವು ಕಲಿಯುತ್ತೀರಿ. ನಿಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ನಿಜವಾಗಿಯೂ ಎಲ್ಲಿ ಸಹಾಯ ಬೇಕಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ತಿಳಿಯುತ್ತೀರಿ. ನೀವು ಸಿಸ್ಟಮ್ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತೀರಿ, ವಿಜ್ಞಾನದ ಪ್ರಯೋಗಗಳನ್ನಲ್ಲ.
ಈ ಅತಿ ವೇಗದ ಬದಲಾವಣೆಗಳು ನಿಲ್ಲುವುದಿಲ್ಲ. ಹದಿನಾರು ದಿನಗಳಲ್ಲಿ ಐದು ಮಾಡೆಲ್ಗಳ ಬಿಡುಗಡೆಯು ಕೇವಲ ಒಂದು ಸಣ್ಣ ಘಟನೆಯಲ್ಲ. ಇದು ಈಗಿನ ಹೊಸ ಸಾಮಾನ್ಯ ಸ್ಥಿತಿ (new normal). ಇದರಲ್ಲಿ ಯಾರು ಉಳಿಯುತ್ತಾರೋ ಅವರು ಅತ್ಯುತ್ತಮ ಬೆಂಚ್ಮಾರ್ಕ್ ಸ್ಪ್ರೆಡ್ಶೀಟ್ ಹೊಂದಿರುವವರಲ್ಲ. ಬದಲಾಗಿ, ತಮ್ಮ ಸ್ಟ್ಯಾಕ್ನ ವೆಚ್ಚ ಎಷ್ಟು, ಅದು ಎಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ ಮತ್ತು ಹೊಸ ಸಾಧನವನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವುದು ಯಾವಾಗ ಲಾಭದಾಯಕ ಎಂಬ ಬಗ್ಗೆ ನಿಖರವಾದ ಅರಿವು ಇರುವವರೇ ಯಶಸ್ವಿಯಾಗುತ್ತಾರೆ.
ರಿಲೀಸ್ ಫೀಡ್ಗಳನ್ನು ರಿಫ್ರೆಶ್ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಬಿಡುಗಡೆ ಮಾಡುವುದನ್ನು ಪ್ರಾರಂಭಿಸಿ.