Vibe Coding Dynamics 365: The One-Day PCF Build Is Real. The Risk Moved.

A PCF control that took a week in 2022 now takes an afternoon. That is not hype. I ship free Power Apps components built AI-first, with a written AI development playbook, and the speed gain on model-driven app custom UI is real and repeatable.

So when people ask whether vibe coding Dynamics 365 customizations is safe, they are asking the wrong question. The economics changed. The accountability did not. The AI writes the control. It cannot own the Dataverse security model, the solution layering strategy, performance against real data volumes, or survival of the next release wave. Those are exactly where AI-built CRM work dies in production.

Speed is solved. Safety is the open problem, and it belongs to a human.

What the AI genuinely nails

Give credit where it is earned, because the critique later only lands if this part is honest.

AI coding agents are excellent at PCF scaffolding, React plus Fluent UI composition, TypeScript boilerplate, and unit test scaffolds. They iterate on visual polish faster than any human can type. Ask for a virtual control with a Fluent UI DetailsList, keyboard navigation, and a loading skeleton, and you get something plausible in minutes, not days.

There is a structural reason for this. The AI is strongest at code that looks like public GitHub, and PCF code mostly does. React components, TypeScript interfaces, Jest tests. These patterns exist in the training data millions of times. The model is pattern-matching against an enormous corpus of code that looks almost exactly like what you need.

My own published controls, FieldAuditHistory, AccessLens, and a config-driven suite of three controls with a public release history anyone can scroll through, were all built this way. The component code, the typing part, was never the bottleneck.

For the typing, the AI is a genuinely strong pair. The bottleneck moved somewhere else entirely.

Where unsupervised vibe coding quietly fails on Dataverse

This is the heart of it. Every failure mode below shares one property: the control demos perfectly. A vibe coded CRM build fails silently, and the failure arrives at go-live or at the next wave, not in the sprint review.

Unsupported customizations

The supportability line in model-driven apps is precise, and the AI does not know where it is. Manipulating the DOM inside your own PCF container is supported. Reaching outside that container to the host form, the grid markup, or Microsoft’s internal objects is not, and Microsoft’s supported customizations documentation makes clear that anything outside the documented Client API surface carries no backward-compatibility guarantee.

An AI agent trying to make your error go away will happily query the host page with a document selector, hide a ribbon button by class name, or call an undocumented internal method it found in a Stack Overflow answer from 2019. It works today. Then Microsoft ships one of its two release waves per year, wave 1 covering April through September and wave 2 covering October through March, the rendered markup changes, and your control breaks in production with no code change on your side. Continuous updates between waves can do the same thing.

Security shortcuts

The AI grants whatever privilege makes the error disappear. It does not reason about least privilege, column-level security profiles, or who is actually permitted to see the data the control surfaces. I have watched agents hardcode a GUID that bypasses record-level filtering, over-fetch with retrieveMultipleRecords and filter client-side, and assign user-controlled strings to innerHTML, which is a DOM-based XSS waiting for a payload.

Effective access in Dataverse is genuinely hard to see. It is the composite of security roles, teams, business units, sharing, and field security profiles, and almost nobody can answer “what can this user actually see on this form” from memory. That is why I built AccessLens, a free PCF control that shows effective access inline. The tool class exists because the problem is real, and an AI agent has zero visibility into it. I went deeper on this in Can You Trust AI With Dataverse Security?, where three of four plausible designs turn out to be wrong.

ALM blindness

The AI has no concept of application lifecycle management. It ships to whatever environment it is pointed at, in an unmanaged solution, under the default publisher. The default publisher decision alone has irreversible consequences for prefixes and option values, and Microsoft’s solution concepts documentation is blunt that unmanaged solutions are for development, not deployment. None of that context exists in the prompt unless a human puts it there, and layering conflicts do not announce themselves until the second solution lands on top of the first.

Performance assumptions

The control works beautifully on 50 dev records. The AI omits destroy() cleanup and leaks memory on every form navigation. It forgets to declare feature-usage for the APIs it calls, which fails at runtime rather than build time. It ships a debug-mode bundle. And it never asks what the query costs at volume.

Illustrative scenario, not a measurement: an audit-history query against a high-churn record in an environment where the audit table has grown for five years behaves nothing like the same query in a two-week-old dev org. Total audit volume and per-record churn drive that, not row count in the primary table. The AI tested neither, because its environment had neither.

Everything above demos fine. That is precisely the problem.

The architect’s job did not shrink. It moved.

The unit of senior work used to be the implementation. Now it is the decision. The architect owns what the AI structurally cannot see: the data access and security model, the solution layering and ALM pipeline, performance against production volumes, the supportability and audit story, and release-wave exposure.

I will take the strong position: this is a promotion of the role, not a threat to it. Reviewing AI output at this level is harder than writing the code was, because the code looks correct. Spotting a working control that violates least privilege or depends on unsupported markup requires exactly the judgment that made someone an architect in the first place.

The practitioner caveat: the docs describe the happy path for PCF deployment, but in production the hard questions are layering order, dependencies, and who owns this control in two years when the person who prompted it into existence has left. I wrote about structuring that upstream work in turning ADO work items into specs any AI agent can build from, because the spec is where the architect’s decisions get encoded before the agent types a line.

The architect’s unit of work is now the decision, not the line of code.

Anatomy of a one-day build

Here is how the day actually splits. This table is illustrative, a realistic shape of a typical build based on how I work, not a measured benchmark. Calibrate against your own team; actuals vary.

The pattern is the story. The AI does most of the typing. The human spends most of their attention on the last 20 percent that decides whether it ships.

FieldAuditHistory, one of my published free controls, is a concrete example. Dynamics 365 audit history lives behind the Related menu by default, a full navigation away from the field you are looking at. The control surfaces field-level change history inline on the form: a quick peek, a deep dive, a status indicator. Microsoft’s Dataverse auditing documentation covers the mechanics, and the AI wrote most of the component code.

But the decisions were human. Which audit API to use and why. Lazy loading so a form with twenty audited fields does not fire twenty queries on load. Respecting the View Audit History privilege so the control never shows a user data the platform would have denied them through the standard path. Graceful degradation when audited metadata has been renamed or deleted. None of that came from a prompt. All of it came from a review.

The day is real. The split of the day is the story.

The pre-ship checklist

Call these PCF best practices under AI speed. If the agent built the control in four hours, you can afford two hours of this list. Run it before anything leaves dev.

If the AI built it in four hours, two hours of this list is the cheapest insurance you will ever buy.

Cheaper code changes the economics, not the accountability

Vibe coding Dynamics 365 collapsed the implementation cost of a custom control to a fraction of what it was. That does not shrink the architecture work. It concentrates it. When the typing is nearly free, the entire value of the work lives in the decisions around it: security, layering, performance, supportability, and surviving the next wave.

The organizations that win treat AI as a force multiplier under architectural governance. The ones that get burned treat a passing demo of a vibe coded CRM control as proof it is done. The control was never the hard part. It just used to take long enough that we confused it for one.

If your pre-ship list differs from mine, I want to see it. The checklist above is what my own public controls go through, and it gets sharper every time someone argues with an item.