Building with AI: my methodology

I learned to write code before I could lean on a model to do it for me. So when the tools arrived, I had a choice most people did not stop to make: hand the work over and hope, or work out how to use the help without losing the thread of what I was building. I chose the second one, and I built a way of working that lets me ship real, production software on my own, in weeks, without the project turning to mush the third time an agent forgets what it decided last Tuesday.

This is that method. It is not a prompt trick. It is a small set of habits and one boring idea: the project needs a memory that lives outside the chat. This piece is the map. Each part links to a deeper writeup if you want it.

The problem nobody warns you about

A coding agent is brilliant for an hour and forgetful forever. Each fresh session it wakes up knowing nothing about your project except what you paste back in. Left alone it will re-decide a settled question, pick a different library than the one you already use, and quietly contradict the choice it made yesterday, because yesterday is gone.

That is the whole game. Not “can the model write a function” (it can), but “does the tenth session agree with the first.” Everything below exists to make the answer yes.

Start on paper

Before any of that, I take a step back into the past and pick up a pen. A whiteboard and a marker, or just paper. I have both and I use both.

There is a practical reason and a human one. The practical one: I want to walk into a fresh agent with as much real thinking about the project as I can, and thinking with your hand is slower in a way that makes it better. The human one: I spend most of my hours in front of a screen, so a few minutes with my eyes on paper feels good, and it keeps me attached to an era before all of this, when ideas got worked out in ink and not in a chat box.

What goes on the paper is small and specific. The core thing the app does. The questions I have for myself. The things I do not want to happen. What a finished version actually looks like. Solo, I tend to have more questions than statements, and that is fine. The goal is not a plan, it is context.

The alternate, when I want to move fast: a fresh chat with a capable model, used as a thinking partner rather than a builder. Same questions, faster, and it pushes back in a way paper cannot. Either way I come out with the raw material for the memory, and a photo of the whiteboard or a written up prompt goes straight into the tool that builds it.

The whole shape

Here is the method on one page. You ideate once, on paper or with a model. That seeds a memory that lives outside the chat. Then every slice runs the same short loop, and a log of what got built feeds the next turn.

The pieces

The method is a few habits and a handful of tools. Two of the tools I built, three I adopted, and one command runs them all. Each has its own writeup if you want to go deeper.

• A memory outside the chat. A set of plain files that hold the project’s decisions, so every session starts knowing them. This is context-system, a skill I built. How the context system works.
• A conductor. One command that reads where the project stands, picks the next slice, runs the right step, and teaches as it goes. This is build-flow, the other skill I built. Stop prompting, start conducting.
• Design, build, prove. The three steps in the middle of every slice, done by three skills I adopted from JS Mastery Pro: settle the decision, build only that, then prove it by running the real thing. The three skill loop.
• When the project is about security. The same method bends to a harder problem without breaking. The security case study takes it into a live security project.
• When the codebase outgrows your head. A second, derived memory that maps what the code actually connects to, and keeps the curated one honest. The two memories is that case study.

If you take one thing

Give the project a memory that lives outside the chat, and make every session read it first. The models will keep getting better at writing code. They will not, on their own, remember what your project already decided. That part is on you, and it is the part that decides whether what you build holds together.