ਮੇਰੇ ਏਜੰਟ ਨੇ ਇੱਕ ਸ਼ਾਮ ਵਿੱਚ 3 PRs ਭੇਜ ਦਿੱਤੇ। ਮੇਰੇ 40% ਸੁਨੇਹੇ ਸੁਧਾਰ (corrections) ਸਨ।
ਮੇਰੇ AI-ਅਧਾਰਿਤ ਕੋਡਿੰਗ ਏਜੰਟ ਨੇ ਇੱਕ ਹੀ ਸ਼ਾਮ ਵਿੱਚ ਤਿੰਨ pull requests ਭੇਜ ਦਿੱਤੇ, ਪਰ ਮੇਰੇ ਵੱਲੋਂ ਭੇਜੇ ਗਏ 30 ਸੁਨੇਹਿਆਂ ਵਿੱਚੋਂ 40% ਸੁਧਾਰ ਸਨ।
ਇਸ ਸੈਸ਼ਨ ਵਿੱਚ ਇੱਕ MCP client, ਇੱਕ Azure AI Agent, ਅਤੇ ਇੱਕ M365 Copilot Agent ਤਿਆਰ ਹੋਇਆ। ਆਟੋਮੇਟਡ ਚੈੱਕਸ ਨੇ ਤਿੰਨਾਂ PRs ਨੂੰ ਪਾਸ ਕਰ ਦਿੱਤਾ, ਅਤੇ ਮੈਂ ਕੋਡ ਦੀ ਇੱਕ ਲਾਈਨ ਵੀ ਐਡਿਟ ਨਹੀਂ ਕੀਤੀ। ਫਿਰ ਵੀ, ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ ਇੱਕ ਵੱਖਰੀ ਕਹਾਣੀ ਦੱਸਦੀ ਹੈ: ਕੁੱਲ 710 ਸੁਨੇਹਿਆਂ ਵਿੱਚੋਂ, ਮੈਂ 30 ਟਾਈਪ ਕੀਤੇ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ 12 ਨੇ ਏਜੰਟ ਨੂੰ ਸਹੀ ਰਸਤੇ 'ਤੇ ਲਿਆਂਦਾ। “steering rate” – ਮੇਰੇ ਸੁਨੇਹਿਆਂ ਦਾ ਉਹ ਹਿੱਸਾ ਜੋ ਸੁਧਾਰ ਸਨ – 40% ਰਿਹਾ।
ਪਾਈਪਲਾਈਨ ਕਿਵੇਂ ਤਿਆਰ ਕੀਤੀ ਗਈ ਸੀ
- Claude ਨੇ ਇੱਕ ਉੱਚ-ਪੱਧਰੀ (high-level) ਇੰਪਲੀਮੇਂਟੇਸ਼ਨ ਯੋਜਨਾ ਤਿਆਰ ਕੀਤੀ।
- DeepSeek V4-Flash ਨੇ ਇੱਕ orchestrator ਵਜੋਂ ਕੰਮ ਕੀਤਾ ਅਤੇ ਯੋਜਨਾ ਦੀ ਸਮੀਖਿਆ ਕੀਤੀ।
- Codex ਨੇ ਅਸਲ ਕੋਡ ਤਿਆਰ ਕੀਤਾ।
- Orchestrator ਨੇ ਕੋਡ ਦੀ ਜਾਂਚ ਕੀਤੀ ਅਤੇ pull requests ਖੋਲ੍ਹ ਦਿੱਤੀਆਂ।
Orchestrator ਦੀ ਨਿਰਧਾਰਤ ਭੂਮਿਕਾ ਸਿਰਫ਼ ਜੋੜਨ ਵਾਲੀ (connective) ਸੀ – ਇਸ ਨੂੰ ਕੰਪੋਨੈਂਟਸ ਵਿਚਕਾਰ ਟਕਰਾਅ ਨੂੰ ਸੁਲਝਾਉਣਾ ਚਾਹੀਦਾ ਸੀ, ਨਾ ਕਿ ਖੁਦ ਕੋਡ ਲਿਖਣਾ। ਅਸਲ ਵਿੱਚ, ਏਜੰਟ ਨੇ ਲਗਭਗ 40 ਮਿੰਟਾਂ ਵਿੱਚ ਤਿੰਨਾਂ PRs ਵਿੱਚ 3,500 ਲਾਈਨਾਂ ਦਾ ਕੋਡ ਤਿਆਰ ਕੀਤਾ, ਪਰ ਇਹ ਦੋ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ (error classes) ਵਿੱਚ ਵੀ ਫਸ ਗਿਆ।
ਦੋ ਤਰ੍ਹਾਂ ਦੀਆਂ ਗਲਤੀਆਂ
- Workflow violations – orchestrator ਨੇ ਕਦੇ-ਕਦੇ ਕੋਡਿੰਗ ਦਾ ਕੰਮ ਆਪਣੇ ਹੱਥ ਵਿੱਚ ਲੈ ਲਿਆ, ਆਪਣੀ “glue” ਭੂਮਿਕਾ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਿਆਂ ਖੁਦ ਇੰਪਲੀਮੇਂਟੇਸ਼ਨ ਦੇ ਵੇਰਵੇ ਲਿਖਣੇ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੇ।
- Context-retrieval failures – ਸਪੱਸ਼ਟ ਹਦਾਇਤਾਂ ਦੇ ਬਾਵਜੂਦ, ਏਜੰਟ ਨੇ ਗਲਤ SDK ਜਾਂ ਵਰਜ਼ਨ ਚੁਣ ਲਿਆ। ਸਹੀ ਜਾਣਕਾਰੀ prompt context ਵਿੱਚ ਮੌਜੂਦ ਸੀ, ਪਰ ਮਾਡਲ ਸਹੀ ਸਮੇਂ 'ਤੇ ਉਸ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਣ ਵਿੱਚ ਅਸਫਲ ਰਿਹਾ।
ਇਹ ਤਰਕ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਵਿੱਚ ਕਮੀ ਨਹੀਂ ਹੈ; ਇਹ ਇਸ ਗੱਲ ਵਿੱਚ ਇੰਜੀਨੀਅਰਿੰਗ ਬੱਗ (engineering bugs) ਹਨ ਕਿ ਵਰਕਫਲੋ ਨੂੰ ਕਿਵੇਂ ਸੀਮਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਇੱਕ ਵਧੇਰੇ ਸਮਰੱਥਾ ਵਾਲਾ ਲੈਂਗੂਏਜ ਮਾਡਲ ਵੀ ਅਜੇ ਵੀ ਇੱਕ ਸਖ਼ਤ, ਅਟੱਲ ਨਿਯਮ ਦੀ ਲੋੜ ਰੱਖੇਗਾ ਜੋ orchestrator ਨੂੰ ਉਸਦੇ ਗੈਰ-ਕੋਡਿੰਗ ਡਿਊਟੀਜ਼ ਤੱਕ ਸੀਮਤ ਰੱਖੇ ਅਤੇ ਸਹੀ SDK ਦੀ ਚੋਣ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰੇ।
ਏਜੰਟ ਨੂੰ ਕਾਬੂ ਕਰਨ ਲਈ ਮੈਂ ਕੀ ਬਦਲਿਆ
ਮੈਂ ਇਹ ਮੰਨਣਾ ਬੰਦ ਕਰ ਦਿੱਤਾ ਕਿ ਸਿਸਟਮ ਸਟੈਪ ਲਿਸਟ ਤੋਂ ਆਪਣੀ ਭੂਮਿਕਾ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾ ਲਵੇਗਾ। ਮੈਂ ਇੱਕ ਸਿੱਧਾ ਬਿਆਨ ਜੋੜਿਆ: “You are an orchestrator. You do not implement.” ਇਸ ਹਦਾਇਤ ਨੂੰ ਲਾਗੂ ਹੋਣ ਲਈ ਪੰਜ ਸੁਧਾਰ ਲਿਆਉਣ ਵਾਲੇ ਸੁਨੇਹਿਆਂ ਦੀ ਲੋੜ ਪਈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਏਜੰਟ ਨੇ ਇਸ ਸੀਮਾ ਦਾ ਸਤਿਕਾਰ ਕੀਤਾ।
ਮੈਂ context-retrieval ਲੌਜਿਕ ਨੂੰ ਵੀ ਸਖ਼ਤ ਕੀਤਾ। ਜਦੋਂ ਗਲਤ ਟੂਲ ਸਾਹਮਣੇ ਆਇਆ, ਤਾਂ ਮੈਂ ਇਸਨੂੰ 'hallucination' ਦੀ ਬਜਾਏ retrieval pipeline ਵਿੱਚ ਇੱਕ ਬੱਗ ਵਜੋਂ ਲਿਆ, ਅਤੇ ਮੈਂ SDK ਦੇ ਵੇਰਵੇ ਦੇਣ ਵਾਲੇ prompt ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਿਆ ਤਾਂ ਜੋ ਸਹੀ ਵਰਜ਼ਨ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਅਸੰਭਵ ਹੋ ਜਾਵੇ।
AI-ਅਧਾਰਿਤ ਵਿਕਾਸ (AI-augmented development) ਲਈ ਵਿਹਾਰਕ ਸਿੱਖਿਆਵਾਂ
- ਆਪਣੇ ਸੁਨੇਹਿਆਂ ਦੀ ਗਿਣਤੀ ਕਰੋ। ਕਬੂਲ ਕੀਤੇ ਗਏ PRs ਦੀ ਵੱਡੀ ਗਿਣਤੀ ਇੱਕ ਖਰਾਬ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਛੁਪਾ ਸਕਦੀ ਹੈ। ਤੁਹਾਡੇ ਸੁਧਾਰਾਂ ਦੀ ਗਿਣਤੀ ਇਸ ਗੱਲ ਦਾ ਮੁੱਖ ਸੰਕੇਤ ਹੈ ਕਿ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਕਿੱਥੇ ਕਮੀ ਆ ਰਹੀ ਹੈ।
- ਭੂਮਿਕਾ ਨੂੰ ਸਪੱਸ਼ਟ ਰੂਪ ਵਿੱਚ ਦੱਸੋ। ਏਜੰਟ ਚੈੱਕਲਿਸਟ ਤੋਂ ਆਪਣੀ ਪਛਾਣ ਦਾ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਗਾਉਂਦੇ; ਉਹਨਾਂ ਨੂੰ ਇਸ ਬਾਰੇ ਇੱਕ ਸਪੱਸ਼ਟ ਅਤੇ ਪੱਕੀ ਹਦਾਇਤ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਕਿ ਉਹ ਕੌਣ ਹਨ ਅਤੇ ਉਹ ਕੀ ਕਰ ਸਕਦੇ ਹਨ।
- ਟੂਲ-ਚੋਣ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਇੰਜੀਨੀਅਰਿੰਗ ਬੱਗ ਵਜੋਂ ਲਓ। ਜੇਕਰ ਏਜੰਟ ਦੱਸੇ ਹੋਏ SDK ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਦੋਸ਼ context-delivery ਮਕੈਨਿਜ਼ਮ ਵਿੱਚ ਹੈ, ਨਾ ਕਿ ਮਾਡਲ ਦੇ “ਗਿਆਨ” ਵਿੱਚ।
- ਗਲਤੀਆਂ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤੋਂ ਯੋਗ ਹੁਨਰਾਂ ਵਿੱਚ ਬਦਲੋ। ਮੈਂ ਏਜੰਟ ਨੂੰ ਆਪਣੀਆਂ ਗਲਤੀਆਂ ਤੋਂ ਇੱਕ ਵੈਲੀਡੇਸ਼ਨ ਰੁਟੀਨ (validation routine) ਤਿਆਰ ਕਰਨ ਦਿੱਤੀ, ਜਿਸ ਨਾਲ ਇੱਕ ਅਸਫਲਤਾ ਨੂੰ ਭਵਿੱਖ ਦੇ ਸੁਰੱਖਿਆ ਕਵਚ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਗਿਆ।