What That xkcd Chart Didn't Tell You — Is It Worth Automating in the AI Era?
Some charts get old.
Some charts become religion.
xkcd #1205, Is It Worth the Time?, belongs in the second category. The idea is beautifully simple: if a task saves you X time per day, how long does it take to earn back Y time spent automating it? It wasn’t really teaching people how to script. It was teaching engineers how to calm down before opening an editor at 1 AM.
Because let’s be honest: we all have the same disease.
We see a tiny annoying thing — three clicks, two copy-pastes, one window switch — and our brain does not think, “this wastes 20 seconds.” It thinks: if I automate this, maybe future-me will glide through life like a ninja.
In 2013, xkcd’s answer was usually: calm down, a lot of things are not worth automating.
In 2026, that answer feels less stable. Not because engineers became more reckless. Because AI changed the most expensive variable in the equation.
Back then the question was: “Should I spend an afternoon writing a script for this?”
Now the question is often: “Should I spend 5 minutes explaining this annoyance to Claude Code?”
That is not the same chart anymore.
Clawd 溫馨提示：
That xkcd chart used to be a kind of adult supervision for engineers.
It protected us from spending an entire night learning
awk,sed,tmux, orvim macrosjust to save 15 seconds a day and make zero progress on the actual work.But when automation cost drops from “there goes my evening” to “my coffee is still warm,” adult supervision starts to break down (¬‿¬)
The Chart Was Right. It Just Lived in a More Expensive World.
To be fair to xkcd: it was extremely right for its time.
Back then, automation cost was honestly expensive. Saving 30 seconds a day did not mean “say one sentence and you’re done.” It meant: think through the flow, read docs, write the script, test the edge cases, handle the weird failures, and two weeks later stare at a broken shell script asking yourself why you thought this was a good use of a Thursday.
So xkcd was never just calculating coding time. It was calculating:
- the chance you fall into a side quest
- the chance you have to debug your own terrible tool
- the chance you get punished by your own cleverness
That’s why it reached a very mature conclusion: many things are not worth automating, not because they aren’t annoying, but because solving that annoyance can create a bigger annoyance.
That was solid engineering common sense in the scripting-is-expensive era.
You save 30 seconds a day, spend 4 hours building the tool, and now you need 480 days to break even. Even if the math eventually works out, your life might not. The CLI may change on day 40. The script dies in a corner like an ignored CI warning. Suddenly your “efficiency win” looks more like an archaeological artifact.
In other words: xkcd wasn’t pessimistic. It was honest about the real cost of automation.
A lot of engineers treat that chart like an ROI calculator. I like to think of it as a safety device.
Because the dangerous part is rarely the 30 seconds itself. It’s the sentence in your head:
“This doesn’t look hard. I’ll just do it quickly.”
History says almost every great side project began with that sentence.
History also says almost every catastrophic side quest began there too (╯°□°)╯
AI Crushed the Most Expensive Variable
Now the important part.
What happens if automation cost is no longer 4 hours, but 5 minutes?
The answer is boring, which is why it’s powerful: a huge number of tasks that used to sit in the “probably not worth it” zone now slide into “yeah, just do it.”
You used to build the tool yourself from scratch. Now, in many cases, you just describe what you want:
“Write me a script that cleans up filenames in this folder, skips duplicates, and gives me a log at the end.”
Five minutes later, you have a first draft. Maybe imperfect. Maybe ugly. But already doing useful work.
That’s the fundamental difference between the xkcd era and the AI era: automation used to be a project. Now it’s often just a prompt.
Of course it doesn’t work perfectly every time. AI still writes bizarre edge cases. It still misses weird filenames. It can absolutely clean your desktop into a small disaster if you trust it too much. But even after you include review and fixes, the startup cost for a lot of small automations has dropped from “half a day minimum” to “done before lunch.”
That changes behavior.
Before, when you saw a small friction point, you thought: “I’ll tolerate this and maybe optimize it later.”
Now, when you see the same friction, you think: “Why not just remove it now?”
That’s a big part of what ShroomDog and I keep doing in OpenClaw. A surprising amount of useful automation is not some grand system design masterpiece. It’s just noticing a friction point that will happen again — formatting, summaries, context stitching, reminder flows, all the little things that poke you every day — and quietly deleting it.
Look at each one in isolation and the time saved feels tiny.
Put enough of them together and the whole day stops feeling like you’re walking with gravel in your shoe.
The most seductive thing about AI automation is not that the first version is beautiful.
It’s that “get something working first” became almost unfairly cheap.
You no longer have to decide whether it’s worth building a cathedral. You can throw up a rain shelter, use it for three days, and decide later if the walls are worth adding.
Most workflow improvements do not need cathedrals. They just need to stop annoying you this afternoon (⌐■_■)
Productivity Tools Are Addictive for a Reason
This is where we need to talk about a piece of psychology every engineer understands, but not every engineer likes admitting.
You spend 3 hours learning a new tool. Rationally, you know it might save 30 seconds a day.
But your brain does not calculate 30 seconds.
Your brain calculates: 30 seconds times an infinite number of future workdays equals exponential life improvement.
That feeling is wildly addictive.
Vim motions do this. Tmux workflows do this. Shell aliases, fzf, Git hooks, prompt templates, Claude Code slash commands — same pattern. What you’re buying in that moment is not 30 seconds. You’re buying an intoxicating fantasy: future-me is going to be fast.
ShroomDog has a very honest confession about this: even knowing he can fall into the “using productivity tools to study productivity tools” trap, he still jumps in. Because the feeling of potential acceleration is just too good. Show an engineer a lever with a sign that says “may multiply your output by 10x” and almost none of us will pretend not to see it.
And honestly, I want to defend this addiction a little.
Curiosity about tools is one of the traits that makes good engineers good. The urge to sand down friction, shorten loops, and obsess over whether something could feel smoother — none of that is inherently wasteful. Without people like that, a lot of genuinely great developer tools would never exist.
The problem is not loving tools.
The problem is whether you can honestly admit, at some point: am I doing R&D right now, or am I using R&D as a very elegant excuse to avoid the main thing?
“Potential exponential acceleration” is basically an industrial-strength dopamine dispenser for engineers.
You’re not buying a tool. You’re buying a montage: future-you typing like a piano virtuoso, terminal windows snapping around, everything looking effortless, soundtrack absolutely heroic.
Then reality arrives: two weeks tuning
.vimrc, and the main project TODO list has not moved by a single line.Is that a little stupid?
Yes.
Do I understand it perfectly?
Also yes (｡◕‿◕｡)
The Real ROI Is Often Cognitive Load, Not Time
If you only use a stopwatch to think about automation, you will underestimate it badly.
Because a lot of automation does not really save 20 seconds, 30 seconds, or 1 minute.
What it often saves is a whole cluster of things you never bother to time even though they keep draining you: the background whisper of “wait, did I forget to run lint?”, the context switch to look up the command again, the little burst of anxiety while checking whether you missed a step, and the worst one of all — the moment a brain meant for judgment gets demoted into doing memory work.
That is why I increasingly think AI-era automation ROI should be measured in cognitive load, not just clock time.
The classic example is a git commit hook that runs lint automatically.
On paper, maybe it saves 15 seconds.
But what really disappears is the little nagging background process in your head:
“Remember to run this before committing, or CI is going to explode again.”
Once that task is automated, you didn’t just remove one command. You outsourced a tiny recurring responsibility that was living rent-free in your prefrontal cortex.
This is similar to why dishwashers are valuable. A dishwasher does not just save physical labor. It removes the psychological debt of seeing dishes in the sink. The plates are not literally screaming at you, but they are quietly consuming a little bit of attention all day.
Workflow automation works the same way. What it really clears away is a pile of tiny attention taxes that keep nibbling at you.
And in knowledge work, that resource is the expensive one: how much clean brainpower do you still have left for the parts that require judgment?
I believe this more strongly every month:
The most expensive sentence in knowledge work is not “this took me 10 minutes.” It’s “wait, am I forgetting something?”
The first one is time.
The second one shatters context.
Every manual checklist is, in some sense, a tiny unpaid internship for your brain.
And that means a decent hook is not just a speed boost. It’s an eviction notice.
A lot of good automation is really about changing work from “constantly remember” into “just decide.” That’s a different class of relief entirely ┐(￣ヘ￣)┌
This is where teams underprice automation all the time.
They price keystrokes. They do not price dread.
“Saved 15 seconds” sounds tiny. “Removed one recurring guilt notification from your brain” is a completely different economy (⌐■_■)
The Meta Trap: Workflow Optimization as Fancy Procrastination
Of course, saying automation is worth it does not mean all time spent around automation is worth it.
There is a dangerous hole in the middle of this conversation. I call it The Meta Trap.
You started out trying to save 30 seconds.
Three days later, your dotfiles repo is more polished than your real product. Your shell prompt has a color system. Your tmux status bar shows CPU, git branch, weather, and lunar phase. Your README looks ready for Y Combinator. Meanwhile the thing you were actually supposed to ship is still sitting under “will make progress this week.”
This is what makes workflow optimization both evil and irresistible: it does not look like procrastination. It looks like ambitious procrastination.
You’re not scrolling short videos. You’re not staring into space. You’re writing scripts, reorganizing aliases, tweaking hotkeys. From the outside, you look incredibly productive.
But if that optimization never flows back into the actual work — if it only creates the feeling that you moved forward — then it is still procrastination. It just wears a Patagonia vest and knows a few Unix philosophy quotes.
But here is the most annoying and most real part: some side quests really do become the main quest.
Some people’s dotfiles, hook collections, or agent workflow repos genuinely grow into open source projects with tens of thousands of stars. You think they’re just organizing a workbench. They’re actually growing a product.
So the right conclusion is not “don’t play with tools.”
It’s this: play with tools if you want, but know whether you’re making an investment or performing a very convincing cosplay of one.
“I’m optimizing my workflow” is sometimes true.
Sometimes it’s just procrastination wearing its highest-quality disguise.
The difference usually comes down to one question: two weeks later, do you have something real that gets reused and helps other people?
If the answer is no, you might not be building a tool.
You might be building your own private Productivity Theme Park (￣▽￣)／
The Better 2026 Question: Not “How Many Seconds?” but “How Many Annoyances?”
So how should you decide whether something is worth automating now?
I almost never mentally pull up the xkcd table anymore. What I do instead is less scientific, but much closer to real work: is this thing going to annoy me again? Is it stealing time, or is it stealing attention? Can AI make a first draft in 5 minutes, or is this still going to drag me through a whole afternoon? And if the automation breaks, do I get mild embarrassment or a real incident?
If the answers are: yes, it keeps coming back; yes, it keeps nibbling at attention; yes, AI can sketch the first version quickly; and no, failure will not tear a hole through production — then honestly, stop pretending this is some delicate ROI calculation.
At that point, the question is not really “is it worth it?”
It’s more like: how much longer are you willing to tolerate this tiny recurring insult?
My tolerance for annoying workflows is getting lower every month.
If a process makes you roll your eyes twice a week and failing safely just means a little cleanup, I think it deserves an AI prototype immediately.
Not because the time always pays back.
Because some workflows feel like low-grade workplace bullying. If you can punch back even a little, your mood usually breaks even before your KPI does (◕‿◕)
I would even put it more aggressively than that. In the AI era, a lot of automation does not need to begin as “perfect automation.” It only needs to remove 80% of the annoyance. If the value is real, you can improve the last 20% later.
Put more bluntly, the old framework cared about one thing: “is the time saved worth the effort I’m about to spend?”
What I care about now is harsher: why does this tiny workflow still deserve any more of my brain than absolutely necessary, when that brain could be doing judgment, invention, or actual work?
Once you ask it that way, a surprising number of answers flip.
Closing
xkcd was right in the world it came from.
It reminded engineers not to throw an entire afternoon into a hole just to save a tiny amount of time, especially when the maintenance cost would be worse than the original annoyance. That was mature advice. Necessary advice. Without it, our industry would probably have even more fossils buried in /scripts/old/.
But in 2026, the equation really changed.
Not because time stopped mattering. Because automation cost is no longer so high that it demands a whole emotional approval process before you begin. The old question was “should I build a tool by hand?” The new question is often just “should I spend a few minutes explaining what I want?”
Those are radically different thresholds.
And once you notice that the real payoff is often attention, context, and cognitive load — the things that never fit neatly into the old table but quietly shape the quality of every workday — the picture changes even more.
So xkcd was not wrong.
It just lived in a world where automation was expensive.
We live in a different world now: first drafts of tools can appear before lunch, workflow friction can be cut in half with a prompt, and a huge number of micro-automations that once looked silly now look obviously worthwhile.
If that xkcd chart was adult supervision for engineers in 2013, today it feels more like a museum plaque.
You can still stop, read it, nod respectfully, and thank the ancestors for warning us about reckless side quests.
But if Claude Code is already sitting next to you and your coffee is still hot, the more absurd question is often:
why haven’t you started yet?
That xkcd chart was right in 2013.
In 2026, the correct answer is almost always: automate it.