For most of computing history, "software engineer" meant one thing: a person who writes code. You sat down, you typed, and the value you created scaled roughly with how fast and well you could think in syntax.
That era is ending. Not because writing code is going away (code still has to get written), but because the bottleneck has moved. Increasingly, the most valuable engineers aren't the ones writing the code themselves. They're the ones building and maintaining the systems that let AI agents write the code: the evals, the sandboxes, the tools, the feedback loops, the guardrails. The harness.
This isn't the first time a profession has flipped like this.
The weavers became the loom mechanics. In 1800, weaving was a craft. By 1900, the people who mattered in textile mills weren't weavers; they were the mechanics who kept the looms running. The work was still about cloth, but the leverage had moved one level up: from operating the tool to maintaining the machine that operated the tool.
The farmers became the equipment specialists. A 19th-century farmer's edge was endurance and skill with a plow. A 21st-century farmer's edge is knowing when the GPS-guided combine needs servicing and how to swap a sensor at 2 AM during harvest. The crops still get planted. The job description got rewritten.
The switchboard operators became the network engineers. Connecting phone calls used to be manual labor, requiring thousands of people physically routing wires. Then it became infrastructure. The work didn't disappear, it abstracted upward. Telecom didn't shrink; it grew enormously. But the human role moved from "make the connection" to "design and maintain the system that makes connections."
The pattern is consistent: when a task gets automated, the important job is no longer doing the task. It's maintaining the machine that does the task. And the people who make that transition early tend to do well, because the machine is always more leveraged than the hand.
Software is now living through its version of this. An AI agent can write a function, but it needs:
- Evals that catch when it's wrong
- Sandboxes that contain what it does
- Tools that give it the right primitives
- Feedback systems that teach it your codebase
- Observability so you can debug what it tried
None of that builds itself. All of it requires deeply technical people who understand both software and the quirks of working with models. That's harness engineering and that's where the leverage is moving.
The good news: this isn't deskilling. If anything, it's the opposite. Building good harnesses requires more systems thinking, more taste, and more judgment than writing the next CRUD endpoint by hand. You're designing the conditions under which work happens rather than performing the work directly. That's a more interesting job, not a worse one.
If you're a software engineer wondering where to point yourself next, the honest answer is: toward the harness. Learn evals. Learn agent tooling. Learn how to make models do useful work reliably. The looms still need mechanics. They always have.
Top comments (0)