The org chart no longer tells you how much you can build.

We are used to there was a relatively stable relationship between the size of an engineering team and what that team could produce. It was never perfectly linear, of course, but it was predictable enough to shape how companies planned. More products, more markets or a larger roadmap usually meant more engineers, which made capacity fundamentally a hiring problem.

That assumption is starting to break.

We are seeing small teams of experienced engineers, working with AI agents throughout the development lifecycle, produce an amount of work that would previously have required significantly larger teams. The important change is not simply that developers are becoming more productive. It is that the number of people on an org chart is becoming a much weaker indicator of what an organization can actually build.

Once that relationship changes, some very established ideas about engineering organizations begin to change with it. How companies structure teams, where they invest and how they add capacity all deserve to be reconsidered.

AI changes the constraint, not just the speed

Much of the conversation around AI development has focused on output. Models write code faster, agents can work across increasingly complex tasks, and a growing portion of the development lifecycle can happen without someone manually producing every artifact.

That matters, but after working this way at Bowery, we think the more consequential change happens somewhere else.

As producing software becomes cheaper,

judgment becomes more valuable

.

Someone still needs to understand whether the implementation belongs in the architecture, whether the assumptions behind it are correct, whether an edge case matters and, ultimately, whether the output is something the company is willing to put into production.

This creates a different kind of constraint. The question is gradually becoming less about how much work a team can produce and more about how much work experienced people can confidently review, direct and own.

That distinction matters because AI does not remove engineering responsibility. It concentrates it. A senior engineer who once spent a large portion of the week producing code can increasingly spend that time directing agents, reviewing decisions and protecting the integrity of the larger system.

At Bowery, we have a simple way of describing this shift: AI accelerates. Seniors own.

Capacity is becoming detached from headcount

If one experienced engineer can direct significantly more production than before, adding capacity no longer necessarily means adding people at the same rate.

This does not mean engineering teams disappear, nor that every company should simply replace developers with agents. The more interesting implication is that companies can begin designing teams around the judgment they need rather than the volume of work they expect to produce manually.

That is a fundamentally different way of thinking about capacity.

For a CEO or CTO, the old planning question was often relatively straightforward: we have this roadmap, so how many engineers do we need to deliver it? Increasing capacity meant recruiting, onboarding and carrying additional headcount, usually before knowing exactly how much of that capacity would still be needed twelve months later.

AI introduces more elasticity into that equation. A smaller senior team can expand its productive capacity through agents and automation without expanding the organization at the same pace. When demand changes, the underlying capability can change with it more easily than a traditional team structure could.

The org chart, in other words, tells us less than it used to.

There may now be a third answer to build vs. buy

This shift becomes particularly interesting when it reaches one of the oldest decisions in enterprise software: whether to build something internally or buy an existing product.

Historically, the tradeoff was reasonably clear. Building gave the company greater control, but required hiring and maintaining the people capable of doing it. Buying reduced that operational burden, but meant accepting somebody else’s product, constraints and roadmap.

AI-enabled delivery creates room for something between those two models.

A company can increasingly subscribe to a capability rather than hire an entire team or buy a standardized piece of software. The capability can still produce custom software, integrate with internal systems and evolve around the needs of the business, but the company does not need to reproduce the full organizational structure traditionally required to deliver it.

This is an important distinction. It is not staff augmentation with AI added on top, because the unit being purchased is no longer primarily a number of people or hours. And it is not SaaS, because the business is not simply adopting the same finished product as everyone else.

What the company is buying is the ability to produce and operate a particular outcome.

That model also changes the economics of quieter periods. Traditional engineering capacity is relatively fixed: once a team exists, the company carries that cost whether the roadmap is unusually demanding or temporarily light. A capability model can be more elastic, expanding when there is meaningful work to deliver and contracting when there is not.

We rebuilt Bowery around this idea

This is not a shift we arrived at theoretically. Over the last year, we have been changing how Bowery itself operates around the assumption that capability, rather than headcount, will increasingly become the useful unit of software delivery. Our teams combine senior engineers with AI agents and a delivery system designed around the part we believe remains fundamentally human: judgment, accountability and ownership of what reaches production.

We are still learning where this model works best and where it does not. But one thing has become increasingly difficult for us to ignore: if AI continues separating software output from the number of people required to produce it, companies will eventually need a different way to think about engineering capacity.

The implications go beyond developer productivity. They reach team design, technology investment, budgeting and even the traditional boundary between building software and buying it.

On September 30, Bowery CEO Gustavo Iglesias will join ReadyBench to unpack both of these shifts: why headcount is becoming a weaker measure of engineering capacity, and how a capability model is changing the traditional build-versus-buy equation. It will be a 45-minute online conversation for the people making these decisions inside their own companies, grounded in what we have learned rebuilding Bowery around this model.

Free, online, September 30. Register here