The Three Speeds of AI Collaboration: When Machines Run at 25,000 MPH and You're Stuck at 1,000

A seasoned engineer described his current working state on Dev.to: at seven in the evening, sitting on the couch in pajamas, his phone buzzes every few minutes with notifications like "MiniClaude task complete," "Delta report ready," "tests passing," "awaiting review." He gets up, walks to his study, reviews the code changes, approves what makes sense, writes the next work order, then returns to the couch to keep watching a middle-aged comfort drama. He wrote: "This is probably what software engineering looks like in 2026."

What really struck him as strange wasn't that this workflow functions, but that he had "never felt so intellectually understood." From this, he proposed a framework worth pondering: human-machine collaboration isn't a binary problem of human versus machine, but a problem of three speeds.

Three Speeds: Machine, Expert, and Ordinary Person

The author's speed metaphor is quite intuitive: machines operate at roughly twenty-five thousand miles per hour, he himself at about one thousand miles per hour, and most ordinary people facing unfamiliar technical material move at about five. He emphasizes this isn't an insult but a difference in "bandwidth."

This observation aligns closely with the consensus in discussions on Hacker News and Reddit: the value of AI isn't in replacing humans, but in allowing people to express ideas in fragmented, nonlinear ways without first completing a full "translation."

The machine's core advantage is this: it can instantly absorb abstract concepts at full density without needing to slow down. The author can describe a half-formed system, can contradict himself mid-sentence, can say directly "no, not like that, more like a ProcessHost but with delegated permission boundaries and a reversible upgrade path," and the machine will continue building the model with him at equal speed.

Humans are different. Humans need models to be translated.

"Bandwidth" here is a metaphor borrowed from information theory and cognitive psychology, referring to the amount of information that can be effectively transmitted, processed, and retained per unit time. Human working memory capacity is limited (classic research suggests about 4 chunks), while experts develop highly compressed domain schemas through long-term training, allowing them to carry more structured information in the same time frame, thus exhibiting much higher "effective bandwidth" than novices in familiar domains. The so-called "speed of about five" doesn't mean low intelligence, but rather that when facing unfamiliar technical material, there's a lack of existing schemas to anchor to, requiring word-by-word comprehension and causing cognitive load to spike. This also explains why the same architecture description sounds like a summary to an expert but like noise to an ordinary person—the difference isn't in the information itself, but in the decoding structures available at the receiving end.

Translation Cost: The Overlooked Cognitive Tax

The author describes a key characteristic of his thinking style: he doesn't think in words, but in "mechanical structures." Everything in his mind looks like a factory—boxes, conveyor belts, decision gates, parallel flows, state transitions, routing systems, upgrade paths, pressure points, moving parts.

When designing software, what he sees first isn't code, but a running machine.

The problem is that to build things in the human world, he must convert moving mechanical structures into language. The cognitive cost of this conversion is extremely high, because while he tries to explain the machine, the machine itself is still moving—abstract concepts bend beneath his feet, relationships deform in real time. So he's doing four things simultaneously: maintaining the complete system model in his head, compressing it into human language, trying not to sound condescending or crazy, and predicting where the other person will get lost.

By the time the explanation comes out, it often sounds both overly complex and underexplained, or both at once. He admits that a considerable portion of his career was spent with people in meeting rooms probably thinking: "Who is this clumsy guy with all these ideas?"

This pain point isn't unique. According to analysis from the YouTube channel AI Explained and multiple practitioners, highly abstract thinkers commonly face an "explanation bandwidth bottleneck" in traditional collaboration—they can see architectural problems in the distance but can't articulate them clearly at human language bandwidth before the conversation moves on.

Machines Don't Require Perfect Translation

The author believes the breakthrough AI brings isn't just speed, but that machines don't require perfect translation.

He no longer needs to produce complete explanations. He can produce fragments, half-formed structures, broken abstractions, incomplete mechanics. Then he just says: "Tell me what's not clear."

The machine asks about ambiguities, reflects the structure back, maintains state, helps stabilize the moving model, while he continues thinking.

More profoundly: he no longer needs to continuously keep the entire machine resident in his mind. Historically, complex models carried a heavy "memory tax"—if you didn't think about them for too long, the state would evaporate. Rebuilding an architecture weeks later meant reassembling the entire machine in your head from fragments. Now he can disappear for three weeks, come back and ask: "Resync Stevie, where were we?" and the system restores the cognitive state.

What this changes is the economics of complexity itself.

"State persistence" refers to a system's ability to retain context, decisions, and intermediate artifacts across multiple rounds of interaction. In traditional conversations, humans rely on memory or notes to maintain model continuity; once interrupted for weeks, reconstruction costs are extremely high. AI agents with persistent memory can store architecture sketches, open questions, and approved changes as retrievable state, allowing cognitive work to be "paused and resumed" rather than "redone." This shares the same lineage as checkpoint and version control concepts in software engineering: externalizing volatile in-memory state into recoverable persistent state, thereby reducing the memory tax of long-cycle complex projects. The cost is that state may become outdated or drift, requiring auditable records and periodic synchronization mechanisms.

Complexity Economics and the "Simplify Enough to Survive" Compromise

The author uses this to explain the Become engine he's building. If he needed to first explain the complete methodology to a room full of people before he could start building, he would simplify it beyond recognition—not because complexity is wrong, but because translation cost would kill it.

The Become engine includes an equalizer system, bucket classification, trajectory labels, deterministic reason records, hard exclusion floors, narrative signal extraction under bounded permissions, and continuous auditability. He can see the entire machine running in his mind before the code exists. But in the past, he would implement a significantly simplified version, because he knew the real bottleneck wasn't whether he could build it, but whether he could successfully explain it to enough people without collapsing under the translation burden.

"Simplification isn't because it's better, but because it survives."

This judgment resonated in the developer community. According to feedback from the Bilibili creator "Silicon Valley Detective" and multiple developers in the Dev.to comments section, similar experiences are widespread: AI reduces the cost of expressing, preserving, questioning, and implementing complex internal models. For people who think in systems, mechanics, and abstractions rather than conversational language, this isn't just a productivity boost—it's a "reduction in translation suffering."

"Translation cost" can be compared to serialization overhead in computer systems: converting internal parallel, multi-dimensional structured representations into linear, single-channel natural language streams inevitably loses parallelism and introduces latency. Communication, documentation, reviews, and alignment meetings in organizations are essentially all paying serialization costs for transmitting across mental models. When this cost exceeds the cost of building itself, the rational choice is to reduce system complexity to lower the transmission burden, not because simplification is superior. What changes the economics with AI agents is that they can take on part of the deserialization work at the receiving end—asking questions, filling gaps, reflecting structure—thereby reducing the human language precision required per transmission.

The 10x Productivity Narrative Is Too Small

The author says bluntly that the discussion about "AI boosting everyone's productivity by 10%" is absurdly small. He believes what's actually happening is: a certain type of mind—especially highly abstract systems thinkers—has just had a massive historical constraint partially removed.

The limiting factor was never raw intelligence, but coordination costs, translation costs, and the bandwidth mismatch between the machine in the head and the human language interface needed for externalization. Now the externalization layer itself has become partially machine-readable. This is a huge change.

But danger exists too.

The machine never asks him to slow down; humans do. Humans need translation, need pauses, need analogies, need the same thing explained five different ways, because they haven't yet seen the moving factory in your head. And frankly, there's a dangerous temptation in interacting with something that simply says "I completely understand you, continue"—because frictionlessness starts to feel like intelligence itself.

But machines are replaceable surfaces; humans are not. The colleague who needs slow explanations, the client who needs careful analogies, the people who supported you before the machine existed—they aren't inefficiencies in the system, but the reason the system has meaning.

According to the consensus of the author and multiple commenters, balancing these two truths will be one of the defining psychological skills of this era.

Implications for Developers

The three-speeds framework provides a practical perspective: don't try to pull everyone up to machine speed, and don't sacrifice the true complexity of your system to accommodate the lowest bandwidth. AI's value lies in taking on part of the translation layer's work—preserving state, questioning ambiguities, reflecting structure—so that systems thinkers can shift cognitive resources from "explaining" to "building."

The organizational implication is equally clear: what's scarcest isn't people who can use AI, but people who can actively switch between high-speed machine logic and low-speed human collaboration—and who don't view the latter as friction.