The core idea

tCode is not given a single broad instruction to "go write code." It is given a small, fixed set of tools, reading a file, editing one, running a command, searching a codebase or the web, and the model decides for itself, turn by turn, which of them actually gets your specific request done.

This is what makes it closer to delegating a task to a colleague than to filling in a template. A request like "fix the failing test" does not map to one fixed sequence of tool calls; it might take a single read and a single edit, or it might take several searches to find every place a related assumption lives before anything is changed. The model works that shape out as it goes, based on what it actually finds.

The full mechanics of one such sequence, called a turn, are covered in The chat loop; the exact tools available and what each one can and cannot do are covered in Tools.

This design choice, a small fixed toolset rather than open-ended system access, is deliberate rather than a limitation. It keeps every individual action reviewable on its own terms, a read, a write, a search, a command, instead of an opaque general-purpose capability that would be much harder to reason about or approve safely.

It also means the model's behavior stays predictable across very different kinds of requests. Whether the task is a one-line fix or a broad multi-file investigation, the same small set of primitives is doing all the actual work; only the sequence and number of calls to them changes.