Inside OpenAI: Where the Bottlenecks Move When Code Gets Faster

Original video: OpenAI: How AI is reshaping the craft of building software

The Pragmatic Engineer · Uploaded 2026-02-23 · Duration: 30 minutes 34 seconds

Event and speakers: The Pragmatic Summit, 2026-02-11, San Francisco. Moderated by Gergely Orosz, with Tibo Sottiaux, then Head of Engineering for Codex, and Vijaye Raji, OpenAI's CTO of Applications.

Metadata verification: Conference website · OpenAI's announcement of Vijaye Raji's role

Transcript and timing: Based on the complete English automatic captions, with names and roles checked against official sources. Internal practices, hiring plans and forecasts retain the context of the interview.

The Codex team's weekly analytics review starts with questions its dashboards have not answered: why adoption of a feature has changed, where users drop out, or what might explain a shift in retention.

According to Tibo Sottiaux, the data analyst starts Codex tasks while the meeting continues. The team can investigate 5 or 6 questions at once, receive findings in about 20 minutes, and discuss them during the final 10 minutes. The example in the video shows a change in the rhythm of work: a question and the analysis needed to discuss it can fit inside the same meeting.

The conversation is about software development, but repeatedly returns to work beyond writing code. Faster generation still leaves a team with users to understand, alternatives to compare, results to verify and decisions to make. Those steps become the places where work waits.

Bottlenecks move along the delivery process

Sottiaux says the Codex team changes its working methods almost weekly. It keeps looking for the slowest step: first code generation, then code review, and increasingly the work of understanding users, processing feedback and turning information from different channels into product strategy. This part of the conversation puts productivity back in the context of an entire workflow.

Raji extends the argument downstream. More generated code creates more review work. Faster reviews can then expose delays in integration, testing and deployment. Counting code output alone misses much of the time between an idea and a product reaching its users.

The execution environment is changing too. Raji describes an internal mechanism called Codex Box, newly introduced at the time, through which engineers reserve development environments on servers and dispatch tasks. Work continues remotely after a laptop closes and its owner leaves for a meeting. Engineers supply context, assign work and return to inspect the results.

Adoption is uneven. Based on conversations with OpenAI engineers, the moderator notes that some still do not generate all their code with Codex. The Codex team's practices should not be treated as a uniform description of the entire company.

Run alternatives in parallel, then test overnight

Technical tradeoffs traditionally begin with a design document: discuss possible approaches, choose one, then invest in implementation. Sottiaux now sees engineers pursue several implementations at once and compare what actually works. Parallel exploration makes it possible to execute and test alternatives that previously might have remained discussion points.

Longer tasks need supporting infrastructure. The Codex team assembled an environment and skills that allow the agent to test itself. Overnight runs perform repeated quality checks and flag regressions introduced by changes.

An agent that keeps working needs a way to observe and check the results of its work. That is the practical distinction illustrated by the overnight testing example: when a task finishes, the team needs evidence that the software works.

Sottiaux also recounts a model researcher's experience with Codex executing a training task and producing a PDF report of findings. Researchers then select promising directions for further iteration. This describes cooperation on long research tasks, with people still judging the direction of experiments and interpreting the output.

Raji offers a more everyday example: generating and executing FFmpeg commands to process video files. Alongside data queries and incident investigation, it shows a team delegating executable processes. Their value depends on whether the results can be checked and used.

Product managers and designers participate in execution

Raji argues that product and design judgment remain necessary while software serves human users. What changes is the path to testing an idea: designers and product managers can build working prototypes, try them out, and then bring the results to engineers.

Sottiaux describes how the team's sole product manager worked at the time. After a bug bash lasting about 1 hour, the product manager sent Codex to collect feedback in Notion, turn defects and proposed improvements into Linear issues, assign them to the relevant people and follow up on progress.

The work reduced here includes collecting information, organizing it, routing tasks and checking their status. The product manager still has to decide which problems matter and whether fixes meet the goal. As code generation accelerates, coordination must keep pace or the person coordinating becomes the next source of delay.

Spreading new methods also takes deliberate work. Active Slack channels, shared tips, hackathons and demonstrations help useful practices move through OpenAI. Raji observes that internal demos increasingly address edge cases and resemble more complete products.

Sottiaux also acknowledges that the team is discovering its methods as it uses the technology. There is no settled best way to work. An organization needs to circulate useful experience while leaving room for the next adjustment.

New graduates still need foundations

Asked about junior engineers, Raji gives a concrete answer: OpenAI is still recruiting graduates and plans to welcome about 100 during summer 2026, while continuing to expand its internship program. This was a hiring plan at the time of the interview; it does not establish how many people subsequently joined.

He sees an opportunity for new engineers to learn with AI tools from the start. Sottiaux focuses on the environment around them. New hires can ask Codex about the codebase, learn what colleagues are working on and read daily reports. Recent joiners also help teach the team's evolving working habits.

Neither speaker removes engineering fundamentals from the requirements. Sottiaux explicitly emphasizes architecture, codebase design, code review and appropriate constraints. Experienced engineers still participate in this work, while newcomers learn within a well-structured environment.

AI can help a new engineer complete tasks sooner; engineering foundations determine whether that person can understand the result, find problems and take responsibility for a change. Raji emphasizes product intuition and the ability to move up or down the stack when diagnosing problems.

Management must also adapt to the pace of execution. Sottiaux says he has 33 direct reports and wants to avoid every decision waiting for him. That number describes a particular team's structure. The broader question is whether leaders let decisions move as quickly as their people can work.

Judge compute budgets alongside completed work

At the start of the cost discussion, the moderator identifies a significant condition: OpenAI employees do not face the token limits ordinary customers encounter. Other companies cannot ignore that resource difference.

Earlier in the interview, Raji says individual engineers sometimes use hundreds of billions of tokens each week. That is his account of internal usage. The video supplies neither a measurement methodology nor usage records, so the figure cannot establish a dollar cost or a normal consumption level for engineers elsewhere.

He proposes a different accounting frame. If an agent becomes reliable enough to work around the clock, its cost can be compared with the work it completes. An engineer coordinating 4 or 5 such assistants would be considering more than the tokens consumed by a single call. Raji also acknowledges that the supplier must make the agents capable enough to deserve that expectation.

Sottiaux adds that market research, backlog review and identifying straightforward features already consume people's time. Delegating some of that work changes where costs sit. He argues that limiting inference too early could prevent useful experimentation, and favors giving effective users more room to explore.

A testable management question follows from this discussion: What additional work did a larger budget finish, whose time did it save, and how much checking or rework did it create? The video provides no universal return on investment. Individual teams still need to answer with evidence from their own delivery process.

Higher abstraction makes verification and debugging harder

The closing forecasts belong to the February 2026 interview. Sottiaux predicts a possible further order-of-magnitude improvement in speed over the next 6 months, alongside networks of agents tackling larger goals. These were expectations at the time, not outcomes established by this article.

Drawing on Cursor's browser exploration, he sketches a possible scale: request a browser built from scratch and receive roughly two million lines of code 24 hours later. The video supplies no reproducible delivery or quality evidence for that example. It sets up the next question: how should a team establish correctness when the code becomes too large to understand line by line?

Sottiaux imagines greater emphasis on constraining system behavior, inspecting inputs and outputs, and finding ways to prove correctness or limit risk. He also predicts that a personal assistant could appear within 2026 to report on the work of multiple background agents, reducing the need to inspect every task individually.

Raji points to a harder debugging problem. As complex systems accumulate layers, developers may rely increasingly on symptoms and observable behavior to identify causes. Tools will also need to help people develop that diagnostic ability.

Whether those predictions were realized requires subsequent evidence. What the interview already describes is a specific shift: shorter code-writing time exposes unclear requirements, insufficient verification and slow decisions more frequently. More of software engineering's value will lie in resolving those problems so that generated output becomes a product a team can maintain, deliver and take responsibility for.