software has always been orchestration
LLMs didn't invent orchestration. They just made it visible by collapsing the implementation layer.
LLMs didn’t change what software is. They just stripped away the noise. Software engineering has always been orchestration.
We move data, coordinate transformations, and assemble outputs. The implementation details were just the friction we accepted to get the orchestration done.
When the “how” of implementation became cheap, what remained was the “what” and “in what order.”
The orchestration layer, previously hidden inside our code, became the primary artifact.
The Hidden Orchestration Layer
Think about any web app you’ve built. The structure is the same:
- Fetch data from somewhere
- Transform it into the shape you need
- Render it to the user
Or an API:
- Receive a request
- Validate and process it
- Return a response
Or a CLI:
- Parse input
- Execute some logic
- Format output
These patterns aren’t about the language or framework. They’re about coordination. We embedded orchestration logic inside implementation details, and the implementation details were so loud that we couldn’t hear the orchestration.
Every line of code that actually matters is a handoff: this function calls that service, which returns data that feeds into this transformation, which renders into that component.
The rest is syntax, plumbing, and boilerplate.
What LLMs Collapsed
When I started using LLMs, the boilerplate evaporated. The syntax became a non-issue. What remained was the layer I’d always spent the most mental energy on: defining what should happen and in what order.
Karri Saarinen1 calls this “the disappearing middle.” The layer between intent and implementation is thinning. The code I write now is mostly glue, stitching capabilities instead of implementing them.
The New Primitives
If software is orchestration, then we’re really just orchestrating four specific things. These haven’t changed, but their shape has.
- Intent is the goal. In traditional code, we froze this into function signatures and user stories. Now, we express it dynamically in prompts.
- Context is what the system knows. We used to manage this with database state, props, and global variables. Now, it’s the context window we curate for the model.
- Capability is what the system can do. We used to import libraries and API clients. Now, we expose tools.
- Verification is how we know it worked. We relied on unit tests and type checks. Now, we need assertions or llm-as-a-judge to verify stochastic output.
These aren’t abstract concepts. They are the components of every prompt and every agent loop.
Addy Osmani2 calls this being a “clarity merchant.” The bottleneck is no longer syntax, but the ability to specify intent so clearly that the system can’t misunderstand it.
Skills That Transfer, Atrophy, and Emerge
This shift has implications for what’s worth learning.
- Transfer: System design, data flow, interface boundaries. (The thinking).
- Atrophy: Syntax memorization, boilerplate production. (The typing).
- Emerge: Context engineering, constraint specification, verification design. (The directing).
I used to pride myself on knowing how to implement a feature from scratch. Now, I find pride in knowing how the pieces fit together.
The Code Becomes a Coordination Layer
Here’s the practical upshot: the code you write is increasingly a coordination layer between intent, context, and capability.
Consider a simple agent loop. The code doesn’t “do” much in the traditional sense. It:
- Assembles context from various sources
- Expresses intent through a prompt
- Invokes capability (the model)
- Checks verification (did the output meet the criteria?)
- Loops until done
There is no “real work” hidden beneath the orchestration anymore. The loop (assembling context, prompting intent, invoking capability, and verifying output) is the product.
This was always true for software, but we couldn’t see it. The ceremony of writing functions, managing state, and handling errors felt like the work. Now they feel like what they always were: infrastructure for the orchestration.
What This Means for What’s Next
If software is orchestration, then the questions that matter are:
- How do I orchestrate intent clearly?
- How do I curate context effectively?
- How do I expose capability cleanly?
- How do I design verification that closes the loop?
These questions frame the following explorations. Each one is really just a deeper look at one facet of orchestration:
- The planning bottleneck is about orchestrating intent.
- Thought completion is about orchestrating the trajectory of reasoning.
- Harness design is about orchestrating capability through infrastructure.
- Attention as a budget is about orchestrating context through curation.
They’re all asking the same thing: given that the implementation layer has collapsed, how do we get good at the thing that remains?
The answer, I think, is to stop treating orchestration as the boring glue between the interesting parts. It is the interesting part. It always was.