Cursor AI and vibe coding: build your MVP without being a senior dev

Table of Contents

• Quick summary: what you need to know about Cursor
• What vibe coding is (and what it isn't)

  • Vibe coding and Lean Startup: build less, validate first
• How to set up Cursor to work well

  • The ways to work with the AI
  • Managing context: the skill with the biggest payoff
• Project rules: AGENTS.md and .cursor/rules

  • .mdc rules in .cursor/rules/
  • AGENTS.md: the project's general rules
  • Three golden rules for writing good directives
• Case study: from idea to an MVP in production

  • Step 1: write a one-page PRD
  • Step 2: build the scaffold
  • Step 3: connect the services
  • Step 4: debug, version and deploy
• The risks nobody tells you about
• Cursor pricing in 2026: the October change

  • How to think about the cost
• What really changes for founders in Latin America
• Before you write your first prompt

Cursor AI is a code editor with built-in AI agents that lets you build an application by describing what you want in plain language while the agent writes, edits and fixes the code. Combined with vibe coding —steering the AI through conversation instead of writing every line— a non-technical founder can go from an idea to an MVP in production in days, not months.

Now the fine print: the hard part is no longer syntax. It's knowing what to ask for, how to give the AI the right context and how to review what it hands back. That's what this guide covers: the philosophy, the setup that prevents spaghetti code, a step-by-step case study, what Cursor costs after the October 2026 plan change, and the risks almost nobody mentions.

Quick summary: what you need to know about Cursor

Concept	What it is	What it's for
Agent (with Composer 2)	The main mode: plans and edits several files from one instruction. Composer 2 is Cursor's own model.	Building screens, logic and configuration without writing code by hand.
Inline edit (Cmd/Ctrl + K)	Targeted changes to the code or command you select.	Tweaking a component without touching the rest of the file.
Project rules	.mdc files in .cursor/rules/ and an AGENTS.md at the root.	Making the AI respect your stack, design and bans in every session.
Context (@-mentions and .cursorignore)	You tell the agent which files and docs to read, and which to ignore.	Fewer hallucinations, less usage and more precise answers.
2026 plans	Free, Plus ($8), Premium ($30), Super ($100) and Ultra ($200) per month.	Choosing based on your project stage and the models you need.

What vibe coding is (and what it isn't)

The term vibe coding was popularized by Andrej Karpathy —OpenAI co-founder and former director of AI at Tesla— in early 2025. He described a way of programming where you "give in to the vibes": you talk to the model, accept its changes and almost forget the code exists.

For a non-technical founder, the useful idea is a more disciplined one: the critical skill stops being syntax and becomes structuring requirements. If you can clearly explain what problem you solve, for whom, what happens on each screen and what data gets stored, the AI does the work of turning it into code.

That changes three concrete things:

• The cost of the first version. What used to be a months-long agency quote can now be a monthly subscription plus your time. Careful: your time still costs money, and not a little.
• How fast you can test hypotheses. A prototype can be in front of real users within days, which is exactly what you need to find out whether the idea is worth it.
• Your role. You go from "the person who writes the code" to something closer to product and architecture: you decide what gets built, in what order and to what quality bar.

What it is not: a way to build without understanding anything. Pure vibe coding works for weekend prototypes. For something that will have users, payments or personal data, you need to understand —even if you don't write it— how it's put together.

Vibe coding and Lean Startup: build less, validate first

One of the most common reasons startups fail is building on unvalidated assumptions. Vibe coding doesn't fix that; it makes it cheaper to correct. If an MVP takes days instead of months, you can launch, measure and change course without burning through your cash.

Order still matters: hypothesis first, code second. Before you open Cursor, it's worth validating the idea in a week and grounding the model in a Business Model Canvas. If you don't know who pays and why, the AI only helps you build something nobody wants, faster.

How to set up Cursor to work well

Cursor is a fork of VS Code: it looks the same and keeps your extensions and shortcuts, but puts AI at the center of the editor. If you've never used VS Code, the learning curve is an afternoon.

The ways to work with the AI

1. Agent. The mode you'll use most. You give it a task ("add a pricing page with three plans") and the agent reads the project, proposes a plan, edits several files and can run commands in the terminal. You can decide whether each change needs your approval or whether it applies them directly; when you're starting out, approve change by change.
2. Plan or ask mode. Before a big change, ask it to analyze and propose without touching files: "explain how the user sign-up flow works" or "which files would need to change to add subscriptions?". It's the best way to learn your own project.
3. Inline edit (Cmd/Ctrl + K). You select a block and ask for a specific change. Ideal for touch-ups without risking the rest of the file.
4. AI in the terminal. You describe what you want to do ("install the dependencies and run the migration") and get the command. Read what it does before running it, especially if it deletes or overwrites something.

As for models, Cursor lets you choose between its own model, Composer 2 (released in March 2026, fast and cheap for editing code), and third-party models like Claude or GPT, depending on your plan. If you want to understand the differences between model families, I have a guide to Claude models in 2026.

Managing context: the skill with the biggest payoff

Models work with a limited context window: what fits in their memory during the conversation. Fill it with irrelevant files and the model gets confused and invents things that don't exist in your code. Give it too little and it guesses.

How to give it just the right context:

• @-mentions. With @ you point to exactly what it should read: a specific file, a folder (for example /components) or a library's official docs. Much better than letting it search the whole project on its own.
• Short, task-based conversations. One conversation per feature. When a session runs long and starts contradicting itself, open a new one and summarize what matters.
• .cursorignore. A file at the root, with the same syntax as .gitignore, so the AI doesn't read heavy files, local data, logs or files with secrets. It saves usage and lowers the risk of a key ending up in a conversation.
• GitHub from day one. Connect the project to a repository. It gives you history to roll back when the AI breaks something (it will) and guarantees the code is yours, not the tool's.

Project rules: AGENTS.md and .cursor/rules

Without rules, the AI improvises: it mixes libraries, changes style from one file to the next and repeats mistakes you already fixed. Rules are persistent instructions the agent reads every session, so you don't have to repeat them.

.mdc rules in .cursor/rules/

Cursor's own format is .mdc files inside .cursor/rules/. Each has a header that defines when it applies: always (alwaysApply: true), only when you work with certain files (globs), or when the agent decides it's relevant based on the description. The old single .cursorrules file is now a legacy format.

Example, .cursor/rules/frontend.mdc:

---
description: Frontend component and styling standards
globs: "src/components/**/*.tsx"
alwaysApply: false
---

# Frontend

1. Use React function components with Tailwind CSS. No inline styles.
2. For UI components, use shadcn/ui first before creating a new one.
3. Local state with React hooks; data mutations with Server Actions.
4. Never put API keys or tokens in code that runs in the browser.

Note one detail: if a rule has globs, you normally set alwaysApply: false so it only activates with those files. If you set both, the rule always applies and globs stops mattering.

AGENTS.md: the project's general rules

AGENTS.md is a regular Markdown file at the root of the repository. It has no header and no conditions: everything you write applies. Its advantage is that it's an open standard, so other agents like Claude Code or Codex read it too; if you switch tools tomorrow, your rules come with you.

	.mdc rules	AGENTS.md
Where it lives	.cursor/rules/*.mdc	Project root (and subfolders, if you want)
When it applies	Depending on its header: always, by file, or by relevance	Always, in full
Who reads it	Cursor only	Cursor and other compatible agents
Use it for	Rules specific to one part of the code	What the project is, the stack, how it's tested and what's banned

A split that works: AGENTS.md for the big picture (what the app does, stack, commands, rules that apply everywhere) and .mdc for rules that only apply to one folder or file type.

Three golden rules for writing good directives

1. Concrete facts, not wishes. "Write clean code" tells the model nothing. "The users table is public.profiles and is joined by user_id" does: it forces the model to work on your real architecture instead of inventing one.
2. Explicit bans. Say what's off-limits: "don't install new libraries without asking", "don't use inline styles", "don't modify migrations that have already run". Clear bans prevent more mistakes than vague recommendations.
3. Straight-to-the-point answers. Ask it to give the code or command first and the explanation afterwards, if needed. It saves time and usage.

If you want to take this further —writing the specification before the code— Spec-Driven Development is exactly that discipline applied to agents.

Case study: from idea to an MVP in production

The path is always the same: specification → scaffold → integrations → deployment. What changes is how much time you spend on each stage.

Step 1: write a one-page PRD

Before asking for a single line of code, write a product requirements document (PRD) in a PRD.md file inside the project. It doesn't need to be long: what problem you solve, for whom, what version 1 does and, very importantly, what it does not do yet.

Also include the events you'll track. If you don't define them up front, later you won't know whether the product works. A base list for a SaaS:

• signed_up: signed up.
• onboarding_completed: finished the initial flow.
• created_first_project: got the first real value from the product.
• invited_teammate: invited someone.
• hit_plan_limit: reached the free plan limit.
• subscription_started: started paying.
• payment_failed: a charge failed.
• cancelled: cancelled.

With the PRD ready, the agent has a source of truth you can mention with @PRD.md in every task.

Step 2: build the scaffold

A very common, well-documented stack that models know inside out:

• Next.js (React framework for production),
• Tailwind CSS (styling with utility classes),
• shadcn/ui (accessible UI components you copy into your project).

The model knowing it well is no small detail: the more popular the stack, the less the AI makes things up.

Example prompt for the agent:

Read @PRD.md. Propose a plan to initialize a Next.js project with App Router, TypeScript, Tailwind CSS and shadcn/ui, with the code inside /src and a navigation bar in the main layout. Don't run anything until I approve the plan.

That last sentence matters: plan first, execution second. Reviewing a plan takes two minutes; undoing twenty badly created files takes an afternoon.

Step 3: connect the services

One integration per session, testing each one before moving to the next:

• Authentication. Supabase Auth if you already use Supabase, or Clerk if you want sign-up and login with Google or GitHub almost ready to go.
• Database. Supabase (managed PostgreSQL). Enable row-level security (RLS) on every table and ask the agent to explain which policy each one has. A table without RLS can end up readable by anyone.
• Payments. Stripe if it operates in your country; in Latin America, also look at Mercado Pago or other local gateways. Payments are confirmed with server-side webhooks, never from the browser alone.
• Transactional email. A service like Resend or SendGrid for the welcome email and alerts.

Step 4: debug, version and deploy

• Errors. When something fails, paste the full error into the agent chat and ask it to explain the cause before fixing it. If you just say "fix it", it tends to patch the symptom.
• Frequent commits. A commit after every change that works. It's your undo button.
• Deployment. Connect the GitHub repository to Vercel (or the platform you prefer). Every change to the main branch goes live automatically, with HTTPS and your own domain. If you want something cheaper for a simple app, you can also deploy on Cloudflare for free.

The risks nobody tells you about

Vibe coding lowers the barrier to entry, but it doesn't remove the problems: it hides them better. The most common ones:

• Security. API keys exposed in the browser, tables without permissions, unprotected admin routes. The code "works", so nobody reviews it. Before you have real users, ask the agent for an explicit security audit and, if you handle payments or personal data, get a human review. To go deeper, I have a guide on AI security and privacy in your business.
• Technical debt. Every quick patch adds up. If every new change breaks two things, it's time to stop and ask the agent to propose a reorganization.
• Relying on a single tool. That's why GitHub and AGENTS.md matter: if Cursor raises prices or changes its terms —as just happened— you can carry on with another agent. I compared the alternatives in the AI IDEs and coding agents worth it in 2026.
• The invisible cost. AI credits go fast when the agent gets stuck in "fix this, break that" loops. Check your usage every week.

Cursor pricing in 2026: the October change

Since October 12, 2026, Cursor sells new subscriptions inside The X Subscription, a bundle shared with Grok and X. The Pro ($20) and Pro+ ($60) plans are no longer offered to new customers; existing subscribers can keep them.

Plan	Monthly price	Included usage	Who it's for
Free	$0	Limited, with Cursor models	Trying the tool and learning the workflow.
Plus	$8	Weekly base usage, Cursor and Grok models only, at fixed settings. No Auto, cloud agents or third-party models.	Simple prototypes on a minimal budget.
Premium	$30	4x Plus usage. Cloud agents, Bugbot and third-party models (Claude, GPT) billed separately at API prices from prepaid credit.	A founder seriously building an MVP. The equivalent of the old Pro.
Super	$100	15x Plus usage and priority at peak hours.	Heavy use or several projects at once. Equivalent to the old Pro+.
Ultra	$200	50x Plus usage and early access to new models.	Teams or large codebases.

Annual plans cost $80, $300, $1,000 and $2,000 respectively. Prices exclude tax (source: Cursor help center).

How to think about the cost

• Usage is no longer counted in "requests". Each plan comes with a usage pool that refreshes every week. When it runs out, you can top up. Cursor doesn't publish the dollar value of each pool, so the only way to know whether it's enough is to measure your own usage during the first weeks.
• Third-party models are paid separately. On Premium and above, using Claude or GPT is deducted from prepaid credit at API prices. Use Composer 2 for the bulk of the work and save the pricier models for the hard parts: architecture, bugs the cheap model can't solve, or security reviews.
• If you already have Pro or Pro+, think before switching. Moving to the new subscription cancels your previous plan, and there's no going back.
• Compare it with what it replaces. Even on Premium plus model usage, the monthly cost is usually a fraction of hiring outside development by the hour. But count your own time: an MVP you build yourself with AI is cheap in money, not in hours.

To compare Cursor with ChatGPT, Claude or Gemini subscriptions and with open models, check out real AI prices in 2026. And if you're worried about depending on a single provider, you can also work with local models from agents like opencode.

What really changes for founders in Latin America

For years, launching a digital product in the region meant raising capital to pay for development or finding a technical co-founder. Vibe coding doesn't remove that need forever, but it does for the first version: today you can reach real users with your time, a subscription and discipline.

The competitive edge no longer lies in memorizing syntax. It lies in being clear about what problem you solve, building the minimum to prove it, measuring what users do and protecting your cash while you iterate. Writing code is no longer the bottleneck; deciding what to build is.

Before you write your first prompt

Run the numbers and the model before you open the editor:

1. Use the profit margin calculator to project what infrastructure and AI subscriptions cost you, and what price your plan needs to sell at for the business to work.
2. Build your model in the interactive Business Model Canvas to be clear about who your customer is and what you'll charge before investing time and money in building.