AI is changing software development. Good engineering still starts with the problem.

There is no shortage of commentary about how AI is transforming software development.

Some of it is justified. The tools available to software teams have improved remarkably quickly, and we are already seeing meaningful productivity gains. But much of the conversation starts in the wrong place.

It starts with code.

How quickly can AI generate it? How many developers can it replace? Can one engineer now do the work of two, five or even ten?

For the organizations paying for software development, those aren't really the most important questions.

The question that matters is much simpler:

Are we building the right thing?

Faster code isn't necessarily better software

Writing code has never been the ultimate purpose of software engineering. Code is an output.

The purpose is to solve a problem, meet a requirement or create measurable business value.

AI doesn't change that.

In fact, as AI makes producing code faster and cheaper, we think the disciplines surrounding the code become more important, not less.

Before development starts, somebody still needs to understand the problem. Requirements need to be discovered, challenged and validated. Technical decisions need to be made in the context of the product, the organization and its longer-term objectives.

During development, somebody needs to determine whether what's being built actually satisfies those requirements.

And before software reaches users, somebody needs to establish whether it works — not merely whether the code compiles or the automated tests pass.

AI can participate in all of those activities. It doesn't remove the need for them.

The software engineer's role is evolving

This is where we think the discussion about AI replacing software engineers often misses the point.

The value of an experienced engineer was never simply their ability to type code quickly.

It's their ability to understand a problem, identify risk, make sound technical decisions, recognize when something doesn't look right and understand the consequences of one decision elsewhere in a system.

AI coding tools can make that engineer substantially more productive.

A good engineer knows how to provide the right context to an AI tool, how to constrain it, when to question its output, what needs testing and — crucially — when not to accept the answer it provides.

They also understand where AI-generated code sits within the wider software development lifecycle.

That's becoming an increasingly valuable engineering skill.

There are real economic benefits

We are seeing meaningful productivity improvements from AI-assisted development.

We're rather more cautious about some of the claims of 10x improvements in developer productivity. Software engineering consists of far more than producing lines of code, so measuring productivity primarily through code generation risks measuring the wrong thing.

In our own work, gains closer to 2x in appropriate development activities can be realistic.

That's still enormous.

It can allow an experienced engineer to work effectively across areas that might previously have required more specialist development resources. AI can accelerate implementation, assist with unfamiliar parts of a stack, generate tests, interrogate existing codebases and reduce the time required for repetitive engineering work.

There is another cost to manage, too: AI itself.

Engineering teams increasingly need to understand when expensive models are justified, when cheaper tools are sufficient, how much context is useful and when repeated AI experimentation is simply consuming tokens without moving the project forward.

AI cost management is becoming part of engineering management.

But saving developer hours or AI tokens shouldn't be the ultimate measure of success.

The real economic benefit comes when a business can reach the correct outcome faster without increasing delivery risk.

Governance matters more when production accelerates

There is a useful paradox here.

The easier it becomes to produce software, the more important good software-development governance becomes.

If AI allows a team to generate code twice as quickly, poor requirements can also be implemented twice as quickly.

An incorrect architectural assumption can propagate rapidly through a system. Technical debt can be generated at extraordinary speed. An AI agent can confidently solve a problem that nobody actually needed solving.

Speed magnifies both good and bad decisions.

That makes the fundamentals of the software development lifecycle increasingly important:

Problem → requirements → design → implementation → validation → release → learning

AI can accelerate activities throughout that lifecycle. It shouldn't be allowed to bypass it.

For product and technology leaders, therefore, adopting AI shouldn't mean abandoning established engineering discipline in pursuit of raw development velocity.

It should mean examining each part of the lifecycle and asking:

Where can AI help us make better decisions or execute good decisions faster?

Evolution, not revolution

We don't believe established businesses need to tear up their development organizations because generative AI has arrived.

Nor do we think ignoring these tools is remotely sensible.

The opportunity lies between those extremes.

The strongest teams will evolve their processes around AI while retaining the things that already make good product development work: clear objectives, validated requirements, experienced judgment, appropriate architecture, disciplined testing and accountability for outcomes.

Team structures may change. The boundaries between engineering disciplines may become less rigid. Smaller teams may be able to accomplish substantially more. And the skills we value in individual engineers will continue to evolve.

But none of that changes the fundamental purpose of the work.

Businesses don't need more code. They need the right problems solved well.

AI gives experienced product and engineering teams a powerful new way to do that faster.

Used intelligently, that's a profound change to the economics of software development.

But it should be an evolution in how good teams work — not a revolution that causes them to forget why they're building software in the first place.