Your Smart Home Is Now Worth Automating: Why Agents Just Flipped the Math

Here is the thing experienced programmers understood that made them avoid this work: the difficulty was never the initial reverse-engineering. It was everything after.

Willison describes the old calculation precisely. Before agents, reverse-engineering home devices was entirely possible. The problem was the return on investment. Was it really worth all that effort? And more importantly, any experienced programmer knows that undocumented, unstable APIs like that may well change or break in the future. You were not signing up for one afternoon of work. You were signing up for a frustrating cycle of maintenance.

That second point is the one people underrate. When you reverse-engineer a device, you are building on an interface the manufacturer never promised to keep stable. They ship a firmware update, they rename an internal endpoint, they add an authentication step, and your careful automation breaks. Now you are back in the code you barely understood the first time, six months later, having forgotten how it worked.

A professional developer looks at that and does the sensible thing: declines. The one-time build might take a weekend. The lifetime maintenance turns it into a part-time job you did not want. For a single household automating a single thermostat, no rational person spends that.

So the ceiling on home automation was never really technical. It was a labor-cost ceiling. The tasks sat in a specific dead zone: valuable enough that you wanted them, not valuable enough to justify the human hours. That dead zone was enormous, and almost everything interesting lived inside it.

There is a lazy version of the coding-agent story that goes: agents make programmers faster. True, and boring. The version that matters here is different.

When the cost of producing a unit of code approaches zero, the set of tasks worth attempting expands. Tasks that were uneconomic become economic. This is the second-order effect, and it is the actual story. It is not that a known task got cheaper. It is that a whole category of previously-abandoned tasks crossed the line into feasibility.

Think about what changes in the maintenance calculation specifically. The old objection was that unstable APIs would break and you would have to re-do the work. But if re-doing the work is now cheap, the maintenance objection largely dissolves. Your device firmware updated and broke the automation? You point the agent at it again. The thing that made a professional say no, the open-ended maintenance commitment, is exactly the thing that agents defang.

This reframes what you should even consider automating. The old instinct was to ask: is this worth a serious engineering effort? The new question is smaller and more permissive: is this worth an afternoon of me watching an agent poke at my device? For a surprising number of household annoyances, the answer is now yes.

Wardley Mapping is useful here if you want the abstract version. A component that was custom-built and expensive slides toward commodity. The custom, artisanal work of hand-reverse-engineering a device moves toward something closer to a utility you can summon. What sits on top of a commodity is where new behavior appears, and the new behavior here is ordinary people automating things they own.

Concretely, the tasks that fit this new economic zone share a shape. They are self-contained, they touch a device you physically control, and the failure cost is low. Start there.

Good first candidates:

• A device with an app but no automation hooks. The app talks to the device somehow. An agent can watch that traffic and work out the requests, then reproduce them in a script you control.
• A local sensor whose data you want elsewhere. Energy monitors, air-quality sensors, and weather stations often expose numbers on a local network without a friendly export. Pulling that into a spreadsheet or a dashboard is a classic afternoon-with-an-agent task.
• A schedule the manufacturer refuses to give you. The vacuum that only supports the schedules the vendor imagined. The light that has three presets when you want a fourth.

The common thread: the device is yours, the data crosses your own network, and if the automation fails, nothing catastrophic happens. A missed vacuum run is an annoyance. A misfired script on a device you do not fully control is a different risk category.

What to keep off the list, at least while you are learning:

• Anything touching a cloud account you could get locked out of. Reverse-engineering a service's private endpoints can trip abuse detection and cost you the account.
• Anything with a physical safety dimension: locks, garage doors, heating elements, medical devices. The Autonomy Spectrum applies. Most failures come from deploying at the wrong point on the spectrum, and a door lock is not where you want your first experiment running unsupervised.
• Anything where a broken automation causes silent, expensive drift. A thermostat that quietly overshoots for a week is worse than one that visibly refuses to respond.

Willison's framing is about the household scale specifically, and that is the right scale to start at. The economics flipped hardest for exactly the low-stakes, personal-scale tasks that professionals always ignored.

You should not read any of this as the maintenance problem being solved. It was not solved. It was reassigned.

The unstable API is still unstable. The manufacturer will still ship a firmware update that breaks your automation. What changed is that the cost of responding to that breakage dropped from a dreaded weekend to a short re-run. The treadmill is still there. You are just no longer the one paying full price for each lap.

That distinction matters for how you set expectations. If you treat your agent-built automation as a finished product, you will be annoyed every time it breaks. If you treat it as a living arrangement that occasionally needs a re-poke, the whole thing feels fine. The mental model is closer to weeding a garden than building a wall.

You'll want to build for cheap re-derivation from the start. That means keeping notes on what the agent figured out, in plain language, so that when the device changes you can hand the agent the original context and say do this again, it broke. The single most useful artifact is not the working script. It is the description of how the agent discovered the interface, because that is what makes the next repair cheap.

There is also a quieter risk. Because each repair is cheap, you accumulate more automations than you can mentally track. Ten small scripts poking at ten devices is ten things that can silently break. This is a household-scale version of the Shadow Agent Problem: automation nobody is formally responsible for, running with real access, until the day one of them misbehaves and you have forgotten it exists. Keep a list. Know what is running.

Let me make this concrete with the shape of a real session, because the abstract version undersells how ordinary it feels.

Say you have a smart plug that measures power draw, and its app shows you a live wattage number the device itself refuses to export. Here is roughly how the afternoon goes.

Step 1: Show the agent the problem, not the solution. You describe what you want (the wattage number, pulled every minute, into a file) and what you have (the device, the app, your home network). You do not tell it how. Working out how is the part it is good at.

Step 2: Let it observe. The agent will typically want to see how the app talks to the device. This is the reverse-engineering step, and it is the one that used to eat a professional's weekend. Expect this to involve some back-and-forth where the agent asks you to do something in the app while it watches.

Step 3: The first attempt will be wrong. This is the gotcha to internalize before you start. The initial script will make an assumption that turns out false: the device wants a token, the response is in a format the agent guessed incorrectly, the endpoint only answers on a specific part of your network. This is normal. The cheapness of the whole endeavor is precisely what lets you iterate through three or four wrong attempts without it mattering.

Step 4: Confirm it does the boring thing reliably. Once it works once, watch it work ten times. Undocumented interfaces are flaky. An automation that succeeds once and fails silently on the second run is worse than no automation, because you will trust data that stopped arriving.

Step 5: Write down how it worked. Not for elegance. For the re-derivation you will need in three months. This is the Feynman check: if you cannot get the agent to explain, in plain terms, how it is talking to your device, you do not yet understand what is running in your home. Close that gap before you walk away.

The home-device story is the visible, friendly end of something broader, and it is worth naming what the broader thing is.

Every domain has its own dead zone of tasks that were valuable but not valuable enough to justify a programmer. Small businesses with software that almost does what they need. Researchers with data trapped in a format nobody will export. Individuals adapting a tool to a workflow the vendor never imagined. All of these lived in the same labor-cost dead zone as your thermostat. All of them just got cheaper to attempt.

Willison's home-automation anecdotes are compelling precisely because they are so mundane. Nobody is going to fund a startup to automate one person's vacuum. That is the point. The tasks migrating into feasibility are the ones too small and too personal to have ever been a business. They were left undone not because they were hard but because no economic actor existed to do them. Now the individual is that actor, at a cost they can absorb.

There is a tension the industry has not resolved. A day when the biggest AI news was a 2.4-trillion-parameter model going open-weight got written up as a quiet day because it landed days after a larger release. The frontier keeps sprinting on raw capability. But the change in your house does not come from a bigger model. It comes from a capable-enough model wired into your devices with enough autonomy to poke, observe, and retry. The value lives in that wiring, the harness, not in the model's raw intelligence.

That is the shift to watch. Not what the models can do in a benchmark, but what ordinary people will now attempt because the cost of attempting collapsed. Your smart home is a small, early, extremely legible example. There will be many more, and most of them will look just as unglamorous as automating a vacuum.