Orchestras, Not Factories: How the Fastest Builders Work — Charlie Holtz, Conductor
Charlie Holtz, co-founder and CEO of Conductor, shares six principles he has observed among the best AI-assisted builders, including staying near the frontier, creating slop-free zones, and giving agents cloud sandboxes. He also demos real-time collaboration and phone-initiated agents, and argues for orchestras over factories, with humans at the center of AI-driven development.
Charlie Holtz, co-founder and CEO of Conductor, a desktop app for running many coding agents at once, opens by saying he ‘honestly kind of hate[s] the term software factory.’ Having watched many of the best builders up close, he distills what they have in common into six principles, then demos where Conductor is heading.
Stay near the frontier
The first principle is to always be trying the latest tools, close to the day they ship. Holtz’s examples are trying new Claude Code features the moment they drop. He gives two reasons. For founders, frontier experimentation generates product ideas. Conductor itself came out of this: the team was building a different app, Chorus, but became such heavy Claude Code users in February of the previous year that they cloned their repo five times, discovered git worktrees, and gradually built Conductor as an internal tool. For people inside companies, he argues that the old social-graph trickle-down of workflow knowledge no longer works because things move too fast. Relying on it means being three to six months behind. The key word is ’near.’ Sitting exactly at the frontier invites what he calls ‘midwit memeing,’ spending all your time optimizing your workflow instead of doing real work.
Don’t try to beat the market
To calibrate, Conductor uses a heuristic: ask ‘why isn’t this workflow the default?’ If a practice like Ralph loops works for everyone, Anthropic or OpenAI will eventually build it into the default harness, so spending heavy effort on it now is wasted. Holtz frames this as an efficient market hypothesis. Unless you have ‘real alpha,’ meaning information about your users or your codebase that the models don’t have, don’t over-optimize. Conductor’s own example is its chat app, which must render very long chats quickly. The team invests heavily in optimizing React queries and accepts tradeoffs elsewhere in the codebase to make that happen.
Create slop-free zones
Conductor defines a ‘slop-free zone’ as a part of the codebase or app that requires strict human review. Holtz pushes back on the assumption that his team ships huge AI-generated PRs. They are careful in some areas and loose in others, and carelessness had forced them to rewrite their whole app a couple of times. Concrete examples include migrations, where CI requires a human to review any change. Anything written in Slack is treated as human-authored and therefore slop-free. Docs, CLAUDE.md files, and skill files receive disproportionate care. He compares a CLAUDE.md or agents.md file to whispering in a new intern’s ear every morning, since it is loaded into the agent’s context each time it starts working.
Feed the beast
Conductor’s internal agent, nicknamed the CIA, serves as a centralized database of everything happening in the organization. New Slack messages, Discord bug reports, and recorded meetings all get picked up and saved to a Postgres table. The purpose is to give agents as much context as possible about how the team specifically works. The recipe is simple: put everything in one database and give the agent a SQL tool.
Free-range agents
Agents need room to operate. That means sandboxes that won’t get killed, where they can explore the codebase, tackle hard tasks, spawn more of themselves, and collaborate with other agents and humans. Holtz’s argument is that models keep getting better at running for longer and there will be many more of them. Confining them to a laptop will make them far less effective, and a cloud sandbox opens up a range of things you can build on top.
Demo: cloud, collaboration, and phone control
The new version of Conductor, rolling out this week, centers on the cloud. Each workspace has a cloud icon showing its sandbox, and agents keep running after the laptop lid closes. Until recently every task ran on a git worktree. Holtz calls real-time collaboration one of the most important and least discussed interface shifts. Teammates can see one another’s workspaces and what they are working on in real time, and chat inside a workspace. In the demo he reviews a colleague’s changes and asks ‘can we actually use tabs, not spaces?’, and the colleague sees the message live. He ties this to model progress: as models improve, teams take on more ambitious work and need more people and agents on it. Agents can also spawn agents. His OpenClaw agent, named Lord Crandon, has access to a Conductor API, so from his phone Holtz texted a request to create a workspace that makes all the buttons blue. The agent set up the workspace and started working while he was away.
Orchestras, not factories
The final principle is the talk’s title. Holtz dislikes the ‘factory’ metaphor because it evokes automation, line managers pushing buttons, and swarms of agents pumping out features. He notes that the industry tried a similar framing a decade ago with feature factories, and it didn’t work. He wants software to feel human and crafted: a conductor standing in front of a blend of humans and agents, waving a baton, zooming in on details when needed and zooming out most of the time. He argues that toolmakers have a responsibility to choose words and designs that make people feel excited, capable, in flow, and having fun. He closes by saying he wants to feel like Steve Jobs designing the Mac with a team of amazing humans and AI agents.
Recap
The six principles are: stay near the frontier, don’t try to beat the market, create slop-free zones, feed the beast, give agents free range, and think orchestras, not factories. Holtz packages them in a mnemonic he calls ‘Stickfo’ to make them easier to remember.