Ten Percent, or Ten Times

Last Thursday I asked Dan Olsen a question I already knew the answer to.

If I had told you a year ago that I vibe coded something, what would you have thought I built?

A prototype, he said. HTML, CSS, and JavaScript. Something clickable you could put in front of a customer to find out whether the idea survived contact with them.

Then the harder version. If someone tells you today that they use Claude Code for their work, do you know what they are doing?

That answer took longer. Production code. Automated workflows. Agents. A lot more pull requests. For the teams that have gone furthest, sophisticated CI/CD.

Same sentence, twelve months apart. A year ago it named one artifact. Today it stretches from a landing page to a deployment pipeline, and the person saying it might be a designer who has never opened a terminal or a staff engineer who lives in one.

The phrase stopped carrying information. So did the tool names underneath it, which is the part that matters, because tool choice is no longer what separates one team from another.

What a year of prototyping bought

Dan has been redrawing one slide for twenty years. On it is what he calls the design gap: you have your words, a PRD or a spec or a user story, and what you do not have is an experience. "There are words," he said, "and we need to bridge the gap from words to code, which is the user experience."

The old bridge was a clickable Figma prototype. Test it, iterate until customers like it, hand engineering something validated. Everyone agreed with that process. Most teams could not run it, and Dan is blunt about why: "they don't have the time, they don't have the bandwidth, they don't have a design resource."

So they skipped the test and built anyway. Not from carelessness. The queue for the one person who could make the prototype was longer than the deadline.

AI prototyping removed the queue. A real win, it arrived fast, and it is now finished. A product manager can now go from words to something interactive without asking anyone. Designers did not lose that work so much as inherit a harder part of it, since a generated screen still has to obey a design system before it ships.

Every one of those wins landed on an individual. One PM got faster. One designer got leverage. Multiply that across a team and you do not get a faster team. You get eight people moving quickly in eight directions, each with their own folder of context, each getting a different answer to the same question.

The interesting year starts there.

The moment it stops being personal

Dan described something he has watched happen repeatedly over the last few months, as enterprise accounts landed and whole teams got these tools at once.

Someone builds a skill for writing PRDs. Someone else mentions they built one too. Then the obvious question arrives: should we not just have one skill for the whole team?

A personal setup has become an operating problem. And the question that follows decides whether the shared version survives more than a month, which is the one I put to him in the room: who keeps it up to date?

What most teams have once everyone gets an agent. It works, and it is different on every laptop.

Six ways teams are building the harness

We have now talked with more than 300 product companies putting these tools to work. Nobody calls it the same thing, but the shapes repeat enough to name. I call the whole apparatus a harness: everything you build around the model so that the model does useful work on your product rather than generic work on a prompt.

Individual prompting. Everyone has a chat tool and people trade the prompts that worked. A reasonable place to start. No shared standard, so the quality of any given output depends on who typed it that morning.

Shared assistants. A Project, a Gem, a custom GPT holding one starting context for the team. This is the first thing most teams build, and it holds right up until nobody can say who owns it, which is usually the week it goes stale.

Agents across the team. Everyone gets Claude Code or Codex. Output climbs and so does divergence, because every laptop holds a different set of folders and the same question returns a different answer depending on who asked. This is where most teams are today, and where most of them stall.

A business harness. One shared place holding product, brand, and engineering context, with starter packs so people begin from the same state instead of from their own history. It works, and it is kept alive by hand, which means it decays the moment whoever maintains it gets busy.

A multiplier harness. The team's own CLIs, plugins, and checks, plus enough DevOps that a product manager can push a branch and get back a working URL with realistic data. The distinguishing feature is that the team stopped waiting for vendors to ship the thing they needed and built it.

An evolving harness. The rare one. New information gets processed on arrival, and the harness improves its own rules against what happened last time rather than waiting for someone to rewrite them.

These are not maturity levels and I would not use them to grade anyone. Teams sit in several at once, one per workflow. The useful question is narrower: which workflow are you still running by hand, and what would it take to stop.

One design decision comes up in every one of these conversations, so it is worth settling early. Someone always asks how this works when product managers never touch code. The answer is that they should not have to. Give the agent the product manager is using read access to the repository instead. Feasibility questions then get answered without interrupting an engineer: can this work at all, what happens when this data arrives, where does this break. Reading a codebase is not the same as writing to it, and the two deserve different conversations about access.

What it costs, which is the part that gets skipped

Every harness conversation I have been in skips the bill. Here is mine.

Giving agents more reach moves capability and risk in the same direction. If everyone can connect to everything, someone can also write a script that deletes production data. Withholding the tools costs more than it saves, so the guardrails become engineering work, and somebody has to do that work and keep doing it.

A small example from our own stack. We drive the Google Workspace API from the command line. As shipped, an agent holding those credentials can send email. We did not want that, and the permission we wanted did not exist, so we forked it and put our own permission layer on top. Our agents draft. They do not send. No strategy in that, only an afternoon of unglamorous work, which is mostly what a harness is made of.

The same picture once someone owns it. The two rows worth arguing about are the last ones: what runs on a schedule, and where the human boundary sits.

The bill gets steeper at the top of the range. A harness that keeps itself current needs DevOps and full-stack skill, and then it needs evaluation work to tell whether the changes it makes to itself are improvements or overfitting to last week. Call that AI engineering, and price the talent accordingly, because the market has.

Which is why the honest advice is not to build all six. Build the one that covers the workflow you run most often, give it an owner and a maintenance budget, and treat it the way you treat your product. It will rot faster than your product does.

Where a harness alone stops paying

Teams who do all of this well tend to arrive at the same wall, and it is worth knowing it is coming.

They set up a weekly job that pulls every call transcript into local storage. It works. Now there is a folder holding tens of thousands of markdown files, fully searchable.

Then somebody asks a normal product question. In the area we are working on this quarter, what are customers telling us that we have not acted on?

The answer may well be in three of those ten thousand files. Finding it by search means already knowing the words those three customers used, which are not the words you would think to type. More context does not fix this. Nothing has been processed, so nothing can be found by meaning.

Notice what has gone missing. Not the data. The reason. Somewhere between the call where a customer said the thing and the branch where an engineer built something, the why came unattached from the what, and no folder of transcripts puts it back.

Closing that gap is what we build, so read the next paragraph as interested rather than neutral. We process signals as they arrive, attach them to the ideas they support, and hold the line intact from a customer sentence to the decision to the pull request that shipped. We call it a loop rather than a pipeline because what you learn after shipping returns to the same place the evidence came from.

The most useful proof I can offer is an admission. During the session I opened our own workspace and went to the idea I am least comfortable about: new users land in Zentrik and see too much at once. Several people on that call had told me exactly that. It sits in our system with sixteen signals from real calls attached, ranked against everything else we could do. Dan then did what a good product person does with a live idea, which was to refuse the vague success metric and make me name the one workflow a new user has to finish on their first visit.

Ten percent, or ten times

The arithmetic below should decide where you spend the next quarter.

If what you are buying is saved time, your ceiling is one hundred percent. A task that took an hour goes to thirty minutes, then to five, then to nothing. When it reaches nothing, the work is gone, and so is the reason to have had someone doing it. The grey curve at the top of this page. Real, and it runs out.

Capacity has no such ceiling, because it is not the same quantity. Saving time makes the work you already have cheaper. Multiplying capacity changes what the team is willing to attempt, and that number has nowhere to stop.

The teams furthest along this are not running ten percent faster. They are shipping work they could not have staffed. A single person now carries what used to need a small team around them, not because anyone types faster, but because the context that used to be rebuilt before every decision is already there. I am describing what I see in our own work and in the companies we talk with, not a benchmark anyone has audited. The gap is not subtle either. You can tell within one conversation which side of it a team sits on.

Our own number, offered as illustration rather than proof: between the first of May and the twelfth of July, seventy-two days, our two-person development team shipped 113 tagged releases. None of that came from typing faster.

So the question to put to your own team is not how much time the tools save. Ask whether any workflow has crossed over from cheaper to larger, and if none has, which one is closest.

One move for this week. Pick a decision your team makes over and over. Name who owns it. Attach one real customer source to it. Smaller than a harness, and the same instinct: refusing to let the reason for the work get separated from the work.

If you are building one of these

I have spent the past year building harnesses and comparing notes with teams doing the same, and the failure modes repeat far more reliably than the wins do. If that is the work in front of you, three things you can take:

• The six patterns above, as a reference to hold your own team against. Find the row you are on, then read one column: the next move.
• A working session, if you want help with the one move rather than the whole climb. Twenty five minutes, one customer source, one decision, and you leave with it running. Ask for one here.
• What this looks like when a system runs it instead of a person, which is what we mean by a loop.

I write about this as I go. Follow along on LinkedIn if you want the next one, and tell me which rung you are on. The answers are the most useful thing I get.