ਮੈਂ ਇੱਕ ਮਹੀਨੇ ਲਈ ਆਪਣੇ CI/CD ਪਾਈਪਲਾਈਨ ਨੂੰ ਇੱਕ AI-ਸੰਚਾਲਿਤ ਏਜੰਟ (AI-driven agent) ਚਲਾਉਣ ਦਿੱਤਾ। ਅਜ਼ਮਾਇਸ਼ ਦੇ ਅੰਤ ਤੱਕ, ਇਹ ਫੇਲ ਹੋ ਰਹੀਆਂ ਬਿਲਡਾਂ ਨੂੰ ਠੀਕ ਕਰ ਰਿਹਾ ਸੀ, ਪੁੱਲ ਰਿਕੁਐਸਟਾਂ (pull requests) ਖੋਲ੍ਹ ਰਿਹਾ ਸੀ ਅਤੇ ਜੌਬਸ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾ ਰਿਹਾ ਸੀ, ਜਿਸ ਨਾਲ ਸਿਰਫ਼ ਇੱਕ ਮਨੁੱਖੀ ਮਨਜ਼ੂਰੀ ਦਾ ਪੜਾਅ ਬਚਿਆ ਸੀ। ਇਹ ਪ੍ਰਯੋਗ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ “ਏਜੈਂਟਿਕ” (agentic) DevOps ਰੁਟੀਨ ਤਰੀਬ (triage) ਨੂੰ ਬੈਕ-ਆਫਿਸ ਤੋਂ ਇੱਕ ਆਟੋਮੇਟਡ ਦਿਮਾਗ ਵੱਲ ਲੈ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਉਹਨਾਂ ਗਾਰਡਰੇਲਜ਼ (guardrails) ਨੂੰ ਵੀ ਉਜਾਗਰ ਕਰਦਾ ਹੈ ਜੋ ਇੱਕ ਖੁਦਮੁਖਤਿਆਰ ਸਿਸਟਮ ਨੂੰ ਜੋਖਮ ਦਾ ਨਵਾਂ ਸਰੋਤ ਬਣਨ ਤੋਂ ਰੋਕਦੇ ਹਨ।
ਇਹ ਪ੍ਰਯੋਗ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਸੀ
ਜ਼ਿਆਦਾਤਰ ਸਾਫਟਵੇਅਰ ਟੀਮਾਂ ਅਜੇ ਵੀ AI ਨੂੰ ਇੱਕ ਸ਼ਾਨਦਾਰ 'ਆਟੋ-ਕੰਪਲੀਟ' (autocomplete) ਵਜੋਂ ਮੰਨਦੀਆਂ ਹਨ—ਇੱਕ ਅਜਿਹਾ ਟੂਲ ਜੋ ਕੋਡ ਦੀ ਇੱਕ ਲਾਈਨ ਸੁਝਾਉਂਦਾ ਹੈ ਜਾਂ ਗਲਤੀ ਦੇ ਸੰਦੇਸ਼ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ। 2025 ਵਿੱਚ, ਉਦਯੋਗ "AI ਜੋ ਤੁਹਾਨੂੰ ਟਾਈਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ" ਤੋਂ "AI ਜੋ ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ" ਵੱਲ ਵਧ ਰਿਹਾ ਹੈ। ਇੱਕ ਕਾਰਜਸ਼ੀਲ ਏਜੰਟ ਲੌਗਸ (logs) ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਸੁਧਾਰ ਦਾ ਫੈਸਲਾ ਲੈ ਸਕਦਾ ਹੈ, ਉਸਨੂੰ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਨਤੀਜੇ ਤੋਂ ਸਿੱਖ ਸਕਦਾ ਹੈ—ਇਹ ਸਭ ਬਿਨਾਂ ਕਿਸੇ ਡਿਵੈਲਪਰ ਦੇ ਇੱਕ ਵੀ ਕਮਾਂਡ ਟਾਈਪ ਕੀਤੇ।
ਮੂਲ ਵਿਚਾਰ: ਇੱਕ ਏਜੈਂਟਿਕ ਪਾਈਪਲਾਈਨ
ਇੱਕ ਏਜੈਂਟਿਕ ਪਾਈਪਲਾਈਨ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਅਨਿਯੰਤਰਿਤ ਪਹੁੰਚ ਵਾਲਾ ਕੋਈ ਇੱਕ ਵਿਸ਼ਾਲ ਮਾਡਲ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਸੀਮਤ ਆਰਕੈਸਟਰੇਟਰ (orchestrator) ਹੈ ਜੋ ਵਿਸ਼ੇਸ਼ ਟੂਲਜ਼ ਦਾ ਤਾਲਮੇਲ ਕਰਦਾ ਹੈ, ਕੰਟੈਕਸ (context) ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਸਖ਼ਤ ਗਾਰਡਰੇਲਜ਼ ਦੇ ਪਿੱਛੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਸਦਾ ਮੁੱਖ ਚੱਕਰ (core loop) ਇੱਕ ਮਨੁੱਖ ਦੀ ਸਮੱਸਿਆ ਸੁਲਝਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ:
- Perceive (ਸਮਝਣਾ) – ਲੌਗਸ, ਟੈਸਟ ਆਊਟਪੁੱਟ, ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਪ੍ਰਾਪਤ ਕਰਨਾ।
- Reason (ਤਰਕ ਕਰਨਾ) – ਅਸਫਲਤਾ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨਾ, ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਸੁਧਾਰ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣਾ।
- Act (ਕਾਰਵਾਈ ਕਰਨਾ) – ਪੈਚ ਲਾਗੂ ਕਰਨ, ਡਿਪੈਂਡੈਂਸੀ ਅਪਗ੍ਰੇਡ ਕਰਨ, ਜਾਂ ਜੌਬ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣ ਲਈ ਇੱਕ ਸੀਮਤ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ।
- Learn (ਸਿੱਖਣਾ) – ਨਤੀਜੇ ਨੂੰ ਰਿਕਾਰਡ ਕਰਨਾ ਤਾਂ ਜੋ ਅਗਲਾ ਫੈਸਲਾ ਬਿਹਤਰ ਜਾਣਕਾਰੀ ਨਾਲ ਲਿਆ ਜਾ ਸਕੇ।
ਉਹ ਆਰਕੀਟੈਕਚਰ ਜਿਸ ਨੇ ਪ੍ਰਯੋਗ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਿਆ, ਉਹ ਇਸ ਤਰ੍ਹਾਂ ਸੀ:
- CI/CD platform – ਜੌਬਸ ਨੂੰ ਸ਼ਡਿਊਲ ਅਤੇ ਚਲਾਉਂਦਾ ਹੈ।
- Orchestrator – ਉਹ “ਦਿਮਾਗ” ਜੋ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਕੰਟਰੋਲ ਲੂਪ ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਫੈਸਲਾ ਲੈਂਦਾ ਹੈ ਕਿ ਕੀ ਕਰਨਾ ਹੈ।
- Tools – ਉਹ ਹੱਥ ਜੋ ਅਸਲ ਕਾਰਵਾਈਆਂ ਕਰਦੇ ਹਨ (ਜਿਵੇਂ ਕਿ PR ਖੋਲ੍ਹਣਾ, ਵਰਜ਼ਨ ਵਧਾਉਣਾ)।
- Context store – ਹਾਲੀਆ ਅਸਫਲਤਾਵਾਂ ਅਤੇ ਸੁਧਾਰਾਂ ਦੀ ਇੱਕ ਹਲਕੀ ਯਾਦਦਾਸ਼ਤ।
- Guardrails – ਸਖ਼ਤ ਸੀਮਾਵਾਂ ਜੋ ਏਜੰਟ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਨੂੰ ਛੇੜਨ ਜਾਂ ਮਨੁੱਖੀ ਮਨਜ਼ੂਰੀ ਤੋਂ ਬਿਨਾਂ ਬਦਲਾਅ ਕਰਨ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ।
ਲਾਰਜ ਲੈਂਗੂਏਜ ਮਾਡਲ (LLM) ਨੂੰ ਸਿੱਧੇ ਪ੍ਰੋਡਕਸ਼ਨ ਰਾਈਟਸ (production writes) ਤੋਂ ਦੂਰ ਰੱਖ ਕੇ, ਸਿਸਟਮ ਨੇ ਹਮਲੇ ਦੀ ਸਤ੍ਹਾ (attack surface) ਨੂੰ ਘਟਾ ਦਿੱਤਾ ਜਦੋਂ ਕਿ ਮਾਡਲ ਨੂੰ ਸਮੱਸਿਆ ਬਾਰੇ ਤਰਕ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਵੀ ਦਿੱਤੀ।
ਇੱਕ ਮਹੀਨੇ ਦਾ ਏਜੰਟ ਦਾ ਜੀਵਨ
ਹਫ਼ਤਾ 1 – ਸਿਰਫ਼ ਪੜ੍ਹਨਯੋਗ ਨਿਰੀਖਣ
ਏਜੰਟ “ਸਿਰਫ਼ ਵਿਆਖਿਆ” (explain-only) ਮੋਡ ਵਿੱਚ ਚੱਲਿਆ। ਹਰ ਫੇਲ ਹੋ ਰਹੀ ਬਿਲਡ ਨੇ ਇੱਕ Slack ਮੈਸੇਜ ਜਨਰੇਟ ਕੀਤਾ ਜਿਸ ਵਿੱਚ ਗਲਤੀ ਦਾ ਸਾਰ ਦਿੱਤਾ ਗਿਆ ਸੀ ਅਤੇ ਸੰਭਵ ਕਾਰਨਾਂ ਦਾ ਸੁਝਾਅ ਦਿੱਤਾ ਗਿਆ ਸੀ। ਕੋਡ ਵਿੱਚ ਕੋਈ ਬਦਲਾਅ ਨਹੀਂ ਕੀਤਾ ਗਿਆ। ਇਸ ਪੜਾਅ ਨੇ ਸਾਬਤ ਕੀਤਾ ਕਿ ਪਰਸੈਪਸ਼ਨ (perception) ਅਤੇ ਰੀਜ਼ਨਿੰਗ (reasoning) ਕਦਮ ਅਸਲ ਲੌਗਸ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ ਟੀਮ ਨੂੰ ਭਰੋਸਾ ਦਿੱਤਾ ਕਿ ਏਜੰਟ ਕੋਡਬੇਸ ਨੂੰ ਸਮਝਦਾ ਹੈ।
ਹਫ਼ਤਾ 2 – ਸੁਧਾਰਾਂ ਦੀ ਤਜਵੀਜ਼
ਅਗਲੇ ਸੱਤ ਦਿਨਾਂ ਲਈ, ਆਰਕੈਸਟਰੇਟਰ ਨੇ ਘੱਟ ਜੋਖਮ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਜਿਵੇਂ ਕਿ ਲਿੰਟਿੰਗ ਫੇਲ੍ਹ ਹੋਣ ਜਾਂ ਪੁਰਾਣੀਆਂ ਡਿਪੈਂਡੈਂਸੀਆਂ ਲਈ ਪੁੱਲ ਰਿਕੁਐਸਟਾਂ (pull requests) ਖੋਲ੍ਹੀਆਂ। ਇੰਜੀਨੀਅਰਾਂ ਨੇ ਮਰਜ (merge) ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ PRs ਦੀ ਸਮੀਖਿਆ ਕੀਤੀ।
ਹਫ਼ਤਾ 3 – ਨਿਯੰਤਰਿਤ ਕਾਰਵਾਈ
ਮਨਜ਼ੂਰੀ ਵਰਕਫਲੋ (approval workflow) ਲਾਗੂ ਹੋਣ ਨਾਲ, ਏਜੰਟ ਨੂੰ ਨਾਨ-ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਣ ਵਿੱਚ ਜੌਬਸ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਮਿਲ ਗਈ। ਜਦੋਂ ਕੋਈ ਬਿਲਡ ਫੇਲ ਹੋਇਆ, ਤਾਂ ਆਰਕੈਸਟਰੇਟਰ ਨੇ ਆਪਣੇ ਆਪ ਖਰਾਬ ਡਿਪੈਂਡੈਂਸੀ ਦਾ ਸਹੀ ਵਰਜ਼ਨ ਪਿੰਨ ਕੀਤਾ, ਇੱਕ PR ਖੋਲ੍ਹਿਆ ਅਤੇ, PR ਮਰਜ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਪਾਈਪਲਾਈਨ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਇਆ।
ਹਫ਼ਤਾ 4 – ਪ੍ਰਭਾਵ ਨੂੰ ਮਾਪਣਾ
ਆਖਰੀ ਹਫ਼ਤੇ ਦਾ ਧਿਆਨ ਨਤੀਜਿਆਂ ਨੂੰ ਮਾਪਣ 'ਤੇ ਸੀ, ਇਹ ਟ੍ਰੈਕ ਕਰਨਾ ਕਿ ਏਜੰਟ ਨੇ ਕਿੰਨੀਆਂ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਹੱਲ ਕੀਤਾ।
ਫਾਇਦਾ: ਉਬਾਊ ਕੰਮ ਨੂੰ ਖਤਮ ਕਰਨਾ
ਪ੍ਰਯੋਗ ਨੇ ਦਿਖਾਇਆ ਕਿ ਇੱਕ AI ਏਜੰਟ CI/CD ਦੇ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੇ ਹਿੱਸਿਆਂ ਨੂੰ ਸੰਭਾਲ ਸਕਦਾ ਹੈ: ਲੌਗਸ ਪੜ੍ਹਨਾ, ਜਾਣੇ-ਪਛਾਣੇ ਪੈਟਰਨਾਂ ਦੀ ਪਛਾਣ ਕਰਨਾ, ਵਰਜ਼ਨ ਵਧਾਉਣਾ, ਅਤੇ ਜੌਬਸ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣਾ। ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਸਿਰਫ਼ ਅੰਤਿਮ ਬਦਲਾਅ ਮਨਜ਼ੂਰ ਕਰਨੇ ਸਨ ਅਤੇ ਉਹਨਾਂ ਕੁਝ ਐਜ-ਕੇਸ (edge-case) ਅਸਫਲਤਾਵਾਂ ਦੀ ਜਾਂਚ ਕਰਨੀ ਸੀ ਜਿਨ੍ਹਾਂ ਨੂੰ ਏਜੰਟ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਿਆ। ਅਸਲ ਵਿੱਚ ਇਸਦਾ ਮਤਲਬ ਸੀ ਰਾਤ ਦੇ ਵਿਚਕਾਰ ਘੱਟ ਕਾਲਾਂ (pages), ਘੱਟ ਕੰਟੈਕਸ-ਸਵਿਚਿੰਗ, ਅਤੇ ਡਿਵੈਲਪਰਾਂ ਲਈ ਇੱਕ ਬਿਹਤਰ ਫੀਡਬੈਕ ਲੂਪ।
ਮੁਸ਼ਕਲਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਘਟਾਇਆ ਜਾਵੇ
- ਭਰੋਸੇਯੋਗ ਪਰ ਗਲਤ ਸੁਧਾਰ – ਏਜੰਟ ਕਦੇ-ਕਦੇ ਅਜਿਹਾ ਪੈਚ ਲਗਾਉਂਦਾ ਸੀ ਜੋ ਸਿਰਫ਼ ਲੱਛਣਾਂ ਨੂੰ ਛੁਪਾਉਂਦਾ ਸੀ ਪਰ ਅਸਲ ਵਿੱਚ ਡੂੰਘੀ ਬੱਗ (bug) ਨੂੰ ਨਹੀਂ ਹੱਲ ਕਰਦਾ ਸੀ। ਗਾਰਡਰੇਲਜ਼, ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਕੋਡ ਨੂੰ ਛੂਹਣ ਵਾਲੇ ਕਿਸੇ ਵੀ ਬਦਲਾਅ ਲਈ ਮਨੁੱਖੀ ਮਨਜ਼ੂਰੀ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ, ਨੇ ਇਸ ਜੋਖਮ ਨੂੰ ਕਾਬੂ ਵਿੱਚ ਰੱਖਿਆ।
- ਸ਼ੋਰ ਦੀ ਵਧੇਰੇ ਮਾਤਰਾ (Noise overload) – ਅਣਫਿਲਟਰ ਕੀਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਅਸਲ ਅਲਰਟਾਂ ਨੂੰ ਦਬਾ ਸਕਦੇ ਹਨ।
- **ਸਕੋਪ ਕ੍ਰੀਪ (Scope
- orchestrator ਸੈੱਟਅੱਪ ਕਰੋ – ਇੱਕ ਹਲਕੀ ਸੇਵਾ ਜੋ LLM ਨੂੰ ਕਾਲ ਕਰ ਸਕਦੀ ਹੈ, context ਨੂੰ ਸਟੋਰ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ CI/CD APIs ਨੂੰ ਇਵੋਕ ਕਰ ਸਕਦੀ ਹੈ।
- guardrails ਨਿਰਧਾਰਤ ਕਰੋ – ਉਹਨਾਂ CI/CD jobs ਨੂੰ ਵ੍ਹਾਈਟਲਿਸਟ ਕਰੋ ਜਿਨ੍ਹਾਂ ਨੂੰ agent ਟ੍ਰਿਗਰ ਕਰ ਸਕਦਾ ਹੈ, PR ਮਨਜ਼ੂਰੀ ਲਾਜ਼ਮੀ ਕਰੋ, ਅਤੇ ਕਿਸੇ ਵੀ ਸਿੱਧੇ production writes ਨੂੰ ਰੋਕੋ।
- ਹਫ਼ਤਾ 1: Observation mode – orchestrator ਨੂੰ logs ਭੇਜੋ ਅਤੇ ਇਸਨੂੰ ਚੈਟ ਚੈਨਲ 'ਤੇ diagnostic summaries ਪੋਸਟ ਕਰਨ ਦਿਓ।
- ਹਫ਼ਤਾ 2: Suggestion mode – agent ਨੂੰ ਗੈਰ-ਮਹੱਤਵਪੂਰਨ ਫਿਕਸਾਂ ਲਈ PRs ਖੋਲ੍ਹਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ; ਮਨੁੱਖੀ ਸਮੀਖਿਆ (human review) ਲਾਜ਼ਮੀ ਰੱਖੋ।
- ਹਫ਼ਤਾ 3: Controlled action – PR ਮਰਜ ਹੋਣ ਤੋਂ ਬਾਅਦ staging ਜਾਂ test environments ਵਿੱਚ jobs ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ।
- ਹਫ਼ਤਾ 4: Metrics and tuning – triaged failures, false positives, ਅਤੇ ਬਚਾਏ ਗਏ ਸਮੇਂ ਨੂੰ ਟ੍ਰੈਕ ਕਰੋ; ਉਸ ਅਨੁਸਾਰ alert thresholds ਅਤੇ guardrails ਨੂੰ ਐਡਜਸਟ ਕਰੋ।
- Iterate ਕਰੋ – ਟੂਲ ਸੈੱਟ (ਜਿਵੇਂ ਕਿ automated rollbacks, security scans) ਦਾ ਵਿਸਤਾਰ ਤਾਂ ਹੀ ਕਰੋ ਜਦੋਂ ਹਰ ਨਵੀਂ ਸਮਰੱਥਾ ਉਹੀ safety checks ਪਾਸ ਕਰ ਲਵੇ।
ਵਿਰੋਧੀ ਦਲੀਲ
ਸ਼ੱਕੀ ਲੋਕ ਇਹ ਨੁਕਤਾ ਉਠਾਉਂਦੇ ਹਨ ਕਿ agents ਭਰੋਸੇ ਨਾਲ ਗਲਤ ਹੋ ਸਕਦੇ ਹਨ। ਇਸ ਪ੍ਰਯੋਗ ਨੇ ਇਸ ਚਿੰਤਾ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕੀਤਾ; ਇਸਨੇ ਸਿਰਫ਼ ਇਹ ਦਿਖਾਇਆ ਕਿ ਅਨੁਸ਼ਾਸਿਤ guardrails ਤੁਹਾਨੂੰ ਜੋਖਮ ਨੂੰ ਕਾਬੂ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਲਾਭ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ।
ਸਿੱਖਿਆ
ਇੱਕ AI agent ਜੋ CI/CD control loop ਚਲਾਉਂਦਾ ਹੈ, ਉਹ ਇੱਕ reactive, manual triage ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਲਗਭਗ ਇੱਕ self-healing pipeline ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ, ਬਸ਼ਰਤੇ ਤੁਸੀਂ ਮਾਡਲ ਨੂੰ ਅਲੱਗ ਰੱਖੋ, ਸਖ਼ਤ ਮਨਜ਼ੂਰੀ ਦੇ ਕਦਮ ਲਾਗੂ ਕਰੋ, ਅਤੇ ਘੱਟ ਜੋਖਮ ਵਾਲੇ, ਪਹਿਲਾਂ observation-first ਪਹੁੰਚ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰੋ। ਅਸਲ ਮੁੱਲ ਇੰਜੀਨੀਅਰਾਂ ਦੀ ਜਗ੍ਹਾ ਲੈਣ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਸਗੋਂ ਉਹਨਾਂ ਉਬਾਊ, ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੇ ਕੰਮਾਂ ਦਾ ਬੋਝ ਹਟਾਉਣ ਵਿੱਚ ਹੈ ਜੋ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ 'ਗ੍ਰੀਨ' ਰੱਖਦੇ ਹਨ ਅਤੇ ਡਿਵੈਲਪਰਾਂ ਦਾ ਧਿਆਨ ਬਣਾਉਣ 'ਤੇ ਕੇਂਦਰਿਤ ਰੱਖਦੇ ਹਨ।