Vibe coding without shadow IT
Power Apps Code Apps · Conference field notes
Vibe coding without shadow IT
AI can build an internal app in minutes. The enterprise question is no longer whether people will do it, but where the result runs, which identity it uses, and whether IT can still govern it.
At ARICOMA's Two Faces of AI in Power Platform 2026 event, I opened my live demo with a deliberately uncomfortable question: how many applications exist in your company that IT does not know about?
Generative AI has shortened the path from an idea to working software. That is useful, but it also removes the friction that once limited shadow IT. A person who could not build an application last year can now prompt a coding agent, connect a data source, and have a plausible interface before IT has even heard about the requirement.
The question is no longer how to ban vibe coding. The question is how to govern it safely.
The demo, not the promise
I did not show a pre-recorded animation or a polished sample with the difficult parts removed. I started from a Code Apps scaffold and asked an AI coding agent to build a small equipment-request application. The first prompt required it to read requests from a SharePoint list through the Power Apps SDK and display them in a clear table with status badges.
The instruction also included an important boundary: use the existing Power Platform data source; do not invent custom authentication or direct API calls. The agent could decide how to implement the React interface, but it could not silently replace the enterprise connection model.
I then extended the scenario with a Dataverse equipment catalogue. The coding agent added the data source and updated the application so a user could open a request and see related catalogue information. The entire flow remained inspectable in the project: prompt, generated TypeScript, data services, and the changes made by the agent.
AI wrote application code. It did not become the identity provider, the connector platform, the policy engine, or the production host.
Why the runtime matters more than the prompt
A React application built with an AI assistant can run almost anywhere. That flexibility becomes a problem when every maker chooses a different host, stores credentials differently, and connects directly to company data. Code Apps changes the operational boundary: developers keep normal web technologies and source code, while the application runs as a Power Apps asset.
According to the official Code Apps overview, this model brings Microsoft Entra authentication, Power Platform data sources and connectors, managed hosting, organizational policies, sharing, and ALM to a code-first application.
- Identity stays explicit. Users access the application with Microsoft Entra identities rather than credentials hidden in generated code.
- Data access remains governable. Connectors are visible to the platform and subject to Data Loss Prevention policies.
- Environment boundaries still apply. Administrators can separate development, test, and production and control where apps are shared.
- Policy changes can outlive the prompt. A revised DLP or Conditional Access policy can be enforced without asking the original AI agent to rewrite every application.
From a prompt to a working business app
The generated result was intentionally ordinary: a request list, readable columns, and visual status indicators. That is precisely why the example matters. Enterprise software is full of small, specific applications like this. They are valuable enough to build, but rarely important enough to justify a bespoke hosting and identity architecture.
The SharePoint connection supplied the request data. The Dataverse connection enriched the detail with catalogue information. Adding a data source to a Code App generates typed TypeScript models and services in the project, which an agent can use without hard-coding raw HTTP calls. Microsoft documents the same pattern for both tabular and non-tabular sources in its Code Apps data connection guide.
After the local test, I published the application to the selected Power Platform environment. It appeared in the maker portal as an app of type Code, with the familiar play, share, details, and settings actions. The code did not disappear into a one-shot prompt. It remained a normal project that a developer could inspect, change, test, and publish again.
Code-first is not the same as uncontrolled
The most useful part of this approach is not loyalty to a particular AI model. The demo used Claude Code, while Microsoft's Power Platform Skills repository supports plugins for Claude Code and GitHub Copilot. The assistant can change. The application architecture and governance boundary should not.
Code-first also creates a practical collaboration point between makers and professional developers. A maker can describe the business need and iterate on the interface. A developer can review the actual TypeScript, correct an unsafe assumption, add tests, and take responsibility for the production path. The hand-off is source code, not a screenshot of a prompt conversation.
Code Apps fit when…
- The UI or interaction requires normal web-development freedom.
- A team can own React or TypeScript after the first prompt.
- The app needs Power Platform connectors and managed hosting.
- Developers need direct access to the generated source.
Use a native app when…
- A standard canvas or model-driven experience solves the requirement.
- Low-code makers must maintain the app without a JavaScript toolchain.
- Native controls and formulas are more important than custom UI.
- The scenario depends on a feature Code Apps does not support.
Managed does not mean finished
Code Apps gives an AI-generated application a much better place to live, but it does not remove engineering responsibility. Someone still needs to review authorization, connector usage, error handling, accessibility, performance, telemetry, dependencies, and support ownership.
Know the current boundaries
- Code Apps require a developer toolchain and users need the applicable Power Apps licensing.
- Power Platform Git integration and SharePoint forms integration are not currently supported.
- Power Apps for Windows is not currently a supported runtime for Code Apps.
- Compiled assets are served from a public endpoint; access to the app is protected by Microsoft Entra ID, and location restrictions should be implemented with Conditional Access.
-
Tooling is evolving. Microsoft's documentation notes a transition from
pac codecommands to the newer npm-based CLI, so verify the current quickstart before copying commands from an older demo.
These limitations are not reasons to dismiss the approach. They are reasons to treat it as a real application platform rather than a magic prompt box.
Govern the path before the first prompt
If an organization wants to make vibe coding useful instead of merely unavoidable, the paved road must exist before employees choose their own. Define which environments are intended for experiments, which connectors are allowed, who reviews generated code, how ownership is recorded, and how an app moves to production.
Then give people a supported scaffold, an approved AI skill, and a deployment route. The goal is not to make every citizen developer a professional React engineer. The goal is to prevent a useful idea from becoming an invisible, unsupported application with direct access to company data.
The output of vibe coding is still software. Speed changes how quickly risk appears; it does not make the risk disappear.
What would you rather govern: AI-generated apps running who-knows-where, or the same apps inside a platform whose identity, data connections, sharing, and lifecycle you already control?
Comments
Post a Comment