The blog author observes that tools have compressed engineering work by 40-70%, yet hours haven't shortened and deadlines haven't softened. They frame the missing time off as a distributional question — when output doubles, who keeps the gains is decided by power dynamics in the labor market, not by any natural ergonomic redistribution.
The editorial frames the HN post as the third front-page variant of the same question in twelve months, situating it within Keynes' 1930 'Economic Possibilities for our Grandchildren' essay that predicted a 15-hour week by 2030. The argument is that productivity gains have never automatically converted to leisure — what's new isn't the question but that senior engineers now believe the productivity claims as observed daily fact.
The editorial cites converging evidence — the 2025 Stack Overflow survey showing 78% daily AI usage among professionals, JetBrains finding 61% report meaningful time savings — against wellbeing data from Stack Overflow, GitHub Octoverse, and ICONIQ all showing flat-to-rising working hours, climbing burnout indicators, and continued layoffs from the same companies shipping the tools. The contradiction is measured, not anecdotal.
On the Wednesday after Memorial Day, a post on a small personal blog (mlsu.io) titled simply "Can we have the day off?" climbed to 1,018 points on Hacker News with over 700 comments. It is, by a wide margin, the highest-scoring labor-and-culture post on HN this quarter — and the third time in twelve months the front page has been dominated by some variant of the same question.
The premise is almost embarrassingly simple. The author works in tech. The author's tools have gotten dramatically better — IDEs that autocomplete entire functions, agents that close Jira tickets while they sleep, CI systems that catch regressions before code review. The author's hours have not gotten shorter. The author's deadlines have not gotten softer. The author wants to know, plainly, where the dividend went.
What made the post land wasn't novelty — Keynes wrote essentially the same essay in 1930 ("Economic Possibilities for our Grandchildren," which predicted a 15-hour week by 2030). What made it land was timing. We are now eighteen months into the period where senior engineers actually believe — not as a sales pitch but as a daily observed fact — that AI tooling has compressed certain kinds of work by 40% to 70%. The 2025 Stack Overflow developer survey put daily AI tool usage at 78% among professional respondents. JetBrains' State of Developer Ecosystem found that 61% of devs report "meaningful" time savings. And yet the same survey runs — Stack Overflow's wellbeing supplement, GitHub's Octoverse, ICONIQ's State of Production AI — all show working hours flat to up, burnout indicators climbing, and a steady drumbeat of layoff announcements from the same companies shipping the productivity tools.
There's a clean economic story for what's happening, and you don't need a labor theorist to tell it. When you 2x an engineer's output, the question of who keeps the gains is decided by power, not by ergonomics. In a tight labor market, some of the gain flows to the worker as comp or hours. In a soft labor market — which is what 2024–2026 has been in tech — basically all of it flows to scope. The same headcount ships more roadmap. The roadmap then expands to fill the new capacity, and the cycle resets at a higher tempo.
This isn't conspiracy. It's the natural state of any system where the workers and the people setting expectations are different people, and the workers don't have a coordinating mechanism. The spreadsheet didn't give accountants Fridays off — it eliminated some accountants and made the survivors do five times the modeling. The compiler didn't give programmers shorter days — it made every business expect software. There is no historical case of a major tooling step-change in white-collar work translating directly to leisure without explicit, organized pressure. None.
The HN comment section split predictably. One faction — call it the meritocratic read — argued that productivity gains *should* go to output: the world has problems, software fixes some of them, and a senior engineer with Claude or Cursor producing more is a senior engineer creating more value. Asking for the day off in exchange is, on this view, asking to be paid the same for less work. Fine if you can negotiate it; not a right.
The other faction — the one that pushed the post to four digits — pointed out that the meritocratic frame ignores who decides what "more output" means. If the floor of expected weekly throughput rises every time tooling improves, the worker never gets to cash the gain; they just run faster to stay in the same place. One top-voted comment, from a staff engineer at a public SaaS company, put it: "I close 2.3x the tickets I did in 2022. My team has the same headcount. We shipped two more product lines. My salary went up 4%. Where exactly did the surplus go? Look at the stock price."
A third, smaller faction — the one worth taking seriously if you actually run engineering teams — argued the question is less about hours and more about what the hours are *spent on*. Devs aren't necessarily working more clock-time; they're working more cognitive time. AI tooling has eaten the parts of the job that were rest-by-default (skimming docs, writing boilerplate, debugging by exhaustion) and replaced them with sustained high-stakes review of generated code. The 40-hour week of 2026 has more decisions per hour than the 50-hour week of 2018. The body knows.
If you're a senior IC or EM, the post is a flag, not a manifesto. The actionable question isn't "can we have the day off" — it's "what is our team's policy when a piece of work that used to take three days now takes one?" Most teams don't have one. The default policy, by inaction, is: pick up the next ticket. That default is what the post is railing against.
The teams that are quietly winning here have made the policy explicit. Some examples worth stealing: a fixed weekly cap on shipped scope regardless of velocity (Shopify's "GSD week" model, in a stricter form); explicit "recovery sprints" after AI-accelerated delivery cycles; using freed time for the work that was always being deferred — internal tooling, on-call ergonomics, dependency upgrades, the long-tail bug list. The pattern is the same: convert the productivity surplus into something durable (tech debt paid down, infrastructure improved, learning) before the next planning cycle absorbs it into roadmap.
If you manage engineers, the harder lesson is that nobody is going to ask you for this from below in a soft market. The people best positioned to push back — the ones whose Cursor diff stats have doubled — are also the ones most worried about how it looks. You have to be the one who notices the velocity jump and decides what fraction of it the team gets to keep. Otherwise you'll wake up in twelve months running a team that's twice as productive, half as healthy, and unable to articulate why.
The post will scroll off the front page by tomorrow and the question will not be answered. It never is. But the fact that this is the third version of the same post to top HN in a year is itself a signal — somewhere between the productivity numbers in the JetBrains survey and the working-hour numbers in the wellbeing survey, there is a gap, and the gap is being noticed. The hard part for senior devs is that the gap is also where the leverage is. Either the people who got faster start asking where the time went, or the answer keeps being decided for them by people who are not them.
My dad was a stock broker in the late 1970s and remembers when most of trading was 100% manual and firms actually had "runners" who would take stock certificates back and forth between trading firms.He has this great quote about when computers came out:"We were told 'computers wi
The four day work week is a prisoner's dilemma. If everyone did it, then we'd all get a payoff, but if someone defects to a longer work week they tend to get ahead at work. Thus we all do it and thus we all lose.It's funny how underappreciated it is how the five day work week is power
Benefits for extra productivity filter up to the shareholders not to the workers producing the extra productivity.This reminds me of the Luddite movement in England. Industrial machines were disrupting the textile industry. The Luddites were not anti technology they were against technology allowing
I never understand why software engineers are so excited about AI as a whole.If you are excited about the technology, sure. But if you are excited about the increase in productivity, unless you are a manager, I don't really understand it. Like, why? You are not working one hour less than before
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
This article is kind of playful, but I think there’s a serious point here that’s not discussed enough. We’re being asked to usher in huge productivity gains by introducing AI to our workflows, but we’re not asking how does it help us? Not a lot of us stand to directly gain from our employers becomin