Coding agent driven automation

The automation you don't maintain, and why cheap tokens make it work.

Say you run a furniture site. You sell what four different suppliers make, and your job, the part that never ends, is keeping the catalog honest: the right products in stock, photos that match, prices that are current.

Here's the problem. Those four suppliers agree on nothing. One has a clean API. One emails you a spreadsheet every Monday. One has the images, but they're zipped up behind a login that times out. The fourth gives you a PDF. An actual PDF, in 2026. And on top of all that, the owner texts you things like "put the gray sectional from supplier two up" and "pull the discontinued recliner before someone orders it."

That last part is the quiet killer. It's not that any one of these tasks is hard. It's that they never arrive in the same shape twice, and there's always a human in the loop with a specific, slightly irregular ask. Too fiddly to do by hand without losing your evenings. Too irregular to automate the way we normally would.

The two ways this usually goes

The first instinct is to build a pipeline. You encode it all: a connector per supplier, a parser for the spreadsheet, a scraper for the login, a PDF reader for the one that hates you. You map every field and wire it to a schedule. It works beautifully, right up until supplier three redesigns their login page, and your scraper starts writing empty strings into the catalog at 2am and nobody notices for a week. A pipeline is a snapshot of how the world looked the day you wrote it. Unfortunately, the world doesn't hold still.

The second instinct, lately, is to hand the whole thing to an autonomous agent and walk away. The trouble is that a furniture catalog is made of facts that cost money when they're wrong. A price off by a digit, an image on the wrong SKU, a discontinued item still taking orders. I'm not comfortable letting a process I can't watch run unattended over that, and if you're honest, neither are you. "Mostly right" is a fine bar for a lot of things. It's not the bar for the number a customer pays.

So you're stuck between automation too brittle to trust and autonomy too loose to trust. Most of the genuinely annoying work in the world lives in that gap.

The third way

There's a third option, and it inverts the oldest assumption in automation. Automation has always meant capturing a process once so you never have to work it out again. You work through it a single time, freeze the result, and the frozen thing runs freely after that. The freezing part of this is the problem.

Coding agent driven automation makes the opposite bet. CADA, if you want the acronym. Nothing gets frozen. The agent works the process out from scratch on every run, and you let it, because working it out from scratch has finally gotten cheap enough to do that often.

You're not maintaining a captured process. Instead, you orchestrate. You hand the agent the day's problem in plain language: "get the gray sectional from supplier X up." The agent owns everything between that sentence and the finished result. Which supplier, how their data comes out today, how to get the images, how to put it on the site. Then, the part that matters, it checks its own work before it hands anything back.

Concretely: the owner texts "gray sectional, supplier two." Supplier two is the Monday spreadsheet. The agent pulls the row, maps the fields, and publishes. Then it checks: it re-reads the live product page, $1,290, and re-reads the spreadsheet, $1,920. They disagree. A digit went missing between the cell and the site. It fixes the listing and republishes, and the first you hear of any of it is the approval sitting in your queue, already correct.

Isn't this just using a coding agent?

Fair question. Plenty of people already open a coding agent and ask it to do a task. If that's the bar, then yes.

But a one-shot prompt hands the agent a task. CADA hands it a job, and three things change.

It owns a standing responsibility, not a request. The job isn't "get this SKU up." It's "keep the catalog correct," with no end date. Today's SKU is one instance of a duty that doesn't stop, and the agent is on the hook for the duty, not the keystroke.

It owns its own tooling. The agent keeps a set of tools and decides, every time, whether to reuse one, edit one, or write something new. When supplier three redesigns their login and a tool breaks, you don't open an editor. The agent notices, fixes or rebuilds it, and carries on. You still hold the keys and the standing job, but the brittle middle, the part that used to break at 2am, maintains itself.

It owns the accuracy. When you one-shot a task, you're still the one who checks it. Here the checking is the agent's job, but only if it checks the right way: against an independent source, not against its own reasoning. It re-pulls the live page and the supplier's number and compares them, instead of trusting the figure it just decided on. That catches the mechanical mistakes, a dropped digit, an image on the wrong SKU, a field left blank. What it can't catch alone is an error it will repeat: misread the PDF once and the check misreads it the same way. That ceiling is exactly why you keep the last word. The check makes you the approver instead of the QA department. It doesn't make you optional.

None of those three is exotic on its own. Agents call tools, write code, and check their output. What's new is putting all three under one standing job, and moving yourself from the middle of the work to the end of it.

It only works if the agent can reach

CADA can only own what it can actually touch, so two things have to be true before any of it pays off.

First, the agent needs a real way to act: a supplier API, a login it can drive, a CMS it can push to. If putting a product on the site is a manual click in some tool with no programmatic access, the agent can't own that step, however clever it is. Usually you solve this once, by giving it the keys or letting it build the access it needs.

Second, it needs a way to check, and the check has to be independent. Publishing the SKU is only half the job. Querying the DB and comparing it with the supplier's PDF. Pulling the page back up, reading the price and images off it, and comparing them against the spreadsheet. No way to verify, no way to trust.

When this is the wrong tool

Coding agent driven automation is certainly not the answer to everything.

It earns its keep in one corner: work that is high in variability and low in volume. The long tail. The furniture catalog with four mismatched suppliers and an owner who texts you one-off requests lives there. So does most of the irregular glue work that fills a small operation's week.

Move out of that corner and the math changes. Fifty thousand identical SKUs from one clean API every night? Don't point an agent at it. Build the pipeline. It's uniform and high volume, and a real program written once will beat an agent re-deriving the same steps fifty thousand times. And if the task is both rare and simple, just do it yourself. You don't need any of this to fix one typo.

Knowing which corner you're in is most of the skill. CADA doesn't replace pipelines. It covers the messy ground pipelines were always bad at, the ground we used to just eat by hand.

Why this works now

I've been dodging the obvious objection. Cost. Wouldn't having a coding agent handle every small task start to get expensive?

A year ago I'd have said yes. However, I don't think that's the case anymore for two reasons. First, coding agents are (at the time of writing this) still subscription-based. A small operation's monthly task list would likely fit into whatever AI subscription tier they already have. Second, open source models keep getting better. You're one Mac Mini away from never worrying about tokens again (not a paid promo).

Also, look at what it replaces. The expensive part of the catalog was never the compute. It was a person, doing irregular cross-supplier glue work and then carefully checking it, hour after hour. CADA takes that costly human work, the judgment and the glue, and handles it itself. You're arbitraging expensive attention against cheap computation, and the spread is enormous.

Summary

Stop thinking of yourself as the person who builds and runs the automation, and start thinking of yourself as the one who directs it. You hold the intent and the last word. The agent holds the brittle middle, its own tools, and the first pass at checking itself. For the messy, irregular, accuracy-sensitive work that used to eat your week, and that no pipeline was ever going to cover, that's a much better seat to be in.