95% of enterprise AI pilots fail. Solo developers ship. Same tool.

Somebody is going to sell you an AI transformation this year. Before you sign anything, put two facts next to each other. They look like a contradiction. They are both true.

Fact one: MIT's State of AI in Business report found that 95 percent of enterprise generative AI pilots deliver zero measurable P&L impact. Tens of billions of dollars in, nothing measurable out.

Fact two: solo developers are shipping production systems in weeks. Real ones, with authentication, data, compliance controls, and paying users.

Same models. Same tools. Opposite results.

I run a studio built entirely on that fact. The proof I keep pointing at is Coda, a HIPAA-compliant AI medical-coding platform running in live healthcare environments, built end to end without a department.

I don't think the enterprise numbers are wrong. They are measuring something else.

They got slower. They swore they got faster.

Two studies did the real work here, and neither one blames the models.

The MIT study looked at 300 public AI deployments and interviewed executives across the market. The interesting part is not the 95 percent, it is the diagnosis: flawed enterprise integration, a learning gap between what the tools can do and what the organization can absorb. The company bought the tool and never changed a single process around it.

Then a randomized trial did something crueler. METR put experienced developers on large, mature open-source codebases, averaging over a million lines each, and measured them with and without AI tools. With AI they finished 19 percent slower. They had predicted 24 percent faster. After the experiment was over, they still believed AI had made them 20 percent faster.

A 39-point gap between feeling and measurement. That gap is where most enterprise AI budgets are living right now.

The bottleneck was never coding

Nobody in those reports says the quiet part, so I will. The models did their job. The pipeline ate the gains.

In a large organization, writing code is a thin slice of the pipeline. A feature is a ticket, a design review, a sprint slot, a pull request, a code review queue, a QA pass, a security sign-off, a release window, and a retro. The typing in the middle might be a tenth of the elapsed time.

AI accelerates the typing.

Speed up a step that is 10 percent of the timeline and the best case, if everything else holds, is a 10 percent gain. That is Amdahl's law pointed at an org chart instead of a processor: the speedup of the whole is capped by the part you didn't touch.

But everything else does not hold. AI makes code cheap to produce and expensive to review. Pull requests get bigger. There are more of them. The same number of senior reviewers now stand between more code and production. The one step AI accelerates feeds directly into the step that was already the constraint.

So the honest enterprise math is: a small speedup on a thin slice, paid for with a new tax on the thickest one. Measured at the P&L, that rounds to zero. MIT found zero.

The machine is too big to absorb speed

Enterprise engineers are not the problem, and METR is the proof. Drop an excellent developer into a million-line codebase with AI at their side and they get slower. The codebase didn't fit the model's context, and the change didn't fit one person's head.

Every layer of a large company exists for a reason. Approvals, ownership boundaries, QA gates, compliance review, release trains: that is what makes 500 engineers safe to run in parallel. But every one of those layers is friction that no prompt can remove. Enterprises do not move at the speed of coding. They move at the speed of coordination, and AI does not attend meetings.

An engineer writing about the disappearing middle class of software work put it in five words: AI removed the speed limit. Bad decisions now compound in days instead of months, while the organization's capacity to catch them hasn't changed. A big machine responds to that rationally: more review, more gates, more caution. More of exactly the thing that was already the bottleneck.

One head, no handoffs

Now take every one of those layers out.

A solo developer holds the entire system in one head. The specification, the architecture, the code, and the review are the same person. A decision takes minutes, not a meeting. The codebase is young and small enough to fit both the model's context window and the builder's memory, which is exactly the condition METR's developers did not have.

For a solo operator, coding, architecture, and decision-making are not a thin slice of the pipeline. They are nearly the whole pipeline. So AI does not shave a tenth off the timeline. It compounds across almost all of it.

The 95 percent failure rate and the solo builder shipping in weeks are the same fact seen from opposite ends: AI is a coding multiplier applied to two structures, one where coding is 10 percent of the job and one where it is 90.

What about everything a solo developer doesn't know?

The fair objection: an enterprise has specialists. Security, infrastructure, databases, QA. One person cannot know all of that.

One person doesn't have to know all of it anymore. The model carries the encyclopedia. What it cannot carry is judgment, so the solo developer's real job is a short list of principles that never bend:

• Least privilege, always. Nothing keeps write access to production that doesn't need it today.
• Every schema change is a migration. No exceptions at 2 a.m.
• Tests gate the merge, and the merge gates the deploy.
• Every touch of sensitive data lands in an audit log.

Rules like these are the brakes that make the missing speed limit survivable. AI fills the knowledge gap. Principles close the judgment gap. That combination is what lets one disciplined person do what used to take a department, and it is the difference between engineering with AI and gambling with it.

This is also where most of the new wave falls down. The same tools that let a disciplined operator ship a compliant platform let an undisciplined one ship a demo with a public database, no migrations, and no audit trail. Both quote you a small number. Only one of them is still standing when you have real users, real data, and a customer's lawyer asking who had access to what. The cheap build is not cheaper. It is the same bill, paid later, by you, usually at the worst possible moment.

That is not theory. It is how we built Coda: a HIPAA-compliant AI medical-coding platform, designed and built end to end, live in healthcare environments with months of production behind it as I write this. And "we" here is exactly what this article is about: one architect, and AI doing the typing. Per-tenant isolation, so no customer's data sits in the same room as another's. Append-only audit logs, so every touch of a patient record is provable a year later. Grounded AI, so the model answers from the record in front of it instead of from memory. In a large shop, each of those is a separate team, a separate review board, and a separate quarter. Here, they are the four principles above, written down as architecture, in the one industry that will actually check.

And Coda is not one app. It is the hospital-facing platform, an operator console, a continuous security scanner we call Sentinel, and the infrastructure that gives every customer an isolated cloud account of their own.

How much work is that, in traditional money? We priced the rebuild three separate ways: a bottom-up staffing plan, US agency market rates, and a parametric cost model. The conservative methods converge on $2 to 4 million and 12 to 18 months, with a team of about ten. An agency would quote more. Coda went from first commit to a signed hospital contract, security review and HECVAT questionnaire included, in three months, built by one architect working with AI. That is not a discount. That is a different cost structure.

What happens if you get hit by a bus?

The other fair objection is not about knowledge. It is about buses. One person is one point of failure, and you would be handing a business-critical system to a structure with no bench.

The answer is not a bigger team. It is a system that does not depend on any single head, including ours:

• Infrastructure is code, not knowledge in someone's fingers.
• Schema lives in migrations, not in a memory of what got run in production last March.
• Decisions are written down where the next person can read them.
• The repository, the cloud accounts, and the data are in your name from day one.

If we disappeared tomorrow, you would hand a competent developer the repository and they would be productive within days. Most agencies cannot promise that, because in their model the knowledge is the staffing plan, and the staffing plan is the invoice.

Who should not hire us

Honesty cuts both ways. There are jobs we would not take. Hire the big shop if your system has to survive a 300 person org chart, or if it needs staffed coverage around the clock from day one. Same if your procurement process requires an account team and a compliance department on the vendor's side. That is what they are for, and they are good at it.

But most of the work that gets routed to them is not that. It is a system one focused structure could have built in a fraction of the time, pushed instead through a pipeline designed for a different size of company, and priced accordingly. The engagement we do our best work on: a real product or internal system, a founder who can actually decide, and a first version that deserves to exist in weeks, not quarters.

And if you already have a large system, we do not wade into a million-line codebase and prompt at it. That is the METR trap. We build the new capability as a clean, separate service beside it, with a narrow interface to the old world, so the part AI accelerates stays the part we are building.

This gap closes

Enterprises will eventually restructure around AI, smaller teams with wider scope, and the coordination tax will shrink. And as I argued in the last piece, the era of cheap AI is itself a window that is already narrowing.

Right now, both windows are open at once. The tools are underpriced, and most large organizations cannot yet convert them into output. A disciplined solo operator sits in the gap between those two facts. The cost of waiting is not standing still, it is paying next year's prices for this year's build.

The one question to ask

If you are deciding who should build your system, skip "how many engineers do you have." Ask this instead: how much of your pipeline does AI actually accelerate?

Every vendor will answer "all of it." So ask the follow-up they cannot spin: how many people sit between a decision and that decision being live for your users? Make them count out loud. Every name on that list is a step no model touches, and you are paying for all of them.

For most large shops the honest answer is a slice. For us it is nearly all of it. You are not buying code. You are buying the pipeline the code has to move through, and ours is short. Plenty of solo builders can say that now. The difference is what survives contact with production, and ours is running in the one industry that audits the answer. Seven-figure systems, without the seven-figure pipeline.

Tell us the problem, not the software you think you need. We answer as soon as it lands, with how we would build it and what it would cost. If the honest answer is that you don't need us for it, we will say that too.

Not ready to talk? Start with the proof: read how Coda got built.