Microsoft just shipped three new skills for the Power Pages agentic code plugin that finally let GitHub Copilot and Claude Code CLI generate server-side logic, not just front-end markup. The announcement landed on the Power Platform blog and this is the gap-closer I have been waiting for. Power pages agentic code server-side generation is the part that was missing.
If you have built anything non-trivial on Power Pages you know the pattern. The studio handles the front-end fine. The moment you need a Web API call, a table permission rule, or a Liquid template that actually does work, you are out of the visual layer and into code that the AI tools could not see properly.
What it actually does
The plugin now ships three new skills focused on the server-side surface of a Power Pages site. From the post and what I have read so far, these cover generating and wiring up Liquid templates with the right context, scaffolding Web API calls against your actual Dataverse tables, and producing the configuration around table permissions and site settings that normally requires you to know exactly which knob to turn.
The important detail is grounding. The plugin pulls from your real site context: the tables you have, the columns on them, the page structure, the site settings already in place. So when GitHub Copilot or Claude Code CLI generate Liquid or a Web API snippet, it is generated against your actual environment, not a hypothetical portal.
I wrote about this grounding problem before in an earlier post on Power Pages and AI. Generic LLM output for Liquid looks correct and breaks immediately on deploy because the model has no idea what your tables are called or what permissions are wired up. Environmental grounding is the entire game here.
Why server-side AI generation is different leverage
Front-end scaffolding from AI is useful but cheap. Anyone can prompt a model to spit out HTML and CSS for a form. The hard part of Power Pages was never the markup. It was the layer underneath: Liquid templates, Web API permissions, plugin logic, the settings that decide whether a record is visible to an authenticated contact or not.
That layer is where sites break. That layer is where you used to bolt on a Power Automate flow because it felt easier than figuring out the right server-side pattern. And bolting on a flow for what should be a server-side query is exactly the kind of decision that creates a silo three months later when nobody remembers why the form posts to a flow instead of using the Web API directly. Understanding Power Automate error handling patterns helps when those flows do need to exist, but the goal should be keeping server-side work on the server side.
Generating server-side logic with proper grounding cuts that path off. You stay inside the site. You use the layer that was already designed for it. The trade-off is real though: you now have AI-generated Liquid and permissions in a place where mistakes are harder to spot than a broken button. Server-side bugs do not show up as the dreaded broken image icon. They show up as a record being visible to the wrong user, which is a much worse failure mode.
This is why I keep saying tool design for AI agents is an API design problem. The quality of the environmental signals fed to the model matters more than the model itself. Microsoft Learn for Power Pages is the reference I keep open when I am sanity-checking what these skills produce.
What I would do with it this week
I would pick a small internal-style site with two or three Dataverse tables, authenticated users, and one workflow that currently lives in a Power Automate flow it should not live in. Something where a list view filters by the logged-in contact, and a form writes back to a related table.
Then I would have Claude Code CLI do three things. First, generate the Liquid for the filtered list using the new skill, against the real tables. Second, generate the Web API call for the form submission with the right permissions, instead of the Power Automate detour. Third, write a small piece of logic that should obviously fail without context, like referencing a column that does not exist, just to see how the grounding holds up.
The point is not to ship anything. The point is to find where it breaks. In my experience, the only honest way to evaluate one of these releases is to push it until it produces something wrong, then look at why. If you are thinking about where this fits in a broader agentic architecture, most agentic workflows are just fancy if/then logic until the grounding is solid enough to trust the generated output in production.
If the grounding is as good as the announcement suggests, this changes how I would start any new Power Pages build going forward.
This post was inspired by Build your server-side logic with AI: new Power Pages Agentic Code skills via Microsoft Power Platform Blog.