This is well-articulated in Eliyahu Goldratt back in 1984, where he termed this the Theory of Constraints. It basically says that every system has a single bottleneck that limits the total output, and when you remove that bottleneck, the next bottleneck emerges.
For software, traditionally the bottleneck has been the actual building of software. But with the advent of AI code generation tools driving the cost of software development to near zero, the bottleneck is shifting to everything around it.
The highest value startups are the ones removing the bottlenecks. We've seen record-breaking revenue growth and valuations from companies that have removed the bottleneck of software development, be it Cursor, Anthropic (because of Claude Code), OpenAI (because of Codex), or Cognition.
But according to the Theory of Constraints, new bottlenecks have now emerged with the cost of building software going to zero.
The New Bottlenecks in AI-Assisted Development
Here are a few bottlenecks that come to mind:
Code review and verification. A human still has to confirm that the generated code is correct, secure, and doesn't cause any regressions (even though AI is starting to encroach on this too). The symptom is PRs piling up for review.
Build, test, and CI throughput. Teams are now shipping 10x the number of PRs per day, but if the build graph, test suite, and CI runners still take the same amount of time per build, the queue backs up right there. Monorepos are tremendously useful for giving AI agents context, but they also become a build bottleneck of their own.
Release engineering and rollout coordination. Merging to main is step one. Beyond that, there are staged rollouts, feature flags, migration sequencing, and rollback planning, all of which still require careful human coordination.
Product marketing and launches. While a feature can be built in an afternoon, positioning, messaging, sales enablement, docs, support readiness, and cross-team alignment still take weeks. The old engineering backlog has effectively turned into a GTM backlog.
Why Builds Break First
Of the four bottlenecks above, build throughput is the one I think breaks first, and breaks hardest, because it sits closest to the part of the loop that's already moved to machine speed.
A human engineer used to write a commit, wait for a build, look at the result, and move on to the next thing a few times a day. On the other hand, an agent doesn't work that way. It writes, builds, reads the failure, and tries again, over and over, in a tight loop, sometimes dozens of times for a single task. Multiply that across a fleet of agents running in parallel and the build system stops being a background utility and becomes the thing everything else is waiting on.
Engineers already lose real time to slow builds, often five to ten minutes at a stretch, multiple times a day. On a large engineering org, that adds up to millions of dollars a year in idle engineering time. Moreover, there’s the added cost of the human incident response when a build breaks. And with a swarm of agents on top of that same infrastructure, the costs compound.
The Return of the Monorepo
The monorepo used to be treated mostly as an organizational headache but in the agentic era, it is becoming critical infrastructure.
Agents are good at wide, mechanical refactors that touch dozens of packages at once. Across multiple repos, you run into versioning hell. But in a monorepo, it’s just a single commit. And once you accept that agents will be committing at volume, the monorepo approach provides stronger verification. Hermetic, reproducible builds, are foundational for trusting an agent's output.
But monorepos also make the build bottleneck worse. More code in one place means larger build graphs, more dependencies to trace, and longer CI times if the system isn't architected correctly.
The Path From Observability to Autonomy
Over the years, I have observed a well-tread path for technology startups where they cover four stages in the following order:
Observability & Reporting. Gathering data about what is happening and surfacing that.
Analysis & Insight. Interpreting the data to highlight and explain trends, anomalies, issues, and hotspots that may require attention.
Recommendations. Recommending corrective actions or interventions that need to be taken to remediate a surfaced issue.
Autonomous Actions. Taking actions autonomously to remediate the situation.
This same four step ladder has been the vision in nearly every company I’ve worked at. At my own marketing tech startup, it started as reporting on content marketing performance, with the vision of a self-optimizing content marketing campaign. At Domino Data Lab, it started as monitoring the performance of machine learning models in production with the goal of a self-remediating MLOps system. At Galileo (now a part of Cisco Splunk), it started as an AI app and agent observability moving the self-resolution of production AI failures.
And beyond that, Datadog started in cloud observability and expanded into AI monitoring and autonomous SRE workflows. Splunk did something similar with machine data before Cisco bought it for $28 billion. Sentry started with application error monitoring and has been pushing into release health and AI-assisted issue resolution. Monte Carlo did the same thing for data quality.
Build systems are one of the few categories that haven't gone through this yet. CI tools like Jenkins, GitHub Actions, and CircleCI give you logs and dashboards, but the actual causal graph, what depends on what, why a build slowed down, whether a failure came from the cache, the test, or the code, is mostly unowned. That's a strange gap given how central builds are about to become, and it's the gap Hermetiq is trying to fill.
What Hermetiq is doing about it
One of the startups I'm most excited about right now is Hermetiq, which is going after the build throughput problem specifically. Full disclosure: I'm an angel investor in the company and I'm writing this because I think the build bottleneck is a genuinely interesting and underappreciated part of the story, not because I need you to believe in my portfolio company.
Hermetiq is a build intelligence layer for agentic engineering, sitting on top of Bazel and Buildbarn-style remote execution. Practically, it ingests the full build event stream (targets, actions, cache, workers, tests, cost, ownership) and turns it into something both engineers and agents can reason about, rather than just a wall of logs. The pitch to a build team is roughly that your CI already tells you a build failed, and Hermetiq tells you why, and increasingly, what to do about it.
Their anchor customer is a marquee lab running Hermetiq at real AI-scale build volume, something like two million builds a day getting ingested and analyzed. What made me comfortable writing a check wasn't the current ARR but rather that the CEO, Jake Newfield, and CTO, Tim Potter, who both came out of Nativelink, another company in the Bazel/remote-execution world.
But won’t the labs just build this?
The most obvious objection is why couldn't OpenAI, Anthropic, or Google just build this themselves? They already have the build volume, the incentive, and more engineers.
Sure, it’s possible but that has been true of almost every valuable infrastructure company at some point. AWS could have built what Datadog builds. Banks could have built what Stripe built. Yet they didn’t.
In practice, a neutral layer that sits across vendors and build systems, will go deeper and is more trustworthy to enterprise buyers than a bundled add-on from a lab that's also trying to sell them the model. Whether Hermetiq specifically ends up being that neutral layer is genuinely an open question and I'm betting yes.
Where this leaves us
If the Theory of Constraints holds, and I think it will, the build bottleneck is not the last one. Somewhere behind it, release engineering and GTM are already queuing up, and I'd expect to see a similar crop of companies going after those next. But right now, the build loop is the one closest to breaking under agent-scale volume, which is why it's the one I chose to bet on first.
For now, if you're an engineering leader watching your PR queue grow faster than your CI can chew through it, I'd be curious to hear how you're thinking about it.
