Six engineering decisions to keep human with AI agents
See which engineering decisions stay human when a coding agent writes the code, how to sort them by reversibility and reach, and what the agent prepares.
Last verified against official docs on
Contents
A coding agent can take on more implementation when a person keeps the decisions. Six kinds stay human: product trade-offs, architecture, data integrity, security, business rules and anything you cannot undo. For those, the agent prepares options, evidence and a recommendation, and a named person decides and records the choice.
The sources quoted below were last verified on 11 October 2026, and nothing in this post was tested. This is part 25 of the series.
Implementation has an answer a test can check
An implementation task is work where the goal is already set and the result can be checked. “Return 404 when the order does not exist” is one: a test passes or fails. A wrong attempt costs a re-run.
A decision is a choice between options that each cost someone something. Nothing in the repository says which cost is acceptable. That answer comes from users, the business, a contract or the law, and somebody has to stand behind it later.
Anthropic’s Building effective agents explains why coding suits agents so well: “Code solutions are verifiable through automated tests” and “Output quality can be measured objectively”. The same section names the limit. “However, whereas automated testing helps verify functionality, human review remains crucial for ensuring solutions align with broader system requirements.”
Decisions hide inside implementation tasks
A made-up example: the task says “retry the payment call when the provider times out”. Writing the retry loop is implementation. How many retries, and whether a retry can charge a customer twice, are a business rule and a data question.
An agent that picks a number to finish the task has made a decision nobody asked it to make. The code compiles either way, and the tests pass either way, because no test exists for a rule nobody has decided. Part 16 covers keeping a change in scope.
Six kinds of engineering decision that stay with a person
In the working model below, six kinds of decision stay with a person, however much the agent is allowed to do. Each row has a made-up example:
| Decision kind | Made-up example | Why it stays human | What the agent prepares |
|---|---|---|---|
| Product trade-offs | Ship the export this sprint without PDF, or wait for it | The answer depends on users, deadlines and what was promised, and none of that is in the code | What each option changes, what it leaves out, and what adding the rest later would touch |
| Architecture | Add a message queue, or keep the call synchronous | It shapes every later change, and moving away is slow and expensive | Two or three designs, the modules each touches, and the existing decisions that limit them |
| Data integrity | Delete orphaned order rows, or archive them | Lost or corrupted data may not come back | A read-only count of the affected rows, the migration with its reverse step, and what cannot be reversed |
| Security | Let support staff read customer invoices | It decides who can reach what, and a mistake can stay invisible until someone uses it | The current access rules, who gains access, the abuse cases, and the tests that would prove the boundary |
| Business rules | Round tax per line or per invoice | The rule belongs to finance, legal or a customer contract, and a wrong guess looks like working code | Where the rule lives in the code today, the cases where the options differ, and questions for the rule’s owner |
| Irreversible consequences | Email every customer, or drop a column | There is no second try | A dry run, the exact scope, what would be lost, and the smallest reversible first step |
No standard sets this split, so adjust it for your team. A team may move a row, as long as someone owns that move and puts their name next to it.
Security has an outside source for its row. OWASP’s Excessive Agency entry in its Top 10 for LLM applications says to “require a human to approve high-impact actions before they are taken”. It also says to implement authorisation in downstream systems “rather than relying on an LLM to decide if an action is allowed or not”.
Two related topics have their own parts in this series: database migrations in Part 17 and API contracts in Part 18.
Three questions sort any decision: reversibility, reach and accountability
Three questions decide whether a choice needs a person: can it be undone, how far would a mistake travel, and who will answer for it?
How reversible is it?
Amazon’s 2015 letter to shareholders splits decisions by whether you can go back. Some are “consequential and irreversible or nearly irreversible”, which the letter calls one-way doors. Those “must be made methodically, carefully, slowly, with great deliberation and consultation.” Most decisions are two-way doors: “You can reopen the door and go back through.”
The letter also warns against the opposite mistake. Growing organisations, it says, seem to drift towards the heavy process for most decisions. Its verdict on that habit: “The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention.”
For a coding agent, that warning is the case for letting it make small, reversible calls on its own. A helper’s name, a loop’s shape and the inside of a private function behind passing tests are two-way doors. Reviewing each one like an architecture choice wastes the person you need for the real ones.
How far would a mistake travel?
Reach is how far a wrong choice spreads before anyone notices. It might stay in one function, or spread to one module, a public interface, shared data, customers or money. Part 6 calls the same idea the blast radius, for permissions.
A choice inside one module, covered by tests, stays small. A choice in a public API, a shared table or a payment path reaches people who never saw the diff.
Who answers for it?
Accountability means a named person can explain the choice later and owns what follows. A model can write the explanation, but it cannot be the person who answers for it.
GitHub builds some of that into Copilot. Its risks and mitigations page says Copilot cloud agent “cannot approve or merge a pull request”. The platform also “Prevents the user who asked Copilot cloud agent to create a pull request from approving it”. A pull request that “isn’t attributed to a person” needs one more approval by default. That applies when the repository already requires at least one.
Route the decision by the three answers
An example of how the three answers can route a decision, in the same working model:
| Can it be undone? | How far a mistake reaches | Who decides |
|---|---|---|
| Yes, cheaply | Inside one module, covered by tests | The agent, and it lists the choice in its report |
| Yes, with some work | Another module, a public interface or another team’s code | The agent recommends; the owner of that area approves |
| No, or not cheaply | Data, money, security or customers | A named person decides in writing, before the work starts |
When the answers point to different rows, the stricter row wins.
The agent prepares, a person decides, the record remembers
A decision brief is what the agent hands over: the options, the evidence for each, and one recommendation. “Do nothing” belongs in the options, so the change has something to be compared with. Evidence points at files, tests and measurements, and anything the agent could not check is marked unverified. The recommendation says what would change the agent’s mind.
Anthropic’s agent essay describes the moment for it. Agents “can then pause for human feedback at checkpoints or when encountering blockers.” A decision from the table is a checkpoint, even when the code would work either way.
The person then decides, and the choice gets a name and a date. Part 23 covers decision records the next agent session reads, so the same question does not come back next week. Releases have their own gates: Part 15 splits what the agent prepares from what a person authorises.
A decided rule can also become a test. Once someone settles “round tax per invoice”, a test can hold that rule, and the next change to tax rounding is implementation again.
More implementation goes to the agent when three things hold
Keeping decisions human leaves plenty of coding for the agent. It can take a bigger share when the system around it has three things:
- Boundaries the platform enforces, so a wrong step cannot reach far. Part 6 covers permissions, and Part 24 covers boundaries in the code.
- Outcomes it can measure: tests and gates that say pass or fail. Part 10 turns those into a definition of done.
- Accountable decision-making: an owner for each kind of decision, and a record of what was decided.
Part 6’s autonomy ladder runs from read-only to production changes. Each of those three things is a reason to move the agent up a rung for implementation work. The rows of the decision table stay with a person at every rung. Higher up, the agent does more of the preparation, such as read-only queries and dry runs.
Two prompts: prepare a decision, and stop at one
Neither prompt relies on a tool-specific feature.
Prompt 1: prepare a decision brief
An example prompt for when you know a decision is coming and want it laid out before anyone writes code.
Task: prepare a decision brief for <the decision, for example "archive
or delete orphaned order rows">.
Do not implement anything. Read only the code, tests, docs and decision
records this decision needs.
Report:
1. The decision in one sentence, and its kind: product trade-off,
architecture, data integrity, security, business rule or
irreversible consequence.
2. Two or three options, plus "do nothing".
3. For each option: what changes in the code, what it costs, what it
leaves out, and the evidence, with file and line.
4. Reversibility: can each option be undone, how, and what would be lost.
5. Reach: which modules, interfaces, data, users or money a mistake
would affect.
6. Existing decision records or rules this decision touches.
7. Your recommendation, how confident you are, and what would change it.
8. Who should decide, if the code or docs name an owner.
Mark anything you could not verify as unverified.
Do not edit files. Never print, expose or commit secret values.
Do not commit, push, deploy, run destructive commands or make external
changes unless I explicitly authorise it.
If two reasonable attempts fail, stop and report the failure rather
than repeatedly guessing.The brief goes to whoever owns that kind of decision, and their answer goes into the decision record.
Prompt 2: stop at a hidden decision
An example prompt to add to an ordinary implementation task, so the agent stops at a hidden decision.
Task: <describe the implementation task>
Implement the task within its stated scope. Make small, reversible
choices yourself, such as names and the internal structure of private
code covered by tests, and list them in your final report.
Stop and ask before you choose anything in these areas:
- product behaviour users will notice that the task does not specify
- architecture: a new service, queue, framework, dependency or module
boundary
- data: deleting, rewriting or migrating stored data
- security: authentication, authorisation, secrets, who can reach what
- business rules: amounts, rounding, limits, dates, eligibility
- anything that cannot be undone, such as external messages or
dropped columns
When you stop, give the options, the evidence for each and your
recommendation. Do not pick one to finish the task.
Never print, expose or commit secret values.
Do not commit, push, deploy, run destructive commands or make external
changes unless I explicitly authorise it.
If two reasonable attempts fail, stop and report the failure rather
than repeatedly guessing.If you add it to every task, the stop list belongs in your rules file.
Quick answers
Which engineering decisions should a human make when using AI coding agents?
Engineering decisions about product trade-offs, architecture, data integrity, security, business rules and irreversible actions should stay with a named person. A coding agent can still prepare the options, the evidence and a recommendation for each one.
Can an AI coding agent make architecture decisions?
An AI coding agent can draft architecture options and compare their trade-offs, but the choice shapes every later change and is slow to reverse. A person who owns the system should make it and record it, for example in an architecture decision record.
What is a one-way door decision?
A one-way door decision, in Amazon’s 2015 shareholder letter, is one that is consequential and irreversible or nearly irreversible. The letter says such decisions need deliberation and consultation, while reversible two-way door decisions should be made quickly.
What should an AI coding agent prepare before a human decides?
An AI coding agent should prepare a decision brief. It lists the options, including doing nothing, with evidence and file references for each. It says how reversible each option is and how far a mistake would reach, then gives a recommendation with its confidence.
Does keeping humans in charge of decisions slow down AI-assisted development?
Keeping humans in charge of decisions slows development down when every small choice gets a review. Letting the agent make reversible, low-reach choices on its own, and saving people for one-way doors, aims to avoid that delay.
More on AI coding is in the AI category.
Kousigan A
Build with AI. Ship with care.
Software engineer building real products with AI assistants. I write down what works: prompts, rules, skills and agents, and how to ship safely.