When AI automation is actually worth it
You spent the weekend wiring up an agent. It scrapes the GitHub issue, drafts a fix, opens a PR, posts a Slack message. It is genuinely impressive. You demoed it on Monday and a colleague asked whether they could borrow it.
Then you used it twice.
This is the part of the AI economics conversation nobody runs the maths on. The pilot is cheap. The demo is cheap. The agent is impressive. And the unit economics quietly fall apart somewhere between "this works" and "I rely on this."
The mortgage you forgot you signed
Every AI workflow is a mortgage. You pay a down payment in build time. Then you pay interest forever — tokens, API calls, the half-day every quarter when the upstream model changes and your prompt drifts. In return you get a per-instance saving when the thing actually runs.
Most engineers do the maths on the down payment and ignore the interest. The interest is where AI is unlike anything else you have shipped.
Sameer Khan's piece on the AI cost illusion puts a number on it: enterprise AI spend roughly tripled in 2025, and agentic systems can run five to twenty-five times the per-task cost of a simple chatbot. SaaS bills as a flat line per seat. Token-billed agents bill as a curve, and the curve depends on retries, retrieval, reasoning steps, and how many times your loop forgot what it was doing and asked again.
If you have ever watched a tool burn four dollars of inference to do something a junior engineer would do in fifteen minutes of attention, you have already met this curve.
The break-even formula nobody runs
Dheeraj Sharma's break-even framework on GenAI Unplugged tells a story I have lived too many times. He built an n8n workflow to format his podcast notes — Sheets, GPT calls, Notion, custom rules. It saved him fifteen minutes per episode. He publishes twice a month. The break-even came out at thirty-two months.
His framework is three lines on a napkin:
break_even_months = setup_time / (time_saved_per_instance * frequency_per_month)Three variables, one threshold. Past six months, he says, walk away.
Six months is a sensible default. I would tighten it for AI. The model you built around will be deprecated, repriced, or replaced inside a year. Your prompt will rot. The library you used to glue it together will release a breaking version. The realistic window in which an AI automation stays unmaintained-but-working is closer to four months than six. Plan accordingly.
A worked example you have probably considered
Auto-generating PR descriptions from the diff. Two hours to wire it up. You write five PRs a week. You spend roughly three minutes on a description and the AI version saves you two of those.
setup = 120 min
saving = 2 min per PR
frequency = 20 PRs / month
break-even = 120 / (2 * 20) = 3 monthsThree months. That clears the bar — but only if you actually write twenty PRs a month. Cut your estimate in half (Sharma's heuristic, and an honest one — engineers chronically over-estimate how often they do anything that is not a meeting). Now it is six months. Now factor in the day you will spend when the API changes. Now factor in the times the description is wrong and you rewrite it by hand anyway.
This is still a borderline-good automation. Most are not. The ones that look impressive on YouTube usually live in the territory of "saves seven minutes once a fortnight" — territory where the maths does not close.
The two automations actually worth building
After running this calculation honestly across my own work, two patterns survive.
The first is high-frequency, low-value-per-instance work where the saving is tiny but real and the volume is huge. A script that triages incoming Sentry errors against your changelog and tags them with a likely owner before a human looks. Each instance saves maybe ninety seconds. You get a hundred a day. The maths is trivial.
The second is low-frequency but catastrophic-when-skipped work — the things humans forget to do under pressure. Pre-deploy checklists. Migration safety audits. Security review of a new dependency. The "saving" here is not minutes, it is an outage you did not have. These break Sharma's formula because the per-instance value is bimodal: most of the time it saves you nothing, and once a year it saves your week.
Everything else — the agent that drafts your standup, the bot that auto-replies to friendly Slack messages, the workflow that summarises an article you would have skimmed in two minutes — is dopamine. It feels like leverage because building it feels like progress. You watched the tutorial. You learnt the tool. The actual return is a rounding error.
A prediction you can disagree with
Inside eighteen months we will see a quiet die-off of personal AI agents. Not the productised ones from labs and big platforms — those have the engineering budget to keep up with model churn. The bespoke ones. The n8n graphs and LangChain scripts and home-built Claude agents that took a weekend to build and now sit in a cron somewhere costing forty dollars a month in tokens to do something the owner could have done in ten minutes a week.
Most of them will not be deleted. They will be ignored, then quietly broken by a model deprecation, then forgotten. The AI automation graveyard is going to be a real category, and most of us will have one.
Disagree if you like. Run the maths on three of yours first.
The small move I'd start with
Open the automations you have built in the last six months. For each, write down setup time, time saved per instance, and honest monthly frequency. Apply Sharma's formula. Anything past four months break-even, retire it without ceremony.
For the next one you are tempted to build, estimate frequency from the last quarter, not from the version of yourself who is excited to have built the thing. Halve it.
For everything you keep, instrument the cost. Token spend, latency, failures. AI workflows do not behave like SaaS — they behave like a marginal-cost business — and you cannot manage what you cannot see.
Most automations are not worth it. The ones that are, are quietly worth a lot. The trick is being honest enough to tell the difference before you have spent the weekend.
Sources I drew from: