Treating Codex as a junior engineer with an infinite patience budget

The framing that finally made Codex click for me wasn’t a prompting technique. It was remembering how I onboard an actual junior engineer, and noticing I was skipping every step of that process when I handed a task to a model instead.

With a new hire, nobody expects them to know the codebase’s conventions from a one-sentence ticket. You point them at the relevant files, explain why the code looks the way it does, tell them what “done” means for this specific task, and check in on the first attempt before they’ve gone too far in the wrong direction. With Codex, my early prompts were closer to shouting a ticket number across the room and hoping for the best.

The onboarding you’re actually skipping

A junior engineer’s first week is mostly context transfer: where things live, what the team’s conventions are, which parts of the code are fragile and shouldn’t be touched casually, what “finished” looks like for a typical task. None of that is written down anywhere a model can absorb it automatically, which means it’s on you to supply it, every time, until you build something reusable.

The task description alone, “add pagination to this endpoint,” is the equivalent of handing a new hire a one-line Jira ticket and walking away. It’ll produce something. It probably won’t produce the thing you actually wanted, because the thing you actually wanted included a dozen assumptions about existing patterns that never made it into the sentence.

The fix is the same fix that works for a human: write the brief you’d actually give a person. Which file has the existing pagination pattern to follow. What the response shape needs to look like. Whether there’s an existing test file establishing the convention. What specifically counts as done, a passing test suite, a specific edge case handled, a particular response shape matched.

The patience is real, and it’s not the same as good judgment

Where the junior-engineer framing earns its keep is in what happens after the first attempt is wrong.

A human junior gets tired, gets embarrassed, starts hedging after the third correction in a session. Codex doesn’t. You can iterate ten times in a row without anyone’s morale taking a hit, which sounds like a pure advantage and mostly is, but it also removes a natural brake that exists with human collaborators: eventually a person says “I don’t think this approach is working, can we back up,” and that instinct is worth having even when the other party is a model.

That means the brake has to come from you now. If attempt three looks structurally like attempts one and two, iterating a fourth time on the same approach is usually not going to fix it; the problem is upstream, in the brief, not downstream, in the execution. A human would eventually say so. Codex will happily keep trying the same shape of solution as many times as you ask.

Reviewing it like you’d review a junior’s PR

The review standard that actually works here is exactly the one you’d apply to a new hire’s first few pull requests: closer than you’d apply to a senior colleague, but for a specific and narrow reason, not out of general distrust.

A junior’s code usually works. What it’s missing is judgment about the parts of the codebase that don’t show up in the ticket: the edge case the team has been burned by before, the convention that exists for a reason nobody wrote down, the module everyone knows not to touch without asking first. That’s exactly Codex’s blind spot too, and for the same underlying reason: neither has the tribal knowledge that lives in people’s heads and old incident reports rather than in the code itself.

So the review pass that catches the most real problems isn’t re-checking the logic, which Codex is usually fine at. It’s checking against the tribal knowledge specifically: did this touch the module we don’t touch without asking, does this handle the edge case that broke production eighteen months ago, does this follow the convention that exists for a reason the code itself doesn’t explain.

Building the reusable version of the onboarding

The part of this that compounds, the same way it compounds with a growing team, is writing the recurring context down once instead of re-explaining it every session.

A short file describing the codebase’s actual conventions, the modules that need extra care, what “done” typically means for common task types, saves the same re-explanation across dozens of sessions. It’s the same document you’d eventually write for a growing team anyway, and building it for Codex first tends to mean it exists and is useful when the next actual junior engineer joins too.

Where the metaphor breaks

It breaks in one important place: a junior engineer learns. Six months in, they need less context because they’ve internalized the patterns. Codex starts fresh, in the relevant sense, every session, and needs roughly the same context on day two hundred as it did on day one. The reusable brief isn’t a nice-to-have that eventually becomes optional. It’s a permanent cost of working this way, and budgeting for it as ongoing rather than as a one-time investment is the difference between this staying useful and it quietly becoming more trouble than it saves.

More field notes on ChatGPT Codex

This piece is one entry in a running series on how AI coding tools change day-to-day engineering work. For more practical notes on Codex specifically, browse the full set at /blog/tag/chatgpt-codex/. For the wider view across every tool in the stack, the AI coding tag collects the whole archive in one place.