What We Actually Measured
Claims about AI coding assistants swing between two fictions: that they halve development time, and that they are autocomplete with a marketing budget. Both are stated with more confidence than evidence, so we did the less glamorous thing and looked at where time actually went across our own delivery work, comparing recent builds against our pre-assistant records on task categories rather than overall vibes. Our context matters for reading the numbers: we ship platforms built on mature reference architectures, with AI-assisted launches that reach production in a handful of days and custom builds that land in a few weeks, so the baseline we are improving on was already disciplined.
The honest framing is that assistants changed the distribution of engineering time, not just its total. Some categories of work collapsed to nearly zero; some shrank meaningfully; a few became more expensive, because the code arrives faster than judgment does. Summing the categories into a single percentage would be easier to quote and less true, because the same assistant is transformative on one task and a distraction on another, and the mix of tasks is what actually determines a project's timeline.
A caveat worth stating plainly: this is our sample, not a controlled study. Our projects are web and mobile platforms, our teams are senior, and our codebases are structured for reuse. Teams working in legacy code with thin test coverage, or in domains where correctness is regulatory, will see a different distribution. What follows is the pattern we can defend from our own delivery records, hedged accordingly.
Where Assistants Genuinely Compress Timelines
Scaffolding is the category that collapsed. CRUD endpoints, form components, configuration files, schema definitions, the connective tissue that every feature needs but nobody would call engineering, assistants produce it near-completely, and the review is faster than the writing ever was. On a typical platform build this was easily a third of the raw coding hours, and most of that third has left the schedule. The gains compound on greenfield work, which is exactly why our AI-assisted launch track can compress delivery into days: the reference architecture provides the decisions, and the assistants eliminate the typing between decisions.
Tests and migrations are the second and third winners. Assistants enumerate edge cases for test suites with a patience no human sustains, and they catch the ones engineers were quietly assuming away; the generated tests still need human review, but reviewing is several times cheaper than authoring. Mechanical migrations, updating an API across forty call sites, converting a module to a new framework version, renaming a domain concept through the codebase, are similarly transformed, because the work is pattern application across many files, which is precisely what the models do best. Documentation, too: docstrings, API references and README files that were always the first casualties of a deadline now cost minutes.
The common thread across all three: the work was well-specified, verifiable and locally scoped. Where the definition of done is clear and the correctness can be checked mechanically, by a test suite, a type system, a compiler, assistants shine, because the verification loop is fast. Keep that criterion in mind, because it explains everything in the next section: where verification is slow or the specification is the hard part, the compression does not materialize.
Where They Do Not
Domain correctness is the stubborn one. An assistant can write a flawless function that implements the wrong business rule, because the rule lives in the client's operations, edge cases and history, not in the prompt. Refund windows, courier settlement logic, moderation thresholds, the specifics that make a platform yours are exactly the specifics no model has seen. The generated code compiles, passes the tests that were also generated from the same misunderstanding, and ships a bug with clean syntax. Every serious delivery team we know has a story in this genre, and the fix is never a better prompt; it is a human who owns the domain reviewing the behavior, not just the code.
Integration debugging resists compression for a different reason: the answer is not in any training set. Why a payment webhook fires twice, why an SDK fails only on one Android manufacturer, why an auth flow breaks behind a specific proxy, these are conversations with external systems that misbehave in ways documented nowhere. The diagnostic loop involves reading vendor forums, capturing real traffic, and forming hypotheses against systems you cannot see inside. Assistants can suggest what to check, which helps, but the loop's bottleneck was never typing speed; it was evidence, and the evidence lives outside the model.
Requirements ambiguity is the third wall, and the most important one for client work. Half of what a senior engineer does in a discovery conversation is prevent the building of the wrong thing: spotting that the client's requested feature implies a workflow they have not thought through, or that two requirements contradict. Assistants cannot sit in that conversation, and worse, they accelerate the building of the wrong thing with the same efficiency as the right one. Where the risk is 'fast delivery of a misunderstanding,' speed is the problem, and no assistant fixes that.
The Review Bottleneck
The hidden cost of generated code is the shift in where senior attention goes. When drafting was the bottleneck, review was cheap; now drafting is nearly free and review is the constraint, because unreviewed generated code is how subtle bugs ship with confident commit messages. Teams that ignore this inversion discover it through incidents. The ones that plan for it restructure deliberately: smaller pull requests so review stays fast, generated tests validated by humans before the code they test is trusted, and CI guardrails, types, linters, test coverage thresholds, that catch mechanically what reviewers cannot.
Layer discipline helps too. Generated code lands first in the low-risk strata, scaffolding, standard flows, the well-specified layers where verification is mechanical, while architecture, security-sensitive paths and domain logic stay human-authored by default. The boundary is not dogma; it is a risk allocation that says verification speed determines trust, and grants autonomy accordingly. It is the same principle we apply to autonomous agents, applied to the tools that write the agents.
There is also a skill effect worth naming. Junior engineers ship faster with assistants but risk plateauing, because the tool removes the productive struggle where fundamentals form. Teams that let juniors review generated code against the reasoning behind it, why this pattern, what this test protects, turn the tool into a tutor; teams that do not, graduate engineers who can prompt but cannot judge. The judgment is the seniority, and the industry still needs it, arguably more than before.
What This Changes About Client Delivery
For clients, the honest summary is that assistants removed waiting, not thinking. Our AI-assisted builds launching in six to nine days are real, and they rest on three legs: prebuilt platform architecture that has already survived production, scoping discipline that prevents building the wrong thing, and assistants compressing the connective tissue between decisions. Any of the three alone underdelivers. A team with assistants but no reference architecture spends its saved typing hours rediscovering decisions it already made last year; a team with architecture but no scoping discipline delivers the wrong thing impressively fast.
Custom builds in the three-to-four-week range tell the same story with the proportions shifted. The custom share of the work, the domain-specific logic and the integrations, is where human engineering concentrates, and assistants shorten the surrounding work enough that the custom share becomes most of the timeline rather than buried inside it. That is a real and significant compression. It is also a ceiling that comes from the nature of the work, not from any deficiency in the tools, and teams promising more are usually pricing the discovery they will do anyway.
One implication matters more as generation grows: source code ownership. When more of the codebase is machine-written under human review, the review trail, the architecture decisions, the domain rules encoded in tests, become the actual asset, and owning all of it outright is non-negotiable. We hand over one hundred percent of the source on every delivery precisely because of this. If you want to follow how our delivery practice keeps evolving as the tools change, we write about it in the engineering blog, and you can see the AI-assisted build track for how we package the compressed timeline.