Ed Bayes - Designing 6 months into the future at OpenAI

Summary

Ed Bayes, a design lead working across Codex and ChatGPT, describes how OpenAI’s product design is adapting to rapidly improving AI models. His central principle is to design for roughly six months ahead: anticipate what models may soon be capable of, prototype for that future, and revise assumptions as new models arrive.

Codex and the shift to agent-centered products

• Codex began as a web product connected to GitHub, where users could assign asynchronous coding tasks and review the resulting work.
• Rather than build a conventional IDE, the team made a deliberate bet on an agent-centered command center: the agent is the primary interface, and users can manage work across multiple tasks and repositories.
• As model capabilities improved, this approach became more viable. Codex’s interaction patterns have since influenced broader ChatGPT experiences, including work with code and artifacts such as slides and spreadsheets.
• The goal is to make agents useful beyond developers while still supporting developers’ specialized workflows.

Making powerful agents accessible

A key challenge is knowing when a model is capable enough to support a more abstract interface. If users must constantly inspect or repair its work, a less abstract coding environment may be more appropriate.

Agents also introduce unfamiliar risks because they can act on local files or connected services. The team uses safeguards such as sandboxing and requiring user approval for consequential actions, such as sending an email. As agent products reach less technical users, interfaces need to make the model’s abilities and the user’s control clear.

Designing and prototyping for the future

Bayes describes three broad stages of prototyping:

1. Figma prototypes to explore and communicate an interaction.
2. Small coded mock-ups to test behavior with a model or API.
3. “Vibe in prod” prototypes: a designer creates a branch of the actual product, implements an idea, and shares it for people to try. These experiments are not necessarily intended to be merged.

Bayes showed an early model-generated, interactive explanation of backpropagation. Users could change learning-rate values, interact with visualizations, and request further explanation. The example illustrated a future in which a model can generate rich, responsive interfaces—not just text.

Dynamic interfaces and evaluation-driven design

Bayes distinguishes between tightly controlled, low-latency interfaces and more variable, model-generated interfaces. The right balance depends on the task, the user, and how long it is acceptable to wait.

Rather than prescribe every possible visual result, designers can define a design language through skills, tokens, and guidance, then test how the model applies it.

His suggested evaluation process begins with a small “golden set” of representative prompts—perhaps 10–20. Teams check where outputs fail, adjust the guidance, and repeat. Researchers and engineers can later help scale this into larger evaluation sets.

Model releases can invalidate previous assumptions or constraints. Bayes argues that teams must repeatedly test and update their approach rather than treat a design system or prompt rules as permanent.

An example: goal-based agent work

Bayes described an early prototype, first called “autopilot,” that evolved into a goal-oriented interaction. A user defines a task and success criteria; after each response, the system checks whether the goal is complete and continues if it is not. The prototype explored how agents might work toward outcomes rather than merely respond to a sequence of prompts.

Team structure and collaboration

• Bayes prefers organizing designers around personas and broader user journeys, rather than assigning them only to narrow features. This helps teams consider the full experience when adding capabilities.
• He encourages regular contact with users, including people outside the developer community, and attention to external feedback from sources such as Reddit, Hacker News, and social platforms.
• Prototypes help communicate a vision, but design’s impact also depends on making ideas understandable and persuasive to engineering, product, and research partners. A polished prototype is not useful if no one can act on its direction.
• Figma remains valuable for early exploration and for precise, complex systems with many states and edge cases. Code-based prototypes are especially useful when a design depends on unpredictable model behavior or real product context.

Leadership and designer traits

Bayes emphasizes high-trust, high-agency teams, humility, mission alignment, and close collaboration with users and cross-functional partners.

He does not consider coding a requirement for designers. He sees design’s central role as envisioning a future and engaging others in building it. He values designers who communicate clearly, collaborate well with researchers and engineers, and show curiosity and initiative. Personal or open-source projects can demonstrate that initiative, particularly for early-career designers.

Guides, tutorials, and reviews

• Practical guide: Start with a clear user problem and representative “golden” prompts. Test outputs repeatedly, identify failure patterns, refine the model’s guidance, and scale evaluations with research and engineering partners.
• Prototyping approaches discussed: Figma exploration, coded mock-ups, and live product branches.
• The episode discusses design reviews and internal prototype-sharing, but does not present a formal product review or step-by-step software tutorial.

Main speakers and sources

• Reed, the host of Design Club, asks the questions and introduces the episode.
• Ed Bayes, design lead for Codex and ChatGPT, provides the product, prototyping, team, and collaboration perspectives.