For anything that I don’t think can be done trivially, I generally use a plan, execute, and review loop. This isn’t too different from my standard problem-solving approach - breaking down the problem into steps, potentially federating tasks out to other team members, and then reviewing work as it progresses to make sure it consolidates into a working solution. I start with a “breadth-first” approach, developing a high level plan and milestones for the task. Once I have that, I take a more “depth-first” approach, attempting to complete each milestone before moving on to the next.
In Claude Code, this means shifting into planning mode then stating my intention, with the details that I think are relevant, and then seeing what plan is returned. I’ll iterate on this plan multiple times, asking for explanations and web research if needed. This process usually requires the advanced reasoning capabilities from Opus. Since access to Opus has become more limited, I’ve shifted a lot of this work into Codex CLI instead, and go through the process with GPT-5 Codex (medium or high reasoning). Once I’m happy with the proposed plan from Codex, I’ll copy that plan into Claude Code and let Sonnet synthesize its own version of the plan.
If it makes sense, I’ll ask for code examples to be written into the plan as well. I’ll make sure that the plan includes not just what needs to be done for the code, but also how I want it done (e.g. create a new branch, commit after each step, lint and make sure tests pass before committing, etc.). If I’m expecting difficulty or if I’m working on a top-level plan, I’ll write the plan out to disk so that I can refer to those documents in specific future steps and include explicit instructions to write them out or keep track of status and update.
Once I’m happy with the proposed plan, I’ll effectively let Sonnet take over. I personally do not like giving Claude Code “yolo mode” - specifically because it’s just a “little” too much power with no responsibility. As IBM told us all the way back in 1979, “A computer can never be held accountable.” Setting up a Docker container just to make it “safe” also feels tedious.
I end up having to give more and more permissions as I go, but since most of those are stored per folder or instance I rarely need to intervene too much. If I’m concerned, I’ll stop and ask it to use extending thinking, which boosts the reasoning allocation for Sonnet. It also writes out the reasoning process so I can supervise and intervene if needed. I like to let Sonnet finish a full “draft” before intervening if possible, however. Simply put, Sonnet works much faster than I do. Trying to “pair program” with a model would mean I’d need to keep pace, either (both?) slowing the process down considerably or (and?) stressing myself out trying to reason at the pace of a model’s output.
It’s much easier to take the backseat for a bit while the model drives. Once it stops, I step back in to review. I’ll ask to lint and type check first. Unfortunately, our full test suite takes much longer than Claude Code’s default timeout - so it’s actually easier to let Github run the tests for me while I review the diff in a pull request. I’ll either tell the model to create a PR or push the updates next.
If the attempt is completely off base, I’ll scrap the last iteration (create a backup branch, then switch back). If things seem mostly on track, I’ll first ask Codex to look at the work on the branch and assess how much of the plan is complete. If significant work is missing, I’ll take the list back over to Claude Code, and go through the planning loop again, using extending thinking if issues are complex. If the work is essentially complete, I’ll use /review in Codex CLI to get a list of potential issues, then copy that over to Claude Code to seed a new plan. I’ll ask the model to verify the issues exist before coming up with a plan to fix them. This sometimes takes a few iterations since the fixes sometimes introduce new bugs.
My final pass is often cosmetic - asking the model to clean up markdown files it created or remove extraneous comments it added.