The agents can work in parallel. I can't.

What happens when one person can suddenly own work that used to require an entire product team?

Four terminals, one brain

Late at night, I often have three or four terminal windows open, each with an AI agent working on a different part of Rawi. One might be debugging, another implementing a feature, a third testing somewhere else in the app. Work that used to happen sequentially — or across several people — now happens in parallel.

For a moment, it feels almost superhuman.

Then they start coming back.

One needs a decision. Another has finished something I need to review. A third wants confirmation before continuing. I reconstruct the context, understand what changed, judge the result, then switch to a completely different problem.

The agents can work in parallel. I cannot.

That has changed how I think about smaller AI-native product teams. We tend to focus on how much more one person can produce. The more interesting constraint is how much one person can still understand, judge and take responsibility for once production becomes cheap.

AI scales execution faster than judgment.

The Rawi operating model: a human founder sets direction and owns final decisions, an AI head of product routes the work, and eleven AI agents sit under three columns — the product, the build, and the Quran. A human scholar has the final word on scripture.

Access is not expertise

In about four months, without a conventional engineering team, Rawi went from an idea to an App Store product in nine languages, recognizing Quran recitation entirely on-device across all 6,236 ayahs, with the Android build now code-complete.

AI lets me work on architecture, debugging, testing and production code I could not have created independently a few years ago.

But access to engineering capability does not give me engineering judgment.

I learned that through a launch bug. Rawi could hang on first launch. An agent produced a fix, it compiled, the code looked sensible to me, and I shipped it. The commit message ended with:

BUILD SUCCEEDED. Needs on-device confirmation.

Apple’s reviewer found the bug immediately and rejected the build.

The next fix was more dangerous because it looked right. The agent raced a slow operation against a timeout and cancelled whichever lost. I read the code. It made sense.

It was also completely inert.

The Swift structure waited for the operation to finish before returning, so the cancellation never took effect. I caught neither problem by reading. The second only became obvious after a standalone test measured 6.2 seconds against a 2-second deadline.

That failure was mine. I approved work I was not qualified to evaluate using evidence — it compiled and looked sensible — that could not prove the code actually worked.

The rule I wrote afterwards:

BUILD SUCCEEDED ≠ verified.

I now ask agents to explain architecture, challenge their own decisions, surface trade-offs and tell me what evidence would actually prove something works. Those techniques help compensate for missing expertise. They do not create it.

My nine-year-old daughter makes the distinction even clearer. After watching me build Rawi, she used Replit to create and publish an Islamic education web app for children her age. She can now turn an idea into working software. Nobody would conclude that she has become an engineer.

Access is not expertise. The activity becomes accessible much faster than the judgment behind the profession.

How small can the team become?

McKinsey’s research on agentic product development describes smaller squads, broader responsibilities and teams supported by agents across discovery, delivery and learning. That direction feels very real to me.

But when eight people become four, the product does not stop needing:

research and user understanding
design judgment
architecture and engineering judgment
QA and security
analytics and learning
content and growth

The people can disappear faster than the capability requirement.

The remaining humans inherit a much larger territory. AI helps them execute across it, but someone still has to recognize when the output is wrong, decide whether it is good enough and own the consequence when it ships.

So the useful question is no longer: how few people can build this product?

It is:

How few people can still competently judge the product they are now capable of building?

Two diagrams captioned traditional and emerging. Both show the same eight capability boxes — product, design, engineering, research, QA, data, growth, content. The traditional side has a person standing beside each; the emerging side has three people in the middle covering all of them.

That also makes me less convinced that the future product organization will map neatly to today’s functional boundaries. A smaller team may have broader human ownership areas — someone primarily responsible for what and why, someone responsible for how — while both use the same AI systems across research, prototyping, code, testing, QA, analytics and growth.

The exact job titles matter less than the ownership.

A definer, owning what and why, and a builder, owning how, stand on either side of a shared territory of AI systems spanning research, prototyping, code, testing, analysis, learning, QA and growth.

Humans become the review queue

Expertise is one constraint. Attention is another.

I can start another agent almost instantly. I cannot create another brain to supervise it.

Every stream of parallel work eventually creates decisions and outputs I need to absorb. The agent may remember exactly what it has been doing for the last hour; I may have spent that hour thinking about three completely different problems. The leverage can start to feel like multitasking on steroids.

There is another side to this that I did not expect. When the distance between an idea and a working version collapses, stopping becomes surprisingly difficult. I often sit in front of those terminals after everyone else has gone to sleep. There is always one more improvement, one more experiment, one more idea that no longer needs to wait until tomorrow. It can feel as if the whole world is sitting at your fingertips.

AI may reduce the effort required to produce an artifact while creating an almost unlimited supply of productive work. The human shifts from making everything to supervising a much faster system.

A team can produce dramatically more while the humans inside it become the review queue.

If organizations measure AI productivity only through output per employee, they may miss the new bottleneck completely.

Preserve judgment, not handoffs

AI-native organizations are often described as having fewer handoffs. I agree — with an important distinction.

Some handoffs merely move work from one organizational box to another. Those should disappear.

Others exist because another person sees something the first person cannot. I did not have the experienced engineer who would have challenged my launch fix. That is why code that compiled, looked reasonable and did nothing survived all the way to Apple’s review.

That is not bureaucracy. That is independent judgment.

Remove handoffs that only transfer work. Preserve checks that add judgment.

If the person who provided that judgment disappears, it still has to come from somewhere: an automated evaluation, another model, a specialist, peer review or human approval.

Deleting the role does not delete the capability.

Responsibility becomes the operating model

As teams shrink, responsibility concentrates.

A person may eventually work with only a few colleagues while orchestrating many autonomous systems across a product area that once required several teams. They manage fewer humans but may own far more consequential decisions.

That changes how I think about seniority. A more useful measure may become the amount of problem territory someone can responsibly own:

How consequential is the problem?
How much business impact sits underneath it?
How complex are the people, agents and systems being orchestrated?
What happens when that person’s judgment is wrong?

It also changes where organizational bottlenecks appear. If ten people suddenly produce three times as much work but the same two executives still need to approve every consequential decision, the organization has not become three times faster. The bottleneck has simply moved upward.

AI-native organizations will need to redesign decision rights alongside execution capacity. And the same logic should determine how much freedom the agents themselves receive.

Autonomy should follow the blast radius

I am comfortable giving Claude Code considerable freedom on Rawi because most mistakes are observable and reversible. Although, as the launch bug showed, “observable” can sometimes mean “when Apple tells me.”

That is survivable for an app I own. It would not be survivable everywhere. A banking system, government service or healthcare workflow is different. The useful question is not simply: how capable is the agent?

It is: what happens if it is wrong?

A practical model could look like this:

Low blast radius: agent acts autonomously.
Increasing blast radius: agent + automated checks.
Significant consequences: agent + human review.
High-stakes or difficult-to-reverse consequences: agent + explicit human approval.

The AI can remain involved throughout. Human judgment accumulates around it as the consequence of error grows.

Four stages along an axis from low risk to high risk: pure agentic autonomy, then automated checks, then human review, then human approval and sign-off. Human figures accumulate around the agent as risk grows.

So how small can the product team become?

AI makes execution capacity elastic in a way it was not before. One person can access capabilities that once required several specialists, and a small group can coordinate far more work than its headcount suggests.

But three human constraints do not scale nearly as quickly:

Expertise: do we know enough to recognize when the system is wrong?
Attention: can we absorb and evaluate the amount of work being generated?
Accountability: does someone understand the decision well enough to own the consequence?

When I look at four terminals working in parallel, I genuinely feel as if I have the execution capacity of a much larger team. But every few minutes, one of those agents asks for something it cannot fully provide for itself: context, judgment or responsibility.

That leaves me with a different definition of the smallest viable AI-native team:

The fewest people who can still understand, judge and take responsibility for the territory they own.

This article was developed using AI assistance for drafting and proofreading. The core concepts, ideas and arguments are entirely my own, with AI serving as an editorial tool.