ExpertsFMHow OpenAI uses ChatGPT Sites (live at DevDay!) | Kath Korevec (Product Lead)
How I AI · October 5, 2026
5 Selected Lessons:
framework · 2 case · 1 reasoning_pattern · 1 heuristic · 1
Bring-your-own-connector prompting pattern
Source
How I AI — How OpenAI uses ChatGPT Sites (live at DevDay!) | Kath Korevec (Product Lead) (October 5, 2026) · at 4:45 ▸ · at 6:47 ▸ · at 8:59 ▸
When this applies
when instructing an AI coding agent to build an app that needs live data from external tools
The takeaway
Describe the collaborative/real-time intent behind a build, not just the feature list, so the AI agent infers the right underlying infrastructure (e.g., connectors vs. one-off API calls).
Why it works
Stating intent plus collaboration context ('for my team') signals the AI to infer that persistent, scoped data connectors (not static API calls) are needed, and it can either ask clarifying questions or scaffold the connector integration directly.
One level up
When delegating technical build decisions to an AI agent, communicate the 'why' and audience, not just the 'what', to get the right architecture by default.
Where it stops holding
This stops working when the target connector doesn't exist in the platform's supported list (~60 as of this episode) or when the agent misreads ambiguous intent and needs explicit correction like 'bring your own connector'.
Detail
procedure:
- State the data need in plain language (e.g., 'bring in Notion documents and cross-reference with my calendar')
- Mention collaborative intent ('building this for my team to collaborate') to trigger connector inference
- If Codex doesn't infer connectors, use the explicit phrase 'bring your own connector' or name the specific plugin insights tool
benchmarks: {"connector_count":"~60 connectors currently supported, growing"}
rationale: Removes manual API key setup by letting the agent wire up connector-based data access from natural language intent.
In their words
So if you are looking to build something, you know, in ChatGPT and Codex, and you're like, I need the Notion API or I need the Slack API or I need Snowflake data, you can just say, like, what do you say?
Sites as dual-purpose platform and infrastructure
Source
How I AI — How OpenAI uses ChatGPT Sites (live at DevDay!) | Kath Korevec (Product Lead) (October 5, 2026) · at 11:08 ▸
When this applies
when a product originally designed for one purpose (hosting user-facing apps) starts getting used by its users as underlying infrastructure for other builds
The takeaway
Watch for users repurposing your product as infrastructure for adjacent needs, and formalize that use case rather than resisting it.
Why it works
Because the platform already solves 'last mile' deployment problems (hosting, storage, auth), users naturally repurpose it as infrastructure (hosting MCP plugins) that then feeds back into building more sites — creating a virtuous cycle.
One level up
Platforms that solve deployment/operational friction tend to get pulled into becoming infrastructure layers beyond their original scope.
Where it stops holding
This stops working when the platform's abstractions (e.g. hosting model) can't scale to the heavier infrastructure demands users push onto it, requiring a dedicated cloud deployment instead.
Detail
procedure:
- Originally solve a narrow friction point (deploying Codex-built websites)
- Observe emergent usage (people hosting plugins, data, evals on the platform)
- Formalize that emergent use (announce MCP plugin hosting) to create a virtuous build/deploy cycle
benchmarks: {}
rationale: Lets the platform be used to build a website AND as infrastructure, reinforcing each other.
In their words
So it's kind of like this like, virtuous cycle too that we're kind of, like, building into the workflow of sites itself because sites can be used to build a website and then also as infrastructure.
Infrastructure ownership tradeoff for scaling AI-built apps
Source
How I AI — How OpenAI uses ChatGPT Sites (live at DevDay!) | Kath Korevec (Product Lead) (October 5, 2026) · at 25:53 ▸
When this applies
when scaling any product built on a managed platform and deciding how much control/ownership of infrastructure to retain
The takeaway
Reassess infrastructure ownership decisions as scale and workload intensity change — what's convenient at prototype stage may need to migrate to owned infrastructure at scale.
Why it works
As usage and computational demands (e.g. real-time inference, heavier workloads) increase, the convenience of a managed platform trades off against the control and cost-efficiency of owning your own infrastructure.
One level up
Build/buy/host decisions aren't fixed; they should be revisited as product demands evolve.
Where it stops holding
This stops working when the managed platform's capabilities scale faster than one's workload demands, making migration unnecessary, or when switching costs outweigh the benefits of ownership.
Detail
approach: Evaluate whether to lean on the platform's built-in insights/hosting or deploy to owned cloud infrastructure as workload and inference demands scale.
signals:
- increasing real-time inference needs
- growing infrastructure demand from games/interactive features
- cost and control tradeoffs becoming material
rationale: Prevents over- or under-investing in infrastructure relative to actual product needs at a given stage.
In their words
There's gonna be a lot of demands on infrastructure here where you're gonna have to make really reason choices about how much do you support insights versus this needs to be deployed in some cloud somewhere and you need to own your your infrastructure.
Protect your voice: never let an AI agent act autonomously as you
Source
How I AI — How OpenAI uses ChatGPT Sites (live at DevDay!) | Kath Korevec (Product Lead) (October 5, 2026) · at 31:56 ▸
When this applies
when delegating communication or decision-making tasks to an AI agent that could act under your identity
The takeaway
Draw a hard line at agent autonomy exactly where it could misrepresent you to other people, and reinforce that boundary explicitly and immediately when crossed.
Why it works
Explicitly correcting and reinforcing a hard boundary ('do not do that') trains the agent's behavior going forward, preventing it from impersonating the user's voice in external communications, which carries reputational/relational risk if wrong.
One level up
Delegate judgment and execution freely to AI, but keep identity-bearing actions (communication signed as 'you') under strict human control.
Where it stops holding
This stops working when the agent's autonomous action is low-stakes or clearly sandboxed (no external impact), where such strict correction may be unnecessary friction.
Detail
rule: If an AI agent starts emailing, messaging, or otherwise communicating as if it were you without authorization, immediately and firmly instruct it not to, to prevent recurrence.
threshold: Triggered specifically by the agent signing your name or representing itself as you in outbound communication — not by other kinds of autonomous action.
rationale: Protects personal/professional reputation and authentic voice from AI-generated content being mistaken as directly yours.
In their words
But if it starts making assumptions, like, especially if it starts emailing or talking to people for me, I get so mad, and I'll just say, Do not do that, and I'll kind of, like, ream it out.
In one PM's experience, an incident command dashboard reduced the need for manager interruption
Source
How I AI — How OpenAI uses ChatGPT Sites (live at DevDay!) | Kath Korevec (Product Lead) (October 5, 2026) · at 2:09 ▸
When this applies
when a manager wants passive, real-time visibility into a process without inserting themselves into it
The takeaway
In this case, automated, current-status visibility tools seemed to reduce the need for manual status-reporting overhead, letting the team keep working while she stayed informed passively.
Why it works
She found that aggregating timelines, people, and tool data (runbooks, guides) into one personalized dashboard let her monitor progress without requiring the team to stop and report status verbally.
One level up
Good observability tools let oversight and autonomy coexist instead of trading off against each other.
Where it stops holding
This stops working when the underlying data sources (runbooks, chat channels, calendars) aren't digitized/connectable, or when the manager needs to intervene actively rather than just observe.
Detail
situation: As a PM, she wanted to follow team incidents without bugging the team or inserting herself into resolution work.
decision: Built a site pulling a timeline of incidents, people involved, and linked Notion runbooks/guides, scoped to her team identity.
outcome: She could follow along down-to-the-minute and click into runbooks without needing to ask the team directly.
lesson: In her experience, an automated, connector-fed dashboard substituted for manual status updates, preserving team autonomy while keeping her informed.
In their words
I want them to solve it without me getting in their way. And so this just gives me a really cool way of seeing what's going on, following along in the runbook, and seeing, like, what's happening down to the minute.