Speed Is Cheap Now. Trust Is Not.
The easy job got faster
A feature that once took a quarter to build can now take a week. Some teams measure it in days. If your job is to ship software, that feels like winning.
I am less sure it is. In enterprise software, building was rarely the slowest part. The slow part was getting people to change how they work, trust what they were given, and keep using it after the launch email was forgotten. Agents have made building much faster. They have done very little for that second part.
This article covers four things: why building and adoption used to move at the same pace, why AI-built software pulls them apart, how trust is really earned, and what I would do about it.
Two jobs, not one
Every feature runs on two jobs. The first is how long it takes to get a change into production. The second is how long it takes enough of the right people to actually rely on it.
In traditional software the two jobs moved together. Releases came every quarter, and people took about a quarter to absorb them. Training, documentation, security reviews and habit all fit inside one release cycle. If the jobs drifted apart, it was an annoyance, not a crisis.
Adoption is not one step. In my experience it moves through stages, and these time ranges are rough and illustrative, not measured:
- People learn the change exists: days to weeks
- They try it for the first time: weeks
- They use it out of habit: weeks to months
- The company approves it through security, risk and procurement checks: months
- They are willing to let it act on their behalf: months
I have seen this gap from the builder’s side. I have built platforms designed to scale before customers were ready to use them, and shipped forward-looking features the market was not ready for. The technology worked in both cases. What set the pace was how ready the customer was. My patents tell the same story: some of the ideas took seven to ten years to become something people could actually use. In each case, the timeline depended on when adoption caught up, not on how good the idea was.
What AI changes is how often this happens. Building ahead of adoption used to be the risk of an ambitious bet. Now it is the normal condition of every feature.
Why agents widen the gap
When AI agents build the software, delivery can get ten times faster or more. Adoption speeds up far less, and AI-based software adds friction of its own.
Get Ajit Patil’s stories in your inbox
Join Medium for free to get updates from this writer.
Four things drive this:
- The product’s behavior changes underneath the user. AI output can vary from one run to the next, and a model update can change what the product does, not just where a button sits. Users have to re-learn how far to trust it, not just where to click.
- The interface hides what is possible. With an open chat box there are no menus or buttons to explore, so people have to work out what to ask.
- Checking the work moves to the user. They now judge the output instead of just using it.
- Trust is lost faster than it is built. A steady stream of changes keeps resetting it.
The bottleneck moves
A useful idea from operations: when you remove one bottleneck, the next one becomes the limit. Agents removed the building bottleneck. The new limit is adoption, checking and trust.
I call what builds up adoption debt. It works like technical debt, but it sits with the users. Every change that ships faster than people can absorb it adds to the balance, and the interest shows up as confusion, workarounds and people quietly stopping use.
This does not mean speed is worthless. It still gives you faster fixes, cheaper experiments, improvements nobody has to relearn, and software for small niches that never justified a team. The gain is real. It is just smaller than the build numbers suggest.
Trust is not just calendar time
Time alone does not create trust. Three things do: how many times people have used the system, whether an independent party has vouched for it through audits, certifications or published test results, and how easily a mistake can be undone.
Of the three, undoing mistakes is the one a product team controls most directly. Easy rollback, limits on what the system can do, and gradual rollouts let people extend trust in small steps. A system that first suggests, then drafts, then acts with approval, and only later acts alone, earns trust faster than one that asks for full control on day one.
What I would do about it
Three changes follow:
- Measure adoption, not release. Track how long it takes for a feature to deliver its intended outcome, and how long until users let the system act without checking it.
- Limit how much unabsorbed change is in flight. When adoption lags, pause new releases and help people catch up with what has already shipped.
- Treat assurance as shared infrastructure. Assurance means the evidence that a system behaves as promised: tests, audit trails and automated compliance evidence. Built once and shared, it shortens the trust clock for every customer instead of each one starting from scratch.
Speed becomes a commodity
Fast building will become ordinary, because everyone will have access to the same AI agents. What stays rare is shipping quickly and having people rely on what you shipped. That depends on assurance: the evidence, controls and ability to undo mistakes that let users trust the system at the pace it changes.
Teams that invest there will get real value from their speed. Teams that do not will pile up adoption debt faster than they create value.
