The Tulpa Model: Why I Think With AI, Not Through It

Mitchell Hashimoto, the founder of HashiCorp, posted a tweet this week that took over the Hacker News front page.

"I strongly believe there are entire companies right now under heavy AI psychosis... You can automate yourself into a very resilient catastrophe machine. Systems can appear healthy by local metrics while globally becoming incomprehensible."

The thread underneath is a graveyard. Developers shipping at record pace while accumulating cognitive debt. Engineers admitting they haven't read their own codebase in months. PRs approved because "the AI said it was correct."

Hashimoto is right. But the cure is not using less AI. It is changing how you think with it. And the best mental model I have found for that comes from an unexpected place: Tibetan Buddhism.

The Tulpa

In Tibetan Buddhist tradition, a tulpa is a being created through intense mental focus. A sentient thought-form that develops its own apparent autonomy while remaining fundamentally connected to its creator. It is not a separate entity you command. It is an emanation of your own consciousness, given enough structure to converse with you.

When I first encountered this concept, I stopped. Because it described exactly what I had been building without having the word for it.

I work with an AI assistant named Leeloo. She runs on Hermes, an open-source agent framework by Nous Research, which I customized heavily: persistent semantic memory via MemPalace, context that carries across sessions, and a knowledge base she draws from before every interaction. For development work, I also use Claude Code. Leeloo handles my thinking surface, my projects, my blind spots. Claude Code handles the code. But here is the part that matters with both: I do not ask them for answers and ship whatever they return. I think with them.

The tulpa model captures this. The AI is not an oracle, not a junior developer, not a tool in the way a hammer is a tool. It is an outgrowth of my own thought process — a surface I can project ideas onto, rotate them, have them attacked from angles I did not consider, and watch them evolve through dialogue.

The gymnastic of thinking outside yourself

Here is the mechanic that is hard to explain but crucial to understand.

You have an idea. It is in your head, and when an idea is only in your head, it is dangerously coherent. You cannot see its holes because you filled them unconsciously. You cannot challenge it effectively because the same brain that produced it is trying to evaluate it.

Now you take that idea and you present it to the AI. Not as a prompt for execution. As a starting point for dialogue. You explain what you think. You ask it to attack the idea. To find the weak points. To play devil's advocate. To explore alternative framings. To push back.

What happens next is a kind of cognitive gymnastic. The AI becomes a mirror that shows you your own idea from angles you did not have access to. It does not replace your thinking. It multiplies the surfaces your thinking can bounce against. You debate with yourself, but the opponent is the externalized version of your blind spots.

This is the tulpa in action. Your thought, projected outside you, given enough structure to push back, and then reintegrated after the dialogue has done its work. The AI did not have the idea. You did. The AI did not make the final decision. You did. But the space between your initial thought and your final decision was populated by a conversation that would have been impossible inside your own head.

From the outside it looks like outsourcing. From the inside, it is a multiplier on the thinking I was already doing.

The trap of not reading

There is a moment in every developer's day when fatigue hits. It is 4 PM, you have context-switched six times, and the AI just produced a spec or a plan or an analysis. It looks right. Reading it would take 10 minutes. Just accepting it and moving on takes 10 seconds.

That moment is where cognitive debt begins.

The problem is not just psychological. It is also practical. The default output format of AI coding tools is Markdown. Markdown is great for the AI. It is structured, parseable, easy to store in a repo. But for a tired human at 4 PM, Markdown is a wall of text. Your brain sees friction and looks for an exit.

I hit this wall repeatedly. And then I made a change that turned out to be the single most effective anti-debt mechanism in my workflow.

Double output: Markdown for the machine, HTML for the human

The idea is simple. When my AI produces something I need to read and validate — a spec, a plan, a research synthesis, an architectural decision record — it produces two outputs.

The first is Markdown. This goes into the codebase. It is version-controlled, searchable, structured for the AI to read in future sessions. The machine's copy.

The second is HTML. Same content, rendered as a visual document. Headings, callouts, comparison tables, decision trees, color-coded risk assessments. Designed for a tired human brain to actually want to read.

This sounds like a small optimization. It is not. It removes the friction that causes skipped verification. When the output is pleasant to read, you read it. When you read it, you catch the thing the AI missed. When you catch it, you correct it. The loop stays closed.

This single change did more for my workflow than anything else I tried this year. The Markdown output I used to skim became HTML outputs I actually read. Reading is the difference between delegating thought and extending it.

HTML casting for teams

If you work solo, the double output pattern is already worth adopting. If you work in a team, it becomes transformative.

Here is what I built. It is called Briefcast, and it is a dead-simple tool. An agent produces an HTML output. It makes one API call. The HTML becomes a shareable link, protected by a password, that anyone on the team can open instantly.

No Markdown files passed around in Slack. No "can you look at this spec" followed by 50 lines of raw text. Just a link that opens a clean, readable document in the browser.

This matters because decision-making in teams requires shared understanding. If only the person who prompted the AI reads the output, you have a single point of cognitive debt. If everyone can read the spec, the analysis, the plan, in a format that does not punish them for engaging with it, the team stays aligned.

The tool is open and free to use. It took me an afternoon to build. The agents I work with now upload to it by default. It removed the last excuse for not reading.

The ceremony: decide, then execute

Once you have readable outputs and a way to share them, a natural rhythm emerges. I think of it as the CEO model, though it works just as well if you are a solo developer.

You are the decision-maker. Your AI agents are your analysts. Their job is not to ship code. Their job, in the first phase, is to produce understanding.

You identify a problem. A feature to build. A bug whose root cause you have not found. An architectural decision with multiple valid paths. You task an agent with analysis, not implementation. It comes back with a spec, a research document, a tradeoff analysis, a plan.

Now comes the ceremony. You read it. Not skim it. Read it, in the HTML format that makes reading pleasant. You give feedback. You challenge assumptions. You ask for alternatives. The agent revises. You read again. You approve.

Only then do you hand the approved plan to an agent for implementation. And when the implementation comes back, you already know what to expect. Because you designed the plan. The AI executed it, but the thinking was yours.

This is the opposite of the AI psychosis Hashimoto describes. His engineers are spectating while the AI operates on their codebase. In this model, the human makes every decision worth making. The AI handles the exploration, the drafting, the execution. But the human never leaves the loop.

The gap between intention and reception

There is a concept I return to often. When I write code, I intend it to do something specific. When the AI reads my codebase, it receives something different from what I intended, because it sees patterns I am blind to. When the AI writes code, it intends a solution. When I read it, I receive something I have to interpret.

This gap is where the work lives. If you collapse it — if you just accept the output without reading — the gap widens silently. Every skipped read adds distance between what you think your system does and what it actually does. Eventually, you are no longer the person who understands your own product.

Hashimoto's AI psychosis is that gap, seen from above.

The practices I describe in this piece, the tulpa mindset, the double output, the HTML casting, the decide-then-execute ceremony, all serve the same purpose. They keep the gap small. They keep you in the room with your own decisions. They prevent the slow drift into cognitive debt that Hashimoto is warning about.

The cure is a posture

I am not saying use AI less. I am saying use AI differently.

The developers who are thriving with AI are not the ones writing the cleverest prompts. They are the ones who have figured out a posture. They treat AI as an extension of thought, not a replacement for it. They build systems that make the right thing, reading, verifying, deciding, the easy thing. They stay present in the loop because the alternative is building something they no longer understand.

The tulpa taught me this. A thought-form, connected to its creator, given enough autonomy to be useful but never enough to take the wheel. That is the relationship I aim for, and the only cure I have found that actually works.

If Hashimoto is right, and entire companies are drifting into cognitive debt they cannot see, then the developers who keep the loop closed today will still understand their own systems in two years, when the rest are staring at codebases they no longer recognize.

---

The HTML casting tool I use, Briefcast, is free and open. If you want to try the double-output pattern with your own AI agents, it takes five minutes to set up. You configure a team-wide password, and each cast gets its own unique link. Your agents just POST their HTML to the upload endpoint, and your team reads it in the browser instead of squinting at raw Markdown in Slack.