· Tooling · 3 min read

Context is the cheapest token you will buy

A screen of JavaScript code in pink and blue on a dark background

Ask an AI to fix something in an application it does not understand and you get a very particular kind of afternoon. The first fix breaks something else. The second fix undoes the first. By the fifth you are no longer fixing the application, you are arguing with a probability engine, and every round costs money. Nothing was wrong with the model. It simply had no idea what it was working on.

Two things are worth knowing before that afternoon happens to you. A large language model does not know, it predicts: it produces the most probable next piece of text given everything it has seen, and the probable is not always the true. And it learns nothing while you use it. Training is over by the time you type. The only thing that changes from one request to the next is what you put in front of it, which is why that part is called context and why it matters more than the model.

The second thing is the meter. Everything in and out is counted in tokens, roughly four characters each, and you pay for both directions: the question and the answer. A loop of fixes is not just slow. It is the most expensive way to get nowhere.

So the work is not in prompting better. It is in building the context once, so that every request starts from the same solid ground. The best way to build an application that performs well is:

  • Define the system before the first request. Programming knowledge matters at this stage: set up the stack you will work with and give the AI specific instructions about how the project is built, in general terms, before anything else.
  • Keep a memory trail. Every action the AI takes should be recorded properly, so that when it comes back to the project at another point it knows where things stand.
  • Split the work before starting. Break the work into tasks before handing anything to the AI. It is better to work in phases than to expect everything to be done in one go.
  • Review every phase. Go through each phase carefully, run functional tests and fix what does not work. This is often the phase that takes longest, and the one where you will spend the most tokens.

None of this makes the programmer optional. It takes real knowledge of code to write the conventions, to split the work sensibly, and to know when a fix is a fix. What changes is where the time goes: less on typing, more on the method, the system and the constant improvement of what is already running. Once the application exists, the model is a very good tester and a tireless troubleshooter, and that is where it pays for itself.

Context is the cheapest token you will ever buy. Everything else is the expensive kind.