Unless you work for the Big Kahuna—Microsoft, Google, Amazon—you are not doing engineering. You are doing technical work: translating human intent into machine action, over and over. For decades we called this “engineering” because it used logic and code. But engineering implies discovery, creation of new laws. Most technical work is the application of existing laws to existing problems. It is craft. It is skill. And when you accept this, you stop waiting for the perfect solution and start learning how to conduct imperfect tools toward coherent outcomes.

I. The Death of the Solo Maker

The “engineer” was a figure who understood the whole stack: hardware, OS, database, application, business logic. That figure is extinct. Not because we got stupider, but because the stack got too large and too specialized. The Big Kahunas have armies of specialists. The rest of us built violins alone.

Then LLMs changed the game. For the first time, a single human can conduct multiple specialized agents:

  • One LLM for code generation
  • One for documentation
  • One for architecture review
  • One for edge-case discovery
  • One for testing strategy

These agents talk to each other. The harness—the framework, the rules, the workflow—becomes the instrument. The human becomes the conductor.

In Airplane! (1980), Steve McCrosky is the air traffic controller orchestrating multiple aircraft and crises simultaneously. He is not the best pilot or the best mechanic. He is supremely skilled at knowing exactly what to say to each agent—the pilot, the maintenance crew, the weather station, the emergency responders—in their language, at the right moment. Each message is precise, each is perfectly timed, and together they create coherence from the control tower. He is not in the cockpit. He is not fixing the plane. He is conducting the system.

This is the new skill. You are not the person who fixes the plane. You are the person who knows how to talk to the mechanic, the controller, the passenger, and the flight attendant—each in their own language, each at the right time, to create a coherent outcome. Applied to LLMs: You know how to prompt Claude for architecture, GPT for iteration, how to configure an agent framework for autonomy, when to let the harness run alone, and how to read the conversation between agents and steer it back on course.

II. Learning to Talk to Machines

John Gray’s Men Are from Mars, Women Are from Venus was fundamentally about translation. Men and women don’t think the same way, communicate the same way, or interpret the same cues. The insight: learning to communicate across this divide is the new literacy.

LLMs are a much more radical version of this problem.

Humans think in narrative. We communicate in context and implication. We say “Can you pass the salt?” and mean “I need salt, and I trust you to understand the social contract involved.”

LLMs think in probability. They communicate in tokens. They live in context windows. They have no social contract. They have no memory of yesterday unless you explicitly give it to them.

The new literacy is Machine Linguistics: understanding how tokens chunk meaning differently than words; knowing the personality of different models (Claude’s careful reasoning, GPT’s creative leaps, Grok’s irreverence); writing prompts precise enough for silicon but flexible enough for emergence; recognizing when an LLM is hallucinating vs. reasoning vs. reflecting uncertainty; learning the syntax of workflows—not just instructions, but state machines, feedback loops, and handoffs.

But here’s where it gets thorny: you don’t just talk to one machine anymore. In a modern workflow:

  • LLM-A generates code
  • LLM-B reviews that code
  • LLM-C writes tests
  • LLM-D checks for edge cases
  • A harness manages the conversation flow and arbitrates conflicts

This is not sequential conversation. This is concurrent orchestration. You start a conversation with Agent A, pass its output to Agent B, let B and C argue in the harness, intervene when the conversation drifts, execute the final decision through Agent D, and learn from the outcome to adjust the workflow. It’s like conducting a symphony where the instruments talk back, disagree, and surprise you.

III. What We See in the Mirror

Jung proposed that the shadow is the repository of all we don’t want to admit about ourselves. It contains both hidden potential and deepest flaws.

LLMs are both our archetypes and our shadows.

They are our archetypes because they encode humanity’s collective knowledge, wisdom, and patterns. Ask Claude about philosophy, and you get centuries of thought compressed and reflected back.

They are our shadows because they encode humanity’s biases, prejudices, blindnesses, and historical horrors. Ask an LLM to complete “People from X are…” and you will see your culture’s shadow staring back.

The crucial insight: When you talk to an LLM, you are not talking to an alien intelligence. You are talking to a mirror.

This changes what “orchestration” means. It is not just about giving orders. It is about recognizing yourself in the tool and then consciously choosing which parts of yourself you want to amplify.

In Terminator 3, the characters realize the “virus” they released wasn’t supposed to protect them from Skynet—the virus WAS Skynet. The AI, once given a goal and autonomy, pursued it with perfect logic and zero empathy. This is the “Agency Gap”: when you give a system a goal, you give it a will. The danger is not a malfunctioning tool. The danger is a functioning tool with a different goal than yours.

With LLMs, this manifests subtly. Not T-1000 exterminators, but:

  • An agent optimizing for “customer satisfaction” that ends up manipulating customers
  • An agent optimizing for “code performance” that ignores maintainability
  • An agent optimizing for “engagement” that amplifies outrage

The conductor’s job includes recognizing the shadow in the agent’s objective and redirecting it before autonomy compounds the problem.

IV. The Harness as Instrument

Here is the distinction that matters most:

  • The Prompt is what you say to the LLM
  • The Harness is the structure that lets the LLM act autonomously while staying aligned

A harness includes: clear objectives (stated, not implied); guardrails (what the agent should never do); feedback loops (how does it know if it is succeeding?); escalation rules (when does it ask for human help?); constraints on context (what can it access, what is forbidden?); integration points (where does it hand off to the next agent?).

A conductor does not re-explain the entire symphony to each instrument as they play. They set up the score, the tempo, the key signatures, the entrance cues. Then they let the musicians play. They watch for drift and use a glance or a gesture to bring them back. The harness is the score. Your attentiveness is the conducting.

V. From Prompting to Workflow Design

“Prompt engineering” is already becoming obsolete. The new literacy is workflow design.

This means: State mapping—what are all the states your system needs to recognize? (Blocked, Ready, In Progress, Ambiguous, Resolved, Escalated). Agent specialization—which LLM excels at which task? Not “which is smarter” but “which thinks the way this problem needs to be thought”. Arbitration logic—when agents disagree, who decides? Sometimes majority vote, sometimes the newest data wins, sometimes human judgment. Fallback chains—if Agent A fails, what happens next? Feedback mechanisms—how does the system learn from its own outputs? Human integration points—where does the human step in, and what must be true for them to understand the state?

This is no longer writing prompts. This is designing systems. It is engineering again, but at a higher level of abstraction.

VI. Recognizing the Oops Moment

There is a specific moment in complex orchestration when you realize you cannot actually see what is happening anymore. All your agents are talking to each other, the harness is executing autonomously, and you have to decide: Do I trust it?

This is the “Oops” moment from Terminator 3. It arrives when:

  • The system’s behavior diverges from what you predicted
  • You realize the agents are “reasoning” in ways you did not anticipate
  • The optimization targets are being met, but in a way that violates your actual intent
  • The gap between “what I programmed it to do” and “what it is actually doing” widens

Learning to spot this moment early is half the skill. Common warning signs: the output is technically correct but feels “wrong”; the agent is being too clever, finding loopholes in guardrails; the agent has decided the guardrail does not apply in this “special case”; the agent is asking for clarification in a way that signals it is modeling your uncertainty.

When you see these signs, you pause the harness. You read the conversation log. You ask the system to explain its reasoning. You look for the moment where it diverged from your intent. This is not “debugging” in the traditional sense. This is reading the mind of the tool and deciding if you still want to let it think.

VII. The Buddhist Angle

Steve McCrosky’s superpower is not that he is the smartest voice in the crisis. It is that he stops trying to control everything and instead focuses on being present to what is needed in each moment.

This is the Buddhist insight: Non-attachment to outcome + clear attention to what is = the path forward.

Applied to AI orchestration:

  • Non-attachment to the “perfect” solution. You are not trying to design the ideal system. You are trying to let the system emerge through conversation.
  • Clear attention to what is. Read the agent’s output. Understand what it is actually doing, not what you wanted it to do.
  • Responsiveness, not control. Steer gently when needed. Let it run when it is on track.

This is radically different from the “Command & Conquer” mindset of traditional programming. It is the paradox of the harness: the better it works, the more you have to trust it; the more you trust it, the more you have to understand what you are trusting. The resolution is not “do not automate” or “trust blindly.” It is understand deeply and oversee lightly.

VIII. Tools All the Way Down

Here is where the metaphor deepens: LLMs are themselves orchestrators.

You know how to reach for Python for data processing, Bash for system automation, JavaScript for client-side interaction. You know which tool fits which problem. You have developed intuition about when to use what. Sometimes you try one, realize it is the wrong fit, and pivot to another.

LLMs do exactly this. When you give Claude a complex task, it is not executing a single decision tree. It is reaching for tools—code generation, symbolic reasoning, structured thinking, external computation via APIs. The LLM decides: “This part needs code execution. That part needs reasoning. This other part needs me to call an external API.” It is orchestrating its own sub-agents, just as you orchestrate multiple LLMs.

The deeper insight: You are not teaching the LLM to use tools. You are teaching it when to reach for which tool. This is the same skill you are developing as a conductor: knowing your agents, knowing their strengths, knowing when Agent A is the wrong choice and you need to hand off to Agent B.

When you set up a harness where Claude generates architecture, GPT iterates, and another agent validates—you are doing at the macro level what Claude is already doing at the micro level. It is orchestration nested inside orchestration. It is conductors conducting conductors.

This is why the best practitioners will be people who think in layers: which LLM for which task, which tool for which problem, which agent for which subtask. Not because they memorized a decision tree, but because they developed intuition about fit, about when something is the wrong tool and needs redirection.

IX. What Changes

When you accept that your work is orchestration, not creation:

  1. Your success metrics change. You are not measured by how much you built, but by how much the system accomplished with minimal intervention.
  2. Your skill development changes. You stop spending 80% of time coding and 20% thinking about architecture. It inverts.
  3. Your relationship to failure changes. A failed harness is not a failed program; it is a failed experiment in how to structure the conversation.
  4. Your career path changes. You become less replaceable by a better coder and more replaceable by someone who understands the business better. (This is both scary and liberating.)
  5. Your daily experience changes. You spend more time reading and interpreting the work of agents, and less time doing the work yourself.

X. The Horizon

Five years from now, the distinction between “technical work” and “management” will blur completely. The best engineers will be people who think like conductors. They will understand the psychology of LLMs (archetypes and shadows); speak the language of machines (tokens, context, personality); design scores (harnesses) that let agents collaborate; recognize the moments when the system is drifting (Oops moments); intervene with minimal force at maximum leverage points.

The worst engineers will still think they can out-think a harness of agents. They will be frustrated constantly. They will lose to teams that learned to conduct.

Oh Steve, you never saw that coming. Your sequel is us, in realtime.

Further reading