How fast can software actually be built with AI tooling?

What actually got faster?

The mechanical middle of a project. Scaffolding an application, wiring a database and an auth layer, writing the integration against a documented API, generating the test suite, migrating content, producing the second and third variation of a layout so somebody can choose between them.

These were never the interesting parts, and they were most of the calendar. An engineer who used to spend three days on boilerplate before writing anything specific to the business now spends an afternoon, and spends the rest of the week on the part that is actually particular to the client.

The compression is real and it is large. It is also uneven, which is the part most estimates get wrong.

What refuses to compress?

• Deciding what to build. Nobody has shortened the conversation where a business works out what it actually wants, and no tool can have it for them.
• Access. Credentials, sandbox accounts, a sample of real data, someone who can approve a change to the CRM. This is the single commonest reason a fast build sits still.
• Review by the people who will live with it. Anything customer-facing, regulated or expensive to get wrong needs a human to read it, and that person has a day job.
• Anything that has to be learned rather than written — how a strange legacy system behaves, why the last vendor did something odd, what the exception in the process is really for.
• Trust. A team that has been burned by a previous build will move at the speed of its own confidence, whatever the tooling does.

Does faster mean worse?

It can, and the failure is predictable: generated code that nobody senior read, no tests that assert anything about the business, and an architecture chosen because it was the default rather than because it fits the load.

The protection is not to slow down. It is to keep the review where it always belonged — a senior engineer owning the design and reading what ships — and to let the tooling absorb the volume underneath that. Where we run this well, speed and quality move together, because the time saved on boilerplate is spent on the parts that decide whether the thing works.

Where it is run badly, you get a large volume of plausible code very quickly, which is worse than a slow project. Velocity without ownership is the actual risk, not the tooling.

A useful test when a firm quotes you an unusually fast timeline: ask who reads the code before it ships, and what happens when the generated approach is wrong.

How do we plan a project around this?

Work backwards from the first thing a real user can touch, and make that as early as possible — days, not months. Everything after that is a conversation about something concrete rather than a document about something imagined.

Stage the work so each stage is independently useful and you can stop. A build that has to run to completion before it delivers anything is a build whose timeline you cannot verify.

Front-load access. Ask for credentials, sample data and the name of the person who approves changes in the first week, because those are the constraints that will actually set the date.

What timelines are honest?

• A business website, rebuilt with existing content: about a week.
• A web application — portal, dashboard, booking system — with logins and one integration: a working version in two to three weeks.
• A mobile app on one codebase for Android and iOS, including store submission: three to four weeks, plus review time you do not control.
• An AI system in production, with evaluations and monitoring: a prototype in days, live in two to four weeks.
• Anything involving a regulator, a migration off a system still in daily use, or more than two organisations: longer, and be suspicious of anyone who says otherwise.