When Agents Write the Code: What Remains Engineering

Start by examining the premise. The proportion of machine-written code tells us little about how much engineering has been automated. An agent can generate almost every character of a change while a person defines the problem, identifies the constraints, chooses the checks and authorizes the release. Alternatively, a person may type the final few lines after delegating most substantive decisions. The same AI-code percentage can describe very different divisions of work.

In my State of AI4SDLC talks, I have consistently moved from adoption metrics toward outcome metrics. Accepted suggestions, requests and lines of code describe tool activity. What matters to a team is whether useful changes move through the entire process faster, and what happens to quality, rework and verification cost. This position connects the HighLoad++ talk and the IT Picnic edition.

The first change is how we delegate. An assistant suggested the next fragment; a person assembled the solution. An agent receives a larger unit of work: investigate a repository, propose a plan, modify several components, run checks and correct failures. As that unit grows, its boundaries matter more. What is known? What may change? What counts as completion? When should execution stop?

Cheaper implementation offers more than a faster version of the existing backlog. It can make an experiment worthwhile when nobody previously had a week to spare. A team can build a temporary analysis tool, compare migration strategies or add diagnostics before an incident. Value may come from expanding the available options even when a familiar task gets only slightly faster. The thing to verify is the additional benefit, not the number of artifacts produced.

A useful unit is the engineering episode: the initial problem, context, actions, checks and observed outcome. In one episode the agent writes code. In another it establishes that no code change is needed. In a third it discovers a mistaken requirement. A good system should accept all three outcomes when they actually address the problem. I develop this approach in my article on agent evaluation.

Consider a hypothetical example: a customer reports a duplicate charge. A literal request to prevent repeated button clicks can produce a flawless button while leaving the server-side failure intact. An engineering episode starts earlier: which event is repeated, who retries delivery, and where must the monetary effect be limited to one occurrence? The most valuable contribution may be correcting the problem model before writing a line.

A strong objection is that a good agent can also clarify the task, discover repeated delivery and propose the right model. I agree. The argument must not depend on machines being permanently unable to reason. The question then moves outward: who set the objective, who has authority to change the service's behavior, and which external observations will establish that the solution helped? More of this can be automated, but the questions do not disappear with manual typing.

What matters is the size of the task we can delegate with a verifiable outcome, not the percentage of its code written by AI.

In my positions for Deep Tech Night, my main answer is verification and acceptance. Our ability to produce changes has grown faster than our ability to establish their usefulness and safety. When more work enters the system, queues appear where it cannot be accepted quickly enough: review, testing, integration or release.

This is an operational hypothesis to test against a particular team's flow. It would be a mistake to turn it into a universal law. A young company's constraint may be finding a customer; a research product's may be experimental quality; an old system's may be access to a test environment. Verification in a broad sense appears everywhere, but broadening the word must not obscure the need to identify a concrete queue and its owner.

Cheaper code exposes two different scarcities. Before implementation, someone must decide which change is worth making. After implementation, someone must establish that it works, respects commitments and deserves ongoing maintenance. The first governs demand for development. The second governs the capacity to accept its output. Improving generation alone can worsen both by launching too many initiatives and overwhelming verification.

Here is an illustration, not company data. A team can review and release eight comparable changes a week. It used to prepare ten; agents now prepare thirty. With unchanged capacity elsewhere, sustainable release throughput will not become thirty. Work in progress accumulates, changes age, conflicts multiply and recovering context becomes expensive. The precise dynamics depend on task sizes and variability, but adding capacity upstream of a saturated queue does not itself drain it.

The practical implication is that limiting agent concurrency and shrinking changes can be more useful than adding five more executors. My AI-native SDLC discussion connects this to review capacity and to turning incidents into checks. Parallel execution must be matched by the ability to integrate its results.

In my article on AI economics, I propose cost per accepted task. As a management model:

Cost per accepted task = total workflow costs over a period / accepted comparable tasks.

The numerator includes models, tools, infrastructure, human time and rework, including unsuccessful attempts. Expected losses from errors are useful as a separate risk estimate, avoiding confusion with accounting expenditure or counting the same loss twice. The denominator requires comparability and acceptance defined in advance: splitting one task into ten must not manufacture a tenfold efficiency gain.

Even this metric does not establish product value. A team can cheaply accept unnecessary features. Two views are needed: the engineering view asks whether the change reached a working state at acceptable quality; the product view asks whether it improved the outcome that justified the work. For infrastructure tasks, the benefit may be lower risk or future cost rather than immediate revenue.

The objection that someone personally became ten times faster may be entirely valid, especially on familiar, local and easily checked tasks. It answers a different question from product-level throughput. Rather than dismiss that experience, I would trace where the saved time went: more validated hypotheses, faster releases, fewer late nights or a larger queue.

When producing options gets cheaper, choosing well and declining unnecessary work become more valuable.

A working model of a shifting queue; identify the actual constraint in your own team.

It helps to separate two layers of architecture. One is implementation structure that is relatively easy to rewrite. The other is commitments: data models, public contracts, access boundaries, failure behavior, compatibility and the accumulated history of decisions. Agents can lower the cost of changing the first layer. That does not make changes to the second equally cheap.

If a module can be rewritten quickly, some local decisions no longer deserve days of approval. This favors shorter experiments and less architectural ceremony where mistakes are reversible. But rewriting code quickly is insufficient to migrate data without loss, move external consumers to a new contract or undo an action that has already taken effect.

My central point in AI for Software Architecture is that a model often receives a snapshot while architecture exists as a history. Code shows how a solution works. It is less likely to reveal why an alternative was rejected, which constraint was temporary or which incident created the current boundary.

This is not a permanent AI limitation. An agent with access to decisions, tests, change history and operational data can reconstruct much more. However, the availability of those connections is a property of the engineering environment. An obligation recorded nowhere does not become available just because the model has a larger context window.

Return to the hypothetical payment example. An agent neatly adds retries after a network timeout. Locally this seems reasonable: fewer requests end in an error. The architectural question is whether the payment provider could have completed the operation before the timeout. A retry may then create a second monetary effect. The boundary must define the operation key, result storage, behavior under an uncertain response and reconciliation with the external system. A successful HTTP-client unit test establishes none of this.

With several agents, architecture also coordinates work. Isolated branches protect files from simultaneous edits; they do not protect meanings from incompatibility. One agent treats an order as complete when it is created; another only after payment. Both pass their own tests. A shared state model and integration contract can expose the conflict before changes are merged.

My practical conclusion is to design for fast, independent verification of local changes: explicit contracts, understandable module boundaries, dependency constraints, migration checks and observability. Some rules should be executable. Others will remain explanations of reasons and trade-offs. A requirement does not cease to matter because there is no sensible automated test for it.

The objection that a stronger model might choose boundaries better than an architect can be true in a particular case. Compare the alternatives and check their consequences. That supports automating architectural work; it does not make architectural properties unnecessary. The aim is not to defend a diagram-drawing position but to preserve the system's ability to change without unacceptable consequences.

The cost of rewriting code is falling faster than the cost of breaking a contract with the outside world.

If a person's only contribution is copying terminal output into a chat and clicking Continue, that participation has questionable value. Reliable, repeatable checks should be automated. Engineers need not watch every iteration to preserve their place in the process.

First distinguish two loops. The inner loop makes a change, runs a check and fixes a failure. The outer loop asks why the change is needed, what correctness means, which consequences are acceptable and how the result relates to actual product behavior. The inner loop can be deeply automated. Parts of the outer loop can also be delegated, but they need independent grounds for evaluation.

The problem with self-checking is not that an agent should be forbidden to write tests. It can write a good test and discover its own mistake. The problem is shared blind spots. If the task omitted a constraint, implementation and tests can faithfully reproduce the same wrong model. Asking the model to switch from developer to tester does not guarantee independence.

In the payment example, the agent implements retries and tests that a retry follows an error. The test confirms the chosen mechanism but says nothing about whether a duplicate charge is permissible. Independence comes from a different foundation: a preserved contract, an uncertain-response scenario, a model of the provider or a property limiting the monetary effect. The evaluator may be human, software or another agent; what matters is what enables it to disprove the solution.

My replayable-episode model records the initial state, task, tools, actions and checkable outcome. Not every check should be hidden from the executor: open tests provide useful feedback. But some independent evaluation is necessary to distinguish fitting a known test set from a more general ability to solve tasks.

In today's process, people still resolve substantial ambiguity, choose success criteria, settle conflicting goals, define authority and examine the quality of the control system itself. We should not turn still into never automatable. A new model may bring some of this inside the agent. Revisiting the division of work is normal.

Human participation should nevertheless add demonstrable value. A confirmation that receives half a second of attention and almost always the same response often provides little substantive control. Important decisions require an intelligible question, context, evidence and the ability to refuse. Otherwise, we retain accountability on paper without preserving the ability to exercise it.

Learning is a special case. A senior engineer can delegate a familiar inner loop and retain understanding. A beginner may need to complete that loop to develop understanding in the first place. Production work and a learning episode can therefore require different degrees of autonomy even for the same technical task. They aim at different outcomes.

Remove people from repeatable actions as reliable verification becomes available. Human presence and effective control are not interchangeable.

I would reject the choice of a single artifact. Each form of review answers a different question. None covers the entire path from intent to consequences on its own.

The connections between artifacts will matter more. A requirement should point to the check that supports it. A change should identify affected contracts. Results should reveal what was actually tested and what remains outside observation. A release plan should explain how consequences will be contained if the team is wrong.

In practice, this could be a compact acceptance package: the original problem, significant decisions, affected boundaries, check results, known limitations and a way to observe the effect. This is a proposed form of acceptance, not a demand for another long document. If the package is harder to inspect than the code, we have created another queue.

In When Code Became Cheap, I contrasted reading a diff with proving the result. That wording needs precision: ordinary tests and observations provide evidence of correctness within the area examined. They are not mathematical proof that no errors exist. Formal methods can establish some properties, but the formalized requirement and its assumptions must still be checked.

Reading code will remain valuable where it exposes what tests omit: excessive permissions, a dangerous dependency, hidden query cost or a broken module boundary. A small, conventional change may need less manual reading. A change to the authorization or data model may need more. Alongside individual reviews, sample-based inspection should check whether the overall process is degrading.

Specifications can also be wrong. If we formalize a requirement to repeat a payment until it succeeds, an agent can implement the mistake perfectly. Evaluating the outcome means returning to the objective: neither the customer nor the ledger should experience a duplicate monetary effect. Moving review earlier is useful, but it cannot promise to eliminate uncertainty before coding begins.

There is a further technical constraint: the tested artifact must match the released artifact. If an agent edits code, changes a dependency or adjusts the build after testing, the earlier results no longer provide the same grounds for release. Checks need to be tied to a specific version, and authority to change the checks must be controlled separately.

Review the justification for a change, from why it is needed to what it actually did. Code remains one important source of evidence.

First, my published position needs to be represented accurately. In the article dated September 5, I allowed agents to work independently in a branch and prepare checks, while a person approved production release. The production access described there was read-only. This was the practical boundary in that article, not a claim that automated release is technically impossible. Source: the Deep Tech Night trust ladder.

In the AI-native SDLC discussion, the boundary is framed in terms of risk that has not been delegated. Before release, authority, constraints, service state, rollback and ownership must be checked. The agent does not acquire permission to remove those conditions merely because it considers its work complete. Source: the playbook discussion.

The following is a condition for potentially revising that position, not a retelling of the earlier statement. A universal rule that agents must never release is difficult to defend if a limited class of changes already has sufficiently reliable automated admission. The useful question is which conditions would allow individual human confirmation to be removed while retaining substantive control.

The ability to execute a deployment command, permission to execute it and permission to change the admission rules are different things. An agent can prepare an artifact and request release. An independent policy decides whether that particular action is allowed. Changing the policy requires a separate decision. The agent's intelligence should not be the only barrier between a proposal and unlimited authority.

I propose the following working matrix. It is a design heuristic to calibrate against the particular system.

Reversibility must describe consequences. Restoring an older program version does not recall an email, recover disclosed information or reverse an executed payment. A dropped column may be recoverable from backup, but new writes may have occurred since the backup. A rollback button alone does not establish the safety of an autonomous action.

Detection speed is another constraint. Automated rollback helps when degradation becomes visible before its effects are unacceptable. If a fault emerges after a month, minutes-to-rollback tells us little about protection. Conversely, a person who approved release without substantive inspection does not solve this problem either.

A strong objection is that humans make mistakes too, so why hold agents to a higher standard? The comparison should be fair: people and agents on comparable tasks in the same environment, accounting for quality and consequences. Automation can, however, increase the scale at which one error repeats. A mistaken shared instruction may affect many changes. We therefore need more than average success rates: common causes of failure, impact scope and the ability to stop the flow matter.

My condition for revising the September boundary is a series of comparable episodes showing that automated admission for a particular change class gives an acceptable outcome at lower coordination cost. This requires observable failures, tested recovery and protected rules. One successful demonstration is insufficient. Keeping manual approval indefinitely after that evidence exists would also be inertia.

In my current working model, a person approves release. That boundary can be reconsidered by change class when we can show what replaces substantive human control.

Partly. It is worth answering that question directly. Today's model limitations can inspire elaborate infrastructure that looks fundamental until the next model learns to do the same work unaided.

My article on the co-evolving AI development stack contains two complementary ideas. A harness provides the protocol through which an agent works with the world. At the same time, much of its design reflects the temporary weaknesses of a particular model. We need to be able to simplify that architecture as well as expand it.

A harness is the execution environment: the work loop, tools, state, constraints and feedback. Context engineering selects and delivers information needed for the current decision. Skills package reusable procedures and resources for a task class. Memory preserves knowledge intended to influence future work. Each layer mixes temporary workarounds with enduring functions.

A vendor may build an enduring function into its product, removing the need for our own implementation. That also counts as a layer disappearing from our code. The need itself, such as obtaining the current service contract, remains. A model cannot know a decision the team made today unless it reaches an accessible source.

A useful external example is Cursor's engineering post from April 30, 2026. The team describes removing earlier rigid guidance and static context as models improved, shifting toward retrieving information during work. This is a vendor account, not independent evidence of universal superiority. It supports a narrower point: useful harnesses change with their models, and some formerly useful mechanisms are genuinely removed.

In Anthropic's experience with long-running tasks, preserving progress and structuring transitions between sessions addressed specific agent problems. This is a reason to study the mechanism, not to declare a particular file format permanent.

I am especially wary of memory that promotes every earlier answer into a rule. If an agent records a mistaken hypothesis and confidently reuses it, memory scales the error. A good entry needs a source, an applicability boundary and conditions for reconsideration. Sometimes the right action is to forget the instruction and check the fact again.

A practical defense against overengineering is an ablation comparison. Take representative episodes and compare the current model with the complete harness, a simpler harness and a new model with minimal adaptation. Measure accepted outcomes, failures, interventions and full cost. Reconsider or remove rules that no longer improve anything. The number of skills is not a measure of maturity.

In my Deep Tech Night talk, this leads to a strategic distinction: often buy rapidly changing general capabilities, adapt integration and retain control over outcome criteria and authority. This is a decision heuristic, not a ban on building a harness when its advantage can be measured.

The durable investment is in verification and controlled action. Today's folder of skills is not automatically a durable asset.

The premise deserves a challenge: code remains important learning material. Getting a solution quickly does not make causality, state, types, algorithms or debugging irrelevant. What changes is the relationship between code produced and skill acquired. A finished project increasingly provides weak evidence that its author can independently understand the next problem.

In The Junior Engineer After Code, I make exactly this distinction: agents accelerate a first result without turning a beginner into a mid-level engineer. Growth appears in the unit of responsibility a person can reliably own. Can they explain a decision, identify an error in their assumptions, check consequences and transfer understanding to a modified task?

There is a small but direct experimental signal. In Anthropic's study published January 29, 2026, 52 mostly junior engineers learned the unfamiliar Trio library. The AI group averaged 50% on an immediate quiz, versus 67% without AI; the time advantage was not statistically significant. That is a 17-percentage-point difference on a particular test. The study does not measure careers a year later or establish that every form of AI-assisted learning is worse.

The problem arises when completing the assignment quickly becomes the sole objective. The pauses most valuable for learning—forming a hypothesis, reading an exception, comparing expected and observed behavior—can be bypassed with a request to fix it. The assignment finishes, but the person may not construct a model useful next time. An elegant explanation from the agent cannot replace that model if the learner cannot use it.

Here is a proposed learning sequence. It develops my apprenticeship model; it is not a description of a program already deployed.

1. State the expectation. Before running the program, explain what should happen and why.

2. Obtain a solution. Use the agent within the learning objective: a hint, explanation or implementation.

3. Find a boundary. Suggest a case where the solution may behave differently.

4. Test the explanation. Change a condition, predict its effect and compare it with execution.

5. Transfer understanding. Solve a small extension that cannot be completed by replaying the previous conversation.

The hypothetical payment retry is also a useful learning exercise. The beginner need not write every HTTP wrapper manually. But they should explain why a timeout does not reveal whether an operation happened, which states the client distinguishes and what a retry does. Then introduce two parallel requests with the same key. If the previous explanation does not transfer, that identifies the next learning objective.

For a programming school, the assessment target changes. A polished homework project is a weak standalone signal. Explanations of causes, controlled breakages, modified requirements and an observable problem-solving process become important. On some exercises, limiting AI assistance is justified by the learning objective. On others, working with an agent is itself the skill. A universal ban or universal permission misses that difference.

For an employer, the economics change. If useful entry-level work is automated, funding apprenticeship from its margin may become harder. That does not make reproducing expertise unnecessary. Mentoring, bounded real tasks and time for explanation need explicit accounting. People should gain progressively wider responsibility rather than remain permanent checkers of someone else's answers.

It is dangerous to promise either that AI will eliminate every entry-level role or that job numbers will remain unchanged. Product demand, capital costs, team design and the limits of automation all matter. My narrower forecast is that polished artifacts will distinguish beginners from experienced engineers less, and demonstrated independence will distinguish them more. That is a prediction about competence signals, not a numerical labor-market estimate.

The objection that we should not teach what machines already do requires separating production from understanding. Much manual routine can go. But while people are assigned verification and accountability, they need practice that enables them to notice a mistaken problem model. If that responsibility changes in the future, curricula should change too. We cannot declare unnecessary a skill on which the current control system still depends.

Evaluate two outcomes separately: what the learner achieved with the agent and what the learner can now do independently.

This is a forecast for September 2029, not a description of a known future. I would organize it around functions rather than product names. The more a function is tied to real-world constraints, the less reason there is to assume stronger models will eliminate it. The more a procedure reflects a current model weakness, the more likely it is to change.

I expect much of today's manual context preparation to move into tools. Procedures requiring many messages and reminders may become a single delegation. Verification will also be automated, so its current bottleneck should not be called permanent. Better automated evaluation could shift the constraint toward task selection, interaction with the physical world or organizational decisions.

Greater autonomy also creates longer action sequences and a wider range of consequences. The need to understand what happened, why it was permitted and how to recover may therefore grow while manual participation shrinks. People decide less often on individual actions, but the quality of the rules acting in their place matters more.

The most vulnerable investment today is treating a complicated in-house harness as a durable advantage without demonstrated benefit. A more durable investment, in my view, is a high-quality corpus of real work episodes: the objective, actual outcome, mistakes and checks that detect them. Logs do not automatically become an asset. The useful corpus supports comparisons while respecting the permitted use of its data.

At least three scenarios are plausible. In one, agents deeply automate conventional changes while people concentrate on ambiguous and unusual cases. In another, reliability on long tasks improves more slowly than expected and verification remains a large share of work. In a third, broad autonomy reaches entire products and human involvement moves toward objectives, boundaries and longer-term outcome evaluation. There is no sound basis here for assigning precise probabilities.

My forecast also has a revision condition. If systems maintain real products over extended periods, identify mistaken requirements, transfer evaluation to new task classes and address the consequences of failures at acceptable cost, I would revise the attainable autonomy upward. If speed increases alongside hidden rework and loss of understanding, more investment should go toward bounded delegation. Those outcomes matter more than the next announcement.

We may eventually laugh at pride in a thousand lines of agent instructions, mandatory role-playing prompts or agent counts used as a maturity signal. I would not laugh at people examining risk today. Some inconvenient checks will prove temporary. Others will make it possible to reach the next level of automation safely.

My three-year bet is on clear objectives, verifiable outcomes and manageable consequences. How we explain them to agents will change.

1. The unit of progress is a useful, accepted change. Generation speed matters to the extent that it changes the whole workflow's outcome.

2. Architecture determines the cost of consequences. Code can be rewritten faster than commitments to users and external systems can be undone.

3. Autonomy needs verifiable grounds. Removing a person from an action requires understanding which check and boundary replace their participation.

4. Harnesses must be simplifiable. Separate enduring functions from temporary recipes for a particular model.

5. Learning becomes an explicit engineering responsibility. Work delivered and independence acquired need different assessments.

METR, 2025. In an experiment involving 16 experienced participants and 246 tasks in familiar open-source repositories, the AI tools of the time increased completion time by an average of 19%. This concerns a particular sample and early-2025 tools. It does not establish that September-2026 agents generally slow development. METR's original publication, July 10, 2025.

METR's 2026 update. The researchers reported indications of speedup but explicitly called the new estimate unreliable because of participant and task selection and difficulties measuring time with parallel agents. Saying that METR proved an 18% speedup would misrepresent the evidence. Update, February 24, 2026.

DORA. The statement that AI amplifies an organization's strengths and weaknesses appears directly on the 2025 report page. That supports the importance of the surrounding work system. The figures of −1.5% and −7.2% used in earlier materials should not be presented as a universal result of that annual report: the separate Impact of Generative AI in Software Development describes associations with a 25% increase in adoption. They are neither a demonstrated causal effect nor a forecast for every team. Annual report, separate Impact of Generative AI report.

Learning with AI. The 50% and 67% figures describe immediate assessment of Trio knowledge, a difference of 17 percentage points. They are not a loss of 17% of intelligence or a long-term assessment of the profession. Anthropic study.

Free code. This is a useful discussion premise about falling implementation cost. It does not mean zero compute, integration, maintenance or error cost.

Independent evaluation. Another agent or model may improve checking, but its presence alone does not establish independence. Evaluation needs a different foundation and the ability to reject the solution.

My production boundary. The September 5 publication was strict: a person approves release. The conditional expansion in section 6 is a possible revision of my position, not a retelling of that earlier publication.