What Survives When You Come Back

Around 2010 I was deep in early microcontroller work and the first wave of consumer 3D printers. RepRap kits, hand-tuned Arduinos, the whole makerspace scene of that era. Then I stopped. For more than a decade I did not touch any of it.

Recently I picked it back up, not for work but for the house. An ESP32 controller for my mini-splits, then a custom epaper dashboard on a reTerminal E1002 for the things I want to know before I leave the house. The toolchains had moved on without me. ESPHome did not exist the last time I cared. The board ecosystem was unrecognizable. The specific knowledge I had built up in 2010 was, for practical purposes, gone.

What was not gone was the shape. I still knew what a microcontroller program looked like end-to-end. I knew how a sensor talked to a controller talked to a display, where the timing risks lived, which problems were hard and which ones were only libraries. That meant I could describe what I wanted to Claude at the level where the decisions lived. I could also notice quickly when the answer it gave back was for a slightly different system than the one in my head. Weekend projects, not month-long relearning curves.

What Decayed and What Held

The decayed parts are the ones I would have predicted. Specific toolchains. Specific SDKs. Which header file to include for I2C on which platform. The version-by-version drama of the Arduino IDE. The names of the libraries that were ascendant in 2010 and the names of the libraries that replaced them. All of that was muscle memory at the time, and none of it survived ten years of disuse. It would not have survived two.

What held was different in kind. The picture of how a small embedded system works end to end. Sensors produce data on some cadence. A controller polls or interrupts on that data, transforms it, makes a decision, drives an actuator or a display. There are timing budgets at every step. There are voltage levels that have to match. There are buses with addressing and arbitration. There is a debugging discipline that starts with “is the wire even connected” and ends with “the firmware is doing exactly what I told it, which is the wrong thing.”

None of that is a fact you look up. It is a way of seeing the problem. It survived because it was never tied to any specific chip or library. It was the shape underneath all of them.

The implementation surface is what AI is good at rebuilding. The shape is what AI cannot give you, because it cannot know whether the system in its head matches the system in yours.

The Mini-Split Worked First Try

The mini-splits in my house are Mitsubishi Heavy Industries units. There is a service port on the indoor unit, CN102, that exposes the internal control bus. With an ESP32 and the right firmware you can sit on that bus, read state, and send commands. The MHI-AC-Ctrl-ESPHome project is the community-maintained integration for exactly that.

I expected a fight and got the opposite. I followed the wiring guide, flashed the ESP32, edited the config by hand for my units, and the data showed up in Home Assistant like magic. No AI anywhere in that loop. The project was documented well enough that a returner could read each step and understand what it was doing and why.

What made it easy was not something in my head. It was that someone had done the hard work of understanding the bus and then written it down: the wiring, the timing, the config, the failure modes. The legibility lived in the world, not in me. My retained sense of how an embedded system fits together let me move through the guide fast, but the trail had already been cut. A decade away from the craft cost me almost nothing here, because the craft had been documented by someone who never left.

There is an operations point buried in that. A well-documented, well-understood system is the one anyone can pick up and extend, with or without a gap in their memory, with or without AI. Legibility is what makes a thing resumable. It is the same property that, when it is missing, keeps a process stuck on the to-do list for years.

The Dashboard Came Before the Hardware

The reTerminal project ran the other way, and it was one of the first things I built with an AI agent doing the heavy lifting.

It started with a specific, slightly silly problem. The tram I take crosses a drawbridge, and when the bridge opens for boats the line backs up behind it. If I knew before I walked out the door that the line was disrupted, I could take another route or wait and leave later. That was the whole seed. A small thing I checked manually some mornings and forgot on others.

Once I was building an “on my way out the door” display, the rest suggested itself. Show the day’s calendar. Pull the weather from OpenWeather. And because it cost almost nothing to add, throw in some AI-generated imagery to make the thing pleasant to look at. A glanceable panel by the door: tram status, weather, what the day holds.

The shape of that was clear before I knew what would run it. Low power, low light, no fan, no glowing rectangle. E-paper, refreshing on a slow cadence. And the architecture underneath it is backend, which is where I am comfortable. A server gathers the data and renders the entire screen to an image every ten minutes, and the device’s only job is to fetch that picture and show it. That split, render on the server and treat the display as dumb, is a systems decision, and it is the kind of decision my head still makes easily.

The part I am not good at is the front of it. My instincts run to backends and systems. Visual layout, what a display owes the eye at a glance, typography that reads from across a room, none of that is native to me. That is the surface I lacked. It is also exactly the surface the AI built. I wrote a specification for the zones and the rules, what dominates, what hides when there is nothing to show, how the tram indicator behaves, and the rendering came back built to it.

That is the gap-returner pattern and the not-my-strength pattern at once. The architectural view, the data flow and the render-on-server, dumb-device split, did not need rebuilding or supplying. It was already mine. What I did not have, the implementation surface and the visual craft, is what AI produced on demand. The board search was downstream of the shape: I needed e-paper, wifi, enough memory to render a layout, a form factor I could mount cleanly. The reTerminal E1002 was the answer, and a different board would not have changed the system I was describing.

The order is the point. The shape came first. The implementation, including the parts of it I am weak at, followed. If the shape had not been there, no amount of AI would have produced the right system, because there would have been no spec for “right” to measure against.

This Is Not a Hardware Story

The pattern generalizes past microcontrollers, and I think this is where it matters most for people who would not call themselves builders.

The accountant who left finance ten years ago still knows how a P&L breathes across a month, where the accruals hide, which line items are the ones that move when something is off. The specific software has changed. The mental model has not. With AI, the surface of “rebuild the working spreadsheet, write the SQL, draft the variance commentary” is hours of work, not weeks. The judgment that says “this number is wrong before I can tell you why” is the part nobody can hand them back.

The designer who stopped coding when frontend frameworks went from jQuery to a new stack every eighteen months still knows what a clean interaction feels like, what a layout owes a user, where complexity should be hidden and where it should be surfaced. The framework of the month is now a thing Claude will scaffold in minutes. The taste, and the systems-thinking about how a UI behaves as a whole, did not go anywhere.

The product manager who used to ship features and then moved into a role of mostly meetings still knows how a release lands. How to scope, how to cut, where the integration risks live, which assumptions kill a launch when they are wrong. The Jira tickets and the figma boards and the spec templates all rotated. The shape of shipping did not.

In all three cases the question is not whether the gap disqualifies them. It does not. The question is whether they still hold the shape of the thing they used to do. If they do, AI is the friendliest tool they have ever had. It rebuilds the decayed surface on demand and leaves the part that mattered intact.

The Throughline

This piece is the personal evidence for an argument I made more abstractly in The Architecture Was Always the Job. That piece said architecture is the surviving skill once building gets cheap. This one says the same thing from the other direction. The skill that survives a decade of disuse is the skill that was always doing the load-bearing work, and AI is what makes that survival actionable instead of nostalgic.

It also connects back to When Building Gets Cheap. That piece argued that the cost of building has collapsed. The under-noticed corollary is who benefits most from the collapse. It is not only the people already in the craft. It is the returners, the ones who have the architecture and lost the surface. For them the collapse is not a marginal speedup. It is the difference between a project being possible and not.

The good news, if you used to build something and stopped, is that you are probably closer to picking it back up than you think. The part of the skill that took you years to build is the part that did not decay.

If this resonates, if you used to build something and have been wondering whether the time away disqualifies you from picking it back up with AI tools, reach out at hello@escapecommand.com.