We Didn’t Get Faster by Doing Less

A full data platform build. Ingestion, deployment, source integrations, operational controls, analytics, stock accounting, validation, runbooks, governance. The kind of scope that normally takes a mid-sized team the better part of a year.

We did it in four months. One team, working with agentic development tooling.

That number alone is the kind of thing competitors are shouting from rooftops right now, usually followed by some version of “AI built this in a weekend.” We’re not going to do that, because it isn’t the whole story, and the part that’s missing is the part that actually matters.

The number that should worry you (and doesn’t)

Here’s the bit most companies selling AI-assisted speed conveniently leave out of the pitch: our code churn on this project sat at roughly 2.1x current code volume. A stable, mature product typically shows 0.5x to 1.5x. Rework-type commits, corrections, hardening, reconciliation, ran 34% to 52% across major work areas, against a normal expectation of 15% to 30%.

On paper, that looks like a warning sign. In a finished product humming along in production, it would be.

Here it’s the opposite: this was a live discovery process, not a finished product being maintained. Real source systems had to be understood as the build happened. Production data gaps had to be found and fixed as they turned up, not assumed away in advance. Provisional logic got replaced with tested, explicit rules once the actual business semantics, how stock gets accounted for, how movement gets tracked, who has reporting authority over what, became clear through the work itself.

The most rework-heavy area was Operations Control, at 52%. Makes sense: it’s the part of the system people actually touch and argue with every day, so it kept evolving as real usage clarified what was genuinely needed. The most stable area was Source Integrations, at 34%, the connective tissue that, once correct, didn’t need to move again.

What the tool actually did, and what it didn’t

Here’s where most of the AI-speed narrative quietly falls apart, and where we’re being deliberately precise instead of impressive.

The agent compressed implementation mechanics, test generation, documentation throughput, and repeated refactoring that would normally need separate handoff cycles between people.

It did not, and could not, compress architecture and boundary decisions. Understanding what the client’s business actually needed took people asking the right questions. Judging whether the production data flowing into the system was trustworthy took human scrutiny. And deciding when something was actually, genuinely done sat with a person, every time, no exceptions.

Put plainly: the speed came from the tool. The reason that speed didn’t turn into a mess is that people were still making every judgment call along the way.

Speed without judgment is just a mess that arrives sooner

“AI replaced a team” is a better slogan. “The tool compressed implementation and documentation throughput for a scope that would normally take a multi-disciplinary team several quarters, and every business, architecture, source-discovery, and acceptance decision still ran through a person” is a better description of what actually happened.

It’s also the more useful thing to know if you’re deciding whether to trust a vendor’s speed claims with your own project. A project moving fast with a suspiciously clean churn number is worth a question about what got skipped. A project moving fast with a slightly alarming rework number might be showing you exactly the sign that real discovery happened, rather than corners getting cut to hit a headline.

We’d rather hand you the second one.

Interested in what this looks like for your own build? Get in touch, and we’ll walk you through exactly where the speed comes from and where the judgment still sits with us.