← back
Prototyping as Leadership: How a CTO Ships with AI Agents — Hursh Agrawal, The Browser Company
Takeaway
Technical leaders can use well-contextualized autonomous runs to turn strategic judgment into working prototypes despite fragmented schedules.
Summary
- Browser Company CTO Hursh Agrawal reports shipping two to ten pull requests per week by fitting autonomous coding work around a manager's schedule.
- Hands-on prototyping builds intuition about changing model capabilities and gives teams tangible demonstrations of new product possibilities.
- Leaders contribute business context and delegation skills, while focusing on prototypes, internal tools, and improvements that do not put critical-path delivery on their calendar.
- An overnight loop gathers context and starts work at day's end, lets the agent run for hours, and uses morning review to guide shipping; examples include features, evaluation optimization, and model training.
coding-agentsleadershipprototyping
Original description
Fifteen recurring meetings a week, seven direct reports, a toddler at home, and somewhere inside that Hursh Agrawal ships between two and ten pull requests. It was not possible a year ago. His argument is that the manager schedule has quietly become usable as building time, which makes building part of a leadership job rather than a hobby squeezed around the edges of one. The reasoning is less about output than calibration. Frontier models turn over every few months and nobody can reliably tell you what a new one is good for, so a leader without hands on time ends up relaying opinions from Twitter. Building also solves a communication problem, since showing engineers a working prototype beats arguing about capability every quarter. He thinks leaders are unusually well suited to it as well, because they hold the most business context and their steering is therefore worth more per token than an engineer's. The mechanics come down to a single overnight loop. A coworker agent wired into Slack and the issue tracker spends twenty minutes assembling context into a prompt, that gets handed to a coding agent at five in the evening, and the morning block goes on reviewing whatever came back. He runs it to build features, to hill climb prompts against eval sets assembled from a handful of feedback dumps, and to train small classifiers end to end. The caveats are real. It only works on top of trustworthy CI, feature flags, and a prototype branch, and he is candid that his own code has caused incidents. Speaker info: / hursh / hurshagrawal https://www.hurshagrawal.com Timestamps: 0:00 - A manager's calendar, and why building became the job 2:44 - Judging a new model, and showing rather than arguing 4:25 - Execution is solved, judgment is not 5:16 - Four things leaders should build, and one to avoid 6:05 - The daily shape, and why 5pm matters most 6:56 - Building a feature overnight, and assembling the prompt 9:28 - Verification, PR hygiene, and the morning report 11:16 - Hill climbing a feature from a few feedback dumps 13:47 - Training a classifier overnight 15:27 - Pushing task scope, and the scaffolding it needs 17:06 - Never add reviewers to code you have not read