> "Users don’t care whether the code was written by AI or by hand, or which framework you used. They care that the product works."
1. Engineers should care about code quality so they can maintain it if their preferred AI providers are down or unavailable.
2. Code that's written well is easier for AI to navigate and modify.
3. Cognitive debt is real. I've been writing software for 20 years and without a doubt, I feel like my knowledge and edge are atrophying. This has been cited and confirmed by more than enough engineers who feel frustrated by this phenomenon.
4. Generating massive amounts of code significantly reduces accountability, making it impossible to review that code line-by-line unless you deliver your generated output in extremely small chunks (200-300 LOC per PR).
5. Since #4 is an objective reality, shipping code that hasn't been reviewed by a human is patently unethical, since the humans merging and deploying that code can't possibly know if there are lingering security holes or mishandling of sensitive information by their generated code.
6. One could say "well this is possible with hand-written code too", and they're right -- but the difference is, there was a human element in reviewing the code in good faith, rather than tossing thousands of LOC over a fence and telling their PAYING customers "good luck, hope it works!"
7. The other rebuttal is that tests and "guardrails" solve these problems. We all know that even the best test suite isn't foolproof. 100% coverage doesn't mean the tests are good, or will catch when something critical breaks.
8. AI guardrails are flaky at best: they're intended to be brief in order to save on context usage, but the more brief and numerous they are, the less accurate they'll be across a growing codebase. IME, many of the rules I've setup are obeyed by LLMs less than 100% of the time, which isn't enough to give me full confidence in them, because things will inevitably drift and fall through the cracks. Scale this to a team, and now you've got endless drift and disorder.
The arguments against AI have nothing to do with elegance, pretty code, formatting, or anything petty of the sort. It has everything to do with code quality and maintainability over time across teams of engineers who are accountable for their code, for products and services that people quite literally pay you for, trusting that what you're delivering them is stable, reliable, secure, and trustworthy.
If shipping speed is a higher priority than any of those, you have no business writing software to sell.
Quote: "This line of thinking boils down to, “Humans are valuable if they produce high-quality output.” This argument dangerously depends on the existing-but-narrowing human-AI capability gap. The gap certainly existed in the past (2023-era ChatGPT). It may still exist now. I do not know if it will hold in the future."
I still don't agree with this, because even the best engineers are producing poor output from AI, unless they spend a reasonable amount of time refactoring and cleaning up the output.
To expect a non-engineer to have the same wisdom to architect and structure their output in a sustainable way that will stand the test of time (and inevitable future changes), they're just fooling themselves.
For anyone who's been using LLMs long enough for development, we all know how sloppy the output is unless you have a mountain of formatting and organizational rules in place, and even then, it's anyone guess how well LLMs can actually follow them as a project scales.
Yes, value the human first, but there are strong reasons we've always emphasized mature patterns and idioms in codebases that help them remain maintainable so they can scale and transform with as little friction as possible, and without reaching a point where nobody has the stomach to keep working on it.
Just because we can try to have AI unwind the hairy mess, doesn't mean it's any easier for AI to navigate it than we do. It's a liability that the AI mistakes one naming conflict for another, when the context rot hits the fan — and after months of tossing unreviewed PRs over the finish line without a single thought, it's only a matter of time before your non-engineers are the worst offenders for introducing bugs and eroding the quality.
It doesn't matter how good the models appear to get (it truly is a facade), without judgment and wisdom, they still don't produce nearly the same quality as an experienced engineer, unless they're heavily steered.
Do they catch more potential bugs and edge cases than a human might? Definitely, but it's going to vomit its solutions in all the weirdest places doing it, and now suddenly you've got a 100k LOC pull request to (not) read.
This is pure cinema. I'm glad he's using his platform to call this out, it's rampant!
I usually just toggle Firefox's reading mode whenever a dickover like this pops up and they magically go away, allowing me to continue reading in peace.
I hate to say this, but this reeks of "We're owned by Anthropic now and we were put to task to prove Claude Opus as the ultimate AI model, so we were forced to do a full port of something millions of developers rely on to Rust in record time. Just ignore the slop and unsafe statements." (sweeps the broom)
This is nothing more than a marketing stunt from Anthropic. Nothing to see here.
Simple answer: it's easily reviewable by a human, which will always be an important step in the process of building software, no matter how many hype conferences tell you to stop checking AI output irresponsibly.
That keyboard layout is a deal breaker for me. Why do companies have to change things up all the time? Why can't they just go with T-shaped arrow keys and a standard layout?
It completely dwarfs the otherwise great hardware.
Are you referring to the UK layout? Or the keys on the side? It's all tradeoffs but full size cursor keys and a line of line/page keys are arguably as good as it gets.
Specifically the line/page keys. I guess I've gotten used to MacBooks for so many years that I'm fine with pressing a modifier key and the arrow keys to navigate that way.
I'd rather do that than accidentally keep pressing "Home" instead of Backspace.
With this, I'd have to look down at my keyboard all the time to make sure I'm not mistakenly pressing those keys, because the hand is used to "resetting" on the edges of the keyboard to get a feel for the keys I expect to find on the edges: Enter, Shift, Arrow Keys, etc.
For business users with notebooks who fly around a lot or spend time in coffee shops, it's possible.
reply