For years, there’s been two main choices when it comes to building Power Apps:
Are you going to build a Canvas app?
Or a Model-driven app?
(Or sometimes a hybrid of the two.)
Both approaches are fundamentally low-code.
You drag and drop controls.
You write some Power Fx.
You connect to data.
You’re productive.
This model has served millions of builders well.
But Microsoft has now introduced a new type of app in Power Apps that is structurally different from both Canvas and Model-driven apps:
Code Apps.
What are Code Apps?
“Code Apps” are literally apps built with real code. They’re full web applications written in your favorite IDE using the same languages professional devs use (TypeScript, React, etc.), but still getting all the Power Platform benefits like access to connectors, security, hosting and management, all without you having to wire that up yourself.
That’s the key distinction: You get the full control and flexibility of a real web app, PLUS the platform services and enterprise guardrails of Power Platform.
Code Apps aren’t a watered-down version of pro-code development. They are real, professional web apps, just built, hosted, and governed inside a managed platform rather than scattered across different cloud services.
Here’s what that means in simple terms:
- You can develop locally in Visual Studio Code or another code-first IDE
- You can use real web frameworks like React or Vue with full control over how your UI behaves
- You don’t have to worry about authentication, data source connections, or infrastructure because the Power Platform takes care of those
- You do get to use the same governance, lifecycle, and policy controls admins already depend on in Power Apps environments
That’s why these are called Code Apps, because they are full-code web applications, even though they live in Power Platform.
How vibe.powerapps.com Fits With Code Apps
Here’s the relationship between code apps and vibe.powerapps in a nutshell:
- Code Apps are the new app type.
- vibe.powerapps.com is one way to create them without needing to start in a code IDE.
This gives you a no-code on-ramp to a code-backed app model.
You describe what you want to build, and:
- The Requirements agent goes to work defining your user stories.
- The Data agent takes those requirements and defines the data model.
- The App agent kicks in and generates the front end.
It’s About Vibe Coding With Guardrails
Across the industry, “vibe coding” often implies:
Generate code.
Hope it works.
Figure out deployment later.
Code Apps change that story. Because they live inside Power Platform, that means you get:
- Dataverse as the data layer
- Entra ID authentication
- Role-based security
- Environment isolation
- Solution support
- ALM and version management
- Connector access governed by DLP policies
- Tenant-level governance and auditing
You aren’t just generating UI. You’re generating an application that automatically inherits enterprise controls.
This is what makes the approach different from standalone AI coding tools.
Low-code builders can experiment with intent-driven app creation (aka “vibe coding”) while staying inside governed infrastructure.
That combination, creative input plus enterprise guardrails, is the key differentiator.
“Describe What You Want” Doesn’t Remove Skill
One concern I’ve heard is that phrases like “you describe what you want” minimize the effort required to produce something valuable.
The natural language “vibe coding” approach to building doesn’t replace the need for domain expertise, understanding your business processes, or even data modeling knowledge and security thinking.
Poor instructions still produce poor systems, and that has always been true. And yes… in the real world, some people will bypass all of that and just use the “prompt and pray” approach.
But this behavior isn’t new. Low-code platforms didn’t create it. They simply make it more visible and accessible.
What actually changes with vibe-powered experiences is where effort is applied.
Instead of spending most of their time arranging layouts and wiring controls, builders spend more time defining:
- Outcomes
- Data relationships
- Roles
- Behaviors
The platform handles more of the mechanical implementation. The builder still defines the system. This is abstraction, not automation of thinking.
Why Not Just Use “Real Vibe Coding Tool”
When I posted about this on LinkedIn, someone asked, “Why not invest in a vibe coding tool that builds REAL pro-code apps using real libraries, frameworks, and use your existing hosting models?”
First, I’ll try not to take offense at the implication that Power Apps isn’t a “real” tool for app building 😉.
Look, if you’re a pro-dev already comfortable with framework selection, hosting decisions, CI/CD setup, identity integration, infrastructure management, etc. Then yeah, AI-assisted pro-code tools are probably your preferred path.
Code Apps are not trying to replace that ecosystem.
They serve a different audience:
- Builders who already work in Power Platform
- Teams building internal business applications (not apps you want to put in the app store for public consumption)
- Organizations that value governance by default
- Low-code makers who want more UI flexibility
There is a clear tradeoff with this. You’re trading less control over infrastructure for more platform integration. And for many enterprise scenarios, that tradeoff is desirable.
Where Things Stand Today (and How to Approach It)
So let’s recap and level-set.
- Code Apps as a new app type in Power Apps
- vibe.powerapps.com as an AI-first authoring experience for building them
- This introduces an intent-first way to create code-backed apps inside a governed platform
That’s the architectural shift. Now, let’s look at the practical reality.
The vibe authoring experience is currently in public preview. It’s also limited to English-only support in the US, Australia, and Asia regions.
Because this is in preview, you should not be using vibe.powerapps.com to build production-critical applications today. Let’s all say it together now: We don’t build production apps with preview functionality!
Preview functionality is for learning, exploring, testing scenarios, and giving feedback. Not shipping mission-critical apps.
Another common question I see about the vibe.powerapps.com experience concerns code access.
Today (in the public preview), you can’t directly edit the underlying code of a vibe.powerapps.com generated app.
However, the product team has shared that the code is viewable, and support for editing the code is planned for GA. So all that points to the long-term direction not being “black box apps.” It’s code-backed apps with multiple authoring paths, intent-first or code-first.
So, I wouldn’t freak out and say this is “doomsday”. Your Canvas and Model-driven apps aren’t being replaced or abandoned. The spectrum of Power Apps development is simply being expanded.
And for builders, understanding that spectrum early is the real advantage. Not because everything is ready. But because the way we think about building apps inside Power Platform is evolving. That awareness will matter long before any single feature reaches GA.
Want to see this in action? Check out the video.