What's this about?
An old thesis restated for the agent era: the job was never typing code, it was containing complexity, so handing the typing to a machine doesn't change the job. The comments are where it gets contentious.
What is the disagreement actually about?
Whether writing code and engineering software can be separated at all. One camp treats code as an implementation detail below a good abstraction — you don't read compiler output, so why read generated code? The other camp argues the two activities are the same mental act, and splitting them damages your understanding of your own system. Both positions are coherent; which one is right probably depends on how much of your system you need to hold in your head at once.
What's the community saying?
HN 112 points, 79 comments
- The boldest claim: AI can already generate architecture from requirements and ask clarifying questions, and "in a few months system architecture will have its Claude Code moment."
- The strongest rebuttal: what's missing from the training data is the *why* behind decisions — separating good design from bad is rarely black and white and is hard to capture in code.
- A concession from the sceptic's opponent that lands well: it may not match my reasoning, but it usually surfaces things I should have thought of.
- The flat rejection: AI cannot be essential to software engineering, because we managed without it a few years ago — and arguably the code was better.
- The compiler analogy and its limits: people who do performance work read compiler output daily, so "good abstractions mean you never look" is not quite true; the honest version is that you look at the critical parts.