Aug 2, 2026 · 7 min read
Two words appear constantly in AI engineering, often in the same conversation, often describing the same code: harness and scaffolding.
They are used as synonyms. They are closer to opposites.
The distinction is not vocabulary. It determines which parts of your system will still exist in a year, where your engineering effort should go, and which parts of your codebase you are quietly writing off every time a new model ships.
Start with where the words come from, because the physical meaning transfers almost perfectly.
Scaffolding surrounds a building under construction. It is external, temporary, and it exists because the structure cannot yet support itself or the work being done on it. Scaffolding is a signal of incompleteness. The moment the building can stand on its own, the scaffolding comes down. Nobody admires the scaffolding on a finished building, because a finished building does not have any.
A harness is the opposite kind of object. A harness goes on something that is already strong: a climber, a horse, an engine on a test bench. It adds no capability. It channels force, constrains movement, and catches failure. You do not put a harness on something weak. You put one on something powerful enough to cause damage if it moved without constraint.
One structure compensates for weakness. The other manages strength.
Scaffolding is everything you build to compensate for what the model cannot do on its own.
It looks like this: prompt chains that decompose a task the model cannot hold in a single pass. Few-shot examples teaching a format the model does not reliably produce. Hand-written reasoning steps that walk it through an order of operations. Output parsers that repair malformed responses. Retry loops that resample until something valid comes back. Manual splitting of one task into six calls because one call fails.
All of this is legitimate engineering. It is also, precisely, a measurement of the distance between what the model does and what you need. Scaffolding is gap-filling code, and the size of it is proportional to the model's weakness at one specific moment in time.
Which leads to the property that matters: scaffolding has a shelf life.
I have watched this happen repeatedly, and it always follows the same shape. Elaborate chain-of-thought prompting became unnecessary once models reasoned by default. Hand-built tool-calling loops, the ones that parsed raw text looking for a function name and arguments, were absorbed into native tool use. Careful multi-step decomposition pipelines collapsed into a single call. Formatting scaffolds were replaced by structured output. Each time, months of correct, careful work stopped being an asset and became something to delete.
That is not a failure of engineering. The scaffolding was right when it was written. It was simply never going to be permanent.
The harness is everything surrounding the model that does not depend on the model being weak.
It looks like this: the evaluation suite that tells you whether a change made things better or worse. Observability that records every call, input, output, latency, and cost. The permission layer deciding what the system is allowed to touch. Sandboxing for code execution. Rate limits and spend ceilings. Schema validation at every boundary where probabilistic output crosses into a deterministic system. Defined fallback behavior when a provider fails. Audit trails. Human approval gates on irreversible actions. The replay suite that runs known cases against a new model before it reaches production.
None of this makes the model smarter. That is the entire point.
The harness does not add capability. It makes capability safe to deploy and makes change measurable. It is the difference between a system that produces output and a system whose output you can defend.
One question sorts any component cleanly:
What happens to this code when the model gets significantly better?
If it becomes unnecessary, it was scaffolding. If it becomes more necessary, it is harness.
Better models need less scaffolding and more harness. This is counterintuitive, and it is the most important consequence of the distinction. A more capable model takes on larger tasks, acts with more autonomy, touches more systems, and has correspondingly more room to be confidently wrong at a larger scale. Every increase in capability increases the value of constraint, observation, and evaluation.
The stronger the horse, the more the harness matters.
It helps to think about the two as assets on a balance sheet.
Scaffolding depreciates. Every model release erodes it. The work was necessary, but its value curve points downward from the day it is written. A team that has spent a year on prompt orchestration, task decomposition, and output repair holds something a single provider announcement can devalue.
The harness compounds. An evaluation suite built two years ago is worth more today than the day it was written, because it has accumulated cases, caught regressions, and can be pointed at any model you want to test. Observability built for one system teaches you about every system that follows. Permission and audit layers survive model changes entirely, because they were never about the model in the first place.
This is a resource allocation decision, not a philosophical one. If most of your effort goes into scaffolding, you are building on a depreciating base and you will feel it with every release. If most of it goes into the harness, each release makes you faster, because you can evaluate and adopt a new model in days rather than quarters.
Scaffolding is visible and satisfying. It produces a demo. You watch a broken output become a correct one. The progress is immediate and legible to everyone in the room.
Harness work produces nothing visible. An evaluation suite makes no demo better. Observability adds no features. A permission layer only ever prevents things from happening. Its value arrives later, as iteration speed and as incidents that never occur, and both of those are difficult to attribute to anyone.
So the incentives push toward scaffolding, especially early, especially under deadline. The result is a shape I have seen many times: a system with sophisticated prompt orchestration and no way to tell whether any change improved it. Teams in this position cannot upgrade their model, because they have no way to know what an upgrade would break. They are held in place by the absence of a harness while holding a large investment in scaffolding they cannot safely remove.
Being unable to adopt a better model is a serious place to be, and it is almost always a harness problem rather than a model problem.
None of this argues for skipping scaffolding.
Models are not good enough at everything, and shipping means working with what exists today rather than what will exist next year. Scaffolding is how you deliver now. The mistake is not building it. The mistake is not knowing that you built it.
Scaffolding should be written the way you would write something you intend to delete, because you will. Keep it isolated. Mark it clearly. Do not braid it through your business logic. Above all, do not let a workaround for a temporary model limitation quietly become load-bearing, because when that limitation disappears you will not be able to find the workaround, let alone remove it safely.
The worst outcome is not having too much scaffolding. It is having scaffolding that has fused with the harness, until nobody can tell which is which.
For any component in the system, a few questions resolve it quickly.
Does it exist because the model fails at something? Scaffolding. Would you keep it if the model were perfect? Harness. Does a better model make it smaller? Scaffolding. Does a better model make it more important? Harness. Is it about getting output at all? Scaffolding. Is it about being able to trust that output? Harness.
The final pair matters most. Scaffolding encodes facts about the model. A harness encodes facts about you: what you require, what you permit, what you can tolerate, and what you must be able to prove afterward.
Facts about models expire. Your requirements do not.
The industry discusses AI progress as model progress. But the durable engineering work is not in the model, and it is not in the scaffolding wrapped around it.
Scaffolding is what you build because the model is weak. A harness is what you build because the model is strong.
One of them comes down when the building is finished. The other only gets tighter as the thing inside it grows more powerful.
Alan Salomon
AI engineer and writer