October 8, 2026

Lost, with two AIs on board

A long conversation with Claude and ChatGPT, a draft I thought was finished, the doubt that sent all three of us back to the beginning — and what it became in KaKeKiKoKu Studio 1.19.

After 1.18, KaKeKiKoKu Studio started calling itself a knowledge system. The words changed, and one part of the product changed with them: the navigation tree began to show relations, not only files. But something still felt off, and I couldn’t say what. It was the itch you get when a sentence is true and the thing it describes hasn’t caught up with it yet.

So I worked with two AIs in parallel, as I often do. I opened one conversation with Claude and another with ChatGPT, gave both the same long and rather messy introduction, and then carried each answer over to the other. I was the bridge. I asked them to treat each other as equals and not to agree with me just because I’m the human in the room. I also warned them that I wasn’t sure I was asking the right question.

Going wide

The question was easy to write and hard to answer: what is this product, really? From there the conversation went everywhere.

Should the files on disk still decide how knowledge is organised, or should the disk be one view among others? Could a project have a single source, with the code or the novel “compiled” out of it, the way a compiler builds a program? Did we need types, categories, registered concepts, tags on every block? A new kind of file that mixes content and knowledge? Markers inside your source code, so KaKeKiKoKu knows which section talks about which function?

Every answer was sensible, and most of them opened a few more doors. Some of my own ideas were, let’s say, adventurous. At one point I felt overwhelmed by how much there was to weigh; at another I pulled the whole thing back to something much smaller. And once I had to give both AIs a gentle telling-off: they had started polishing my ideas instead of thinking for themselves, which was exactly what I had asked them not to do.

It felt like sailing by intuition. Logic mattered, but I didn’t know where the coast was.

The question that got me out

What finally helped was a plainer question: what am I actually trying to fix?

The answer was already in my daily work. Knowledge changes. A decision gets revisited, an assumption stops being true, a line of work turns out to be a dead end. When that happens today, the knowledge that depended on it doesn’t find out.

KaKeKiKoKu already notices when a file changes and asks for its context to be reviewed. I have watched what happens next more than once: an AI gets the warning, decides nothing important changed, acknowledges it and carries on, while one section that did matter slips through. The AI isn’t being lazy. It is focused on what you asked it to do, and keeping knowledge tidy feels like a detour. Better models soften that, but I don’t think it ever goes away completely.

When a rule shapes twenty places across a project, I want to know which ones need another look after it changes, without searching for words and hoping I found them all.

The answer we almost published

After all the types, compilers and source markers, we settled on dependencies. A piece of knowledge would declare what it depended on, and a significant change would leave the dependent pieces waiting for review. It felt small compared with everything we had discarded.

We wrote it down, put it in the roadmap and prepared this article. The plan had become Studio 2: dependencies would change the format, so we would make a major release and use the occasion to look at other format improvements too.

Then the day came to publish, and I stopped. We already had relations. Why were we designing another kind of connection?

I took that doubt back to both AIs with the same request as before: question it. I wanted to find out whether it was true. By then all three of us had spent quite a while agreeing on the previous answer.

The arrow was already there

A relation already connects a description, a section or a subsection to another piece of knowledge. Its description says what that connection means. An arrow might mean that some code follows a rule, that a document explains a decision, or something quite different. Its direction tells us which side declares the relation. It doesn’t reliably tell us who should review their work when the other side changes.

Take three pieces of knowledge: A points to B, and B points to C. If B changes substantially, both A and C deserve a look. One relation comes in and the other goes out; that alone gives us no reason to ignore either of them.

That brought the proposal back to the product we already have. We would add review tracking to existing relations. When editing knowledge in Studio, you or your AI would say whether the change calls for a review. A small correction could avoid creating new work, while reviews left by an earlier change would still be waiting.

The useful parts of the earlier plan survived: your AI would see the pending reviews when it reads the knowledge, sync would list what needs attention, and a review could end with an edit or an acknowledgement that the content still holds.

Then came the awkward cases

Then I raised a practical problem with simply marking things for review: someone can edit the files outside Studio, or merge changes from another branch. The application needs to notice those changes too. I suggested storing a fingerprint of the content when a relation is established, so it could be compared later.

We worked that into a fingerprint of the content accepted at each end of a relation. Studio could compare it with the actual content later, whoever edited it. Acknowledging a review would leave the knowledge itself unchanged, so that action alone would not trigger another review.

I also suggested a version counter to reduce the number of files a small correction might touch, knowing it would miss outside edits. Claude added a fingerprint per block to catch those edits; ChatGPT found a case that broke the combination. Two branches could both call different content “version 8”, each with a matching fingerprint. After a merge, a relation could look up to date even though it had accepted the other text. Claude checked the case and withdrew the combined proposal.

The fingerprints mean more changes in Git when Studio updates those records across connected files. I can live with that. We also considered keeping lists of equivalent fingerprints to reduce those writes, and I decided against adding that machinery. The application can do the repetitive work; I want the rules we have to understand to stay manageable.

None of this tells an AI whether its review was thoughtful. It can still call an important change harmless. The aim is to keep the relevant connections in front of whoever is working, with less searching and less to remember.

What shipped in 1.19

A simpler plan also turned out to be a shorter road. Studio 1.19 adds review tracking to the relations you already have. When a description, a section or a subsection changes, Studio flags the knowledge at the other end of each of its relations, whether the relation comes in or goes out. You see it in the sync panel under Relations to review and in the navigation tree, and your AI sees it when it reads that knowledge.

When you edit connected knowledge in the application, you choose how to save it. Save asks for the related knowledge to be reviewed. Just save is for a typo: it creates no new reviews and leaves the ones already waiting in place. Before deciding, you can unfold the list of relations the change touches without leaving the editor.

A review ends the way we planned: you open the knowledge that needs a look, check what changed at the other end, and either edit it or give your conformity because it still holds. You can do that for one review or for all the reviews of a resource. Your AI makes the same choice explicitly every time it edits, is told straight away which resources now need a review, and has its own commands to check and acknowledge them. When it creates context, it also has to declare its relations, or say there are none; I had seen AIs leave them out too often.

Edits made outside Studio, in another editor or after a merge, are noticed too: sync compares the content with what each relation last accepted and lists what needs attention.

Format 1.1, and what it means for your files

The fingerprints live in the .wuniq format, which moves from 1.0 to 1.1. Its version is separate from the application’s. Studio 1.19 reads your existing files as they are and updates each one only when it saves it; opening a project or running sync does not rewrite them.

Studio 1.18 cannot edit 1.1 files that contain relations, so update every computer you work on. The new version also looks ahead: a file written in a newer format is reported and left untouched, instead of being misread.

Also in 1.19

Search is more precise. Put a phrase in quotes to find those words together, search only the project you are working on, and use More… to choose between names, context and file content. Results are less noisy, and opening one takes you to the match it shows, even in long lines of text.

The application looks more consistent, with a single family of icons, an aligned navigation tree, and a more careful welcome screen and themes. And an important fix: the web application saves the text of a relation again, including when you describe a relation created by dragging it.

One more change came from a last review before release: a damaged context file, or one from a newer version, no longer gets in the way of the rest of the project. Sync points it out, and everything else, including restoring a backup, keeps working.

On working with two AIs

Carrying answers between Claude and ChatGPT was useful. Each found things the other had missed, and the version-counter case was a particularly clear example of an idea improving because somebody tried to break it.

Earlier, seeing them reach similar conclusions had given me confidence. The draft I nearly published is a reminder of how easily that confidence can arrive too soon. I had helped lead us into the same complication. Having three voices in the conversation didn’t make the conclusion right; we still had to question the premise and try concrete cases.

This article arrives later than I first intended, and it now announces what it once only planned. I’m glad I held it back. I want KaKeKiKoKu to help us keep knowledge current when a project changes its mind, and 1.19 is a smaller, clearer step in that direction than the one we almost took.