I handed AI agents almost the whole product. Except one part - and that part is the job

Recently an agent built a working prototype of MERIDIAN in a couple of days. A live page - where I’ve been, where I am, where next - plus a world map the app draws itself from the EXIF in your photo library, on-device, with zero manual input. Expo, React Native, a black SVG map. What would have taken a week of dense frontend a year ago was ready to screenshot-test the same day.

Here’s what that speed did. It didn’t remove the risk - it moved it. While code was expensive, the main question was “can we build it.” Now building costs almost nothing, and one expensive question is left: am I even building the right thing. The risk moved off “make it” and onto “decide what to make.”

So I rebuilt how I run product. Not around who writes the code - there’s unlimited code now. Around who decides which code is worth writing at all. I barely write myself - I hand tasks to agents, check, and cut. Below is how it’s wired. Not “look at my system,” but something you can copy.

What the agents do, and what I hand to no one

The work is split into pieces. Each piece has an agent that carries the volume, and a piece I keep. The line between them is the whole job.

1. Discovery. Agents comb the market, competitors, user conversations, my own note archive - and pull out what I physically can’t read in time. I keep one question for myself: which of these patterns am I willing to believe, and which just sound good.
2. Hypotheses. An agent spits out twenty versions of a feature faster than I write one. The volume is its. The taste is mine: which two of the twenty are even worth touching.
3. Decisions and priorities. Here the agent is a sparring partner, not a judge. It sorts hypotheses against what I actually know, argues, looks for holes. The final cut - what goes on the roadmap, what goes in the bin - is mine. It’s irreversible, you don’t delegate it.
4. Build. Claude Code and agents write the code, the design, the schemas. I read their output the way a senior reads a junior’s PR: not “does it work,” but “is the estimate lying, did they cut a corner that blows up in a month.” I came into product from engineering - I started on JavaScript and React, then tech lead and eng management - and that’s not nostalgia now, it’s a tool: I catch lies in code because I wrote code.
5. Review. A separate agent attacks what the first one built. Its job is to find where it falls apart. More on this below - it’s the heart of the whole thing.
6. Orchestration. The layer holding the other five: which agent on which task, in what order, with what context. That’s Yan OS - a layer on top of Claude Code: projects, agents, schemas, hooks, scheduled runs, a handful of MCPs. One conductor. Me.

Notice what I did NOT hand to agents: deciding what to believe, the final roadmap cut, and checking someone else’s work for lies. Everything else is volume, and volume is cheap now.

How one agent catches another one lying

An agent left alone lies with confidence. It generates a hypothesis, justifies it, and serves it as fact - in the same tone it would use for the truth. So the one that generates and the one that checks are different in my setup. And between them sits a simple sort. Every claim - mine, a user’s, an agent’s - lands in one of three buckets:

• know - real data, behavior, a pattern that holds.
• looks like - a signal, not proof.
• want it true - a wish, unconfirmed for now.

Anything in “want it true” gets a test attached: confirm or kill. Nothing rides into the build unmarked - and my own gut gets the hardest check, because it’s the loudest.

Where this actually saves me. An agent proposes a feature and writes “users want X.” The second one goes to the source and finds that “want” is one thread in one chat. That’s “looks like,” served as “know.” Without the second agent that “want” would have rolled onto the roadmap dressed as data. With it - it gets a test and waits. Costs pennies, and catches the most expensive class of error: confident lying that looks like fact.

What the speed exposed on MERIDIAN

Back to the prototype, because the whole point is in it.

Before MERIDIAN I killed the previous hypothesis - Nomad Bridge, a two-sided marketplace for nomads. It didn’t survive my own teardown: two sides, both needed from day one, the classic cold start that kills marketplaces, and the only paying demand I could find was by analogy, not by evidence. Inside that dead product sat a small feature I never took seriously - a profile page with a map of the countries you’d been to. I threw it out with everything else.

Then I spent a month looking for the next thing. Around 350 ideas, nine runs with agents, and in almost every run one motif kept surfacing - that same movement map. The feature already in my hands, that I hadn’t seen.

Here’s the trick. The agent built the prototype in days - and that speed is exactly what showed the hard part was never the code. The hard part was that I spent a month scoring 350 ideas on a spreadsheet and nearly missed what was in my pocket. When code was expensive, slow building masked the error in my head - you build so long you never notice you’re building the wrong thing. When building got fast, the one real job was left naked: decide what’s even worth building.

Where it breaks (without this part it’s an ad)

Honest now, or everything above is just a nice shop window.

The client of this system is me. One user, who’s also the developer, who’s also the one who needs it. Which means the gains aren’t proven by numbers - only that it suits me better, which is the weakest proof there is. Yan OS isn’t finished and, honestly, by its nature never will be.

Next - an agent loves its own ideas. A second agent grown from the same model tends to love the first one’s ideas a little more than it should. So I keep the final knife, not the second agent: it lowers the lying, it doesn’t zero it.

Context costs money and attention. For an agent to judge well you have to feed it the right context, and gathering and keeping that context fresh is work nobody counts until it quietly eats the speed gain. A system that saves hours on the build easily returns them through the back door, on wrangling context.

And the main thing - I can’t be replaced exactly where there’s nothing to check against. An agent is brilliant when there’s a reference to compare the answer to. When there’s nothing to compare - when the question is “am I building the right thing” and the market hasn’t answered yet - taste decides, appetite for risk, and willingness to carry a product for years. That doesn’t hand off yet. The whole thing stands on it - more on that here: when building gets cheap, judgment becomes the job.

What a team buys when it hires a person

Put it together. When design and code are almost free, a team hiring a product person stops buying a pair of hands to execute a spec. There are unlimited hands now, and they’re cheaper than any hire.

What gets bought is exactly what I didn’t hand to agents: deciding what to believe, the discipline to kill your own hypotheses, and a nose for lying that sounds like fact. Not the person who writes a PRD faster. The one who runs the agents that write the PRD - and knows which one is worth building.

I built this alone, with agents - the same way I ran Unicorn Embassy for three years with zero ad spend. Building dropped to nothing. The price of judgment is the only thing that went up

Yan Nerovny - AI-native Technical Product Lead and Head of Product. Founder of Unicorn Embassy (180+ events, 9 cities, 7 countries, zero paid acquisition). Writes about product, AI and emigration at nerovny.com. Telegram @nerovny_blog, Instagram @nerovny.