ਹੈੱਡਲਾਈਨਾਂ ਸਾਨੂੰ ਲਗਾਤਾਰ ਦੱਸ ਰਹੀਆਂ ਹਨ ਕਿ AI ਸੌਫਟਵੇਅਰ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਬੇਕਾਰ ਕਰ ਦੇਵੇਗਾ। ਮੈਨੂੰ ਇਸ 'ਤੇ ਵਿਸ਼ਵਾਸ ਨਹੀਂ ਹੈ। ਅਸਲੀ ਖ਼ਤਰਾ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਮਸ਼ੀਨਾਂ ਇੰਜੀਨੀਅਰਿੰਗ ਦਾ ਕੰਮ ਸੰਭਾਲ ਲੈਣਗੀਆਂ। ਖ਼ਤਰਾ ਇਹ ਹੈ ਕਿ ਇੰਜੀਨੀਅਰ ਸੋਚਣ ਦੀ ਔਖੀ ਮਿਹਨਤ ਕਰਨਾ ਬੰਦ ਕਰ ਦੇਣਗੇ।

ਸੌਫਟਵੇਅਰ ਕਦੇ ਵੀ ਸਿਰਫ਼ syntax ਟਾਈਪ ਕਰਨ ਬਾਰੇ ਨਹੀਂ ਸੀ। ਇਹ ਹਮੇਸ਼ਾ ਤੁਹਾਡੇ ਦਿਮਾਗ ਵਿੱਚ ਗੁੰਝਲਤਾ ਨੂੰ ਸਮਝਣ, failure modes ਨੂੰ ਸਮਝਣ ਅਤੇ ਉਦੋਂ trade-offs ਕਰਨ ਬਾਰੇ ਸੀ ਜਦੋਂ ਕੋਈ ਵੀ ਵਿਕਲਪ ਸੰਪੂਰਨ ਨਾ ਹੋਵੇ। AI ਨੇ ਕੋਡ ਬਣਾਉਣ ਦੀ ਰਫ਼ਤਾਰ ਤਾਂ ਬਦਲ ਦਿੱਤੀ ਹੈ, ਪਰ ਇਸ ਨੇ ਇਹ ਨਹੀਂ ਬਦਲਿਆ ਕਿ ਸਾਨੂੰ ਇਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਮਨੁੱਖਾਂ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ। ਜੇਕਰ ਕੁਝ ਬਦਲਿਆ ਹੈ, ਤਾਂ ਉਹ ਇਹ ਹੈ ਕਿ ਸਪਸ਼ਟ ਸੋਚਣਾ ਹੁਣ ਹੋਰ ਵੀ ਕੀਮਤੀ ਅਤੇ ਦੁਰਲੱਭ ਹੋ ਗਿਆ ਹੈ।

ਪਹਿਲਾ ਡਰਾਫਟ ਇੰਜੀਨੀਅਰਿੰਗ ਨਹੀਂ ਹੈ

ਮੈਂ ਦੇਖ ਰਿਹਾ ਹਾਂ ਕਿ ਜੂਨੀਅਰ ਡਿਵੈਲਪਰਾਂ ਦੀ ਇੱਕ ਵਧਦੀ ਗਿਣਤੀ ChatGPT ਜਾਂ Claude ਨੂੰ ਅਗਲੀ ਕੁਰਸੀ 'ਤੇ ਬੈਠੇ ਸੀਨੀਅਰ ਇੰਜੀਨੀਅਰ ਵਾਂਗ ਮੰਨ ਰਹੀ ਹੈ। ਉਹ ਇੱਕ ticket description ਪੇਸਟ ਕਰਦੇ ਹਨ, ਜਵਾਬ ਕਾਪੀ ਕਰਦੇ ਹਨ, ਟੈਸਟ ਚਲਾਉਂਦੇ ਹਨ, ਅਤੇ commit ਕਰ ਦਿੰਦੇ ਹਨ। ਜੇਕਰ ਇਹ compile ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕੰਮ ਖਤਮ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਚੱਕਰ ਤੇਜ਼, ਰੁਕਾਵਟ ਰਹਿਤ ਅਤੇ ਖ਼ਤਰਨਾਕ ਹੈ।

AI ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ। ਮੈਂ ਇਸ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹਾਂ। ਮੈਂ ਜਿਨ੍ਹਾਂ ਜ਼ਿਆਦਾਤਰ ਉਤਪਾਦਕ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਜਾਣਦਾ ਹਾਂ, ਉਹ ਵੀ ਇਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਸਮੱਸਿਆ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ AI ਕਮਰੇ ਵਿੱਚ ਇਕਲੌਤਾ ਇੰਜੀਨੀਅਰ ਬਣ ਜਾਂਦਾ ਹੈ। ਪਹਿਲੇ ਹੱਲ ਨੂੰ ਸਿਰਫ਼ ਇਸ ਲਈ ਸਵੀਕਾਰ ਕਰ ਲੈਣਾ ਕਿਉਂਕਿ ਇਹ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਇੰਜੀਨੀਅਰਿੰਗ ਨਹੀਂ ਹੈ। ਇਹ ਆਪਣੇ ਫੈਸਲੇ ਲੈਣ ਦੀ ਸਮਰੱਥਾ ਨੂੰ ਇੱਕ ਅਜਿਹੇ ਮਾਡਲ ਨੂੰ ਸੌਂਪਣਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਯੂਜ਼ਰਸ, ਤੁਹਾਡੀਆਂ ਵਪਾਰਕ ਸੀਮਾਵਾਂ, ਜਾਂ ਉਸ ਆਖਰੀ ਵਾਰ ਜਦੋਂ ਤੁਹਾਡਾ stack ਰਾਤ ਦੇ 2 ਵਜੇ ਡਿੱਗ ਗਿਆ ਸੀ, ਉਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਜਾਣਦਾ।

Large language models ਬੇਅੰਤ ਆਤਮ-ਵਿਸ਼ਵਾਸ ਨਾਲ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਭਾਵੇਂ ਉਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਗਲਤ ਹੀ ਕਿਉਂ ਨਾ ਹੋਣ। ਇੱਕ ਇੰਜੀਨੀਅਰ ਨੇ AI ਨੂੰ ਇੱਕ scalable architecture ਡਿਜ਼ਾਈਨ ਕਰਨ ਲਈ ਕਿਹਾ। ਮਾਡਲ ਨੇ ਇੱਕ ਵਿਸਤ੍ਰਿਤ ਅਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਪ੍ਰਸਤਾਵ ਦਿੱਤਾ ਜੋ ਪੂਰੀ ਤਰ੍ਹਾਂ ਇੱਕ ਅਜਿਹੇ ਫੀਚਰ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣਿਆ ਸੀ ਜੋ ਅਸਲ ਉਤਪਾਦ ਵਿੱਚ ਸੀ ਹੀ ਨਹੀਂ। ਇਹ ਸਹੀ ਲੱਗ ਰਿਹਾ ਸੀ। ਇਹ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਇਕਸਾਰ ਸੀ। ਪਰ ਇਹ ਬੇਕਾਰ ਵੀ ਸੀ। ਖ਼ਤਰਾ ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਹੈ ਕਿ AI hallucinate ਕਰਦਾ ਹੈ। ਖ਼ਤਰਾ ਇਹ ਹੈ ਕਿ ਹੁਣ ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਉਨ੍ਹਾਂ hallucinations 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਹੁਣ ਝੂਠ ਨੂੰ ਪਛਾਣਨ ਲਈ ਲੋੜੀਂਦਾ context ਨਹੀਂ ਰੱਖਦੇ।

ਤੁਸੀਂ ਰੁਕਾਵਟਾਂ ਤੋਂ ਸਿੱਖਦੇ ਹੋ

ਜਦੋਂ ਮੈਂ ਇਸ ਬਾਰੇ ਸੋਚਦਾ ਹਾਂ ਕਿ ਮੈਂ ਇੱਕ ਜੂਨੀਅਰ ਡਿਵੈਲਪਰ ਤੋਂ ਇੱਕ ਅਜਿਹਾ ਵਿਅਕਤੀ ਕਿਵੇਂ ਬਣਿਆ ਜੋ ਇੱਕ ਸਿਸਟਮ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਲੈ ਸਕਦਾ ਸੀ, ਤਾਂ ਮੈਨੂੰ ਉਹ syntax ਯਾਦ ਨਹੀਂ ਆਉਂਦਾ ਜੋ ਮੈਂ ਯਾਦ ਕੀਤਾ ਸੀ। ਮੈਨੂੰ outages ਯਾਦ ਹਨ। ਮੈਨੂੰ ਉਹ slow queries ਯਾਦ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਮੈਨੂੰ ਹੱਥ ਨਾਲ trace ਕਰਨਾ ਪਿਆ ਸੀ, ਉਹ race conditions ਜੋ ਸਿਰਫ਼ production load ਦੇ ਅਧੀਨ ਦਿਖਾਈ ਦਿੱਤੀਆਂ ਸਨ, ਅਤੇ ਉਹ deployments ਜੋ ਇਸ ਲਈ ਟੁੱਟ ਗਈਆਂ ਕਿਉਂਕਿ ਮੇਰਾ local environment ਅਸਲ ਦੁਨੀਆ ਵਰਗਾ ਬਿਲਕੁਲ ਨਹੀਂ ਸੀ।

Debugging ਹੀ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਸਿੱਖਣਾ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਕੋਡ ਨੂੰ manually ਚੈੱਕ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ ਸਿਸਟਮ ਅਸਲ ਵਿੱਚ ਕਿਉਂ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ। ਤੁਸੀਂ ਪਤਾ ਲਗਾਉਂਦੇ ਹੋ ਕਿ bottlenecks ਕਿੱਥੇ ਆਉਂਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਸਿੱਖਦੇ ਹੋ ਕਿ ਜਦੋਂ ਤੁਸੀਂ ਦਸ ਯੂਜ਼ਰਾਂ ਵਾਲੇ ਡੈਮੋ ਤੋਂ ਦਸ ਹਜ਼ਾਰ concurrent requests ਸੰਭਾਲਣ ਵਾਲੇ production system ਵੱਲ ਵਧਦੇ ਹੋ, ਤਾਂ architecture ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਅੰਦਰੋਂ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ ਕਿ production ਇੱਕ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਤਿਆਰ ਕੀਤੇ ਡੈਮੋ ਨਾਲੋਂ ਕਿਵੇਂ ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ।

ਉਹ ਸਾਰਾ ਗਿਆਨ ਕਿਸੇ ਜਨਰੇਟ ਕੀਤੇ ਜਵਾਬ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਨਹੀਂ ਮਿਲਦਾ। ਇਹ ਸਮੱਸਿਆ ਨਾਲ ਲੜਨ ਤੋਂ ਮਿਲਦਾ ਹੈ। ਜੇਕਰ AI ਹਰ ਸੰਘਰਸ਼ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ, ਜੇਕਰ ਇਹ ਕੋਡ ਲਿਖਦਾ ਹੈ, bugs ਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ ਅਤੇ ਅਸਫਲਤਾਵਾਂ ਦਾ ਬਹਾਨਾ ਬਣਾਉਂਦਾ ਹੈ, ਤਾਂ ਡਿਵੈਲਪਰਾਂ ਦੀ ਅਗਲੀ ਪੀੜ੍ਹੀ ਆਪਣੀ ਸੀਨੀਅਰਤਾ ਕਿਵੇਂ ਹਾਸਲ ਕਰੇਗੀ? ਤਜਰਬਾ ਕੋਈ ਸਰਟੀਫਿਕੇਟ ਨਹੀਂ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਡਾਊਨਲੋਡ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਉਹ ਨਿਸ਼ਾਨ ਹਨ ਜੋ ਤੁਸੀਂ production incidents ਅਤੇ ਟੁੱਟੀਆਂ ਹੋਈਆਂ deployments ਤੋਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ। ਜੇਕਰ ਤੁਸੀਂ ਰੁਕਾਵਟਾਂ ਨੂੰ ਹਟਾ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਵਿਕਾਸ (growth) ਨੂੰ ਵੀ ਹਟਾ ਦਿੰਦੇ ਹੋ।

ਫੈਸਲਾ ਲੈਣ ਦੀ ਸਮਰੱਥਾ ਜਨਰੇਸ਼ਨ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ

ਕੁਝ ਸਮੇਂ ਲਈ, ਇੰਡਸਟਰੀ ਨੇ prompt engineering ਨੂੰ ਰੈਜ਼ਿਊਮੇ 'ਤੇ ਲਿਖਣ ਲਈ ਇੱਕ ਨਵੀਂ ਅਤੇ ਹੌਟ ਸਕਿੱਲ ਵਜੋਂ ਦੇਖਿਆ। ਇਸ ਨੇ ਅਸਲ ਮਕਸਦ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਗਲਤ ਸਮਝਿਆ। AI ਨਾਲ ਭਰਪੂਰ ਮਾਹੌਲ ਵਿੱਚ ਸਭ ਤੋਂ ਕੀਮਤੀ ਯੋਗਤਾ ਵਿਕਲਪ ਪੈਦਾ ਕਰਨਾ ਨਹੀਂ ਹੈ। ਇਹ ਜਾਣਨਾ ਹੈ ਕਿ ਕਿਹੜੇ ਸੁਝਾਵਾਂ ਨੂੰ ਰੱਦ ਕਰਨਾ ਹੈ।

ਮੈਂ ਜਿਨ੍ਹਾਂ ਵਧੀਆ ਇੰਜੀਨੀਅਰਾਂ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹਾਂ, ਉਹ ਸਭ ਤੋਂ ਵੱਧ prompts ਨਹੀਂ ਲਿਖਦੇ। ਉਹ ਸਭ ਤੋਂ ਔਖੇ ਸਵਾਲ ਪੁੱਛਦੇ ਹਨ। ਉਹ ਜਾਣਦੇ ਹਨ ਕਿ ਕਦੋਂ ਇੱਕ refactor ਇੱਕ ਲੁਕੀ ਹੋਈ dependency ਪੈਦਾ ਕਰਦਾ ਹੈ। ਉਹ ਪਛਾਣ ਲੈਂਦੇ ਹਨ ਕਿ ਕਦੋਂ ਇੱਕ ਜਨਰੇਟ ਕੀਤਾ ਟੈਸਟ ਸਿਰਫ਼ happy path ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ ਪਰ ਉਸ edge case ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੰਦਾ ਹੈ ਜੋ ਗਾਹਕ ਦੇ ਡੇਟਾ ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦਾ ਹੈ। ਉਹ ਬਿਲਕੁਲ ਸਹੀ ਕੋਡ ਨੂੰ ਦੇਖ ਕੇ ਕ

AI ਡਿਵੈਲਪਮੈਂਟ ਲਾਈਫਸਾਈਕਲ ਦੇ ਲਗਭਗ ਹਰ ਹਿੱਸੇ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ ਵੀ ਕੁਝ ਅਜਿਹੀਆਂ ਮੂਲ ਪ੍ਰਣਾਲੀਆਂ ਹਨ ਜੋ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮਨੁੱਖੀ ਹੀ ਰਹਿਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਲਈ ਵਿਰੋਧੀ ਪਾਬੰਦੀਆਂ (constraints) ਵਿਚ ਸੰਤੁਲਨ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਲਾਗਤ, ਲੇਟੈਂਸੀ, ਭਰੋਸੇਯੋਗਤਾ, ਅਤੇ ਭਵਿੱਖ ਦੀ ਰੱਖ-ਰਖਾਅ। ਆਰਕੀਟੈਕਚਰ ਰਿਵਿਊ ਸੰਸਥਾਗਤ ਯਾਦਦਾਸ਼ਤ ਅਤੇ ਦੂਜੇ ਦਰਜੇ ਦੇ ਪ੍ਰਭਾਵਾਂ ਦਾ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਯੋਗਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਮੈਂਟਰਸ਼ਿਪ ਲਈ ਅਜਿਹੇ ਵਿਅਕਤੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਿਸਨੇ ਅਸਲ ਵਿੱਚ ਉਨ੍ਹਾਂ ਅਸਫਲਤਾਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕੀਤਾ ਹੋਵੇ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਉਹ ਤੁਹਾਨੂੰ ਚੇਤਾਵਨੀ ਦੇ ਰਹੇ ਹਨ। ਉਤਪਾਦ ਦੀ ਡੂੰਘੀ ਸਮਝ ਉਪਭੋਗਤਾਵਾਂ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਅਤੇ ਅਸਲ ਵਰਤੋਂ ਦੇ ਦੌਰਾਨ ਉਨ੍ਹਾਂ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਦੇਖਣ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਟ੍ਰੇਨਿੰਗ ਡੇਟਾ ਪੜ੍ਹਨ ਤੋਂ।

ਇੰਜੀਨੀਅਰਿੰਗ ਜੱਜਮੈਂਟ ਉਹਨਾਂ ਅਨੁਭਵਾਂ ਦਾ ਸਾਰ ਹੈ। ਇਹ ਉਹ ਸ਼ਾਂਤ ਆਵਾਜ਼ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਕੋਡ ਰਿਵਿਊ ਪਾਸ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਸ਼ੁੱਕਰਵਾਰ ਦੀ ਦੁਪਹਿਰ ਨੂੰ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕਰਨਾ ਬਹੁਤ ਜੋਖਮ ਭਰਿਆ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਉਹ ਅੰਤਰ-ਬੁੱਧੀ (intuition) ਹੈ ਜੋ ਦੱਸਦੀ ਹੈ ਕਿ ਹੁਣ ਕੀਤੀ ਗਈ ਪਰਫਾਰਮੈਂਸ ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਬਾਅਦ ਵਿੱਚ ਸੁਰੱਖਿਆ ਵਿੱਚ ਕੋਈ ਕਮੀ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ। ਇੱਕ LLM ਕੋਲ ਕੋਈ ਅੰਤਰ-ਬੁੱਧੀ ਨਹੀਂ ਹੁੰਦੀ। ਇਸ ਕੋਲ ਪੈਟਰਨ ਹੁੰਦੇ ਹਨ। ਪੈਟਰਨ ਲਾਭਦਾਇਕ ਹੁੰਦੇ ਹਨ, ਪਰ ਉਹ ਜੱਜਮੈਂਟ ਨਹੀਂ ਹਨ।

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

ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ਾਂ ਤੋਂ ਬਿਨਾਂ ਤੇਜ਼ੀ

AI ਨੂੰ ਇੱਕ ਐਕਸਲਰੇਟਰ ਪੈਡਲ ਵਜੋਂ ਸਮਝੋ। ਇੱਕ ਅਜਿਹੀ ਕਾਰ ਵਿੱਚ ਜਿਸ ਵਿੱਚ