1 From Self-Taught to HashiCorp
The 12-Year-Old Coder
Mitchell Hashimoto taught himself to code at the age of 12, originally motivated by video games. He quickly gravitated toward web programming, picking up PHP and Perl as his first languages. With parents who wouldn't buy programming books, he turned to the only free resource available: open-source code. He printed out the entire PHP manual and literally walked to school reading it page by page.
Headhunted at 18
Mitchell's open-source contributions were visible enough that he got headhunted at just 18 years old by a Ruby on Rails consultancy. There he met his future boss — someone who ran Linux exclusively and didn't use a mouse. That exposure pulled Mitchell from web development deep into infrastructure and systems, setting the trajectory for everything that followed.
The 2010s Startup Scene in San Francisco
18:22 Mitchell paints a vivid picture of San Francisco's startup scene in the early 2010s — a period of intense energy where cloud computing was just becoming mainstream. AWS was still relatively new, and the idea that you'd provision servers through an API felt revolutionary. This was the fertile ground from which HashiCorp would grow.
Meeting Armon & The Birth of HashiCorp
Co-founder Armon Dadgar emailed Mitchell while both were at university. Mitchell responded in two minutes. HashiCorp was born from a failed research project and a notebook full of unsolved problems in infrastructure automation. Rather than chase a single idea, they catalogued gaps in the ecosystem and systematically attacked them one by one.
2 Building HashiCorp: From Open Source to IPO
Funding & The Mayfield Connection
HashiCorp secured early funding from Mayfield, with a key connection through Chuck Robbins. The funding allowed them to go all-in on building open-source tools, but monetization remained an open question. The initial strategy was to build strong community adoption first and figure out revenue later — a bet that would take years to pay off.
An Early Failure: The Atlas SaaS Model
35:28 HashiCorp's first attempt at commercialization was Atlas, a SaaS platform that tried to bundle their tools into a hosted offering. It failed. The market wasn't ready for it, the product-market fit wasn't there, and the team learned a painful lesson about the difference between building great open-source tools and building a viable commercial product.
The Open-Core Pivot
38:28 The pivot to open-core with Terraform Enterprise changed everything. The model was simple: the core tool (Terraform) stays open source and free; the enterprise version adds governance, collaboration, and compliance features that large organizations need. This became the blueprint for HashiCorp's entire product line.
The Product Portfolio
- Vagrant — the first product, local development environments
- Terraform — infrastructure as code, the breakout hit
- Vault — secrets management and encryption
- Consul — service discovery and mesh networking
Each addressed a specific problem from the notebook. Revenue grew from early millions to significant scale as enterprise adoption accelerated.
Taking HashiCorp Public
48:08 The IPO represented the culmination of years of patient open-source-first strategy. Mitchell reflects on the journey from two university students with a notebook to a publicly traded company — a process that took far longer than either of them originally imagined.
3 The Almost-VMware Acquisition
VMware Comes Knocking
Before the IPO, VMware approached HashiCorp with an acquisition offer. This was a pivotal moment. Mitchell and Armon had to seriously consider whether to sell the company they'd spent years building.
The Regret Minimization Framework
To make the decision, they used what they called the "regret minimization framework" — asking themselves which choice they'd regret least in 10 or 20 years. They arrived at a minimum number: $100 million. This was the floor below which walking away from their life's work simply wasn't worth it.
Personal vs. Passion
Mitchell discusses the tension between the personal financial security an acquisition would have provided versus the passion of continuing to build. For founders, this is one of the hardest decisions: a guaranteed life-changing outcome versus the uncertain but potentially much larger upside of independence. The VMware vote failing turned out to be one of the best things that ever happened to HashiCorp.
4 Honest Take on AWS, GCP & Azure
Mitchell provides a remarkably candid assessment of working with the three major cloud providers, drawing on years of direct partnership experience at HashiCorp.
AWS: Arrogant but Dominant
- "Really arrogant. Felt like they were doing us a favor."
- Subtle undertone of "we'll spin up a competing product and kill your company" in every interaction
- HashiCorp maintained 5 full-time engineers dedicated solely to the AWS Terraform provider — roughly $1M/year in cost
- AWS provided zero help or support for the provider
- The breakthrough came only when HashiCorp threatened to deprecate the AWS provider entirely — that's when AWS finally began contributing
Microsoft / Azure: Business-Savvy Partners
- Mitchell's most positive view of any cloud provider
- Technically, Azure was described as a "hairy" product — complex and sometimes messy under the hood
- But the business side was exceptionally competent
- First question in every meeting: "How do we both win?"
- First cloud provider to officially support Terraform
- The partnership mentality made them the easiest to work with by far
Google Cloud: Best Tech, Worst Business
- Best technology and most incredible architecture of all three
- But nobody cared about business outcomes
- Meetings would devolve into hours-long discussions about edge cases and technical minutiae
- When it came to co-selling, partnerships, and go-to-market — complete silence
- The engineering-first culture meant commercial partnerships felt like an afterthought
5 AI's Impact on Open Source
Mitchell raises an alarm about the state of open-source contributions in the AI era. The signal-to-noise ratio has become incredibly low. AI has made it trivial to generate plausible-looking but subtly incorrect code contributions.
Before vs. After AI
- Before: Bad contributions came from people who were genuinely trying to help. Even if the code was wrong, the intent was clear and the effort was real.
- After: Low-effort AI-generated PRs flood projects. The code looks superficially correct but often misses context, introduces subtle bugs, or solves problems that don't exist.
6 Ghostty: Building a Modern Terminal
Why a Terminal?
After leaving HashiCorp, Mitchell wanted to rebuild his atrophied systems programming skills. After 15 years of infrastructure-level work, he craved low-level, close-to-the-metal programming. He chose his technologies first — Zig and GPUs — then found the project. A terminal emulator was the perfect intersection.
The Surprising Architecture
The biggest revelation: a terminal is actually 30% terminal and 70% font renderer. The majority of the engineering challenge is getting text to render correctly and quickly on screen.
- UI thread — handles user input and window management
- IO thread — manages the shell process and data flow
- Renderer thread — GPU-accelerated rendering synced to VSYNC at 30/60/120 fps
Performance Obsession
Mitchell optimized frame rendering from 800 microseconds down to 9 microseconds — nearly a 100× improvement. This level of performance caught the attention of Salvatore Sanfilippo (creator of Redis), who praised Ghostty for being fast enough to tail production logs without the terminal becoming the bottleneck.
libghostty: Terminal as a Library
One of Ghostty's most forward-thinking decisions: libghostty, an extracted library (MIT-licensed) that lets any application embed a terminal. This means terminal functionality can be integrated into IDEs, dashboards, or any tool that needs to run shell commands — without reinventing terminal emulation from scratch.
AI's Unexpected Boost to Terminals
Counter-intuitively, terminal usage has gone UP since 2023, not down. The rise of CLI-based AI tools like Claude Code means developers are spending more time in terminals than ever. Even desktop applications that appear graphical often execute commands in pseudo-terminals under the hood. AI has made the terminal more relevant, not less.
7 How Mitchell Uses AI
The Daily Toolkit
Mitchell uses AI tools every single day: Claude Code, AMP, Codex, and various chat interfaces. He doesn't commit to a single tool — he uses whatever is best for the task at hand and sometimes runs multiple in competition.
The Core Principle
The Always-Running Agent Workflow
Mitchell's standard workflow is built around one rule: always have an agent running. The pattern:
- If Mitchell is coding → an agent is planning the next task
- If agents are coding → Mitchell is reviewing their output
- He runs no more than 2 agents simultaneously — more than that and context-switching erodes the quality advantage
- Sometimes he runs Claude Code vs. Codex in direct competition on the same task and picks the better result
- He especially loves agents for research tasks — exploring APIs, reading documentation, summarizing options
Context-Dependent Code Review
Mitchell's approach to reviewing AI-generated code varies dramatically based on context:
- Ghostty code: Reviews everything meticulously. This is a performance-critical systems project where subtle bugs can have real consequences.
- Personal wedding website: Doesn't care about reviewing. Just ship it. The stakes don't justify the effort.
This pragmatic distinction — knowing when to be rigorous and when to accept "good enough" — is central to getting real value from AI tools.
8 Open Source + AI: The Trust Crisis
Ghostty's Evolving AI Policy
Ghostty's stance on AI-generated contributions has shifted significantly over time. It started with a simple disclosure requirement — just tell us if AI was used. But the situation escalated rapidly:
- Phase 1: Disclosure — just be honest about AI usage
- Phase 2: More restrictive — AI-generated PRs held to higher scrutiny
- Phase 3: Agents started opening PRs directly, bypassing human involvement entirely
"Effort for Effort"
The Dead Giveaway
Mitchell can spot agent-generated PRs instantly: Claude opens a draft PR with no body, then edits it moments later to fill in the description. This pattern is unmistakable and has become the signature of low-quality automated contributions.
The quantity of low-quality AI PRs reached unsustainable levels, forcing the project to adopt increasingly strict policies. The step change wasn't just more AI-assisted contributions — it was fully autonomous agents submitting code with no human in the loop.
9 Git Is Breaking Under Agents
A Question Nobody Used to Ask
For the first time in 12–15 years, Mitchell is hearing the question "Will Git still be around?" and people aren't laughing when they ask it. That's a remarkable shift for a tool that has been utterly dominant in version control.
Why Git & GitHub Are Failing
Git and GitHub's forge model doesn't work with agentic infrastructure today. The core problems:
- Massive churn: Agents create branches, commits, and PRs at a rate that overwhelms traditional workflows
- Lost context: The prompt history that produced AI-generated code is often more valuable than the diff itself, but Git doesn't capture it
- CI/CD overload: Continuous integration systems aren't resourced for the volume of automated contributions agents generate
Harness Engineering
Mitchell introduces the concept of "harness engineering": when an AI agent does something bad, don't just fix it — build tooling the agent can call to prevent or correct that behavior in the future. This creates a flywheel where every mistake makes the system more robust.
Testing Must Expand Dramatically
With agents writing code, testing must become far more expansive. The traditional testing pyramid isn't sufficient when code is generated at scale by non-human contributors. More tests, more edge cases, more integration scenarios — testing is the primary quality gate in an agentic world.
10 Hiring in the AI Era
The Best Engineers Have "Boring" Backgrounds
Mitchell drops a counterintuitive observation: his best engineers consistently had what most people would consider "boring" backgrounds:
- No social media presence
- No public GitHub profile
- 9-to-5 work schedule — they don't code at night
- But during work hours: completely locked in and exceptionally skilled
Thinking Without a Screen
Mitchell himself spends significant time lying awake at night thinking through code, mentally running CLI commands, tracing execution paths, and working through architectural decisions. By the time he sits down at the keyboard, much of the hard thinking is already done.
AI Competency as a Hiring Requirement
Going forward, Mitchell would require AI competency in hiring. Not for every task — but candidates must demonstrate understanding of when AI tools are useful, how to prompt effectively, and how to evaluate AI-generated output. The goal: everyone on the team should have an agent running at all times.
11 Mitchell's AI Adoption Journey
Initial Skepticism
Mitchell tried Claude Code at its launch in May 2025 and was not impressed. His first experience didn't match the hype. But as he continued seeing positive remarks from people he respected, a different feeling emerged: fear of falling behind.
Forcing the Adoption
Rather than dismiss AI tools, Mitchell forced himself to reproduce his normal work using agents. The early days were painful — he was essentially doubling his work, doing everything his normal way and then again with AI assistance. It was slower, not faster.
The Breakthroughs
Persistence paid off. Mitchell discovered several key techniques that dramatically improved results:
- Separate planning step: Having the agent plan before coding makes output significantly better
- Better test harness: More comprehensive tests = better agent results, because the agent can verify its own work
- AGENTS.md file: Documenting common mistakes in a file the agent reads prevents it from repeating the same errors
12 Advice for Founders & What's Changing
For Founders
- Startups are much longer than you think — imagine committing for 10 years, because that's closer to reality
- You need a certain hubris — a genuine belief that you'll do it better than anyone else
- AI startups face unique pressure: the expectation to move faster than ever because the tools theoretically enable it
For Software Engineers
- The expectation is shifting: engineers are expected to do far more independently — full demos, designs, research, prototypes
- The capacity to experiment is dramatically higher. What used to take a week to prototype can now take hours.
- But productionizing still feels similar — taking something from prototype to production-ready hasn't gotten proportionally easier
The Pre-Seed Shift
The Closing Rule
Mitchell leaves the audience with one powerful habit:
★ Key Takeaways
12 Things to Remember
- Start with problems, not products — Mitchell and Armon's notebook of unsolved infrastructure problems became HashiCorp's entire roadmap.
- Being first doesn't matter — Terraform was the 7th infrastructure-as-code tool. Approach and execution beat timing.
- Open-core > SaaS for dev tools — HashiCorp's failed Atlas SaaS pivot vs. the successful Terraform Enterprise open-core model.
- Cloud providers are not your friends — AWS spent nothing on a provider they depended on; Azure asked "How do we both win?" Know who you're partnering with.
- AI is breaking open-source trust — "Default deny, you must earn trust" is the new reality for maintainers drowning in low-quality AI PRs.
- Terminals are more relevant than ever — CLI-based AI tools have actually increased terminal usage since 2023.
- Always have an agent running — Mitchell's core workflow: if you're coding, the agent plans; if the agent's coding, you're reviewing.
- Context determines rigor — review AI code carefully for critical systems, ship without review for throwaway projects.
- Git needs a "Gmail moment" — version control must evolve to handle agentic infrastructure, prompt history, and massive churn.
- Harness engineering — when AI makes a mistake, build tooling it can use to prevent that mistake in the future.
- AI adoption is like learning Git — initial awkwardness doesn't mean the tool is bad. Invest time building the right mental model.
- Before closing your laptop — ask what slow task an agent could be doing while you're away.
☍ Resources & Links
- mitchellh.com — Mitchell Hashimoto's personal site and blog
- ghostty.org — Ghostty terminal emulator
- Ghostty on GitHub — Source code and documentation
- Mitchell's AI Adoption Blog Post — Detailed write-up of his AI workflow evolution
- Full Video on YouTube — The Pragmatic Engineer interview