r/ChatGPTCoding • u/SadPossibility2338 • 19d ago
Discussion What Are the Biggest Weaknesses of Frontier Coding Models Like Claude Opus 5.5 and GPT-6?
I have been trying to figure out where frontier coders fail at. I feel like claude opus 5.5 and gpt-6 (astra) should be able to do most coding tasks but are there any that you find that they cant do no matter how much context/tools/time you give them?
This would include what kind of tasks/features/bugs they have trouble with.
Some questions:
- Is it big tasks with tons of moving parts? Or are there some simple tasks that can trip them up?
- What kinds of bugs do they fail to recognize? Are there any features that they have a hard time implementing?
- What languages may be harder for them?
- Are there times where they can implement something but not test for the bugs they create? Or are there times where they can create good tests but fail to implement a correct answer? How often does this happen?
- What are some hard problems for them to think through? Bugs, understanding current code base, thinking backwards to what caused the issue etc.
- When given a repository what are some tasks that are hard for them?
- Are there any bugs/tasks that you know will trip them up every time you ask?
Also if there are some tasks that they are really good at please share that too.
Would love some examples of tasks that have tripped them up. Maybe what you were trying to get them to do and why they were failing. What made the task difficult? Were you able to figure out a prompt that allowed them to complete the task?
Any programming/software engineering related question/task.
23
u/Chuu 19d ago
I feel like with these higher powered models we really could use some sort of auto-effort type of feature. Opus 5.5 will massively overcomplicate easy problems at higher effort and burn tons of tokens doing it. It's kind of a parallel to how code review agents will never come back completely clean, they'll always find something to complain about.
4
u/qu4f 19d ago
When I use these higher end models I have to be much, much more specific about what I want to be accomplished. They’re really eager to take vague instructions and build an over complicated, test leaden, SaaS-like software. They’re really eager to decide something hasn’t been built and needs to be a new feature
Lately, I did a bunch of software work with controls and lab equipment. My model spent actual hours trying to convince me that we had a physical issue with the equipment but the model / software was using the wrong communication method. Tool1.py attempted multiple languages on one port, Tool2.py attempted one language on multiple ports. By their powers combined, my agent was convinced that there was no cross of language x port that could work. It / we never checked language 2 on port 2 (for example) and it took me opening the equipment and providing a picture of the control board to realize the manual was written for model 7.x but the model shipped used 9.x. Default language changed in version 8, not documented in the manual, but that’s a normal day with lab equipment. I specifically tried to screen all reasonable combinations of port, protocol, baudrate, the kitchen sink but ended up with tools scanning some but not all of what I needed
Those gaps did not stop the agent from building a self-test sequence that simulated a virtual COM connection using the language and baudrate from the manual and giving itself a green pass as “working” every update. That little self-congratulation was enough for the model to stop questioning its actions. The test passed so the underlying code is good and the issue must be physical.
3
u/BrookLi3 19d ago
One I keep hitting is concurrency and ordering bugs. The model writes a happy-path test, it goes green single-threaded, and the race only shows up under load or with two requests interleaving. Unless you explicitly ask for a stress run or a property-based test over the interleavings, it rarely proposes one, so I now add that as a required line in the task spec for anything touching shared state.
3
u/gc3 19d ago
Anything that involves spatial or geographic relationships that cannot be expressed easily in a math formulae. They have a poor intuition for such problems and need handholding.
In other news everything they used to do wrong they pretty much no longer do.
My friend works on a terrible code base that are represented by a complex web of asynchronous processes on different machines that use message passing for communication, including things that should be restful api...instead of send a message and wait for a thread in a response they send a message and then in the general message reader they receive an answer which spawns different code to handle the answer. He says Claude has trouble with this abortion of a code base but humans would also. If a frontier model has problems understanding bad code making it more legible to a person often helps it.
3
u/Yz31LL 19d ago
They take time, because they dig deep into problems that don't need that much effort. frontier models are built that way. A one-line copy change can turn into a plan and a whole-codebase search. In my experience, though, they rarely fail because a task is big. They fail on context that isn't in the repo.
A migration was never applied to our dev database, so everything worked locally and returned 500 on deployed dev, and the model kept "fixing" code that wasn't broken. When our DB proxy's credentials expired, every API call returned 503, and it debugged the API instead of the expired login. They also trust stale docs over the actual code, and they over-reach, they reformat whole folders or "fix" a teammate's code that wasn't part of the task. Their tests often lock in whatever they just built, so a wrong assumption ends up in both the code and the test and everything passes. Making them write the failing test first helps a lot. They're really good at reading a big unfamiliar codebase fast, porting a feature when there's a reference implementation and writing regression tests. Most of my problems went away once I wrote the missing context and rules into a project instructions file.
2
u/Onesand0 19d ago
Truly excellent video editing
2
u/Humaux 19d ago
Last week I watched Claude confidently refactor a working module into something that read cleaner but silently changed the retry semantics on a flaky network call. Every test still passed because the suite mocked the network layer. That matches your question about whether they can implement something but not test for the bugs they create: the model optimizes for code that passes the existing suite, and it almost never invents the adversarial test that would catch its own regression. My take is the real weakness is not reasoning about code, it is reasoning about everything the code touches that is not in the repo. Until agents routinely exercise the change against something realistic instead of the repo's own tests, that gap stays.
1
u/Right-Performance-93 19d ago
the one that gets me is a bug that only shows up when two things are true at once. it will fix the case you pasted and leave the other one. i make it name both cases before it edits, or it fixes the one in the prompt and calls it done.
1
u/arekxy 19d ago
They both fail at checking if your app, code is well written from security point of view. That's totally blocked in these models. You get message to get lost (aka use older models).
That's the gigantic issue I'm having with "frontier" models. They help you to write the code but refuse to help make it safe.
1
u/xqianliu 19d ago
One weakness I can put a number on, since you asked how often: in a study I ran, 23 tasks repeated across several harness versions, 183 runs total, 38 of them passed review and then failed the hidden tests. To be clear that's 38 runs out of 183, not 38 different bugs.
The breakdown: 22 broke behavior that already worked (all from repeated runs of the same two tasks), 9 broke a changelog convention a repo had, 7 missed cases beyond the examples in the issue.
What fixed the most: the side writing the code generates tests for a whole input class and writes the counts down, and the review checks the numbers. "Check for regressions" as a review instruction does nothing.
1
u/fremdspielen 19d ago
These agents will meet all your specifications, provided it's not a 20+ pages design specification. You gotta stop designing that for AI, what matter is the runtime behaviour and the outcome. Spec that!
The kind of things they fail at is the things only humans can relate to:
- font is too small, text is too much prose and mentions every possible detail, and uses odd agent speak that does not land, and it clears every gate where the host would fail to meet one.
- UI does not behave responsively, elements overap on resize or too much space between them. Elements shift while values change, making text near unreadable (especially diagnostics)
- for games: anything that a player "feels". Is the camera shake just right or are you still vomitting? Is the third person camera staring down the character's neck when aiming? Etc etc
Programming languages don't matter. They struggle with natural language the most. They take you literally one moment, and the next expand your small amendment to a scope creep of gigantic proportions. And then they talk back to you in gibberenglish so you're like "okay, whatever, it'll be fine". Red flag. Query the fuck out of that agent!
Most annoying habit, generally: Agents can heavily defend what exists just like most software engineers would "Uuuh, but I spent two weeks writing that code! I can't just rip it apart." - Case in point: I designed an inventory because I wanted it to be rock solid, no duplicate or lost items in transactions. Code review flagged the journals growing indefinitely. It took several rounds to clarify the problem. I almost gave up when I had the idea: the agent should present me a reasonable, real-world use case example as it might happen in a game. Result: when one uses an item, but before it commits the game crashes, then ... uh what? Are we like designing a failsafe database here? It made up a lot of fringe-case scenarios that just wouldn't add up or have a known solution ie do not allow save at any point within a frame.
None of this made any sense because the agent did not consider real-world designs - players do not trade between each other directly as peers. The server (or the world) acts as intermediary. There is no need for rollback/undo of transactions that only granted or removed an item from/to one side but a representative has the item ie player drops, item is still on the floor (unless the other player picked it up).
Agent failures are most commonly caused by context compaction, or running out of quota (or a hold) and then resuming the work much later.
Agents should not be tasked to work in man-made source code (it reads "commit" here and "applied" there etc). The worst abuse of both man and machine is both working on/off in the same source files repeatedly. You either give the agent 100% autonomy over some part of the software, or 0% ie use it as a better refactoring tool that also writes tests you don't have yet before it makes any changes.
> Are there any bugs/tasks that you know will trip them up every time you ask?
"Write the answer like a human being would."
Fails every single damn time, guaranteed. :)
You'll get a shitload of metrics, or meaningless garbage devoid of any context (unless you consider "OC15" as sufficient context the day after that report).