Chapter 8

Two Jobs, One Title

Meet two engineers on the same team at a Series B startup in Austin, Texas. Both hired in 2025. Both called "software engineers" on their LinkedIn profiles. Both building the same agent-powered product.

Priya spends her mornings crafting system prompts. She rewrites them ten times — testing each version against fifty edge-case scenarios she's built into an evaluation dataset. She anticipates how the agent might misinterpret an ambiguous instruction and adds clarifying examples. She adjusts few-shot demonstrations until the agent's judgment matches what a senior product manager would decide. Her work looks like writing. It feels like teaching.

Raj spends his mornings configuring MCP servers and wiring A2A connections between agents. He builds retry logic with exponential backoff and jitter. He designs the approval gate flow — which agent actions need human sign-off (database writes, external API calls, file deletions) and which can proceed automatically (reads, searches, analysis). He sets up Langfuse for trajectory logging and builds Grafana dashboards that show token costs per agent per task per hour. His work looks like infrastructure. It feels like plumbing.

Both are called "software engineers." They cannot do each other's jobs.

The Teacher vs The Plumber — two distinct roles, completely different loadouts and core tasks

Priya is teaching. She shapes what agents know and how they behave. Her skills are pedagogical — clarity of instruction, anticipation of misunderstanding, knowing which examples to include and which create confusion. Teaching is closer to management than to coding. You're not telling the agent how to do something step by step. You're telling it what good looks like and trusting it to figure out the how.

Raj is plumbing. He connects agent capabilities into working systems. His skills are infrastructure — service discovery, health checks, circuit breakers, connection pooling, monitoring — plus the agent-specific challenges of non-deterministic behavior, context window management, and cost optimization. Plumbing is distributed systems engineering with a probabilistic twist.

In 2026, the industry recognized this split explicitly. Phil Schmid named the teaching side: "The new skill in AI is not prompting, it's context engineering." Context engineering means designing the complete information environment around an LLM — the memory, retrieved documents, tool definitions, conversation history, and system instructions that shape how the model reasons. Orchestration, deployment, and governance infrastructure is the plumbing side.19Schmid, P. "Context Engineering." philschmid.de · Neo4j

The new skill in AI is not prompting, it's context engineering — Phil Schmid, 2026

For fifty years, "programming" was one activity. You wrote instructions. The machine executed them. The skill was knowing the language, the algorithms, the data structures.

Agent-era programming is two activities that require fundamentally different cognitive skills. Teaching requires empathy — you need to model how the agent will interpret your instructions, which means understanding its perspective. Plumbing requires systems thinking — you need to see the whole topology of data flows, failure modes, and resource constraints.

Most engineers are naturally better at one. The rare engineer who is very good at both is extraordinarily valuable.

The 0.1% Engineer — dangerous competence at the intersection of teaching and plumbing
The 0.1% engineer masters their natural strength and gets good enough at the other to be dangerous.

I am better at: Teaching / Plumbing

Diagnostic — Team Capability Map

Most engineering managers staff agent teams like traditional teams — by seniority and language proficiency. But agent teams need both teaching and plumbing skills. Map your current team to find the gap before it becomes a bottleneck.

// MAP YOUR TEAM

team_size =

strong_at_teaching = engineers

strong_at_plumbing = engineers

strong_at_both = engineers

// If strong_at_both == 0, you have a single point of failure

// at the intersection. That person doesn't exist yet. Grow them.

← Chapter 7 The Invisible Complexity Problem