The part you can't generate

By any honest definition, Dustav is vibecoded. I haven't written a line of it. Every file on the server was typed by an AI, working from my descriptions. So when I sat down one evening and asked how many solo builders on earth have built something like it, I expected the answer to be "lots." Making software is nearly free now, and I'm living proof.

The honest answer was stranger. Thousands of people have built an AI that reads your Gmail and drafts replies. It's one of the most common side projects of the last two years. Maybe a few hundred have one running on real people's inboxes rather than a demo. Some dozens have made it through Google's security audit for apps that read mail. And the number who've built the whole thing (a true mirror of Gmail, a calendar, workflows, facts learned from what you actually told customers, prepaid billing, and real businesses using it every day) is probably a handful.

I can't prove those numbers, and I don't want to oversell them. But the shape feels right, and the shape raises a question worth an essay. If the code is free, and mine was written the same way everyone else's is, what exactly is rare?

The filter moved

For most of software's history, the cost of building was the filter. Writing a real app took a team or a year, so most ideas died before they shipped. It was a bad filter, because it selected for time and money, not for judgment. But it was a filter.

That filter is gone. A weekend now gets you a working product, a nice landing page, and a demo video. So the filter moved somewhere else. It isn't at the build any more. It's at month two, when the app meets a real person with a real business, and something that worked on Tuesday has to keep working on every Tuesday after.

That's where the sea thins out. And the things that decide who makes it through turn out to be the things you can't generate.

A feature is something it can do. A promise is something it can't.

A vibecoded app has features. You can list them, and so can its competitors, and so can the AI that builds the next one.

What a business owner actually buys is different: promises. Things that stay true while she isn't watching. Dustav never sends an email by itself; she's the one who hits send. A folder in Dustav is a label in Gmail, both directions, always. A fact Dustav "knows" about her shop came from something she actually said to a customer, never from a guess. Look at those closely and they're mostly about what the software won't do. A feature is a capability. A promise is a constraint that holds forever, against every future change, including the ones you haven't thought of yet.

You can generate a feature in an afternoon. You can't generate a promise, because a promise isn't code. It's code plus the thing that stops the next change from breaking it. Dustav has 107 verification scripts, and most of them exist to pin a promise, not to test a feature.

Take the facts promise. The part of Dustav that reads incoming mail is never given a way to write a fact about the business, because incoming mail is written by strangers. What Dustav learns on its own comes only from her own sent replies. That isn't a sentence in a prompt that the model is asked to respect. It's a check that fails the build if any future change hands the inbox reader that power. The promise holds because nothing can quietly undo it.

That's the difference between software people can rely on and software that merely works today: every promise is a permanent piece of knowledge the system enforces, instead of a thing someone remembers to watch for.

What can't be generated

When I look at why Dustav made it through month two (and three, and four), I keep landing on the same short list. None of it is code.

A person who says no. An AI will tell you your idea is good. A busy shop owner won't open the page. I built a beautiful map of the business, a constellation of customers and threads, and both of my design partners independently called it pointless. It's deleted. I built a queue of questions for Dustav to ask the owner about her business. She dismissed them. Every question that did get answered was answered by her own sent replies, which Dustav was already reading, so the queue is deleted too. I kept inventing a smarter inbox and lost to plain Gmail four times, each time on a screenshot from someone actually using it. You can't generate that contact. It costs a real person's time, and it's the only thing that reliably tells you you're wrong.

The memory of why. An AI starts every session cold. If you killed something last month and didn't write down why, the next session will cheerfully and expertly build it again. So Dustav has a session log that's now 2.4 megabytes, and a list at the top of its instructions called Settled — don't re-open. That list is the scar tissue: every decision that took real evidence to make, with the reason attached. It's the most valuable file in the project, and it's made entirely of things we decided not to build. Code can be regenerated. Four months of reasons can't.

The willingness to delete. Adding is free, and the tool never suggests stopping; it has no stake in simplicity. So vibecoded software accretes. Over Dustav's life, the repository has seen roughly 312,000 lines added and 125,000 deleted. Among the dead: the entire companion personality it started as, a marketplace, four auto-filled tables of the business's books, a second character, the map, the dashboard, the question queue, and the whole layer that let several people share one account. Every one of those worked. Deleting working things is the hardest call in software, and when building costs nothing, it's the most important one left.

The boring tax. Google's audit for apps that read mail isn't hard so much as unglamorous. You declare every permission by hand, prove each one on video, keep every document matched to the deployed code, clean the dependency list the week before the scan, and answer 48 security questions with evidence. I wrote about ours separately. Nobody is excited to do that work, and that's exactly why it filters. The weekend app never gets past the warning screen.

Time is the input

Put that list together and there's one ingredient under all of it: time. Time with a real user. Time for reasons to accumulate. Time spent maintaining promises rather than shipping features. Time on paperwork nobody sees.

AI compressed almost every step of making software, but it can't compress that. It can't make a shop owner use the product for four months in four days. It can't make a decision's history exist before the decision happened. So when making gets cheap, the value moves to whatever is expensive to keep, and what's expensive to keep is care, paid in time.

That's my best answer to why something like Dustav might be rare. It isn't talent, and it certainly isn't typing. It's patience that got pointed at the right things, mostly by other people telling me I was wrong.

The honest part

Rare isn't the same as valuable. There are funded teams working on the same problem right now, with more people and more money, and some of them are good. The market hasn't voted on Dustav yet. Two design partners using it every day is a real start and not yet a company. Being one of a handful gives me a head start on the hard part. It doesn't let me skip it.

But I think the lesson holds whether or not Dustav wins. For a while, people will be impressed by what AI can build. That's already fading, because everyone can build. What will stand out is what someone kept: the promises that held, the things they deleted, the reasons they wrote down, the months they spent listening to a person who wasn't impressed.

I once wrote that the hands got cheap and the judgment got more valuable. Four months later I'd put it more simply. The hands got cheap. Everything that takes time didn't.