An answerable vocabulary for LLM collaboration

Working with LLMs as a software engineer has changed how I understand language.

Language does not merely describe the world. It helps divide, bind, test, and move it. Programming languages are constrained reductions of this power: small, deterministic fragments of language made legible to machines.

LLMs loosen that constraint. We can now write software in English. But English is only the interface. The deeper fact is that language has always programmed the world. LLMs made that old power newly executable.

So I have been collecting a vocabulary for writing software in English with LLMs. It is not a methodology. English is too flexible, variable, and alive for that, at least this early. These terms do something smaller and more useful: they keep the work in contact with the thing that can say no.

The compression is:

center
  -> owner
    -> surface
      -> scope
        -> claim
          -> burden
            -> distinction
              -> bridge
                -> license
                  -> pressure
                    -> proof
                      -> oracle
                        -> gate
                          -> receipt
                            -> residue
                              -> loop

The movement is inquiry, authority, work, correction.

The LLM chat is usually not the owner. It is the place where you discover the owner: the repo, route, source file, essay, person, screenshot, test, browser, contract, or memory surface that can answer back.

pressure (inquiry)
  -> proof (authority)
    -> oracle (work)
      -> gate (correction)

Proof names what would make the claim more than plausible. Oracle names the answer, surface, or check that can resist the claim and produce that proof.

In code, that might be a typecheck, a failing-then-passing test, a browser route, a rendered screenshot, or exact source inspection. In writing, it might be whether the claim still carries its burden after the source is reopened.

Correction is where the vocabulary earns its keep. The test fails. The route does not render. The distinction collapses. The source does not support the bridge. The correction leaves residue, and the residue can become a better constraint next time.

This is why words matter so much when working with LLMs. Names do not merely label reality. They sort, bind, invoke, oblige, and make future moves answerable.

If the words are loose, the work becomes loose. If the words carry real distinctions, the work can stay in contact with what can correct it.

This is the question underneath the whole list.

Not: is this fluent?

Not: does this phrase sound right?

Not: does this look like good work?

Those are local signals. They can all pass while the work never touches the thing that owns the truth.

Instead, ask: what makes this answerable?

The word “this” is the mechanism. This claim. This file. This route. This sentence. This distinction. This thing I am asking you to accept.

If you cannot name what “this” is answerable to, you are still in the appearance of work. When you can name what can answer back, you are doing work.