#engineering #ai #architecture - 9 mins read

Is AI changing the boundaries of architecture and engineering?

Is AI changing the boundaries of architecture and engineering? A question we explored at Leeds Digital Festival, 2026.

Historically, being a great architect has meant years of lived experience:

👉 Building systems

👉 Making mistakes

👉 Doing things the wrong way

👉 Understanding the trade-offs

👉 Developing judgement

AI is starting to challenge that. Knowledge is becoming more accessible than ever and engineers are implementing code faster than ever.

We invited four leaders to explore what this means for both engineers and architects.

The panel:

Christina Burge: Staff Ecosystem Architect at Arm, a British semiconductor and software design company. Christina looks at what Arm builds, why they are building it, and how their partners might use their technology.

Matthew Clark: Head of Architecture at the BBC. There are a thousand engineers at the BBC building all kinds of things such as iPlayer, BBC News website, and more. Matthew is the Architecture Strategy Lead for the BBC's newly merged product and technology division.

Martin Thwaites: Principal Developer Advocate at Honeycomb.io, an observability platform. Martin works with organisations all over the UK on understanding production systems. Before Honeycomb, Martin built a bank in London, worked for e-commerce platforms, and ran the teams at Manchester Airport for a number of years.

Andy Norton: VP of Engineering at Flipdish, an Irish tech unicorn. Flipdish is an all-in-one restaurant management platform. It handles orders, payments, staff tools, and marketing to keep everything running smoothly. Before that, Andy was Head of Engineering at cinch.

Key-takeaways (TL;DR):

AI is making implementation cheaper, but it doesn't remove the need for judgement.
As engineers work at a higher level, architectural thinking becomes more important.
Verification and context become bottlenecks when generation becomes cheap.
Organisations need to encode their constraints, decisions and knowledge so both people and agents can use them.
The advantage will come from turning output into outcomes.

Questions:

This is an abridged version of the conversation, which was approximately one hour long. We’ve opted to remove who said what, to give you a general overview of what was discussed.

1. Historically, it took years of lived experience to become a great architect. What seems to be changing now? What have you observed recently?

AI cannot compress the lived experience required to judge implementation.

Many practitioners now rely on AI to build faster. Where they could once build a few options in a month, they can now build ten.

One thing AI cannot compress, however, is the experience an architect needs to understand how systems work. A good architect has lived experience of the patterns that come from production. They can recall something they built two or three years ago that users hit, that fell over, and that went terribly wrong.

Today, that experience is important because AI will not tell you whether its output is any good.

Experience used to be built from the ground up. To make anything at all, you had to learn the basics of whatever language you were speaking. AI has removed that step, and with it one of the routes to experience.

The architect's role is becoming even more important.

With so much change going on inside organisations, you need an architect who can step back and look across it all, asking:

👉 What's really happening?

👉 What is the business trying to do?

👉 What are competitors doing?

👉 Where is the technology going?

👉 Are we going in the right direction?

👉 Are the teams talking to each other?

👉 Are we picking the right thing, or are we just picking the easy thing?

The architect role matters more with AI because more is being built. There are more systems, more data, and more to explain to leadership.

For engineers, AI multiplies whatever skills they already have.

One panellist described AI as a '10x tool'. If your skills are minus one: multiply minus one by ten and you get minus ten.

If you are an experienced developer who thinks through problems, and you have taste in how things are built and come together, AI can multiply your abilities and make you much faster.

But the reverse is true. Without that experience, the same tool lets you write something incredibly bad, incredibly fast.

2. Is architectural judgement becoming a capability every engineer needs, or does it remain a specialist skill in your organisation?

More agents mean engineers need to start thinking like architects.

Before the AI boom, the architect was never designing every last bit. Engineers were doing plenty themselves, and the architect oversaw the system rather than designing all of it.

Because engineers now use agents, they're producing more. That means they can become less involved in the fine details and begin to think higher up, closer to architectural thinking. Working at that level, engineers must be able to understand the work they hand to agents and be able to explain what it is doing.

As engineers level up, there's now even more for one architect to look across. As a consequence, the architect also has to be less detailed to keep up.

Fundamentally, the output of an architect is their understanding.

A good architect will make sure people have enough context to understand how their part of the system needs to work alongside everything else.

At leadership level, that means being able to explain what is happening across teams and systems, what is driving it, where the risks are, and where the organisation may be underinvesting.

3. What’s a common assumption about AI and architecture that you’d push back on?

Assumption one: Everyone is already doing the sophisticated version.

There is a lot of talk on Twitter and LinkedIn about spec-driven development and building harnesses to one-shot a specification into production. Most engineering teams are doing none of it.

The panel felt the one-shot idea is debatable and un-agile. Where spec-driven development is working, it looks agile: a two-page document, Gherkin-style features, built up iteratively.

The more natural version is conversational. The model joins a Slack channel where several people can ask ‘what about this?’, a stakeholder can ask ‘what is this?’, and the team works through security, then the API, a bit at a time.

Assumption two: A technology recommendation is a decision.

AI will happily hand you an opinion. It’ll say use this technology, do it that way. But an opinion is not a decision. When people treat it as one, they hyper-optimise, arguing over whether it should be TypeScript or Ruby, a choice that matters less than ever. The conversation stays on programming, when it should be on how teams and systems fit together.

As one panellist put it, AI is ‘very good at giving you a very average answer’. Lived experience is what tells you whether that answer will "stay up when it's hit by ten thousand people instead of the five you tested with".

Assumption three: The model can check its own work.

AI is confidently wrong and bad at marking its own homework. It needs reviewing. To know what good looks like, that reviewer needs constraints and rules, which are worth codifying.

4. As software gets cheaper to build, where are you starting to see new bottlenecks appear? How are they changing the way engineering and architecture teams work?

Verification is the new bottleneck, but nobody is hiring reviewers.

What has not been solved is verification. AI has pushed everything to the pull request, yet there is currently no verification boom.

Context is becoming one of the most valuable things you can build.

Building important context should start with verification: watching real usage to see whether the system behaves as expected, then checking dashboards and metrics.

Then, what you learn is worth codifying: engineering constraints, principles, architecture decision records (ADRs), and who in particular is currently solving a problem. At one organisation, every team keeps a Notion database. As they learn, they add ADRs, so the database grows over time. On day one, a joiner can understand the technology, who the users are, what stops them every day, and the current constraints on delivery.

Diagrams don’t always match what happens in production.

One panellist used to call a diagram the tube map, with different coloured lines for internal and external traffic. They spent hours making sure the lines did not cross. Soon they learnt that once the system got into production, things were completely different.

That gap is a bottleneck. Not enough people have the access or the knowledge to ask what actually happens, so they fall back on documents. And now AI relies on those documents too.

We are finally writing documentation, but for the wrong reason.

The wrong reason is AI: we document to give our own prompts context. DORA (DevOps Research and Assessment) found in 2023 that teams with high-quality documentation had 25% higher team performance. The same research found that businesses are generally rubbish at it.

Once other parts of the business join up their documentation, you get closer to a system where you can ask anything. So whilst documentation guides your prompts, it can also benefit your business and colleagues.

For the panellists, agents already put documentation to work in two practical ways:

👉 Bad search: everybody knows Confluence and SharePoint search are rubbish, but point an agent at both and it finds the work somebody else already did.

👉 Decision timelines: an agent builds them from ADRs and Slack. Ask why we picked this technology, and it traces it. For example, in 2024 we thought this, then somebody in Slack said that.

Agents that understand past decisions are close, but not quite there yet.

With the right documentation, you could have an agent that knows every reason why certain things are not done, and their consequences. But good documentation is rare.

Long context is also still unreliable. Models forget key things, including instructions you told them to never break. They want to give you an answer even when they do not know, so you get something surface-level plausible.

5. Are there problems architects are dealing with today that simply didn’t exist five years ago? What happens if we fail to address them?

AI problems come from misuse.

Many new problems come from misuse of AI, and not the malicious kind. People do not understand what AI has done for them. Because of this, organisations are wading through far more ‘slop’. A consequence of this is building things the organisation cannot join up or does not need, and rebuilding things it already has.

That same lack of understanding has changed the shape of the pull request. It’s now much harder to understand what led to change, and what design decisions people went through.

A good example of this is the principle ‘Don’t repeat yourself’ (DRY). Now it’s normal to write code 17 times with small variations, when it is still better written once with a few extra parameters.

Pain used to be the brake.

Before, three weeks to develop something was a pain, so instead you’d consider buying something off the shelf. Now the pain has gone, so what is stopping us?

What should stop us is ownership. Before taking it on, consider operability, maintainability, and innovation.

Security by obscurity is over, because AI does not get bored.

Security by obscurity has worked for decades because people cannot be bothered to try every single one of your endpoints. AI can be bothered because it doesn’t get bored. In two years, we may look back and say how naive we were.

6. Five years from now, what do you think will separate the highest-performing engineering organisations from the rest?

The best will not mistake output for productivity.

The panel recommended three diagnostic questions:

Are you more productive, or did you just do a lot?
Have you produced something of value?
Is it joined up across your business?

AI has the potential to accidentally create a lot of silos. Instead of going to talk to another team, you may decide you do not need to, because the model will build it for you.

The best organisations can quickly pivot.

We keep falling into the episodic change trap. We have a new tool, so this is how we work now. But change does not stop. Even the frontier labs have no idea what happens next. The winners will be the ones that evolve.

Some organisations can quickly move money and people, and pivot. Others cannot, because of cumbersome processes and politics.

The best teams stop caring about code and care more about outcomes.

Code and languages may matter even less in five years. But what will remain is whether the thing you produced did the thing you wanted. High-performing teams hire people who solve problems, who are not hung up on tabs versus spaces, and who can step back to think about outcomes.

Two engineer archetypes are pulling ahead.

The first is the engineer who is good at asking questions. They can ask an AI 400 questions, and it will never get bored.

The second is the engineer with a product mindset who can use an LLM (large language model) to understand what problem the business is trying to solve. They know the goal is the outcome and the impact on the business.