Software Engineering is Dead, Long Live Harness Engineering
First it was Prompt Engineering. Then Context Engineering. Now, it's time for Harness Engineering.
Most developers have a vague understanding of this already, even though the idea itself has not formed as clearly in their heads. Most still focus on the question of:
"When will my software engineering work be completely replaced by AI?"
Well, before that happens, AI has to be used (orchestrated) in a sufficiently proficient way first to replicate the work of software engineers. In terms of speed, we all know that there are no issues with that. Even when working on a single task, sometimes humans are faster, but you can easily run parallel sessions.
Speed is now not an issue, but quality is. Specifically, correctness and optimality. LLMs hallucinate and are very eager to report completion. So solutions are sometimes flat out wrong or sub-optimal. This is when humans come in — to steer (through prompts, rules and skills) and to design (or prompt for it) verification systems.
Initially, we were introduced to the term Prompt Engineering — which honestly sounded ridiculous at first and sounded like the layperson's attempt to pass off what they were doing as something far more technical than it is — but we now know to actually be a real thing. Then came Context Engineering.
Now, you will start seeing Harness Engineering everywhere.
You can think of Harness Engineering as the superset of both Prompt Engineering and Context Engineering. Harness Engineering includes everything from the System Prompt, to Context Management, to rules and skills.
A "harness" is basically everything that wraps around the model that helps it to achieve a particular objective better.
As capable as models get, you can always get better quality outputs if you have a harness specifically built for the use case.
The Evolution of Harnesses
The first harnesses we were introduced to were of course the Chat Harnesses — ChatGPT, @claudeai Web. Then came the Coding Harnesses — Claude Code, @cursor_ai, Codex CLI, @AmpCode, @opencode.
Now, more recently, we are starting to see more varied harnesses, for things such as:
- AI Assistants — @openclaw
- AI Employees — @crewAIInc
- Complete company operations — Paperclip
What This Means for Engineers
It's clear now that manual programming is almost completely dead — the baseline speed for shipping has now increased by an order of magnitude, thanks to coding agents and all other harnesses. Businesses that don't catch up with this will soon get beaten by their competition.
The work that needs to be done now is in building those harnesses for all the businesses. No longer are we writing the code directly. Instead, we are building and designing the system that writes the code. It's a bit like what platform engineering is to application engineering, except harness engineering is far more consequential to the whole business, since the "platform" itself dictates the velocity, efficiency and accuracy of the "application" engineering.
Sure, a non-technical person can prompt their own harness into existence as well, but again, everything is relative. A software engineer would make better steering decisions than a non-technical person. This advantage in experience is still very much relevant. Will it stay relevant forever? That I don't know. But at least for the next 2 years, I am confident in saying that software engineers of today can build more robust harnesses than non-technical people with a significant difference.
So what say you, software engineer? Will you now pick up Harness Engineering too, or is it time now for you to pick up farming?