You know the lifecycle. Discovery, alpha, beta, live, or a local version with the same shape. It was a real advance: it put research at the front, and made shipping the wrong thing something a team could be marked down for. A phase passes when its deliverable is present, and for a long time that was a safe test.
It was safe because the deliverable proved the work. You could not hand over a discovery report without running a discovery, so checking the report was as good as checking the work. That is the part that has changed. A model will now write the report, personas, needs and all, off a brief, in the time it takes to read this page. The deliverable has come loose from the work that used to be the only way to get it.
This cuts two ways, and both are real. Pointed at the right problem, the same model does in an afternoon the months of digging a team could never finish in time. Pointed at the wrong one, it hands you a confident account of people nobody met, and the phase passes with no one the wiser. Knowing which is which is the new skill.
Two jobs, one of them new to the machine
A discovery does two different jobs, and we rarely hold them apart. One is to use what is already known about a problem: the research someone ran two years ago, the thing the call‑centre data has said for a decade, the pattern every team in the sector found and wrote up long ago. The other is to find what nobody knows yet, the thing about these users, in this service, that is in no document because no one has met them doing it.
Decision science has a name for the pair, the explore‑exploit trade‑off. Exploiting is making the most of what you already hold. Exploring is paying to find something new. Every discovery is a mix of the two, and the mix is set by one thing: how much of this problem is already known.
The machine is extraordinary at one of these jobs and incapable of the other.
The machine can compress the discovery you already knew the answer to. It cannot run the one you didn't.
What the machine genuinely gives you
Take the upside first, because it is real and often skipped.
A great deal of discovery ran long not because the knowing was hard, but because the finding was. The answer existed. It sat in an old report, a forum thread, the discovery another department ran and never shared. It could not be reached in time, or read in the volume it came in, or held in one head. Researchers have a name for that cost too, information foraging: the work of sniffing out where an answer might be, and digesting it once you arrive. For a known problem, foraging was most of the expense and most of the wait.
That is the cost the machine collapses. Point it at a known problem and it will take in the existing material, the prior research, the documented patterns, the things the sector learned the hard way, and give you a fair account of them in an afternoon. This is retrieval doing what it is good at: gathering and compressing what is already in the record. It is the exploiting half of the work, done faster than a team could manage by hand.
So when the problem is known, discoveries can be shorter, alpha can start sooner, and you may run more rounds of alpha and beta as a result. This is a real gain, and the discipline should welcome it. Long discovery always drew the same complaint, that it is slow and tells the team things it half‑knew already, and for a known problem the complaint was often fair. If the machine lifts the months of foraging out of the known, the honest move is to take the time back and spend it where it counts.
Where the gift turns into a fake
Point the same tool at a genuinely new problem and it hands you an artefact that looks exactly as finished.
It cannot do otherwise. Ask a model about a problem nobody has documented and it does not return nothing. It returns the typical shape: the most likely discovery for a brief like yours, drawn from every discovery already written down. That is next‑token prediction over its training distribution, doing its job. A model is strong inside the distribution of what it has seen, and unreliable outside it. A genuinely new problem is, by definition, outside it. The answer was never in the record to retrieve, so the model builds a plausible one from the records nearby. The personas have names. The needs are phrased the way real needs are phrased. None of it was met.
This is the failure, and it is exact: exploiting dressed as exploring. You have taken a tool that compresses the known and aimed it at the unknown, and because retrieval and invention arrive as the same fluent object, the slide cannot tell you which you are holding. A clumsy fake announces itself. A fluent one does not. This is the new thing to watch for, because the old test, asking whether the deliverable is there, now passes either way.
The question that sorts them
The old test was simple: did we run a discovery. It no longer works, because the file says yes either way. The test now is sharper, and you run it by hand: how much of this problem was already known, and how much is new?
For the known parts, take the compression and be glad of it. One discipline remains, and it is small: confirm, rather than assume, that the known answer still holds for these users. The machine has handed you the sector's commonplace. A light check against a few real people tells you whether your service is the ordinary case or the exception. That check is short, and it is not optional, because the exception is exactly the user a public service cannot afford to miss.
For the new parts, nothing the machine produces is the work. Here the only thing that finds the answer is meeting real people and being changed by what they do. A real meeting in a new problem almost always disturbs the plan, because the typical shape was the thing it was there to break. If you met someone and nothing moved, look again. If you met no one, you do not have a discovery of the new. You have a retrieval of the near.
The blunt form of the question, to ask on every phase: how much of this did we already know, who did we meet for the rest, and what did meeting them change?
Welcome the short one, guard the other
A phase is meant to be a meeting: the machine's work on one side, a real person on the other. The two loops, one each side of the phase line.
The machine can now turn both on its own, indoors, and pass the phase with no real person in the room. When the problem is known, that is mostly fine: the answer was already true, met or not. When it is new, what passes is a confident account of a person nobody met.
Telling those two apart is the craft now, and it is firmer ground than the old argument. User‑centred design spent years defending the length of its process, and gave way every time the process was slow and the finding was thin. The machine lets us stop defending the length, and defend what actually matters: someone has to go and find what is not yet known, by meeting the person the service is for.
Welcome the shorter discovery. Guard the one that cannot be shortened.
The map will keep marking phases complete. Your job is to know which of them met the new, and which only retrieved the known and called it the same.