Tanya Cushman Reviewer
Tanya Cushman Reviewer
Hello. I was at a wedding this weekend, and it was in New York, and there were a bunch
of trendy people there. And I was talking to someone who I'd never met before, and I told
him I was prepping for this presentation. And he was like, oh, that's cool. Like, what's
the conference about? And I said it was about AI engineering. And I could just see his eyes
glaze over and he started like looking behind me to find the next person to talk to and
it's like so cool to actually be in a room full of people who actually want to hear about
this stuff. So I'm very excited to be here. I am the co-founder of Conductor. Has anyone
here used Conductor? Okay, nice, nice. Okay, cool. So for those who don't know, Conductor
is a desktop app for managing a team of coding agents all at the same time. So instead of
having a bunch of terminal windows for your cloud codes, your codexes, or your whatever
coding agent, you have one interface to manage them all. And one of the really cool things
about Building Conductor has been that I've seen a lot of the best builders up close.
I've watched their workflow, I've seen how they work, I've seen the things they do do
and the things that they avoid doing, and so I thought I would compile a bunch of the
principles that I've seen the best engineers use and give them to you all.
So here's what Conductor looks like. Can you guys see this? Okay, nice. Okay. So here's
what Conductor looks like and here are my principles for being the fastest builder in
your organization. So let's start with number one, stay near the frontier. Staying near
Near the frontier means you are always trying the latest things, basically the day they
come out. It means that when UltraCode comes out, you're trying it. It means that when
SlashGoal comes out, you're giving it a go. It's really important to stay near the frontier
for a few reasons. If you are doing your own startup, then staying near the frontier means
that you will come up with lots of new ideas for what you should actually be building.
This literally happened to us.
We were building a totally different app called Chorus,
but we started using, we were such power users of Cloud
Code back in February of last year
that we started building our whole workflow around Cloud
Code, and we started cloning our repo five times,
and then we discovered work trees, and then bit by bit,
we had built Conductor as an internal tool.
And we couldn't have figured that out
if we weren't staying near the frontier.
And if you're not doing a startup,
you should be the person at your company
who always knows what the latest workflows are.
It used to be that you could just kind of
like use your social graph and the information
that was important about the best workflows to use
would trickle down to you.
But things just like move way too fast now.
You're always gonna be three to six months behind
if you do that.
So it's very important to stay near the frontier.
And there's an important word here, near.
There is a danger if you are at the frontier.
You can do what I call midwip memeing,
where you're spending all of your time
working on your workflow and not doing actual work.
And so internally we've come up with a heuristic for this.
We call it don't beat the market.
Don't try and beat the market.
The concept here, the heuristic you should use
when you're trying to decide if you're near the frontier
or at the frontier and too deep into the latest trends
is you should ask yourself,
why isn't this workflow the default?
So for example, when route loops were becoming a big thing,
you should ask yourself, like,
should I spend a ton of time optimizing my workflow
to work with route loops?
Because if route loops work for everyone,
like if they are the default,
then you probably should just wait for Anthropic
or OpenAI or whatever, to build the workflow
into the default harness.
You can think of this as sort of like
an efficient market hypothesis,
where unless you have real alpha,
you shouldn't be optimizing your workflow too much.
And what I mean by real alpha is some kind of information
about either your users or your code base
that the models might not know about.
So an example for us is, we're a chat app,
We have to render really long chats really quickly,
and performance is important to us.
And so we need to spend a lot of time optimizing our React
optimizing our React queries to render the chats quickly.
And we're willing to make sacrifices
in other parts of our code base to make that happen.
So if you have some kind of alpha,
it's like some kind of information
about the app you're building that the models might not
know about, then you should put time into the workflow.
Otherwise, don't be the person who
has an amazing Emacs setup but doesn't actually
get stuff done.
Okay, three, create slot-free zones.
So, at Conductor, we have this term
we call a slot-free zone.
And a slot-free zone is a part of the code base
or a part of the app that requires
really strict human review.
And we're actually, I think, a little bit unusual in this way.
I think a lot of people assume that we are pure token maxers
and we are like ripping through like 30,000 line PRs,
but we're actually not.
We're actually quite careful with certain parts
of our code base and then very loose with other parts of our code base.
The reason this is important is because if you are not careful about your slot free zones,
your code base can get in a really tricky spot.
And this actually happened to us.
We've had to rewrite our whole app like a couple of times because we weren't careful
about slot free zones.
Specifically, we have a migrations file.
And in RCI, any change to the migrations file
requires a human to review it.
We also assume that anything written in Slack is slap free.
It's not written by the AI, it's written by a human.
All of our docs, our Cloud MDs, all our skills,
we put a ton of time into making them good.
And this is also something I've seen
with all the best builders up close.
They put an unusual amount of time into the Cloud MD
their skill files. And I think another way that I've thought about this is like if you
had a new intern that was joining your company and you had the opportunity to like whisper
something in their ear every time they started working, like every day, any time they sat
down you could like whisper something in their ear. You would probably put a lot of thought
into like what it is that you're whispering in their ear. And this is what the CloudMD
or AgentsMD is. It's like information that gets loaded into the agent's context every
every time they start working.
And so you probably want to put a lot of thought into those.
Okay, four, feed the beast.
At Conductor we have a internal tool we call the Conductor
Internal Agent and it is, we also, also known as the CIA.
And the CIA is basically like the centralized database of
everything that's happening in the organization.
So anytime a new Slack message gets sent, the CIA picks it up.
The CIA agent will see that a new message sent in Slack,
it will pick it up and it will save it to a Postgres table.
Anytime a user has a bug request in Discord, the same thing happens.
Anytime we have a meeting, we are recording it and it goes into the CIA.
We call this feed the beast because you want to,
for your agents to be effective in your company,
you want them to have as much information and as much context as they can have
about the way you guys specifically work.
And the best way to do that is by having a centralized place
for all the information to go.
I think this tweet sums it up pretty well.
It's really effective to just put everything in a database
and then give your agent a SQL tool
and let it handle the rest.
Okay, next is free range agents.
Give your agents a lot of space to play.
Give them a sandbox that won't get killed,
where they can explore your code base,
where they can work on really hard tasks,
where they know that they're not going to get shut down
when you close your laptop lid.
Give them opportunities to create more of themselves.
Give them ways to collaborate with other agents
and other humans.
I think what's really interesting about free range agents
and this concept and why this is important
is the models are getting better
and they are able to run for much longer
and there are going to be many more of them.
And so, if they are confined to your laptop,
then they're not gonna be nearly as effective
as if they are free roaming.
The other thing that's important here
is that once you give them a sandbox to play in
that isn't confined to your laptop,
there's a bunch of really cool stuff
that you can build on top.
And we have built some of those things into Conductor.
And I'll give you a quick glimpse into some
of those cool things.
So this is Conductor.
I'm going to make it a bit bigger.
And this is actually a new version of Conductor
that is coming out this week,
and it is centered around collaboration in the cloud.
And so the thing I said was you need a sandbox for agents to play.
You need a free-range agent.
And so you'll notice that each workspace
has a little cloud icon at the top,
and I can click it and get information
about the sandbox that the agent is running in.
And what's awesome about this is I can close my laptop
and the agents are going to keep running.
Up until basically this week,
every task in Conductor was built on a Git Work Tree,
but now they're in a cloud sandbox.
They are free range agents.
But what's also really cool that we can build
on top of cloud is collaboration.
So you'll see here, I'll make this even bigger.
That's me.
And here are a list of the things that I am working on.
And you can see that I am in the conductor org.
But if I scroll down, I can see what Caden's working on.
I can see what Lewis is working on.
I can see what Tywin is working on.
And I can see Jackson's face pop up there.
I can click in and see what he's working on in real time.
And I think collaboration is one of the most important new
concepts in these tools that no one is really
talking about right now. Collaboration is important because not only is it true that
all great things are built with teams of people, like they're not built by individuals, they're
built by teams, but also as the models get better, as we've seen this with the two days
of Fable, you can get a lot more ambitious with the kinds of things you're building.
And if you're getting more ambitious, you're going to need more people and more agents
to work on those things. So I'm going to go into a workspace that Caden is working on.
this one, and I'm gonna say,
I can review the changes that he's made.
I'll make this a little smaller.
And this looks fine, but I'm just gonna say,
can we actually use tabs, not spaces?
And Caden should be able to see that message happen in real time,
and he can actually chat in the workspace as well.
You see here that he's typing.
So I see Caden is typing.
Let's see what he says.
Seems like he's typing a lot.
Maybe he stopped typing.
I'll give him a second to take a look at it.
But the point is, we can now have collaborative workspaces
that are shared in real time with people on our team.
OK, he's typing again.
OK, come back.
The agents have escaped.
All right.
So I'm really excited about this,
and we're rolling this out to all Conductor users this week.
I think collaboration is going to be one
of the most important new interface changes this year.
The other really cool thing about Cloud
is that, and giving the agents the free range sandbox,
is that we can give the agents APIs to spawn themselves.
So I have here a, I'll bring up my open claw.
This is my open claw called Lord Crandon.
And you can see that it has, I don't
know how well you can see this text,
but it has access to a conductor API.
And so from my phone or from my Telegram
or from Slack or wherever I am, I can say,
hi, can you create a new workspace for me
that makes all the buttons blue?
And so I'll text that to Lord Crandon,
and Lord Crandon has access to the conductor API
and so can kick off work itself.
So let's see what it does here.
Okay, so just created the workspace.
The agent is on it.
And then I can go into my conductor.
I'm out and about, but it's still setting up the workspace,
and it will do work for me while I am gone.
So I'm pretty excited about all the cool things
you can build on top of free range agents.
Okay, the final principle that I want to talk about today, and the title of this talk is
Orchestras, Not Factories.
The whole talk track today is about software factories, and I honestly kind of hate the
term.
I think it's the wrong way of thinking about these new tools that are emerging.
think, like, when I think of a factory, I think of automation. And I think of, like,
there's a lot of amazing things about automation, and like, it makes our lives more efficient,
and we can, like, create more of everything. But I don't want the future to be built around
factories. I want the future to, I want to feel like a human. I want to, like, be in
the flow, I want to be in front of an orchestra, like waving my baton, and I wave it this way,
and this team of agents starts working, and then this intermingling of humans and agents
starts working as I go here. And when I want to, I can zoom in on the details, but most
of the time I can zoom out. And I don't think the future should be we are managing swarms
of agents, and we are factory line managers, pushing buttons, getting the agents to pump
out the next feature. We tried this 10 years ago with the term feature factories and it
just doesn't work. I want my software to feel human and crafted. I want to feel like a human
at the center of it all. And I think because we're all building these tools, we actually
have a responsibility to make the tools great for humans. I think it's really important
to use the words that make us feel excited and feel capable and feel like we're in the
flow and having fun. And so I don't think the future is something like this. I don't
want to be in my dark factory. I don't want to be a line manager. I want to feel like
this. I want to be in the flow. I want to be having fun. I want to be crafting things.
I want to feel like I'm Steve Jobs designing the Mac with a team of amazing humans and
AI agents all in the same place. I want to feel like I'm in an orchestra.
So here are my principles for being the best builder in your organization.
Stay near the frontier, don't try and beat the market,
create slot free zones, feed the beast, free range agents, and
think about orchestras, not factories.
Came up with this handy acronym for remembering it, stick foe.
All right, so thanks a ton for having me, I'll be around.
Feel free to ask questions and I'll see you on the internet.
Thank you.