There is an amusing pattern in the vocabulary of applied AI. Roughly every six months, a new -engineering term appears. And every time, it appears at the exact moment the previous discipline stopped being enough.
First prompt engineering. Then, once it became clear that phrasing was not the main lever, context engineering. Then, as agents started chaining dozens of steps, loop engineering. And now harness engineering, as we discover that the scaffolding around the model weighs as much as the model itself.
A caveat on usage: these names are not settled. "Context engineering" has broad consensus, "harness" circulates mostly among people who run evaluations, and "loop engineering" means two or three different things depending on who you ask. That instability is part of the story — we name things quickly when we are discovering them as we go.
Let us go through them honestly: what each one actually solved, and where it stops.
# Four disciplines, four ceilings prompt how I phrase it ↳ ceiling: tricks don't survive the next model context what the model sees ↳ ceiling: who maintains it over twelve months? loop how the agent iterates ↳ ceiling: a great loop, the wrong goal harness what surrounds the model ↳ ceiling: measured per task, not per product
1. Prompt engineering: the phrasing
What it solved. That how you ask matters. Breaking a task down, specifying an output format, showing an example: these are moves that work, and they saved a lot of people a great deal of time.
Where it stops. Wharton's generative AI lab put the most popular recipes on the test bench — politeness, tips, threats, expert personas, "think step by step". The verdict is unforgiving: contingent effects, unpredictable, sometimes expensive in tokens for no gain at all. Ethan Mollick sums it up: what works is "specifying your goals, your output, what good and bad results look like, and how to test".
And there is something worse than ineffectiveness: expiry. A system prompt finely tuned for one model can hold back the next, whose planning abilities have changed. Libraries of "generic" prompts age in silence. That is technical debt, with the peculiarity that it never breaks the build — it just degrades your results without warning.
2. Context engineering: what the model sees
What it solved. The most important shift of the past two years. We understood that the lever was not the phrasing but the material: which files, which rules, which past decisions, which documentation enter the window. The consultancy Archwise puts it well — treat context as infrastructure, on the same level as code or data.
Where it stops. On a question of ownership, not of technique. The discipline says very well what to put in the context. It says far less about who maintains it when the team grows, when the product changes, when whoever wrote the guidance file has left.
The symptom is universal: a context file at the root of the repository, excellent the day it is written, obsolete six months later, and which nobody feels responsible for updating because it belongs to no ticket. Context is treated as infrastructure in the discourse, and as a draft in practice.
3. Loop engineering: the shape of the iteration
What it solved. An agent is not an answer, it is a loop: plan, act, observe, repeat. How you draw that loop changes everything — when to stop, when to re-read your own work, when to delegate to a sub-agent, when to ask a human. Loops with a verification step produce markedly more reliable results than loops that charge ahead.
Where it stops. On an uncomfortable fact: an excellent loop checking the wrong criterion will converge, confidently, on the wrong result. That is in fact the most dangerous property of a good loop — it is persuasive. It iterated, it tested, it corrected. It simply was never told that the feature requested was not that one.
A second, quieter limit: a loop is designed per task. It does not compound. What it learned while fixing a mistake stays inside its execution trace, and disappears with it.
4. Harness engineering: the scaffolding around the model
What it solved. The most recent realisation, and probably the most underrated: what you consume is never "a model", it is a model plus its harness. The tools you give it, the sandbox it runs in, the permissions, the hooks, the memory, the sub-agent orchestration, the evaluation sets. With an identical model, two harnesses give you two different products — the gaps observed on benchmarks like ARC-AGI made that impossible to ignore.
Where it stops. The harness is a piece of engineering, measured on tasks. That is its strength — and its boundary. An excellent harness tells you how well the agent succeeds at what you give it. It says nothing about what you should have given it, nor who decided that, nor what it cost relative to what shipped to users.
And like the prompt and the context, it belongs to whoever writes code. The person deciding the product has no access to it, and no reason to touch it either.
What they share: all four optimise an execution
Taken together, they cover remarkably well the journey from the moment you press Enter to the moment the agent stops. That is genuine progress, and nothing below calls it into question.
But they share three blind spots, and they are the same at every layer:
- They live at the session level. What was learned, settled or corrected during one execution does not survive into the next — unless you re-inject it by hand, which nobody sustains over twelve months.
- They belong to whoever writes code. The prompt, the context, the loop and the harness live in the repository and on the developer's machine. The person deciding what to build is not in the loop — literally.
- They optimise the answer, not the question. None of them will tell you whether the goal was worth pursuing, who agreed to it, or what the shipped feature actually cost.
In other words: we spent eighteen months improving the quality of execution. We have done very little on what decides the execution, and on what remains of it once it is over. The next ceiling is not a model problem, nor a harness problem. It is an organisational one.
What Survol adds — and exactly where
We have no fifth -engineering term to offer, and it would be slightly ridiculous to invent one. What we observe is that past a certain point, it stops being engineering: it becomes product steering, with instruments. Three blind spots, three concrete answers.
Making context outlive the session
In Survol, what matters is not reloaded on every run: it persists. Each feature's specification is versioned and linked to its shipped versions. Product decisions have a full lifecycle — open, accepted or rejected, then implemented — with their dates, their voters and their why. The organisation's technical constraints are injected at the start of every session, at three levels of authority, and every application is logged.
The consequence is that context stops being a file someone has to remember to update. It becomes a by-product of the work: deciding is already writing it down.
Getting steering off the developer's machine
The prompt, the context, the loop, the harness: four things a PM will never see. Survol is web first, and that is a deliberate design choice — the person deciding the product should not have to install anything to see where their request stands. They describe the feature, the team settles the open decisions, and that approved spec becomes the instruction sent to the agent. The prompt is no longer typed: it is derived from what was decided.
Connecting execution to what ships
This is where the four disciplines structurally have nothing to say, and yet it is the question executives ask. Survol tracks consumption per session, per version and per feature — not just per person. And a feature's status is derived from what is actually deployed: preview approved, test book run on a named environment, released to production. A loop that runs beautifully without ever producing a shipped version stands out immediately.
What this does not exempt you from
Let us be clear, because the opposite would be dishonest: Survol replaces none of the four disciplines.
- You will still need a good harness — that is the job of the tool that executes, not ours.
- You will still need a well-drawn loop, with its verification steps.
- You will still need well-composed context. We build part of it from the spec and the decisions, but the discipline is the same.
- And there will still be prompts, somewhere. It is just that nobody should have to write them by hand to launch a feature.
What we claim is more modest, and more precise: these four disciplines share a ceiling, that ceiling is not technical, and none of them was ever meant to break through it.
The takeaway
- Every -engineering term appeared when the previous one stopped being enough. That is a good indicator of where the difficulty is moving.
- All four optimise an execution: what happens between Enter and the agent stopping. None claims to do more, and that is legitimate.
- Their blind spots are identical: nothing persists, everything belongs to whoever writes code, nothing connects spending to what ships.
- Breaking through that ceiling does not require a bigger model or a finer harness. It requires treating the spec, the decisions and the costs as first-class objects. That is what we are building.
The next -engineering term will arrive regardless — we are taking bets for the autumn. But there is a more interesting hypothesis: perhaps the next step up will carry no -engineering name at all. Because at that point, as Mollick puts it, "it's just management".
