Lesson 1 of 5 · 7 min

What Codex is, and where it fits.

You can write code, or you manage people who can. So you don't need the hype, you need a clear picture of what this thing is, where it earns its keep, and where it doesn't. Five short lessons, builder to builder. Let's start with what Codex actually is, because the name has meant a few different things over the years.

An agent you hand a task to

Codex is OpenAI's coding agent. The useful way to picture it: you give it a scoped task, in plain English, the way you'd write a ticket for a capable new engineer. It then works on your repository in an isolated sandbox, reads the relevant code, makes the change, runs the tests, and comes back with a diff or a pull request for you to review. You're not pairing keystroke by keystroke. You brief it, it goes away and does the work, and you review what it brings back.

That word, agentic, is the whole shift. Older tools finished the line you were typing. This one takes a unit of work end to end: plan, edit across files, run the test suite, iterate until it's green, and hand you something to merge. It's closer to delegating to a junior than to using autocomplete.

One quick note to clear the decks, because the name is overloaded. This is not the 2021 Codex API model that powered early autocomplete, and it isn't an inline completion plug-in. It's the current software-engineering agent: a coworker you give jobs to, not a feature inside your editor that guesses the next token. Anthropic's tool of the same shape is a separate thing, and if you'd like to weigh the two there's our Claude Code course too. The workflow this course teaches carries across either.

The forms it comes in, and the trade-off

It's the same idea wearing a few different coats, and which one you reach for is a real trade-off between convenience and control:

  • The cloud agent. You hand it a task and it runs in an isolated cloud sandbox against your repo, off your machine. This is the form Codex leans into hardest, because you can launch a batch of tasks at once and let them run in their own sandboxes in parallel, then review the diffs as they land. The trade is that the sandbox doesn't have your local environment, so you set it up through a config and trust it to run unattended.
  • The command-line tool. The agent in your terminal, working in your local checkout. You get the most control and the closest fit to your own environment and tooling, at the cost of running one focused task in front of you rather than a fleet.
  • The IDE extension. The same agent reachable from inside your editor, a middle ground: brief it and review its work without leaving where you already are.

That parallel cloud model is the bit worth internalising, because it changes how you work. Instead of pairing on one ticket, you queue several well-scoped jobs, walk away, and come back to a stack of diffs to review. The exact menus, plan tiers and limits move around, so don't anchor on them. What lasts is the shape: a defined task in, work done in a sandbox or your checkout, tests run, a reviewable change out.

Where it fits a small team

Here's the honest pitch, without the breathlessness. An agent like this is leverage on well-shaped work. It does not replace your engineers and it does not make architectural calls. What it does is take a slice of the queue off their plates so the people you trust can spend their hours on the parts that need a human.

  • Offload well-scoped work. The clear, bounded jobs that pile up, adding tests, a tidy refactor, glue between two services, are exactly what it handles well. That's a real dent in the backlog.
  • Parallelise. Because the cloud agent runs off your machine, you can have a few tasks going at once and review them as they land, rather than working one ticket at a time.
  • Free your senior people for design and review. The scarcest thing in a small team is senior judgement. Hand the routine work to the agent and your strongest people spend more time on architecture, hard calls and reviewing what ships. That trade is where the value is.

It's worth being clear-eyed about the ceiling too. An agent is brilliant on a well-defined task and shaky on a vague one. Give it something ambiguous, or a job that needs a decision only you can make, and you'll get confident work pointed in the wrong direction. The skill, which the rest of this course is about, is knowing what to hand over, how to set it loose safely, and how to keep a person on the things that matter.

The mental model to keep: Codex is an agent you brief like a capable junior. It works in a sandbox, runs the tests, and hands you a diff to review. It comes as a cloud agent, a CLI and an editor integration, but the workflow is what lasts, not the menus. In a small team it's leverage on well-scoped work, freeing your senior people for design and review. Next up: how to set it loose without getting burned.
Quick check

A few quick questions to lock it in. No marks recorded, just for you.

Q1.What's the most useful way to picture Codex?

It's agentic: you hand it a defined task, it works in a sandbox, runs the tests, and comes back with a change to review.

Q2.Which forms does Codex commonly come in?

Same idea, different surfaces: a cloud sandbox working a task, a CLI in your terminal, and integration inside the editor.

Q3.Where does an agent fit best in a small team?

Hand it the well-shaped jobs and run a few in parallel. That frees your strongest people for the calls only people should make.

Pick up anywhere

Save your progress

Pop your email in and we'll send you a link to pick up where you left off, on any device. No account needed.

Just for the link to your progress. No spam, and I never share your details.