For years, Power Apps has been Microsoft’s answer to making application development more accessible. Instead of writing everything from scratch, developers and makers could build business applications using visual designers, connectors, Power Fx, and Dataverse.
Now Microsoft is introducing something that challenges this approach. With Copilot Code, users can describe an application in natural language, watch AI generate the underlying software, refine it conversationally, and publish it for others to use.
No traditional application designer required. Woohoo!! But this raises an interesting question: If AI can generate working applications from a prompt, where does that leave Power Apps?
The answer isn’t quite as straightforward as replacing low-code with AI-generated code. Copilot Code is primarily an AI-driven development experience, whereas Power Apps is a broader application platform. To compare how applications are built, we can examine their development experiences. To compare architecture and operations, the more meaningful comparison is Copilot Code together with Copilot Managed Runtime versus the different Power Apps development and hosting options.
To understand why, we need to look beyond how applications are created and examine what happens after they’re built.
What is Copilot Code?
Copilot Code is a development experience within Microsoft Copilot, available through the Frontier preview program.
Users describe an outcome, such as a dashboard, internal tool, website or script, and work with Copilot to generate and refine it.
Capabilities include:
Generating software using natural language.
Previewing and refining applications.
Working with GitHub repositories, branches, commits and draft pull requests.
Using local or cloud coding sessions, where enabled.
Publishing supported applications through Copilot Managed Runtime.
That last capability is particularly important. Microsoft has also introduced Copilot Managed Runtime, providing hosting, Microsoft Entra authentication, governed data access, and centralised application management
This means Copilot Code isn’t simply generating a website and leaving developers to figure out where to host it.
Microsoft is building an application platform around AI-generated software.
Note: Copilot Code and Copilot Managed Runtime are preview capabilities as of October 2026. Availability and functionality may change.
But isn't Power Apps already doing this?
To some extent, yes. Power Apps already supports AI-assisted application development, including experiences that help makers generate applications and work with data using natural language.
And Power Apps is no longer exclusively a visual, low-code development platform, with Power Apps code apps, developers can build custom web applications using frameworks such as React and Vue, work locally in Visual Studio Code, and deploy those applications into Power Platform.
These applications can use Microsoft Entra authentication, Dataverse, Power Platform connectors, and platform governance controls.
So the distinction isn’t simply:
Power Apps = Low-Code
Copilot Code = Pro-Code
Both platforms are evolving beyond those definitions. The more meaningful differences lie in their development experiences, data architecture, runtime, and application lifecycle.
Development experience: From components to outcomes
Traditional Power Apps development gives makers explicit control over application components. Canvas apps allow developers to design interfaces, configure properties, write Power Fx expressions, and connect data sources.
Model-driven apps take a metadata-driven approach, generating experiences from Dataverse tables, forms, views, and business processes. Code apps on the other hand offers a more conventional developer experience using JavaScript or TypeScript frameworks.
Copilot Code approaches development differently, rather than starting with a designer, framework, or data model, developers describe the outcome. For example: Create an internal request management application where employees can submit requests, assign priorities, track approvals, and view outstanding items.
Copilot Code can generate an initial application and progressively refine it through subsequent instructions. That’s a compelling experience, particularly for rapid prototyping. However, generating the interface is only one part of application development.
What happens when approval logic becomes complex? When requirements change? Or when different users require different permissions?
The real question isn’t whether the Copilot Code can generate an application, It’s how reliably that generated application can be understood, extended, tested, and maintained as requirements evolve.
Data architecture: Connecting to data vs designing around it
This is where the comparison becomes particularly interesting. Power Apps has a well-established relationship with Dataverse where developers can define tables, relationships, choices, business rules, security roles, and server-side extensions.
For example, a request management application might require:
- Separate request and approval tables.
- Relationships between employees, departments, and requests.
- Role-based access restrictions.
- Server-side validation.
- Auditing and integration with external systems.
Dataverse provides an established framework for managing these requirements. Copilot Code can also work with organisational data and services through approved plugins and connectors.
Importantly, Copilot Managed Runtime includes Dataverse among its default approved connectors, alongside SharePoint, Teams, Outlook, and other Microsoft services.
However, accessing Dataverse doesn’t automatically mean the generated application has an appropriate data model, that’s still an engineering responsibility.
Developers should examine how applications handle data relationships, validation, transactional consistency, and permissions rather than assuming AI-generated code gets these details right.
For relatively simple applications, a lightweight generated solution may be sufficient. For complex business processes, however, choosing the right underlying data architecture remains critical.
Governance: Is Copilot Code another shadow IT problem?
It’s tempting to assume that giving everyone an AI application builder creates an entirely new governance problem. But that overlooks what Microsoft is implementing with Copilot Managed Runtime.
Applications hosted on the runtime inherit organisational controls, including:
- Microsoft Entra authentication.
- Governed connector access.
- Application sharing restrictions.
- Content security policies.
- Centralised inventory and monitoring.
Administrators can review these controls through the Microsoft 365 admin centre.
Microsoft also restricts certain potentially risky connector actions by default, including arbitrary HTTP requests and selected Dataverse operations. See Copilot Managed Runtime governance settings.
Power Apps provides its own mature governance capabilities, including data policies, Managed Environments, Conditional Access, environment groups, and administrative monitoring. So this isn’t a comparison between governed and ungoverned development, it’s a comparison between two application platforms with overlapping, but not necessarily identical, governance and operational models.
For organisations already operating Power Platform at scale, understanding how these controls interact will be essential.
Application lifecycle management: Planning for change
An application that works in a preview is not necessarily ready for production. Power Platform has established ALM capabilities built around solutions, environment separation, connection references, environment variables, and deployment pipelines.
Developers can move applications through Development, Test, and Production environments using repeatable deployment processes. Even Power Apps code apps now support solution-based deployment through the Power Apps CLI.
Copilot Code offers GitHub integration, while Copilot Managed Runtime provides deployment, versioning, and source-control capabilities.
These are meaningful features.
However, Copilot Managed Runtime’s application lifecycle is not the same as Power Platform’s solution-based ALM model.
Before treating the two approaches as interchangeable, developers should investigate:
- How application versions are promoted and rolled back.
- Whether deployment processes can enforce automated quality gates.
- How environment-specific configuration is managed.
- How dependencies are packaged.
- Whether production changes can be restricted and audited.
- How generated applications fit into existing CI/CD processes.
These questions become increasingly important as applications grow beyond individual productivity tools.
A successful deployment isn’t just one that works today. It’s one that can be changed safely tomorrow.
Licensing: Does easier development mean cheaper applications?
aster development does not automatically mean lower operating costs.
Copilot Code access and development consumption need to be assessed separately from the cost of hosting and running applications.
Microsoft’s licensing guidance describes Copilot Credits for Copilot Managed Runtime hosting, runtime and management. Power Apps Premium includes runtime access within applicable request limits, while hosting, management, separately billed services and usage beyond those limits can still consume credits. See the Copilot Credits licensing guidance.
Power Apps licensing also depends on the application type, functionality, connectors and deployment approach.
An evaluation should consider:
Development usage.
Hosting and runtime consumption.
Expected user numbers.
Data and integration requirements.
Ongoing support and maintenance.
Compare the cost of operating the application over its expected lifespan, alongside the effort needed to create it.
Which should developers choose?
There’s no universal answer.
The following scenarios provide a starting point for evaluation. They are practical considerations rather than hard platform boundaries.
| Scenario | Starting point to evaluate |
|---|---|
| Rapidly exploring a dashboard or internal productivity tool | Copilot Code |
| Building a structured Dataverse business application | Power Apps |
| Creating a custom web application within Power Platform | Power Apps code apps |
| Experimenting with AI-generated scripts and software | Copilot Code |
| Extending a complex Dynamics 365 business process | Power Apps and Dataverse |
| Building an internal application using approved Microsoft 365 data | Evaluate both approaches |
The right choice depends on application complexity, expected lifespan, data requirements, integration needs and operational expectations.
Teams should also consider who will own the application and how comfortably they can maintain it after the initial build.
How the developer’s role is changing
Copilot Code represents an important shift in how software can be created.
But Power Apps has never been valuable simply because it reduces the amount of code developers write.
Its value also comes from the underlying application platform: structured data, extensibility, security, integrations, and lifecycle management.
AI-generated software doesn’t eliminate the need for those capabilities.
If anything, making software easier to create increases the importance of ensuring that applications are secure, reliable, maintainable, and appropriately governed.
The future may not be a choice between AI-generated applications and traditional low-code development.
Instead, we’re moving towards a world where application creation becomes increasingly conversational, while engineering and operational disciplines remain essential.
And perhaps that’s the more interesting change.
Developers may spend less time constructing applications component by component, and more time defining architecture, validating generated solutions, designing integrations, and ensuring software behaves correctly.
AI is changing how we build software. It isn’t removing our responsibility for what we build.
