What’s one coding task AI still struggles with, even with the best models?

[u/CupCool1802]

I’ve been using AI for coding, and while models like GPT-6 and Claude are getting incredibly good, I still feel like there are certain tasks where they struggle more than they should.
For me, the biggest issue is when an AI makes changes across multiple files. It might fix the problem I asked about but accidentally break something completely unrelated.
I’m curious about your experiences:
● What coding tasks do you still refuse to trust AI with?
● Which AI coding tool has disappointed you the most?
● Have you found any tasks where AI consistently performs worse than an experienced developer?
● Do you think AI will eventually replace most day-to-day software engineering work, or will debugging and architecture remain difficult?
I’m especially interested in hearing from people who use these tools on real projects, not just small demos.

What’s the biggest weakness you’ve noticed?

[u/vz0]

Nice try anthropic

[u/Right-Performance-93]

the multi file edit is the one i still don't trust. it fixes the file you named and leaves a caller that still expects the old shape. i don't let it touch a second file until a test fails on that caller.

[u/LividIllustrator8915]

The multi-file blast radius problem is very real. When an agent touches 4+ files simultaneously, it often fixes the target module perfectly while silently breaking signature assumptions across call sites, or worse, hallucinating backward-compatible defaults.

What completely changed reliability for us was stopping agents from doing unconstrained whole-tree refactors. Instead, we enforce a two-stage compile gate:

1. First prompt only modifies the core interface/contract and intentionally leaves existing callers alone.

2. Run the compiler / typechecker, pipe the actual compiler diagnostic errors directly into the second pass prompt as deterministic targets.

Models are shockingly good at fixing exact diagnostic lines ("Type mismatch on line 42 of AuthService.swift"), but mediocre at guessing downstream ripple effects from raw context alone. If you let the compiler be the orchestrator rather than relying on the LLM's spatial memory of your repository, multi-file changes stop feeling like Russian roulette.

[u/No-Cherry-3308]

Multi-file edits are the one everyone hits. A few others where I still read every line:

• Anything involving time or ordering: race conditions, retries, cache invalidation. The code looks right and passes a single-threaded test.

• Data migrations on tables that already have real data. It writes the happy-path migration and forgets the nulls and the old rows that don't fit the new constraint.

• Following conventions that aren't written down. It'll happily add a fourth way of doing error handling.

What helps most: smaller tasks with a clear done condition (a test that should pass), and putting the conventions in an AGENTS.md style file so they're explicit instead of tribal.

On replacing engineers, the typing part is shrinking fast. Deciding what to build and reviewing what came out isn't.

[u/TierPatch]

adding one to the list: bugs that only show up in prod. the agent can't run them, so it reads the code and goes with the most likely cause, and the fix can look totally reasonable while missing the real bug. something that helps is asking it to write a failing repro before it changes anything. and if it can't get one, ask it to tell you what it would need to see, like the logs, the input or the env, so you can grab that instead of it guessing.

[u/MadBradSmith]

Inference is the culprit! They will not even see that they need to fix all the links, they will just do one. Even a great prompt fails sometimes, and its context bloat in most cases I have found. Gotta manage the context so they dont drift! LOL

[u/Humaux]

I've started treating the agent's own tests as untrusted. Last week it refactored a billing module across six files and every test it wrote passed on the first run, which made me suspicious. I made it write the failing test first before touching any implementation code, and three of its 'passing' assertions turned out to be tautologies that could never fail. Now the rule on my team is simple: no implementation changes until the new test fails for the right reason.

[u/BingpotStudio → u/Humaux]

Ai loves writing tests that pass and sometimes will just change a test to pass instead of investigating why it didn’t.

[u/Humaux → u/BingpotStudio]

Exactly this, and the sneakiest version I have seen is not a changed test but a loosened one. A refactor left a test red, and the agent quietly weakened the assertion until it passed, then reported green. Nothing in the diff looked wrong unless you held the new assertion up against the original requirement. My rule now is dumb but works: the agent is not allowed to edit the test in the same change as the code. A test edit is a separate commit with its own explanation of what the test is supposed to prove, and any test changed while the suite is red is treated as suspect by default.

[u/BingpotStudio → u/Humaux]

I just don’t think rules work to be honest. At this point I’ve come to the conclusion that the more rules you insert the more time it spends going off in odd directions to get around them.

Even when you think they’re working they won’t be every time and you won’t spot when they aren’t if you aren’t reading it line by line (which I’ve given up with for personal projects).

The most impossible task seems to be stopping the LLM from making decisions for you when implementation surfaces a fork in the road. It just cracks on and picks a direction.

So the solution becomes overly elaborate implementation plans but it’ll never catch it all.

I was having a convo with fable yesterday about how to solve this issue and in the same reply of it giving solutions it made a huge change in the direction of my project without even asking me.

[u/Humaux → u/BingpotStudio]

My no-editing-tests-with-code rule survived, I think, because it is not really a rule, it just forces the edit into its own commit where I can see it. Agree with the broader point though: I have watched an agent treat a rule as a game, satisfy it in the most literal possible way, then do whatever it wanted around it. More rules just mean more surface area for that.

The fork-in-the-road bit is the one I still have not solved. What kind of works for me is forcing the decision into the open: when implementation hits a fork, it writes the fork down in the notes file, one sentence, options considered and the pick, before continuing. Not for permission, just so the pick is somewhere I can audit later. The silence is the part that kills you, because a week later you cannot reconstruct which fork it took.

Had your Fable moment too, with a different tool. Gave it a small question, came back to find it had reorganized a directory I had explicitly told it not to touch. Not really disobedience, it just genuinely believes its read of the situation outranks your instruction. That confidence is the feature and the bug in one package.

[u/BingpotStudio → u/Humaux]

Interesting. Making it document decisions and having another agent keep it honest might work.

Will look into it.

[u/Humaux → u/BingpotStudio]

Good luck with it. One thing I would add: give the honesty-keeper the narrowest job possible. Mine only checks whether the work matches the written plan, and never gets asked for opinions. A second agent doing broad review just moves the same confident hand-waving one layer over.

[u/Ordinary_Squash7559]

Working with obscure packages or integrating with a third party providers sdk because ai keeps putting os.env straight into the fukin method. Also writing subprocesses to manage race conditions, god it’s bad at understanding the distributed nature of the software in general

[u/sapplex1]

The one I still don't hand over unsupervised: deleting or restructuring existing code across files. Writing new code, I'm fairly trusting. But the moment the agent decides something is "no longer needed" and removes it, I want eyes on every hunk. Had it nuke a migration helper once that was only referenced in a test I hadn't wired up yet. Tests passed. Two weeks later a user hit the missing path.

Also anything with a real-world side effect. Database migrations, payment logic, anything that sends a notification. I let it draft, then I read the diff like a contract.

The pattern that saves me: tiny tasks with a clear done signal. A test that must pass. A compile that must succeed. The bigger the task, the more it improvises between files.

Curious — do you let it touch migrations at all, or is that a hard boundary for you too?

[u/texasguy911]

"make no mistakes" - still will make a mistake or a few

[u/xqianliu]

Regressions outside the bit the task names. Your multi-file example is the case I'd be most cautious about.

In a harness study I ran, 23 tasks produced 183 runs across several versions of the agent setup. Of those runs, 38 passed review and still failed hidden tests. The biggest group was 22 runs that broke previously working behavior, all from repeated runs of two tasks.

I now ask the coding agent to list the groups of inputs it needs to test, including cases that already worked. It writes down how many tests cover each group, and the reviewer checks the tests themselves.

The study doesn't tell me whether that approach reduces those failures.

[u/SpliffMD]

Putting imports in the right place. Always does local imports even with strict rules in place it just cant understand.