Full-draft editorial perspectives and critique

How Codex Happened
Jack Cheng’s suggested changes are incorporated below. Comments and writing goals are in the other tabs.
Intro
I can remember exactly when I realized that OpenAI would lose the mandate of heaven—the seemingly insurmountable lead they had built in AI coding since ChatGPT took off originally. And I know where I was: in their Mission Bay office, in the summer of 2025, the night before the launch of GPT-5.
That night, there was a certain buzz to the building. The overhead lights burned like stage lights and people seemed to walk amidst the warm rusts and browns of its halls just a little faster. Even the gravity seemed heavier—as if, were I to open my phone and look at a map, I would find myself standing at the center of the universe.
This made what I had come to say a little awkward.
I was in a conference room with Lindsay McCallum from comms, and Alexander Embiricos from the Codex team. Today, Codex is the centerpiece of OpenAI’s comeback—the product that has quietly swallowed ChatGPT from the inside and become the foundation for everything the company is building next. But that night, it was still a scrappy, unsettled effort to build an AI software engineer. A version launched in the cloud a few months earlier hadn’t found product-market fit, and the team was in the middle of a pivot to a version that ran on a developer’s computer—in their terminal and in their code editor.
Lindsay was typing with intense focus on her laptop across the conference table from me, probably refining the launch blog post that millions of people would read in the morning. Alexander sat on my side. He was coding while he talked to me, which I took as a good sign. He was rushing to finish a GPT-5 release feature that would let the agent pause and ask a human for permission to step outside its sandbox.
Every, the company I run, had begun to build a reputation for testing new AI models on real work and explaining what they could—and couldn’t—do. OpenAI had given us access to GPT-5 about a month before launch so we could help them understand the model’s strengths and weaknesses, and publish our vibe check, a detailed review, on launch day. We tested it both in ChatGPT for everyday use and in Codex for programming.
Ten of us had spent a week in a house in upstate New York, eating and working together at one long wooden table, and gathering on a couch in front of a big screen to put GPT-5 through its paces. The model was long-awaited and our excitement to try it was high—especially for coding, where the pace of AI progress was moving fastest. We liked GPT-5 for everyday use, but when we tried it in Codex, the tone around the TV was muted.
GPT-5 was fast, and it seemed smart. The most technical engineers on the team, like Naveen Naidu, were impressed with it as a technical collaborator. Together, they’d tracked down a mysterious freeze in his app Monologue that he’d been trying to resolve for days.
But step-by-step collaboration with a model had started to become the exception, not the norm for us. Using Anthropic’s terminal agent, Claude Code, we had started handing entire tasks to Opus 4 and walking away until a finished feature—or sometimes an entire app—came back. This had even started to spread from our programmers to non-programmers. With minimal help from an Every engineer, Katie Parrott built and deployed her own AI content management system in a few days—it had some bugs, but previously it would’ve been completely out of reach for her.
Next to Opus 4 inside Claude Code, GPT-5 inside Codex felt boxed in.
In that conference room in San Francisco, I sensed that Lindsay, who has a keen radar for vibe shifts in the market, wanted me to explain why I suddenly wouldn't shut up about this new way of working.
“With Claude Code, you just let it rip,” I told Alexander. “GPT-5 feels a little timid—like it’s held back by the sandbox and it seems afraid to use its own power.”
Lindsay’s typing slowed, “Tell Alex about this new engineering workflow you have,” I remember her saying without looking up from her laptop.
Alexander pushed his computer lid three-quarters shut and swiveled his chair to focus fully on me.
“We don’t even really look at the code anymore,” I said. But I blushed as I said it. First, because I was talking about engineering work on a tiny team building products that hadn’t scaled yet. Second, because it felt ridiculous to be explaining agentic delegation to Alexander, of all people—building an autonomous coding agent was his job.
Yet on the eve of OpenAI’s biggest launch in years, GPT-5 inside Codex still felt like a cautious pair programmer. How had that happened? And would they get stuck there?
*
For a while afterward, it looked like they might.
When GPT-5 launched the next morning, its rocky reception confirmed many of the issues we’d felt in our testing. And in the months that followed Claude Code took off with unprecedented speed. In September 2025, a month after GPT-5, Anthropic said Claude Code was generating over $500 million in annualized revenue. As early as February 2026, Claude Code alone was running at more than 2.5 billion dollars a year, with business subscriptions quadrupling since the start of the year.
Yet to Alexander and a small group of engineers inside OpenAI, that night in Mission Bay wasn’t the beginning of a decline.
“For me, GPT-5 was actually a really big deal and a really positive moment,” he told me later. It was the first time “we felt like we were actually in the game.”
Over the next several months, Alexander and the Codex team threw out their existing harness, rewrote the agent from scratch, and trained a dedicated line of coding models alongside it. They shipped a new command-line interface and an editor extension. Then, instead of staying on the turf where their competitor was strongest—the terminal—they built a native desktop app designed around managing multiple agents at once. This time, you could let it rip.
Within months, the app had attracted over five million weekly users. Even at Every, where Claude Code had long been the default, many of us were switching back to OpenAI—even for non-technical tasks. They had made a coding agent so good it had started changing how knowledge work happened too.
By July of 2026—less than a year after the GPT-5 launch, the product had gained so much gravity with inside and outside OpenAI that it merged into the flagship ChatGPT desktop app, and elevated Codex’s leader, Thibault Sottiaux, to run ChatGPT itself.
I can think of few other examples where a large technology incumbent successfully disrupts themselves, and then merges the disruptive product back into their main offering. That this is possible is a testament to how OpenAI is organized, and to the new leverage AI gives a small team inside a company of roughly 4,500 people. AI lets a few people build enough, quickly enough, to be truly disruptive before they are swallowed by the larger organization.
Unlike every product before it, AI gave Codex enough time to become undeniable—to show OpenAI that it could remake the company.
This is the story of how Codex happened.
This is the story of how Codex happened.
[TRANSITION TRACE]
Thinking…
Something is off. The lead I had a year ago isn't showing up in the results…
It looks like the problem starts earlier than I assumed…
Going back to the beginning…
OpenAI’s comeback begins with a simple line: "Thinking...."
In 2026, any time you interact with an AI model on any kind of complex request, you will see that word—thinking—shimmering in the place where your response will appear.
It might seem like a throwaway: a one-word replacement for the spinning beach ball on macOS or the circling blue ring Windows displays beside its cursor, each a sign that the computer is too busy to respond.
But "Thinking", in this context, denotes a new style of computing without which Codex would never have happened.
The first generation of large language models were external processors. They had no shimmering status label for their internal reasoning; instead they did their thinking directly by responding to you. Whatever you asked them to write an email or a line of code, they had to work out their answer one word at a time, with no opportunity to plan ahead or revise afterwards.
In that way, early chat models were like improv actors given a prompt by the audience. As these tools composed on the run, their results could be impressive—and sometimes unintentionally funny.
Early users of these models noticed that if you asked the model to write out its reasoning step by step before answering, it would often arrive at a better answer. This technique, the same advice as a grade school math teacher would give, was called chain of thought prompting.
Chain-of-thought prompting led to the second generation of AI models, and the shimmering “Thinking” UI. Rather than requiring the user to ask the model to work through a problem step by step, OpenAI trained that behavior into the model itself. Before responding, a reasoning model works in a scratch pad, called a reasoning trace, where it can attack a problem from different angles, backtrack out of a blind alley, and pick a path more likely to succeed. It responds only when it has settled on an answer.
OpenAI called its first model of this kind o1, and released a preview of it in September 2024. With o1, OpenAI found that the longer a model was allowed to work on a hard question, the better its answer got. That created a second way to scale AI. Until then, the main way to improve a model was to train a larger one for longer. Now the same model could do better on a difficult task simply by being given more time.
One kind of work stood to gain more from this than any other: programming.
"There's many beginnings" to Codex, Thibault Sottiaux, who leads the team and goes by Tibo, told me in an interview.
Codex has many beginnings for two reasons. The name has been reused: Before today’s product, Codex was OpenAI’s earliest commercial code-generation model, a version of GPT-3 fine-tuned on public code that powered the original GitHub Copilot.
The Codex we know today also did not start as one product or one team. A prompt from leadership set several people and groups working toward it from different directions.
“At the beginning of 2025, we … set coding—software engineering—as a top-level company goal,” Greg Brockman told me in an interview. Leadership had already started to focus on it by the fall of 2024, in the weeks after o1’s preview release, as it became clear that the reasoning paradigm was going to work.
Programming is unusually suited to reasoning models because it provides a closed loop of work and verification. A model can make a change to real code, run it, and learn within seconds whether the change worked, with no person needed to check. This is valuable because during training, a model can try thousands of different approaches to a problem. When it finally solves the problem, the trajectories that lead to the correct solution can be reinforced, all without the need for any human oversight.
When a real task arrives, the model can use its thinking time to try, check, and revise competing solutions, drawing on the approaches that worked during training. This is why reasoning models perform well at real-world coding—and why they are especially strong in domains like formal math and cybersecurity where the model can grind through millions of different possible solutions until it finds one no single human would've had the persistence to find unaided.
One of the beginnings to Codex was Alexander Embiricos, who came to OpenAI in 2024 when it acquired Multi, a startup he had co-founded. Multi was a screen-sharing tool for pair programming, in which two programmers work through the same code together. It let both of them see and control the same Xcode window, Terminal or desktop at once, each with their own cursor.
Embiricos’s time at Multi helped him understand that a model that could work directly in the files and apps on someone’s computer would be much more powerful than one confined to a chat box on the web. He expected multimodal capabilities—the ability to process inputs beyond text, like images and video—to improve quickly enough that an agent on your own computer, as opposed to a remote server, could see your screen, look at the files and apps you had open, and understand what you were doing.
That conviction led him first to the ChatGPT desktop app, which could read the windows you had open, and then to Atlas, a browser whose assistant could see whatever page you were on. But multi-modal progress was slower than Embiricos anticipated. The models struggled to accurately interpret what was happening on a user’s screen and respond fast enough to be useful.
Then reasoning models came out. Seeing a reasoning model connected to a terminal, Embiricos told me, was his first “feel-the-AGI moment”—a phrase people working in AI use to describe the “aha” moment of the technology working like magic. Coding products were not yet his full-time job, but he began sketching one.
“My assessment from a product perspective [was] that we [could] already build a successful coding product,” he said. “But it has to be designed around expecting the user to see what’s going on every thirty seconds, maybe a minute max.”
Speed was the problem again. Most AI coding products at the time were built around a tight feedback loop. GitHub Copilot completed the line you were typing; its chat-based successors, like the original Cursor and Windsurf, answered within seconds. None asked the model to work on its own for long, because the models couldn’t. OpenAI's early reasoning models were the reverse: slow, and weak when their thinking time was cut short.
Could he turn their flaw—the time it took to get a response—into an advantage?
Meanwhile, in another part of OpenAI, Thibault Sottiaux was attempting to turn reasoning models back on themselves.
“I got involved with coding agents around December 2024,” he told me. We were sitting in the OpenAI cafeteria. His glossy brown hair was swept neatly to one side as if for picture day, and he wore thin wire glasses that caught the afternoon light. If above the nose he looked like an architect, below he was all programmer: A beard of brown stubble paired with a dark brown hoodie printed with “Research and Deployment Co,” and a slice of pepperoni pizza in hand.
The goal, he told me between bites of pizza, “was to help us write infrastructure and do research faster.”
Sottiaux had spent much of his career building infrastructure for researchers, first at DeepMind, and then at OpenAI. Research infrastructure—the shared code that AI researchers rely on to run, evaluate, reproduce, and deploy experiments—might seem like an odd origin story for the person who would lead Codex. When you think of infrastructure you might think of servers and undersea cables, the tech world’s equivalent of plumbing: necessary, but invisible until a pipe springs a leak.
In the AI world, though, infrastructure—and particularly research infrastructure—is where much of the action happens, because infrastructure determines the rate of AI progress. If you can cut the time it takes to run an experiment, you can run more experiments and get a better model sooner.
“At what point did you split out the model line?” I asked. “How did you decide?” I wanted to fast-forward to the action. I pictured a scene inside of OpenAI where Tibo, or maybe Brockman, or cofounder and CEO Sam Altman made the uncannily prescient strategic choice to separate the Codex model and product from the rest of ChatGPT, thereby giving the Codex team the freedom it needed to ship quickly and disrupt OpenAI and the industry at large.
"There was no decision to split off the model line," Tibo said matter-of-factly. “This was a research exploration and an optimization of our velocity.”
Rather than building a model for public consumption, Tibo’s group worked specifically on training internal coding agents on OpenAI’s monorepo, the single repository where all of the organization’s code lives. The specialist agents wrote the Python code OpenAI’s researchers needed to run and improve the systems that built new models. Crucially, they had a tight feedback loop because the researchers themselves used the agents every day.
Their methods diverged from the rest of the company. “We were training models very, very frequently,” Tibo said. “We were seeing rapid gains on coding.” The techniques behind those gains were very different from—and for a while, hard to reconcile with—how the larger organization trained models for the public.
Tibo, as with everyone else at the AI labs, is tight-lipped about what exactly those training techniques were. But it became clear they were working: Tibo’s group had successfully turned the models back on the research process that created them, and these new models started being used by the researchers to make next generation models.
Engineers call this bootstrapping. Make a model that’s good at helping researchers run experiments, and the researchers can use it to build a more powerful one, which runs better experiments, which leads to a better model, and so on.
This internal research effort contained one half of what became Codex: agents that could improve the infrastructure researchers used to build new models. But it was still designed for OpenAI’s own researchers. To become a product that the rest of the company could use—and that would eventually make its way beyond the confines of OpenAI—it needed the other half: Embiricos’ thesis about how people should work with those agents.
[TRANSITION TRACE]
Thinking….
Three approaches so far…
Two of them overlap…
I’ll merge those and continue with what works…
After exploration comes convergence.
We can picture OpenAI from above in the last months of 2024 and early 2025. A hard prompt had arrived—coding became a top-level company goal and several teams started working toward the goal at once. In one corner of the company, Tibo's group was making fast progress training coding agents against the monorepo. In another corner, Alexander was sketching, part-time, a product built around asynchronous work, designed for the strengths—and weaknesses—of their capable-but-slow reasoning models. Other teams, in other corners, were working oblique angles on the same question. All the while,: In October 2024 its upgraded Claude 3.5 Sonnet took the top score on a widely used coding benchmark, and in February 2025 it released Claude 3.7 Sonnet along with a preview of Claude Code
The open question, Greg Brockman told me, was the right “form factor”: whether the agent belonged in a terminal, in an editor, or in the cloud. Some of these paths were blind alleys, but at the time nobody knew which.
This spirit of parallel inquiry inside of OpenAI sometimes feels chaotic and wasteful to a few insiders I spoke to. Who wants to work on the team that built the third best agent product inside of OpenAI? Having run a similar strategy at my own company, I know that there’s a thin line between creating space to explore and creating an utter, internal mess.
But, in watching OpenAI—and despite the internal grumbling I’ve heard—I have also come to see it as necessary when the frontier keeps moving. Because each leap in model capabilities radically changes what you can build with them, your previous experiences, intuitions, and decisions no longer apply. You have to throw them out and explore new ideas with many parallel paths, initiated from the bottom up. And then when you find a signal, leadership merges the most promising efforts.
By early 2025 OpenAI was ready to do just that. Greg Brockman, talking about the various internal coding efforts, said, “We ended up merging two of them. And then merging another two of them.” The combined team was a small multidisciplinary crew of technical product thinkers like Embiricos, infrastructure and engineering wizards like Tibo, and researchers like Mia Glaese.
Glaese came to OpenAI from DeepMind where she worked on Gemini and model alignment. At OpenAI, she was responsible for the data used for model training and alignment, meaning she specialized in getting and using data that would shape the specific behaviors of the models.
This sort of multi-disciplinary team, with product people and researchers working side-by-side, is somewhat unusual in AI. AI has historically been a research-driven field with the best researchers fetching multimillion-dollar Lebron James-sized salaries for their services while while everyone else is paid like an ordinary, well-paid engineer.. (The exalted superstar dynamic is one that OpenAI and other labs have long tried to counter, and is responsible for uniformly giving most technical employees, whether one is a researcher or not, the job title “Member of Technical Staff.”)
Instead of working in a silo, Glaese told me, researchers could see “all the amazing things that” the product team was applying their models to. Product people could ask, “Wouldn’t it be amazing if the model could do this thing?” It was Tibo’s bootstrapping loop again, this time running between a model and the product built on it.
By the spring of 2025, the merged team (Embiricos, Tibo, Glaese, and a handful of others) quickly set its sights on a new vision for the future of software engineering: Codex Cloud. They envisioned an agent in the cloud, with access to its own computer, designed for asynchronous work that would allow users to delegate coding tasks to from their computer or their phone. They gave themselves roughly seven weeks to build and launch it.
[TRACE TRANSITION]
Thinking…
Enough comparing….
I’ll go with the cloud approach….
It works for our researchers. It should work for other developers…
By then, Anthropic had a head start. On February 24, 2025, it released Claude 3.7 Sonnet and, with it, a research preview of Claude Code. Unlike Cursor and other IDEs, which put an AI assistant beside the code you were editing, Claude Code had no editor at all. It ran in the terminal, the text-only window where programmers type commands, and worked directly on the files on your own computer: You told it what you wanted, and it read the code, made the changes, and ran them. Developers took to it quickly. At Every, for example, Edmar Ferreira wrote in a March 2025 Vibe Check that, “Claude Code is better than anything that I have used on the agent front.” The rest of the team had begun to agree.
Why then did OpenAI skip the terminal form factor?
“We didn’t skip it,” Tibo told me in our cafeteria conversation. “We built a version of that and then discarded it after a month to go for the full cloud version.”
OpenAI did, in fact, release a small, open-source Codex CLI reminiscent of Claude Code on April 16, exactly one month before Codex Cloud. It was one more of Codex’s many beginnings.
Embiricos described it as a side project built “heroically by like two people.” But this CLI was not where OpenAI had placed most of its resources—or its best model. “You couldn’t even use the Codex model in the CLI,” he said.
This was partly a safety decision. A coding agent could do more than suggest code: It could edit files and run commands on the user’s computer. “As a company, we have a very conservative safety stance,” Embiricos said. “We actually had to do a lot of work to figure out how to get comfortable deploying that level of capability.” Early users instead had to run the CLI with a general-purpose model—o4-mini by default—that hadn’t been built to work as a coding agent. The CLI existed, but the attention of the team—and its best model—was on Cloud.
“Why?” I asked Tibo. I knew somewhere out the large floor to ceiling windows on all sides of me, if I really looked, I could probably find Anthropic’s office on the horizon. I could certainly walk there without much trouble. San Francisco is a small town.
“Because we were optimizing for what we thought we would benefit from the most if we were willing to invest a lot in the setup,” said Tibo.
Behind that answer was a belief I’d heard over and over from people inside of OpenAI. To them, the ideal form of an AI agent has always been one that works autonomously for you in the cloud, that doesn’t stop responding when you shut your laptop lid. Brockman had said the same thing in our interview: “If you project into the future, the right form factor is an AI in the cloud that has its own laptop. And so we actually built that.”
Codex Cloud was a first attempt at that vision. Clicking Codex in ChatGPT’s sidebar opened a workspace where you could describe a task and click “Code.” The assignment peeled off into a queue, clearing the prompt box for the next one. Codex copied your codebase into an isolated cloud machine, edited files, and ran tests and linters—tools that scan code for common mistakes. It returned a summary, a diff of the changes, and a button to open a pull request.
Embiricos’s idea of asynchronous work was built into the interface: Hand Codex a task, move on, and let several run in parallel. It was also a truce with model limits. “We didn’t really have the models to build a more interactive experience with, so we went with this asynchronous product,” Alex told me.
Codex Cloud was “very successful internally,” Tibo told me. Outside OpenAI, its launch drew interest but little sustained use.
To get it working, developers had to recreate their laptop’s software, permissions, and settings in the cloud—a process that was painful and often failed. Once set up, it could deliver on a well-specified task. But you couldn’t interrupt it to correct its course, and even a follow-up prompt started a fresh cloud computer.
By comparison, Claude Code was a completely different beast. Because it ran on your own computer, its work landed in the same files you were already working in, with the same tools you already had installed, and with the context of everything you'd done together so far. You could interrupt it mid-task. You could also bring lessons learned from one session into the next so that your system improved and compounded over time—something that Codex Cloud with its ephemeral cloud computers didn’t allow for.
“It’s a tool you’ll reach for if you’re a tech lead adding features or fixing bugs on an existing codebase. If you’re trying to vibe code a new one-person billion-dollar SaaS company, look elsewhere,” I said in our launch-day vibe check.
Inside OpenAI, standardized environments had made setup automatic, and the researchers had clearly defined work to hand off. The team’s own working environment had hidden how much they were asking of everyone else.
The product wasn't the only thing holding Codex Cloud back. The model was part of the constraint too, and the team knew it. The models weren’t yet strong enough to make that leap worthwhile. “It was too early because the models weren’t smart enough,” Alexander said.
“We were kind of approaching it with this more future vision,” Glaese told me. “We didn’t do this like, ‘Let’s go to the people where they are,’” which was “on their laptop.”
The product wasn’t working, and the models still weren’t good enough. The team’s engineering manager left for Cursor, the frontrunner in AI coding with a valuation of $9 billion, whose product featured a chat agent tucked into the sidebar of an IDE, or integrated development environment: the all-in-one desktop application where programmers write, run, and debug code. Around this time, OpenAI reportedly reached a $3 billion agreement to acquire Windsurf, Cursor’s closest competitor, which was built around the same idea. That deal would fall apart in July.
“The most challenging time was when we felt like we didn’t know what to do. Or we knew what to do, but it was really hard to see that [progress] actually happening,” Alexander told me.
For the first time, the Codex team—and to an extent OpenAI’s larger coding ambitions—were lost in the wilderness.
TRANSITION TRACE:
Thinking…
Hmm, this worked in our environment. Why isn’t it working in theirs?…
Maybe I’m trying to fix the wrong thing…
Going back to the local approach I set aside…
There’s something here. But I’ll need to rebuild it…
What makes a reasoning model powerful is its ability to backtrack. If it believes a bug lives in a particular function, and rewrites that function, only to find the bug still active, it does not typically continue marching confidently in the wrong direction. It can reconsider its assumptions, broaden its search for solutions, and decide on a new, more promising path based on what it’s learned.
This simple ability, using mistakes to correct course, is what allows reasoning models to find answers that were not obvious at the start.
In the aftermath of the Cloud launch, in late spring and summer of 2025, the Codex team was ready to try another path. At the time, the project occupied what designer Ed Bayes—who had recently joined the team—recalled as, “the backwaters” of OpenAI. “If you wanted to be the sexy designer,” he told me, “you work[ed] on ChatGPT.”
Here, into this neglected outpost, Tibo ascended as the team’s engineering manager. “I took over the team, and then I changed the direction quite a bit,” Tibo told me. “We pivoted to local.”
“Local” meant running the agent on the developer’s own computer, the way Claude Code did, instead of in the cloud. They started with the local Codex CLI that, as Alexander mentioned, had been “heroically” built as a side-project by two people. Rather than start adding features to it immediately, which would generate quick momentum, Tibo took a different tack. He decided to rewrite the agent.
"We were kind of slow to have really good CLI features,” Tibo told me, “because we were so busy developing the agent.”
The team started over in Rust, a language built for low-level systems work, where speed and safety matter more than ease of writing. And they split the agent apart from its terminal interface. This allowed them to use the same agent to power multiple products: A terminal CLI and, later, an extension for code editors like VS Code and Cursor.
The same agent could now sit behind a terminal or an editor. What it lacked was a model good enough to drive it.
That model was GPT-5—the one whose launch had brought me to OpenAI’s offices that summer. While the Codex team was realigning under Tibo’s leadership, OpenAI was pouring resources into making GPT-5 work well inside real codebases.
“The thing I think we missed or were slower to was we'd always had the best numbers on coding competition benchmarks. But actually connecting it to real world software engineering—that was the thing that we had under-invested in and under-appreciated relative to its importance,” Greg Brockman told me. Competition benchmarks test self-contained puzzles. On SWE-bench, a benchmark built from real engineering work, Anthropic’s models had already taken the top score.
A coding model can be like a student with a perfect SAT score who has never held a job. It aces the test and still gets lost in a real codebase. “They never had seen a messy code base or how a programmer might interrupt it halfway through…Those were not as keenly in our sights and focus,” said Brockman.
In the months before the GPT-5 launch, Michelle Pokrass, who had helped lead research on GPT-4.1, was working to close that gap. She led post-training—refining an already-trained model’s behavior so it could handle real programming work. Embiricos recalled that she was working with customers who had asked OpenAI for better interactive coding.
To give the booksmart models real-world experience, Pokrass and her team sat with programmers and watched them use the models to see where problems came up. Her team turned those failures into repeatable tasks, then trained the models to do better.
The post-training work paid off.
GPT-5 brought reasoning models into ordinary ChatGPT conversations, including for free users, for the first time. It came in several flavors—Instant, Thinking, and Pro—and sat behind a router which automatically decided whether or not to use the reasoning version for a particular query, a choice users had previously made themselves from a menu of models.
This meant that for many people, as we wrote at the time, it would be their first encounter with the powers of reasoning models. For programmers working in Codex, it was better at understanding how the pieces of an existing codebase fit together and following detailed instructions about what to change. The model could explain its plan, investigate a bug, and keep the programmer updated as it worked.
At Every, Naveen Naidu had spent four days chasing a bug that made Monologue, the dictation app he was building, freeze. Even a four-hour session with Claude Code one Sunday hadn’t cracked it. GPT-5 helped him narrow the search to the right part of the code and pinpoint the bug. “GPT-5 and I solved it together as collaborators,” he wrote in ourlaunch-day Vibe Check.
But while GPT-5 was the first OpenAI model our team found useful for real engineering, it still wasn’t the one most of us reached for.
Back in the conference room the night before launch, Alexander was typing emphatically on the pull request open on his MacBook.
“I’ve gotta run to this bug bash,” he said.
“Before Alex leaves, tell him about this new engineering philosophy,” Lindsay said. Alexander closed his laptop lid and swiveled his chair to focus fully on what I was saying.
“We call it compound engineering,” I said. “Kieran Klaassen on our team figured it out. We make a detailed plan up front. Then we delegate the task to the agent. At the end we review its work, and compound its learnings.” Alexander leaned more and more forward as I talked, like a ski jumper pointed down a hill.
“How does it compound from one task to the next?” he said.
I explained how the agent wrote markdown files as it worked about what it had tried along the way and read them back at the start of the next run. I told him the point was to push the developer up a level, away from writing code by hand. In normal engineering, I said, each feature makes the next one harder to build; compound engineering is supposed to do the opposite.
As I talked I felt excited too—and maybe a little crazy. Was any of this actually useful for real engineering? Or just a true believer’s pipe dream that only seemed to work because we were a small team building relatively small-scale products?
A notification went off on his phone. “I gotta run,” he said. “Can we talk about this more after launch?”
TRANSITION TRACE:
Thinking…
Rebuilding the whole app was too ambitious…
What is the smallest version of this I can finish?
A few more improvements to the editor…
Now back to the larger goal…
Sometimes a reasoning model is too ambitious at first. Ask it to speed up a website and it may start rebuilding the whole app from scratch—then stall, three files in, with nothing working. When that happens, a good reasoning model shrinks the problem. What's the smallest version of this I can actually finish? It picks one slow page and starts there. Progress resumes.
The danger here is that it can go down rabbit holes. It gets caught on refining the simple solution—optimizing each image on the page, cutting extraneous code—without eventually returning to the larger goal.
Shortly after the GPT-5 release in late August, the Codex team released a revamped CLI and an extension that brought Codex into Visual Studio Code and Cursor. Developers could continue using their code editor, and interact with Codex in a sidebar. The extension would eventually become, in Embiricos’s words, their “most-used surface,” overtaking the terminal interface they had started with.
OpenAI was putting the agent beside the code, inside the tools where programmers already spent their days reading and editing that code. The extension’s popularity gave the team another reason to keep building there.
At this time, the powers of reasoning models were still nascent enough that delegating production code to agents was commonly being snorted at by programmers who were used to writing each line of code by hand.
“I don’t let it drive my code,” David Heinemeier Hansson, the creator of Ruby on Rails, and an influencer in the engineering community was saying around the time of the GPT-5 launch. “The joy of a programmer, of me as a programmer, is to type the code myself.” Besides when the agent drives, he said, “I can literally feel competence draining out of my fingers.” By January 2026 he would write that AI agents were “fully capable of producing production-grade contributions to real-life code bases,” and at Rails World this September he declared the end of writing code by hand at his company.
But I wondered if this was a trap—the “faster horse” problem often attributed to Henry Ford. Each new user and feature request could pull OpenAI toward making programmers more productive in their existing workflows, without returning to the larger ambition of agents that could take on the work themselves.At Every, we were beginning to discover how much work agents could do without us looking at the code at all. We gave them whole tasks and came back to review the results. Claude Code, powered by Anthropic’s Opus model, was already good at this. Just before GPT-5 launched, it gained the ability to divide a task among several agents working in parallel.
The contrast with GPT-5 and the Codex CLI was stark.“GPT-5 is a Sonnet 3.5 killer, not a leap into the future,” Kieran Klaassen wrote in our launch-day Vibe Check.
Inside OpenAI, though, something else was happening.
TRANSITION TRACE
Thinking…
Codex Cloud had been too big a leap…
Customers are obviously loving what we have, Claude Code is now the product to beat…
Let’s catch up there…
[Interrupted]
With the Codex CLI and VS Code extension exploding in popularity, the logical choice would be to continue to invest in both of them. In a normal company, this move would keep you from getting fired.
Instead, the Codex team did something unexpected:
“We decided we should continue maintaining the CLI, but the next biggest immediate investment should be a native desktop app,” Tibo told me.
His reasoning was a forecast. Inside OpenAI, he could see the models completing longer tasks and drawing on information from outside the codebase, with voice and images on the way. People would soon be running several agents at once and spending their whole day with them. “It has to be like this very rich interface if you’re gonna spend all your time in it,” he said. Doing all of that in a terminal seemed silly to him. A desktop app could also reach people who would never open a terminal.
To help design and build it, Tibo brought in Andrew Ambrosino, a designer, programmer, and former startup founder.
Ambrosino reminds me of B.J. Novak’s character in The Office: dark hair, thick eyebrows, and a small, tight-lipped smile. In person and online, he gives the sense of perpetually being inwardly amused; whether or not anyone else joins him in the joke is a consideration, but usually appears to be somewhat secondary.
When, earlier this summer, Tibo promoted the Codex app on X, Ambrosino—who had helped build it—replied, “TIL codex has an app.” Anyone following him for insights into the future of artificial intelligence might scroll his feed and find a post with 617 likes consisting entirely of a single word: “ai.” The next day’s offering was, mysteriously, “tibo.” (1,000+ likes.)
(If you’re wondering what he meant by “tibo”, I can report that Tibo seems to be consistently on his mind. When I asked him whose comedy he admires, he replied, “Tibo is my comedy idol”. I leave it to the reader to decide how much this clarifies.)
When Ambrosino joined the small group working on the app, they knew they wanted to make a desktop app, but not what it would actually look like. All the team knew was that they wanted to make something they would use themselves.
“Our first mandate,” Ambrosino told me, was to make the app “our main thing day-to-day.” “We knew we wanted a surface that could be a daily driver, but [one] that was more lightweight than an IDE,” Ambrosino told me.
IDEs have been the center of professional programming since the 1980s, and by the 2020s the dominant one was Microsoft’s Visual Studio Code, which Cursor and Windsurf were both built on top of. Conductor, a Mac app for running coding agents, had a sidebar of tasks, each with its own agent and chat where you could give instructions and follow the work. ChatGPT supplied another reference point: a list of conversations down the side and a single thread in the middle. The Codex app took “more inspiration from chat than it does VS Code,” Ambrosino said of their design process. Anthropic, too, by that point, had a Claude desktop app.
The team worked quickly, answering the basic questions like how the sidebar should be organized (TK what they decided), how users would keep track of their work (TK what they decided), and how the basic interface should be laid out (TK what they decided).
Then came a harder question: When an agent got something wrong, could you fix the code yourself inside of Codex? The team decided on a risky answer: No hand-typing code allowed. If you wanted to make any changes to your code you had to ask the agent.
“We specifically wanted it to be a different thing [from an IDE],” Ambrosino told me. Let developers type code in the app, and they’d expect everything else their editor did—undo, search, keyboard shortcuts—and thereby notice what Codex lacked. Meeting, let alone exceeding, these expectations would have required a massive effort from a team of four.
In other words, the team decided Codex couldn’t win by being a “bad IDE.” It had to make coding with agents in Codex so much better that developers would choose it despite the missing an editor.
The only problem was: While they were building a tool intended to replace VS Code and other traditional IDEs, they were still building it with VS Code.
“Every day Alexander would come in and be like, ‘Let’s go around the table. Are you maining this app? Are you maining this app?’” said Ambrosino
At first the answers were all “no”—none of them was using Codex over their IDE. Without a code editor even a small correction required a conversation with an agent. Dominik Kundel, who works in developer experience, wrote in an early Slack message that, “it feels cumbersome to have to prompt Codex” just to replace a sentence.
Even Ambrosino himself had doubts: “I think ‘no file editing’ is the launch scope I’m most skeptical about,” he wrote in November.
The outside market made the no-IDE bet look even riskier. In November of 2025, Google released Antigravity, which combined coding agents with a full-fledged code editor—a very similar concept to the IDE style experience the Codex team was trying to get away from.
“We just kinda looked at each other,” Ambrosino recalled. “Did we make a huge mistake by not forking VS Code? We felt very conflicted on this, and I don’t think the team even agreed with each other,” he said.
The models powering the app were a problem, too. In November of 2025, Ambrosino told me, the Codex app—even fully featured—would have been “unreleasable because of the quality of the models at that point.” But Mia Glaese’s work on the Codex model line was beginning to change the equation.
On November 19th 2025, OpenAI released GPT-5.1-Codex-Max, a variant of the Codex model that could code for hours at a time. They followed it quickly with GPT-5.2-Codex which improved even further—it was able to carry out effective edits on large codebases making it a viable workhorse for serious engineering tasks.
To produce these updates, Glaese worked directly with the rest of the Codex team to further shorten the feedback loop between developer feedback and model improvements. Crucially, they prioritized improvements that worked well inside of Codex for real workflows instead of just trying to improve their scores on popular benchmarks. And because the Codex model line was separate from the main ChatGPT model, they could move more quickly without worrying how each change would affect the rest of the 800 million people using OpenAI’s general models.
Around the release of the GPT-5.2-Codex, the team started using Codex over IDEs like VS Code in their daily work. Team member Dominik Kundel wrote in a Slack message, “I was originally craving a code editor now most of my changes I just leave inline comments and it's rapid fast.” Ambrosino remembered thinking, “I do have to steer [the model] a lot, but I don’t have to edit [code] by hand.” Glaese, too, became aware that the sentiment had changed internally. “5.2 was a turning point where I was like, ‘Wow, I’m very excited about what this can do for me,’” she said.
By early January the whole team was using the app. The next test was whether the rest of OpenAI would adopt it. If not, Ambrosino said, it was ‘back to the drawing board. By February the Codex desktop app was gaining wide adoption on the engineering and research teams. OpenAI researcher Noam Brown said he had “fully switched” to it, and Greg Brockman, a devoted terminal and Emacs user, had too. He said returning to his old workflow, “felt like going back in time.” Sam Altman would describe it later as, “the most loved internal product we’ve ever had.”
The Codex team had built something that developers inside of OpenAI loved. But Codex Cloud had also been embraced inside OpenAI and flopped once it was launched. Would this time be different?
TRANSITION TRACE
Thinking…
Everyone here is using it…
But I’ve mistaken that for success before…
This time it works where the user already works…
Time to test it outside…
The Codex MacOS desktop app was released to the public on February 2, 2026. It looked more like a chat app than a code editor: a sidebar held ongoing and historical tasks, and clicking one opened a conversation with the agent that was doing the work.
You could ask one agent to fix a bug, send another off to build a feature, and move between them to answer questions or review their changes. Each could work on its own copy of the code, without overwriting the others’ work. You could stay close and steer, or leave several assignments running and come back when they needed you.
At the time, none of this was especially groundbreaking. The Claude Desktop app, for example, had for many months at this point allowed technical and non-technical users to do the same. But the Claude Desktop app had been built step-by-step, starting with Chat, then adding Code, and then adding Cowork—which left its interface confusing and tacked together. It was hard to figure out which tab to use for which task, and what set of features or permissions would be available in each.
The Codex app bore none of these scars. When I used it for the first time—alongside the new Codex model released a few days later, 5.3—It was fast, simple, and totally agent-native. There was a fluidity to the experience; a feeling you get when all of the details of a product are right. Because of the team’s early insistence on excluding a code editor, they made sure that the Codex agent could do almost anything inside of the app that a user could do. That meant much less time digging through settings screens to, for example, connect a new tool. Instead, you could just ask the agent.
GPT-5.3 Codex was also a turning point in OpenAI’s model capabilities. According to Glaese, it was the first time they had started to branch out from programming-specific training for the Codex line. They still named it Codex, and she wasn’t claiming it was better at everything. But the team had begun asking what else a coding agent needed to know to be useful for all kinds of knowledge work—not merely what else it needed to know about code.
The impact on my workflow was immediate: I switched from using Claude 80% of the time to using Codex half the time. On Proof, a document editor I was building, I watched Codex fix complex bugs autonomously without much intervention. Soon I was leaving it working overnight on difficult problems, and anytime I was faced with a particularly gnarly task, I went to Codex first.
The change spread through Every. Monologue GM Naveen Naidu saw his use of Ghostty—the terminal app where he usually ran coding agents—drop as he moved his Monologue work into Codex. “Now I’m just living in the Codex app,” he said.
Then GPT-5.4 arrived in early March and cemented Codex as daily driver. It was still an expert coder, but now it explained itself clearly and better understood what I wanted. And because the Codex app had a clean and fast interface, I started to do all of my work inside of it.
By then many people at Every were using OpenAI’s tools and models every day—a reversal from just a few months earlier where Claude was far and away the dominant choice. As we put it in our GPT-5.4 Vibe Check: OpenAI was back.
The same thing was happening far beyond Every. By March 19, OpenAI said Codex had passed two million weekly users, while overall usage had grown fivefold since the start of the year. In April, OpenAI added an in-app browser, so the agent could look things up and check its work on a live page; the ability to work across other Mac apps; and previews for documents, slides, and spreadsheets, so someone who never touched code could ask for a deck or a budget and see the result without leaving the app..
By June, Codex had more than five million weekly users, and roughly one in five was a knowledge worker. On July 9, OpenAI made the Codex desktop app the new ChatGPT desktop app, with chat inside it. Under the hood, the new ChatGPT still tells your Mac its name is com.openai.codex.
A year earlier, Codex Cloud had shipped as a tab inside ChatGPT. Now ChatGPT runs on Codex.
Ed Bayes remembers walking out of the all-hands where the merge was announced thinking about how far the team had come. What had started as "a few people in the corner" had now become "the future of ChatGPT."
“This is like a piece of American corporate history,” he told me.
*
TK years and TK months after the night of the GPT-5 launch, I was back in a conference room with Alexander Embiricos.
"I'm just going full honesty here, right?" Alexander asked.
"Please do," I said.
It was early June, a month before the merge, and we sat in OpenAI's New York office. Alexander wore a gray zip-up with the sleeves pushed up. His role had recently changed from product lead for the Codex agent to OpenAI’s head of enterprise product. Behind him was a whiteboard.
I had come to ask Alexander how Codex went from Codex Cloud’s failure to becoming the foundation of ChatGPT. How did they get away from pair programming? A product that succeeds at one thing usually keeps doing that thing. Codex hadn’t. What had let them keep moving?
Alexander sketched Codex’s growth on the whiteboard with a black marker. He started with a short upward curve for Codex Cloud. It was a nice spike, but that flattened out quickly.
Then he drew a steeper, bigger curve, for the CLI after GPT-5; another, higher still, for the IDE extension. Last came 5.3 Codex and the desktop app, a curve that dwarfed the others. The first mark now looked like a scratch near the bottom of the board.
The curves looked like a compressed history of an industry, each new product climbing past the last. But all four belonged to the same company, drawn by the same hand.
"For me, GPT-5 was actually a really big deal and a really positive moment," he said, "because before GPT-5, we were incredibly far behind on coding models." It was the first model, he said, where "we felt like we were actually in the game…finally we can fight now."
GPT-5 was one reason a new curve could begin. Later, 5.3 Codex would make the app useful for more than code. Each improvement in the model opened more territory for the product. Tibo had described the other part: how quickly agents let the team try a new surface. Much of the team switched to using the app in under a month; without agents, he thought that progress might have taken four or five months. “It takes way less talking now to convince people,” he told me. You could build something, show it, let people try it. The black curves on Alexander’s board now looked like two things moving together: what the models could do, and how fast this team could show people a new way to use them.
[
Tibo said it took less than a month for much of the team to switch—progress he estimated would have taken four or five months without agents. That speed mattered to more than the development schedule. “It takes way less talking now to convince people,” he told me. You could build something, show it, and let people try it. “That’s a lot more convincing than any document you could write before.”
But within a month of starting to build—as a testament to how fast coding agents made their development process—much of the team had switched to using the app as their main tool.
Tibo credits this with the reason the effort succeeded. “I think pre-agents, maybe this would have taken us four to five months, and it would've been very hard to convince people. Because we were kind of able to make rapid progress,” that changed the equation.
]
“Oof. I have to think about this a little bit,” he said. If a product could take advantage of the new capabilities, he wanted to extend it. If it couldn’t, the new idea needed room. The CLI had needed room outside ChatGPT; now the app gave the agent a path back in. “Our job is to build an agent,” he said.
By then we were six minutes over. He asked if there was a point I was trying to get to. “How does it feel to be behind?” I asked. He said the hardest stretch was when they could not see what to do. Once GPT-5 arrived, he said, “I know exactly what we need to do.”
He had one more move in mind: the agent would keep working after you closed your laptop. “And then we’re gonna move to asynchronous,” he said, “which means we’re gonna have to rehoist to the cloud.”
NOTES:
3. Later payoff: Users won’t leave
Who: Marketing, communications, finance, and legal staff adopted Codex despite its developer-oriented interface.
Alternative: OpenAI experimented with bringing Codex capabilities into ChatGPT’s desktop app and Atlas.
Result: According to Andrew, users preferred staying in Codex.
Story use: The small team built something people chose over established alternatives. Save this for the broader organizational payoff—not the initial four-person test.
Source: Andrew on Lenny’s podcast — 52:18
WORKING BEATS — WHY THE DESKTOP APP

1. The models were outgrowing the work the current interfaces were designed for.
   After Andrew’s design references, turn to what Tibo could see inside OpenAI: models successfully completing longer assignments and using information outside codebases. Voice and image generation widened the possibilities further. This is his account of the bet, not a claim that every capability was already part of the launch app.
   Full quote — Tibo, turn 45:
   “And the information that I had at the time was that our models were rapidly getting better. And we were seeing the models do longer and longer horizon tasks successfully. We're seeing models capable of ingesting a lot of data outside of code bases as well in order to inform their work.
   And then we were early at OpenAI as well on voice and multimodal. We had state-of-the-art image generation, state-of-the-art advanced voice mode that shipped two years ago.
   And so this idea of playing it out where is this very rich interaction, it just felt completely silly to expect that that would happen in a terminal. But obviously requires a lot of conviction to then go and do it.
2. That forecast made the terminal an unlikely long-term home.
   Bring the capabilities together with multitasking: several agents working at once, richer output, and ways to interact beyond typing commands. This explains the desktop investment, not just a preference for a nicer-looking CLI. In the eventual prose, use one of Tibo’s overlapping terminal conclusions rather than repeating both.
   Full quote — Tibo, turn 41:
   “It has to be like this very rich interface if you’re gonna spend all your time in it,” Tibo told me. “And just doing all that in your terminal felt like a very silly when you played it all out.”
3. Users could grow from collaboration into delegation.
   Alexander supplies the intended change in workflow. Users could begin by working closely with an agent, then learn which tasks they could leave to it. Unlike the original Cloud product, this did not require committing to fully asynchronous work from the start. This addresses Dan’s earlier worry about getting stuck in pair programming; let the intended progression emerge before declaring whether it succeeded.
   Full quote — Alexander, turn 173:
   ““We need to build a very flexible primitive that runs on the user’s computer and that people can use as interactively as they want, and in fact we think people will start using it very interactively and then, like, kind of onboard a teammate, they will learn how to use it less interactively.” - alexander
4. The same app could eventually reach beyond programmers.
   Widen the audience after explaining the workflow: someone would not need to learn a terminal or live in a code editor to work with the agent. Alexander’s two transitions connect the workflow and audience ambitions. Translate the terms into ordinary language in the prose; this is the direction he describes retrospectively, not proof that the initial app already served every audience.
   Full quote — Alexander, turn 212:
   “And so I talked about this a bit earlier as well, but for us, moving to the app was a big part of how we got to ... It was kind of two things actually. The app helps us transition from sync to async. And it also helps us transition from dev to non-dev.” - alexander
   Next: test the ambition against the builders’ own behavior. Move to Alexander’s daily “Are you maining this app?” question once the reader understands what they were trying to build.
   “GPT-5 was the first model where we felt like we were actually in the game,” Alexander told me later, recalling that night. “Once we [shipped] the CLI and GPT-5…it was just like it created this self-fulfilling flywheel,” he said.
   [ Jump to Andrew ]
   Once we ship the CLI and GPT-5, well, mostly GPT-5 with the CLI as a light wrapper around it, it was just like it created this self-fulfilling flywheel—timeline 46
   PROPOSED BEATS — THE DESKTOP BET
5. Enter the room before they know what they are building
   Pick up the “Jump to Andrew” with the small group trying to work out the app. Andrew remembers “four of us or maybe, you know, a little more if you count Thibaut and such.” The useful opening is uncertainty: “we didn’t really know what it was gonna be.”
   Dan: “Like Conductor?” Andrew: “Like Conductor, yep.” He praises Charlie’s team. They had examples of something lighter than an IDE, not a finished blueprint. The goal was “a surface that could be a daily driver, but that was more lightweight than an IDE.” Concrete early questions: how to organize the sidebar and people’s work, and how separate working copies of a project would function. The browser and plugins marketplace are Andrew’s retrospective examples of what the app could accommodate, not evidence that every feature existed at inception.
   Connect this to Tibo’s bet: “we should continue maintaining the CLI, but the biggest next investment should be like a native desktop application.” He saw longer tasks, information beyond codebases, multitasking, voice, and richer interaction ahead: “It has to be like this very rich interface if you’re gonna spend all your time in it. And just doing all that in your terminal felt like very silly when you played it all out.”
   Timing: Andrew places development roughly from mid-November to February; Tibo places making desktop the main bet in December. Exploration followed by commitment is a plausible reconciliation, not yet an established sequence.
   Sources: Andrew — the room and Conductor · Andrew — the daily-driver brief · Tibo — desktop instead of more CLI · Tibo — the capability forecast · Andrew — development window · Tibo — December commitment
6. The first customers have to be the people building it
   Their first mandate was to make this the small team’s main tool, day to day. Use the recurring scene rather than a general claim that they believed in dogfooding: Alexander comes around the table every day and asks, “Are you maining this app? Are you maining this app?” At first the answers are no; then one person starts saying yes. Andrew’s wording around “all nos” is garbled in the transcript, so paraphrase that part.
   Dan asks what “maining” means. Andrew: “Like, I am not opening VS Code.” That is the test—not whether they can demonstrate it, but whether they stop reaching for the editor. Andrew also credits dogfooding for the app’s feel; his criticism that competitors seem not to use their own products is his judgment, not an independently established fact.
   Sources: Andrew — the daily round-table question · Dan and Andrew — what maining means
7. Antigravity makes the alternative look dangerously plausible
   While they are still trying to make the app their daily driver, Antigravity arrives. Andrew recalls looking around the office and asking whether not forking VS Code was a huge mistake. The team was conflicted and did not all agree. The line to retain: “You know what? Let’s sit on it.” They ultimately decided to keep building their own app.
   The surrounding exchange sharpens the scene. Dan asks how many people were maining the app when Antigravity appeared. Andrew: “It might have been half, but it wasn’t all of us yet.” Their own adoption was still incomplete when the competitor made them question the direction.
   Why the doubt was reasonable: an IDE already offered file editing, customizable panes, and familiar workflows. If the model kept getting things wrong, steering it could be slower than opening a file and fixing it yourself. Andrew says he does not remember the exact sequence of the capability changes. Keep this challenge during the build; do not silently place it after December’s commitment.
   Sources: Andrew — Antigravity and disagreement · Dan’s follow-up and Andrew’s half-the-team answer · Andrew — the case for an IDE
8. The models improve while they are building
   This is a bet on capability, not just a different interface. Andrew says that even an app finished to its eventual February quality would not have been ready for release in November: “it would’ve been unreleasable because of the quality of the models at that point.” Their closeness to research gave them a better sense of the direction and speed of progress; he still calls it a bet.
   Retain the public milestones alongside the app’s development: Nov 19, 2025 — GPT-5.1-Codex-Max, trained to work across context windows using compaction. Dec 18, 2025 — GPT-5.2-Codex, with improvements to long-running work in large repositories, including migrations and refactors. These are documented capability gains, not proof of which release incorporated the Coding Ninja Sprint.
   Mia, after Dan explicitly asks about 5.2-Codex: “5.2 was a turning point where I was like, ‘Wow, I’m very excited about what this can do.’ And like what it can do for me.”
   The practical threshold, in Andrew’s words: “yes, I do have to steer this a lot, but I don’t have to edit it by hand.” His distinction is production quality, not the first ability to generate code: they could now work this way while meeting the quality bar for the app itself. This answers the conference-room question without pretending human collaboration disappears.
   Sources: Andrew — why November would have been too early · Andrew — research visibility and production quality · GPT-5.1-Codex-Max announcement · GPT-5.2-Codex announcement · Mia — the 5.2-Codex turning point · Andrew — the no-hand-editing threshold
9. From one yes to the team, then the company
   Return to the daily question for the payoff. In the continuation of the interview, Andrew says, “once we were all yeses on maining the app, we released it to the company.” The next gate was internal product-market fit: if they could get it, they could release publicly; otherwise, “back to the drawing board.” Tibo says much of the team switched in less than a month. Keep the useful complication that AI-assisted development let them test the bet quickly, rather than spending months defending it without a usable product.
   Possible callback to Cloud: internal adoption mattered there, too, and did not guarantee external fit. What is different here is the test being described—replacing the editor in daily work. Let subsequent external use establish whether this time the experience transferred; dogfooding alone does not settle that question.
   Sources: Andrew — all yeses and the company rollout · Tibo — rapid prototyping and adoption
10. Land the bet, keeping the launch sequence straight
    Feb 2, 2026 — Codex desktop app launches. Feb 5, 2026 — GPT-5.3-Codex launches. Do not reverse these because an interview compresses the sequence; internal model availability may have differed from public release.
    For the reasoning-trace theme, the evidence supports people choosing to build ahead of complete proof, disagreeing about the alternatives, and testing the result against their own behavior. “A model could never make this leap” remains a thesis to defend, not something the interviews establish. The payoff is a new way of working becoming practical, not merely a successful prediction about a screen.
    Sources: Codex app launch · GPT-5.3-Codex launch
    Reporting questions to keep open
    Greg / Michelle: When exactly was the Coding Ninja Sprint, what concrete failure did it fix, and which release first included the change? Confirm the sprint’s name against the recording.
    Mia / Lindsay: Who led September’s GPT-5-Codex training, and how did that team overlap with Michelle’s interactive-coding work?
    Tibo / Andrew: Reconcile mid-November development with December’s main bet. Who was in the original room? What settled the Antigravity disagreement? What specific task made the first person stop opening VS Code? Andrew’s “might have been half” gives us a relative adoption marker, not an exact date or headcount.
    END OF NEW PROPOSED BEATS — existing scratch notes and earlier source material continue below.
    Merger of the o series into the base models, router
    Michelle Pokrass
    Now we can start to see that conference room in its proper perspective.
    They really were behind. GPT-5 as a model really was improved. Its harness WAS too circumscribed, couldn’t get th emost out of it. They really did go back to pair programmer. Why? Probably part of it was competitive pressure, part of it was the limitations of the model, part of it was not wanting to skip a step again, and go back to the actual evolution: copilot, to VS code extension, to cli. Part of it is probably feedback from customers, what they actually wanted, and being a bit captured by that.
    And there’s this tension that was present then about what senior engineers actually wanted. And whether they would get stuck there (pair programming) vs. what AI engineers want.
    And I was afraid they’d get stuck, and they probably did a bit. But interestingly, every frontier company seemed to eventually make the jump to not looking at the code.
    ===
    PROPOSED BEATS — IN THE WILDERNESS: CLOUD → GPT-5
11. THE EMOTIONAL FLOOR. Alex: “The most challenging time was when we feel like we didn’t know what to do. Or we knew what to do, but it was really hard to see that actually happening.” He was “really pushing hard to get us to try an interactive coding product,” but “we really needed to have a good model to do this with.” Tibo also says the first return to local was “too early.”
12. THE RESEARCH THREAD COMES IN FROM THE SIDE. Michelle Pokrass was already working on better interactive coding before the Cloud launch; she was a research lead on GPT-4.1. Alex says she was “mostly ... working with other customers we had that were asking us to improve our interactive coding capability.” Greg separately recalls a midyear “Coding Ninja Sprint” focused on messy codebases, interruption, customer feedback, and post-training. Do not conflate the earlier model work and the later sprint or assign either a more precise date than the sources support.
13. RETURN TO THE NIGHT BEFORE GPT-5. The model becomes the first one that makes the rebuilt, local, interactive strategy feel viable internally. Alex: “GPT-5 was the first model where we felt like we were actually in the game”; “Finally we can fight now.” End by returning to the opening conversation: you see a company losing the plot; Alex sees the first moment the pieces might fit together.
    CHRONOLOGY GUARDRAILS: The Rust rewrite is underway before GPT-5. The Windsurf acquisition belongs to the summer competitive backdrop. The IDE extension launches after GPT-5, not on the same day. The later GPT-5-Codex model launch is separate from the original GPT-5 launch.
    ====
    MIA, looking back: “We were kind of … approaching it with this more … future vision.” “We didn’t do this like, ‘Let’s … go to the people where they are,’” which was “on their laptop.”
    CONNECTIVE BEAT: The setup had been invisible inside OpenAI. Outside, it was part of what users had to acquire, configure, and live inside.
14. Save the second failure for the next movement.
    TIBO: As models improved, users wanted more system context and “felt trapped … inside … that little VM.” “So we went back to local.”
    CONNECTIVE BEAT: Cloud was not simply a bad idea. It had reached toward the future before the model, the product, and the customer environment could meet there.
15. Why the provisioned setup worked internally—and why it was hard externally.
    “It was very successful internally.”
    “Everyone having … perfectly … reproducible environments, provisioned dev boxes at scale … seemed like the way to go.”
    “But then externally that was … way too high friction.”
    “With models getting better and better … you wanted to pull in … a lot more context … [and] felt trapped … inside of that little VM.”
    “So we went back to local. Then again, it was … too early.”
    If you take a step back and think about it, it’s a little ridiculous that Codex Cloud was built in eight weeks. A few years ago, it would’ve taken—generously—six months to a year.
    CLOUD SPRINT — BEATS + SOURCE QUOTES
    SOURCE CHECK: Tibo calls this “roughly a seven-week sprint,” not eight weeks.
16. The Cloud choice followed the model-research path, not a settled product preference.
    ALEX: “We really predicated the products we built around what the research team thought that they could deliver the best model for.”
    ALEX: “It seemed like there was clearer line of sight to improving model performance for an asynchronous product. … If we could increase test-time compute, we got better performance.”
    ALEX: “We didn’t really have any line of sight at the time for … really strong … interactive models. … ‘All right. Well, let’s design a product around asynchronous models.’”
    ALEX: “Codex Cloud was really just like a product built around a model, and a model research direction of asynchronicity.”
17. The CLI history is not one clean prelude. Preserve two accounts, and do not yet say they describe the same artifact.
    TIBO, on an internal terminal-shaped version: “We had it internally. We did not release it. … We built a version of that and then discarded it after a month to go for the full cloud version.”
    ALEX, on a public CLI: “We actually shipped the CLI even before Codex Cloud, but that was like a very small side project, done like heroically by like two people. And it … wasn’t really successful because it had no good model to power it.”
    ALEX: “You couldn’t even use the Codex model in the CLI.”
    SOURCE NOTE: The interviews do not establish that the internal version and public CLI were the same thing. They also do not say security was the reason the public CLI lacked a good model.
18. The merged team then accelerated toward a Cloud agent: a model with time, tools, and a computer of its own.
    TIBO: “As I’m working with Alex, we were … working on what’s referred [to] as the cloud sprint, which was … roughly a seven-week sprint. Then we came out with Codex, the cloud version.”
    GREG: “The right form factor is an AI in the cloud, right? That has its own laptop, that’s able to execute things on its own. And so we actually built that, and that was basically Codex Cloud.”
19. The bet had immediate proof inside OpenAI. Save the external-friction diagnosis for the following scene.
    TIBO: “It was very successful internally.”
    TIBO: “Everyone having … perfectly … reproducible environments, provisioned dev boxes at scale, … seemed like the way to go. And it … was making … people a lot more productive.”
    TIBO: “Then externally … that was … way too high friction.”

The first product question: what do you build when a reasoning model can work in code, but needs a computer and time?
The local/terminal thread: both men describe an early terminal-shaped agent, but preserve the discrepancy for now — Tibo: an internal version, not released, quickly discarded for full Cloud; Alex: a tiny CLI that shipped before Cloud, but lacked a good enough model.
On scale and timing: “The very early versions were… a handful. And then it got a bit bigger when we started to actually do the external—when Cloud Codex launched, for example.”
On physical organization: “Product engineers and researchers… [were] just sitting next to each other.”
On the alternative she rejects: it was not research handing a model to product to wrap afterward. “I don’t think either of them is true.” Instead, researchers could say, “Here’s all the amazing things that we could build,” while product people could say, “Wouldn’t it be amazing if the model could do this thing?”
On the actual operating model: “We can… sit together and… build something together.” They could decide what Codex should do, then “build the model for that,” alongside “the product and the harness and everything that we need for that together.” Her clearest summary: “We are thinking about this as… one… joint thing that we build together.”
On why that matters culturally: researchers and engineers are “both… building a thing,” but the work has different complexities. The arrangement requires “trust and respect”—the researcher accepting that the engineer knows production constraints, and the engineer accepting the researcher’s judgment about the model.
Andrew gives you the cleanest retrospective framing:
“One of the great successes of Codex as a team was pairing the product team and the research team together very closely, especially when it came to the harness.”
“Eventually, we thought we should combine forces with another effort, which was called Scientific Assistant,” Tibo told me.
*
[ALEX / DEVELOPERS + MOVING OUT — WHITEBOARD EXCHANGE — VERBATIM, LIGHTLY CLEANED]
Alex: “It’s like dev, non-dev. And then it’s sync, async.”
Alex: “We’re just going to start here [the dev, sync quadrant]. And then we’re going to kind of move this way and also move this way. But you have to land here.”
Dan: “Why? Because you would imagine one way I could say is, well, to be really good for devs, you have to be so smart and so good that we should start with consumers.”
Alex: “There’s a lot of reasons that I think developers are the right place to start. They as an audience are very interested in trying new tools. You’re just going to get a lot more adoption. They are interested in trying open-ended tools, and they will figure out how to use it. They are the best audience for providing actionable feedback for something that’s still early. And then you can figure out how to productize from there.”
Alex: “I think the second thing is actually that the tasks are way easier to build for.”
Dan: “Coding tasks are verifiable.”
Alex: “The interesting thing about [coding tasks] is they’re verifiable. There is an existing place where the human is in the loop. A lot of coding is regulated too. It’s just we already have established human practices. It’s called code review.”
Alex: “Coding tasks are hermetic. You can do a coding task in a sandbox without access to the internet, and it’ll work pretty well. As you’re getting started, you can literally limit it to a folder on your computer.”
Alex: “The specificity of the task you get is quite high here, and a developer knows how to change how they’re specifying to give you what they want. [For non-devs], the task specificity goes down. Eventually we’re going to get here where they don’t even know what they want, and we have to be useful. So that’s why we want to start there, and kind of productize our way through.”
[TIBO / DEVELOPERS EXCHANGE — VERBATIM, LIGHTLY CLEANED]
Dan: “What about, if you were ever going to split out a model line again—and maybe a product too—in the same way? You had a ChatGPT desktop app; you didn’t necessarily have to do a separate Codex desktop app. When is it the right move to do that kind of split?”
Tibo: “We were optimizing for velocity first and foremost. There was a deep sense that all of this was going to change again and again in the course of a couple of months, and you need to optimize for how quickly you can ship and move. And we needed to start with a very forgiving audience as well.”
Dan: “By ‘forgiving audience’—usually people don’t think of developers as being particularly forgiving.”
Tibo: “I think they’re amazingly forgiving. And they are very good with feedback as well, which makes it delightful to work with.”
Dan: “They understand what it means to build a product, whereas Joe in Montana, who uses ChatGPT to get answers, doesn’t understand what’s going on under the hood.”
Tibo: “If it doesn’t work, that person will probably stop using your product. Whereas an early adopter and a developer will come and bother you and be like, ‘Hey, you broke me. And I want to know about that, and I want to fix it. And I want to learn from you.’”
Dan: “That feels like another good generalizable strategy: serve builder-type people with new AI stuff, because they’re going to figure out all the different corners and all the ways that you might not even realize, and then you can translate that to everybody else. Is that consciously something that you guys are doing?”
Tibo: “Yeah, I think there’s a lot that we learned from that strategy. And now we’re reproducing it in other corners.”
Tibo and Alex merge in scientific assistant.
They even developed a version of their internal coding model built into a terminal UI, like Claude Code. At this point, they made their first false move. “We had it internally. We did not release it. We went through that phase very quickly. We built a version of that and then discarded it after a month,” Tibo told me.
Why? Building for yourself is the most powerful technique in AI, but it has a particular pitfall. It gives you unusual insight into what kinds of products are useful because you’re testing the model against tasks that you can judge accurately. But, if you’re not careful, it can also disconnect you from what might happen when your internal solution meets the complexity of customers and their development environments.
If that happens, you end up building something that looks like the future but is too early. Which is the same thing as being wrong.
*
GREG ON “EXPLORATION AND COLLAPSE” + CLOUD — GREG, turn 8
“And on the tooling side, that we'd experimented with a few different form factors, and I think that the place we'd started was with a, um... And we actually had several different efforts. We ended up, like, merging two of them and then merging another two of them. [laughs] So we ended up with, like, a little bit of exploration and then collapse, but I think that a lot of the energy was about, like, what is the right form factor? And if you think project into the future, that the right form factor is an AI in the cloud, right? That has its own laptop, that's able to execute things on its own. And so we actually built that, uh, and that was basically Codex Cloud. But it didn't get PMF, and I think it was too early, right?”
NEXT-SECTION BEATS — WORKING MAP
The merger: Tibo’s research-acceleration effort joins Scientific Assistant; that is where he and Alex begin working together.
The first product question: what do you build when a reasoning model can work in code, but needs a computer and time?
The local/terminal thread: both men describe an early terminal-shaped agent, but preserve the discrepancy for now — Tibo: an internal version, not released, quickly discarded for full Cloud; Alex: a tiny CLI that shipped before Cloud, but lacked a good enough model.
The Cloud bet: the combined team runs the roughly seven-week Cloud sprint and launches Codex Cloud. It works inside OpenAI; outside, it is too early / too frictionful.
ADDITIONAL VERBATIM SOURCE QUOTES FOR THIS NEXT SECTION
(Exact transcript language; headings are mine.)
MERGER + CLOUD — TIBO, turn 23
“That was, like, my background. And so did this for a bit and then as things started to work, uh, we got, like, increasing adoption, increased our ambitions step by step. Eventually to the point where, um, we thought we should combine forces with another effort, which was called, um, Scientific Assistant, and there was, like, a merger of teams, and that's when I got to know, uh, Alex. So as I'm working with, with Alex, we were, um, working on what's referred a-as, as the cloud sprint, which was, like, a roughly a seven-week sprint. And then we came out with Codex, um, the cloud version, which was really, really exciting. It was, like, a little bit too early. Um, eventually, it's, like, what we're going back to. Like, what everyone will go back to. Um, but it did not have PMF at the time, and it was, like, too, too, too frictionful.”
LOCAL VERSION → CLOUD — TIBO, turn 25
“We didn't skip it. We, we had it internally. We did not release it. Um, we went through that phase very quickly. We built a version of that and then discarded it after a month to go for the full cloud version.”
THE LATER CLI PIVOT — TIBO, turn 33
“It was rooted in this, this very, the very beginning of this, this research acceleration effort, which I was part of, where we were training agents specifically on coding, um, to help us write infrastructure and do research faster. Um, and we were doing so off of things that were so far of, you know, what we were doing for, like, external models. This is just really, um, a research exploration and an optimization of, you know, like our, our velocity. So we were training models like, you know, very, very frequently. We were seeing, you know, rapid gains on coding. And so we continued doing that and, um, what we developed is, like, a series of research methodologies that were, you know, very different and were, like, hard to reconcile for a while. Um, and then the-- One, one of the relevant things here is, um, after, after the Claude Sprint, we did not immediately find PMF, like the engineering manager left for Cursor. I took over the team, um, and then I changed the direction quite a bit. We pivoted to local. Um, I-- We, we, we had a bit of a lull with the Rust rewrite of like the, the CLI, which was, like, very controversial.”
WHY THE CLI WAS NOT THE MAIN THING — TIBO, turn 35
“Um, yeah. So the, the, the Codex CLI initially was written in TypeScript. Um, then there was a, there was a Rust rewrite, um, where we decided to... That it wasn't this, the, the, the CLI was the way to interact with the agent, but just really the underlying infrastructure was our agent, which was our, like, our most precious infrastructure. Uh, and we needed to take great care in it and, you know, think about, you know, the correctness, the security, sandboxing, and all of that was like, you know, low-level system design. And we wanted to invest in it. And for the long term, there was, like, absolutely no lack of conviction. There was, like... It's like 100% conviction that this is, like, very, very core to our success. Um, and so we decoupled like the textual, uh, the, the Tui implementation from, like, the agent implementation very early on.”
VELOCITY + DEVELOPERS — TIBO, turns 57, 61, 64
“We were also optimizing for, uh, velocity first and foremost. Um, just deep sense that all of this was going to change again and again in the course of a couple of months, and you need to optimize for, like, how quickly you can ship and move. Um, and that we needed to start with, like, a very forgiving audience as well.”
“I think they're amazingly forgiving. [laughs] And they are very good with feedback as well. Um, which makes it, you know, delightful to work with. And you can sort of, like, navigate, you know, the fact that you get like a thousand different feelings thrown at you.”
“Yeah. Yeah. And if it doesn't work, it's, you know, that, that person, you know, will probably stop using your product, whereas, you know, someone who's, like, an early adopter and a developer will come and bother you and be like, ‘Hey, you broke me.’ Um, ‘And I wanna know about that, and I wanna fix it.’ ‘And I wanna learn from you.’”
START WITH DEVELOPERS — ALEX, turn 194
“Yeah. So there's a lot of reasons that I, I think devs are the, developers are the right place to start. Um, so, a-and I mentioned this a bit during the talk, but I don't know if you arrived yet. Basically, I think that they as an audience are very interested in trying new tools. Um, so you're just gonna get a lot more adoption. They are interested in trying open-ended tools, and they will figure out how to use it. They, they provide ... They're, in my opinion, they are the best audience for providing actionable feedback for something that's like still early. Um, and then you can figure out how to productize from there. You like, you can put a feature deep in config.”
VERIFIABILITY, REVIEW, SANDBOXING — ALEX, turns 202 and 204
“But let's start with the coding tasks. The interesting about, thing about them is they're verifiable. There is an existing place where the human is in the loop, right? I talk to a lot of enterprise customers today, and they're like, ‘Hey, we have like a regulated workflow. Um, how do we make sure we trust the agent?’ The truth is that like a lot of coding is regulated too. It's just we already have ex- established human practices. It's called code review. Right? So we, we already know how to do this-”
“Also, coding tasks are hermetic, right? You can do a coding task in a sandbox, like, and I, and you might actually disagree with some of this, but you can do a coding task in a sandbox without access to the internet, and it'll work pretty well, right? Maybe, okay, some amount of testing and things will need sandbox access, but as you're getting started, like you can literally limit it to a folder on your computer.”
THE WHITEBOARD’S PRODUCT ROADMAP — ALEX, turns 190 and 210
“We're just gonna start here. Right? And then we're gonna kind of move this way and also move this way. You know? And like, but you have to land here. Like both like-”
“So also the specificity of the task you get is quite high here, and a developer knows how to like change how they're specifying to give you what they want. Here, the task specifi- specificity goes down. We actually see this. It's like less, less clear what I want, and then eventually we're gonna get here where they, they don't even know what they want, and we have to be useful. So that's why we want to start there, um, and kind of productize our way through.”
MIA ON THE MERGER’S REAL MEANING — MIA, turn 87
“I care a lot about product and m- maybe I'm not a product sort of professional, right? But I can, like, I can see what's possible with the models. I can be like, ‘Here's, like, all the amazing things that we could build.’ And also there's, like, product people are like, ‘Wouldn't it be amazing if the model could do, like, this thing?’ And so we can, like, sit together and we can share, like, our vision and, like, build something together. Um, and we have a lot of strength in that where we can sort of parallelize that work where, where, like, we can think about, like, what do we want Codex or, like, our models to be able to do. And then we can, like, build that for the, build the model for that and we can build the product and the, the, like, the harness and everything that we need for that together. Because we are thinking about this as, like, a one, like, joint thing that we, that we build together.”
The handoff: Cloud exposes the gap between an internally standardized environment and a customer’s messy one.
The developer wedge: they start by serving people like themselves — builders who will try unfinished tools, diagnose failures, and tell you exactly what broke.
Why developers are a particularly good first audience: open-ended work; high-quality feedback; coding tasks are verifiable; existing habits of code review; bounded/sandboxed environments; tasks can be specified precisely.
The roadmap on Alex’s whiteboard: start with developers + synchronous work, then move toward asynchronous work and non-developers.
The larger turn: serving researchers created the capability; serving developers taught the team how to productize it; only then can the story move outward.
QUOTE-FIRST BEATS FOR TOMORROW
5. Alex and Tibo work together on the Cloud sprint.
“As I’m working with Alex, we were … working on what’s referred [to] as the cloud sprint, which was … roughly a seven-week sprint.”
“Then we came out with Codex, the cloud version.”
6. The first Cloud version is exciting but early.
“It was … a little bit too early.”
“It did not have PMF at the time, and it was … too, too, too frictionful.”
7. Do not flatten the local-versus-Cloud sequence. This is a live chronology question.
“We didn’t skip it. We … had it internally. We did not release it.”
“We built a version of that and then discarded it after a month to go for the full cloud version.”
8. Why the provisioned setup worked internally—and why it was hard externally.
“It was very successful internally.”
“Everyone having … perfectly … reproducible environments, provisioned dev boxes at scale … seemed like the way to go.”
“But then externally that was … way too high friction.”
“With models getting better and better … you wanted to pull in … a lot more context … [and] felt trapped … inside of that little VM.”
“So we went back to local. Then again, it was … too early.”
9. The apparent split: when asked when it was right to separate a model line and product, Tibo does not describe a grand strategy decision. He answers in terms of velocity, a fast-changing landscape, and a forgiving early audience.
“We were also optimizing for … velocity first and foremost.”
“All of this was going to change again and again … in the course of a couple of months.”
“We needed to start with … a very forgiving audience as well.”
“Doing that with the ChatGPT desktop app felt … not fulfilling … either of those.”
10. Greg corroborates the organizational shape: many efforts, then collapse and merger.
“We actually had several different efforts. We ended up … merging two of them and then merging another two of them.”
“A little bit of exploration and then collapse.”
“The right form factor is an AI in the cloud … that has its own laptop.”
“We actually built that, and that was basically Codex Cloud.”
*
“You start out with autocomplete, then you move to more of the Cursor style… Then it’s this agentic, sort of Codex app or CLI.” —Greg Brockman (Greg interview, 3:13 (https://embiricos-transcript.vercel.app/#/greg/transcript/5)
MERGER → CLOUD — RECONCILED, SOURCE-FIRST BEATS

1. Internal adoption becomes a team question. Tibo: “As things started to work, we got increasing adoption, increased our ambitions step by step.” Mia places herself at “basically the beginning of Codex,” when it was “a project of like four people”; the early group built the model, product, and harness as “one, joint thing.”
2. The efforts converge. Tibo: “Eventually, we thought we should combine forces with another effort, which was called Scientific Assistant”; “there was a merger of teams, and that’s when I got to know Alex.” Greg’s wider description: “several different efforts” followed by “a little bit of exploration and then collapse.”
3. Keep the terminal chronology open. Tibo describes an internal terminal-shaped version: “We had it internally. We did not release it”; it was discarded after a month for “the full cloud version.” Alex remembers a public CLI that “actually shipped … even before Codex Cloud,” but calls it “a very small side project” built by two people, with “no good model to power it.” He says: “You couldn’t even use the Codex model in the CLI.” Do not yet say these were the same artifact.
4. The merged team’s central product constraint is model capability. Alex’s retrospective: the research direction offered a clearer path to models that could work asynchronously for a long time than to strong interactive ones. “Let’s design a product around asynchronous models.” Cloud was a product built around “a model research direction of asynchronicity.”
5. The Cloud sprint. Tibo: after meeting Alex, they worked on “the cloud sprint,” “roughly a seven-week sprint.” “Then we came out with Codex, the cloud version.” Greg supplies the form-factor thesis: “an AI in the cloud” with “its own laptop,” able to execute things on its own.
6. The launch contains both the seed of success and the failure. Tibo: “really, really exciting,” but “a little bit too early” and “too, too, too frictionful.” Alex calls the response “a very cool spike”; “everyone thought it was a great idea.”
7. Save the diagnosis for the following scene. Internally, Tibo says Cloud was “very successful”: reproducible environments and provisioned dev boxes made people productive. Externally, it was “way too high friction.” Alex’s terms: too early because the models were not yet good enough, and “incorrectly done” because it was rigidly asynchronous and awkward to get work back from the cloud. Mia’s product formulation: the team had built toward a future vision rather than going to users “where they are,” on their laptops.
8. Chronology guardrail. The local pivot is subsequent: Alex places the stronger local-product thesis in August. Greg’s Coding Ninja Sprint is separate and later still: a midyear correction for the gap between benchmark coding and real-world engineering.
   )
   ==imwriting the piece above. what are the most interesting / most helpful perspectives you could adopt in order to gife me feedback on this draft and help me improve as a writer / improve this draft? propose 10, and pick the top 1-2 and give me a detailed critique