Most writing about AI and software engineering lands in one of two places. Big claims that it changes everything, or dismissive claims that it is mostly hype. Neither is very useful day to day. The better question is smaller. For a given kind of task, does AI assistance actually make you faster, and by how much? The answer depends a lot more on the type of task than most discussions admit.
Where it clearly helps
Boilerplate and scaffolding. Setting up a new service skeleton, writing a basic CRUD layer, generating test fixtures, wiring up config. This is exactly the kind of well-defined, pattern-heavy work that AI tools handle well. The task has a clear shape and a lot of prior examples to draw from. The time saved here is real and it adds up across a project.
Getting unstuck in unfamiliar territory. Working in a language, framework, or library you rarely use, and needing a starting point rather than an expert-level answer, is a strong use case. It shortens the usual loop of checking the docs, reading a few forum answers, and piecing together an approach, into a single conversation, even though you still need to check the result.
Reading and summarizing unfamiliar code. Being dropped into a large codebase you do not know, and needing to understand what a piece of it does before touching it, is a genuinely strong use case. It works more like faster reading comprehension than writing code for you, and that difference matters for trusting the result.
First-draft documentation and comments. Explaining what a function does, drafting a README, writing a first pass at a PR description. This is low-risk, easy to check, and the kind of task that often gets skipped entirely without something lowering the effort to just do it.
Where it helps less than people expect
Debugging deep, unfamiliar failures. AI tools are good at matching patterns to common bugs, but a genuinely tricky bug, a race condition, a stale cache, an edge case tied to your system’s history, often needs context the tool does not have and cannot get without you doing most of the investigation yourself anyway. It can be a useful sounding board, but its confidence is not proof it is right here.
Architecture and system design decisions. These need weighing trade-offs specific to your team, your constraints, and how much risk you can take, context an AI tool does not have unless you have spent a long time giving it, and even then, it will produce an answer that sounds reasonable whether or not it actually fits your situation. It is useful for generating options to react to. It is risky as the final word.
Anything where “sounds right” and “is right” are easy to mix up. This is the sharpest risk. AI-generated code reads well. It is formatted cleanly and uses sensible names. That polish is exactly what makes a subtle mistake dangerous. Code a person wrote quickly often looks unfinished, which draws attention. Code a machine wrote looks confident, which discourages a closer look at the exact moment you need one.
The real skill that matters now
The engineers getting the most value are not the ones using AI tools the most. They are the ones who have built an accurate sense of where the tool is strong and where it is not, and who match their level of trust to the task. That is a skill you build the same way you build any judgment skill, by getting it wrong a few times, shipping something that looked fine and was not, and adjusting from there.
A useful habit is to ask, before accepting AI-generated output, what about this task makes it likely to be right or likely to be wrong. Boilerplate for a well-known pattern, trust it, but still read it. A tricky fix to a concurrency bug, treat it like a first draft from a very fast but unreliable engineer, not a finished answer.
The honest bottom line
For well-defined, pattern-heavy work, the speedup is real and it matters. For work that depends on judgment, architecture, tricky debugging, decisions with real trade-offs, the speedup is smaller than the hype suggests, and trusting the output more than it deserves will cost you more time than it saves, usually later, when the mistake shows up in production instead of in review.
Building with AI does not mean using it for everything. It means knowing which part of your work it genuinely speeds up, and staying just as careful as ever on the rest.