The boring work is the real work: what OpenAI's Codex story taught me about automation

Every engineer I respect has a version of the same story. It is a Tuesday afternoon. A model evaluation needs to run against the latest checkpoint, a Kubernetes cluster needs a private link and a quota bump, and none of it is hard. It is just fiddly, repetitive, and yours. You have done it forty times. You will do it forty more. The knowledge of how to do it correctly lives in exactly one place: your own scrollback.

That last part is the quiet tragedy of operational work. Not that it is boring, but that it is invisible. It never becomes a document. It never becomes a system. It stays trapped in one person's chat history until that person leaves.

So when OpenAI published a short, unglamorous post about automating repetitive work at OpenAI with Codex, I read it twice. Not because it announced anything flashy, but because it quietly gets the hard part right. Below is my breakdown of what is actually going on, what most people will miss, and where I would take it next.

The setup: two chores, one pattern

The author works across OpenAI's cloud infrastructure and API teams, and the two chores they automated are about as ordinary as engineering gets:

1. Provisioning infrastructure. Standing up Kubernetes clusters, wiring private links, chasing quota, nudging Terraform into a working state.
2. Running model evaluations. Kicking off evals against the newest models, fixing broken graders, juggling quota again, wrestling with PyTorch configuration.

Notice what these have in common. Neither is a "build a feature" task. Both are operational. They are the connective tissue between the interesting work, and they are exactly the kind of thing teams either burn a senior engineer on or quietly let rot.

The instinct most people have here is "let the agent do it." Fire off a prompt, let Codex run wild, hope for the best. That is not what OpenAI did, and the difference is the whole point.

The real idea: the notebook is the unit of work

Instead of treating Codex as a magic button, the author treats a notebook as the durable artifact and Codex as a collaborator inside it.

They use Runme, an open-source app where a single document holds Markdown prose, runnable code cells, and HTML together. Every notebook saves straight to Google Drive with a companion *.index.md file so future-you can actually find it again. That small detail, an index file for discoverability, tells you these are people who have been burned by lost knowledge before.

The workflow reads almost like a contract. The engineer opens a notebook and writes the goal at the top, something close to this:

Review a previous run to understand the workflow. Write a detailed plan in
this notebook. Wait for me to review and approve the plan before beginning.
Document the commands you run, their output, and how you interpret the
results.

Then Codex is pointed at that goal. It reads the intent, drafts a plan, and stops. The human reviews the plan, approves it, and only then does the agent begin executing, writing down each command, its output, and how it interpreted the result as it goes.

Sit with that for a second, because there are three design decisions packed into one short prompt.

A persistent goal keeps the agent honest. Agents drift. Ten steps into a task they forget why they started. Pinning the goal to the top of a living document, and asking the agent to keep updating that document, gives it a stable anchor to return to. The notebook becomes working memory that survives longer than a chat window.

The plan is a checkpoint, not a suggestion. "Wait for me to review and approve the plan before beginning" is the load-bearing sentence in the whole post. It splits the task cleanly: the machine handles the repetitive execution, the human keeps the consequential decisions. When quota runs out, the human decides whether to reuse existing infrastructure. When two eval systems could work, the human picks. The agent proposes, the human disposes.

Documentation gets written while the work happens, not after. This is the part I want to tattoo on a wall. Documentation almost never gets written because it is a second job you do once the real job is done and you are exhausted. By folding intent, commands, output, and reasoning into the same notebook the agent is already working in, the cost of documentation drops to nearly zero. It is a byproduct of the work, not a tax on top of it.

The result is that the next person who has to run this eval does not start from a blank prompt and a colleague's fading memory. They open a notebook that already explains what to do and, crucially, why the last person made the calls they made.

The clever bit of plumbing: no new servers

Here is the piece most readers will skim past, and it is my favourite.

You would expect wiring an agent into a web app to mean standing up a backend, an MCP server, some new surface area to secure and maintain. OpenAI's team sidestepped that entirely using WebMCP, which lets the browser itself register the tools the agent can call. Inside the running Runme tab, the agent gets a small, bounded set of capabilities: read the Runme docs, read the app documentation, and run tightly scoped JavaScript that updates the notebook.

The elegance is in what they did not build. No new service. No new deployment. No widened blast radius. The agent operates through tools that live in the page the human is already looking at, inside the permission boundary that already exists. In their words, automatic review can approve eligible actions without changing the existing permission boundaries. That is a security posture disguised as a convenience.

As an enterprise architect, this is the detail I would put in front of a nervous CISO. The reason this pattern is adoptable is that it does not ask the organisation to trust a new box on the network. It reuses the trust boundary you already audited.

What I would tell a team trying to copy this

If you strip the post down to transferable principles, here is the shortlist I would hand to any team, and it costs almost nothing to adopt:

• Automate the chores, not the crown jewels. Start with the repetitive operational work nobody wants and no one documents. The upside is high and the downside is contained. This is the opposite of "let the AI write our core product."
• Make the artifact durable, make the agent disposable. The notebook survives. The agent session does not. Design so the value accretes in a document a human can read, not in an agent's ephemeral memory.
• Put a human gate at the plan, not at every keystroke. Approving a plan once is leverage. Approving every command is babysitting. The former scales, the latter just moves the toil around.
• Turn documentation into a side effect. If writing down what happened requires a separate act of will, it will not happen. Make the workspace and the record the same object.
• Reuse your trust boundary. Prefer patterns that operate inside existing permissions over ones that demand new infrastructure and new attack surface.

One honest caveat, since I would rather be trusted than impressive: the post cites no hard metrics. No "40% faster," no hours saved. I read that as refreshing rather than damning. This is a working pattern shared by a practitioner, not a marketing claim dressed as a case study. Treat it as a design you can borrow, then measure it yourself.

Where I would push it further

The OpenAI post is deliberately modest. Here is where I would extend it, drawing on how other teams, Anthropic in particular, have been talking publicly about the same problem.

1. Promote the best notebooks into reusable Skills. A one-off notebook is knowledge for one task. Anthropic's engineering team describes packaging repeatable capability into Skills and plugins, a folder of scripts, assets, and instructions the agent can discover and reuse, so a new engineer inherits the whole team's muscle memory on day one. I would run OpenAI's notebook loop first, then harvest the patterns that recur into named, versioned Skills. The notebook is how you learn the workflow. The Skill is how you stop relearning it.

2. Add a second agent as the reviewer. The single-human-gate model is good. I would make it better by borrowing the writer/reviewer split Anthropic recommends in their Claude Code best practices: one agent drafts the plan, a fresh agent with clean context critiques it before it reaches the human. A reviewer that did not write the plan is far less likely to rubber-stamp its own assumptions. The human still decides, but now they are choosing between a proposal and a critique rather than judging in a vacuum.

3. Run the boring work in parallel. Anthropic engineers talk about running many agent instances at once rather than one chatbot in series. Operational chores are embarrassingly parallel. Ten evals across ten checkpoints do not need to queue behind one another. Fan them out, each in its own notebook, each reporting back to a shared index.

4. Treat verification as its own investment. The most quietly radical claim in Anthropic's writing is that it is worth spending real engineering time building the checks the agent runs against, not just the tasks it performs. For evals and infra, that means a notebook is not "done" when the agent says so. It is done when an automated verification step, a sanity assertion on the eval output, a Terraform plan that shows zero unexpected drift, passes. Trust the agent less, trust the harness more.

5. Close the loop back into the org's memory. OpenAI writes the notebook to Google Drive with an index file. I would take the final step and pipe those indexes into whatever your team actually searches, Notion, a wiki, a vector index behind a Slack bot, so the knowledge is not just saved but retrievable at the moment of need. Saved-but-unfindable is only marginally better than lost.

The lesson under the lesson

It would be easy to read OpenAI's post as "we used an AI to do our chores." That misses it.

The real lesson is about where you point the automation. They did not aim it at the glamorous, ambiguous, judgment-heavy work. They aimed it at the repetitive, well-bounded, soul-eroding work, kept themselves firmly in the decisions that carry consequences, and captured the knowledge on the way through so it stopped dying in someone's terminal.

That is not a story about a clever model. It is a story about good taste in what to delegate. The engineers who get the most out of this generation of tools will not be the ones who hand over the most. They will be the ones who are precise about handing over the right things, and who insist that every automated run leaves the team a little smarter than it found them.

The boring work, it turns out, was always the real work. We just finally have a way to do it without letting the knowledge evaporate.