How do you avoid the spaghetti code that (in my experience) most AI models spit out? Sure you can steer it, ask it to make it better, etc... but it's easier to me to be in the driver's seat. Doesn't mean AI isn't useful, but whenever AI designs a feature end-to-end, everything is tightly-coupled, the wrong abstractions are picked, and fundamentally the code is not optimized for human understanding. I don't really understand how people can tolerate this kind of code (assuming they read it, which I think they do not). Just take the Claude Code CLI as an example - is there anyone in the world that knows how that spaghetti machine works?
I agree that AI is very useful in reviewing PRs and searching for bugs. It's definitely a game-changer there. But a human still needs to understand the code and take responsibility for it.
>Claude Code CLI ... is there anyone in the world that knows how that spaghetti machine works
Having a very active, and happy user base.
Now this a simplistic view, and I think even heavily AI first dev teams still glance at the diff to make sure things aren't going too awry or ask questions. But the concept "spaghetti code" and "optimized for human understanding" are assumptions being revisited entirely in 2026.
I am not trying to get into a flame war, but I have seen a lot of complaints about Claude Code, not to mention their huge backlog of bug reports (https://github.com/anthropics/claude-code/issues) on GitHub. Just because they have lowered the bar for software quality and people have accepted it, does not mean that they are delivering quality software. I know at the very least we agree that these ideas are being re-explored in 2026, but I don't see evidence that it's a positive improvement for software development/quality. How many sites or services does one use on a daily basis that are just broken? Is that really the best our industry can aspire to?
EDIT: also, from the software engineer perspective, it is an order of magnitude more tedious to maintain software projects that lack quality, consistency, or standards. If I could measure the effect of AI vibe-coding in terms of personal pain, I would say it makes software development more painful when code is not well thought-out. There is a way to use AI responsibly, but I see more often people taking shortcuts and throwing "engineering" out the window. It's possible to ship quality with AI, but that's not the path of least resistance.
> but I have seen a lot of complaints about Claude Code,
This may be a case of "you'll see more posts from people who are complaining than from the people who are busy using it." As a semi-relevant comparison: go on Reddit/Twitter any time there's a Fortnite update and you'll see and endless sea of complaints, yet the game is still being played by ridiculous numbers of people.
> How do you avoid the spaghetti code that (in my experience) most AI models spit out?
That's the neat thing—you don't.
Frontier models, especially Opus 5.5, have vastly stepped up their game in terms of code quality. Furthermore, the sheer volume and speed of code they produce has meant that humans just don't have time to read and review the code even if it were the most well-written code in the world. The frontier is now structuring your loops, graphs, and evals in such a way that agents with a fresh context review the agent-produced code looking for bugs and errors. If humans review anything, it's an agent-produced summary of the code changes.
Business people now expect speed of delivery that humans can't match. Humans are now the bottleneck; agents will step up to replace them.
I'm sorry, as someone that uses agents daily, I just don't buy it. When the whole thing collapses into a pile of junk, someone is on the hook, and customers are unhappy. I don't find this approach to engineering to be a sane way of going about things (and if I'm proven wrong, then I would expect the whole software engineering process to become fully automated and repeatable, which has not yet happened).
That's the brilliant part! Someone is on the hook but it's not going to be upper management. When it all goes tits up, you just fire your existing dev teams, hire in "AI-native" devs who better know how to work with these tools (i.e., kids fresh out of college who only graduated because Claude did all their homework) and try again! By the time this changeover occurs, the models will be able to handle most software engineering tasks on their own. (I know, it was "in six months" since three years ago. But it might actually happen this time; that step function over the summer ain't nuttin' to fuck wit' and Claude and Codex can now make sensible design/architecture decisions one-shotting a medium-sized component.)
It all starts making sense once you realize the most important thing in software development: MONEY. Oh, and the fact that management hates programmers.
You should see the spaghetti code that humans working 70 hour weeks for months on end to meet a launch date have pushed out.
You can be in the driver seat while delegating implementation to agents. You can use agents to generate documentation and refactor architectures. You can ask an agent to explain a feature and then work with it to plan how to extend it.
You don’t have to type the code to be the architect.
Well the passwords are GPG encrypted, so they'd need your private key too, not just breach the server.
What sites you have accounts on is visible though.
If the benchmarks show better performance, but a consensus of experienced software engineers establishes that the model is worse on coding performance... well, the benchmarks don't mean much, do they? It seems like we need much more comprehensive and better benchmarks. And of course, I don't think benchmarks yet capture the "human" factor - does a human think a bit of code is logical and maintainable? I often find that these models produce a bit of code, but it is much more convoluted than it needs to be. It makes perfect sense given that these things are code generators, that they generate a lot of code. But quantity of code does not mean code quality, and code quality tends to matter when you read code much more than you write it.
Data-Oriented Programming in Java by Chris Kiehl. So far it's one of the best books I've read about taming complexity in software, ensuring integrity of state, and writing correct software. It's applicable to languages other than Java, though Java is a good fit for the text given its object-orientation.
Funny fact, DynamoDB local fails about 100 of my conformance tests. Mainly around error message formatting and text. Just be careful about parsing those.
That's a really impressive result. There are all kinds of small tasks like this I use an LLM for, but theoretically if you broke all the sub-use cases into local-only models, and had something lightweight that routed to the right model, you could have faster and cheaper workflows. E.g. something trained on the linux man pages for common commands, since it's usually quicker to ask an LLM for a specific command with flags than to consult the man pages.
I believe it's only a strategy that works in the short-term. If you ever expect the software to be stable, quality, and human-maintainable, you're going to need a good test suite (hopefully not AI-generated) to get away with that little ownership of the code. That said, this is great for prototypes or throw-away software, provided you don't mind being entirely reliant on an LLM for maintaining the code (speaking from experience, a human usually does not want to touch a fully vibe-coded application that they've never reviewed).
If I'm wrong about this, I would expect to see a new field of LLM-automated software engineering with at least the same level of rigor and quality as the existing human-led processes, and in the absence of this, we're just further degrading software quality for dubious gains (is it to go "faster", is it because we are being compelled to by leadership, is it out of fear of being left behind by competitors?). I can't imagine any other engineering discipline as critical as software being "vibed" - if I had learned that the local bridge had no human inspection, simply was "vibe-checked", it might be a good bridge, but I'm not going to be the one to test it.
I couldn't agree more. We really need more engineers to be vocal about how stupid these ideas are. "How about we throw out 30+ years of software engineering literature so we can 'move faster'?" What if the customers on the other end don't want new features, they just want software stability? If SQLite came out with a new LLM-written feature a week, would it be a better library? If you know what to build, writing software right the first time pays for itself over time. LLMs are still great, but more for rapid prototyping, researching, log diving, one-off scripts...
I agree that AI is very useful in reviewing PRs and searching for bugs. It's definitely a game-changer there. But a human still needs to understand the code and take responsibility for it.
reply