You can vibe code almost anything right now.
Describe an app, and a model will build a working interface in minutes.
So why hasn't that produced a wave of new companies?
We wanted to find out. So we picked one of the hardest products to fake, an AI support concierge, the kind of system that handles millions of customer conversations for companies valued in the billions. Then we tried to build one with a single prompt.
Prefer to watch it happen? Check out the full demo below:
Our Hypothesis On Why Vibe Coding Can't Build a Company...
Going into our experiment, we had a theory about why vibe coding stalls before it becomes a real company.
Three things get in the way:
- A foundation model is trained to be a generalist. It learns from history, poetry, physics, every major programming language, and a large slice of the public internet. A real company is built by specialists, as in, people who know one domain, one stack, or one workflow in depth. A model with broad knowledge of everything doesn't automatically have deep, current knowledge of the specific systems a product needs.
- A model's knowledge is stuck at the point it was trained. But, the infrastructure real products run on needs to grow and adapt. APIs change versions, there's deprecation, and the correct way to configure something this month may not match what the model learned.
- Even a model with access to perfect, current, specialist knowledge can't hold all of it at once. Every model has a context window. This is a limit on the amount of information it can reference in a single session. Building a full product requires knowledge spanning the frontend, the backend, the data layer, and whatever integrations the product depends on.
These three limits explain why vibe coding tends to produce awesome demos rather than working products.
We wanted to test whether that gap can close if a model is given exactly what it's missing: current, specialist, in-context knowledge for a specific vertical. We picked a hard test case and tried to build it with a single prompt.
Here's what happened.
The Plan: What an AI Support Concierge Actually Has to Do
When you message an airline or bank at 2 a.m. and get a fast answer, there's a good chance no person was involved.
Likely, it was an AI support concierge. And the companies that build them well are valued in the billions.
Before testing whether one prompt can build something like this, we wanted to define what it actually requires. Strip away the branding and the specific vertical, and a working AI support concierge comes down to four components:
- Real-time chat. A customer sends a message and gets a response back instantly, regardless of how many other customers are messaging at the same time. This sounds basic, but it's the part that has to hold up as our "test company" scales.
- An AI agent in the loop. The system responding needs to read the actual question, understand what's being asked, and respond the way a knowledgeable human agent would, including pulling in relevant account or product information when needed.
- Guardrails. The agent can't leak private data, can't be talked into acting outside its intended scope, and filters both what it receives and what it sends. Without this, our AI agent would be a liability.
- Operational control. A human team needs to see conversations, review what got flagged, adjust rules, and step in when a case needs a person instead of a bot.
Together, these four separate a working AI support concierge from a demo that just looks like one.
That's the test we set up. Build all four, from a single prompt, and see how close the result gets to something real.
The Build: One Prompt
To test this, we started with a blank repository containing an .env file with the required API keys, and Stream's Agent Skills already installed.
From there, the entire build ran through one skill invocation.
1. Invoke the Skill
The skill identifies the use case from the prompt and applies the matching recipe, then uses the Stream CLI to scaffold the project and configure chat and the supporting infrastructure.
2. Make the Configuration Choices
Before it builds anything, the recipe asks you to choose a few things:
- Theme
- LLM provider (we chose Gemini)
- Knowledge source for retrieval (we chose Turbopuffer)
- Webhook-based server setup versus a simpler demo-only setup (we chose demo)
- Optional add-ons: persistence, an operator dashboard, human escalation, document lookup, and a Vision Agents add-on for building agents in Python
3. Let It Build
From there, the skill sets up a Postgres database, wires in Stream's prebuilt chat components for the UI, and configures the knowledge search and escalation logic.
4. The Result
The finished output was a working demo application with a support bot answering questions live. Entering a username loads a support chat on one side and an operator dashboard on the other.
The operator dashboard lets a human set live rules for the bot to follow (for example, restricting when it can offer a refund), review past tickets, and see which integrations are configured.
Asking the bot a product question returns an answer pulled from the knowledge base. Asking it to escalate to a human flags the ticket for review, and that ticket shows up in the dashboard along with the full transcript and a log of what the bot did to answer it, including any knowledge search it ran.
All of this came from just one prompt, a set of configuration choices, and a recipe built for this specific use case.
What This Didn't Build
We want to be direct about what this test did not do.
It did not build a company.
To have a working, growing, thriving company, customers have to trust it. People have to run it. And a lot of other things have to be in place that one prompt can't create.
What did change is the size of the technical core. The chat layer, the AI agent, the guardrails, and the operational dashboard used to require a team of specialists working for months to get it right. In this test, that same technical core came from one prompt and a handful of configuration choices.
So, here's our takeaway:
What used to take the most time when building a product was the infrastructure behind it. Things like the knowledge retrieval, escalation logic, guardrails, and a way for a human team to stay in control of what the AI agent does were... tedious and time consuming at best.
Now, that can be generated directly.
The work of running a company stays the same (sorry). But, what you build before the work starts is now a lot easier. And that's a win.
If you want to see how far one prompt can take you, install Stream Agent Skills and try building your own support agent (or any product idea you're curious about!).