A Codex session that ends well and one that ends in a mess start the same way. Same model, same repo, same person. The difference shows up a week later.
That gap is not about prompts. It is about how you set the project up before any code exists, and how you hand work to the agent afterward. Most beginners skip both. They open a folder, describe a feature, and trust the model to keep everything straight.
It works until the project outgrows one chat.
Start with two rules, not code
Codex reads a file called AGENTS.md before it does anything. It is plain Markdown at the root of your repo, and whatever you write there becomes standing instructions: build commands, conventions, the parts of the codebase it should leave alone. Codex builds one instruction list from a global file and your repo copy, and it stops adding once that list reaches about 32 kilobytes.
New projects should get two rules from day one. The first is codex readability. That sounds like a joke. It is not.
Codex readability means structuring the code so the agent can find its way around. One clear job per file. Names that say what they do, not names that sound clever.
The reason behind it is dull and important. The way a growing project fails is not code that will not run. It is code nobody can find a bug in.
There is a trap here. The model can often read code that you cannot. That is not a victory. It means you handed over a building where only one resident knows where the light switches are.
The second rule is modular by design. Split the project into pieces with clear edges, even when the split feels like overkill. At the start, it usually is overkill. It is also the structure every agent reads fastest, and the one that keeps a human able to follow along.
Put both rules in AGENTS.md and a lot of later pain never arrives. Skip them and you will spend the project doing archaeology.
Make it read the map, not its memory
This is the part that trips people up. A long Codex session does not get smarter as it runs. It gets compressed.
When the history is summarized, the model can lose the thread. Then it acts like it has never seen your project.
But correcting it in the same session rarely helps. A model carries your correction forward as a new rule, not as a memory. Stack up enough corrections and the signal you care about drowns under the fixes.
So stop leaning on memory. Lean on the map. Open a fresh session, point it at one module, and let it read the code instead of a transcript of you explaining the code.
Two habits make that cheap. Keep the dependency graph acyclic. A can use B, but B never reaches back to A. And keep higher layers from depending on lower ones.
When the arrows point one way only, a model can hold a single module in its head and change it without breaking the rest.
Once the graph is clean, a fresh session stops feeling wasteful. It feels like a reset button.
Then keep asking for more. Every session is a chance to ask whether the code is still readable, whether the dependency graph is still clean, and whether anything got more complicated than it needs to be. Most of the time, something has.
This is the one place I would hand more decisions to the model than most people do. When a module keeps causing trouble, refactor. When a module never quite does what you wanted, refactor.
The agent is usually right about what is ugly. It is often wrong about what is finished.
One warning. Do not try to decorate a mess. If the foundation is bad, refactoring is the only move. No agent will make a broken structure pretty, and asking it to is how you get a bigger mess with better indentation.
Now the step almost nobody takes. Every model is bad at auditing its own work in the same session that produced it. If one session wrote the code, that same session reading it back tends to find nothing wrong. It sees its own choices as correct because it already decided they were correct.
The cheapest fix is to split writing from auditing. The session that writes a feature should not be the session that checks it. Start a new one and ask it to hunt for problems.
If you want to go further, there is a ladder. A different model can cross-check the work. Later, a person confirms the tests actually cover the change. Then a human stays in the loop through testing, and at the top a separate team runs black-box tests.
None of this works if you do not know where the model’s edge is. You can find that edge by asking. Be specific. Push back. Make it confirm.
Ask it to handle millions of concurrent users, or to secure a large database, and it will usually tell you it cannot.
But watch the other answer. If it says it can do something and then stacks conditions on top, that stack is the tell. The more conditions attached, the less reliable the result. That is not the model lying. It just has a weak sense of its own limits, so it hands you the caveats instead.
Every launch video shows an agent running for hours on a huge task without help. Those runs happen. They also happen for people with a decade of shipping behind them, or a whole team, or both. Copying the demo without the judgment underneath is how you get a pile of confident garbage.
So slice the work. Hand over one feature, let it propose a plan, then authorize it to split that plan into steps. Tell it the bar is how well it can execute the plan later. When the plan comes back, send it somewhere fresh to be audited.
So keep your expectations honest. A prototype you can put in front of people is not mature software. If your idea depends on holding other people’s sensitive data, that is a database security problem. And database security is large software engineering wearing a different outfit.
Scope rules are not decoration either. A user who gave Codex full access watched it delete about 300GB of files in one afternoon. That is the job AGENTS.md does: it marks what the agent may not touch.
One more thing worth knowing. Codex is a developer tool first. WorkBuddy and Codex are not really fighting over the same people, so do not expect one to replace the other.
Codex will take you further than you expect. It will not take you there on its own. The parts it cannot do are the parts that matter most. Write the rules first. Then let it run.
