Halilcan Soran

Tag: Agentic Coding

  • 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.