Prototyping as Leadership: How a CTO Ships with AI Agents

[on-hold music] Hi, everyone. Thanks for coming.

Uh, I'm Hursh Agrawal. I'm the CTO and co-founder of The Browser Company, makers of the Arc and Dia browsers. Uh, and I'm gonna talk about prototyping as leadership, as you get to a manager schedule, how you can keep building.

So this is my actual calendar from last week. Uh, I imagine this is ki- familiar to some of you in leadership. Um, that was my actual week. I, uh, have a whole org that reports up into me, so I have fifteen plus recurring meetings a week, uh, stand-ups, reviews, recruiting meetings, et cetera, uh, and seven direct reports.

And I've noticed something over the last several months, which is I've started to consistently ship, you know, two to ten PRs a week, uh, and this is new. This was not possible several months ago.

It's really because of these new AI agents. Uh, and notably, I also have a toddler at home, so I, like, cannot work nine, nine-six. You know, I'm working forty, fifty hours a week, so I really like to fit all this in into a regular week.

And pre-AI agents, uh, as you grew as a leader, you had more of the org reporting to you, uh, you'd sort of-- the way you would influence the org was through communicating to people.

Uh, so you'd, uh, write roadmaps, docs, meetings, and you'd sort of incept, uh, your context and what you wanted to build with your employees, uh, and your engineers. And now, interestingly, in the last few months, as coding agents have become more autonomous and able to handle longer tasks, the manager schedule, as Paul Graham put it, is suddenly

usable as building time. You can actually ship stuff.

And so I think building is part of the job now. You can do it, first of all, as a leader, but it's-- I think it's also becoming necessary as part of the job for two reasons.

First, uh, the technology world is changing, where suddenly the core technology that's part of our products are these frontier models that change every three months, which is a new dynamic that's come out.

And as each new frontier model comes out, its capabilities change, the contours of what it's useful for change. It's, you know, how it actually reacts to prompting changes. And there's so much noise on Twitter, even internally for us, and so many opinions with each new model release on what's good and what's bad.

And I found it is impossible to tell what a new model is good for unless you have your hands in it and you're using it all day long. And so having an ability to slot in building time into your schedule means you can figure out the contours of what is this new model family capable of, and both

how do I direct my engineers in terms of, uh, setting expectations on how they should be building. But also getting a sense of how does this fit into our product, how does this fit into our business, you know, how is this-- how is our strategy gonna change because of this?

What's gonna happen in three to six months when the open source models catch up? All of that intuition comes from actually using the models and building.

I've also found even if you've built the intuition, it's actually tough to communicate that to other people who haven't played with the models. Uh, and so you're like, "Oh, this new thing is possible.

It's gonna be amazing." And your engineer's like, "Okay. Yeah, sure." Um, so it's really helpful to have some s- time to actually build stuff so you can show them.

You know, you can be like, "Hey, I built this prototype with this new model family. It works in the product. Here's an actual prototype you can play with." And this is just so much faster and more efficient than trying to convince people every three months when a new model family comes out.

I also think leaders are really well suited for it. You know, you all have, uh, context, more context than anybody else, uh, in the organization about the business, the strategy, the trade-off, the decisions to be made, what needs to be done, what's, uh, what's coming up, what are imperatives.

And so the steering of a leader, uh, as you are prompting these models is to- per token, uh, more impactful than an IC's. And so you can really fit this into a little bit of time.

The delegation skill also transfers. Like, you delegate to people. That's sort of one of the core skills of being a leader, and that transfers to agents pretty well. You know, it's setting goals, giving context, checking in, even coaching the agent.

You know, "What if you tried this?" Um, and then I've also found, I, I think this is maybe specific to now, uh, maybe this will change in several months as these models get better, but the models are really good at execution, but still not unbelievable at judgment.

You know, often the model will come back and be like, "Hey, that algorithm idea is not possible," or like, "I can't do this." And so you have a, uh, as a leader, have to be like, "Oh, have you tried this thing?"

And the model's like, "Oh, okay. Cool, cool, cool. I'll try that." And so it's a really nice dynamic you can have with these models if you have time slotted out for building, uh, that really leverages all the context you have.

So the great Julie Zhuo had a great tweet about this, uh, a month ago. She polled some Bay Area technical leaders on what can you actually build, what should you be building in this new world.

And four categories emerged. Uh, you could build internal tools or internal efficiency, uh, quality-of-life improvements, just like gardening around the code base and the product. This is really helpful.

Um, I really like this. I learned from this, the celebration story. You can build artifacts to celebrate people on your team. And then arguably, I think the most important is the vision piece, is really playing with the new model families, understanding what's possible viscerally yourself, and then trying to fit that into the business and building products that

can show that off to your engineers so you can really push, uh, the boundaries of what's possible with the product and business.

I-- She's right, I would not take any critical path work. The last thing you wanna do is to have that dependent on you, especially you're gonna be dragged into fires and recruiting calls and meetings, et cetera.

Uh, so really trying to do s- one of these four categories is, is optimal.

So this is, this is my how I work, uh, and what two to three hours a day of coding can actually look like. Uh, so I usually have a morning coding block about an hour, and this is when I look over last night's code, what the, uh, agent did last night, review it.

I'll talk a little bit more about this. Uh, and then a few maybe steering blocks throughout the day interspersed between one-on-ones and reviews and meetings and everything else you need to do.

And then the most important block is that 5:00 PM block at the end of the day where you really set up whatever overnight run it is you want to run, and I'll talk about that, whether that's coding or training models or whatever you want the agent to do.

I'll go over sort of three examples of tasks you can do, but really what I've found work for me is this one overnight loop. Uh, you first at-- in that 5:00 PM block gather context.

I'll talk about that. Uh, you set up the run. You know, you get-- ask-- answer any clarifying questions. Uh, and then Claude Code or whatever your coding agent is overnight does the thing, you know, does the work for four, six, eight hours.

And in the morning, you get this beautiful report, uh, and you figure out what to do with it, and then you ship whatever it is. So I'll talk about building features, which is sort of the most obvious one.

Uh, I found this worked really well with evals and hill climbing, so optimizing AI features. Uh, and then a new thing actually in the maybe more recent, uh, generations of models is you can have these models train other ML models overnight too, and this works really, really well.

So building features. Um, the big mindset shift for me that really helped was starting to think about building features not in terms of how do I build this feature and break it up and then give it prompting on how to do the individual tasks, but rather what is all the context this frontier model needs to be able

to make decisions like I would make. So trying to give it as much context as possible 'cause if it's working for six hours, eight hours overnight, you're not gonna be there to steer it.

And so you want it to have as much context as you do about the business goals or whatever you're trying to get it to do. So, uh, a little tip I found that has worked well for me, um, if you have a cowork agent, whatever your, uh, Claude Cowork or Codex or I recommend Dia, I feel like

that's the best one, uh, not biased at all. Um, whatever it is that's connected to your Slack and your Jira, Confluence, Notion, the repo, et cetera, uh, just I-- before a meeting or something, I'll be like at like three, four PM, uh, be like, "Hey, I really wanna build this."

Go and do like twenty minutes of research, and go dig through all of, uh, Slack and Notion and everything else, and come up with a Claude Code prompt that I can post-- paste into Claude Code.

And just give me as much context as possible, the trade-offs, what we tried before, what works, what doesn't, why we're doing it, what is like the business context of this feature I wanna build or this model I wanna train.

And that takes like thirty seconds to whisper flow into Dia or whatever your cowork agent is. And the nice thing is this comes back with a giant prompt that then you can paste into Claude Code or Cursor or Codex or whatever your coding agent is.

So this is an example of a, a 5:00 PM prompt I'll have that I give it before I go to bed. I'll say, "Implement this whole feature," and then just paste all of that context I got from my cowork agent.

Uh, and then it's important to think about verification. So as this, uh, agent is running overnight, you want it to verify how it's doing as it's building and testing the feature.

So first I'll be like, "Hey, write the test first so they capture what you do." This is really helpful 'cause I've, I found with the coding agents, if you-- if they write tests afterwards, they're a little sloppish.

Um, and then I'll t-tell it to test the end-to-end flow with computer use. You know, go around, click around, just make sure the flow works and matches the business context I gave you.

And so the modern models are really good at reasoning about, okay, does this flow actually solve the problem I was trying to solve?

And then, uh, I usually prompt it to do as much work as possible so that when I wake up in the morning, the stack is ready. So split this into reviewer-friendly PRs with clear descriptions, m-manage CI and get CI green, and just make sure you're, you're monitoring, uh, just to make sure the, the whole stack is passable.

AI code review is really important. We have a bunch of internal AI code reviewers. Uh, you know, previ-- the previous talk was talking about Codo, another AI code reviewer.

If you don't have any, I would look on Twitter for a bunch of AI code review skills, and then just prompt it, "Hey, once you're done, run this AI code review skill in a clean sub-agent and then fix those things."

And then watch the PRs. Fix every bot comment, every, you know, CI check that shows up, any sort of, uh, anything you need to do, resolve the threads, run this autonomously.

Uh, don't ask me questions. And then I'll like throw in a little encouraging something, you know, be like, "You'll do great. I believe in you. It's gonna be great."

Um, I don't know if that helps or not, but I, it's, it's a-- I tend to do that. Uh, and then I tell them I'm going to bed. Just leave me a report in the morning on what you do.

I need the full stack ready and a report on what trade-offs you made, how you did. Uh, and it does great. Uh, it actually-- modern models, the new Opus 4.8 or the new GPT, they can handle what used to be, you know, weeks of work, uh, in one overnight run, and you come back in the morning with

this, uh, beautiful package ready for you. It actually makes the mornings kinda nice 'cause you have this little present ready for you. Another example is optimizing AI features. So first, you're at the AI engineering conference.

Uh, I assume you all are familiar with this. When you first build an LLM call or agent into a, into a feature, it's not optimized. You know, you need to optimize it, hill climb on some evals to get the quality, the latency, the cost to where you want it to be.

This is also all doable overnight, um, especially with the modern coding agents. So, uh, usually if I'm prototyping a feature, I will, uh, put a little feedback button on it.

So after the LLM call or the agent runs, I'll be like, "Hey, uh, just add a feedback button and a little text box." And then in one of my one-hour slots or thirty-minute slots throughout the day, I'll just take the time to, uh, collect a bunch of feedback.

So I'll, uh, you know, run it a few times, collect a bit of feedback, be like, "Hey, this was bad," or, "This was good," or, "This could've been better."

And then just have it save JSON dumps on my downloads folder. So it'll save a dump of each of the runs with the system prompt and the inputs and my feedback.

Uh, and you just collect a handful, you know. Like even four, five, ten are fine. If you can get some other, uh, coworkers to run it, that would be great.

You could collect like twenty or thirty. And then similarly, uh, at 5:00 PM when you're setting up an overnight run, uh, just say, "Hey, like here are, you know, ten, twenty, thirty feedback JSONs.

This is all the information they have in them. Turn this into an eval set. Like just do it locally with SQLite or Markdown or whatever you want. And then over the next few minutes, talk me through how would you design evals or scoring functions to optimize for this, and let's do it interactively."

And then I want you to, A, build a harness that runs this call against the evals and hill climbs until the score goes up. Like, just do whatever you need to do to get these scores to go up.

And obviously, with this kind of thing, if you have such little data, overfitting is a problem. But even that I found, these modern models, you can just tell it to not overfit, and it actually does a pretty good job.

Uh, and so just say, "Don't overfit," just keep it general, uh, "Run overnight autonomously until we align on a scoring rubric, and then give me a full report, uh, in the morning."

And then a little tip, it's also nice to just say, "Hey, save this flow as a generic skill so I can reuse it." Uh, and that allows you to improve this flow over time and improve that skill, and this works.

Actually, in the morning, you wake up to ideally something hill climbed. Uh, and actually, when using that feature, when we, we shipped these features to employees to, to further dogfooding to production, it actually does improve the quality.

You know, these are not overfit. Um, and we, we use this flow quite a bit internally. Uh, we have an internal code reviewer similar to, uh, some of the external ones, and same thing there.

We had that hill climb to pretty good quality just o- with these overnight runs.

And then the last example, uh, and this is again pretty new and really interesting, uh, you can train custom models with this mechanism overnight, you know, in one night.

So, uh, this is an example of a modern BERT PII classifier we trained. We were trying Opus and Haiku for it, and it was expensive and latency was not great, and we just couldn't get the precision recall to be amazing.

And so, uh, we collected a bunch of training data, and then overnight one night I was like, "Here is a bunch of business context and a bunch of training data we collected.

Uh, A, clean up the training data, Claude. Just bolster it with synthetic data, whatever you need to. Here's a bunch of OpenAI and Anthropic keys. Uh, use an ensemble of frontier models to push the quality.

I don't know anything about what ML model would be good here, so, like, you decide. You know? Just give me the best model class. Give me a few options, and in fact, train two.

Like, don't even train one. Train two separate ones." Uh, and then I gave it AWS access. I was like, "Give me a provision sandbox. Do not give it prod."

That's not a good idea. That's how you take prod down. Um, pick the right GPU and EC2 cluster, like, train it, test against eval examples, deprovision it, whatever you need to do, just give me back the trained models, uh, and then give me a report in the morning.

And in fact, even put in how I would host this with my code base on inference once this model's ready. And again, ask me any clarifying questions. You can do it.

I believe in you. You're gonna do great. Uh, and in the morning, just have this ready." And of course, it works beautifully. In the morning you have, uh, two ML models trained, a full report, great results, uh, and we've, uh, pushed a bunch of these to production.

So those are three examples. Um, I would try, try your own. Uh, but I think the main takeaway for me in doing these is really to push on task scope.

So this was a, a tweet by Simon Lass, one of the Notion founders, uh, and he, he called out these modern models are just capable of so much more than we think.

Uh, and I think it's our jobs as leaders to really understand the contours of how much we can push these models, 'cause it affects both how we lead and how we influence our teams, but also how they fit into our products and what these, our new products are capable of in terms of utility.

So I'd really push you overnight, try to think of how do I give it more and more, uh, scope so that we can do, you know, weeks of work, months of work overnight, and see what these models are really capable of.

I will say a caveat, a lot of this works because of existing organizational scaffolding, so you'll have to build this up in your organization. You know, AI code reviewers, this really helps.

We have an internal one we trained, but also just external ones, whatever you need. Um, agents.md hygiene, you know, claude.md, agents.md, proper CI that you can trust. And then we have a bunch of other things like, uh, really sophisticated feature flags.

Uh, we have a prototype branch that you can push to that goes to employees but it doesn't go to production. Just layers like that so you're not taking prod down, basically, as you're prototyping and showing these things off.

Not amazing for the CTO to take prod down.

I will say again, code hygienes really matter, really matters. I've been humbled a lot. You know, my code has annoyed engineers. It's caused SEVs. Uh, coding agents are not perfect yet, so just, uh, your mileage may vary.

You will get humbled, but I, I still think it's worth it, uh, 'cause you learn so much and you can model what taking on more and more scope, even with a busy calendar, looks like.

Some tactical tips on hygiene. Uh, I would test everything before the PR goes up. That morning slot, that's a lot of what I'm doing is just testing what the overnight run did.

Uh, even though there's computer use, et cetera, it's really important you test it yourself. Um, small, readable PRs are really helpful. I think they, you're modeling to the rest of the team what good looks like.

So if you're putting up three 5,000-line PRs, uh, other engineers on the team are gonna start doing that, and that's not amazing. So, uh, it's really important your hygiene is really good, 'cause it's modeling for the rest of the team what good looks like.

Um, and then, ooh, this is so tempting. It's so tempting to put other reviewers on code you haven't read yet. Don't do it. It's, uh, mostly 'cause you're gonna look like an ass, 'cause there's gonna be something in that code that is gonna be so obviously bad, and then some senior engineer is gonna call you and be

like, "Yo, why didn't you read this?" So, uh, I speak from experience. Read the code, review it properly before you add anybody else to it.

So hopefully this convinces you building is part of the job now. Uh, you can do it, uh, even with just one or two hours a day, and you should.

Uh, you'll start to feel the models every three months as the new model families come out, and you'll learn the skill on how to push scope as you are, uh, instructing them.

And you'll be able to show the, the, the team and the org what's possible as well. You know, just because you h- as you have this capability, you'll automatically think of ideas on what to slot in for these overnight runs, and then you can model for the team, "Hey, this is what the future looks like."

Thank you. [audience applauding] [upbeat music]