The best engineer on your team probably doesn't write the most code.
They orchestrate. They validate. They manage agents like interns, scoping work, reviewing output, redirecting when something drifts. The center of gravity moved underneath them and most job descriptions haven't noticed.
We still hire for the software engineer of 2019. The job became something else. I think in 2026 you should be hiring harness engineers. I want to make the case for that term even though it might not stick.
What actually changed
A few things happened at once and they compounded in ways nobody predicted.
The post-COVID correction reset engineering teams. Easy money disappeared, headcount got tighter, every hire carries more weight. Olivia Moore at a16z calls interviews "low ROI" for companies. She is right, and the ROI is getting worse. Entry-level startup hiring is down 73% (Dover, 2025). Each seat has to produce more now. At the same time, AI moved from novelty to daily infrastructure. Not in demos. In actual workflows where people ship real things. Meta now gives candidates Claude, GPT-5, and Gemini during 60-minute coding interviews (Hello Interview, 2025-2026). Anthropic reversed its own AI ban in hiring. Canva encourages candidates to use Cursor or Copilot in interviews. Meanwhile, Google pulled engineers back to in-person interviews. The industry hasn't settled on one answer yet, but the pattern is the same: stop pretending AI use is outside the job. Put it inside the evaluation.
The output of one engineer changed. Not because every engineer became 10x. The multiplier is real, but only for engineers who can actually harness AI rather than just sit next to it. The gap between engineers who direct systems and engineers who type into them got wider this year. It's not closing.
The evolution
Prompt engineering was the 2023 obsession. It mattered the way knowing how to write a good Google search still matters. Useful, but not a career. Context engineering became the deeper discipline through 2024 and 2025: what information reaches the model, when, and in what structure. Retrieval, memory, tool access, system prompts, state management. It moved the conversation from clever wording to actual system design. Harness engineering is where this lands, IMO: the full-stack operating model for building with agents. You don't just talk to AI or feed it information. You build the control system. You operate it.
Prompt engineering is learning to drive. Context engineering is learning to navigate. Harness engineering is managing a fleet.
OpenAI recently published about this same idea, using the same term. It's gaining traction because it describes something real that didn't have a name until now.
What separates good from bad harness engineers
The easiest mistake is confusing AI usage with AI judgment. Plenty of engineers use AI constantly but without intention behind it.
The best people don't treat an agent like a magic box. They treat it like a junior developer who is eager, fast, and confidently wrong about 20% of the time. That means scoping work tightly, assigning bounded tasks, reviewing intermediate output instead of waiting for the final result. This is why experienced engineering managers and senior ICs often adapt unusually well to agentic workflows. They already know how to decompose work, create checkpoints, and inspect progress. They have been doing it with humans for years.
Harness engineers also shape the environment agents operate in. Tests as contracts. Consistent naming. Predictable patterns. Strong CI. An agent-friendly codebase isn't one with the most comments. It's one where the next action is inferable.
And then there is judgment. AI can produce code quickly. That stopped being the hard part a while ago. The hard part is deciding whether that code is correct, secure, maintainable, and fit for the system around it. AI-assisted code has 1.7x more major issues when judgment is weak (Second Talent, 2025). AI is only a speed gain if the engineer knows how to validate, reject, and steer. Otherwise they spend the savings cleaning up their own mess.
Output is cheap. Judgment is scarce. That is the whole filter now.
How to hire for it
Most job descriptions are still written for a world that doesn't exist. "5+ years of Python." "Strong React experience." "Familiarity with AI tools is a plus." That attracts coders. Not the people I have been describing.
One question I keep asking in interviews: walk me through the last thing you shipped with AI assistance. Where did the model help? Where was it wrong? What did you rewrite? What tests did you add because you didn't trust the output? That reveals more in five minutes than a whiteboard session ever did.
The market is already moving this way. Meta didn't redesign its interview process for fun. The skill changed, and the evaluation had to change with it.
The next problem is evaluation. Once you know you need harness engineers, you still have to figure out how to interview for the role without collapsing into security theater or proctoring games. I'll get into that in Part 2. But here is the filter: if your interview cannot tell the difference between an engineer who used AI with judgment and one who copy-pasted blindly, it is not an interview anymore. It is paperwork.
If you want to see what AI judgment looks like when you capture the process and not just the output: Fairground is an interview platform that captures how candidates work with AI, not just what they submit. Async coding screeners, live collaborative interviews, and AI-ready scorecards in one place. 100 free credits to try it. No credit card. No sales call.
Get started with Fairground in just few mins.
Plug and Play. Works well with your existing ATS.
100 Free Credits
