Endler argues that the compounding cost of shortcuts — undocumented hacks that become load-bearing, quick patches that become architecture, 'fix it later' debts that become multi-year migrations — proves that 'move fast and break things' optimizes for typing speed when the real bottleneck is comprehension. He makes the case that deliberate, well-understood software ultimately ships faster because it avoids the compounding tax of accumulated shortcuts.
The editorial argues that 'move fast and break things' was a rational response to 2010-era over-deliberation, but LLM-assisted coding tools like Cursor, Claude Code, Copilot, and Cline have made writing code essentially free. The bottleneck has moved from decision-making to review capacity, so 'move fast' has shifted from a cultural choice to a default behavior engineers must now actively resist.
By resubmitting the 2024 post and driving it to 127 points, the submitter signaled that the essay's thesis lands harder in late 2026 than when it was written. The accompanying comment thread — described as reading 'less like nostalgia and more like confession' — suggests practitioners recognize their own 2,000-line unread PRs in Endler's critique.
Matthias Endler's 2024 post *Move Slow and Fix Things* hit the Hacker News front page again this week, pulling 127 points and a comment thread that reads less like nostalgia and more like confession. The essay is a direct swing at Zuckerberg's old Facebook motto — the one every startup pitch deck quoted in the 2010s and every post-mortem has been quietly apologizing for since.
Endler's argument is simple and unfashionable: most software problems are understanding problems, not typing problems, and 'move fast and break things' optimizes the wrong variable. He points to the compounding cost of shortcuts — the undocumented hack that becomes load-bearing, the quick patch that becomes the architecture, the 'we'll fix it later' that becomes the migration project three years later with its own Slack channel. None of this is new. What's new is who's reading it in late 2026, and why.
The post is resurfacing now because the industry's velocity math changed. LLM-assisted coding tools — Cursor, Claude Code, Copilot, Cline — have made the *writing* part of software roughly free. Scroll any engineering Slack and you'll find someone shipping 2,000-line PRs they didn't read line-by-line. The bottleneck moved. 'Move fast' used to describe a team culture; now it describes a default behavior you have to actively resist.
The original 'move fast and break things' was a response to a real problem: engineering orgs that spent twelve months planning a feature only to ship something nobody wanted. In 2010, the dominant failure mode was over-deliberation. Facebook's bet was that the cost of a bug was less than the cost of indecision, and for a growing social network with a forgiving substrate (user content, A/B-testable UI), that bet mostly paid.
The failure mode in 2026 is inverted. The dominant risk now isn't that your team deliberates too long — it's that your tooling writes faster than your reviewers can read. Endler's essay doesn't mention AI, but every top comment on the HN thread does. 'I keep catching Copilot-generated null checks that handle the wrong null,' one commenter writes. Another: 'My team's velocity doubled and our incident count tripled. Nobody wants to say the quiet part.'
The mechanics are mundane but worth naming. When code generation is cheap, the implicit cost model of a PR changes. A human-written 300-line change represents hours of thought — the author has already walked the edge cases, considered the invariants, probably rejected two earlier drafts. An LLM-generated 300-line change represents one prompt and one accept. The artifact looks identical in the diff view. The reviewer, if they're honest, is now doing the thinking the author skipped — except they're doing it on someone else's mental model, which is strictly harder.
The compounding part is where Endler is sharpest. He describes software as a system where every shortcut earns interest, and the interest is paid by whoever touches that code next — often you, six months later, with no memory of why. In an environment where generation is cheap but comprehension is not, this interest rate goes up. You can ship more code per sprint. You cannot necessarily *understand* more code per sprint. The gap between those two numbers is where outages live.
There's a honest counter-argument worth stating. 'Move slow' can become its own pathology — the staff engineer who blocks every PR on a nine-page design doc, the architecture review board that exists to justify its own existence. Endler's point isn't that slow is a virtue; it's that *deliberate* is a virtue, and deliberate sometimes looks slow and sometimes looks fast. A one-line fix to the right place is deliberate. A 500-line LLM-generated refactor nobody read is not, regardless of how long it took.
Three practical shifts, if you're buying the argument.
First, treat comprehension as a first-class engineering output, not a side effect. If your team ships a feature nobody can explain back a month later, that's a defect — same category as a failing test. Some teams are formalizing this: PR templates that require a 'what would break if this were wrong' section, pairing requirements for anything LLM-generated above a size threshold, mandatory walkthroughs for merges touching critical paths. These feel bureaucratic. They are cheaper than the 3 AM page.
Second, invest in reversibility over velocity. Feature flags, canary deploys, blue-green, database migrations that are forward- and backward-compatible, idempotent jobs — all the boring infrastructure that lets 'oops' cost minutes instead of weeks. The teams that are winning the AI-codegen era aren't the ones generating the most code; they're the ones who've made undoing cheap enough that moving fast is actually safe. 'Move fast and break things' only works if you can also un-break things.
Third, be suspicious of velocity metrics that aren't paired with quality metrics. PR count, lines merged, story points closed — these go up almost automatically with LLM assistance. They tell you nothing about whether the system is getting better or worse. Pair them with incident rate, mean-time-to-recovery, change failure rate, and the oldest-untouched-TODO count. If the first set is climbing and the second set is flat or worse, you're not moving fast. You're accumulating debt faster.
The essay will probably resurface again in 2027, and again in 2028, because the underlying tension doesn't resolve — it just finds new terrain. The 2010s version was teams-vs-process. The 2020s version was microservices-vs-monoliths. The current version is humans-vs-generators, and the answer is going to be the same answer it always is: the tool is fine, the discipline is the thing. Endler's post is useful not because it's a manifesto but because it's a mirror. If reading it makes you uncomfortable about a PR you merged this week, that's the point. Fix the thing. Slowly, if that's what fixing it takes.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.