How AI Coding Assistants Work

You've probably asked Claude Code, Codex, GitHub Copilot or a chat assistant for code, pasted the answer, and hoped. This track is about replacing hope with understanding. It starts with a simple, honest mental model of what the assistant is doing.

Predicting text, one piece at a time

At the core of every coding assistant is a large language model (LLM). During training it learned statistical patterns from a huge amount of text, including a lot of code. When you send a prompt, it generates a reply by repeatedly predicting a likely next piece of text (a token) given everything currently in its context. This is a simplification, but it's the right one to keep in your head.

That's why generated code usually looks very plausible: it resembles the code that typically follows requests like yours. But plausible-looking code can call functions that don't exist, use an option from an old version, or miss the one edge case your app depends on.

Context window

Everything the model can "see" in one go: your prompt, earlier messages, files or tool output that were added. It has a size limit. Anything outside it, the model doesn't know about.

Training cutoff

The model learned from data up to some point in time. Newer library versions or changed APIs may be missing unless they're provided in the context (for example by pasting the docs).

Tools / agent

Some assistants (for example Claude Code or Codex) can be given tools: read files, run commands, run tests. Without tools, a model only produces text — it hasn't run anything.

Hallucination

A confident answer that isn't true: a made-up method, package, flag or fact. It reads exactly like a correct answer, which is what makes it dangerous.

What this means in practice

• It only knows what's in its context. If it never saw your utils.js, any code that uses it is a guess.
• "This works" in a chat reply is not evidence. Unless a tool actually ran the code and you can see the output, nothing was tested.
• It can be confidently wrong. Tone tells you nothing about correctness. Treat every suggestion as a draft from a fast, well-read colleague who never double-checks.
• Answers vary. Ask the same thing twice and you may get different code. Your tests, not the wording, decide which one is right.
• You stay responsible. Whatever you commit, deploy or paste into a terminal is yours.

function totalPrice(items) {
  return items.sum((item) => item.price);
}

function totalPrice(items) {
  return items.reduce((sum, item) => sum + item.price, 0);
}

Could not render the cart: TypeError: items.sum is not a function

The loop for this whole track is read → run → verify → decide. Read the code until you could explain it. Run it. Verify it against what you actually need. Then decide: keep, fix, or ask again with better context.