What OpenAI Is Showing Developers on September 29
OpenAI will open DevDay 2026, its yearly meeting for developers, in San Francisco on September 29, with the main talk at 1PM ET / 10AM PT. CEO Sam Altman is expected to appear on stage with other company leaders. Engadget OpenAI
The company describes DevDay as a hands-on work meeting, with technical talks, live demos, workshops, and time with the teams that make its developer tools. OpenAI Those sessions explain how the software connections behave, what the default settings are, and how to fit them into apps.
The agenda for this year is a first look at what is next for ChatGPT, Codex, and tools for building. OpenAI News coverage is planned around the same list, with Engadget planning its live blog around ChatGPT and Codex news from the main talk. Engadget
To put that list in plain terms, each item touches a different user. ChatGPT is the chatbot people talk to. Codex is the coding helper that works where programmers store and test code. Tools for building are the basic parts underneath, like wiring behind walls, that let companies run the other two in real products.
In my view, the boring details matter most. Teams using large models need steady versioning, low moving costs, speed limits, memory for text, reliable tool connections, clear permissions, ways to watch the system, and repeatable tests. A new feature only changes plans if it acts in a steady way, its mistakes are easy to see, and its cost stays predictable. Stage demos show the easy case. Real use waits for clear instructions, usage limits, update rules, and support for current systems.
The broader context here is how software platforms earn trust. The pattern was the same for PCs, the web, phones, and cloud. People adopt a platform when it is easy to try without becoming hard to maintain. That needs clear rules between parts, tools that show why the system acted, and controls that protect data, allow checks, and undo changes. For helpers like Codex, that usually means code access rules, safe test spaces, review lines, and action records.
Looking further out, there is reason for measured hope about better tools. Faster trial and error lets small teams try ideas that once needed costly special equipment. More adjustable assistants let product teams add business rules without rebuilding everything. That does not remove careful work. It moves the work toward defining the product, testing it, and running it well, where lasting software value has usually come from.
