Codex Inside ChatGPT: Why the IDE Is Losing Its Place at the Center

For most of a developer's career, the editor window was home base. Searching happened in the browser, requirements landed in Slack, work was described in Jira, code got reviewed on GitHub, and things broke in the terminal. But the IDE was where all of that finally turned into software. Every conversation ended up as a file, a cursor and a blinking line waiting for your next decision.

OpenAI merging the Codex app into its new ChatGPT desktop app reads like routine product housekeeping. It's more than that. The company didn't just add a coding tab beside a chat tab. Code, research, documents, connected apps, browser activity, pull-request review, local files and long-running agents now share one surface. That challenges the longest-held belief in the IDE world: that engineering naturally revolves around the source file. Maybe it no longer does.

Why the IDE won in the first place

Few productivity tools have been as successful as the modern IDE. It understands symbols, types, references, builds, tests, breakpoints, version control and a thousand language quirks, which made it the obvious home for developers for decades.

The logic was simple: almost every meaningful engineering action needed a person manipulating code directly. A requirement became a design, the design became files, files became functions, functions became a diff. The developer carried the work through each stage personally, so the tool nearest the text became the command center.

Early AI assistants respected that hierarchy. They showed up as autocomplete, chat panels and inline suggestions, living inside the IDE because the human still owned the loop. You picked the file, placed the cursor, asked for a snippet, checked the output and decided what came next. The assistant was an accessory to editing.

Agents aren't accessories.

Codex has left the cursor's side

Codex can operate across repositories, spin up isolated worktrees, run commands, read terminal output, review pull requests, drive applications, use a browser and keep going on tasks that outlast a single editing session. It can ask for approval, report test evidence, accept a correction sent from a phone and carry on running on some other machine.

Calling that smarter autocomplete misses the point, because the thing being handed over has changed. Before, the unit was a single edit:

Open File
   |
Move Cursor
   |
Write Code
   |
Run Test
   |
Fix Result

Now it's an outcome you hand off:

Describe Outcome
      |
Provide Context And Constraints
      |
Agent Plans And Executes
      |
Tests, Diffs, Logs, Screenshots
      |
Human Reviews Evidence
      |
Approve, Redirect, Or Reject

In the first loop, you produce every intermediate step. In the second, you govern the process.

That's why the merger matters. ChatGPT already sits nearer to intent than any editor does, because it's where people explain goals, attach documents, weigh tradeoffs, bring in business context and sharpen fuzzy requests. Put a coding agent on that surface and code becomes one possible result of a much bigger conversation. The source file keeps its importance. It just isn't where work has to start.

Context is the new center

Hardly any feature starts life as code. The trigger is an angry customer, an outage, a spec, a screenshot, a long Slack thread, a ticket, a dashboard number, or an offhand comment from somebody who couldn't name the service responsible.

Traditional tools make the engineer migrate that context by hand: read the ticket, open the repo, hunt for the right path, check logs, rebuild the architecture in your head, edit, test, prepare the pull request, explain the change, then go back to the ticket. The IDE handles the middle of that trip brilliantly, sees almost nothing of the start and only part of the finish. An agent surface that spans everything is after the entire chain:

Email  ─────┐
Slack  ─────┤
Docs   ─────┤
Browser ────┼──> Intent + Context ──> Agent Work ──> Reviewable Result
Repos  ─────┤
Terminal ───┤
GitHub ─────┘

This is the real platform fight. The winner won't be whoever has the slickest code completion. It'll be whoever assembles the most useful context, executes safely in the most environments and returns evidence a person can trust. That tool might contain an editor, but it needn't be built around one.

From typing to scheduling

The most telling Codex features aren't the ones that generate code fastest. They're the ones that let work continue while nobody watches. Several agents can run in parallel, tasks can live in separate worktrees, scheduled jobs can inspect a repository later, and a developer can start something on a desktop, check progress from a phone, approve a command and redirect the task without redoing the setup.

Your attention gets budgeted differently. A person at a keyboard can only work in one place at a time, while a person supervising agents can have a migration looked into, a flaky test reproduced, a dependency bump prepared and a pull request reviewed in the same hour.

It sounds like payoff, and often it is. It's also a fresh management problem. When execution gets cheap, half-formed thinking gets expensive. Vague requirements produce bigger mistakes, weak tests breed convincing false confidence, and thin repository docs turn into operational bottlenecks. Teams that got by on tribal knowledge while humans did every step will find out that agents can't infer agreements nobody wrote down.

Expect developers to type less and to spend their days drawing boundaries, writing acceptance criteria, designing checks and judging when the evidence justifies a merge. That's not engineering disappearing. It's engineering moving up a level.

The IDE isn't going anywhere

The headline-friendly claim is that ChatGPT kills the IDE, and that's a stretch. Hands-on editing is still often the quickest way to think a problem through. Untangling an ugly function, stepping through a debugger, redesigning an API, comparing call sites, optimizing a query or carrying out a careful refactor can call for an intimacy with code that delegation can't replace. Editors will stay where developers go when precision matters more than orchestration.

Surviving isn't the same as staying central, though. The terminal outlived the graphical IDE and became one strong surface among several. The browser outlived mobile apps and lost its monopoly on interaction. The IDE may follow suit, still important but with more work starting and finishing elsewhere.

OpenAI's own product quietly concedes this. Codex ships IDE extensions and can open its changes in an editor, which makes the editor a tool you pick up, no longer the one room where development takes place. That's a demotion, not a deletion.

Trust is the new bottleneck

Working in an editor feels controlled because every change happens in front of you. Agentic development removes that feeling. A task might touch dozens of files, run commands, inspect a browser, call tools and come back with a polished explanation of why everything is fine.

That write-up might be mistaken. The test suite might have gaps. The patch might fix exactly what was asked and still break something nobody thought to mention.

When the IDE was central, productivity meant how fast you could write and navigate code. With agents at the center, it means how fast you can establish justified trust. So the key interface isn't the prompt box but the evidence layer. What changed, and why? Which tests ran and what did they cover? What permissions were used? Which assumptions were made, and what's still uncertain? Can the work be reproduced, stopped or reversed? The agent that writes the most code won't necessarily win. The one whose work is easiest to verify might.

Junior developers get a harder road

There's an uncomfortable side effect here. Senior engineers can supervise agent output because years of failures taught them to spot missing constraints, suspicious abstractions, weak tests and elegant answers to the wrong problem. Juniors are still building that instinct.

They used to build it by doing the intermediate work: searching the repo, misreading the architecture, writing a bad first version, debugging it, reading the stack trace and slowly learning why the system got so complicated. If agents absorb too much of that struggle, new developers could reach the review stage without the experience to review well.

Wishing agents away isn't a plan. Teams will have to build training deliberately: reading agent plans, guessing where they'll fail, comparing competing patches, tracing runs, and now and then doing a task manually. A generation that only knows how to request outcomes could become productive fast and dangerous quietly.

A control plane for software

The classic workstation was organized around artifacts such as files, tabs, terminals, branches and diffs. What's emerging looks more like a control plane. The developer assigns work, picks environments, grants permissions, watches parallel runs, resolves uncertainty, reviews evidence and decides what reaches production. Repositories remain underneath, the way servers remain underneath a cloud console. They're real, just managed from a higher abstraction.

So the merger isn't just branding. Chat is where intent gets negotiated, work tools hold organizational context and Codex turns that context into executable change. Together they make a plausible operating system for knowledge work, one in which software isn't an isolated profession but one of the things an agent can produce while finishing a broader task.

Developers should find that both exciting and slightly unsettling. The owner of that layer gets a say in model choice, context gathering, where jobs run, how permissions work, how results get reviewed and which tools fade into the background. The fight over developer tooling is turning into a fight to own the layer above the repository.

The cursor no longer marks the start

Launching the IDE once signaled that work was starting. These days it could be well along already, with an agent having read the issue, explored the repo, made a worktree, reproduced the bug, drafted a fix, run the tests and parked its questions for your approval. You arrive not at an empty file but at a decision.

IDEs were designed for people who build software by working on code nonstop. The ChatGPT desktop app targets people who more and more supervise systems that work on the code for them. You'll keep opening files and debugging the baffling cases, and you'll write the critical function by hand whenever an abstraction leaks and the agent sounds surer than it should.

Even so, the middle of software development is moving, from the spot where code gets typed to the spot where intent, context, execution and judgment come together. The IDE isn't dead. It's becoming a tool inside something bigger.