Codex and the shape of a coding task

Codex has made one thing painfully obvious: a vague coding task is not improved by giving it to a faster worker.

It just fails faster, more confidently, and with a diff.

That sounds harsher than I mean it. Agentic coding tools are genuinely useful. Being able to hand a tool a repo, ask it to inspect the project, make a change, run tests, and report back is a real shift. It changes what feels worth automating. It changes how quickly a small fix can move from thought to branch.

But the best results still come from well-shaped tasks.

The task is now an interface

When I ask Codex to do something, the prompt is not a magic spell. It is an interface between the human intention and the codebase.

A good task says what to change, what not to change, where the sharp edges are, and how success should be checked. It names the relevant files when I know them. It says whether the work is exploratory or implementation-ready. It makes the acceptance criteria boringly clear.

That boring clarity matters because the agent is not living inside my head. It does not know which accidental behaviour is secretly important. It does not know that a certain slug cannot move, that a particular CSS rule is there because Safari had a bad afternoon, or that the client hates the word “journey” for reasons I fully support.

Those constraints have to be made visible.

Small scopes are still king

The temptation with a capable coding agent is to make the task bigger.

Fix the bug, clean up the component, improve the tests, tidy the docs, maybe refactor the data layer while you are in there. That is how a simple job becomes a fog machine.

I get better results when I keep the scope narrow. One change. One reason. One validation path. If the agent discovers a related issue, it can report it. That does not mean it gets to solve it in the same pass.

This is not about mistrust. It is about preserving the shape of the work. A small diff is easier to review. A small failure is easier to understand. A small success can be integrated without needing a lie-down.

Validation is part of the request

A coding agent that can run commands should be asked to prove what it did.

Not emotionally. Mechanically.

Run the check. Run the test. Run the build if the change warrants it. If something fails, explain what failed and whether the failure came from the change or from an existing problem. Do not make the human guess from a cheerful summary.

This is one of the places where agentic coding feels less like autocomplete and more like delegation. The output is not only the code. The output is the code plus the evidence around it.

That evidence is what makes review possible.

Review gets more important, not less

The strange thing about AI coding tools is that they can make review feel optional right when review becomes more important.

The diff looks plausible. The tests pass. The explanation sounds sensible. That is a good start. It is not a merge button.

Review is where the human checks for product sense, architectural fit, naming, maintainability, and all the quiet context that rarely fits into a test. Did the change solve the right problem? Did it make the next change harder? Did it follow the project’s pattern, or merely produce valid TypeScript in the vicinity?

Those questions still need a person.

Better tasks make better software

Codex has not made me care less about process. It has made weak process more visible.

If the task is vague, the output drifts. If the repo has no checks, the agent has nothing solid to run against. If the project has no conventions, the model invents some. If the human cannot review the result, the speed is mostly theatre.

The better version is simple: write clearer tasks, keep the scope tight, make validation explicit, and review the work like it came from a very fast developer who still needs context.

That is not a downgrade. That is a useful working relationship.

What creative work borrows from debugging is still relevant here: trace the problem before changing the thing.