Prototyping as Leadership: How a CTO Ships with AI Agents — Hursh Agrawal, The Browser Company

0:13 Hi everyone, thanks for coming. Uh, I'm Hersh Agarwal. I'm the CTO and co-founder of the browser company, makers of the Arc and Dia browsers. Uh, and I'm going to

0:22 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 kind familiar to some of you in

0:34 leadership. Um that was my actual week. I uh have a whole org that reports up into me. So I have 15 plus recurring meetings a week uh standups, reviews, recruiting meetings, etc. Uh and seven

0:47 direct reports. And I've noticed something over the last several months, which is I've started to consistently ship, you know, two to 10 PRs a week. Uh and this is new. This was not possible

0:57 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 996. You know, I'm working 40 50 hours a week. So, I really have to

1:07 fit all this in into a regular week. And pre-I agents, uh, as you grew as a leader, you had more of the org reporting to you. Uh, you would sort of the way you would influence the org was

1:21 through communicating to people. Uh so you'd uh write road maps, docs, meetings, and you'd sort of incept uh your context and what you wanted to build with your employees uh and your

1:32 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

1:43 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

1:56 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

2:06 models that change every 3 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

2:18 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

2:29 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

2:40 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

2:51 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 going to change because of this? What's

2:59 going to 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

3:09 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 going to be amazing." And

3:18 your engineers are like, "Okay, yeah, sure." Um, so it's really helpful to have some time to actually build stuff so you can show them, you know, you can be like, "Hey, I built this prototype

3:27 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 3 months

3:36 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

3:47 business, the strategy, the trade-offs, 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

3:57 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.

4:10 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

4:18 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

4:28 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

4:37 you have 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

4:44 these models if you have time slotted out for building. uh that really leverages all the context you have. So the great Julie Zo had a great tweet about this uh a month ago. She pulled

4:56 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. So internal efficiency

5:06 uh quality of life improvements just like gardening around the codebase and the product. This is really helpful. Um I really like this. I learned from this the celebration story. You can build

5:15 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

5:24 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

5:35 product and business. I she's right. I would not take any critical path work. the last thing you want to do is to have that dependent on you, especially you're going to be dragged into fires and

5:43 recruiting calls and meetings, etc. Uh so really trying to do 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

5:55 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

6:06 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

6:16 important block is that 5:00 p.m. 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

6:24 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 found work for me is this one overnight loop. uh you first in that 5pm block

6:37 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

6:47 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

6:56 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

7:05 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

7:17 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

7:28 individual task 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 because if it's

7:39 working for 6 hours, 8 hours overnight, you're not going to be there to steer it. And so you want it to have as much context as you do about the business goals of whatever you're trying to get

7:46 it to do. So, uh, a little tip I found that has worked well for me, um, if you have a co-work agent, whatever your, uh, cloud co-work or codeex or I recommend DIA, I feel like that's the best one.

7:57 Not biased at all. Um, whatever it is that's connected to your Slack and your Jira, Confluence, notion, the repo, etc. Uh, just I before a meeting or something, I'll be like at like 3:00 4

8:08 p.m. I'll be like, "Hey, I really want to build this. go and do like 20 minutes of research and go dig through all of Slack and Notion and everything else and come up with a cloud code prompt that I

8:19 can post paste into a cloud code and just give me as much context as possible the trade-offs what we tried before what works what doesn't why are we're doing it what is like the business context of

8:28 this feature I want to build or this model I want to train and that takes like 30 seconds to whisper flow into DIA or whatever your co-work agent is and the nice thing is this comes back with a

8:38 giant prompt that then you can paste into cloud code or cursor or codeex or whatever your coding agent is. So this is an example of a 5mm prompt I'll have that I give it before I go to bed. I'll

8:49 say implement this whole feature and then just paste all of that context I got from my co-work agent. Uh and then it's important to think about verification. So as this uh agent is

8:58 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 tests first so they capture what you do. This is really

9:07 helpful because I I found of decoding agents if you if they write tests afterwards, they're a little sloppish. Um, and then I'll tell it to test the endto-end flow with computer use. You

9:16 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

9:25 actually solve the problem I was trying to solve? And then uh I usually prompted to do as much work as possible so that when I wake up in the morning, the stack is

9:34 ready. So split this into reviewer friendly PRs with clear descriptions, 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

9:46 passable. AI code review is really important. We have a bunch of internal AI code reviewers uh you know pre the previous talk was talking about codto and other AI code reviewer. If you don't

9:56 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.

10:05 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

10:15 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 going to be great. Um, I don't know if that helps or not, but it's it's

10:23 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

10:31 did. Uh, and it does great. Uh, it actually modern models, new Opus 4.8 or the new GBT. They can handle what used to be, you know, weeks of work uh, in one overnight run and you come back in

10:41 the morning with this uh, beautiful package ready for you. It actually makes the mornings kind of nice because you have this little present ready for you. Another example is optimizing AI

10:51 features. So, first you're at the AI engineering conference. 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,

11:02 you need to optimize it hill climb on some eval 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

11:11 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

11:21 feedback button and a little text box. And then in one of my 1 hour slots or 30-minut slots throughout the day, I'll just take the time to uh collect a bunch of feedback." So I'll uh you know, run

11:32 it a few times, collect a bit of feedback, be like, "Hey, this was bad or this was good or this could have been better." And then just have it save JSON dumps on my downloads folder. So it'll

11:41 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, 10 are fine. If you can get some other

11:52 uh co-workers to run it, that would be great. Collect like 20 or 30. And then similarly, uh at 5:00 p.m. when you're setting up an overnight run, uh just say, "Hey, like here are, you know,

12:03 10 20 30 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

12:13 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

12:23 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,

12:31 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 to just say don't overfitit, just keep

12:39 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

12:50 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

13:00 something hill climbed. Uh and actually when using that feature when we we ship these features to employees to to further dog fooding to production it actually does improve the quality. You

13:09 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 add that hill

13:19 climb to pretty good quality just 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

13:29 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

13:40 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

13:51 a bunch of training data we collected. uh a clean up the training data cloud just bolster it with synthetic data whatever you need to here's a bunch of open AI and enthropic keys uh use an

14:00 ensemble of frontier models to push the quality I don't know anything about what ML model will be good here so like you decide you know just give me the best

14:09 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

14:18 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

14:27 train models. Uh, and then give me a report in the morning. And in fact, even put in how I would host this with my codebase on inference once this model is ready. And again, ask me any clarifying

14:38 questions. You can do it. I believe in you. You're going to 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

14:46 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

14:57 main takeaway for me in doing these is really to push on task scope. So this was a tweet by Simon Lass, one of the notion founders. Uh and he he called out these modern models are just capable of

15:08 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 because it affects both how we lead and how we influence

15:17 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

15:27 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

15:37 because of existing organizational scaffolding. So you'll have to build this up in your organization. You know, AI code reviewers, this really helps. You have an internal one we trained, but

15:45 also just external ones, whatever you need. Um, agents.md hygiene, you know, cloud.md, agents.mmd, proper CI that you can trust. And then we have a bunch of other things like uh really

15:57 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

16:07 as you're prototyping and showing these things off. Not amazing for the CTO to take prod down. I will say again code hygiene really matter really matters. I've been humbled

16:17 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

16:27 it uh because 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

16:38 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, etc., it's really important you test it yourself. Um small

16:48 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 going to

16:58 start doing that, and that's not amazing. So, uh, it's really important. Your hygiene is really good because it's modeling for the rest of the team what good looks like. Um, and then, ooh, this

17:06 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 because you're going to look like an ass because there's going to be something in

17:15 that code that is going to be so obviously bad and then some senior engineer is going to call you and be like, "Yo, why didn't you read this?" So uh I speak from experience. Read the

17:24 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

17:35 hours a day and you should uh you'll start to feel the models every 3 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.

17:45 And you'll be able to show the the the team and the org what's possible as well. you know, just because you as you have this capability, you'll automatically think of ideas on what to

17:53 slot in for these overnight runs and then you can model for the team. Hey, this is what the future looks like. Thank you.