KAITUM AIOur in-house brand — execution AI for automotive sales.Visit nrmnext.com
Article

AI builds in days: why month-long projects are over.

Finn Tigchelaar··7 min read

How LLM-assisted implementation lets us ship 10× faster — and why quality doesn’t suffer.

The waterfall project is dead.

Twelve weeks of concept phase, six weeks of specification, then half a year of development by the end of which hardly anyone remembers why a requirement was in the brief in the first place. Anyone who has bought software this way over the last twenty years knows the pattern — and the risk that the result misses the market.

With LLM-assisted implementation, we deliver the first working version today in days rather than months. Not a throwaway prototype, but a codebase that carries on into production. That doesn't just shift timelines, it changes how decisions are made.

Because when a functioning version is on the table after three days instead of three months, you're no longer debating mockups — you click through a real system and immediately notice what's missing. Requirements that sounded plausible on paper expose themselves on the running product in minutes as superfluous or wrongly conceived.

How the 10x factor comes about.

The speed gain doesn't come from faster typing but from removing friction. Boilerplate, data models, API integrations, test scaffolding — everything that used to be days of grunt work, a model generates in minutes. Our developers spend their time where judgement counts: architecture, edge cases, integration.

A typical comparison from our projects: a customer portal with auth, roles, three connected systems and reporting used to take around four months to a production launch. With an LLM-assisted build, the first two weeks gave a usable MVP, the full build was ready after a good six weeks.

What matters: the model writes code, the human owns it. Every generated line goes through review, tests and our security gates. Nobody merges unread.

The bottleneck thus shifts from production to decision. It's no longer the question "how long will this take?" that sets the pace, but "what exactly do we want to build?" — and that question can be answered faster and more honestly on the running system than in any workshop.

Why quality rises rather than falls.

The reflex is understandable: fast means sloppy. In practice the opposite is true. Because test coverage, linting and documentation barely add effort any more, they're created from the start — rather than cut at the end when the budget runs tight.

Faster iterations also mean false assumptions surface early. A conceptual error that, in a classic project, only becomes visible at acceptance testing after six months surfaces with us in the first week — when the fix still costs hours rather than weeks.

We measure this: defect density and the share of rework after launch are not higher in the fast-built projects but lower than in the classic approach.

Where the 10x factor doesn't apply.

Honesty is part of it: not every project accelerates by a factor of 10. Where the complexity lies not in the code but in coordination, regulatory sign-offs or the migration of grown legacy systems, the model is only one building block among many. Implementation was never the bottleneck there.

With heavily domain-specific logic too — actuarial pricing, safety-critical control — the share of human work stays high, because every error here is expensive and the model can't judge reliably without deep domain expertise.

We communicate this openly rather than promising the same factor everywhere. The honest gain averages more like a factor of 3 to 5 across the whole project — and for the standard build, where friction dominates, exactly 10.

What this means for our clients.

Newroom is an operator, not a consultancy. Speed isn't an end in itself for us but the basis for building a product, rolling it out and operating it — and developing it further after launch rather than freezing it.

For the client, the risk shifts: instead of betting a large budget against a spec sheet, they see substance after a few days and decide on the basis of what works. Wrong decisions no longer cost half a project but one iteration.

That's the real revolution — not the speed, but the certainty it creates. Whoever sees in days rather than believes for months makes better decisions.

RELATED

Does this apply to something on your side?

If you want to talk about how we translate this to your context — 30 minutes is enough for a start.

More articles