Why Building With AI Is Slower Than I Expected
How to get faster to the right destination
I keep a file where I write down what I expect a build to take. I started Build to Thrive’s agent system in the spring with a number in that file, and I passed it a while ago. Not by a little.
The strange part is that nothing broke. No tool or model failed me in a way I could point at, and I have more working parts running now than I planned to have by this point, and I am still behind the date I wrote down. For a few weeks I read that as a discipline problem, which is the read most of us reach for first, and it is usually wrong.
Here is what actually happened, and I think it happens to a lot of people building right now.
The week my own system refused to work
Three weeks running, one of my agents produced nothing.
It is the one that drafts the weekly newsletter. It fires, it reads the research, it checks the inventory, and then it stops and writes a short note that says it is waiting on me to choose the topic. I built it that way on purpose, back in July, after I caught myself reviewing finished editions I had never asked for and rejecting them. So I locked it, on the rule that it does not draft anything until I have chosen the topic myself.
The lock worked exactly as designed. Every week it read the research, found no decision from me, and halted.
What I had built was not a writing bottleneck. It was a mirror. The agent could do the work in minutes. It could not do the one thing the work depended on, which was me deciding what the week was about. Three weeks of a machine sitting still, waiting, while I told myself I was behind on production.
I was not behind on production. I was behind on decisions, and I had never noticed because until this year, my slow execution had been quietly absorbing them.
What speed actually exposed
For twenty five years across five businesses, the gap between deciding something and seeing the result of it was long enough to hide a lot of vagueness. I could say “we should go after that market” and spend six weeks building toward it, and somewhere in week four the decision would finish making itself. The work did the thinking. I did not have to be precise up front, because the time it took to execute gave me room to get precise on the way.
That room is gone. When execution collapses from six weeks to an afternoon, every decision I was half making now has to be whole before anything moves. The vagueness that used to dissolve inside the build has nowhere to go. It sits at the front and blocks the queue.
This is why the build feels slower even while everything measurable about it got faster. I am not producing less. I am hitting the unresolved decision sooner, and hitting it more often, and there is no longer a four week buffer where it quietly resolves itself.
You have probably seen a version of this number: roughly 95 percent of corporate AI pilots produce no measurable return. It comes from an MIT-linked report in August 2025, it has been argued with since, and I would not build a case on it. I mention it because when I read past the headline, most of those stalls are not the model underperforming. They are organizations that automated a process nobody had decided the shape of, so the tool arrived on schedule and the judgment about what it was supposed to do never got made.
I wrote something related last year about what happens to high performers when output stops being the scarce thing. I was looking at it from the employee side then. Running my own build, the same shift showed up from the owner’s chair, and it was less comfortable.
Three signs this is what is happening to you
Not every slow build is this. Sometimes a build is slow because the thing is genuinely hard. A few weeks ago I wrote about how to tell which broken thing in your business is worth fixing first. What follows is the answer I kept getting wrong in my own, for months, with that general version already written down. These are the signals that say the delay is sitting somewhere else.
One. Your output went up and your finished work did not. You are generating more drafts, more versions, more options than you were a year ago, and fewer of them are crossing the line. The pile in the middle is growing. That middle is where undecided things go to wait.
Two. Your tools are waiting on you more than you are waiting on them. Count the number of times this week you opened something, looked at it, and closed it without moving it. If the answer is more than a couple, the constraint is not capacity.
Three. You keep rebuilding instead of finishing. Going back to improve something already built feels like progress and asks nothing of you. Finishing requires a decision you have been avoiding. Rebuilding is the more comfortable of the two, and it is very easy to do for a month without noticing.
If two of those three are true, more speed will not help you. I tried that first. I added capacity to a system whose actual constraint was one person’s unmade decisions, which is a fast way to build a larger queue.
The thing I got wrong for about six weeks was assuming the delay was a capacity problem, so I kept adding capacity. What finally moved the build was going the other direction, and the specific change I made is small enough to describe in a paragraph.
The Decision Debt Audit
This is the exercise, and it takes under an hour. I run it Friday afternoons now.
Step one. List everything currently built and not running. Any process, agent, page, offer, sequence, or asset that exists and is not live. Do not judge it yet. Just get the list.
Step two. For each one, write the sentence that starts “This is waiting on.” Be specific and name a person. “This is waiting on me to decide whether we are still selling the thing” is a real answer. “This is waiting on more time” is not, and if that is what you wrote, you have not found the real blocker yet.
Step three. Sort into four piles.
My call, and I can make it in five minutes. Make them now, in the session. Most of my eleven were here. This pile is where the build gets unstuck.
My call, and I need information first. Write down the one piece of information and where it comes from. Not a research project, one specific thing. If you cannot name it in a sentence, the decision is probably in pile one and you are avoiding it.
Not my call. Send it to whoever it belongs to today, before you close the session.
No longer needed. Kill it. Some of what is waiting on you is waiting because it stopped mattering and nobody said so. Killing these is the fastest capacity you will find all week.
Step four. Count pile one. That number is your decision debt. Mine was seven the first time I ran it. It is usually one or two now, and the build moves at a pace I recognize.
What paid subscribers get in this piece
The rest of this is the part I could not have written six weeks ago, because I had not fixed it yet.
The one change that unblocked the build, written out step by step so you can run it this week
A worked example from inside Build to Thrive, including the three-week halt, what it cost me, and the two decisions that were actually behind it
Where this goes wrong, the two failure patterns I hit while fixing it
How to tell a real capacity problem from a decision problem, so you do not apply this to a build that genuinely just needs more hours
The Loop Audit. Is the exercise I use to walk a single process end to end and find where it stalls. It pairs with this piece directly.
Paid subscribers also have access to my library of more than 200 tools and prompts.
It runs $80 a year, and you can add two hours of my time on an AI project of your choice by subscribing as a Founder.
The change that moved it
I stopped adding to the system and spent one session writing down every place it was waiting on me.
Not every task. Every decision. There is a difference, and the difference is the whole thing. A task is work I have not done. A decision is a judgment nobody else can make, which some piece of already built work is currently parked behind.
I found eleven. I had assumed there were two or three.
