The AI Correction, Not the AI Collapse

What I keep seeing

Every long pause of a $1M to $5M company I talk to ends in the same place. They want to build their own software. Not someday. Now.

The founder is rarely an engineer. They have never run an engineering team. They have never carried payroll for one. Until twelve months ago, building a real software capability was simply not on the table for a company at their stage. The cost was wrong. The timeline was wrong. The risk profile was wrong.

That math has changed. They have heard, correctly, that AI compresses what used to take eighteen months and a team of ten into a few months and two or three people who can drive the new tooling. They are right about the compression. They are usually wrong about how much of that capability they currently have inside the building.

So they go looking for help.

What they are actually reaching for

Inside the frameworks I work with, the thing they are reaching for has a name. Some people call it level 4-5 of aiDevOps. Others call it Native AI Software Engineering. The labels are less important than the shape. It is a working stack made of four layers stacked on top of each other:

1. Technical capability. The engineering judgment to design, build, and ship.
2. Cognitive capacity. The bandwidth and pattern recognition to direct the new tooling without getting lost in it.
3. Tooling. The current generation of agents, IDEs, eval harnesses, and orchestration that make the compression real.
4. Process. Customer-driven workflows that have been redesigned around the fact that build cost is no longer the bottleneck.

The cultural and mindset side of moving an organization toward AI is well covered. ExO 2.0 and 3.0 do that work. Plenty of others do, too. That part is not the gap.

The gap is the install. A founder of a $2M services or product company asking for an installed level 4-5 capability is asking for something different from culture work. They are asking for an implementation team. That is a different problem with a different answer.

Why this is suddenly a live question

The reason this conversation is happening at this stage of company is the collapse of time-to-build. When build cost was high and build time was long, only well-capitalized firms could justify owning their own software. Everyone else rented. The buy versus build decision had a clear, structural answer for any company below a certain revenue line: buy.

That answer no longer holds. Build cost has fallen far enough that an owner of a $2M business with a sharp customer insight and the right two operators can produce, in months, what used to require a Series A. The structural argument for renting has weakened.

So the bottleneck moved. It used to sit in build cost. It now sits somewhere else: in product judgment, in customer-driven workflow design, in the human and AI handoffs that connect them, and in finding the people who can actually drive the new toolchain inside a small company. That last one is the binding constraint right now.

The other side of the market

While that is happening at the small end, the large end is shedding people. Big companies are letting engineers go in waves. Ten thousand from one. Fifteen thousand from another. The headlines call it AI job loss.

That language is sloppy. The job did not vanish. The match between where the engineer was sitting and where engineering is most valuable now did. Those people have not lost their craft. They have lost their assignment. There is a meaningful difference.

The math, held up at once

Now hold both sides of the market in view at the same time.

On one side, tens of thousands of companies in the $1M-$5M revenue band who never planned to build software and now intend to. Each of them needs one to three engineering-capable operators to install the capability they are reaching for.

On the other side, tens of thousands of engineers cut from companies that no longer need them at the scale they were employed.

That is millions of potential open positions on the demand side. Tens of thousands of available candidates on the supply side. Order-of-magnitude mismatch. In the wrong direction for an employer, in the right direction for a worker.

This is not a collapse. It is a correction. Engineering labor is being reallocated from a small number of concentrated, oversized employers to a much larger number of distributed, undersized employers who were priced out of hiring engineers at all until very recently.

What this means for the people in it

For the founder of a $1M-$5M company: the bottleneck to building your own software is no longer infrastructure or capital. It is finding one or two operators who can do the install, and then giving them a working culture that lets them ship without dragging the rest of the business behind them. The AI part is mostly handled. The hiring and integration part is the problem.

For the engineer who got cut from a Big Tech roll-up: your value did not drop. Your address changed. The companies that need you most are smaller, less famous, and run by people who have never managed an engineer before. They need you to lead the install, not just to take tickets. That is a different working posture. It is also a different kind of upside.

For the public conversation: stop calling this AI job loss. Call it what it is. A reallocation of engineering labor from concentrated employers who had scaled past their natural footprint to distributed employers who had been priced out of building software at all.

The risk in this moment

The risk is not that the work disappears. The risk is that the two sides of this correction never meet.

That is the bet I keep making in my own work. The job loss frame is the wrong frame. The reallocation frame is the right one. And the people who get rich on this transition will not be the ones predicting a collapse. They will be the ones connecting the dots between the two halves of a market that is already there, just not yet introduced.

If you are on either side of this correction, what is the actual barrier between you and the match you need? Reply and tell me. I will use what you send to keep building this thesis in public.