Fast builders stay close to new tools while avoiding workflow work that the major labs will soon make part of the default experience.
2
Teams should protect some parts of their code and knowledge with strict human review while letting agents work more freely elsewhere.
3
Coding agents become more useful when they have shared organizational context, persistent cloud sandboxes, and ways to collaborate with people and other agents.
Summary
Charlie Holtz explains the working habits he has seen among fast builders while building Conductor, a desktop app for managing multiple coding agents. He recommends trying new tools as they appear, but asks builders to avoid spending time perfecting workflows that will soon become standard features. Teams should mark some areas, such as migrations, documentation, and agent skill files, for careful human review. They should also collect Slack messages, bug reports, and meeting recordings in a database that agents can query. Holtz argues that agents need persistent sandboxes so they can keep working after a laptop closes. His Conductor demo shows cloud workspaces, real-time collaboration, and agents that can start new workspaces through an API from a phone or messaging app. He rejects the phrase "software factory" and prefers an orchestra model, where a human guides people and agents while moving between high-level direction and detailed review.
The fastest builders stay near new tools without living at the frontier
Holtz says builders should try new tools close to the day they appear. This can reveal what a company should build, as happened when Conductor grew out of the team's workflow with Claude Code, cloned repositories, and work trees. People inside established companies can also become the person who knows the newest workflows. He warns against going too far, though. Spending all day tuning a workflow can replace actual work. His test is to ask why the workflow is not already the default. If a method works for everyone, Anthropic or OpenAI may add it to the standard experience. The exception is information specific to your users or codebase.
Teams should spend workflow effort where they have information models lack
Holtz calls his rule "don't beat the market." Builders should avoid optimizing heavily around a general technique unless they have some advantage based on their users or application. He gives Conductor's chat rendering as an example. The product has to render very long chats quickly, so the team spends time optimizing React queries and accepts tradeoffs elsewhere in the codebase. That application-specific knowledge is a reason to invest in the workflow. Without it, Holtz compares elaborate setup work to having an impressive Emacs configuration while failing to get work done.
Strict review should protect selected parts of the codebase and agent context
Conductor uses the idea of a "slop-free zone" for areas that need strict human review. The team is loose in some parts of the codebase and careful in others. Changes to migration files require human review in CI because careless changes had forced the team to rewrite the app more than once. Holtz also treats Slack messages as human-written, and puts substantial effort into documentation, AGENTS.md or CLAUDE.md files, and skill files. He compares those files to instructions whispered to an intern every time they begin work. Since agents load them into context, the instructions deserve deliberate writing.
Agents need a shared store of the organization's working context
Conductor's internal agent, called the CIA, collects information from across the organization. It saves Slack messages to a Postgres table, takes in bug requests from Discord, and adds recorded meetings. Holtz calls this "feeding the beast" because agents need context about how a particular company works. His preferred pattern is to put the information in one database, give the agent a SQL tool, and let it query what it needs. The point is to make company-specific knowledge available to agents instead of leaving it scattered across separate conversations and meeting records.
Persistent sandboxes let agents work beyond a laptop session
Holtz says agents should have room to explore a codebase, work on difficult tasks, and continue after the user closes a laptop. They should be able to collaborate with other agents and people, and have opportunities to create more agents. As models run for longer and more agents appear, confining them to one laptop limits what they can do. Conductor's new cloud version puts each workspace in a cloud sandbox. In the demo, a user can close the laptop while the agent continues working.
Cloud workspaces make agent work visible and collaborative
The Conductor demo shows a person viewing the work of colleagues in the same organization. Holtz can see what Cadence, Lewis, Tywan, and Jackson are doing, open a workspace, review changes, and send a request to use tabs instead of spaces. The other person can see the message and type back in the shared workspace. Holtz argues that collaboration matters because ambitious projects need teams of people and agents. He presents shared, real-time workspaces as a new interface for that collaboration.
Agents can start work through APIs while their owner is away
Holtz shows an agent called Lord Crandon with access to a Conductor API. From a phone, Telegram, Slack, or another location, he can ask it to create a workspace that changes all the buttons to blue. The agent creates the workspace and starts the task while Holtz is away. This depends on the persistent cloud sandbox, since the work can continue without the user's laptop. Holtz sees agent-created workspaces as one of the things that becomes possible when agents have room to run and APIs through which they can act.
Holtz wants humans to conduct teams of people and agents
Holtz rejects the factory metaphor because it suggests automation, production lines, and people managing agents by pushing buttons for the next feature. He prefers an orchestra, where a human stays in the flow, directs different groups of agents and people, and zooms into details when needed. He connects this to the old idea of feature factories, which he says did not produce software that felt human and carefully made. His closing principle is to keep a human at the center, with tools that help people craft software rather than manage an assembly line.
