OpenAI staff describe how ChatGPT's new app-building capabilities let non-technical people create interactive tools just by describing what they need.
What is ChatGPT Sites? #
ChatGPT Sites is part of a broader shift at OpenAI toward letting people build working software by describing what they want instead of writing code. Rather than opening a spreadsheet, a form builder, or a lightweight app tool, someone can describe a problem in plain language and get back an interactive artifact that other people can actually use. The idea sits alongside tools like Codex (OpenAI’s coding agent) and improvements to computer use, all pointed at the same goal: closing the gap between having an idea and having something functional.
This isn’t a stand-alone product announcement so much as a natural extension of where OpenAI’s internal engineering and productivity teams say the company is already headed. In a conversation with OpenAI staff working on Codex and on the company’s productivity and agents efforts, the throughline was consistent: the interface layer between “I need this thing” and “this thing exists” is collapsing.
TL;DR #
- Describing a need in natural language, rather than specifying steps or writing code, is becoming the primary way OpenAI staff say they build small internal tools.
- Computer use (the model clicking, typing, and navigating software the way a human would) has crossed a capability threshold that OpenAI staff describe as a genuine tipping point rather than incremental progress.
- Connectors and integrations (email, Slack, and similar third-party tools) compound the value of the underlying model, according to OpenAI staff, because each new connector multiplies what the agent can act on.
- Internal adoption at OpenAI reportedly happened unevenly across functions, with coding teams adopting agent-native workflows first and other departments like legal following as the models got better at handling their specific material.
- The design philosophy for non-developer tools favors abstracting away the mechanics of what the agent is doing while still giving people enough visibility to trust the output, according to the OpenAI staff interviewed.
- This approach targets “non-verifiable domains” in knowledge work, meaning tasks without a clean pass/fail test, which is a harder design problem than tasks like code that can be checked automatically.
How does building an app without code actually work here? #
The pattern described by OpenAI staff is straightforward in concept: a person states a need out loud or in text, and an agent handles the translation into something functional. Internally, OpenAI employees reportedly rely on voice input (using a dictation tool) paired with Codex or ChatGPT to skip the traditional step of manually building a presentation, spreadsheet, or internal tool themselves. One staff member described the personal discipline of resisting the instinct to just start doing a task manually and instead routing it through an agent first.
The mechanics behind this depend heavily on what OpenAI calls computer use: the model’s ability to navigate software visually, the way a person would, by clicking, scrolling, and reading a screen rather than calling an API. Early attempts at computer use across the industry were widely seen as impressive demos that were too slow and unreliable for real work. OpenAI staff describe this as having changed markedly in the last year, to the point where computer use now runs fast enough that people sometimes don’t notice their agent silently switched from an API-based approach to clicking through a screen instead.
For non-developers building an internal app or interactive artifact, this means the underlying complexity, scripts, selectors, API calls, is deliberately hidden. What the user sees instead is closer to a simple, visual representation: a cursor moving on screen, a generated interface, an artifact they can interact with. That abstraction is the design choice that makes the feature usable by people who have never written a line of code.
Why does computer use matter more than APIs and connectors? #
For years, the dominant belief in AI tooling was that machine-to-machine interfaces, APIs, structured connectors, and protocols like MCP (Model Context Protocol) would always beat having a model literally look at and click through a screen. The logic was simple: machines should talk to machines through machine-readable channels, and screen-based interaction was a workaround for cases where nothing better existed. OpenAI staff in the conversation pushed back on that assumption based on what they’ve observed. Once computer use crossed a capability threshold, it started functioning as what one staff member called a “universal connector.” APIs and MCP integrations are still faster and more token-efficient when they exist. But the reality is that most of the software people actually deal with, government paperwork, fax-based pediatrician forms, legacy web portals, will never get a clean API. Computer use lets an agent handle those systems anyway, without waiting for a developer to build a formal integration.
That doesn’t mean connectors are obsolete. OpenAI staff described continued investment in things like email and Slack integrations because a well-built connector is faster and more reliable than clicking around a browser. But the two approaches are treated as complementary now rather than one making the other unnecessary: connectors for speed and efficiency where they exist, computer use for everything that falls outside that coverage.
What does this mean for non-technical employees? #
The most direct implication is that “building software” stops being a specialized skill reserved for engineers. Instead of learning a no-code platform’s specific interface (drag-and-drop builders, form logic, workflow diagrams), a person describes their problem conversationally and the agent produces something usable: an interactive page, a small internal tool, a way to track or process information.
This matters most in what the OpenAI staff called “non-verifiable domains,” tasks in knowledge work where there’s no automated test for whether the output is correct, unlike code that either compiles and passes tests or doesn’t. Legal review, HR processes, internal reporting, and similar knowledge work don’t have that clean feedback loop. Designing for these domains means the interface has to build trust through transparency and consistency rather than through a pass/fail signal, which is part of why abstracting away technical detail while preserving visibility into outputs became a deliberate design principle.
Is this actually being used, or is it a demo? #
Based on the account from OpenAI staff, internal adoption happened gradually and unevenly, function by function, rather than as a single company-wide switch. Coding teams adopted agent-native workflows first, in part because their existing tools (local command-line environments, codebases) were already well-suited to an agent working directly with them. Legal was reportedly an early adopter outside engineering, attributed to the sheer volume of material legal teams work through, a task well-suited to a model that can read and reason over large amounts of text.
Other functions transitioned as models improved at their specific type of work and as the right data and connectors became available. The staff described the current state internally as one where most employees at OpenAI now use Codex or ChatGPT as a default step in their workflow, with the company’s internal tooling deliberately set up to be, in their words, “ChatGPT and Codex native,” meaning employees are encouraged to interact with normal third-party software through the agent rather than by hand.
Frequently Asked Questions #
What is a ChatGPT “Site” or artifact?
It refers to an interactive output that ChatGPT can generate from a natural-language description, functioning as a small application or tool rather than a static text response, intended for people without coding backgrounds.
Do I need to know how to code to build one?
No. The stated goal, according to OpenAI staff, is to let someone describe what they need in plain language and have the agent handle the technical execution, including navigating other software through computer use.
How is this different from traditional no-code app builders?
Traditional no-code tools still require learning a specific interface (drag-and-drop editors, logic blocks, templates). This approach relies on conversational description and an agent that can click through and operate other software directly, rather than requiring the user to configure a builder.
Does this replace APIs and integrations?
Not according to OpenAI staff. Dedicated connectors remain faster and more reliable when they exist. Computer use fills the gap for the much larger set of tools and processes that don’t have a clean API, such as government forms or fax-based systems.
Which types of work benefit most right now?
OpenAI staff pointed to knowledge work broadly, with coding as the earliest and clearest adopter internally, followed by functions like legal that deal with large volumes of material well-suited to a model’s reading and reasoning capabilities.