ਹਰ AI ਕੋਡਿੰਗ ਏਜੰਟ ਇੱਕ diff ਦੇ ਸਕਦਾ ਹੈ। ਅਸਲ ਸਮੱਸਿਆ ਇਹ ਜਾਣਨ ਵਿੱਚ ਹੈ ਕਿ ਕੀ ਉਹ diff ਇੱਕ ਕੇਂਦਰਿਤ ਅਤੇ ਜਾਣਬੁੱਝ ਕੇ ਕੀਤੀ ਗਈ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਆਇਆ ਹੈ—ਜਾਂ ਤੁਹਾਡੀ ਰੈਪੋਜ਼ਟਰੀ (repository) ਵਿੱਚ ਇੱਕ ਅਜਿਹੀ ਭੱਜ-ਦੌੜ ਤੋਂ ਜੋ ਅਚਾਨਕ ਸਹੀ ਹੋ ਗਈ। ਇਸ ਸਮੇਂ, ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਇਸ ਵਿੱਚ ਅੰਤਰ ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ।
ਇਹ ਕੋਈ ਤਕਨੀਕੀ ਸੀਮਾ ਨਹੀਂ ਹੈ। ਇਹ ਦਿੱਖ (visibility) ਦੀ ਸਮੱਸਿਆ ਹੈ।
ਜਦੋਂ ਕੋਈ ਏਜੰਟ ਪ੍ਰੋਡਕਸ਼ਨ ਕੋਡ ਦੀਆਂ ਤਿੰਨ ਲਾਈਨਾਂ ਲਿਖਦਾ ਹੈ, ਤਾਂ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਸਨੇ ਤਿੰਨ ਫਾਈਲਾਂ ਪੜ੍ਹੀਆਂ ਹੋਣ ਅਤੇ ਟੈਸਟ ਚਲਾਏ ਹੋਣ। ਜਾਂ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਸਨੇ ਚਾਲੀ ਅਸੰਬੰਧਿਤ ਫਾਈਲਾਂ ਨੂੰ ਛੇੜਿਆ ਹੋਵੇ, ਦਰਜਨਾਂ ਅਸਫਲ ਕਮਾਂਡਾਂ ਚਲਾਈਆਂ ਹੋਣ, ਡਿਪੈਂਡੈਂਸੀ ਇੰਸਟਾਲ (dependency install) ਟੁੱਟਣ ਕਾਰਨ ਤੁਹਾਡੇ ਟੈਸਟ ਸੂਟ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਹੋਵੇ, ਅਤੇ ਇਸ ਸਭ ਲਈ ਤੁਹਾਨੂੰ ਚਾਰਜ ਕੀਤਾ ਹੋਵੇ। ਦੋਵਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ diff ਇੱਕੋ ਜਿਹਾ ਲੱਗਦਾ ਹੈ। ਸਫ਼ਰ ਦਾ ਰਿਕਾਰਡ ਤੋਂ ਬਿਨਾਂ, ਤੁਸੀਂ ਸਿਰਫ਼ ਅੰਤਲੇ ਨਤੀਜੇ ਦੀ ਗੁਣਵੱਤਾ ਬਾਰੇ ਅੰਦਾਜ਼ਾ ਹੀ ਲਗਾ ਸਕਦੇ ਹੋ।
ਚੈਟ ਲੌਗਸ (Chat Logs) ਰਸੀਦਾਂ (Receipts) ਕਿਉਂ ਨਹੀਂ ਹਨ
ਬਹੁਤ ਸਾਰੇ ਟੂਲ ਕੰਮ ਦੇ ਸਬੂਤ ਵਜੋਂ ਚੈਟ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ (chat transcript) ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹਨ। ਇੱਕ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ ਰਸੀਦ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਤੁਹਾਡੀ ਡੈਸਕ 'ਤੇ ਸੁੱਟੇ ਗਏ ਪੁਰਜ਼ਿਆਂ ਦਾ ਇੱਕ ਡੱਬਾ ਹੈ। ਇਸ ਵਿੱਚ ਹਰ ਇੱਕ ਵਿਚਾਰ, ਹਰ ਅਸਫਲ ਕੋਸ਼ਿਸ਼, ਹਰ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ (system prompt), ਅਤੇ ਹਰ ਅਸੰਬੰਧਿਤ ਟੂਲ ਕਾਲ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਤੁਹਾਨੂੰ ਤਿੰਨ-ਲਾਈਨਾਂ ਦੇ ਪੈਚ (patch) ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਹਜ਼ਾਰਾਂ ਲਾਈਨਾਂ ਦੀ ਗੱਲਬਾਤ ਪੜ੍ਹਨੀ ਪੈਂਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ ਰਿਵਿਊ ਵਰਕਫਲੋ (review workflow) ਪਹਿਲਾਂ ਹੀ ਖਰਾਬ ਹੋ ਚੁੱਕਾ ਹੈ।
ਮਨੁੱਖੀ ਧਿਆਨ ਸੀਮਤ ਹੈ। ਏਜੰਟ ਦਾ ਮਕਸਦ ਬੌਧਿਕ ਯਤਨ (cognitive effort) ਨੂੰ ਬਚਾਉਣਾ ਹੈ, ਨਾ ਕਿ ਹੋਮਵਰਕ ਕਰਵਾਉਣਾ। ਇੱਕ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ ਰਿਵਿਊਅਰ ਨੂੰ ਜਾਸੂਸ ਬਣਨ ਲਈ ਕਹਿੰਦੀ ਹੈ। ਇੱਕ ਰਸੀਦ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਹੀ ਜਵਾਬ ਦੇ ਦਿੰਦੀ ਹੈ।
ਇੱਕ ਲਾਭਦਾਇਕ ਰਸੀਦ ਇੱਕ ਵਿਹਾਰਕ ਸਾਰ (practical summary) ਹੁੰਦੀ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਏਜੰਟ ਨੂੰ ਕੀ ਕਰਨ ਲਈ ਕਿਹਾ ਗਿਆ ਸੀ, ਉਸਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਕੀਤਾ, ਅਤੇ ਉਹ ਆਪਣੇ ਨਤੀਜੇ 'ਤੇ ਕਿਵੇਂ ਪਹੁੰਚਿਆ। ਇਹ ਅਸਫਲਤਾ ਨੂੰ ਛੁਪਾਉਂਦੀ ਨਹੀਂ ਹੈ। ਇਹ ਇਸ ਨੂੰ ਉਜਾਗਰ ਕਰਦੀ ਹੈ।
ਇੱਕ ਚੰਗੀ ਰਸੀਦ ਕਿਹੋ ਜਿਹੀ ਦਿਖਦੀ ਹੈ
ਇੱਕ ਰਿਵਿਊ ਕਰਨ ਯੋਗ ਰਸੀਦ ਨੂੰ ਬਿਨਾਂ ਡੂੰਘਾਈ ਵਿੱਚ ਗਏ ਖਾਸ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ:
- ਕਾਰਜ (Task) ਕੀ ਸੀ? ਇੱਛਿਤ ਤਬਦੀਲੀ ਦਾ ਇੱਕ ਸਪਸ਼ਟ ਵੇਰਵਾ, ਨਾ ਕਿ ਕੋਈ ਅਸਪਸ਼ਟ ਪ੍ਰੋਂਪਟ ਈਕੋ।
- ਕਿਹੜੀਆਂ ਫਾਈਲਾਂ ਪੜ੍ਹੀਆਂ ਗਈਆਂ? ਤਾਂ ਜੋ ਤੁਸੀਂ ਫੈਸਲਾ ਕਰ ਸਕੋ ਕਿ ਕੀ ਏਜੰਟ ਨੇ ਸਹੀ ਸਰੋਤਾਂ ਤੋਂ ਸੰਦਰਭ (context) ਤਿਆਰ ਕੀਤਾ ਹੈ।
- ਕਿਹੜੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਐਡਿਟ ਕੀਤਾ ਗਿਆ? ਤਬਦੀਲੀ ਦਾ ਅੰਤਿਮ ਨਿਸ਼ਾਨ (footprint)।
- ਕਿਹੜੀਆਂ ਕਮਾਂਡਾਂ ਚਲਾਈਆਂ ਗਈਆਂ? ਬਿਲਡ ਸਟੈਪਸ, ਲਿੰਟਰਸ (linters), ਫਾਰਮੈਟਰਸ, ਜਾਂ ਕਸਟਮ ਸਕ੍ਰਿਪਟਾਂ ਜੋ ਏਜੰਟ ਨੇ ਚਲਾਈਆਂ।
- ਕਿਹੜੀਆਂ ਕਮਾਂਡਾਂ ਅਸਫਲ ਰਹੀਆਂ? ਸਿਰਫ਼ ਸਫਲਤਾਵਾਂ ਹੀ ਨਹੀਂ। ਅਸਫਲਤਾਵਾਂ ਇਹ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਏਜੰਟ ਨੂੰ ਕਿੱਥੇ ਤਿਆਰੀ ਕਰਨੀ ਪਈ ਜਾਂ ਉਹ ਕਿੱਥੇ ਹਾਰ ਮੰਨ ਗਿਆ।
- ਕਿਹੜੇ ਟੈਸਟ ਪਾਸ ਹੋਏ ਜਾਂ ਛੱਡ ਦਿੱਤੇ ਗਏ? ਛੱਡੇ ਗਏ ਟੈਸਟ ਇੱਕ ਚੇਤਾਵਨੀ (red flag) ਹਨ। ਰਸੀਦ ਵਿੱਚ ਇਹ ਦੱਸਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਹ ਕਿਉਂ ਛੱਡੇ ਗਏ।
- ਕੁੱਲ ਲਾਗਤ ਕੀ ਸੀ? Tokens, API ਕਾਲਸ, ਅਤੇ ਕੰਪਿਊਟ ਟਾਈਮ। ਇਸ ਵਿੱਚ ਤੁਹਾਡੇ ਆਰਕੀਟੈਕਚਰ ਦੀ ਕੀਮਤ ਵੀ ਸ਼ਾਮਲ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਮਾਡਲ ਦੀ।
ਇਹ ਫਾਰਮੈਟ ਰਿਵਿਊ ਨੂੰ ਇੱਕ ਪੁਰਾਤੱਤਵ ਖੋਜ (archaeological dig) ਤੋਂ ਬਦਲ ਕੇ ਇੱਕ ਤੇਜ਼ ਸੈਨੀਟੀ ਚੈੱਕ (sanity check) ਬਣਾ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਸੀਨੀਅਰ ਇੰਜੀਨੀਅਰ ਰਸੀਦ ਨੂੰ ਦੇਖ ਕੇ ਇੱਕ ਮਿੰਟ ਤੋਂ ਵੀ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਕਹਿ ਸਕਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ "ਇਹ ਸਹੀ ਲੱਗ ਰਿਹਾ ਹੈ" ਜਾਂ "ਇਹ ਸ਼ੱਕੀ ਲੱਗ ਰਿਹਾ ਹੈ"।
ਸਿਰਫ਼ ਇਤਿਹਾਸ ਨਹੀਂ, ਨਿਸ਼ਾਨ (Footprint) ਪੜ੍ਹੋ
ਇੱਕ ਏਜੰਟ ਰਨ ਦਾ ਨਿਸ਼ਾਨ ਕੰਮ ਦੇ ਰੂਪ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਕੀ ਏਜੰਟ ਟਿਕਟ ਦੀਆਂ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਰਿਹਾ? ਜਾਂ ਕੀ ਉਹ ਅਸੰਬੰਧਿਤ ਮੋਡਿਊਲ ਵਿੱਚ ਚਲਾ ਗਿਆ ਅਤੇ ਉਹ ਚੀਜ਼ਾਂ ਬਦਲ ਦਿੱਤੀਆਂ ਜੋ ਕਿਸੇ ਨੇ ਨਹੀਂ ਮੰਗੀਆਂ ਸਨ? ਇੱਕ ਰਸੀਦ ਜੋ "Files Read" ਦੇ ਨਾਲ "Files Edited" ਦੀ ਸੂਚੀ ਦਿੰਦੀ ਹੈ, ਇਸ ਨੂੰ ਸਪਸ਼ਟ ਕਰ ਦਿੰਦੀ ਹੈ।
ਨਿਸ਼ਾਨ ਦੁਹਰਾਓ (repetition) ਨੂੰ ਵੀ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ। ਇੱਕ ਏਜੰਟ ਜੋ ਵਾਰ-ਵਾਰ ਇੱਕੋ ਅਸਫਲਤਾ ਦਾ ਸਾਹਮਣਾ ਕਰਦਾ ਹੈ—ਜਿਵੇਂ ਇੱਕੋ ਕੌਂਫਿਗ ਫਾਈਲ ਨੂੰ ਤਿੰਨ ਵਾਰ ਪੜ੍ਹਨਾ, ਜਾਂ ਫੇਲ ਹੋ ਰਹੇ ਟੈਸਟ ਨੂੰ ਵਾਰ-ਵਾਰ ਚਲਾਉਣਾ—ਉਹ ਕੰਪਿਊਟ ਅਤੇ ਕੰਟੈਕਸਟ ਵਿੰਡੋ (context window) ਨੂੰ ਬਰਬਾਦ ਕਰ ਰਿਹਾ ਹੈ। ਉਹ ਪੈਟਰਨ ਦਿਖਾਈ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਕਿਸੇ ਏਜੰਟ ਨੂੰ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਕ੍ਰਿਪਟ ਚਲਾਉਣ ਲਈ ਨੌਂ ਕੋਸ਼ਿਸ਼ਾਂ ਕਰਨੀਆਂ ਪਈਆਂ, ਤਾਂ
- "ਇੱਕ ਲਾਈਨ ਦੇ ਬਦਲਾਅ ਲਈ 37 ਫਾਈਲਾਂ ਪੜ੍ਹੀਆਂ।"
- "
npm installਵਿੱਚ peer dependency conflict ਕਾਰਨ ਟੈਸਟਾਂ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਗਿਆ।" - "ਏਜੰਟ ਦੁਆਰਾ ਲਿਆਂਦੇ ਗਏ ਇੱਕ import ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਮੰਗੀ ਗਈ ਸੀਮਾ (scope) ਤੋਂ ਬਾਹਰ
utils.pyਨੂੰ ਐਡਿਟ ਕੀਤਾ ਗਿਆ।" - "ਲਿੰਟਰ (linter) ਨੂੰ 4 ਵਾਰ ਚਲਾਇਆ ਗਿਆ; ਪਹਿਲੇ ਤਿੰਨ ਪਾਥ ਮਿਸਕੌਂਫਿਗਰੇਸ਼ਨ (path misconfiguration) ਕਾਰਨ ਫੇਲ ਹੋ ਗਏ।"
ਇਹ ਰਸੀਦ (receipt) ਵਿੱਚ ਕੋਈ ਬੱਗ (bug) ਨਹੀਂ ਹਨ। ਇਹ ਸੰਕੇਤ ਹਨ। ਇਹ ਰਿਵਿਊਅਰ (reviewer) ਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਕਿੱਥੇ ਸ਼ੱਕ ਕਰਨਾ ਹੈ। ਇਹ ਪਲੇਟਫਾਰਮ ਟੀਮ ਨੂੰ ਇਹ ਵੀ ਦੱਸਦੇ ਹਨ ਕਿ ਵਰਕਫਲੋ (workflow) ਨੂੰ ਕਿੱਥੇ ਸੁਧਾਰਨ ਦੀ ਲੋੜ ਹੈ।
ਛੋਟੇ ਰਨ, ਸਪੱਸ਼ਟ ਨਿਗਰਾਨੀ
ਏਜੰਟਾਂ ਨੂੰ ਵੱਡੇ ਖੇਤਰਾਂ ਵਿੱਚ ਖੁੱਲ੍ਹ ਕੇ ਕੰਮ ਕਰਨ ਦੇਣ ਦੀ ਇੱਕ ਕੁਦਰਤੀ ਪ੍ਰਲੋਭਨ ਹੁੰਦੀ ਹੈ। ਪੂਰੀ ਸਰਵਿਸ ਨੂੰ ਰੀਫੈਕਟਰ (refactor) ਕਰਨ ਲਈ ਇੱਕ ਵਿਸ਼ਾਲ ਪ੍ਰੋਂਪਟ (prompt) ਤੇਜ਼ ਲੱਗਦਾ ਹੈ। ਪਰ ਇਹ ਅਜਿਹਾ ਨਹੀਂ ਹੈ। ਇਹ ਕੰਮ ਦਾ ਇੱਕ ਅਜਿਹਾ ਢੇਰ ਬਣਾ ਦਿੰਦਾ ਹੈ ਜਿਸਦੀ ਰਿਵਿਊ ਕਰਨਾ ਅਸੰਭਵ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਡੀ ਦੁਪਹਿਰ ਇਸ ਗੱਲ ਦਾ ਪਤਾ ਲਗਾਉਣ ਵਿੱਚ ਗੁਆਚ ਜਾਂਦੀ ਹੈ ਕਿ ਬਦਲੀਆਂ ਗਈਆਂ ਅੱਸੀ ਫਾਈਲਾਂ ਵਿੱਚੋਂ ਕਿਹੜੀਆਂ ਜਾਣਬੁੱਝ ਕੇ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ।
ਛੋਟੇ ਅਤੇ ਜਾਂਚਯੋਗ ਰਨ ਬਿਹਤਰ ਹੁੰਦੇ ਹਨ। ਕੰਮ ਲਈ ਸਪੱਸ਼ਟ ਸੀਮਾਵਾਂ (boundaries) ਨਿਰਧਾਰਤ ਕਰੋ। ਉਹਨਾਂ ਫਾਈਲਾਂ ਦੀ ਸੂਚੀ ਨੂੰ ਵੱਖ ਕਰੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਏਜੰਟ ਪੜ੍ਹ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਹ ਲਿਖ ਸਕਦਾ ਹੈ। ਫੇਲ ਹੋਏ ਕਮਾਂਡਾਂ ਦਾ ਇਤਿਹਾਸ ਰੱਖੋ ਤਾਂ ਜੋ ਰੁਕਾਵਟਾਂ ਸਾਫ਼ ਦਿਖਾਈ ਦੇਣ। ਛੱਡੇ ਗਏ ਵੈਰੀਫਿਕੇਸ਼ਨਾਂ (verifications) ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਫਲੈਗ ਕਰੋ। ਸਰਚ APIs ਤੋਂ ਲੈ ਕੇ ਟੈਸਟ ਰਨਰਾਂ ਤੱਕ, ਹਰ ਬਾਹਰੀ ਟੂਲ ਦੀ ਵਰਤੋਂ ਨੂੰ ਨੋਟ ਕਰੋ।
ਟੀਚਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੁਤੰਤਰਤਾ (autonomy) ਨਹੀਂ ਹੈ। ਅਜਿਹੀ ਪੂਰੀ ਸੁਤੰਤਰਤਾ ਜਿਸਦੀ ਕੋਈ ਮਨੁੱਖ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਉਹ ਸਿਰਫ਼ ਜ਼ਿੰਮੇਵਾਰੀ ਵਾਲੀ ਆਟੋਮੇਸ਼ਨ ਹੈ। ਅਸਲ ਟੀਚਾ ਰਿਵਿਊਯੋਗਤਾ (reviewability) ਹੈ। ਏਜੰਟ ਦੇ ਹਰ ਆਉਟਪੁੱਟ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣਾ ਜਾਂ ਰੱਦ ਕਰਨਾ ਆਸਾਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੋਈ ਅਸਪਸ਼ਟ ਵਿਚਕਾਰਲਾ ਰਾਹ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਜਿੱਥੇ ਤੁਸੀਂ ਜਾਂਚ ਕਰਨ ਤੋਂ ਬਹੁਤ ਥੱਕੇ ਹੋਣ ਕਰਕੇ ਕੋਡ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦੇ ਹੋ।
ਕਿਸੇ ਵੀ ਕੋਡਿੰਗ ਏਜੰਟ ਲਈ ਟੈਸਟ
ਕਿਸੇ ਵੀ ਏਜੰਟ ਜਾਂ ਪਲੇਟਫਾਰਮ ਨੂੰ ਅਪਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਸਵਾਲ ਪੁੱਛੋ: ਕੀ ਇਹ ਇੱਕ ਮਨੁੱਖ ਲਈ ਅਗਲੇ ਕਦਮ ਨੂੰ ਭਰੋਸੇ ਨਾਲ ਮਨਜ਼ੂਰ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਸਬੂਤ ਛੱਡ ਸਕਦਾ ਹੈ?
ਜੇਕਰ ਜਵਾਬ ਹਾਂ ਹੈ, ਤਾਂ ਉਹ ਟੂਲ ਇੱਕ ਪੇਸ਼ੇਵਰ ਵਰਕਫਲੋ ਵਿੱਚ ਫਿੱਟ ਬੈਠਦਾ ਹੈ। ਜੇਕਰ ਜਵਾਬ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਤਪਾਦਕਤਾ (productivity) ਨਹੀਂ ਖਰੀਦ ਰਹੇ ਹੋ। ਤੁਸੀਂ ਇੱਕ ਅਜਿਹੀ ਰਹੱਸਮਈ ਚੀਜ਼ ਖਰੀਦ ਰਹੇ ਹੋ ਜੋ ਕਦੇ-ਕਦੇ ਕੰਪਾਈਲ (compile) ਹੋ ਜਾਂਦੀ ਹੈ। ਇਹ ਵੀਕੈਂਡ ਦੇ ਸਾਈਡ ਪ੍ਰੋਜੈਕਟ ਲਈ ਠੀਕ ਹੈ। ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ ਇੰਜੀਨੀਅਰਿੰਗ ਲਈ ਇਹ ਅਸਵੀਕਾਰਯੋਗ ਹੈ।
ਉਹ ਟੀਮਾਂ ਜੋ ਏਜੰਟ ਦੇ ਆਉਟਪੁੱਟ ਨੂੰ ਬਿਨਾਂ ਜਾਂਚ ਕੀਤੇ ਤੋਹਫ਼ਿਆਂ ਵਾਂਗ ਮੰਨਦੀਆਂ ਹਨ, ਉਹ ਅੰਤ ਵਿੱਚ ਇੱਕ ਅਜਿਹਾ ਸੂਖਮ ਬੱਗ (subtle bug) ਸ਼ਿਪ ਕਰਨਗੀਆਂ ਜੋ ਅਣਡਿੱਠੇ ਸਕੋਪ ਕ੍ਰੀਪ (scope creep) ਕਾਰਨ ਪੈਦਾ ਹੋਇਆ ਹੋਵੇਗਾ। ਡਿਫ (diff) ਮਾਸੂਮ ਲੱਗੇਗਾ। ਪਰ ਰਸੀਦ (receipt) ਸੱਚ ਦੱਸ ਸਕਦੀ ਸੀ।
ਰਸੀਦਾਂ ਦੀ ਮੰਗ ਕਰੋ। ਰਿਵਿਊ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ। ਭਰੋਸਾ ਕੋਈ ਰਣਨੀਤੀ ਨਹੀਂ ਹੈ। ਸਬੂਤ ਰਣਨੀਤੀ ਹੈ।
AI ਟੂਲਿੰਗ ਅਤੇ ਡਿਵੈਲਪਰ ਵਰਕਫਲੋ ਬਾਰੇ ਹੋਰ ਵਿਸਤ੍ਰਿਤ ਚਰਚਾਵਾਂ ਲਈ, ਤੁਸੀਂ GyaanSetu on Telegram 'ਤੇ ਕਮਿਊਨਿਟੀ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹੋ।