Chapter 10: Vibe coding with Cursor

Introduction

The introduction explains vibe coding as conversational, AI-assisted development and positions it as a fast way to prototype without replacing structured practices for important applications.

• Conversational vibe coding: Explain that vibe coding lets people guide AI agents with natural-language prompts rather than detailed specifications, and that tools such as Cursor can work across a codebase.
  Why it matters: This distinction explains what makes vibe coding different from simpler AI code-completion tools.
• Prototyping value and limits: Justify using vibe coding for quick prototypes and exploration while distinguishing it from structured practices needed for important applications.
  Why it matters: Knowing when to use vibe coding helps you benefit from its speed without treating a prototype as a substitute for careful development.

Key terms: vibe coding, natural language, AI agents, Cursor, quick prototyping, structured practices, validate ideas

10.1 What is vibe coding?

Defines vibe coding, explains when it can be useful, and cautions against using it for sensitive or high-stakes software.

• Vibe coding and human role: Explain how vibe coding uses simple language prompts to generate software and shifts the human role from writing code to guiding and testing the AI’s output. Distinguish it from the book’s earlier approach of understanding and integrating generated code.
  Why it matters: This distinction helps you recognize what makes vibe coding different from simply using AI assistance while coding.
• Uses for exploratory coding: Describe why vibe coding can help nonprogrammers make products and how programmers can use it for rapid prototypes, trying unfamiliar technologies, or low-stakes projects.
  Why it matters: Knowing the useful contexts helps you choose vibe coding for exploration rather than treating it as an all-purpose development method.
• Security and accountability limits: Explain why the section warns against releasing vibe-coded enterprise production software or software handling sensitive data, and who remains accountable for it.
  Why it matters: The speed of generating software does not remove your responsibility for what you release.

Key terms: vibe coding, simple language prompts, LLM, guide and tester, rapid prototyping, proof of concept, unfamiliar technologies, security concerns, production software, sensitive data

10.2 What is Cursor, and why is it different?

Introduces Cursor as a popular tool for vibe coding while clarifying that it also supports professional, supervised code generation.

• Cursor Beyond Vibe Coding: Explain why Cursor is often used for vibe coding and why it should not be considered only a vibe-coding tool.
  Why it matters: This distinction keeps you from treating Cursor as useful only for free-form AI coding.

Key terms: Cursor, vibe coding, immersive and agentic experience, structured and supervised code generation

10.2.1 The interface

This section contrasts Cursor’s AI-centered IDE with plugin-based assistants and explains how its agent mode can carry out multistep coding tasks under user supervision.

• AI-Centered IDE Interface: Distinguish Cursor’s interface from AI coding tools that run as IDE plugins, and explain why its dedicated interface can feel more immersive.
  Why it matters: The interface helps explain how Cursor differs from the plugin-based tools used earlier.
• Supervised Agent Mode Workflows: Describe what Cursor’s agent mode can do across a coding task and what role the user retains.
  Why it matters: Agent mode is the main reason Cursor offers more than individual code suggestions.

Key terms: interface, plugins, IDE, LLM, agent mode, AI agents, autonomous workflows, AI codeveloper

10.2.2 Project-wide context and customization

This section explains how Cursor uses project-wide context and team rules, while noting the limits of building an application through prompts alone.

• Project-wide AI context: Explain how Cursor’s analysis of the whole project differs from single-file or manually supplied context, and what that enables.
  Why it matters: Project-wide context explains why Cursor can assist with more than the file currently open.
• Team rules for generated code: Describe how project-level customization can steer Cursor’s generated code toward team conventions.
  Why it matters: Team rules can make AI-generated code fit the project’s conventions with less review.
• Limits of prompt-only building: Distinguish the author’s experience with prompt-driven building on smaller projects from larger ones.
  Why it matters: It sets a realistic expectation for how much work prompting may leave to the developer.

Key terms: project-wide context, structure, dependencies, coding patterns, context-aware chat, project-level customization, .cursorrules, coding standards, best practices, series of prompts

10.3 First concept

The section turns a rough idea for a Python game into a specific concept that can guide an initial Cursor prompt.

• Specific outline before prompting: Explain why the author sketches the game before asking Cursor to build it: a developer can make the request more specific, and a clear outline provides a starting point for a detailed prompt.
  Why it matters: A concrete starting concept gives Cursor a clearer target for its first response.
• Pyfrog game concept: Describe the proposed Frogger-style game's objective, implementation choice, and main river-crossing rule.
  Why it matters: These details make the intended game concrete enough to describe in a coding request.

Key terms: prompt engineering, Cursor, initial prompt, Pyfrog, Frogger, Python, Pygame, logs

10.4 The initial prompt to build our game

This section shows how a detailed initial prompt defines a runnable game for Cursor and why specifying requirements up front can reduce unwanted results and repeated prompting.

• Upfront prompt specificity: Explain why the author puts substantial detail into the initial vibe-coding prompt: unclear requirements can lead Cursor to build something unintended, while a specific prompt can reduce later revisions and potentially costly extra prompts.
  Why it matters: A clear starting request can save you from correcting the wrong application later.
• Game prompt requirements: Describe how the example prompt specifies the desired deliverable, game behavior, technical constraints, and code quality rather than merely asking Cursor to make a game.
  Why it matters: The example shows what it looks like to turn a game idea into instructions Cursor can act on.

Key terms: vibe coding, initial prompt, premium models, Constraints & Specs, Python 3.10+, Pygame 2.x, Logs, Scoring & Win Condition, Code Quality

10.5 Cursor basics

Introduces Cursor’s familiar Visual Studio Code-like interface and shows a prompt receiving a response in its side chat.

• Cursor editor and side chat: Describe how Cursor’s interface resembles Visual Studio Code and identify the side chat as the place where the author entered a prompt and received a response.
  Why it matters: The familiar editor and side chat help you orient yourself before using Cursor’s other features.

Key terms: Cursor, Visual Studio Code, chat window, prompt

10.5.1 Giving feedback

Explains how to review a Cursor result, give optional feedback, copy it, and identify changed files.

• Cursor result controls: Describe how to review proposed changes, give optional thumbs-up or thumbs-down feedback, and copy a result, usually in Markdown format.
  Why it matters: These controls help you inspect and respond to a suggestion without requiring you to rate it.
• Changed file listing: Explain that Cursor shows which files changed after a result, as illustrated by the single file river_run.py.
  Why it matters: The file listing lets you see which parts of the project a result affected.

Key terms: Review changes, Thumbs up, Thumbs down, Copy, files that were changed, river_run.py

10.5.2 Adding context

This section explains how to add focused context in Cursor and why selecting relevant material is better than loading an entire application.

• Cursor context sources: Describe how you can direct Cursor’s attention by adding context, such as files, selected code, documentation, past chats, terminal output, or linter errors.
  Why it matters: Choosing the right context helps keep Cursor’s answers relevant across many conversations about an application.
• Selective context benefits: Explain why choosing relevant individual files can work better than including the entire application as context.
  Why it matters: Focused context can improve the usefulness of suggestions without spending tokens on irrelevant material.

Key terms: context, Files and folders, Code, Docs, Past chats, Terminals, individual files, noise, token limits, focused, intentional context

10.5.3 Selecting a mode

This section explains Cursor’s three chat modes and when to use each one.

• Cursor mode purposes: Distinguish Agent, Ask, and Manual modes by what each is used for, and describe where to switch between them.
  Why it matters: Choosing the mode helps you match Cursor to the task you want it to perform.

Key terms: Agent, Ask, Manual, chat window

10.5.4 Model selection

Explains that Cursor lets you choose a model for each prompt, while model quality and costs can change.

• Per-prompt model selection: Explain that Cursor lets you choose a model for each prompt and that there is no lasting, universal answer to which model is best.
  Why it matters: You can choose a model for the task at hand rather than treating one model as permanently best.
• Model costs and customization: State that some model choices may cost extra beyond a Cursor account and that custom models can also be added.
  Why it matters: Checking a model’s cost helps you avoid an unexpected charge.

Key terms: model, prompt, Cursor, custom models, Cursor account

10.5.5 MAX mode

MAX mode expands Cursor’s available context but can substantially increase costs.

• MAX mode tradeoff: Explain that MAX mode allows larger conversations and more files in context, but can greatly increase billing; describe how to check its pricing and turn it off.
  Why it matters: Knowing the tradeoff helps you decide whether the extra context is worth the cost.

Key terms: MAX mode, context windows, billing

10.6 Results from the first prompt

The section shows how a detailed first prompt led Cursor to produce a claimed runnable game in one pass, giving the author a quick starting point for iteration.

• First prompt constraints: Explain why the author specified the application's language and framework in the first prompt, while acknowledging that a coder could instead let the tool choose.
  Why it matters: An early choice about how much to specify can affect whether the first result is useful.
• One-prompt game result: Describe what Cursor reported producing from the first prompt and why that result appealed to the author, without treating its claims as verified gameplay.
  Why it matters: The first result illustrates the appeal of a quickly runnable prototype without implying that no testing or changes are needed.

Key terms: language, framework, prompt, Frogger-style game, River Run, runnable, iterations

10.7 Running our game for the first time

The section reports that a playable game ran on the first try from a single prompt, using that result to emphasize detailed prompts in vibe coding.

• Detailed prompts and playable results: Explain what happened when the author first ran the game and why the author connects that result to prompt detail.
  Why it matters: The first run shows what a detailed prompt can produce while leaving room for later changes.

Key terms: single prompt, vibe coding, details

10.8 Making changes to our game

This section uses plain-English prompts in Cursor to fix a game, add persistent high scores, and revise the gameplay after testing reveals an unintended result.

• Specific prompts for game changes: Explain how the author describes desired game behavior in plain English rather than specifying code, and why a structured, specific prompt helps steer Cursor's output.
  Why it matters: A clear description of the outcome gives Cursor less room to invent behavior you did not intend.
• High-score feature requirements: Describe the high-score behavior the author requested, including local persistence without a database and how scores and initials should appear in the game.
  Why it matters: These concrete requirements make it possible to check whether Cursor built the feature the author intended.
• Testing and revising game flow: Trace how running the game exposed a flaw in the first high-score implementation and how the follow-up prompt changed the flow.
  Why it matters: Running the result can reveal a gameplay problem even when Cursor has fulfilled the prompt as written.
• Reviewing Cursor changes and limits: Describe how the author reviews and checks Cursor's changes, and identify the large-file and terminal limitations encountered in this example.
  Why it matters: Accepting generated edits is not the same as confirming that the game behaves correctly.

Key terms: plain English prompts, Goal, Gameplay, Requirements, Flow, vibe coding, persistent scoreboard, high_scores.json, top 5 scores, initials

10.9 Summary