Software development has always been about abstraction layers. We moved from assembly to C, from C to Python, from writing SQL by hand to using ORMs. Each leap let us think at a higher level. The next leap is here: orchestrator agents that read structured config files and coordinate specialized subagents to ship features while you watch. I built a feature in six minutes this way — not six minutes of coding time, six minutes of elapsed time, start to finish.
This article walks through what the orchestrator pattern actually looked like in practice, how MDX config files served as the source of truth, and what changes about engineering work when agents handle decomposition.
The problem I was solving
I needed to add a new content type to a documentation site. The site already had articles and tutorials. Now it needed glossary entries with different metadata, different templates, and different routing rules. In the old workflow, this meant touching five files: a content schema, a template component, a route handler, a build script, and a test suite. Each required context switching. Each invited typos.
The new workflow started with a single MDX (Markdown extended with embedded JSX) frontmatter file describing what I wanted. The orchestrator read it, reasoned about dependencies, spawned subagents to handle routing and templating and testing, and integrated their output. I reviewed diffs, approved changes, and deployed. Six minutes.
How I structured the MDX frontmatter files
Each content type lived in a .config.mdx file with four fields in the frontmatter: name, description, model, and color. The name field was the canonical identifier—"glossary", "tutorial", "case-study". The description explained what this content type was for in plain English: "Short-form definitions of technical terms, optimized for quick reference." The model field specified which language model variant should handle content generation for this type. The color field set the accent color in the UI.
That's it. No JSON schema. No TypeScript interfaces. Just structured data in a format humans can read and write without consulting docs. The orchestrator treated these files as the source of truth for everything downstream.
When your config files are literate, your agents can reason about intent, not just parse syntax.
The main orchestrator pattern
The orchestrator agent ran a loop with three phases: scan, plan, and execute. In the scan phase, it read all .config.mdx files and built a dependency graph. Adding a new content type meant creating routes, which depended on templates, which depended on schemas. The plan phase generated a task list in dependency order. The execute phase spawned a subagent for each task and collected results.
The key insight was treating the orchestrator as a coordinator, not a do-everything superagent. It didn't write code. It didn't touch the filesystem. It read config, made decisions, and delegated. Think of it like a conductor: the conductor doesn't play the instruments, but the orchestra only works because the conductor exists.
│
▼
Orchestrator (main session — stays clean)
│
┌────┼────┐
│ │ │
[analyze] [implement] [test]
md md md
│ │ │
summary summary summary
│ │ │
└────┼────┘
▼
Main session
3 summaries
This pattern scaled because each subagent had a narrow scope. The routing subagent only cared about URL patterns and file paths. The templating subagent only cared about React components and props. Narrow scope meant faster inference, fewer hallucinations, and easier debugging when something went wrong.
How subagents were spawned
Each subagent got a context bundle: the relevant config file, the file it needed to modify, and a natural language instruction. For the routing subagent, that instruction was: "Add a route for the glossary content type that matches /glossary/:slug and loads the GlossaryTemplate component." The bundle included the existing route file so the subagent could match the existing style.
Spawning was asynchronous. The orchestrator didn't wait for the routing subagent to finish before starting the templating subagent—they could run in parallel because the dependency graph said they were independent. This shaved two minutes off the total time. When subagents finished, they returned not just code, but a confidence score and a list of assumptions. Low confidence triggered a human review gate.
The orchestrator also passed memory between subagents. When the schema subagent added a lastUpdated field to the glossary type, it wrote that fact to shared memory. The templating subagent read from shared memory and automatically added a timestamp display to the template. No one told it to—it inferred the relationship from context.
What Claude Code did that surprised me
Claude Code, the subagent handling the test suite, wrote integration tests I hadn't asked for. I specified unit tests for the new route handler. It wrote those, then added end-to-end tests that spun up a test server, created a sample glossary entry, fetched it through the full routing stack, and validated the rendered HTML. The tests passed on the first run.
The surprise wasn't that it could write tests—that's table stakes. The surprise was the taste. It identified an edge case (what happens when a glossary entry has no lastUpdated timestamp?) and wrote a test covering it before I noticed the gap. It matched the existing test style—same assertion library, same fixture patterns, same naming conventions—without explicit instructions.
This is different from autocomplete. Autocomplete suggests the next token. This was anticipating the next problem. The agent read the config, inferred that timestamps were optional, reasoned about the implications, and acted. That cognitive leap is new.
| Traditional autocomplete | Agent reasoning |
|---|---|
| Suggests next line of code | Identifies missing test cases |
| Matches local patterns | Infers global requirements |
| Reacts to what you type | Anticipates what you need |
What this means for how engineers should think about tasks
Stop thinking in terms of "tasks I need to do" and start thinking in terms of "outcomes I need to specify." The unit of work used to be the pull request. Now it's the specification. You don't write the code, you write the intent—clearly enough that an orchestrator can decompose it into subproblems and dispatch them.
This shifts the skill set. Writing clear specifications matters more than knowing the standard library. Reviewing diffs matters more than writing them from scratch. Debugging orchestration logic (why did the agent choose this approach?) becomes the new bottleneck. Engineers who thrive will be the ones who can prompt effectively, structure config files well, and reason about agent behavior.
The flip side: you can't abdicate judgment. Agents are fast, but they don't have product sense. They don't know if this feature will confuse users or if that API design will cause maintenance pain in six months. The orchestrator executes your plan. It doesn't decide if the plan is good.
The Karpathy connection — agents as the new functions
Andrej Karpathy has argued that large language models (LLMs) represent a new abstraction layer — a runtime in which natural language sits roughly where assembly once did. If that framing holds, agents are the new functions. In the old paradigm, you wrote functions that encapsulated logic. You composed functions into modules, modules into libraries, libraries into systems. The compiler handled the translation from high-level code to machine instructions.
In the agent paradigm, you write specifications that encapsulate intent. You compose agents into orchestrators, orchestrators into workflows, workflows into products. The LLM handles the translation from natural language to code. The unit of abstraction moves up one more level. Just as you don't write assembly anymore (unless you have a very specific reason), you won't write boilerplate CRUD code anymore. You'll specify what CRUD behavior you want and let an agent generate it.
This doesn't mean "no code." It means the code you write is the part that requires human judgment—the business logic, the edge cases, the stuff that matters. The rest is generated, reviewed, and integrated. The signal-to-noise ratio in your codebase goes way up.
What this means for builders
Invest in config-as-code infrastructure. If your system's behavior is driven by config files that agents can read and reason about, you unlock orchestrator workflows. MDX works well because it's structured data plus literate content. But YAML with good comments, TOML with clear schemas, even well-organized JSON can serve the same purpose. The key is machine-readable and human-readable.
Design for agent composition. Build tools that agents can invoke through natural language APIs. If your CLI tool requires twelve flags and a context file, an agent will struggle to use it correctly. If it takes a single JSON payload with sane defaults, agents can call it reliably. Think of agents as the new target audience for your developer tools.
Watch for new failure modes. Orchestrators fail in ways traditional code doesn't. An agent might misinterpret a specification, make a reasonable but wrong assumption, or generate code that works but doesn't match your architecture. Build logging, versioning, and rollback into your orchestrator layer from day one. Treat agent-generated code like any other generated artifact—it needs review gates and integration tests.
Conclusion
The six-minute feature wasn't a fluke. It was a preview of a different development model—one where engineers spend time on problems, not on syntax. Orchestrator agents and structured config files are the infrastructure layer that makes this possible. The work doesn't vanish. It shifts from writing every line of code to writing clear specifications, reviewing agent output, and making judgment calls about architecture and product.
This is the abstraction leap. Assembly to C let us stop thinking about registers. Functions to modules let us stop thinking about memory layout. Agents to orchestrators let us stop thinking about boilerplate. The engineers who adapt fastest will be the ones who recognize that writing less code can mean building more software—as long as they know how to direct the agents doing the writing.