ਉਹ ਦੋ ਹਫ਼ਤਿਆਂ ਦਾ ਹੜ੍ਹ ਜਿਸਨੇ ਖੇਡ ਬਦਲ ਦਿੱਤੀ

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 ਨੂੰ ਜਨਤਕ ਤੌਰ 'ਤੇ ਰਿਲੀਜ਼ ਕੀਤਾ।

ਪੰਜ ਅਤਿ-ਆਧੁਨਿਕ ਮਾਡਲ। ਸੋਲ਼ਹੇ ਦਿਨ। ਇਹ ਕੋਈ ਪ੍ਰੋਡਕਟ ਸਾਈਕਲ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਤੇਜ਼ ਧਾਰਾ (firehose) ਵਾਂਗ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਡਿਵੈਲਪਰ, ਪ੍ਰੋਡਕਟ ਮੈਨੇਜਰ, ਜਾਂ ਇੱਕ ਫਾਊਂਡਰ ਹੋ ਜੋ ਇਹਨਾਂ ਸਿਸਟਮਾਂ 'ਤੇ ਕੁਝ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਰਫ਼ਤਾਰ ਉਤਸ਼ਾਹਜਨਕ ਨਹੀਂ ਹੈ। ਇਹ ਥਕਾ ਦੇਣ ਵਾਲੀ ਹੈ। ਮਾਈਗ੍ਰੇਟ ਕਰਨ, ਟੈਸਟ ਕਰਨ ਅਤੇ ਨਵੇਂ ਨੰਬਰਾਂ ਦੇ ਪਿੱਛੇ ਭੱਜਣ ਦਾ ਮਾਨਸਿਕ ਦਬਾਅ ਅਸਲੀ ਹੈ। ਪਰ ਹਰ ਰਿਲੀਜ਼ ਦੇ ਪਿੱਛੇ ਭੱਜਣਾ ਹੁਣ ਅਧਿਕਾਰਤ ਤੌਰ 'ਤੇ ਇੱਕ ਮਾੜੀ ਰਣਨੀਤੀ ਹੈ।

ਮਾਡਲ ਵਾਰਜ਼ ਤੋਂ ਪਲੇਟਫਾਰਮ ਵਾਰਜ਼ ਤੱਕ

ਅਸੀਂ ਇਕੱਲੇ ਲੀਡਰ ਦੇ ਯੁੱਗ ਤੋਂ ਅੱਗੇ ਨਿਕਲ ਚੁੱਕੇ ਹਾਂ। ਸਾਲਾਂ ਤੱਕ, ਪੈਟਰਨ ਸਧਾਰਨ ਸੀ: ਇੱਕ ਲੈਬ ਕੋਈ ਵੱਡੀ ਕਾਢ ਲਿਆਉਂਦੀ ਸੀ, ਬਾਕੀ ਸਭ ਭੱਜ-ਦੌੜ ਕਰਦੇ ਸਨ, ਅਤੇ ਉਹ ਲੀਡਰ ਮਹੀਨਿਆਂ ਤੱਕ ਬਾਜ਼ਾਰ 'ਤੇ ਕਬਜ਼ਾ ਰੱਖਦਾ ਸੀ। ਹੁਣ ਉਹ ਮਹੀਨੇ ਦਿਨਾਂ ਵਿੱਚ ਬਦਲ ਗਏ ਹਨ।

ਜਦੋਂ ਇੱਕੋ ਪੰਦਰਾਂ ਦਿਨਾਂ ਵਿੱਚ ਪੰਜ ਅਸਲ ਵਿੱਚ ਸਮਰੱਥ ਮਾਡਲ ਆ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਪਹਿਲੇ ਅਤੇ ਪੰਜਵੇਂ ਸਥਾਨ ਦੇ ਵਿਚਕਾਰ ਦਾ ਅੰਤਰ ਬਹੁਤ ਹੀ ਨਿਗੁਣ ਹੋ ਜਾਂਦਾ ਹੈ। ਸਮਰੱਥਾ ਹੁਣ ਫਰਕ ਪਾਉਣ ਵਾਲਾ ਕਾਰਕ ਨਹੀਂ ਰਹੀ। ਲੜਾਈ ਦਾ ਮੈਦਾਨ ਹੁਣ 'ਸਟੈਕ' (stack) ਤੱਕ ਪਹੁੰਚ ਗਿਆ ਹੈ। ਅਸੀਂ 'ਮਾਡਲ ਵਾਰਜ਼' ਤੋਂ 'ਪਲੇਟਫਾਰਮ ਵਾਰਜ਼' ਵੱਲ ਤਬਦੀਲੀ ਦੇਖ ਰਹੇ ਹਾਂ।

ਇਸਦਾ ਅਭਿਆਸ ਵਿੱਚ ਕੀ ਮਤਲਬ ਹੈ, ਇਸ ਬਾਰੇ ਸੋਚੋ। ਜੇਕਰ ਤੁਹਾਡੇ ਚੁਣੇ ਹੋਏ ਬੈਂਚਮਾਰਕ 'ਤੇ GPT-5.6 Terra ਅਤੇ Grok 4.5 ਦੇ ਸਕੋਰਾਂ ਵਿੱਚ ਇੱਕ ਅੰਕ ਤੋਂ ਵੀ ਘੱਟ ਦਾ ਫਰਕ ਹੈ, ਤਾਂ ਫੈਸਲਾ ਕਰਨ ਵਾਲੀ ਚੀਜ਼ ਬੁੱਧੀ (intelligence) ਨਹੀਂ ਹੋਵੇਗੀ। ਫੈਸਲਾ ਇਸ ਗੱਲ 'ਤੇ ਹੋਵੇਗਾ ਕਿ ਕੀ Terra ਦੀ ਲੇਟੈਂਸੀ (latency) ਤੁਹਾਡੇ ਰੀਅਲ-ਟਾਈਮ ਚੈਟ ਬਜਟ ਦੇ ਅਨੁਕੂਲ ਹੈ, ਜਾਂ ਕੀ Cursor ਨਾਲ Grok ਦਾ ਇੰਟੈਗ੍ਰੇਸ਼ਨ ਤੁਹਾਡੀ ਟੀਮ ਦੇ ਹਰ ਸਪ੍ਰਿੰਟ ਵਿੱਚ ਤਿੰਨ ਘੰਟੇ ਦਾ ਬੁਨਿਆਦੀ ਕੰਮ ਬਚਾਉਂਦਾ ਹੈ। ਲੈਬ ਵਿੱਚ ਸਭ ਤੋਂ ਸਮਾਰਟ ਮਾਡਲ ਅਕਸਰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਗਲਤ ਮਾਡਲ ਸਾਬਤ ਹੁੰਦਾ ਹੈ।

ਹੁਣ ਅਸਲ ਵਿੱਚ ਕੀ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ

ਜਦੋਂ ਪ੍ਰਦਰਸ਼ਨ (performance) ਇੱਕੋ ਜਿਹਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਹੋਰ ਕਾਰਕ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦੇ ਹਨ। ਤੁਹਾਡੇ ਮੁਲਾਂਕਣ ਦੇ ਮਾਪਦੰਡ ਇੱਕ ਰਿਸਰਚ ਪੇਪਰ ਵਰਗੇ ਨਹੀਂ, ਸਗੋਂ ਇੱਕ ਖਰੀਦ ਸ਼ੀਟ (procurement sheet) ਵਰਗੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

ਪਹਿਲਾਂ ਪ੍ਰਤੀ ਟੋਕਨ ਲਾਗਤ (cost per token) ਦੇਖੋ। ਇੱਕ ਮਾਡਲ ਜੋ ਤਰਕ (reasoning) ਵਿੱਚ 10% ਬਿਹਤਰ ਹੈ ਪਰ ਵੱਡੇ ਪੱਧਰ 'ਤੇ 3 ਗੁਣਾ ਮਹਿੰਗਾ ਹੈ, ਉਹ ਤੁਹਾਡੇ ਉਤਪਾਦ ਨੂੰ ਸੁਧਾਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਡੇ ਮੁਨਾਫੇ (margin) ਨੂੰ ਖਤਮ ਕਰ ਦੇਵੇਗਾ।

ਲੇਟੈਂਸੀ ਅਤੇ ਰਫ਼ਤਾਰ ਦੇਖੋ। ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਲਾਈਵ ਕੋਡਿੰਗ ਸਹਾਇਕ ਜਾਂ ਰੀਅਲ-ਟਾਈਮ ਅਨੁਵਾਦ ਟੂਲ ਚਲਾ ਰਹੇ ਹੋ, ਤਾਂ 500ms ਦੀ ਦੇਰੀ ਇੱਕ ਮਰਿਆ ਹੋਇਆ ਪ੍ਰੋਡਕਟ ਹੈ। ਇੱਕ ਥੋੜ੍ਹਾ ਜਿਹਾ ਘੱਟ ਸਮਾਰਟ ਮਾਡਲ ਜੋ 50ms ਵਿੱਚ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਉਹ ਯੂਜ਼ਰਸ ਨੂੰ ਜੋੜ ਕੇ ਰੱਖਦਾ ਹੈ।

ਭਰੋਸੇਯੋਗਤਾ ਦੇਖੋ। ਸਿਧਾਂਤਕ ਸਮਰੱਥਾ ਨਾਲੋਂ ਅਪਟਾਈਮ (uptime) ਦੀ ਗਾਰੰਟੀ, ਰੇਟ ਲਿਮਿਟਸ, ਅਤੇ ਲਗਾਤਾਰ ਆਊਟਪੁੱਟ ਸਟ੍ਰਕਚਰ ਜ਼ਿਆਦਾ ਮ

ਇਹ ਸੰਤੁਸ਼ਟੀ ਲਈ ਕੋਈ ਦਲੀਲ ਨਹੀਂ ਹੈ। ਇਹ ਸਟੀਕ (surgical) ਅੱਪਗ੍ਰੇਡਾਂ ਲਈ ਇੱਕ ਦਲੀਲ ਹੈ।

ਕਦੋਂ ਬਦਲਣਾ ਹੈ: ਇੱਕ ਵਿਹਾਰਕ ਫਿਲਟਰ

ਅਗਲੀ ਵਾਰ ਜਦੋਂ ਕੋਈ frontier model ਆਉਂਦਾ ਹੈ—ਅਤੇ ਇਸ ਰਫ਼ਤਾਰ ਨਾਲ, ਇਹ ਅਗਲੇ ਮੰਗਲਵਾਰ ਨੂੰ ਵੀ ਹੋ ਸਕਦਾ ਹੈ—ਆਪਣੇ codebase ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਚਾਰ ਸਵਾਲਾਂ ਵਿੱਚੋਂ ਲੰਘਾਓ।

ਪਹਿਲਾ, ਕੀ ਇਹ ਉਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਡਾ ਮੌਜੂਦਾ ਮਾਡਲ ਸੱਚਮੁੱਚ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ? ਕੋਈ ਸਿਧਾਂਤਕ ਸਮੱਸਿਆ ਨਹੀਂ। ਇੱਕ ਅਸਲ ਯੂਜ਼ਰ-ਮੁਖੀ ਰੁਕਾਵਟ। ਜੇਕਰ ਤੁਹਾਡੇ ਗਾਹਕ reasoning depth ਬਾਰੇ ਸ਼ਿਕਾਇਤ ਨਹੀਂ ਕਰ ਰਹੇ ਹਨ, ਤਾਂ reasoning ਅੱਪਗ੍ਰੇਡ ਸਿਰਫ਼ ਇੱਕ ਦਿਖਾਵਾ ਹੈ।

ਦੂਜਾ, ਕੀ ਇਹ ਲਾਗਤ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਰੂਪ ਵਿੱਚ ਘਟਾਉਂਦਾ ਹੈ ਜਾਂ ਕੁਸ਼ਲਤਾ ਵਧਾਉਂਦਾ ਹੈ? "ਮਹੱਤਵਪੂਰਨ" ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਇੱਕ ਤਿਮਾਹੀ (quarter) ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ migration ਦੀ ਲਾਗਤ ਕੱਢ ਦਿੰਦਾ ਹੈ। ਇਸ ਤੋਂ ਵੱਧ ਕੁਝ ਵੀ ਉਸ ਬਾਜ਼ਾਰ 'ਤੇ ਸਿਰਫ਼ ਅੰਦਾਜ਼ਾ ਹੈ ਜੋ ਸੋਲ਼੍ਹੇ ਦਿਨਾਂ ਵਿੱਚ ਫਿਰ ਤੋਂ ਬਦਲ ਜਾਵੇਗਾ।

ਤੀਜਾ, ਕੀ ਇਹ ਤੁਹਾਡੇ ਮੌਜੂਦਾ workflow ਵਿੱਚ ਫਿੱਟ ਬੈਠਦਾ ਹੈ? ਜੇਕਰ ਇਸ ਲਈ ਇੱਕ ਨਵੇਂ inference provider, ਇੱਕ custom proxy, ਅਤੇ ਤੁਹਾਡੇ evaluation pipeline ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਹ ਮਾਡਲ ਸਿਰਫ਼ ਇੱਕ ਸੌਖਾ ਅੱਪਗ੍ਰੇਡ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ side project ਹੈ।

ਚੌਥਾ, ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ: ਕੀ migration ਦੀ ਲਾਗਤ ਉਮੀਦ ਕੀਤੇ ਫਾਇਦੇ ਨਾਲੋਂ ਘੱਟ ਹੋਵੇਗੀ? ਇੰਜੀਨੀਅਰਿੰਗ ਘੰਟਿਆਂ ਬਾਰੇ ਇਮਾਨਦਾਰ ਰਹੋ। Testing, monitoring, ਅਤੇ ਲਾਜ਼ਮੀ rollback plan ਨੂੰ ਵੀ ਸ਼ਾਮਲ ਕਰੋ। ਜੇਕਰ ਹਿਸਾਬ-ਕਿਤਾਬ ਘਾਟੇ ਵਿੱਚ ਹੈ, ਤਾਂ ਉੱਥੇ ਹੀ ਰਹੋ।

ਜੇਕਰ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਦਾ ਵੀ ਜਵਾਬ 'ਨਹੀਂ' ਹੈ, ਤਾਂ hype ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰੋ। ਤੁਹਾਡਾ ਮੌਜੂਦਾ stack ਠੀਕ ਹੈ।

Ship ਕਰੋ, Benchmark ਨਾ ਕਰੋ

Evaluations ਚਲਾਉਣ ਵਿੱਚ ਇੱਕ ਖਾਸ ਆਰਾਮ ਮਿਲਦਾ ਹੈ। ਇਹ ਤਰੱਕੀ ਵਾਂਗ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਪਰ ਇਹ ਤਰੱਕੀ ਨਹੀਂ ਹੈ।

Benchmarks ਸਿਰਫ਼ ਇੱਕ ਝਲਕ ਹਨ। ਤੁਹਾਡਾ ਉਤਪਾਦ ਇੱਕ ਬਦਲਦਾ ਰਹਿੰਦਾ ਨਿਸ਼ਾਨਾ ਹੈ। ਉਹ ਟੀਮ ਜੋ ਜੁਲਾਈ ਦਾ ਸਮਾਂ ਪੰਜ ਮਾਡਲਾਂ ਦੀ ਆਹਮੋ-ਸਾਹਮਣੇ ਤੁਲਨਾ ਕਰਨ ਵਿੱਚ ਬਿਤਾਉਂਦੀ ਹੈ, ਉਹ ਟੀਮ ਅਗਸਤ ਵਿੱਚ ਕੁਝ ਵੀ ship ਨਹੀਂ ਕਰ ਪਾਉਂਦੀ। ਇਸ ਦੇ ਉਲਟ, ਉਹ ਟੀਮ ਜਿਸਨੇ ਜੂਨ ਵਿੱਚ ਇੱਕ ਮਾਡਲ ਚੁਣਿਆ ਅਤੇ ਜੁਲਾਈ ਦਾ ਸਮਾਂ ਉਸਨੂੰ ਯੂਜ਼ਰਸ ਦੇ ਸਾਹਮਣੇ ਲਿਆਉਣ ਵਿੱਚ ਬਿਤਾਇਆ, ਉਸ ਕੋਲ ਅਜਿਹਾ feedback ਹੁੰਦਾ ਹੈ ਜਿਸਦਾ ਤੁਸੀਂ benchmark ਨਹੀਂ ਕਰ ਸਕਦੇ।

Execution ਦਾ ਪ੍ਰਭਾਵ ਵਧਦਾ ਜਾਂਦਾ ਹੈ। ਚੁਣੇ ਹੋਏ ਮਾਡਲ ਨੂੰ integrate ਕਰਨ, monitor ਕਰਨ ਅਤੇ ਉਸ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨ ਵਿੱਚ ਬਿਤਾਇਆ ਹਰ ਘੰਟਾ ਅਜਿਹਾ operational knowledge ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਕੋਈ ਵੀ leaderboard ਕੈਪਚਰ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਤੁਸੀਂ ਸਿੱਖਦੇ ਹੋ ਕਿ ਤੁਹਾਡੇ prompts ਕਿੱਥੇ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ। ਤੁਸੀਂ ਸਿੱਖਦੇ ਹੋ ਕਿ ਤੁਹਾਡੇ ਯੂਜ਼ਰਸ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਮਦਦ ਦੀ ਲੋੜ ਹੈ। ਤੁਸੀਂ systems ਬਣਾਉਂਦੇ ਹੋ, ਵਿਗਿਆਨਕ ਪ੍ਰਯੋਗ ਨਹੀਂ।

ਇਹ ਤੇਜ਼ ਰਫ਼ਤਾਰ (firehose) ਘੱਟ ਨਹੀਂ ਹੋਵੇਗੀ। ਸੋਲ਼੍ਹੇ ਦਿਨ ਅਤੇ ਪੰਜ ਮਾਡਲ ਕੋਈ ਅਸਥਾਈ ਘਟਨਾ ਨਹੀਂ ਹੈ। ਇਹ ਨਵਾਂ ਆਮ (new normal) ਹੈ। ਜੋ builders ਇਸ ਵਿੱਚ ਟਿਕ ਕੇ ਰਹਿਣਗੇ, ਉਹ ਉਹ ਨਹੀਂ ਹੋਣਗੇ ਜਿਨ੍ਹਾਂ ਕੋਲ ਸਭ ਤੋਂ ਵਧੀਆ benchmark spreadsheet ਹੋਵੇਗੀ। ਉਹ ਉਹ ਹੋਣਗੇ ਜੋ ਜਾਣਦੇ ਹਨ ਕਿ ਉਨ੍ਹਾਂ ਦੇ stack ਦੀ ਲਾਗਤ ਕੀ ਹੈ, ਉਹ ਕਿੱਥੇ ਟੁੱਟਦਾ ਹੈ, ਅਤੇ ਬਿਲਕੁਲ ਕਦੋਂ ਇੱਕ ਨਵਾਂ ਟੂਲ ਵਰਤਣਾ ਬਦਲਾਅ ਲਈ ਜਾਇਜ਼ ਹੈ।

Release feed ਨੂੰ refresh ਕਰਨਾ ਬੰਦ ਕਰੋ। Ship ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ।