The short answer
AI coding tools speed up the mechanical, well-patterned parts of a software build dramatically, and barely move the parts that require judgment about a specific system's design or a specific business's constraints. Knowing which is which — task by task, not project by project — is what separates a realistic AI-assisted workflow from a hopeful one.
The tasks where the speedup is real
- Boilerplate and scaffolding. Setting up a new API endpoint, a CRUD screen, a standard project structure — these follow patterns AI tools have seen an enormous number of times, and generating a correct first draft is fast and reliable.
- Test writing. Once the behavior to test is specified, generating the test cases themselves — including edge cases a developer might not think to write by hand — is one of the strongest use cases, because the hard part (knowing what should be tested) is separable from the mechanical part (writing the test code).
- Documentation. Explaining what a function does, generating API references from code, writing setup instructions — this is close to a best case for AI tools, because the source of truth (the code) already exists and the task is translation, not invention.
- Refactoring within a known pattern. Renaming, restructuring, or updating code to a new convention across a codebase is fast when the transformation is well-specified, even across a large number of files.
The tasks where it barely moves
- Architecture decisions. Choosing how a system should be structured — where the boundaries between services go, how data should flow, what the failure modes look like under load — requires understanding trade-offs specific to a business's actual scale, team, and constraints. AI tools can describe options; they can't make the call, because the call depends on context an AI tool doesn't have and can't infer from a codebase alone.
- Debugging unfamiliar systems. Finding the root cause of a bug in a large, unfamiliar codebase usually requires building a mental model of how the system actually behaves — not just what the code says it should do. That mental-model-building is still largely a human process; AI tools help search and summarize, but the diagnosis itself remains slow.
- Encoding tribal business knowledge. The parts of a system that exist because "that's how this specific business's process actually works" — an exception rule, a workaround for how one client's data arrives, a compliance requirement that isn't written down anywhere in the code — have to come from a human who knows the business. AI tools have no way to generate what nobody told them.
- High-complexity, novel problem-solving. McKinsey's research on generative AI and developer productivity found under 10% time savings on high-complexity work, versus 35–45% on routine code writing and 45–50% on documentation — a wide enough gap that treating "AI speeds up coding" as a single, uniform claim misses the entire practical picture.
Why the split matters for how a project actually gets built
A software build isn't one uniform activity — it's a mix of the mechanical and the judgment-heavy in proportions that shift throughout a project. Early scaffolding is mechanical-heavy; the middle of a project, where architecture gets decided and edge cases get discovered, is judgment-heavy; the end, with documentation and test coverage, swings back toward mechanical. A workflow that applies AI tools well leans on them hardest exactly where the mechanical share is highest, and treats the judgment-heavy stretches as still fundamentally a job for an engineer who understands the system and the business behind it.
What this means in practice
The realistic version of "AI speeds up software development" isn't a flat percentage applied to a whole project — it's task-by-task, and the tasks that speed up are disproportionately the ones that were never actually the hard part of building good custom software in the first place. The hard part — understanding what a business needs and making sound decisions about how to build it — is still work a person has to do.