The fundamentals of AI dev

This is the companion to the episode, and it is the front door to the series. The other parts show you how to build software with an agent. This one comes first and gives you the words for what is going on, so none of it feels like magic. By the end you can say what a coding agent is, why it answers the same question in different ways, how you steer it, why it loses the thread on long jobs, and what a skill is. With those, the rest of the series is easy to follow.

What a coding agent is

You have probably used a chatbot like ChatGPT. You type a question, it types an answer, and that is the whole loop. A coding agent starts from the same kind of model and adds two things on top.

First, it can use tools. That means it can read and write the files on your computer and run commands, so it can change your actual project rather than only describe a change in a chat box.

Second, it runs in a loop. It reads a file, makes a change, runs the code, looks at the result, and decides what to do next, over and over, until the job is done. You give it a goal and it works toward that goal on its own.

The program you run all this inside is called a harness. We use one called Claude Code. Cursor, Copilot, and Codex are other harnesses that do the same job, and everything in this series works the same way whichever one you pick. When we say the agent, we mean the model plus the loop plus the tools, running in a harness like these.

Why it gives different answers

The model at the center works by prediction. It reads everything so far and predicts the next word, then the next, one word at a time. Your phone keyboard does a tiny version of this when it suggests the next word; the model does it far better and for whole answers at once.

Because it predicts rather than looking up one fixed answer, you can send the exact same request twice and get two different results. The word for this is nondeterministic. A calculator is the opposite kind of thing: 2 plus 2 is always 4. An agent aims for a good answer each time, and it may word that answer differently each time. This is normal, and it is worth expecting up front.

It is also the first reason the series leans on a repeatable process. If the output can change from one run to the next, then one lucky success is not proof that something works. You check the result every time.

How you steer it: prompt and context

A prompt is what you type to the agent. It is the request itself. "Add a login screen" is a prompt.

Context is everything the agent can see while it answers. That includes your prompt, the files it has open, the earlier messages in the conversation, and any standing instructions you gave it. The model can only work from what is in front of it, so the context is what really sets the quality of the answer.

You will hear us repeat a short version of this: context is king. A bare one-line prompt makes the agent fill in the gaps by guessing, and it guesses whatever is most common. The same request with the right files and a clear example of what you want gives it enough to land on the answer you actually wanted. Most of the craft in this series is feeding good context, and very little of it is clever wording.

The context window, and why long sessions go wrong

The context an agent can hold is not unlimited. It has a fixed size called the context window, which is the agent's working memory for the session you are in. Picture a desk. A large desk holds many open papers at once, and every desk eventually runs out of room.

When the window fills up, older details get pushed aside. The agent starts to forget decisions you made earlier, redo work it already finished, or contradict itself. That slow loss of the plot is called drift. In practice it looks like answers that were sharp at the start of a session turning mushy near the end.

There is a simple way to picture it. Early on, with plenty of room, the agent is in the smart zone. As the window fills toward its limit, it slips into the dumb zone, where drift shows up.

You keep drift away with a couple of habits. Keep each task small enough to finish before the window fills, and start a fresh session for each new task rather than piling everything into one endless conversation. When you do need to carry work from one session to the next, you write a short note of what matters so the new session starts with only that. The later parts of the series show the exact tools for this. Here it is enough to know why they exist.

What a skill is

The last word to learn is skill, and it is the whole subject of the next part. A skill is a single markdown file that teaches the agent one process. Markdown is plain text with light formatting, the kind of file you can open and read yourself. Inside a skill you write down how to do one thing well, for example how to plan a feature before writing any code, or how to hunt down a bug step by step.

You install the skills you want once, and after that the agent follows the matching process on its own whenever the situation comes up. A lot of what separates sloppy output from professional output is simply handing the agent good processes to follow.

Part one of the series installs a whole pack of skills called superpowers, and that is where the building starts. Everything on this page, the agent and its tools, prediction, context, and the window with its drift, is the ground that part stands on.

What you walk away with

• A plain map of how a coding agent behaves, so nothing in the rest of the series lands as a black box.
• The vocabulary the other parts lean on, from agent and prompt through context, drift, and skill. Once you can define these words, you can follow the build and steer it yourself.

Where to go next

• Part one installs superpowers and builds a real feature with it. That is the natural next watch after this one.
• The links below are the other parts of the series and the community where we build in the open.