I have been a developer for a long time. Long enough that my first scripts were dBASE III, before Clipper, before compiler days. I know what a good system looks like, what a bad one looks like, and most of the awkward in-between places where things break. I pay for Claude Max so I have the tokens to do real work. I can easily spend ten hours on a single feature and end up with code that is not yet workable.
Then someone with no software background ships an app on a weekend. Wtf? How?
I have been turning that question over for a few months. The answer I keep coming back to is not the one I expected.
The part we don’t talk about
When I work with Claude on a feature, the planning is not a formality. I spend real hours unpacking the problem before any code is written. The implementation runs in 75-minute sessions where the model writes and I read. That is part one of a five-part plan, for a single feature inside a much larger app.
What do I end up with at the end of those sessions? Certainly not a working piece of code. I end up with something I can keep working with, because I have been reading every step and pulling it back when it drifts. I see the divergence because I know what good looks like. I remind it of choices we made last week so it does not reinvent something. I push it out of the absurd pathways it likes to wander into when there is no one at the wheel.
That is the part we don’t talk about. The full-time job of keeping the AI on track.
After the feature is “delivered”, the actual work starts. Walking the UI. Auditing the data model. Catching the silly choices. Pushing back on the over-engineered solutions to problems we never had. Trimming the complexity the model inflated when it had nothing better to do.
How is the non-developer gliding?
The most probable answer is they are not. They have made something that looks like magic to people who do not know what to look for. The same inability to spot divergence in the code is the same inability to spot what is broken in the result. The output does what the demo needs and very little else. The data model is wrong in ways the founder cannot see. The architecture wanders in ways that will haunt anyone who tries to build on it. They do not know any of this, because they cannot read the artifact they are holding.
That should be the end of the story. We get sniffy about it, the rant ends, and nothing changes.
From all the ranting will come nothing, of course. So let me try a different question.
There is a real artifact here
Forget for a moment whether the vibe-coded thing is good or bad. That is the wrong axis. Ask instead what kind of artifact it is.
It is not a product. That much we have established. A specification it is not either, because a specification describes what should be built, while the vibe-coded thing describes what someone tried to build when no one helped them describe it. A Figma prototype shows the surface a designer chose. A Bubble app is opaque to the kind of reading we are about to do. The vibe-coded thing sits in a category of its own: a runnable record of intent.
What an intent record actually shows you
If you have ever asked a client “what did you have in mind?”, you know how badly that question fails. The client tells you what they have in mind by pointing to other apps, gesturing at workflows, and going quiet at the parts they have not figured out yet. You leave the meeting with a brief that is half their idea and half your guess at the rest. Often, more than half is missing.
Now read a vibe-coded app instead. The architecture they expected is right there in the file structure, however wrong it is. The features they thought were core are the ones they made the model fight for. The places they got stuck show up as the most convoluted code paths, because they kept asking the model to make them work and the model kept improvising. The screens they cared about are detailed; the ones they did not are placeholder. The data model, however broken, is the data model they were imagining when they pictured the app working.
That is more information than I have ever got from a discovery call.
You read it the way you might read a confession. This is what I was trying to build, before I knew how to say it. Not the thing they wanted, but the thing they pictured wanting. A real artifact, finally, for the part of the brief that has always been missing.
What changes when you read it that way
Don’t try to make the vibe-coded app production-ready. That is the trap. The foundation is wrong in too many places, and “fixing the last few things” turns into a rebuild dressed up as a clean-up. Everyone is angry by month three.
Read it once, properly, for intent. Make notes on what they expected, where they got stuck, and what they tried to insist on. Then sit down with the founder and walk them through what their own artifact tells you. Most founders have never seen their idea reflected back at them in a form they cannot edit on the fly. It tends to clarify things.
After that you are doing the same work you have always done. Designing a system on a clean foundation, with a brief that finally reflects what was actually wanted. The vibe-coded thing has done its job. You do not need it any more.
Read the artifact for what it is. Not a product. An intent record. Then start the real build with a brief in your hand that finally means something.
I’m Wilfred Greyling. I build ReadyRun, which helps businesses see their operations clearly and close the gaps that matter.