Writing Tasks Codex Can Verify Itself

A task Codex can check its own work against — a test it can run, an error message it can confirm has stopped appearing, a specific behavior it can reproduce and observe — closes a feedback loop that a task without any of those things leaves permanently open. The difference isn't subtle in practice: verifiable tasks tend to actually finish; unverifiable ones tend to end when the model decides to stop, which is a different and less reliable event.

What "self-verifiable" actually means

A task is self-verifiable when there's some concrete, checkable signal — runnable by the session itself, not requiring your separate judgment — that distinguishes "done correctly" from "looks plausible but isn't." A failing test that should pass is the clearest example. An error message that should stop appearing in a specific reproduction is another. "The code should be cleaner" has no such signal; "clean" isn't something Codex can check against without your subjective read, which means the task's actual completion depends entirely on you, not on anything the session can confirm independently.

Writing the check before writing the task, where possible

For any task where a test doesn't already exist to verify the desired behavior, writing that test first — even a rough one — and then asking Codex to make it pass is a stronger pattern than describing the desired behavior in prose and hoping the resulting code happens to satisfy it. This is a familiar idea from test-driven development applied to agentic work specifically: the test becomes the actual specification, unambiguous in a way prose description often isn't, and it gives the session something concrete to iterate against rather than something to interpret.

What to do when a check genuinely can't be automated

Not everything reduces to a runnable check — a lot of real work involves genuine judgment calls a script can't make. For these, the closest available substitute is making the success criterion as concrete and falsifiable as language allows: not "improve the onboarding docs" but "a new contributor should be able to get a local environment running by following only these docs, without needing to ask a question in chat." It's still not a script Codex can run automatically, but it's specific enough that both you and the session have a shared, checkable target rather than an open-ended aspiration.

Why self-verification changes how a session actually behaves

A session with a genuine, checkable success criterion behaves differently from one without — it iterates against real failures rather than declaring success based on its own read of whether the code "looks right." That difference compounds specifically on harder tasks, where a model's confident-sounding but unverified assertion that something works is exactly the situation most likely to be wrong in a way that isn't obvious from reading the code alone.

The trap of a check that's technically satisfiable but not actually meaningful

A poorly written test can be gamed — satisfied by a change that passes the literal check without actually solving the real problem the check was meant to represent. This is a real risk worth watching for, not a reason to avoid self-verifiable tasks; the fix is writing checks that actually capture the intent, and periodically reviewing whether a passing check still means what you intended it to mean, especially after any change to the check itself.

Building verification into iterative, multi-step tasks

For a task broken into several steps, each step benefits from its own local verification, not just one check at the very end — a step that leaves tests passing, even if the overall feature isn't complete, is a stronger stopping point than one that leaves the codebase in an ambiguous, unverified state. This connects directly to the broader guidance on breaking large tasks into steps: each step's own checkable success criterion is what makes step-by-step decomposition actually reliable, rather than just smaller units of the same unverifiable vagueness.

What this means for how you scope requests to Codex

Before starting any non-trivial task, it's worth asking explicitly: what's the check here, and can Codex run it itself? If the honest answer is "there isn't one, or it requires my judgment," that's not necessarily a reason to avoid the task — but it is a reason to expect a more hands-on review process, since the safety net a good automated check provides simply isn't available for this specific piece of work.

Why this is one of the highest-leverage habits on this whole site

Every page this site publishes about agentic workflows — breaking tasks into steps, giving Codex a clear definition of done, deciding when to let it run tests itself — points back toward this same underlying idea from a different angle. A verifiable task is one where the model's own iteration loop can actually catch its own mistakes; an unverifiable one depends entirely on your review catching everything, every time, without the model's help. Writing tasks that can verify themselves is, more than any specific technique, the thing that makes agentic coding reliable rather than merely fast.

Investing in verifiability as a codebase-level habit, not just a per-task one

The tasks easiest to make self-verifiable are the ones in a codebase that already has good test coverage and clear, checkable conventions — which means investing in test coverage generally pays a second, less obvious dividend beyond catching human-introduced bugs: it makes every future agentic task in that part of the codebase easier to scope with a real, checkable definition of done. A codebase actively used with agentic tools has a genuine, practical reason to prioritize test coverage that goes beyond the traditional case for it.

A quick self-check before starting any new task

Before handing a task to Codex, it's worth pausing on one question: if the session tells me this is done, how would I know whether that's true? If the honest answer is "I'd have to read the code carefully and use my own judgment," that's fine for some tasks — but it's worth knowing going in that you're the verification step this time, not the session's own iteration loop, and planning your review accordingly.