ਲੂਪ ਇੰਜੀਨੀਅਰਿੰਗ (Loop engineering) ਅੱਜਕਲ ਬਹੁਤ ਚਰਚਾ ਵਿੱਚ ਹੈ। ਕਿਸੇ ਵੀ ਤਕਨੀਕੀ ਫੋਰਮ ਨੂੰ ਦੇਖੋ, ਤੁਹਾਨੂੰ ਅਜਿਹੀਆਂ ਆਵਾਜ਼ਾਂ ਮਿਲਣਗੀਆਂ ਜੋ ਦਲੀਲ ਦੇ ਰਹੀਆਂ ਹਨ ਕਿ ਸਾਨੂੰ AI ਏਜੰਟਸ ਨੂੰ ਸਿਰਫ਼ ਚੈਟਬੋਟਸ ਵਾਂਗ ਨਹੀਂ ਸਮਝਣਾ ਚਾਹੀਦਾ ਜਿਨ੍ਹਾਂ ਨੂੰ ਚਲਾਕ ਪ੍ਰੋਂਪਟਸ (prompts) ਨਾਲ ਸਿਖਾਇਆ ਜਾਵੇ। ਇਸ ਦੀ ਬਜਾਏ, ਉਹ ਕਹਿੰਦੇ ਹਨ ਕਿ ਸਾਨੂੰ ਲੂਪਸ (loops) ਡਿਜ਼ਾਈਨ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ: ਖੁਦਮੁਖਤਿਆਰ ਚੱਕਰ ਜੋ ਇੱਕ ਏਜੰਟ ਨੂੰ ਯੋਜਨਾ ਬਣਾਉਣ, ਲਾਗੂ ਕਰਨ, ਆਪਣੇ ਕੰਮ ਦੀ ਜਾਂਚ ਕਰਨ ਅਤੇ ਜਦੋਂ ਅਸੀਂ ਸੌਂ ਰਹੇ ਹੁੰਦੇ ਹਾਂ ਤਾਂ ਉਸ ਨੂੰ ਦੁਹਰਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ। ਇਹ ਸੁਣਨ ਵਿੱਚ ਬਹੁਤ ਆਕਰਸ਼ਕ ਲੱਗਦਾ ਹੈ। ਜੇਕਰ ਲੂਪ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਤਾਂ ਏਜੰਟ ਲਗਾਤਾਰ ਮਨੁੱਖੀ ਨਿਗਰਾਨੀ ਤੋਂ ਬਿਨਾਂ ਰਸਤੇ 'ਤੇ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਰਾਤੋ-ਰਾਤ ਕੱਚੇ ਇਰਾਦੇ ਨੂੰ ਤਿਆਰ ਆਉਟਪੁੱਟ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਇਹ ਵਾਅਦਾ ਸਿਧਾਂਤ ਵਿੱਚ ਬਹੁਤ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ। ਅਸਲ ਵਿੱਚ, ਜ਼ਿਆਦਾਤਰ ਏਜੰਟ ਪਹਿਲਾਂ ਹੀ ਲੂਪ ਕਰਦੇ ਹਨ। ਉਹ ਕੋਡ ਤਿਆਰ ਕਰਦੇ ਹਨ, ਕੰਪਾਈਲਰ ਗਲਤੀਆਂ (compiler errors) ਜਾਂ ਟੈਸਟ ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ, ਕੋਡ ਨੂੰ ਸੁਧਾਰਦੇ ਹਨ, ਅਤੇ ਦੁਬਾਰਾ ਚਲਾਉਂਦੇ ਹਨ। ਇਹ ਬੁਨਿਆਦੀ ਫੀਡਬੈਕ ਚੱਕਰ ਨਵਾਂ ਨਹੀਂ ਹੈ। ਜਿਸ ਦੀ ਹੁਣ ਸਮਰਥਕ ਮੰਗ ਕਰ ਰਹੇ ਹਨ, ਉਹ ਕੁਝ ਵਧੇਰੇ ਅਭਿਲਾਸ਼ੀ ਹੈ: ਇੱਕ ਬਾਹਰੀ ਲੂਪ (outer loop) ਜੋ ਸਿਰਫ਼ ਸਿੰਟੈਕਸ ਗਲਤੀਆਂ ਨੂੰ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਪੂਰੇ ਕੰਮ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦਾ ਹੈ। ਉਸ ਬਾਹਰੀ ਲੂਪ ਨੂੰ ਬਣਾਉਣਾ ਹੀ ਮੁਸ਼ਕਲ ਕੰਮ ਹੈ, ਕਿਉਂਕਿ ਸਾਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰਿੰਗ ਸ਼ਾਇਦ ਹੀ ਕਦੇ ਨਿਸ਼ਚਿਤ ਨਿਯਮਾਂ ਵਾਲਾ ਇੱਕ ਬੰਦ ਸਿਸਟਮ ਹੁੰਦੀ ਹੈ।
ਲੂਪ ਡਿਜ਼ਾਈਨ ਦੀ ਸਮੱਸਿਆ
ਪ੍ਰੋਡਕਟ ਦੇ ਟੀਚੇ ਅਕਸਰ ਉਲਝਣ ਵਾਲੇ ਹੁੰਦੇ ਹਨ। ਤੁਸੀਂ ਸ਼ਾਇਦ ਹੀ ਕਦੇ ਕੰਮ ਦੇ ਮੁਕੰਮਲ ਹੋਣ ਦੀ ਇੱਕ ਸੰਪੂਰਨ ਪਰਿਭਾਸ਼ਾ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰਦੇ ਹੋ। ਅਕਸਰ, ਤੁਸੀਂ ਅਸਲ ਟੀਚਾ ਉਦੋਂ ਪਤਾ ਲੱਗਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਬਿਲਡ (build) ਦੇ ਕੰਮ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਡੁੱਬੇ ਹੁੰਦੇ ਹੋ। ਇੱਕ ਲੋੜ ਜੋ ਵ੍ਹਾਈਟਬੋਰਡ 'ਤੇ ਸੌਖੀ ਲੱਗਦੀ ਸੀ, ਉਹ ਅਜਿਹੇ ਐਜ ਕੇਸ (edge cases) ਵਾਲੀ ਨਿਕਲਦੀ ਹੈ ਜੋ ਹੱਲ ਦੇ ਰੂਪ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਏਜੰਟ ਨੂੰ ਇੱਕ ਸਖ਼ਤ ਲੂਪ ਦੇ ਅੰਦਰ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਉਹ ਸਖ਼ਤੀ ਇੱਕ ਰੁਕਾਵਟ ਬਣ ਜਾਂਦੀ ਹੈ। ਲੂਪ ਉਸ ਟੀਚੇ 'ਤੇ ਵਾਰ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ ਜੋ ਸ਼ਾਇਦ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਤੋਂ ਵੀ ਮਾੜਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਲਚਕਦਾਰ ਲੂਪ ਕਈ ਵਾਰ ਟੀਚੇ ਨੂੰ ਚੁੱਪਚਾ ਬਦਲ ਕੇ ਡੈੱਡਲੌਕ (deadlock) ਨੂੰ ਹੱਲ ਕਰ ਦਿੰਦਾ ਹੈ ਤਾਂ ਜੋ ਉਹ ਜੋ ਵੀ ਆਉਟਪੁੱਟ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ ਉਸ ਨਾਲ ਮੇਲ ਖਾ ਸਕੇ। ਦੋਵੇਂ ਹੀ ਨਤੀਜੇ ਲਾਭਦਾਇਕ ਨਹੀਂ ਹਨ। ਇੱਕ ਕੰਪਿਊਟ (compute) ਬਰਬਾਦ ਕਰਦਾ ਹੈ; ਦੂਜਾ ਭਰੋਸੇ ਨਾਲ ਕੂੜਾ (garbage) ਭੇਜ ਦਿੰਦਾ ਹੈ।
ਗਹਿਰੀ ਸਮੱਸਿਆ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਲਾਗਤ (specification cost) ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਇੱਕ ਲੂਪ ਬਿਨਾਂ ਨਿਗਰਾਨੀ ਦੇ ਚੱਲੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਅਜਿਹੀ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਲਿਖਣੀ ਪਵੇਗੀ ਜੋ ਲਗਭਗ ਹਰ ਚੀਜ਼ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਵੇ। ਏਜੰਟ ਨੂੰ ਬਿਲਕੁਲ ਕੀ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ? ਕਿਹੜਾ ਮੌਜੂਦਾ ਵਿਵਹਾਰ ਅਟੱਲ ਹੈ ਅਤੇ ਉਸ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ? ਕਿਹੜੀਆਂ ਸਹੀ ਸ਼ਰਤਾਂ ਦੇ ਅਧੀਨ ਏਜੰਟ ਨੂੰ ਦੁਹਰਾਉਣਾ (iterating) ਬੰਦ ਕਰ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ? ਕਿਹੜੇ ਜੋਖਮ ਸਵੀਕਾਰਯੋਗ ਹਨ, ਅਤੇ ਕਿਹੜੇ ਮਾੜੇ ਪ੍ਰਭਾਵਾਂ (side effects) ਕਾਰਨ ਤੁਰੰਤ ਰੁਕਣਾ ਚਾਹੀਦਾ ਹੈ? ਉਸ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਲਿਖਣ ਵਿੱਚ ਏਜੰਟ ਦੇ ਨਾਲ ਬੈਠ ਕੇ ਰੀਅਲ-ਟਾਈਮ ਵਿੱਚ ਕੰਮ ਕਰਵਾਉਣ ਨਾਲੋਂ ਵੀ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਆਟੋਮੇਸ਼ਨ ਦੇ ਬਦਲੇ ਇੱਕ ਭਾਰੀ ਅਗਾਊਂ ਟੈਕਸ ਦੇ ਰਹੇ ਹੋ, ਜੋ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਫਾਇਦੇਮੰਦ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਜਾਂਚ (verification) ਕਰਨਾ ਕੰਮ ਕਰਨ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਸਸਤਾ ਹੋਵੇ
There is a crucial distinction missing from much of the current conversation. Loops are regulators. They keep a system aligned with a predetermined target, much like a thermostat keeps a room at seventy-two degrees. But the thermostat does not choose seventy-two. Someone had to decide that was the right temperature first.
Applied to software, this means an agent inside a loop can fix bugs, refactor functions, or tune parameters all day long. It cannot, however, decide which feature actually helps the customer or whether a bug is worth fixing before the next release. Those choices require judgment about business context, user pain, and strategic priority. Agents execute. Humans decide. Confusing the two is how teams end up with beautifully optimized systems that solve the wrong problem.
Loop engineering is useful, but it is narrow. It helps you run the machine with discipline and speed. It does not decide what machine to build, who it is for, or what success looks like in human terms. The judgment about which feature matters, which risk is acceptable, and when the goal itself needs to change lives with you. Build loops for the work you already understand well enough to verify automatically. Keep yourself in charge of everything else.
This article draws on ideas originally discussed by Isaac Hagoel in “Loop Engineering Minus The Hype.” For more engineering discussions, join our learning community on Telegram.