Four Ring Circus

21/03/2026 << back to Debugging Myself

Some time ago I saw video of Amazon's new humanoid robots. They were incredible machines, feats of staggering engineering, designed to… pick up a box with two bionic hands and carry it from Point A to Point B.

It struck me as one of the most absurd things I’ve ever seen in tech.

Why are we so obsessed with imitating the human body for logistics? A human is a biological Swiss Army knife: versatile, adaptable, capable of playing the piano and climbing a mountain. But if your sole objective is moving boxes in a warehouse, the human body is the worst possible design. A conveyor belt or a flat robot on wheels is orders of magnitude more efficient, cheaper, and faster.

This phenomenon has a name: skeuomorphism. It’s the obsession with designing new tools by inheriting the forms and limitations of the old ones. What’s truly worrying is that this isn't just happening in robotics; it’s happening right now at the bleeding edge of software engineering with AI.

The Development Team "Cosplay"

I’ve seen brilliant engineers bragging about AI agent workflows that look like they were ripped straight out of a 2015 office. They talk about "parallelism as a planning problem," creating work "lanes," having an "Overseer Agent" for backlog triage, and orchestrating four agents working simultaneously on different repository branches.

It is, essentially, forcing technology to cosplay as a human team.

We are trying to replicate the structure of an Agile development cell in an environment where there are no humans who need to coordinate. We are forcing AI into a mold designed for beings that get tired, work 9-to-5, and need meetings just to avoid stepping on each other's toes.

The Myth of Parallelism (Or why you’re overpaying)

Parallelizing agents sounds like "extreme productivity," but in reality, it’s a premature optimization of execution that brings three major headaches:

  1. The Validation Tax: The human remains the bottleneck. If you have four agents working at once, you have to validate four different contexts simultaneously. This "context-switching" drains your attention and spikes the risk of letting bugs slip through.
  2. Token Inflation: Every agent working in parallel has to "read" the project independently. You’re paying four times for the same input context. You’re scaling your expenses, not necessarily your value.
  3. Logic Fragmentation: In a sequential flow, the "learnings" from Task A (a new abstraction, a database change) are immediately available for Task B. In parallel, agents end up creating redundant or incoherent solutions because they are blind to each other’s work.

The Advantage of the "Asynchronous Engineer"

If you have an AI that can work 24/7 without getting exhausted, why on earth do you need parallelism?

True evolution isn't about managing "digital laborers" in real-time from a dashboard full of terminals (what I call Matrix-porn). Real evolution is leveraging asynchronous sequentiality:

  • Plan once.
  • Launch a sequential logical thread where each task builds upon the last.
  • Go to sleep.

In the morning, you have a clean history, no merge conflicts, and an architectural coherence that no "swarm of agents" can replicate. You’ve gained the same productivity, but without the stress of being an air traffic controller for code.

The Risk of the Spectacle

It’s true that the spectacle sells. Seeing four monitors with cascading logs is "impressive" for a LinkedIn post or an investor pitch. Sometimes we need that period of inefficient adaptation just to wrap our heads around a tool's potential.

However, the risk is real: if we stay in the phase of imitating the familiar, we will miss the chance to discover the true potential of AI. Many innovations in history were discarded because the public couldn't understand their value outside of traditional mental frameworks.

We don’t need AI to work like a human team. We need AI to work like AI. Less robotic "little hands," more industrial efficiency. Less orchestrated chaos, more logical flow.

exit(0);

<< back to Debugging Myself