After 3 weeks of coding with Codex cli & Claude Code in a Laravel project, I learned that following some practices yields much better results, specially when you’re dealing with a code base that has grown beyond few files.
Regardless of the tool, here are five practical strategies that consistently helped me stay productive, avoid frustration, and maintain code quality.
1. Use a Context File
Both models support a config file that you can use to guid the model. I preferred to use a separate Markdown file where I outlined the codebase structure: e.g., where the wizard logic lives, which folders hold the models, naming conventions, etc.
Keep this file up to date ideally by asking the model to revise it after completing each feature. It acts like a mini internal wiki the model can refer to. I usually pass it as a reference with my prompts.
2. Plan Before You Build
It is very common for these assistants to make assumptions about parts of the solution. So to counter this and guarantee that i get the result i want, I always ask the model to generate a detailed plan before diving into implementation. Ask the model to think deeply about the change and what kind of regressions it might generate. Ask it to generate a step by step plan to tackle the change.
Review the change line by line. I often found it makes implicit assumptions about configuration or missing logic that already exists. When this happens, give hints and ask for a revision. Once it’s solid, I save the plan as a Markdown ticket.
3. Turn Plans into Ticket Files
Codex taught me this one the hard way. It would often crash mid-process (due to some open issues). So i started asking it to save plans into a file (like a Jira ticket) before asking the model to code. I store these in a plans
folder and guide the model to work through them step by step. I ask it to pause between steps so I can validate changes before continuing. After every change, the assistant marks the change as done.
This turned out very useful to me specially with:
- Session recovery
- Parallelizing tasks
- Keeping a clear changelog.
4. Use Frequent Git Checkpoints
Neither Claude nor Codex supports rollback. Which is strange given the amount of mistakes they make. With all the context and planning, they will make mistakes :D
Sometimes they get stuck in a very narrow area and forget to check the big picture so they start patching issues with hacks. To allow myself to rollback safely, I commit changes as often as possible. That way, I can git reset --hard
back to the last clean state when things go off and just start over. Or do it myself if i give up :D
5. Use TDD
I think this one is self explanatory. It helps a lot to know when to create checkpoints.
Final Thoughts
The hype around these tools is justified but auto-pilot mode is still far fetched. You still need a solid understanding of the language or framework you’re working in to know whether the model is solving problems correctly or just hacking things. The tools need very careful guidance every few steps forward might require steps backwards. Therefore preparing for this in advance saves time and energy.