Where AI actually saves time in a sprint — and where it costs you
Boilerplate, scaffolding, tests, docs: real wins. Architecture, debugging novel state bugs, naming things: still on humans.
Our name is AI Dev Crew, and we lean heavily on AI tools across a sprint. It would be easy — and a little dishonest — to claim the whole thing is magic. It isn't. AI has specific places where it halves the time a task takes, and specific places where it adds time if you let it. A 7-day timeline makes the difference legible; there's no room to absorb a mistake.
What follows is our working model after a lot of sprints. The categories aren't permanent — the tools are changing fast — but the shape has been stable for at least a year.
Where AI saves real time
Boilerplate and scaffolding
The largest, dullest, and most consistent win. API routes, form components, data-fetching hooks, server actions, database migrations, type definitions, test scaffolds. Anything where "if you've seen one, you've seen them all" applies. A model that's aware of your project's conventions can produce a Next.js route with Zod validation, a database query, error handling, and a typed response in the time it takes to describe it.
The discipline here is to keep the conventions narrow. The less your project looks like a snowflake, the better the model performs. Boring is productive.
Tests
Writing tests used to be the place projects quietly sagged under the timeline. With the spec already written and the code in front of it, a model produces unit tests and integration tests that cover the cases a junior engineer would miss. We still write the key flow tests by hand — those are specification documents, not scaffolding — but the edge case coverage that reads "if input is null, if input is empty, if input is the wrong type" happens in a fraction of the time it used to.
Documentation
Handover docs, environment-variable explanations, API reference for internal endpoints, flow diagrams described in prose. Docs are consistently undervalued and consistently skipped by every team under time pressure. AI is very good at producing an honest first draft from the code and the spec. The engineer's job becomes editing, which is fast and often fun.
Translating between languages and conventions
SQL to ORM query. JSON to TypeScript type. curl to fetch. Python script to Node script. Converting between formats is the most reliable pattern-matching task available. We use AI constantly for this and it's never been a bottleneck.
Broad code search and summarisation
"Where in this codebase do we handle the billing webhook?" is now a one-sentence question. "Summarise what changed in this PR diff" is the first pass of review. Neither is the final answer. Both are a real acceleration over grep and patience.
First-pass UI
A rough version of a page or component is now a minute-long task. The model gets the structure right, gets the Tailwind classes mostly right, and gets the empty state wrong in a way that's easy to fix. The engineer becomes a designer with a fast sketch pad. This is categorically faster than starting from a blank file, even for people who are quick with a blank file.
Where AI reliably costs you time
Architecture decisions
"Should this be a server component or a client component? Should state live in the URL or in a store? Should we use a queue here or a cron? Should this be two tables or one?" These are decisions that depend on where the product is going, not just what it needs to do today. The model doesn't know where the product is going, and it will give you a confident answer either way.
The failure mode is subtle: a plausible-looking architectural suggestion gets implemented, everything works, and three weeks later it turns out to have been the wrong shape for the next feature. We keep architecture decisions in human hands. The model can argue options; it doesn't get the vote.
Debugging novel state bugs
A race condition between two tabs. A stale cache that triggers once a day. A form that submits twice under a specific keyboard-and-mouse sequence. The class of bugs that hinges on what actually happened in the browser is exactly where the model is furthest from ground truth. It will confidently suggest the wrong fix, then confidently suggest the next wrong fix. You lose an hour.
Our rule: when a bug is genuinely weird, close the AI tab and read the code. Use AI afterwards to write the fix cleanly.
Naming
Naming a concept is an act of product definition. If a founder hasn't settled on what the thing is called, the model will choose an adequate name that obscures the disagreement. You'll live with a name like "WorkspaceItem" because that's what the model typed first, and a month in you'll realise the product calls it a "Canvas" and you've got fifty files to rename.
Names are a human decision. Always.
Exact data modelling
Model a generic data shape: fast. Model the right data shape for this specific product: still human work. The model doesn't know what queries you'll run in six months, or which fields will turn out to be one-to-many later. A schema that's a day's thought saves a week of migration pain later. AI shortens the typing, not the thinking.
Integration quirks
Stripe's trial handling. Google OAuth's consent-screen review. An email provider's deliverability profile for a cold domain. These are domain-specific pitfalls where the model's training data is outdated, inconsistent, or missing a detail that matters. We read the provider docs and the recent changelog. AI summarises them for us; it doesn't replace them.
Code review
AI review is good at the small stuff and bad at the important stuff. It'll flag a missing await; it won't flag that the PR implements the wrong feature. We keep humans doing the review, and we let the model do a first pass on style.
The meta-rule
The pattern underneath all of the above: AI accelerates work where the correct answer is a shape the model has seen before. It struggles where the correct answer depends on taste, on trajectory, or on ground truth the model can't observe.
A 7-day sprint has a lot of work in the first category and a real amount of work in the second. Getting the first done faster is how we finish the second on time.
How this changes the way we work
Day-to-day, the shape of engineering looks different from a sprint five years ago. Less typing. More reviewing. More deliberate moments of "no, the model is wrong, I have to think about this myself." More writing in general — specs, prompts, tests — because words are now load-bearing artefacts, not just documentation.
The engineers who do well with this stuff are the ones who are happy to treat code as the easy part of the job. The hard parts — taste, judgement, saying no — are exactly the parts AI is worst at. A sprint still rises and falls on those.