Originally published on research.thinknimble.com.

I am developing a formal theorem I call the Verification Complexity Barrier.

In a nutshell, if a program has some components n that have connectivity factor of k > 0, then verification complexity increases superlinearly for each new component. Therefore the time required to fully verify the system always exceeds time to generate components.

After a while, because it’s superlinear, the verification complexity takes off and becomes impossible to keep up with in some finite amount of time. This was true before AI, but is much starker now as code generation time trends towards zero. You hit the barrier sooner.

An interactive model

Drag the sliders and watch where the barrier lands. (Same model, on the canonical essay.)

We all have finite capacity - even AI agents - so there will always be a certain number of components n where the wall is hit. You must spend more and more effort on verification for each new component in the system.

The best thing you can do is spend time changing the “topology” of the problem - change the software architecture - so that the exponent of verification complexity is lowered (Lehman¹) and the curve is flattened. You can bundle components into modules, you can add automated tests, you can use formal proofs, you can use type systems. These things push the barrier to the right. They buy you more components and a more complex system. But the theorem suggests you can only ever defer the barrier, never completely eliminate it.

AI Agents can burn tokens all day long generating software components and tests for those components. They can find bugs and fix them, but they cannot prove the absence of bugs (per Dijkstra², Rice³, Smith⁴, and others). And “Bug” needs to be defined against someone’s spec for what “working” and “not buggy” looks like. The more you build with Agents, the heavier the verification burden becomes.

This may sound like the same trite observation others have made on X: “Our bottleneck is no longer writing code, but reviewing code”⁵ and “I am the bottleneck now.”⁶ True, but I don’t think anyone has captured the magnitude of the problem. The math is: at a certain component count n, it is literally impossible for you, your team, and your agents to completely verify a system. The bottleneck goes to zero, and nothing gets through.

So what software companies do in the real world is release incompletely verified software and massively scale up. This shifts the burden of verification onto their customers, because “given enough eyeballs, all bugs are shallow” (Raymond⁷). If you can get enough eyeballs, this is a very cost-effective way to shift the barrier to the right by massively increasing your team’s capacity. You walk the tightrope of doing enough internal verification before release so you don’t lose customers, while tolerating a certain amount of escaped bugs, which - if those bugs matter at all - your customers will find for you.

Meanwhile, massively scaling up just accepts the growing cost of complexity. You can push n* from 15 to 30 by quadrupling your capacity. To get to 60 you need to quadruple again, and then again to get to 120. Your cost curve is superlinear to get linear gains in system size. At a big enough scale, you amortize the cost across your customer base and the economics work.

Contrast that with a sufficiently complex vibecoded app built for a small audience - high complexity costs can’t be amortized at small scale. I expect to see many people and companies try and fail at vibecloning complex SaaS in the near term. Complexity cost economics only scale with audience size (I will share another model for this).

I do think SaaS prices will be corrected downwards to account for savings in code generation, but I predict that once the irrational exuberance for vibing fades, we’ll see that it still makes sense to buy rather than self-build complex SaaS.

A broader implication is that AI Agents will never be able to self-verify. Humans, too, will never be able to fully verify their behavior, because LLMs are by design of maximal complexity. Did you see the size of those error bars in the latest METR results?⁸ The longer the horizon on a task, the more spread in AI agent outcomes. This is the Barrier in action. Spread is a feature of GenAI, but in practice it means heaps more output to review and verify.

The Complexity Barrier shows you literally won’t have time to review it all. At the inflection point of verification complexity, you have to fall back on vibes. The implication for fast-takeoff AGI is even scarier: if AI does reach a point of recursive self-improvement, this theorem suggests it will be structurally impossible to know that behavior is aligned, because you won’t be able to completely verify. Drift is bad enough in vibe coding. Runaway AI will drift massively and there’s no way of knowing where it will end up.

All that’s to say, verification should be the focal point of AI Engineering for the foreseeable future and maybe forever. That is: how do you capture what you want to do, refine that into specifics, and then follow up with automated tests, assertions, evals, and customer feedback to progressively harden your software?

The verification problem is acute now because of how cheap software generation is. Because of the superlinear nature of software verification complexity, companies that push hard on the barrier and successfully shift it right will have a built-in moat versus those who fail to put in the verification work.

---

What the sliders reveal

Set coverage \(c\) to 0% and test setup cost \(S\) to 0. This is a team with no tests: verification is entirely manual and the wall is close. Raise \(c\) and the dashed line moves right, because automated testing scales \(n^*\) by \((1/(1 - c))^{1/\alpha}\). Raise \(S\) and the green baseline flattens, because each component honestly costs more to produce, but the wall moves much further out. That trade is almost always worth it.

The “move fast, no tests” configuration is high \(g\), zero \(S\), zero \(c\). Early progress looks great, because the baseline is steep. But \(V(n)\) is convex: it barely registers for the first few components, then explodes. The transition from headroom to zero velocity is nearly instantaneous, with no gradual slowdown to warn you. A team that writes tests from day one has a visibly lower effective generation rate and appears to be losing the race, until the no-test team stalls. Adding tests after the fact is worse still: the setup cost lands on every existing component at once, a capacity spike at the moment velocity is already near zero.

Capacity does not buy a way out. With \(\alpha = 2\), \(n^* \propto \sqrt{W}\), so doubling the team pushes the barrier out by about 41%. The constraint is structural, not a staffing problem. As long as verification cost grows faster than linearly with system size, and it does, because of combinatorial interactions between components, there is a finite ceiling for any given team and process.

Appendix: The formal model

For readers who want the precise mechanics behind the visualization.

Axiom 1 (Finite Capacity). A development team has fixed capacity \(W > 0\) per sprint. All productive activity, generation and verification, must be funded from \(W\). No activity can proceed without consuming capacity.

Axiom 2 (Positive Production Cost). Each component requires \(g\cdot(1 + S)\) units of capacity to produce, where \(g > 0\) is the generation rate and \(S \geq 0\) is the per-component verification setup cost. We require \(g\cdot(1 + S) < W\), otherwise no component can be produced at all.

Axiom 3 (Superlinear Verification). The human verification cost for a system of \(n\) components is \(V(n) = (1 - c)\,n^{\alpha}\), where \(c \in [0, 1)\) is the fraction of verification automated by tests, and \(\alpha > 1\) is the interaction exponent. \(V\) is continuous, monotonically increasing, and unbounded.

Axiom 4 (Capacity Constraint). At system size \(n\), the team must simultaneously fund production and verification from \(W\):

\[g\cdot(1 + S) + V(n) \leq W\]

Velocity is zero whenever this inequality is violated.

Definition 1 (Verification Budget). The verification budget is \(B = W - g\cdot(1 + S)\). By Axiom 2, \(B > 0\).

Definition 2 (Effective Velocity). The effective velocity at system size \(n\) is:

\[v(n) = g_{\text{eff}} \cdot \left(1 - \frac{V(n)}{B}\right)\]

where \(g_{\text{eff}} = g \,/\, (1 + S)\) is the effective generation rate. \(v(n) > 0\) when \(V(n) < B\), and \(v(n) = 0\) when \(V(n) \geq B\).

Definition 3 (Complexity Barrier). The complexity barrier \(n^*\) is the unique solution to \(V(n^*) = B\), that is:

\[n^* = \left(\frac{B}{1 - c}\right)^{1/\alpha}\]

This exists and is unique because \(V\) is continuous, \(V(0) = 0\), and \(V\) is unbounded (Axiom 3).

Theorem 1 (Existence of the Barrier). For any system satisfying Axioms 1 to 4, there exists a finite \(n^*\) such that the cumulative development time \(T(n) \to \infty\) as \(n \to n^*\). The system cannot reach \(n^*\) components in finite time.

Proof. The cumulative time to reach \(n\) components is:

\[T(n) = \int_0^n \frac{dn'}{v(n')} = \int_0^n \frac{dn'}{g_{\text{eff}} \cdot \left(1 - V(n')/B\right)}\]

By Definition 3, \(V(n^*) = B\), so as \(n' \to n^*\), the denominator \(\left(1 - V(n')/B\right) \to 0\).

Since \(V\) is continuous and differentiable near \(n^*\), we can write \(V(n^*) - V(n^* - \varepsilon) \approx V'(n^*)\cdot\varepsilon\) for small \(\varepsilon\). Then near \(n^*\):

\[1 - \frac{V(n')}{B} \;\approx\; \frac{V'(n^*)\cdot(n^* - n')}{B}\]

so the integrand behaves as:

\[\frac{1}{v(n')} \;\approx\; \frac{B}{g_{\text{eff}} \cdot V'(n^*) \cdot (n^* - n')}\]

This has the form \(C/(n^* - n')\), which is a logarithmic divergence:

\[\int^{n^*} \frac{dn'}{n^* - n'} = -\ln(n^* - n') \;\to\; \infty\]

Therefore \(T(n) \to \infty\) as \(n \to n^*\). The barrier cannot be reached in finite time. ∎

Corollary 1 (Diminishing returns of capacity). For the bare case (\(c = 0\), \(\alpha = 2\)): \(n^* = \sqrt{B} = \sqrt{W - g}\). Doubling \(W\) increases \(n^*\) by a factor of at most \(\sqrt{2}\). The barrier is sublinear in capacity investment.

Corollary 2 (The generation-rate trap). \(\partial n^*/\partial g < 0\). Increasing generation rate \(g\) while holding all else constant moves the barrier closer, because it shrinks \(B\). A faster team hits the wall at a smaller system.

Corollary 3 (Testing shifts but preserves the barrier). For any coverage \(c < 1\) and any \(\alpha > 1\), \(n^*\) is finite. Automated testing increases \(n^*\) by a factor of \((1/(1 - c))^{1/\alpha}\) but does not eliminate the barrier. Only \(c = 1\) (complete verification automation) removes it, but Axiom 3 requires \(c < 1\), reflecting the irreducible residual of emergent, unautomatable interactions.

Corollary 4 (Recursive barrier). Capacity \(W\) is itself produced by a team of \(m\) people with coordination cost \(C(m)\) growing superlinearly. By the same argument, there exists \(m^*\) beyond which adding people decreases effective \(W\). The barrier is self-similar across levels of organization.

---

First shared as a post on X on February 28, 2026. The canonical version lives on the ThinkNimble Research site.