My take as someone one tier out of the groups seeing AI going vertical (so I only watch it go up on a high exponential): the escape of "AI can do only automatically verifiable work well" and "AI doesn't have judgement" is a mirage, that will shatter within the year. AI already has better judgement than many senior people in some tech domains, on top of better skills, and I see absolutely no reason to believe it won't be able to deliver end-to-end solutions with no human involvement, that are more correct, robust and efficient than they would be if humans were allowed to weigh in.
I also see no reason for that to not generalize into every field of human endeavor.
You don't see a monument to vertical because its construction is bottlenecked on the time it takes for companies to form around it and start executing. So it's few months out still.
This weekend I had some time with Opus 5.5 and GLM 5.3. I went over some findings in a library of Claude Mythos 5.1. These were minor, low-severity bug fixes and Mythos provided a PR to address them. Its PR was functionally correct. I still spent ~5 hours looping over them until I was really happy, even though a fully working PR already existed.
Some of the differences were:
- Mythos recommended salvaging damaged labels. I pushed back: data whose structure is broken shouldn’t be trusted
- My simpler more readable test caught a regression that Mythos’s more elaborate test missed
- Mythos allowed invalid values, citing real-world data that I could not reproduce, while I decided to follow the spec
- Mythos kept the old error types. I made every kind of malformed input raise the same error, and accepted a small, documented breaking change for anyone who relied on the old ones
Overall, I much preferred the final version of my PR to the initial draft Mythos provided. However, getting there involved quite a bit of time messing around with the code, as well as some back and forth with Opus (which was valuable).
This is a recent example that matches my overall experience working with current SOTA models (the ones mere mortals like me have access to).
TL;DR: I don’t think AI already has better judgment than (most) senior people. Obviously, that might change with future models. But that’s a hypothetical scenario. It might as well not change anytime soon.
Resonates exactly with my experience.
I'll add they also seem to make 'bad' judgement calls around which layer to implement something, often preferring downstream fixes/hacks/workarounds when upstream fixes would be better.
They also duplicate code lots rather than finding and reusing existing.
Both of these patterns lead to degradation and time wasting in complex code bases. Part of the behavioural adaptation I've made in using these tools is heading these off as much as possible at prompt-time
My prompts are often verbose to several paragraphs
> often preferring downstream fixes/hacks/workarounds when upstream fixes would be better.
It sometimes feels like the model is too lazy to do the actual reasonable fix and implements a _hacky_ fix downstream. And to be honest: I feel that!
This is true, but we also don’t know the long term architectural tradeoffs that are right for an LLM-maintained codebase.
For human-maintained code you manage duplication and locality of changes in the codebase because you want concepts to fit inside a human’s working memory. Keeping method bodies short is so they fit in one code window on the screen.
LLMs’ working memory works in very different ways; they see codebases not as windows of code but as blips of grep results. It might be that it’s easier for an LLM to just ensure five pieces of code are all modified in sync with one another than to safely implement a DRY refactoring.
It also differes between human-maintained codebases, too.
For some greenfield project I'm developing, 99% of the time, fixing architecture and going as far upstream as possible is the right choice.
For the codebase I'm working on professionally, doing the hacky thing is the right choice most of the time, because there's enough people changing it frequently enough, with little coordination, that architecture is fluid, and hacks only survive if they work well enough (otherwise someone will come around and fix it).
That was true pre-LLM, too, and is simply a function of scale. And ironically, it's not laziness but pragmatism - at this scale, you just can't assume code you worked on last month will look today like anything you remember. Code review process + extensive linting and testing and AI-assisted analysis filters out most of the junior-style mistakes and flag ugly hacks, so you get a moment to pause and double-check, but if it's good enough, you merge it in and go do another useful thing.
This is how you end up with a big ball of mud [1]. If the argument is that LLMs are just as capable as humans at building big balls of mud, then I'm not sure it's much of an endorsement of their use.
[1] https://www.laputan.org/mud/
I've thought about that and I agree. One thing I'm wondering though is, are we really ready to go all-in on making a codebase that is effectively unmaintainable by humans?
> It might be that it’s easier for an LLM to just ensure five pieces of code are all modified in sync with one another than to safely implement a DRY refactoring.
One thing they are definitely not doing is making decisions based on how easily and quickly they will be able to maintain those decisions in the future, or considering that duplicating code rather than creating abstractions will be easier for them to keep track of because of their "very different working memories."
They're just doing a bad job. It's not some sophisticated work avoidance/efficiency in defiance of feeble human abilities to maintain what they have written. 1) LLMs are not lazy, and 2) if writing maintainable code is part of the remit, they're consistently failing. You can't convince me simultaneously that LLMs can handle everything, and also that they can't figure out how to factor their code in a way that would be a pleasure to review.
It simply doesn't make sense. If they're so good, they can make it easy to read and well-factored. If they can't make it easy to read and well-factored, they ain't so good. Saying that they're so good that the code has to be this bad is a very weird rationalization. One that apparently involves speculating about their internal states in a strange way that sounds a lot like the projection of fantasies.
That mostly matches my experience, but there is a caveat that you're not considering.
You don't know what good judgement calls the AI made along the way. Or rather you do but not in detail because those are the part you looked at that said, okay, this is good code and I should ignore it. Your judgment is biased because you're looking at the bad parts and not the good parts.
I think we are already at the point where code quality doesn't matter anymore because no human can keep up with the output. I don't like the code that these AI agents produce, but what do I care when I no longer have to read the code? As long as other AI agents can continue to understand it, it's good enough.
do you really want AI to make life and death decisions? do you really want that power concentrated in the hands of the few who own the AI systems?
Yes! When ever I read comments like this it always makes me think the poster has led a much more charmed life than I have. Every institution we have that makes major decisions is an impenetrable mass of bureaucracy that takes forever. Give me the quick automated decision every time
> Give me the quick automated decision every time
Don't we already have this experience and isn't it called "the Google support experience"? And I don't know about you, but I don't like it.
Last week I was dealing with a bug where we were triggering some behavior in a service in all requests when actually we really shouldn't be triggering this behavior for one of our callers. It just so happens that this caller sends a unique flag to the service.
The suggestion from frontier models was to have our service check for this flag and use that to decide whether to trigger this behavior, even though the flag had nothing to do with this behavior semantically. I'd expect this from a junior engineer. Correct now, but almost surely to cause a bug in the future as the codebase evolves.
These tools are incredible and can achieve things I would never have imagined five years ago. I have yet to see their judgement exceed mine.
>AI already has better judgement than many senior people in some tech domains, on top of better skills
It has better judgement in math and coding, which have infinitely generatable training data; if you ask it a domain-specific question about something like sales or marketing, its answer is often horrendous.
> AI already has better judgement than many senior people in some tech domains
How would you quantify this?
How do you quantify judgement?
My proxy metric is observing the growing ratio of "AI suggested, I haven't even thought of that" to "AI nonsense I had to correct" (where it didn't turn out later AI was actually right).
“I hadn’t even thought of that” = tech debt
> "AI doesn't have judgement" is a mirage, that will shatter within the year. AI already has better judgement than many senior people in some tech domains
No offense, but if you noticed it has better judgment than you, consider that you might not be a "senior people in a tech domain"
Well my job title says otherwise.