I see it like someone walking through a minefield safely after not noticing the signs.
“What do you mean it’s a minefield? MY legs didn’t get blown off.”
No doubt code quality increased substantially, but I've been wrestling overengineering for a long time, with both GPT/Claude - they will take any small chance to write excess code/documentation/specifications, anything - heck, even prompts sent to subagents are a wall of text.
Explicitly requiring simple solutions works for simple problems, but for more complex ones, complexity quickly creeps in. I even ask the alternative model to challenge the complexity of solution, but doesn't work really well.
There is a perverse incentive for AI companies to train models to be verbose, as it increases the tokens consumption.
Contributors to this project must follow YAGNI, DRY, KISS, and principle of least astonishment, both from user-visible surfaces, and backend design.
Code is a liability. Do not build anything not expressly asked for.
You can also tell it what kinds of tests to write. (Assuming you're still interested in details of the codebase).
> "AI writes overly complex ccode" - only if you let it. A "do not overengineer it" or "Pareto, 80% result with 20% of effort" go a long long way.
Also, if it wrote a complex solution, tell it write a simple one instead.
In my experience, good AI adjusts pretty well to an existing code base, and produces roughly similar abstractions to the ones it finds.
This is a pretty severe issue I have. Give it a bad codebase, and it'll happily carry on the awful, ignore failed unit tests, omit documentation, not fixing existing problems just to, and I quote, "follow precedence".
It seems these models have been (probably for the better) trained to not rock the boat too much, and keep the work to a minimum. I think we're going to end up get stuck in de-risked "just make it work" sort of mode in the near term, with all the "less good" code that's was generated relative to newer/future models. At some point, these models will need to be trained to just rewrite bad code, without excessive, often forgotten, instructions to do so.
Staying inline with the codebase is the right thing to do. It's down to you to tell it when it's time to re-engineer.
> without excessive, and very often forgotten, instructions to do so.
It forgets, within long sessions. I'm still seeing Opus 5.5 implement workarounds for bugs it created within its own session, even with explicit, and plentiful, instructions and global memories that it's time to re-engineer.
But to your point, yes, multiple rounds are required. My point is that this is going to eventually hold development back.
No, AI is still absolutely terrible at design.
It doesn't matter if they are good at implementation.
If you ask for a car and they build you an awesome surfboard, it's basically worthless.
Sure, if you're building rapid prototypes where it doesn't matter if anything is coherent or works, AI crushes it.
If it's a 99% derivative small greenfield project, AI crushes it.
For anything real, it is still a painfully awful experience to extract juice from the squeeze.
We've been hearing this claim for years. It wasn't true then, it isn't true now.
Sure I don't have a deep understanding of the Linux kernel, but some human(s) somewhere do(es). If a whole company switches to LLM development for their (closed source) product, nobody has a deep understanding of the code anymore. That could become an issue real quick, if AI doesn't do what you want anymore.
(Not saying AI is gonna go sentient, just saying taking AI for granted is a problem in and of itself)
If I take ownership of the Linux kernel and refactor it into Rust with a "thorough test" using Astra/Fable, will you use it?
Even if AI did indeed make worse architectural decisions, that just means we have to be more on top of it in preventing them to make those decisions.
We've already managed to successfully convince everyone that you should tell AI to always produce tests for your changes. But we were ALWAYS meant to ALWAYS have test. Why did we ever not do that? Oh right, lack of time, different priorities, etc. etc. AI gives us the time back so now we're no longer allowing excuses. Weird how the standards only change with a complete lack of care and naive trust of AI?
The article also mentions that AI produces code that doesn't scale. Well? Why aren't you running a profiler and looking for places to optimize then? You were ALWAYS meant to do that. You were ALWAYS meant to ~prove~ the scalability of your architecture. This was ALWAYS a responsibility of engineers. Why are you just trusting it to do whatever instead of putting in the work doing all those things and improving? Where the hell did your responsibilities go, and why are we having a discussion on AI instead of on the fact the human is avoiding their job-description responsibilities?
I am an engineer. It is my job to produce good code. And I am proud of that, and of what that means. And right now, that means looking at AI doing a half baked job, and either baking the other half myself, or telling the AI how to.
Knock knock. That's all the shitty engineering of the last decades. It isn't dead. It's just called vibecoding now. Don't blame the AI. Unmask it, and blame shitty engineers.
uhm.. what? The reason I don't understand how the kernel works is because I'm not working on it. The people working on it understand how it works. What kind of logic is this?
and that is a means to which end, again? I very much enjoyed the engineering bits of programming: having a deep mental model of how the software works, understanding the architecture, the data structures, the algorithms.
It absolutely does. You lose understanding of the code, but what kind of understanding do you actually gain in turn? AFAICT it is purely a tradeoff between velocity and understanding.
It's not a mantra, it's the reality of the business: if I must bear responsibility of the code facing a customer, then I have to understand the code. The AI can be a wonderful tool, but people are still calling me to fight fires.
At some point technology becomes so good that it's a reasonable choice to give up understanding. And in opinion of many, that point is now for agenting coding.
you are probably smarter and more skillful then I am, but despite coding all my life for a living I feel that AI is vastly better than me in every single skill that I thought are my strongest skills.
I also think that the risk for a small company is larger that their only programmer who understand the code base quits than the ai not being able to fix issues in its own code.
The only point of disagreement is if llms are already good enough. And for a lot of people this is already true today.
"You were hacked because the well known, respectable crypto lib I bundled with my binaries actually got a bug" is fine.
"You lost one day of productivity and I can't tell you when I'll be able to propose you a fix because I shipped you a lazy copy/paste" is not.
Of course not - I use battle-tested options. Why would I pivot from battle-tested, production software that's had bugs shaken out for years to brand-new never-used-in-anger software that an LLM spat out?
Thing is we don't write kernel code nor assembly.
It would be an issue if for every API request handler we write we'd also ship a kernel patch or some kernel level helper. That's the situation we're stuck in with agents, they produce a bunch of low level code that we have to either trust or thoroughly review, even as our goal is at a higher level.
IMHO we really need high level and proven solid frameworks that the agents can rely on, and get in exchange high level code that is succinct, simple and readable enough to be properly understood.
Those are really bad examples to quote tho. I'm not making a change in the Linux kernel nor am I releasing it or debugging it or maintaining it or getting pinged at 1am by Pagerduty because of it. Nobody is asking me how it works or what would it mean to add feature X to it.
I think the bigger point is that you still do need to understand what is up in your codebase, relying on agents 100% of the time for absolutely everything is going to be preposterous in the long term.
- You are using it wrong! You don't know how to prompt!
- And if you do, then you are using cheap models! You aren't spending enough!
- And if you are, then you care too much! The quality doesn't matter anymore!
- And if it does, then the models will get exponentially better! The problem will be solved in a few months!
"AI writes shallow tests" - used to be true, not true anymore since Astra and Fable 5.1 / Opus 5.5.
"AI writes overly complex ccode" - only if you let it. A "do not overengineer it" or "Pareto, 80% result with 20% of effort" go a long long way.
"Reliance on AI decreases human understanding" - human understanding does not decrease, it just moves up a level or two. The same way you do not really understand how the Linux kernel works, nor do you know how assembly really works (with probably a bunch of exceptions here given this is the HN crowd!). And then there is hardware and physics too.
Understanding code, algorithms and data structures becomes a rarer need than it used to be.
"AI moves too quickly to maintain a high quality bar" - if you are stuck with the mantra that humans must review the code today, then obviously that statement becomes true. The problem is the assumption, not the observation. The good news about AI progressing fast is that coding AND reviewing get better and better with each release.
I know it is tough to let go. But as a software engineer, the sooner you do it, the quicker you will learn to yield a much, much more powerful weapon.