What Survives When You Come Back

Around 2010 I was deep in early microcontroller work and the early consumer 3D printers. RepRap kits, hand-tuned Arduinos, the 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 structure. 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 were, 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 get made. 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 Survived

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 survived 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 applied across all of them.

The implementation surface is what AI is good at rebuilding. The structure 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 was 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 here. A well-documented, well-understood system is one anyone can pick up and extend, whether or not they have a gap in their memory, whether or not they use 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. It was one of the first things I built with an AI agent writing most of the code.

The origin was 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 seed of it. 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 followed. 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 has in it.

The requirements were clear before I knew what would run them. Low power, low light, no fan, no glowing rectangle. E-paper, refreshing on a slow cadence. The architecture underneath is backend, which is where I am comfortable: a server gathers the data and renders the full 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 my head still makes easily.

The part I am not good at is the visible layer. My instincts run to backends and systems. Visual layout, what a display owes the eye at a glance, and typography that reads from across a room: none of that is native to me. That is the surface I lacked, and it is 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. The rendering came back built to it.

Both patterns show up here at once: the gap-returner and the not-my-strength. The architectural view, the data flow, and the render-on-server, dumb-device split, needed no rebuilding. 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 came after the architecture. I needed e-paper, wifi, enough memory to render a layout, and 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 matters. The architecture came first, and the implementation followed, including the parts of it I am weak at. Without that architecture there would have been no spec for “right” to measure against, and no amount of AI would have produced the right system.

This Is Not a Hardware Story

The pattern generalizes past microcontrollers. I think the argument applies most directly to 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, and which line items 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 stay hidden and where it should be visible. 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 are, which assumptions kill a launch when they are wrong. The Jira tickets, the figma boards, and the spec templates all rotated. The craft 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 grasp the structure 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 underlying skill intact.

Architecture Outlasts the Tools

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 carrying the hardest part of the job, and AI is what makes that survival actionable instead of nostalgic.

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

If you used to build something and stopped, 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 [email protected].