Vibe Coding with Agility

Vibe coding is building a working site by describing what you want to an AI coding tool and steering it, instead of writing every line yourself. With Agility, the AI tool does more than write front-end code: through the Agility CMS MCP server it can also create the content models, containers, component models and seed content the site needs, in a real instance your editors can use.

This section shows how to do that well: how to go from a brief to a working, editable, previewable Agility site in a day or two, what to write down so the AI tool doesn't repeat its mistakes, and what to fix before anything you build this way goes to production.

Why build per use case instead of starting from a generic starter

For years the fastest way to stand up an Agility site was to clone a starter that already did most of what you needed. That approach ages badly. Our older Conference and Commerce starters each solved one imagined use case, and every real project spent its first days removing what didn't fit. The Commerce starter has since been archived.

With an AI coding tool and the MCP server, it's now faster to build the site for the specific use case in front of you:

The content model fits the brief. You model the content this project needs, not the content a starter's author guessed at. There's nothing to delete.
The demo uses real content. The AI tool can import a prospect's or project's public content into your models, so the site looks like theirs from the first preview.
Plumbing is the part you reuse. Data fetching with cache tags, routing, preview, the revalidation webhook and the component registry are the same on every project. Start from the Agility Next.js Starter or from your own closest previous build, keep that plumbing, and rebuild only the layer that's specific to this project.
Your instructions improve with every build. An AGENTS.md that records conventions, IDs and gotchas carries forward from project to project, so each build starts with what the last one learned.

The starter still matters, as an engine rather than a template. You keep its wiring and throw away its sample content model.

What you need

You need	Why
An AI coding tool	Claude Code, Cursor, GitHub Copilot, Codex, Windsurf or any tool that reads a project instruction file and supports MCP.
The Agility CMS MCP server	Lets the AI tool read and create models, containers, content, pages and media in your instance, with your own permissions.
The Agility Knowledgebase MCP server	Lets the AI tool search these docs instead of guessing at SDK and API details.
An `AGENTS.md`	Tells the AI tool the conventions it can't discover from your code. See Writing an AGENTS.md for Agility Projects.
A blank or trial Agility instance	A clean place to model and seed content, with API keys and a sitemap set up by a person.
A host such as Vercel	So preview, Web Studio and the publish webhook work against a real URL, not just `localhost`.

The setup for the two MCP servers, the starter and a base AGENTS.md is in Building an Agility Site with AI Coding Tools. Start there if you haven't connected the servers yet.

What the evidence shows

This approach comes from practice. An Agility solutions engineer uses it to build customer proofs of concept, and we reviewed those builds to write this section. Across 18 proof-of-concepts built in 2025 and 2026, spanning manufacturing, financial services, government, higher education, membership associations, charities, events, real estate, an enterprise intranet and in-store digital signage:

The median time from first to last commit was about a day and a half. Five builds were committed within a single day, nine within two days and thirteen within a week.
Core site code usually landed in one working session. Measured from first to last code commit, examples include about an hour and a half, about three and a half hours and about six hours.
The longest histories (several weeks) were not build time. They were later demo rounds and post-sale documents, and the core builds inside them took one to two days.
Nearly every build used the full Agility loop. The MCP server for schema and content, preview, Web Studio in-context editing and a publish webhook for on-demand revalidation each appear in at least 17 of the 19 repositories we reviewed (the 18 builds plus the shared engine most of them copy).

Read these numbers for what they are: commit history from proof-of-concept repositories, not a benchmark and not a promise. Commit history also understates some effort. Several repositories were committed as a single import, and every build inherited plumbing that took far longer to develop in the first place. Your first build will take longer than your fifth.

When not to vibe code a site

A vibe-coded proof of concept is a working site, not a production site. Don't ship one as-is when:

It will take real traffic or real data. Proofs of concept routinely skip webhook signature checks, tests, monitoring and accessibility review. From Proof of Concept to Production lists what to restore.
Requirements are mostly non-functional. SSO, encryption, audit and data residency can be demonstrated or described in a proof of concept, but not proven by one.
No one will own the code. AI-written code still needs a developer who understands it, reviews it and maintains it.
The content model is the real deliverable. A model sketched in an afternoon is a good first draft. A model for a large organization deserves review by the people who will edit in it every day.

In this section

Vibe Coding with Agility (this article): what it is, why it beats a generic starter, and when not to use it.
Building an Agility Site with AI Coding Tools: connect both MCP servers, extend the starter's AGENTS.md, and build your first component end to end.
From Brief to Working Site: The Vibe Coding Workflow: the step-by-step workflow, with typical times and prompts.
Writing an AGENTS.md for Agility Projects: the conventions that make each build faster than the last.
MCP and Agility Gotchas to Know Before You Build: the silent failures that cost the most time.
Vibe Coding Playbooks by Use Case: content model ideas and starter prompts for ten common use cases.
From Proof of Concept to Production: what a proof of concept skips that production needs.