What takes the time on a real project now that agents write most of the code.
In short
- On the project I look at here, most of the measured hours went to deciding what to build and getting it approved. Building was about a tenth.
- Since my earlier analysis in April 2026, AI agents have taken over most of the writing and checking of code, so it is an even smaller part of the work.
- That small share comes from how we work. Before the agents build anything, we write down and approve what the product must do. We haven't measured what happens when a team skips that step.
- Most of a feature's calendar time is not building. It goes to decisions, approvals, reviews and waiting, and none of that disappears when an agent writes the code.
Earlier this year, in April 2026, I wrote about why software still takes time in the age of AI. It was a question I kept hearing from founders and product leaders. If AI can write so much code, shouldn't software be dramatically faster and cheaper to build?
My answer then was that the bottleneck had moved. Software was never just code. It also meant understanding the business, deciding how the product should behave, fitting it into what already exists and checking the result. At that point AI was already part of everyday work in our teams, and it was still reasonable to debate how much of the code it wrote deserved a careful human review. We were not yet delivering with multi-agent systems the way we do today.
That has changed, and it makes the argument stronger. We now build software with what we call our delivery system. It is a group of specialized AI agents, plus the rules and checks around them, that write and check most of the code. Writing code is now an even smaller part of the work than it was at the beginning of the year, and whether it is worth reviewing every line by hand is no longer the interesting question. The system also keeps a record of what happens in each project, which gives me something I didn't have in April. Numbers. So here is the same question again, asked with data. On a real project, where does the time actually go?
Most of the time goes to deciding what to build and approving it
The data comes from an app we built for a client with our delivery system, between 31 July and 14 October 2026. The system measures how many hours each stage of the work takes. On this project, defining what to build took 44% of the measured hours and human approval, people reviewing and signing off, took 38%. Building was about 10%, and everything else, shipping and testing, was about 7%.
Read that as an example and not as a benchmark. These are shares of the clock hours recorded in each stage, not of anyone's effort, and the stages can overlap. Time spent going back, which I come to below, is recorded separately and overlaps with the stages, so I left it out rather than count it twice. Every project is different, and across the six projects where we have good records, building was between 7% and 17% of the measured hours, so the pattern repeats.
What does defining what to build look like? Mostly questions that agents can't answer on their own. On this project the system asked people 218 questions. Many are quick. 170 of the 218 were resolved, most within minutes, and people mostly confirmed what the agents proposed, the same pattern I described in Is Your AI Vendor's Human in the Loop Real? Others take longer, because they are the ones that shape the product. What should the app do, for example, if the same receipt arrives twice, once by email and once scanned by hand? That is not a coding question. It is the kind of judgment I wrote about in Human in the Loop for AI Agents, and it makes sense that it takes time.
Building is the quick part
Once those questions are answered, building goes quickly, and agents do most of it. On this project, 81% of the commits that reached the main code (458 of 562) had an agent as author or co-author, and 40% of the 562 commits were written by an agent working inside the delivery loop. A co-author tag means a person was working with an agent, not that nobody was involved. On the project behind my human in the loop article, agents ran 976 checks in two weeks, and only one needed a person. The code is generated, and largely checked, by agents.
Why is it so quick? Think of a presentation you are preparing on something you know well, whether it is for your boss, your peers or your investors. You ask an AI for the slides and you get a draft quickly, much faster than building it by hand. The rest of the afternoon is yours. You decide what you really want to say, check the numbers, spot the slide that doesn't hold up and get the right people to sign off. You can do that because you know the subject. Someone who didn't would accept the first draft, and it would look fine. The clearer your brief, the less you go back. In our projects the brief is what we call the Ground Truth, a written, approved description of what the product must do and what "done" means. The agents are the part that produces the draft quickly. Most of the time goes to getting the brief right, and that is why the building is quick.
So I wouldn't read the 10% as "AI makes software ten times faster to build." It is what the split looks like when the brief is in place. In my experience, a team using AI without one sees a very different split. We haven't measured that case, so I won't say by how much. Building may well be many times faster, as the headlines say. I'm not arguing with the headlines, only with the arithmetic. When building is only a small slice of a project, speeding it up can only change the total so much.
Part of the time goes to going back
The first version is rarely the last. On this project, 43% of the agents' runs in the delivery loop needed at least one more pass (83 of 192). An agent produces something, a check finds a gap and the agent tries again. I wrote about that loop in the article on agent loops, on a different project. It is natural, and it is where quality comes from.
The system records those passes separately from the stages above, and their hours overlap with them, so I can't give you a clean share of the total. Even if I added them in full on top of the stages, defining and approving would still be more than half of the measured hours.
The temptation would be to cut that second pass to save time. I would call that an anti-pattern. The gaps don't disappear, they show up later, when they are more expensive to fix, and the total goes up instead of down.
Most of the calendar isn't building
The system records how long the work inside the workflow takes, and for most stories that covers only a small part of the calendar. It doesn't record the time between runs, or what happens outside it, but that is where the days go.
Take a small feature. When the app imports a receipt from an email and can't read the total, it asks the person to enter it. The agents built the first version in under an hour, and the feature took almost four days to ship. The system recorded only a few hours in that time, under an hour of building and about two of checking. Building was not where those days went. The system doesn't log what filled them, but anyone who has run a delivery team recognizes it. It is the decision on whether the feature is ready to release, the wait for someone to review or confirm it, the alignment with the people who depend on it, or the story sitting in line until somebody has time. None of that disappears because an agent writes the code.
So why does software still take time?
Because the time moved. Building is fast now. What is left is the work around it:
- Understanding the problem, and the people who have it.
- Deciding what to build, and what not to.
- Writing down what the product must do, and what "done" means.
- Approving it, and signing off on what ships.
- Checking the result, and going back when it isn't right.
- Fitting it into what already exists, securely and in a way the team can keep running.
- Finding out whether anyone needs it once it is out.
That list is not paperwork. Each item is a decision that costs something if it is wrong, and someone has to know how much. It takes experience to see that one requirement contradicts another, that a design won't hold when the product grows, that a result looks right and isn't, or that a feature nobody asked for isn't worth building. Agents can propose, build and check at a speed a human team can't match. They can't be accountable for the answer. That is what a software expert is for, and it is why this part of the work takes the time it takes. It is the part that needs judgment.
As my colleague Gonzalo Mercadante explains in Is the MVP Dead?, shipping proves a product can be built and says nothing about whether anyone needs it. Building is getting cheap. Knowing what is worth building, and answering for it, is the work that remains.
That is the answer I gave in April, and now it has numbers behind it. If you want an outside read on where the time goes in your own project, talk to our team.
About the data. The numbers in this article come from the records of our delivery system for one project, between 31 July and 14 October 2026, and from that project's code repository. They were recalculated from the raw records on 24 October 2026. The percentages are shares of the hours spent in each stage of the work, not of the elapsed calendar, and the stages can overlap. Building is measured from the moment an agent starts working on a task until it proposes the first version of the change, and includes fixing bugs. Time spent going back is recorded separately and is not included in the percentages. For most stories, the records tied to that story cover only a small part of its calendar time. Hours are clock hours of the runs, not compute hours.
Frequently asked questions
Does AI make software projects faster?
Building is much faster. On this project it was about 10% of the measured hours, and agents wrote most of the code. But a project also includes defining what to build, approving it and checking it, and those take most of the time. So the project as a whole speeds up less than the building does.
Where does the time go in an AI-native software project?
On one project we measured, defining what to build took 44% of the measured hours, human approval 38% and building about 10%. Across six projects with data, building was between 7% and 17%. These are examples and not benchmarks, the stages can overlap, and time spent going back is recorded separately.
Why do AI agents need more than one pass?
Because the first attempt often doesn't match what was agreed. In this project, 43% of the agents' runs in the delivery loop needed at least one more pass. It is a normal part of the process, and the checks are what catch it.
