Videos

Every coding agent, Claude Code, Codex, all of them, is the same handful of lines. Call the model, the model asks for a tool, the tool runs, and the result goes back into the conversation. Then you go again until it's done. The vendors differ on what they put into that loop. They don't differ on the loop.

This is the one I want you to walk out with. Every file it reads, every command it runs, every test output comes back as a message and sits in the conversation. So the budget fills up without you typing a word. A 2,000-line file read is the same as you pasting 2,000 lines into the chat.

The agent runs in your repo. The browser habit, one long chat and copy-paste out, is the wrong mental model here. Start from the folder, let it read, let it act, let it write there.

The vendor's system prompt, which is fixed. Your project files. The list of tools it has. The conversation so far. And every tool result that came back. That's it, and it's a hard limit, input and output both count.

This one's counterintuitive. Quality goes down as the window fills, and stuff in the middle gets less attention. So "bigger context" is not a thing you want to max out, it's a thing you want to manage.

In Claude Code /context shows you the breakdown, /compact summarizes (you can say /compact focus on X), and /clear resets between unrelated tasks. When it fills on its own, the harness auto-compacts: the history becomes a summary, the project file and tool list come back, nested files and skill bodies don't.

First the vendor's system prompt, fixed, invisible, always first. Then your project file: CLAUDE.md for Claude Code, AGENTS.md for Codex. It gets read at session start and sent every turn on top of the system prompt. Claude Code does not read AGENTS.md on its own, you import it with @AGENTS.md or symlink it, and Codex doesn't read CLAUDE.md. Same idea, different filename.

It's the most expensive place you can put anything. Only what the agent can't figure out on its own: which project, which commands, the house rules. It's not a wiki and it's not where knowledge goes. Ten lines you wrote by hand beat two hundred generated ones, and the model still drops some of what you tell it either way.

Global (~/.claude/CLAUDE.md) plus repo root plus CLAUDE.local.md get concatenated; files in nested folders load when the agent touches that folder. The precedence details, read the docs when you need them, don't memorize folklore.

A little frontmatter, name and a one-line description, then a short procedure. If you want, scripts and reference files sit next to it and the procedure calls them. Both Claude Code and Codex have this; Codex even has a skills panel.

At startup only the name and description are in the window. The body loads when you invoke it, either with /name or because the description matched what you asked. So: project file is always-loaded facts, skill is on-demand procedure. That's the thing people mix up the most, and it's really just when it loads.

Three sentences can be a skill. The scripts beside it are how a skill does real work the same way every time. Build your own for stuff you repeat, don't go collect a pile of them. One-off jobs stay one-off prompts.

Two questions do most of the work: how checkable is the output, and how much context does it need? Checkable and bounded, delegate it, hand over the folder and review what comes back. Judgment-heavy or it needs stuff that's only in your head, pair, you drive and it drafts. Taste, politics, anything irreversible, keep. The sort itself is the skill.

Summarize a ticket. Map a module. Tell me what this test file actually covers. Draft the test matrix. Explain this stack trace. Reading tasks are bounded, checkable, cheap to verify, so they're the safest on-ramp, and it's already where the hands from 0.1 beat chat: it reads the real files, you don't paste anything.

Bigger model for judgment and ambiguity, smaller and faster for volume and mechanical stuff. For now default to the capable one and just notice when it feels like overkill.

The built-ins, read, edit, run a command, search, cover most of the engineering work you'll do. Everything in the loop from 0.1 is a tool call.

A server exposes tools, each with a name, a description and a schema, and you configure servers per project (.mcp.json) or per user. Here's the catch: every tool the agent knows about costs window. Newer harnesses list just the names and load the schemas on demand; older setups loaded everything, and that's where the "MCP ate 12% of my window" demos come from. Know it, don't collect it.

A CLI the agent already knows, plus a short readme to prime it, often does the same job for less context. So we're deferring this to a later course, on purpose.

Project file and skills go into the window and the model decides what to do with them. A hook is a script the harness runs around a tool call, before or after, every time, no model in the loop. If the hook says no, the tool doesn't run. That's the difference between "it usually does" and "it can't not."

Before a tool call (block an edit to a file you've frozen, stop a dangerous command), after a tool call (run the linter or the tests every time a file is written, and feed the result back), and at session events like stop or compact. In Claude Code they live in settings.json under hooks.

Context and preferences go in the project file. Procedures go in skills. Anything you'd be upset to see skipped even once goes in a hook: formatting, the test run, "never touch this folder." Keep hooks few and boring. A hook that tries to be clever becomes the thing you debug instead of the agent.