AI is helping us build software faster. We also need to make sure it helps us build better engineers.

The time between identifying a problem and having a working solution is getting much shorter. A developer can now describe a problem, ask an AI agent to investigate it, generate a solution, run tests, and have working code in minutes.

For engineering teams, the opportunity is significant. We can move faster, explore more possibilities, automate repetitive work, and lower the barrier to building software. I am an optimist by nature, and I am genuinely excited about what this could mean for software development.

But I keep coming back to another question:

What happens to software engineering when we stop experiencing the journey of finding the solution?

The value of not knowing the answer

A lot of what makes someone a good engineer is not in the code they eventually ship. It comes from the process of getting there.

You encounter a problem you do not fully understand. You investigate the codebase, read documentation, try something, discover it does not work, question an assumption, and try again.

Eventually, something clicks.

Along the way, you build something that lasts much longer than the fix itself: a better understanding of the system and the judgement that helps you solve the next problem.

I think about the times I have spent investigating slow SQL queries, timeouts, or systems struggling to scale. Sometimes the fix was simple, but getting there forced me to understand the problem better.

I would often discover that one of my assumptions was wrong, or that the system behaved differently from what I expected. That understanding stayed with me, helped me solve similar problems later, and helped me write better code.

Looking back, that investigation was not simply overhead between finding a problem and fixing it. It was part of becoming a better engineer.

AI changes this dynamic.

Instead of starting with a blank page, we can start with a proposed solution. Instead of spending hours exploring an unfamiliar codebase, we can ask an agent to investigate it. Instead of testing different possibilities ourselves, we can ask AI to do much of that work for us.

These are powerful capabilities. The important distinction for me is this:

Using AI to accelerate learning is not the same as using AI to bypass it.

Productivity is not the same as capability

Software teams are constantly looking for ways to be more efficient. Better tools, automation, CI/CD, cloud infrastructure, and higher-level frameworks have all helped us deliver software faster.

Most software developers today do not need to understand everything happening behind the abstractions they use. We rely on compilers, operating systems, databases, frameworks, and cloud platforms without understanding every detail of how they work.

And that is generally a good thing.

The difference I see with AI is that most of those abstractions are predictable and reliable enough that we rarely need to look beneath them.

AI is different. Its output is probabilistic. It can produce something that looks reasonable, passes tests, and may still be wrong in ways that are difficult to notice.

We are automating more of the work while still expecting engineers to understand the result, verify it, and step in when something goes wrong. That means the underlying understanding has not gone away. In some ways, it matters even more.

This is not an entirely new problem. In 1983, researcher Lisanne Bainbridge described what became known as the “ironies of automation”: as systems become more automated, people have fewer opportunities to practise the skills needed to understand and control them, while still being expected to step in when something goes wrong.

I think software engineering may be facing its own version of that problem.

If we judge AI adoption mainly by how much code we produce, how quickly issues are closed, or how fast features ship, we may miss what is happening to the capability of the team underneath those numbers.

The concern is not only what an individual developer learns. Over time, teams could also lose some of the collective knowledge and judgement they rely on to maintain, troubleshoot, and evolve their systems.

For example, a developer might use an agent to implement a feature in a fraction of the usual time. The code works, the tests pass, and the feature ships. That is a good outcome.

But if the developer did not need to understand much of the problem to get there, we should also ask what they actually learned along the way.

Does the developer understand why the solution works? Do they understand its assumptions and limitations? Would they recognise when the same approach is wrong in another situation? Could they investigate the problem if it failed in production?

AI can help with all of those things too. But I think we need to be more deliberate about how.

There is a difference between using AI as an oracle that gives us the answer and using it as a tutor that helps us work through the problem.

I saw this in my own work recently while developing a technical vision for modernising a complex system. I already had a general idea of the direction I wanted to take, but I used AI to challenge my assumptions, refine the approach, and explore alternatives.

I also used it to help me build small proofs of concept with different technologies so I could compare the trade-offs first-hand. AI did not make the decision for me. It helped me better understand the options so I could make a more informed decision.

Instead of asking an agent to fix a slow query and explain the answer afterwards, we could ask it to suggest things to investigate, challenge our diagnosis, or help us compare approaches as we work through the problem.

It could ask us questions instead of immediately giving us the answer.

The goal is not to make solving problems artificially difficult. It is to use AI in ways that still help us develop the judgement we will need when the answer is not obvious.

Delivering a solution and developing the ability to solve problems are two different outcomes. A healthy engineering organisation needs both.

Where will the next generation of senior engineers come from?

This matters even more for people entering the profession.

AI can remove a lot of unnecessary friction from learning software development. It can explain unfamiliar concepts, suggest debugging strategies, help someone navigate a large codebase, and make systems that once looked intimidating much more approachable.

That is a good thing.

We should not romanticise the old way of doing things. Spending hours trying to find a typo or small configuration mistake was not always a valuable learning experience.

But I think we need to be careful not to remove the parts of learning that help us build real understanding.

There may also be a bigger issue.

A lot of the work that AI is becoming good at is the same work we have traditionally given to junior developers.

Small bug fixes, straightforward features, tests, documentation, refactoring, and relatively contained problems are often where people start.

Those tasks do not only produce output. They give people opportunities to learn a codebase, make mistakes in relatively safe situations, receive feedback, and gradually take on harder work.

If AI absorbs more of that work, the journey may not simply become shorter for junior developers. For some people, it may never start.

That raises a difficult question for engineering leaders: how do we develop the senior engineers we will need in five or ten years if fewer people get the opportunities that helped today's senior engineers develop their judgement?

I do not think that means protecting busywork for the sake of it. We should absolutely automate work that does not contribute much to learning.

But we need to understand which experiences actually develop engineers and make sure those experiences do not disappear simply because an agent can complete the task faster.

Building capability, not just shipping code

The immediate benefits of AI are easy to see. Features can ship faster, developers can explore more approaches, and repetitive work can be automated.

What is harder to see is what happens to the capability of the team over time.

That is the part I think engineering leaders need to pay attention to.

I do not believe the answer is to restrict AI or ask developers to work the way we did before. We should be encouraging people to use these tools.

But we should also be deliberate about what we automate, what we continue to ask engineers to understand, and what behaviours we reward.

If we are going to measure the productivity gains we get from AI, we should also be asking whether we are building or losing engineering capability along the way. That is harder to measure than tickets closed or features shipped, but it matters just as much.

In practice, that means expecting engineers to explain important AI-assisted changes in their own words, not simply point to passing tests. We can make sure junior engineers still get meaningful opportunities to investigate problems, make technical decisions, and learn from the results. And we can reward debugging, technical judgement, mentorship, and a deep understanding of systems, not only how quickly someone ships.

The outcome of engineering work is not only the software we produce. It is also the capability we build along the way, and the trust that comes from knowing what we ship is reliable, understandable, and does what our users and stakeholders expect.

AI can make finding a solution much easier. We should embrace that.

But the journey is still part of the engineering. We are not only building software. We are also developing the engineers who will need to understand it, maintain it, troubleshoot it, and improve it in the future.