# Nobody Vibe Codes a Can't List By Robert Sfeir ยท October 28, 2026 Agents write the code now. What still needs a human is owning what must be true, and judging how it feels. ### The gist (for those who don't read)
Prose hides the TBDSpecs and user stories let gaps hide, and agents fill them with slop. A clickable mockup can't hide a missing box.
Hold production to a second copy of the truthWe keep the mockup's rules as a separate model, and walk-throughs check the real app against it every night.
Enterprise means proving what it refusesEvery can't, for every role, in its exact words. Nobody vibe codes that list.
The PM owns what must be true, and humans still judge the feelAgents check that the words match. Only a person knows how they land.
### The questions I keep asking Ever since generative AI and agents showed up in my work, I've been chewing on the same handful of questions. What does this mean for how we work? What should we still be doing, and what should we stop? How does a product manager's job really change? And I don't mean vibe coding your way through a weekend app. I mean enterprise software, the kind where getting a permission wrong means someone reads a memo they never should have seen. What still needs doing? What do we let go of? What do we validate, and how? Those are not questions that will ever be answered, but they are questions I'll keep asking because the answer changes. Look, I don't have a framework yet, I don't know if I ever will or if it even matters that a framework exists. To me, frameworks are a guide for how you might want to think of something. Applying a framework wholesale is just going to cause you trouble. A framework is really defined as: An organized set of ideas, rules, laws, values, or methods that serves as a guide... as a guide. So what I have is a few products, built mostly by agents through a few model generations, and a growing pile of evidence about what works, and what's a waste of time, and tokens. > I don't need a framework. I need evidence of what works, and what's a waste of tokens. ### Prose hides the TBD I believe to this day that if I wrote the requirement clearly enough, the build would match it. Before agents it wasn't always true, no matter how much I believed it. Even with the best UI and UX work in place, the build often didn't match. Specs are prose, and even a small user story is still prose, and prose is very good at letting "TBD" hide in plain sight. I thought with agents it would get better, but the reality is that agents don't fix that. The slop they generate makes it worse, and keeping them focused, recording only facts and getting their work reviewed is a job on its own. But something has to provide the right specification, so we can build the right thing, and build it right. > Prose lets a TBD hide in plain sight, and agents only make it worse. ### A mockup can't hide it For us, that something turned out to be clickable mockups. A mockup of a screen with functionality you can experience can't hide a "TBD." The TBD is obvious: "Wait, how do I set the discount on this plan for a yearly payment? There's no box"... you can't miss it. It has to not only say *something*, it has to show it. If it shows it, an agent can follow it (mostly). So we started with clickable mockups. Not wireframes, and not a pretty Figma file. A mockup you can sign into as any number of roles and try to do things. Behind it sits a small working model of the rules, and next to it a page listing 164 lines of what each role can and can't do. Each can't comes with the exact sentence the product shows a person when it refuses the action. "You can't answer your own request. Someone else in Marketing has to." Why? Because products we build are for humans, and if a product can't be clear on the action you took, then what's the point? > A screen has to show something. That's why it can't hide a TBD. ### Making the app prove it We then made the real app prove it matches. Every push checks the rules. Every night the browser walk-throughs click through the real screens as those people and record video. Before each release, a full walk runs on a seeded copy of the product. It tries every can and every can't, and checks the rules, the functionality, the words, and buttons. It checks to make sure that the functionality we know we wrote and that a user can see is actually there and works. Most of this process runs through [Masthead](https://github.com/kyroco/masthead), the Claude Code plugin we built for our own work and made public: the hooks that refuse a step done wrong, the skills that carry an issue from scenarios to a reviewed pull request, and the reviewer agents that check what got built. > Every night, the real app has to prove it does what the mockup promised.
Production is held to a second copy of the truth: decide together, mockup and model, agents build it, walk-throughs check the app against the model, and a mismatch goes back to be fixed and run again.
### Proving what it refuses That list of can'ts is, I think, the line between vibe coding and enterprise work. A weekend app only has to prove it works. Enterprise software also has to prove it refuses, correctly, every time, without leaking what it refused to show. That extends beyond the app, to the infrastructure, how you design the database, how the system is protected, what encryption you use, etc... Nobody vibe codes a can't list. > A weekend app proves it works. Enterprise software proves it refuses. ### What changes for the product manager This brings me back to the product manager. When agents write the code, the product manager's job stops being "write down what to build." It becomes **"own what must be true, and build the thing that checks it."** That list of 164 lines is a product artifact and also a test, and honestly I didn't plan it that way, it just turned out that the most useful thing I could write was something a machine understood completely: what the product is and does. That also changed what "validated" means. There are three questions, and they need three different answers:
Three questions, and only one is automated: does it do what we asked (rules model and walk-throughs, every push and every night), does it feel right (a human at the screen), is it the right thing (customers).
Most teams only answer the first one, and some not well. > The PM's job isn't to write down what to build anymore. It's to own what must be true. ### Does it have a name? I felt like I was converging on an existing model, a framework, and I went looking for a name, assuming someone was already ahead of me. It turns out the closest relative I could find is Specification by Example, Gojko Adzic's approach: concrete examples, often written as Given/When/Then, that double as tests. We do that. Our issues carry Gherkin. The newer cousin is prototype-driven development, which Versent described this spring: build the prototype as real code, write the tests during discovery, and the prototype becomes the product. We sit between the two, because of one decision we made almost by accident: **we kept the mockup's rules as a separate, permanent implementation and check production against it**. Spec by Example has no prototype. Prototype-driven development turns its prototype into the product. We keep a second copy of the truth and make the first copy argue with it. That's where our coverage of the can'ts comes from. That's where we can ask one agent to write it, and another to look at the first copy and validate. Had we done this before agent work it would have been an enormous waste of time and resources. Humans also know how to look at a screen and say: yeah, no, that's not right. Agents don't, unless you ask them to compare to something. So if I look at the original and approve it, and the agent writes it, an adversarial agent can look at what I saw and tell the agent implementing it that it was too drunk on a Friday night to implement things right. > We keep a second copy of the truth and make the first one argue with it. ### What it costs, and what's next Of course, nothing's free. Keeping a second copy of the truth means keeping it in sync, and that's real work. In one recent milestone, 8 of 26 build issues were mockup updates, keeping the reference current so the agents had something true to build against. That's the price of the coverage, and honestly, I'd pay it again. When an agent read through that same milestone, it found seven places where issues disagreed with each other or with the decision record... which is exactly what this approach is supposed to surface. Better an agent finds it in an issue than a customer finds it in production. (It even caught our README saying two different things about which one wins. Fixing that.) Those seven told us where the next gain is. Today a single decision lives in three places: the decision record (the why), the mockup (the what), and the issue's scenarios (the slice we're building). Four, if you count the rubric the tests use. Every copy is one more place for drift to creep in, and the walk-throughs can only be as current as the copy they read. This is our next iteration to improve on.
Each decision gets one home, and the rest link to it. Today the decision record, mockup and issue each carry copies. Next, the decision record owns the why, the mockup owns the what, and the issue owns the slice and links to the rest.
The good news is we already have the rule for this, we just hadn't applied it to decisions. In our code it's "one way in and out": a body of data is reached through one module, and nothing else writes to it. Decisions get the same treatment. The decision record owns the why. The mockup owns the what, down to every refused sentence. The issue owns which lines this change builds, and links to the rest instead of copying them. We're already halfway there: a test fails today if a rule in the mockup has no match in production. Next, the walk-throughs read their words straight from the mockup instead of pasting them in. And the screens stop being a drawing: built once in the real UI stack on made-up data, so the screen we review is the screen we ship, while the rules model stays separate and keeps checking it. > Decisions need what our code already has: one way in and out. ### More amigos Who sits around that mockup is going to change as we grow. Today it's me and a handful of agents. Tomorrow it's business, product and agent advisors in the same room, arguing over one screen instead of three documents. Adzic called his version the three amigos. Ours'll have more amigos... and some of them don't sleep. > One screen in the room beats three documents in three places. ### Am I just holding on? Now here's the part I question myself on, more than I'd like to admit. Devs want to look at code. I was one of them, and honestly, I learned to let that go with Opus agents. Not because I stopped caring, but because I ran out of evidence that my reading caught anything the agents and the tests didn't. UX folks want to look at screens, and here we still embrace that. It's our human-in-the-middle thing: someone sits there and clicks and tries to feel the customer's friction and pain. No agent can do that. So is that the same reflex? Am I holding on to the mockup the way devs hold on to the belief they can write better code than Claude? Partly, yeah. A lot of what's in the mockup is specification: who can do what, and the exact sentence when they can't. That's code wearing a cool xkcd t-shirt. If I'm proofreading it screen by screen, I'm just the dev reading every line again. But some of it isn't specification, and that's the part I don't think we let go of. Does a refusal read as helpful, or like a door slammed in your face? Is the third click one too many? Does someone walk away feeling capable, or feeling stupid? Are they delighted when the screen loads, or are they completely overwhelmed with anxiety? An agent can tell you the words match. It can't tell you what they feel like to a 'hooman'. Not today, and I don't think anytime soon. (Watch a frontier model prove me wrong tomorrow morning.) The test I keep coming back to: if I stopped looking at the screens tomorrow, what'd break? Not the rules, the walk-throughs would catch that. The customer would... and until we can build them, nothing we've built would notice. > An agent can check that the words match. Only a human can feel how they land. ### My current answer So that's my working answer, for now, to the questions I started with. Let go of reading what the machine can check. Own what must be true, in one place, in a form something can hold you to. Keep the human where the judgment's about how it feels, the customer experience, not whether it's right. Ask me in a year which of those I actually managed to let go of. I'd write a spec for the answer, but, well... we've established how that goes. > Let go of what the machine can check. Keep the human where it's about how it feels. ### How what we do is different, and works for us
DimensionSpecification by ExamplePrototype-driven developmentKyroco
Where the spec livesText examples in tables (Gherkin, FitNesse)The coded prototype and its tests, plus an API contract and a design docA clickable mockup, an executable rules model, the abilities list, the decision record and the issue's Gherkin
Example formatBusiness-readable rows, often GherkinScreens on the real UI stackGherkin scenarios in the issue, plus screens, plus every can and can't per role with its exact words
Negative casesWhatever examples the team thinks ofSad paths written during discoveryEvery can't line for every role, each checked for refusal with no change and no leak
Who specifiesBusiness, developers and testers togetherA frontend developer embedded in design, with real users testingBusiness, product and agent advisors together, working from the screens. Today that's me and the agents, with business added as we grow.
Test oracleThe examplesThe prototype's testsA second implementation (the rules model) plus walk-throughs
How the spec reaches the testsThe Gherkin runs as writtenTests written alongside the prototypeGherkin translated into tests by hand. A gate checks the mockup's rule cases against the production rules, by name. Walks paste in the refusal words by hand. Needs improvement: walks read the words from the abilities list.
What happens to the prototypeNo prototypeIts code goes into productionStays separate and checks production. Needs improvement: the screens become production (built in the real UI stack on made-up data), and the rules model stays separate to keep checking it.
When validation runsContinuously, on every changeTDD baseline during the buildRules on every push, browser walks every night, full walks on a seeded copy before each release. The mockup's own checks only run locally.
Living documentationThe core idea, in one placeNot statedSpread across three places: the decision record, the mockup (abilities list, rules model and pages) and the issue's Gherkin, with the test rubric as a fourth copy. Needs improvement: consolidate.
Where the why is recordedOutside the methodLow-level design docThe decision record
Sources: [Specification by Example, Gojko Adzic](https://oreilly.com/library/view/specification-by-example/9781617290084) and [Prototype driven development, Versent](https://versent.com.au/blog/prototype-driven-development-an-sdlc-for-the-ai-age/).