ਏਜੰਟਿਕ ਕੋਡਿੰਗ ਅਪਣਾਉਣ ਵਾਲੀਆਂ ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਦੀ ਰੁਕਾਵਟ ਕੋਡ ਬਣਾਉਣ ਤੋਂ ਹਟ ਕੇ ਸਮੀਖਿਆ ਵਿੱਚ ਆ ਜਾਂਦੀ ਹੈ ਅਤੇ ਇਸ ਲੂਪ ਨੂੰ ਸੁਧਾਰੇ ਬਿਨਾਂ ਕੁੱਲ ਰਫ਼ਤਾਰ ਲਗਭਗ ਨਹੀਂ ਵਧਦੀ.
ਵੱਡੇ ਪੱਧਰ ਦੇ CI ਵਾਤਾਵਰਨਾਂ ਵਿੱਚ (ਜਿੱਥੇ ਹਰ ਰਾਤ ਲੱਖਾਂ ਜਾਂਚਾਂ ਚੱਲਦੀਆਂ ਹਨ ਅਤੇ ਸੈਂਕੜੇ ਇੰਜੀਨੀਅਰ ਕੰਮ ਕਰਦੇ ਹਨ), ਏਜੰਟ ਦਾ ਸਭ ਤੋਂ ਕੀਮਤੀ ਕੰਮ ਕੋਡ ਬਣਾਉਣਾ ਨਹੀਂ, ਸਗੋਂ ਮਾਮਲਾ ਜ਼ਿੰਮੇਵਾਰ ਟੀਮ ਤੱਕ ਪਹੁੰਚਾਉਣਾ ਅਤੇ ਟ੍ਰਾਈਏਜ ਕਰਨਾ ਹੈ.
ਉਪਯੋਗੀ ਏਜੰਟ ਨਤੀਜਾ ਡੂੰਘੀ ਜਾਂਚ ਉੱਤੇ ਖਰਾ ਉਤਰਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਨਮੂਨਿਆਂ ਦਾ ਮੇਲ ਨਹੀਂ ਦੱਸਦਾ, ਸਗੋਂ ਕਾਰਨ-ਪਰਿਣਾਮ ਵੀ ਸਮਝਾਉਂਦਾ ਹੈ.
ਸਬੂਤ ਇਕੱਠੇ ਕਰਨ ਅਤੇ ਸੰਦਰਭ ਜੋੜਨ ਵਾਲੀ ਪਰਤ ਦਾ ਡਿਜ਼ਾਈਨ, ਨਤੀਜਾ ਬਣਾਉਣ ਵਾਲੀ ਪਰਤ ਨਾਲੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ.
ਏਜੰਟਿਕ ਕੋਡਿੰਗ ਬਾਰੇ ਜ਼ਿਆਦਾਤਰ ਚਰਚਾ ਅਜੇ ਵੀ ਇੱਕ ਸਧਾਰਨ ਵਾਅਦੇ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ: ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਵੱਧ ਕੋਡ ਲਿਖਣਾ.
ਕਈ ਵਾਰ ਇਹ ਸੋਚ ਇੱਕ ਹੋਰ ਮਹੱਤਵਾਕਾਂਖੀ ਦ੍ਰਿਸ਼ਟੀ ਬਣ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਏਜੰਟ ਕੰਮ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੇ, PR ਖੋਲ੍ਹਦੇ ਅਤੇ ਬਹੁਤ ਘੱਟ ਮਨੁੱਖੀ ਦਖ਼ਲ ਨਾਲ ਤਬਦੀਲੀਆਂ ਜਾਰੀ ਕਰਦੇ ਹਨ. ਪਰ ਜ਼ਿਆਦਾਤਰ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ ਲਈ ਨੇੜਲੇ ਭਵਿੱਖ ਦਾ ਸਭ ਤੋਂ ਸਪਸ਼ਟ ਲਾਭ ਇਸ ਤੋਂ ਸੀਮਤ ਹੈ. ਇਹ ਦੁਹਰਾਈ ਨਾਲ ਸੁਧਾਰ ਕਰਨ ਦੀ ਲਾਗਤ ਘਟਾਉਣ ਬਾਰੇ ਹੈ.
ਸਾਫ਼ਟਵੇਅਰ ਪਹੁੰਚਾਉਣਾ ਸਿਰਫ਼ ਕੋਡ ਬਣਾਉਣਾ ਨਹੀਂ ਹੈ. ਕੋਡ ਲਿਖਣਾ ਇੱਕ ਲੰਮੇ ਲੂਪ ਦਾ ਕੇਵਲ ਇੱਕ ਪੜਾਅ ਹੈ, ਜਿਸ ਵਿੱਚ ਸਮੀਖਿਆ, ਜਾਂਚ, ਡਿਪਲੌਇਮੈਂਟ ਅਤੇ ਗੜਬੜ ਹੋਣ ਉੱਤੇ ਪੜਤਾਲ ਵੀ ਸ਼ਾਮਲ ਹਨ. ਸਮੀਖਿਆ ਲੂਪ ਨੂੰ ਮੁੜ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਬਿਨਾਂ ਏਜੰਟਿਕ ਕੋਡਿੰਗ ਅਪਣਾਉਣ ਵਾਲੀਆਂ ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਆਪਣੀ ਰੁਕਾਵਟ ਨੂੰ ਸਿਰਫ਼ ਅਗਲੇ ਪੜਾਅ ਵੱਲ ਧੱਕ ਦਿੰਦੀਆਂ ਹਨ.
ਕੇਵਲ ਕੋਡ ਬਣਾਉਣ ਦੀ ਰਫ਼ਤਾਰ ਵਧਾਉਣ ਨਾਲ ਟੀਮ ਆਪਣੇ ਆਪ ਤੇਜ਼ ਨਹੀਂ ਹੋ ਜਾਂਦੀ. ਇਸ ਨਾਲ ਸਮੀਖਿਆ, ਤਸਦੀਕੀਕਰਨ ਅਤੇ ਭਰੋਸਾ ਕਾਇਮ ਕਰਨ ਉੱਤੇ ਹੋਰ ਮਿਹਨਤ ਲੱਗ ਸਕਦੀ ਹੈ.
ਬਹੁਤ ਸਾਰੇ ਇੰਜੀਨੀਅਰਿੰਗ ਵਾਤਾਵਰਨਾਂ ਵਿੱਚ, ਮਹਿੰਗਾ ਹਿੱਸਾ ਪਹਿਲਾ ਖਰੜਾ ਤਿਆਰ ਕਰਨਾ ਨਹੀਂ, ਸਗੋਂ ਭਰੋਸੇ ਤੱਕ ਪਹੁੰਚਣਾ ਹੈ.
ਕੀ ਤਬਦੀਲੀ ਨੇ ਸੱਚਮੁੱਚ ਸਮੱਸਿਆ ਹੱਲ ਕੀਤੀ ਜਾਂ ਸਿਸਟਮ ਨੂੰ ਬਿਹਤਰ ਬਣਾਇਆ? ਕੀ ਇਸ ਕਾਰਨ ਕਿਸੇ ਹੋਰ ਥਾਂ ਰਿਗ੍ਰੈਸ਼ਨ ਆ ਗਿਆ? ਨਾਕਾਮੀ ਕੋਡ, ਵਾਤਾਵਰਨ, ਟੈਸਟਾਂ ਜਾਂ ਕਿਸੇ ਨਿਰਭਰਤਾ ਵਿੱਚ ਹੈ. ਕੀ ਸੁਝਾਇਆ ਗਿਆ ਸੁਧਾਰ ਮੂਲ ਕਾਰਨ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਦਿਖਾਈ ਦੇਣ ਵਾਲੇ ਲੱਛਣ ਨੂੰ?
ਏਜੰਟ ਇੱਥੇ ਇੰਜੀਨੀਅਰਾਂ ਦੀ ਥਾਂ ਲੈ ਕੇ ਨਹੀਂ, ਸਗੋਂ ਖਿੰਡੇ ਹੋਏ ਸਬੂਤਾਂ ਦੀ ਢਾਂਚਾਬੱਧ ਮੁੱਢਲੀ ਜਾਂਚ ਕਰਕੇ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ: ਲੌਗ ਜਾਂਚਣਾ, ਹਾਲੀਆ ਤਬਦੀਲੀਆਂ ਦੀ ਤੁਲਨਾ ਕਰਨੀ, ਸੰਬੰਧਿਤ ਸੰਕੇਤਾਂ ਦਾ ਸਾਰ ਦੇਣਾ, ਸੰਭਾਵੀ ਕਾਰਨਾਂ ਦਾ ਪਤਾ ਲਗਾਉਣਾ, ਜਾਂਚਾਂ ਚਲਾਉਣੀਆਂ ਅਤੇ ਅਜਿਹਾ ਨਤੀਜਾ ਦੇਣਾ ਜਿਸ ਦੀ ਮਨੁੱਖ ਡੂੰਘੀ ਪੜਤਾਲ ਕਰ ਸਕੇ.
ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਵਿੱਚ ਏਜੰਟ ਦੀ ਸਭ ਤੋਂ ਵੱਧ ਅਸਰਦਾਰ ਵਰਤੋਂ ਸ਼ੁਰੂ ਤੋਂ ਕੋਡ ਬਣਾਉਣਾ ਨਹੀਂ ਹੈ. ਇਸ ਦੀ ਅਸਲ ਵਰਤੋਂ ਸਮੱਸਿਆ ਦੇ ਸੰਭਾਵੀ ਕਾਰਨਾਂ ਦਾ ਘੇਰਾ ਘਟਾਉਣਾ ਹੈ, ਤਾਂ ਜੋ ਮਨੁੱਖ ਨੂੰ ਇਹ ਕੰਮ ਹੱਥੀਂ ਕਰਨ ਉੱਤੇ ਘੰਟੇ ਨਾ ਲਾਉਣੇ ਪੈਣ.
ਵੱਡੇ ਪੱਧਰ ਉੱਤੇ ਖ਼ਰਾਬੀਆਂ ਲੱਭਣ ਵਾਲੇ ਵਰਕਫਲੋਜ਼ ਵਿੱਚ ਇਹ ਗੱਲ ਖ਼ਾਸ ਤੌਰ ਉੱਤੇ ਸਪਸ਼ਟ ਹੁੰਦੀ ਹੈ. ਕਲਪਨਾ ਕਰੋ ਕਿ ਹਰ ਰਾਤ ਚੱਲਣ ਵਾਲਾ CI ਉਨ੍ਹਾਂ ਕੋਡਬੇਸਾਂ ਵਿੱਚ ਲੱਖਾਂ ਜਾਂਚਾਂ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਉੱਤੇ ਸੈਂਕੜੇ ਇੰਜੀਨੀਅਰ ਕੰਮ ਕਰਦੇ ਹਨ (ਸਾਡੇ ਇੱਕ ਗਾਹਕ ਕੋਲ ਅਸਲ ਵਿੱਚ ਹੁੰਦਾ ਹੈ). ਕੁਝ ਨਾਕਾਮ ਹੋਣ ਉੱਤੇ ਮਾਮਲਾ ਜ਼ਿੰਮੇਵਾਰ ਟੀਮ ਤੱਕ ਪਹੁੰਚਾਉਣਾ ਔਖਾ ਹੁੰਦਾ ਹੈ. ਸਮੱਸਿਆ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ, ਕਿਸੇ ਨਿਰਭਰਤਾ, ਜਾਂਚ-ਢਾਂਚੇ ਜਾਂ ਤਕਨੀਕੀ ਪਰਤਾਂ ਦੇ ਕਿਸੇ ਹੋਰ ਹਿੱਸੇ ਵਿੱਚ ਹੋ ਸਕਦੀ ਹੈ. ਲੌਗ ਕਈ ਗੀਗਾਬਾਈਟ ਤੱਕ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਸਮੱਸਿਆ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਦੇਖਣ ਵਾਲੀ ਟੀਮ ਹਮੇਸ਼ਾ ਉਸ ਦੀ ਜ਼ਿੰਮੇਵਾਰ ਟੀਮ ਨਹੀਂ ਹੁੰਦੀ.
ਇਸ ਕਿਸਮ ਦਾ ਵਰਕਫਲੋ ਸੁਧਾਰ ਲਿਖਣ ਲਈ ਕਿਸੇ ਇੱਕ ਏਜੰਟ ਦੀ ਮੰਗ ਸੁਭਾਵਿਕ ਤੌਰ ਉੱਤੇ ਨਹੀਂ ਕਰਦਾ. ਇਹ ਅਜਿਹੇ ਸਿਸਟਮ ਲਈ ਬਣਿਆ ਹੈ ਜੋ ਸਮੱਸਿਆ ਦਾ ਘੇਰਾ ਛੇਤੀ ਘਟਾ ਸਕੇ.
ਇੱਕ ਉਪਯੋਗੀ ਪਾਈਪਲਾਈਨ ਲੌਗ ਫੈਚ ਕਰ ਸਕਦੀ ਹੈ, ਸੰਬੰਧਿਤ ਸਬੂਤ ਚੁਣ ਸਕਦੀ ਹੈ, ਮਹੱਤਵਪੂਰਨ ਗੱਲਾਂ ਦਾ ਸਾਰ ਦੇ ਸਕਦੀ ਹੈ, ਸੈਂਡਬਾਕਸ ਵਿੱਚ ਕੋਡ ਦੀ ਪੜਤਾਲ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਭਰੋਸੇ ਦੇ ਅੰਕ, ਟ੍ਰੇਸ ਕਰਨਯੋਗਤਾ ਅਤੇ ਸੁਝਾਏ ਅਗਲੇ ਕਦਮਾਂ ਸਮੇਤ ਮੂਲ ਕਾਰਨ ਦਾ ਢਾਂਚਾਬੱਧ ਵਿਸ਼ਲੇਸ਼ਣ ਪੇਸ਼ ਕਰ ਸਕਦੀ ਹੈ. ਭਰੋਸੇ ਦਾ ਅੰਕ ਤਿਆਰ ਕਰਨ ਲਈ, ਵਿਸ਼ਾ-ਮਾਹਰ ਏਜੰਟ ਦੇ ਸ਼ੁਰੂਆਤੀ ਨਤੀਜੇ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ. ਫਿਰ ਇਸ ਨੂੰ LLM-as-a-judge ਵਿੱਚ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਜੋ ਅੱਗੇ ਦੇ ਮੁਲਾਂਕਣ ਆਪਣੇ ਆਪ ਕੀਤੇ ਜਾ ਸਕਣ ਅਤੇ ਮਨੁੱਖੀ ਫ਼ੈਸਲੇ ਨਾਲ ਇਕਸਾਰਤਾ ਕਾਇਮ ਰਹੇ.
ਮਕਸਦ ਇੰਜੀਨੀਅਰਿੰਗ ਫ਼ੈਸਲੇ ਨੂੰ ਖ਼ਤਮ ਕਰਨਾ ਨਹੀਂ, ਸਗੋਂ ਸਮੀਖਿਅਕਾਂ ਨੂੰ ਵਧੇਰੇ ਮਜ਼ਬੂਤ ਸ਼ੁਰੂਆਤੀ ਆਧਾਰ ਦੇਣਾ ਹੈ. ਰਿਗ੍ਰੈਸ਼ਨ ਟ੍ਰਾਈਏਜ, PR ਸਮੀਖਿਆ, ਟੈਸਟ ਦੀ ਮੁਰੰਮਤ, ਰਿਲੀਜ਼ ਦੀ ਪੁਸ਼ਟੀ ਅਤੇ ਡਿਪਲੌਇਮੈਂਟ ਤੋਂ ਬਾਅਦ ਦੀ ਪੜਤਾਲ, ਸਭ ਦੀ ਪ੍ਰਕਿਰਤੀ ਇੱਕੋ ਜਿਹੀ ਹੈ. ਇਨ੍ਹਾਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਸਬੂਤ ਅਤੇ ਸਮੀਖਿਆ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ ਅਤੇ ਕਾਫ਼ੀ ਅਸਪਸ਼ਟਤਾ ਹੁੰਦੀ ਹੈ. ਇਹ ਏਜੰਟ ਨੂੰ ਇੰਜੀਨੀਅਰਿੰਗ ਪ੍ਰਕਿਰਿਆ ਦੀ ਥਾਂ ਲੈਣ ਲਈ ਨਹੀਂ, ਸਗੋਂ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਅੱਗੇ ਵਧਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ ਕਹਿੰਦੇ ਹਨ.
ਇਸੇ ਕਾਰਨ ਟੀਮਾਂ ਨੂੰ ਇਹ ਵੀ ਧਿਆਨ ਨਾਲ ਤੈਅ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਹ ਇਨ੍ਹਾਂ ਸਿਸਟਮਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਿਵੇਂ ਕਰਦੀਆਂ ਹਨ.
ਇਹ ਪੁੱਛਣਾ ਗ਼ਲਤ ਹੈ ਕਿ ਕੀ ਏਜੰਟ ਇਕੱਲਿਆਂ ਕੋਈ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਚੀਜ਼ ਬਣਾ ਸਕਦਾ ਹੈ. ਬਿਹਤਰ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕੀ ਇਹ ਕਿਸੇ ਹੋਰ ਥਾਂ ਰੁਕਾਵਟ ਪੈਦਾ ਕੀਤੇ ਬਿਨਾਂ ਅਸਲ ਵਰਕਫਲੋ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ.
ਇਸ ਲਈ ਦੇਖਣਾ ਪਵੇਗਾ ਕਿ ਕੀ ਨਤੀਜਾ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਸਪਸ਼ਟ ਹੈ, ਕੀ ਇਹ ਸਿਰਫ਼ ਨਮੂਨਿਆਂ ਦਾ ਮੇਲ ਲੱਭਣ ਦੀ ਬਜਾਏ ਕਾਰਨ-ਪਰਿਣਾਮ ਸਮਝਾਉਂਦਾ ਹੈ ਅਤੇ ਕੀ ਇਹ ਸਮੀਖਿਆ ਨੂੰ ਔਖਾ ਨਹੀਂ, ਸੌਖਾ ਬਣਾਉਂਦਾ ਹੈ. ਭਰੋਸੇਯੋਗ ਜਾਪਦਾ ਜਵਾਬ ਲਾਜ਼ਮੀ ਤੌਰ ਉੱਤੇ ਲਾਭਦਾਇਕ ਨਹੀਂ ਹੁੰਦਾ. ਅਮਲ ਵਿੱਚ ਟੀਮਾਂ ਏਜੰਟ ਦੇ ਨਤੀਜੇ ਉੱਤੇ ਉਦੋਂ ਭਰੋਸਾ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਡੂੰਘੀ ਜਾਂਚ ਉੱਤੇ ਖਰਾ ਉਤਰੇ ਅਤੇ ਜਾਂਚਣ ਲਈ ਕੋਈ ਠੋਸ ਆਧਾਰ ਦੇਵੇ.
ਡੂੰਘਾ ਸਬਕ ਇਹ ਹੈ ਕਿ ਉਪਯੋਗੀ ਏਜੰਟਿਕ ਸਿਸਟਮ ਸਿਰਫ਼ ਨਤੀਜੇ ਬਣਾਉਣ ਉੱਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦੇ. ਉਹ ਇਸ ਗੱਲ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਕਿ ਸਬੂਤ ਕਿਵੇਂ ਇਕੱਠੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਸੰਦਰਭ ਕਿਵੇਂ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਨਤੀਜਿਆਂ ਦੀ ਜਾਂਚ ਕਿਵੇਂ ਹੁੰਦੀ ਹੈ ਅਤੇ ਸਮੀਖਿਅਕ ਅੱਗੇ ਅਨਿਸ਼ਚਿਤਤਾ ਕਿਵੇਂ ਸਪਸ਼ਟ ਕੀਤੀ ਜਾਂਦੀ ਹੈ.
ਇਸੇ ਲਈ ਏਜੰਟਿਕ ਇੰਜੀਨੀਅਰਿੰਗ ਦਾ ਨੇੜਲਾ ਭਵਿੱਖ ਇੱਕੋ ਵੱਡੀ ਛਾਲ ਨਾਲ ਪੂਰੀ ਖੁਦਮੁਖਤਿਆਰੀ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲਾ ਨਹੀਂ ਜਾਪਦਾ. ਇਸ ਦੇ ਸੁਚੱਜੇ ਢੰਗ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਲੂਪਾਂ ਦਾ ਸਮੂਹ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਵੱਧ ਹੈ, ਜਿੱਥੇ ਏਜੰਟ ਪੜਾਵਾਂ ਵਿਚਕਾਰ ਵਿਅਰਥ ਮਿਹਨਤ ਘਟਾ ਕੇ ਟੀਮਾਂ ਨੂੰ ਆਪਣਾ ਕੰਮ ਜਾਂਚਣ, ਸਮੀਖਿਆ ਕਰਨ, ਪੁਸ਼ਟੀ ਕਰਨ ਅਤੇ ਨਿਖਾਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ.
ਇਹ ਵਿਆਪਕ ਖੁਦਮੁਖਤਿਆਰੀ ਦੀ ਕਹਾਣੀ ਜਿੰਨਾ ਨਾਟਕੀ ਨਾ ਹੋਵੇ, ਪਰ ਉਪਯੋਗੀ ਸਿਸਟਮ ਅਸਲ ਵਿੱਚ ਜਿਵੇਂ ਅਪਣਾਏ ਜਾਂਦੇ ਹਨ, ਉਸ ਦੇ ਕਾਫ਼ੀ ਨੇੜੇ ਹੈ.