Vibe Coding Gets You a UI. Context Engineering Gets You a Product

There is a particular kind of optimism that arrives when an AI coding tool produces a decent-looking interface in under a minute.

You describe a dashboard. It gives you cards, gradients, a sidebar, responsive behaviour and just enough fake data to make it feel like you have accidentally become a ten-person product team.

It is genuinely useful. It is also where a lot of AI-assisted product building stalls.

A nice UI is not a product. It is an expensive-looking opinion about what a product might be.

The harder, and far more valuable, part is building a system where the interface, content, user data, business rules and customer communications all know about one another. That means going beyond giving an agent a clever prompt. It means giving it the context to make sensible decisions inside a real product.

I have been doing this while building Lets Talk Early Years, a Next.js platform, using Cursor and MCP connections across the stack. The biggest unlock has not been getting Cursor to make another page. It has been making sure the agent can understand the systems behind that page before it starts changing anything.

The Vibe Coding Plateau

Vibe coding is useful.

It is a brilliant way to explore an idea, test a flow, create a landing page, establish a visual direction or get past the blank-screen stage of building. You can go from “I have an idea” to “I can click around something” at a speed that would have felt mildly ridiculous a few years ago.

That matters, especially for founders. Momentum is not a vanity metric when you are trying to validate whether a problem is worth solving.

The issue starts when we mistake visible progress for product progress.

You ask an AI agent to create a resource library. It produces a beautiful grid of cards, category filters, individual resource pages and a download form. It may even throw in tasteful empty states, because apparently every AI coding tool now has strong opinions about empty states.

Then you ask basic operational questions:

• Where does the resource content live?
• What happens when a non-technical person needs to add a resource?
• How are categories managed?
• What data are we collecting when someone downloads something?
• Which audience or group should that person enter?
• What consent have they provided?
• What email do they receive?
• Which template is used?
• What happens if email delivery fails?
• How does the team know whether the resource is actually useful?

At this point, the shiny interface has done its job. It has made the real work impossible to ignore.

The agent was not necessarily wrong. It was responding to the information it had. If all you give it is a visual request, it will optimise for a visual outcome. It cannot reliably infer your data model, content operations, marketing workflows or business rules from a screenshot and a sentence.

That is not an AI problem. It is a context problem.

The Shift: Context Engineering

Prompting is telling an AI what you would like it to do.

Context engineering is making sure it has the information, access, constraints and feedback loops required to do the work properly.

This matters because software is rarely just software. A feature may touch a frontend application, a database, a CMS, an authentication system, analytics, email marketing, transactional communications, internal workflows and third-party APIs. A user experiences it as one journey. Your codebase experiences it as a group project with several participants and no obvious meeting notes.

For an AI coding agent to help meaningfully, it needs context across a few distinct layers.

Context layer	What the agent needs to understand	What happens without it
Product intent	The customer problem, user journey, business rules and desired outcome	It optimises for a completed-looking feature rather than a useful one
Codebase	Application structure, conventions, dependencies, auth patterns, tests and existing integrations	It creates isolated code that technically works but does not belong
Data model	Entities, relationships, permissions, validation and the source of truth	It invents fields, states and workflows that do not exist
Operational systems	CMS models, email templates, groups, automations, analytics and support workflows	It builds features that stop working as soon as they leave the browser
Guardrails	What the agent may inspect, propose, change, publish or send	It becomes very productive in places where productivity may be regrettable

This is the difference between asking an agent to “build a feature” and asking it to work inside a product system.

It is also the point where AI-assisted development becomes much more interesting.

What This Looks Like in Practice

While building Lets Talk Early Years in Next.js, I use Cursor as a development environment and connect the wider product stack through MCP.

MCP, or Model Context Protocol, is a standard that lets AI tools connect to external software and work with structured tools and data. In practical terms, it gives an agent a way to inspect systems that normally sit outside the repository: a CMS, an email platform, a database service, a project tracker or other operational tooling.

The interesting part is not simply that these systems can be connected. Plenty of integrations can claim that.

The interesting part is that the agent can understand the shape of the system before it starts proposing an implementation.

For a content-led product, that means giving the agent access to the actual places where content, audiences and communications are defined.

Contentful: The Content Is Part of the Product

A CMS is often treated as an afterthought until the first person asks, “Where do I edit that?”

In reality, the CMS model is part of the product architecture. It decides what content exists, which fields are required, how entries relate to each other, who can publish, what gets localised and what the frontend is allowed to expect.

With access to Contentful through MCP, an AI agent can inspect:

• Content types and their fields
• Validation rules and required values
• References between content entries
• Existing entries and content patterns
• Media and structured content
• Draft versus published state
• Locales, where relevant

That changes the quality of a request.

Instead of saying:

Build a resources section with title, description, category, image and downloadable file.

You can say:

Inspect the existing Contentful content models and propose the smallest change required to support downloadable resources. Reuse existing patterns where possible. Do not create or publish content entries without approval.

That is a much better brief because it has a relationship with reality.

The agent can see whether there is already a Resource, Article, Guide or Download model. It can identify the actual field names. It can understand whether categories are references, plain text, tags or something else entirely. It can build the frontend against the structure you already operate instead of inventing a parallel universe called resourceCategory, which only exists in one component and someone’s optimism.

Email Is Not a Postscript

The same applies to email.

A typical AI-generated flow looks something like this:

1. User submits a form.
2. The app displays “Thanks, check your inbox.”
3. A made-up function called sendEmail() appears somewhere.
4. Everyone agrees it is probably fine.

It is not necessarily fine.

In a real product, email has at least two separate jobs.

MailerLite may hold the marketing and lifecycle context: subscriber groups, custom fields, consent status, forms, campaigns and automation logic.

MailerSend may hold the transactional layer: emails that need to be delivered because a customer completed an action, requested something, created an account or reached a meaningful system state.

Keeping those roles clear makes a big difference.

A parent downloading an early-years guide might need a transactional email containing a direct download link. That is a delivery event. They may also have opted in to receive relevant resources, events or updates. That is a marketing preference and audience-management event.

They are related. They are not identical.

When an agent has read access to both systems, it can answer practical questions before writing the code:

• Does the MailerLite group already exist?
• What subscriber custom fields are available?
• Is consent stored and represented correctly?
• Is there already an automation for this audience?
• Which MailerSend template should deliver the resource?
• What dynamic variables does that template expect?
• Is the sender identity configured?
• Does the system already capture email events through webhooks?
• What should happen if the transactional email fails?

That is what I mean by giving the agent context. It does not mean throwing the keys to every service into Cursor and hoping for the best.

A Better Feature Brief

Take a common feature: adding a downloadable resource to a content platform.

A vague vibe-coding request might be:

Build a landing page for our downloadable guide. Add a form and email it to the user after they submit.

The output could be visually impressive. It may still leave you with an unmanageable collection of hand-wired logic, duplicated content, invented email fields and a customer journey that only works on the happy path.

A context-aware request looks more like this:

Create a downloadable-resource journey using the existing Next.js form
and server-side patterns.

First inspect:
- The relevant Contentful content model
- Existing MailerLite groups and subscriber fields
- Available MailerSend transactional templates

Use the current resource content shape rather than adding a new one unless
there is a clear gap.

On form submission:
- Capture consent separately from resource delivery
- Add the subscriber to the appropriate existing MailerLite group only when
  consent is present
- Use an approved MailerSend template for the delivery email
- Pass only supported template variables

Before making changes, provide an implementation plan with:
- Affected systems
- Assumptions
- Data flow
- Failure states
- Test coverage

Do not publish CMS entries, edit audience groups or send email without
explicit approval.

That is not a fancy prompt. It is a feature brief that recognises software as a connected system.

The agent now has a real job to do:

1. Inspect the Contentful model before designing data requirements.
2. Follow patterns already present in the Next.js codebase.
3. Identify whether the user journey creates a subscriber, a lead, an account or simply a download event.
4. Separate transactional communication from marketing consent.
5. Reuse the correct email template and supported merge variables.
6. Handle validation, retries, errors and observability.
7. Explain what it plans to change before it changes it.

This is where AI becomes significantly more useful than a very fast component generator.

Read First, Write Later

One of the best patterns for working with AI agents is simple: let them inspect broadly, but make consequential changes deliberately.

An agent should usually have enough access to answer questions such as:

• What does the current system look like?
• Where does this data live?
• Which template or group already exists?
• What conventions does the codebase use?
• What would this change affect?
• What needs to be tested?

That is read-oriented access. It grounds the agent in the product you actually have.

Write access is a separate decision.

Publishing a new Contentful entry, changing a content model, moving customers between groups, changing an automation, sending an email, editing a production domain or altering a production configuration should not be treated as a minor side effect of a development task.

The goal is not to make AI agents timid. It is to make their actions reviewable.

A practical split looks like this:

Agent capability	Default approach
Read code, documentation and tests	Allow
Inspect Contentful content models and existing entries	Allow
Inspect MailerLite groups, fields and automations	Allow
Inspect MailerSend templates and supported variables	Allow
Propose changes and generate code	Allow
Modify local code in a branch	Allow, with review
Create or publish CMS content	Require approval
Alter customer groups or automations	Require approval
Send a campaign or transactional message	Require approval
Change production settings, secrets or permissions	Require explicit, separate approval

The distinction may feel obvious. It is also easy to skip when the agent is moving quickly and the UI looks great.

Speed has a funny way of making governance sound boring right up until the moment you need it.

MCP Is Useful, Not Magical

MCP is valuable because it provides a standard way for AI tools to interact with external software rather than relying on disconnected prompts, screenshots or copied documentation.

It allows the agent to query systems that matter, use structured tools and work from the current state of the product.

But MCP is not the architecture.

It cannot decide whether your CMS is the right source of truth for a piece of data. It cannot define your consent policy. It does not know your commercial model unless you explain it. It will not automatically distinguish between a feature that looks complete and one that works across the entire customer journey.

Those remain product and engineering decisions.

MCP reduces the amount of guessing involved. It is useful connective tissue between an AI agent and the systems that make up your product. It does not remove the need to think clearly about how those systems should behave.

How to Get More From Your AI Agent

Before asking an AI tool to build a feature, work through this checklist.

Start With Customer Intent

Describe the customer, their problem, the action they need to take and the outcome they should receive.

“Build a guide download page” describes a screen.

“Help a parent find a relevant early-years guide, receive it reliably and choose whether to hear from us again” describes a customer journey.

The second version gives the agent a chance to make better implementation decisions.

Map the Systems Involved

List every system touched by the feature:

• Next.js frontend and backend
• Database and authentication layer
• Contentful content model
• MailerLite audience and consent handling
• MailerSend transactional delivery
• Analytics and event tracking
• Any CRM, payment or support tooling involved

If the feature crosses three systems, the implementation plan should say so. A neat pull request is not much use if it quietly breaks an automation on the other side of the stack.

Define the Source of Truth

For every important object, decide where it lives.

Where is the canonical record for a resource? Where is a user profile? Where is marketing consent stored? Where is an email template authored? Where are email-delivery events recorded?

If you cannot answer those questions, neither can the agent.

Ask for a Plan Before Code

A useful agent workflow should include a planning stage.

Ask it to return:

• Its understanding of the user journey
• The systems it expects to touch
• Assumptions it needs you to validate
• Proposed data flow
• Security and permission considerations
• Failure states
• Test plan
• The exact actions that require your approval

This takes a few extra minutes. It can save you hours of cleaning up code that solved the wrong problem with impressive confidence.

Turn Discoveries Into Durable Context

If the agent learns an important pattern, such as how forms work, how content is fetched, how email events are handled, how naming works or what cannot be changed, record it in project documentation.

AI coding sessions should not rely on you remembering every architectural decision at 1:30am while simultaneously wondering whether the error is in the webhook, the environment variable or your life choices.

Good documentation gives the next agent session a better starting point. More importantly, it gives future-you a chance.

The Actual Opportunity

The exciting part of AI-assisted development is not that it can generate another dashboard, pricing page or CRUD interface.

It is that a well-contextualised agent can help you reason across systems that normally require a lot of context switching: the codebase, CMS, marketing platform, transactional email service, data model and the customer journey that connects them.

That is where small teams can move much faster without defaulting to fragile builds.

Vibe coding is still worth doing. It gets ideas moving. It lowers the barrier to experimentation. It gives founders a faster way to test whether a product direction has legs.

Just do not stop at the point where the interface starts looking convincing.

Give your AI agent the codebase. Give it the content model. Let it inspect the email templates, groups and business rules. Tell it what the customer is trying to accomplish. Make it explain its plan. Keep meaningful write actions behind clear approvals.

Then you are not just asking an AI to make screens.

You are using it to help engineer a system.

Work With Me

AI can make product development feel much faster. That speed becomes genuinely useful when it is connected to a clear product strategy, trustworthy data and systems that hold together beyond the first demo.

If you are building an AI-enabled product and want help moving from an impressive prototype to a durable, customer-aware system, get in touch. I work across product strategy, AI-enabled workflows, technical architecture and the practical decisions that turn a promising idea into a product people can rely on.