Resources

How AI coding actually works.

Everything that happens between your prompt and the code that appears. The mental model that separates vibe coders who ship from vibe coders who get stuck.

15 min read

The full picture

1
The model — what it is and isn't
2
Tokens and the context window
3
The harness — what makes it an agent
4
Tools and the environment
5
Where things go wrong
6
Sessions, memory, and staying sharp
7
Patterns of work — how you actually build

The model — what it is and isn't

A model is a giant pile of numbers trained to predict the next word. It has no memory, no tools, no agency. It reads what you give it, generates one token at a time, and stops. Everything you experience as "intelligence" is built around it, not inside it.

Input tokens

Model

Output tokens

This is why AI can seem creative — it's assembling statistically plausible sequences. It's also why it confidently invents things. If a plausible-sounding answer exists, the model will generate it whether or not it's true.

When you'll hit this

You ask Cursor to add a SwiftUI modifier that doesn't exist. The name sounds right, the syntax looks right — but it's hallucinated. The model predicted what a real modifier would look like.

This is why re-running the same prompt can give you a completely different implementation. Not a bug — it's how the model works. Temperature controls how "random" the sampling is.

When you'll hit this

You prompt "build a settings screen" twice. First time you get a list-based layout. Second time you get a tab-based layout. Both valid — the model just sampled differently.

Tokens and the context window

Every word you type gets chopped into tokens — roughly word-sized chunks the model can process. The context window is the total amount of tokens the model can see at once. Think of it as the model's working memory. Everything — your prompt, the system instructions, the file contents, the conversation history — has to fit inside this window or the model literally cannot see it.

Everything competes for this space: your prompt, system instructions, file contents, conversation history. When it fills up, the model either truncates or compresses. This is why long sessions degrade — you're not running out of "memory," you're running out of window.

When you'll hit this

You're 45 minutes into a Cursor session. You paste a large file and suddenly the model "forgets" decisions from earlier. The new file pushed older context out of the window.

The harness — what makes it an agent

A model alone can't do anything useful. The harness is everything built around it — the system prompt, the tools, the permission system, the context management. Cursor is a harness. Lovable is a harness. Claude Code is a harness. The model is the engine; the harness is the car.

Different harnesses give the same model wildly different capabilities. Claude in Cursor can edit files, run terminal commands, and read your codebase. Claude in the chat window can only talk. Same model — different harness.

When you'll hit this

You're frustrated that Claude "can't" do something in one tool that it does in another. It's not the model's limitation — it's the harness. Cursor exposes file editing tools. Lovable exposes a browser preview. The chat has neither.

Tools and the environment

Tools are how the agent actually does things beyond generating text. Reading files, writing code, running terminal commands, searching the web — these are all tools the harness exposes. The environment is everything the agent acts on: your filesystem, your browser preview, your database.

The model doesn't "use" tools the way you use a hammer. It outputs structured text that says "I want to call this tool with these arguments." The harness reads that text, actually executes the tool, and sends the result back. The model never directly touches your files.

When you'll hit this

When Cursor "edits a file," the model is actually outputting a structured tool call like "apply this diff to this file path." Cursor's harness reads that, applies the change, and shows you the result.

Where things go wrong

Every AI coding frustration traces back to a small set of failure modes. Once you can name them, you stop blaming the tool and start working around the actual limitation. This section will save you more time than any other.

Factuality hallucinations happen with APIs, library methods, and config options the model hasn't seen in training. Faithfulness hallucinations happen when the context window is full and the model loses track of your requirements.

When you'll hit this

The model imports a package version that doesn't exist, or rewrites a function you explicitly told it not to touch. Both are hallucinations — different flavors.

This is why the model confidently uses outdated syntax or deprecated APIs. It's not being lazy — it literally doesn't know the new version exists. The fix is loading current documentation into the context (paste the docs, link to them, or use a tool that fetches them).

When you'll hit this

You ask Cursor to use a SwiftUI API introduced in the latest iOS release. The model's training data stops before that release. It either hallucinates a plausible-looking API or uses an older equivalent. Loading Apple's current docs into context fixes this.

Each token has a fixed attention budget. Spread across more context, each piece gets less focus. This is why the first prompts in a session feel sharp and the 30th starts breaking things.

When you'll hit this

You've been working in one Cursor session for an hour. The model starts "forgetting" files you edited earlier, or re-introduces bugs you already fixed. Time to start a fresh session.

Sessions, memory, and staying sharp

The model is stateless — it carries nothing forward between requests except what's in the context window. Sessions give you the illusion of continuity, but they're really just an accumulating context window. Understanding this changes how you structure your work.

Smart zone (fresh)DriftingDumb zone (full)

This isn't metaphorical. The attention degradation from section 5 is the mechanism. Fewer tokens in context = more attention per token = sharper output. This is why starting fresh sessions frequently is a power move, not a limitation.

When you'll hit this

You notice Cursor giving increasingly generic responses. Instead of rephrasing your prompt 5 times, start a new session with a clear brief. You'll get first-prompt quality again.

Patterns of work — how you actually build

These aren't theoretical categories. They're the working modes you switch between daily. Knowing which one you're in — and when to switch — is the highest-leverage skill in AI coding.

This is how most non-engineers build with AI tools. It works for shipping fast. It breaks when the codebase gets complex enough that invisible decisions compound. The fix isn't "learn to code" — it's pre-build planning that constrains what the agent can do wrong.

When you'll hit this

You prompt Lovable to add auth. It works. Three features later, everything breaks because the auth implementation made assumptions about your data model that conflicted with what came next.

The single biggest unlock for vibe coders. Instead of prompting and hoping, you give the agent a constrained decision space. Architecture is decided. Data models are defined. UI flows are mapped. The agent fills in implementation — which is what it's actually good at.

When you'll hit this

Without pre-build planning, you prompt "build me a habit tracker app" and get whatever the model defaults to. With it, you've already decided: SwiftUI, local-first with SwiftData, specific screen flows, specific data model. The agent builds what you designed, not what it guessed.