Back to this island

WRITING / 01

Engineering context

AI models went from writing a paragraph to building good apps. Getting exactly what you need still depends on giving them the right context. I think the next step is models that gather that context themselves.

TLDR: You get what you don’t ask for. Models are getting good enough that soon you won’t need to engineer their context. The model will already have it, and it will build exactly what you need, whether or not you can specify it.

Each generation of AI models has changed what people expect from them. Early models impressed people by producing anything at all. The latest ones build full applications and hardly anyone reacts. I think the next improvement is less about what a model can make and more about how much you need to tell it first.

Output

Early models could write a paragraph, an email or a short piece of writing, or generate an image. For developers, an instruction or a file could return a code fix, a few lines of code or a page of it. The output was small, but it was new. You could ask for something and get a usable result.

Apps

The next models could do much more. You could give an instruction like “Build me a finance app. Here is what it should do, and here is what it shouldn’t”, and get an entire app back. It often wasn’t very good, but you could describe what you wanted and watch it get built.

Good apps

Now nobody is surprised that a model can build a full-stack app. People expect it to, and they expect the app or website to be good.

AI companies are improving models in other ways: making them faster, cheaper to run and better at using a computer. None of these changes closes the gap between what you ask for and what you get.

The gap that remains

A really good app, or what you think is a really good app, still depends on good requirements. Someone has to decide what matters, what to leave out, and what good means for this person and this purpose. The bar for good requirements has already dropped. A short description now produces what once needed a detailed specification. I expect it to keep dropping, until a model builds exactly the app you need, at the time you need it.

Apps are one example. Fixing something in a large enterprise codebase is another. Changing that code is risky, so today you describe exactly what you need, and often which files you think the model should change. The model can usually write the change, but it doesn’t have the context you have.

Some tools tackle this with agentic commands such as /goal, or with settings for how much the model thinks before it acts. These help, but they don’t fix the problem. You still need to define the goal accurately, and there is still a gap between the goal you define and what you get. Closing that gap needs changes around the model, not just inside it. I plan to write about those separately.

What you need to provide at each stage

Using apps as the example, each generation of models produces more. At the final stage, you provide much less.

  1. A paragraph or a code fix

    Ask for one small piece of work and receive it.

    You provide
    An instruction for one email, image or file.
  2. A whole app, often rough

    Describe an application and the model builds a working version that often needs fixing.

    You provide
    What the app should do and what it shouldn’t.
  3. A good app is expected

    A full app no longer surprises anyone. The result is only as good as the requirements and context.

    You provide
    Clear requirements and the context that defines what good means.
  4. Exactly the app you need

    The model already has the context, so it builds the app you need at the time you need it.

    You provide
    A short request.

Apps are one example of this progression. The final stage is my prediction, not a description of current models.

After context engineering

Supplying that context is called context engineering, and it is one of the main topics in AI right now. People write detailed instructions, pick the right files and documents, and describe their preferences so a model can do good work.

I think the next step is models engineering the context themselves. As models improve and get access to better context, they will already know what they need: how your codebase fits together, what you are trying to achieve and what you would consider good. You would no longer need to engineer the context, because the model would already have it.

That also changes how carefully you need to define a goal. You wouldn’t have to specify it in detail. You could give the model the goal in a sentence and get what you meant, including the parts you never wrote down.

These are my own views and do not represent those of my employer.