An afternoon with Claude is not an estimate

At Nerdearla, one topic kept coming back from talk to talk even when it was not in the title. Roles are moving, and not only the developer's. CEOs and executives no longer stop at running the business: they open Claude or Cursor on a Saturday and test, themselves, that idea they had wanted to build for years. Vibe coding: you describe what you want, the model writes the code, and in a couple of hours you have something you can click.

I had seen it before hearing it there. Sometimes up close, sometimes secondhand. And there is nothing wrong with it. Validating your own idea in an afternoon, without asking anyone for a sprint, is one of the best things AI brought.

The problem is not the prototype. The problem is what the prototype does to the yardstick.

Every vibe coding session ends the same way: the idea works and it took hours. After the third or fourth one, that stops being an experience and becomes a reference. “This takes an afternoon.”

Then an estimate arrives from the team. Six weeks for something similar to Saturday's. And the reaction is not to ask what is in those six weeks. It is to think the team is slow.

It is not bad faith. It is a bias, and it builds itself, session after session, without anyone noticing.

A prototype built with AI solves the happy path. One person, one case, sample data, nothing failing. Everything else does not show up, so it is never charged:

• What happens when two people pay at the same time?
• Who can see what, and what happens when their role changes?
• Where do the logs go when something breaks at three in the morning?
• How do you migrate existing data without breaking anything for people who already pay?
• Who maintains it in six months, when the model that wrote it is no longer in the conversation?

Transactions, operations and maintenance are the product. The prototype is the idea with a nice face. Both are worth something, but they do not cost the same, and whoever only built the first one measures the second with the wrong clock.

The bias does not stay in an awkward conversation. It leaks into decisions:

• A date promised to a customer or an investor before asking anyone on the team.
• A roadmap with three features per quarter, because each one “is an afternoon”.
• A team that, to hit the date, cuts what nobody sees: tests, permissions, migrations. That does not disappear. It comes back as an incident.
• People who burn out chasing a yardstick that was never real, and who leave one day.

And the most expensive one, because it makes no noise: the team stops estimating honestly. If every real estimate reads as slowness, people start giving the number the executive wants to hear. From then on, whoever decides loses the only information that told them what their requests cost.

It was not a speed problem. It was a problem of trust in the numbers.

Arguing about the prototype's code does not help. A model wrote it so something would show, not so it would hold, and it is almost never what you will maintain. What is worth something is everything else: what problem it was trying to solve, which screen mattered first, what got left out without anyone noticing. That prototype is a spec, and often a better one than those that arrive in a document.

What works for me is sitting down with whoever built it and walking through it together, splitting it into three lists:

• What it solves: the flow they care about, the data it shows, the decision it enables.
• What it assumes: a single user, clean data, nobody else touching the same thing, nothing failing.
• What it does not know exists: billing, permissions, auditing, support, migrating what is already in production.

The first list is the Saturday afternoon. The other two are the six weeks. When they sit side by side, the estimate stops looking inflated, because the person who asked is seeing what the team sees.

Sometimes what comes out of it is that six weeks are not needed. Half of what the prototype assumed can wait, and a smaller version ships in two. That is a good answer too. What does not work is estimating blind, in either direction.

People in charge testing their ideas with Claude is fine. They come to the conversation with something clearer than many meetings produce. What does not hold is that afternoon becoming the yardstick for their team.

Before promising a date, walk through the prototype with someone who will maintain it and split it into the three lists. AI speeds up the idea. Keeping it alive is still someone's job, and that job does not show up on screen.