These tools are fast, and they are also prone to slop, drift, and confident nonsense. Here are the protocols I use to actually ship something.
You picked up a task from the board. Jira, Trello, whatever your team used. Then you opened VS Code or PyCharm,
found the module, and started holding Shift, clicking your way through function after function
until you understood that specific corner of the codebase.
Then you wrote the code the way Uncle Bob keeps telling us to. Test first. Then the function body. Respect every SOLID principle. Keep the functions small and the names honest. It was slow, but at every moment you knew exactly where you were.
Now you are somewhere in the middle of a refactor you did not read, and Claude asks you a question about it. You have no real sense of what is going on, so you scan the options for the one marked (Recommended) and click it, because you would rather not let this decision interrupt your scrolling.
Hours pass. Tokens burn. At the end there is a clean, refactored codebase, a dozen Opus and Sonnet agents that spawned just to review functions you never looked at, and a results table full of statistics you could not define if someone asked. Every number looks right. You feel very smart.
Then you actually run it, and you hit the first bug. You ask what that was. It is a small one, the fix is easy, it just needs a full rerun, which takes a few hours. The rerun finishes and introduces you to the next small, easy-to-fix bug.
Days go by. You have not shipped anything.
These tools are genuinely useful, and they are also prone to slop, drift, overengineering, and hallucination. Both things are true at the same time. The bottleneck was never how fast the code gets written. It is whether you still know what changed and why.
So you have to show up armed to the teeth. Here are the findings and protocols that actually help me ship things.
Think about the problem. Then think about it again. Then start writing the prompt, and give the prompt itself real time. A few minutes of thinking and reading the code yourself is worth hours of fixing, refactoring, and rerunning later.
Ask Claude or Codex about the parts of the codebase you genuinely do not know. That is what they are good at. But do not hand them the decision of where and how your code should change. That part stays with you.
If you are about to run experiments, have them build the results table first, with placeholders. Verify every row and every column. Then let the experiments start. You do not want to spend hours of compute only to find out the results are not reported in the metric you actually care about.
Do not accumulate a pile of .md files and inline comments. There are two reasons.
First, clean code reduces the need for documentation. Given how much of your repository these models can hold in context, you do not need comments explaining what is already clear from the code, and you certainly do not need paragraphs in a markdown file repeating what the code already says. Keep them for what the code cannot show on its own, like intent and constraints, and delete them once they go out of date.
Second, stale comments can mislead the model. If a comment no longer matches the code, the model may trust it and make the wrong decision, and you will not catch it while you are scrolling and clicking (Recommended).
There is a real pull toward always reaching for the Pro Max Ultra Plus tier of whatever you are using. In my experience it is not free. More thinking also means more surface area for the model to talk itself into something, so the odds of a biased or overbuilt answer go up along with the capability.
Match the model to the task instead of defaulting to the largest one.
Watch for three signals: the codebase starts feeling unfamiliar to you, Claude or Codex begins making decisions that look arbitrary, or your token consumption climbs for no obvious reason.
Any of these can have other causes, but when I see them I check the codebase first. Usually there are too many unfinished changes, leftover files, or more complexity than the task needs, and all of it forces the model to explore more and resolve more ambiguity. That is billed, so you hit the limit sooner, and the natural conclusion is that you need a bigger plan. Often you just need a cleaner repository.
Not just as a place to put your code. Use branches for the different things you are working on, and let Claude or Codex commit and push each meaningful piece of work.
The reason is concrete. These tools run git status and git diff constantly to figure
out what changed, including while you are scrolling and not paying attention. You want that view to contain only
the changes relevant to the current task, not leftovers from an experiment that failed two hours ago.
For a bonus, open a pull request and have a separate session review it.
My usual loop: I give my prompt to Claude, it implements the piece I asked for, and then, right before any heavy run, I hand the whole thing to Codex for a second opinion. Codex is much faster right now, which makes it a good fit for a mid-task review.
We are working on {your current goal}. This is the prompt I gave Claude,
it has made a few changes, and here is its result. Will you verify it?
I don't want you to talk about small and unimportant things. If it was OK,
respond with OK. Otherwise, give me a copy-paste ready prompt so I can give
it to Claude.
Don't be too fine grained. Only mention things that are important or are a
real bug. The goal is to double check everything and speed up the process
so we reach {your goal}. So be unbiased, don't overengineer, and bring up
only the important and crucial things. If everything is correct, just
respond with OK.
Don't change anything by yourself.
Here is what I gave to Claude:
{your prompt}
Here is Claude's output:
{the output}
The constraints in that prompt are doing most of the work. Giving OK as a valid answer makes the
reviewer less likely to go looking for problems just because it feels like it has to find something, and
forbidding it from editing anything keeps the review a review.
I know there are plugins that wire Claude and Codex together directly. For me that is overengineering. Maybe at some point I will sit down and understand how they work, and then this will get another protocol.
You would be surprised how much irrelevant material, and how many long analyses you never asked for, find their way into these files. Everything in there is in context for every single request, so it is Protocol 2 with a much larger blast radius.
Read them. Keep them short, simple, and concise.
Last, and not the least, but actually the most important one. Use a fresh session as often as you can. In my experience very long sessions eventually become less reliable. After enough back and forth, the model is carrying around old assumptions and decisions that stopped mattering hours ago.
I know starting over feels expensive. You are looking at a long conversation full of context and dreading having to explain all of it again. Two things make it easier than it looks.
Which is really the whole list in one line. Almost every protocol here pays off through the same mechanism: a clean codebase and a clear head are what let you throw a session away without losing anything.
Written in the time of Claude Opus 5 and GPT-5.6 Sol in Codex. These things move quickly, so some of this will age badly.