Why AI forces us to return to small teams.

Over the past twenty years, software development has become increasingly complex. Not just technically, but especially organizationally.

Where small teams once built complete products, today we often see teams of ten or more specialists: front-end developers, back-end developers, DevOps engineers, testers, UX designers, data specialists and a Product Owner. On top of that come Scrum Masters, architects and an ever-growing number of coordination structures.

This way of working emerged for good reason: software became more complex, organizations grew and risks needed to be managed.

But in many organizations, this has led to a new form of inefficiency: the coordination tax.

Teams spend a significant portion of their time not building products, but coordinating work. Stand-ups, refinements, sprint plannings and cross-team synchronization are intended to improve collaboration, but in practice often create a heavy process layer.

Ironically, that is exactly the problem Agile once set out to solve.

The paradox of modern agile teams

Many organizations today work according to frameworks like Scrum or SAFe. These methods have delivered value, but in enterprise environments they have often evolved into elaborate process machines.

The result is a paradox.

Although teams have grown larger to deliver more speed and quality, effective productivity often actually decreases. As teams grow, the number of communication lines also grows exponentially.

In a team of ten people, there are 45 possible communication relationships. In a team of four, there are only six.

The consequence: a large portion of time is spent on coordination rather than creation.

This raises an important question: are we still organizing software development the right way?

AI shifts the bottleneck

The rise of AI coding assistants is fundamentally changing the playing field.

For decades, the speed of software development was largely dependent on how many people could write code. Today, that is changing rapidly. AI accelerates writing code, generating tests and even analyzing existing systems.

This means the bottleneck is shifting.

No longer: who can build this? But increasingly: are we actually building the right thing?

As execution becomes cheaper and faster, scarcity shifts from hands to insight.

The most important value in software development then no longer lies in writing code, but in understanding the problem, designing the right solution and sharply defining what needs to be built.

From large teams to a Lean Core

This shift makes a different team model possible: the Lean Core.

Instead of large, highly specialized teams, a compact core team of very experienced professionals emerges that uses AI as a multiplier.

Such a team ideally consists of four complementary roles.

Product Owner Responsible for strategy, priorities and business value. The Product Owner determines where the product is heading and which problems are most important to solve.

Product Architect The linchpin between business and technology. This role translates strategic goals into concrete product logic, data models and functional architecture.

Product Engineer An experienced developer who uses AI tools to rapidly deliver functionality. The Product Engineer thinks not only in code, but also in product behavior and user interaction.

Product Designer Responsible for user experience and product behavior. In a world where building goes faster, good UX design becomes even more important to prevent teams from building bad products faster.

Together, these four roles form a small, senior team responsible for the complete product: from strategy to delivery.

The rise of the Product Architect

In many organizations, the role that fulfills this bridging function has actually weakened in recent years. Traditionally, this role was often filled by a Business Analyst. In Agile environments, however, that function has often disappeared or been absorbed into the Product Owner role.

In practice, this proves problematic. Product Owners rarely have the time or technical depth to fully work out complex product logic. Developers therefore regularly make decisions about functionality or data structures themselves, often driven by technical considerations rather than business logic.

The Product Architect role emerges at precisely this intersection. In a world where AI generates the code, this role becomes the ‘Single Source of Truth’. AI is only as powerful as the instruction it receives. The Product Architect designs the high-quality blueprint that drives the AI models. Without this sharp definition, AI merely builds the wrong things faster.

The Product Architect:

• Designs the functional blueprint: The source from which AI models draw to generate the solution.
• Structures business logic and data flows: So that technology supports business goals rather than obstructing them.
• Defines small, clear units of value: That can be directly realized by the Product Engineer with AI support.
• Guards consistency: Ensures that strategy, technology and design remain aligned in every iteration.

In a world where AI increasingly takes over execution work, true craftsmanship shifts to this form of product thinking.

From Scrum ceremonies to continuous flow

As teams become smaller and execution becomes faster, the development process also changes.

Many organizations still work with fixed two-week sprint cycles. That model was useful when development cycles were longer and releases were harder to organize.

But when code can be generated and tested faster, a different rhythm emerges.

Instead of fixed sprints, a continuous flow emerges in which teams continuously work on small, well-defined units of value.

A simplified cycle looks like this:

Define → Architect → Generate → Validate → Iterate

The emphasis shifts from ceremonies to clear design and rapid validation.

This demands more sharpness in upfront thinking, but eliminates a large part of the process overhead that slows down modern software development.

The real productivity gain

The biggest impact of AI is probably not in faster coding, but in reducing organizational friction.

Smaller teams have fewer handoffs, fewer meetings and fewer dependencies between specialists.

In a team of four people, there are only six communication lines. In a team of ten, there are 45.

That difference translates directly into speed and focus.

The productivity gain is therefore not just in technology, but especially in organizational design.

From process rituals to craftsmanship

Over the past ten years, organizations have tried to manage software complexity by adding more roles, more processes and more coordination.

The rise of AI shows that a different approach is possible.

Not larger teams, but smaller teams with more seniority. Not more process steps, but clearer product thinking.

In a world where code is increasingly becoming a commodity, the real scarcity shifts to people who understand what needs to be built and why.

The organizations that invest in this, and dare to let go of what is no longer needed, will gain an enormous advantage.

The future of software development is not about more people.

It is about smaller teams making better decisions.