Developers Should Test Ambitious Ideas Before the Next Model Release
OpenAI’s Romain Huet argues that developers should stop treating the next model release as a reason to postpone ambitious projects. With OpenAI shipping models roughly every six weeks, he says users quickly normalize new capabilities without fully testing what current tools can do; his advice is to use Codex on the “crazy ideas” and passion projects that have been left aside.

Build before the next release becomes the excuse
Romain Huet describes a familiar tension for developers building with AI: they want practical guidance for doing more with the tools in front of them, while also watching closely for the next model. Huet says people ask OpenAI for best practices and for news about when the next release will ship. He puts the company’s release cadence at about one model every six weeks.
That pace creates a particular kind of impatience. Huet says that users can become accustomed to a new model within only a few days, then begin looking toward whatever is next. The point is not that interest in future capabilities is misplaced. Developers are responding to a period of rapid change, and their questions about new models sit alongside a genuine desire to build more effectively.
But Huet’s advice directs attention back to the work that can be attempted now. The practical question is not simply what a later model may make easier. It is whether a developer is using current models broadly enough to discover what they can already do. He frames curiosity as the starting point: if there is something a builder has wanted to try, they should try it.
Take your best crazy ideas, the passion projects you've been putting on the side for way too long. Give them to Codex and you'll be surprised.
The “crazy ideas” and sidelined passion projects matter because they are the kinds of work that can remain perpetually deferred. A fast release cycle supplies an easy reason to postpone an experiment: wait for more capability, more reliability, or a better set of practices. Huet’s position is that this waiting can obscure the capacity already available. His recommendation is not a detailed implementation method or a claim that every project will work immediately. It is an invitation to put ambitious, delayed ideas in front of Codex and see what happens.
He describes the models as already “so, so smart” and says that in many ways they are smarter than their users. The limiting factor he identifies is users’ reticence. People, in his phrasing, are still too shy with these systems. That does not mean a builder should expect an answer without direction or judgment. It means the initial experiment should not be constrained by an assumption that the tool cannot help with a project that feels unusually large, strange, or personal.
Be curious, and if there are any things that you've always wanted to try, just go for it.
Huet links three observations: developers want more best practices; they expect capability to keep moving quickly; and they may be under-testing what current models can do. Taken together, those observations make a narrower case than a generic call to “move fast.” Use practical guidance where it is available, remain interested in the next release, but do not let anticipation substitute for trying the project already waiting in the backlog.
Best practices matter because builders want to do more
Huet says the most common request he hears from developers is for more from OpenAI on best practices—specifically, how to build even more. That demand suggests that curiosity is not merely an attitude in the abstract. Builders want ways to turn model capability into useful work, and they want to understand how to extend what they are already making.
His answer does not offer a prescribed workflow. Instead, it places experimentation alongside the search for guidance. Best practices can help developers build more effectively, but Huet’s advice is not to wait until every uncertainty has been resolved before beginning. The work of trying an idea is itself part of finding out what is possible with the available tools.
The source’s on-stage visual reinforces the setting for that advice: a slide showed a mobile banking interface next to a dashboard with charts and percentages. It was presented as an example of a product-like application rather than as a technical explanation of how it was built. Huet’s point is similarly oriented toward building: take an idea that has remained hypothetical and test it against a model rather than leaving it in the category of something to attempt someday.
This is also why the rapid model cadence and the demand for best practices are not opposing signals. Developers can want clearer guidance and still make progress before the next capability arrives. Huet’s concern is the tendency to normalize new capability almost immediately, so that the baseline shifts before people have fully explored it.
The Paris scene Huet saw was defined by people building now
For Huet, the principal takeaway from the OpenAI France event was the energy in Paris’s technology scene. He says there is “so much going on” in the city and singles out founders who are building companies with AI and OpenAI’s models. Hearing from those founders, he says, was “really magical.”
That observation gives concrete context to his advice to developers. The relevant activity is not only discussion of forthcoming models or abstract enthusiasm about AI. Huet points to founders using models in the course of building companies. Their work represents the behavior he is urging more broadly: engaging with the tools that exist rather than holding every ambitious effort for a future version.
The source does not claim that all founders use AI in the same way, or that the tools remove the hard parts of building a company. Huet’s point is simpler: there is visible energy among people who are putting AI models to work. In that environment, curiosity becomes less a vague virtue than a decision to attempt the project, product, or experiment that has been kept on the side.


