What AI Does Not Speed Up in a Software Project

What AI does not speed up in a software project

Short answer: AI speeds up writing code, not the rest of a software project. Understanding the need, making trade-offs, validating with users, integrating with existing systems, reviewing and shipping to production take as long as before. When one step gets fast, the others become visible: the bottleneck moves, it does not vanish. This article lists the six steps AI does not compress, what you can reasonably expect from it, and how to build a schedule that does not bake in an imaginary gain.

We ship products with coding assistants every day at Tesseract Studio. Our view is that of users, not skeptics: the tool is useful, but saying so without saying where it is not leads to wrong budgets and wrong deadlines.

Why code was never the bottleneck

In a project lasting a few months, writing code is a share of the time, rarely the majority. The rest goes into scoping meetings, rounds of feedback on screens, and waiting for an access, a test file or a decision. Speeding up the writing share by 30% or 50% shortens the calendar by only a fraction of that gain.

It is the logic of a chain: its speed is that of its slowest link. Speed up one link and the queue forms just before the next one. Several 2026 analyses describe exactly this: AI exposes bottlenecks that were already there (specification, testing, integration, release) rather than creating them.

Serious measurements are less flattering than demos

The best public reference point remains METR’s controlled trial, published in July 2025. Sixteen experienced developers from large open source projects completed 246 real tasks, randomly assigned to be done with or without an AI assistant. Result: 19% more time with AI. Even more striking, developers expected a 24% speedup and, afterwards, still believed they had gained about 20%.

This result must be read at its true scope. The authors state that it applies to experienced developers, mature codebases they know very well, and early-2025 tools. They also note that more recent measurements, on late-2025 tools, show different results. So it is not proof that AI slows people down, but a solid warning: perceived speed is not measured speed. A schedule built on perception will be wrong.

The six steps AI does not compress

1. Understanding the real need

An assistant produces what you ask for, very fast. It does not know the request is badly framed. Knowing whether you are building the right thing takes interviews, trials on real cases, and sometimes the realization that the requested feature is not the real problem. That work happens with people, at people’s pace.

2. Trading off and deciding

When you can generate ten variants of a screen in an hour, the difficulty is no longer producing but choosing. More options without a decision criterion make the decision longer. The right reflex is the opposite: set the criterion (conversion, delay, running cost) before asking for variants, and cap them at two or three.

3. Reviewing and verifying

Generated code almost always looks clean. The error to look for is the plausible one: a forgotten business rule, a test that tests nothing. Verification costs as much as, or more than, hand-written code, and it cannot be delegated to whoever generated it. We covered this shift in code review with AI assistants.

4. Integrating with what exists

The constraints that cost time are rarely in the new code: a supplier API that answers badly, an accounting export with surprising fields, an access to obtain from a third party, a rule in a line-of-business tool nobody documented. AI cannot guess what is written nowhere. For cases where real data breaks an automation, see our article on AI automations facing real data.

5. Validating with users

Users do not test faster because the code was written faster. A week of feedback is still a week. Validation cycles (acceptance testing, training, fixing gaps, formal sign-off) follow the client organization’s rhythm, and AI changes nothing there.

6. Operating, securing, maintaining

Release, monitoring, backups, access rights, compliance with the Swiss data protection act (nFADP) when personal data is processed: these tasks do not go away. The more code you ship, the more surface you have to maintain. Code produced fast but poorly understood becomes debt someone will pay later.

What AI really speeds up

It would be wrong to conclude it is useless. It brings a real gain on well-bounded tasks: throwaway prototypes to test an idea, repetitive code, unit tests from a described behavior, documentation, refactoring protected by tests, exploring an unfamiliar codebase. In these cases the result can be checked quickly, so an error costs little.

The rule we apply: AI pays off where verification is cheap. Where verifying takes as much work as producing (subtle business logic, security, architecture), the gain disappears. Our delivery method, described in shipping a product in 90 days, rests on this distinction: speed up what is checked quickly, protect the time of what does not compress.

A worked example, for illustration

Take a fictional twelve-week project, split as follows before AI: two weeks of scoping, two of design, four of development, two of integration, one of acceptance, one of release. These numbers are an example of reasoning, not a measurement.

Suppose AI halves development time, which is a generous assumption. Development drops from four weeks to two, and the project from twelve to ten weeks: a 17% gain on the calendar, not 50%. If review and fixes then absorb half a week, you land at ten and a half weeks. The real gain therefore depends on the share of development in the initial calendar, and on what verification takes back.

That is also why the promise of “delivered twice as fast” should always trigger the same question: on which step, and with what assumption about the others?

How to build an honest schedule

1. Split the project by type of step, not by feature: scoping, design, development, integration, acceptance, release.
2. Apply the AI gain only to the development step, and on a cautious assumption. If someone promises a project twice as fast, ask at which step.
3. Put external dependencies at the top of the plan: accesses, datasets, legal or accounting sign-offs.
4. Keep validation milestones with users at fixed intervals, for example weekly.
5. Measure the real lead time from idea to production, not the amount of code written.

Five questions to ask a vendor who promises an AI gain

• On exactly which step does the gain apply, and what share of the calendar does that step represent?
• Who reviews the generated code, and how much time is planned for that review?
• Which external dependencies (access, data, sign-offs) are identified from the start?
• How will lead time be measured: in lines of code shipped or in the production date?
• What happens if the announced gain does not materialize: does the price change?

What this changes for price

If a project costs less, it is mainly because baseline development costs less, not because everything goes twice as fast. We prefer a fixed price on a defined scope, because it forces us to name the steps that cannot be compressed. The logic is explained in fixed price or time and materials. To see how this plays out in practice, see our plans and prices.

Key takeaways

Estimate development with AI, but do not credit it with the rest. If your project has a tight schedule, the most useful thing is to describe your external dependencies to us: that is where the lead time is decided. See also all articles on the blog.