# Why AI-Assisted Development Still Needs Engineers at Every Level

> AI changes how engineers work and how they learn. Junior developers can contribute useful engineering now, acquire judgement through that work and use AI to participate more fully. Removing the entry route would weaken the capability organisations still need.

Paper: Technical report: engineering agents
Published: 2026-10-26
Canonical: https://harten.io/papers/why-ai-assisted-development-still-needs-engineers/

Cover illustration: [View the title image](https://harten.io/media/papers/covers/v1/why-ai-assisted-development-still-needs-engineers.png?v=f1340081da8e). Illustrative cover artwork, not an application screenshot or a record of measured results.

**Lavan Nallainathan | Harten Technical Papers | 26 October 2026**

I do not believe that AI's ability to write code makes engineers unnecessary. I am especially unconvinced by the conclusion that junior developers are the first people an organisation can dispense with. That conclusion takes one part of their work, much of which AI can now perform, and treats it as the whole contribution they make. It also overlooks how an organisation acquires its next generation of experienced engineers.

My view comes from using these systems extensively. I work with twelve or more agents across the day and night, investigating problems, implementing changes and reviewing work. They carry useful engineering forward while my attention is elsewhere. We have seen a service move from an idea to a production deployment in roughly forty-eight hours. That capability changes what a small team can undertake, and it is central to how I want to work.

The experience has also made the engineering around code generation more visible. Someone has to establish the required behaviour, understand how the change fits its consumers and recognise whether the result serves its purpose. Junior developers can contribute to that work now. AI can help them participate earlier and learn faster, provided they take responsibility for understanding the work they deliver. Mid-level and senior engineers contribute different depths of knowledge and judgement, while helping that capability develop across the team.

This is a position about the kind of engineering organisation I would build. Tasks and team structures will change. My reason for retaining engineers at every level is that the work still needs capable owners, and experience has to develop through useful participation in it.

## The Work Behind a Working Change

An implementation begins with an account of what the software should do. Sometimes that account is explicit. Often it is distributed between a request, an existing operation, the person who runs the service and several components whose behaviour has to remain compatible. Writing code is one way the team gives that account a concrete form. The team also has to establish that it has understood the account correctly.

One of our own changes concerned a reset operation. I needed to preserve the existing output, clear the current state, deploy a correction and then choose when to start again. The agents built a flow that archived the output and automatically ran a replacement. There was useful engineering inside it, including preservation and concurrency checks. The operation was still wrong because it removed the interval in which I needed to make the correction. Reviews of the implementation's mechanics did not resolve that earlier decision about its purpose. [1]

![The required reset archives the output, retires the current result and waits for a separate Start. The earlier implementation instead admitted and executed a replacement run during reset.](/assets/papers/engineering-agent-drift/01-reset-drift.svg)

**Figure 1. The required operation determines what correct implementation means.** Archival was only part of the reset. The required path preserved an interval for review or deployment and waited for a separate Start. The corrected reset follows that path. [Open the vector diagram at full size](https://harten.io/assets/papers/engineering-agent-drift/01-reset-drift.svg).

The defect was subsequently corrected. The live reset preserved the archived output, retired the old result and left the service ready for a separate Start. Local integration also exercised reset followed by that separate Start. The agents carried the correction forward, and verification established that the requested operation now worked. The lesson includes that successful recovery: understanding the requirement gave implementation and testing the right result to work towards.

The interval mattered because of an operational need. Once that need was made explicit and kept attached to the work, it could guide the design and the checks. An agent could help investigate it, and an engineer could misunderstand it. The organisation needed somebody responsible for connecting the operation to its purpose and resolving the disagreement.

That responsibility exists throughout delivery. A service may produce a file that its reader cannot accept. A test can pass because it expects the behaviour the implementation happens to provide. A report can contain every requested heading while omitting the investigation that was supposed to populate it. Understanding these conditions requires following the work beyond the line of code most recently changed.

As models improve, I expect more investigation and verification to become automated as well. I want the team to use that capability. The responsibilities can then be carried through different tasks, but the organisation still has to resolve competing requirements, decide which operational consequences are acceptable and answer to the people using the service. Engineers need enough understanding to carry those responsibilities and use the agents effectively. A junior's contribution should develop with those tools, moving towards larger changes and better investigation as the cost of implementation falls.

This is why I would assess an engineer's contribution through the change they help establish. Did they make a fault reproducible? Did they identify a missing condition? Can the next person understand what the change preserves? Those contributions remain useful when much of the code is generated. They are also contributions that a junior developer can make without first becoming an architect.

## The Contribution a Junior Developer Can Make Now

Consider an export option for a view of existing results, with a junior responsible for building it. An agent could help locate the data path, implement the export and construct the tests. The developer would still need to establish whether the export includes the filtered selection or the whole collection, what an empty result should produce and which information the recipient needs to interpret it. They can work through those choices with a colleague and deliver the resulting feature.

There are implementation trade-offs to understand along the way. An existing export path may provide consistent formatting and avoid a new dependency, while needing a small extension for the selected data. The developer can use the agent to investigate both approaches, explain the choice and follow the feature through to its actual output. They have built something useful, learned how it fits the application and taken responsibility for its behaviour. That is a stronger contribution than completing a set of edits somebody else has already reasoned through.

A junior developer can also help establish that an existing operation is wrong without first understanding the entire service. In the reset example, the first useful observation is straightforward: the system began another execution before anybody requested Start. A junior could reproduce that behaviour, record the starting condition and trace the new execution back to the reset. That would give the team something concrete to investigate.

Making that observation reliable takes engineering. A background worker might already belong to an earlier operation. A queue message might concern archival rather than new generation. The unwanted execution might start and fail before a test reads the final status. The developer has to decide what to observe and explain why it represents the behaviour at issue. A more experienced colleague can help with that decision without taking the whole task away.

The result has present value. A reproducer saves the team from repeatedly reconstructing a complaint. A check tied to the expected operation can prevent the same mistake returning. A clear account of the state before and after the action helps distinguish a requirement problem from a timing problem. These are contributions to delivery, even if the developer uses an agent to construct most of the fixture or locate the relevant code.

There is similar value in tracing a small part of an unfamiliar system. A junior can follow a record from its producer to its reader, identify where a field is added and show where it is validated. They may need help deciding whether the producer or consumer should change. Establishing the actual path is still useful work. It gives the person making that decision a firmer basis than an assumption about how the components probably interact.

Judging a junior developer only by the code they produce unaided misses much of their contribution. An agent may generate that code more quickly. The developer's contribution can include recognising which condition deserves a test, following an unexpected result and leaving the system easier to understand. Reducing the cost of implementation can make those contributions more economical, because the team spends less effort reaching the point where it can examine the behaviour.

The team needs to choose real work with an intelligible boundary and provide the review that allows it to be owned. A developer who brings back a useful feature, a well-founded observation or a correct bounded change has helped deliver the service. Their future development is an additional benefit, rather than the only reason the organisation employs them.

## How Judgement Develops Through Real Work

Experience becomes useful when somebody has seen how an apparently reasonable change behaves under conditions the first explanation missed. That understanding develops through making predictions, examining results and correcting an account of the system. Reading an answer can help. Being responsible for a change gives the developer a practical reason to find out whether the answer holds.

Consider a developer who has built the reset reproducer with an agent. I would want them to explain why their observation distinguishes reset processing from a replacement run. I would then change a starting condition with them. What happens when an earlier worker is still active? Which observation should remain the same if the reset request is repeated? They do not need an immediate answer to every question. They need to know how to investigate the difference between their expectation and the result.

That exercise develops judgement while producing useful engineering evidence. The developer learns that a final status may conceal an intermediate action, that asynchronous work needs an identity and that the absence of one kind of message says little about another. Those details later become part of how they recognise an incomplete test or ask a better question during design.

AI makes ownership especially important because it can supply a coherent implementation and an equally coherent explanation. If the developer accepts both without working through their relationship to the requirement, the team may receive a finished-looking artefact while the developer acquires little understanding. The same problem can affect an experienced engineer. Fluency in the explanation is a poor substitute for being able to predict what the software will do.

The expectation I would set is that the person delivering a change can explain its purpose, the relevant path through the system and what they checked. They should be able to identify where they relied on an agent and what remains for a colleague to help resolve. A reviewer can then work with an actual account of the change, rather than guessing whether the author understands the generated result.

This also changes what useful supervision looks like. A senior need not dictate every edit or ask a junior to recreate an answer that is already available. They can examine the developer's reasoning at the points where it affects behaviour. Why does this test expect that result? Which consumer depends on the field? What would make this proposed correction inappropriate? The discussion improves the current change and gives the developer a way to approach the next one. [2]

## What AI Changes for a Junior Engineer

I see considerable scope for AI to increase a junior developer's contribution. Unfamiliar code, poor documentation and difficulty finding a starting point can consume much of a newcomer's attention. An agent can help locate the entry point, trace calls, explain a library and construct an initial fixture. That assistance gives the developer more opportunity to work on the question they were actually asked to resolve.

For a developer learning an asynchronous service, the agent can help assemble the sequence of requests, records and worker activity. The developer can inspect that account against the source and the observed execution. When something does not fit, they have a specific discrepancy to pursue. They can use the same tools to compare another path or try a smaller experiment. The learning proceeds through participation in the system rather than waiting until every technology in it is familiar.

This is particularly useful when the work crosses languages or layers. A developer who understands the required operation may still struggle with a deployment script, a persistence API or the conventions of an unfamiliar test framework. AI can reduce that friction. With appropriate review, the developer can carry a useful piece of work further instead of handing it over as soon as it reaches an unfamiliar syntax or tool.

There is no educational value in preserving unnecessary difficulty for its own sake. I would not require juniors to spend days finding information an agent can help them locate in minutes. I would use the time gained to deepen their understanding of the result: inspect the actual record, run the boundary case, compare the consumer and explain the consequence. Faster access to an answer is useful when the developer then has room to examine and apply it.

The standard of contribution can rise with that assistance. A junior might arrive at review with a reproducer, the relevant code paths, a candidate correction and an explanation of the test. The reviewer can spend time on the uncertain part instead of helping reconstruct the basics. That is a more productive relationship for both people, and it gives the junior a clearer view of the decisions that experience helps resolve.

An organisation should teach that use of AI deliberately. A junior left alone to submit generated work and hope that a senior catches the mistakes has neither useful independence nor a reliable way to develop it.

## The Route to Experienced Engineers

The case for juniors also extends beyond the current change. An organisation needs people who can take responsibility for larger parts of its software over time. That experience has to come from somewhere. Hiring only people who already possess it depends on other organisations continuing to develop them and leaves the team with little control over its own future capability.

AI does alter the work through which people traditionally entered the profession. Straightforward implementation, repetitive test construction and routine documentation may require much less manual effort. An employer cannot simply assume that the old sequence of junior tasks will continue to provide the same learning. It has to consider what useful participation should look like when those tasks are assisted or automated.

The answer I favour is to move ownership closer to behaviour. Let a junior establish a reported problem, make a bounded change, follow it into its consumer and help determine whether it worked. Give them access to the tools that reduce mechanical work and to colleagues who can explain the consequential decisions. Over several changes, the developer builds knowledge of the system and encounters the reasons its boundaries exist.

That investment contributes directly to delivery. The feature, reproducer or correction remains useful after the learning conversation ends. The developer also becomes able to take more responsibility on the next change. A team develops capacity by arranging for current work to produce both a useful result and a more capable colleague.

Removing entry roles because agents can perform some of their earlier tasks gives up that development route. It does not explain how the organisation will acquire engineers who understand its application, recognise its failure modes and can judge a difficult change. I would expect a staffing decision to address that question directly, rather than treat the availability of generated code as its answer.

## The Understanding Needed Between Components

As engineers gain experience, they should be able to own more of the path between a request and the resulting service behaviour. This is where I would expect a mid-level engineer to contribute strongly. A component can be correct in isolation while the change fails at the point where another component consumes it. Somebody needs to understand both sides well enough to decide how they should fit.

In one documentation change, the team was trying to remove failures caused by model-generated citation identifiers. There was a sensible opportunity to retain identifiers in code rather than require a model to reproduce them perfectly. But the repair also altered the output consumed by chapter assembly and diagram compilation. Useful prose survived in supporting files while the main chapters became little more than navigation, and the diagram path lost the structured records it needed. The correction had to preserve the different contracts of those consumers. [1]

![Two consumer paths depend on different forms of content: chapter assembly needs the retained prose, while diagram compilation needs structured elements and relationships. A repair disrupted both paths.](/assets/papers/engineering-agent-drift/02-publication-regression.svg)

**Figure 2. Understanding the consumer is part of delivering the change.** Chapter assembly and diagram compilation needed different inputs. Useful material remained upstream, but the published output no longer carried it through. Tracing those paths is engineering work that can be owned and learned. [Open the vector diagram at full size](https://harten.io/assets/papers/engineering-agent-drift/02-publication-regression.svg).

A junior can contribute by tracing that path and showing where the useful content stopped appearing. A more experienced engineer should be able to take responsibility for the integrated correction: determine which representation each consumer needs, preserve the working material and choose a test that actually exercises the affected path. The difference is the breadth of responsibility they can carry, with help available when the evidence changes the scope.

The same issue appeared in an assessment service that published reports without performing the required external investigation. Providing report structures and explaining that references were absent did not complete the assignment. An engineer had to distinguish an unresolved component identity, a failed lookup and a retrieval path that had not been implemented. Each condition required different work. Later local assessment work supplied references and substantive findings, while retaining the specific questions the available evidence could not settle. [1]

AI can assist throughout these investigations. It can follow the consumer, propose a representation and help implement the missing path. The responsibility remains to connect those contributions to a result the team can maintain and the user can use. That responsibility can be carried by engineers with different job titles. It should be visible in how the work is assigned and accepted.

## Senior Responsibility in an Agent-Assisted Team

A senior engineer should help the team decide which problem it is actually solving and how much change the requirement justifies. Once a plan has accumulated new identities, states and consumer behaviour, those additions can begin to look inevitable. Experience is useful in recognising that some of them follow from an earlier design choice which the team can still reconsider.

The reset required that kind of judgement. There were legitimate questions to solve inside a reset-and-rerun feature. They did not make that feature the right response to the operation I wanted. Returning to the required interval allowed the team to correct the design. A senior contribution can therefore be removing work and clarifying a boundary, as well as handling a technically difficult implementation.

It also includes deciding where review effort belongs. Some work can proceed with well-established checks and little intervention. A change to the meaning of an operation or an identity consumed elsewhere needs more context. If all generated changes receive the same scrutiny, the team either spends its attention on routine mechanics or loses the ability to examine consequential work properly. Useful delegation gives people room to act while making those consequences visible. [2]

A capable engineer working alone can use several agents effectively, and a small team may be able to undertake much more than before. The practical question is how much relevant context and responsibility they can carry. Concentrating every requirement decision, integration problem, review and learning conversation in one person can restrict the benefit of parallel execution. Developing that capability across the team gives more of the work an informed owner.

Senior engineers also have a responsibility for how juniors participate. They can help choose bounded work that matters, explain why a proposed correction is insufficient and let ownership grow as understanding develops. That is part of building the delivery capacity of the team. If every difficult decision remains permanently with the same senior, the team has increased its output without doing much to strengthen its organisation.

## A Team That Uses AI Fully

I want engineers to use these systems extensively. Agents can investigate in parallel, prepare candidate changes, construct fixtures and continue useful work while people attend to other decisions. The objective should be to bring more work through to an understood and accepted result. Requiring engineers to redo everything manually would consume much of the benefit without establishing a clearer basis for acceptance.

The practical discipline is to keep the required behaviour available while the implementation develops. The test expectation needs a basis beyond the code the agent happened to generate. A reviewer needs access to the request and relevant operating knowledge. When a change affects another component, the team should examine that consumer instead of assuming it will infer the new meaning. These are ordinary engineering responsibilities made more pressing by the speed at which work can now accumulate. [2]

![The original request informs implementation and expected observations separately. Engineers compare actual behaviour with those expectations, resolve mismatches and preserve useful work before accepting the change.](/assets/papers/engineering-agent-drift/03-engineering-checks.svg)

**Figure 3. Engineers connect the change to the outcome it needs to deliver.** The original request informs both implementation and expected observations. Junior developers can own bounded parts of this work while experienced colleagues help resolve the wider consequences. [Open the vector diagram at full size](https://harten.io/assets/papers/engineering-agent-drift/03-engineering-checks.svg).

Our own operating experience feeds into the engineering harness around the agents: their instructions, tools, tests, responsibilities and work records. One useful improvement was replaying publication from retained model outcomes. That allowed the team to inspect chapters, links and diagrams while changing the assembly code, without repeating the expensive generation each time. It made a particular class of defect easier to investigate and correct.

The value of that improvement was visible in the work it enabled. Likewise, the reset correction mattered because the archived output was preserved and the operator could choose when to begin again. Those are useful delivery outcomes. A junior can help establish them, an agent can carry much of the implementation and a more experienced engineer can help resolve the wider implications. The contributions reinforce one another when the responsibilities are clear.

I would judge the resulting arrangement by how effectively it delivers that work and develops the people responsible for it. Faster generation matters. So do useful investigation, correction effort, the ability to explain a change and the growing range of problems the team can own. The organisation should gain both from using AI: more capability available now and people better equipped to use it on the next problem.

## Why I Still Want Engineers at Every Level

The engineering organisation I want has junior developers contributing real work, mid-level engineers owning integrated changes and senior engineers judging scope, consequences and trade-offs. The responsibilities will overlap. A junior may identify the mistaken requirement first; a senior may need to write the reproducer. The point of having that range of experience is to distribute understanding and allow it to grow.

AI changes how the work is performed and can make a much greater contribution to it. That strengthens my interest in developing engineers who can use the capability well. It does not give me a reason to remove the people entering the profession just as the tools available to them become more powerful.

Junior developers should learn to investigate, explain, implement and take responsibility with AI as part of their normal work. They should contribute to delivery while acquiring the experience that lets them own more of it. My conclusion is that we still need them, alongside the engineers they are learning from and becoming. The task is to build teams in which that development and the useful work proceed together.

## Source Notes

1. The operating examples are drawn from Harten's retained engineering investigations: the reset correction, documentation interfaces, assessment behaviour and local publication replay. The corrected reset was verified live, and separate Start also passed local integration. The junior contributions described here are illustrative uses of that work.
2. Related Harten papers develop the surrounding reasoning: [What Engineers Need From AI-Assisted Application Analysis](https://harten.io/papers/what-engineers-need-from-ai-assisted-application-analysis/), [Machines Directing Machines](https://harten.io/papers/machines-directing-machines/), [The Human Cannot Be the Bottleneck](https://harten.io/papers/01-2-human-cannot-be-the-bottleneck/) and [Modernisation Starts by Establishing What Is Actually True](https://harten.io/papers/02-03-modernisation-starts-by-establishing-what-is-actually-true/).

*More writing and the complete series are available at [the Harten papers archive](https://harten.io/papers/).*