Does it work, or does it keep working?

Most arguments about AI-generated code are talking past each other. I have been watching this debate for months now and I think I finally understand why it never resolves: the two sides are answering different questions.

Robby Russell puts it plainly: your codebase doesn’t care how it got written. What it does, it does. He draws the analogy to the founders of the late nineties who built real businesses on Access and FileMaker — systems that professionals dismissed as toys — and the business ran on them for years. The code worked. Nobody cared that it came out of a wizard.

I find this argument genuinely hard to dismiss. And Robby is being honest in a way most people in his position are not: this threatens his consultancy model. He built a career around being the person you call when you need things done right. Now a client can prototype at a fidelity that used to require a designer and a developer, before they ever pick up the phone. That admission earns him the right to make the argument.

Paul Stack is also right. Vibe coding works great for the first few pull requests. You describe what you want, the model writes it, tests pass, ship it. Then you do that two hundred more times and one morning you open the codebase and realize you cannot tell which decisions were intentional and which were the model filling in blanks because nobody asked it to do anything specific.

“That’s the actual risk. Not the hallucination that blows up immediately — you catch that in five minutes. It’s the six months of code that works fine, passes every test, and slowly stops making sense as a whole.”

That is the ball of mud. The same one engineering teams have always built when they ship without architecture. Except now it happens in weeks instead of years because agents produce code so much faster.

Both of these observations are correct. The problem is that everyone in this debate is conflating two distinct questions. Robby is asking: does it work right now? Paul is asking: does it keep working six months from now? Those are not the same question and the answer to each has no bearing on the other.

I have seen both failure modes personally. I have inherited systems that were built quickly, worked fine on delivery, and became unmaintainable within a year. I have also seen teams spend months arguing about the right abstraction for something that should have been a weekend project. Both are expensive. The first cost is paid later, the second cost is paid upfront, and most people are bad at choosing which one to take on.

John McBride, who has reviewed over 90,000 lines of AI code this year, calls most of it grocery-store sushi. Fast, convenient, gets the job done. Not a criticism — he loves a quick sushi lunch. The problem is the industry is obsessed with shipping as much of it as possible, and eventually we are going to get sick.

Charity Majors at Honeycomb draws the line clearly: disposable code is here to stay, but durable code is what runs the world. The distinction is not about quality in the abstract. It is about time horizon and consequence. A weekend prototype that you throw away after validating an idea? Vibe it. The authentication layer of a SaaS that two hundred companies depend on? Please do not vibe that.

The mistake is treating these as a single category and then arguing about which camp is right. They are not in conflict. Robby is right about throwaway work. Paul is right about production systems. The question you actually need to answer is which kind of thing are you building right now? We already had to decide how much effort to put in a task and it is the experience the facilitator to find the right answer.

I have started asking this explicitly before I write a single line. Disposable or durable? That question does more work than any amount of debate about whether AI code is good or bad.