Discover how Conductor CEO Charlie Holtz uses AI coding agents to replace manual coding. Learn his AI setup, tools, and workflow optimization strategies.
AI Coding Setup: How Conductor's CEO Uses AI Agents Daily
Key Takeaways
- Gooseneeck microphones ($20) enable hands-free voice commands to Claude, reducing office disruptions while maximizing AI interaction
- Multi-workspace workflow allows simultaneous agent tasks across different coding challenges with keyboard shortcuts for seamless context switching
- Token maxing strategy achieves $22,000+ monthly spending with tens of thousands of lines of code generated, but prioritizes code quality over quantity
- AI-human collaboration model combines Claude for creative problem-solving with Codex for heavy-duty debugging and implementation
- Strategic code boundaries ("slot-free zones") prevent AI from spiraling into bad code patterns while maintaining human-written core infrastructure
The Evolution of AI-Assisted Coding: From Manual Work to Agent Orchestration
The traditional developer workflow is undergoing a fundamental transformation. Charlie Holtz, co-founder of Conductor—a YC Summer 2024 company that orchestrates multiple AI coding agents on Mac—doesn't write code anymore. Instead, he directs AI agents like an orchestra conductor, and this shift represents where professional software development is heading.
Five years ago, developers spent most of their day actually typing code. Today, the best developers are spending their time describing what they want built and how it should be built. Code has become what Holtz calls "sawdust"—a byproduct of the prompting process rather than the primary focus of development. This philosophical shift changes everything about how developers should approach their work, their tools, and their professional growth.
The implications are profound: when the next generation of models arrives, you simply re-run your prompts and get new code. The old code didn't matter. What matters is your ability to articulate requirements, iterate on AI output, and maintain quality boundaries. This is why Conductor exists—to make this new workflow feel natural and efficient rather than clunky or restrictive.
Designing the Physical and Digital Workspace for AI Collaboration
Most developers haven't optimized their physical environment for constant AI interaction. Holtz's first recommendation seems deceptively simple: a $20 gooseneeck microphone from Amazon. Yet this single tool reveals deep thinking about how human-AI collaboration actually works in practice.
In an open office environment, constantly talking to your computer feels disruptive. Traditional approaches like typing queries into chat interfaces break focus and kill momentum. A quality microphone allows you to lean over and whisper commands like "merge PR 3475" without disturbing colleagues. More importantly, it makes the interaction feel conversational rather than transactional. You're having a dialogue with an intelligent agent rather than submitting tickets to a system.
The digital workspace deserves equal attention. Conductor's interface solves a problem that terminal-based workflows never addressed: humans are spatial, visual creatures. A command-line interface might work well for AI brains, but it restricts how humans can organize information and maintain context. Conductor places all active chats on the left sidebar, the current conversation in the center, and a code review panel on the right. This spatial organization means you immediately know where to find what you need.
Keyboard shortcuts amplify this efficiency. Holtz uses Command+N to spawn new workspaces and Command+Shift+Y to jump between them. Every common action should have a shortcut. This isn't optimization for its own sake—it's about maintaining flow state when juggling multiple AI agents working on different problems simultaneously.
The physical setup matters too. Holtz uses a heavily specced machine (128GB RAM) specifically to run local models like Parakeet for text-to-speech. Yet he's intentionally ordered a base-model MacBook Neo to force himself to build for constraint. This paradox—building on maxed hardware but shipping for minimal specs—ensures Conductor works for all users, not just power users with expensive machines.
Multi-Agent Workflow: Orchestrating Parallel Development Threads
The core insight behind Conductor is that a single developer should be able to orchestrate multiple AI agents working in parallel, each tackling different tasks simultaneously. This changes how you think about daily work structure.
Holtz's typical workflow involves constantly kicking off new tasks through voice commands. He'll ask Claude to examine the latest Linear issue and provide a rough solution approach. While Claude works, he switches to another workspace using a keyboard shortcut. In the sidebar, he can see which workspaces are "in progress," which have PRs "in review," and which are "done." This workspace status system prevents context loss and ensures nothing falls through the cracks.
Experimentation becomes central to this workflow. Holtz maintains multiple parallel branches exploring different approaches. Most won't ship. Some get promoted from "in progress" to "internal" to "experimental" before potentially merging to main. This staged promotion system creates natural quality gates while encouraging rapid iteration. Four PRs might be in formal review while dozens of experimental ideas simmer in parallel branches.
The mobile capability extends this orchestration beyond the desk. Holtz can speak a feature request into his phone—"Add a theme switcher with hacker mode"—and tap "Conduct." His Mac immediately starts implementing the feature. He's literally managing his development team from anywhere, receiving updates and providing course corrections as needed.
This parallel workflow reveals why traditional development tools feel inadequate. GitHub's web interface works for reviewing a single PR, but it's torture when managing five concurrent agent tasks. Conductor's unified interface lets you review code changes, add GitHub-style comments, check CI status, and decide whether to merge—all in one place without context switching to three different browser tabs.
The key is that each workspace is a work tree generating a PR. Forced workflow prevents chaos. You can't edit files directly. Every change goes through PR workflow. This might seem restrictive, but it's actually what enables orchestrating multiple agents—you need clear boundaries between their work.
Strategic Prompting and AI Model Selection: Claude vs. Codex
Not all AI tasks are equal, and selecting the right model matters significantly. Holtz has developed clear mental models for when to use Claude versus Codex, despite both living in Anthropic's ecosystem.
Claude (specifically Claude 3.5 Sonnet, which Conductor calls "Opus") excels at creative problem-solving, architectural thinking, and tasks requiring back-and-forth dialogue. When Holtz is building a new feature, he instinctively reaches for Claude. The model brings more creativity, acts as a true partner in the design process, and handles ambiguous requirements gracefully. Claude shines when you need discussion, when you want to explore multiple approaches, or when the problem isn't fully specified yet.
Codex (Claude's code-focused variant) is the workhorse. It powers through specific problems without hesitation, doesn't fear making dozens of tool calls, and excels at methodical debugging. When the goal is clear—"fix this bug" or "implement this spec"—Codex gets it done. It's not afraid to try multiple approaches, get feedback, and iterate relentlessly until something works.
The token-maxing strategy underpinning this approach is intense. Holtz's highest spending was $22,000 in a single month when Conductor launched in July 2024. With previous-generation models, this translated to tens of thousands of lines of code generated. He's not conservative with tokens. He runs in "fast mode" constantly (not the default setting), pushes models to use full context windows, and has Claude dangerously accept all file permissions to maximize what the model can accomplish.
Yet this doesn't mean maximizing lines of code. Holtz is very deliberate about keeping codebases lean. You can quickly spiral. A codebase metastasizes if you're not vigilant about lines of code added. The difference between a startup building Conductor and maintaining an established codebase is huge—one can be more experimental and loose, the other requires discipline. The goal isn't volume; it's velocity without technical debt.
The skill files and claude.md files deserve special attention here. Holtz spends significant time crafting these prompt documents—often hundreds of lines. They establish engineering practices ("we're a startup, not an enterprise"), define what code quality looks like, clarify where humans must review before AI contributes, and create "slot-free zones" where AI contribution is restricted. These documents are investments that compound over time, letting you spend less time in individual prompts repeating context.
Maintaining Human Control: Boundaries, Review, and Slot-Free Zones
Here's where Conductor's philosophy diverges radically from "let AI do everything." Holtz has built the system specifically to prevent AI from becoming the architect.
The concept of "slot-free zones" is critical. These are parts of the codebase or documentation written entirely by humans. AI can contribute to them, but every single line must be read and approved by a human. This prevents a vicious cycle where the AI sees existing bad code, learns from it, and writes more bad code as a result. The same mechanism prevents positive feedback loops from bloating the codebase—AI getting too aggressive with implementation without proper human oversight.
Some code literally bears warnings: "Do not touch if you are an AI. This is for human eyes only." These boundaries might seem restrictive, but they're actually what enable aggressive AI use elsewhere. You can't let AI be your architect. Design decisions, interface choices, and core abstractions must come from human thinking. The concept of "workspaces" as work trees, the layout of chats on the left and review panel on the right, the decision to show open-in icons in the top bar—these required deliberate human thought and shouldn't be delegated to AI design processes.
This is why building with human-written APIs and contracts matters. The core infrastructure should be stable, well-documented, and mostly off-limits to AI contribution. Large chunks of the codebase can have "free reign" where you throw tons of ideas at AI and know it won't destabilize the foundation. Currently, the boundaries are somewhat murky—something Conductor is actively improving.
Holtz admits that on difficult PRs, he still occasionally opens an IDE and makes changes by hand (what Conductor calls "caveman mode," facetiously). Modern AI is incredible at many tasks, but some changes require human judgment and context that even the best models haven't fully grasped. Showing small tweaks—"that button looks too wide, can you make it smaller?"—often works better than trying to describe the desired outcome abstractly. Highlighting problematic code and adding commentary lets the AI understand your intent through example rather than explanation.
The Interface Philosophy: Why GUI Beats Terminal
This raises the fundamental question: why is a visual interface necessary at all? Wouldn't a command-line interface be simpler and faster?
The answer reveals something important about how humans and AI interact differently. Humans are spatial, visual creatures. We evolved to process information through space and visual hierarchy. A command-line interface feels restrictive because it's fundamentally linear—one thing at a time, scroll up to see context, no spatial organization. Terminal interfaces might work better for AI brains (which are just processing tokens), but they hobble human brains.
A GUI solves this by creating spatial mental models. You know your chats are on the left. Your conversation happens in the center. Code changes appear on the right. This isn't just aesthetic—it's cognitive. Your brain can hold this mental model and navigate it instantly. You're not searching for information; you're finding it in a place you expect.
There's another advantage that terminals truly can't match: interactive visual elements. You can't click a button in a terminal. You can't see a live preview of code changes before merging. You can't visually scan which workspaces have pending reviews. These aren't luxuries—they're essential for managing complexity at scale.
The Conductor interface evolved through deliberate thought. The "open in" button behavior, the collapse/expand states for tool calls, the status indicators for workspace progress—none of this happened accidentally. Holtz describes constantly thinking about interface decisions, testing them, and iterating. The result feels "crafted" rather than generated, which matters because people prefer software that feels intentionally designed.
Building Conviction in an Opinionated Tool
Creating Conductor involved making thousands of small decisions, and building conviction behind those decisions when users want flexibility and configurability is challenging.
Holtz's approach is refreshingly pragmatic: use the product obsessively and trust your gut. Conductor's team doesn't rely heavily on analytics, A/B testing, or data. When something doesn't feel right during daily use, they change it. When an interaction feels smooth and intuitive, they keep it. This gut-driven approach might sound unscientific, but it has an advantage: it prevents analysis paralysis and maintains a coherent vision.
The risk is obvious—you could optimize for personal preference over general usability. Holtz mitigates this through team consensus. Multiple founders using the tool daily creates alignment. If a feature feels wrong to everyone using it constantly, it probably is wrong. This is why he's building Conductor partly by using Conductor itself—dogfooding forces honesty.
There's also a philosophy here about opinionated tools versus flexible tools. Yes, some users want extensive configuration options. But opinionated tools can feel cohesive and crafted. They can establish conventions that make learning intuitive. The trade-off is worth it when the core workflow genuinely solves people's problems better than alternatives.
The Technical Stack: Tauri, TypeScript, and Strategic Language Choices
Understanding Conductor's implementation reveals choices that support the development philosophy.
The desktop app is built with Tauri, which uses the native Safari web renderer. This makes it lightweight compared to Electron while maintaining web technologies. The backend is technically Rust, but approximately 90-95% of the desktop app is written in TypeScript. This consistency reduces context switching—developers aren't bouncing between languages constantly.
The web app is a Phoenix application written in Elixir. Currently, it's minimal because it literally only handles authentication. But Holtz is a huge Elixir enthusiast and actively advocates for more Elixir in the codebase. This preference reflects his values: he's willing to choose languages and frameworks he loves, even if they're less mainstream, because he believes they lead to better software.
This isn't religious zealotry—it's pragmatic preference based on experience. Elixir's pattern matching, immutability, and process model make concurrent systems easier to reason about. For a tool orchestrating multiple parallel agents, this matters.
The Future: Cloud Workspaces and Always-On Agents
The most exciting developments on Conductor's roadmap represent the natural evolution of the product.
Currently, agents stop running when you close your laptop. The Mac is the constraint. Cloud workspaces change this entirely. Imagine describing a complex task, kicking it off, and having agents work continuously in the cloud while you sleep or work on other things. They could work 10x longer, integrate with cloud resources, and maintain state across sessions.
This requires rethinking the entire architecture. The workspace-based mental model shifts from "work tree on my computer" to "distributed task execution in the cloud." The UI needs to show agent status and progress even when you're disconnected. You need better ways to interrupt and redirect agents mid-task. These are solvable problems, but they require intentional design.
There's also potential for multiplayer collaboration. Should multiple developers be able to conduct the same orchestra simultaneously? Should sub-agents be able to communicate with each other? The orchestral metaphor extends further—imagine a team of developers and a team of agents working in concert, with clear signals and coordination mechanisms.
Practical Lessons: What Matters When Building AI-Powered Tools
Several principles emerge from Holtz's approach:
1. Start with use cases, not technology. Conductor exists because Holtz and his team needed a better way to work with AI coding agents. The tool solves real problems they experienced daily, not hypothetical problems or technology for its own sake.
2. Maintain clear boundaries. Let AI have free rein in experimentation zones, but protect core infrastructure. This balance enables rapid iteration without destabilizing the foundation.
3. Invest in prompting infrastructure. Skill files and claude.md documents pay dividends. Spending time crafting these guides lets individual prompts be shorter and more focused. It's leverage.
4. Design for how humans actually think. Spatial interfaces, visual organization, and keyboard shortcuts aren't luxuries—they're how humans manage complexity. GUIs beat terminals not because they're prettier, but because they align with human cognition.
5. Use the product obsessively. You can't ship something you wouldn't use daily. Eating your own dog food catches problems that user feedback might miss and ensures decisions are grounded in real experience rather than assumptions.
6. Be opinionated about core decisions, flexible about customization. Conductor has a clear vision about workflow, but it enables users to extend it through prompts and customizations. This balances coherence with flexibility.
Conclusion
Charlie Holtz's AI coding setup reveals that the future of software development isn't about writing less code—it's about changing what developers do. Instead of typing, developers orchestrate. Instead of debugging alone, they collaborate with AI agents. Instead of building monolithic features, they iterate rapidly through parallel experiments.
The specific tools matter—gooseneeck microphones, keyboard shortcuts, thoughtful UI design. But the deeper insight is philosophical: humans and AI collaborate best when humans orchestrate, set boundaries, and make architectural decisions, while AI handles execution, iteration, and implementation details. This division of labor plays to each agent's strengths.
As AI models improve, this collaboration will deepen. Cloud-based agents, multiplayer workflows, and seamless integration with development infrastructure are coming. But the core principle—keeping humans in the conductor's role—will remain essential. The future belongs to developers who can think about prompts the way they used to think about code, who understand when to use Claude versus Codex, and who maintain the discipline to prevent AI from spiraling.
Start building with these principles today, and you'll be ready for tomorrow's AI-augmented development workflows.
Original source: Conductor CEO Charlie Holtz Walks Us Through His AI Coding Setup
powered by osmu.app