Coding agents can now write most of the code. The decisions that determine whether that code is defensible still need an owner.
The tests passed, and nobody could say why the split was right
Consider a clinical risk-modeling team extending its validation pipeline. The model predicts thirty-day unplanned readmission. The team’s aim is to estimate how it will perform on patients it has not seen before. The implementation request is specific: add a held-out test set, report AUROC, and keep the report format. It does not translate that aim into a patient-grouping rule or say who owns the validation design.
The agent reads the repository, finds the feature builder and evaluation module, writes a stratified random split, adds the metric, and updates the report. The tests pass. The pull request is 214 lines and reads cleanly.
Two weeks later, a statistician reviewing the draft manuscript asks why encounters from the same patient can appear on both sides of the split. The cohort is encounter-level; a patient with four admissions can contribute training and test rows. Nobody can say, without opening a transcript, whether that was deliberate. The validation design belonged to the domain lead and the statistician, but neither had been asked to accept it.
The agent’s split was not absurd. Stratified random splitting is standard for tabular models, and preserving the positive rate is a reasonable instinct. That is what makes it hard to catch: the agent produced a conventional implementation where convention did not apply.
Part of the problem is technical. Row-level splitting leaks information across a patient’s encounters, so reported performance can look better than it will on a new patient. TRIPOD+AI’s glossary says evaluation data should have no participant overlap with training data and should represent the intended-use population (Collins et al., 2024). The larger part is procedural. A decision that determines what the reported number means was made inside an implementation task, reviewed as code, and accepted because the tests were green.
Patient-level separation is not a universal rule; it follows from the intended-use population. If the goal had been the next encounter for a patient already in the data, a temporal split by encounter date might have been defensible. But no one wrote that rule into the request, accepted the validation design, or recorded the rationale. A test asserting that the two sides share no patient would have failed.
The case is invented, but the failure pattern is ordinary: a consequential scientific choice was silently converted into an implementation detail.
Delegation is not one decision
Agent autonomy is usually treated as a single dial: more freedom or less. Three separate things get delegated in that turn, and they fail in different ways.
Exploration is who generates alternatives. An agent can read the repository, compare resampling strategies, and run each against a scratch dataset. Delegating this is cheap and usually valuable, because the alternative is one person’s memory of what worked last time. Authority is who accepts a tradeoff the project will later have to defend; that commitment outlives the session. Execution is who writes and runs code inside settled constraints.
The three can be allocated independently. An agent might have wide freedom to explore and implement while the team keeps authority over a short list: intended-use population, unit of analysis, validation design, public interface, dependency policy. That lets a team move quickly where being wrong is cheap.
An agent can propose the best design in the room; authority means the team understands the tradeoff well enough to adopt it. Other domains need different controls, but the same question applies wherever a decision changes domain meaning, external commitments, security exposure, or coupling that outlives the task.
Prompt length is a poor proxy for delegated authority. A nine-word instruction pointing at docs/decisions/0007-cohort.md can carry more constraint than a page of imperatives. What matters is whether the constraint is durable, discoverable in the repository, and owned by someone who can defend it.
Anthropic’s current guidance separates instructions the model decides how to follow from rules the harness enforces deterministically through hooks, deny rules, or CI (Claude Code best practices, retrieved October 2026). Most instructions belong in the first category; the second is for rules with no exceptions. A hook can block a path or force a check; it cannot decide whether the check asserts the right property. The decision about what must hold is portable even when the enforcement mechanism is not.
Once validation design is a decision requiring consent, the important test is whether that consent reflects understanding.
Approval only matters when the reviewer can challenge the decision
An engineer can sign off on generated code without being able to explain its design assumptions. The signature is real; the control is not. Operative control is the capacity to have said no for a reason; organizations assume it came with the name.
An accountable decision needs three things: authority to accept or reject it, a rationale recoverable later that states what was decided and why, and enough competence to challenge it. A named approver is not yet a competent reviewer, and a recorded rationale is not yet evidence that anyone understood the decision.
A blunt check: ask what evidence would have changed the reviewer’s mind. If nothing could have, the review was a ceremony. In the opening case, the reviewer would identify the intended-use population, inspect the split key, check whether the split respects that population, and record the acceptance criterion: no patient on both sides. The test confirms the split enforces the rule. It cannot establish that the rule is the right one; that judgment comes from the intended use and the validation design, and the record should carry the reason. If the reviewer cannot explain why patient-level separation follows from the intended use, the review is not finished.
High-stakes choices may require a domain lead or an independent statistician. Putting a name on the gate does not supply the competence to evaluate the proposal.
Automation bias research offers a precedent: clinicians often accept automated recommendations with less scrutiny than the situation warrants (Goddard et al., 2012).
Agent-to-agent review can make the gap harder to see. A second agent checks conformance to the request; if the request encoded a bad assumption, it confirms the code matches it, and the assumption ends up two agents deep with nobody owning it.
The problem starts one level earlier. Where the specification is silent, the agent reaches for a familiar implementation. Nothing in the repository said the unit of analysis mattered, so it chose a row-level split. Passing tests certify the beliefs that were formalized, not the ones that were not.
Review gates belong where the frame can change: generalization target, cohort construction, validation design, security boundaries, risk assumptions, data contracts, behavior outside parties rely on. Human direction there does not guarantee a correct answer. It establishes that someone with standing made the call and can be asked later.
A decision that can be defended today also has to remain legible after the agent or reviewer changes.
The project has to outlive its agent
Months after the opening case, a second model or harness is asked to extend the same evaluation pipeline. It cannot see the first agent’s conversation. Its reliable references are the decision record, the cohort definition, and the test that enforces patient isolation. Without them, the new agent has to infer the rule from code that happens to be there.
Models get deprecated. Harnesses change defaults and review behavior. A team that built its conventions inside one agent’s conversation history has put its architectural memory somewhere that expires.
Durable artifacts are the countermeasure. Decision records, invariants, and tests move a decision out of a conversation and into the repository. A decision record can be short: what was decided, why, and when to revisit. In the opening case, it would say the intended-use population is patients not seen in training, the grouping key is patient ID, evaluation rows must not share a patient with training rows, and the test asserts disjoint patient sets. A second agent can read that and run the test.
OpenAI’s account of building a product with no manually written code is the strongest version of this argument. They treat repository knowledge as the system of record, keep architecture docs and execution plans with decision logs in the repository, and enforce dependency directions with custom linters (OpenAI, 2026). Humans steer and agents execute. The constraints were explicit enough to enforce without a conversation. They are candid that they do not yet know how architectural coherence evolves over years, which argues for keeping the record durable.
What matters is that the next developer or agent can continue the work under the same rules.
A durable record preserves the rationale. It does not teach someone how to evaluate it.
Someone has to learn to say no
The reviewer in the opening scene had to know that patient-level splitting is a different question from row-level splitting. That knowledge is not free, evenly distributed, or acquired by watching an agent work. Judgment develops through making decisions with feedback, living with the consequences, and revising.
The concern is not that agents make juniors worse. A workflow can remove the repetitions through which judgment forms. If every consequential choice is routed to a senior or an agent, a junior gets the output without the decision. The output improves, but the junior has not practiced the decision.
A randomized study gives the concern a bound. Fifty-two developers new to the Trio library learned it with or without an AI assistant. On an immediate quiz, the AI group averaged about 50% and the hand-coding group about 67%, with no significant time advantage. Participants who delegated heavily averaged below 40%. In the same study, participants who generated code and then asked follow-up questions retained more of the material (Shen & Tamkin, 2026).
The limits are clear: one short task, an assistant rather than an agent, an immediate assessment. It does not show that agent use erodes senior expertise over a career. It does suggest that interaction style shapes short-term learning.
Juniors will still learn from the work. The risk is that the workflow gives them fewer chances to practice the decisions they will later be responsible for reviewing.
The interventions are ordinary. Ask a junior engineer to propose two validation designs and defend one before an agent implements anything. Have them write the decision record and test strategy first, then compare the implementation against their reasoning: state the intended-use population, choose the grouping key, and write the test that fails on patient overlap. Give them progressively more consequential decisions, with a senior as backstop and mentor.
When implementation gets cheaper, teams can redirect some of that time toward deliberate practice. The agent can draft the implementation while the junior does the design work. Assign the design conversation deliberately rather than letting it disappear into implementation.
Those review and learning costs are largely invisible in a benchmark that ends when a task passes.
A passing build is a weak measurement
Suppose two teams use different delegation policies on the same clinical pipeline. One keeps authority over the validation design with the domain lead and statistician. The other lets the agent choose the split and reviews the result. Both produce a passing pipeline, one in an afternoon and one in two days. Which has produced a workflow the team can defend and extend next quarter?
Ordinary coding evaluations cannot answer that. They measure time to a passing artifact, not who accepted the design or what the next change will cost. Productivity estimates vary by context: a controlled experiment with GitHub Copilot found developers completed a JavaScript HTTP-server task 55.8% faster with the assistant (Peng et al., 2023), while METR randomized 246 real issues across sixteen experienced developers and found a 19% increase in completion time (Becker et al., 2025). Neither study assigns design authority. Both results can be true; they differ in task, repository, and tool generation.
The lifecycle question is different. Consider a bookkeeping identity for the cost of a change:
$$ C_{\text{lifecycle}} = C_{\text{design}} + C_{\text{implementation}} + C_{\text{review}} + \mathbb{E}\left[C_{\text{future change}}\right] $$The first three terms are paid now: design time, the agent’s implementation plus prompting and waiting, and human review. The last term is an expectation: future changes weighted by how likely they are and by how much the original decision raises their cost. The identity is a budget, not an estimate: its terms need the same units, and the future term is not observed.
Benchmarks that stop at merge leave the last term out of the accounting. That is defensible for a benchmark and misleading for a team. A design that saves an hour today and adds two hours to every later change wins the first three terms and loses the fourth. Review and future changes are harder to observe, so they are the terms most likely to be missing. The same accounting leaves out goals that do not reduce to cost, such as whether the work teaches the team something.
A fair comparison would hold task, model, harness, supplied information, and human-effort accounting fixed, randomize who holds design authority, and measure past the merge. It would measure design time, implementation time, review time, comprehension, follow-on changes, and handoff.
I looked for that study and did not find one. The closest study measures something else: Patel and colleagues found that four frontier agents resolved downstream tasks less reliably on agent-written code, with drops up to 13.1% across benchmarks. Many traditional maintainability metrics did not explain the gap; changes to input validation and error handling were among the clearest signals (Patel et al., 2026). That compares authorship, not design authority. The existing comparisons set AI against no AI, or agent-written against human-written code; neither manipulates who chooses the architecture. Until that experiment exists, the case for human-directed design rests on accountability requirements, observed failure modes, and continuity, not on a measured lifecycle advantage. The hypothesis is plausible and untested.
The missing evidence does not prevent teams from assigning review authority explicitly and testing whether it works.
A division of labor that survives review
The workflow is small enough to adopt on a Monday. Write down the goal and the conditions under which the result counts as correct. Mark the decisions that change domain meaning, risk, interfaces, or dependencies; those need an owner before implementation starts. Let the agent explore where exploration is cheap. Record who accepted the tradeoff and why, then verify behavior independently.
The allocation below is a starting heuristic.
| Decision | Who accepts it | What the agent may do | Why the gate exists |
|---|---|---|---|
| Intended-use population, cohort, unit of analysis, validation design | Domain lead with a statistician | Propose and critique alternatives | Changes what the result means |
| Public interfaces, module boundaries, dependency policy | Technical lead | Explore options; implement the accepted contract | Creates coupling that outlives the task |
| Internal implementation under a fixed contract | Agent | Broad freedom, including implementation and auxiliary tests | Reversible and locally checkable |
| Critical assertions, docs, and data contracts | Shared, with a human sign-off | Draft tests and docs; implement accepted checks | A passing test only proves what it asserts |
The request is short because most of the constraint lives in the repository.
|
|
The request points at a decision record, grants freedom where it is safe, and includes a stop condition.
If an agent proposes a design the team would not have reached, authority means understanding why it is better and accepting it. The reviewer still has to evaluate it; if nobody can, the answer is a domain expert, not a signature.
Constraint has a cost. Upfront specifications can be wrong, and a rigid architecture can freeze a bad decision. Progressive commitment is the mitigation: explore widely while uncertainty is high, formalize when reversal gets expensive, and revisit when conditions change. A throwaway script and a clinical pipeline need different ceremony.
Review effort should follow consequence, uncertainty, reversibility, and independent verifiability rather than diff size. A large mechanical refactor behind a stable interface can be checked by tests, types, and a diff read. A twelve-line change to the cohort filter can alter who is in the evaluation set and what the reported number means. The second deserves more scrutiny even though it is smaller. In the opening case, the question is whether the grouping key matches the intended-use population, whether a patient crosses the boundary, and whether a test would catch it. When a consequential contract is ambiguous, the agent should stop and escalate rather than choose a default.
The reviewer’s question is the one to design for
Return to the statistician at the manuscript review. The team does not need to have written every line of the pipeline. It needs to answer why the split was right for the question, in a form that does not depend on replaying a compacted session.
With the workflow in place, the answer is visible. The team can point to a decision record that names the intended-use population, the grouping rule, the reason, and the condition for revisiting it. It can run a test that fails when a patient appears on both sides. The test shows the rule is enforced; the record shows why it was chosen. It can name the statistician who accepted the rule and the reviewer who checked the implementation. If a new model or developer takes over, the same record and test are the handoff.
None of that makes the decision correct. A reviewer can still be wrong, and a record can still go stale. The difference is that the error is inspectable: someone can find the assumption, compare it with the intended use, and revise it.
Better agents are genuinely better at exploring, implementing, and testing. Keeping design authority directs any saved effort toward the decisions that determine whether the work is worth doing, the learning that makes those decisions possible, and the people who will make them after these models are gone.
The code can be generated. The reason for it still has to survive review.
References
- Collins, G. S., Moons, K. G. M., Dhiman, P., et al. (2024). TRIPOD+AI statement: updated guidance for reporting clinical prediction models that use regression or machine learning methods. BMJ, 385, e078378.
- Patel, S. P., Hou, B. L., Purohit, A., Xu, K., Pan, J., He, H., & Chen, V. (2026). Is Agent Code Less Maintainable Than Human Code?. EMNLP 2026.
- Shen, J. H., & Tamkin, A. (2026). How AI Impacts Skill Formation. arXiv:2601.20245.
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590.
- Becker, J., Rush, N., Barnes, B., & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR.
- Goddard, K., Roudsari, A., & Wyatt, J. C. (2012). Automation bias: a systematic review of frequency, effect mediators, and mitigators. JAMIA, 19(1), 121-127.
- OpenAI (2026). Harness engineering: leveraging Codex in an agent-first world. February 11.
- Anthropic (2026). Best practices for Claude Code. Retrieved October 31, 2026.