AI can generate code faster than engineers can realistically review it. But that does not mean software engineering is disappearing. It means the bottleneck is moving — from writing code towards understanding the problem, making decisions, designing systems, managing context and knowing what “good” looks like.
That was one of the central themes of a shared keynote at AWS Community Summit Manchester, exploring the past, present and future of software engineering.
The keynote travelled from decades of deterministic software development, through the increasingly probabilistic world of AI, before David Anderson closed by asking the difficult question:
What happens next?
His answer was deliberately optimistic.
No one can accurately predict what software engineering will look like in five years — arguably even six months. But we can identify the engineering principles that become more valuable as AI accelerates the rate at which software can be produced.
AI has solved one bottleneck. It hasn’t solved engineering
For years, engineering organisations have tried to improve three things:
Build the right thing. Build the thing right. Build it fast.
Generative AI has made a dramatic difference to the third.
Models and agents can now produce code at a speed that would have been difficult to imagine only a few years ago.
The other two questions have not gone away.
What should we actually build?
And how do we know that what we have built is right?
As Dave put it during the keynote, speed of delivery has accelerated enormously, but intent and purpose remain difficult. In some respects, they become harder because engineers now have to process and evaluate far more output. Pasted text
This is an important distinction.
Faster implementation does not automatically create better systems.
It simply moves the constraint.
The earlier part of the keynote explored exactly this phenomenon. Once code generation becomes cheap, the bottleneck can move into code review, decision-making, product design, architecture or organisational context.
A 200,000-line AI-generated pull request isn’t necessarily evidence of extraordinary productivity.
It may simply have created a much larger review problem.
That changes what engineering organisations should optimise for.
The problem with the AI software factory
One of the metaphors gaining traction around AI development is the software factory.
There is something attractive about the idea.
Requirements enter one side. Agents analyse, design, generate, test and deploy. Working software emerges from the other.
But Dave challenged the metaphor.
Factories historically became obsessed with output: widgets produced, units completed, throughput increased.
Software organisations already have a tendency to make the same mistake.
Lines of code. Story points. Pull requests. Features shipped.
AI can magnify that behaviour dramatically.
If an organisation takes its existing development process and simply adds agents to every stage, it may create a faster version of the same dysfunctional system.
Dave described seeing organisations where engineers effectively end up trying to understand what their automated “factory” has generated. His prediction is that simply applying AI to old workflows without changing the operating model will produce plenty of failures along the way. Pasted text
That isn’t AI transformation.
It is automation without understanding.
Think of software as a garden, not a factory
Dave offered an alternative metaphor: the software garden.
A garden is not produced once and declared finished.
It is designed, nurtured, observed, pruned and continually improved.
The gardener works with a living system.
Software behaves in much the same way.
Good systems need to evolve as customer needs change, technology changes and our understanding of the problem improves.
More importantly, software engineering is ultimately a human activity.
We engineer systems because someone needs something to be better: a customer experience, a business process, an operational problem or a capability that did not previously exist.
That purpose doesn’t disappear because an LLM can generate an API in seconds.
The role of the engineer becomes increasingly about guiding, shaping and sustaining the system, rather than maximising the amount of code passing through it.
Context becomes architecture
So what might AI-native engineering actually look like?
Dave shared an example from work on an AI-assisted development lifecycle in which humans and agents operate against a shared model of the system.
Three ideas stood out.
First, there is topological context: the relationships between the domain, data, architecture and capabilities are explicitly mapped.
Second, there is a living architecture. The architecture is not a document written at the beginning of a project and forgotten. It participates in an ongoing verification and feedback loop.
Third, humans and agents work from a shared model — an ontology or knowledge graph that makes the organisation’s engineering context available to both. Agents execute against that context rather than being given an isolated prompt and expected to infer everything else. Pasted text
This points towards an important shift.
In the AI era, context is not documentation around the architecture. Context is part of the architecture.
That includes bounded contexts, architectural decisions, standards, security constraints, domain language, APIs, data relationships and operational expectations.
The better this context is made explicit, the more effectively agents can operate within it.
From one requirement to a living system
The keynote included a practical example of how dramatically the shape of development can change.
Dave showed a piece of work carried out by one engineer working within a mob over 16 days — work he said would previously have required several teams over several months. Pasted text
The interesting part wasn’t simply the speed.
It was the flow of information.
A requirement moved into discovery and feature specification. From there, the process explored architecture, integrations, events, APIs, data changes, entities and threat models.
Humans reviewed the proposed solution.
The work was decomposed into epics and bounded contexts, implemented, tested and fed back into the graph. Defects and new learning didn’t sit at the end of the process — they flowed back through it.
Instead of treating analysis, architecture, development and testing as largely separate stages, the system created a connected feedback network. Pasted text
That is a much more interesting application of AI than simply asking:
How can we generate more code?
The better question is:
How can we create a development system in which humans and agents continuously improve their understanding of what should be built?
Old engineering disciplines become more important
There is an irony in all of this.
Some of the practices that could matter most in AI-assisted development aren’t new at all.
Dave highlighted several.
Intent. Don’t start by asking an agent to build something when the team doesn’t understand the customer problem.
Delegation. Agents need clear authority, scope and constraints. Delegation is an old organisational skill applied to a new kind of collaborator.
Context and boundaries. Domain-driven design, event-driven architectures, serverless-first approaches and clearly defined bounded contexts give agents a safer environment in which to operate.
Formal verification. If producing an implementation becomes cheap, being explicit about what constitutes a correct implementation becomes increasingly valuable.
Well-Architected by design. Instead of running an architecture review after software has been created, architectural principles can form part of the instructions and guardrails governing how agents build.
Observability. Production behaviour becomes another feedback mechanism, allowing the system to compare intended outcomes with what actually happened. Pasted text
None of those ideas arrived with generative AI.
AI changes their leverage.
What is the anatomy of a modern software engineer?
If everybody can generate software, what distinguishes an engineer?
Dave’s answer was not a particular programming language, IDE, model or framework.
In fact, being overly identified with a specific tool becomes increasingly limiting.
The modern engineer needs several deeper capabilities.
They need to understand quality and know how to define the conditions under which a system is considered correct.
They need strong mental models that let them reason about complex systems.
They need to be increasingly tool agnostic.
They need to improve the speed of decision-making, because waiting for decisions can easily become a bigger constraint than implementation itself.
And they need a frugal mindset: treating code as an operational liability and designing efficient systems rather than simply consuming more compute, tokens and infrastructure because it is available. Pasted text
This is why engineering remains different from simply building something.
AI will enable many more people — product managers, designers, domain experts and others — to create working software.
That’s a good thing.
But engineering brings the disciplines required to make those systems reliable, maintainable, secure, operable and sustainable.
The Value Flywheel in the AI era
The same principles also map naturally onto the Value Flywheel.
Clarity of Purpose
AI cannot compensate for a team that doesn’t understand the customer problem.
Starting with clear intent becomes even more important when implementation is almost instantaneous.
Challenge
As execution accelerates, teams need the psychological safety to challenge assumptions.
Engineers need to be able to say: this isn’t going to work — before an automated development system produces thousands of lines implementing a bad idea.
Next Best Action
Teams need access to the technology, platforms and capabilities that let them act quickly without continually working around organisational constraints.
Long-Term Value
Quality needs to be shared and explicit.
Architecture, guardrails, standards, observability and operational expectations must become part of the system itself rather than knowledge residing in the heads of a handful of experienced engineers.
Dave described this period as one of establishing the new norms and principles for the next phase of engineering. Pasted text
Code was never the point
Perhaps the most important message from the keynote came towards the end.
Software engineering was never fundamentally about typing code.
Code is an artefact produced while solving a problem.
And increasingly, code is cheap.
That makes the underlying engineering capability more visible, not less.
Understanding people.
Understanding systems.
Making good decisions.
Defining quality.
Creating feedback loops.
Managing complexity.
Knowing what to build — and having the courage to decide what not to build.
As Dave concluded:
Engineering is the pursuit of solving human problems.
AI will change the tools, workflows and operating models we use to do that.
But the underlying engineering mindset has survived every previous technology shift.
There is little reason to believe this one will be different.