LLM era has a reliable product cycle: someone coins a term, someone more famous endorses it, the internet credits the endorser, and LinkedIn does the rest.
Cycle is embarrassingly simple
We have done this at least three times in four years. Each time with complete sincerity. Each time with worse naming.
The progression is instructive. Prompt engineering at least had the decency to describe what you were actually doing — writing prompts.
Context engineering was already stretching it; the word "engineering" is doing considerable structural load-bearing for what Shopify CEO Tobi Lutke accurately described on June 18, 2025 as "the art of providing all the context for the task to be plausibly solvable by the LLM.
One week later, Andrej Karpathy endorsed the term with a longer explanation.
This is the naming mythology rewriting itself in real time, which is either poetic or depressing depending on your tolerance for how information actually spreads.
Harness engineering arrived in February 2026, formalized by Mitchell Hashimoto and documented by an OpenAI team who used it to describe building a million lines of agent-generated code. The OpenAI post is worth reading carefully, because what it actually describes — at length, with genuine insight — is: write config files, enforce architectural patterns with linters, and run cleanup jobs to remove code the agents wrote badly. In previous decades we called this maintenance. We did not issue certifications for it.
A brief taxonomy, in ascending order of naming audacity
Prompt engineering (2020 onward). You wrote better prompts. The model got better and started understanding worse prompts. The practice quietly became "just describe what you want" and nobody held a funeral. Peak era: elaborate system prompts explaining that the model was a helpful assistant who should be honest. The model already knew. The prompt was load-bearing only for the engineer's confidence.
Context engineering (June 2025). Toby Lutke named it. Karpathy amplified it. The internet misattributed it. The underlying activity — deciding what information the model needs to do its job — predates LLMs by however long humans have been briefing other humans before asking them to do things. The new contribution was giving that activity a name that sounds like it requires a degree. Within weeks, "context engineering" had a LangChain blog post, a Hugging Face explainer, an Anthropic guide, and a GitHub repository with a biological metaphor that progressed from atoms to neural fields. The speed from named to over-explained remains a record.
Harness engineering (February 2026). The OpenAI post describes three engineers spending every Friday cleaning up what they called "AI slop" before they automated that cleanup into a recurring agent task. This is a genuinely useful observation. It is not a new discipline of engineering. It is a description of what happens when you run software in production and things go wrong, which has been happening since software existed in production.
AI slop is low-quality, mass-produced digital content generated by artificial intelligence that lacks human effort, meaning, or artistic value
Why this keeps happening, and who benefits
Naming game is not accidental and it is not innocent. A new term does three things simultaneously: it creates a hiring category, it creates a product category, and it creates a reason to hold a conference. All three monetize faster than the underlying practice matures.
Vendors benefit most cleanly. The company whose engineer names the discipline owns the default tooling search. OpenAI documented harness engineering using Codex. OpenAI sells Codex. The educational content is the distribution strategy wearing a lab coat.
It is just how technology markets work. The observation worth making is that it works every single time, on an accelerating schedule, with no apparent ceiling on how quickly a named practice can generate a certification program.
Engineers benefit more ambiguously. A new title justifies a salary band and provides a legible identity in a market where "I work with AI" is too broad to be useful.
The cost is that the identity couples to practices with an expiry date.
The prompt engineer of 2022 discovered this. The context engineer of 2025 is discovering it now. The harness engineer of 2026 has perhaps eighteen months before the runtime absorbs the harness and the job title requires a new noun.
Predictions — clearly labeled as such
Following are forward-looking extrapolations that are likely to emerge soon. I want to present these early so that if they catch the attention of influential voices or gain traction publicly, they can spark a self-reinforcing cycle — from hiring categories to product ecosystems to conferences — ultimately unlocking significant value. And who knows, it might even make me a bit famous.
The next term will probably be verification engineering, describing the practice of checking whether agent output is correct before it causes a problem in production. This is currently called testing. It will get renamed when a sufficiently publicized production failure is traced to inadequate output validation from an autonomous agent, and when that failure generates enough LinkedIn posts to constitute a discourse.
After that, something like decomposition engineering — the practice of breaking high-level goals into units of work that agents can handle without producing nonsense. The OpenAI harness post describes this as their team's primary job: working "depth-first, breaking down larger goals into smaller building blocks."
This activity already has a name in project management. It will get a new name when someone publishes a paper showing that agent output quality correlates more strongly with task decomposition quality than with model selection. The paper will be correct. The naming will still be funny.
At some point the industry will notice that the "prior art" column and the "AI engineering term" column describe the same activities, and software engineering — which has existed since the 1960s — will be quietly declared to have been context-harness-verification engineering all along. A retrospective blog post will be written. It will get many LinkedIn reposts.
What actually transfers
Why i wrote this satire ?
Building reliable systems around non-deterministic components is genuinely hard. The existing vocabulary of software engineering does not perfectly fit — a prompt is not a function, a context window is not a database, an agent failure is not a standard exception. The gap in vocabulary is real, and new terms can be useful even when the underlying activity is old.
The mistake is not naming practices. The mistake is mistaking the name for the skill. The engineer who understands why a system should behave a certain way — and can specify, verify, and maintain that behavior across model versions — will be fine regardless of what the current term is. The engineer who has mastered the current term and little else will be retraining when the next model ships.
The models will keep improving. The limitations will keep shifting. The terms will keep coming. And somewhere, a course will always be ready before the ink on the blog post is dry.
