I don't think it's usually about what AI "did really badly on" at this point. It's more about whether the overheads of adding all the guard rails and then reviewing and correcting all the output end up costing at least a similar amount to just writing the code yourself.
For a junior developer, I'd say frontier models passed their standard some time ago. Today's LLMs routinely write code at the level of a competent junior-mid but with the advantage of an inhumanly broad knowledge base.
For a good senior, I'm much less convinced. The frontier models are hit-and-miss when it comes to writing good test suites, which matters a lot when they rely on tests so heavily to reach acceptable quality. IME, they are still mostly miss when it comes to the business insight that seniors will take into account and design/architecture decisions that keep the code manageable as it evolves. While they have become much better at recognising existing patterns in the code, and I would say they follow them reasonably well the majority of the time now, there are still bizarre anomalies that creep in, and they aren't very good at extending those patterns when necessary.
I think AI advocates also tend to underestimate just how much time it takes to properly review what they are doing. Take a half-day Claude session to implement some new feature. It might take half an hour to give it the initial brief and then review its plan. Make a few edits and it'll propose a new plan that is also long and detailed and has no edit markings to show what it changed so you have to review the whole thing, carefully and in detail, again to pick up the minor changes it also made for no obvious reason. Then you let it start doing its thing. You can't really leave it unattended for long because it'll stop to ask questions. Some of those questions might be whether it can run a screenful of ad-hoc Bash script to make some edits to your source files, because for some reason it decided not to show the actual edits as it usually would, so now you have to figure out what all the sed incantations are actually going to do while looking at those files in another editor or just trust it and then review all the changes properly later anyway. Sometimes it decides to change its plan mid-flight, but not always in a good way, and if you interrupt it to apply corrections or redirect, you break the neat plan flow it was in. Then you get to the end and you can finally see how everything it has done fits together, and you still need to review everything with the same care as you would with a junior developer's code and probably apply a few fixes where it's come up with weird names or not quite followed a pattern or imagined some instructions that were never there and made other changes in other parts of the system that should be out of scope.
If you read to the end of that last paragraph, you know how I typically feel at the end of a half day working with an agentic UI. And the thing is, I do those sessions as experiments fairly often to keep up with progress, but a lot of what I do is still written by hand, which gives me simple, objective data to compare the two ways of working and see whether the AI tools are really making me more productive once you take everything into account.
Currently, based on objective data comparing similar fully completed development tasks like for like, I still outperform agentic workflows using frontier models by about 25-50% on average, and I don't have to pay anyone extra fees to do that, and subjectively I also find it more engaging to work that way. So I don't really buy the hype about AIs making us all orders of magnitude more productive unless you're happy to YOLO everything forever and take the much-discussed risks that comes with.
Personally, I think the optimum use of LLMs right now is probably not to use them for the whole coding workflow like that or rely on agentic tools, but to use them for tasks like answering quick questions about the existing code, doing research like a fancy search engine, writing a first draft of some boilerplate, and writing quick and dirty throwaway code for experiments, one-shot tools and the like, where you don't really care about the quality as long as it gets the job done and you will see immediately if it has in fact got the job done. For these things, the LLM can read and type faster than me, and that's useful.
