I’d say I fall in the “AI skeptic but willing to use it” category. If LLMs can actually clean up after themselves it would actually be a game changer.
Essentially, there's a few ways LLMs write "bad" code that is different from how people write "bad" code.
We've got pretty good tooling to catch the ways people write bad code - it just happens to be much easier to do with static analysis (and is less noise prone).
The ways LLMs write bad code is typically 1) bad architecture - hard to detect in the ways that are really important, 2) unnecessary state and control flow (and decisions based on state), 3) bad / inadequate tests.
Methods to detect these problems have existed for ages, but they've never caught on because it's typically too difficult to tune them to have high signal / noise for humans, and AFAIK - no one else tried putting them all together and seeing how LLMs work with it.
LLMs are great at sorting through signal / noise -> so you can help surface potential issues with metrics that would be too noisy for humans, but seems to work pretty well for LLMs to find the source of architectural problems and design better solutions (from my experience - may be biased, I built the tooling to literally solve this problem for the main project I'm working on).
But it doesn't yet have a coherent UX unless you're me.
Hopefully, I'll iron that out over the next week and I'll update you.
Something like that.
Too many new nodes in the syntax tree, or a sub-tree that appears sufficiently similar to another sub-tree (for various definitions of similar), data-flow/side effects gets more convoluted, too many LOC, and so on.
But they're also writing some very strange code and some very strange tests. I don't know what good practices look like here, so when something looks strange to me I can't trust my own judgment, whether it's actually smelly or just a pattern I'm not used to yet.
--
On a side note, I recently had an agent implement a major architectural change. It turned out to have done it completely backwards, in a way that was pointless. (Improved nothing and actively made things worse.) However it had supplied generous tests for the new code, and of course all the tests passed...
So it had "proven the correctness" of something which was completely incorrect.
I later realized that even formal verification would not have prevented this. It would have just written a mathematical proof that the wrong code was correct.
The main problem is that pointing an LLM at a codebase and telling it to just "make it better" taps out pretty quickly. That is, not that there's zero juice to squeeze there, but there's not a ton. You can get a bit of improvement but it also rapidly starts changing things just to change things, which I'm not even going to complain about all that much because there's a sense in which it is simply doing as you asked.
So you still need human taste and direction. This will be especially true for something the size of that codebase where you can only hold small fractions of the actual code in the context window at once. Summaries only get you so far.
More broadly I've found that making code more elegant (e.g. by removing duplication) increases the cognitive load, because now you can't just read the code anymore but need to mentally "decompress" the higher level structures and indirection into the straight line code, the "code that actually runs."
LLMs, to a first approximation, already did as well as they could on the first pass. You can get a bit more out of them by asking them to just try harder, but not much. Whereas if you go in with specific changes they are pretty good at implementing them.
This especially matters because my personal style deviates from the common practices. This may also be why I can't get it to just happen by prompting for it. But if you walk it through it's perfectly capable of transforming the code into a better style, and it's still way faster than trying to write it from scratch.
The closest I could get to mine was by telling it to write like a Unix hacker. Hahaha
My experience has been the opposite. I prompt it and it generates something that mostly works, but steering it into something that would actually be maintainable is an exercise in futility. GPT-5.5 uses up my entire allocation of tokens in just reading the context docs and doing a single shot task.
> aven't found a way to prompt it with any number of skills or CLAUDE.mds or anything else to get it to do it the way I want on the first pass, but it's not that hard to just fix it afterwards.
I've yet to find a way to get an LLM to actually follow the instructions in CLAUDE/Agents.md It very quickly gets to a point where it forgets explicit instructions such as "run clang-format on all .h/.cpp files that you touch", and saying "our coding standards can be found at <link to Notion/Confluence>, please ensure all code adheres strictly to this standard" is ignored. I'd also say that the first pass of the code is very often not even close to how it _should_ be implemented so it's not just review and patch up, it's rearchitect + restructure 50% of the code.
> it also rapidly starts changing things just to change things,
Agreed. LLM's are (very good) text generators. They are good for generating code, and left to their own devices they will generate and generate and generate. Getting them to edit, simplify, and foresee future problems is something that people keep saying "use the latest model, it's amazing (despite saying that about the last 3 models" or "you just need to use <harness|framework>" or "your agents.md needs to contain XYZ" will solve.
I'll give you a hint: do you rely on people to do the right things, or do you have automated unit, integration, and e2e testing? Do you have linters? Do you have static analysis that automatically runs and will block when violated?
If you are verifying humans, why aren't you verifying LLMs?
I've seen others have this experience, too.
It would be interesting to sit us down next to each other for a day or two and compare how we do things, but I suspect much less than that won't reveal much of interest.
It is weird to me how often I have to remind the models about their skills or CLAUDE.md (or equivalent). Though I've sort of taken it as just another way I can impact the process, because sometimes I'm happy for them to forget a particular skill for a moment... particularly when I want it to just do a thing based on my prompt and it decides to invoke the "OK let's design this super carefully" skill. I've gotten a lot of use out of that one but I'm pretty comfortable having to explicitly invoke it.
I'm inclined to agree. If I had to write a hypothesis, I would say that is' likely that people like me underestimate the capability of the tools, and people who disagree likely underestimate the amount of manual steering and/or overlook the things that I find offensive!
[0] https://apple.stackexchange.com/questions/299505/ios-11-defa...