ChatGPT Sites Is the Internal Tool Builder You Never Had to Code
At OpenAI's DevDay, product lead Kath Korevec demoed ChatGPT Sites live and showed exactly how non-engineers can wire up Slack, Notion, and calendar data into smart internal tools. Here's what that actually looks like, and why it matters for designers who are starting to build.
At OpenAI's DevDay, Kath Korevec, a product lead on the Codex team, gave a live demo of ChatGPT Sites and showed how her team uses it internally. The short version: you can now build a working, connected internal tool from your existing Slack and Notion data without writing a single line of code.
That is a meaningful shift for designers. Not because it replaces engineering, but because it removes the waiting.
What ChatGPT Sites Actually Is
Sites is OpenAI's way of letting you publish a custom AI-powered interface, think of it as a mini-app built on top of ChatGPT. You point it at your data sources, give it a purpose, and share it with your team. The people using it just see a clean, conversational tool. They never need to know what's under the hood.
Korevec spent over a year building and using Sites internally before the public launch. One of her most practical examples was an incident command site, a tool her team uses during outages or fast-moving situations. It pulls live data from Slack and Notion connectors (integrations that link Sites directly to those apps), so whoever opens it gets a real-time picture of what's happening, not a stale wiki page or a thread they have to scroll through to reconstruct.
That kind of tool would traditionally take a sprint and a developer. She built it herself.
The Feature That Changes Who Gets to Use This
One of the more quietly important things Korevec talked about is a feature called Plugin Insights. Without going deep into the mechanics, it essentially makes Sites smarter about surfacing the right information to the right person at the right moment. The upshot is that a single Site can behave differently depending on who's using it, adapting its output to each person on the team rather than giving everyone the same generic response.
For designers, this matters because it changes the mental model. You are not building a one-size-fits-all FAQ bot. You are building something closer to a personal assistant for each person who opens it, one that already knows their context.
How to Actually Build One (What to Try First)
The connector ecosystem inside Sites now includes around 60 integrations, according to Korevec. The ones she highlighted most are Slack, Notion, and calendar. If your team already lives in those tools, you have the raw material for a useful Site right now.
Here is the practical starting point she described: there is a specific prompt pattern, essentially a single phrase that tells Codex to wire up your connectors for you automatically, rather than configuring them by hand. She did not quote the exact phrase in the transcript excerpt, but the concept is that you describe what you want the Site to do and Codex handles the integration scaffolding. If you are exploring Sites, look for that pattern in the official docs or the Awesome Sites gallery at awesomesites.ai, which Korevec mentioned as a place to see what others have shipped.
Beyond work tools, she also showed a community dungeon crawler game she built using a skill distribution model, where different players contribute different abilities. It is a stretch use case, sure, but it gestures at something real: Sites is not just for dashboards and wikis. If you have a creative or community project that needs a shared, interactive layer, it is worth experimenting.
What to Watch For (and Where the Limits Are)
A few things are worth keeping in mind before you go all in.
First, Korevec was clear that she draws a firm line at AI acting in her name. Sites can surface information, summarize, and guide, but she is not comfortable with it sending messages or taking actions on her behalf without explicit approval. That is a reasonable boundary, and it is one you should think about when designing what your Site is allowed to do.
Second, the infrastructure layer inside Sites, including things like how data is cached and how connectors handle permissions, is something most people have not explored yet. That is not a reason to avoid it, but it is a reason to test carefully, especially if your Site will touch sensitive team data.
Third, Korevec made an observation that stuck with me: model speed is what actually determines how creative you get. When the tool responds slowly, you second-guess your prompts and play it safe. When it responds fast, you try weirder things and find better solutions. That is a design insight as much as a technical one. Build with that loop in mind.
The Grounded Takeaway
ChatGPT Sites is not magic, and it is not finished. But it is one of the clearest examples yet of AI tooling that designers can pick up without a technical co-founder standing next to them. The connector ecosystem is real, the internal use cases are real, and the person demoing it spent a year building with it before it went public.
If you have been waiting for permission to start building your own tools, this is a reasonable place to start. Go look at awesomesites.ai, pick one workflow your team does manually every week, and see if a Site can take the first pass at it.