Why Orchestration May Be the Future of Agentic Development

For now, AI agents are autonomous entities to which users can delegate simple tasks: Monitor your calendar. Sort emails. But for now, when the time comes to combine a variety of tasks, or execute a complicated multi-step process, agents generally need orchestration and additional human supervision to get any semblance of reliable performance.

While some analysts predict significant adoption of agentic into enterprise apps this year, we haven’t quite arrived at the exciting future state where agents can handle complicated, time-consuming tasks on their own with little supervision. Yet. Open-source creator Moaz Muhammed explains his approach to agentic orchestration in the CodeMachine project.

From Spec-to-Code to Architecture

The creator explains the origins of his project as being a spec-to-code project, initially intended to help users build enterprise-grade projects without the friction of using complicated coding tools. “We started with one hard-coded workflow. However, we ended up having the project build about 90% of itself via dogfooding.”

“The initial idea was having a workflow to build architecture, then start converting the architecture into a plan. Like agents in a workflow, with the first agent writing architecture and related decisions like which stack to use: front end, back end, and so on. Another agent took the MD file and converted it into a plan. A third agent converted the plan to tasks based on the size and scope of the project.”

Moaz notes that the original architectural spec seemed to be a hit with early users and may have gone on to influence the structure of subsequent AI projects. But over time, feedback started to vary, with software engineers taking issue with the original projects’ waterfall-based methodology.

“They said, ‘We want something faster.’ Some projects would take hours to build. I even built one with about 80,000 lines of code, which proved that CodeMachine was at least capable of building huge projects. It wasn’t perfect, but a good starting point, because CodeMachine provided a real and organized scope, with every file in its place, everything well documented and explained without human supervision.”

The creator explains that as the project evolved, he shifted to more of an engineering focus with clear architecture. “This was a very big problem [for AI developer tools]. When you started a project, you couldn’t scale it, because you weren’t really building. You were ‘vibing.’” By shifting focus on building full architecture for projects, Moaz was able to avoid generating spaghetti code projects.

“From there, we pivoted from being hard-coded to a single workflow into being a workflow infrastructure for any kind of workflow. That was actually a huge transformation.”

Growing Adoption with Tool and Framework Choices

Moaz explains several deliberate choices he made over the course of building the project, such as focusing on command-line interface over the more-common browser-based chat window. “Not only was the terminal popular in well-known coding tools, but developers building software tend to use a CLI-based terminal interface. They’re familiar with it, and I’m familiar with it. Personally, I love the terminal so much as an interface.”

The creator suggests that some design decisions not only made the project more appealing to engineers, but also made it more marketable. Popular and trendy tools and frameworks can help attract new users despite strong opinions and preferences among technical audiences. “I used to use Node,js, then switched to using Bun, which was becoming an extremely popular alternative even before it was acquired by Anthropic.”

Of course, the choices weren’t all for marketing: The goal was to stay on top of a trending stack while delivering real value, especially since some engineers will always be hesitant to adopt new technologies due to potential bugs and lower reliability. The creator suggests that the strongest projects are those that balance engineering with marketing.

“It's not enough for a product to work. Engineers need to enjoy using it and feel connected to it. The most successful projects understand this human side, making deliberate choices that are not only technically sound but also appealing to the developer community.” So, the decision to move from Node.js to Bun was not purely technical. It also helped the project align with emerging trends and attract attention from engineers who were excited about the new ecosystem.

Between Human-in-the-Loop and Full Autonomy

The creator tactfully avoids weighing in on whether there exists an ideal balance between a fully autonomous agentic fleet or, on the opposite end, a tightly-restricted agentic program with one or more humans in the loop. “I can say that the philosophy of the CodeMachine project sits between [those two extremes]. It depends on the use case.”

“I designed this project to act as infrastructure for workflow agents for any coding task. For example, you could use it as a full pipeline to migrate from ancient languages like COBOL to a modern language. Some workflows might need permission or some sort of user interaction at times, but you can set the interactive portions of your project to control every autonomous step.”

“It's an orchestration platform that lets you run long-running workflows in any configuration you want between interactive and autonomous.” The founder also concedes that there are well-founded concerns about agentic security, but emphasizes that security is up to individual builders.

“Users will interact with this project like infrastructure. For those who prioritize security, local models are a solid option. CodeMachine is fully local. Any data it stores stays on your device and never leaves it. The only point where data exits is when it's sent to your provider, such as Claude Code or Codex. So while the project itself poses no security concerns, full end-to-end security comes down to keeping your setup as local as possible.”

What Agentic Means for Future Developers

The creator is optimistic about a future that enables builders, rather than focusing heavily on technical expertise. “I think the future is going to belong to people who have a ‘builder’ mindset, who can think in terms of architecture and how to build things brick by brick.”

The creator suggests that the future of software will belong to builders who embrace this different set of skills. “People who take the initiative to build things, whether using Claude Code or other tools, but also have the curiosity to ask why Claude and other tools make the choices they do. People who are curious about the why will build the next great era of products.”