One thing people keep telling us when talking about AI is, that AIs can’t do software architecture well and we’ll always need humans to do that – thus all developers will need to become architects. While I’m not sure that is true (in fact – most software developers don’t do architecture well either), I actually believe this statement is an answer to the wrong question. Let’s find out why…
Raison d’être for software architecture
Why do we need architecture at all? Why are we going through the hassle of designing software systems with UML charts and use case diagrams and all that stuff? The most important things are:
- Communication: We use architecture to communicate the inner workings of the system to fellow engineers. A well designed architecture limits the number of “things” an engineer needs to know and understand in order to effectively develop in the context of our system.
- Futureproofing: We design our software with extension points in mind, because we know a lot of the life time of the software is spent in maintenance mode and we plan ahead for that. Not doing so might end up costing us dearly, when a trivial feature wish of our product manager spirals into a multi month multi person development effort and endangers the stability of the whole system.
Both of these are essentially safeguards against skyrocketing maintenance and development costs in the future. Notice how I left out things like – e.g. – “performance”? For one: Performance is not an intrinsic property of an architecture. In fact, one could argue that you most likely get the best performance out of a software by avoiding the costs associated with architecture altogether. Bring out the assembler and run with it, no architecture needed (or at least not much in the way of what we would consider a traditional architecture). I also conveniently left out system design as a whole – we’re just considering a singular software, which may be part of a larger system. Thus: Architecture is a tool that is geared towards software development where the act of programming the software is the main cost driver, so if we look at the (very simplified!) cost distribution for developing a software product it would look somewhat like this:
I’m oversimplifying things dramatically, but that’s important to make the point. Development takes up most of the time and requires most of the money. That’s why it is a good idea to ensure the money is well spent – if we increase costs by 10% the impact on the TCO of the software is going to be huge (as opposed to spending more on requirements). So we better put some thought into what we build and use all tools at our disposal to accelerate development. Now – if we get to a point where writing the code is essentially “free” (at least compared to today), that cost distribution would flip:
All of a sudden changes to the existing system are cheap and can be done in mere days, where we would have needed months or more before.
Consequences
This effectively means, that the two most important reasons why we do architecture today are arguably no longer valid:
- If code is an artifact that can be produced (at decent quality!) at a cost approaching relative zero (we’re talking about a 80 – 95% reduction in cost), then rewriting that code, when requirements change, suddenly is a good option. We can then choose solutions that actually fit the mix of requirements we have at any given time, instead of planning for extensions and trying to shoehorn our changed requirements into those (because anything else is prohibitively expensive).
- If we assume, that code is only ever read and written by AI systems that can easily have most of the software’s code in their active memory (“context”) at any given time there is little need to design the system with abstractions in mind, that limit the exposure for an engineer. Note that this is a realistic development – as of March 2026 we get Claude Opus 4.6 with a 1M token context window – this is huge and we can expect the context windows to expand further in the future.
Looking at the “new” cost distribution we can see the elephant in the room though: Thorough requirements get more important (relatively!) as does QA – at some point we have to make sure, that the software built by our agents actually solves the correct problem, and we also have to ensure, that our agents are fed with good enough descriptions of what we want of them. Both of these are issues, where I feel the industry is still woefully under prepared for. When discussing AI with clients nowadays, they are super eager to get something into the hands of their engineers and most discussions revolve about: “How is this going to impact my IP”, “Developers must review all code produced” (spoiler: They can’t and they won’t!). “The tech must ensure, that our code is not used for training” (possible for most tools, but does it matter?). IMHO all these bark up the wrong tree and assume the wrong things.
- Code is essentially WORTHLESS*. The value of a company’s IP, as far as code is concerned, is a direct function of how long it would take a competitor to rebuild the product from scratch with zero knowledge to a comparable standard. The operating principles for most products are either well known (“An ERP system”) or are based on scientific work, which was most likely ingested by AI systems during their training. Thus: The act of rebuilding the software part of a product is trivial nowadays and doable in a manageable amount of time, resulting in IP being worth a lot less than it used to.
- Execution and speed is what matters. Being able to hit the market with your product fast gives you an edge. Having a suitably polished product matters. Convenience for the user matters. Solving the problems of your user base matters.
Both of these points feed directly into the argument I made earlier: QA & Requirements are the key ingredients for success. Code is not. Architecture is not.
* This applies to your generic, run of the mill software, which is probably 80 – 90 % of the software out there (guesstimate!).
And that means?
I argue, that modern AI makes a lot of nitty gritty architectural work obsolete. While we still need to do thorough systems design and systems architecture, the design of the software components that run the system actually does not matter that much anymore, since software is so malleable (to the extend we might as well call it “liquidware”). Our systems on the other hand are hard and expensive to change – they might comprise of custom hardware, where we have to keep the population in the field in mind, they might be interfaces to other systems which are slow to adapt, they might have constraints towards scalability that can’t be solved with software alone. These are properties that are intrinsic to the systems we build and no amount of AI is going to change that.
All this does not mean, that it’s not necessary to have an architecture – far from it. In the end the person that operates the AI still has to have a model of the software in their mind, so they can meaningfully interact with it. The big BUT is, that we can always change it if we think a different model suits our needs better. In the end software “architecture” might become more like what a wise architect told me two decades back: “We should not call it architecture, we should call it gardening – the act of evolving a thing, if needed with a bulldozer, so that the result is beautiful.” … this quote has aged like fine wine for me, even though I still think that “Software Gardener” is decidedly less sexy than “Software Architect”.
Post Image by Sean Pollock via Unsplash