Share your experiences

Posted 2026-08-09 • 6 min read

For years I've been writing master plans for people — a small document explaining what needs to be done and why. I started when I was deeply impressed by how Tesla formulated their master plan: literally one or two screens of text with clear plans and clear stages, articulated simply and convincingly — why, what, and how — and it stayed valid for decades. I've been using that formula for many, many years. The key is that the document articulates the strategic direction — it's not a to-do list. You read it and see the whole picture: where we're cutting corners now and where we'll fix them soon, that this feature looks like this today but will be different in a month or a year — so every next stage builds on the previous one. Back then I wrote such documents for people; recently I decided to start writing them for models.

For humans, such a document must be extremely compact and dense — it has to land, but without the nuances. Say you want to build a roadster: you're not going to write in the document about how hard it is to source batteries. That's understood anyway; you handle it behind the scenes — in meeting rooms, in personal conversations, in internal docs. The main document stays very short so that everyone roughly understands what we're doing and why. The details you simply can't put there.

With models it's completely the opposite. Ideally you do no preprocessing of your ideas at all — you lay out your entire thought process instead of trying to distill it into some perfect plan. I still call these master plans, because they do get distilled and improved — by the model. Written better, and prepared for working with a model: take all these ideas and pack them as compactly as possible.

Talk to it

You talk, a machine writes it down — every idea stays yours. What's critical is that the model doesn't distort your words and doesn't misunderstand you: it grasps as precisely as possible what you actually meant, and can fix your phrasing while understanding you better than anyone. That takes a very big model. The model is the typist and the translator, never the author. And in the modern world, a single entry in AGENTS.md is enough to keep agents from breaking your master plans — no sandboxes, no locked files, nothing else.

Instead of trying to figure out precisely what you want to build, you say absolutely everything you know and figure it out as you go. Everything on your soul: your fears, your desires, what you're sure of and what you're not, what you're throwing away and why. Change your mind mid-sentence. Whatever is in your head must end up spoken — all of it. Talk long, as long as you possibly can. The longer, the better. All of it goes into the master plan.

Voice, not text, because writing takes enormous resources — you'd exhaust yourself after a page and start cutting corners. Nothing stops you when you talk.

Let your innies speak

We all know the feeling of having a gut feeling and simply ignoring it. But when you talk to the model, nothing stops you — you can go deep, almost a form of therapy. And unlike those conversations, the model will actually understand and put all of it to use. The model can't talk to your customers: even having seen an enormous number of people, it doesn't know where you are right now and what's happening — but it can understand, if you share. So describe what you like and what you don't, going as deep as you can, and where your understanding ends, say exactly that and let the model explore. But if you can't grasp the key things yourself, the model most likely can't do it for you either.

I've designed the same things many times over — chats, event sourcing — and each time hit different problems, usually because there was never enough time to implement something the way it deserved. Fully persistent event sourcing ate the disk, because I never got around to making the queue ephemeral: that would've meant writing a pile of client code to carefully restore and resync state. With models, that's finally realistic. So I just talk all of it out — what I liked, what I didn't, which designs from Telegram still work fine and don't need reinventing (though they had their problems too, and I tell those as well), which problems I want to avoid this time. Raw experience like this lets the model design APIs, storage, whole systems almost autonomously — and out of it emerges my own distinct style of what I build and how.

Limitations of master plans

Master plans don't constrain anything technically — the model can still generate bad low-level code, so you still ban useEffect and useState, and set linters loose on the rest. Models also still can't reason about themselves: they can't predict the cost of a piece of work, how long it will take, how strictly your idea should be followed, or when a review is needed and when it isn't — you still have to design that process by hand. And high-level planning still depends on your personal skill: the model can't decompose well on its own. You can throw tokens at a problem, but the biggest limitation isn't even their cost — it's that tasks block each other. A run takes from a day to a week before you can move to the next stage, and you can't buy your way past that speed. That was true with people; it stayed true with models — which is probably why we're not seeing a thousandfold jump in productivity.

There has never been a better time

There was never anywhere to put your inner world: people don't listen, documents demand distillation. Never before could we talk endlessly and have it all actually used by something — or someone. Now we can, and it's time to start doing it at a much, much bigger scale. Your hidden gems are the most important thing you have — speak them.

@ex3ndr@ex3ndr@founders@ex3ndr