The first time I started building with AI, I treated each model like a separate specialist. I moved from one application to another: one model for brainstorming, another for research, another for coding, another for review.
Every transition created friction. I had to restate the context, explain the project again, repeat the constraints, and carry decisions from one tool into the next by hand.
The models were capable. The workflow was not.
The biggest efficiency gain was never going to come from finding a single best model. It comes from designing a system that gives each model a clear role and coordinates the work between them. That is what led me to build a harness around an orchestrator.
The challenge was not model quality
My earlier projects involved a surprising amount of hand-holding. I spent time troubleshooting authentication, moving prompts between applications, checking whether a model had actually completed a task, and repairing misunderstandings caused by missing context.
The work often looked like this:
- Think through a problem in one application.
- Copy the result into another.
- Ask a coding model to interpret it.
- Move the implementation back for review.
- Discover that an important constraint was lost along the way.
- Repeat.
This was not an intelligence problem. It was an orchestration problem.
The models needed better task boundaries, better shared context, and a workflow that could tell planning, implementation, testing and review apart.
The orchestrator changed the workflow
The orchestrator became the control layer.
Instead of directing every model interaction myself, I could define a larger objective and delegate focused work to the appropriate worker. One model prepares the brief. Another implements a narrowly scoped change. A separate reviewer inspects the result without modifying it.
That separation is the part that mattered. The orchestrator handles the continuity and coordination I was previously managing by hand. The individual models execute specific tasks against explicit acceptance criteria. Less context switching, less repeated explanation, much less uncertainty about what actually happened at each stage.
None of this removes the need for human judgment. It moves that judgment to the points where it is worth the most: architecture, risk, scope, approval.
The hard parts were operational
Setting up the harness was not effortless, and almost none of the difficulty was about prompts.
It was configuring authentication correctly, understanding which accounts were being used, enabling the right delegation tools, choosing models and reasoning levels, and learning the boundaries of each execution environment.
One discovery stands out. A delegated coding worker could modify project files but could not modify Git references, which meant it could not create or switch branches itself. The fix was simple once the cause was clear: the orchestrator creates or switches to the feature branch first, and the worker does its scoped work on the branch that already exists.
That class of problem is easy to miss when you are thinking only about models. In practice, AI-native engineering depends as much on permissions, state management, source control and verification as it does on model capability.
Planning became a first-class activity
The harness also changed how I plan software.
Planning used to feel like a preliminary step before the real work began. Now it is part of the execution system. A project moves through explicit stages: source review, specification, clarification, planning, implementation, testing, review. Each stage has a purpose and a stopping point.
That structure keeps the system aligned with a real architecture and a real timeline. It also creates natural review gates, before implementation decisions get expensive to change.
The goal is not to generate more code faster. It is to get from a validated problem to a coherent system with fewer unnecessary loops.
What actually improved
Moving between model applications treats every interaction as a new beginning. An orchestrated harness treats the work as a continuous process with shared state, defined roles and controlled handoffs.
- Less repeated context and explanation.
- Clearer ownership of each task.
- Easier troubleshooting when something fails.
- A reliable separation between planning and implementation.
- Specialized models doing specialized work.
- Stronger review and approval points.
- A clearer path from architecture to execution.
The largest gain has been cognitive. I am no longer the message bus between every tool.
Why this matters for how we build
This is how we intend to work, in both arms. Not an AI assistant bolted onto an existing process, but systems where AI workers do meaningful parts of the work and people keep control of direction, risk and accountability.
An orchestrated harness is one layer of that. It is also reusable. The patterns that come out of building internal tools are the same patterns that turn up in client work.
The lesson I am carrying forward
AI productivity is not mainly about asking better questions in isolation. It is about designing better systems for getting work done.
The models matter. So do the task boundaries, the shared context, the permissions, the review gates, the source-control strategy, and the decision about which worker should do what. Once those are in place the experience changes: the system absorbs the operational overhead, and the attention goes to architecture, product judgment and the decisions that are actually hard.
Not replacing the builder. Giving the builder a much better operating system.