Vibe Coding Moves the Work to Decisions
Agents were supposed to close the loop on their own. They stop at questions no repository can answer, and what decides the outcome is how often I choose well.
When I started building services with coding agents, I expected the loop to close by itself. Describe the product — say, one of the saju fortune-telling sites that keep appearing here in Korea — and let the agents pass work between each other. One builds, another reviews, a third notices what is thin and proposes the next revision. Repeat until the result is good. The premise was that autonomy would eventually cover the whole distance from an idea to a service worth shipping.
The loop does run. Code appears, tests get written, gaps get found and closed. But it stops, repeatedly, at a class of question it has no basis to answer. Not because the model is weak. Because the answer is not derivable from anything in the repository.
The questions an agent cannot answer for you
The questions that stopped the loop were never technical. Three of them, from products I actually run:
- How certain should the result sound? Clad turns a photo into a personal color analysis. A season label on its own tells someone nothing, and lighting, camera processing, and edits all move the answer. So the product explains its reasoning, says where it becomes unreliable, and offers a path to retake the photo. It gives a starting point rather than a diagnosis. Nothing in the codebase implies that choice, and a more confident-sounding version would have demoed better.
- What should the product refuse to sell? HappyBirthTown is a pixel town where friends and family gather for someone's birthday. Cosmetics there unlock by participating and cannot be bought at all. That removes the obvious revenue model deliberately, so the reward loop has to come from showing up. An agent optimizes toward a goal. It does not decide which goal you decline.
- Where does the model ceiling sit? Move to a stronger model because the output improves, or hold the current one because the output is already accurate enough and the unit cost matters more? Every AI feature carries this question and none of them answer it.
These are not gaps in a model's capability. They are questions whose answers depend on what I want the product to be — and that intent has never been written down anywhere the agent can read.
Automated checks confirm the code, not the product
Last week the portrait on my own About page was rendering wrong. It is a 1200×1600 photo. It was being drawn at 496×1847 — a narrow vertical sliver of a face, because one CSS class overrode the aspect ratio and the crop went unnoticed.
Everything passed. Lint, type checking, unit tests, an end-to-end suite with accessibility assertions and visual snapshots, the production build, and a post-build verifier that checks routes and metadata. None of it failed, because none of it was wrong by its own definition. The markup was valid, the tests asserted what they were written to assert, and nothing in that system knows what a photograph is supposed to look like.
A person opened the page and said the picture looks cut off. That sentence contained more product information than the entire test suite.
This is the shape of the limit. An agent can verify that code runs and matches the specification it was handed. It cannot verify that the specification was the right one. The second question is the one that determines whether a product is good.
The tree, and where the leverage moved
I have started thinking about this as a decision tree. Every generation is a branch point. What changed with agents is the cost of producing branches: they arrive faster than I can evaluate them, and that speed is real and worth having.
What did not change is that the tree has no labels. The agent cannot tell me which branch leads where I want to go, because where I want to go is not in the code. So the work moved. Less time typing, more moments choosing — and the moments arrive faster and more often than they used to.
Stated plainly, the quality of what I ship looks something like the number of decision points I actually take, multiplied by how often I choose well at each one. Both terms matter, and the first is the one people lose.
Because the real failure mode is not choosing badly. It is not noticing that a decision was there at all. The generated code compiles, the page renders, the tests are green, and the branch gets taken by default. Nobody decided. Something was decided.
Care is an operating property, not a feeling
The word I keep returning to is care — how much I actually want this particular product to be good. That sounds sentimental, but in practice it is mechanical. Caring is what makes me open the page instead of reading the test output. It is what makes me ask whether the trial should come before the card, when accepting the generated flow would have been faster and nothing would have complained.
Someone who cares about a product takes more branch points per feature and gets more of them right. Not because they are more skilled in the abstract, but because they looked. Attention is the input; hit rate is the output.
So I no longer think a fully autonomous path from prompt to finished service is the goal, or that it is close. Generation has become abundant. Judgment is the constraint. Increasingly, what separates one engineer's product from another's is not how fast they can produce code, but how many decisions they notice and how often they get them right.