# AI Is Making Systems Architecture More Consequential > As AI expands what people can build, the ability to design how the parts work together becomes more valuable. This is the architectural expertise I have built across my career. - Author: Kostas Karolemeas - Published: 2026-10-28 - Topics: systems thinking, software architecture, AI, engineering leadership - Canonical URL: [https://www.voxelperfect.com/writing/ai-is-making-systems-architecture-more-consequential](https://www.voxelperfect.com/writing/ai-is-making-systems-architecture-more-consequential) When I read [Sinead Bovell's LinkedIn post about the growing importance of systems thinking](https://www.linkedin.com/posts/sinead-bovell-89072a34_ill-say-it-again-and-again-we-are-entering-share-7520941258995965952-z8Xo/), my response was immediate: “Exactly. This is the era of the architect!” That is my interpretation of the shift she describes. As AI expands what people can build, I expect more value to accrue to people who can design how those capabilities work together in a real system. It is also a description of the expertise I have built over the years. My work has crossed banking, industrial systems, medical imaging, software platforms and enterprise AI. The technologies and constraints have changed. The architectural task has remained recognisable: understand the purpose, connect the parts, and take responsibility for the consequences of the design. ## Why this argument resonates now In [*The Rise of Systems Thinking*, published on October 26](https://sineadbovell.substack.com/p/the-rise-of-systems-thinking-5f5), Bovell argues that AI helps people work across boundaries that once separated professions. She expects the ability to understand interactions and consequences across those boundaries to become more valuable, while specialist expertise remains important. I see a direct implication for software. A working feature is increasingly only the beginning of the design conversation. Someone still has to establish how it fits into the organisation, which promises it makes to other systems, and what happens when its assumptions fail. AI can help with that work too: exploring alternatives, tracing dependencies and challenging a proposal. My argument is about the importance of the architectural capability itself. Better tools make it possible to consider more options; they also make it easier to introduce changes whose consequences extend beyond the immediate task. The ability to build a component and the ability to make a system work well together are related skills. Both need deliberate development. ## A sensible local decision can create a system problem Consider a service that retries a failed request. From the perspective of that service, trying again seems like a reasonable way to improve reliability. Now place it in a chain of services. If each layer retries independently while a shared dependency is overloaded, the attempts can multiply. A mechanism intended to recover from failure can deepen the failure. Google's [Site Reliability Engineering chapter on handling overload](https://sre.google/sre-book/handling-overload/) describes this problem and the use of retry budgets. It also explains why retries across multiple layers can cause a combinatorial explosion, and describes propagating a signal that a request should not be retried. This is a useful example of architectural reasoning. The implementation of each retry loop can be perfectly competent. Understanding the outcome requires looking at the interactions, available capacity and behaviour under stress. An AI coding tool might implement any of the individual loops correctly. It might also help identify the combined failure mode if given the relevant system context. The engineering responsibility is to make that wider question part of the work and verify the answer. The same reasoning applies beyond infrastructure. Imagine a proposed automation that lets a sales team produce customised offers much faster, while every non-standard offer still requires the same small operations team to review it. More output at the first stage can create a longer queue at the second. This is an illustrative scenario, not a measured customer result. It shows why I would assess completed, deliverable orders alongside the number of offers generated. ## Architecture connects business goals to technical choices Systems thinking becomes useful when it changes a decision. Suppose a customer wants immediate confirmation of an order. An asynchronous design may protect the system during traffic spikes, but the product must distinguish an accepted request from a confirmed order. That distinction affects the interface, customer expectations, support procedures and recovery when a downstream service fails. The architect needs to bring those decisions together with the people who understand them. A technically valid queue does not settle the customer promise. A compelling customer promise does not establish that the implementation can keep it. This connection between architecture and business goals has a long history. The Software Engineering Institute's [Architecture Tradeoff Analysis Method](https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/) evaluates architectures against quality goals and examines how those goals interact. Its process brings business drivers, stakeholder scenarios and architectural risks into the same evaluation. I find that a useful discipline for AI-enabled systems as well. Start with a situation the organisation cares about. Describe what acceptable behaviour means. Then examine the choices and their consequences together. A demand for faster response might conflict with a requirement for fresh data. Greater autonomy might reduce waiting while increasing the cost of an incorrect action. A more adaptable platform might ask more of the team that operates it. The architectural work is to make these trade-offs visible, test them and agree which ones the business can sustain. ## What years across different domains contribute My career has given me opportunities to work across the boundaries between engineering, product and business. I have built software, designed platforms, worked with customers and taken on founder and leadership responsibilities. Those are different perspectives on the same underlying question: what must be true for this system to succeed? I value that breadth because it gives me more ways to examine a proposal. I can look at an integration as an engineering dependency, a product commitment and an operational responsibility. Each view exposes different questions. Experience also needs limits. A pattern that worked in one domain is a candidate to investigate in another, not proof that it belongs there. The useful habit is to recognise a possible connection, identify what is different and involve the specialists who know those differences best. That is the architectural expertise I want to keep developing: sufficient depth to engage with implementation, sufficient breadth to see its context, and the judgement to know when another person's expertise is essential. ## The architect as a working capability When I say this is the era of the architect, I mean people who can turn a collection of capabilities into a coherent, operable system. That contribution can come from engineers, technical founders, product leaders and others, whatever their title. It needs contact with reality. Follow a request through the system. Test the failure path. Ask the person handling exceptions what the design assumes about their work. Check whether the measures of success describe the outcome the organisation actually needs. As AI expands the range of things we can attempt, I expect that ability to become more consequential. It is the thread connecting the work I have done across my career, and the contribution I intend to keep making: designing systems whose parts work together, whose trade-offs are understood, and whose behaviour serves a clear purpose. ## Sources - [Sinead Bovell's LinkedIn post](https://www.linkedin.com/posts/sinead-bovell-89072a34_ill-say-it-again-and-again-we-are-entering-share-7520941258995965952-z8Xo/), which prompted my comment and this article. - [Sinéad Bovell, *The Rise of Systems Thinking*](https://sineadbovell.substack.com/p/the-rise-of-systems-thinking-5f5), October 26, 2026: the original essay behind her post. - [Google, *Site Reliability Engineering*, “Handling Overload”](https://sre.google/sre-book/handling-overload/): retry budgets, overload handling and interactions across service layers. - [Carnegie Mellon University Software Engineering Institute, Architecture Tradeoff Analysis Method collection](https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/), February 14, 2018: evaluating architectural trade-offs against business and quality goals.