Mitchell Hashimoto’s new way of writing code

Summary of Mitchell Hashimoto’s new way of writing code

by Gergely Orosz

1h 57m•February 25, 2026
Listen to Episode

Overview of Mitchell Hashimoto’s new way of writing code

This episode (hosted by Gergely Orosz) is a long-form conversation with Mitchell (Mitchell) Hashimoto — co‑founder of HashiCorp and creator of Vagrant, Packer, Consul, Terraform, Vault, Nomad and more — about his origin story, building HashiCorp, product and business lessons, his new terminal project Ghosty, and how agentic AI is changing both developer workflows and open source. The conversation mixes history, technical detail (terminals and renderers), product/business pivots (open‑core, Vault enterprise), practical AI usage habits, and recommended changes to how teams and open source projects handle AI-generated contributions.

Episode highlights

  • Early background: self‑taught teen, learned via online code, built PHP sites and forums; University of Washington → consultancy → infrastructure.
  • Paths to HashiCorp: Vagrant (reproducible dev VMs), a failed university scheduler project (inspired reusable ideas), and early cloud (AWS) context led to tools for multi‑cloud infrastructure.
  • HashiCorp product timeline: Vagrant (pre‑company), Packer (image builder), Consul (service discovery), Terraform (infrastructure as code), Vault (secrets management), Nomad (scheduler).
  • Business pivot: early “Atlas” commercial effort failed; pivoted to per‑product enterprise, open‑core (Vault enterprise first) and found clearer buyers, budgets and traction.
  • Cloud provider relationships: candid take — AWS seen as arrogant / slow to collaborate; Microsoft pragmatic and cooperative; Google superb technically but less business‑oriented.
  • IPO & M&A: HashiCorp prep and secrecy for IPO; a near‑sale to VMware early on (decision against selling shaped future outcome).
  • Ghosty: Mitchell’s opinionated modern terminal built with Zig and GPU rendering; focus on performance, correct terminal state, and libghosty (reusable embedding library).
  • AI and agents: Mitchell runs an agent almost constantly. He explains how agents changed his work, the benefits (research, idea prototyping, repetitive tasks), and the pitfalls (noise, low‑quality AI PRs).
  • Open source & AI: rising problem — high volume of plausible‑looking but low‑quality AI contributions. Ghosty adopted stricter policies (no unsanctioned AI PRs; moving to vouching system modeled on Lobsters/Pi).
  • Larger engineering implications: Git/monorepo stresses, merge queue pressure, increased sandbox/compute demand, and the need for new tooling (harness engineering, observability, CI/CD and test strategy changes).

Key takeaways and practical advice

  • Always have an agent doing something useful while you’re working (research, tests, slow tasks) — but do not let it interrupt you. Mitchell disables agent desktop notifications and interrupts the agent on his schedule.
  • Use AI to reclaim your time: delegate boilerplate or exploratory work so you can focus on higher‑value thinking. Start small — reproduce research tasks with an agent before handing over coding.
  • Open source must change policies and guardrails. Mitchell’s approach for Ghosty:
    • Close unsolicited AI PRs that have no linked feature/issue.
    • Move to an explicit vouching system: contributors must be vouched for by existing community members; vouching ties reputational risk to the inviter.
  • Maintain high standards for security: Vault was built with early audits and security pros added later; developer UX matters in security products as much as the underlying crypto.
  • Founders: startups typically take longer than expected — imagine a 10‑year horizon. Be deliberate about what you build, pick the right constraints, and be prepared to pivot.
  • Hiring: some of the strongest engineers are low‑visibility — minimal social media/GitHub presence, highly focused during work hours. Look for depth, not just public footprint.
  • Productization: when selling open‑source tools, identify clear buyers, budgets, and features that solve enterprise scale problems (e.g., replication, compliance, SLAs).

Notable quotes / insights

  • “If the company fails, it doesn't matter. If they're good ideas, the open source community will just continue.” — illustrates Mitchell’s product-first credo early on.
  • “AI makes it trivial to create plausible‑looking but incorrect and low‑quality contributions.” — concise diagnosis of the AI‑open‑source friction.
  • “I always endeavor to have an agent doing something at all times.” — Mitchell’s personal productivity rule.

Technical notes (Ghosty & terminals)

  • Terminals are like a text‑oriented application platform (simpler than a browser but with similar classes of problems): rendering, input, cursor, ANSI escape sequences, scrollback/history, progress bars, images and mouse events.
  • Ghosty architecture (overview):
    • UI thread (windowing and UI).
    • IO thread (pty / shell bytes processing).
    • Renderer thread (GPU accelerated rendering at vsync rates; font subsystem).
  • Renderer challenges: mapping terminal state (grid of monospace cells + styles) to glyphs and GPU draws; optimizing to microseconds per frame; maintaining large scrollback efficiently.
  • Libghosty: a minimal, MIT‑licensed library to embed a correct terminal surface (to reduce broken terminal UIs across apps).

AI, open source and platform changes to expect

  • Immediate effects:
    • Increased volume of PRs (many low quality) and an influx of agent‑opened PRs (fast, often anomalous patterns).
    • Need for disclosure and community vouching mechanisms.
  • Systemic needs:
    • Better version‑control workflows and tooling for high‑churn, agent‑driven code generation (merge queues, partial clones, branch archival, richer metadata).
    • New testing and harness strategies so agents can validate their outputs programmatically (more exhaustive, goal‑oriented tests).
    • CI/CD, observability and sandbox orchestration to cope with orders‑of‑magnitude increases in short‑lived compute units and agent sandboxes.
  • Potential long run: forks and alternative governance models may increase; default‑deny contribution models and reputation trees will become common.

Actionable recommendations (for maintainers, engineers, founders)

  • Maintainers:
    • Require feature‑request association for external PRs and consider a vouching system for contributors.
    • Rate‑limit, detect and auto‑close obvious agent PR patterns (empty draft PRs, instant bodies, rapid resubmits).
    • Invest in CI/observability and automated checks for security/quality before human review.
  • Engineers:
    • Start by delegating research or slow tasks to an agent; keep an agent running but disable intrusive notifications.
    • Create agent playbooks (agents.md) with edge cases, tests and harnesses so agents learn from repeated mistakes.
    • Use AI for fast prototyping, but always review production code, especially for security‑sensitive systems.
  • Founders / infra leads:
    • Plan for 10‑year horizons; choose bets deliberately (what not to build matters).
    • Prepare infra for agent‑scale churn (sandbox orchestration, merge queues, fast CI).
    • Reassess hiring criteria: depth and focus often trump public visibility.

Sponsors & projects mentioned

  • Statsig — feature flags, experimentation, analytics (sponsor pitch in episode).
  • WorkOS — enterprise identity/auth building blocks for SaaS.
  • Sonar (SonarSource) — code quality/security and the Sonar Summit (approach “vibe, then verify” for agent velocity with automated guardrails).
  • Projects/Products discussed: Vagrant, Packer, Consul, Terraform, Vault, Nomad, Ghosty, libghosty, Claude, Codex, AMP/Auto‑agent tools.

Final summary

This episode blends entrepreneurial history with concrete, tactical thinking about how AI is reshaping software development and open source. Mitchell Hashimoto: (1) recounts how HashiCorp’s products, business model pivot and vendor relationships developed; (2) explains why a performant, modern terminal mattered to him and how Ghosty is structured; and (3) gives a practical, nuanced view of how to use agents (always-on but non‑interrupting), how open source projects must evolve (vouching and stricter policies), and how engineering practices, hiring and infrastructure should change to survive and thrive in an agentic future.