The Coherence Problem

Everyone's celebrating velocity. Nobody's talking about what happens when you succeed.

Everyone's talking about AI making solo developers faster.

Ship a SaaS in a weekend. Replace your junior devs. Build an MVP before lunch.

Cool. But nobody's talking about what happens when you succeed.

---

The Week That Changed My Framing

I spent the last week maintaining a multi-product software ecosystem — alone, with AI as my architecture partner. Not generating code. Not shipping features. Managing the coherence of a system that's grown complex enough to behave like a team-scale project.

One architectural decision triggered documentation updates across 21 pages. A single boundary change cascaded through 5 product requirement documents, 4 platform-level architecture decision records, and a dozen cross-references that all needed to stay internally consistent.

That's not a speed problem. That's a coherence problem. And it's the problem nobody warns you about when they celebrate the solo AI dev.

---

Speed vs. Coherence

Here's what I've learned building this way:

AI doesn't make you faster. It makes you capable of holding more complexity in working memory than one person should be able to.

That's a fundamentally different thing.

Speed means you do the same work in less time. Coherence means you do work that wasn't possible before — maintaining the kind of cross-system architectural consistency that used to require a team of people whose entire job was keeping the model straight.

When I work with AI on architecture, the value isn't autocomplete. It's that my AI partner can hold the full specification of a multi-product ecosystem in context while I make a decision — and then execute the downstream implications of that decision across every artifact it touches. In real time. Without drift.

A human team doing this would need an architect who understands the decision, a technical writer updating the docs, a project manager tracking the cascade, and a QA engineer verifying consistency.

I have one terminal and a conversation.

---

The Part Nobody Warns You About

But here's the part the "AI productivity" narrative misses entirely:

The system got complex enough that I had to build a new service just to manage the dependency graph between my own architectural artifacts.

Read that again.

I didn't build it because I wanted to. I built it because the cascade problem — one change rippling through dozens of documents — became its own engineering challenge. The AI partnership made me productive enough to create a system that now requires its own tooling to maintain.

That's not a failure. That's what real architecture looks like. It's just that most solo developers never get there because without AI, the complexity ceiling hits you long before the architecture demands it.

---

The Question Nobody's Asking

The discourse right now is fixated on velocity. How fast can you ship. How many lines of code per day. How quickly you can go from idea to deployment.

I'd argue the more interesting question is:

How much architectural integrity can one person sustain?

Because the companies that win long-term aren't the ones that shipped fastest. They're the ones whose architecture held up when it mattered — when the edge cases arrived, when the compliance audit landed, when the system had to evolve without a rewrite.

If AI is genuinely changing what a solo builder can accomplish, the interesting frontier isn't "build it faster." It's build it with the kind of structural rigor that used to require a team standing behind you.

---

The solo dev + AI revolution is real. I'm living it.

But if all you're using AI for is speed, you're solving the wrong problem. Speed was never the bottleneck. The bottleneck was always one person trying to hold an entire system in their head without losing the thread.

AI doesn't speed up that work. It makes it possible for the first time.

That's the unlock. Not velocity. Coherence.