Engineering teams evaluating coding agents usually start with the wrong question. They want to know how autonomous the agent can get. How much of the pipeline can it own? Can it write the spec, edit the repository, and push to production without bothering anyone? The demos make this obsession easy. You see a slick workflow where a single prompt triggers a cascade of edits and deployments, and the instinct is to chase that same capability inside your own organization. But glamour is a lousy design principle. The better questions are far less exciting: who gave this thing authority, what systems can it actually touch, and what happens when it inevitably gets something wrong?

The Autonomy Trap

Exciting autonomy is a trap. It trains us to celebrate bots that generate specifications, modify repositories, and deploy code while calmly claiming the task is finished. That is not engineering. It is a trust fall with shell access. The work itself becomes almost too easy to produce. Any model can churn out code, documentation, or architecture plans in seconds. But the real cost in software development has never been typing speed. It has always been the validation, the review, and the careful decision to say yes, this is correct and safe to ship. Generated work is cheap. Approval is expensive. The companies that figure out how to handle approval cleanly and consistently will be the ones that actually ship reliable systems.

Why Self-Review Fails

The risks show up in predictable patterns. A model drafts a plan and then evaluates whether that plan is any good. An agent edits your codebase and explains to you why its changes are safe. A tool executes a command and asks for forgiveness instead of permission. Each of these represents the same core failure. If an agent produces a specification, something outside of that agent must sign off on it before it becomes truth. If an agent modifies code, a separate process must inspect the diff. Letting the generator act as its own validator is not a shortcut. It is a structural bug dressed up as convenience.

Prompts Are Not Permission Systems

You cannot secure an agent with clever wording. Telling a model to be careful or to ask before deleting something does not create a boundary. Prompts are not permission systems. Before you let an agent anywhere near production, you need an honest inventory of its capabilities. Can it read the entire repository? Can it execute shell commands? Can it open a browser? Can it pull customer data into its context window? Most teams do not know the full answers. They assume the tool is confined to a sandbox when it actually holds write access to critical paths. Map the surface area first. Then build the walls.

Build a Tiered Control System

Once you understand what the agent can do, design a control system that matches risk to friction. Low-risk actions, like updating internal documentation or formatting consistent code, can run automatically. Medium-risk actions, such as refactoring a module or adding a new dependency, should hit a checkpoint where a human or a verified test suite confirms the move. High-risk actions, deploying to production, modifying infrastructure, or accessing sensitive data, need a separate approver who was not involved in the generation. Every single action must leave an audit trail. You should be able to replay exactly which files were read, which tools were invoked, and which decisions were made. Agentic development is not a license to skip reviews. Boring friction is a feature. A proper approval gate acts like a circuit breaker when things start to drift.

Match the Boundary to the Risk

Calibrate your boundaries to the actual danger. Turning every Markdown formatting tweak into a compliance ceremony will grind your team to a halt. But treating high-stakes actions as harmless because the agent seems confident is equally foolish. The goal is proportionate control, not theatrical restriction.

Keep Artifacts Small and Observable

ਸਭ ਤੋਂ ਲਾਭਦਾਇਕ ਏਜੰਟ ਸਿਸਟਮ ਤੁਹਾਨੂੰ ਵੱਡੇ ਖੁਦਮੁਖਤਿਆਰ ਰਨਾਂ (autonomous runs) ਨਾਲ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਛੋਟੇ, ਸਮੀਖਿਆਯੋਗ ਆਰਟੀਫੈਕਟਸ (artifacts) ਤਿਆਰ ਕਰਦੇ ਹਨ। ਇੱਕ ਸਹੀ ਯੋਜਨਾ। ਇੱਕ ਕੇਂਦਰਿਤ ਡਿਫ (diff)। ਇੱਕ ਪੜ੍ਹਨਯੋਗ ਲੌਗ (log)। ਵਿਸ਼ਾਲ ਖੁਦਮੁਖਤਿਆਰ ਕਾਰਜ (executions) ਡੀਬੱਗ ਕਰਨ ਲਈ ਇੱਕ ਦੁਸ਼ਵਿਧਾ ਹਨ। ਜਦੋਂ ਪੰਜਾਹ-ਫਾਈਲਾਂ ਵਾਲੇ ਏਜੰਟ ਸੈਸ਼ਨ ਤੋਂ ਬਾਅਦ ਕੁਝ ਖਰਾਬ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕੋ ਸਮੇਂ ਇਰਾਦੇ (intent), ਕਾਰਜ (execution) ਅਤੇ ਸਾਈਡ ਇਫੈਕਟਸ (side effects) ਨੂੰ ਸੁਲਝਾਉਣਾ ਪੈਂਦਾ ਹੈ। ਪ੍ਰਭਾਵ ਦਾ ਘੇਰਾ (blast radius) ਛੋਟਾ ਰੱਖੋ। ਇਸ ਗੱਲ 'ਤੇ ਜ਼ੋਰ ਦਿਓ ਕਿ ਏਜੰਟ ਨੇ ਕਿਹੜੀਆਂ ਫਾਈਲਾਂ ਪੜ੍ਹੀਆਂ ਅਤੇ ਕਿਹੜੇ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਦੇਖਣਯੋਗ (Observable) ਸਿਸਟਮ ਹੀ ਰੱਖ-ਰਖਾਅਯੋਗ (maintainable) ਸਿਸਟਮ ਹੁੰਦੇ ਹਨ। ਬਲੈਕ-ਬਾਕਸ ਖੁਦਮੁਖਤਿਆਰੀ ਸਿਰਫ਼ ਬਿਹਤਰ ਮਾਰਕੀਟਿੰਗ ਵਾਲਾ ਤਕਨੀਕੀ ਕਰਜ਼ਾ (technical debt) ਹੈ।

ਐਕਸੈਸ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਛੇ ਸਵਾਲ

ਕਿਸੇ ਏਜੰਟ ਨੂੰ ਕੋਈ ਅਸਲ ਜ਼ਿੰਮੇਵਾਰੀ ਸੌਂਪਣ ਤੋਂ ਪਹਿਲਾਂ, ਆਪਣੇ ਸੈੱਟਅੱਪ ਦਾ ਛੇ ਔਖੇ ਸਵਾਲਾਂ ਨਾਲ ਟੈਸਟ ਕਰੋ।

  • ਸਿਸਟਮ ਕੋਲ ਅਸਲ ਵਿੱਚ ਕਿਹੜੀਆਂ ਸਮਰੱਥਾਵਾਂ ਹਨ?
  • ਕਿਹੜੇ ਕਾਰਜ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਮਨ੍ਹਾ ਹਨ, ਜੋ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਇੱਕ ਨਿਮਰ ਵਾਕ ਰਾਹੀਂ ਰੋਕਣ ਦੀ ਬਜਾਏ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਪੱਧਰ 'ਤੇ ਰੋਕੇ ਗਏ ਹਨ?
  • ਕਿਹੜੇ ਕਾਰਜਾਂ ਲਈ ਸਪੱਸ਼ਟ ਪ੍ਰਵਾਨਗੀ ਦੀ ਲੋੜ ਹੈ?
  • ਕਿਹੜੇ ਆਰਟੀਫੈਕਟਸ ਏਜੰਟ ਦੁਆਰਾ ਵਰਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਫ੍ਰੀਜ਼ (freeze) ਕਰ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਜੋ ਉਹ ਚੁੱਪਚਾਪ ਆਪਣੇ ਇਨਪੁੱਟਸ ਵਿੱਚ ਹੇਰਾਫੇਰੀ ਨਾ ਕਰ ਸਕੇ?
  • ਜਨਰੇਟਰ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰਾ ਕਿਹੜਾ ਵੈਲੀਡੇਟਰ (validator) ਅੰਤਿਮ ਆਉਟਪੁੱਟ ਦਾ ਫੈਸਲਾ ਕਰਦਾ ਹੈ?
  • ਕਿਹੜਾ ਲੌਗ ਬਿਨਾਂ ਕਿਸੇ ਸ਼ੱਕ ਦੇ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਹੋਇਆ ਸੀ?

ਇਹ ਬੁਨਿਆਦੀ ਇੰਜੀਨੀਅਰਿੰਗ ਹਾਈਜੀਨ ਹੈ। ਜਨਰੇਟਰ ਨੂੰ ਵੈਲੀਡੇਟਰ ਤੋਂ ਵੱਖ ਰੱਖੋ। ਮਨੁੱਖੀ ਅਧਿਕਾਰ (human authority) ਨੂੰ ਸੀਮਾ 'ਤੇ ਰੱਖੋ।

ਅਸਲੀ ਟੈਸਟ

ਉੱਥੇ