The Team That Isn't There

Something changed quietly over the last year. Writing code stopped being the hard part of building software. An AI agent can now take a clear description of a feature and produce a working version of it in an afternoon. That sounds like the whole game, but it isn’t—because the bottleneck simply moved somewhere else. It moved to judgment: knowing what to build, whether the thing you built is any good, and who’s going to be annoyed by it on Tuesday morning.

Judgment has always been the expensive part. It’s why teams have product managers, designers, user researchers, and a Slack channel full of customer complaints. Those roles exist because one person’s opinion is a narrow instrument. The fix, historically, is to get more kinds of people in the room.

So that’s what we did. We just didn’t use people.

What a “persona” actually is

The unglamorous truth: a persona is a text file. Ours are a page or two of Markdown that gets handed to a fresh instance of Claude before it starts working. The file contains four things, and each one is doing a specific job:

• A name and a life. Not decoration. “You are Imogen Vale, a senior product designer who led this brand system, exacting, never pads, always gives exact hex values” produces measurably different output than “review this design.” The identity is a commitment device.
• A standing bias. Every good reviewer is biased, and the bias is the point. Ours is told to do the pairwise color math rather than eyeball it, and to say plainly when something is already right—which is the line that stops an AI from inventing problems to look useful.
• A required output format. Not “give feedback.” Ranked findings, exact targets, one thing to leave alone. Format is a leash.
• Its own tools. This is the part most people skip, and it’s the one that matters most. More on it below.

Run that file as a separate agent—its own context, its own reasoning, no memory of what you were just doing—and you have a colleague. Run five of them and you have a team.

The cast

To talk about this without giving away our own product, picture a different one: a platform that processes insurance claims. A claim document lands in an inbox, the system reads it, prices it, flags the sketchy ones, and puts the rest in a queue for a human to approve. Same architectural bones as what we actually build; nothing about it is ours. Every example below lives in that world.

Our roster looks like this:

Role	What they do
The Analyst	Market research. Goes and reads the internet—competitors, pricing pages, forum complaints, regulatory notes—and hands back the evidence. Runs before anyone writes a spec, so the spec is grounded in something other than vibes.
The PM	Writes the spec. Takes the research and the customer interviews, and produces an actual requirements document: what we’re building, what we’re explicitly not, and how we’ll know it worked.
The Designer	Judges craft. Palette, hierarchy, whether two status colors are indistinguishable at the size they’re actually rendered. Constrained to simplify, organize, clarify—every note must be a cut, a merge, or a recolor. She is not allowed to add features.
The Panel	Five customers. In our claims example: a claims adjuster who lives in the tool eight hours a day, a supervisor who only glances at the queue, a fraud investigator, an ops manager who cares about throughput, and a brand-new hire who doesn’t know the jargon. They react. They are explicitly forbidden from requesting features.

The order of the room

The sequence matters more than any single persona, because each one’s output is the next one’s input.

1. Ask the customers first. Before there’s a spec, we put the feature idea to the five ICP personas as a question, not a demo. “Your supervisor wants a fraud score on every claim. What do you think?” The adjuster says it’ll be ignored unless it explains itself. The new hire says she won’t know what a 0.7 means. That’s the spec, already.
2. Send the analyst for evidence. The PM’s instinct gets checked against what’s actually out there—what competitors ship, what regulators require, what people complain about in public.
3. The PM writes the requirements doc from both, and it’s a real document, not a paragraph. Ours run to several thousand words and end with a build sequence.
4. Build it. This is the fast part now. This is no longer where the risk lives.
5. Then the loop opens—and this is the actual subject of this post.

The loop

Once the feature exists on screen, we run the designer and the customer panel against the same live screen, separately, and then reconcile them. That split is deliberate, and it’s the single most useful thing we’ve learned:

The designer judges craft. The panel judges legibility in use. They reliably converge on the real problem—and where they disagree, the panel is usually right.

The designer will tell you the two amber tones are 4% apart in value and give you the corrected hex. The panel will tell you they never once noticed the amber tones, but they cannot tell an approved claim from a stalled one and it’s costing them ten seconds a row. Both are true. Only one of them is why the feature is failing.

And because the panel runs on every surface we ship, it has started producing a pattern library of its own—recurring complaints that show up again and again regardless of what we’re building. These are now things we pre-empt rather than rediscover:

What the panel finds, over and over

• Everything’s brown. Move every state onto one tasteful palette and you destroy the contrast gap that made the important rows pop. The screen gets prettier and the scan gets slower.
• The color reads backwards. A high fraud score rendered in red means “danger, avoid”—but to the fraud investigator, a high score is the good one, the one she wants to work. A magnitude is not a verdict; it needs its own ramp.
• Same color, opposite meanings, same row. A status badge and a deadline both rendered in gold. One means good, one means hurry.
• Empty states read as broken. A card full of ”—” and “not recorded” doesn’t read as honest; it reads as failed to load. Low contrast is the visual language of “disabled.”

Not one of those is a bug. Every one of them would have shipped.

Why not just ask Claude to review it?

This is the fair objection, and it’s worth answering directly, because the personas are not magic and the reason they work isn’t mystical.

Ask a general-purpose assistant to “review this design” and you get the average of all design advice: it is competent, it is agreeable, and it is the same answer every time. What you want from a review is not competence—it’s disagreement. Five reviewers who all say the same thing are one reviewer.

A persona is a constraint, and a constraint narrows the distribution of things the model will say. Give one agent an eight-hour-a-day power user and another a supervisor who glances at the screen twice a day, and they will come back with different complaints—not because either is “simulating a human,” but because you’ve pointed two instances of a very capable reader at genuinely different questions. Diversity of thought is manufactured, on purpose, by narrowing.

The second reason is tools, and it’s the one we underrated for months. Our designer persona doesn’t just describe an icon—she has an image generator wired into her hands. She calls it, gets back a shape, normalizes it into the codebase’s house style, and previews it at the size it’ll actually render. A persona with a specialized tool isn’t giving you an opinion about the work; it’s doing the work, in its own voice. That’s the difference between a consultant and a colleague.

The other loop: let it use the browser

Traditional automated testing checks that the engine runs. It does not check that the car is drivable. For most of software history that gap was filled by a human clicking around, and it is precisely the part everyone skips when they’re in a hurry.

We closed it by giving the agent the browser. Through a Chrome extension, the agent operates a real Chrome session—the same one you’d use—and it can click, type, scroll, take screenshots, and, crucially, read the browser’s console and network traffic while it does. That last part is what makes it more than a screenshot tool. It sees the errors your users get and never report.

So before a feature ships, an agent is told: open the claims queue, filter to last week, open the top claim, add a note, approve it, and confirm it disappears from the queue. It does exactly that, on the real screen, and it comes back with what broke. In our own work this routinely catches a class of bug that no unit test would have: the button that’s technically clickable but sits under a header, the filter that returns the right data and renders nothing, the form that silently fails on a value with a comma in it.

One hard-won practical note: point a separate, cheap agent at this. Iterative click-and-debug loops burn enormous amounts of context for very little insight per step, and you do not want your main thread—the one holding the design rationale—clogged with three hundred screenshots. Delegate the grind; keep the judgment.

Loop engineering

Underneath both loops is one idea, and if you take nothing else from this post, take this:

Stop giving the agent a task. Give it a goal and a condition under which it’s allowed to stop.

A task is “fix the color contrast on the queue page.” An agent does it, reports success, and hands back something 80% right. A goal with an exit condition is: “run the designer and the panel against this page; apply their findings; run them again; keep going until a full round surfaces nothing new.” Now the agent doesn’t stop when it’s tired. It stops when the room goes quiet.

The same shape works for the browser: “drive this flow end to end until it completes with zero console errors and the record actually changes.” Not try to drive it. Until.

The subtlety worth knowing: a naive counter (“run three rounds”) misses the tail, and an open-ended loop can convince itself it’s found something to justify continuing. The rule we settled on is run until two consecutive rounds surface nothing new—and, importantly, deduplicate against everything ever raised, not just against what got fixed. Otherwise a finding the team already rejected comes back every round and the loop never converges. That’s a real bug we hit; it costs money.

What this is not

These are not your users. A persona will never surprise you with the thing you couldn’t have imagined, because everything it says is downstream of what a model already knows about people like that. It cannot tell you that your customers are secretly running the whole workflow in a spreadsheet. Only a customer can tell you that.

What it does is make the obvious problems too cheap to leave in. The panel finds, for a few cents and ninety seconds, the class of problem that would otherwise have consumed the first ten minutes of a real customer call—and those ten minutes are the most expensive ten minutes you own. Spend the human attention on the things a simulation genuinely cannot reach. Let the room full of ghosts handle the rest.

If you want to try it

Don’t build the whole cast. Build one, tomorrow:

1. Write a single page describing one real user—the one whose complaints you can already hear in your head. Give them a name, a job, a specific frustration, and one thing they care about more than anything else.
2. Tell them the output format you want. Ranked. Specific. And “say so plainly when it’s already fine”—this one line prevents most of the nonsense.
3. Forbid feature requests. They will try. That’s how you know it’s working.
4. Run them against your next change, before anyone else sees it.

Then read what comes back and ask yourself the only question that matters: would we have shipped that?

---

Illustrations for this post were generated by an image model and cleaned up by hand—which is, in its own small way, the whole argument.