From a Workweek to a Coffee Break

Most AI automation efforts fail before a single workflow gets built — not because the tooling is weak, but because nobody found the right task first. The fix is a three-pillar audit — repetitive, time-consuming, error-prone — that turns a vague sense of "we should automate something" into a short, ranked list of what to build first.

How I got here: from "is my career over?" to "should this be built?"

Early this year I was deep in coding-agent experiments — running OpenClaw (formerly ClawdBot), wired up to my own wrapper. On a whim, I asked it to build something with containers: a small site backed by a couple of services, database included, fully wired up. I expected a slog. I recorded a long voice prompt — everything I wanted, the shape of the stack, the pieces that needed to talk to each other — sent it over Telegram to the laptop running OpenClaw, and walked away assuming I'd be babysitting it for the rest of the afternoon. The model behind it at the time was Codex 5.3.

I poured a coffee. Before I'd finished it, the agent messaged back: done.

I didn't believe it. "Done" is not a word you expect that fast for networking, a database, a backend, and a frontend all wired together. I walked over expecting to find the thing half-built, or worse, confidently broken. It wasn't. Everything was there, and it all actually worked.

My first thought, honestly, was is my career over? My second thought, about ten seconds later, was: no — this is just a different way of working now. You can go from a week of work to a coffee break. That was the start of the rabbit hole.

Since then I've built dozens of agents and shipped production systems running on 90–95% AI-generated code — Claude Code, Opus, Sonnet, sub-agents, workflows, all of it. And the conclusion I keep landing on is the one this blog is built around: whether something can be built is basically a solved question now. Not literally 100%, but close enough that it's stopped being the interesting constraint. The real question — the one that actually separates good outcomes from wasted sprints — is whether it should be built. That's the highest-leverage skill left for engineers and leaders in the AI era, and it's what the rest of this post is about.

Why "find the task" beats "pick a tool"

I keep seeing the same failure pattern in AI transformation work: a team picks up a tool — an agent framework, an n8n instance, a Claude Code subscription — and goes looking for something to point it at. They land on whatever annoyed them that morning, or whatever a YouTube video demoed that week, and ship something that saves ten minutes. Meanwhile the task actually costing the business ten hours a week sits untouched, because nobody ever went looking for it systematically.

The order matters. Diagnose before you prescribe. Find the leverage before you touch a tool. That's the whole first move of any engagement I run, and it's cheap enough that a team can do the first pass themselves in an afternoon.

The three pillars of personal friction

Most people are sitting on at least ten hours a week that AI could already reclaim — they just can't see it. It doesn't show up as one big obvious time sink; it's scattered across small tasks done so often they've stopped registering as work at all. To surface it, scan a calendar, an inbox, and a to-do list for three shapes of friction:

• Repetitive — same steps, consistent inputs and outputs, every time.
• Time-consuming — high total annual hours, regardless of how often it runs.
• Error-prone — manual entry, handoffs, or conditional logic where mistakes creep in.

A task that shows only one of these is worth a note. A task that shows two or three is very likely worth building first.

Repetitive. Same task, same steps, done on a daily or weekly cadence, with consistent inputs and consistent outputs. Pulling action items out of a meeting transcript. Sending the identical welcome email off the identical form trigger. Copying new data into a spreadsheet in the same layout every time. The person or the numbers change; the process doesn't. Consistency is what makes a task tractable to automate — you don't need a task to happen often for it to qualify, just for it to happen the same way each time.

Time-consuming. Total time cost, not frequency, is the metric that matters. A task done monthly that eats half a day still costs 48 hours a year — often more than a task done weekly for thirty minutes. A weekly report pulled from three sources, cleaned, charted, and sent might be an hour a week — 52 hours a year — hiding in plain sight because it never feels urgent enough to fix. Client onboarding at two hours per new client behaves the same way: low frequency, real annual cost. Add it up before you decide it's not worth the build.

Error-prone. Manual data entry, handoffs between people or systems, and conditional logic under time pressure are where mistakes live — and mistakes cost more than the redo. Typing invoice line items by hand risks a wrong amount or the wrong client. Routing a new lead based on company size, industry, and stated need is conditional logic; done manually while busy, it drifts. These tasks are worth automating twice over — once for the time saved, once for the cost of the errors they were quietly producing.

Scoring what you find

Run the audit, then triage with a simple rule: one pillar makes a task a candidate; two or three pillars makes it a near-certain high-value target. This is deliberately a coarse first filter — it's meant to compress a long list of vague complaints into a short list worth actually scoping, not to be the final word on priority. (Impact/confidence/ease scoring comes next, once the candidate list is short enough to be worth the extra rigor.)

The angle I'd add on top of this, from the engineering side: the audit is only useful if what gets built afterward is verifiable. A repetitive task automated with an opaque model call that occasionally hallucinates a number isn't leverage — it's a new, hidden error-prone task wearing a demo's clothing. The three-pillar audit tells you where to look. Whether the fix earns back the trust it costs is a build-quality question, and that's where most automation projects — including some I've had to unwind — actually go wrong.

That's the wedge this blog will keep coming back to: finding the hours is the easy half. Compressing them without introducing a new kind of risk is the actual job.