We need to talk about vibe coding.
The "AI is coming for your job" take is tired, I'm tired, and frankly, I just want to code. So why did I decide to write a blog post instead? Well, because I think we're all missing a trick with this whole paradigm that's come about where people basically flick Claude Code in autopilot and slop up their websites like nobodys business.
Vibe coding works. It works for a surprising amount of the job. We've watched people go from zero to a deployed Next.js site in a single afternoon using Cursor and v0. That's not hype. If you're a founder or a CTO reading this, you've probably already thought about whether your next project needs a dev team at all.
We think it does. But not for the reasons you'd expect.
The part that AI gets right
Give Claude or Cursor a design and ask it to build the frontend. You'll get something usable. Often something good. The layout will work, the responsive breakpoints will be sensible, the components will be structured reasonably. Tailwind CSS is basically designed for AI to write. Utility classes map directly to visual properties, and there's no ambiguity about what flex items-center justify-between p-4 means.
Navigation, hero sections, feature grids, testimonial carousels, footer layouts. AI handles all of this quickly, and well enough that you'd struggle to tell the difference between AI-generated markup and something a mid-level developer wrote.
v0 can generate entire page layouts from a prompt. Cursor can take a screenshot of a Figma design and produce a component that's 80-90% accurate. Bolt and Lovable are getting better monthly.
If all you need is a marketing site with a few static pages, we'll be honest: you might not need us. Or anyone. The tooling is that good for presentation-layer work.
Content isn't code, and AI doesn't know the difference
A website isn't just a frontend. It's a system. The moment you add a CMS (and you will, because nobody wants to redeploy every time they fix a typo), you've introduced a problem that AI consistently gets wrong.
Here's why.
A CMS isn't a database. It's an editorial interface backed by a data model. The schema you design determines what your content team sees, what they can do, and what they can't accidentally break. This isn't a technical problem. It's an information architecture problem wrapped inside a UX problem wrapped inside a "what does this organisation actually need" problem.
When you ask AI to "add a CMS" to your vibe-coded site, here's what you get:
Flat schemas that can't be reused
AI will create a blogPost type with a title, body, image, and publishedDate. It'll work. It'll also be completely isolated from every other content type on your site. Want to reuse the same author across blog posts and case studies? Want a shared rich text configuration? AI doesn't think about this because it doesn't know what your content team needs next quarter.
That second schema isn't just longer. It's connected. The person type gets reused on team pages and case studies. The richText definition enforces consistent formatting across every content type. The seo object standardises metadata so your marketing team doesn't have to remember which fields exist on which pages.
No page builder, no flexibility
The single biggest architectural decision in a CMS-powered website is whether you build a page builder. AI doesn't build page builders because it doesn't know they exist. It gives you fixed page templates: one schema per page type, one layout, no flexibility.
Three months later, your marketing team wants to add a testimonials section to the about page. Without a page builder, that's a code change. With one, it's a drag-and-drop operation in the studio. We've written an entire guide on this because it's the highest-value pattern we implement.
Editorial UX is invisible to AI
How should the sidebar be organised? Which document types belong together? Which fields need custom validation ("this URL slug can't contain uppercase characters")? What happens when an editor deletes an author who's referenced by 30 blog posts?
These decisions shape whether your content team actually uses the CMS or just emails someone to make changes for them. AI doesn't account for any of this. It has no context for how a content editor actually works day to day.
What the foundation actually means
When we talk about building the foundation, we don't mean writing your entire website. We mean the architectural decisions that everything else sits on top of.
1. Content model design
This is the big one. How many document types do you need? How do they reference each other? What's an array of objects vs. a reference to another document?
A good content model survives a redesign. A bad one needs to be rebuilt from scratch the moment requirements change.
2. Shared definitions
Rich text configurations, SEO fields, button objects, image fields with alt text and hotspot. You define these once and reuse them everywhere. When you change the rich text config, it changes across every content type simultaneously. AI will duplicate these definitions across every schema file, and within a month you'll be maintaining four slightly different versions of "rich text."
3. Page builder architecture
If your site needs one (most do), this is the backbone. You're deciding which block types exist, what their schemas look like, and how they compose. This is fiddly, opinionated work. It requires knowing what the content team needs today and anticipating what they'll ask for when they inevitably want a new section type.
4. Component architecture on the frontend
How do Sanity blocks map to React components? Where does the resolver pattern live? How do you handle preview mode and visual editing? The conventions you set here determine whether your next developer (or your AI tool) can add a new section in 30 minutes or wastes three days figuring it out.
5. Editorial workflow setup
Drafts, publishing, scheduling, roles, permissions. Which fields should be mandatory before publishing? Do you need content releases for coordinated launches? Does the sidebar make sense to someone who's never seen the codebase?
Then you vibe code the rest
Once the foundation is solid, AI becomes useful again.
When you ask Cursor to "create a new blog post page using the existing blog schema," it has context. It can see the types. It knows the query patterns. It generates a component that actually fetches data the right way, because the right way has already been defined.
When you ask Claude Code to "add a new page builder block for a pricing table," it can look at the existing blocks, follow the same patterns, and produce something that slots in without breaking the resolver. The conventions are already there. The AI just follows them.
This is the part nobody talks about: AI is excellent at pattern-matching existing conventions. It's terrible at establishing them.
That's the principle behind our agentic workflows service. Lock in the conventions, then let it rip. We took this far enough to build our own background agent that autonomously handles routine tickets — the kind of work that only works because the conventions already exist.
Here's what we've seen teams successfully vibe code on top of a proper foundation:
- New page templates. Once the page builder exists, new pages are composition, not architecture.
- Individual components: cards, CTAs, feature sections, testimonial grids
- Styling and animations, where Tailwind and Motion play to AI's strengths
- API integrations like contact forms and newsletter signups
- Content pages, converting a brief into MDX or structured content with the right frontmatter
And here's what they shouldn't touch:
- Schema changes that affect data relationships
- New document types that need to integrate with existing references
- Migration scripts for restructuring live content
- Changes to editorial workflows or permissions
- Performance-critical data fetching patterns
The economics
A full agency build for a marketing website with CMS typically runs three weeks to three months depending on scope. You're paying for design, content modelling, frontend development, CMS configuration, and launch support.
A foundation-only engagement is a fraction of that. Content model, shared definitions, page builder setup, component conventions, editorial workflow. One to two weeks of focused work. Our Sanity & Next.js Accelerator is built for exactly this.
After that, you've got a codebase that AI tools can actually work with. Your team can iterate on the frontend using Cursor or v0. New pages are afternoon projects, not week-long sprints. And when you do need specialist help, it's for specific problems, not "we need to rebuild the whole thing because the schema is a mess."
The alternative? Build everything with AI, hit a wall at month three when your content team can't edit anything without a developer, then hire an agency to redo the architecture anyway. We've taken on three of those projects in the last six months. The rework always costs more than the foundation would have.
A real example
One of our recent clients came to us after building their marketing site entirely with Cursor. The frontend looked good. Actually good. The design was sharp, the components were clean, the site performed well.
The CMS was a different story. They'd used Sanity (good choice), but every page type had its own isolated schema with duplicated field definitions. There were four different "rich text" configurations, none of which matched. The blog had no author references, just a string field with the author's name typed in manually. No page builder either, so every new marketing page required a developer to create a new template.
Their content manager was spending roughly two hours a day on tasks that should have taken 15 minutes. When they wanted to add a case studies section, the estimate was two weeks of development because nothing in the existing architecture supported reusable content types.
We rebuilt just the foundation. New content models with shared definitions, a page builder with 12 block types, proper author and category references, a studio configuration that grouped content logically. The frontend components mostly survived. We rewired them to the new schema and added the block resolver.
Total time: eight days. Their content manager's daily CMS workflow dropped to 20 minutes. And their dev team (one developer using Cursor) added three new page types in the following two weeks without touching the schema at all.
No spam, only good stuff
Subscribe, for more hot takes
What about next year?
AI is improving fast. Will it eventually design a proper content model? Probably. Will it understand editorial workflows intuitively? Maybe. Anthropic's Claude is already very good at reading Sanity schemas and generating consistent extensions. We use it daily.
But "eventually" isn't "today." The websites you build today need to work today. They need content teams who can publish without a developer. They need schemas that survive the next three feature requests. They need architectural decisions that were made with intent, not generated on a best guess.
The smart bet right now: know which parts of the stack benefit from expertise and which parts benefit from speed. The foundation needs expertise. The rest can be fast.
What to look for in a foundation partner
If this model appeals to you, here's what matters.
CMS expertise, not just "we can set it up." You want a team that's built enough content models to know which patterns break at scale. Ask them about page builders, shared definitions, and how they handle schema migrations.
A handoff that actually works. The whole point is that your team takes over after the foundation is set. That means documentation, conventions that are obvious from the codebase, and types that your AI tools can read.
Schema-as-code. If your CMS stores the schema in a GUI, AI tools can't read it. Sanity's schema-as-code approach is specifically why it works well with vibe coding. The schema lives in TypeScript files that Cursor and Claude can parse natively.
No vendor lock-in on the agency itself. If you need to bring in a different team later, the foundation should be self-explanatory. Good architecture doesn't need a glossary.
So where does that leave you?
Vibe coding is real, and pretending it isn't helps nobody. AI tools can build production-quality frontend code. Dismissing that is as foolish as trusting it blindly.
The gap is the invisible architecture underneath: content models, editorial workflows, shared definitions, page builder patterns. The stuff that determines whether your site works for your team or against them. The stuff that compounds.
Build the foundation with someone who's done it before. Vibe code the rest.
We've been building these foundations on Sanity and Next.js for years. If you want a proper headless CMS architecture that AI tools can actually extend, not fight against, get in touch.