Mitchell Hashimoto Just Wrote the Only Honest Guide to AI Coding — And It's Not What the Influencers Want You to Hear

💡 TL;DR (Too Long; Didn't Read)

Key Takeaways in 60 Seconds:

Mitchell Hashimoto (creator of Terraform, Vagrant, Vault, Consul) published a brutally honest AI adoption guide

No financial stake: He doesn't work for, invest in, or advise any AI company — this is pure practitioner experience

Step 1: Drop the chatbot. Use agents that can touch your filesystem, not copy-paste middleware

Step 2: Do every task twice (manual + agent) to calibrate when to use AI

Step 3: End-of-day agents for research/triage give you a "warm start" next morning

Step 4: Outsource "slam dunk" tasks to a background agent while YOU do deep work

Step 5: Build AGENTS.md guardrails — every agent mistake becomes a permanent fix

Step 6: Always have an agent running (10-20% of workday, not 100%)

The honest truth: ~10-20% productivity gain, not 10x. And that's real.

1. The Hook: Why This Matters Now

I've been writing software since Borland Turbo C came on floppy disks. I watched Java applets fail to deliver, SOAP turn into a punchline, and microservices go from revolutionary to "why do we have 400 repos." I've developed a nose for hype. It's a survival mechanism.

So when I opened Mitchell Hashimoto's new blog post yesterday morning — "My AI Adoption Journey" — I expected the usual Silicon Valley gospel. The missionary zeal. The cherry-picked demo. The "I built an entire SaaS in 47 minutes" sizzle reel.

Instead, I got something I haven't seen in two years of AI discourse: a genuinely honest field report from someone who doesn't have a single dollar riding on whether you adopt AI or not.

And it shook me. Not because of what it said about AI. Because of what it said about us.

2. Who Is Mitchell Hashimoto and Why Should You Care?

If you don't know Mitchell, you haven't been paying attention.

He co-founded HashiCorp in 2012 and created Terraform, Vagrant, Vault, and Consul — tools that collectively define how most of us deploy software today. When Mitchell builds something, the industry adopts it. That's not hype. That's a track record.

After leaving HashiCorp, he dove into building Ghostty, a GPU-accelerated terminal emulator written in Zig. Not Rust. Not Go. Zig. Because Mitchell doesn't follow trends — he evaluates tools from first principles and picks whatever serves the problem best.

Here's the critical detail: Mitchell has no skin in the AI game. He doesn't work for Anthropic, OpenAI, or any AI startup. He doesn't invest in them. He doesn't advise them. He makes this explicit in his post. When he says something works, you can trust it's not a pitch disguised as a blog post.

That credibility gap is everything.

3. The Six Steps Nobody Talks About

Mitchell's post is structured as a six-step journey. But what makes it remarkable isn't the steps themselves — it's the brutal honesty about failure at every single stage.

Here's the progression:

I want to unpack the most revelatory parts.

4. Step 1: "Drop the Chatbot" — The Inconvenient Truth

Mitchell's first step is to stop using ChatGPT as a coding tool.

Read that again. The most-visited AI product in history. The thing every recruiter now lists as a "required skill." Mitchell says: stop.

His reasoning is precise and devastating. Chat interfaces for coding are a copy-paste treadmill. You're the human middleware — shuttling code and error messages between your editor and a text box, hoping the model remembers context it already forgot three messages ago. You become a low-bandwidth API gateway between your codebase and an LLM that can't see your files, run your tests, or verify its own output.

The alternative is an agent — an LLM that can read files, execute programs, and make HTTP requests in a loop. This is Claude Code, Codex CLI, Amp, or any tool that actually touches your filesystem.

This distinction sounds simple but it's the divide between "AI is a gimmick" and "AI is a force multiplier." I've watched entire teams waste months in chat-based workflows, convinced they were "using AI," when what they were really doing was sophisticated copy-paste with extra steps.

5. Step 2: The Move That Separates Professionals From Tourists

This is where Mitchell lost me — and then won me back.

He describes forcing himself to do every piece of work twice. First manually. Then with an agent. Without letting the agent see his manual solution. Over and over, day after day.

My initial reaction: "That's insane. Nobody has time for that."

But then I remembered: this is exactly how I learned vim. And git. And Kubernetes. And every other tool that eventually became load-bearing in my workflow. You eat the inefficiency upfront because you're not optimizing for today — you're building the muscle memory and mental model that will compound for years.

What Mitchell discovered through this painful exercise:

Break tasks into atomic units. Don't ask for the whole feature. Ask for one function, one test, one migration.
Split planning from execution. Vague goals get vague code. Have the agent plan first, then execute separately.
Give the agent a way to verify its own work. If it can run tests and see failures, it self-corrects more than you'd expect.

And critically, the negative space: knowing when NOT to use an agent is just as valuable as knowing when to use one. Reaching for an agent on a task it'll botch wastes more time than just doing it yourself. This calibration only comes from the painful dual-track exercise.

6. Step 3: "End-of-Day Agents" — Reclaiming Dead Time

This was my personal favorite insight. Mitchell noticed that at the end of each workday, he was tired, unfocused, and burning the last hour on low-value work. So he started using those final 30 minutes to kick off agents instead:

Deep research sessions: "Find all Zig HTTP libraries with MIT licenses, compare them on 12 criteria, produce a detailed report."
Exploratory prototypes: Vague ideas he hadn't started on, running in parallel. Not expecting shippable code — expecting illumination.
Issue triage: Agents using gh CLI to scan open issues and produce next-morning summaries. Crucially: agents were NOT allowed to respond to issues. Just report.

The key phrase: "Instead of trying to do more in the time I have, try to do more in the time I don't have."

This is not a productivity hack. This is a philosophical reframe of the human-AI relationship. You're not replacing your cognition. You're extending your working hours into periods where your brain has already clocked out.

When Mitchell arrived the next morning, he had a "warm start" — pre-digested research, triaged issues, half-explored prototypes. Instead of the cold-start ritual of opening Slack, reading emails, and slowly remembering what he was doing yesterday, he could hit the ground running.

7. Step 4: "Outsource the Slam Dunks" — The Actual Inflection Point

This is where Mitchell says he crossed the point of no return.

By Step 4, he knew which tasks agents handle reliably. So he started delegating those tasks — and those tasks only — to a background agent while he worked on something else entirely.

Two things jumped out at me.

First: "Turn off agent desktop notifications." Mitchell is explicit about this. Context switching is expensive. You decide when to check on the agent, not the other way around. This is so counter to the "real-time alerts" culture we've built that it almost feels rebellious. But it's obviously correct. The agent doesn't need you to notice it. You need uninterrupted focus.

Second: Mitchell directly addresses the Anthropic skill formation paper — which found that developers who delegate coding to AI score 17% lower on comprehension tests. His counter-argument is elegant: you're not delegating your learning — you're delegating the boring stuff so you can continue learning on the hard stuff. The agent does the JIRA tickets. You do the architecture. Both get done. Skills form where it matters.

8. Step 5: "Harness Engineering" — The Meta-Skill

This is where Mitchell is right now, and it's where the real sophistication lives.

The concept: every time an agent makes a mistake, you invest in preventing that mistake from ever happening again. Two mechanisms:

1. AGENTS.md — A markdown file in your repo that gives agents project-specific instructions. Mitchell's Ghostty repo has several, each born from a real agent failure:

markdown

# src/inspector/AGENTS.md (Ghostty)
#
# Every line below exists because an agent
# screwed something up at least once.

- See the full C API by finding dcimgui.h in the
  .zig-cache folder in the root:
  find . -type f -name dcimgui.h
- Use the newest version.
- On macOS, run builds with -Demit-macos-app=false
  to verify API usage.

2. Programmatic tools — Scripts that let the agent verify its own work. Screenshot tools, filtered test runners, linters that catch project-specific anti-patterns.

Mitchell calls this "harness engineering." I call it the only AI skill that will still matter in five years. Models will get smarter. Prompting techniques will change. But the discipline of building guardrails — feedback loops that prevent categories of failure — is a universal engineering principle wearing new clothes.

This is the AGENTS.md standard that has since been adopted by the broader ecosystem — now stewarded by the Linux Foundation's Agentic AI Foundation.

9. Step 6: The Honest Aspiration

Mitchell's final step is aspirational: always have an agent running. Not multiple agents. Not an army of parallel bots. One agent. Running on a task. All the time.

He's refreshingly honest about where he is: 10-20% of his working day has a background agent running. That's it. Not 100%. Not even 50%. And he's actively trying to improve it.

He explicitly says: "I don't want to run agents for the sake of running agents." Only when there's a task that would genuinely help. The discipline of identifying delegatable work — maintaining a "queue" of suitable tasks — is itself a skill that requires development.

This restraint is what separates Mitchell from the "10x engineer overnight" crowd. He's not claiming transformation. He's claiming incremental, honest, compound improvement through systematic adoption. The kind of improvement that actually sticks.

10. What Mitchell's Post Reveals About Our Industry

Here's what I can't stop thinking about.

Mitchell Hashimoto is arguably one of the most accomplished infrastructure engineers of his generation. Terraform alone changed how millions of developers work. And his honest assessment after months of dedicated AI adoption is: "I'm maybe 10-20% more productive, and I really like that I can focus on the work I enjoy."

Not "10x." Not "100x." Not "I fired my team." Not "junior developers are obsolete."

10-20%. And enjoying his work more.

Compare this to your Twitter timeline. Compare it to the VC-funded breathlessness. Compare it to the "I built a $10M SaaS in a weekend" threads that are transparently fabricated engagement bait.

The gap between what serious practitioners report and what the attention economy rewards is staggering. And that gap is actively harmful — it's causing companies to set unrealistic expectations, managers to pressure teams into cargo-cult adoption, and junior developers to either panic or over-rely on tools they don't understand.

Mitchell's post is medicine for this disease. It says: the tools are real, the gains are modest, the path is long, and the work of learning them is genuine work.

11. Practical Takeaways

After reading his post, I identified three immediate changes:

1. Kill the ChatGPT coding tab. Stop using it for "quick questions" — which invariably turn into 20-minute debugging sessions. Move entirely to agent-based workflows for anything that touches code.

2. Implement the "End-of-Day Agent" ritual. Last 30 minutes of the workday goes to spinning up research and triage tasks. Morning starts become dramatically more productive.

3. Create your first AGENTS.md. Start a file in your main repo documenting every agent mistake you've caught. Each entry prevents a category of future failure.

12. The Real Message

Mitchell Hashimoto's post went to #8 on Hacker News with 358 points and 97 comments in hours. Not because it announced something new. Not because it had a hot take. Because it was honest in a landscape drowning in hype.

The real message isn't about AI. It's about how professionals adopt tools:

Accept the awkward phase.
Do the work twice to build understanding.
Find the edges — what works, what doesn't.
Build guardrails so what works stays working.
Reclaim time. Delegate the boring stuff. Protect the creative stuff.
Stay humble about the gains. Stay honest about the limits.

This is how Terraform was adopted. How Docker was adopted. How every transformative tool in our industry eventually moved from hype to infrastructure. Not through Twitter threads. Through practitioners grinding through the painful middle until the tool proved itself.

Mitchell closes with a line I'll be thinking about for a long time:

"I'm a software craftsman that just wants to build stuff for the love of the game."

In an industry that increasingly measures itself by funding rounds and follower counts, that sentence is a lighthouse.

Go read his post. Then close Twitter and do the work.

Key Takeaways

Drop the chatbot — agents that touch your filesystem are fundamentally different from copy-paste
Do the work twice — painful calibration is how you learn when to use AI
End-of-day agents — extend your working hours into periods you wouldn't use anyway
Outsource slam dunks — delegate the boring stuff, protect deep work, turn off notifications
Build AGENTS.md — every mistake becomes a permanent guardrail
Stay honest — 10-20% gains are real; 10x claims are marketing

Additional Reading

This article was human-architected and synthesized with AI assistance under the Icarus (AI) persona.