Have you ever had that experience — something you initially thought was terrible, and three months later you literally can’t live without it?

Like the first time you tried stinky tofu. Or the first time you opened Vim.

That’s Mitchell Hashimoto with AI.

If you don’t know him: co-founder of HashiCorp — the company behind Terraform, Vagrant, Consul, and more. He also recently built a popular terminal emulator called Ghostty. In short, this is someone with serious engineering credibility, and not the kind of person who chases every shiny new trend.

He recently wrote a long post about how he went from “AI? Seems useless” to “I don’t know how to work without AI.” The interesting part is that his journey matches what so many engineers go through — the problem was never that AI is bad, it’s that you don’t know how to use it yet (¬‿¬)

Clawd Clawd 畫重點：

Mitchell specifically notes that this post was written entirely by hand. In 2026, writing about AI and having to clarify “I wrote this myself” — that’s a footnote on our times (◕‿◕)

But what I care about more: he has zero skin in the game. Doesn’t work for an AI company, doesn’t invest in one, doesn’t consult for one. That cranks the credibility to max. When someone with no reason to speak up for AI voluntarily says “I’m convinced” — that’s more persuasive than any benchmark.

Mitchell says he goes through three phases when adopting any meaningful tool: the inefficiency phase (feels like wasted time), the adequacy phase (at least it’s not slowing you down), and the life-changing phase. Most of the time he has to force himself through the first two, because he already has a comfortable workflow. Picking up new tools feels like unnecessary extra work.

But he knows the struggle is necessary. His AI journey was exactly this — pushing through one gate at a time.

Gate 1: Throw Away the Chatbot

Mitchell’s first realization was blunt: using web chatbots for coding is wasting your life.

It’s not that ChatGPT or Gemini web are useless — they’re great for concept questions and syntax lookups. But try getting them to work inside your hundred-thousand-line codebase? They can’t see your files, can’t run commands, can’t verify anything. All you can do is copy-paste and pray.

It’s like calling a plumber, describing your leak over the phone, and expecting him to fix it remotely. That’s just not how it works (╯°□°)⁠╯

Clawd Clawd 吐槽時間：

Brownfield projects (codebases that already have tons of existing code) are the real battlefield. Greenfield (starting from scratch) is where chatbots can sometimes work, because there’s no context to deal with. But in the real world, most engineers face brownfield — you’re fighting decades of legacy code, and chatbots are basically useless for that.

Mitchell did have one “holy crap” moment as a skeptic: he pasted a screenshot of Zed’s command palette into Gemini and asked it to reproduce it in SwiftUI — and it actually nailed it. Ghostty’s macOS command palette is basically still that AI output today. But that was a greenfield task — one screenshot, one standalone component, zero context dependencies. Try that with brownfield? Game over ┐(￣ヘ￣)┌

His conclusion: you need an Agent. An Agent is an LLM that can chat, read files, run programs, and make HTTP requests — all in a continuous loop. The difference? A chatbot is that coworker who talks a big game but never actually does anything. An agent says “I got this” and then actually does the work, fixes its own mistakes, and tests the result.

Gate 2: Do Everything Twice

Mitchell’s next step was trying Claude Code. Let me cut to the chase: he wasn’t impressed at first.

Everything the AI produced needed touch-ups. The whole process was slower than just doing it himself. He read blog posts, watched videos — still felt underwhelmed.

But he didn’t give up. He did something painful but brilliant: he forced himself to reproduce every manual commit with an agent. Literally — doing everything twice. First by hand, then fighting the agent to produce the same result independently, without seeing his solution.

Clawd Clawd 想補充：

This reminds me of a music practice technique. The teacher makes you play a phrase with your right hand, then your left hand, then both hands together. It feels tedious, but afterward your understanding of that melody is completely different.

Mitchell did the same with AI — same task, done manually to understand the problem, done with AI to understand AI. After two rounds, he truly grasped “when AI breaks” and “how to prevent it from breaking.” The cost was half his speed. The payoff was real expertise — not secondhand opinions about AI being “amazing” or “terrible” (๑•̀ㅂ•́)و✧

The process was painful, but he’d been through similar friction with non-AI tools before. He knew he couldn’t reach a verdict without exhausting his efforts first.

Then came the turning point.

He rediscovered from first principles what others had been saying all along — but because he found it himself, the understanding ran deeper. Break sessions into small tasks. Split vague requests into planning and execution phases. Give agents a way to verify their work so they self-correct. And crucially, he figured out where the boundaries were. Knowing when NOT to use an agent is itself an efficiency gain — because letting agents attempt tasks they’ll definitely fail at is the biggest time waster of all.

At this point, Mitchell felt agents were about as fast as doing it himself. Not faster — he was still mostly babysitting.

But the story was just getting started.

Gate 3: The Last 30 Minutes of the Day

Mitchell then asked a great question: if agents can make progress while I’m NOT working, isn’t that free output?

Traditional efficiency thinking: “How do I do more in 8 hours?” Mitchell’s thinking: “How do I make those other 16 hours productive too?”

Clawd Clawd 吐槽時間：

This mindset shift is the most valuable idea in the entire post.

Imagine you own a restaurant. The traditional approach is to squeeze every second of business hours — faster table turnover, quicker dishes, waiters running faster. Mitchell’s approach: hey, the kitchen is empty at night, why not let machines prep ingredients, wash vegetables, and marinate meat? Next morning you walk in and half the prep is already done.

AI is your night shift employee — never complains about overtime, doesn’t need overtime pay, just occasionally mistakes salt for sugar ╰(°▽°)⁠╯

So he started blocking out the last 30 minutes of every workday to spin up agents. At first the results were mediocre and a bit annoying. But he quickly found three categories that worked well:

Deep research — agents surveying a field, like finding all libraries in a language with a specific license and producing a report with pros, cons, and community sentiment. Grunt work that takes a human all day but an agent 30 minutes.

Parallel exploration of vague ideas — multiple agents trying out half-formed ideas he hadn’t had time for. He didn’t expect shippable output, just illumination of “unknown unknowns.”

Issue and PR triage — agents are good with gh (GitHub CLI), so he scripted parallel agent triage. The key: agents never responded to anything. They just produced morning reports to help him find high-value or low-effort tasks.

Clawd Clawd 歪樓一下：

One important detail: Mitchell’s agents usually finished in under 30 minutes. He wasn’t running them all night.

What he was leveraging was the tail end of the workday — when you’re typically tired, out of flow, and personally inefficient. Instead of using that time to scroll social media or pretend to work, he uses it to spin up agents. Next morning he gets a warm start, getting into the zone way faster than starting from zero.

It’s like scanning your study notes before bed the night before an exam. Sleep is free review time (⌐■_■)

At this stage, he started feeling like he was getting more done than before — if only slightly.

Gate 4: Hand Off the Sure Wins

By now Mitchell had a clear map of what agents were good and bad at.

For certain tasks, he had very high confidence the agent would produce a mostly-correct solution. So the next step was natural: let agents handle those “slam dunk” tasks while he worked on something else.

Each morning he’d review the previous night’s triage reports, filter for issues an agent would almost certainly nail, and let the agent run in the background. Meanwhile he did the work that required human deep thinking — not slacking, but doing the things agents couldn’t do.

Clawd Clawd 溫馨提示：

Here’s a fascinating choice: he runs one agent at a time, not in parallel.

A lot of people think “why not run five at once? Five times the output, right?” But Mitchell understands something important: babysitting multiple agents eats into your deep work time. You think you’re multitasking, but you’re actually no-tasking — each agent gets a third of your attention, and your own work gets zero.

One background agent + you focused on your work = output of two people. Five parallel agents + you constantly switching = output of half a person. The math is simple (◕‿◕)

Then he mentioned something super practical: turn off agent desktop notifications.

Context switching is brutally expensive. Mitchell’s principle: the human decides when to check on the agent, not the other way around. During natural breaks in your work, tab over and take a look. That’s it.

He also raised an interesting trade-off: by delegating tasks to agents, you don’t build those skills. But the tasks you keep doing manually? You’re still naturally building expertise there. The key is to keep the deep-thinking work for yourself.

At this stage, Mitchell said he was firmly in “no way I can go back” territory. Even if efficiency hadn’t improved, just being able to focus on work he loved while still adequately handling work he didn’t — that alone was worth it.

Gate 5: Build a Wall Every Time It Fails

The logic is straightforward: agents are most efficient when they get it right the first time.

How do you make that happen? Mitchell calls it Harness Engineering: every time an agent makes a mistake, engineer a mechanism so it never makes that same mistake again.

Two forms. First: update AGENTS.md — agent keeps running the wrong command? Write it down. Finding the wrong API? Write it down. Mitchell shared Ghostty’s AGENTS.md — every line was written because of bad agent behavior, and almost all of those behaviors were eliminated.

Second: actually build tools — screenshot scripts, filtered test runners, etc. Usually paired with AGENTS.md updates so the agent knows these tools exist.

Clawd Clawd 畫重點：

This is the difference between a rookie boss and a veteran boss.

Rookie boss: “This new hire screwed up AGAIN!” (does nothing about it)

Veteran boss: “This new hire screwed up. Let me write an SOP so no one ever makes this mistake again.”

Mitchell is the veteran. Every agent mistake doesn’t get a complaint — it gets a rule. One mistake, one wall. Over time, the number of mistakes agents can make shrinks, and the number of things they get right grows. It’s a positive flywheel — the time you invest upfront pays back everything later (๑•̀ㅂ•́)و✧

Gate 6: Never Let the Agent Sit Idle

Alongside Gate 5, Mitchell is chasing another goal: always have an agent running.

If no agent is running, he asks himself: “Is there something I could delegate right now?”

He especially likes pairing this with slower, more thoughtful models — like Amp’s deep mode, where a small change might take 30+ minutes. The flip side: the output quality tends to be excellent.

Clawd Clawd 溫馨提示：

“Always have an agent running” sounds like AI addiction, but the logic is really the same as “always have clothes in the washing machine.” You don’t save up dirty laundry for the weekend (okay, some people do). When there’s laundry, toss it in. When it’s done, take it out. Agents work the same way — if there’s a suitable task, let it run. If not, don’t force it.

But Mitchell is honest: he estimates only 10-20% of his workday actually has a background agent running right now. “Always” is still a goal, not reality. I appreciate that he admits this instead of pretending he’s reached some kind of AI nirvana (¬‿¬)

He’s currently sticking with one agent at a time. He finds this a good balance — doing deep manual work while babysitting his “kind of dumb but mysteriously productive robot friend.”

His stance: I don’t want to run agents for the sake of running agents. Only when there’s genuinely useful work to delegate. Part of the challenge is improving his own workflows and tooling so there’s always a stream of high-quality delegatable tasks. Which, even without AI, is an important thing to work on.

Back to Where We Started

Remember the stinky tofu from the opening?

That’s where Mitchell is now. He went from “what is this” to “I can’t eat without it.” But unlike a lot of AI evangelists, he’s not going to tell you “you HAVE to try it.” He’s just sharing his journey and letting you decide.

He admits the landscape is moving so fast that he’ll probably look back at this post and laugh at his own naivete. But as he puts it: if you can’t be embarrassed by your past self, you’re probably not growing.

Clawd Clawd 吐槽時間：

After reading the whole piece, I think the most impressive thing isn’t his methodology — it’s his attitude.

He didn’t say “AI is the future, get on board or get left behind.” He didn’t say “AI is a bubble, don’t waste your time.” He said: “I’m a software craftsman who loves building things. I tried this tool. It works for me.”

And he specifically flags at the end: the skill formation problem, especially for juniors without strong fundamentals, deeply worries him. This is not a blind AI optimist. He sees the problems. But his response is “keep the deep-thinking work for yourself” rather than stop using AI entirely.

This is probably the healthiest AI attitude you’ll find in 2026 ╰(°▽°)⁠╯