Should You Vibe Code Your Embedded Analytics?

AI has changed the way software is built—quickly and visibly.

Using modern tools, teams can now generate working applications from simple prompts. Screens, workflows, and dashboards can be created in minutes. What once required weeks of development can now be produced far more quickly.

For SaaS companies, this is not theoretical. Many teams are already experimenting with it, and in some cases using it in production.

This is where a new question naturally emerges.

If it is now so easy to build software—including dashboards and data-driven features—why rely on an analytics platform at all? Why not simply generate the analytics directly as part of the application?

This question is not academic. It reflects a real shift in how teams think about building versus buying. In the past, the tradeoff was driven largely by cost and time. Today, AI significantly lowers the effort required to create functional software.

And analytics sits directly in the middle of this shift.

Dashboards, reports, and data-driven views are highly visible parts of an application. They look self-contained. They can be generated quickly. They are often the first thing teams experiment with when using AI to build product features.

It is easy, therefore, to conclude:

“If we can generate dashboards ourselves, why do we need an embedded analytics platform?”

This paper addresses that question directly—not by pushing back on AI, but by clarifying what is actually being built, what is not, and where platforms remain essential.

What we mean by vibe coding

Vibe coding is the use of AI tools to generate working software directly from prompts, allowing users who are not necessarily professional developers to design, build, and iterate applications without writing most of the code themselves.

Instead of implementing logic line by line, the user describes intent—what the application should do—and the AI produces the corresponding functionality.

This dramatically compresses the time required to create usable software, especially for user-facing features such as interfaces, workflows, and data-driven views.

Vibe coding exists alongside AI-assisted development, where experienced engineers use AI to accelerate specific tasks but still design and control the system architecture.

In vibe coding, you don't construct software step by step. You generate a working result, then refine it through further prompts and iteration.

Two types of software: applications and platforms

There are two fundamentally different kinds of software systems.

Applications are built to deliver specific user-facing functionality. They operate within a defined context, serve a known use case, and are designed to be created and changed quickly.

An application might present data, capture input, or automate a workflow, but it does so within a boundary that is understood and controlled by the team building it.

Applications depend on underlying services to function. They rely on data storage, identity systems, and compute resources, but they do not implement those capabilities themselves. Their purpose is to deliver an experience.

Examples include customer-facing dashboards, internal tools, workflow applications, or operational systems built for a particular business need.

Platforms, by contrast, provide the services that applications depend on.

A platform operates across many contexts and users. It must handle different data, permissions, and environments while behaving consistently. It enforces rules, manages access, and ensures that the system works predictably as it scales.

Platforms are not tied to a single use case. They are designed to be used by many applications, often across many customers, over long periods of time.

They must be reliable, extensible, and maintained as ongoing systems.

Examples include databases, identity systems, cloud infrastructure, and analytics platforms.

This distinction matters because applications and platforms are built (and used) in fundamentally different ways. Applications solve a specific problem; platforms support many problems over time. That boundary defines where approaches like vibe coding will succeed or fail.

Where vibe coding works

Vibe coding delivers the most value at the application layer.

Because it allows software to be generated directly from intent, it significantly reduces the time and effort required to build user-facing functionality.

Teams can create interfaces, workflows, and data-driven views quickly, test them immediately, and refine them through iteration.

This makes vibe coding particularly effective in scenarios where:

The scope is well defined
The context is known and controlled
The behavior is tied to a specific use case
The goal is speed and rapid delivery

For example, a team can use vibe coding to build a simple internal tool, a workflow application, or a customer-facing feature such as a dashboard tied to a specific dataset.

In these cases, the system does not need to operate across many environments or adapt to fundamentally different contexts.

In this setting, the ability to generate a working result and refine it through prompts is a clear advantage. It enables faster iteration, lowers the barrier to building useful functionality, and allows more people within an organization to participate in creating software.

This is not limited to prototypes. When the scope is narrow and requirements are stable, these applications can be used in production with appropriate oversight.

However, all of this operates within a boundary.

Applications created through vibe coding depend on underlying services. They rely on systems for data access, identity, security, and execution.

These capabilities are not generated as part of the application—they are assumed to exist.

This is why vibe coding works so well at the application layer. It allows teams to focus on functionality without building the systems that make that functionality possible.

Embedded analytics: generate code or generate analytical assets

There are two ways to use AI in embedded analytics. One is to generate code that produces analytics without relying on an analytics platform. The other is to generate analytical assets directly inside a platform.

At a surface level, both approaches look similar. You describe the dashboard you want, the data you need, and the output appears quickly. But beneath that surface, two fundamentally different models are at work.

AI generating raw code without a platform

In the first model, AI is used to generate the code that produces analytics. A prompt returns JavaScript, SQL queries, API calls, and application logic, which are then assembled into dashboards or data-driven features inside the application. This can be fast. It can look complete and create the impression that analytics has been solved.

However, what is being created is still raw code, and it comes with two consequences.

First, the team now owns that code. The people prompting the system are no longer simply defining dashboards or datasets. They are generating software artifacts—JavaScript, SQL, integrations, and logic.

In many cases, they cannot fully read or reason about what has been produced, yet they remain responsible for how it behaves and evolves over time.

Second, that code is being created without an analytics platform. The generated dashboard does not inherit tenant isolation, governance, permissions, lifecycle management, or deployment processes. These capabilities must still be designed, built, and maintained.

What begins as “let's generate a dashboard” in our SaaS application quickly expands into responsibility for data access and modeling, permission systems, tenant separation, versioning and deployment, and ongoing maintenance.

At that point, the team is no longer just creating analytics. It is quietly building an analytics platform, piece by piece in application code—even if that was never the intention.

And even with experienced developers, this is not a small extension of the application.

It becomes a larger undertaking: designing and maintaining a system that can exceed the complexity of the application itself.

AI accelerating the creation of analytical assets

In the second model, AI accelerates the creation of analytics inside a platform. The output is not raw code, but analytical assets—dashboards, datasets, visualizations, and workflows—created within a system that already defines how they behave. AI simply makes it faster to create within that structure.

The analytics team remains in its existing role, building dashboards and shaping data. The outputs are familiar, understandable, and directly manageable.

Because they are created inside a platform, they inherit its behavior automatically.

The real distinction

Both models use AI, and both can produce dashboards quickly. But they are not equivalent.

In one model, AI generates raw code without a platform, forcing the team to take on both the artifacts and the system those artifacts require. In the other, AI accelerates the creation of analytical assets inside a platform, where that system already exists.

The difference is not speed. The difference is what you are building—and what you are taking on as a result.

The right model for embedded analytics

By this point, the conclusion is clear. AI is already part of how analytics is created. The question is how it is used.

AI can be used to generate code that produces analytics directly in the application. This can be fast and convincing, but it comes with a cost: the team takes ownership of both the code and the platform-level system it implies.

Alternatively, AI can accelerate the creation of analytical assets inside a platform. In this model, dashboards, datasets, and visualizations are created within a system that already provides the capabilities embedded analytics requires.

The team continues to build analytics, but does so within a structure that ensures those analytics behave correctly in production.

The fundamental difference

The difference is fundamental. In one approach, the team is building an analytics platform. In the other, it is using one.

The right model for embedded analytics in the age of AI is not to replace platforms with generated code, but to use AI on top of a platform. AI should accelerate how analytics are created; the platform should ensure they work reliably at scale.

This is where Qrvey fits.

Qrvey provides the system that embedded analytics depends on while enabling teams to create analytical assets quickly using AI.

It allows organizations to move faster without taking on the complexity and long-term responsibility of building and maintaining an analytics platform themselves.

The outcome is not simply faster development. It is analytics that is created efficiently, remains understandable to the people building it, and is ready to operate in a real SaaS product.

Next step