ਮੈਨੂੰ ਲੱਗਿਆ ਕਿ ਮੈਂ ਬਹੁਤ ਚਲਾਕ ਬਣ ਰਿਹਾ ਹਾਂ। ਮੈਂ ਇੱਕ ਹੈਲਪਰ ਫੰਕਸ਼ਨ ਲਿਖਿਆ ਸੀ ਜਿਸਨੇ ਸਾਡੀ AI ਪਾਈਪਲਾਈਨ ਲਈ ਕੰਟੈਕਸਟ ਵਿੰਡੋ (context window) ਦਾ ਬਿਲਕੁਲ ਤੀਹ ਪ੍ਰਤੀਸ਼ਤ ਹਿੱਸਾ ਸੋਚਣ ਦੇ ਬਜਟ (thinking budget) ਵਜੋਂ ਰਾਖਵਾਂ ਕਰ ਲਿਆ ਸੀ। ਇਹ ਸਾਫ਼, ਅਨੁਮਾਨਿਤ ਸੀ, ਅਤੇ Opus 4.5 'ਤੇ ਬਹੁਤ ਵਧੀਆ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ। ਫਿਰ ਮੈਂ Opus 4.8 'ਤੇ ਸਵਿਚ ਕੀਤਾ ਅਤੇ ਹਰ ਇੱਕ ਰਿਕਵੈਸਟ 400 ਐਰਰ ਦੇ ਨਾਲ ਫੇਲ੍ਹ ਹੋ ਗਈ। ਮੇਰਾ ਸੋਚ-ਸਮਝ ਕੇ ਬਣਾਇਆ ਗਿਆ ਟੋਕਨ ਮੈਥ ਰਾਤੋ-ਰਾਤ ਕੂੜਾ ਬਣ ਗਿਆ ਸੀ।

ਪੁਰਾਣਾ ਪੈਟਰਨ ਸਧਾਰਨ ਸੀ। ਤੁਸੀਂ ਇੱਕ budget_tokens ਮੁੱਲ ਸੈੱਟ ਕਰਦੇ ਸੀ ਅਤੇ ਮਾਡਲ ਉਸ ਸੀਮਾ ਦੇ ਅੰਦਰ ਰਹਿਣ ਲਈ ਆਪਣੀ ਰੀਜ਼ਨਿੰਗ ਨੂੰ ਨਿਯਮਤ ਕਰ ਲੈਂਦਾ ਸੀ। ਜੇਕਰ ਮੈਂ 128K ਕੰਟੈਕਸਟ ਦਿੱਤਾ ਹੁੰਦਾ, ਤਾਂ ਮੇਰਾ ਕੋਡ ਰੀਜ਼ਨਿੰਗ ਲਈ ਲਗਭਗ 38,000 ਟੋਕਨ ਕੱਢ ਲੈਂਦਾ ਅਤੇ ਬਾਕੀ ਜਵਾਬ ਲਈ ਛੱਡ ਦਿੰਦਾ। ਇਹ ਜ਼ਿੰਮੇਵਾਰ ਲੱਗਦਾ ਸੀ। ਜਿਵੇਂ ਗੱਡੀ ਨੂੰ ਸਪੀਡ ਲਿਮਟ ਦੇ ਅੰਦਰ ਰੱਖਣਾ।

ਉਹ ਮਾਡਲ ਹੁਣ ਨਹੀਂ ਰਿਹਾ। Opus 4.7 ਅਤੇ 4.8 ਵਰਗੇ ਨਵੇਂ ਰੀਲੀਜ਼ ਐਡੈਪਟਿਵ ਥਿੰਕਿੰਗ (adaptive thinking) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਹੁਣ ਤੁਸੀਂ ਕੋਈ ਨੰਬਰ ਨਹੀਂ ਚੁਣਦੇ। ਇਸ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਇੱਕ effort knob ਪਾਸ ਕਰਦੇ ਹੋ। ਇਹ ਸੁਣਨ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਨਾਮ ਬਦਲਣ ਵਰਗਾ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਦੋਵੇਂ ਕੰਟਰੋਲ ਇੱਕ ਦੂਜੇ ਤੋਂ ਬਿਲਕੁਲ ਵੱਖਰੇ ਹਨ। budget_tokens ਇਸ ਗੱਲ 'ਤੇ ਇੱਕ ਸਖ਼ਤ ਸੀਮਾ ਲਗਾਉਂਦਾ ਸੀ ਕਿ ਮਾਡਲ ਨੂੰ ਕਿੰਨਾ ਸੋਚਣ ਦੀ ਇਜਾਜ਼ਤ ਹੈ। Effort ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਮਾਡਲ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਕਿਵੇਂ ਸੋਚਦਾ ਅਤੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਇੱਕ ਗੈਸ ਪੰਪ ਮੀਟਰ ਹੈ। ਦੂਜਾ ਇੰਜਣ ਮੈਪ ਹੈ।

Effort ਨੂੰ ਅਸਲ ਕੰਮ ਨਾਲ ਜੋੜਨਾ

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

Classification ਅਤੇ routing ਲਈ ਲਗਭਗ ਹਮੇਸ਼ਾ low effort ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਇਹ ਕੰਮ ਤੇਜ਼ ਫੈਸਲੇ ਹਨ। ਕੀ ਇਹ ਰਿਫੰਡ ਦੀ ਬੇਨਤੀ ਹੈ ਜਾਂ ਸੇਲਜ਼ ਦਾ ਸਵਾਲ? ਕੀ ਇਸ ਲੌਗ ਐਂਟਰੀ ਨੂੰ ਅੱਗੇ ਭੇਜਣ (escalation) ਦੀ ਲੋੜ ਹੈ? ਤੁਹਾਨੂੰ ਕਿਸੇ ਲੰਬੀ ਗੱਲਬਾਤ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। Low effort ਲੇਟੈਂਸੀ (latency) ਨੂੰ ਘੱਟ ਰੱਖਦਾ ਹੈ ਅਤੇ ਲਾਗਤ ਨੂੰ ਬਹੁਤ ਹੀ ਘੱਟ ਕਰ ਦਿੰਦਾ ਹੈ।

ਜ਼ਿਆਦਾਤਰ ਐਪ ਟ੍ਰੈਫਿਕ, ਜਿਵੇਂ ਕਿ ਰੋਜ਼ਾਨਾ ਦੇ ਸਾਰ (summaries), ਰੀ-ਰਾਈਟਿੰਗ, ਸਪੋਰਟ ਦੇ ਜਵਾਬ, ਅਤੇ ਕੰਟੈਂਟ ਐਕਸਟ੍ਰੈਕਸ਼ਨ, medium ਤੋਂ high effort ਵਿੱਚ ਆਉਂਦਾ ਹੈ। ਇਹ ਸੰਤੁਲਨ ਦਾ ਬਿੰਦੂ ਹੈ। ਮਾਡਲ ਨੂੰ ਅਸਲ ਅੰਧਵਾਸ਼ (ambiguity) ਨੂੰ ਸੁਲਝਾਉਣ ਲਈ ਕਾਫ਼ੀ ਜਗ੍ਹਾ ਮਿਲਦੀ ਹੈ ਬਿਨਾਂ ਅਜਿਹੇ ਕੰਮ 'ਤੇ ਟੋਕਨ ਖ਼ਰਚ ਕੀਤੇ ਜਿਸ ਲਈ ਲੰਬੀ ਰੀਜ਼ਨਿੰਗ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

Coding ਅਤੇ agentic loops ਲਈ xhigh effort ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਥੇ ਗਲਤੀਆਂ ਵਧਦੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਜੇਕਰ ਮਾਡਲ ਟੂਲ-ਕਾਲਿੰਗ ਲੂਪ ਦੇ ਪਹਿਲੇ ਚੱਕਰ ਵਿੱਚ ਇੱਕ ਮਾੜੀ ਯੋਜਨਾ ਲਿਖਦਾ ਹੈ, ਤਾਂ ਉਹ ਅਗਲੇ ਤਿੰਨ ਕਦਮ ਉਸ ਨੁਕਸਾਨ ਨੂੰ ਸੁਧਾਰਨ ਵਿੱਚ ਬਿਤਾਏਗਾ। ਜਾਂ ਇਸ ਤੋਂ ਵੀ ਮਾੜਾ, ਇਹ ਗਲਤ ਟੂਲ ਕਾਲ ਕਰੇਗਾ, ਪੈਰਾਮੀਟਰਾਂ ਦਾ ਭਰਮ (hallucinate) ਕਰੇਗਾ, ਅਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਇੱਕ ਟੁੱਟੇ ਹੋਏ ਵਰਕਫਲੋ ਦੇ ਨਾਲ ਛੱਡ ਦੇਵੇਗਾ। ਸ਼ੁਰੂ ਵਿੱਚ ਬਿਹਤਰ ਰੀਜ਼ਨਿੰਗ ਉਸ ਚੱਕਰ ਨੂੰ ਰੋਕਦੀ ਹੈ।

ਮਹੱਤਵਪੂਰਨ ਕੰਮ (Critical tasks) ਨੂੰ max effort ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸਦੀ ਵਰਤੋਂ ਹਰ ਚੀਜ਼ ਲਈ ਨਾ ਕਰੋ। ਇਸਨੂੰ ਉਹਨਾਂ ਪਲਾਂ ਲਈ ਰਾਖਵਾਂ ਰੱਖੋ ਜਿੱਥੇ ਇੱਕ ਗਲਤ ਜਵਾਬ ਕਿਸੇ ਵੀ ਟੋਕਨ ਬਿੱਲ ਨਾਲੋਂ ਵੱਧ ਨੁਕਸਾਨ ਕਰ ਸਕਦਾ ਹੈ। ਵਿੱਤੀ ਮੇਲ-ਜੋਲ (Financial reconciliations), ਸੁਰੱਖਿਆ ਜਾਂਚ, ਆਰਕੀਟੈਕਚਰ ਦੇ ਫੈਸਲੇ, ਅਤੇ ਮੈਡੀਕਲ ਟ੍ਰਾਇਜ (medical triage) ਇਸਦੇ ਲਈ ਸਹੀ ਹਨ। ਜੇਕਰ ਇੱਕ ਗਲਤੀ ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਇੱਕ ਇਨਸਾਨ ਨੂੰ ਘੰਟਿਆਂ ਬੱਧੀ ਇਸ ਉਲਝਣ ਨੂੰ ਸੁਲਝਾਉਣਾ ਪਵੇਗਾ, ਤਾਂ ਵਾਧੂ ਸੋਚਣ ਲਈ ਭੁਗਤਾਨ ਕਰੋ।

ਲਾਗਤ ਦਾ ਹੈਰਾਨੀਜਨਕ ਪਹਿਲੂ

ਇੱਥੇ ਉਹ ਹਿੱਸਾ ਹੈ ਜਿਸਨੇ ਮੇਰੇ ਮਾਨਸਿਕ ਮਾਡਲ ਨੂੰ ਤੋੜ ਦਿੱਤਾ। ਮੈਂ ਮੰਨਿਆ ਸੀ ਕਿ max effort ਹਮੇਸ਼ਾ ਮੇਰੀ ਲਾਗਤ ਨੂੰ ਵਧਾ ਦੇਵੇਗਾ। ਇੱਕ ਸਿੰਗਲ ਟਰਨ 'ਤੇ, ਇਹ ਕਰਦਾ ਹੈ। ਰੀਜ਼ਨਿੰਗ ਟ੍ਰੇਸ (reasoning trace) ਲੰਬਾ ਹੁੰਦਾ ਹੈ। ਪਰ ਮਲਟੀ-ਸਟੈਪ ਏਜੈਂਟਿਕ ਟਾਸਕਸ 'ਤੇ, ਕੁੱਲ ਬਿੱਲ ਅਕਸਰ ਘਟ ਗਿਆ।

ਮਾਡਲ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਬਿਹਤਰ ਯੋਜਨਾ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਘੱਟ ਟੂਲ ਕਾਲ ਕਰਦਾ ਹੈ। ਇਹ ਆਪਣੇ ਆਪ ਨੂੰ ਗਲਤ ਰਸਤੇ 'ਤੇ ਜਾਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਮੈਂ ਇੱਕ ਡਾਟਾ ਐਕਸਟ੍ਰੈਕਸ਼ਨ ਏਜੰਟ ਨੂੰ ਦੇਖਿਆ ਜਿਸਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਪੰਜ ਵਾਰ ਆਉਣ-ਜਾਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਸੀ, ਉਹ ਦੋ ਵਾਰ ਵਿੱਚ ਹੀ ਖਤਮ ਹੋ ਗਿਆ ਕਿਉਂਕਿ ਮਾਡਲ ਕੋਲ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਸਕੀਮਾ (schema) ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਪੜ੍ਹਨ ਲਈ ਕਾਫ਼ੀ ਰੀਜ਼ਨਿੰਗ ਜਗ੍ਹਾ ਸੀ। ਜਦੋਂ ਤੁਸੀਂ ਲਾਗਤ ਨੂੰ ਮਾਪਦੇ ਹੋ, ਤਾਂ ਕੰਮ ਦੀ ਪੂਰਤੀ (job completion) ਨੂੰ ਦੇਖੋ, ਨਾ ਕਿ ਰਿਕਵੈਸਟ ਨੂੰ। ਪ੍ਰਤੀ ਸਟੈਪ ਇੱਕ ਵੱਡਾ ਥਿੰਕਿੰਗ ਬਜਟ ਕੁੱਲ ਸਟੈਪਸ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ।

ਬਾਕੀ ਸਭ ਕੁਝ ਵਿਗਾੜੇ ਬਿਨਾਂ ਮਾਈਗ੍ਰੇਟ ਕਿਵੇਂ ਕਰੀਏ

ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਡਬੇਸ ਵਿੱਚ ਅਜੇ ਵੀ budget_tokens ਮੌਜੂਦ ਹੈ, ਤਾਂ ਇੱਥੇ ਬਾਹਰ ਨਿਕਲਣ ਦਾ ਸਹੀ ਰਸਤਾ ਹੈ। ਤੀਜੇ ਅਤੇ ਪੰਜਵੇਂ ਸਟੈਪ ਨੂੰ ਨਾ ਛੱਡੋ। ਮੈਂ ਛੱਡ ਦਿੱਤਾ ਸੀ, ਅਤੇ ਇਸਦੀ ਮੈਨੂੰ ਇੱਕ ਦੁਪਹਿਰ ਡੀਬੱਗਿੰਗ ਵਿੱਚ ਲੱਗ ਗਈ।

ਆਪਣੇ ਕੋਡ ਵਿੱਚ budget_tokens ਲੱਭੋ। ਹਰ ਇੱਕ ਇੰਸਟੈਂਸ ਨੂੰ ਹਟਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਨਵੇਂ ਮਾਡਲਾਂ 'ਤੇ ਇਹ ਪੈਰਾਮੀਟਰ ਖਤਮ ਹੋ ਚੁੱਕਾ ਹੈ ਅਤੇ ਇਹ 400 ਐਰਰ ਦੇਵੇਗਾ।

ਬਜਟ ਆਬਜੈਕਟ ਨੂੰ ਇੱਕ adaptive thinking ਬਲਾਕ ਨਾਲ ਬਦਲੋ। thinking: { type: "adaptive" } ਦੀ ਵਰਤੋਂ ਕਰੋ।

ਹਰੇਕ ਕਾਲ ਲਈ ਇੱਕ ਸਪੱਸ਼ਟ effort ਲੈਵਲ ਦੇ ਨਾਲ output_config ਜੋੜੋ। ਜੇਕਰ ਤੁਹਾਡਾ ਟ੍ਰੈਫਿਕ ਮਿਸ਼ਰਤ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਗਲੋਬਲ ਡਿਫੌਲਟ 'ਤੇ ਨਾ ਛੱਡੋ। ਤੁਹਾਡਾ ਹਲਕਾ-ਫੁਲਕਾ ਕਲਾਸੀਫਿਕੇਸ਼ਨ ਐਂਡਪੁਆਇੰਟ ਗਲਤੀ ਨਾਲ ਤੁਹਾਡੇ ਕੋਡਿੰਗ ਏਜੰਟ ਵਾਂਗ ਹੀ ਉਹੀ effort ਸੈਟਿੰਗ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਕਾਲ ਸਾਈਟ 'ਤੇ ਸਪੱਸ਼ਟ ਰਹੋ।

ਆਪਣਾ ਬਜਟ ਕੈਲਕੂਲੇਸ਼ਨ ਹੈਲਪਰ ਡਿਲੀਟ ਕਰ ਦਿਓ। ਮੈਂ ਜਾਣਦਾ ਹਾਂ। ਸ਼ਾਇਦ ਇਸਦੇ ਯੂਨਿਟ ਟੈਸਟ (unit tests) ਹੋਣਗੇ। ਮੇਰੇ ਸਨ। ਪਰ ਇਹ ਹੁਣ ਬੇਕਾਰ ਦਾ ਭਾਰ ਹੈ। ਪਲੇਟਫਾਰਮ ਨੂੰ ਤੁਹਾਡੇ ਟੋਕਨ ਮੈਥ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਮਾਡਲ ਆਪਣੀ ਰਫ਼ਤਾਰ ਖੁਦ ਸੰਭਾਲਦਾ ਹੈ।

temperature, top_p, ਅਤੇ top_k ਨੂੰ ਹਟਾ ਦਿਓ। Opus 4.7 ਅਤੇ 4.8 'ਤੇ, ਇਹ sampling parameters 400 errors ਦੇਣਗੇ। ਪਲੇਟਫਾਰਮ ਨੇ ਇਸ ਜਨਰੇਸ਼ਨ ਵਿੱਚੋਂ ਇਹਨਾਂ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਹੈ। ਤੁਹਾਡੀਆਂ ਪੁਰਾਣੀਆਂ temperature-tuning tricks ਇੱਥੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀਆਂ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਰੱਖਣ ਨਾਲ ਤੁਹਾਡਾ migration ਚੁੱਪਚਾਪ ਖਰਾਬ ਹੋ ਜਾਵੇਗਾ।

ਹਰੇਕ ਮਾਡਲ ਦਾ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਟੈਸਟ ਕਰੋ। Opus 4.5 ਅਤੇ 4.8 ਬਿਲਕੁਲ ਵੱਖਰੇ ਹਨ। ਇੱਕ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੀ config ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਦੂਜੇ 'ਤੇ ਵੀ ਕੰਮ ਕਰੇ। ਜੇਕਰ ਤੁਸੀਂ ਕਈ ਵਰਜ਼ਨਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਆਪਣੇ logic ਨੂੰ ਵੱਖ ਕਰੋ ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਵੱਖਰੇ backends ਵਜੋਂ ਮੰਨੋ।

UI Freeze ਨੂੰ ਠੀਕ ਕਰਨਾ

ਇੱਕ streaming ਵਿਵਹਾਰ ਅਜਿਹਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਉਲਝਨ ਵਿੱਚ ਪਾ ਸਕਦਾ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਸੰਭਾਲਦੇ ਨਹੀਂ ਹੋ। ਨਵੇਂ ਮਾਡਲਾਂ 'ਤੇ, thinking blocks stream ਹੁੰਦੇ ਹਨ ਪਰ text ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਖਾਲੀ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਡੇ interface ਵਿੱਚ, ਇਹ ਬਿਨਾਂ ਕਿਸੇ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਪ੍ਰਗਤੀ ਦੇ ਇੱਕ ਲੰਬੇ, ਅਜੀਬ ਵਿਰਾਮ ਵਾਂਗ ਲੱਗਦਾ ਹੈ। ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਲੱਗੇਗਾ ਕਿ ਐਪ ਹੈਂਗ ਹੋ ਗਈ ਹੈ।

ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ, thinking: { type: "adaptive", display: "summarized" } pass ਕਰੋ। ਇਹ ਚੈਟ ਵਿੰਡੋ ਵਿੱਚ raw thought stream ਨੂੰ ਡੰਪ ਕੀਤੇ ਬਿਨਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ progress indicator ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਤੁਹਾਡਾ frontend responsive ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਅੰਦਰ ਕੁਝ ਹੋ ਰਿਹਾ ਹੈ।

ਅਸਲੀ ਸਬਕ

ਮੈਂ ਇੱਕ ਅਜਿਹੇ parameter ਦੇ ਉੱਪਰ ਪੂਰੀ abstraction layer ਬਣਾਈ ਸੀ ਜਿਸ ਨੂੰ vendor ਨੇ ਕਦੇ ਵੀ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਰੱਖਣ ਦਾ ਇਰਾਦਾ ਨਹੀਂ ਰੱਖਿਆ ਸੀ। ਮੈਂ ਉਹਨਾਂ ਦੀਆਂ settings ਨੂੰ ਆਪਣੇ logic ਵਿੱਚ ਲਪੇਟ ਦਿੱਤਾ ਸੀ ਕਿਉਂਕਿ ਮੈਨੂੰ ਲੱਗਿਆ ਸੀ ਕਿ ਮੈਂ platform ਨਾਲੋਂ ਬਿਹਤਰ ਤਰੀਕੇ ਨਾਲ tradeoff ਨੂੰ ਸਮਝਦਾ ਹਾਂ। ਮੈਂ ਗਲਤ ਸੀ। Adaptive thinking ਇੱਕ ਬਿਹਤਰ ਵਿਕਲਪ ਹੈ ਕਿਉਂਕਿ ਮਾਡਲ ਅਸਲ ਵਿੱਚ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਉਸਨੂੰ ਕਦੋਂ ਡੂੰਘਾਈ ਨਾਲ ਸੋਚਣ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਕਦੋਂ ਉਹ ਆਰਾਮ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ। ਮੇਰਾ codebase ਹੁਣ ਛੋਟਾ ਹੈ। ਨਤੀਜੇ ਹੋਰ ਵੀ ਸਪੱਸ਼ਟ ਹੋ ਗਏ ਹਨ। ਕਦੇ-ਕਦੇ ਸਹੀ engineering ਕਦਮ ਚਲਾਕ ਕੋਡ ਨੂੰ ਮਿਟਾਉਣਾ ਅਤੇ platform ਨੂੰ ਆਪਣਾ ਕੰਮ ਕਰਨ ਦੇਣਾ ਹੁੰਦਾ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਅਸਲੀ migration notes ਪੜ੍ਹਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਇੱਥੇ ਲੱਭ ਸਕਦੇ ਹੋ। ਇਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਹੋਰ hands-on ਚਰਚਾਵਾਂ ਲਈ, Telegram 'ਤੇ GyaanSetu AI community ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੋ।