What my 386 DX40 taught me about the AI age

Christmas morning, 1991. I was in ninth grade. I woke up early, before anyone was opening presents, and on the way to the bathroom I looked across the hall into the family room, and there it was. A 386 DX40, set up on a desk, not yet plugged in. My parents had hidden it there overnight. The reveal was about to happen anyway, but I’d seen it first, by accident, in the quiet before the rest of the house was awake.

When the actual reveal came I did a respectable job of acting surprised. The full setup was a 386 DX40 with 8 MB of RAM, a 120 MB hard disk, a 14-inch CRT, an external SCSI CD-ROM, a Sound Blaster Pro, and a dot-matrix printer that woke the whole house the first time I ran it. DOS 6.22 on disk. Windows 3.1 came later, layered on top, mostly as a polite suggestion.

What didn’t come in the box was an instruction manual. I told my parents. They figured it had been forgotten. Dad took me back to the store, a small place where they custom-built machines, and we stood at the counter arguing with the guy. He kept saying it didn’t come with one. Dad got upset. My parents had just put $4,500 on credit for this thing and it didn’t come with a manual. By the time Dad was done, the guy went into the back and came out with an MS-DOS 6.22 book. Over twelve hundred pages, two inches thick. The price tag on the back said $45.

I went on to spend thousands of dollars on books like that. Books that became obsolete in twelve to eighteen months. Then six months. Then, eventually, the moment you walked out of the store with one. The MS-DOS 6.22 book outlasted most of what came after it.

Before that, in sixth grade. I had a Commodore 64 with a 1541 floppy drive, a cassette deck, and a 300-baud modem that connected me to a world that, at the time, mostly consisted of local BBSes. The C64 was the first machine I figured out how to live inside. The 386 was where I actually moved in.

I have been thinking about that 386 a lot lately. Not in a nostalgia way. I don’t actually want to go back to a 640K conventional memory barrier and a sound card that needed three jumpers set correctly before it would acknowledge it existed. The thinking is more specific. I keep noticing that the instincts I built sitting in front of that machine are the ones I’m reaching for now, in 2026, in the AI age. The shape of the lesson is older than the technology it applies to.

Three threads, all from the same machine.

You owned the stack, because nobody else was going to

When something on the 386 broke (and things broke constantly) there was nobody to call. The internet existed, technically, but not for me, not in my house, not at a speed that would have let you ask a question and get an answer in under a week. If HIMEM.SYS was misconfigured and the game wouldn’t launch, you opened CONFIG.SYS in EDIT and you figured it out. If the IRQ for the sound card conflicted with the IRQ for the modem, you learned what an IRQ was. If a driver disk came corrupted, you wrote to the company and waited two weeks. The machine was opaque only until you decided it wasn’t.

What that produced was a relationship with the computer where I assumed, by default, that I was responsible for understanding it. Not in a “becoming an expert” way (I was fourteen, I wasn’t an expert at anything) but in the way you assume responsibility for a bicycle. You learn how the chain comes off and how to put it back on, because nobody else is going to do it for you while you’re standing at the side of the road.

I have written before about sixteen years in cloud automation and the through-line of my career being “understand the layer below the one you’re working on.” The instinct started here. I was not afraid of the machine. The machine was a thing I lived inside.

The AI version of this is the personal-AI framing I keep coming back to. The default posture toward AI right now is the opposite of how I learned to live with the 386. People treat the model as opaque, as something that happens to them, as a service whose insides are not their business. I think that’s the wrong posture and it produces the wrong outcomes, the same way treating your computer as a sealed box in 1992 would have meant the machine got worse for you, slower, more frustrating, less yours. The principled position is to own your stack. Know what the model is doing, what data leaves your machine, and what the system prompt says. Don’t accept opacity as a default.

Constraints were a teacher, not an obstacle

8 MB of RAM was a lot in 1991. Most machines shipped with 1 or 2 MB. My parents had spent real money to put me in a position to actually run the software I cared about. And it still wasn’t enough, because the 386 lived behind a 640K conventional memory barrier, and every TSR, every device driver, every memory manager you loaded ate into the conventional pool that the actual applications needed. You picked your TSRs carefully. You learned the difference between conventional, upper, expanded, and extended memory because the machine made you. You wrote batch files to swap configurations because there was no other way to get DOOM and a flight simulator to coexist on the same machine without one of them complaining about memory.

The constraint was the curriculum. You did not learn about memory management because someone taught you memory management; you learned it because the machine would not let you not learn it. The same with disk space, with CPU cycles, with bandwidth. Every resource was scarce enough that you had to develop a feel for it. The feel was the skill.

The instinct that produced (that constraints are a feature, not a bug) is one I have not been able to shake. I have written about vCAC actually preparing me for this, and one of the threads there is the same one: the early-days infrastructure tools forced you to model the system precisely because the tools were not powerful enough to paper over your sloppiness. You either understood your environment or it didn’t work. The constraint did the teaching.

In the AI age the analogous constraint is the one most people are trying to remove. Bigger context windows. More compute. More agents. More tools. The default narrative is “scale removes the constraints, and that’s progress.” It is progress in some senses. But the part I keep wanting to push back on is the assumption that removing the constraints removes the need for the discipline. The opposite is closer to true. The discipline you build by working inside a constraint is the discipline that lets you use the unconstrained tool well when it shows up. The people I trust most with AI now are the people who learned to do precise work with small tools first. The constraint was their teacher and they retained the lesson.

Iteration was slow, and slow was a gift

The 386 ran at 40 MHz. A compile took as long as it took. If you made a mistake in a config file and the machine wouldn’t boot, you waited through the POST, through the memory check, through the floppy probe, through DOS loading, through the error message, through the reboot. Two minutes, three minutes, five minutes. You learned to think before you typed. Not because you were patient by nature (I was a teenager, I wasn’t patient) but because the feedback loop punished you for not thinking and the punishment was time.

What that taught was a relationship with iteration where each cycle was treated as expensive. You did not try things at random because each try cost real seconds you could feel. You built a hypothesis, you tested it, you watched what happened, and you updated. The pace of the work was the pace of your thinking, more or less, because the machine did not run faster than you could form an idea.

The AI environment is the opposite of this. The feedback loop is microseconds. You can generate fifty variants of anything before you have finished forming the question. The cycle is so fast that the cycle becomes the trap, you iterate on output without iterating on thought, because the machine has removed the cost that used to force the thought to happen.

I do not think the answer is to slow the tool down. The tool is what it is. The answer is to put the cost back somewhere else, to artificially impose the pause that the 386 imposed for free. Read the output before you regenerate it. Form the hypothesis before you ask. Decide what “better” means before you compare two versions. The slow iteration of the 386 was a gift because it forced the thinking to happen at the right point in the loop. You can give yourself the same gift now; you just have to do it on purpose.

What the machine actually taught

If I try to compress it down to one line, the 386 taught me that the relationship between the operator and the tool is the thing that matters. The tool changes (wildly, across generations) but the question of whether you own the tool or the tool owns you is the same question every time.

I have been writing this year about encoding a person and about what it would mean for an individual’s cognitive process to be preserved, captured, transmitted. That work is downstream of the same instinct. The thing worth encoding is the way of working, the patient debugging, the willingness to open the box, the discipline to slow down and form the hypothesis. The tools change. The way of working compounds.

I do not miss the 386. I miss a few things about it, the satisfaction of a working AUTOEXEC.BAT, the moment a game finally launched after an hour of configuration tuning, the specific quality of the silence in the room when the floppy drive stopped seeking, but I do not miss the actual machine. The lessons stayed; the hardware was scaffolding. Over the six years that followed, the machine kept changing, every dollar of birthday money went into the next bus speed, the next memory upgrade, a grayscale handheld scanner one year, a color printer the next, and what stayed constant was the relationship. Mine to understand. Mine to fix. Mine to push further.

The AI age will have its own scaffolding. In thirty years some kid who grew up on whatever-comes-after-this will write the equivalent essay about whatever they learned from the tools of 2026. I want the lessons I pass forward to be the right ones. Own the stack, let the constraint teach you, and slow the loop down on purpose. That’s most of it. The 386 was a good first teacher and I am still using what it taught me.