2,900 ਇੰਜੀਨੀਅਰਾਂ ਦੇ 2026 ਦੇ ਸਰਵੇਖਣ ਅਨੁਸਾਰ, ਡਿਵੈਲਪਰ ਹੁਣ ਹਫ਼ਤੇ ਵਿੱਚ 11.4 ਘੰਟੇ AI-ਨਿਰਮਿਤ ਕੋਡ ਦੀ ਸਮੀਖਿਆ ਕਰਨ ਵਿੱਚ ਬਿਤਾਉਂਦੇ ਹਨ, ਜੋ ਕਿ 9.8 ਘੰਟੇ ਹਨ ਜੋ ਉਹ ਖੁਦ ਲਿਖਦੇ ਹਨ, ਇਸ ਨੂੰ ਪਛਾੜਦੇ ਹੋਏ। ਰੁਕਾਵਟ ਹੁਣ "ਕੀ AI ਕੋਡ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ?" ਤੋਂ ਬਦਲ ਕੇ "ਕੀ ਅਸੀਂ ਇਸ ਦੁਆਰਾ ਪੈਦਾ ਕੀਤੇ ਗਏ ਕੋਡ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਾਂ?" 'ਤੇ ਆ ਗਈ ਹੈ ਅਤੇ ਟੀਮਾਂ ਮਲਟੀ-ਏਜੰਟ AI ਵਰਕਫਲੋਜ਼ (multi-agent AI workflows) ਵੱਲ ਵਧ ਰਹੀਆਂ ਹਨ ਜੋ ਸਪੱਸ਼ਟ ਫੈਸਲੇ ਲੈਣ ਦੇ ਰਸਤੇ ਅਤੇ ਉੱਚਾ ਭਰੋਸਾ ਵਾਅਦਾ ਕਰਦੇ ਹਨ।

ਉਹ ਸਰਵੇਖਣ ਜਿਸ ਨੇ ਚਰਚਾ ਸ਼ੁਰੂ ਕੀਤੀ

ਇਸ ਸਾਲ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਕੀਤੇ ਗਏ ਪ੍ਰਸ਼ਨ ਪੱਤਰ ਵਿੱਚ, ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਪੁੱਛਿਆ ਗਿਆ ਸੀ ਕਿ ਉਹ ਨਵਾਂ ਕੋਡ ਲਿਖਣ ਅਤੇ AI ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਗਏ ਕੋਡ ਦੀ ਜਾਂਚ ਕਰਨ ਵਿਚਕਾਰ ਸਮਾਂ ਕਿਵੇਂ ਵੰਡਦੇ ਹਨ। ਉੱਤਰ ਦੇਣ ਵਾਲਿਆਂ ਨੇ ਕਿਹਾ ਕਿ ਸਮੀਖਿਆ ਕਰਨ ਵਿੱਚ ਹੁਣ ਸ਼ੁਰੂਆਤੀ ਕੋਡ ਬਣਾਉਣ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ। ਉਨ੍ਹਾਂ ਨੇ ਇੱਕੋ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਦੋ ਤੋਂ ਚਾਰ ਵੱਖ-ਵੱਖ AI ਸਹਾਇਕਾਂ (assistants) ਨੂੰ ਸੰਭਾਲਣ ਦੀ ਰਿਪੋਰਟ ਵੀ ਦਿੱਤੀ, ਅਤੇ 70% ਨੇ ਕਿਹਾ ਕਿ ਇਹ ਅਭਿਆਸ ਰੁਟੀਨ ਬਣ ਗਿਆ ਹੈ।

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

ਇੱਕ ਸਿੰਗਲ ਮਾਡਲ ਹੁਣ ਕਿਉਂ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ

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

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

ਕੰਮ ਨੂੰ ਵੰਡਣਾ: ਮਲਟੀ-ਏਜੰਟ ਸਿਸਟਮ ਕਿਵੇਂ ਮਦਦ ਕਰਦੇ ਹਨ

ਮਲਟੀ-ਏਜੰਟ ਸੈੱਟਅੱਪ ਇੱਕ ਛੋਟੀ ਡਿਵੈਲਪਮੈਂਟ ਟੀਮ ਦੀ ਨਕਲ ਕਰਦੇ ਹਨ। ਇੱਕ ਮਾਡਲ ਦੁਆਰਾ ਸਭ ਕੁਝ ਸੰਭਾਲਣ ਦੀ ਬਜਾਏ, ਵੱਖ-ਵੱਖ ਏਜੰਟ ਵੱਖ-ਵੱਖ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨਿਭਾਉਂਦੇ ਹਨ:

  • Architect agent: ਇੱਕ ਉੱਚ-ਪੱਧਰੀ ਡਿਜ਼ਾਈਨ ਦਸਤਾਵੇਜ਼ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਡਾਟਾ ਮਾਡਲਾਂ, API ਕੰਟਰੈਕਟਸ ਅਤੇ ਐਰਰ-ਹੈਂਡਲਿੰਗ ਰਣਨੀਤੀਆਂ ਦੀ ਰੂਪਰੇਖਾ ਬਣਾਉਂਦਾ ਹੈ।
  • Implementation agent: ਕੋਡ ਲਿਖਦਾ ਹੈ ਜੋ ਸਪੈਸੀਫਿਕੇਸ਼ਨਾਂ ਨੂੰ ਇੱਕ ਚੈੱਕਲਿਸਟ ਵਜੋਂ ਵਰਤਦੇ ਹੋਏ ਬਿਲਕੁਲ ਆਰਕੀਟੈਕਚਰ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ।
  • Verification agent: ਯੂਨਿਟ ਟੈਸਟ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਸਟੈਟਿਕ ਵਿਸ਼ਲੇਸ਼ਣ (static analysis) ਚਲਾਉਂਦਾ ਹੈ, ਜਾਂ CI/CD ਪਾਈਪਲਾਈਨਾਂ ਪ੍ਰੋਵੀਜ਼ਨ ਕਰਦਾ ਹੈ, ਜੋ ਸਿਰਫ ਕੁਆਲਿਟੀ ਐਸ਼ੋਰੈਂਸ 'ਤੇ ਕੇਂਦਰਿਤ ਹੁੰਦਾ ਹੈ।

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

ਉਹ ਟੂਲ ਜੋ ਮਲਟੀ-ਏਜੰਟ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਵਿਵਹਾਰਕ ਬਣਾ ਰਹੇ ਹਨ

ਡਿਵੈਲਪਰ ਪਹਿਲਾਂ ਹੀ ਵੱਖ-ਵੱਖ ਯੂਟੀਲਿਟੀਜ਼ ਦੇ ਮਿਸ਼ਰਣ ਨਾਲ ਇਹ ਪਾਈਪਲਾਈਨਾਂ ਤਿਆਰ ਕਰ ਰਹੇ ਹਨ:

  • IDE integrations ਏਜੰਟਾਂ ਨੂੰ ਸਾਈਡ ਪੈਨਲਾਂ ਵਜੋਂ ਦਿਖਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ, ਇੱਕ ਕਲਿੱਕ ਨਾਲ ਆਰਕੀਟੈਕਚਰ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਕੋਡ-ਜਨਰੇਸ਼ਨ ਸਹਾਇਕ ਨੂੰ ਭੇਜਦੇ ਹਨ।
  • CLI utilities ਸਕ੍ਰਿਪਟਡ ਸੀਕਵੈਂਸਾਂ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਆਰਕੀਟੈਕਟ ਨੂੰ ਚਲਾਓ, ਇਸਦੇ ਆਉਟਪੁੱਟ ਨੂੰ ਕੋਡਰ ਨੂੰ ਭੇਜੋ, ਫਿਰ ਨਤੀਜੇ ਨੂੰ ਟੈਸਟਰ ਨੂੰ ਸੌਂਪੋ।
  • Frameworks ਕਸਟਮ ਏਜੰਟ ਬਣਾਉਣ ਲਈ ਲਾਇਬ੍ਰੇਰੀਆਂ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਪ੍ਰੋਜੈਕਟ ਦੀਆਂ ਲੋੜਾਂ ਦੇ ਅਨੁਸਾਰ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ।
  • Specification-first platforms ਕਿਸੇ ਵੀ ਜਨਰੇਸ਼ਨ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਰਸਮੀ ਲੋੜਾਂ (requirements) ਫਾਈਲ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਨ ਕਿ ਡਿਜ਼

ਇੱਕ ਵਿਰੋਧੀ ਦਲੀਲ ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਮਲਟੀ-ਏਜੰਟ ਸਿਸਟਮ ਜਟਿਲਤਾ ਵਧਾਉਂਦੇ ਹਨ। ਤਿੰਨ ਜਾਂ ਇਸ ਤੋਂ ਵੱਧ ਮਾਡਲਾਂ ਦਾ ਤਾਲਮੇਲ ਕਰਨ ਨਾਲ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਬੱਗ ਆ ਸਕਦੇ ਹਨ, ਲੈਟੈਂਸੀ ਵਧ ਸਕਦੀ ਹੈ, ਅਤੇ ਵਧੇਰੇ ਉੱਨਤ ਨਿਗਰਾਨੀ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਉਹ ਟੀਮਾਂ ਜਿਨ੍ਹਾਂ ਕੋਲ ਕਸਟਮ ਏਜੰਟ ਬਣਾਉਣ ਜਾਂ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਮਾਹਰਤਾ ਦੀ ਕਮੀ ਹੈ, ਉਹ ਅਸਲ ਵਿਕਾਸ ਦੀ ਬਜਾਏ ਆਰਕੈਸਟ੍ਰੇਸ਼ਨ 'ਤੇ ਵਧੇਰੇ ਸਮਾਂ ਬਿਤਾ ਸਕਦੀਆਂ ਹਨ। ਉਹਨਾਂ ਸਮੂਹਾਂ ਲਈ, ਇੱਕ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਟਿਊਨ ਕੀਤਾ ਗਿਆ ਸਿੰਗਲ ਮਾਡਲ—ਖਾਸ ਕਰਕੇ ਉਹ ਜੋ ਇਨ-ਬਿਲਟ ਵਿਆਖਿਆਯੋਗਤਾ (explainability) ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ—ਇੱਕ ਵਿਹਾਰਕ ਚੋਣ ਬਣਿਆ ਰਹਿ ਸਕਦਾ ਹੈ।

ਆਉਣ ਵਾਲੇ ਮਹੀਨਿਆਂ ਵਿੱਚ ਕਿਸ ਚੀਜ਼ 'ਤੇ ਨਜ਼ਰ ਰੱਖੀਏ

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

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