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

Les systèmes d'agents les plus utiles n'essaient pas de vous éblouir avec des exécutions autonomes massives. Ils produisent de petits artefacts révisables. Un plan précis. Un diff ciblé. Un log lisible. Les exécutions autonomes géantes sont des cauchemars à déboguer. Quand quelque chose casse après une session d'agent de cinquante fichiers, vous devez démêler l'intention, l'exécution et les effets de bord, tout cela en même temps. Limitez le périmètre d'impact. Exigez de savoir quels fichiers l'agent a lus et quels outils il a appelés. Les systèmes observables sont des systèmes maintenables. L'autonomie en boîte noire n'est que de la dette technique avec un meilleur marketing.

Six questions avant d'accorder l'accès

Avant de confier une réelle responsabilité à un agent, testez la résistance de votre configuration avec six questions difficiles.

  • Quelles sont les capacités réelles du système ?
  • Quelles actions sont refusées par défaut, bloquées au niveau de l'infrastructure plutôt que simplement découragées par une phrase polie dans le prompt système ?
  • Quelles actions nécessitent une approbation explicite ?
  • Quels artefacts sont figés avant que l'agent ne les consomme, afin qu'il ne puisse pas manipuler silencieusement ses propres entrées ?
  • Quel validateur, entièrement distinct du générateur, juge le résultat final ?
  • Quel log prouve, sans ambiguïté, ce qui s'est réellement passé ?

C'est l'hygiène technique de base. Séparez le générateur du validateur. Maintenez l'autorité humaine à la limite du système.

Le véritable test

Il y a