Mitchell Hashimoto on HashiCorp, the Cloud Giants, and Always Keeping an Agent Running
The Pragmatic Engineer
Mitchell Hashimoto co-founded HashiCorp, whose tools (Vagrant, Packer, Consul, Terraform, Vault, Nomad) became standard parts of cloud infrastructure. He now works on the terminal emulator Ghostty. In this long conversation on The Pragmatic Engineer podcast, Hashimoto covers how HashiCorp began and nearly didn't, what partnering with AWS, Azure, and Google Cloud was really like, and how AI coding agents have changed both personal workflow and the maintenance of an open source project. A recurring thread runs through all of it: Hashimoto is most motivated by what "feels right" and what is fun, and treats AI as a way to choose what to think about, not as a replacement for thinking.
A self-taught start and an unexpected job offer
Hashimoto's beginning will sound familiar to many developers. They taught themselves to program at around 12 or 13, drawn in by video games, but quickly moved to the web, working in PHP and Perl. Their parents wouldn't buy expensive programming books (partly because they doubted the books would be read), so the only learning material was whatever code was published online. That was Hashimoto's first contact with open source, before knowing the term.
One memory stands out. Hashimoto printed the first chapter or two of the PHP manual, about 30 to 40 pages, and read the whole thing on every walk to school for weeks without understanding it. Then one morning the meaning of the dollar-sign variables suddenly clicked: they store things, and those things can change. Hashimoto arrived at school thrilled, and remembers progress speeding up a lot after that. Early projects included gaming sites, game cheat tools, and clones of sites like PayPal, built out of curiosity about how money moved online. Hashimoto also pretended to be 18 on freelance sites and earned $50 or $100 per job doing things like image upload features.
Programming was lonely. Being into computers was, in Hashimoto's words, "a social death kiss," so even close friends didn't know. Online friends from MSN Messenger, AIM, and forums filled the gap, and Hashimoto still keeps in touch with some of them. After going to the University of Washington to study computer science, Hashimoto stopped hiding it and started blogging. Late in freshman year, a stranger emailed asking if Hashimoto wanted to be a Ruby on Rails programmer. Hashimoto had never written Ruby and assumed it might be a scam, but the sender was in LA, so they met in person. The job turned out to be real: a consultancy that, in the 2007 Rails boom, built minimum viable products for clients about every two months. Hashimoto built a YouTube-style site, a philanthropy site, an e-commerce site, and more, and valued the variety of technologies and scale questions.
An unplugged mouse and a notebook of unsolved problems
What turned Hashimoto toward infrastructure was a boss at that consultancy, a very private person whom Hashimoto didn't name. There was no Heroku or Engine Yard yet, and this person handled hosting on dedicated servers. He ran Linux, had long black hair, didn't use a mouse, and sat in a corner avoiding conversation, which made Hashimoto curious. Once Hashimoto showed real interest, the boss began handing out challenges. The first was to unplug Hashimoto's mouse and take it away, saying Hashimoto would never use a mouse again and would have to figure it out. After about a week, Hashimoto was fluent with the keyboard. Then came GNU Screen ("early tmux"), then SSH, package managers, and so on. Hashimoto says they loved infrastructure right away.
Around the same time, Hashimoto joined a University of Washington research effort called the Seattle Project. The name was, as Hashimoto notes, impossible to Google. Inspired by Folding@home, it aimed to let people donate heterogeneous hardware, from home machines to unused racks, and build a general scheduler so academic institutions could run workloads on it. Hashimoto's vague assignment was to make it possible to spin up all these nodes. After a 10-week quarter, Hashimoto had failed on the technical side. They wrote in a notebook, which they still have, the missing pieces that would have been needed: a way to declaratively manage resources, a way to network the machines privately, and so on. Much of that list was never built, but a subset later became HashiCorp's products.
Hashimoto shared the notebook as a kind of exit interview with the undergraduate supervising the project: Armon, who became Hashimoto's co-founder. A few weeks later Armon emailed out of the blue around 11:30 p.m. asking whether Hashimoto wanted to do a startup together. They had barely met. Hashimoto, around 19 or 20, replied within two minutes: "Sure." Hashimoto says Armon still remembers how fast the answer came, and that was the start of their friendship.
Vagrant and the value of constraints
In parallel, Hashimoto was building Vagrant, which came from a consultancy problem rather than from the research project. Any hour that couldn't be billed was wasted, and developers often needed to jump into another team's project to help with a feature. Setting up a development environment could take half a day. That time couldn't be billed to the client, and installing a different Ruby or Rails version could also break the environment for the developer's own client. Hashimoto's mental model was being able to "double click and open a dev" environment, help for a couple of hours, and leave.
Vagrant was built on VirtualBox (then from Sun), and it was chosen because it was free, not because it was open source. EC2 already existed, but a college student couldn't pay for instances. Hashimoto uses this to make a broader point: much of software engineering is understanding and working within constraints, and constraints tend to produce better software.
Betting on the cloud, and on multiple clouds
Being in Seattle placed Hashimoto near the start of AWS. Amazon donated credits to the university, many UW computer science students interned at Amazon, Armon interned at AWS, and people weren't yet sure whether to pronounce S3 as "S cubed." Hashimoto remembers AWS as very rough. EC2 and most services were unreliable, S3 was the only dependable piece, and EBS didn't exist yet, so there was no durable storage other than S3.
Hashimoto says they never had a clear belief that the cloud would be enormous. It simply felt like the better way to work, whether or not it won in the market. The real bet came when HashiCorp started around 2011–2012, on the premise of multi-cloud. At that point AWS was dominant, Azure barely existed, and Google had App Engine rather than a real cloud. Pitching cloud-agnostic tools drew raised eyebrows because AWS was the only real player. Hashimoto and Armon's reasoning was that anything economically huge attracts competitors, and Microsoft and Google wouldn't ignore it. Hashimoto says it "mostly played out that way."
From a mobile ads startup to HashiCorp
After graduating, Hashimoto moved to San Francisco because Seattle's options were mostly Amazon or Microsoft (and to some degree Facebook), and Hashimoto wanted startups. They joined a mobile ads company with fewer than 30 people and persuaded Armon, who had been admitted to a PhD program at Berkeley, to defer for a year and join. There the two built rough prototypes in Python and C of ideas from the notebook: DNS-based service discovery made by connecting an off-the-shelf DNS server to Postgres, and an early version of Terraform called "Launchy." They were hacky, but they felt directionally right.
San Francisco's social scene made the rest clear. Hashimoto recalls being invited across the street to a company that later became Lyft, to try an unnamed app with a mustache. At meetups and parties, two patterns kept showing up. Every startup was cloud-first, and Hashimoto can't remember meeting anyone besides Twitter who used dedicated servers. And they were all hitting the same problems Hashimoto and Armon's internal tools addressed. (The joke of the time, Hashimoto says, was that AWS outages made startups more cash-flow neutral, so nobody wanted to migrate regions.) Combining some hubris about building the right thing with a sense of where the industry was going, they started a company. Vagrant mostly supplied credibility, and Hashimoto points out it wasn't that big at the time.
Hashimoto initially self-funded, moving $20,000 from savings into a corporate account and taking no salary for six months. Armon joined after that, and they decided to raise money. As Hashimoto saw it, there were three options: bootstrapping, venture capital, and "patronage," meaning convincing a company to pay your salary to work on an idea (Hashimoto cites Redis at VMware as the best example). The initial plan already included everything except Vault. Their estimate was that even a very successful bootstrapped path would take about a decade just to build the software, and the cloud was growing so fast that someone else would solve the problems their own way first. So they chose VC to hire quickly.
The Hashi stack, product by product
Hashimoto walks through the products in order of release:
- Packer, the first HashiCorp product, builds machine images such as Amazon and VMware images. Hashimoto calls it understated, and says entire multi-billion-dollar cloud platforms build their official images with it. It targeted a problem similar to today's serverless cold starts: if a server took tens of minutes to become ready, you couldn't take advantage of auto scaling. Packer let teams snapshot a configured image and launch it directly.
- Consul handled service discovery. Previously machines had stable IPs, but in the cloud, web servers, load balancers, and databases were "breathing," constantly created and destroyed. Discovery had to be faster and had to ensure an address was actually ready. Hashimoto compares this to readiness and health checks that later became common with Kubernetes, but applied to VMs and cloud servers.
- Terraform, released around 2014, lets you describe infrastructure as text (VPCs, subnets, gateways, EBS attachments, and so on) and "make this text reality" in an empty cloud account, then tear it all down with one command.
- Vault is secrets management and encryption. It covered production secrets and also sensitive data like customer emails, addresses, and credit card numbers. Hashimoto had hoped it would also solve developer-side secrets, but says it never did that well.
- Nomad was the scheduler, finally solving the undergraduate problem: given a pool of compute and an app with requirements, find a place to run it. Hashimoto admits it arrived "a couple years late" to the market.
Hashimoto shares that no one on the team that built Vault had more than one quarter of undergraduate security coursework. Worried about that, the startup paid two firms tens of thousands of dollars to audit Vault 0.1 and privately shared an early beta with security experts. Professional security staff were hired soon after. Hashimoto's takeaway is that the security market mainly needed a change in user experience: Vault's functionality wasn't fundamentally different from what large existing companies offered, but the way people interacted with it was.
Four years without a business, and Atlas
For about four years, Hashimoto says, there was no repeatable, growing business, only a bit of revenue from a few random sources. Everything was open source, and Hashimoto privately believed that if the company failed, good ideas would survive through the community. The technology mattered most, and the business was something Hashimoto hoped to figure out. Hashimoto admits this wasn't something they would have told investors then.
Investors went along because of traction. Hashimoto describes a rough Silicon Valley framework: a seed round builds the product, a Series A shows hints of product-market fit, a Series B proves product-market fit with hints of revenue, and later rounds build a repeatable revenue machine. By the A, HashiCorp had millions of downloads and plenty of GitHub stars, but zero revenue. Hashimoto thinks they followed the usual sequence, just a year or two behind.
The first try at commercialization, a product called Atlas, "was a total failure." Its premise was a commercial offering that ran all the products together. That created two problems. A company using only Vault had no practical way to buy in. And even companies using everything couldn't decide who should pay, because security, networking, infrastructure, and developer tooling teams each pointed at another budget, like the Spider-Man meme. Hashimoto's lesson for engineers turned founders is that companies are willing to pay for software but will fight over whose budget covers it.
The Friday-night pivot to open core
Things came to a head at a board meeting, held on a Friday about an hour south of their San Francisco office. Nobody yelled, but Hashimoto compares it to knowing your parents are disappointed without them saying it. The drive back was silent. Instead of going to Armon's place for wine and a debrief as usual, Armon drove straight to the office. At a whiteboard they played a game: if there were no sunk costs, what would they do? They wrote out per-product enterprise offerings, starting with Vault. Late that night, Hashimoto recalls, Armon looked at the board and asked why they didn't just do that.
Over the weekend they scrapped the old plan, including arrangements with their two paying customers ("just breach contract, I don't know," as Hashimoto puts it). At a Monday all-hands with roughly 20 to 30 people, they announced the new direction: enterprise customers, open core, per product, with the open source project plus an internal fork containing closed-source features. They expected people to leave, since open core was already somewhat unpopular, enterprise sales seemed boring, and the change suggested the founders didn't know what they were doing. Hashimoto admits they didn't. No one quit, and the mood in Slack was very positive. In one-on-ones, employees said that clear direction and conviction were a relief after feeling like the company had been throwing darts.
They built Vault Enterprise by the new year. Within the first quarter of selling, the difference was noticeable in the quality of conversations, how far deals got, and how quickly. Looking back, Hashimoto thinks customers had been asking for this all along. During pitches about adopting the full stack, people kept asking things like how to replicate secrets in Vault. Hashimoto says they were too focused on their own vision to notice. Secrets replication, initially within a single region's cluster, became the first closed-source feature. Security was an obvious buyer with an obvious budget. Hashimoto also stresses that these corporate buyers didn't care about open source. What they needed was a commercial agreement, support, proofs of concept, legal terms like code escrow, and evidence from other customers. Revenue later came mainly from Vault and Terraform, as HashiCorp's public filings showed.
Terraform wasn't first, and 30 issues closed after every flight
Asked why Terraform became so widespread, Hashimoto says it's odd to hear, because for a long time HashiCorp felt like "the background company." What still annoys Hashimoto is the claim that Terraform won because it was first. By Hashimoto's count, it was about seventh to market in an infrastructure-as-code space with no clear winner.
Hashimoto's marketing strategy back then was to be at every conference possible, speaking or just talking to people. When COVID lockdowns began in March 2020, Hashimoto and their wife, together since 2012, noticed that for roughly nine years Hashimoto had not stayed in one place for more than eight days in a row.
Coding continued through all that travel. Before in-flight Wi-Fi was common, Hashimoto wrote scripts to download GitHub issues, categorized them on the ground, and split them into tasks of 10 to 15 minutes each, avoiding design-heavy work because deep flow was hard on a plane even on long flights. Fixes were committed locally during the flight and pushed on landing, so people would get notifications of around 30 issues closed at once. The key, Hashimoto says, was doing the planning beforehand.
Going public
HashiCorp went public in 2021. Hashimoto had stepped down from the executive team about six months before and didn't take part in the roadshow, but knew about the planning. The process takes more than a year. The company starts operating like a public company at least two quarters early, including mock earnings calls where investors act as public investors over speakerphone while the finance lead presents the quarter.
Secrecy was intense. Hashimoto went silent on most public topics. About eight months before the IPO, the general counsel contacted Hashimoto in the middle of the night to ask that a Hacker News comment be deleted. Hashimoto didn't remember the exact regulation but understood that you can't influence the market or hint at an IPO. Hashimoto took this far enough to ask their parents to come to New York for something "really, really important" related to HashiCorp without saying what it was, and even told the relative dog-sitting that it was a family vacation.
The VMware deal that fell through by one vote
About two years into the company, when HashiCorp had three people, VMware began showing interest. Hashimoto describes it as a slow process: a low-level business development contact wanting to talk vaguely, then an office visit, a VP of engineering "swinging by," a dinner with three executives that was mostly social, then partnership talks, then hypotheticals about what they would do with VMware's resources. Hashimoto was flying up from LA for these meetings and eventually pushed for a decision. This is why Hashimoto warns founders that M&A can waste a lot of time.
VMware provided a one-page letter of intent without a number. Verbally, the first figure was $20 million. Hashimoto and Armon, then about 23 and 21, owned 70% together, and Hashimoto admits you start thinking about what you'd buy, which is the dangerous part. Advisors said the offer was far too low. They asked for something like $40–50 million and got an informal yes, which suggested it was still too low. When a meeting with VMware's CEO came up, they started having second thoughts. They called it "dream-killing" money: life-changing personally, but too small to matter to VMware, which likely meant their products would be absorbed and they'd be assigned to something like ESX.
Hashimoto credits Armon with suggesting a regret-minimization exercise. Each would privately pick the lowest price at which, if VMware shut everything down the next day and made them work on ESX through a four-year lockup, they would still feel it was worth it. Their numbers were close, and they settled on $100 million. It felt ridiculous to ask for, but they did. The answer was hesitant, VMware called an unscheduled board meeting to vote, and the vote didn't pass. Hashimoto heard it came down to one vote, says they know who cast it and why, and believes Terraform probably would never have existed if the deal had gone through.
AWS, Azure, and Google Cloud, now that it can be said
While at HashiCorp, Hashimoto avoided criticizing any cloud provider because the company partnered with all of them, and stayed cautious for a while after leaving. Hashimoto noted that individuals at all three were great to work with and that these impressions come from around 2019 and may have changed since.
AWS was, in Hashimoto's words, "really arrogant," even "annoyingly arrogant." It always felt like AWS was doing HashiCorp a favor, even by agreeing to meet, and there was a subtle sense that AWS could launch a competing product and kill the company. Hashimoto says it eventually got close to "if we don't come to terms, we'll build this service." The Elasticsearch/OpenSearch situation had already happened to others. Hashimoto grants that AWS's public explanations had some truth to them, but says it "still [was] not a nice thing." Since HashiCorp's code was under MIT or MPL licenses, the leadership team was worried for about two years that an AWS Vault service might appear. HashiCorp had about five full-time engineers, roughly $1 million a year including benefits, working only on the open source AWS Terraform provider, with no help from AWS, which was the last provider to contribute. Hashimoto says things changed only after HashiCorp told AWS it would publicly deprecate the provider because AWS shipped features too fast to keep up. After that, help arrived quickly. Hashimoto acknowledges AWS might tell the story differently.
Microsoft gets the most positive assessment. Azure was technically "hairy," and Hashimoto still doesn't fully understand its IAM hierarchy despite integrating with it. But the business side was competent and cooperative. Meetings often began with "how do we both win?" Microsoft was the first to support Terraform and stayed consistent.
Google Cloud had the best technology and architecture thinking, but Hashimoto says it felt like nobody there cared about the business. Partnership meetings turned into hours of discussion about edge cases and scalability. The public evidence Hashimoto points to is that Google fully automated its Terraform provider (Hashimoto recalls it being called "Matrix something"), so new Google Cloud features had well-designed Terraform resources immediately. But when the topic turned to co-selling or giving sales engineers quota credit for infrastructure provisioned through Terraform, there was little response. Someone would talk for 20 minutes and then return to technical topics for two more hours.
Ghostty: starting from technologies, not a problem
After leaving HashiCorp a bit over two years before this interview, Hashimoto turned prototypes started around three years earlier into Ghostty, working on it much more intensively. Hashimoto describes the origin as the reverse of the usual advice. Instead of finding a problem and choosing technologies, Hashimoto chose technologies and asked what to build with them. After about 15 years focused on infrastructure and distributed systems, Hashimoto felt out of practice at desktop and low-level systems programming, had never really worked with GPUs, and wanted to try Zig. For Hashimoto, who enjoys writing C, Zig looked like the best "better C," one that lets you "blow [your] own foot off" if you choose. Having built CLIs for years and spent most of the day in a terminal while knowing little about how terminals worked, Hashimoto started a toy terminal project and discovered how much complexity was involved.
Hashimoto describes a terminal as an application platform for text, "like a browser, but for text content," where programs need text, colors, images, widgets, and mouse events. Adding capabilities like images creates entire new categories of problems. Hashimoto's joking summary is that Ghostty is "30% a terminal and 70% a font renderer." Architecturally, Ghostty is multi-threaded, which Hashimoto notes isn't meant as a boast. There's a UI thread for windows, an IO thread running the shell and processing bytes in both directions, and a renderer thread that samples terminal state on a vsync clock at 30, 60, or 120 frames per second and draws it, including mapping grid characters to fonts. Operating systems don't handle this for you unless you work at a much higher level. Hashimoto says the renderer isn't the hardest part. Maintaining terminal state is: a grid of monospace cells (80 by 24, for example), commands that move the cursor or change the "paintbrush" style, and scrollback, all done quickly.
The most visible benchmark is dumping a large file to the screen. Hashimoto says modern terminals like Ghostty, Kitty, and Alacritty all handle this far better than macOS Terminal.app or traditional Linux terminals. When critics ask why this matters, Hashimoto points to people force-quitting after accidentally catting a big file, and to a Hacker News comment by the creator of Redis explaining that they used to send production Redis logs to an intermediate file to read later, but now can stream them directly in Ghostty and scan them in real time.
Some of this, Hashimoto admits, is simply "the love of the game." Ghostty cut its per-frame renderer work (preparing state and submitting to the GPU, not including GPU time) from about 800 microseconds to about 9 on a full-screen Mac window, while a 120 Hz frame gives about 8,333 microseconds. Hashimoto acknowledges users wouldn't notice the difference, but says getting under 10 was more fun.
AI unexpectedly increased terminal use
One of the stranger results of AI, according to Hashimoto, is that it helped terminals. Because of Claude Code and similar CLI tools, and because even desktop agent apps run many commands in pseudo-terminals, Hashimoto says the number of terminals in use is much larger than in 2023, which Hashimoto wouldn't have predicted and calls "hilarious." That's part of the reason for libghostty, which has been extracted as a minimal, zero-dependency, MIT-licensed library for embedding a terminal anywhere. Many tools implement a small, flawed subset of terminal behavior, which is why something as ordinary as a progress bar in a Docker build or a Heroku push can render as a mess. Hashimoto is tired of seeing broken terminals and wants people to use this instead.
How Hashimoto actually uses AI
Hashimoto calls AI a revolutionary tool "within the right categories of things" and uses Claude Code, Amp, Codex, and chat tools daily. The biggest benefit is choosing what to think about. Two hours of boilerplate Hashimoto doesn't want to learn can now go to something else. Hashimoto acknowledges this means not building skill in those areas.
The core rule is to always have an agent doing something while working, though not overnight as some people do. If Hashimoto is coding, an agent is planning. If the agent is coding, Hashimoto is reviewing. Agents run in separate tabs, and usually no more than two at once, because Hashimoto doesn't enjoy cleaning up after many agents and doesn't run setups in the style of Gas Town. For harder tasks with uncertain outcomes, Hashimoto sometimes runs Claude and Codex against each other, or runs one agent on code and another on research, which Hashimoto especially likes them for.
Review depends on stakes. Everything going into Ghostty gets reviewed. But for a wedding website made for a family member, which makes no network requests, has no access to secrets, and would be online for two months, Hashimoto only checked that it rendered correctly in three browsers and on a phone.
Hashimoto has a routine around transitions: spend a few minutes before leaving the desk or the house, or before stopping work, asking what slow task an agent could do in the meantime. On the drive to the recording, a deep research task was building a map of HTTP/3 and QUIC libraries with certain properties and licenses. Before leaving, Hashimoto had used Amp's "oracle" feature to think through edge cases in the vouching system Hashimoto was designing. Given two more hours, Hashimoto would have done that personally, but didn't have the time. Desktop notifications from agents are turned off, which Hashimoto thinks are mostly a mistake: "I choose when I interrupt the agent." Hashimoto tries to separate tasks that need thought from those that don't and delegate the latter. Hashimoto agrees with critics that AI can make you think less if you start an agent and go scroll social media, but argues it doesn't have to if used to choose what to think about, while expecting most people won't use it that way.
Ghostty's contribution policy: from disclosure to vouching
About a year before the interview, Ghostty started requiring contributors to disclose AI use. To people asking why it matters how code was produced, Hashimoto answers that it determines how much effort a maintainer should invest in return. Bad contributions aren't new, but previously they usually came from people who had tried hard, and Hashimoto would respond with patient, educational reviews. If someone spends a few minutes and "threw it over the wall," Hashimoto wants to spend a few minutes, say no thanks, and close it.
Disclosure mostly worked. The problem was volume. Hashimoto noticed a turning point when agents began opening pull requests themselves. At the time of recording, Hashimoto says Claude opens a PR as a draft with no body, adds the body afterward, and then marks it ready for review, all within about a minute. Hashimoto used to see a human do this about once a year and now sees it about three times a day, which makes AI PRs identifiable even when undisclosed. Hashimoto had recently tweeted a wish that agentic tools would slow down on opening PRs, since that's where the friction is.
Ghostty's current policy prohibits AI-written PRs unless they're linked to an accepted feature request. Ghostty receives two or three drive-by PRs of this kind a day, and Hashimoto closes them without reading the code, as a matter of policy. At the time of recording, a further change was pending: an explicit vouching system based on Lobsters, and in the AI context on a project called Pi, which Hashimoto describes as a build-your-own-agent toolkit that cares a lot about code quality. Under this system, nobody can open a PR, AI-assisted or not, unless an existing community member vouches for them. Vouched contributors join a list and can open PRs indefinitely. If someone behaves badly, they, whoever vouched for them, and everyone that person ever vouched for are blocked from the repository. Hashimoto says they'd give a second chance to someone who shows up on Discord or email and seems reasonable and apologetic. Unlike Pi, Ghostty's version also lets members denounce bad actors. Hashimoto mentions someone the day before who reopened a closed AI PR from a new branch ten minutes later.
Hashimoto admits to "crashing out" when earlier musing about closing PRs entirely, and describes lying awake until 12:30 a.m. the night before, going over how vouching might or might not work.
Open source, trust, and forking
Hashimoto expects open source to change significantly. One extreme view, which Hashimoto mentions without endorsing, is that if agents are good enough, you don't need open source because you can build everything yourself. The core issue, Hashimoto says, is that the effort required to submit a change used to provide natural back pressure, and AI removed it. Hashimoto quotes Pi's framing: AI makes it trivial to create plausible-looking but incorrect and low-quality contributions. Open source has always been a reputation and trust system. The default used to be trust, and now it has to be default deny, with trust earned through someone else. Hashimoto sees the vouching approach as consistent with what open source has always been.
Hashimoto hopes to see many more forks and says they've argued this publicly for years, independent of AI. Contributors often feel entitled to a merge because their change is clean and works, and communities get angry when a perfect PR is declined. But Hashimoto has said since the HashiCorp days that clicking merge is the easy part. The hard part is years of maintaining that code alongside the roadmap, bugs, and user needs, and features are very hard to remove. The core right open source grants, Hashimoto says, is the ability to fork and maintain your own version.
Git, monorepos, and "everything is changing"
On reports that large companies are rethinking monorepos because of agents, Hashimoto lists Git's weaknesses: mainline Git essentially requires cloning the whole repository, heavy churn makes getting changes into trunk difficult, and merge queues work for humans at some scale but grow deep. Multiply activity by 10, conservatively, or by 100 or 1,000 if you believe the hype, and Hashimoto thinks keeping main coherent becomes untenable. Hashimoto also points out that Git retains only successful work. Abandoned experiments that never became branches or PRs are lost, even though that information has value. Hashimoto compares the moment to Gmail's arrival, when email went from curating and deleting to never deleting: repositories should be huge and context-rich, with better tools to find what's relevant.
Hashimoto advises a stealth company in this area and says the evidence comes from highly agentic companies that have "drunk the Kool-Aid." Their problem isn't AI review but release mechanics: merge queues, performance, pushes rejected because something always changed, and people finding the right information. Asked whether Git will still be around in a few years, Hashimoto says nobody knows, but this is the first time in 12 to 15 years that anyone can ask without laughing. Hashimoto says Git, GitHub, and similar forges in their current form don't work with agentic workflows, while noting they are only an observer here, as a heavy agent user and maintainer, not someone trying to fix it.
More broadly, Hashimoto agrees with Amp's line that "everything is changing," calling this the first time in a roughly 20-year career that so much is open to change at once, and saying they find that exciting as an optimist. Editor loyalty used to be strong and is now very fluid, and Cursor reached a valuation Hashimoto thinks an editor company never could have before AI. CI/CD will change, and testing especially, because agents are goal-directed and will break behavior that no spec or test protects. One of Hashimoto's goals for the year is "harness engineering": whenever an agent does something bad, build tooling it could have used to avoid or correct the mistake. Hashimoto also sees sandboxing and compute changing. Agent sandboxes have already bent the growth curve of small compute units, which will stress Docker, Kubernetes, and similar tools with a new kind of non-production workload.
Hiring: quiet engineers and minimal context switching
Hashimoto stands by an earlier observation that the best engineers they've worked with, at HashiCorp and elsewhere, tend to have unremarkable public profiles. They often have no social media, sometimes no GitHub account, work for companies Hashimoto hasn't heard of, and are frequently "9-to-5 engineers" who spend evenings with family but are fully focused and highly skilled during work hours. Hashimoto notes the irony of spending a lot of time on social media while saying these engineers are better. Time is zero-sum, and switching to social media while code compiles costs more than the minutes spent because getting back into flow takes time. Hashimoto's own advantage, they say, is spending long stretches at night mentally writing code, website copy, and CLI interactions, and being willing to compete with anyone because they expect to spend more time thinking about the product. The best engineers, Hashimoto suggests, are probably those who context switch least.
Hiring today, Hashimoto would require competence with AI tools, not using them everywhere, but understanding where they help. Prototypes are the clearest example: Hashimoto would rather someone "throw slop at a wall" for a day to test an idea than spend a week building a throwaway version by hand. That's why sloppy open source PRs frustrate Hashimoto: there's a time and place for slop, and someone else's repository isn't it. Hashimoto would also encourage every engineer to keep an agent running on something, while being unsure whether that's the right requirement.
How Hashimoto went from skeptic to user
Hashimoto tried Claude Code around its May public release and wasn't very impressed. By summer, the amount of praise made Hashimoto worry about falling behind. Still unconvinced, Hashimoto did all work manually and then made themselves figure out how to prompt an agent to reach the same quality, a process that took more than twice as long. Some tasks weren't possible yet. But Hashimoto arrived at the same lessons many others had: a separate planning step improves results a lot, a better test harness for the agent to run helps, and adding a mistake to AGENTS.md means the agent stops repeating it. Watching livestreams of AI skeptics trying these tools, Hashimoto felt they were "swinging the hammer way off." Hashimoto compares it to learning Git: nobody gets proficient in an hour.
Hashimoto's advice for reluctant engineers is to reproduce their own work with an agent. If they don't want an agent writing code, they can have it redo the research portion. You don't have to accept the idea that it must replace you. Just find the parts of your work it can take over.
Advice to founders, and pressure on AI startups
When aspiring founders ask for advice, Hashimoto first warns about survivorship bias, then asks for specifics: open source or not, remote or not, enterprise or not. The general advice is that startups take much longer than expected. Hashimoto tells people to imagine 10 years instead of 5. You need enough hubris to believe you'll do it better than anyone for a decade, which Hashimoto admits has no basis other than hubris, but not so much that you can't see change coming. Many people with good ideas, Hashimoto says, burn out quickly.
Hashimoto doesn't advise AI startups but has talked with some and describes the pressure as greater than any they've seen. There's an expectation that AI should let you move extremely fast, and many companies are moving that fast. Otherwise, questions like remote work and open source are the same as before. Hashimoto is careful not to call engineers "more productive." The better description is that more is expected: building a full demo and design without a team, researching well, handling vaguer tasks, and experimenting much more. Productionizing still feels similar to before, and Hashimoto finds it somewhat worrying when companies copy AI labs' "ship whatever" approach. For pre-seed founders, the change is that investors now expect a prototype rather than funding one, except in genuinely hard tech.
Recharging
Outside of work, Hashimoto, an introvert, recharges mainly with quiet time alone, often by closing the laptop and walking near the beach when things aren't going well. Hashimoto reads mostly fiction apart from news, and prefers reading to TV when alone. Their recent pick is a novel they referred to as "The something life of Addie LaRue," about a woman who trades her soul to live forever at the cost of being forgotten by everyone once she leaves a room. Hashimoto isn't sure whether it's escapism, but living in very different worlds helps them switch off from coding.
The episode ends with the host highlighting Hashimoto's rule: before stepping away, ask what slow task an agent could be doing while you're gone, and keep notifications off so you decide when to check in.
What was your experience back then of AWS? Your honest view.
AWS was really arrogant. Felt like they were doing us a favor.
Subtle vibe of we will spin up a product and kill your company.
Terraform just seemed to be everywhere. Why do you think that sudden popularity was?
One of the things that frustrated me was like, oh, they only won cuz they were first to market. We were like seventh to market.
It feels like most of open source will have to change because of AI.
AI makes it trivial to create plausible-looking but incorrect and low-quality contributions.
Open source has always been a system of trust. Now it's just default deny and you must get trust.
Think Git will be around in a few years?
What's interesting is this is the first time in like 12 to 15 years that anyone is even asking that question without laughing.
If AI just can write code, open pull requests, and ship features, do we even need open source contributors anymore? Mitchell Hashimoto, the co-founder of HashiCorp, has been thinking deeply about this, the future of open source, and how to efficiently integrate AI into his day-to-day workflow. Mitchell built the tools that power modern cloud infrastructure, Terraform and the Hashi stack. He also created a popular terminal, Ghostty, and I consider him to be one of the most thoughtful voices in the industry on how AI is changing the craft of software engineering.
In today's episode, we cover the origin story of HashiCorp, a failed university research project, a notebook with unsolvable problems, and an email from his future co-founder that he answered in two minutes. His honest, unfiltered take on working with AWS, Azure, and Google Cloud as partners, both the arrogance and also the brilliant engineers who never thought about the business. How he's adapted to AI coding tools, why he always keeps an agent running in the background, and his practical advice for engineers who have not yet warmed up to AI agents, and many more.
If you're interested to hear from one of the most hands-on builders in the industry and want to know where AI tools are useful versus not, then this episode is for you. This episode is presented by Statsig, the unified platform for flags, analytics, experiments, and more. Check out the show notes to learn more about them and our other season sponsors, Sonar and WorkOS.
Mitchell, welcome to the podcast. It's awesome to be here in person.
Yeah, it's cool to meet you in person after so many years of following you.
You've had such a massive impact on the tech industry and software engineers, but how did it start?
I think the high level is the same story as a lot of people. I self-taught around 12, 13, early teens, motivated by video games. Same as a lot of people.
Although I really quickly realized that I liked web. You know, web was new, Google wasn't out yet. I think web was new. I never became a video game programmer. I really quickly just became a web programmer, PHP, Perl, that sort of stuff.
And because I was so young, the only way I could learn was through whatever code was published online. And so that's how I got acquainted with open source. I didn't know that's what it was called then, but a kid with no job, no money, parents didn't want to buy, you know, professional books were, I don't know what they are now, but they were like 50 bucks then, right? And so they were like, "No way, right?" And also they didn't believe I was going to read it. And so there was no way they were going to buy that. So yeah, anything I could find online was my in into coding.
I'd walk to school every day with a group of friends. And there's a period of time where I printed out the first or second chapter of the PHP manual. I remember it was about 30 to 40 pages of paper. And I never programmed, so all the stuff, and I'm 12, is very confusing. So I read the whole 40 pages every walk to school and I don't remember how long it took me, but I did that a long time before, you know, I remember this one moment where I was walking to school where suddenly I understood what these dollar sign things were. For whatever reason it just came in.
Those were variables, right?
Variables, yeah. And I really understood. I'd heard that word before. And you don't hear the word variable as a 12-year-old in any context. And finally, at one point it hit me that they store things, and things could change. And I remember just weeks of reading this thing and not understanding it, getting to school so excited, being like it triggered. And then after that, I remember stuff happened really quickly.
What kind of stuff did you build? Websites?
Yeah, websites. It was gaming-related websites. It was a lot of game cheat stuff for software. Yeah, I mean, I had a lot of fun cloning websites. You know, I did it poorly, but PayPal was out, and I really wondered, how does money get transferred over the internet? How does that work? So, I tried to build copies of cloning websites. I did masquerade as an 18-year-old on freelance websites. And so, I got, you know, 100 bucks here, 50 bucks here to do image upload stuff.
I decided to study computer science in college. Went to University of Washington. I mean, I guess that's when you'd call it serious, but I was really, I mean, I was coding every day as much as I could through high school.
Oh, okay.
Yeah.
That's impressive. Were you alone with this in your friend group? Were there other people doing it, or was it kind of lonely?
It was lonely. It was very lonely. It was lonely in the real world, and then I quickly found online friends through MSN Messenger and AOL Instant Messenger and forums. I found online friends, many of which I have met now, and I still keep in touch, which is cool. But, no. I mean, back then, being a programmer, one, no one knew that word, but being into computers was like a social death kiss. And so even my closest friends didn't know. My best friends and stuff. I hid it from all of them, and I didn't talk about it at school and stuff like that. So, it was just a secret until I went to college. And college is when I decided to let it all out.
The big break that I got was I blogged, and my late freshman year, heading into the summer after it, of college, someone just emailed me out of the blue and I kind of thought it was a scam. It was just like, do you want to be a Ruby on Rails programmer? And I didn't know Ruby. I was a PHP programmer. I had never done Ruby and never done Rails, but I got this email and I'd never been headhunted before. I didn't know what this was. I was also 18 so I didn't really know what to think about it.
I probably would have not responded except that the person who contacted me was in LA, and so I did respond and we set up a meeting, a real physical meeting, and I met him and met the company and realized this is real and they're serious and genuine, and I took that job and, yeah, I learned a lot on the job there. So that was a huge change.
Was it a startup, a small company, something like that?
No, it was a consultancy. So it's kind of one of the standard, like, this is 2007, Ruby on Rails had blown up. It was already very popular and there were all these consultancies that appeared out of nowhere that were basically like, we'll build your minimum viable product, and we're one of those shops. So great job for a college student, cuz we'd see a client like 2 months and I would build a YouTube style website and then I would build a philanthropy website and then I would build an e-commerce website, and I got to learn all these different technologies and different scale challenges, and, you know, there wasn't a lot of scale cuz we're building MVPs, but different ways of thinking about scale problems. It was great.
How did eventually HashiCorp start? Or what happened between getting this Ruby job to a few years later?
It kind of starts with this Ruby job. There was one guy that worked at the company and he's pretty into his privacy so I won't share his name, but he was my boss and there was no Heroku, there was no Engine Yard. So you had to self-host, and Ruby on Rails hosting then was kind of difficult. So he was the guy who got all these projects hosted on dedicated servers and I didn't know anything about that. And he ran Linux and he had long black hair and he didn't use a mouse and all these things that were so weird to me and I was just intrigued. He sat in the corner, he didn't want to talk to anybody. And I just wanted to know more about what that world was.
And luckily despite appearances he's very nice. And so, yeah, I think as soon as I showed a genuine interest, started asking a lot of questions, he started just giving me challenges. The first challenge I remember he did is he unplugged my mouse. And it's funny cuz there's an era of time where if you did that it probably would have been some kind of harassment or something, but he literally said, unplug your mouse, and said, "You're never going to work with a mouse again. So, figure it out. I'm not going to tell you how, just unplug your mouse, restart the computer. Your problem now." And took the mouse away. Took me about a week and I got really good with the keyboard. Harsh lesson.
And once I got good with the keyboard, he said, "Okay, here's," he installed screen, you know, early tmux, he installed screen in my terminal and said, "Figure this out. You're going to use this now. There's no questions, you will use this." And he just slowly installed all of it on me, and as we got there, then it became, you know, here's SSH, here's a package manager. He slowly taught me more and more and that got me just in. I loved infra immediately. It was like, this is super cool, super fun. So, that long-winded process got me into infrastructure.
And then simultaneously or very shortly afterwards I joined a research project at the University of Washington called the Seattle Project, which is a terrible name cuz you can't Google it. But it's called the Seattle Project. I'm sure it doesn't exist anymore. And again, another popular thing during this time was kind of like Folding@Home. They were trying to generalize Folding@Home, which is, can a bunch of people compute, you know, it could be your home machine, it could be an unused rack, it could be in your basement, it could be around the world, but can you donate all this heterogeneous hardware, and then can you generalize a scheduler on top of it so that academic institutions across the world could just run workloads. And not just research. The job I got was basically, very vaguely, to create not the scheduler component, but create the ability to spin up all these nodes and a bunch of other stuff. It's very vague, but it was this infrastructure-y problem.
And I completely failed at it. I tried for a quarter, but from a technical side, I just failed. And I wrote down in this notebook what I thought the pieces were missing that I couldn't solve this problem in a quarter, in a 10-week period. Like why? Well, we need this, we need this, we need this.
It's interesting to see how structured Mitchell was in his approach in defining components that would later become parts of the Hashi stack. And this leads us nicely to our season sponsor, WorkOS.
One thing I've learned from studying great engineers, Mitchell included, is that they're very deliberate about what they choose to build. Great engineers don't just ship fast, they think in systems. They understand leverage, and they're careful about what becomes part of their long-term surface area. If you're building SaaS, especially an AI product, authentication and enterprise identity can quietly turn into a long-term investment. SAML SSO, directory sync, audit logs, and all the things enterprise customers expect. WorkOS provides these building blocks as infrastructure, so your team can stay focused on what actually differentiates your product. Great engineers know what not to build. If identity is one of those things for you, visit workos.com. And with this, let's get back to Mitchell's notebook with all the components he would end up building at HashiCorp.
And I still have this notebook in my house here, but the problems were really, you know, I have no way to declaratively manage the different resources that are out there. I have no way to network these together in a private network. You know, I wrote these things down. And there's a lot of stuff there that I never ended up building, but a subset of that was ultimately what HashiCorp would end up building. And I shared this with my undergraduate boss, who was Armon, who was my co-founder.
Yep.
So, he was my
Yeah, later became your co-founder.
Yes, he was my boss on the undergrad side. And I shared it with him as kind of an exit interview. Like, this is what it is. And then some period of time passed, not much, weeks passed, and he emailed me out of the blue and was like, "Do you want to do a startup together?" You're a teenager and you have no idea what this commitment is.
Well, you're like 20 or something at this point?
Probably not even. Probably 19 or 20, yeah. And he emailed me out of the blue, just like, "Do you want to do a startup?" Like, a person you never met, or you barely met, never met personally, all this stuff. It's so funny. And he emailed me that at like 11:30, near college. I emailed him back in 2 minutes and said, "Sure." And he remembers thinking, "Wow, you just thought of something fast." And he's just in. He's ready to go. That was sort of the start of our friendship. And then,
again, there's overlapping pieces here, but I was also at the time working on something called Vagrant. And Vagrant, you know, came out of the consultancy, less the research project. It was solving the problem in this consultancy where we had new clients every 2 months and we had different teams. How do we create reproducible dev environments so I could go help somebody without a lot of billable hours.
So, this is a development environment that you could spin up quickly, right?
Yeah. The metaphor I always had was, I didn't use Windows then, but the metaphor I always used was how could I double click and open a dev
Yep.
That was the metaphor I used because
It's a good one.
Yeah, the problem we were having was any hour wasted in a consultancy that you can't bill is just a waste. And so, it was basically like, if somebody else is behind schedule, how can I jump in, help implement a feature, and jump out. And we were in that era where just setting up the dev environment for a project might take you half a day.
And you couldn't bill that for the client, right? The client would only pay for the work.
Yeah, you couldn't bill that for the client. So, it'd be like 4 hours of work wasted. And it would probably mess up your dev environment for your actual client because you would be on a different Ruby version, a different Rails version. And so, you would kind of destroy both ends. And so, Vagrant came out of that. Which was, I just need to go over there and, what ended up becoming, vagrant up, sweet, in a few minutes. Let's help you for the next 2 hours and then
And how did you build it back then? Was it some kind of virtual machine or
Yeah, it was with VirtualBox. Virtual Oracle. Well, it was Sun then, but VirtualBox, and that's another cool constraint, which is that I was a college student. So, I had no money. So
This was expensive back then, right?
Virtualization was expensive, but VirtualBox was free and open source. I don't care about the open source side for that. I was
Back then, yeah.
Yeah, I was never going to read it, but yeah, it was free. That was why I did it. And that's why I did that and not like EC2, which did come out by then. But I didn't do EC2 because I didn't have money to pay for these instances. So, yeah, that was the constraints. And I like bringing that up because I think so much of software engineering is understanding constraints and working with these constraints. In your prior podcast, they were, you know, called forces, like static and dynamic forces. It's that. And I think that helps create better software when you have constraints. And that was my constraint.
So, yeah, so that was: we have Vagrant. We have this failed infrastructure project. We have sort of my boss at the consultancy getting me into infrastructure. And then, I mean, externally, we had the cloud being introduced. AWS. I went to school at University of Washington. So,
Oh.
I was right there.
Right in the epicenter of it. Amazon was next door, right?
Amazon very next door. They donated a bunch of credits. Right away, I knew about the launch. Most of the CS students at UDub interned at Amazon, not necessarily AWS, but also including AWS, but all over. Armon interned at AWS. And so, I was in the bubble of like cloud, cloud, cloud, AWS, AWS, AWS, when people were pronouncing S3 like "S cubed." Like, people didn't know how to pronounce it, right? That's how new it was. And so, yeah, all this stuff kind of came together and kind of led me on the path to build tooling to better manage it.
At that moment in time when you saw cloud, you know, you saw it was being big, did you know or have a conviction that it would be big, or as big as cloud had become? Because I'm just trying to put yourself back. Like, this was very, very new back then, right?
Totally. Yeah.
And I think, you know, if I imagine, I assume more people would have been skeptics or think that it's just a fad or whatever. What was it like? Can you bring us back a little bit there?
Compared to today, it was very unpolished, I guess, is how I'd describe it, you know? Like EC2 was, I mean, AWS in general was very unreliable. S3 was the only ever reliable piece. Everything else was totally unreliable. And there were only a few services; like EBS didn't even exist when we started. So, there was no durable storage besides S3 when I first started with it. It just felt very raw.
And I never really viewed it as "this is going to be big." I mean, eventually I thought it was going to be big. What I viewed it as is: this is the better way to do it. This feels like the better way to do it. Just, yeah, at a base level. Like, whether this wins or loses in the realm of markets and social popularity, I don't know, but this felt good. And so, that's what kind of pushed me towards it. And I say this all the time: I'm really motivated by what's the most fun and what feels right. And it just felt right to me.
I think where I started making the bet, me and Armon both started making some kind of bet, was not just when we started HashiCorp, but we started HashiCorp on the basis of multi-cloud. And I really like to contextualize that at the time we were starting this, which was like 2011, 2012, AWS was huge. Azure didn't really exist and Google Cloud didn't really exist.
Google App Engine, right? It wasn't even cloud.
Correct. Correct.
I used to use that when it was App Engine, yeah.
Yeah, yeah. And so in that context, as we were pitching these cloud-agnostic tools, I mean, we got a lot of raised eyebrows, being like, "This is a waste of time because AWS is the only player in town." And our conviction was, at that point, cloud is going to be huge, and anything that's economically huge, other people want a piece of that pie. And so, you're not going to just have AWS. It'll be huge, but you're going to have these others pop up, and Microsoft is not going to sleep on it, and Google's not going to sleep on it, and who knows who else, and who knows. And that was our conviction. That was our bet. And it mostly played out that way.
So, when you decided to start HashiCorp, you had Vagrant. Was the idea to, you know, invest in, commercialize Vagrant? And did you go out to raise money, or did you start doing it with, you know, bootstrapping? How did that go?
It wasn't to commercialize Vagrant. So, what we had done is Armon and I both worked at this mobile ads startup. There were like less than 30 people, and we had built, with Python and C, these really rough prototypes of these ideas that I had in this notebook, of like service discovery and an early version of Terraform we called Launchy. We had DNS-based service discovery by connecting an off-the-shelf DNS server with Postgres, and we did all these hacky things, but they felt good. And again, we get back to how things feel to me to motivate me. It felt right, directionally right.
I graduated. The environment in Seattle was not very startup heavy at the time. It was basically everyone was like, "Are you going to work for Amazon or are you going to work for Microsoft?" Yeah. That was kind of the end, and to a certain extent Facebook was starting to show up up there, but that was it. I knew I wanted to work for startups, so I moved to San Francisco. So, I moved to San Francisco, found a startup that would hire me, which was a mobile ads thing, and just wanted to learn. So, that's the short step there. So, I ended up in San Francisco.
And Armon was actually going to do a PhD at Berkeley, and he was accepted, and this was a huge deal. Huge deal. I mean, incredible program, and so he was going to go there, and he would have done amazing things there, but I convinced him to join this mobile ads startup. He actually took a year deferment on the PhD. He's like, "I'll give it a year.
Yeah.
I'll join this mobile ads
And I'll go back to Berkeley for sure.
If it doesn't work out, I'm going to go back." And what ended up happening in that year is now what we get to. Which is that we had this hotchpotch of prototype tools that felt right. And we were going to all these little startup mingling parties. You know, things like GitHub drink-ups, but also just like, this is such a San Francisco thing, and that's why I think, even though I don't want to live there again, it was so magical at the time, was like, across the street was this company that was called Zimride at the time. Ultimately became Lyft, and they invited us over to get drinks and have pizza to demo this new app with a mustache that didn't have a name. And so
Wow.
Yeah, so stuff like that.
When it was born.
Yeah, yeah, yeah. And that happens all the time, like all the time in San Francisco. And it's not unique to me at all. Like, yeah, there's a bunch of stories there that I think aren't worth going into. It's just, it's fun, but I went to all these things and people would just talk. They're all a bunch of tech guys, right? And you'd be like, "What are you working on?" And there are two things I realized. One is all these companies are cloud first. They're all just adopting AWS first. There is no dedicated
This was like in 2011, 2012 or so. Like, they just went and paid for cloud, which was brand new, right? The previous generation just had on-prem. I remember people had server rooms and server admins. They had roles for those. All that jazz.
That was just gone. Gone. Like
That must have been a massive shift.
I literally can't think of one social event I went to where there was somebody that had dedicated servers. The only one is very Twitter.
Yeah, yeah, but I think we probably have to emphasize that this was a massive shift in the industry, right? And it probably was only happening in Silicon Valley, or like
Probably. Yeah, probably.
Well, what about everyone else?
At a scale that was larger than anywhere else, it was probably in Silicon Valley. The joke used to be, because AWS was so unreliable, the joke used to be that when AWS went down, all these startups finally became more cash-flow neutral.
[laughter]
And they would lose less money. So, there would be a huge, you know, US East outage, and everyone would be like, "Are you going to migrate regions?" Like, "No, we're saving money right now."
But yeah, getting back to it. Everyone is cloud first, cloud born, cloud native, whatever you want to call it. And the other thing was they were hitting all the same challenges that we were hitting, and they didn't use our tools because they were just internal prototype tools, but
Yeah.
But I knew that our tools felt good. So, I had these two things come together, where I had some ego, some hubris, where I'm like, "I'm pretty sure we're building the right thing," along with "I think the industry's moving in that direction," and we could come together. And so, that led to: let's start a company based around that.
The fact that I had Vagrant was more like industry respect. I mean, Vagrant wasn't that big then, so that's not saying much. But I just had some foundation publicly to give some credibility to head in this direction. That was about it, and we started HashiCorp.
And then when you decided, you incorporated, you know, got the things, did you decide to raise money? Because again, back then I guess it wasn't as much common wisdom. You know, Y Combinator was probably starting around that time. So, were startups a big thing, or was it a given that, okay, if you start a startup, you're going to raise money?
In my social bubble, it was pretty much a given. And not just that. We incorporated. I self-funded. I transferred $20,000 from my savings account into this corporate account as initial funding, and I worked off of that. I paid myself $0 for the first 6 months. So the 20,000 was purely towards whatever things the company needed. That was the first 6 months. And then Armon joined after 6 months, and we decided to raise.
And the motivation there really is there weren't many other options. There were basically three options as I saw it then, which was bootstrapping, right? Just build something, make money, and as it becomes affordable, continue to grow, reinvest, and grow. Bootstrapping, VC on the other side. And then in the middle was what I call patronage, which was not like Patreon-style stuff today. That infrastructure didn't exist. There was no subscriber/donate type infrastructure then. Patronage was more like you might be able to convince a company like VMware to pay your salary for you to work on some idea. And the best example is Redis at VMware.
And yeah, we kind of laid out this plan that we wanted to do, which at inception of the company included Terraform, Consul... No, it included everything but Vault. Vault came a little bit later. And we looked at that and said, "If we bootstrap this, even if we hit it out of the park, this is going to take us like a decade just to build the software, and that's in the best-case scenario." This is just going to be slow, and the problem with slow is that things have a window, and cloud was growing so fast that if we were that slow, someone else was going to do it their own way. I mean, I guess that was the primary issue. We really just wanted to go fast.
You knew you needed to.
Yeah, we needed to hire many engineers right away and start building right away, and so VC was the route we chose.
Can you talk us through the first several products and what they do? You know, we know Vagrant, but just for those who are less aware of what became the HashiCorp stack later, right?
Yeah, let me see if I can still get these in order. I'm pretty sure I can. So, Vagrant predated it. The first product that came out of HashiCorp itself was a product called Packer. Kind of understated publicly, but it kind of underpins a lot of things in the industry to this day. That's an image-building tool. So building Amazon images, VMware images, etc. I'm not even sure how much publicly came out, but there are whole multi-billion-dollar cloud platforms where all of their official images, the service images, are built with Packer.
Everyone was trying to utilize this horizontal scaling, auto-scaling nature of AWS. That was the dream. And it's kind of like the, what do they call it, cold start problem with serverless today. If you were waiting tens of minutes for your server to be ready, you couldn't react. And so my idea was: do that, snapshot the image, and then next time just spin up that image. And so that was Packer.
That was Packer.
So Vagrant, Packer. The next one that came out was Consul. Consul was solving the networking problem, and not networking, it was more solving the service discovery problem, which was: you have all these machines coming and going. Before, again, to contextualize this, you would have a static set of machines that had IPs, and you would probably use DNS or something, but the IPs didn't change that much. So, you could be like, "Oh, my database is here and it's not moving." But if you're in this world where web servers and load balancers and databases are just breathing, you know, that's how I always describe it, breathing, they're creation, destruction, creation, destruction, constantly, then things are happening at a scale where the service discovery needs to be much faster.
And not just faster, but you want to have better guarantees that when you get a response that, oh, it's at this IP address, that IP address is ready. Yeah, I think this is also kind of more mainstream now with Kubernetes readiness checks and health checks and things like that. It was bringing that to more physical servers or cloud servers, virtual machines, and things like that. And so, that was Consul.
Then after that, I think we did Terraform. Terraform spins up infrastructure as code; describe your infrastructure. In AWS parlance, it was things like all the attachments, you know, your EBS volumes, gateways, VPCs, subnets, and connecting them all together. The idea was I wanted to have an empty AWS account, or any cloud account, and I wanted to have this text, and I wanted to say "make this text reality," and that's what Terraform is. And you would wait whatever amount of time it took AWS, and you would blink, and you would have thousands of resources. And then, with one command again, you could just tear it down to zero. That was Terraform. So, that came out like 2014. So, that was the next thing. And then was Vault.
Yep.
Vault is the easiest to describe. It's secrets management. Yeah. It is core.
Secrets management and encryption; it grew to do a lot more things, but that was
So, it's like, well, on your local developer machine, you have your environment variables, and doing that at scale, at a team level, at a company level, services need to access all this stuff securely.
Yeah, it was much more focused on the production environment secrets. I had dreams and visions of really solving the developer secret problem, but Vault really never did that well.
Mitchell just talked about secrets management, which turned out to be a pretty important focus area for him. In general, security is both very valuable, but also pretty hard to do well. This leads us nicely to our season sponsor, Sonar. Looking at where we are today,
We've now moved past tab completion into the era of generative AI. Autonomous agents are opening pull requests. One big question: how do we get the speed of AI without inheriting a mountain of risk? Sonar, the makers of SonarQube, has a really clear way of framing this: vibe then verify. The vibe part is about innovation, giving your teams and your AI agents the freedom to build and iterate at high velocity. The verify part is the essential automated guardrail. As agents start contributing more of our code base, independent verification that checks every line, human or machine generated, against your quality and security standards is more critical than ever before.
Helping developers and organizational leaders get the most out of AI while ensuring quality, security, and maintainability is one of the main themes of the upcoming Sonar Summit. This isn't just a user conference. It's where devs, platform engineers, and engineering leaders are coming together to share practical strategies for this new era. I'm excited to share that I'll be speaking there as well. If you're trying to figure out how to adopt AI without sacrificing code quality, join us at the Sonar Summit. To see the agenda and register for the free virtual event on March the 3rd, head to sonarsource.com/pragmatic/sonarsummit.
And with this, let's get back to HashiCorp and why the company decided to raise 6 months after founding.
But, yeah, it's just basically like, yeah, where do you store your secrets? And the secrets were not just — I forgot the words I use to describe this, but secrets were not just like passwords, but it was also like PII. So, how do you protect emails and addresses and stuff for your customers?
Or credit card numbers.
Credit card numbers. So, Vault was core to all of that and it continues to be.
That is hard to build. Something like that.
Yeah, we were really scared when we built that actually, 'cause we kind of hid the fact — we never lied about it, but nobody on the team that built Vault had more than one quarter of undergraduate security experience. There were no professional security engineers from industry, there were no professional security academics, and yeah, we built it. We got a lot of audits because of that. Like, we were scared, so we did get a couple — for us it was very expensive as a startup. We paid a couple firms tens of thousands of dollars for Vault 0.1 to audit it. We paid two. We shared the early beta with a lot of people who were security experts in order to review it, not publicly, just privately. We got a lot of good feedback. But yeah, we didn't want that exposed in a sense, so...
Yeah, I understand, but I mean it kind of validates that you can build good stuff with, I guess, people who might not have the experience, but I guess people were learning, right? Like...
Yeah, the security stuff ended up — we really quickly hired professionals that helped the product, and the security stuff was always pretty solid. But I think what it really showed was what the security industry needed was a shift in user experience more than a shift in like what it did. 'Cause like what we were doing was not fundamentally different than existing multi-hundred-million, billion-dollar companies that already existed, but the experience, the way you interface with it, was dramatically different. And that was, I think, a good example of that, yeah.
And after Vault came...
Nomad.
Nomad.
Yeah, Nomad, which was our scheduler, which was a couple years late to the market, yeah.
What was — you say scheduler, was it not an orchestrator?
I always described it as a scheduler.
What did it do?
Simple thing: you have a pool of compute. It finally solved that problem that we had in undergraduate. You have a pool of compute, you have an app that has a certain set of requirements, and it needs to find a place to run it.
Yeah, the undergrad problem we talked about. And as you're building out these — you said some of these took years. Like, how did the business, like HashiCorp as a business, work? Like, did you start to generate some rev...
There was no business.
There was no... So, all right, tell me about this one.
Yeah, I think we waited too long to develop a business, but for 4 years there was — there was actually revenue from a couple of random sources, but there was no real reproducible growing business.
So you were just building this vision of the founders' vision of like, all right, we need all these things that would have taken like a decade bootstrapped, let's build it.
Build it in 5 years and figure it out.
That was literally it.
Yeah, that was literally it. And, you know, it was all open source, and I always had this mentality, which was like, if the company fails, it doesn't matter because if they're good ideas, the open source community will just continue. And so, I don't think I would ever tell that to my investors at that time, but, you know, I had this idea, which was like, the technology was the most important thing to get out into the world. The business, I really sure hope we could figure it out, but it's not the most important thing.
And for those engineers who are thinking of becoming founders or, you know, might be founders, how did this work with your investors? You know, when they put in money, like, did they get some board seats? Did you have to manage expectations? 'Cause I'm hearing, just putting a bit of my business hat on, is like, you know, for 4 years you're building these cool things, you don't exactly have a business plan. How did that work? Or they just believed that eventually you guys will figure it out? Or they saw some kind of traction with, like, open source?
It's traction. And I don't think what we did was atypical for Silicon Valley. So, the really broad hand-wavy way I like to describe it is, you know, your seed is about building the product. You don't even know if there's product market fit. You're making educated guesses, but you're building something. Getting the A, you've sort of proven hints of product market fit, but you definitely don't have it yet. You've proven hints. And then when you get the B, you've proven product market fit, and now you haven't really proven, like, repeatable revenue. You now have hints of revenue, but you know the product is useful, you know people like the product and want to use the product, and maybe want to pay for the product, but you don't know exactly how to get everybody to pay for the product. And then C, D and so on is just continuing to build the repeatable revenue machine.
And so with that framework in mind, we were on the right track. It was basically like build the product. We had clear product market fit by the A in terms of the open source, right? We had millions of downloads, a lot of stars on GitHub, all sorts of signals that showed that this was resonating. We had zero revenue. And so, you know, it was raise money and slowly, slowly get closer and closer to solving the business problem. And I think we were just a year or two late, or later than the average startup, but the general keyframes were the same, just on the slightly wrong timeline, I guess.
And then when you decided to do a business, you already had the Hashi stack and then you built managed offerings, if I remember.
Yeah, our first foray into commercialization was a total failure. We had this product that — you would have to have been a die-hard HashiCorp product fan to know this, but we had this first product that was called Atlas. And the idea was commercially shipping the vision of running all the products. And so, you know, there's a couple death nails there. One of them was that you had to run all the products. And so if you were just like a Vault user, you had a really impossible time buying, or buying into, our commercial product. And the second was just that it was just a huge problem to, like, attach onto. And regardless of the adoption required, you're trying to solve the problem that multiple different buying organizations in a company were fighting over. So like even the people who had adopted all our tools, we ran into the problem of who pays for it. It wasn't as simple as engineering paying for it. Correct.
And one of the lessons that I would have, you know, I would have for engineers that become founders that don't have a business background — one of the tough lessons I had to learn is that companies will want to pay for software, but they will fight over whose budget owns that.
Budgets are important, right?
The budget has to exist, and if it looks like a networking problem, they're going to say, "Oh, networking should pay for that." So I have more budget to buy my other toys that I want.
Or I can hire more people, or I can have all this stuff.
Yeah, it could get broken down into like vendor budget. It could already be earmarked for external purchase, but yeah. So, we had this product that was like: do the security people pay for it? Do networking people pay for it? Do infrastructure people pay for it? Like, does dev tooling pay for it? Like, where does this go? And it's just that Spider-Man meme where everyone's pointing at each other. Ultimately, you don't sell anything. And so, that was a failure for that reason.
So, I don't remember the total time we chased this down, but we had a board meeting for sure on a Friday, and board meetings are usually on Fridays. And we had the meeting — we're based in the city of San Francisco. Board meetings were an hour south in real Silicon Valley. And it didn't go well. There was no yelling. There was nobody saying, "You guys are messing up." There was nothing like that. It was just — the way I describe it is when your parents aren't happy with you, but they don't have to say that they're not happy with you. You know, but you know they're not happy with you.
We had this board meeting. We drove home. Armon and I — the complete drive home was silent. And it's Friday night. So, usually what we do is we go straight to — Armon lived in the city, and I lived in LA already, but we'd go straight back to Armon's place and just, like, have a glass of wine, debrief, talk through things. And we didn't talk on this car ride home. Armon drove straight to the office. I didn't question that. We went into the office, sat at a table not much larger than this. The only difference is there would be a whiteboard here. I think one of us at that point said, "Well, that didn't go well." We both knew it. We didn't feel good.
And the sequence of events here is now very fuzzy, but at a certain point we decided, "Let's play this experiment where if there were no sunk costs, if we were starting from scratch, what would we do differently today?" We whiteboarded all this stuff. What we whiteboarded out was per product, enterprise products, and doing Vault first, and all this stuff. We wrote it out. Spent some amount of time there. It's still Friday. It might be Saturday in terms of the time of day, but it's still Friday. I think it was Armon who looked at the board and goes, "Why don't we just do that?" Like, why not? And I was like, "Yeah, why not?"
So, we decided over the course of that weekend to just throw it all away. Just throw everything we were doing before away. We had two paying customers. We're like, "Just breach contract, I don't know. Like, figure it out. Like, get out of it. We're done." And we convened an all-hands meeting on Monday. Probably only about 20-30 people in the company at that time, but we convened an all-hands meeting over Zoom. I mean, we might not have used Zoom then, but whatever video chat. And we said, "Okay, we're switching directions. We are now enterprise as our customer, open core, per product." We would have this open source, and we would have a forked version internally that had closed source features. It was a fork, but yeah. Open core business model.
Armon and I thought people would quit. Like, we thought we would lose like — we didn't have an exact number. We thought it would shatter some level of confidence and, like, "Wow, these guys have no idea what they're doing." And we didn't have any idea what we were doing. And you know, yeah, open core even then had a bit of an icky taste in people's mouths. And so, like, we thought people would just philosophically quit, being like, "No, I came here to work on open source. I'm not going to do open core." Enterprise was kind of just like a boring thing. There were, like, multiple facets of why people might quit. Nobody quit. The vibes in Slack were amazing, super positive.
Oh, what happened? Do you think, like, why? People...
Yeah, we asked about it in one-on-ones and follow-ups. We asked about it and it was really like everyone was kind of just buzzing that we had a clear direction and a conviction. And you know, there's fear of the unknown, but before there was this feeling of like we're just throwing darts at the wall and doing this thing and we don't know exactly who our customer is. And there was all this uncertainty in a different way. And now it was like, we don't know if this will work, but at least we're just going to sprint towards this. Like, there's these clear things, which was, like, definitely enterprise, definitely open core, definitely Vault. Like, all these things were set in stone that gave us a different set of certainty that suddenly the company was like, let's go. So yeah, nobody quit. It went super well.
And I don't know the time of year, but it was like in the fall. We built Vault Enterprise by the new year. Within, like, the first quarter of trying to do sales, we could just, like, tell that it was different. It wasn't, like, obviously successful yet, but just the caliber of conversation we're having, the distance we're getting in the buying process, and the speed we're doing it, it just felt different.
And what was it, from the old approach?
Yeah, I mean part of it just comes down to, like, the classic startup, like, listen to your customer, and we should have listened from the beginning 'cause our potential customers were screaming at us to do what we ended up doing, which is — we would give these pitches about adopt all the products and buy this kind of thing, and there were so many meetings where someone would be like, "Okay, I'll think about that, but how do you replicate your secrets in Vault?" You know, they would just, like, ask these questions where if I was just listening — I was so blinded, a lot of us were blinded, but I was so blinded. If I was just listening, I'd be like, wait. A lot of people are asking about secrets replication. And that's an at-scale problem. Maybe we could close source that, right?
Like, that's what we ended up doing. That was our first feature with secrets replication. Not even across data centers. The first feature was just like a cluster of Vault servers in a single region. You would sell this more focused product, but now, kind of the problem from earlier, security was definitely the buyer. There was an obvious budget, obvious person you were talking to. There was a feature that resonated with that scale. And so, we were just having much higher quality meetings in terms of getting this done.
Mitchell just talked about how HashiCorp managed to build a product that enterprise customers cared about and wanted to buy because it resonated with their scale. This brings us nicely to our presenting partner for the season, Statsig. Statsig offers engineering teams the tooling for experimentation and feature flagging that used to require years of internal work to build and is especially important at enterprise scale. Here's what it looks like in practice. You ship a change behind a feature gate and roll it out gradually, say to 1% or 10% of users at first. You watch what happens. Not just did it crash, but what did it do to the metrics
you care about? Conversion, retention, error rates, latency. If something is off, you turn it off quickly. If it's trending the right way, you keep rolling it forward. And the key is that the measurement is part of the workflow. You're not switching between three tools and trying to match up segments and dashboards after the fact.
Feature flags, experiments, and analytics are in one place using the same underlying user assignments and data. This is why teams at companies like Notion, Brex, and Atlassian use Statsig. Statsig has a generous free tier to get started, and pro pricing for teams starts at $150 per month. To learn more and get a 30-day enterprise trial, go to statsig.com/pragmatic.
And with this, let's get back to the episode and what came after they built Vault.
And I get asked on the open source side all the time, but these buyers, like corporate buyers, do not care at all about open source. They don't care at all. Like they need a commercial agreement. And so, the closed source nature of it, like some people needed legal protections around like code escrow in terms of downtime and stuff like that. That was about the extent of it. Otherwise, they were like, you know, we need support, we need proof of concept, proof it works. We need some white papers in terms of like other customer scale, blah blah blah. And yeah, that's what we had to build up after that and get going.
And then so you started selling with Vault and then you did it for the other products as well, right?
Yeah, we did Terraform and we did Consul. We had it for all the products, but, you know, all this data's public. You could look at it and they... Well, for a period of time it was public. You could look at it in like the public reports of when HashiCorp was a public company. You know, it really broke down to Vault, Terraform.
One thing I remember is Terraform just became so, so, so popular across the industry. So like, you know, there's a Hashi stack, but I only later learned that all the other parts existed because Terraform just seemed to be everywhere. Why do you think that sudden popularity was?
It's so funny to hear that because I accept and know that now and I feel the same way that you feel now that Terraform is this huge thing, but for the longest time, we were the background company. Like all the other tools were... no one knew the other tools. And not only that, like Terraform... One of the things that kind of frustrates me, I haven't heard it recently, but for a period of time, one of the things that frustrated me was like, "Oh, they only won because they were first to market." I hear that a lot and we were like seventh to market. Okay. So, like
To market in what category? In what product?
That infrastructure as code space, in your perspective.
So there were like other players who, you know,
So many, yeah. And no one was a clear winner. It was a warring market, but that first year, 2014, when we came out with Terraform, at that time one of my marketing strategies was I was at every conference. I traveled an obscene amount. I was speaking wherever I could, but even if I couldn't speak I was going just to talk to people.
And there's actually a little anecdote here, which is when the COVID lockdowns happened in March 2020, my wife and I had nothing to do, and we didn't have kids yet, and we opened up our calendars and we realized that we had been dating since 2012 and it was the first time in almost 10 years of our relationship that I will have been in the same place longer than 8 days.
No, for almost 10 years... for 9 years straight I had been somewhere different at least every 8 days.
That's how much you traveled?
That's how much I traveled, yeah. And I know there's consultants that travel a lot more and stuff, but I was traveling a lot, I was coding a lot, I was doing all these things.
Did you also code a lot while you traveled as well?
All the time, yeah. I had a whole system. When I started traveling, in-flight Wi-Fi didn't exist.
Yeah, exactly. Even now it's kind of patchy.
Yeah, so I wrote these scripts that I ended up iterating over, where I downloaded all the GitHub issues and I categorized them and I would just break it down into tasks that none took more than 10 to 15 minutes. And I just created this list, and when I was on the plane, I would just one by one bust them out. There's no internet, so just commit them locally.
Yeah.
And then I would get back, and some people used to notice this because I would land and you would get this push and people would get these email notifications where like 30 issues were closed all at once.
Wow.
The key was pre-planning what issues you were going to work on. I did that online, on the ground.
Yeah.
And then breaking them down into 15-minute chunks because I found it was really hard to get into multi-hour... Even when I was traveling to like Japan or something, it's really hard to get into multi-hour flow on an airplane. So, I was like, I'm only going to work on the stuff that isn't heavy design work. None of that. It's just like bug fixes, right? Just cleaning stuff up. And so, that was my process.
In 2021, HashiCorp went public. What is it like to go public, both in terms of preparing for it? How did it feel? What changed after?
On the prep side, I don't have the full answer because I also stepped down from the executive team about maybe 6 months before we went public. So, I was part of some of the planning and I was very aware that we were planning to go public, but, for example, I wasn't part of the roadshow or any of that. But, yeah, you know, from my seat, the parts that I was part of, the parts that I had visibility into...
It takes over a year to do it. So, there's a lot of prep, and there's some funny things that you do, like you start running like a public company at least two quarters before you're public. I don't remember what the drop-dead date is, but there's a date where you could just cancel going public. And it's pretty close. Like it's very close to when you actually have that day. So, you kind of run like a public company, to the point where you do mock earnings calls.
Like you actually, with a conference room table, your investors are the public investors that aren't in the room. They go somewhere else and they talk over the speakerphone and ask you the types of questions. Your CFO or VP of finance gives the full report of the quarter. They try to frame the types of questions again, and you run it and you try to figure out whether it's running well enough, I guess. And that's sort of what the prep feels like.
And there's an obscene amount of secrecy because from a regulation standpoint, you can't talk about any of this. And so, I mean, you could look back at even the dumb stuff like Hacker News comments. Like I just went radio... it's the clearest signal that a company is going to go public, because I went radio silent on every topic because everything became questionable. I remember there was just a point, because there was a Hacker News comment I gave like 8 months before it went public. And our general counsel, in the middle of the night, was like, "You have to delete that." After he talked to me, I was like, I could see how that might affect things, but I didn't realize it would matter, and I ended up deleting it.
And is this because you're not supposed to give public information away or something like that?
I don't remember the exact regulation, to be honest.
There's some regulation about like not leaking
It's not
information or
It's not really... I mean, it is all information, but it's more about you can't influence the market in any way. And so, yeah, and you can't make promises, because if you say we're going to go public, it might cause even private funding to froth up, and it's a form of fraud.
So, yeah, basically I just stopped talking about everything. I don't know how seriously other people take it, but I took it to the point where I planned this trip to New York to go public and I invited my parents and I didn't tell my parents why we were going to New York. And I just told them, "I want you in New York. It's really, really important. It has to do with HashiCorp." And they were like, "Sure." And I said, "I can't tell you about it." And they're like, "Sure." And I told them maybe a month in advance. We had a dog, we had to get our dog sat by my aunt. And I just told them we're going on a family vacation up to the point we left. So, I didn't tell... Nobody except my parents knew, basically. None of my friends, nothing, except the friends I worked with at the company. But, yeah, that's what it's like leading up to it.
Yeah, I was at Uber when we went public. And then previously I read that a while before going public, VMware made an offer to HashiCorp.
Way earlier.
That was like super early days.
Like 2 years into the company. We went public like 10 years into the company. So, yeah.
Yeah. So, when they tried to buy you, what was it like? Did you almost sell at some point? Was there any point where you were close to potentially selling?
It felt close. And I got a lot of accounts afterwards that it was very close. It came down to like one vote on the VMware board, is what I heard. About 2 years into the company, we were only three employees, including me and Armon. So, we had one employee, I guess. Are two founders employees? Three of us.
We got approached by VMware. You know, I didn't know what this would be like. And what it isn't is they don't show up and say, we would like to buy you.
I know.
No.
That would be too obvious.
The way it happens is you get an email from some low-level business development person that wants to just talk vaguely. And the vague talk is they're not interested in buying you. One of the jobs of BD people at large companies is just to have an understanding of the ecosystem. So, it's really just like, let's have an understanding. They might have had an executive tell him or her to go talk to this company. There might already be an executive kind of poking around, but yeah, so it kind of starts out that way.
It turns into, would you like to come by our offices and meet in person? Oh, our VP of engineering swung by. Let's talk to him. Nice to meet you. Well, that's in that. Then I think this is like our actual timeline. And then I think there was a dinner where there were three VMware executives at the dinner. At that point, we thought they might be interested, but it was still so much dancing. So, this is months before there was even an offer. It was still so social. Like we drank, we talked about our hobbies and interests, and very basic about tech. It's really more vibes. They go to dinner.
And then it started to get more serious. We spent more time in Palo Alto at the VMware offices, where we started talking about partnerships. About how can VMware help our products more? And it starts about partnerships, and then it turns into, hypothetically, if you had the resources of VMware, what would you do? You know, we're like six meetings in at this point. There's no offer of anything. And then at a certain point, honestly, we were getting tired of it, because nothing was happening anyway.
Then you're a startup and you're going to all these meetings and
Oh, and I don't even live in the Bay Area. So, I was flying up all the time. It was a waste of time. And to a lot of founders, that is the warning I give them: M&A becomes a waste of time. So, I have another
M&A, mergers and acquisitions.
Mergers and acquisitions becomes a waste of time. So, I'll tell you another anecdote after this, but ultimately, we kind of politely had the "Okay, let's... or get off the pot" kind of conversation, and they put an LOI in front of us, which is a letter of intent. The LOI was one page. You know, it's basically a semi-binding promise that we're pursuing buying you. No number on there. It's just kind of vague.
No number?
Yeah, well, verbally. But they're not writing anything down. They're not putting anything in email. None of that. It's just verbal. And so, at that point, verbally, we had gotten a drop of $20 million, which
doesn't sound that much.
Well, yeah, but we're
What? Well, what's the three
years old.
Oh, yeah, the three of you, 23 years old.
Years old. Me and Armon together own 70% of the company.
Okay, yeah.
Yeah, you know, it sounds interesting, to say the least. But what I tell people is you start thinking about the things you will buy. That's the dangerous path. That's where it happens. And we had advice from people who said it's phenomenally too low, like wildly too low. So, go ask much higher. And we asked... I don't remember anymore, but we asked for maybe like 40 or 50 or something, and they just said yes. They said, "Okay." And then you know it's way too low.
And that was verbal, too, so there was nothing binding about that yes. It wasn't like yes, it was more like, "Okay, we'll work on that." You know, but very positive.
Yeah, that's a bit like in this indirect... It's an indirect
Indirect business sense. An indirect yes. And it turned into, come meet the CEO of VMware. You know, clearly they're interested because we're climbing still. Armon and I kind of started getting cold feet because the way we described it is it's a dream-killing amount of money. It's like you would take the money, but you're too small to be important to a company like VMware. So they're going to just
Because even though it's so much money
Personally it's so much money.
You know that at VMware's level, I guess you see the revenue there and all that, you realize that for them it's not a big deal.
It's meaningless to them. Yeah, it's meaningless.
That messes with your mind, you know?
Yeah, so it becomes a thing where personally your life could change. But this thing that we both were truly passionate about, the thing I wanted to work on more than anything else, would end in a sense, because, you know, I would probably get thrown into working on ESX or something, you know, and
You would get a manager at VMware, you know, not even the CEO.
The executives make it sound like they're going to do all this stuff with your products, but that's just one executive, a cog in corporate machinery. So we started getting cold feet, being like, if they're interested, maybe we're onto something. If we're onto something, do we want to sell out early, and sell out in a way where our dream dies? That's why I called it a dream killer. Armon, very maturely, and he's 2 years younger than me, so he's 21 at the same
No, he sounds like the older one.
Yeah, he's very mature. And Armon very maturely came up with the... I forget where it comes from, but the risk minimization, not risk, the regret minimization framework. He was like, "Personally, on your own, go think, and I'll do the same, and let's come up with a number that if we walked in the next day and they said, 'We're killing everything. You're going to go work on ESX for the next 4 years,'" because we were going to have a lockup no matter what, "'you're going to work the next 4 years,' that we would be like, cool, this was worth it." Like, what's the minimum regret number?
We came back, and I don't remember exactly what our numbers were, but they were pretty close, and we ended up at 100. And so we're like, it felt so wrong. How could we possibly ask for 100? But we said this is what we're going to do, and we stuck to it. So, we went back. We asked for 100. And it wasn't a no. And it wasn't a yes. This one had
a lot more hesitance. It was a lot more like, "We'll get back to you." All right? Like, I don't know. But it wasn't a no. And basically, they came back to us and said, "This requires board approval." So, we're convening the board meeting next week. Like, unplanned. That's not when their board meeting was. Like, convening the VMware board. We're going to vote on this. And then we heard that the vote didn't pass. That was that.
It's just crazy how such small things could, you know, influence. If that was an extra yes, who knows what your story would have been. You might have been
You might have, you know, like it's hard to put, you know, in VMware, you might have been clogging away on like this project.
I mean, we didn't build Terraform at. So, Terraform
Terraform might have not been
Probably never would have existed. I confidence I know who the vote was. I know why they voted that way. Like, I know a lot more details, but it's like it worked out obviously in my favor, but yeah.
So, you've left HashiCorp and you're independent, and one thing cool about being independent is you're just very honest about stuff, and there was this really interesting thread on Twitter where you wrote about it. You said like, "Ask me anything about the big cloud providers." Because at HashiCorp, you work with all of them. What was your experience back then of, you know, like Azure, AWS, Google Cloud, like your kind of honest view of how they worked back then, and possibly how have your views changed on them?
The precursor to that is while I was at HashiCorp I always had to be very careful about what I said about any of the cloud providers because we're partners with all of them. We're partners and I didn't want to insult anyone and so I was just very professional about all the relationships and then like
We like all of them, like
Yeah, or just say nothing.
Or just
If you have nothing nice to say don't say anything at all. And then I left and I kept that up because it was too close, I was still flying too close to the sun as they say. And then after time passed I was like, yeah, my opinion doesn't really matter. And so to answer your question, my broad view of all of them was that AWS was really arrogant. Annoyingly arrogant is how I'd describe it.
And then when you say arrogant, can you help us understand how you worked with them or what part of them, or is it just general, or like
Yeah, I'll start by disclaiming this though, that we worked with so many people there that there were individuals at all of them who are awesome and nice and kind. And so I'm not trying to make individual judgments here. It was just more of like how all of it came together and how it felt as a whole. So by arrogant I mean it always felt like they were doing us a favor at every turn in terms of partnerships, in terms of just getting a meeting with them. It always felt like you should be thankful that we're spending time talking to you. And not just that, but also there was always this subtle vibe of like, we will just spin up a product and kill your company. You know, it felt that. No one ever said that. Well, it kind of got to a point where it was sort of like, if we don't come to terms we're going to build this service. It did kind of come to that.
But you know, we did see that later on with Elastic and
That had already happened, that was the
Oh, that had happened already.
Yeah, just not with us but with other companies.
But with OpenSearch.
Yeah, and they always publicly spun it as like, oh, it's so great and builds the ecosystem larger and we're doing it by the letter of the license, and, you know, all has truth elements to it, but it's still not a nice thing.
No, I think people paying attention to open source didn't appreciate what Amazon did with a lot. It really hurt Elastic's business and it showed how open source can be weaponized against a company that spends, you know, their blood, sweat, and tears. And I guess, you know, HashiCorp got the same thing, right? Because you were publishing permissive... Well, I mean, open source needs to be permissive.
It was MIT or MPL license, so yeah.
Like Amazon could have spun up anything they wanted. Yeah.
There was like a 2-year period where I think for the entire 2 years, the entire leadership team was terrified that at any moment there would be like a Vault service or something that would pop up. And so, yeah, that's sort of my characterization of AWS. It really took, for example, teeth running to get them to help with the AWS Terraform provider. I don't remember the exact number, but we had something like five full-time engineers employed working on only the AWS provider for Terraform, which, you know, maths out with full benefits and everything to like a million dollars a year.
Yeah.
And all of that was pure open source, pure integration with a commercial entity, and they were not helping us at all. And they were the last of any of the cloud providers to provide any sort of help there, and it came down to some drama where we went to a meeting and basically said that we're going to publicly say that the AWS provider is deprecated. And we're done. Like, the community could pick it up or whatever, but we're going to
Yeah, because you didn't get any help from them.
Yeah, and it's taking them twice as long and there's too many bugs, and honestly AWS is shipping features too fast, and it's just not worth it. And that freaked them out. And finally, they started helping. You know, they might recount their side of things differently, but that's pretty much it. It felt like no movement for years, and we said that, and movement started happening really fast. So, yeah, there was that.
Microsoft, I have the most positive view on Microsoft. They had a really hairy technical product is how I'd describe it. It was very difficult to use.
Azure?
Azure, and a lot of nouns, like principals, and I still to this day, and I integrate with Azure, don't fully understand the IAM hierarchy of Azure. I just kind of bolted it and got it working with a team, and that was that. So technically, kind of, but from the business side, super competent professionals and team players. That's how I'd describe it. We went into every meeting with them, and in a lot of our meetings, the first question was, how do we both win? That was like the first question, and yeah, very pleasant. Awesome. They were the first people to jump on board supporting Terraform. Sure, that's some kind of bias, but they were consistent throughout the years. So, positive on Microsoft.
And Google Cloud, you know, Google Cloud in general, it was always like the best technology thing, most incredible technology and architectural thinking, and I swear it felt like none of them cared or thought about the business at all. It was like every partnership meeting, we'd spend hours talking about the coolest edge cases and scalability and how this is going to work. And I think the best public example that you could just see in history was they were the only company that, when they partnered with us to write the provider, spent a lot of time building this very good, I think they called it Matrix something. They fully automated the whole thing. So, when they shipped a new Google Cloud thing, it had a Terraform provider resource right away, and it didn't feel automated. It felt very ergonomic, and it was good. It was really good. And so they had that, but whenever we would get into how do we do co-sale? How do we attribute your sales engineers' quota to selling infrastructure that's spun up by Terraform? Like, how do we do this?
So like the business side of things.
Crickets. Like impossible to get anyone. Not just impossible. It was like even if you got someone, they would say something for 20 minutes and be like, okay cool, we have two more hours. Let's figure this other thing out. And yeah, that's what it felt like. And the other disclaimer I give is all this knowledge was circa, I don't know, 2019, something like that. So maybe in the past 7 years things have dramatically changed, but that's what it felt like.
Yeah. Going to open source, you're actively involved in open source today. And, you know, it seems open source is changing a lot, especially with AI, and you're seeing stuff at Ghostty. Can you tell us how open source has changed with Ghostty with the AI contributions, and what are you seeing with open source maintainers? Seems like there's a bit of, you know, drama or worrying stuff happening.
Well, I would say more broadly, the issue facing open source today is, I mean, there's multiple, but the one that I feel is most prevalent across industries right now is AI contributions, and specifically the signal-to-noise ratio being incredibly low. Or in other words, it's being super noisy with low quality contributions. It's just stressing the system quite considerably, and yeah.
And so after you left HashiCorp, you started Ghostty. How many years ago was that? Was that like 2 years or so?
Well, I left HashiCorp a little over 2 years ago. I had poked around with prototypes of Ghostty maybe 3 years ago, but after I left HashiCorp, I started working on it like 20 hours a... like much more, just because it was the thing that I had.
What drew you to Ghostty? What was your kind of vision and why did you start working on it? It's a better terminal, right?
It's a terminal.
Better is subjective. I installed it because I like it better, but yes, a terminal and
opinionated
terminal, right?
Opinionated, very modern in terms of supporting as many of the newer specs as possible that enable functionality like displaying images or, you know, clicking on your prompt to move the cursor, but dozens more examples like that. The original thing that drew me to it is the exact opposite of the good advice that people usually give, which is that you find the problem and you build a solution, and you pick the best technology that solves that. What I did was I found a set of technologies and I was like, "What could I build with these technologies?" I went the opposite direction. And I had spent over 10 years, 12 years at HashiCorp incorporated, and 3 years prior to that doing infrastructure open source. So, 15 years in total just thinking almost all the time about infrastructure and cloud services and things like that. And so, I felt that I was rusty. My skills had weakened on desktop software, systems programming to a certain extent, because I was so constrained by networking challenges in distributed systems. So, low-level systems programming had atrophied. I had never really worked with GPUs, and with GPUs, I guess crypto was happening, but I kind of ignored that whole trend. But this is pre-AI. But GPUs were obviously in use and I just felt like I had no idea how they work. So, I wanted to go to desktop. So, I picked all these different technologies and I said, "Okay, Zig." Because it looked cool to me. I just wanted to try it.
Can you, for those of us, I'm not into Zig, I heard good things about it. Can you explain why Zig is so interesting, innovative, and why does it grab so many devs' attention?
I don't know why it grabs other people's attention, but for me it just felt like the best better C that I saw out there. And I am someone that's coming from the position where I actually enjoyed writing C. So, a better C sounds great to me. To me, it's not very annoying in terms of, if I want to blow my own foot off, please let me blow my own foot off. You know, a bunch of qualities came together where I thought on the surface it looked cool, but it's very hard to judge a programming language on the surface. So, I wanted to build something with it. And so, yeah, I picked Zig, GPUs, desktop software.
What could I build? For all my time at HashiCorp I built CLIs, and I was like, well, I live in a terminal, and yet I understand very little about terminals. So, why don't I just build a toy project that's a terminal? That's how it started. And as with a lot of stuff, I find that once you dig beneath the layer of taking something for granted, you realize that everything is way more nuanced and complicated than you imagined it to be. And terminals were the same way: once I dug beneath the surface, I realized how much they were doing, how brittle some things were, how much better certain things could be, and I got sucked in to being like, I want to do this better. So.
Okay, for someone who's a dev, you know, I use terminals as well. I'm going to ask the stupid question. How hard could it be? What does a terminal actually do? And then can you maybe tell us how Ghostty is structured? Or what are the things that it needs to do? Just to give a little empathy for all the work that you're doing.
I actually get that question a lot. So, it's definitely not a dumb question. It gets asked less now, but a lot of people were like, I thought they were done. That's usually the most feedback I get. It's like, what is there to do in a terminal? So, at a basic level they don't do a lot. The problem is that the functionality terminal developers want has grown significantly. But let me just give what they do. It's kind of like an application development platform, right? It's not an operating system. You're not dealing with hardware level problems, but it is like an application sandbox on top of that, and other applications run within it and need to render text. They need to render colors and images and widgets and mouse events and all this stuff. The best description is it's like a browser, but for text content. And so all of the complexities that a browser has, a terminal has similar ones at a smaller scale. And if you try to extend what a terminal is capable of, then, you know, you start bringing in more and more problems. Like as soon as you brought images into a terminal, you introduced a whole new ecosystem of problems. But the tongue-in-cheek answer I like to give to Ghostty's complexity is that it's 30% a terminal and 70% a font renderer.
[laughter]
And yeah, that's what it feels like. It's really a problem of, you know, that terminal screen you see, whether it's GPU or CPU rendered, you're drawing on a canvas. So, you are building a renderer for text in there. Everything kind of bubbles from there. So, from a rough architecture standpoint of Ghostty, I like breaking it down in terms of threads because Ghostty is multi-threaded. Most terminals are not. But I'm not saying that as a positive point. It's just a good way to describe the architecture. We have a central UI thread, which just draws the windows and stuff. That's pretty standard for desktop software. And then we have an IO thread, which runs the actual shell that you're seeing. So, any bytes that we send or it sends back to us are processed by the IO thread. And then we have a renderer thread, which is actually drawing it. The best way to think of it is it's on a VSync clock at 30, 60, 120 frames per second. It's just sampling what the terminal state is and then drawing it. And the renderer itself uses a font subsystem on the same thread, but we have to take the fact that this grid has this character at these sets of
characters and map them into fonts and do that all on our own. A lot of people think, "Oh, doesn't the operating system solve that for you?" But they don't unless you're much higher level. Like, you know, you can't just draw easily, you know, monospace text in that way. You have to really put pieces together. That's the big picture. It's quite simple at that level and then just, you know, extend all the functionality that terminals have into that.
So, you're kind of like building a 2D graphics engine a little bit that's very focused on fonts.
Yeah, yeah. From a renderer side, it's very simple. The renderer is actually not that complicated and I won't overcomplicate. The hardest part is actually maintaining the terminal state.
So, the way terminals work is they're a grid of monospace cells. So, you'll have like 80 by 24, 80 columns, 24 rows. And there's commands that the program can send to move the cursor or say, think of it like a paintbrush. They could say make the paintbrush red and bold and everything after that is red and bold. And now change it, and you're just maintaining the state and drawing around, and then there's all the scrollback, right? Which people are used to in terminals, going back. And that's where the challenge is, doing that in a fast, performant way, and that's what I try to do with Ghostty.
I mean, I show this. There's so many benchmarks we run. But one of the most obvious ones that shows the speed, which also gets a lot of criticism, is just catting, reading a large file. If you just dump a bunch of text, how fast can it get through it? And you'll see a stark difference between modern terminals. I'm not just going to say Ghostty here. If you take Ghostty, Kitty, Alacritty, any of these newer terminals, they're all going to do great compared to Terminal.app in macOS or traditional Linux terminals. The criticism is why does that matter? And, you know, the easy answer is when you accidentally cat a file, a lot of people will force close.
The creator of Redis posted a great comment on Hacker News about why he loves Ghostty, which is that he previously used to tail production Redis logs, and, you know, it just spews logs out. And he used to have to send them to an intermediary file, and then read them out later.
So, he could render it.
So, he could render it and actually work with it. And he does not do that anymore, because Ghostty's fast enough that he could just let it dump while he's going through it, parsing it, like mentally parsing it, things like that. And that just saves him time. And, yeah, so.
There's something to be said, at some point we should probably talk more about the fact that a lot of software these days does not care about performance. And I think it's refreshing to actually have examples. And I hope we will at some point maybe get back to it. You know, we'll talk about AI. It might not help, but there's a level of craftsmanship, right? Just not wasting resources, or being efficient. I see in my day-to-day life, we have more powerful resources, laptops, phones, and they're not getting any faster, and it's just frustrating at times.
It's kind of like the love of the game. I mean, a lot of Ghostty is just the love of the game. I like to say, like, our renderer, because, like I said just before, it's not complicated. I'm not ever going to say that Ghostty is like a 2D game, because a 2D game from a rendering standpoint is much more complicated. But I do care a lot about the renderer, and we got our renderer down to, for a full screen on my Mac, set of grids, each frame updates in roughly, I don't know, it's something like 9 microseconds, or something. That doesn't include the draw time. That's just taking the state and submitting work to the GPU. It's about 9 microseconds, and then the GPU takes some time. A 120 hertz, 120 frames per second frame is 8,333 microseconds. So, if you have nine, you know, again, we don't have the number of how long the GPU takes, but it doesn't take much time at all.
You're leaving a lot of options on work for
What I'm saying is we could have made it 2,000 microseconds, and it wouldn't have mattered. You would still get that performance, but that's not fun. I want to make it sub 10.
I like it, the fun.
Yeah, so we spent a lot of time just, it was a big, I blogged about it. It was this thing where we got it down from, it used to be about 800 microseconds, and got it down to like nine. And I thought that was awesome, even though for end users it doesn't make a difference.
It does just say the craft and a little bit of game.
So, when you started out building Ghostty, that was around the time where I think ChatGPT was out. There were some tools. How did your tool set change in terms of how you're developing day-to-day?
There's two sides to that. So, one, AI gave a huge boost to terminals, which is a funny thing.
Oh, how so?
Because of Claude Code and all these things, the amount of time spent in a terminal has gone up, which if you told me in 2023 terminal usage would go up, I would say no, it's not going to go up. I had no disillusions that I was going to save terminals, and I didn't, right? AI came out and came out with all these CLI tools, and even when you're seeing Codex apps and Claude apps leaving the terminal, they're still executing so many things in a pseudo terminal. The number of terminals out there is massively larger than there was in 2023, which is hilarious.
Oh, wow.
So random.
Super random. And so, that's part of why one of the things I'm doing with Ghostty is extracting, it's actually extracted already, what I've called libghostty, which is, everyone reinvents this very small surface area of a terminal, and because they do it, all sorts of things break. Like if you run a Docker build or push to a platform like Heroku, and you do enough weird things in the terminal that aren't actually that weird, just like draw a progress bar, it renders it like chaos.
All over the place.
All over the place, yeah. And it's just because they've poorly implemented a tiny subset of a terminal, because they're more complicated than people think. And so libghostty is this minimal, zero-dependency library that people can use to embed terminals anywhere.
Oh, cool.
And yeah, yeah, MIT license. And it's really like, I'm tired of seeing broken terminals everywhere, so please use this.
So okay, that's the one angle, really funny. The other angle is actually AI usage. It's hard to say, I'm a big fan, but, you know, within the right categories of things. I think that it's a revolutionary tool and I get a lot of joy using it. Yeah, I use it every day. I use tools like Claude Code and Amp and Codex and the chat tools every day for some aspect of my life, and it's really allowed me to choose what I want to actually think about, right? I think that's the most important thing, is that I always felt limited in terms of, oh, I'm going to have to spend the next 2 hours, I don't know, doing this boilerplate, annoying stuff that I don't want to learn about. But now I don't have to learn about it, which is, yeah, I'm not getting skill formation in that category, but I could now spend these 2 hours doing something else, and that's the best to me.
In your workflow, do you just use a single agent, use multiple agents? Have you experimented with them? I've tried a bit of everything.
I would say my standard workflow, what I try to do, is I endeavor to always have an agent doing something at all times. Maybe not when I sleep. I don't go that far. A lot of people do go that far. I don't go that far. But while I'm working, I basically say, if I'm coding, I want an agent planning. If they're coding, I want to be reviewing. I know that there should always be an agent doing something.
So, but then it's a separate tab?
Yeah, separate tab. And sometimes it's multiple. There's a lot of work that I do around cleaning up what agents do, and I don't run Gastown-esque things, and so I'm the mayor, so to speak. And so, I don't want to run too many. I don't find it that fun to clean their stuff up, but periodically I'll run two in competition with each other, because it's a harder task and I don't have high confidence that they're going to just crush it. So, I'll just run Claude versus Codex or something like that. Or I'll have one coding, I'll have one doing some sort of research task. I absolutely love them for research. That's awesome. And then I'll be doing something else, but no more than two, I would say.
Yeah.
Yeah.
The code that they generate, do you always review it, or have you gotten a bit more loose? I mean, you know, some people swear on closing the loop, having validation for it, or are you still like, all right, I want to see the exact code, and I'll review if it's correct and what I expected?
It matters what I'm working on. If it's Ghostty, I'm reviewing everything that's going into it. If it's like, I set up a personal wedding website for one of my family members, I don't care at all what the code looks like. Did it render right in the three browsers that I tried? Yes. Did it render right on my phone? Yes. Don't care what the code looks like. Doesn't make any network requests. Has no secrets access. I don't care. Ship it. It's only going to be online for 2 months, so I'll ship it.
Yeah. And then how did the AI policy at Ghostty change? I remember that maybe a year ago or so, you asked for disclosures if someone is using it. And just very recently, you kind of cracked down and said, all right, no more.
Yeah, we're going to change again, too. Well, we're not going to change. We're going to iterate. So, yeah, a year ago, we started asking for disclosure. And people, you know, the very fair question there is, what does it matter how the code is produced? And the reason to me it always mattered was because it dictates how much effort I put into fixing it. Because if you produced the code with AI and you did it really quickly, then I'm not going to spend hours fixing up your code. You spend your time fixing
Yeah, because you know that the person didn't put much time into it, not much human time. You're kind of trying to mirror it, right?
Yeah, it's effort for effort. If you put in hours, I'm going to put in hours back and I'm going to help you. But if you put in a few minutes and never read anything and threw it over the wall, then I should be able to read it in a few minutes, say "No, thank you," and close it. It's fair, and I need to better understand what that is. And you know, I thought about bad code, because open source has always gotten bad code contributions. But the difference before is usually those bad code contributions came from people that were genuinely trying their best and put in a lot of effort just to get to that bad code point. And so people behave differently. I would always try to reciprocate by being like, "This is someone very junior," or "This is someone just new to the project," and I would try to educate them, be like, "Okay, we should do this better," and give these careful reviews. But if it's bad code where there was low effort, I'm not going to give a careful review. So again, I wanted to know these things, and the disclosure worked decently well. The issue wasn't the disclosure. The issue was that the quantity of low-quality AI PRs that we were getting reached a point where it was too high.
Do you know why that might have happened? More people instructed agents to contribute a PR to fix an issue? Do you have theories, or have you actually seen evidence of why this happened?
I have theories and I've seen some evidence, but yeah, I mean, I think obviously there's the rise of just AI usage in general, but the real trend, a step change that I saw at a certain point, and I don't know when it happened because I don't use agents in this way, but at a certain point, they started opening PRs. You know, before it was like, you generate code and maybe they commit and stuff, but you would still push it to a branch and then open the pull request. At a certain point, they started opening PRs. And there was a dead giveaway of AI, because at least to this day, to the point where we're recording this, the way Claude opens a PR is it opens a draft with no body, and then it edits the body later and then reopens it for review.
Which is not how a human would do it.
Oh, like one human a year would do that. And now it's happening three times a day. And so even if they're not disclosing AI or they're hiding it, it's like, oh, and it happened at a speed that's unrealistic. It opened, the body came in less than a minute later, and it opened less than a minute later.
Yeah.
Pure AI. I just tweeted about this a couple days ago, which is just, I wish that these agentic tools would put a pause on opening PRs for a second, because I think that's the point where it's really causing a lot of friction.
How did you change the policy? Are you considering closing down PRs? You mentioned recently that the thought crossed your mind.
I would say I was crashing out in that moment.
But kind of. So we shipped this policy update where PRs written by AI are no longer allowed anymore unless they're associated with an accepted feature request. So you can't just drive by and be like, I did this thing that I've never talked to you about, here you go. And we get about two or three of those a day. And so we just close those things. I literally don't even read the content. I can see it's AI. I can see there's no "fixes issue number." I just close it. No idea if the code is good. Don't care. It's just policy. Don't have time for that. That's pretty much where we've landed currently.
And we're recording this in the middle of another transition, which I already have the PR open for, where we're going to switch to an explicit vouching system for the community. So, you're no longer able to open a PR at all, AI or not, don't care anymore, which is, I think, for the people who criticize, where it came from doesn't matter. It doesn't matter anymore. Now, all that matters is that another community member has vouched for you. And if they vouched for you, you're added to a list where forever, or indefinitely, you can open a PR. If you behave badly, then you, the person who invited you, and the entire tree of people they ever invited are blocked forever from the repo.
This reminds me a little bit of, do you know the social site Lobsters?
Lobsters, yes. That's what it's based off of. So, the idea is that you're putting your own reputation on the line by vouching for somebody else. I'm a reasonable person. If this happens, then I or one of our maintainers or community made a mistake. If you just hop in a Discord or email and seem like a reasonable, apologetic person, I'm not going to spend a lot of time, there's not going to be, I don't know, a mock court type session. I'm just going to be like, "Okay, I'll give you another chance." So, yeah, we're sort of moving to that system. I think one thing that's a little bit different is, I should say that this is, one, inspired by Lobsters, but specifically in the AI space it's inspired by this project called Pi. They do this. Well, they do, they
The code quality is built on Pi. It's a self-improving
Self, like, build-your-own-agent toolkit. So, you know, kind of ironically, it's an AI tool, but they care a lot about code quality and anti-slop and things like that. So, they have a similar mechanism, a little bit less of the tree and some other things, but a similar "you can't open a PR unless"
you're vouched for. And the other difference here that we're going with is in addition to vouching, where you could positively mark someone, you could actually denounce users. So, if there's a bad actor, you could actually ban them. Not just like... you can't even attempt to contribute again. And that's just a... yeah, we had one yesterday where someone opened a PR, we closed it because it violated... it had no associated issue and it was AI. And then they just reopened it. Like not the same one, they resubmitted a new branch and reopened it like 10 minutes later. I was like, oh my gosh. So stuff like that is just... the problem is it's just wasting time.
It feels like most of open source will have to change because of AI, right? Like it's... You probably know more maintainers, but I hear this... your story is not the only one, you know, like the project closes down PRs. GitHub is, I think, just shipping a feature that projects can automatically close or reject PRs.
Yeah, I think open source will have to change in a lot of ways. I mean, I forgot who wrote this, but, you know, one of the logical extremes is if agents are so good, you don't need open source anymore cuz you can just build it, right?
Do you want to say yes?
That's the extreme. I don't want to describe that extreme, but that's one of the extremes. The issue is there used to just be this natural back pressure in terms of effort required to submit a change, and that was enough. And now that has been eliminated by AI. I like the wording that Pi uses, which is that AI makes it trivial to create plausible-looking but incorrect and low-quality contributions, and that's the fundamental issue. You know, open source to a certain extent has always been a system of reputation, right? Like you earn some trust and you get more access, you know, and that's how it's supposed to work. But yeah, that reputation system has been taken advantage of in a certain sense with AI, or the default allow PRs, as you know, has been taken advantage of. And so I think, like this vouching system that we're proposing for my project, I think it's very true to what open source is, which is that open source has always been a system of trust. Before we've had a default trust, and now it's just a default deny and you must get trust by somebody.
Do you think we might see a lot more forking happening though?
I hope so. I hope so.
Because until now forking used to be, you know, like a fork off a little bit because it was a lot of effort. It wasn't... to keep up. Like it never seemed viable to fork a profitable project, right?
Yeah, and okay, I am... separate from AI and everything, I have always been a huge proponent, or I guess in the past few years I've been a huge public proponent of: there should be a lot more forks. Like a lot more forks, because open source, I think... one of the reasons maintainers have been taken advantage of to some extent is that contributors have some sort of entitlement, you know, whether it's toxic entitlement or not, but there's some sort of entitlement, which is: I've made a valuable change, so you should accept, and it's clean and it works great, so you should accept it. But you really don't have to. Like you absolutely don't have to. And then I've seen this time and time again where you have a high-quality PR, like a perfect PR, but you say no. And there's anger in the community.
But the thing is, I've said this since 10 years ago in the HashiCorp days: hitting the merge button is the easiest step. Getting to and hitting the merge button is the easiest step. Like undergraduates should be able to do that. It's after that, it's the years of maintaining whatever you just merged within the context of your roadmap, the bugs, customer needs, all that stuff. Like that's the hard part. Like you're signing up to keeping this forever. It's very hard to remove features. So anything... remove anything.
So the core privilege you get with open source, like OSI open source, is forking. And you should take... that's the right you got. You should fork it and maintain your own software.
Yeah. One interesting impact of AI: someone tweeted about how there's a rumor that big tech is looking into re-architecting their monorepos because of agentic tooling, AI tooling, just a lot more code being churned out. What's actually happening? What's the problem with Git?
The problem with Git... I mean, I think there's a lot of problems with Git, but the monorepo problem with Git is that Git is relatively bad at very large repositories because you pretty much have to clone the entire repository. There's some extensions to fix that, but official mainline Git can't really do that, right? And so, for very large changes, the very large repositories, it's sort of annoying to maintain. And then, if you have a lot of churn in it, it's very hard to get changes into whatever your trunk is, your main, your master branch, right? You constantly rebase. Merge queues solve that to a certain extent. I think merge queues work for humans at a certain scale, but merge queues could get quite deep. But then, if you sort of 10x that, like conservatively, I think 10x that. And then, if you buy into hype cycles and you 100 or 1,000x that, I think it gets completely untenable in terms of how are you ever getting any semblance of cohesiveness onto the main branch quickly. And so,
yeah, I think there's a confluence of problems there, which is the merge queue problem, the disk space problem, the branching review type problem. Oh, I also tweeted another time where, like, Git has this... you branch and you push up your branches, but the branches are only the positive. Like, when you close a PR and you don't accept it, you pretty much have the branch. In GitHub, you could reaccess closed PRs, but a lot of people don't even get to the PR stage. They experiment, they're like, "Oh, this isn't the right way." And then, they never push the branch. And that's relatively important information, relatively important. It's not as important as the positive, but I think there should be a lot more branches in Git, a lot more information that we just never throw away. Like, to me, we're sort of at the Gmail moment for email for version control, where you used to really have to curate, delete all this email. And then, Gmail came out, gave a gig away for free to everybody.
Who never has to think about it.
Their tagline or something was like "never delete email." I remember seeing that in some sort of marketing. It's like archive it, right? Never delete it. And that's where I feel like we should be at with code, which is just huge repos, a lot of context. We need better tooling in order to find relevant context in that Git repo or version-controlled repo. I would say that the real... you asked for real examples. I do advise a company that's currently in stealth but working in this space. And the real examples are driven by the highly agentic companies. The companies that are going really all in and drinking the Kool-Aid. And they're struggling in terms of the amount of churn that these agents are causing is so much greater than humans. And it's not an AI review problem or anything. It's really just a release problem, like managing the merge queues, humans getting access to the right set of data in the repository, and things like that.
So are problems performance problems mainly with Git, or just even the workflow of...
Yeah, yeah, all of it. Performance for sure, but workflow, yeah. I mean, like, every time you pull... you can't push because every time you pull there's another change. Like every time you push it's rejected.
Yeah, there's a lot of parallel work happening as well.
Do you think Git will be around with these agents in a few years?
Who knows, but what's interesting is this is the first time in like 12 to 15 years that anyone is even asking that question without laughing.
We're not laughing.
Right. Like if 5 years ago you said "will Git be around in 5 years," you'd be like, "Are you... Yeah, of course it'll be around. Like, that's crazy to think," Git, right? But now people could ask that question. And of course some people will laugh, but there are people that critically think that Git might not be around in 5 years.
Well, I think you do want to save the prompt history cuz often reading the prompts is actually... if it's a bunch of code generated, the pull request is meaningless.
Changes will happen. Like Git and GitHub, forges in their current form, do not work with agentic infrastructure today. And it's nascent today. So, yeah, change will happen. And I'm not exactly sure, and that's not something I'm trying to change myself, but, you know, I'm on the receiving end in terms of agent user and a maintainer where I'm like, this isn't working.
What other engineering practices that, you know, have been relatively stable for like 10, 20, or even more years do you think have to change or are looking to change? Thinking things like CI/CD, testing, code review, other, you know, ways of doing?
You know, Amp has a saying which is... it's kind of clickbaity, but it's so true: everything is changing. And this is the first time really where it feels like... it's the first time in my, you know, short, relatively short to other people, but still like 20-year professional career that so much is on the table for change at one time. And I'm an optimist, so it's really exciting to me. It's a lot of fun, but
we've never seen so much editor mobility. Editors used to be one of those things that once someone picks an editor, it's very hard to get them off that editor. They're stuck. The level of editor mobility in the past few years between VS Code and Cursor and just jumping around is unreal. So, there's a bunch of mobility there in terms of... I mean, Cursor itself is a great example of a company that reached an insane valuation that you could never have gotten pre-AI on an editor product. So, editors, forges, CI/CD for sure, and I think testing in general, because to make an agent better, it needs to be able to validate its work. And so, tests go from... even the best test case scenarios don't have... I mean, the best I guess have full coverage, but that's a very extreme. The very good test case scenarios just test one of the edge cases and one of the happy cases and, you know, a bad case, and they just kind of go through, and if it passes, it's probably good, paired with a human who's thought about the problem. But AI is more goal-oriented in terms of: I want this feature to work this way. If it doesn't see a spec somewhere or a test somewhere that other things should work in a different way, it'll just break it on its path to its own goal. And so,
I've heard this called a lot of things. I mean, the one I like the most is kind of like harness engineering.
Harness engineering?
Yeah, one of my goals for this calendar year has been to spend more time doing that, which is that anytime you see AI do a bad thing, try to build tooling that it could have called out to, to have prevented that bad thing or course-corrected that bad thing. And so, it's sort of like moving from the product to working on the harness for the product, or product development. And so, yeah, there's a lot of that where I think testing has to change to be far more expansive, but CI/CD is not set up, just resource and performance-wise, to be able to do stuff like that. So, yeah, I'm not sure how it changes, but that's going to change, too. So, everything is on the table. It's really interesting.
Yeah, and a lot of tools to be built. One other thing: observability.
Yeah, and I guess on that same topic, I mean, of the volume and scale and observability, it's also the sandbox. Like I didn't think... even being in infrastructure and being heavily into infrastructure, you know, containers blew up the amount of minimal compute units we had floating around everywhere. I didn't think that was going to go up. I mean, it'd go up predictably, but I didn't think it was going to slope change up. And it has slope changed up already just due to the sandbox environments that agents need.
And yeah, I mean, that's super interesting to me cuz that stresses a whole lot of new systems. I think, you know, the things that I worked on, all the products I worked on, but also things in the ecosystem like Docker, like Kubernetes, they're going to be stressed significantly because they're engineered for some level of scale, but this is a different type of, particularly non-production, workload scale that you have to support. So, yeah, it's fun, fun problems.
Going back to hiring, you've hired a lot of engineers, and you previously talked about something really interesting. This was, I think, in the context of maybe HashiCorp: how some of the best engineers you've hired had really boring backgrounds. Can you talk about that? Like who were the best engineers you hired, and how does...
Yeah, that's a better way to frame it. Yeah, I stand by this. I mean, most of the best engineers I can remember from my time at HashiCorp, but also just in every job that I've had, are notoriously private. Not because they want to be private, because they just don't care to be public, I guess would be the better way to put it. I don't want to carefully describe anyone without giving them away, but, you know, they don't have social media profiles. And very often they honestly are 9-to-5 engineers. They go back and they don't code at night. They just spend time with their family. But because they don't do anything else during their working time, they're locked in and they're really good. And it's not about putting in the hours, it's also just skill-wise super strong. So,
yeah, I always found, when I was reviewing resumes and stuff, when you find the person that has a resume where they don't have even a GitHub account... Like some people are like, "Oh, you have to have public contributions to stand out." That is a way to stand out, but also if you have zero public contributions and you've just worked at companies that I've also never heard of before, it kind of is interesting to me, which is like, "Okay, you might know something deep." So,
yeah, I think that, you know, the problem is... and the ironic thing is I spend a lot of time on social media. And these engineers are better than me. But the funny thing is, every moment you spend on social media... time is zero-sum. So every moment you spend on social media is taking away from something else. And the issue is it's not one-for-one because, as every engineer knows, the time it takes to really get your mind into flow, to get going with something, varies, but it takes time. And so, when you context switch to social media, if something's compiling and you tab over and you spend time, you've given something up in terms of thinking. I think one of the best things... I do spend a lot of time on social media, maybe an unhealthy amount of time on social media, but also an unhealthy amount of time at night.
I don't have insomnia, but it takes me a long time to fall asleep. And it's because I just sit there in the dark, and I love... Some people do this in the shower, but it's not long enough for me. I love to just sit in bed, lights off, my wife sleeping, and I just think through... like I'm writing code in my head, I'm thinking through products, I'm thinking through website copy, I'm running CLIs in my head of how it's going to feel. And sometimes... last night I went to bed at 9:30 cuz I'm a dad, so I go to bed early. And
And you probably have to wake up, and you don't know when you have to wake up.
Yeah, yeah, and I didn't even feel like
I was up that long. And I was like, "Oh, I got to go to the bathroom. I should really actually go to sleep." And I looked and it was 12:30. And all I was thinking about was, it's so dumb, but all I was thinking about was this vouching system, of how vouching might work, it might not work.
And I've always had this thing where I like competing. I think competition's fun. But I always feel fair game to compete with anyone in the product building space, because I think I'll spend more time thinking about it than they will. I think people turn it off, and I try not to turn it off. So, yeah, I think the point of all that is the best engineers are the ones that context switch the least, probably.
Having used AI agents, you think this might change? Because these agents can go on and think or do work for you. How would you hire in this new world where using AI is kind of a given? Most devs will prompt and fewer and fewer write, even though the best devs clearly know how to write code as well.
I would definitely require competency with AI tools. You don't need to use them for everything. That's not the important part of it. It's an important tool to understand the edges of. It's like any other tool where sometimes it's useful and sometimes not useful. But if you ignore it completely, you're going to do something suboptimal in a time.
I mean, the best example to me is proofs of concept. Constantly in real product organizations, you have an idea and you need to demo it out to figure out if it works. I would much rather someone just throw slop at a wall that you're never going to ship and spend a day doing that, maybe less than a day, rather than spend a week doing it organically as a human. Because you're going to throw it away anyway. You might throw it away because it's a bad idea, but I'd rather prove it out. And so just slop it up.
And so this is why it's so nuanced. I get so worked up about sloppy PRs to open source. But it's because there's a time and place for them, and that's not the time and place for them, but there is one. And so I would hire in that way.
And I think the other thing, I don't know if this is the right thing to do, but that goal that I have, I would strive for everyone to have an agent running at all times. Again, it doesn't need to be coding, but to be doing something extra for you. I would strive for that because I do it driving. That's my biggest one. On the drive here, I had some deep research going. I will always spend 30 minutes on the boundaries: when I wake up, before I stop working, before I leave the house or something, I spend 30 minutes before I stop working thinking, what can my agent do next? What's a slow thing my agent could do for the next time?
And I know I'm going to drive here for an hour. It finished far faster than an hour, but it's just like, oh, I need to do some library research. Okay, find all the libraries that have these properties that are licensed in this way. I was looking up some HTTP/3 stuff, QUIC stuff. And so, build that ecosystem graph for me.
Right before I left, I was working on something to do with this vouching system, and I didn't quite understand the edge cases of what I was doing. And I will think about that manually, but why not just start an agent to look at this repo? And I use Amp's "consult the oracle," like think deeply about what the edge cases might be. What am I missing? If I had another 2 hours to work, I wouldn't need the agent to do that. I would have done it myself, but I don't. So, why not have it do it? So, it's just part of my goal to always have one going. And I unfortunately don't have one going because I finished it all right now.
Interesting. And so, with this agent running there, do I feel correctly that it's now so natural that it doesn't get in the way of your own thinking? You do your own thinking and you do your work, but every now and then you glance and you ping it or you start it. It's not distracting, right?
Yes, I actually turn off all the agentic tools that do this, and I turn off the desktop notifications. I think the desktop notifications are for the most part a mistake. So, yeah, I turn those off. I choose when I interrupt the agent; it doesn't get to interrupt me. So, for sure.
And there's another aspect where I think my engineering has changed, where I try to identify the tasks that don't require thinking and the tasks that do require thinking, and just delegate the work to an agent. Sometimes it just feels productive to do the non-thinking tasks and you're like, yeah, I did a lot today, I got this. But a lot of times I just try to delegate and get out. There's a lot of people that say you think less. And I think if you use the tools wrong, you do think less, because you just launch an agent and, I don't know, go watch YouTube or scroll social media or something. But if you instead view it as a way to choose what you think about, then I think that you don't need to sacrifice that thinking. But I think the problem is the majority of the population probably won't do that.
Yeah, but I think it's good food for thought, and it's good to hear from you how you're using it and that it's working for you. When did you start to have this second agent running? What made the switch? Was it the models getting better, or...
Yeah, I don't remember which model it was, but there was a certain... I tried Claude Code right when it came out. It was like March or May last year.
Yeah, it was March, the beta, and the May public release.
Okay, I don't think I used the beta, so it was probably May. Wasn't super impressed, honestly. And then really quickly, by the summer, at some point during the summer, oh, I remember. I saw so many positive remarks about it that I started to get scared that I would be behind on how to use the tool.
And so, I actually started forcing myself to... I still didn't believe in it, so I would do everything manually, but I was forcing myself to figure out how to prompt the agent to produce the same quality result. I was working much slower because I was doubling the work, and it was more than double because they're slow and we're going back and forth, and I already had the work done and all the stuff, but I was forcing myself to do it.
And you find stuff that I couldn't figure out, it just wasn't there yet, but then I found other stuff where it's like, "Oh, I naturally got to the same point that thousands of other people got to." Which is like, "Oh, if I do a separate planning step, it does so much better." And everyone got there. And then I figured out, "Oh, if I have a better test harness for it to execute, it does a lot better." And then, I think everyone starts with no AGENTS.md, no CLAUDE.md, or anything. Same thing, I realized, oh, if it makes a mistake and I just add that to AGENTS.md, it never makes that mistake again. And these are just incremental things that I recognize when I see people that are new.
Or I've watched a couple live streams, I've lurked on live streams where kind of anti-AI people try AI, and it's one of those things where I'm like, they're just swinging the hammer way, way off, right? It's because you haven't... It's as if someone tried to adopt Git and they used it for an hour and decided they weren't more productive with it. It takes much longer than an hour to get proficient with Git, but you put in the effort and then you reap the rewards later. And it's sort of the same thing to me with AI tools.
What would your first advice be for someone who is not...
My first advice would be reproducing your work with an agent. And if you really, really don't want an agent to code, reproduce the research part of your work with an agent. There's a lot of people where it's like, I don't want it to write code for me, for whatever reasons. But yeah, just kind of delegate some of the other research part. There's so many places it could be helpful. So you don't need to pick up on the "it must replace you as a person" kind of propaganda. You could just find the corners of where you work and replace those parts.
One thing that you give people is advice for potential founders, because you're a successful founder. You've had an exit, you built up this awesome company. You get a bunch of emails from people asking, "Hey, I want to be a founder. What's your advice?" And you wrote about this, you shared the email. But what can you tell us, what advice you typically give people and how is it received?
Well, I usually have to ask for more specifics, because if someone's like, what could I do to be successful? One, I also always explain that you're consulting someone with survivorship bias, so you have to take that into account. But I'm willing to share my experience as a survivor, just understand that there's survivorship bias. But usually I ask for something more specific. What are you trying to do? And so we usually get to, should I open source a project or not? Or should I be remote or not? Or should I do enterprise versus... and I don't know.
But the most general advice I usually give people is startups are much longer than you think. You're going to probably work on it for, I say imagine 10 years. A lot of people say 5 years, but I say imagine 10 years. Is this really something you want to work on for 10 years? And you need to have a certain amount of hubris in order to say, I'm going to work on this for 10 years and I truly believe I'm going to do it better than anyone else. There's nothing behind that, no substance behind that other than hubris. So you need to have a certain amount of ego and hubris in your head to make that, but not too much where you'll be blind to change coming in. So that's usually the first advice I give. Because a lot of people have cool ideas, but they're going to burn out relatively quickly. So, that's where I start.
So currently you're advising some companies. What are you seeing with them? What are startups doing these days? What are they doing differently than earlier? How's that landscape?
Again, it's really contextual in terms of, if you're an AI startup, it's very, very different.
How are AI startups working differently?
There's a lot of pressure to go faster than I've ever seen any startup. I think the industry is moving so fast. I don't advise any AI startups, but I've talked to some of them, and even as an advisor I feel like it's too much pressure because they are just being pushed to prove themselves quickly. Whether it's through traction or revenue or something, there's this mentality within that ecosystem where AI should allow you to go crazy fast. And in addition to that, there are a lot of companies moving crazy fast. The change is happening. I think that's the one thing. Outside of that, like I said, there's just a ton of opportunity in every space. Otherwise, it's a lot of the same stuff. It's remote versus non-remote, open source versus non-open source.
Do you see the role of software engineers changing now, especially at the AI-native companies where engineers like yourself are actually being way more productive? They can produce a lot more code, a lot more output. Are they being pushed into wearing more hats, talking to the business, or being a bit more like a mini founder, if you will?
I hesitate to say more productive. I view that there's an expectation that they could do more. I don't think that's necessarily more productive, but it's more like you should be able to, for example, build a full demo, design, everything for your... You don't need a team to do that anymore, right? You should be able to do that, at least from a demo perspective. There's no reason not to, because again, you could ship slop for that. That's fine. This is all the same, but you should be able to research effectively, and in a sense, handle more vague tasks. I'm seeing that a lot more, which is just, the capacity to experiment is so much higher, I would say. But then, when it turns into productionizing something, it feels similar to what it's always been. I think that there's a lot of companies that are eating the dog food of the AI companies, of shipping whatever, and I think that's a little scary.
Yeah, they look at Anthropic, and they're like, "Oh, they built Claude Cowork in 10 days, and they'll be a billion-dollar company." They're freaking out about why they're not doing that.
I think a big change is from a pre-seed perspective, where you would be like, "I need to raise a seed in order to build a prototype." It's like, show me the prototype, because you should be able to build that really quickly for most things. There's still hard tech out there where you can't do that.
So, you do a bunch of coding, you do a bunch of thinking about coding as well, even as you're trying to fall asleep. What refills your bucket outside of coding, outside of tech?
Obviously the stereotypical things, like just taking breaks and being with my family and things like that. But I think the biggest thing is, I am introverted. So just quiet solo time refills the most energy for me. I live pretty close to the beach, and if I'm in a bad mentality, things aren't working, I'm feeling unproductive or something's going on, just closing my laptop and taking a walk outside, stuff like that helps a lot. I have a lot of hobbies and stuff, but as a general recharge, it's that more than anything. I know there's a lot of people for whom it's going out with friends or something like that, and I like that, but that's not the full recharge for me.
And what's a book that you would recommend and why?
So I pretty much only read fiction outside of news.
Great.
Great. Okay. The most recent book of fiction I read is an older book, and it is an easy read. So I hope people are not like, oh, he's an idiot for reading this, but it was... what's it called? The something Life of Addie LaRue. It's kind of a romantic type of fiction novel. I think it's like 10 years old. It's older now. But it's about a woman who kind of sells her soul to live forever, but the cost was no one remembers her once they walk out of the room. And it's going through her whole life of losing all human connection, but she gets to live forever, what that is like. And, you know, I like reading fiction, so...
I like reading fiction at night. I don't know if it's escapism or just, you get to live in different worlds. It's so different to the coding or anything. Maybe it just helps me turn off the thing. I personally probably read way more fiction than I do professional non-fiction, honestly.
Yeah, I'm the same way. It's my version of TV, too. TV to me is more of a social activity. If my wife wants to watch something together, we'll watch a show. But if I'm alone, I'm not going to watch a show. I'm going to read, probably.
Awesome. Well, thanks so much for going through all of these details. It was just so great to hear how you're working, the history of HashiCorp. This was all just really, really interesting and motivating.
Yeah, thank you.
Thank you.
I hope you enjoyed this long and interesting conversation with Mitchell. One thing that really stuck with me from this conversation is Mitchell's own rule for himself. Always have an agent that does something. Not necessarily coding, just doing something. For example, while he was driving to this podcast recording, he had deep research running. Before he leaves the house, he asks himself, "What's a slow task that my agent could do while I'm gone?"
An important part to all of this, he turns off all notifications. The agent does not get to interrupt him. He interrupts the agent when he's ready. Mitchell is in charge, and he has a buddy who does the work that he has delegated while he focuses on the problem that he is solving.
This is a nice challenge for anyone listening. Next time you step away from your desk, before you close the laptop, ask yourself, "What slow task could an agent be doing while you're gone?"
If you enjoyed this episode, share it with a colleague who's thinking about where software engineering could be heading. And if you've not subscribed yet, now's a good time. We have more conversations like this one coming. Thanks, and see you in the next one.
Article published