Why your AI-built product still feels replaceable

Mik Bry · 2026-08-21 · ~9 min read · AI · Authorship

One of my own projects still runs. Nothing is technically wrong with it. Nobody complains about it. And it never quite became the thing I meant to build — I can't even point to the moment that happened, because there wasn't one. I handed an AI agent a pile of specifications and let it work. It followed every one of them. What it didn't have was my reason for building the thing in the first place, and eventually that gap showed up in the product itself: correct, competent, and quietly not what anyone had actually asked for.

It would be tidy to blame the prompt. I don't think that's what happened. Around the same time, I pointed a similar kind of AI agent at a different job — one where I'd already written a test suite that spelled out, case by case, what "finished" meant. It hit that target cleanly, overnight, while I was asleep. Same category of tool. Two very different mornings. What changed wasn't the AI — it was whether I had already decided, in a form the machine could actually check, what I wanted.

When nothing in the product reflects a specific person, problem or point of view, another team with the same tools can rebuild something that looks very similar.

01 — A competent product nobody quite asked for

Here's what "specifications without vision" actually looks like from the inside, because it's easy to hear that phrase and picture something obviously broken. It isn't. A specification tells a builder what to build: which screen, which button, which field. It doesn't tell anyone why this feature matters more than that one, who is supposed to open the thing at 9pm on a Tuesday, or what problem has to still be annoying them for them to come back tomorrow. My drifting project had plenty of the first kind of instruction and almost none of the second.

The agent didn't fail at any individual task. It succeeded at all of them, one after another, in order. The result was a house built exactly to a floor plan that nobody had actually decided to live in. Every room was where the drawing said it should be. I just hadn't picked a person to hand the keys to, so nothing in the house pointed anywhere in particular. That's a strange kind of failure — there's no error message for it, no failing test, nothing a reviewer would flag. The code works. Nobody had told it, clearly enough, who any of this was for. That part was on me, not on the agent.

02 — The same kind of AI, pointed at a real target

This isn't a controlled experiment. Different projects, different weeks — no scientist would sign off on calling it that, and I'm not going to. But it's a clean enough comparison that I stopped being able to blame the tool for the first project's drift.

Both projects ran through the same internal system I use to coordinate coding agents day to day — the tests, the reviews, the integration checks, the whole apparatus. That system is its own story, for another time. What matters here is what I fed it: two different kinds of instruction.

The second project had a test suite before the agent ever touched a line of code — cases that would pass, cases that were supposed to fail, and a clear line between the two. The agent worked through it the way water finds the bottom of a container: fast and unglamorous. By morning it had converged on exactly what the tests described. I hadn't watched a single step of it happen, and I didn't need to.

The agent performed best when the purpose and definition of "done" had already been authored. When I supplied activity without a clear purpose, competent execution drifted. That's the whole finding, and it's smaller than it sounds — but it's mine, pulled from my own work, not from a hot take I read this week.

03 — Why a system of agents converges so well when the target already exists

For a growing class of software products, writing the code is no longer the most expensive part. I'm not going to pretend that's a loss — I spent a good chunk of my career doing the parts of coding I no longer have to do by hand, and I don't miss most of them.

That's exactly why AI is so good at rebuilding things that already exist. Clone a familiar app, copy a competitor's feature, reimplement something whose shape is already public — an agent will chew through that with real competence, because the intelligence in the task was never the coding. It was the original decision, made by someone else, that this specific thing should exist and work this particular way. The agent inherits that decision. It doesn't have to make one.

What AI is making dramatically cheaper is the middle of the process: turning a product decision into working software. That's genuinely the hard, slow, expensive part it used to be, and it's fair to be glad it's cheaper now. What it didn't take is the two ends of the process — the decision that a specific thing should exist, for a specific person, for a specific reason, and later, the decision that it's actually safe to hand to that person. My drifting project had a machine that could do the middle brilliantly. It never once had someone hand it the front end of that: a person, a reason, a "this, not that."

04 — The moat was never the tool

Every founder who's watched an AI-built product underperform has heard the standard answer by now: the real moat isn't the app, it's the data, the distribution, the domain knowledge, the brand. That list is correct. It's also one level too shallow — it names the symptoms of the thing without naming where any of them actually come from.

Take domain understanding. That's not something you research your way into over a weekend — it's what's left over after someone cared about one specific person's specific problem long after it stopped being interesting to think about. Or workflow fit: that comes from watching what a user actually does at their desk, not from what looks good in a demo. Even the data everyone points to as a moat only compounds into something useful because somebody decided, ahead of time, what was worth keeping and why. A database doesn't get valuable by filling up on its own.

Agents can turn those advantages into software, workflows and features very effectively once someone has defined the job. But the advantage itself comes earlier: from understanding who the product is for, what matters to them, and why. What separates a real moat from a commodity clone was never a capability gap — it's whether someone had already decided, before any of it got built, who this was for and why it mattered. Most of those durable advantages eventually trace back to that decision. Not to the code that came after it.

05 — Building the software is only one part

AI has made it much cheaper to turn a product decision into working software. That's a significant change, but it can also distort where founders put their attention.

The code is only one part of a product.

Someone still has to find a problem worth solving, understand how people deal with it today, decide which part matters enough to change, explain the product in words those people recognise, and find a way to reach them.

None of that happens automatically because the implementation got easier.

In fact, the cheaper building becomes, the easier it is to spend months producing features nobody asked for. When writing another feature costs a few prompts instead of a few weeks of engineering, saying no becomes more important, not less.

Marketing belongs in this loop too. Not advertising as an afterthought, but the work of understanding how a customer describes the problem, what makes them pay attention, what alternative they compare you with, and why they would trust you enough to try something new.

That's product work. So is talking to users. So is watching what they actually do after launch and changing your assumptions when reality disagrees.

AI can accelerate all of those activities. It can analyse interviews, draft positioning, explore competitors and generate experiments. But it cannot remove the need to decide what evidence matters and what you are going to do about it.

06 — Authorship doesn't disappear — it moves up

Coding was always a means — an invented way to make a computer do what someone wanted without wiring transistors by hand. As AI makes implementation cheaper, that's fine — nothing essential was lost, because a means is supposed to get cheaper. Authorship was never a means. It's the reason a means gets used at all: the decision that this specific thing should exist, for this specific person, for this specific reason. A faster builder doesn't get closer to that decision the way a faster compiler gets closer to a working program. Speed was never the constraint.

If AI keeps getting better at authorship-shaped work too — sensing what a market wants, drafting the plan, choosing which feature ships first — that decision doesn't vanish. It moves up a level. Someone still has to decide what the system itself should be trying to do, and for whom. On my drifting project, the fix wasn't a smarter agent. It was me finally showing up with an answer to "for whom, and why" — the one input no amount of additional competence was ever going to generate on its own.

Authorship isn't writing every line. It's remaining responsible for the direction of the product: who it's for, what problem you're choosing to solve, what you learn from the people using it, how you reach the next customer, and which direction you take when reality disagrees with the original plan.

The prompt is one sentence. The decision behind it still has to come from someone. That someone is still you.