GenAI-based software delivery needs a fast flow architecture

genAI development   fast flow   microservice   socio-technical architecture   design-time coupling   testing   deployment pipeline   deployment   observability   devops   team topologies   idea to code   decision making   testability   deployability   modifiability   evolvability  

---

---

GenAI doesn’t change the fundamentals of software architecture. In fact, GenAI-based software development is an amplifier of organizational capabilities, not a replacement for sound architectural principles. It can make high-performing organizations even better and make low-performing organizations worse. For organizations adopting GenAI-based software delivery, fast flow is therefore not optional, but essential.

This article explores what GenAI-based software delivery means for architecture and organizations. It begins by revisiting the need for fast flow and why it remains the defining characteristic of high-performing software delivery, regardless of tooling. It then introduces the concept of a fast-flow socio-technical architecture and the architectural characteristics that enable it. From there, the article examines how these same characteristics support GenAI-based software delivery. It looks specifically at the role of the microservice architecture in providing the boundaries and fast feedback that GenAI-based coding agents need. Finally, it poses a practical question for engineering leaders: whether their current socio-technical architecture is ready for GenAI-based software delivery.

Let’s start by looking at fast flow.

The need for fast flow

High-performing software development organizations are ones that practice fast flow: the continuous delivery of value to customers combined with continuous learning and improvement.

Let’s look at how to achieve fast flow.

Fast flow requires a socio-technical architecture that supports it

Fast flow in turn requires a particular kind of socio-technical architecture.

That’s a socio-technical architecture consisting of two parts:

• An organization structured using Team Topologies that practices DevOps (as defined by the DevOps Handbook)
• A fast flow architecture that enables Team Topologies and DevOps

Let’s focus on the second part: the fast flow architecture.

The characteristics of a fast flow architecture

As I describe in Chapter 5 of Microservices Patterns, 2nd Edition, a fast flow architecture is an architecture that promotes team autonomy and optimizes the two inner and outer developer loops.

The outer loop is the change-deploy-analyze loop, which is the application’s delivery workflow. The change step consists of design decision-making phase followed by the inner edit-test-analyze loop - the developer’s implementation workflow.

An architecture enables fast flow by satisfying these five quality attributes:

• Modifiability - reflects how easily changes can be made to the application. It is achieved through designing an architecture that is loosely design-time coupled and cohesive. Loose design-time coupling increases the likelihood that changes are localized to a small part of the application, reducing cognitive load and enabling team autonomy by reducing the need for coordination between teams. See Andrew Harmel-Law’s architecture advice process and fast flow for more on decision-making and team autonomy.
• Evolvability - describes how easy it is to upgrade the application’s technology stack. For large applications, it is achieved by using a multi-component (microservice) architecture which allows for most architectural decisions to be made separately for each component - often within a team - and for upgrades to be done incrementally.
• Testability - reflects how easy and fast it is to verify that a change is releasable. Testability is achieved through designing an architecture that is loosely design-time coupled, loosely build-time coupled, and is verifiable using fast-running automated tests that run locally on a developer’s laptop. Loose coupling reduces both the scope and impact of a change, which reduces the number of tests that need to be run. Fast-running tests accelerate both the inner and outer development loops, resulting in faster feedback.
• Deployability - reflects how easy and fast it is to deploy a change into production. Deployability is achieved through designing an architecture that supports deployments that are automated, fast, reliable, can be done without affecting SLAs, and can be automatically rolled back when there’s a problem. High deployability accelerates the outer development loop by reducing the time it takes to get feedback from production and from users.
• Observability - reflects how easy it is to understand the behavior of the application and its users. Observability is achieved through designing an architecture that implements the observability patterns. Observability enables teams to understand how their code is behaving in production and how users are using it. It’s essential for fast feedback in the outer development loop and supports deployability by providing the telemetry that determines whether a deployment is successful or not, and whether a rollback is needed.

Together these five quality attributes enable fast flow by optimizing the inner and outer development loops and by promoting team autonomy. They are essential for high-performance software delivery organizations. Let’s now see how they are also required for GenAI-based software delivery.

Why fast flow architecture is essential for GenAI-based software delivery

The quality attributes that enable fast flow by humans also support GenAI-based software delivery. Moreover, there are characteristics of GenAI-based development that actually require these quality attributes even more strongly.

Let’s explore each one in turn.

Modifiability reduces the scope of changes

Modifiability makes it easier for GenAI coding agents to make changes to the application. Because changes are localized, the coding agent can focus on a small part of the application. What’s more, cohesion means that once the code for the change has been located, there is less extraneous code to consider. There’s less code that needs to go in the context window and fewer tokens to process.

Conversely, without modifiability, GenAI coding agents struggle to localize changes and are forced to reason about large, tightly coupled parts of the system. As a result, the agent’s context window fills with unrelated code, increasing token usage, reducing accuracy, and raising the likelihood of unintended side effects. Instead of accelerating delivery, agents amplify architectural coupling and increase the risk of widespread regressions.

Evolvability reduces the impact of changes

Evolvability makes it easier for GenAI coding agents to upgrade the application’s technology stack. The impact of a change is localized to a small part of the application - i.e., a single component/service - there’s less work for the agent to do. Once again, there’s less code that needs to go in the context window and fewer tokens to process.

In an architecture that lacks evolvability, even small technology upgrades have a system-wide impact. When GenAI coding agents attempt such changes, the blast radius quickly expands beyond a single component, requiring broad coordination and extensive validation. This negates the benefits of automation and often forces changes to be batched, slowing delivery and increasing risk.

Testability provides fast feedback and guardrails

Testability is critically important for GenAI-based software delivery. There are two reasons why: guardrails and fast feedback.

Testability enables automated testing: the guardrails for coding agents.

Testability enables GenAI coding agents to use TDD. The tests provide essential guardrails for coding agents. They constrain agent behavior by defining what correctness means, forcing agents to make progress through verifiable steps rather than speculative code generation. The deployment pipeline further constrains agent behavior by enforcing quality gates that must be satisfied before a change can be deployed to production.

Without strong testability, GenAI coding agents lack fast, reliable feedback on whether a change is correct. Errors propagate further through the delivery pipeline before being detected, if they are detected at all. In this situation, agents can generate changes faster than the organization can verify them, turning CI into a bottleneck and production into the first meaningful feedback loop.

Not only does testability enable automated tests as guardrails, but it also provides coding agents with fast feedback.

Testability provides fast feedback in the inner and outer development loops

Testability enables the tests written using TDD to execute quickly. It provides fast feedback in the inner development loop when the coding agent is implementing a change. It also reduces the number of tests that need to be run to verify a change, which, like modifiability, reduces the amount of code and test results that need to go in the context window and the number of tokens to process.

Testability also accelerates the outer development loop, which means the coding agent can get feedback faster from production. What’s more, testability means that the deployment pipeline can handle the volume of changes being made by multiple coding agents. Without testability, the deployment pipeline becomes a bottleneck. Either feedback is delayed, or changes are batched, which complicates troubleshooting test failures and production outages.

Deployability provides fast feedback and safe deployments

Deployability is critically important for GenAI-based software delivery because it provides fast feedback in the outer development loop. It also ensures that deployments are safe. If the agent makes a mistake that’s not caught by a code review, deployability ensures that the deployment can be automatically rolled back when there’s a problem. Deployability acts as a guardrail that prevents coding agents from causing production outages.

In architectures with low deployability, deployments are slow, risky, or require manual coordination. When GenAI coding agents increase the rate of change, these constraints force changes to be queued or bundled together. This delays feedback, complicates rollback, and increases the likelihood that a single agent-generated error results in a production incident.

Observability provides fast feedback and understanding of behavior

Observability is essential for GenAI-based software delivery because it provides fast feedback in the outer development loop. It ensures that deployments are safe by providing the telemetry that determines whether a deployment is successful or not, and whether a rollback is needed. It’s yet another guardrail that prevents coding agents from causing production outages. Observability also provides the coding agent with an understanding of how the code is behaving in production and quickly identifies issues that need to be addressed.

Without effective observability, the impact of agent-generated changes in production is difficult to assess. Failures take longer to detect, root causes are harder to identify, and corrective actions are delayed. In such environments, GenAI coding agents can inadvertently repeat or compound mistakes because the system provides no clear signal about what is actually happening in production.

Fast flow architecture as the foundation for GenAI-based software delivery

Taken together, these architectural characteristics are how a fast-flow architecture supports GenAI-based software delivery. Architectural boundaries and loose coupling constrain the scope and impact of agent-generated changes, while fast, automated feedback loops provide control and correction. In such environments, GenAI coding agents can increase the rate of change without overwhelming teams, pipelines, or production systems. By contrast, introducing GenAI agents into a slow-flow architecture - one that lacks these qualities - increases change velocity without increasing the system’s ability to absorb it. Feedback is delayed, changes are batched, blast radii expand, and risk accumulates faster than it can be managed. This contrast sets the context for understanding the role that architectural structure plays in enabling GenAI-based software delivery at scale.

Why the microservice architecture matters for GenAI-based software delivery

The monolithic architecture supports fast flow for small applications developed by a small organization consisting of a few teams. However, fast flow at scale - a large application developed by large organizations consisting of many teams - often requires the microservice architecture. There are two reasons why:

• Greater team autonomy - teams can work autonomously on different parts of the system simultaneously without stepping on each other’s toes
• High-capacity deployment pipelines - by using per-service deployment pipelines, the architecture can handle the volume of changes being made by multiple teams It avoids a key limitation of a monolithic architecture, which has a single deployment pipeline that is likely to become a bottleneck as the organization and application scale.

Let’s now look at how GenAI-based software delivery amplifies the need for the microservice architecture.

How GenAI-based coding agents scale software development

GenAI-based coding agents effectively scale software development. The rate of change is significantly higher than if humans were doing the work. A single developer might even use multiple coding agents to help them with their work. As a result, GenAI-based software delivery creates some of the scaling challenges that the microservice architecture is intended to address.

Let’s look at how the microservice architecture supports GenAI-based software delivery.

Service boundaries act as guardrails for coding agents

For GenAI-based software delivery, the microservice architecture provides an important guardrail. By constraining a coding agent to work within a single service, it enforces clear ownership boundaries and limits the scope of change by default. This aligns service boundaries with Conway’s Law and prevents agents from making system-wide changes that ignore ownership boundaries and/or require cross-team coordination.

Of course, an agent can still make changes that affect other services - for example, by changing an API contract or adding collaborators. But such changes are explicit and therefore visible, reviewable, and governable. As a result, architectural boundaries replace informal social cues as the primary mechanism for governing agent behavior at scale.

Small codebases reduce agent working set size

The microservice architecture breaks down a large application into a set of smaller, loosely design-time coupled, independently deployable services. As a result, the coding agent can focus on a single service when making a change. Since a service has a small code base, it’s easier for a GenAI coding agent to work with. There’s simply less code to comprehend, less code to go in the context window, and fewer tokens to process.

Faster feedback from local test execution

The small code base of a microservice also means that the service’s tests execute quickly. This provides fast feedback in the inner development loop when the coding agent is implementing a change.

Faster feedback from independent deployments

Since each service has its own deployment pipeline, the deployment pipeline has less work to do due to the smaller code base. It’s also handling a smaller volume of changes - most likely from one small team and their coding agents. As a result, deployments are fast and provide fast feedback in the outer development loop. Other teams and their coding agents can independently deploy their services without affecting each other.

Taken together, service boundaries, automated tests, deployment pipelines, and observability form a control system for GenAI-based software delivery. They continuously sense the effects of changes, compare observed behavior to intended outcomes, and apply corrective action by rejecting, rolling back, or guiding subsequent changes. Without these fast, automated feedback loops, coding agents can amplify errors faster than the organization can detect and correct them.

Fast flow architecture, microservices, and the GenAI coding agent experience

A microservice architecture with these characteristics - modifiability, evolvability, testability, deployability, and observability - provides the foundation for GenAI-based software delivery at scale. The architecture constrains the scope and impact of agent-generated changes while providing fast, automated feedback that enables correction at speed. By offering clear service boundaries, independent deployment pipelines, and localized feedback loops, it allows GenAI coding agents to operate in parallel without overwhelming teams, delivery pipelines, or production systems.

Just as fast-flow architecture improves developer experience by reducing cognitive load and accelerating feedback, it also defines the GenAI coding agent experience. Small codebases, explicit boundaries, fast tests, and reliable deployments determine how effectively agents can reason about changes, validate correctness, and make progress. In contrast, introducing GenAI coding agents into a slow-flow architecture degrades both developer experience and agent experience, increasing friction, batching, and risk rather than sustainable throughput.

Are you ready for GenAI-based software delivery?

A key question every engineering leader should be asking themselves is: “Is our socio-technical architecture ready for GenAI-based software delivery?” Answering this question requires more than evaluating individual tools or experimenting with coding agents. It means examining whether the organization’s team structure, architectural boundaries, and delivery mechanisms can safely absorb a much higher rate of change. If the answer is “no”, then the challenge is not adopting GenAI, but transforming the socio-technical architecture so that it supports fast flow through clear boundaries, fast feedback, and effective guardrails. Only then can GenAI-based software delivery be used to accelerate outcomes rather than amplify existing bottlenecks and risks.

Need help with modernizing your architecture?

I help organizations modernize safely and avoid creating a modern legacy system — a new architecture with the same old problems. If you’re planning or struggling with a modernization effort, I can help.

Learn more about my modernization and architecture advisory work →