AI coding agents are becoming normal developer tools. The interesting question is no longer whether they can write code.
It is where you should let them act without a human.
Stack Overflow’s 2026 Developer Survey found that 66% of respondents use AI coding assistants or agents, and 73% of those users use them daily. But the same survey shows a much more cautious pattern when the action becomes operational: developers delegate writing code and debugging far more often than deploying software.
That gap is useful.
It suggests a practical rule for AI-assisted development:
Automate the work first. Keep the consequences human-controlled.
Not every task has the same risk
Imagine an AI agent working on a small web application. You could let it:
- explain an unfamiliar function
- generate a unit test
- refactor repetitive code
- update documentation
- open a pull request
- merge the pull request
- deploy directly to production
Those are not six versions of the same permission.
The first tasks are relatively easy to verify and reverse. The last one can create consequences outside the codebase.
That means an agent should not receive one giant permission called do_the_job.
A simple permission ladder
I like thinking about agent permissions as a ladder:
Level 1 — Read
Inspect files, logs, docs, and configuration.
Level 2 — Suggest
Generate code, tests, plans, and patches.
Level 3 — Change
Modify files and run local checks.
Level 4 — Propose
Create a pull request or change request for review.
Level 5 — Execute
Merge, publish, deploy, or change production systems.
Most everyday coding-agent work can happen safely in Levels 1–4.
Level 5 deserves a different standard.
Let the agent prove its work
A useful agent workflow is not:
Task → Agent → Production
It is closer to:
Task
↓
Inspect
↓
Plan
↓
Implement
↓
Test
↓
Show evidence
↓
Human review
↓
Deploy
The important addition is show evidence.
Ask the agent to report:
- Which files changed.
- Which tests it added or modified.
- Which commands it actually ran.
- The test results.
- Any assumptions it made.
- Anything it could not verify.
This makes the agent's output easier to audit instead of treating its explanation as proof.
Why deployment is different
A failed unit test is usually a clear signal.
A bad production deployment can be much messier:
- users can lose access
- data can be corrupted
- secrets can be exposed
- infrastructure costs can increase
- a dependency can break an unrelated service
- a seemingly harmless migration can be difficult to reverse
The agent may be perfectly capable of executing the deployment command and still be the wrong system to decide whether this particular deployment should happen now.
That distinction matters.
Technical ability and decision authority are not the same thing.
The 10-minute experiment
If you are introducing coding agents into a project, try this before giving them production access.
Pick one small feature and ask the agent to complete it with these constraints:
You may inspect the repository and modify source files.
You must:
- explain the current implementation first
- make the smallest reasonable change
- add or update tests
- run the relevant checks
- report the exact commands and results
- list assumptions and remaining risks
Do not deploy, merge, or modify production systems.
Then review the result like a normal pull request.
You are not trying to prove that the agent is perfect. You are measuring how much of the development loop it can handle without increasing your review burden.
That last part is important.
If an agent saves 30 minutes of typing but creates 45 minutes of verification work, the workflow is not necessarily faster.
What the 2026 data suggests
The Stack Overflow survey gives a useful picture of where developers are comfortable delegating work.
Among respondents who use AI agents, writing or generating code was delegated by 72.9%, debugging by 62.2%, and writing or maintaining tests by 50.6%.
Deployment was only 9.8%.
That does not prove that deployment automation is bad. It shows something more interesting: developers are already drawing a boundary between generating changes and causing external effects.
That boundary is worth designing intentionally.
My default setup
For a small web project, my starting point would be:
Agent can:
- read the repository
- search documentation
- edit code
- run tests and linters
- inspect build output
- prepare commits or pull requests
- explain its changes
Agent must ask for approval before:
- merging to the main branch
- changing production configuration
- modifying databases
- rotating secrets
- deploying production
- spending money through external services
As confidence grows, individual permissions can be expanded.
That is much safer than starting with full access and trying to discover the dangerous edge cases afterward.
The bigger idea
The next step in AI-assisted development is not simply giving agents more autonomy.
It is designing better boundaries around autonomy.
The best workflow may be the one where the agent is extremely autonomous inside a well-defined sandbox, while a human remains responsible for the few actions that are expensive, irreversible, or difficult to verify.
AI agents are getting very good at producing changes.
Our job is to get better at deciding which changes they are allowed to make on their own.
Where would you draw the line: what is the first action you would never let a coding agent perform without human approval?
Sources:
- Stack Overflow Developer Survey 2026 — AI usage: https://survey.stackoverflow.co/2026/ai
- Stack Overflow Developer Survey 2026 — tasks delegated to AI agents: https://survey.stackoverflow.co/2026/knowledge/data/know-agent-delegate
Top comments (2)
Your ladder puts human review at level 4, but the expensive part starts after it. An agent that opens six PRs to get one merged spends six attempts on one unit of accepted work, and the permission level does not change that arithmetic. Do you track review load per merged PR, or only per agent run?
Anything irreversible outside the repo: sending email, payments, deleting data, prod migrations. Inside the repo git makes most mistakes cheap, outside it nothing does.