What AI Coding Tools Still Can't Do (And Why That's the Job)
AI handles the writing; you still own every decision about what it should say
I use AI coding tools every day. Not experimentally — as core infrastructure. They write tests, scaffold components, catch edge cases I'd miss, and compress the mechanical work of software into a fraction of the time it used to take.
So when people ask whether AI tools are changing the job, the honest answer is yes, significantly. What they're usually asking, though, is whether the job is disappearing. That one I'm less worried about, and not for defensive reasons.
Here's what I've actually observed about where AI coding tools fall short.
They can't decide what the code should do
This sounds obvious but it keeps surfacing in non-obvious ways. An AI can implement a feature from a specification. It can even find ambiguities and contradictions in that specification. What it cannot do is resolve those ambiguities — it can't decide which interpretation is right, because "right" depends on context it doesn't have.
I ran a recent spec review process where an AI reviewer found 89 genuine issues across a dozen passes. Every finding was real. But none of those findings told me what the answer was. Each one was a question that required someone who understood the product's intended behavior, the client's business model, and the technical constraints all at once. The AI surfaced the problem; I had to own the decision.
That gap doesn't shrink with better models. It's structural. The model doesn't know what the software is for in the way that a person who built it does.
They optimize for plausibility, not correctness
AI-generated code is usually plausible. It looks like what correct code looks like. It follows the patterns of the surrounding codebase, uses the right libraries, handles the common case. This is genuinely useful. It's also where things go wrong.
The failures I see most often are the ones that pass every check. The code compiles, the tests pass, the linter is happy. And then it ships behavior that doesn't match what the product should do, because the model optimized for a solution that fit the spec as written rather than the intent behind it.
The spec is always incomplete. Business requirements are always partially implicit. An experienced developer reads between the lines constantly — translating "users should be able to do X" into a set of edge cases the requirement didn't name, predicting what the person will actually do in the UI versus what the requirement assumed they'd do. That interpretive layer doesn't transfer to a prompt.
They can't tell you when not to build something
This is the one I think matters most, and it barely shows up in discussions about AI and software.
A significant part of good software work is recognizing when a feature request is actually a symptom of a different problem. When a client asks for a filter, sometimes what they actually need is a data cleanup. When someone asks for a notification, sometimes the underlying issue is that a workflow is confusing. When a bug gets reported, sometimes the right fix isn't in the code at all — it's in changing how the feature works.
AI tools have no standing to push back. They execute. You describe a feature, they implement it. You describe a bug, they fix it. The judgment about whether the thing should exist in its current form, whether there's a better framing, whether the effort is worth it — that stays entirely on the human side of the table.
I've turned down more features than I've built. That's not an accident; it's usually the right call. AI can't make that call.
They don't carry the context of the decisions that came before
Every codebase has decisions baked into it that aren't visible in the code. Why is this table structured this way? Why does this component do this unusual thing? Why was this seemingly obvious approach avoided? The answer is usually "because we tried it and it didn't work," or "because of a constraint from an external system," or "because the client changed direction three months ago and this was the compromise."
AI tools read the current state. They don't know the history. They'll confidently suggest the approach that was tried and rejected, reproduce the pattern that caused a production incident last year, or optimize for a metric that stopped being the right metric two iterations ago.
Explaining that context — and recognizing when new code is repeating a past mistake — requires someone who was there, or who took the time to understand why things are the way they are.
What this actually means
I'm not making an argument for human irreplaceability as reassurance. I'm making a more specific observation: the parts of software work that AI tools are bad at are not peripheral. They're the parts that determine whether the software is worth building, whether it solves the actual problem, and whether the decisions made along the way will hold up.
The mechanical work was never really the job. The job was always the judgment — reading a situation, synthesizing incomplete information, making calls that involve tradeoffs no tool can weigh for you. AI tools make the mechanical work faster and cheaper. That means the judgment layer is more exposed, not less. You can't hide bad decisions inside expensive implementation time anymore.
If anything, AI coding tools have made it clearer what the valuable part of software development actually is. It's the "why" behind every decision. That hasn't moved.