Prosthetics, Not Amplifiers

Every AI newsletter I've read, and I've read most of them, has the same implicit assumption buried in the first paragraph. You are a functional professional. You have a working memory. You can recall what you did yesterday, last week, last month. The AI tool makes you faster, sharper, more productive. It amplifies what's already there.

This is a reasonable assumption. For most people, it's correct.

For me, it's not.

In July 2022, I sat in a clinic and watched a doctor walk through the results of a neuropsychological evaluation. The numbers were specific in a way that doesn't leave much room for interpretation.

Processing speed at 99. Recall memory at 12. The engine runs at full speed. The storage is nearly empty.

What that means in practice: I can diagnose a system problem faster than most people in the room. I can read a situation, a broken workflow, a misconfigured tool, a person who's about to quit, with a precision that feels like instinct but is actually pattern recognition running at high clock speed. I've been doing this since I was bartending at O'Toole's, reading a room of 200 people to know who needs a drink, who's about to start trouble, and who's already past the point of useful conversation.

What I cannot do reliably: remember what I diagnosed yesterday. Remember the fix I applied. Remember the conversation where the decision was made. Remember the name of the person I talked to about it.

The gap between what I can process and what I can retain is a functional problem. Without external systems, documented decisions, searchable logs, structured workflows, tools that remember what I can't, I don't operate at reduced capacity. I don't operate.

Why This Changes What AI Tools Are For

When the AI productivity discourse talks about "augmentation," it means amplification. You're at 80%, the tool takes you to 95%. Your memory works; the tool makes recall faster. Your judgment is sound; the tool processes more data to inform it.

My use case is different. The tool supplies the signal instead of boosting one.

When an amplifier fails, you're slightly less productive. You wait for the tool to come back, or you do the task manually. It's inconvenient.

When a prosthetic fails, you can't walk. There is no manual fallback. The function the tool provides doesn't exist without the tool. When my documentation system goes down, I don't revert to a slower version of remembering. I revert to not remembering.

I mean that literally. I have a Supabase bill that's overdue right now. The database layer that stores project state across everything I build is at risk. If it goes down, I don't lose convenience. I lose the persistence layer that compensates for a clinically measured deficit. The bill is a single point of failure for a cognitive function.

Construction, Not Recovery

Recovery means returning to a previous state. There is no previous state to return to. The brain I have now, fast engine, empty storage, is the brain I'm working with. The question was never "how do I get back to baseline?" The question is "what can I build that does the job my neurology won't?"

That's construction. Building what never existed, not restoring what was lost.

I choose tools for cognitive access. A skill library that encodes my judgment so I don't have to re-derive it every session. A workflow engine that executes sequences I've designed but can't reliably execute from memory. A project state file that tells me where I am because I can't trust recall to do it.

None of this is productivity porn. It's not optimized for impressiveness. Most of it looks like overhead from the outside. From the inside, it's key infrastructure. Remove any piece and a specific function stops working.

What This Series Is About

Construction, Not Recovery is about AI tools tested in real use. No hype, no sales pitch, just what holds.

But "tested in real use" means something specific here. It doesn't mean "I tried the new feature for a blog post." It means the tool is supporting a function I can't perform without it, and I'm reporting whether it held under that load.

When I write about a Claude skill, I'm writing about a cognitive prosthetic I depend on. When I write about a deployment pattern, I'm writing about infrastructure that, if it fails, takes a measurable capability with it. When I write about prompt engineering, I'm writing about the difference between output I can trust and output that wastes the limited recall capacity I have.

The stakes are different when the tool isn't optional.

Most AI content is written by people who use the tools because they're interesting. I use them because I need to. That doesn't make my perspective more valid, it makes it different. The failure modes I notice are different. The things I test for are different. The definition of "works" is different.

A tool "works" for me when I can depend on it the way I'd depend on a physical prosthetic, reliably, predictably, without wondering each morning whether it will be there. Most AI tools don't meet that bar. The ones that do are worth writing about.

The ones that don't are worth writing about too. Because knowing what breaks, and why, and what it costs when it does, is the information nobody else is publishing.

That's what this is. AI tools, tested under load. Written by someone for whom "under load" isn't a metaphor.