I don’t really ask myself which model is best anymore. That question feels sterile, like standing in a hardware store and arguing over hammers while the wall remains unbuilt.
Instead , I think in terms of jobs. What’s the actual work in front of me? What shape does it take? Once I see that, the tools fall into place. The rhythm has become second nature:
I don’t really ask which model is best anymore. That question feel sterile , like standing in a hardware store and arguing over hammers while the wall remains unbuilt
Think
When I’m at the very beginning of a project, I need space to reason things out. A blank page with a voice pushes back just enough. This is where chat-style tools live best , not as answer machines but as working rooms. I treat them like a whiteboard I can argue with.
Before any code exists , I’ll ask: What’s the job in one line? what are the inputs , the constraints , the pass check? It’s remarkable how quickly clarity arrives when you’re forced into that compression. From there, I sketch workflows , ask for possible risks and let the model toss edge cases at me.
Thinking aloud like this is less about brilliance and more about not wandering down blind alleys. I leave the room with a crisp little map and usually a handful of test cases that will travel with me into the next stage.
Build
Once I’ve got the map , I switch rooms. This is where code assistants earn their keep. They don’t get to design. They only get to lay bricks. I already know what the wall should look like. Now it’s about stacking.
Here the prompts are different. No open-ended exploration , no rabbit holes. I’ll ask for a first pass on a function or for changes limited to a single edge case. Deltas , not rewrites. If I let the assistant start redesigning, the plan dissolves. So I hold the line: five minutes max per turn, commit or discard and I read every diff with my own eyes.
What this gives me is speed without surrender. I’m not outsourcing thought , only the typing. And there’s relief in that separation. Design belongs to me , execution is shared.
Remember
The last room is quieter. By now the code runs, the tests pass and the temptation is to close the tab and move on. But this is where the real leverage lives: memory.
I use a knowledge base, Obsidian most of the time. Not as a display cabinet but as a living workshop. I capture the essentials: the one-line job, the rubric that held up , the test table and all the plans and flows even the draft ones and finally the prompts that worked or the elements of them that did. And I always write down one lesson , no more. Just a single line that will matter later.
The magic happens when retrieval enters the picture. A search , or a lightweight RAG layer if you want to get fancy , pulls back rubrics and tests I’d otherwise forget. Not to mention plans and architectural decisions that are universal. This can be loaded directly onto my thinking space for the next project. It’s like leaving myself small tools on the workbench for tomorrow.
What you capture isn’t for display, it’s for tomorrow’s self who doesn’t want to start empty.
The Hand-offs
The beauty of this flow isn’t in the rooms themselves, but the way they hand off to each other. A rubric and test cases migrate cleanly from Think to Build. Passing tests and one line lessons flow into Remember. And when I return to Think with a new project, I don’t start empty. I start by pulling something that worked before.
A Small Example
Take something almost trivial: a task classifier for messy notes. The labels are simple – Action , Schedule , Delegate , Drop
In the first room, I’ll sketch a six-line rubric an a little table of test cases. in the second, I’ll hand that table or create test stubs that will be handed over to the code assistant and have it build a function called classify(note) along with tests. In the third, I’ll save the rubric , the JSON of the tests and the single lesson the project surfaced like : “Dates without verbs default to Schedule with a nudge.”
That’s it. The loop is closed. And the next time I need a classifier , for sentiment , for tags or for anything else. I’m not starting over but building on the knowledge that I have already gained.
The Real Discipline
The hardest part of this flow isn’t the tools, it’s the rituals. Start with a one-line job. Don’t let prompts sprawl. Keep turns short. Write down one lesson only. Retire what doesn’t earn its keep.
It sounds small but honesty compounds. You end up with a system that doesn’t just deliver results but delivers them without chaos.
Closing
I’ve learned to keep these rooms separate: Think to map , Build to lay bricks , Remember to hold the wins and the thinking to get there.
The tools may look different but the value is the same. By keeping the loop tight , speed arrives almost by accident and that’s the lesson I return to again and again.
Use beats outcome. Always.
Here are some of the tools I use in each room:
Thinking
Building
A few others to check out:
Remembering
Leave a Reply