Who Will Become a Senior Engineer Now?

As coding agents absorb entry-level work, engineering teams risk dismantling the apprenticeship that once created production judgment.

---

Six months into my first client project, almost every senior member of the team left.

The manager left. The technical lead left. The experienced engineers who understood the product moved on as well. New engineers, managers, and leads joined to replace them.

On paper, I was still one of the most junior people on the project. I had only recently completed my training and had been assigned to the client as a new engineer.

In practice, I had something many of the people joining the team did not: product knowledge.

I knew why certain parts of the application had been designed the way they were. I knew which areas were fragile, which requirements had changed, and where previous problems had occurred. When someone had a question about how the product worked, they often came to me.

Without the title, I had started virtually leading parts of the product.

I did not acquire that understanding from a training programme or an architecture document. Much of it came from doing ordinary project work: reading JIRA tickets, making code changes, participating in reviews, listening to team conversations, debugging failures, and watching senior engineers respond when something went wrong.

At the time, I thought I was simply completing the work assigned to me.

Looking back, I was accumulating context.

That experience shapes how I think about coding agents today. The industry is asking whether these tools will reduce the need for junior developers. I think that question misses a more difficult problem.

If agents perform more of the work through which junior engineers traditionally develop judgment, how will companies produce their next generation of senior engineers?

---

The deployment I could not roll back

One of my hardest lessons came from the way we used to deploy a Java application.

There was no proper CI/CD pipeline. We ran shell scripts directly on an AWS EC2 instance. The same script built the application and placed the resulting artifact inside a Tomcat container.

Once a build had been deployed, we deleted its artifact.

For a while, this process seemed good enough. The script ran, the application started, and production moved to the latest version. We did not think deeply enough about what would happen when the deployment only partially succeeded.

Then one production release failed because of a problem with the database migrations.

We needed to restore the application quickly, but the build that had previously been running in production no longer existed. We had deleted the only artifact we could have used for a straightforward rollback.

Our rollback process became: return to Git, revert the code, create a fresh build, and deploy it again.

That takes time even when everything goes well. Under production pressure, every additional step feels longer. The team is trying to understand the migration failure, restore service, verify the reverted code, build the application again, and avoid introducing another problem while rushing.

That incident changed how I thought about deployment.

Before it happened, CI/CD could sound like an engineering improvement—something that would make releases faster and reduce manual work. After the incident, I understood it as a recovery mechanism.

A reliable delivery process is not only about getting a new version into production. It is also about preserving deployable artifacts, knowing exactly what is running, controlling database changes, and being able to return to a known state.

I could have read those principles in documentation. That would not have created the same judgment. I understood their importance because I had experienced the consequences of not following them.

This is how a large part of engineering apprenticeship has always worked. The lesson is attached to an actual system, an actual failure, and the pressure of having to recover it.

The work leaves behind a mental model.

---

What disappears when the agent completes the task

Coding agents can now perform many of the steps that once exposed junior engineers to these lessons.

They can inspect a repository, modify several files, generate tests, respond to build failures, and return what appears to be a completed implementation. For many well-bounded tasks, they can do this impressively well.

But completion can conceal a lack of understanding.

In one of the simplest examples I encountered, an agent was asked to create a CRUD application. It produced the application and implemented the expected operations. On the surface, the task appeared complete.

The agent had assumed that all the data could remain in memory.

There was no persistent database.

The application could create and retrieve records during a running session, but the data would disappear when the process restarted. For almost any real CRUD application, that is not a minor implementation detail. It changes whether the application fulfils its basic purpose.

The code may have been valid. The routes may have worked. Tests written around the same assumptions might even have passed.

The failure was not primarily in code generation. It was in understanding the system being built.

This is what I mean when I describe many coding agents as developers with no voice in the room. They complete the requested work, but they do not consistently stop and challenge the premise. They do not always ask whether the chosen architecture fits the existing application, whether a requirement has been omitted, or whether the implementation will survive outside the local development environment.

An experienced engineer can catch this because they already know which questions to ask. They see an in-memory collection and immediately ask what happens after a restart. They see a database migration and think about deployment order and rollback. They see a retry and consider duplicate execution.

A junior developer may not yet have those instincts.

If the agent generates the implementation and the developer accepts it because it runs, the task has been completed without the underlying lesson being learned.

---

I use agents differently because of what I already know

My response to coding agents has not been to stop using them. I use them extensively.

But they have changed the way I approach development.

I now try to think more architecturally before allowing an agent to proceed. I define clearer boundaries around the work so I can keep track of what it is building. I want to understand how the proposed change fits into the larger system before the agent starts producing files and code.

Otherwise, it is very easy to go with the flow.

The agent makes one change, discovers that another change is required, introduces a new abstraction, modifies a configuration, and then adjusts the tests. Each individual step can appear reasonable. After several iterations, however, the implementation may have moved further than the developer’s understanding of it.

This is particularly dangerous when something fails.

If I understand the system, I can usually narrow the problem to a likely layer. I can ask whether the issue is in the API, business logic, persistence layer, configuration, infrastructure, deployment process, or an external dependency.

If I do not understand the flow, my only option may be to return the error to the agent and ask it to fix the problem.

The agent then suggests a change. If that does not work, it suggests another. Soon, I am applying fixes to code I did not fully understand in order to resolve an issue I cannot properly locate.

The result can be a lot of activity without much progress. Worse, the agent may fix the visible symptom in the wrong layer and leave the real problem in place.

My previous experience gives me a boundary from which I can supervise the agent. A junior engineer who has not yet built those mental models may not have the same advantage.

That is why giving a junior developer a powerful coding agent does not automatically make them equivalent to a senior developer. It can increase the sophistication of their output much faster than it increases the sophistication of their judgment.

---

The old apprenticeship was never formally designed

Engineering teams have rarely called this an apprenticeship system.

It happened through work.

A developer picked up a JIRA ticket and followed it into unfamiliar parts of the application. A pull-request comment forced them to understand why their implementation did not fit an existing pattern. A private conversation with a senior engineer gave them context that had never been written down. A disputed decision escalated into a team discussion, exposing trade-offs that were invisible in the original task.

Sometimes the learning was intentional. Often, it was incidental.

Even uncomfortable situations contributed to it. When the senior members of my first project left, the loss of experience created a difficult environment. But it also made visible how much product knowledge I had accumulated through day-to-day involvement.

That knowledge allowed me to take responsibility before my designation suggested that I should.

Coding agents interrupt this informal process in subtle ways.

The JIRA ticket can go directly from description to implementation. The first architectural decision may be made by the agent before the developer has formed their own view. The debugging process can become a conversation between the error message and the model. The pull request may be reviewed as a finished answer rather than as evidence of the developer’s reasoning.

The organization still receives code, but the engineer may receive less exposure to the thinking that produced it.

This does not mean we should preserve every repetitive task. There is little value in making developers manually write boilerplate simply because earlier generations did so.

But we need to distinguish between typing that consumes time and work that creates understanding.

Those two things were bundled together in the old development process. Coding agents are separating them. If companies automate the first without deliberately preserving the second, the learning loop breaks.

---

What I would expect from a junior engineer now

If a junior engineer brings me an agent-generated change, I would not expect them to have manually written every line.

I would expect them to understand what has been built.

They should be able to walk through the code flow rather than only describe the files that changed. They should understand where the request enters the system, how it moves through different layers, where the data is stored, and what happens when one of those layers fails.

They should also be able to explain whether the architectural pattern introduced by the agent is coherent with the existing codebase.

A solution can work in isolation and still be wrong for the system. The agent may introduce a repository pattern into an application that uses a different abstraction, bypass an existing validation layer, duplicate functionality, or create a new way of solving a problem the team has already standardized.

Most importantly, the developer should have an initial view of where to look when the implementation fails.

They do not need to predict every possible bug. They do need a mental model strong enough to say, “Based on how this flows, the problem is likely in this layer, and here is the evidence I would check.”

Without that understanding, debugging becomes another act of delegation. The developer repeatedly asks the agent to diagnose and modify the code, without being able to judge whether the proposed fix belongs in the right place.

This is the standard I think engineering teams will increasingly need: generated work is acceptable; unowned work is not.

---

The real risk is delayed

For the moment, experienced engineers can compensate for these weaknesses.

They can use agents to move faster while relying on years of accumulated judgment to review the output. They know that a successful build is not the same as a safe deployment. They recognize when a simple implementation is hiding an operational problem.

This can create significant short-term productivity.

The longer-term risk is that companies begin to treat the presence of experienced reviewers as a permanent condition while reducing the opportunities through which less experienced engineers become those reviewers.

Senior engineers are not created by giving junior engineers senior-level tools. They are created through repeated exposure to systems, decisions, consequences, and recovery.

The form of that exposure can change. In fact, it should change.

Junior developers can use agents to explore larger systems earlier in their careers. They can compare alternative implementations, ask questions about unfamiliar code, generate experiments, and receive feedback more quickly than I could when I started.

But none of this is automatic.

Someone still needs to ensure that the developer is learning to question the output rather than merely operate the tool. Someone needs to connect implementation decisions to production consequences. Someone needs to ask the developer to explain the system before approving the change.

The old apprenticeship emerged from the friction of software development. As agents remove that friction, engineering leaders will have to rebuild its valuable parts intentionally.

When the senior members of my first project left, I was able to step into a larger role because the knowledge of the product had stayed with me.

The question for today’s engineering organizations is whether the knowledge will still stay with the developer—or whether it will disappear when the agent’s session ends.