equinumerous

That's a fair point, now there's just much more spaghetti, faster. But agree overall.

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).

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.

Couldn't agree more. I find a new bug in the VSCode Codex extension every day... quantity != quality!

I would be terrified of the server being breached and having my passwords/key material leaked.

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.

Wow! This is not production-ready at all. DynamoDB would be my main use case. I'll stick with DynamoDB local.

+1, would like to see. Even if it's not fully "ready for consumption", it's probably enough to reproduce the results.

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...

Sorry, </rant>.

Given the amount of spaghetti code I see frontier models generating on a daily basis, I cannot take seriously the idea that LLMs will write all the code, and somehow our systems will not degrade in performance, reliability, and maintainability. At least, not until we have really good understandings of how to maintain systems autonomously. All of our technologies were designed for humans, it may require a new set of technologies that are "LLM-proof". But I don't see this happening anytime soon.