Our client, a new startup, asked us for a one-pager. It should bring in leads, and a slider should explain who they are. I've been building websites and digital applications since 1995, so I knew how long it should take: ten days.
I was wrong.
I used Claude Code, and the work was done in one day.
But the speed is not the only interesting part. Once it was built, it took the people involved more than a week of changes before they could launch. The decisions came after the build, and took five times longer.
They weren't decisions about code. They were the real questions: Why do we have a website? What should it communicate? How do we communicate it best?
AI is so fast at making things real that people don't have time to understand what they've been given. When code took a long time, coding was the bottleneck. Now it isn't. The bottleneck moved.
Directing, not vibing
People would call what I did vibe coding. I don't like the term. If you understand code, you aren't vibing, you're directing. It's closer to leading a team than to typing.
I started from sketches in Figma. They had gaps, as sketches do. Not everything a page needs was there, and little on how the pages should work on a phone. Filling those gaps was the work. Sometimes I told Claude exactly how a part should work. Sometimes I asked for suggestions. Sometimes I told Claude it was wrong.
Claude can check its own work using tools like Playwright or Chromium. That isn't the same as a person looking. It isn't the same as looking at a real phone.
What I bring is a human eye, human judgment, and experience with digital services since the mid-nineties. That doesn't always make me right, but I notice when something is off.
So my experience isn't worthless. It has a new job: judging the result instead of writing the code. And I don't do that alone. I still have a team around me.
The uncomfortable bit
Directed well, AI writes better code than I do. It's faster, knows more, and ships fewer bugs. Some say at least ten times faster. My guess is more than twenty.
This is an unpopular thing for many to hear, but it is my honest experience, after working with AI for over a year.
So if writing the code isn't the hard part anymore, where did the challenge go?
Where it went
The challenge landed in architecture and systems design, and in knowing what people want and what produces business value. And in making all the decisions.
Garbage in, garbage out. That was always true. The challenge is to keep the garbage out in the first place. That got harder. Results arrive ten times faster and look finished. People think they have achieved something. Looking finished is not the same as delivering value.
We already get the calls: "We built it with AI, now we need something that works." I've been handed these builds. They're vibe-coded, often by someone without a firm grip on code. The idea is proven. The build is not. And they don't know what's under the hood.
The code is the smaller problem. The bigger one is whether anyone has worked out what the application they produced is for: what good it does, why it exists, how a person benefits from it.
When the web was young, clients told us their son could do it in an afternoon. Today they ask: "Hasn't AI solved this already?"
Same sentence, new decade. The honest answer is yes, mostly. AI can build it, but building was never the risk. The risk is deciding wrong and finding out late.
The work is in the iterations
There's a good side to this. Decisions now are made along the way, in real iterations, on something that exists. That's more agile, and it's a good way to work. The real work is in those iterations.
But right now they run on gut feeling, as they always have. Real iterations on real decisions should build on evidence that the business is getting better. There are several ways to get that. Real people using the application. Or data on how they behave in it, tracked and collected.
Two kinds of decisions
The decision on that one-pager was about content. What the page should say, and why. The other kind of decision is how a thing works, what the slider does, not what it says. Those decisions can be written down in a structured way. That's a spec.
The inversion
The codebase used to be the asset you protected. I no longer think it is.
If you document your features in a structured way, the code becomes reproducible from the spec. Building the spec is the work.
I've done this once. I built a web app. Two weeks of work. Then I built it again as an app for iPad, pointing Claude at the spec and at the existing code.
It took fifteen minutes to rebuild it for the iPad. I can't tell you what Claude took from the spec and what it took from the code. I didn't watch it work. I looked at the result. Testing that result took a good deal longer than building it.
So the bottleneck moves again, from building to knowing that what you built works. With a good spec and good infrastructure to test against, rebuilding software is a walk in the park. A booking system for a gym. A CRM system. These can be reproduced fast.
The spec shouldn't live in a Word file. You can structure a document, but only so far. It belongs in a database. As a tree: this is feature A, these are the sub-features of A. Every feature is its own record, and other things can be connected to it.
The tree gives you more than a tidy spec. When every feature is its own record, each one can be switched on or off. Not only for everyone at once, but for one specific person. That's personalization, almost for free. Two people open the same application, and each one gets only the set of features they came for.
That matters.
With AI it's easy to end up bloated with features nobody asked for. Switching features on and off per person is the way out of that.
How we work
At Varvet we use our own tool for this, Greenroom.
Research with AI goes into it. Decisions, open questions and findings are stored against project phases, alongside milestones and tasks. The spec grows as the work happens, instead of being written once and then abandoned.
Greenroom's own features are kept the same way. Tasks are a feature. Under it sits "Move a task through its lifecycle". Under that, "Set a substatus". Each one has a short description of what it does, and two flags: defined and implemented. Tests hang on the same tree. Some run as code, some an agent follows, some a person checks.
What clients ask for
Today clients ask for the product, not the spec, but they should order the spec. That shift hasn't happened yet. But people pay for reports. Why not for a specification, in a form a machine can build from?
If you do just one thing
When you build something new, define it in a form you can build from again.
What comes next
Once features are structured, something else becomes possible. The person using the application can steer it. Tell the AI you want the action buttons bottom left instead of top right, and it happens.
That leads to applications that adapt to each person. And to applications that improve by themselves over time. I think that's one of the directions digital applications are heading.
An upcoming blog post will be about building for that: always build the API first, always build an MCP, make feedback so easy to leave that it almost becomes a task by itself, and let the system learn.