Botsitting: the 6-hour tax you didn't budget for

What happened

Business Insider reports that knowledge workers are now spending over six hours a week doing what the piece calls "botsitting" — babysitting AI output: re-prompting, fact-checking, fixing hallucinations, cleaning up half-finished code, and rewriting tone. The reporting is built on survey data from workers across marketing, legal, software, and customer support, with a recurring complaint: the tools were sold as time-savers, but the time saved on drafting is being eaten by time spent verifying.

The number itself isn't shocking to anyone who has shipped a Copilot-assisted PR lately. What's notable is that it's now large enough, and consistent enough across roles, to show up in workforce surveys as a distinct category of labor. Six hours a week is roughly 15% of a 40-hour week — a full afternoon, every week, spent in the loop with a machine that was supposed to remove the loop. The article frames this as a source of growing frustration, particularly among mid-career workers who were told AI would handle the grunt work and instead find themselves doing a new kind of grunt work: QA on a junior employee that never learns.

Managers, predictably, are not measuring this. The hours don't appear on a timesheet line called "botsitting." They get absorbed into "writing," "coding," or "review" — which makes the productivity gains look better than they are and the human cost invisible.

Why it matters

The industry pitch for generative AI at work has always rested on a simple equation: model does the draft, human does the polish, net hours saved. The botsitting data suggests the equation is closer to: model does a draft that looks 90% done, human spends disproportionate time finding the 10% that's wrong, and the net savings are smaller — sometimes negative — than the dashboard claims.

This is a verification tax, and verification is structurally harder than production. Writing a function from scratch, you hold the invariants in your head as you build them. Reviewing a function an LLM produced, you have to reconstruct the invariants from the output, which is the same cognitive load with worse ergonomics. Anyone who has reviewed a 600-line PR from a coworker knows this; doing it eight times a day against a tireless model is a different kind of exhausting.

There's a second-order effect that the Business Insider piece touches on but doesn't fully unpack: the skill of verification atrophies in people who never built the thing in the first place. Senior engineers can catch a subtly wrong SQL query because they've written ten thousand of them. Juniors trained primarily on "accept the suggestion, run the tests, ship" are being asked to be the last line of defense against a generator that's confidently wrong in ways they aren't equipped to detect. The botsitting hours are highest, anecdotally, among the people least prepared to do the sitting well.

The community reaction on HN has been blunt. The top comments aren't "AI is bad" — they're "the tooling assumes a level of trust the model hasn't earned, and the workflow makes it expensive to distrust it." One thread points out that the IDE integrations are optimized for *acceptance velocity* (tab to accept, Enter to continue) rather than *verification velocity* (here's a diff, here's a test, here's the blast radius). The friction is in the wrong place.

The honest reading is that we've automated the part of knowledge work that was already cheap — first drafts — and added overhead to the part that was always expensive: deciding whether the draft is right.

What this means for your stack

A few concrete moves if you're running an engineering org that's been told to "adopt AI aggressively":

Measure verification, not just generation. If you're tracking lines of code suggested, PRs opened, or tickets closed, you're measuring the cheap half. Start tracking review time per AI-assisted PR vs. human-only PR, post-merge revert rate, and bug density in AI-touched files over a 90-day window. The botsitting tax shows up there, not in the suggestion-acceptance rate your vendor dashboard brags about.

Move the friction. The biggest win is not a better model — it's a workflow where the model's output arrives with the verification artifacts already attached: a generated diff with a generated test, a generated SQL query with a generated EXPLAIN, a generated email with the source quotes inline. Tools like Cursor's agent mode and Claude Code's plan-then-execute pattern are early attempts at this. The pattern to copy: never ship output without the receipts.

Treat botsitting as a real budget line. If a developer spends six hours a week verifying AI output, that's $15K-$25K/year of fully-loaded cost per engineer, depending on geography. Multiply by headcount. That's your *actual* AI cost, not the $20/seat/month on the invoice. Decisions about which workflows to AI-ify should weigh this honestly — some will still be huge wins, others will be a wash, and a few will be net negative. You can't tell which is which without measuring.

Looking ahead

The interesting next phase isn't bigger models — it's tools that respect verification as a first-class workload. Expect to see IDE features that surface uncertainty ("this function is in a region of the codebase the model hasn't seen tests for"), code-review bots that flag AI-touched hunks for higher scrutiny, and procurement contracts that include verification-time clauses. The vendors who win the next 18 months will be the ones who stop selling "AI that writes code for you" and start selling "AI that's cheap to verify." Until then, budget the six hours. They're not going anywhere.