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.
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
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.
I am better at: Teaching / Plumbing
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.