I Run a Stack of Terminals. The Bottleneck Was Never the Code.

A stack of Claude Code windows, one operator, a production SaaS. By day three the agents were never the constraint. I was.

That sentence is the whole operating model, and I lived inside it before I had a name for it. A wall of agents executing in parallel. One human as the merge point. Coherence existing in exactly one location. Not in the code. Not in the tools. In a single mind holding the whole system at once.

I built Orbyt this way. A production SaaS, solo, in 32 days, for roughly $400, using Claude Code across a stack of terminal windows, four to eight running at a time. At launch it was 243,000 lines of code, 4,124 tests, 852 commits. It runs on over 425,000 lines now, and I still ship daily. The number that matters most is not in that list. It is the number of people. One.

How you split work so the agents do not collide

The first problem is not capability. It is collision. Multiple agents writing to the same codebase will step on each other instantly if you let them. Two agents editing the same file produce a merge conflict and an hour of cleanup. Two agents holding different assumptions about the data model produce a bug that does not surface until both halves ship.

So you split work the way you would split it across a team that never talks to each other. By seam, not by feature. One window owns the schema and migrations. One owns the payment and billing layer. One owns the interface and onboarding. One stays free for the thing that just broke or the idea that just arrived. The boundaries follow the places where two parts of the product touch but do not overlap.

The trick is in the boundaries, and the agents do not negotiate them. I do, in advance, before any agent touches a line. The agents do not coordinate with each other. They coordinate through me. I hold the contract between the billing agent and the auth agent in my head, and I make sure neither one violates it. The agents are not a team. They are many hands, and I am the only nervous system connecting them.

Each window has deep context on its slice and zero context on the others. That is by design. An agent does not need the whole picture. It needs its piece and a clean boundary. The whole picture lives with the operator, because the operator is the only thing that spans them all. Which means the moment the work outruns what one nervous system can hold, the whole thing stalls. Not because an agent failed. Because the operator ran out of room.

Day three: the agents were never the slow part

I expected the agents to be the bottleneck. They were not. By day three it was obvious, and it was humbling. The work each window could produce was effectively unlimited. Tell it what to build and it built it, faster than I could read the diff. A stack of them running at once produced more output in an afternoon than a small team produces in a week. The supply of execution was not the problem. It was infinite for all practical purposes.

The scarce thing was me. Every window eventually needed a decision only I could make. Which way the schema should branch. Whether the billing edge case was worth handling now or later. Whether the onboarding copy was right or just acceptable. A stack of agents, each fast, each waiting, and one human deciding one thing at a time.

The agents were never tired. I was. The agents never lost the thread. I did. The execution was free and infinite. The judgment was neither.

That is the realization that reorganizes everything. The bottleneck moved. It moved off the keyboard and into the operator’s head. Once execution is free, the constraint is the person feeding it judgment.

What being the bottleneck actually means

Being the bottleneck is not about typing speed. The agents type. It is about three things, and none of them get faster no matter how good the model gets.

First, holding the system model. Agents working in parallel only stay coherent if one mind knows how all the pieces fit together. How billing touches permissions. How ingestion feeds the matching logic. How a change in one lane ripples into the others. The agent in window two does not know that the change it just made breaks an assumption window one is relying on. I have to know. The architecture lives in one place, and it cannot be parallelized, because the instant you split it across two minds you have reintroduced the coordination cost you were trying to escape.

Second, decision queue depth. Every stream generates decisions faster than one person can resolve them well. Which approach for the retry logic. Whether that abstraction earns its complexity. Which thing to cut. The queue never empties. The faster the agents go, the faster it fills. My throughput as a decision-maker became the literal clock speed of the build. Not how fast the code got written. How fast I could decide what was correct.

Third, being the merge point. The agents report to me and only to me. Nothing they produce becomes real until it passes through one set of eyes. I am the place where parallel realities become one product that holds together, or fragment into a pile of products that happen to share a repo. There is no second merge point. There is no committee. There is one mind, and it either holds or it does not.

Hold the map, drain the queue, own the merge. Lose any one of them and the swarm does not slow down. It accelerates in the wrong direction, and you find out three windows later.

I rejected working code constantly. Code that ran, passed, and shipped, and was still wrong, because the abstraction was slightly off or the name did not express intent or the flow asked the user to think when it should not have. The agents cannot make that call. They optimize for done. I optimize for right. Most of what a stack of capable agents produces is fine, and fine is the enemy. The gap between done and right is where the entire value of the human now lives.

The founding team was always a coordination workaround

Here is the part that reframes everything. The founding team was never the goal. It was a workaround.

One person could not build and run a whole product at once. Not the code and the design and the infrastructure and the ten thousand small decisions, all moving in parallel, all at the speed the market demanded. So you hired. You assembled a team. And the moment you did, you took on the tax that comes with every team. Coordination.

Meetings. Handoffs. Sprint planning. Status updates. The shared context you rebuild every morning because it lives in five heads instead of one. The slow leak of intent as it passes from the head that had the idea to the hands that build it. The team was a parallelism mechanism. It let you do many things at once. But it charged coordination overhead for the privilege, and past a certain size that overhead eats the capacity you hired it to provide.

Agents give you the parallelism without the tax. A stack of windows runs at once, like a room of engineers. But they hold no opinions you have to negotiate. They forget nothing you told them. They never need a meeting to sync, because the only sync point is you, and you never left. Building Orbyt, I had a stack of parallel streams and zero coordination overhead. No meetings. No handoffs. No sprint planning. The friction the founding team was assembled to manage simply did not exist.

So the founding team was never the irreducible unit of building. It was a coordination structure built to compensate for the throughput limit of a single human. Remove the limit and the structure becomes optional. Not obsolete. Optional. You still might want one. You no longer need one just to get a whole product built and running. The thing that defined zero to one for forty years is now a choice, not a requirement.

Zero to one no longer needs the team. It needs the clarity.

This is the shift. The unit of creation used to be a team. Now it is one operator plus a swarm of agents.

And the constraint moved with it. When you needed a team, the scarce input was talent. You competed for engineers. You raised money to pay them. You spent your first year hiring instead of building. The whole zero-to-one playbook was organized around acquiring and aligning labor, because labor was the thing standing between an idea and a product.

Labor is no longer the constraint. The agents supply it on demand. What is scarce now is the thing only the operator can provide. Clarity about what to build. Judgment about what to keep. The decision throughput to clear a queue the agents keep refilling. Taste sharp enough to reject working code because it is not the right code.

This inverts the founding calculus. The question is no longer who do I hire to build this. It is can I hold this entire system in my head while a stack of streams change it at once. Add people and you add coordination cost. Add clarity and you add throughput at the only point that was ever constrained. You no longer need the team. You need the clarity. And clarity does not come from a hire. It comes from the one person at the center who can hold the whole system and decide, fast, what is true.

I have run this at both ends

I am not theorizing from the cheap seats. I have run the funded-team model at full scale and I have run the swarm-of-one, and the contrast is the whole argument.

At Norhart I ran CTO, CDO, and CMO simultaneously on a $200M organization. Three C-level functions, one person, a fully funded team underneath each one. That is the coordination structure at its most demanding. Many people, real budgets, the full overhead of keeping a large org pointed in one direction. It works, and it is expensive, and most of the expense is coordination, not invention.

At Taxa, a team of four took the product to $113M with KKR and Bessemer behind it. Four people is about the leanest a serious founding team gets, and it is a genuinely great outcome. But four people is still four minds that have to stay aligned, four sets of context to keep in sync, four calendars to reconcile. It was the leanest version of the funded model, and it still ran on coordination.

Orbyt is what comes after the team becomes optional. One operator. A swarm of agents. A production SaaS in 32 days. The team of four became a team of one with a stack of terminals, and the terminals do not need to be managed, aligned, or paid a salary. They need to be directed. The coordination cost was not reduced. It was removed, because there was only one mind to keep aligned, and it was already aligned with itself.

The contrast is the point. Norhart was coordination at $200M scale. Taxa was the leanest funded team possible. Orbyt is the new shape entirely. The constraint moved from how many people you can align to how much one person can hold.

Knowing what to reject is the job

By day three I stopped trying to keep up with the agents. That was never going to work. A stack of agents will always outproduce one human, by design. The mistake was thinking my job was to match their output. It is not. My job is to be the part of the system that decides.

The agents own execution. I own judgment. They generate options at a rate I cannot match, and the value I add is not another option. It is the no. Labor generates. Judgment selects. When generation is free and infinite, the entire value of the system collapses onto selection. Onto taste. Onto the one mind deciding, fast and well, what survives. The operator who can reject fastest and most accurately ships the coherent product. Everyone else ships a pile of confident, technically correct, collectively incoherent output.

That limit is real, and it does not disappear. I cannot run a hundred windows. Past a certain point the system model gets too large to hold, the decision queue gets too deep to clear, and the merge point becomes the thing that breaks. The ceiling did not vanish. It moved. It used to be how many people you could hire and coordinate. Now it is how much system one person can hold in their head while deciding fast enough to keep the swarm fed.

The new unit of zero to one is one operator plus a swarm of agents. The agents are not the limit. They never were. The limit is how much coherence a single mind can hold. That is the bottleneck. It is also the moat. Because the agents are available to everyone, and the clarity is not.