ਇੰਜੀਨੀਅਰਿੰਗ ਜੱਜਮੈਂਟ (Engineering Judgment) ਸਭ ਤੋਂ ਦੁਰਲੱਭ ਸਰੋਤ ਬਣ ਰਹੀ ਹੈ

ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ (Implementation) ਸਸਤੀ ਹੁੰਦੀ ਜਾ ਰਹੀ ਹੈ। ਇਹ ਜੱਜਮੈਂਟ ਨੂੰ ਮਹਿੰਗਾ ਬਣਾਉਂਦੀ ਹੈ।

ਜੱਜਮੈਂਟ ਦਾ ਮਤਲਬ ਸਿਰਫ਼ ਅੰਦਾਜ਼ਾ ਜਾਂ ਰਾਏ ਨਹੀਂ ਹੈ। ਇਹ ਅਨਿਸ਼ਚਿਤਤਾ ਦੇ ਹਾਲਾਤਾਂ ਵਿੱਚ ਫੈਸਲੇ ਲੈਣ ਦੀ ਸਮਰੱਥਾ ਹੈ। AI ਇਸ ਹੁਨਰ ਨੂੰ ਪਹਿਲਾਂ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਬਣਾ ਰਿਹਾ ਹੈ।

ਦੋ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਇੱਕੋ ਜਿਹਾ ਕੰਮ ਮਿਲ ਸਕਦਾ ਹੈ: ਇਨਵੌਇਸ ਰੀਕੰਸੀਲੀਏਸ਼ਨ (invoice reconciliation) ਲਈ ਇੱਕ API ਬਣਾਉਣਾ। AI ਦੋਵਾਂ ਲਈ ਕੋਡ ਲਿਖ ਸਕਦਾ ਹੈ। ਸਿੰਟੈਕਸ (syntax) ਅਤੇ ਫਰੇਮਵਰਕ (frameworks) ਇੱਕੋ ਜਿਹੇ ਲੱਗਣਗੇ।

ਅੰਤਮ ਸਿਸਟਮ ਵੱਖੋ-ਵੱਖਰੇ ਹੋਣਗੇ। ਇੱਕ ਇੰਜੀਨੀਅਰ ਸ਼ਾਇਦ ਇੱਕ ਅਜਿਹੀ ਗੁੰਝਲਦਾਰ ਸਰਵਿਸ ਬਣਾਵੇ ਜਿਸ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣਾ (maintain) ਮੁਸ਼ਕਲ ਹੋਵੇ। ਦੂਜਾ ਸ਼ਾਇਦ ਬਿਜ਼ਨਸ ਨਿਯਮਾਂ ਅਤੇ ਲੌਜਿਕ ਨੂੰ ਸੁਤੰਤਰ ਕੰਪੋਨੈਂਟਸ ਵਿੱਚ ਵੱਖ ਕਰ ਦੇਵੇ।

ਉਹ ਚੋਣ AI ਨੇ ਨਹੀਂ ਕੀਤੀ। ਇੰਜੀਨੀਅਰ ਨੇ ਕੀਤੀ।

ਆਰਕੀਟੈਕਚਰ (Architecture) ਅਜੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਹੁਣ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਅੰਤਰ ਪੈਦਾ ਕਰਨ ਵਾਲਾ ਕਾਰਕ ਨਹੀਂ ਰਹੀ। ਕੋਡ ਦੇ ਪਿੱਛੇ ਲਏ ਗਏ ਫੈਸਲੇ ਅੰਤਰ ਪੈਦਾ ਕਰਦੇ ਹਨ।

AI ਦੇ ਆਉਣ ਨਾਲ ਗੁੰਝਲਤਾ ਖਤਮ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਸਿਰਫ਼ ਆਪਣੀ ਜਗ੍ਹਾ ਬਦਲ ਲੈਂਦੀ ਹੈ।

ਪਹਿਲਾਂ, ਇੰਜੀਨੀਅਰ ਵਿਚਾਰਾਂ ਨੂੰ ਕੋਡ ਵਿੱਚ ਬਦਲਣ ਲਈ ਸਮਾਂ ਬਿਤਾਉਂਦੇ ਸਨ। ਹੁਣ, AI ਉਹ ਕੰਮ ਕਰਦਾ ਹੈ। ਅਸਲੀ ਮਿਹਨਤ ਇੱਕ ਲਾਈਨ ਵੀ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦੀ ਹੈ।

ਤੁਹਾਨੂੰ ਅਜਿਹੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਪੈਣਗੇ:

  • ਅਸੀਂ ਕਿਹੜੀ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕਰ ਰਹੇ ਹਾਂ?
  • ਸੱਚਾਈ ਦਾ ਸਰੋਤ (source of truth) ਕਿਹੜਾ ਡੇਟਾ ਹੈ?
  • ਬਿਜ਼ਨਸ ਨਿਯਮ ਕਿੱਥੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ?
  • ਅਸੀਂ ਸਫਲਤਾ ਨੂੰ ਕਿਵੇਂ ਮਾਪਦੇ ਹਾਂ?

Autocomplete ਇਹਨਾਂ ਦੇ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦਾ। ਇਹਨਾਂ ਲਈ ਸੰਦਰਭ (context) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਸਾਫਟਵੇਅਰ ਡਿਵੈਲਪਮੈਂਟ ਹੁਣ ਇਨਫਰਮੇਸ਼ਨ ਇੰਜੀਨੀਅਰਿੰਗ (information engineering) ਵਾਂਗ ਲੱਗਦੀ ਹੈ। ਰੁਕਾਵਟ ਕੋਡ ਨਹੀਂ ਹੈ। ਰੁਕਾਵਟ ਜਾਣਕਾਰੀ (information) ਹੈ।

ਤੁਹਾਡਾ ਸਾਹਮਣਾ ਹੁੰਦਾ ਹੈ:

  • ਲੋੜਾਂ (requirements) ਦੀ ਘਾਟ।
  • ਅਧੂਰੀ ਡਾਕੂਮੈਂਟੇਸ਼ਨ।
  • ਆਪਸੀ ਟਕਰਾਅ ਵਾਲੇ ਬਿਜ਼ਨਸ ਨਿਯਮ।
  • ਅਣਪਛਾਤੀ ਮਾਲਕੀ (ownership)।

ਉਹ ਇੰਜੀਨੀਅਰ ਜੋ ਜਾਣਕਾਰੀ ਨੂੰ ਸੰਗਠਿਤ ਕਰਦਾ ਹੈ, ਉਸ ਨਾਲੋਂ ਵੱਧ ਮੁੱਲ (value) ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਕੋਡ ਲਿਖਦਾ ਹੈ।

ਵਰਕਫਲੋ (workflow) ਬਦਲ ਗਿਆ ਹੈ। ਪਹਿਲਾਂ ਇਹ ਅਜਿਹਾ ਹੁੰਦਾ ਸੀ: Requirement -> Design -> Code -> Debug -> Deploy।

ਹੁਣ ਇਹ ਹੈ: Business Problem -> Context -> Architecture -> AI Implementation -> Human Review -> Security -> Evaluation -> Production।

ਕੋਡਿੰਗ ਹੁਣ ਪ੍ਰਕਿਰਿਆ ਦਾ ਇੱਕ ਛੋਟਾ ਹਿੱਸਾ ਹੈ। ਆਲੇ-ਦੁਆਲੇ ਦੀਆਂ ਗਤੀਵਿਧੀਆਂ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।

ਵੱਡੇ ਪ੍ਰਭਾਵ ਵਾਲੇ ਫੈਸਲੇ ਕੋਡ ਐਡੀਟਰ ਤੋਂ ਬਾਹਰ ਲਏ ਜਾਂਦੇ ਹਨ। ਉਹ ਉਦੋਂ ਲਏ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਪੁੱਛਦੇ ਹੋ:

  • ਕੀ ਇਹ ਇੱਕ ਵੱਖਰੀ ਸਰਵਿਸ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ?
  • ਕੀ ਅਸੀਂ ਇਸ ਫੈਸਲੇ ਦੀ ਜਾਂਚ (audit) ਕਰ ਸਕਦੇ ਹਾਂ?
  • ਜੇਕਰ AI ਗਲਤ ਹੋਵੇ ਤਾਂ ਕੀ ਹੋਵੇਗਾ?
  • ਕੀ ਇਹ ਆਰਕੀਟੈਕਚਰ ਵਿਕਸਿਤ ਹੋ ਸਕਦਾ ਹੈ?

AI ਇੰਜੀਨੀਅਰਿੰਗ ਸਿਰਫ਼ ਪ੍ਰੋਂਪਟ (prompts) ਜਾਂ ਮਾਡਲ ਦੀ ਚੋਣ ਤੋਂ ਕਿਤੇ ਵੱਧ ਹੈ। ਉਹ ਸਿਰਫ਼ ਇੱਕ ਪਰਤ ਹਨ।

ਅਸਲੀ ਚੁਣੌਤੀਆਂ ਆਰਕੀਟੈਕਚਰਲ ਹਨ:

  • ਅਸੀਂ ਬਿਜ਼ਨਸ ਗਿਆਨ ਨੂੰ ਕਿਵੇਂ ਮਾਡਲ ਕਰਦੇ ਹਾਂ?
  • ਅਸੀਂ ਅਸਪਸ਼ਟਤਾ (ambiguity) ਨੂੰ ਕਿਵੇਂ ਦੂਰ ਕਰਦੇ ਹਾਂ?
  • ਅਸੀਂ ਭਰੋਸਾ ਕਿਵੇਂ ਬਣਾਈ ਰੱਖਦੇ ਹਾਂ?

ਮਾਡਲ ਹਰ ਕੁਝ ਮਹੀਨਿਆਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ। ਆਰਕੀਟੈਕਚਰ ਸਾਲਾਂ ਤੱਕ ਚਲਦੇ ਹਨ। ਇੱਕ ਮਾੜਾ ਆਰਕੀਟੈਕਚਰ ਬਹੁਤ ਜਲਦੀ ਮਹਿੰਗਾ ਸਾਬਤ ਹੁੰਦਾ ਹੈ।

ਵਧੀਆ ਟੀਮਾਂ ਅਜਿਹੇ ਸਿਸਟਮ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਮਾਡਲਾਂ ਦੀਆਂ ਕਈ ਪੀੜ੍ਹੀਆਂ ਤੱਕ ਟਿਕ ਸਕਣ। ਉਹ ਅਨੁਕੂਲਤਾ (adaptability) ਲਈ ਆਪਟੀਮਾਈਜ਼ ਕਰਦੇ ਹਨ।

AI ਅਬਸਟਰੈਕਸ਼ਨ (abstraction) ਦੀ ਇੱਕ ਹੋਰ ਪਰਤ ਹੈ। ਉੱਚ ਅਬਸਟਰੈਕਸ਼ਨ ਲਈ ਮਜ਼ਬੂਤ ਤਰਕ (reasoning) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਕਮਜ਼ੋਰ ਤਰਕ ਦੀ ਨਹੀਂ।

ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਇੰਜੀਨੀਅਰ ਸਭ ਤੋਂ ਤੇਜ਼ ਪ੍ਰੋਗਰਾਮਰ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਉਹ ਹਨ ਜੋ ਸਪਸ਼ਟਤਾ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਉਹ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ, ਡੇਟਾ ਨੂੰ ਮਿਆਰੀ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਅਸਪਸ਼ਟਤਾ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।

ਇੱਕ ਚੰਗਾ ਸਿਸਟਮ ਮਨੁੱਖਾਂ ਅਤੇ AI ਏਜੰਟਾਂ ਨੂੰ ਮਿਲ ਕੇ ਕੰਮ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਇੱਕ ਮਾੜਾ ਸਿਸਟਮ ਸਿਰਫ਼ ਗਲਤੀਆਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵਧਾਉਂਦਾ ਹੈ।

ਉਹ ਇੰਜੀਨੀਅਰ ਜੋ ਸਪਸ਼ਟਤਾ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਉਹ ਲਿਵਰੇਜ (leverage) ਪੈਦਾ ਕਰਦਾ ਹੈ।

Source: https://dev.to/uigerhana/engineering-judgment-is-becoming-the-scarcest-resource-1a5l

Optional learning community: https://t.me/GyaanSetuAi