Take the boring version of the future, the one with no singularity in it, and just assume the thing that has been happening keeps happening. The time between we should try this and it is in front of users keeps compressing, quarter after quarter, and nobody planned this so nobody is going to unplan it either; the cost of producing a working candidate fell and nothing pushed back.

Engineering Is Not Going to Slow Down. Your Research Model Is Priced On the Assumption That It Will.

Take the boring version of the future, the one with no singularity

in it, and just assume the thing that has been happening keeps happening. The time between we should try this and it is in front of users keeps compressing, quarter after quarter, and nobody planned this so nobody is going to unplan it either; the cost of producing a working candidate fell and nothing pushed back.

Now ask what that does to research.

Most people, given this hypothetical, hear a scheduling problem. They picture the function they already have, running the studies it already runs, just sweating more, and that is a comforting thing to hear because it comes with a fix you can buy: get faster, buy the platform, run unmoderated, hire an ops person, do the two-week thing in four days and call it transformation.

Your Side Has a Floor and Theirs Does Not

A study you can run in three days cannot be run in zero days, because there is recruitment, and there are humans with calendars who have to actually show up, and about fifteen percent of them will not. Compression on the research side is real and it stops somewhere, probably around a day for anything that involves a conversation with a person, faster if you are reading behavior that already exists.

The thing on the other side of the table has no equivalent floor, because a growing share of its work is not being done by people, and that asymmetry is the entire mechanism: two systems accelerating, one bounded and one not, which is less a forecast than a calendar.

So the honest version of the hypothetical is that the gap widens permanently rather than closing, and past some point it stops behaving like a gap and starts behaving like a wall.

Two Thresholds You Have Already Met

The first one everybody has lived through. The build outruns the study, a team produces a credible version of the thing faster than you can produce evidence about whether the thing should exist, and you arrive holding an answer to a question that shipping already settled. That has an answer and it is not new: you match the size of the research to the size of the decision, which is what the book calls routing, micro, sprint, or deep, a two-day check for a two-day question and the full study for the bets that deserve one. That is the central argument of AI-Powered UX Research and I stand by every page of it. It was written for this threshold and at this threshold it holds.

The second is where the build outruns the reading. Past a certain tempo the bottleneck is no longer how fast you can produce knowledge but how fast anyone can absorb it, so you deliver on a Tuesday into a decision that happened the previous Thursday, while three others your work should have informed got made this week in a channel you are not in, by people who did not know an answer existed. The readout quietly becomes a ceremony, and not because anybody is lazy or disrespects research; a scheduled forty-five minutes cannot serve a loop that turns over faster than the scheduling does. The fix is that knowledge has to be retrievable at the moment of the question rather than delivered on a calendar, which means units small enough to match a question, with the evidence attached, the confidence stated, and a date on it. Findings as claims rather than documents, since a document has to have been read by someone, while a claim can find a person who did not know to look for it.

Both of those I had already worked out before this hypothetical, and neither is what kept me writing. The third one is.

The Third Threshold Is Where It Stops Being Familiar

Keep compressing and a shrinking share of decisions passes through a moment where a person weighs options. The spec becomes the production contract, and what is written there gets built, increasingly by something that reads the spec and does not pause to wonder where the claim about users in paragraph three came from. At that point "influencing the team" stops being a coherent goal, because a chunk of the deciding is not happening in any room, and what you know about users is either in the spec when the spec gets read or it does not exist for that decision.

I want to stay here for a while, because this is the part I have no settled answer for, and the honest thing is to lay out what actually changes rather than reach for the prescriptions I already had lying around.

The first change is that the claim loses its last reader. For as long as I have done this work there has been a person between a finding and a build, and that person was doing enormous amounts of invisible labor: discounting a small sample without being told to, remembering that the flow changed in March, noticing that a quote came from the one participant who hated everything, asking who ran this and when. None of that was in the document. It lived in the reader, and we all quietly relied on it, which is why sloppy findings survived for years without doing catastrophic damage. Take the reader out and the document has to carry its own defenses, and most research writing has never had to.

The second is that machines read literally, which sounds obvious and is not. A human reading that users seemed frustrated in five of eight sessions applies an automatic discount, hears the hedge, knows that eight is not a lot. A system reading the same sentence treats it as an input, and so does the next system that reads what the first one wrote. Hedging that lives in your tone of voice, in the way you said it in the meeting, in the eyebrow you raised, does not survive the trip. If the confidence is not literally in the text as text, it is gone, and what propagates is a flat assertion with your name on it.

The third is that findings now decay in silence. When a person was the retrieval system, decay was self-correcting, because the person knew the product had changed and would say so before quoting a finding from a screen that no longer exists. Retrieval does not know that. It will return an accurate description of a flow you replaced two quarters ago with exactly the same confidence it returns something from last week, and it will do it at the moment somebody is writing a spec, which is the worst possible moment to be quietly wrong.

The fourth is the one I find hardest, which is that being wrong loses its confession moment. In the old loop a bad finding eventually surfaced, because somebody built on it, the thing failed, and the conversation traced back to you. That was unpleasant and it was also a correction mechanism, and it depended entirely on there being a conversation. When the claim gets read and built automatically, nothing traces back, and a wrong claim about users can sit in circulation for a year, get cited into three specs, get summarized into somebody else's context, and never once produce the meeting where a person says that was wrong.

Put those four together and the shape of the problem is not that research gets less influential. It is that research loses its error correction while keeping all of its authority, which is a genuinely dangerous combination and not one our profession has any practice with.

What That Actually Requires

Here is where I have to be careful, because I have a set of positions I have been arguing for years and it would be easy to bolt them onto this and call it a conclusion. Some of them do survive: coverage and freshness and confidence still matter, they are three of the four properties of the Frame, and the case for owning the maintained picture of your users is not weaker in this world. But those were true before the hypothetical and would be true without it, so they are not what this piece earns.

What this piece earns is smaller and stranger, and it is mostly about the claim rather than the study.

You start writing for two readers, and the second one is not a person. Every claim needs its sample, its date, its confidence, and its scope written into the sentence rather than implied by the room it was presented in, because the room is not coming. This is a craft change and a demotion of a skill many of us are proud of, since the ability to land a finding in a meeting is worth much less when the meeting is not where the finding gets used.

You put the evidence bar at the spec, not at the readout. If specs are production contracts then that is where the gate belongs, and a claim about users that enters a spec without a source is a defect that deserves the same treatment as any other defect that gets built automatically. This is unglamorous and slightly bureaucratic and I do not have a more elegant version of it.

And you audit what is in circulation rather than what you delivered. This is the part I keep circling, because our entire measurement tradition is about output: studies run, readouts given, decisions influenced. None of that tells you what claims about users are currently being used, by whom, in what artifacts, at what age. Sampling the specs and the tickets and the prompts to see which of your findings are actually load-bearing right now, and which of them are eighteen months old and describing a product that no longer exists, is not a thing I have seen any research function do systematically. It is also the only version of quality control that works when nobody is going to tell you that you were wrong.

Which leads somewhere I did not expect when I started writing this. Retraction becomes part of the job. Not correction in the sense of a follow-up study, but actively going back into circulation and pulling a claim you no longer stand behind, the way a newsroom issues one, because if you do not do it nobody else will and the claim will keep working long after it stopped being true.

Where I Think the Premise Is Wrong

I do not fully believe the premise, and the piece is worse if I pretend otherwise.

Engineering speed is not the variable that binds in most companies; decision speed is, and decision speed runs into things that do not compress on the same curve: legal review, regulated surfaces where somebody has to sign their name, and the political metabolism of the organization. Plenty of teams can already produce candidates faster than their own org can agree to look at them, the bottleneck there moved past engineering years ago, and the acceleration story in those places is mostly noise with a slide deck attached.

There is also a decent case that the curve hits an evaluation wall instead of continuing smoothly, because when producing options gets close to free, the scarce thing becomes knowing which option is worth having, which is a world where the ability to evaluate against real users is worth more rather than less.

What keeps me thinking and writing about this is velocity. Not any single speed, since I just argued engineering speed is often not the one that binds, but the widening ratio between how fast things get made and how fast anyone can know whether they should exist. That ratio moves in every future I can construct, including the ones where my premise is wrong, and all of them end in the same place: a claim about users, written down, read by something that will not ask you a follow-up question.

No future I can construct has a version where the request queue survives. I keep checking for one anyway, the way you pat your pocket for keys you already moved, because the queue is how I learned this job and I am not above sentiment. But the queue was priced for a world that could wait three weeks for an answer, and that world is gone. The loop stopped waiting. Most of us have not.

🎯 If the loop keeps compressing, the pre-answered question wins. Subscribing takes four seconds and answers it in advance. Subscribe to The Voice of User.

📖 The machinery underneath this, the Frame and the routing and the rest of it, is the book: AI-Powered UX Research. This piece is what happens when you push it past the threshold it was written for.