
A team I follow built a mock-testing platform very quickly, and then made a choice that looked like a step backwards: every piece of educational content was validated by hand, by experts. Nothing forced the team to. The build was fast, and a faster route to launch was obvious. The team chose what John Cutler calls positive friction.
That slow step bought two things. The first was time to tweak and iterate. Content is very different from code: you cannot run a test suite against whether a question is fair, clear and set at the right level, so its quality comes from experts reading it and revising it, pass after pass. Experts caught things the AI that produced the content had missed. The second is easy to miss. Because people worked through the content by hand, they used the product the way a learner would, so the team felt the UX problems directly. That forced continuous iteration over many small annoyances, each minor, which added up to a much better experience. AI-driven workflows tend to remove that kind of friction.
Where the judgement lived
Before AI, every handoff in a product workflow made someone process, discuss and reshape information before passing it on: customer call, synthesis, decision, build, ship, measure. It was tedious. Cutler writes that each of those moments was a chance to apply a forcing function: to pay attention, discern, say “no” or “what if.” His summary: The friction was judgement and discretion’s friend.
Automate the whole chain and the arithmetic gets strange. Five customer calls, around 8,000 words, become 80 opportunities, 80 tickets and 400 tasks. A few steps later, all you have is pointers to what the customers said. The code at the end is real, and everyone trusts that step for exactly that reason. Cutler asks the question that follows: how did the code get that way?
Exposure
Cutler’s frame is judgement: the handoff is where someone says no. The platform adds exposure: friction is also how a team comes to know what it has built, and a report cannot hand that over. Automate the step and you save the hours, but you also lose the exposure. The cost shows up later as a product nobody on the team has really designed or used.
Humans as the bottleneck
The obvious reply is that people are what is left slowing everything down. Claire Vo put it to Zach Lloyd on her How I AI podcast: at Warp, kickoff to pull request takes 35 minutes, and pull request to first human review takes three and a half hours, across more than 2,000 pull requests in a month. Lloyd himself calls humans a little bit of the bottleneck, and also the creative force. Every pull request at Warp still gets a human review, which he calls a team choice, an organizational choice, because we don’t have yet complete trust. Vo then describes the pattern she sees in mature teams: risk-score every pull request, stamp the low-risk ones, and keep human review for the rest.
Warp’s factory keeps a person on every change, deliberately. That is the right instinct, applied at one end of the chain. Risk scoring works for code because code has tests, diffs and a blast radius you can measure. I know of nothing equivalent upstream: no risk score for a synthesis that turned five calls into 80 opportunities. Friction at the end of the chain gets designed. Friction at the start simply disappears.
The strongest case against keeping human steps is volume. A person approving more than 2,000 changes a month will skim, and a skimmed approval is worse than none because it looks like assurance. I have written about a reviewer who skims an agent’s pull request and approves it without understanding it, and about a review backlog that grew with the code. That argument is right about the problem and wrong about the remedy. Skimming is a sign the step was badly placed or badly sized, which is a reason to redesign it, and the redesign still has to leave someone deciding something. A step where nobody decides anything is ceremony, not friction.
Sorting the handoffs
Before you wire an agent into a handoff, ask what judgement happened there and who made it. Three answers cover most cases:
- Automate the drudgery: copying, reformatting, restating the same notes in another tool. Nobody decided anything there.
- Keep the steps where someone decides: what is worth building, what is good enough to ship. The hand validation of that content was one of these.
- Relocate what cannot stay manual at volume: move the friction somewhere cheap and visible, as risk-scored review does for code.
List every handoff in your chain, from the first customer conversation to the measured result, and mark each one automate, keep or relocate. Set aside an hour for it.
Ask of every handoff you remove: who was saying no here, and who will say it now?
Leave a Reply