The Golden Age of AI Engineering

A World’s Fair makes an improbable future tangible: people can see it, walk into it and begin to believe in it because someone built it in public. Opening the AI Engineer World’s Fair, Romain Huet applies that idea to the engineers building with AI. He describes more than 7,000 AI engineers in the room, making capabilities usable faster than many people expected.

That activity sits awkwardly beside headlines predicting the disappearance of software engineers. If AI abstracts away coding, does engineering disappear with it? Romain’s answer follows the progression from software eating the world, to AI eating software, to AI engineers extending what can be built. Engineering is problem-solving, not merely code production. Its work combines science with design, taste, judgment and imagination to make something useful for other people. Automating more of the implementation can therefore return engineering to its roots.

Alexander Embiricos describes a release cadence that has accelerated from roughly one model every fifteen months to roughly one every six weeks. The GPT-5.6 series preview had launched the preceding week. For a developer, that acceleration appears as successive changes in what can be delegated: first completion, then inline prediction, then Command-K edits that did not test their work, then models that did test, and finally agents pursuing long, difficult goals until completion. Each transition initially feels extraordinary; soon it becomes the baseline for getting work done.

The difference becomes concrete in Romain’s live demos. At DevDay 2024, he used o1 in preview to build a mini-drone interface from scratch. The model could neither run the generated code nor verify its work, leaving him to take the stage with an interface he expected to work most of the time. It did work. By DevDay 2025, models could test their own work, and he felt confident enough to demonstrate control of an entire camera and lighting system live.

Alexander jokes that, before a demo, Romain might report that it worked “three times out of four” and receive little more than a good-luck wish. That exchange captures the earlier experience: generating plausible code left the presenter carrying the verification burden. Closing the build-and-test loop changed what he was willing to attempt.

The Codex app, Goal Mode and Remote are Alexander’s examples of product changes that alter the experience of working. The team uses Codex to build Codex, but his broader claim is that agents can undertake any task a person can do on their computer. That expands the useful surface beyond writing code to the work that precedes and follows it.

Connecting an agent to why work is needed helps it identify and initiate work. Connecting it to review and deployment helps it finish and land that work. The opportunity is larger than faster implementation: Alexander says the team can prototype more ideas and spend more time with users, improving decisions about what deserves to be built in the first place.

Alexander offers a personal comparison: given equal time on an average, medium-length computer task, he expects the model would probably do a better job than he would. That raises a product question. If agents are increasingly capable, how should people work with them? He connects this to the mission of AGI benefiting humanity through two questions: what agents can do and where they run, and what the human experience around them should feel like. The goal he sets is to empower engineers.

His proposed interface has two complementary modes:

• Chat: one entity you can ask for help with anything, wherever you are.
• Hands-on collaboration: a powerful interface for inspecting, steering and shaping the work yourself.

A Codex-generated illustration supplies the workbench analogy. With a teammate, most coordination happens through conversation; you do not stand over their shoulder for every task. Occasionally, you need to examine a problem together in detail. The interface should make that transition easy enough to preserve a feeling of mastery, including the ability to take the work apart.

The Codex app puts that sequence into a product: start with a conversation, then go as deep as necessary. The example on screen is Romain’s prediction for an upcoming World Cup match. A user can point to a particular element and ask for a change, or make the change directly. Conversation and manipulation belong to the same workspace.

Some developers initially told Alexander they would never leave their terminal, Vim or Emacs for this kind of app; he says those same people now use it. The internal debate was similar: why add another surface when developers already liked the CLI and IDE? His answer is about the order of interaction.

The app’s purpose is to support teammate-style collaboration across kinds of work, with direct access to the artifact when the conversation alone is insufficient.

The product is also shaped by developers discovering uses its builders did not anticipate. Romain describes seeing community experiments, personal tools and team workflows that reveal what Codex can do and what it should support next. For that feedback loop to work, Codex cannot be a closed product that only OpenAI can improve. Its architecture needs layers other developers can build on.

The first layer is the model, accessed through the Responses API. Romain says the Codex app uses the same models through the same API offered to developers, with an intent to put new primitives into the API first when Codex needs them. Context compaction is his example: long-running tasks needed a way to compact long contexts, so that capability became an API primitive available to other agents.

Above the API sits the open-source Codex harness, which developers can inspect, fork and adapt. The AGENTS.md convention follows the same interoperability principle: choose an instruction-file name other agents can use rather than invent a Codex-only format. OpenAI models are defaults in the harness, Romain says, rather than hard-coded requirements; an open model can use the same agent loop. He also describes bringing the harness into model post-training so models learn tool use and environment navigation in an environment whose implementation developers can inspect.

OpenCode provides a concrete example of why that visibility matters. Its developers could examine the reference implementation, reuse useful parts and make different decisions elsewhere. Romain specifically mentions their investigation of sign-in with ChatGPT. Reading the implementation provides a more direct foundation for integration than reverse engineering a launched product.

An application needs more than an agent loop: it needs a way to control that loop and let people sign in with an existing Codex subscription. OpenAI faced that problem when building its VS Code extension and Codex app. The resulting open-source app-server is the integration path used by those products, not a separate community adapter.

Thomas used app-server to build the native CodexMonitor application. Romain says it preceded the official Codex app, and that Thomas subsequently joined the team and built Codex for iOS. The example illustrates what a reusable product integration layer enables: another developer can build a different client around the same underlying agent.

At the application layer, the extension primitives include the in-app browser and plugins. Romain says browser_use and computer_use were themselves built as plugins using the extension points available to developers. Open-source role-specific plugins extend that approach to work such as data science and design, giving developers implementations they can inspect and adapt.

The ecosystem also extends where an existing subscription can be used. Romain names OpenCode, Pi, Droid, OpenClaw, Xcode and JetBrains. Across these layers, his architectural commitment is consistent: OpenAI uses the system it gives developers, rather than keeping a richer internal system and exposing a simplified substitute. Forks of the harness and discoveries at the edge of model capabilities become inputs to further improvement.

Once agents become useful, the question becomes how much value an organization can extract from them. Alexander calls this “value maxing,” contrasting it with maximizing token consumption. Cost efficiency is the first recurring theme in his conversations with engineering leaders: they want frontier capability, but also as much useful intelligence as their budget can buy.

On the displayed Terminal-Bench evaluation, Alexander identifies GPT-5.6 Sol as the frontier choice. His comparisons for the smaller models are:

These are comparisons around the displayed evaluation, whose precise settings and scores are not specified in the spoken explanation. The Terra claim does not establish half the total cost of completing a task, and Luna’s token prices apply to Luna rather than the entire family.

Speed is the next dimension. GPT-5.3-Codex-Spark had already shown what fast generation could unlock, but Romain emphasizes the desire to combine that speed with frontier capability. Romain presents GPT-5.6 Sol on Cerebras at an advertised rate of up to 750 tokens per second, with access anticipated the following month. That is generation throughput, not the elapsed time to implement, test and land a change.

His comparison is a substantial pull request written in roughly ten seconds—an illustration of the generation rate, rather than a measured delivery result. More interesting than a single faster answer is the possibility of exploring several answers: an agent could try five or six approaches in parallel, then select the best, within a waiting period that previously constrained it to less than one. Faster inference could change the search strategy as well as the responsiveness of the interface.

A familiar office scene exposes another limitation: laptops left open so agents can keep working. The desired outcome is straightforward—close the computer while multiple tasks continue, each isolated on its own machine. Alexander points back to Codex Cloud as the first major launch and promises substantial upgrades, but the longer-term product goal goes beyond a better cloud task queue.

Users should not have to classify every request as local or cloud work. They should be able to talk to one agent, which determines what needs doing, chooses an appropriate available environment and uses it. When Romain asks about a displayed prediction from Theo, Alexander expects its general direction much sooner than six months, while explicitly stopping short of endorsing its exact details. The direction is a unified agent whose execution location follows the task.

Instead of another live demo, Romain introduces Peter Steinberger, the “Clawfather,” to describe a changing way of working. Peter recalls juggling ten or more terminal windows, waiting for one agent to finish so he could steer it and queue more work. In January, that felt like peak productivity. Looking back, he sees a different division of labor: he was polling, and serving as the scheduler, router and memory for the whole system.

Pairing with one agent had become managing ten direct reports. Peter’s new default is to talk to a long-running manager that delegates to a team. He can still pair directly with a worker on a difficult problem, but he no longer needs to supervise each worker’s routine progress.

Three capabilities make that shift possible:

• Persistent context: server-side compaction made long-running tasks reliable enough in Peter’s experience that he stopped organizing his work around fresh sessions.
• Delegation: coordination lets one thread create and steer the appropriate projects.
• Triggers: automation wakes the same manager when something happens.

Together, these let an event resume an ongoing relationship with project context and delegated work, rather than requiring a person to reconstruct the situation and dispatch every next action. Compaction supports that continuity; it does not imply lossless memory or guaranteed completion.

Once the loop works, its bottleneck moves. Peter was initially constrained by tokens. He jokes that joining OpenAI fixed that problem, immediately acknowledging that the strategy does not scale. Compute became the next constraint: concurrent threads made his MacBook sound like a jet engine. Separate test boxes, where agents could run tests on another machine, mostly addressed that contention.

Now the scarce resource is attention. Unlike tokens or compute, Peter cannot simply add more of it, so deciding where to spend it becomes a central engineering skill. Watching an agent’s code stream can consume attention without changing the outcome. Earlier models often needed that supervision: spot an unwanted direction, press Escape and steer them back. Peter’s judgment is that newer models understand intent well enough to make constant observation a poor default.

Peter’s illustrative workflow begins with someone filing an issue on an open-source project. The manager wakes up and evaluates the issue against the project’s goals, notes and vision. If it appears to fit, the manager creates a worker. That worker investigates, implements and tests the change; another agent can review the result. The human does not need to consume every intermediate message.

The handoff happens when there is something consequential to inspect:

1. Return a pull request together with the original issue and proposed diff.
2. Include richer evidence when useful: a video, or a running build the human can enter through VNC.
3. Let the human review, leave a note or approve.
4. Continue the loop; the change can land after the checks pass.

The agent owns the inner execution loop; the human owns direction and decisions in the outer loop. Generating a diff is not itself permission to land it.

A small TypeScript predicate can make the review boundary explicit in an implementation of this proposed workflow. It answers whether a reviewed change is eligible to land; it does not perform the merge:

type ReviewDecision = "pending" | "changes-requested" | "approved";
type CheckStatus = "pending" | "failed" | "passed";

type ChangeReview = {
  pullRequest: string;
  decision: ReviewDecision;
  checks: CheckStatus;
};

function canLand(change: ChangeReview): boolean {
  return change.decision === "approved" && change.checks === "passed";
}

const proposedChange: ChangeReview = {
  pullRequest: "Fix empty search results",
  decision: "pending",
  checks: "passed",
};

const eligibleToLand = canLand(proposedChange); // false

Passing checks leaves this proposed change awaiting the human decision. A request for changes likewise keeps it in the execution-and-review loop.

Peter cites Paul Salt as already running a version of the manager pattern: a pinned chief-of-staff agent wakes every ten minutes to coordinate GitHub work. It creates threads in the sidebar so Paul can enter a particular workstream when it needs additional steering. The manager supplies continuity while preserving access to individual workers.

A long-lived manager makes attachment to a single laptop feel increasingly arbitrary. Peter notes that Codex can already move work between hosts and that OpenClaw has a gateway and nodes, but he considers neither the final form. The thread should outlast the machine on which a person happens to be working.

The desired agent can connect to the user’s machines and distinguish work suitable for the cloud from work requiring local access. Its manager should be reachable by text or Slack, rather than trapped inside an application session. Peter pushes the aspiration further: why not ask the agent to design the whole loop itself?

That system remains unfinished. Models are advancing faster than the harnesses and organizations built around them, leaving the design of those harnesses and organizations as the next engineering problem. Peter closes with the direction of travel: “The future is not twenty terminals. It’s better loops.”