On confirm: July 3rd I ordered the first parts for a device that didn't exist. On confirm: July 23rd my father pressed its one big red button and started telling the story of his life.
Twenty days. In between: a custom Raspberry Pi HAT with a MEMS microphone, a Class-D amplifier, a haptic driver and a color display, hand-wired and brought up on the bench. Multithreaded C++ firmware with real-time audio capture. Studio-grade signal handling. A crash-safe cloud upload pipeline on an OAuth refresh flow. A family-facing web view. Remote fleet deployment over a secure mesh, because one unit on a bench isn't a product.
Five disciplines that normally imply five people and a roadmap measured in quarters.
Let me scope the claim honestly, because the number is the least interesting part of this: twenty days took it from concept to a delivered, working v1 in the hands of its actual end user. It did not produce a scaled product company, a certified enclosure, or a supply chain. Anyone who tells you otherwise is selling something.
What I want to write about is the part I got wrong going in — not about the product, but about what AI was going to do for me.
The prediction I'd have made
Ask me in June where AI assistance would help most on a build like this, and I'd have said: the code. Write the firmware faster. That's the story everyone tells.
That's not what happened. The acceleration was real — twenty days is not a normal number — but it landed almost entirely in a place I wasn't expecting, and it was conspicuously absent from two others. Sorting out why took me most of the build, and it's the only genuinely useful thing I have to say about AI-assisted development.
The framing I ended up with has nothing to do with what AI knows. It has to do with what I knew, and — this turns out to be the whole thing — how recently I'd used it.
Tier one: what you use every day
Software is my daily instrument. I've spent my career in it and I'm in it constantly.
AI added the least here, and that's fine. In the domain you exercise daily you're already operating at the speed of your own judgment. The bottleneck isn't retrieval — it's decision-making, and decision-making doesn't compress. Asking for help inside your strongest, most current domain mostly returns things you already knew, phrased confidently, which is a slow way to learn nothing.
I suspect this is why so many very senior engineers come away unimpressed. They evaluate the tooling in the one tier where it has the least to offer them, and generalize from it.
Tier two: what you own but haven't touched in years
This is where the twenty days came from, and I badly underestimated it.
I have deep background outside software. Hardware and electronics. Audio — seriously, not casually: studio recording, years as a working musician, the kind of time around signal chains that teaches you what things sound like when they're wrong. Phase 3a: replace this sentence with the real specifics — instrument, years, studio role, and one dateable piece of gear. The entire thesis rests on this background being real and deep, so vagueness costs more here than anywhere else in the piece. That knowledge is genuinely mine. It's also, in most years, dormant. Software is what I practice; the rest sits in cold storage.
And dormant expertise is expensive to use. Not because you've lost the judgment — you haven't — but because the supporting detail has evaporated. I know exactly what I want a haptic driver to do. I do not remember its register map. I know precisely how to reason about a wiring fault. I do not remember which pin on this particular part should read 3.3V, or which two should show continuity and which absolutely shouldn't. I know a battery-backed clock stores time in a packed format. I'd have to go look up which one.
None of that is hard. All of it is slow — the right revision of the right PDF, fifteen minutes at a time, producing no engineering value whatsoever. On a board with a mic, an amp, a display and a HAT tying them together, that tax gets paid over and over. Historically it's what made me reluctant to reach for those skills at all: not doubt that I could, but knowing what the re-immersion would cost.
This time it cost almost nothing. I'd describe a symptom — this line stays low when it should toggle, this pin reads open where I expected continuity — and get back a specific checklist of what to measure and what each pattern of readings would imply. I still held the probes. Nobody automates the meter. But the plan for where to put them arrived in seconds instead of an afternoon of datasheet excavation.
That's the real mechanism, and it's less glamorous than "AI writes your code": it didn't teach me anything. It reloaded what I already had. The judgment was already in place and had been for decades. What was missing was the scaffolding underneath it, and scaffolding turns out to be exactly what this tooling is good for.
The compounding shows up in the design decisions this makes affordable. There's a well-known pattern where you write firmware against a simulated hardware layer so you can build and test before the parts arrive. It's textbook correct, and solo builders skip it constantly — not from ignorance but because writing the simulator is a chore big enough to feel like a detour when you could just wait for the mail. With that chore cheap, the right way became the fast way. I built and exercised the entire product — the recording flow, the prompts, the state logic, what happens when Wi-Fi drops mid-upload — days before a single wire was connected.
That one decision is why twenty days was possible. AI's contribution to it wasn't cleverness. It was making the disciplined choice cheap enough to actually make.
Tier three: what you never owned
And then the tier where AI isn't neutral but actively dangerous.
Every recording on my test unit was quietly overwriting the one before it. The clock chip had died, so every file was stamped with the same non-time and therefore the same name, and the uploader — seeing a filename it had already handled — sent nothing. The light came on. My father would have told his story. It would have felt like it worked. Nothing would have been kept.
Once I was suspicious, AI traced that chain from timestamp to filename to uploader in minutes, where I'd have spent an afternoon. Genuinely fast, genuinely useful.
But it did not get suspicious. I did — because I've been burned by hardware clocks before, and because I asked the question that matters for this product: if this fails, would we even notice?
The same shape again with a click at the top of every take. It sounds like a digital audio problem, so that's where you look: buffers, alignment, file headers, the encoder. AI will tear through that space faster than you can, and I ruled all of it out in an afternoon. The audio data was clean. The click was analog — the amplifier coming out of shutdown as the clock started. Nothing to do with the recording at all. And the thing that pulled me out of the wrong domain wasn't analysis. It was recognition: I've heard that click before, on other gear, decades ago.
AI will search any space you point it at. It will not tell you that you're searching the wrong space. It has no model of its own ignorance and won't volunteer that the question is malformed. Products break at the seams between domains — digital meets analog, software meets power, firmware meets a person's hands — and naming which domain you're actually in stays entirely human.
What actually changed
Not "AI made me faster." Something more specific:
AI collapsed the cost of reaching for skills I own but rarely use. It did little for the domain I practice daily, and it is a liability in the domains I never learned.
Which leads somewhere I didn't expect, and which I think is underappreciated.
A long career doesn't only make tier three small — fewer unknown unknowns, better instincts about where the bodies are buried, a working sense of what correct looks like so you can catch the tooling being confidently wrong. That part is real, and it's most of what people mean when they talk about experience.
But the bigger effect is that a long career makes tier two enormous. Decades of accumulated, shelved, still-valid expertise — the hardware you haven't touched since the nineties, the audio work you did before you moved into software, the whole trailing wake of a career spent in more than one place. That inventory used to be a depreciating asset. The judgment stayed sharp while the operational detail rotted, until reaching for it cost more than it was worth and you stopped reaching.
That inventory just became liquid again. Not because the tooling knows those domains — it's the same model for everyone — but because it removes the specific tax that made your dormant knowledge impractical to use. The engineer who benefits most here isn't the one starting out. It's the one with thirty years of range and a decade of specialization sitting on top of it.
That also means the honest answer to "does AI 10x productivity" depends on a property of the engineer nobody is measuring. Large tier two, small tier three: the multiplier is real and large. Invert it, and you get a fast, confident, plausible march in the wrong direction — because reloading only works if you owned the thing in the first place. Without the underlying judgment you're not reloading anything. You're accepting answers you have no way to evaluate.
I don't think that changes with better models. Tier three is defined by not knowing what to ask, and no improvement in answering fixes a question that was never posed.
Five posts follow this one, each a specific instance:
- Building the product before the hardware existed — the simulated hardware layer, and why the right way finally became the fast one.
- The bug that was quietly erasing the recordings — the dead clock, and the difference between tracing a failure and suspecting one.
- The click that wasn't where it sounded like it was — an hour spent searching the wrong domain, and what pulled me out of it.
- What voltage should be on this pin — bench debugging when the reference layer is instant.
- Tuning, and talking to chips that don't explain themselves — the unglamorous majority of the work.
Two of those are about the multiplier. Three are about its limits. That ratio is not an accident; it's the honest proportion from the build.
The device is called Memory Thread. My father David is Phase 3a: decide whether to name David's age and blindness for the technology audience. Used once, lightly, here. 95 and legally blind, which is why it leads with one button, spoken prompts and haptic feedback, and why the case is school-bus yellow — he drove one for fifty years, and bright color is what his remaining peripheral vision still catches. You can see it at mymemorythread.com.
He's recording his stories now. That was the whole point. The engineering was just what it took to get out of his way.