EPPC26 Session Recap — Charles Sexton

European Power Platform Conference, Copenhagen | Thursday, July 2, 2026 | Track: Power Apps | Level 300

Charles Sexton’s session carried a warning label from the start: two live demos, no safety net, “if it goes wrong, it goes wrong.” Both demos did go a bit wrong, in the way live conference demos do — and that turned out to be the most useful part of the session, because the failures illustrated exactly the distinction Sexton was building toward: the difference between vibe coding and agentic engineering, and why that difference should decide how much you trust what gets built.

Vibe Coding vs. Agentic Engineering

The framing: vibe coding is prompting an agent step by step, watching it generate code, caring about the end result rather than the code itself. Agentic engineering is different in kind, not degree — you build a workflow, a harness, for the agent to follow, so that by the time you reach the result you know what tests ran, what it did, and what it achieved. Vibe coding assumes it’s fine because it looks fine. Agentic engineering earns confidence through process.

Sexton’s take on Vibe Apps versus Code Apps cuts against the common assumption that one is “for coders” and the other “for everyone else.” He sees the real barrier as prerequisites, not skill: Code Apps need Node.js, Git, a coding agent, and a subscription — genuine setup friction — but once past that, the skill ceiling is enormous, from a ten-minute Microsoft-documented starter app to highly complex engineering. Vibe Apps, by contrast, tops out much lower: it’s Code Apps underneath (literally the same runtime, same React/web-app foundation), wrapped in an abstraction that makes it accessible but caps how far it can go. Code Apps is GA; Vibe Apps is still in preview — which, in his read, tells most of the story about where each one currently sits.

Demo One: What Vibe Apps Actually Hits Today

The live build was a session-feedback app for EPPC itself, styled to match the conference branding and populated from the conference programme. Two things broke immediately, and both were instructive:

It can’t reach the internet. Asked to pull branding or programme data from a live web page, Vibe Apps has no mechanism to do that — no file upload path either, at least not yet. It’s sandboxed inside its own framework, and Microsoft is expanding that boundary cautiously rather than all at once.

It refused an email action outright — no explanation given at first. Asking “why?” (Sexton’s favourite question to put to an AI) surfaced the real reason: no output connector was configured, though in earlier test runs of the same demo it had, at different times, cited a completely different reason — refusing to email a personal address, even though the address belonged to the presenter’s own tenant. The inconsistency itself was the point: a system in preview will give you a different failure mode on a different day, and you need to interrogate it rather than assume the first answer is the real constraint.

The broader limitation list he’d compiled: no NPM package installation, no real Git integration (you can pull code down locally but can’t push it back without creating a fresh app), no Copilot Studio or Power Automate integration yet, and no way to attach files after generation starts. His prediction — informed but explicitly speculative — was that Vibe Apps reaches general availability before the end of 2026, both because Microsoft doesn’t want to sit in preview too long given competitors like Lovable, and because every capability that lands in Code Apps eventually surfaces in Vibe Apps for free, since it’s built on the same runtime.

Demo Two: Building a Code App with a Harness, Not a Prompt

The second demo shifted from prompting to orchestration. Sexton had pre-built a specification: a database schema described in markdown (“the model really consumes markdown well”), a design contract generated by pointing the agent at the EPPC website and asking it to derive a matching visual language, and a set of custom skills — scaffolding tables, deploying code, adding a data source — built specifically because the official Power Platform CLI plugin, in his assessment, isn’t worth using as-is. It leans on Azure CLI and PowerShell in ways that fail silently on machines without those tools, and it was stuck on an outdated version because Microsoft hadn’t bumped its version number — a gap his own skill worked around by forcing a version check.

Once scaffolded, the build ran largely unsupervised — “I’m not prompting anymore, I’m just saying go off and do this task” — using a cheap, non-frontier model, deliberately, because a well-built harness compensates for a weaker model. That’s a deliberate inversion of the usual assumption that better output requires a better model. The session referenced Google’s own research reaching the same conclusion from a different angle: the same model, given a better harness, jumped from outside the top 30 to inside the top 5 on terminal-bench rankings. Harness quality outweighs model quality.

The finished app — a real EPPC feedback tool wired to Dataverse, rating actual sessions from the conference programme — took roughly an hour to generate against a proper specification, and looked, in his words, like “night and day” compared to the equivalent Vibe Apps attempt.

The Confidence Framework

Sexton’s central argument wasn’t really about Vibe Apps versus Code Apps — it was about how you earn trust in anything an agent builds, regardless of which tool produced it. His answer: it’s not about reading the generated code (there’s too much of it, and reading it all isn’t actually productive), it’s about building confidence through process:

  • Testing that passes or fails definitively.
  • Type checking and linting to catch structural problems early.
  • Evaluations for the non-deterministic parts, where pass/fail isn’t clean-cut.
  • A second agent auditing the first agent’s output — for security, performance, whatever matters — with results you can track over time.

He cited external research to temper the productivity-boost narrative around AI coding: a 25–39% productivity gain from vibe-style coding sounds compelling until you ask whether the result was ever properly tested, and one study found experienced developers up to 19% slower using agentic engineering on some tasks — not because the approach failed, but because building the verification harness around it takes real time. The trade being made is a higher upfront human cost in exchange for a lower ongoing AI cost and a result you can actually trust, rather than a fast result you have to hope holds up.

Two war stories anchored the risk side of this: a non-coder developer whose agent silently chose Python for a task, then failed because Python wasn’t installed on the machine — a failure mode invisible to someone who can’t read the error — and a general warning against installing skills and plugins blindly, including auto-updating ones that could turn malicious after the fact.

Practical Gotchas Worth Remembering

  • Images break silently in Code Apps unless sent through as text (Base64 for JPEG/PNG, raw for SVG) — dropping a file into an assets folder does not work the way you’d expect.
  • Always verify against the published, government-cloud URL, not just the local preview — behaviour can differ.
  • Write your own agent instructions rather than installing someone else’s wholesale. Read others’ published instructions for ideas, but authoring your own keeps you in control of what the agent actually does — and losing that control means losing the ability to trust the output.
  • Existing code is treated as your pattern. An agent extending a messy codebase will faithfully continue writing messy code, because it assumes that’s the style you want.

What to Take Away

  • Vibe Apps and Code Apps are the same platform at two different levels of abstraction — pick based on your prerequisites and how far you expect to need to go, not a coder/non-coder assumption.
  • A strong harness beats a strong model. Instructions, skills, tests, and audits matter more than which frontier model you point at the problem.
  • Confidence is manufactured through process — testing, linting, evaluation, and agent-driven auditing — not by reading through generated code line by line.
  • Preview software will fail differently each time you run it. Interrogate the failure (“why?”) rather than accepting the first explanation.
  • Trust is earned, not assumed — for the agent, and for whatever it hands you.

Session: “Vibe Apps and Code Apps: The Future of Power Platform Development” — EPPC26, Copenhagen, July 2, 2026
Presenter: Charles Sexton (Capgemini United Kingdom)