Halilcan Soran

Tag: Claude Code

  • Power Pages Agentic Coding Hits GA and I Already Know Where I Am Pointing It First

    Power Pages Agentic Coding Hits GA and I Already Know Where I Am Pointing It First

    Power Pages agentic coding GA announcement with GitHub Copilot CLI and Claude Code

    Microsoft just announced Power Pages agentic coding GA for the GitHub Copilot CLI and Claude Code plugins. The official blog post went up today, June 9, 2026, and it moves the plugin from the preview we got a few months ago into something I can actually plan delivery around.

    I wrote about why GA matters for Power Pages tooling when the news first broke. Now that it is live in the docs, I want to talk about where I would actually point it first.

    What shipped

    The Power Pages plugin for GitHub Copilot CLI and Claude Code is now generally available. In the preview you could describe a site in natural language, and the plugin would generate the scaffolding, set up Dataverse tables, wire up the Web API, and deploy the site. GA means the API contract is stable, the plugin is supported, and it can sit inside a real CI pipeline without the rug getting pulled.

    The pattern is the same as before. You stay in your terminal. You describe what you want. The plugin grounds itself in your actual Power Platform environment, reads the existing tables and site settings, and generates Liquid, Web API calls, and configuration that match what is really there.

    What it actually does

    The thing that makes this different from generic AI code generation is environmental grounding. Asking ChatGPT to write Liquid for a Power Pages site produces output that looks right and breaks immediately on deploy, because the model has no idea what your tables are called or what permissions are wired up.

    The Power Pages plugin reads your environment first. It knows your table names. It knows your site settings. It knows the authentication contact relationships. The generated code is diffable and committable, not a guess against a hypothetical portal.

    The other thing GA changes: this is the difference between a side experiment and something I can put in a pipeline. Preview features at most large enterprises do not make it to production. Security review blocks them. Procurement blocks them. Internal policy blocks them. GA is the switch that lets a pro dev actually own a full portal project end to end without leaving the terminal.

    Why it matters

    Power Pages has always had a split personality. The maker studio handles front-end click work, and the layer underneath, covering Liquid templates, Web API calls, table permissions, and plugin logic, requires real code and environment-specific context. You end up configuring half the site in one place and half in the other, with no reliable way to keep them in sync.

    Agentic coding at GA collapses that split for the pro dev path. You can scaffold tables, generate Liquid, wire up the Web API, and version the whole thing in git. That is a real shift in who can iterate on Power Pages sites and how fast they can do it. If you want more context on where agentic tooling is heading across the broader platform, Microsoft Build 2026 Made Fabric and Azure Databases the Foundation for Agentic Apps and the Direction Is Clear lays out the architecture story behind it.

    I want to be careful about one thing. This is not a citizen dev tool. It looks like one because the entry point is natural language, but the output is code that needs to be reviewed, committed, and deployed through a pipeline. Treating it as a click-and-ship tool is how you end up with a portal that nobody can debug six months later. The Power Pages documentation is still required reading.

    What I would do with it this week

    I would not point this at a polished external portal first. That is the wrong target. The schema is too settled, the design system is too constrained, and the value of AI scaffolding is lowest when the requirements are clear.

    I would point it at an internal-facing site where the schema is messy and the stakeholder keeps changing their mind. Think a request intake portal for a small ops team. A vendor onboarding tracker. An internal exception-handling site that nobody has gotten around to building because the requirements never sit still long enough. The Dataverse side of this gets more interesting now that Dataverse Just Got Knowledge Sources and Agent Feedback Loops, which gives the plugin even more to work with when it reads your environment.

    Those are exactly the cases where regenerating the scaffolding cheaply matters. The stakeholder says “actually we need a new field and a different approval path” on Thursday afternoon, and instead of rewriting Liquid by hand, you describe the change and let the plugin redo the wiring against the current environment.

    That is the workflow I want to test. I have spent enough time rebuilding intake portals because the requirements drifted to know exactly where this saves real hours.

    GA is the green light. Now the question is which internal site gets to be the first one I rebuild.

    This post was inspired by Build Power Pages Sites with AI through Agentic Coding tools, now Generally Available via Microsoft Power Platform Blog.

  • Power Pages Agentic Coding Tools Just Went GA and the GitHub Copilot CLI Plugin Is What I Am Trying First

    Power Pages Agentic Coding Tools Just Went GA and the GitHub Copilot CLI Plugin Is What I Am Trying First

    Power Pages agentic coding tools GA in GitHub Copilot CLI terminal

    Microsoft just announced that the Power Pages agentic coding tools GA milestone is here. The plugins for GitHub Copilot CLI and Claude Code are now generally available, after a preview that landed earlier this year. You can read the full announcement on the Power Platform blog.

    This is the part I have been waiting for. Power Pages site building is moving out of the maker portal and into the terminal where pro devs actually live. That changes who can credibly own a Power Pages project inside a large org.

    What it actually does

    The plugin sits inside GitHub Copilot CLI or Claude Code as an extension. You describe the site in natural language. The agent generates the scaffolding, sets up Dataverse tables, wires up the Web API, configures table permissions, and deploys the site.

    The important bit is the grounding. The plugin is not asking the model to guess at Liquid syntax or invent table names. It reads your actual environment, your existing tables, your site settings, your authentication setup. The output lands in your repo as files you can diff, review, and commit.

    You get the standard pro-dev loop. Branches. Pull requests. CI checks. Code review. The site definition is text, the agent generates text, and Git handles the rest. No more configuring half the site in the maker studio and the other half through manual file edits and praying the two stay in sync.

    Why moving to GA actually matters

    Preview features do not get deployed to production at most enterprises I talk to. Security reviews block them. Procurement blocks them. Internal policy blocks them. GA flips that switch.

    More importantly, GA means the API contract is stable enough that you can build CI around it without expecting it to break next month. That is the difference between a fun side experiment and something a team commits to as a standard delivery pattern.

    The bigger shift is cultural. Power Pages has always had a split personality. The studio handles the front-end click work, but the layer underneath, Liquid templates, Web API calls, table permissions, plugin logic, is real code. I wrote about this when the server-side skills landed. The maker portal hid the code layer behind a UI that pro devs did not want to touch and citizen devs could not safely change.

    Pulling the build process into Copilot CLI or Claude Code lets a pro dev own the whole site end to end without leaving the terminal. That is a real unlock for the kind of internal portal work that has been stuck between teams for years. If you are also thinking about how multi-agent orchestration patterns in Copilot Studio fit alongside this kind of terminal-driven build loop, the two are worth thinking about together.

    The trade-off is honest. This is not for citizen devs. If your maker has never opened a terminal, this is not their tool. The maker studio is not going away, and it should not. But for the portal projects where someone wanted to use Git, code review, and a real deployment pipeline and could not, the path now exists.

    What I would do with it this week

    I would pick the smallest internal Power Pages site I can find. Something with two or three tables, an authenticated user experience, and a form that writes back to Dataverse. Nothing customer-facing. Nothing with sensitive data.

    Install the Power Pages plugin in GitHub Copilot CLI. Point it at a dev environment that mirrors a real one but is safe to break. Ask it to scaffold the site from a short description and let it generate the Dataverse tables and Web API config. If you want the agent to do more than scaffold, Dataverse knowledge sources and agent feedback loops are worth wiring in at this stage.

    Then I would intentionally break something. Change a table permission by hand in the maker studio. Re-run the agent. See how it handles drift. That is the failure mode that will hurt in production, and you want to know the answer before you commit to this for a real project. I have learned the hard way that the demo path always works. The drift path is where tools live or die.

    I would also run the same prompt through both the Copilot CLI plugin and the Claude Code plugin and compare the output. Same site, same description, two agents. The deltas will tell you a lot about which one to standardise on.

    For anyone running portal projects inside a large org, this is the week to actually try it. The Power Pages docs have the setup steps and the plugin is a clean install.

    The terminal is becoming a real surface for Power Platform work, and I am here for it.

    This post was inspired by Build Power Pages Sites with AI through Agentic Coding tools, now Generally Available via Microsoft Power Platform Blog.

  • Power Pages Just Got Server-Side Logic You Can Actually Generate With AI

    Power Pages Just Got Server-Side Logic You Can Actually Generate With AI

    Power Pages server side logic AI code generation with GitHub Copilot and Claude Code CLI

    Power Pages server-side logic has always been where the low-code promise quietly falls apart. You get a clean design studio, drag-and-drop layouts, reasonable out-of-the-box forms. Then someone asks for server-side validation that cannot safely run in the browser, a secure external API call where the key can never touch the client, or a multi-table transaction that needs to complete before a Dataverse record is committed. And these three new skills are for modern single-page application (SPA) Power Pages sites specifically — not the classic Liquid-templated architecture — which matters if your audience spans both worlds. And suddenly you’re either writing it from scratch by hand, spending an afternoon in documentation, or handing it off to someone on a proper dev team and waiting. I came across a post from the Microsoft Power Platform Blog about three new agentic code skills for the Power Pages plugin, and it hit on something I’ve been thinking about for a while: the ceiling for what a single automation developer can ship in Power Pages without a dedicated dev team behind them just moved.

    What Server-Side Logic in Power Pages Actually Means and Why It Was Always the Hard Part

    Power Pages is a low/no-code portal builder sitting on top of Dataverse. The studio handles most of the front-end work reasonably well. But portals have always had a split personality. There’s what you can configure visually, and then there’s the layer underneath. For modern SPA-style Power Pages sites, that means server-side JavaScript endpoints that handle validation, secrets, and external API calls; Cloud Flow connections for backend automation; and integrations with systems that can’t be wired directly from the browser. That second layer is not configuration. It is code. And it requires context about your specific environment to write correctly.

    This is why generic AI code generation has never worked well here. Asking an LLM to write you a server-side endpoint without knowing your Dataverse schema, your table structure, or your page context produces something that compiles and fails as soon as you wire it to real data. The model doesn’t know your environment. You end up doing the real work yourself anyway, just with a plausible-looking starting point that may or may not match reality.

    What These Agentic Code Skills Actually Do When You Run Them

    The specific thing that matters here is scope. These are not general-purpose code suggestions. The plugin is grounded in your actual Power Pages site. It understands your tables, your site settings, your page context — because architect agents analyze your actual code and query your Dataverse environment before generating anything. Then they propose specific changes for your review before anything is applied. That propose-then-approve loop is not a limitation; it is a selling point. You stay in control of what lands in your site. When you describe the server-side behaviour you need, the generated code is scoped to your environment, not a hypothetical portal that shares no properties with yours.

    That is the distinction most people will miss when they skim the announcement. The three new skills are /add-server-logic, which generates server-side JavaScript endpoints for validation, secrets management, and cross-entity operations; /add-cloud-flow, for connecting backend automation; and /integrate-backend, for wiring in external systems. These join six existing skills in the plugin — nine total. Each one is pulling from what the plugin already knows about your site structure. The output is contextually aware in the same way that Claude operating with good tool design returns useful results because it has real signals to work with, not because the model is smarter in isolation. I wrote about this in the context of agentic workflows generally: tool design is an API design problem, and what makes these skills interesting is that Microsoft has done that tool design work to give the model actual environmental context to reason against. If you want to go deeper on how Claude functions as that reasoning layer in enterprise contexts, Claude as an Orchestration Brain Is the Most Interesting Thing Happening in Enterprise AI Right Now covers the architecture side of that in more detail.

    The Claude Code CLI path is worth calling out specifically. If you’re already working with Claude for orchestration or code tasks outside the Power Platform, having it also handle your Power Pages server-side work inside the same workflow is practically useful. You’re not switching contexts or tools.

    The Specific Scenario Where I Would Use This First

    The scenario I keep running into internally is validation logic that cannot run client-side — business rules that reference data from other tables, check against external state, or need to complete before a Dataverse write is committed. That is exactly the /add-server-logic case: a server-side JavaScript endpoint that runs the check first, keeps any secrets out of the browser, and returns a clean result to the form. Describing that condition and getting generated code that already references your actual table names and schema cuts the build time significantly. That’s the first thing I’d point this at.

    The second would be secure external API calls where credentials cannot touch the browser at all. You describe the integration — what the endpoint expects, what you need back — and /add-server-logic generates an endpoint that already references your actual environment. That is a different kind of useful than autocomplete, and it removes a class of security mistake that comes from passing keys through the client.

    Where This Still Has Limits and What You Still Need to Know Yourself

    I want to be direct about this because I’ve seen the same pattern play out with AI-assisted flow building in Power Automate: faster to working and closer to production are not the same thing. Generated server-side code that looks correct can still have permission boundary issues, silent failures on edge case inputs, or endpoint logic that works on the happy path and throws an unhandled error when a value comes back null from Dataverse. The model generates against your environment, but it does not run your QA process.

    You still need to understand how Power Pages table permissions actually interact with Web API calls. You still need to know what a plugin execution context looks like and where it can fail. If you’re purely vibe building with generated code and no mental model of what’s running underneath, you’ll ship something that passes your own demo and fails on the first real user submission. This is the same problem that comes up when adding Copilot to a Power App gets treated as a shortcut around understanding what’s actually running under the surface. The same principle I keep coming back to on my own work applies here: the AI is the generation layer, you are still the verification layer.

    That said, for an automation developer who already understands the Power Pages architecture and just needs to move faster on the server-side code parts, this is genuinely useful. The ceiling for what one person can build without a dedicated dev team behind them has moved. I’ll be testing this on the next portal build that needs real server-side work, and I’m curious how much of the scaffolding holds up in practice.

    Frequently Asked Questions

    How do I generate server-side logic for Power Pages using AI?

    You can use the three new agentic code skills available through the Power Pages plugin, which work with tools like GitHub Copilot or Claude Code CLI. Unlike generic AI tools, these skills are grounded in your actual site environment, so the generated server-side endpoints, Cloud Flow connections, and backend integrations are written against your specific Dataverse schema and site structure rather than a generic example. Note that these three skills are designed for modern SPA-style Power Pages sites, not classic Liquid-based portals.

    What is the difference between Power Pages server-side logic and front-end configuration?

    Front-end configuration in Power Pages covers layouts, forms, and visual design handled through the studio. For modern SPA-style Power Pages, server-side logic refers to the layer underneath the client: JavaScript endpoints for validation and external calls, Cloud Flow integrations for backend automation, and connections to external systems. This layer is not configuration — it is code that requires environment-specific context to write correctly. This second layer requires actual coding knowledge and environment-specific context to get right.

    Do these Power Pages agentic code skills work with classic Liquid-based sites?

    No. The three new skills — /add-server-logic, /add-cloud-flow, and /integrate-backend — are designed for modern single-page application (SPA) Power Pages sites, not classic Liquid-templated portals. If your Power Pages work is primarily in the classic architecture, these skills do not apply to your current stack.

    When should I use AI-generated plugin logic in Power Pages instead of writing it manually?

    AI-generated plugin scaffolding is most useful when you need to enforce business rules on record creation or updates and want a working starting point built around your actual Dataverse tables. It reduces the time spent in documentation and removes the dependency on a dedicated development team for straightforward but environment-specific server-side requirements.

    This post was inspired by Build your server-side logic with AI: new Power Pages Agentic Code skills via Microsoft Power Platform Blog.