The decisions that stay with your engineers

The useful question in an AI-native team is which decisions a person should make. Putting a person on every decision brings back the slow step you were trying to remove. Putting them on none produces a system whose design nobody chose.

We decide with one test, and then apply it to four specific areas.

The test: how expensive is it to undo

A decision belongs to a person when reversing it later is expensive, and can be delegated when a later change can replace it cheaply. That is the whole rule, and it is deliberately about cost rather than about importance, because importance is an argument and cost is a number you can estimate.

Choosing how a function is structured internally is cheap to undo: rewrite the function. Choosing how a value is stored across ten million rows is not: you need a migration, a backfill, a period where both shapes exist, and a rollback plan for each step. The second one gets a person even though the first one might look more like real engineering.

This test also explains why the split between human and delegated decisions moves over time. As a system gets more coupled, more decisions become expensive to reverse, and more of them need a human. A team that finds itself needing sign-off on everything usually has a coupling problem rather than a governance problem.

The four that reliably need a person

The data model. Field names, nullability, cardinality, where a value lives and which service owns it. Everything built on top depends on these, and the cost of changing one after data exists is measured in weeks. An agent will readily add a nullable column to solve today's ticket, and that column will be interpreted three different ways within a quarter.

Trust boundaries. Who is allowed to do what, where that is enforced, and which side of the boundary a piece of input arrives on. Permission logic is unusually easy to generate and unusually hard to review, because a plausible-looking check in the wrong place reads exactly like a correct one. This is also where the consequences are worst, since a permission mistake is often silent until it is public. Our post on why permissions are the hardest part of an AI feature covers the pattern.

Contracts other people depend on. Public API shapes, event payloads, file formats, anything a customer or another team has already integrated with. These are expensive to reverse because the cost is paid by people outside your team, on a timeline you do not set.

Anything that carries a migration. If undoing the change requires moving data, the decision is not an implementation detail regardless of how small the diff looks.

Everything else, including most of the code, can be delegated with checks. That is a larger share of the work than most leaders expect when they first make this split.

Why agents make these decisions invisibly

A human engineer proposing a new queue, a new table or a new service will usually say so, because they know it is a decision and they want others to agree with it first. An agent will do the same thing inside an implementation, describe it in one line of a summary, and move on. It is not hiding anything. It simply does not have a model of which choices your organisation considers reversible.

The practical consequence is that these decisions do not arrive labelled. They arrive as a diff. If your review process depends on someone noticing that line 340 introduced a second source of truth for customer status, you will catch it sometimes.

Two things help. The first is asking for the decision explicitly before the work: what are you going to store, where, and who owns it. The answer takes a minute to read and is the single highest-value minute in the process. The second is making the important boundaries visible in the codebase itself, so an automatic check detects when one is crossed, rather than someone having to notice. Directory boundaries, module ownership rules, and lint rules that forbid an import across a layer all turn an architectural rule into a failing check, which is the subject of the quality gates that should block a merge.

Write the decision down or it will be reversed

An unwritten architectural decision does not last long in an AI-native codebase. The next session has no memory of the discussion, sees code that could be simpler, and simplifies it. That is not a defect of the tool, it is the correct behaviour given the information available.

Short decision records fix this, and they need to be in the repository rather than in a wiki nobody has ever linked to from the code. Ours are a few lines: what was decided, what the alternatives were, why this one, and what would make us revisit it. The last clause matters more than it looks, because it tells a future reader whether the decision is still binding or whether the reason behind it has expired.

Two rules make records work rather than accumulate. Keep them next to what they constrain, so someone touching the code has a reason to encounter them. And keep the count low: a hundred decision records is a document nobody reads, while twelve that describe the real design of the system get read by every new engineer and every agent session that is given them to read.

The mechanics of writing this so both a person and a model can use it are in documentation an agent and a new hire can use.

Make the agent declare its decisions

There is a cheap technique that removes most of the invisibility problem, and it costs one extra step before the work.

Ask for the decisions before the implementation. What will you store, where, and which component owns it. What will this call, and what happens when that call fails. What are you assuming about who is allowed to do this. The answer is a short list, it takes a minute to read, and it arrives before any code exists, which is the only point where changing the plan costs nothing.

Two details make it work rather than becoming a formality. Ask for the alternatives that were rejected, because a list with no alternatives usually means the first plausible option was taken. And ask specifically what the change assumes about existing behaviour, since that is the category that produces the worst surprises: an implementation that is correct in isolation and wrong about the system it is joining.

For the mechanical parts of this, the plan-then-implement pattern is standard practice in agentic tools and Anthropic recommends it directly, separating research and planning from implementation to avoid solving the wrong problem [3]. The addition here is a leadership one: read the plan for the decisions in it, not for the steps.

Judgment is now the scarce input

There is a broader point behind all of this. When writing code was expensive, the scarce resource was people who could produce code. Now it is people who can tell a good decision from a plausible one, quickly, in a domain they understand.

DORA's 2025 report found 30 percent of nearly 5,000 respondents report little or no trust in AI-generated code, alongside 90 percent using it at work [1]. Stack Overflow's 2025 survey puts trust in accuracy lower still, with 45.7 percent distrusting AI accuracy against 32.7 percent trusting it [2]. Those numbers describe a workforce using a tool it does not fully trust, which is a reasonable position and also an argument for putting human judgment where it changes outcomes rather than spreading it across everything with little time for each.

Concentrating senior attention on the four areas above, and automating the rest, is what that looks like in practice. It is also why AI-native teams keep needing senior engineers: the work that remains is disproportionately the work that requires having seen the failure before.

There is a scheduling consequence worth planning for. If the same two people make every decision that is hard to reverse, they become a queue, and a queue on decisions is more damaging than a queue on review because it blocks work before it starts. Spread the ownership by domain, write down who decides what, and make the list visible, so an engineer with a data model question knows who to ask without escalating.

Where this connects

Decisions that stay human have to be enforced by something, or they are preferences. The enforcement is partly gates, partly the review policy in team shape and ownership, and partly the release process for the changes that carry the most risk, in progressive delivery for AI-written changes. The governance version of this question, for larger organisations with policy and audit requirements, is covered in enterprise AI coding governance. The main guide has the full picture.