YC Root AccessThe Tool the Best Engineers Are Using Right Now
CHAPTERS
- 0:05 – 0:45
Conductor explained: a Mac app to run multiple coding agents in parallel
Aaron opens by introducing Conductor and its founders, Charlie and Jackson, fresh off a $22M Series A. Charlie explains Conductor’s core workflow: spin up isolated copies of a repo, assign agents (Claude/Codex) tasks, then review and merge their output.
- •Conductor consolidates multiple coding agents into one interface
- •One-click isolated codebase copies (worktree-style workflow)
- •Agents work in parallel while the human reviews/merges changes
- •Positioning: beyond running agents inside IDE/terminal
- 0:45 – 1:50
Business traction and the new launch: Conductor Cloud
The team shares rapid growth and the breadth of users—from indie hackers to engineers at large public companies. They announce Conductor Cloud, enabling agents to keep running even when your laptop is closed.
- •~10x growth since January with a small team
- •Adoption across individual and enterprise engineers
- •Conductor Cloud introduces cloud-backed workspaces
- •Cloud removes the ‘close laptop = stop agents’ limitation
- 1:50 – 2:37
The scaling problem: managing more than 3–5 agents is an interface challenge
Charlie describes a cognitive bottleneck: humans can only effectively juggle a few agents at once. They see the next breakthrough as an interface/abstraction leap rather than just more compute or more agents.
- •Typical human working-memory limit: ~3–5 concurrent agents
- •Productivity proven for multi-agent workflows, but UI must evolve
- •Need higher-level abstraction to orchestrate many agents
- •Motivation: users already pushing instance/worktree limits
- 2:37 – 3:45
Early experimentation: from manual repo clones to worktrees to Conductor primitives
Jackson and Charlie recount trying to run multiple agents manually and hitting friction. Their workflow evolved from multiple repo clones to using worktrees, gradually shaping the core primitives that became Conductor.
- •Manual multi-agent setups were painful beyond 1–2 agents
- •Started with multiple repo clones and one agent per clone
- •Discovered git worktrees and built around them
- •Conductor began as internal tooling to remove orchestration friction
- 3:45 – 6:59
Founders’ origin story: meeting in college and deciding to build together
They share how they met in college, bonded through sports and projects, then reconnected professionally. Their desire to replicate an “elite team” feeling became part of the company’s ethos.
- •Met in college (freshman vs fifth-year age gap)
- •Collaborated closely (lifting coach, ultimate Frisbee)
- •Reconnected while working (Netflix + Replicate)
- •Motivation: work intensely as a high-performing team
- 6:59 – 8:40
First startup idea: an AI agent that books reservations (and why it didn’t last)
Their YC application centered on an AI that could make reservations (e.g., tennis courts) by controlling a browser. In retrospect, it was a “solution in search of a problem,” and conviction was limited.
- •Initial concept: AI that navigates the browser to book reservations
- •Explored early model capabilities (e.g., Sonnet 3.5 browser control)
- •Struggled to identify a compelling, urgent user problem
- •Learning: thinking through ideas isn’t as valuable as trying them
- 8:40 – 11:30
YC batch reality: rapid prototyping, constant pivots, and speed as a superpower
They describe the YC experience as a whirlwind of prototyping and user conversations where most ideas failed quickly. Aaron highlights their unusual ability to ship new MVPs every few days.
- •First ~1–1.5 months: broad exploration and rejected prototypes
- •Frequent office hours with new directions every few days
- •Core strength: extremely fast building and iteration cycles
- •Team dynamic emerges: hacker (speed) + gardener (robustness)
- 11:30 – 14:22
Key turning point: ‘Build a dev tool you want’ and the path through Chorus
Charlie recounts pivotal advice from Aaron: focus on dev tools and “make something these guys want.” They first shipped Chorus (multi-model chat) to force real-world testing, then discovered Conductor while building internal tooling.
- •Advice: dev tools fit + build for yourselves (poster mantra)
- •Belief that AI coding tools weren’t going far enough yet
- •Early attempt at ‘post-IDE’ UI was premature (models/tool calling not ready)
- •Shipped Chorus to get real users, then Conductor emerged from internal needs
- 14:22 – 15:24
From first line of code to users: Conductor’s prototype-to-launch sprint
They explain how quickly Conductor came together: Charlie’s solo prototype worked unexpectedly well, then both founders polished it into something shippable. Early external feedback started within a few weeks.
- •~2–3 weeks from first code to release
- •Prototype week: Charlie built an MVP that worked surprisingly well
- •Polish phase took longer than expected to make it usable
- •Motivation: fear someone else would build the tool they needed
- 15:24 – 17:21
The ‘magic moment’: parallel agents, unread dots, and building Conductor with Conductor
The founders describe the first compelling proof that the product “stuck”: assigning multiple tasks, switching between agents, and seeing completed work. They also found it exhilarating to use Conductor to build Conductor itself.
- •First delight: quickly task a second agent while the first finishes
- •UI signal (unread dot) reinforced asynchronous progress
- •Validation test: Jackson found it genuinely useful (rare bar)
- •Momentum from ripping through many independent tasks in parallel
- 17:21 – 20:21
Going viral: authentic demos, reps, and learning what you’d click on
Charlie shares how he learned to create attention-getting demos, including a viral GPT-4 Vision experiment narrated by a David Attenborough voice clone. He attributes success to authenticity, directness, and repeated practice observing what resonates.
- •Viral demo story: Attenborough-style narration of webcam feed
- •Replicate growth work trained him to ship compelling demo content
- •Principles: authenticity, minimal polish, straightforward language
- •Technique: study what you personally like/click and replicate the feeling
- 20:21 – 23:00
What top engineers do with AI tools: skills files, simple setups, and ‘slop-free zones’
Based on user visits and watching elite engineers work, Charlie notes patterns in how the best teams use AI. They invest in reusable “skills” documentation, keep tooling surprisingly simple, and intentionally separate areas where AI can move fast vs. areas requiring human architecture.
- •Best engineers curate ‘skills files’ (markdown best practices + codebase rules)
- •Agents repeatedly reference skills files for consistency
- •Most top setups are simpler and more vanilla than expected
- •‘Slop-free zones’: boundaries where humans architect and AI is constrained
- 23:00 – 25:20
The future of engineering: from agent orchestration to ‘AI CEO’ interfaces
They predict models will become dramatically more capable, running longer with less intervention and feeling more like coworkers. This will require new interfaces that let builders operate at a high level—like managing an organization—while still drilling into details when needed.
- •Expectation: models get 10–100x smarter and run longer unattended
- •Agents will feel like coworkers but with ‘alien’ reasoning traits
- •Need interfaces for managing many agents like an org chart/megacorp
- •Best AI builders proactively set constraints and anticipate design decisions
- 25:20 – 27:25
What’s next for Conductor: ubiquitous access, higher abstractions, and better reviews
They outline Conductor’s direction: run anywhere (laptop/phone/cloud) and manage organizational AI workflows, not just local sessions. Charlie highlights upcoming leaps in abstraction and rethinking code review beyond the 2010-era PR model.
- •Vision: Conductor as an org-wide AI manager accessible anywhere
- •Move to ‘next level of abstraction’ beyond today’s July-2025 workflow
- •Remove bottlenecks: human working memory and review throughput
- •Reimagine PR review workflows for AI-generated changes
- 27:25 – 29:22
Hiring and culture: scrappy builders who make tools for themselves (and top engineers)
They close by describing who they want to hire: fast-moving, frontier-oriented builders who love making tools they personally use. The conversation ends with appreciation for the product’s impact and the team’s enthusiasm.
- •Hiring for scrappiness and comfort with startup pace
- •Motivation: build tools for themselves and for the best engineers
- •Meta-loop: use Conductor to build Conductor and improve process
- •Closing reflections on fun, teamwork, and momentum
