Blog

iSAQB Software Architecture Gathering

CTO/Architect, Co-Author of Continuous Architecture Books
Published on September 4, 2026

Continuous Architecture in the Age of AI: Murat Erder on Change, Technical Debt, and Accountability

1. The Continuous Architecture principles were developed long before today’s generative AI boom. Which of these principles has become more important because of AI, and has AI challenged any of your original assumptions?

Actually, the beauty of it is that all of the six principles are still relevant. This makes us quite proud since we laid out these principles more than 10 years ago. However, if you want me to pick, I can highlight the following:

Principle 2: Focus on Quality Attributes: The importance of quality attributes like performance, scalability, security etc. need no further explanation. What is interesting is the quality attribute of cost: understanding how to build agentic systems that are cost efficient is becoming ever more important in a market that is in constant change.

Principle 5: Architect for build, test, deploy, and operate: Building AI systems (or using AI to build systems) has again forced us to focus on building out efficient and reliable pipelines. This becomes more important the more aggressive you are in fully AI-native software development .

Principle 4: Architect for change. Leverage the “power of small.” In particular for building agentic systems the basics of modular self contained components (i.e. agents) is key. What this also relates to is how maintainable your system is. I think we will figure the impact of AI developed software on maintainability in a few years' time - it will not be a pleasant realisation.

The main change in our assumptions is that we were thinking about fully human driven processes. Now we have to consider a different world - but it is more about the 'how' than the core principles.

2. You raise the question of whether AI will finally force enterprises to sort out their data foundations. What makes AI a potential catalyst for this, and what role should architects play in that transformation?

If I say AI is only good as the data it works on, I will probably cause people to switch off due to how much the term is used. But there is truth in that. Even at the basic level, the amount of Confluence cleanup people are doing, so that the basic knowledge management agents can give correct answers, is fascinating. AI is forcing us to cleanup legacy documentation, which has been hanging around for a long time.

On the wider enterprise scale, the last 15 years has seen the creation of CDO organisations which have had mixed levels of success. AI is yet another demand on sorting out the same challenge. What makes such efforts difficult is more organisational than technical. Do not underestimate the impact of Conways law; which is reflected in Principle 6: Model the organization of your teams after the design of the system

In terms of architects' role in sorting out the data mess - it is about applying the principles, thinking about organizational ownership.

3. You mention the risk of “AI Technical Debt.” How is AI-generated technical debt different from the technical debt we already know, and are there warning signs architects should be looking for now?

At the code-base level there is the obvious challenge of managing AI generated code. If you architect first and then generate code, then you should be OK. If you generate code and then try to work out the structure - might as well throw it away and start again. One view I have is that AI will make architects out of all engineers - the skillsets will evolve and change.

At the enterprise level, there is the explosion of EUAIAs (I just made that up, but it stands or End User AI Agents). Key questions are: How will we deal with the plethora of AI agents that make (or propose) decisions? What is the data provenance of those decisions? I find the work done on context layers that capture tacit knowledge in making decisions quite interesting.

These are just two examples; there are additional issues like - AI embedded in your SaaS solutions; chaining of agents and fanout of mistakes etc.

4. How does AI change the timing of architectural decisions? Does it give architects more freedom to defer decisions and experiment, or does it make early architectural guardrails even more important?

AI definitely gives freedom to experiment with new product ideas and rework them based on feedback. However, I believe the key architectural decisions to build a sustainable product are still relevant. What does change is the speed of feedback loops - which will impact the way we work.

A related topic is cognitive overload. If all we are doing is making decisions, then how many of these decisions can we make without relegating them to AI?

5. Looking ten years ahead, which part of the architect’s role do you think AI is most likely to take over, and which responsibility would you be deeply uncomfortable handing over to AI?

Everything is evolving so quickly, I doubt I can think ten years ahead; but first of all, the architect's role will become even more important. (Sidenote: we always claim that architecture is a skill not a role). As I said before, the skillsets of engineers will naturally evolve to thinking more architecturally.

In terms of activities that architecture requires - documenting systems, dependencies and architectural decisions will become much easier and delegated to AI. Architectural patterns to deal with key quality attribute requirements will also be easier to identify and compare. Some of these can be delegated to AI - as long as we explicitly capture architectural decisions and who made them.

But at the end of the day, someone (or team) has to be accountable for the architecture of the system. They are the ones that can take pride in a well working system or sweat it out in front of the business when things go wrong. That cannot be delegated to AI.

Many thanks to Murat for the great interview!