This video features an interview with Mitchell Hashimoto, co-founder of HashiCorp and creator of Ghostty. He talks about how he got into software engineering, the founding history of HashiCorp, and the challenges of turning widely used open-source tools into a successful business. He also shares candid experiences working with cloud providers like AWS, Azure, and GCP as a startup, and explains in detail how AI tools — especially AI agents — have revolutionized his daily workflow. He offers deep insights into what changes are coming for software engineers and founders in the AI era.

1. Getting into Software Engineering and First Encounters with Open Source

Mitchell Hashimoto started teaching himself to code around age 12 or 13, driven by a passion for video games. He quickly discovered that web programming interested him more than game programming. The web was new territory, and he built websites using PHP and Perl. Too young to afford technical books, he learned from publicly available code online — which became his introduction to open source.

"I was self-taught at 12, 13 — young teens — motivated by video games, like a lot of people. But I realized pretty quickly that I really love the web. This was before Google."

He printed out the first two chapters of the PHP manual — about 30 to 40 pages — and read them every day while walking to school. He recalls that at first it all seemed impenetrable, but the moment he realized the dollar sign meant variables, his understanding of coding exploded. He enjoyed building gaming websites, forum software, and even cloned PayPal just to understand how online money transfers worked. He went on to major in computer science in college. In high school he hid his programming from friends, but at college he was finally able to be open about his passion.

2. The Origins of HashiCorp: A Failed Research Project and Unsolved Problems

During college, Mitchell developed an interest in infrastructure while working at a Ruby on Rails consulting firm. His boss there used Linux exclusively and never touched a mouse — Mitchell was fascinated and learned infrastructure skills from him.

"He pulled out my mouse. And he said, 'You're never going to work with a mouse again. Figure it out. I'm not going to tell you how.' "

He later joined a research project at the University of Washington called the Seattle Project. The goal was to build a distributed computing environment using various machines — personal PCs, server racks, and more — so that academic institutions could run workloads on them. Mitchell was responsible for deploying nodes, but the project ultimately failed.

That failure, however, proved inspiring. He analyzed what went wrong and carefully recorded in a notebook which technical components had been missing. That notebook contained entries like "there's no way to manage resources declaratively" and "there's no way to connect via a private network" — notes that would later become the foundation of HashiCorp's core product suite, the Hashi stack.

During this same period, Mitchell built Vagrant, an open-source tool designed to solve the problem of reproducible development environments, drawing on his consulting experience. Vagrant made it easy to create and manage virtual machines so developers could set up fast, consistent development environments.

"My metaphor was always: I didn't use Windows, but how do I open a development environment with a double-click?"

He witnessed firsthand the dawn of cloud computing — especially AWS — and became convinced that the cloud was the better way forward.

3. HashiCorp's Early Challenges: The Multi-Cloud Vision and Raising Investment

Mitchell co-founded HashiCorp with Armon Dadgar, who had been his boss in college. Both founders held a strong conviction about multicloud. In 2011–2012, AWS dominated the market while Azure and Google Cloud barely existed, so the idea of building cloud-agnostic tools was met with skepticism. But they were convinced that if something was economically large enough, others would want a slice of the pie — and multicloud would inevitably arrive.

HashiCorp's first six months were funded by Mitchell's personal savings of $20,000, and he took no salary. When Armon joined, the two decided to pursue venture capital investment. They concluded that bootstrapping would take far too long, and that competing in the fast-growing cloud market required moving quickly — which meant outside funding.

"If we bootstrap this, even if it works, it'll take ten years to build the software. That's too slow. And the problem with slow is the world has windows, and cloud was growing so fast."

HashiCorp grew by focusing on product development at the Seed stage, showing hints of product-market fit at Series A, and building repeatable revenue from Series B onward. Their open-source products racked up millions of downloads and GitHub stars — strong proof of product-market fit — but for the first four years there was almost no actual revenue.

4. Building the Hashi Stack — and Failing to Monetize It

The first product HashiCorp launched independently was Packer — a VM image build tool that helped create images for AWS, VMware, and others, enabling fast autoscaling in cloud environments.

Next came Consul, which solved the problem of service discovery. Old-school infrastructure relied on servers with fixed IPs, but in the cloud servers are constantly being created and destroyed, making fast and reliable service discovery essential. Consul addressed this with functionality similar to Kubernetes health checks.

Then in 2014 came Terraform, which would become HashiCorp's signature product. Terraform introduced Infrastructure as Code — users define their infrastructure in text files, and Terraform automatically provisions or destroys thousands of cloud resources in environments like AWS.

"The idea was to take an empty AWS account, or any cloud account, and take this text and say, 'Make this text real.' "

Next came Vault, a secrets management solution. Beyond passwords, Vault securely stores and manages sensitive data including personally identifiable information (PII), credit card numbers, and more. Mitchell admits that when building Vault, the team had little security experience and had to spend heavily on external security audits.

"We hid the fact that nobody on the team had more than one semester of undergraduate security experience."

After that came Nomad, a tool that solved the distributed computing scheduling problem Mitchell had failed to crack during his undergraduate research project.

HashiCorp spent its first four years focused on realizing this vision, but struggled to build a business model around it. Their first attempt at commercialization — a bundled product called Atlas — was a major failure. It required customers to adopt all of HashiCorp's products at once, and its complexity in spanning multiple departmental budgets caused customers to walk away.

"It was a problem of multiple buying organizations fighting each other within a company. Even companies that had adopted all the tools ran into 'Who's supposed to pay for this?' "

5. Pivoting to Open-Core and Going Public

After the Atlas failure, Mitchell and Armon faced criticism from the board and spent an entire weekend rethinking the company's direction. They asked themselves, "If we were starting over, what would we do differently?" The answer was to adopt a per-product enterprise model and an open-core business model — building on open-source foundations while offering additional features for enterprise customers as closed-source products.

When they announced this radical shift at the company-wide Monday meeting, Mitchell and Armon expected a wave of resignations. Instead, nobody left — and the team's morale improved dramatically. Employees were relieved to have a clear direction after so much uncertainty.

"Everyone was excited that we had a clear direction and conviction."

They launched Vault Enterprise first and saw signs of success within months. There was a clear buyer — the security department — with a defined budget, and core enterprise features like Secrets Replication hit exactly what customers needed. Enterprise clients cared less about whether something was open source and more about commercial contracts, support, and proof-of-concept engagements.

Terraform and Consul followed with their own enterprise releases, and HashiCorp grew rapidly. Terraform in particular became enormously popular across the industry.

"I remember Terraform became so, so popular across the industry."

During this period Mitchell traveled relentlessly — speaking at conferences and meeting people. For nine years before the COVID lockdowns began in 2020, he never stayed in one place for more than eight days. Even while traveling he found ways to code, breaking GitHub issues into 10–15 minute tasks he could work on offline and push all at once after landing.

In 2021, HashiCorp successfully went public (IPO). Mitchell explains that the preparation took over a year, and the company had to operate as a public company before it technically was one. Prior to the IPO, strict regulatory compliance meant extremely limited public statements.

6. Candid Views on AWS, Azure, and Google Cloud

After leaving HashiCorp, Mitchell shared frank perspectives on working with the big cloud providers.

• AWS: Mitchell describes AWS as "arrogant and obnoxious." Every partnership discussion or meeting felt like AWS was doing HashiCorp a favor. He also sensed a subtle undercurrent of threat — that AWS could build their own version of any product and kill a startup at any time. AWS did in fact generate controversy by building services on top of open-source projects like Elasticsearch. HashiCorp was even forced to publicly threaten to stop maintaining the Terraform AWS Provider just to get AWS's attention and support.

"AWS was really arrogant. Like annoyingly arrogant. They treated us like they were doing us a favor." "There was always this subtle undertone of 'We could just build your product and kill your company.' "

• Microsoft Azure: Mitchell has the most positive view of Microsoft. While the technology was complex, Azure was a capable and collaborative business partner. In every meeting their first question was "How do we both win here?" Azure was also the most proactive of the three in supporting Terraform.

"I have the most positive view of Microsoft. They had some really difficult technical products." "In every meeting we had with them, the first question was always, 'How do we both win here?' "

• Google Cloud (GCP): Google had the best technical chops and architectural thinking, but gave the impression they didn't care at all about the business side. Technical discussions were lively, but conversations about co-selling, quota allocation for sales engineers, and business collaboration rarely went anywhere. Google built a Terraform provider in an impressive automated way — but having a conversation about how to sell it was difficult.

"Google Cloud always had the best technology, the most amazing technical and architectural thinking." "None of them seemed to care about or think about business at all."

7. Building Ghostty and Open Source in the AI Era

After leaving HashiCorp, Mitchell threw himself into Ghostty, a project he had been prototyping for three years. Ghostty is a terminal emulator with the goal of going beyond the limitations of existing terminals to deliver modern features. After fifteen years of focusing on infrastructure and cloud services, Mitchell felt his desktop software skills had atrophied — so he started Ghostty to sharpen them again. He chose the Zig programming language and dug into GPU and desktop software techniques to build a terminal from scratch.

"I spent over a decade — twelve years at HashiCorp, three years before that — thinking only about infrastructure and cloud services. Fifteen years total." "I chose Zig because it just looked cool. I wanted to try it."

A terminal is like a browser for text content — it has to render text, colors, images, widgets, mouse events, and much more, making it a surprisingly complex system. Ghostty uses a multi-threaded architecture with three threads: UI, IO, and renderer. Mitchell jokes that Ghostty is "30% terminal, 70% font renderer," underscoring the complexity of font rendering. Ghostty places particular emphasis on performance, excelling at rapidly dumping large files.

"The joke I make about Ghostty's complexity is that it's 30% terminal, 70% font renderer."

AI brought an unexpected side effect: more terminal usage. With the proliferation of AI-powered CLI tools and code generation apps, the amount of time developers spend in a terminal has grown substantially since 2023. As a result, Mitchell extracted Ghostty's core functionality into a zero-dependency library called libghosty, making it easy for anyone to embed terminal functionality into their own applications.

8. Transforming How He Works with AI Agents

Mitchell is a huge fan of AI tools and says he uses tools like Claude Code, AMP, and Codex daily alongside chat tools. AI has given him the ability to "choose what to think about." In the past he spent a lot of time on tedious, repetitive boilerplate work; now he delegates that to AI and focuses his time on what matters more.

"The most important thing for me is that it lets me choose what to think about."

His standard workflow is to always have an AI agent doing something. While coding, he might have an agent draw up a plan while he reviews code the agent already wrote. Sometimes he runs two agents simultaneously, competing on a hard problem, or has one doing coding while the other does research. He is especially impressed by AI agents' efficiency on research tasks.

Mitchell takes different approaches to AI-generated code depending on the stakes. For low-importance projects like a personal website, he doesn't scrutinize the code at all — if it renders correctly in three browsers and on his phone, he ships it. But for a core project like Ghostty, he reviews every line.

9. Open Source in the AI Era: Rethinking Trust Systems

The Ghostty project has been struggling with low-quality AI-generated contributions. Mitchell explains that AI "trivializes making plausible-looking but inaccurate, low-quality contributions." In the past, even low-quality code showed genuine effort from the contributor, which warranted an educational response — but AI-generated code is produced with minimal effort, so that approach is no longer warranted.

Because of this, Ghostty changed its policy on AI-written pull requests. Initially the project required disclosure of AI usage, but as the volume of low-quality AI PRs became unmanageable, the policy tightened further. Now, AI-generated PRs that aren't tied to an approved feature request are not accepted — they're closed immediately without review.

"AI trivializes making plausible-looking but inaccurate, low-quality contributions."

Going further, Ghostty is preparing to transition to a vouching system where no one can open a PR without being vouched for by an existing community member. Users who earn trust through vouching can submit PRs — but if they misbehave, both the person who vouched for them and every user that person has vouched for are permanently banned from the repository. The system was inspired by the social network Lobsters and the AI toolkit project PI.

Mitchell believes that AI will force most open-source projects to change. In the past, the effort required to submit a PR served as a natural barrier to entry — AI has removed that barrier, and trust systems need to be rebuilt as a result. Where the default was once "trust," the new direction will be "deny by default" with trust that must be earned.

Mitchell also emphasizes the growing importance of forks. Forks used to require significant effort, but in the AI era more active forking should be encouraged. This matters because it means maintainers don't have to accommodate every contributor's request — contributors have the right and ability to maintain their own version of the code.

10. The Future of Git, Monorepos, and Software Engineering

As the volume of AI-generated code explodes, the limitations of Git and monorepos are becoming apparent. Git is relatively ill-suited to very large repositories, and the need to clone an entire repo is one such pain point. As AI agents generate enormous quantities of code and merge queues grow deeper, keeping the main branch coherent will become extraordinarily difficult.

Mitchell points out many problems with Git, and is particularly troubled by the loss of information when failed experiments or unadopted code changes are discarded. He compares this to how Gmail eliminated email storage limits and created a culture of "archive, don't delete" — code, he argues, should move in the same direction of preserving all information rather than throwing it away.

"What's interesting is that for the first time in twelve to fifteen years, someone is asking that question and nobody is laughing."

Five years ago, no one would seriously ask whether Git had a future — now people are genuinely raising the question of whether Git will still exist in five years. He argues that agent infrastructure in the AI era is fundamentally incompatible with current Git and GitHub systems, and that radical change is needed.

Mitchell expects CI/CD, testing, and code review — traditional engineering practices — to all evolve in the AI era. Testing in particular needs to expand dramatically so AI agents can verify their own work. He calls this "harness engineering" — the work of building tools that catch or correct what an AI agent does wrong — and says it deserves far more focus.

"Everything is changing. And in my short but relatively short twenty-year professional career compared to others, this is the first time this many things are simultaneously up for change."

He also predicts that the sandbox environments AI agents require will cause minimal compute units to proliferate explosively, placing heavy strain on existing infrastructure systems like Docker and Kubernetes.

11. Hiring and Advice for Future Founders

Mitchell says the best engineers he hired at HashiCorp often had surprisingly "boring backgrounds." They valued privacy, worked 9-to-5, and frequently didn't write code after hours. But during work hours they showed extraordinary focus and ability. He learned to look for engineers who had built deep, specialized expertise at obscure companies, even without public GitHub activity.

"The best engineers I remember from HashiCorp mostly had boring backgrounds."

Mitchell acknowledges spending a lot of his own time on social media, but notes that the best engineers don't waste time there and minimize context switching. He himself admits to lying in bed late at night writing code in his head and thinking through product ideas — his mind is constantly at work.

On hiring in the AI era, Mitchell emphasizes that proficiency with AI tools is now essential. You don't have to use AI for everything, but you need to know how to use it when it counts. The ability to quickly build a prototype using AI — especially in early stages like proof-of-concept work — is increasingly critical. He says every engineer should be running an AI agent at all times, delegating slow tasks to it.

"I think AI tool proficiency is essential. You don't have to use it for everything. But you need to know how to use it appropriately."

To avoid being interrupted by AI agents, Mitchell turns off all notifications and only checks results when he's the one who chooses to interrupt the agent. He also draws a clear distinction between tasks that require thinking and those that don't, delegating the latter to agents. He warns that misusing AI tools leads to thinking less, but if you use them to "choose what to think about," you don't have to sacrifice your depth of thought.

The most general advice Mitchell gives to future founders is: "Startups take far longer than you think." You should ask yourself whether you're willing to do this for at least ten years. You need a certain "hubris" — a belief that you can do this better than anyone else — but you also need the balance to stay aware of change rather than be blinded by it.

For AI startups, he notes there is unprecedented pressure to move fast. AI enables you to move at a crazy pace — and many companies are in fact doing exactly that. He also notes that AI has changed the fundraising process: founders can now use AI to rapidly build prototypes even before a seed round, raising investor expectations accordingly.

12. Closing Thoughts

Mitchell Hashimoto says that in the AI era, software engineers will increasingly be expected to handle "vague tasks." Engineers will now be able to build entire demos solo, do research effectively, and run more experiments than ever before. However, he expects that production-stage work will continue to look much as it does today.

Beyond coding and technology, what recharges Mitchell is quiet, solitary time. As an introvert, he recharges by taking walks on the beach or reading novels at night. His most recent book recommendation is V. E. Schwab's The Invisible Life of Addie LaRue — a romance novel about a woman who lives forever but is forgotten by everyone she meets. He says reading fiction provides a completely different experience from coding and helps him shift his thinking.

Mitchell Hashimoto's story offers important insight into how AI is changing every aspect of software engineering, and how we might adapt and find new opportunities amid that change. His advice — "always have an agent doing something, but turn off notifications and don't let the agent drive you" — is a practical guide for every engineer navigating the AI era.