Categories
AI Aviation

Buffer Overflow

There is a moment in a stall, before the airplane actually stalls, when the controls go soft. The yoke stops talking back. You can still pull it toward you, and the nose will still come up, but the airplane is no longer answering in the language it used thirty seconds earlier, and if you do not recognize the change in dialect you will keep asking questions in a tongue the airplane has stopped speaking. Pilots have a phrase for the general condition this belongs to, which is broader than stalls and covers weather, traffic, radio calls, checklists, an unfamiliar airport with three runways and no tower: getting behind the airplane. The airplane is still flying. It is you who have stopped keeping pace with what it is doing.

I flew a Cherokee 235 for years, a airplane with enough useful load to make it forgiving and enough control weight to make it honest, and I only got behind it twice that I can remember with any precision, both times on approach, both times because I let a secondary task — a frequency change, a passenger question, a glance at a chart — eat the attention that the airplane needed at exactly the moment it needed it most. What is strange, looking back, is that the airplane never sped up. The airplane was doing what it always does on a three-degree glide path. I was the one who fell behind a constant.

I have started to notice the same falling-behind, unrelated to constants, in conversations with a language model.

It happens on the good days, which is the part that took me a while to understand. It is not the model being slow or confused. It is the model being unusually generative — pulling a thread from something I said four exchanges ago, connecting it to a domain I had not mentioned, offering three candidate framings where I had expected one — and somewhere in the second or third of these, I notice that I have stopped actually absorbing and started merely receiving. The words are still arriving. I have quietly stopped being the kind of reader who can do anything with them.

The name I have for this, mostly because I spent some years around fraud systems and payments infrastructure and the vocabulary never entirely leaves you, is buffer overflow. In a computer, a buffer is a fixed patch of memory set aside to hold data until a program is ready to process it — a loading dock, essentially, sized for a delivery truck of a known dimension. A buffer overflow is what happens when the truck backs in and keeps unloading past the edge of the dock. The classic and dangerous version of this is not that the extra data spills onto the floor and is lost. It is that the extra data lands on the memory sitting just past the dock, and overwrites whatever was stored there — a return address, a variable, something the program needed intact to know where to go next. The failure is not loss. It is corruption. The fifth insight does not politely fall away; it lands on top of the second insight and changes what the second insight was.

This is, I think, the more accurate complaint than “overwhelm,” which is the word I would have reached for a few years ago and which suggests simple excess, more water than the glass can hold. What I am describing is not excess. It is a rate mismatch between generation and integration, and the damage happens specifically at the boundary — not in the ideas that never arrived, but in the ones that arrived and were still being turned over when the next one came in and knocked them loose.

Aviation, as it turns out, has more than one name for this family of failure, and the names are not redundant, because they describe different mechanisms. Task saturation is the CRM term — Crew Resource Management, the discipline built in the seventies and eighties largely in response to accidents where a competent, rested, well-trained crew flew a functioning airplane into terrain because attention had been consumed by something lower priority than staying alive. Task saturation is measured, in training, less by how much is happening and more by whether the pilot can still prioritize — whether they know which thing to drop. Channelized attention is the adjacent and opposite failure: not too many things competing for a narrow channel, but one thing filling it entirely, a fixation on the landing gear light while the airplane, unflown, descends into the Everglades. And John Boyd’s OODA loop, developed for fighter pilots and stolen since by nearly every field that has ever needed a name for out-thinking someone under time pressure, describes what it feels like structurally to fall behind: you are not reacting to what the situation is, you are reacting to what the situation was, one iteration back, and every loop after that the gap does not close on its own.

I suspect what I am calling buffer overflow is closest to task saturation, with the wrinkle that in a cockpit the incoming data is at least all real-time and load-bearing — the runway is where the runway is — whereas a model in full flow is producing a mix of load-bearing insight and elaboration that only sounds load-bearing, and no light comes on to tell you which is which. Sweller’s cognitive load theory gives this a cleaner anatomy than aviation does: intrinsic load, which is the actual difficulty of the idea; extraneous load, which is how badly or well the idea is presented; and germane load, which is the effort of building the new idea into the structure of what you already know. My buffer does not overflow on intrinsic load — the ideas themselves are usually not hard. It overflows on germane load. The model can generate connections faster than I can lay the track that would let each new connection actually attach to something.

None of the aviation solutions to task saturation involve asking the airplane to slow down, and this is the part I keep returning to, because slowing down is the intervention that occurs to me first and is also, I think, the least aviation-like response available. A pilot who is task-saturated on approach does not usually ask the tower to widen the pattern. He drops something. He un-couples the autopilot from one axis and flies it by hand so the workload becomes tactile instead of cognitive, or he tells the passenger the question will have to wait, or he reads back only the clearance and lets the weather advisory go unacknowledged for ninety seconds because the weather advisory is not what is going to kill him in the next ninety seconds. The skill is not deceleration. It is triage performed at full speed, which looks, from outside the cockpit, indistinguishable from calm.

I do not yet know what the triage move is for a conversation with a model that is generating faster than I can integrate. I have a guess, which is that it looks less like asking the model to slow down and more like periodically stepping outside the exchange entirely — not to catch up on what was said, but to write down, in my own words, the one thing from the last five minutes I actually want to keep, before asking it to continue. That would make the move not deceleration but discard: choosing, the way the saturated pilot chooses, which incoming data does not get processed at all, on the theory that a buffer with something deliberately thrown out of it still holds its shape, and a buffer that tries to keep everything is the one that overflows.

Or maybe the real answer is the one the checkride examiner gave me in Springfield, on a September morning in 1978, when I came in too fast and too high and asked, afterward, what I should have done differently. He said the airplane had told me everything I needed to know about forty seconds before I noticed, and that the only skill that mattered was noticing forty seconds earlier next time. Not slower. Earlier.

Categories
AI Work

The Digital Beast of Burden

A friend of mine recently cut through the noise of the current AI discourse with a comment that felt surprisingly grounding. We were talking about the breathless predictions of AGI—superintelligence, sentient machines, the technological singularity—when he shrugged and said, “I don’t need any of that. I just want AI to do the donkey work.”

He wasn’t asking for a god in the machine; he was asking for a better tractor. He didn’t want a synthetic philosopher to debate the meaning of life; he wanted the next evolution of “Claude Cowork”—a reliable, tireless entity to handle the drudgery so he could get back to the actual business of thinking.

There is something profound in that phrase: donkey work. It evokes the image of the beast of burden—the creature that carries the heavy packs up the mountain so the traveler can focus on the path and the view. For thousands of years, humans have sought tools to offload physical exertion. We domesticated animals, we built water wheels, we invented the steam engine. We outsourced the calorie-burning, back-breaking labor to preserve our bodies.

“The ‘donkey work’ of the information age isn’t hauling stone; it is the cognitive load of bureaucracy, formatting, sorting, scheduling, and synthesizing endless streams of data.”

Now, we are looking to preserve our minds.

The friction that exists between having an idea and executing it is often composed entirely of this “donkey work.” When my friend says he wants AI for this, he isn’t being lazy. He is expressing a desire to reclaim his cognitive bandwidth.

There is a fear that if we hand over these tasks, we become less capable. But I suspect the opposite is true. If you are no longer exhausted by the logistics of your work, you are free to be consumed by the meaning of it.

We often talk about AI as if it’s destined to replace the artist or the architect. But the most valuable version of this technology might just be the humble assistant—the digital mule that quietly processes the mundane in the background. It’s the difference between a tool that tries to be you, and a tool that helps you be you.

We don’t need AGI to solve the human condition. We just need the “donkey work” handled so we have the time and energy to experience it.

What do you think?

  1. Is there a danger that in handing over the “donkey work,” we accidentally hand over the friction required to build mastery?
  2. If your daily cognitive load dropped by 50% tomorrow, would you actually use that space for “higher thinking,” or would you just fill it with more noise?
  3. Where exactly is the line between “drudgery” and the “process”—and are we risking erasing the latter to solve the former?