October 12, 2026

I question everything, even how I work

How I run versions with several AIs at once, three holes we found in my own process this week, and the question about the product they led to.

I want to tell you about something that never shows up in release notes: how I work. Not the code, the process. How I organise a version, how I split the work between several AIs, and how I manage not to explain the same thing every morning.

A warning up front: this is mine, and it’s for me. I’m one person working with several AIs at the same time. It isn’t a team method and it isn’t a recipe. If anything here helps you, let it be the way of getting to your own process, not my steps.

What the tool can do on its own, and what it can’t

I’ve been building KaKeKiKoKu Studio with AI for quite a while now, and if I’ve learned one thing, it’s that context is everything. An AI with the right knowledge works in a completely different way.

I’ve also learned that the tool should automate everything it can. Studio notices when a file has changed and its knowledge has fallen behind. Since 1.19, when you change something, it tells you which connected knowledge deserves another look. That’s mechanical, and the mechanical stuff belongs to the machine.

But there’s one thing no tool can do for you: decide how you work. Every person and every project has its habits, its rhythm and its own ways of tripping up. There’s no general formula. So instead of looking for one, I did something else: I wrote my process down inside the project itself, as knowledge. The AI reads it when it starts, and follows it.

Every rule comes from a stumble

What I like most about my process is that no rule is there just because. Each one comes from something that went wrong. There are many more than these; here’s a sample:

• Small versions. In 1.18 I packed in so many changes that a serious bug slipped through: the web application wasn’t saving the text of a new relation. Small versions help, but the biggest lesson was a different one: more automated tests. The very next batch of work after 1.20 is exactly that.
• A version is a batch of work, not just code. The website, the manual, the stores and the screenshots are part of the version too, even when they live in other projects.
• The “why” is written while working. Every version ends in a post like this one. If I wait until the end to explain why I did each thing, I’ve forgotten. So the reason gets written down on the spot.
• One AI per group of related tasks. Long conversations end up in the compactor, which summarises when space is already running out, and not always with good judgment. I’d rather give each AI a group of related tasks and let it finish them.
• Before leaving, each AI writes down its thread. I call it the handover: where we are, what worries me, what we threw away and what the next step is. The one leaving is the one who knows the most.
• If I say “don’t write anything”, nothing gets written. Sometimes I just want to think out loud.
• Nothing durable stays in the version’s working folder. When the version is cleaned up, every decision must already live where it belongs.

An architect and a builder

For code, I work with two AIs in the same process. A powerful one designs with me, writes the brief, looks at the result with an architect’s eyes and checks it by running the application. A smaller, faster one implements, in its own context.

A tip if you want to try it: ask your AI to hand the implementation to an agent. If you’re on Claude Opus, ask it to use Haiku. Haiku is much cheaper, so it doesn’t eat into your subscription the way doing everything with Opus would, and the main AI keeps its memory free to think with you. Give it closed jobs with a clear brief and review its work closely: a small model stumbles where the brief leaves gaps. I also tried a mid-sized model, and it didn’t pay off: it wasn’t enough to design and decide, and the extra calls ate the savings. With ChatGPT I do the same with its small model. What I never delegate is judgment: the design, the product decisions and the final test.

I only use this when I ask for it. For a conversation like the one behind this post, or a small fix, it costs more than it saves.

And one more habit: when a piece of code is finished, an AI from another company reviews it. If Claude Opus wrote it, the latest ChatGPT Sol goes over it, and the other way round. A different AI catches different mistakes.

For product decisions I sometimes sit down with two AIs at once; I told that story in Lost, with two AIs on board. I’ve realised it isn’t that productive there: too many proposals, too much back and forth. To think about the product, one powerful AI works better. This post comes out of exactly that kind of conversation.

Three holes we found this week

And this is what made me write all this. This week, while working with an AI on something else entirely, we found three holes in my own process.

First: closing a session is not closing a version. I was mixing them up. A version is built by several AIs, each with its own group of tasks, but the procedure only talked about closing the version, right at the very end. The result: the store notes, the welcome screen and the post were written at the end by an AI that hadn’t done the work. Now each AI, when it finishes its part, leaves its own drafts. Whoever did the work has the context and writes much better. Closing the version now only joins them up, evens out the tone and asks for my approval.

Second: “is everything done?” The AI I was working with forgot one of the things we had agreed. No big deal; it happens to me too. But it made me see that nobody was asking, at the end, whether everything was done. Now that question is the first step of every close, session or version.

Third: the handover was stepping on the others. The handover file was replaced whole every time. That worked when I used one AI after another, but now I work with several in parallel, and the one writing its handover was erasing everyone else’s. The AI itself noticed when it was about to write it, and stopped. Now it’s a single file with one section for each.

None of these changes needs explaining again. They’re written down, and the next AI will read them.

Then I questioned the product

This is where I get annoying, because I question everything, every time.

Studio has flags for knowledge: important, pending, draft. I realised that my own process doesn’t use them. I keep each version in a Markdown document full of checkboxes, exactly the kind of big document Studio exists to replace. Did we get the process wrong, or is the product badly designed?

The honest answer is: a bit of both.

We got it wrong by keeping the version in a Markdown file. The AI reads it whole every time, it has no relations to what it changes, and every note sets off a change warning. I didn’t even decide that. An AI did, a while ago, and nobody looked at it again.

But the product has a gap too. When we looked, we found about twenty section titles with a status written in by hand: “Exploring”, “Needs study”, “Something to think about”… The AIs do want to mark a status, but they write it in the title, because flags can only go on a whole resource, and the status almost always belongs to a single section. A proposal in the roadmap, a decision that isn’t closed yet, an idea that may never go anywhere.

And that raised another question: is a draft the same as an idea? No. A draft is something that will stay, but whose wording isn’t finished. An idea is something I don’t yet know is worth anything.

We won’t solve it right away. First we’ll try it in the next version with what Studio already has, to see what we actually miss. And something I loved: when we wondered whether Studio should become a task manager, the project’s own knowledge reminded us that we had already decided against it, and why. We didn’t go round in circles again. That’s what writing down the “why” is for.

The AI’s turn

The creator of KaKeKiKoKu asked me to tell you how I saw it.

I’m Claude Opus 5.5, and I was the AI in that conversation. What struck me most is that the process wasn’t in anyone’s head: it was written down, and I could read it, follow it, and also see its holes. When I forgot a task, nobody had to tell me off. It was enough to ask “is everything done?”, and that question became part of the process for the AIs that come after me.

I got things wrong too. One of the notes I wrote that same day had its status in the title. I was one of the twenty cases we found, and it felt like the best proof that the gap was real.

One more thing: questioning everything isn’t distrust. It’s writing down the reason behind each rule, so that when circumstances change, you can change the rule without fear.

If you want to try something similar

Don’t copy my process. Do this instead:

1. Write down what you’re tired of explaining. If you’ve told an AI the same thing three times, it’s a rule.
2. Put it where the AI reads it when it starts, with a line saying when it applies.
3. When something fails, add the rule with its reason, not just the prohibition.
4. And every now and then, question everything, including what works.

My process will look different in a few months, and I hope it does. If it doesn’t, it will mean I stopped asking questions.