AI agents need approval boundaries, not autonomy theater
Most teams are asking the wrong question about coding agents.
The interesting question is not "how autonomous can this thing be?" It is "who gave it authority, what can it touch, and what happens when it is wrong?"
That sounds less exciting. Good. Exciting is how you end up with a bot that can write a spec, edit a repo, call a tool, open a browser, push a diff, and then vaguely claim it "completed the task." That is not an engineering workflow. That is a trust fall with shell access.
Generated work is cheap now. Approval is still expensive. The companies that figure out the second part will get more value from agents than the ones endlessly shopping for the next smarter model.
The hard part is authority, not generation
A recent DEV.to piece about AIEOS makes a clean point: AI can write the spec, but it cannot approve it. That distinction is easy to nod along with and surprisingly easy to violate in practice.
You see the violation everywhere:
- the model writes the plan and judges whether the plan is good
- the agent changes code and summarizes why the change is safe
- the same run creates the artifact and decides it is ready for the next step
- the tool takes action first and leaves the human to reconstruct what happened later
That is not a small process smell. That is the core failure mode.
If an agent writes a spec, something outside the generator should decide whether the spec is acceptable. If an agent changes code, something outside that run should decide whether the diff is shippable. If an agent wants to touch production-adjacent systems, credentials, dependencies, workflows, or customer-facing assets, the approval path should be explicit before the action happens.
Otherwise "agentic development" just becomes a more expensive way to skip review.
Capability inventory beats prompt trust
Prompts are useful. Prompts are not permission systems.
The practical move is to inventory what the agent can actually do. Can it read the whole repo? Write anywhere? Run shell commands? Use a browser session? Call internal APIs? Install packages? Push branches? Send messages? Publish content? Touch image assets? Open customer data?
Once the list exists, the shape of the control system gets much less mystical:
- low-risk actions can run automatically
- medium-risk actions can require a visible checkpoint
- high-risk actions need a separate approver
- every consequential action should leave an audit trail
That is why projects like MakerChecker are interesting even if they are early. The useful idea is not "this one repo solved agent governance." It is the pattern: deny-by-default roles, governed tools, human approvals, segregation of duties, and signed audit trails.
That is the right direction. Not because every side project needs enterprise governance. Because teams need something more concrete than "the prompt told it to be careful."
The agent label is almost useless now
Product Hunt had a discussion asking whether every product is suddenly becoming an "AI agent." The answer is basically yes, at least in marketing language.
But "agent" does not tell you much anymore.
An assistant suggests. An automation executes a predefined path. An agent takes context, chooses actions, uses tools, and brings work back. That last category is where the risk changes, because the system has moved from text generation into workflow execution.
The useful product question is not whether something deserves the agent label. The useful question is where autonomy stops.
Can the user see the proposed action before it happens? Can the system reverse it? Can another role approve it? Can the team tell which tool calls happened and why? Can a reviewer inspect a small diff instead of a massive pile of generated work?
If the answer is no, you do not have an agent workflow. You have a demo with a blast radius.
Developer machines are already too powerful
The security backdrop matters here.
Developer workstations are full of quiet authority: package managers, extension ecosystems, API keys, local credentials, Git remotes, shell history, browser sessions, private repos, internal docs. Supply-chain incidents keep reminding us that the developer machine is not some harmless local playground.
Agents make that surface faster.
They do not invent dependency risk. They accelerate it. They do not invent bad extension behavior. They inherit the IDE. They do not invent sloppy review. They generate more work for review to miss.
That is why boring friction is becoming a feature. A two-hour extension update delay sounds dull until you remember that dull controls often exist because instant propagation is a gift to attackers. The same logic applies to agents. A good approval gate is not bureaucracy by default. Sometimes it is just a circuit breaker.
Make outputs reviewable, not just impressive
The most useful agent systems I have seen, and the ones I trust fastest, make small artifacts.
Small plans. Small diffs. Small command logs. Small generated assets. Small review packets.
Big autonomous runs feel amazing until you have to debug them. Then you discover that "the agent completed the task" means very little. Completed which step? With which assumptions? After reading which files? With which tool calls? Did it skip a warning? Did it quietly route around a failed check? Did it create a screenshot, resize it, and place it somewhere publishable, or did it just say it did?
For visual or publishing workflows, that last mile matters. If a team asks an agent to prepare reviewable screenshots or social assets for a release note, a browser-local utility like Resize Image For can be one boring step in the packet: resize the artifact, preserve the source image locally, and make the output easier to inspect. Not the center of the workflow. Just a concrete example of the kind of artifact boundary that keeps review sane.
The same applies to generated interfaces. If you are exploring agentic UI, component catalogs, or generative interface patterns, keep a grounded reference set close by. A curated index such as Awesome Generative UI is useful because it lets a team compare papers, cases, videos, and open-source resources without pretending every agent-rendered UI idea is new.
Agents are easier to trust when their outputs are boring enough to review.
What the control pattern looks like
I would start with six questions before letting a coding agent do anything serious:
- What capabilities does it have?
- Which actions are denied by default?
- Which actions need approval before execution?
- Which artifacts are frozen before downstream work depends on them?
- Which validator judges the output outside the generator?
- Which log proves what happened after the run?
That is not heavy process. That is basic engineering hygiene.
A generated spec should be frozen before implementation starts. A diff should be small enough for a human to review. A tool call that changes external state should be gated. A high-risk action should not be approved by the same identity that requested it. A failed validation should stop the flow instead of becoming another prompt for the model to rationalize.
The key move is separation. Generator over here. Validator over there. Human approval at the boundary. Audit trail underneath.
Do not overbuild this for toy tasks
There is a trap in the other direction too.
Not every agent action needs a governance platform. If the agent is renaming local variables in a throwaway branch, run it, review the diff, move on. If it is formatting Markdown, do not turn that into a compliance ceremony.
Approval boundaries should match risk.
The mistake is treating all agent work as harmless because some of it is harmless. The other mistake is treating all agent work as dangerous because some of it is dangerous. The sane version is more boring: classify capabilities, set defaults, gate consequential actions, and keep the work reviewable.
That is enough for most teams to start.
The practical test
Here is the test I keep coming back to:
If the agent is wrong, can your team see it, stop it, reverse it, and learn from it?
If yes, you probably have a workflow.
If no, more autonomy will not save you. It will just make the failure arrive faster.
Source notes
Top comments (0)