Since the end of 2025, I've been thinking a lot about how to improve my development workflow with AI agents. Like many developers, I started using agents in their simplest form: manually. One agent, one task, a lot of supervision, and a lot of interaction to keep the work moving in the right direction. As I became more comfortable with these tools, understanding how to communicate with them, how much context to provide, and when to intervene, the main question started to change. It was no longer just about how AI could help me write code, but how much of my development workflow I could delegate to AI without losing control or quality.
My First Attempts at Agent Orchestration
I previously wrote about my first orchestration design using subagents. The design itself was reasonably solid, even though there was still a lot to improve, but getting consistent results from it was difficult. The parent agent was not always reliable when coordinating subagents. For example, after spawning a subagent, it would sometimes continue doing unrelated work instead of waiting for the delegated task. In other cases, it would repeatedly poll the subagent for results or start working on something that had already been delegated. That created duplicated work, unnecessary context usage, and unpredictable behavior.
This wasn't only a prompt-design problem. Part of the issue seemed to come from limitations in the agent harness or model behavior itself, and I even opened an issue in the openai/codex repository documenting one of these cases.
What Changed
Recently, however, this has started to change. For my workflow, Codex subagent orchestration has become reliable enough that I can actually design development processes around it. The parent agent can delegate a well-scoped task and wait when waiting makes sense, while I can continue interacting with the main thread, inspect what the subagents are doing, and redirect the work when necessary.
That may sound like a relatively small improvement, but I don't think it is. Once delegation itself becomes dependable, the problem changes. You can start thinking about which tasks should be delegated, which can run in parallel, which depend on previous results, what context each agent actually needs, and how the parent agent should integrate everything afterward. At that point, the workflow starts to look much closer to software engineering than simply asking a model to "implement this feature."
Planning Before Orchestration
This is also where planning becomes much more important. The fact that an agent can spawn several subagents does not mean that it should. Before delegating anything, I try to understand the feature and break it into tasks with clear boundaries, expected outputs, relevant constraints, and known dependencies. Some tasks should run sequentially, while others can happen in parallel.
One agent may investigate an unfamiliar part of the codebase, another may work on tests, another may review an implementation, and the parent agent can later combine those results into the next step. The important part is not the number of agents. It is whether the work has been decomposed correctly.
Repository-level context also becomes much more valuable in this model. Good AGENTS.md instructions, architecture documentation, project conventions, reusable skills, tests, strict type requirements, and other forms of persistent context give future agents a foundation they can reuse. Without that foundation, every new agent has to rediscover the project. With it, agents can enter the repository with a much better understanding of how the system works and how they are expected to behave. In practice, the quality of the orchestration depends not only on the model or the harness, but also on how well the project itself is prepared for agents.
AI Is Not Only About Building Faster
Another thing I've been thinking about is how we measure the value of AI in software development. Most discussions focus heavily on speed: how quickly a feature can be built, how much code an agent can generate, or how fast something can be shipped. I don't think that is the most interesting part.
Before working this way, I worked professionally at a software house where I shipped thousands of production commits. Like many teams working under real client deadlines, we constantly had to make trade-offs. A feature needed to go live, another task was already waiting, and the client needed the change. Because of that, work that we knew would improve the project could easily be postponed: more automated tests, broader integration coverage, additional edge-case validation, deeper refactoring, better documentation, or simply more polish. The problem was not that these things were unimportant. The problem was time.
AI Changes the Economics of Quality
This is where I think AI changes something important. It reduces the cost of doing some engineering work that was previously expensive in terms of developer time. An agent can investigate edge cases while another works on implementation. A subagent can expand tests without forcing the parent agent to carry every implementation detail in its context. Another agent can review a change against the original requirements or inspect an unfamiliar part of the codebase before any code is changed.
None of this removes the need for engineering judgment, and it does not guarantee quality, but it makes some work much cheaper to perform.
That is also why I don't care if I sometimes spend hours or even days working with AI on the same feature. If the result has better architecture, stronger tests, fewer edge cases, better documentation, and a more polished implementation, then the value is not that AI helped me finish the feature in twenty minutes. The value is that AI allowed me to spend engineering effort differently. For me, AI is becoming less about building faster and more about making it practical to build with more quality.
Anyone who has spent enough time developing with AI agents also knows that generating something that works is becoming relatively easy. Generating something that is consistent with the existing architecture, maintainable, properly tested, understandable by another developer, aligned with the product requirements, and free from generic AI defaults is a different problem.
This is especially visible in frontend work, where agents can easily converge toward similar layouts and visual patterns without strong direction, but the same problem exists in backend development. Agents can introduce unnecessary abstractions, inconsistent naming, duplicated logic, weak boundaries, or solutions that technically work but do not really fit the architecture of the system. Better models help, but the workflow around them still matters just as much. Planning matters, context matters, task boundaries matter, and review still matters.
What This Looks Like in Practice
I've been applying these ideas while building my public project TowelBooks and while contributing to different projects through my GitHub. A large amount of that work has been done with relatively low-cost models such as GPT-5.6 Luna, which is another part of this shift that I find interesting.
Agentic workflows do not necessarily require using the most expensive model for every step. A stronger model can be useful for architecture, planning, difficult reasoning, or ambiguous problems, while smaller implementation, investigation, testing, and review tasks can often be delegated to cheaper models once the work has been decomposed properly. Good task decomposition can therefore improve reliability and cost efficiency at the same time.
Final Thoughts
What interests me most about this direction is not the idea of an agent generating an entire application from one prompt. It is the possibility of building a development workflow where we can decompose engineering problems, delegate focused pieces of work, execute independent tasks in parallel, preserve context boundaries, review intermediate results, and coordinate everything through a parent agent.
The developer still owns the architecture, defines the constraints, decides which trade-offs are acceptable, and remains responsible for the final result. But the amount of engineering work that can happen around those decisions is increasing quickly.
You may have noticed that I've mentioned Codex a lot throughout this article. That's simply because it has become my primary AI development tool. I've been particularly impressed by how quickly the agent experience has evolved. For my workflow, combining stronger models for planning and reasoning with lower-cost models for implementation and delegated tasks has made multi-agent development much more practical.
The most interesting part, though, is not any single model. It is that the surrounding tooling is finally becoming reliable enough for these workflows to move from experiments into actual software development processes.