ਸਾਲਾਂ ਤੋਂ, ਆਰਟੀਫੀਸ਼ੀਅਲ ਇੰਟੈਲੀਜੈਂਸ ਐਡੀਟਰ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ ਬੈਠਦੀ ਸੀ ਅਤੇ ਅੰਦਾਜ਼ਾ ਲਗਾਉਂਦੀ ਸੀ ਕਿ ਅੱਗੇ ਕੀ ਆਵੇਗਾ। ਤੁਸੀਂ ਇੱਕ ਲਾਈਨ ਲਿਖਦੇ ਸੀ; ਇਹ ਅਗਲੀ ਲਾਈਨ ਦਾ ਸੁਝਾਅ ਦਿੰਦੀ ਸੀ। ਆਰਕੀਟੈਕਚਰ, ਡੀਬੱਗਿੰਗ ਅਤੇ ਸਿੰਟੈਕਸ (syntax) ਅਜੇ ਵੀ ਤੁਹਾਡੇ ਅਧੀਨ ਸਨ। ਉਹ ਵਿਵਸਥਾ ਹੁਣ ਖ਼ਤਮ ਹੋ ਚੁੱਕੀ ਹੈ।
ਅਸੀਂ Intent-Driven Development ਵੱਲ ਵਧ ਰਹੇ ਹਾਂ। ਤੁਸੀਂ ਲੂਪਸ (loops) ਅਤੇ ਕੰਡੀਸ਼ਨਲਸ (conditionals) ਟਾਈਪ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ। ਇਸ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਉਸ ਨਤੀਜੇ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹੋ ਜਿਸਦੀ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ। ਇੱਕ ਏਜੰਟ (agent) ਉਸ ਟੀਚੇ ਨੂੰ ਸਮਝਦਾ ਹੈ, ਕਦਮਾਂ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦਾ ਹੈ, ਕੋਡ ਲਿਖਦਾ ਹੈ, ਟੈਸਟ ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਦੁਆਰਾ ਨਤੀਜਾ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਆਪਣੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਸੁਧਾਰ ਲੈਂਦਾ ਹੈ। ਕੀਬੋਰਡ ਹੁਣ ਮੁੱਖ ਸਾਧਨ ਨਹੀਂ ਰਿਹਾ। ਸਪੱਸ਼ਟ ਸੋਚ ਹੀ ਹੁਣ ਮੁੱਖ ਸਾਧਨ ਹੈ।
ਲਾਈਨ-ਦਰ-ਲਾਈਨ ਕੋਡਿੰਗ ਦਾ ਅੰਤ
ਪੁਰਾਣੇ ਵਰਕਫਲੋ (workflow) ਵਿੱਚ ਤੁਹਾਨੂੰ ਹਰ ਇਰਾਦੇ ਨੂੰ ਇੱਕ ਖਾਸ ਭਾਸ਼ਾ ਵਿੱਚ ਬਦਲਣ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਸੀ ਜਿਸਨੂੰ ਕੰਪਾਈਲਰ (compiler) ਸਮਝ ਸਕੇ। ਤੁਸੀਂ ਬਿਜ਼ਨਸ ਦੀਆਂ ਲੋੜਾਂ ਨੂੰ ਆਪਣੇ ਦਿਮਾਗ ਵਿੱਚ ਰੱਖਦੇ ਸੀ, ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਮੈਨੂਅਲੀ ਫੰਕਸ਼ਨਾਂ, ਇੰਪੋਰਟਸ, ਐਰਰ ਹੈਂਡਲਿੰਗ ਅਤੇ ਟੈਸਟ ਕੇਸਾਂ ਵਿੱਚ ਵੰਡ ਦਿੰਦੇ ਸੀ। Intent-Driven Development ਉਸ ਅਨੁਵਾਦ ਲੇਅਰ (translation layer) ਨੂੰ ਖ਼ਤਮ ਕਰ ਦਿੰਦਾ ਹੈ।
ਮੰਨ ਲਓ ਤੁਹਾਨੂੰ ਇੱਕ ਪੇਮੈਂਟ ਵੈੱਬਹੂਕ (payment webhook) ਨੂੰ ਇੰਟੀਗ੍ਰੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਪਹਿਲਾਂ, ਤੁਸੀਂ ਰੂਟ ਹੈਂਡਲਰ ਲਿਖਦੇ, ਪੇਲੋਡ (payload) ਨੂੰ ਪਾਰਸ ਕਰਦੇ, ਸਿਗਨੇਚਰ ਨੂੰ ਵੈਲੀਡੇਟ ਕਰਦੇ, ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੇ ਅੰਦਰ ਡਾਟਾਬੇਸ ਨੂੰ ਅਪਡੇਟ ਕਰਦੇ, ਅਤੇ ਰਸੀਦ ਈਮੇਲ ਦੀ ਕਿਊ (queue) ਬਣਾਉਂਦੇ। ਹੁਣ ਤੁਸੀਂ ਲੋੜ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹੋ: “ਆਉਣ ਵਾਲੇ Stripe webhook ਨੂੰ ਵੈਲੀਡੇਟ ਕਰੋ, ਘਟਨਾ ਨੂੰ idempotently ਰਿਕਾਰਡ ਕਰੋ, ਅਤੇ ਰਸੀਦ ਪ੍ਰਕਿਰਿਆ (receipt flow) ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਡਾਟਾਬੇਸ ਲਿਖਣ ਵਿੱਚ ਅਸਫਲਤਾ ਆਉਂਦੀ ਹੈ ਤਾਂ ਰੋਲ ਬੈਕ (roll back) ਕਰੋ।” ਏਜੰਟ ਹੈਂਡਲਰ ਲਿਖਦਾ ਹੈ, ਪਾਰਸਿੰਗ ਰਣਨੀਤੀ ਚੁਣਦਾ ਹੈ, ਰੀਟ੍ਰਾਈ ਲੌਜਿਕ (retry logic) ਨੂੰ ਸੰਗਠਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਟੈਸਟ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਤੁਹਾਡੀ ਭੂਮਿਕਾ ਲੇਖਕ ਤੋਂ ਡਾਇਰੈਕਟਰ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ।
ਇਹ ਸਿਰਫ਼ ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਏਜੰਟ ਸਿਰਫ਼ ਕੋਡ ਬਣਾਉਣ (generation) 'ਤੇ ਨਹੀਂ ਰੁਕਦਾ। ਇਹ ਇੱਕ ਲੂਪ (loop) ਵਿੱਚ ਪ੍ਰਵੇਸ਼ ਕਰਦਾ ਹੈ।
ਏਜੰਟ ਲੂਪ ਦੇ ਅੰਦਰ
ਮੁੱਖ ਕੰਮ ਹੁਣ ਮਨੁੱਖੀ ਟਾਈਪਿੰਗ ਜਾਂ ਮੈਨੂਅਲ ਡੀਬੱਗਿੰਗ ਨਹੀਂ ਰਿਹਾ। ਇਹ ਜਨਰੇਸ਼ਨ ਅਤੇ ਵੈਲੀਡੇਸ਼ਨ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਸਖ਼ਤ ਚੱਕਰ ਹੈ। ਏਜੰਟ ਕੋਡ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਇਸਨੂੰ ਤੁਹਾਡੇ ਟੈਸਟ ਸੂਟ (test suite) ਦੇ ਵਿਰੁੱਧ ਚਲਾਉਂਦਾ ਹੈ, ਆਉਟਪੁੱਟ ਪੜ੍ਹਦਾ ਹੈ, ਅਤੇ ਖੁਦ ਹੀ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ। ਇੱਕ ਗਲਤ ਇੰਪੋਰਟ, ਇੱਕ ਟਾਈਪ ਮਿਸਮੈਚ, ਇੱਕ ਫੇਲ ਹੋ ਰਹੀ ਅਸਰਸ਼ਨ (assertion) — ਏਜੰਟ ਸਟੈਕ ਟ੍ਰੇਸ (stack trace) ਦੇਖਦਾ ਹੈ, ਫਾਈਲ ਨੂੰ ਐਡਿਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਸੂਟ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਉਸ ਲੂਪ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦੇ। ਇਹ ਚੱਕਰ ਮਸ਼ੀਨੀ ਗਤੀ ਨਾਲ ਚੱਲਦਾ ਹੈ।
ਤੁਸੀਂ ਉਦੋਂ ਦਖਲ ਦਿੰਦੇ ਹੋ ਜਦੋਂ ਲੂਪ ਖੁਦ ਟੁੱਟ ਜਾਂਦਾ ਹੈ। ਸ਼ਾਇਦ ਏਜੰਟ ਦੋ ਡਿਪੈਂਡੈਂਸੀਆਂ (dependencies) ਵਿਚਕਾਰ ਟਕਰਾਅ ਨੂੰ ਸੁਲਝਾ ਨਹੀਂ ਸਕਦਾ, ਜਾਂ ਇਹ ਅਜਿਹਾ ਕੋਡ ਬਣਾਉਂਦਾ ਰਹਿੰਦਾ ਹੈ ਜੋ ਯੂਨਿਟ ਟੈਸਟਾਂ ਵਿੱਚੋਂ ਤਾਂ ਲੰਘ ਜਾਂਦਾ ਹੈ ਪਰ ਉੱਚ-ਪੱਧਰੀ ਬਿਜ਼ਨਸ ਨਿਯਮਾਂ ਦੀ ਉਲੰਘਣਾ ਕਰਦਾ ਹੈ। ਉਹ ਸੀਮਾਵਾਂ ਹਨ ਜਿੱਥੇ ਮਨੁੱਖੀ ਫੈਸਲੇਬਾਜ਼ੀ ਅਜੇ ਵੀ ਮਹੱਤਵ ਰੱਖਦੀ ਹੈ।
ਤੁਹਾਡਾ ਅਸਲ ਕੰਮ: Constraint Designer ਅਤੇ Edge-Case Hunter
ਜੇ ਮਸ਼ੀਨ ਫੰਕਸ਼ਨ ਲਿਖਦੀ ਹੈ, ਤਾਂ ਤੁਹਾ
ਜਦੋਂ ਕੋਡ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਉਤਪਾਦ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ
ਇੱਥੇ ਇੱਕ ਵਿਰੋਧਾਭਾਸ ਹੈ। ਹਾਰਨੈੱਸ (harness) ਖ਼ਰਾਬ ਕੋਡ ਨੂੰ ਫੜ ਲੈਂਦਾ ਹੈ। ਇਹ ਖ਼ਰਾਬ ਇਰਾਦੇ (intent) ਨੂੰ ਨਹੀਂ ਫੜ ਸਕਦਾ।
ਜੇਕਰ ਤੁਹਾਡੀ ਸਪੈਸੀਫਿਕੇਸ਼ਨ (specification) ਕਹਿੰਦੀ ਹੈ, "ਹਰ ਨਵੇਂ ਯੂਜ਼ਰ ਨੂੰ ਵੈਲਕਮ ਈਮੇਲ ਭੇਜੋ," ਤਾਂ ਏਜੰਟ ਸਾਫ਼ ਅਤੇ ਟੈਸਟ ਕੀਤਾ ਹੋਇਆ ਕੋਡ ਲਿਖੇਗਾ ਜੋ ਉਹ ਈਮੇਲ ਭੇਜੇਗਾ। ਉਸਨੂੰ ਇਹ ਨਹੀਂ ਪਤਾ ਹੋਵੇਗਾ ਕਿ ਤੁਹਾਡਾ ਮਤਲਬ ਸੀ, "ਵੈਲਕਮ ਈਮੇਲ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਭੇਜੋ ਜੇਕਰ ਯੂਜ਼ਰ ਨੇ ਆਪਣਾ ਪਤਾ ਵੈਰੀਫਾਈ ਕੀਤਾ ਹੈ, ਮਾਰਕੀਟਿੰਗ ਲਈ ਸਹਿਮਤੀ ਦਿੱਤੀ ਹੈ, ਅਤੇ ਆਪਣੇ ਸਥਾਨਕ ਟਾਈਮਜ਼ੋਨ ਵਿੱਚ ਕਾਰੋਬਾਰੀ ਘੰਟਿਆਂ ਦੌਰਾਨ ਸਾਈਨ ਅੱਪ ਕੀਤਾ ਹੈ।" ਕੋਡ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਨਿਰਦੋਸ਼ ਹੈ ਪਰ ਵਪਾਰਕ ਤੌਰ 'ਤੇ ਖ਼ਤਰਨਾਕ ਹੈ।
Intent-Driven Development ਵਿੱਚ ਅਸਲ ਜੋਖਮ ਅਸਪਸ਼ਟ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਹੈ। ਅਸਪਸ਼ਟ ਇਰਾਦਾ ਅਜਿਹਾ ਸਾਫਟਵੇਅਰ ਤਿਆਰ ਕਰਦਾ ਹੈ ਜੋ ਕਿ ਕਿਤਾਬੀ ਸੁੰਦਰਤਾ ਨਾਲ ਗਲਤ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ। ਇਸੇ ਲਈ ਤੁਹਾਨੂੰ ਆਪਣੀਆਂ ਸਪੈਸੀਫਿਕੇਸ਼ਨਾਂ ਨੂੰ ਅਸਲ ਸੰਪਤੀਆਂ ਵਜੋਂ ਮੰਨਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਹਨਾਂ ਦੇ ਵਰਜ਼ਨ (version) ਬਣਾਓ। ਸਟੇਕਹੋਲਡਰਾਂ (stakeholders) ਨਾਲ ਉਹਨਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ। ਏਜੰਟ ਦੁਆਰਾ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲ ਵਰਕਫਲੋਅਜ਼ (workflows) ਦੇ ਅਧਾਰ 'ਤੇ ਉਹਨਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਚੈਟ ਬਾਕਸ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਇੱਕ ਪ੍ਰੋਂਪਟ (prompt) ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਦੇਣਦਾਰੀ (liability) ਹੈ।
ਇੰਜੀਨੀਅਰਿੰਗ ਜੱਜਮੈਂਟ ਉੱਪਰ ਵੱਲ ਵਧ ਰਹੀ ਹੈ
ਇੰਜੀਨੀਅਰਿੰਗ ਜੱਜਮੈਂਟ ਖ਼ਤਮ ਨਹੀਂ ਹੋ ਰਹੀ। ਇਹ ਇੱਕ ਉੱਚੇ ਪੱਧਰ ਵੱਲ ਵਧ ਰਹੀ ਹੈ।
ਹੁਣ ਤੁਸੀਂ ਇਸ ਗੱਲ 'ਤੇ ਮਾਨਸਿਕ ਊਰਜਾ ਖ਼ਰਚ ਨਹੀਂ ਕਰਦੇ ਕਿ ਮੈਪ (map) ਨੂੰ ਕਿਵੇਂ ਦੁਹਰਾਉਣਾ ਹੈ ਜਾਂ ਕਲਾਸ ਹਾਇਰਾਰਕੀ (class hierarchy) ਨੂੰ ਕਿਵੇਂ ਬਣਾਉਣਾ ਹੈ। ਤੁਸੀਂ ਇਸ ਗੱਲ 'ਤੇ ਊਰਜਾ ਖ਼ਰਚ ਕਰਦੇ ਹੋ ਕਿ ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਸਿਸਟਮ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਹੜਾ ਡੇਟਾ ਕਦੇ ਵੀ ਪ੍ਰਗਟ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ, ਅਤੇ ਡਿਸਟਰੀਬਿਊਟਡ ਸਰਵਿਸਿਜ਼ (distributed services) ਵਿੱਚ ਕਿਹੜੇ ਇਨਵੈਰੀਐਂਟਸ (invariants) ਬਣੇ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ। ਕੋਡਿੰਗ ਦੀ ਕਲਾ ਹੁਣ ਰਿਕੁਆਇਰਮੈਂਟਸ (requirements) ਦੀ ਕਲਾ ਬਣ ਰਹੀ ਹੈ।
ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੀਆਂ ਸਪੈਸੀਫਿਕੇਸ਼ਨਾਂ ਨੂੰ ਉਸੇ ਸਖ਼ਤੀ ਦੀ ਲੋੜ ਹੈ ਜੋ ਤੁਸੀਂ ਕਦੇ ਆਪਣੇ ਕੋਡ 'ਤੇ ਲਾਉਂਦੇ ਸੀ। ਆਪਣੀਆਂ ਸੀਮਾਵਾਂ (constraints) ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਦੱਸੋ। ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਤਰੀਕਿਆਂ (failure modes) ਨੂੰ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਵਪਾਰਕ ਨਿਯਮਾਂ ਨੂੰ ਉਨੀ ਹੀ ਸਪਸ਼ਟਤਾ ਨਾਲ ਦੱਸੋ ਜਿੰਨੀ ਸਪਸ਼ਟਤਾ ਨਾਲ ਤੁਸੀਂ ਕਦੇ ਆਪਣੇ ਟਾਈਪਸ (types) ਘੋਸ਼ਿਤ ਕਰਦੇ ਸੀ। ਏਜੰਟ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ (implementation) ਨੂੰ ਸੰਭਾਲ ਲਵੇਗਾ। ਤੁਹਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਬਣਾਉਣ ਦੇ ਯੋਗ ਹੈ।
ਆਪਣੀ ਕੁਆਲਿਟੀ ਬਾਰ (quality bar) ਨੂੰ ਪਲ ਰਿਕਵੈਸਟ (pull request) ਤੋਂ ਹਟਾ ਕੇ ਪ੍ਰੋਂਪਟ (prompt) 'ਤੇ ਲਿਆਓ। ਪਹਿਲਾਂ ਹਾਰਨੈੱਸ ਬਣਾਓ। ਦੂਜੇ ਨੰਬਰ 'ਤੇ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਲਿਖੋ। ਫਿਰ ਮਸ਼ੀਨ ਨੂੰ ਸਿੰਟੈਕਸ (syntax) ਸੰਭਾਲਣ ਦਿਓ ਜਦੋਂ ਕਿ ਤੁਸੀਂ ਇਸ ਗੱਲ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰੋ ਕਿ ਕੀ ਸਮੱਸਿਆ ਸਹੀ ਤਰ੍ਹਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੀ ਗਈ ਹੈ ਅਤੇ ਕੀ ਸੀਮਾਵਾਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਤੈਅ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ।
ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਤਬਦੀਲੀ ਦੇ ਪਿੱਛੇ ਦੇ ਵਿਚਾਰਾਂ ਨੂੰ ਹੋਰ ਡੂੰਘਾਈ ਨਾਲ ਸਮਝਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Intent-Driven Development 'ਤੇ ਅਸਲ ਚਰਚਾ ਇੱਥੇ ਉਪਲਬਧ ਹੈ। AI-native ਇੰਜੀਨੀਅਰਿੰਗ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਚੱਲ ਰਹੀਆਂ ਚਰਚਾਵਾਂ ਲਈ, ਤੁਸੀਂ GyaanSetu community ਵਿੱਚ ਵੀ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹੋ।