Part two of UXR for AI-native teams, a six-post series.
Last week I made the claim this series defends: at the speed of AI-native teams, the only research that matters is research built into how the team operates. Fine, but built into what, exactly? Today: a tour of one bet through an AI-native team's loop, an audit you can run yourself on any team that will let you near their repository, and the map the rest of this series hangs off, the five moments where knowledge about users can enter these teams' decisions. By the end you'll score your own research portfolio against it, and the score will probably sting.
One bet, kickoff to ship #
Watch a single bet move through the loop.
Kickoff is short and late. The old model front-loaded planning because building was expensive and mistakes were costly to reverse; when that cost collapsed, heavy pre-planning stopped paying. Anthropic's Claude Code team describes it as just-in-time planning: a six-month roadmap that was stale by month three, planning rituals that migrated out of design documents and into discussions on pull requests and working prototypes, because the cheapest way to discuss an idea is now to build it and argue about the build. Where a kickoff survives at all, it's an hour that covers the problem statement, the constraints, and who watches which risk. Then somebody opens the spec.
The spec gets written, and this is the moment to slow down for. Sometimes it's drafted in the morning and reviewed like code. Often, on real teams with real deadlines, it gets finished at night, by one person, with a chat window open in the next tab. Be precise about what's in the room right then: the author's memory of the users, which is whatever it is. The codebase. An assistant that will confidently supply anything the author asks for, including answers about what users want. And the author is tired. Whatever that document contains when it freezes is what gets built, because on these teams the spec is a production input; GitHub built tooling around exactly this. The caveat from an old readout, the segment difference somebody once presented, the finding that this exact idea tested badly two years ago: none of it is in the room unless it happens to live in a human head at 11pm.
Generation runs in parallel: agents pick up the spec, read the team's standing instructions, explore the codebase, and build several candidates, because trying five costs roughly what trying one costs. Tests get written first and satisfied along the way, since the process document demands it and the agents, unlike the rest of us, actually do what the process document says. The gates do the checking: agent review on every change, a human owning the final merge with their name on it, eval suites scoring anything model-facing. Then it ships behind a flag, telemetry comes back, somebody reads it, and by Monday the team is two bets further on. Whatever this bet learned about users mostly goes nowhere, which is a problem we'll spend a whole post on.
The constitution #
Underneath all of that sits a layer most people outside these teams have never heard of, and it's my favorite discovery from the conversations behind this series.
AI-native teams keep standing instruction files in the repository itself, conventionally named things like AGENTS.md as of this writing, and every agent reads them on every task: the project's structure, its conventions, its commands, its boundaries, its definition of done. OpenAI's guidance to engineering teams is blunt: iterate on these files the way you iterate on code, because they're what unlocks the agentic loop, and treat the test suite as the source of truth agents build against. The mature teams add memory files on top, records of past decisions and the reasons behind them, so an agent working in March doesn't casually violate a choice made in September by people who have since changed teams.
Add it up and you get the fact I most want you to carry out of this post. The team's beliefs about how software should be built are now encoded, versioned, and machine-read at the moment of generation. There is a constitution in the repo, and the agents obey it. (I keep calling it a constitution. The teams call it a markdown file. Both are true, and mine is more honest about the power.) The team's beliefs about its users, meanwhile, are written down nowhere.
The twenty-minute audit #
You can verify everything above yourself, on any team that will let you near their repository, and I'd genuinely encourage it. The move: at the moment of generation, list what an agent can actually see. It's roughly five things:
- the standing instruction files
- the spec for this bet
- whatever code and documentation it retrieved while exploring
- the test suite it must satisfy
- and, on mature teams, the memory files.
Now walk that stack top to bottom and count the mentions of users.
The instruction files have detailed sections on naming conventions, error handling, and how to structure a migration, and nothing on who the users are, what they're trying to do, or what breaks their trust. The spec mentions users exactly as well as its author's memory did at 11pm. The retrieved context is code. The tests check that the code is correct, not whether it serves the people it's for. A build can pass every one and still be confidently wrong about them, and there's no error message for that. The memory files record architecture decisions and nothing about who the software is for. (The first time I ran this audit it took me about twenty minutes, and I spent a couple of them just staring at the tests section.)
The agents obey a constitution with chapters on lint and no chapter on people, and nobody decided this. There was no meeting where an organization voted to exclude user knowledge from its production loop. Engineering encoded its own judgment, design encoded its judgment into the design system, and nobody was in the room encoding yours.
The five doors #
So where can knowledge about users actually enter? In the loop above there are exactly five moments. I've been looking for a sixth since the conversations started, and I keep not finding one. Steal this map; the rest of the series walks through it.
Door 1: Kickoff framing. The hour where the problem gets stated and the bet gets shaped. What enters today: whoever's in the room, remembering whatever they remember, at whatever confidence the loudest person projects. How it fails: the wrong problem, framed convincingly by the loudest dashboard, then built cleanly by Friday, because good execution can no longer save a team from a badly framed problem.
Door 2: Spec authorship. The 11pm moment. What enters today: the author's recall, plus whatever the chat window offered, plus nothing else, structurally. How it fails: unstated assumptions ship as behaviors, and the careful qualifier from an old study gets lost somewhere between paste three and paste five, because the caveat is the first thing to get cut.
Door 3: Generation context. What the agents can see while they build. What enters today, regarding users: nothing, structurally, on every task, at scale, which makes this the highest-stakes door on the map and the one no research function on earth currently owns. How it fails: invisibly, because the build still passes.
Door 4: The pre-ship gate. The reviews, tests, and evals that decide what merges and what opens. What enters today: correctness checks, style checks, and safety checks, all of them real and none about the people the software is for. How it fails: a build can clear every gate the team has and still be wrong about people, because the team's definition of done doesn't include being right about people.
Door 5: Post-ship learning. The telemetry read after the flag opens, and everything the bet learned along the way. What enters today: numbers, interpreted by whoever looks, remembered by no system. How it fails twice: the numbers arrive without the reasons in the moment, and then the learning disappears when the bet closes, so the organization pays to learn the same thing again next quarter, often one floor away from where it was already known.
Notice the gradient, because it organizes everything that follows. Doors 1 and 2 are human-mediated: you could start arming them Monday, with no budget and nobody's permission. Doors 3 and 4 are machine-mediated: arming them is an infrastructure project with a negotiation attached. Door 5 is both, and it's where the compounding happens: the difference between an organization that gets smarter over time and one that only gets faster at doing the same things. That gradient is also the sequence this series follows.
Score your portfolio #
Now the part that stings. Take your current research portfolio, everything your function shipped or ran last quarter, and tag each item with the doors it arms. One rule keeps you honest:
An activity arms a door only if its output ispresent at that moment, in the room, in the document, in the context, in the gate. "Could inform, if someone remembers it" arms nothing.
Run it honestly and most functions discover that the bulk of their effort arms zero doors: reports that arrived after Door 5 had already closed, repositories no door can reach, readouts to rooms where no door exists. A little arms Door 1, when a study happened to land before a kickoff. Almost nothing touches Doors 2 through 4, which is exactly where the unit now decides. The work is good. The targets moved, and the aim didn't follow.
Next week #
Every door has the same requirement hiding inside it: a unit of knowledge that a tired human at 11pm and an agent mid-generation can both actually use. The industry's default unit, the report, the deck, the repository full of documents, has been failing that job for a decade, through every tool migration we threw at it. Next week I take apart why that default unit fails and offer the replacement: a unit of knowledge that still works inside Door 2's paste buffer and Door 3's context window.
And if you can find a sixth door, my email is open, and I mean that. I'd rather redraw the map in week three than defend a wrong one for four more posts.
See you next week.
🎯 This is part two of UXR for AI-native teams, a six-post series. Subscribe, and the rest arrives as it publishes, no algorithm required.
📖 If the fast-research layer underneath this series is the part you need first, that's my book: AI-Powered UX Research, the operating manual for running research at the speed your team actually needs. This series is what I've been thinking since.