At localhost, Dominik Kundel walked through how coding with Codex has changed at OpenAI over the past year: autocomplete, then pair programming, and now what he calls agentic delegation. Code has stopped being the bottleneck. What matters now is whether a team has built the surrounding harness that gives an agent context, a way to validate its own work, and a way to get that work verified.
The comparison he kept returning to: you wouldn't hire someone and leave them to figure everything out alone. Most people's first instinct with agents is exactly that, handing over a vague instruction and expecting the gaps to fill themselves in.
The prompt only worked because Codex could investigate
Dominik drew a line between this and last year's idea of context engineering, hand-crafting the perfect prompt before sending it off. A colleague who needs everything spelled out isn't much use, and neither is an agent that does. Codex needed to work across OpenAI's own large codebase from early on, which meant it had to navigate and understand how things fit together on its own rather than being told which files to open every time.
A useful test: drop a talented new hire into your codebase with nothing but the repository. Do they know which tools to use, which conventions apply, which external dependencies matter? For most teams, some of that knowledge lives outside the code entirely, in Linear tickets, Slack threads, or a Google Doc where a decision was made. Dominik has Notion, Google Drive, Slack, Gmail, and his calendar all connected to Codex through plugins for this reason. The same skill Codex uses to trace how a codebase fits together applies to tracing a Slack thread: start from one message the way you'd start from one file, and follow it to what it connects to.
Once that's in place, the prompts you can send start looking less like instructions and more like a message to a colleague who already knows what you're talking about. In one meeting, a colleague reminded Dominik about a developer blog idea she'd mentioned earlier that he'd never gotten around to reading. He didn't remember where the Slack message was or what it referenced. The task he fired off mid-meeting was sparse: find that message, find the tracking sheet, work out the topic, and connect it to earlier related work. Codex found all of it and returned a draft grounded in source material from the relevant projects.
A second example went further. A documentation update needed to go live at midnight on a Sunday, and Dominik didn't want to be awake to shepherd it. He prepared the pull request with Codex on Friday, then gave it the rest of the job: watch the relevant Slack channel for context, get approval from a specific teammate and track down someone else if that person didn't respond, account for the twenty-minute publishing delay and deploy with enough lead time, confirm the page was live, and post the result to the team. At 12:04 a.m., Codex had verified the page was live and sent the message.
Over the weekend, a colleague asked Dominik for the preview link again so she could review the change. Dominik wasn't online. Codex answered in his place, since it was still watching that thread. "That wasn't me," Dominik told the audience. "I wasn't online at that time." When the colleague confirmed the change looked good, Codex replied and continued toward deploy; had she said no instead, it would have paused the deployment and worked the fix, since watching that PR through to completion was part of the job it had been given.
Another source of context comes from a feature called App Shots: pressing both Command keys on macOS captures not just a screenshot but the surrounding application state, so a page longer than what fits on screen still comes through in full. Getting tagged in Slack can now mean opening App Shots, saying "fix this," and letting Codex work out the rest from there. Codex can also be pulled directly into a Slack thread, a Linear ticket, or a GitHub conversation as a cloud agent, picking up whatever context already lives in that conversation instead of needing it repeated.
Codex is also expected to improve over time and remember how work gets done. Memories lets it learn from past interactions, useful for things like recurring debugging patterns. Chronicle watches a person's screen and turns those interactions into memories of its own, learning which tools someone reaches for and in what order. It's why Codex created a Google Doc rather than a pull request for that dev blog draft: Chronicle had already learned that blog posts get drafted collaboratively in Google Docs first, even though the request came from inside the dev blog repository.
Record and replay, launched the same day as the talk, goes a step further: instead of describing a workflow in words, a person can start recording, perform the actions once, save it, and have that become a reusable skill that Codex can carry out on its own through computer use.
Validation crossed the deployment boundary
Validation covers the tools that let an agent check its own work before anyone else sees it: compilers, formatters, test suites, and linters, the baseline things an agent already tends to reach for. Those linters don't have to stay limited to code. OpenAI uses a tool called Vale to lint its developer documentation against style guides, so anything Codex writes already matches house style without a round of back-and-forth.
Speed matters here more than it used to. An agent that reruns a full compilation or the entire test suite for every change adds real time to every task, which is reason enough to invest further in making those tools fast. Parallel environments matter for a similar reason: once agents are working for hours at a stretch, the natural next step is running several of them at once, which means being able to run multiple full, independently debuggable copies of an application rather than just a frontend preview. Building the Codex app itself required running as many as five, six, or seven copies in parallel so Codex could work several projects at the same time, particularly for background automations debugging things unattended.
More advanced validation includes screenshots, accessibility checks, testing, and computer use for deeper verification that a task did what it was supposed to. Codex's in-app browser recently added Chrome DevTools Protocol (CDP) support, letting it debug a performance issue or run profiling directly rather than guessing at the cause. Plugins extend that reach further: the Render plugin lets Codex watch a real deployment, catching a pipeline failure or a slowdown as it happens. That's what makes an open-ended request like "find ways to cut our build time" workable at all, since the agent has somewhere to check whether an attempted fix helped.
When validation does surface a failure, it's worth treating as a teaching moment rather than a dead end. A bare "test failed" doesn't tell an agent much. Explaining what went wrong and how it got there is what keeps the same mistake from recurring.
Verification started in a fresh conversation
At OpenAI, no pull request goes to a human teammate until Codex has already reviewed it, in a separate conversation from the one where the code got written. That separation matters: a review session that inherits the implementation conversation also inherits its blind spots. So the agent that wrote the change should not be the only agent asked whether the change is correct. Only once every comment from that review is resolved does the change move to a person.
Keeping that review useful means keeping it quiet. A reviewer that flags everything trains people to ignore it. OpenAI's default is to flag only P0 and P1 issues, with teams adjusting that bar through an AGENTS.md file. Documentation turned out to need a different bar than code: Codex wasn't treating typos as high priority by default, even though a typo in a doc matters far more than, say, a variable name inside a React component, so the team told it explicitly to flag typos in MDX files.
A CI pipeline is worth judging by how much it catches rather than how fast it runs. If it's slow, the fix is to have Codex babysit it: watch a pull request through CI and review, fix whatever gets flagged, and merge once everything's green, rather than a person waiting on the result.
Deploy previews close the loop for anything web-facing, letting a task get started, checked, and merged from a phone without cloning a branch first. Where previews aren't practical, as with the Codex app itself, the fallback is attaching a video to the pull request, sometimes recorded by a person and sometimes by Codex itself using computer use to interact with the app and capture its own screen recording. Either way, a product manager or designer contributing a task can look at what actually happened and feel confident about it without reading a diff.
The habits underneath it
A few practices make all of this sustainable. Migrations that used to require a code freeze can now run in parallel with everything else, since rewriting a large surface area is cheap enough to attempt without blocking other work. It's also cheap to try more than one approach and throw away what doesn't land: the work-tree handoff in the Codex app went through several iterations after user feedback, well after it originally shipped, because building the next version costs so little.
Recurring feedback is worth encoding into a skill rather than repeating by hand. For documentation, a colleague turned the standing feedback he and another teammate gave on pull requests into a "finalize" skill, so a draft now gets what Dominik jokingly calls a "Dominik review" automatically, before either of them looks at it. The same logic applies to mistakes: if an agent keeps using the wrong variable type or violating a framework convention, the fix isn't repeating the correction, it's asking the agent to write a new lint rule or test so that specific mistake can't happen again.
Where this heads next
Three trends stood out from what Dominik is seeing:
- Proactivity: automations that run on a schedule without a fresh prompt each time, like one that checks logs for recurring errors and opens a pull request testing a fix before anyone asks.
- Independence: agents working a hard backlog item for hours or days unattended, once they have the context and validation to make that safe.
- Parallelization: running agents across more compute than a single laptop can hold, instead of tethering a phone hotspot to a laptop propped open in the passenger seat. Put together, those three describe what people mean by a "loop": an agent that has the context to act, the means to check its own work, and a reason to keep going, whether that's watching pull requests, drafting responses to a calendar or inbox, or picking up whatever lands next in Linear or Slack and carrying it through to a finished, reviewed pull request.
Three words, one deploy
Dominik closed on three words: context, validation, and verification.
- Context: is all the information an agent needs accessible to it, or is a person still supplying it by hand every time? Make the feature context and standards accessible to Codex directly.
- Validation: can the agent confirm on its own that it did the job correctly, rather than leaving that check to someone else? Give it the tools to validate its own work, with errors specific enough to guide a fix.
- Verification: how do you confirm, in the end, that the work is done, and how fast can that happen so an agent isn't left waiting on a person to finish theirs? Make it easy for your team to verify completed work, and feed review feedback back into context and validation.
At 12:04 a.m., "the page is live" was carrying all three at once: the right Slack thread, a human's approval, a checked deployment, and a review that happened before anyone had to ask for it.