Executive Summary

The rise of AI-assisted development isn't just changing how we write code — it's fundamentally reshaping how we should structure our engineering teams. After restructuring several 4+ person engineering teams into smaller units, I've discovered that the traditional model of consensus-driven development is not only outdated but actively harmful in our new AI-enhanced reality.

The Context Problem: Why Bigger Isn't Better Anymore

In the world of AI-assisted development, context is everything. Large language models and coding assistants perform best when they have clear, focused context about what you're building and why. But here's the problem: sharing context is expensive, and making decisions by consensus is tedious.

When you have four engineers debating the best technical approach, segmenting work, and trying to swarm on a problem, you're optimizing for yesterday's constraints. What we actually need today is two engineers who trust each other, agree on the approach, and will own the outcome together.

With agentic coding tools, these smaller units don't just maintain velocity — they often exceed it. The reduced communication overhead, JIT alignment sessions, and clearer ownership model creates an environment where AI assistants can be maximally effective.

The Product Trio Challenge

Many teams have adopted the "product trio" concept (popularized by Teresa Torres in her work on continuous discovery), which pairs a product manager, designer, and engineer to drive product decisions. While this model offers valuable benefits — particularly in discovery and user-centered design — it creates an unintended hierarchy problem.

The trio structure often relegates other team members to feeling like "implementers" rather than strategic contributors. In practice, three people make the big decisions while everyone else codes what they're told.

A New Model: Autonomous Dev Pairs with Strategic Alignment

Instead of the traditional trio, I've found success with a different approach:

Product and design should drive forward to define the destination and overall direction — the "what" and "why" of our efforts.

Development pairs should act with full autonomy and ownership to bring clarity to the "how," gradually bringing the fuzzy strategic picture into sharp focus through rapid iteration and feedback.

This model preserves the strategic value of product and design expertise while empowering engineering teams to make tactical decisions quickly. The result? Faster iteration cycles and higher-quality outcomes.

Practical Implementation: Making Small Teams Work

Team Structure

Decision-Making Framework

Avoiding the Knowledge Silo Trap

The most common objection to smaller teams is the fear of knowledge silos. But we already solve this problem at larger organizational scales. The same techniques work here:

The key insight is that demos aren't about "showing your work" or proving productivity — they're opportunities to get quick feedback from the broader team and maintain shared understanding.

Why This Matters More Than Ever

AI-assisted development has fundamentally changed the cost structure of software creation. The bottleneck is no longer typing code — it's making good decisions quickly and maintaining clear context.

Small, autonomous teams excel in this environment because they can:

Moving Forward

The transition to smaller engineering units isn't just about team size — it's about embracing a fundamentally different approach to software development. One where context clarity, rapid iteration, and autonomous decision-making take precedence over coordination and consensus.

As AI continues to transform our industry, the teams that will thrive are those that can move quickly, think clearly, and iterate rapidly. In my experience, that's much easier to do with two people you trust than with four people trying to agree on everything.

The future belongs to small teams making big impacts. The question isn't whether this shift will happen — it's whether you'll lead it or follow it.