Mitchell Hashimoto sat down with Gergely Orosz on The Pragmatic Engineer podcast this week. The HashiCorp co-founder and Ghostty creator covered a lot of ground: the origin story, cloud provider politics, open source under siege. But two things stuck with me that I haven’t seen anyone else talking about.
The Background Process
Mitchell has one rule for his AI workflow: always have an agent doing something.
— Mitchell HashimotoWhile I’m working, I basically say I want an agent - if I’m coding, I want an agent planning. If they’re coding, I want to be reviewing. There should always be an agent doing something.
Not always coding. Sometimes research. Sometimes edge case analysis. Sometimes just “think deeply about what I might be missing.” The point is that dead time for the human becomes productive time for the machine. This is the Ralph Wiggum pattern taken to its logical conclusion: the agent doesn’t need you watching it.
His process before leaving his desk: “What slow task could my agent do while I’m gone?” Before driving to the podcast recording, he kicked off deep research on library options. Before bed, he had an agent exploring edge cases in his vouching system design. Every context switch becomes a delegation opportunity.
The critical detail: he turns off all desktop notifications. The agent doesn’t get to interrupt him. He interrupts the agent when he’s ready. This flips how most people use AI tools. Most treat agents as pair programmers demanding attention. Mitchell treats them as background processes he checks on his own schedule.
Before you close your laptop or leave your desk, spend 30 seconds asking: what’s a slow task my agent could work on while I’m gone? Research, edge case analysis, library comparisons, documentation review. Anything that takes the machine 20 minutes but would cost you an hour of context-building.
Competition Mode
On hard tasks, Mitchell runs two agents against each other. Claude vs Codex, same problem, pick the better output. Not because one model is always better. Because on problems where he has low confidence in any single output, seeing two independent approaches reveals things a single run never would. I wrote about this exact pattern in When Claude Needs a Second Opinion: different models have different blind spots. Running them in parallel isn’t redundancy. It’s coverage.
He caps it at two. More than that and the cleanup becomes the bottleneck. He described himself as the mayor of a small town, not the operator of a factory floor. Steve Yegge’s GasTown runs 20-30 instances. Mitchell runs two and curates. Both work. The right number depends on how much cleanup you’re willing to do.
The Adoption Curve Nobody Talks About
Mitchell’s path to this workflow wasn’t instant conviction. He tried Claude Code at launch, wasn’t impressed, and walked away. What brought him back wasn’t a breakthrough. It was fear.
— Mitchell HashimotoI saw so many positive remarks about it that I started to get scared that I would be behind on how to use a tool. So I actually started forcing myself. I still didn’t believe in it.
He doubled his work deliberately. Every task, he’d do it manually and figure out how to prompt the agent to produce the same result. Slower for months. But he found the same inflections everyone finds: planning steps improve output, test harnesses improve output, CLAUDE.md prevents repeat mistakes. He discovered these independently because the patterns are real, not because someone told him.
This matches what I’ve seen. Steve Yegge and Kim call it the Swiss watchmaker problem: senior engineers who refuse to adopt AI tools because they’re already fast. Mitchell’s path was different. He wasn’t refusing. He was stress-testing. The people who get the most from AI tools aren’t the ones who believed immediately. They’re the ones who were skeptical enough to push back, but honest enough to admit when it worked.
Git Might Not Survive This
Midway through the conversation, Mitchell dropped something I haven’t heard anyone else frame this clearly: git, in its current form, may not survive the agentic era.
The problems compound:
- Merge queues can’t keep up. Human churn was manageable. 10-100x agent churn means every push triggers a rebase, every rebase conflicts with another agent’s push. The queue depth becomes untenable.
- Branches only capture the positive. When an agent experiments with an approach, finds it doesn’t work, and abandons the branch, that negative signal disappears. Mitchell argues this information is “relatively important” and we’re throwing it away.
- Monorepos are already breaking. Mitchell advises a stealth company in this space. The companies going hardest on agents are hitting real performance and workflow problems with git at scale. Not theoretical. Happening now.
— Mitchell HashimotoThis is the first time in like 12 to 15 years that anyone is even asking that question without laughing.
His framing: version control needs its Gmail moment. Email used to require careful curation and deletion. Gmail gave everyone a gig and said “never delete, just search.” Git still operates in the curation model. Save the positive, discard the negative, prune your branches. In an agentic world, you want to save everything and build better tools to find what’s relevant.
The problem isn’t just performance. GitHub’s forge model - branches, PRs, merge queues - was designed for human cadence. Agent cadence is a different regime entirely. The workflow assumptions break before the performance limits hit.
What’s Actually Changing
Mitchell frames the current moment as the first time in his 20-year career where “so much is on the table for change at one time.” Editors, forges, CI/CD, testing, version control, observability. Everything built for human-speed development is being stress-tested by machine-speed development.
His specific bets on what changes:
- Testing becomes “harness engineering.” Every time an agent breaks something, build tooling that would have caught it. Move from testing the product to testing the development process.
- Sandbox compute explodes. Containers already changed the density of compute units. Agents need isolated environments at a scale Kubernetes wasn’t designed for.
- Editors have unprecedented mobility. People who never switched editors are switching constantly now. Cursor hit a valuation no pre-AI editor company could have touched. Meanwhile, the terminal is having a renaissance nobody predicted.
The thread connecting all of it: infrastructure built for human pace is being asked to handle machine pace. Some of it will scale. Some of it won’t. Git is the most interesting question mark because it’s the one piece of infrastructure that literally everyone depends on and nobody has seriously questioned in over a decade.
The Lesson
Mitchell’s workflow isn’t about being more productive. It’s about being more deliberate about what he thinks about. The agent handles the tasks that don’t require judgment. He reserves his attention for the tasks that do.
The always-running agent isn’t a productivity hack. It’s a delegation discipline. The question isn’t “how do I use AI more?” It’s “what am I currently spending time on that doesn’t require my brain?”
That question doesn’t require better tools. Just honesty about where your time actually goes.
Related Posts
