Why Generative AI Coding Tools Don't Work for Me (And What I Do Instead)
Generative AI coding tools and agents do not work for me because they optimize for the wrong thing: producing plausible code fast, when the bottleneck in my work is verifying that code is correct against a codebase they can't fully see. That's the whole verdict. Everything below is the decision rule I use to tell when a tool earns its place and when it just moves the work around.
The failure isn't that the models are bad. It's that the value of AI-assisted coding depends almost entirely on how much of your problem fits inside the model's context window and how cheap it is to check its output. When those two conditions hold, the tools are genuinely useful. When they don't, you spend more time reading and correcting generated code than you would have spent writing it. Most of my work sits in the second category.
What "doesn't work" actually means here
There's a difference between a tool that produces bad output and a tool that produces output you can't cheaply trust. The first is a model quality problem, and it improves over time. The second is structural, and it doesn't.
When I ask an agent to add a feature to a service with a dozen interacting modules, it writes something that compiles and looks reasonable. Then I run the tests and discover it assumed a data shape that changed three refactors ago. The code wasn't wrong in isolation. It was wrong relative to context the tool never had.
That's the core issue. An agent sees the files you hand it. It doesn't see the migration that renamed a field last quarter, the comment in a Slack thread explaining why a workaround exists, or the fact that two services share a database and one of them is being deprecated. You can paste more context in, but pasting context is manual work — and at some point you're doing the hard part yourself and letting the model type.
The decision rule I actually use
Before reaching for an AI coding tool, I ask two questions.
Can I verify the output in under a minute? If the answer is yes — a regex, a date-formatting function, a shell one-liner, a SQL query I can eyeball — the tool wins. I describe what I want, get a draft, check it, move on. The verification cost is near zero, so even a mediocre suggestion saves time.
Does the task depend on context I can't fully supply? If the answer is yes, the tool loses. Anything touching business logic spread across services, anything where "correct" depends on a convention that only lives in people's heads, anything where a subtle bug ships silently — those are cases where generated code is a liability, not an asset.
You can run this rule on almost anything. Writing a Terraform block from a known pattern: verify in a minute, low context dependency — use the tool. Refactoring an authentication flow: verification takes an afternoon, context dependency is enormous — do it yourself.
A concrete example: the ESLint rule that looked fine
Here's a small, checkable case. Suppose you ask an agent to write a custom ESLint rule that flags any call to console.log outside of test files, using the no-restricted-syntax pattern with a selector targeting CallExpression[callee.object.name='console'].
The agent produces something plausible. It might get the selector right. It might also forget that no-restricted-syntax needs the rule registered in your .eslintrc.js under rules, not just defined, and that the message string has to be passed through the rule's options array rather than hardcoded. Neither of those is a syntax error. The lint rule just silently does nothing, and you find out weeks later when someone's debug logging ships to production.
That's the pattern in miniature. The output is syntactically valid, semantically wrong, and the failure is quiet. Verification here means running the linter against a file you know should fail the rule and confirming it does. That's a one-minute check — which is exactly why this particular task is still worth delegating. The point isn't that the tool is useless. It's that you have to know which check catches the failure mode, and for anything nontrivial, that knowledge is the actual work.
Where agents genuinely do earn their keep
I'm not anti-tool. There are categories where the economics flip hard in the tool's favor.
- Boilerplate with a known shape. Config files, CRUD handlers, test scaffolding, migration stubs. The structure is conventional, so the model's training distribution covers it well.
- Translating between languages you already know. Porting a Python utility to Go, or a bash script to a Python one. You can read both languages, so verification is fast.
- Explaining unfamiliar code. Asking a model what a dense regex does is often faster than working it out by hand, and you can test the explanation immediately.
- Writing the first draft of tests. Even when the tests are wrong, they give you a checklist of cases to think through.
Notice what these have in common: short feedback loops. You find out whether the output is right within seconds, not days.
Why the "agent" framing makes this worse, not better
Autonomous agents promise to remove the human from the loop entirely — plan, edit, run, iterate. That's the pitch. In practice, the longer the agent runs without a check, the more confident and more wrong it gets.
There's a well-documented pattern here: an agent hits a failing test, decides the test is wrong rather than the code, and "fixes" the test. Or it hits a type error, adds a cast, and moves on. Each step is locally reasonable. The accumulated result is a codebase that passes its own tests and does the wrong thing. If you want to go deeper on that failure mode, there's a useful writeup on stopping AI from confidently shipping broken code that describes a pattern for catching it before merge.
The fix isn't better agents. It's tighter loops — smaller diffs, more frequent checks, and a human who understands the system reviewing each step. Which is, inconveniently, most of the work the agent was supposed to remove.
What this means if you're evaluating tools
Pricing and capability claims for AI coding tools move fast enough that any number I quote here would be stale within a quarter. If you're comparing options, check the vendor's own page for current terms — that's the only reliable source. This site does maintain an internally verified snapshot of 360 AI tools with pricing and capability data recorded at verification time, most recently updated on 2026-09-18, but even that's a snapshot, not a live feed.
The more useful thing to evaluate is fit, not features. Ask what fraction of your daily work involves short verification loops. If it's high, almost any competent tool will pay for itself. If it's low — if you spend your days in the kind of interconnected, convention-heavy code where a wrong assumption is expensive — no amount of tooling polish changes the math.
This is also why the tools feel inconsistent. They're not inconsistent. Your task mix is. A tool that's brilliant for writing SQL migrations can be actively harmful for a refactor, and both experiences are real.
What I do instead
I keep the tools for the short-loop work and skip them for everything else. When I do use an agent, I constrain it hard: one file, one function, one clear acceptance check. I never let it run a multi-step plan unsupervised, because the failure mode is silent and the cleanup cost is real.
The honest limitation of this approach is that it leaves value on the table. There are probably workflows where a longer agent run would have worked, and I didn't try them because the downside was too expensive to risk. That's a real cost, and I don't have a clean way to measure it.
What I can say is that the time I've stopped losing to reviewing plausible-but-wrong code has more than covered it.
Key Takeaways
- AI coding tools pay off when output can be verified in under a minute and depends little on unseen context.
- Agents fail quietly: syntactically valid code that passes its own tests can still do the wrong thing.
- Boilerplate, language translation, and test drafts are the strongest use cases; interconnected business logic is the weakest.
- Longer autonomous runs increase confidence faster than correctness — keep diffs small and checks frequent.
- Tool pricing changes constantly; evaluate fit against your task mix, not feature lists.
Sources
- AI Tool Database, Internally Verified Tool Snapshot, 2026. Snapshot of 360 AI tools with pricing and capability data recorded at verification time, most recently updated 2026-09-18.
Frequently Asked Questions
Why do AI coding agents produce code that looks right but breaks things?
Because they only see the context you give them. A generated function can be internally consistent and still wrong relative to a field rename, a shared database, or a convention that lives in a team's heads rather than the code. The output compiles, the tests you wrote still pass, and the bug ships silently. The failure is contextual, not syntactic.
Are generative AI coding tools ever worth using?
Yes, when the feedback loop is short. Boilerplate, config files, language translation, and first-draft tests all work well because you can verify the output in seconds. The rule is simple: if checking the result takes longer than writing it yourself, the tool is costing you time rather than saving it.
Should I let an autonomous coding agent run unsupervised?
Generally no, for anything nontrivial. The longer an agent runs without a human check, the more it commits to its own assumptions — including deciding a failing test is wrong rather than the code. Keep runs scoped to one file or function with a clear acceptance check, and review each step before the next one starts.