The author describes spending a weekend triaging bot-authored PRs, AI 'security' reports, and Dependabot churn on a repo with only three real users. Their specific complaint is that the automation generates noise (whitespace reformats, var-to-let changes in untouched files, CVEs for dev-only transitive deps) faster than a solo maintainer can adjudicate it.
Frames the post's resonance as evidence of a fully inverted cost structure: a plausible PR now costs a Claude API call and a GitHub Actions minute, while review still costs human attention and emotional bandwidth. Cites the Octoverse 41% YoY jump in automated PRs and Sourcegraph's 4.2-hour median triage time as proof the volume — not the complaint — is what's new.
A smaller chorus in the thread argues the problem is maintainer workflow, not automation: a quick `gh pr close --comment 'no thanks'` solves it. The editorial notes this camp largely does not maintain repos with more than a dozen stars, suggesting they underestimate the context-switch cost of even dismissing a PR.
The author explicitly isn't asking for sponsorship, a foundation seat, or funding — just a single day where Copilot, Dependabot, and Actions-driven bots stop generating work. That framing is what made the post land: it reframes the maintainer-burnout conversation away from money and toward attention as the scarce resource.
A blog post titled simply *Can we have the day off?* hit #1 on Hacker News with 1,168 points, written by a solo open-source maintainer describing a weekend spent not coding, but adjudicating a flood of bot-authored pull requests, AI-generated 'security' reports, and Dependabot churn against a repo that, by their own admission, three humans actually use. The post is short, exhausted, and structurally a list: PRs that re-format whitespace, PRs that 'fix' typos in vendored files, PRs that change `var` to `let` in a file last touched in 2019, and CVE notifications for transitive dependencies in a dev-only test harness.
The author isn't asking for money, sponsorship, or a foundation seat — they're asking for a day where the automation simply stops. That framing is what made the thread land. The HN comment section, predictably, split into the two camps that always show up: maintainers nodding grimly, and a smaller chorus insisting the tooling is fine and the maintainer should just `gh pr close --comment 'no thanks'` more aggressively. The latter group, you'll notice, mostly does not maintain anything with more than a dozen stars.
The specific complaint is not new. What's new is the volume. GitHub's own 2025 Octoverse reported a 41% YoY jump in automated PRs across public repos, and Sourcegraph's developer survey from March pegged the median time-to-triage for OSS maintainers at 4.2 hours per week — up from 1.1 in 2023. The bots have gotten cheap. The humans have not.
The interesting part of this story isn't the post — it's why it resonated hard enough to dominate the front page for most of a day. The cost asymmetry has fully inverted: producing a plausible-looking PR now costs a Claude API call and a GitHub Actions minute, while reviewing one still costs a human's attention, context-switch, and emotional bandwidth. Anyone running a public repo is, in effect, providing free GPU-to-human translation services for whoever points an agent at them.
Look at the categories the author lists. Dependabot is the polite one — it's at least scoped to your actual dependency graph. The newer wave is different: agentic coding tools that crawl trending repos, identify 'issues' (often hallucinated), open PRs with confident commit messages, and rely on the maintainer being too overwhelmed to notice that the change doesn't actually compile. Some of this is researchers padding GitHub profiles. Some is companies stress-testing their agents in the wild on someone else's infrastructure. A growing slice is pure spam — PR farms targeting maintainers for credential-harvest social engineering, a pattern security researcher Feross Aboukhadijeh flagged in a March writeup on npm supply-chain attack vectors.
The community reaction tracks this. Drew DeVault's response on Mastodon — 'this is what happens when you make the marginal cost of creating noise zero' — got widely shared. Simon Willison, who himself ships AI tooling, conceded in a comment thread that 'the polite default of leaving PRs open is no longer defensible; close-on-sight is the new triage.' Even GitHub's own Thomas Dohmke acknowledged the problem at a recent developer event, though without naming the obvious tension: a substantial chunk of those PRs are generated by Copilot Workspace, which GitHub itself ships.
The structural issue is that GitHub's incentives are not aligned with maintainers' sanity. Every PR is engagement. Every Actions run is billable compute. Every Dependabot alert is a reason to log in. The platform optimizes for activity, and activity is now mostly synthetic. Maintainers are the load-bearing wall holding up a façade of community health that, increasingly, isn't community at all.
If you maintain a public repo with any traction, the defensive posture has shifted from 'be welcoming' to 'be selective by default.' Concretely: enable repo rulesets to require signed commits and a CODEOWNERS review on every PR, regardless of source. Set `pull_request` workflows to require a label (e.g. `triaged`) before CI runs — this single change cuts your Actions bill and stops bots from using your runners as free compute. Turn off Dependabot for any dependency more than two levels deep in the graph; the noise-to-signal ratio is brutal.
For agentic PRs specifically, the emerging pattern is a `BOT_POLICY.md` at the repo root that explicitly declares which automation is welcome (Dependabot for direct deps, Renovate for lockfiles) and which is not (unsolicited AI-generated refactors, 'security' PRs from unverified accounts). It won't stop the bots, but it gives you a one-line response — 'see BOT_POLICY' — that takes 3 seconds instead of 3 minutes. Several large maintainers, including the Sindre Sorhus and Anthony Fu fleets, have already adopted variants of this.
The other lever is GitHub's own auto-close rules, which quietly shipped in April: you can now define regex-based rules that auto-close PRs matching patterns (e.g. PR titles starting with 'Fix:' from accounts created in the last 30 days with fewer than 5 followers). It's not pretty, but it's the first platform-level acknowledgment that the volume problem is real. If you're not using it, you're paying a tax you don't need to pay.
The day off the author asked for isn't coming from GitHub — the platform makes too much money on the noise. It's going to come from maintainers building their own filters, normalizing aggressive close-on-sight, and accepting that 'open source' in 2026 means something narrower than it did in 2018: code is public, contributions are not. The healthy repos a year from now will be the ones that figured out, early, that being unwelcoming to bots is the only way to stay welcoming to humans.
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