Vibe Coder to AI Engineer: Lessons for Umbraco Delivery with Claude Code

From a funny demo to a serious Umbraco lesson

Vibe coding in Umbraco is fast, risky, and expensive without context. The safer path is AI engineering: give Claude Code project knowledge, ask it to plan before it edits, split guidance into lean files, and wrap MCP or CLI tools with review gates.

Matthew Wise’s “Vibe Coder to AI Engineer: From Designs to Umbraco (and Everything In Between)” session took that idea out of theory. The talk followed a real path from Figma-style design work into a CMS-managed Umbraco build using Claude Code, context engineering, MCP servers, sub-agents, custom commands, and skills.

The best part was the honesty. Claude failed. SVGs went wrong. A live demo returned nothing. Content models improved, but not by magic. The lesson for enterprise Umbraco delivery is useful: better AI models help, but better engineering habits decide whether the output is safe to ship.

What changes a Vibe Coder into an AI Engineer?

A Vibe Coder asks an AI agent to build and then reacts to the result. An AI Engineer designs the working conditions before asking the agent to act.

In Umbraco, that difference affects the whole delivery path.

The difference is governance. For an enterprise CMS estate, governance is not paperwork. It protects editor experience, data links, release reliability, and future upgrade paths.

Lesson 1: Context beats longer prompts

The transcript gives a useful example. A broad agent init file used about 820 memory tokens. After splitting project guidance into smaller files, the base load dropped to about 180 tokens. After the agent pulled in extra files for the task, it rose to about 450. The run also took less time and used roughly 2,000 fewer tokens.

That number is small enough to sound trivial. At the portfolio level, it adds up. Every repeated instruction costs money, adds attention load, and increases the chance that the agent acts on the wrong part of the project.

For Umbraco, split context by area:

• /cms-guidance.md for document types, compositions, block lists, URLs, and editor rules.

• /frontend-guidance.md for Next.js, rendering, caching, styling, and data contracts.

• /integration-guidance.md for APIs, identity, search, CRM, ERP, payments, or other linked platforms.

• /release-guidance.md for CI, environments, approvals, rollback, and monitoring.

Keep the top-level file short. Tell the agent what the project is, which Umbraco version it uses, where the guidance lives, and what it must read before touching the CMS structure.

Lesson 2: Plan before changing Umbraco

CMS modelling is a poor place for trial and error. A weak document type can annoy editors for years. A bad alias can make migrations harder. A block design that works for a demo may fail once marketing, legal, support, and regional teams start using it.

A useful Umbraco AI plan should answer:

1. Which document types are needed?

2. Which fields belong in reusable compositions?

3. Which items should be element types rather than pages?

4. Which blocks need rich text, media, links, validation, or variants?

5. Where do settings, SEO fields, and global content belong?

6. Which existing types can be reused?

7. Which changes need a dry run before apply?

Ask Claude Code to produce the model first. Review it with an Umbraco developer and an editor. Only then let the agent create or change files, call a CLI, or use MCP.

Lesson 3: Skills make senior judgement reusable

Agent skills are useful because they package instructions, metadata, examples, and optional scripts into a reusable unit. In practice, a skill lets senior Umbraco knowledge travel with the task.

A content modelling skill can tell the agent:

• Use compositions for repeated fields such as SEO, teaser copy, metadata, and publishing options.

• Use element types for reusable blocks that should not become pages.

• Use link pickers or URL pickers instead of plain text fields for links.

• Use sort-order gaps such as 10, 20, and 30 so future fields can be inserted cleanly.

• Check existing aliases and GUIDs before creating new ones.

• Ask before applying structural CMS changes.

That is different from pasting a long rulebook into every prompt. The skill is loaded only when the task calls for it. The result is less context waste and better repeatability.

Lesson 4: MCP and CLI both need guardrails

MCP gives an AI agent structured access to tools and project data. A CLI can be lighter because it runs a command only when called. Both can help Umbraco developers, especially with content modelling, code inspection, repetitive back-office tasks, and validation.

They carry different risks.

MCP can keep a rich connection open, which is useful for agent-native work. It can also add token cost and local runtime care. A CLI can be easier for dry runs and one-off checks, but the agent must know that the CLI exists and how to use it safely.

For enterprise delivery, write the guardrails before granting access:

• Read current Umbraco types before creating anything.

• Use dry run or plan mode for structural changes.

• Never create or alter production content without approval.

• Record what changed, why, and how to roll it back.

• Run tests and compile checks before pull request review.

• Apply least privilege to API users, MCP access, and local credentials.

Why enterprise buyers should care

Stack Overflow’s 2025 Developer Survey reported that 84% of respondents use or plan to use AI tools in development, and 51% of professional developers use them daily. DORA’s 2025 AI-assisted software development research found that AI amplifies existing engineering quality. In plain terms: AI helps disciplined delivery groups more than chaotic ones.

For a public body, health provider, bank, university, or multi-region enterprise, AI-assisted Umbraco work must fit the same engineering bar as any other delivery method.

That includes GDPR, ISO 27001-style requirements, HIPAA or SOC 2 assurance where relevant, SSO, MFA, least privilege, audit logs, secure coding, peer review, CI checks, staged releases, observability, HA, DR, documentation, and SLAs.

Start by tracking numbers,

• Lead time from ticket to reviewed plan.

• Token use per work type.

• Compile failure rate from AI-assisted code.

• Pull request review comments by category.

• Release frequency and rollback rate.

• MTTR for CMS incidents.

• Editor support tickets after content model changes.

These numbers tell you whether AI is reducing delivery effort or creating rework.

A practical Umbraco AI workflow

1. Write the ticket as an engineering brief.
   Include user need, Umbraco version, content ownership, environments, linked platforms, and acceptance tests. A vague prompt invites invention.

2. Ask for a plan, not code.
   Require a proposed content model, file changes, risks, open questions, and dry-run commands. Review the plan before any write action.

3. Use version-aware docs.
   Umbraco 17 is the current active LTS version, with support stated until 27 November 2028. Agents should read the correct docs for the version in use.

4. Wrap MCP or CLI in a skill.
   Tell the agent what it may read, what it may write, and which actions require approval. Keep credentials scoped and logged.

5. Treat AI output like junior code from a fast colleague.
   Compile it. Test it. Review it. Ask why each document type, alias, block, and integration point exists.

AI-assisted Umbraco delivery works best when project knowledge, tool access, review, and release discipline are designed together.

Phases is an Umbraco Gold Contributing Partner with delivery experience across Denmark, India, the USA, public bodies, and large private organisations. If your team is testing Claude Code, MCP, agent skills, or AI-assisted CMS modelling, book a 45-minute review with a senior Phases.io Umbraco engineer.

We can review one backlog item, one content model, and one release path. You will receive a short risk note, recommended guardrails, and a first 90-day action list for safer AI-assisted Umbraco delivery.

 Book a Meeting with an Umbraco Partner