Agents can write more code, but they should not decide alone
The turning point in AI-assisted development is not code generation; it is how the team decides what gets through. Agents can already draft functions, propose fixes, rewrite tests, summarize diffs, and open pull requests that look clean at first glance. That is useful, but it does not remove coordination work. In fact, the faster the agent produces output, the more precisely the team has to define the boundary between what the agent may do on its own and what must remain a human decision. GitHub says this plainly: a prompt gives you a one-off output, while a reliable workflow needs checks, context, and controls. In practice, that means the developer does not disappear. The developer becomes the person who designs the delivery system, not just the line of code.
This idea is too often framed as a productivity story, when it is really a governance story. When a team hands a task to an agent, it is not only delegating typing speed. It is delegating part of the intent, the context, the sequence of work, and the responsibility for the result. If the scope is fuzzy, the agent fills in the gaps with whatever it can infer. If permissions are too broad, it can make changes that pass tests but break the architecture, an API contract, or a business assumption only a human would know. The right workflow does not try to make the model “do what a human would do, just faster.” It tries to make delegation explicit, bounded, and reversible.
The new unit of control is the review rule
OpenAI put this into concrete terms in its post on custom code review rules for Codex. Some comments keep coming back: preserve an old API, avoid logging customer data, do not rename a symbol that feeds another service, or respect a local constraint that new contributors cannot possibly guess. The lesson is simple: if reviewers repeat the same explanation, that explanation deserves to be written down. Put it close to the code, in a file such as AGENTS.md, and you turn oral knowledge into an interface that both humans and agents can read.
That shift matters because it moves review upstream. Instead of hoping a model “understands” a repository’s history, you encode the invariants that actually matter: backward compatibility, data boundaries, access limits, security conventions, and acceptable fallback paths. A good review rule is not a novel. It is short, scoped, and actionable. It says what must not change, why it is sensitive, and what safer alternative is acceptable. That is exactly what agents need when they work in a codebase they do not yet know well. And it is exactly what humans want to see again when they review a change proposed by automation.
The trap here would be to turn rules into bureaucracy. If everything becomes a rule, nothing has weight. The best rules protect a decision that is expensive to get wrong. They speak about compatibility, data, security, side effects, or genuinely painful exceptions. They do not replace tests; they complement the things tests cannot express. Tests catch deterministic regressions. Review rules remind everyone what a clean-looking diff must still not do, even when the build is green.
Large pull requests are not a win; they are a cognitive cost
The second shift comes from the structure of the work itself. In its post on stacked pull requests, GitHub points out that a highly productive agent naturally pushes teams toward the giant diff. That is understandable: if a model can complete in one pass what several humans would do in steps, it tends to package everything into one PR. The problem is not aesthetic. It is mental. A review does not improve just because it processes more lines per minute. It improves when each layer of change remains small enough to understand, validate, and correct without losing the thread.
Decomposition helps keep humans in the loop precisely because it preserves orientation. Each layer has its own goal, base, review set, and checks. You can read the bottom of the stack before the top, let deterministic controls run at every layer, and assign the right parts of the change to the right people. A layer that touches the data model does not call for the same judgment as a layer that touches the UI or the agent wiring. In other words, the stack is not just an organization technique. It is a comprehension device. It stops the giant PR from hiding the real decision.
This becomes even more useful when teams wire agents into real workflows. An agent can absolutely handle issue triage, documentation sync, or low-risk maintenance. But once the change becomes broader in scope, the delivery structure has to make the reasoning visible. Without that, you end up with a machine that produces a lot, but no one can review properly. Speed goes up, but decision quality goes down.
The developer role changes, but responsibility does not move away
The most seductive story around agents is that the developer “becomes an orchestrator.” That description is fair, but it is easy to misread. Orchestrating does not mean cheering for the model’s autonomy and stepping aside. It means choosing the context, limiting the blast radius, defining the stopping points, and deciding where human approval is still mandatory. GitHub describes this as a control plane: agents handle ambiguous, context-heavy tasks, while deterministic checks — lint, tests, build, security — take over before anything merges. It works because the machine does not decide everything; it sits inside a chain where some stages are mechanical and others require judgment.
Useful autonomy, visible boundary. That is the rule missing from many flashy demos. An agent can help move a task forward faster, but the important question is still: who is accountable if the change is wrong? Who confirms that an exception is acceptable? Who decides that a green test suite is not enough because the code changes business behavior that the tests do not cover? As long as those answers stay human, the system has a clear direction. The moment they are implicitly transferred to the model, you are no longer talking about orchestration; you are talking about blindness.
The practical habit is to separate two kinds of work. The first is broad, repetitive, sometimes exploratory: preparing a migration, proposing a refactor, syncing tests and docs, or assembling a first draft. The second is sensitive: approving a breaking change, widening permissions, touching a payment path, changing an external contract, or accepting a security exception. Agents are good at the first kind of work. Humans must stay in command of the second.
What a repository should write down explicitly
A repository that wants to use agents seriously has to turn tacit habits into visible instructions. That does not require a fifty-page constitution. It requires a few well-chosen rules written where agents and reviewers can see them at the right moment. In practice, a good starting point looks like this:
- domain rules in
AGENTS.mdor an equivalent file, placed close to the code they govern; CODEOWNERSso review responsibility is explicit;- protected branches and required approvals for high-risk changes;
- mandatory deterministic checks: tests, lint, build, security analysis;
- clear fallback rules: when the agent must stop and ask a human;
- compatibility or migration guidance for public interfaces and contracts.
The key point is not the list itself, but the fact that it is governed. Rules should be short, tested against real diffs, and removed if they create too much noise. A useful rule actually changes the review. If you can remove it without changing reviewer behavior, it is probably too weak or too vague. Conversely, if a rule keeps firing on the same major risk, it has earned its place in the repository.
When should you still say no to the agent?
There are situations where the best use of an agent is to let it prepare the ground, then hand the wheel back to a human before anything is committed. That is the right move for changes involving sensitive data, permissions, keys, secrets, irreversible migrations, fallback paths, or contracts that extend beyond the repository. It is also the right move when the code looks correct but the intent is not: a test may be green even though the change introduces product ambiguity, compliance risk, or behavior that operators cannot accept.
Automation should reduce friction, not dilute accountability.
The human role is therefore not only to correct agent mistakes. It is to decide exceptions, interpret weak signals, and keep control over scope changes. The better agents get at producing code, the more disciplined the team has to be about framing that production. That is not a regression. It is the normal price of a more powerful system.
A simple pattern for a team that wants to move without getting lost
If a team wants to adopt this approach without drowning in ceremony, it can start with one tiny, concrete workflow. Pick a bounded task — documentation-test synchronization, a low-risk fix, or issue triage — then define the agent’s autonomy level, the permission limits, and the validation it must satisfy. Write one or two rules in AGENTS.md for the invariants you repeat all the time. Then ask the agent to work in a PR or PR stack that is small enough to remain legible, with deterministic checks required before any human review.
- Start small and narrow, not with a general-purpose assistant.
- Write down the rules reviewers already repeat.
- Keep changes small enough to preserve understanding.
- Let tests and security stop what can be stopped automatically.
- Reserve human approval for changes in context, risk, or scope.
- Revise the rules when they become noise instead of signal.
This pattern is deliberately unglamorous. That is exactly why it works. It gives AI a useful role without granting sovereignty. It reduces friction without reducing vigilance. And it lets a team increase shipping capacity without losing the memory of why a change should pass, or should not pass.
The real gain from agents is the scale of human work, not the disappearance of human judgment
If you look at the strongest workflows today, the message is fairly consistent. Agents are getting more capable; the strongest teams are getting more explicit. They write their rules, split their PRs, protect their branches, and keep one person responsible for the final yes. The speed gains are real, but they show up most clearly when autonomy is contained inside a system humans still understand. That is where AI helps for real: it accelerates execution, not abdication.
In practice, the goal should not be “make AI do our work for us.” It should be “make AI work inside a frame we understand and accept.” The teams that succeed most with agents will probably be the ones that accept a simple truth: you can delegate a lot of code, a lot of repetition, and a lot of preparation. You do not delegate final responsibility. As long as that line stays clear, agents remain amplifiers. Once it blurs, they become just another source of complexity.
