TL;DR
The short version
The most useful thing in OpenAI's launch-day episode wasn't the model. It was a strategic-finance lead explaining that he spent a month of evenings teaching an agent one hard recurring process — and that the payoff only shows up on the second, third, and tenth run.
Kyle Cobber isn't a software engineer. He built the system his team uses to close the books on compute spend each month. The method he describes — run the process the old way once with the agent watching, then codify each repeated step into a skill — is transferable whether or not you use Codex.
Built on the 21 July 2026 episode of Every's AI & I, hosted by Dan Shipper with Dom and Roman (Codex developer experience, OpenAI) and Kyle Cobber (Strategic Finance, OpenAI).
A month of evenings, not a prompt
Kyle Cobber works in strategic finance at OpenAI. He is not a software engineer. He built the system his team uses to close the books on compute spend each month — the hierarchy view, the allocation logic, the dashboard, the commentary pass, the export to slides for the board.
He built it in his evenings, over about a month, with Codex.
That's the story worth stealing from the episode, not the launch. OpenAI shipped GPT-5.6 Sol and merged Codex into the ChatGPT desktop app on 9 July. Fine. The interesting part is what the people inside the building actually do with it, and their answer is unglamorous: pick your worst recurring process and teach the agent to do it, slowly.
Stop trying to one-shot the system
Cobber's diagnosis of why people fail is precise. They open the tool and try to describe the whole workflow in one prompt.
His alternative inverts it. Take your hardest recurring process. Do it the old way one more time — but have the agent watching, gathering context from every file, every sheet, every Slack channel the process touches. Then, as each step repeats, codify that step into a skill.
You're almost reverse engineering the process over time.
Kyle Cobber, Strategic Finance, OpenAI
You're not automating the process. You're producing a written description of the process that happens to execute. The distinction matters, because a description can be corrected, versioned, and handed to someone else.
The economics are honest, and he says so: it is more work at first. The first run gets you maybe 70% of the way with mistakes you have to catch. The second is better. A month or two in, it's running at 95% and you're editing commentary instead of building slides. Those numbers are his own, from an internal process nobody outside OpenAI can audit — but the shape of the curve is the claim, not the decimals.
Skills are where the institutional knowledge goes
The mechanism underneath all of this is boring and important. A skill is a written instruction file the agent loads when it needs it.
Cobber describes a Google Drive audit skill: before anything ships, it traces a metric from the memo, to the linked slide, to the sheet behind it, and flags where they disagree. That skill exists because he did the trace manually a few times with the agent watching, then wrote down how he thinks about tracing.
That's the part most teams skip. The knowledge of how your team checks its own work usually lives in one person's head and leaves when they do. Writing it as a skill turns it into an artifact the whole team runs.
He layers the same idea structurally: one top-level agent instruction file, plus one per project folder, so work arriving from Slack lands in the right context with the right instructions already attached.
Trust is a governance line, not a feeling
Someone on the call asked the question every finance team asks: how do you trust it when it sometimes misses a file?
Cobber's answer isn't reassurance. It's that you treat it like a new analyst — it gets things wrong, you correct it once, and you encode the correction so it can't recur. And you write the boundary down explicitly. His example: never send anything back on Slack until I've read it.
Dom, who works on Codex developer experience, named the constraint that follows. As the models act more autonomously, the limiting factor stops being whether the agent can do the work. It becomes whether you can understand what it just did. That's an operator problem, not a model problem.
The boundary
Read the lean. This is three OpenAI employees on a friendly podcast on launch day, and every productivity number in it is OpenAI describing its own internal use of its own product. "Five days compressed into five hours" is the most repeatable line in the episode and the least checkable one.
What survives the lean is the method, because it doesn't depend on the vendor being right: a non-engineer, working evenings, taught an agent one genuinely hard recurring process over a month, and the accuracy compounded. That's testable in your own org this quarter, on your own worst process.
The host's own framing is the useful caveat. He says on-air that a rival model is the better programmer, just less usable. Pick the tool your non-engineers will actually operate.
