I am a heavy user of Codex and have relied on it for all my development work. However, Codex recently became unstable—throwing frequent errors and suffering from a drop in performance—which caused my work to fall behind schedule. While I could switch to other models to complete the tasks, maintaining quality control would be more difficult. Driven to the limit of my patience, I prepared to modify the code myself, only to find I had developed a strong aversion to manual coding. I am not sure if this stems from the need to decipher unfamiliar code generated by the AI or simply because I have grown accustomed to “vibecoding”; either way, manual coding now strikes me as incredibly inefficient.
I would not frame this as “manual coding vs vibecoding.” The dangerous state is not being able to take ownership back when the agent fails.
If Codex has generated enough of the codebase that it now feels foreign, I would use the current instability as a reason to make the project recoverable:
- keep changes small enough that one diff can be reviewed;
- require tests for behavioral changes before accepting them;
- maintain a short architecture/state document in the repo;
- have the agent explain why a change is needed, not only produce the patch;
- commit/checkpoint before large agent tasks;
- periodically review one subsystem yourself until you can explain its boundaries and invariants;
- when an agent makes a large unfamiliar change, ask for a file-by-file change map and verify it against the actual diff rather than trusting the summary.
You do not need to become slower by manually typing every line. The useful human skill becomes understanding, verification and recovery, not competing with the model at keystrokes.
That also protects you against exactly what you are seeing now. If a model/service becomes unstable, you can switch models or work manually without discovering that your own repository has become an opaque artifact produced by a service you currently cannot rely on.
For the current Codex instability itself, I would preserve the exact errors/timestamps/model/version when it naturally happens rather than repeatedly retrying just to collect failures. There are already active reports for capacity and quota/reliability problems, so another expensive reproduction is not useful unless it adds a new discriminator.
I ran into a similar architectural concern and ended up separating the project authority from the coding agent.
Instead of letting Codex itself become the source of truth, I keep the requirements, architecture decisions, current state, checkpoints and acceptance criteria in a separate authoritative repository. The implementation repo is treated as the workspace, while Codex is only one interchangeable implementation agent.
Before any run, the agent refreshes from the live authority, reads the required documents in a defined order, performs a preflight check, then implements the scoped task. Afterward, deterministic tests/CI and an independent review validate the result, and a checkpoint is written so another model or a later Codex session can continue without relying on conversational memory.
This does not eliminate the need to understand the system, but it changes the failure mode. If Codex becomes unstable, I can switch agents without asking the new model to reverse-engineer the entire AI-generated codebase from scratch. The project knowledge remains outside the model.
I think this is especially useful once “vibecoding” becomes large enough that manually understanding every generated line is no longer realistic. The goal then becomes less “manually code everything” and more design the system, constrain the agent, and verify the output.
Exactly how i do it. I use a browser instance as an independent reviewer to validate the results, I also use it to issue the scoped tasks, yes codex works autonomously but strictly with in boundaries and it doesn’t validate its own work. And I also protect the canonical repo from casual writes. Codex works in a separate worktree, does its commits there, and only integrate them once validated.