One model to plan, another to execute: how I work with AI
3 minutes read ·When I work with AI agents, I don't hand an entire request to a single model. I split it in two: a high-end model designs the plan, a more affordable model executes it. Between sessions, a simple CHANGELOG.md file serves as their shared memory.
Reasoning is expensive, execution far less so. Better to pay for the first only once.
Planning with a high-end model
The hardest part of a task isn't writing the code, it's understanding: reading what exists, spotting dependencies, anticipating side effects, choosing an approach. That's where a top-tier model makes the difference. I ask it for a precise plan: the files involved, the steps in order, what must not change and how to check that the work is done.
Executing with a more affordable model
Once the plan is approved, execution becomes a well-scoped task: applying clear steps in identified files. A faster, much cheaper model handles it very well. Since most of a session's volume usually lies in execution, that's where the savings show, without cutting corners on the quality of the thinking.
This split has its rules. The plan must stand on its own, because the second model won't redo the first one's reasoning. If the code contradicts the plan, the executor must stop and flag it rather than improvise. And for a two-line fix, splitting is pointless: the preparation would cost more than it saves.
A CHANGELOG.md as working memory
A model starts every session with no memory of the previous one. Without landmarks, it rereads the project, guesses what has already been done and sometimes redoes existing work. That's why I keep a CHANGELOG.md file at the root of the project, where every completed task is logged.
- Most recent entries at the top: by reading the first lines, the model immediately knows the context it's working in.
- For each task: the date, what was done and why, the files touched and any open points.
- Short entries, with older ones archived: an overly long log would eat up the very context it's meant to save.
Git history tells you what changed; the log tells you why, and what's left to do. One instruction in the project's guidelines closes the loop: read the latest entries before starting, add one at the end. The planner and the executor then start from the same context.
What I take from it
Both habits rest on the same idea: AI does its best work when someone sets the frame. I decide how the work is split, I write the rules, I approve the plan and I review the result. The models execute, each in its place.
