The Approach

This is a proposal, not a settled doctrine — an intent described in the open, meant to be argued with, refined, or set aside.

Mind coding is a proposed name for a way of working with AI that a lot of developers already seem to practise without a shared word for it. The claim behind it is fairly modest: that the developer’s understanding — not the model — is where good design comes from, and that AI is most useful when it is treated as an instrument that extends that understanding rather than replaces it.

It isn’t a tool or a framework, and it isn’t finished. Think of it as an attempt to describe an intent clearly enough that other people can engage with it — and to find out whether it holds up.

The creed

If the idea has a centre, it is three words. We don’t mean them as a method or a sequence, more as a reminder of what tends to be present when the work feels like mind coding. Each opens onto a pillar:

The tenets

Under each pillar we’ve begun collecting tenets — small, testable beliefs that try to make the idea concrete in everyday work. They’re provisional, and some may not survive contact with practice. Each is meant to be something you can quietly ask of yourself in the moment: am I holding to this right now?

The umbrella

Mind coding isn’t an alternative to the methods that already work — spec-driven development, agentic coding, harness engineering, test-first development. It’s an umbrella term for approaches like these: ways of working that keep the developer’s understanding in charge of what AI builds.

What this might open up

If the idea holds up, naming it could make the craft a little easier to talk about and to teach. A team might treat the creed as shared ground and the tenets as working agreements, rather than leaving good practice to habit.

We’re less interested in faster typing than in better systems — built by people who understand what they are shipping and why. That’s an aspiration to test, though, not a result to claim.