AI coding assistants speed up the part of a project where a developer already knows what to build and just needs to write it: boilerplate, test scaffolding, CRUD endpoints, well-specified functions. They don't shrink the time spent figuring out what to build, getting stakeholders to agree on it, deciding how the pieces fit together, reviewing the resulting code, or debugging it once it's live. On anything past a small, well-defined app, those slower phases dominate the schedule, so faster typing doesn't translate into a proportionally cheaper project.
Where project time actually goes
Ask any engineering lead to account for their hours on a real client project, and writing new code is rarely the largest line item. On the mid-sized builds we run, the rough split usually looks like this:
- Requirements discovery and stakeholder alignment. Understanding what the client actually needs, reconciling what three different stakeholders each assumed the system would do, and turning that into something a team can build against.
- Architecture and technical decisions. Choosing a data model, deciding what stays synchronous versus async, picking where to draw service boundaries, and weighing trade-offs that are expensive to reverse later.
- Writing the code. The actual implementation work: functions, endpoints, UI components, migrations.
- Code review. Reading every diff, checking it against the intent behind the ticket, catching edge cases the author missed.
- Testing and QA. Verifying behavior beyond what unit tests cover: integration paths, edge cases, how the system behaves under real data.
- Debugging and stabilization, especially after launch, when the system meets real users and real data for the first time.
Writing new code is one bucket among six, and on most projects past a simple internal tool, it isn't even the biggest one. Discovery and architecture alone often eat more hours than implementation does, because getting the decision right the first time is harder than typing out the result of a decision already made.
What AI coding tools are actually good at
Where a developer already knows exactly what needs to exist, AI assistants remove a lot of the mechanical effort of producing it. A REST controller with standard validation, a database migration, a test suite for a function with clear inputs and outputs, a first draft of a UI component that matches an existing design pattern: these go from something that takes 30 to 60 minutes of typing to something a developer can generate and check in 5 to 10 minutes. That's a real, measurable speedup on a real category of work.
The common thread across everything AI tools handle well is that the specification is already settled. Someone has already decided what the function should take in, what it should return, and how it should behave at the edges. The tool's job is translation, not decision-making, and translation is exactly what these models are built for.
What they don't touch
None of that speed carries over to the phases where the answer isn't settled yet.
Requirements discovery doesn't get faster because a model can write code quickly. It gets faster through interviews, workshops, and the slow process of getting three stakeholders to agree on what "done" means. Architecture decisions still require a person to weigh trade-offs specific to a business: how the system needs to scale, what data has to stay consistent, what vendor dependency the team is willing to accept. A model can generate five plausible database schemas in seconds; picking the right one still depends on constraints nobody wrote down anywhere it can read.
Code review doesn't get lighter either. If anything, it gets heavier, because a team using AI assistants produces more code per day, and someone still has to read every line of it, understand what it does, and catch the subtle bugs that a model produces just as confidently as a correct answer. Debugging in production is the clearest case: reproducing an intermittent failure, tracing a request across three services, and figuring out why the system behaved one way in staging and another way with real traffic takes the same investigative work it always has, regardless of how the original code was typed.
Why this means costs don't fall proportionally
Take a project where coding is 30% of total effort. Even if AI tools cut that slice in half, the client sees a 15-percentage-point reduction, not a dramatic one, because most of the hours were never going into typing code in the first place.
The math runs the other way on simple, well-specified builds. A small internal tool, a well-defined script, or an integration between two systems with a clear existing API is a project where coding really is most of the effort, because there isn't much discovery or architecture to do. On that kind of work, AI assistance genuinely cuts cost and turnaround meaningfully, sometimes close to in half, because the bottleneck the tool addresses actually is the bottleneck in that project.
What this means when you're scoping work
The honest way to set expectations is to separate the two cases rather than apply one story to every project:
- Complex, ambiguous, or integration-heavy work should be scoped and priced the way it always has been, with AI assistance treated as a modest efficiency gain on the implementation slice, not a reason to expect the whole timeline to shrink.
- Small, well-specified builds with a clear spec and few unknowns are where clients should expect real savings, because coding is a much larger share of what those projects actually cost.
Internally, this is also where we put the gain to use: freeing senior developers from boilerplate so they spend more of their time on the decisions and reviews that actually determine whether a system holds up. That's where quality gets made or lost, and it's the one part of the job AI tools were never going to do for us.