How AI coding tools work

What is the model actually doing?

The model receives a long block of text and produces more text. That is the whole operation. The text it receives contains your instruction, project context and a description of the actions available to it. The text it produces is either an answer or a structured request to use one of those actions.

{
  "tool": "write_file",
  "path": "src/routes/signup.tsx",
  "content": "..."
}

The program around the model reads that request, performs it for real, and sends back what happened. The model never touches your disk directly.

What is the context window and why does it run out?

The context window is the maximum amount of text the model can consider at once, measured in tokens (roughly three-quarters of a word each). Your whole project rarely fits, so the tool chooses what to include: recently edited files, files you mentioned, a project summary, the last few messages.

When a conversation gets long, older parts are summarised or dropped. That is why a tool sometimes 'forgets' a decision you made twenty messages ago — the decision is genuinely no longer in front of it. Restating constraints is not nagging; it is refilling context.

Why does the same model behave differently in different tools?

Because most of the behaviour lives in the wrapper, not the model. Two products can call the same model and feel completely different depending on what context they gather, what rules they inject, which actions they allow, whether they run the build and read the errors, and how many times they will retry.

What is the build loop?

1. 1The model writes files.
2. 2The tool runs the type check and build.
3. 3Errors, if any, go back to the model as plain text.
4. 4The model edits and the build runs again.
5. 5After a few failed rounds the tool stops and shows you the error.

This loop catches syntax and type errors reliably. It does not catch logic errors, permission errors or anything that only appears with real data, because a successful build only proves the code compiles.

How should this change the way you prompt?

• Say what the thing must do, not how to write it — unless the how matters, in which case say it explicitly.
• Name the files or features involved so the right context gets gathered.
• Give the failing behaviour, not your theory about it. Paste the real error text.
• State the constraint that must survive: 'do not change the existing signup flow'.
• Ask for verification: 'then tell me how to check it worked'.