Nathaniel Whittemore

And interestingly, this becomes sort of product-led education, where the salesperson, for example, who now has access to the plugins and skills that are used by the salespeople who are best at getting the most value out of Codex, can start to imitate those best practices by virtue of what's being presented in this functional plugin.

Simon Smith again notes,

Plugins seem to follow what Anthropic is doing with plugins focused on different business domains, but what's interesting is that OpenAI plugins seem like they can do more than provide instructions and connectors.

They can add interactivity inside the Codex preview pane, like buttons and guided actions that make powerful workflows more clickable.

Still, the update that I'm most excited about, and one which at some point I might do an entire operator episode on, is the new Sites feature.

My guess is that a lot of you have had the experience at this point of realizing as you're going about your normal work that something that you might previously have done as some sort of static document might now be better suited to presenting as some sort of small website.

For example, instead of some PDF presentation, maybe you just send them a URL.

It's easier to share because they don't have to download anything, plus you can update it as makes sense.

Codex sites productizes that type of behavior.

It allows you to turn any sort of artifact that you've built inside of Codex into a full website or web app that's shareable with your team.

They give the example of a revenue forecast planner that represents a sort of much more interactive way to look at budget planning than a traditional spreadsheet or presentation might have been, an event operations dashboard, and a product launch hub.

With both the event operations dashboard and the product launch hub,

representing a way to keep track of operational progress with a highly customizable set of inputs.

Rounding out his analysis of these three, Simon Smith again writes, sites are kind of like clawed artifacts, but on steroids.

This puts vibe coding even more directly in the hands of everyone in an organization.

You can build stuff, share it, deploy it, and importantly, do it in a more secure way, which has been a real issue with some internal vibe coded tools.

Now, I think that Simon's analysis is right, but I think this is where we have a terminology problem.

Part of why vibe coding never really fit for this type of use is that these sort of sites are effectively disposable software and web apps.

They're meant for a specific purpose for a specific set of time.

And the only thing that they have in common with software engineering is that they use code to deliver an output.