AI agents make a manager's calendar usable as building time, so prototyping becomes part of leadership work.
2
Hands-on building is how leaders learn what changing frontier models can do and show engineers working examples instead of making claims about them.
3
An overnight agent loop can build features, improve AI prompts against small eval sets, and train models, provided the organization has trusted CI, feature flags, and careful review.
Summary
Hursh Agrawal argues that leaders should keep building even when their calendars fill with meetings. He has 15 or more recurring meetings a week, seven direct reports, and a toddler at home, yet now ships two to 10 pull requests weekly with AI agents. Building gives him direct knowledge of what new model families can do, which helps him set expectations, shape products, and demonstrate working prototypes to engineers. His method is an overnight loop: gather context with an agent connected to company knowledge, hand a detailed prompt to a coding agent at 5 p.m., then review the result in the morning. He applies this to feature work, eval-driven prompt improvement, and training small classifiers. The approach depends on trusted CI, readable pull requests, feature flags, prototype branches, and personal review. Agrawal is candid that agent-written code has caused incidents and that leaders must read it before adding other reviewers.
A manager's calendar can now contain real building time
Agrawal says he has 15 or more recurring meetings each week, seven direct reports, and a toddler at home, yet he now ships two to 10 pull requests weekly. He attributes the change to more autonomous coding agents that can handle longer tasks. Before these agents, leaders mainly influenced teams through road maps, documents, and meetings. Now, he says, the manager schedule is usable as building time. He works 40 to 50 hours a week rather than an extreme schedule, so the work has to fit into ordinary gaps in the day.
Hands-on prototypes reveal what new models are actually good for
Frontier models change every few months, and each release changes their capabilities, prompting behavior, and useful applications. Agrawal says opinions about new models are noisy, both online and inside companies. He does not think a leader can reliably judge a model without using it. Building gives him intuition about how a model might affect engineering expectations, product decisions, business strategy, and the next three to six months. A working prototype also communicates faster than telling engineers that a new model makes something possible. They can play with the result instead of debating a claim.
Leaders get unusually high value from steering agents
Agrawal says leaders hold more business and organizational context than anyone else, including strategy, trade-offs, decisions, upcoming work, and current imperatives. That context makes their steering more impactful per token when they prompt an agent. He also sees a direct transfer from management to agent work. Setting goals, giving context, checking in, and coaching an agent resemble delegation to an employee. In his experience, current models execute well but still need help with judgment. When an agent rejects an approach, a leader can suggest another path and ask it to try again.
Leaders should build internal tools, celebrations, vision prototypes, and product gardening
Agrawal describes four useful categories for leader-led building. Internal tools can improve efficiency and quality of life. Small artifacts can celebrate people on a team. Product and codebase gardening can clean up existing work. The fourth category is vision work, where leaders experiment with new model families and build products that make their possibilities concrete for the organization. He advises against taking critical-path work because meetings, recruiting, and incidents can interrupt it. The leader's projects should remain useful even when the leader is pulled elsewhere.
The daily workflow centers on a 5 p.m. overnight handoff
Agrawal describes two to three hours of coding spread across a manager's day. A morning block goes to reviewing what the agent produced overnight. Short steering blocks fit between one-on-ones, reviews, and other meetings. The most important period is the 5 p.m. block, when he sets up the next run. He gathers context, answers clarifying questions, and sends the work to a coding agent that runs for four, six, or eight hours. In the morning, he reads the report, decides what to do with the result, and ships the work that is ready.
A context-gathering agent can prepare the overnight coding prompt
For feature work, Agrawal asks a coworker agent connected to Slack, Jira, Confluence, Notion, and the repository to spend about 20 minutes researching the task. He asks it to produce a prompt containing the business context, previous attempts, trade-offs, known constraints, and what has or has not worked. He then pastes that large prompt into a coding agent before bed. His mindset is to provide the context the model needs to make decisions as he would, since he will not be available to steer it during the overnight run. The agent is asked to implement the feature and prepare the full stack for review.
Verification and pull request hygiene have to be part of the agent's task
Agrawal asks the agent to write tests first, because tests written afterward tend to be sloppier. He also asks it to test the end-to-end flow with computer use, check that the behavior matches the business context, split the work into reviewer-friendly pull requests, manage CI, and resolve bot comments and CI checks. His company uses internal AI code reviewers, and he suggests running an AI review skill in a clean subagent when needed. The agent should leave a morning report covering the work and its trade-offs. Agrawal still tests the result himself before approving it.
Small feedback dumps can become evals for overnight hill climbing
Agrawal adds a feedback button and text box to prototype AI features. During short daytime blocks, he runs the feature and records what was good, bad, or improvable. The runs become JSON files containing the system prompt, inputs, and feedback. Four, five, or ten examples can start an eval set, while feedback from coworkers can bring the set to 20 or 30 examples. At 5 p.m., he asks an agent to turn the files into an eval set, design scoring functions, build a harness, and optimize the call overnight. He acknowledges that small datasets create overfitting risk, so the agent is told to keep the result general.
Agents can train small custom models when given a safe sandbox
Agrawal describes training a BERT-based PII classifier overnight after finding that frontier-model calls had poor cost, latency, or precision and recall for the task. He gave the agent business context and training data, asked it to clean and expand the data with synthetic examples, and provided model API keys. The agent was told to compare model classes, train two candidates, provision a sandbox rather than production, choose an appropriate GPU and EC2 cluster, test against eval examples, and deprovision the resources. By morning, it returned trained models, a report, and instructions for hosting inference in the codebase.
"Don't do it. It's mostly because you're going to look like an ass because there's going to be something in that code that is going to be so obviously bad."17:10
Who should watch
You manage engineers and want a practical way to keep prototyping despite a meeting-heavy schedule.
You need direct experience with changing frontier models before setting product or engineering expectations.
You are considering overnight coding agents and need guidance on prompts, evals, CI, pull requests, and safe deployment boundaries.
