There’s an uncomfortable conversation almost nobody is having about AI and automation: the real cost isn’t building the solution, it’s keeping it alive.
This week, engineer James Shore published an article that went viral on Hacker News with a simple but devastating argument: an AI agent that writes code is useless if what it produces costs you more to maintain than it saved you to build. And while the article is about programming, the principle applies to any automation you bring into your business.
Let’s unpack it, because if you’re thinking about automating something in your company, this will save you a lot of headaches.
The trap of “it’s done”
When someone sells you an automation —whether it’s a bot, a workflow, or an AI agent— what you see is the demo. It works. It does what it promised. You sign, you pay, you go home happy.
And three weeks later the problems begin:
- The bot starts failing on cases that weren’t considered.
- An API changes and everything breaks.
- No one knows how to fix it because the code is unreadable.
- The original provider doesn’t जवाब, or charges a fortune for every tweak.
- You end up paying someone to do manually what the automation was supposed to do on its own.
This is what the software world calls technical debt. And with the arrival of AI agents that generate code and automations at lightning speed, the problem is multiplying.
Why AI makes the problem worse (if you don’t use it properly)
Modern AI agents are incredibly fast at generating solutions. In five minutes, they’ll set up a workflow that connects your CRM to your email and sends automated replies. Magic.
The problem is that speed hides an uncomfortable truth: generating code or automations is easy. Maintaining them is hard.
A poorly supervised AI agent produces automations that:
- Work in the happy path, but break at the edges. When a strange email comes in, a customer has a name with special characters, or an invoice uses a different format, everything falls apart.
- Are a black box. No one understands how they’re built. When something needs changing, you have to rebuild from scratch.
- Depend on opaque services. If the provider raises prices, changes the API, or shuts down, you’re stuck.
- Have no logs or alerts. When they fail, you don’t find out until a customer complains.
It’s like buying a car that runs perfectly for a month and then starts acting up, and no mechanic can fix it because it’s made of parts only the seller understands.
How to tell a good automation from a ticking time bomb
Before approving any automation in your business, you should be able to answer these questions. If the answer is “I don’t know” or “the provider won’t say,” that’s a bad sign:
| Question | Why it matters |
|---|---|
| Who can modify it if the provider disappears? | Avoids vendor lock-in. |
| What happens when something fails? Does it alert me or do I find out through a customer? | Without monitoring, failures pile up silently. |
| Is it documented in a way a human can read? | If only the AI that created it understands it, you have a problem. |
| Does it use open-source tools or am I tied to one vendor? | Lock-in means price hikes and zero flexibility. |
| How much monthly maintenance time does it require? | If the answer is “none,” be skeptical. If it’s “a lot,” too. |
| How does it handle edge cases or unexpected errors? | 80% of failures come from the 20% of edge cases. |
The calculation almost nobody makes: real ROI
People calculate automation ROI like this:
“It saves me 3 hours a day, that’s 60 hours a month, at €30/hour that’s €1,800 saved. The automation cost me €2,000. I’ll make it back in just over a month.”
The real calculation should be:
“It saves me 3 hours a day. But it requires 4 hours a month of maintenance, plus 1 hour whenever something breaks (which happens twice a month), plus the mental cost of not fully trusting it and checking the results. That’s 10 real hours of cost per month, not zero.”
A good automation has low, predictable maintenance costs. A bad one looks cheap at first and then eats your hours and your patience.
What makes an automation last
After years building automations for SMEs, there are clear patterns that separate a solution that holds up from a toy that breaks in three months:
1. It’s built on foundations that aren’t yours, but aren’t locked away either. The best automations use open-source tools and open standards. At Studio SmartWork, we work with n8n for exactly this reason: if tomorrow you decide to change provider, you take everything with you. You’re not locked in.
2. It has observability from day one. A serious automation tells you when it works, when it fails, how much it processes, and what it’s costing. If you don’t have visibility, you don’t have control.
3. It’s designed to fail gracefully. Yes, you read that right. Every automation will fail at some point. The difference between a good one and a bad one is what happens when it does: does the whole system go down, or does it enter a safe state, alert you, and keep running the rest?
4. It’s built by someone who’s still there afterward. This is key. An automation is not a product you buy once. It’s a living system. It needs someone who understands it, cares for it, and improves it as your business changes.
The mistake of thinking about automations as “set and forget”
The dream of “set it up and forget it” is exactly that: a dream. Businesses change. APIs change. AI models change (sometimes overnight). Regulations change.
What is realistic is this: a well-built automation requires little maintenance, but steady maintenance. Like a car. You don’t do anything to it every day, but you service it when it’s due. And if you take care of it, it lasts for years.
That’s the difference between buying a tool and working with someone who operates the automation with you. The tool is yours on day one and your problem on day thirty. An operated automation is a service: someone builds it, monitors it, adjusts it, and improves it.
What you should demand before automating anything in your business
If you’re going to put an automation into your operations, ask for this in writing:
- Clear ownership of the code and configurations. You should be able to take it with you if you want.
- Documentation readable by humans, not just by the AI that generated it.
- A monitoring and alerting plan. How will you know something has failed?
- A support and maintenance agreement. Who, when, at what cost.
- A rollback strategy. If something goes wrong, how do we go back to the previous state?
- Response times for critical incidents. Especially if the automation affects customers or sales.
If a provider can’t give you this, they’re not selling you a professional automation. They’re selling you a prototype.
The underlying lesson
The debate Shore’s article is opening up matters because it marks the end of the “wow, look what AI can do” phase and the beginning of the “okay, but is this sustainable?” phase.
AI has brought the cost of building automations down to almost zero. That’s great. But it has raised the risk of building automations that look like they work and turn into a nightmare six months later.
The right question is no longer “can I automate this?” The answer is almost always yes. The right question is: “can I automate it in a way that still works a year from now without bankrupting us in maintenance?”
That’s the difference between an automation that transforms your business and an expensive experiment you end up switching off.
And it’s exactly the kind of problem we’ve been thinking about since 2021: how to build things that work well, are easy to maintain, and keep delivering results months after going live. Because in the end, an automation only has value if it gives you time back, not if it takes it away through another door.