Coding Agents Made Reverse-Engineering Cheap — Here's What Changes
Simon Willison's observation that AI coding agents have collapsed the cost of reverse-engineering home devices isn't just a curiosity — it rewrites the ROI math for a whole category of side projects.
By TRAGenX Desk
In a short post this week, Simon Willison pointed at a pattern he keeps hearing about secondhand: people using coding agents to reverse-engineer and automate devices in their own homes. It sounds like a hobbyist footnote. It's actually a clean illustration of what happens to a whole category of engineering work when the cost of writing code drops.
The old math didn't work
Reverse-engineering an undocumented device API was never impossible. Anyone comfortable with a browser's Network tab and a disassembler could capture the calls a smart thermostat or heat pump made to its cloud backend and rebuild a client for it. The blocker was never capability — it was ROI. Every experienced engineer knows the second half of that story: undocumented APIs change without warning, and taking one on means signing up for open-ended maintenance on something you don't control. If the initial build takes a weekend and the payoff is one smart-home integration, that trade rarely penciled out.
What actually changed
The effort to get a simple automation working has dropped, as has the cost of trying and failing to get it to work.
— Simon Willison
That's the whole shift in one sentence. Coding agents don't make undocumented APIs more stable — they make the *attempt* nearly free. If a first pass fails, or the vendor changes the API in six months, redoing the work is no longer a weekend you have to justify. It's an afternoon, or less. Lowering the cost of failure changes which projects clear the bar for starting, independent of whether the underlying risk changed at all.
A working example: rebuilding a heat pump's cloud API
The pattern isn't hypothetical. When Hitachi migrated its heat pump control system to a new ATW-IOT-01 module and CSNet Manager cloud service with no public documentation, it broke every existing Home Assistant integration for that hardware. Developer Marco Mornati documented rebuilding it from scratch: capturing REST calls from browser DevTools, feeding the unminified JavaScript and sample JSON responses to Claude Opus for an architectural spec, then implementing iteratively with Claude Sonnet and GitHub Copilot under human code review. The result — climate entities per zone, 40+ sensors, silent-mode and fan-speed control — shipped as a real Home Assistant Community Store component with 166+ closed issues, 29 releases, and 11 contributors.
The risk didn't disappear — the threshold did
None of this makes undocumented APIs stable. Hitachi can still change CSNet Manager tomorrow and break the integration again. What changed is that breaking it is no longer a crisis — it's a re-run. That's the underrated part of the agentic-coding story: the interesting effect isn't agents writing code faster than humans on tasks people were already funding. It's agents pulling a long tail of previously-not-worth-it projects over the line, because the cost of being wrong collapsed along with the cost of being right.
For builders, that's the actual signal buried in an anecdote about smart thermostats: any project you shelved because the maintenance tail looked too long is worth re-pricing under current tools, not just the ones on your roadmap.
FAQ
Frequently asked questions
- Does reverse-engineering an undocumented API with an AI coding agent violate a device's terms of service?
- It depends on the vendor's terms and jurisdiction — reverse-engineering for interoperability has different legal treatment in different regions, and cloud-service ToS vary widely. Check the specific vendor's terms before publishing or distributing an integration built this way.
- Why does an unofficial API integration still need maintenance if an agent built it quickly?
- The API itself is still controlled by the vendor and can change without notice, exactly as before. What's changed is the cost of rebuilding when that happens — not the underlying instability.
- Is this pattern specific to home automation?
- No — the Hitachi/Home Assistant case is just a visible example. The same cost collapse applies to any undocumented-API or legacy-system integration where the blocker was effort-to-benefit ratio rather than technical feasibility.
Sources