What harness engineering actually means
Harness engineering is the practice of designing everything around an AI model – the context, tools, constraints, and feedback loops – so it becomes a reliable, production-ready coding agent. The short version is a formula: Agent = Model + Harness.
The model is the raw brain. The harness is everything that steers it, checks its work, and helps it recover from mistakes.
The term is new, but the idea is now widely shared. Thoughtworks' harness framework defines the harness as everything in an AI agent except the model itself. The practice went mainstream in 2026, after OpenAI, Anthropic, and Thoughtworks all wrote about it and search interest spiked.
And the results can be striking. OpenAI's Codex team shipped an internal beta with zero lines of manually written code, in roughly one-tenth the time hand-writing it would have taken.
That's the promise. The rest of this post covers how to get there, and why security belongs inside the harness from day one.
Why AI coding agents need a harness
A raw model is not an agent. Models are non-deterministic – the same prompt can produce different code on different runs – and they know nothing about your codebase, your rules, or your goals.
That gap between "impressive demo" and "reliable teammate" now matters to almost everyone. The 2025 Stack Overflow Developer Survey found that 84% of developers are using or planning to use AI tools, and 51% of professional developers use them daily.
But the frustration is real too. The top complaint, cited by 66% of developers, is AI output that is almost right, but not quite.
Speed gains are also easy to overestimate. A 2025 METR study found that experienced developers using AI tools took 19% longer to finish tasks, even though they expected to be faster.
None of this is a case against agents. It's a case that autonomy needs structure, and the harness is that structure. It turns an unpredictable model into an agent you can trust with real work.
Harness vs. prompt vs. context engineering
These three disciplines nest inside each other. Prompt engineering shapes the wording of a single request. Context engineering manages what the model sees before it answers.
Harness engineering has the widest scope. It covers the whole system around the model: the tools it uses, the environment it runs in, the constraints it follows, and the feedback it gets back.
DisciplineWhat You ShapeQuestion It AnswersPrompt engineeringThe wording of a single requestHow do I ask for what I want?Context engineeringWhat the model sees at inference timeWhat information does the model have?Harness engineeringThe full system around the modelHow does the agent act, check, and correct?
Think of it as zooming out. Prompt and context engineering both feed the model. Harness engineering governs how the whole agent behaves.
The building blocks of a harness
A useful way to group harness parts is by direction. Some steer the agent before it acts. Others hand it signals after it acts so it can self-correct.
Thoughtworks calls these two categories guides (feedforward) and sensors (feedback). Together they form the loop that makes an agent reliable.
Guides: steering the agent before it acts
Guides set expectations up front, so the agent starts in the right place instead of guessing.
- Rules files – Project files like
AGENTS.md
orCLAUDE.md
that capture your conventions, commands, and boundaries. - System prompts – Standing instructions that define the agent's role and default behavior across tasks.
- Structured context – Curated code, docs, and examples the agent sees, instead of a raw dump of the repo.
- Tool selection – The specific tools you expose, which shapes what the agent can and cannot do.
Sensors: helping the agent self-correct
Sensors are the feedback half of the loop. They emit machine-readable signals the agent can read and act on without a human in the middle.
- Linters – Flag style and syntax problems the moment code is written.
- Compilers – Confirm the code actually builds before it moves forward.
- Test suites – Prove the behavior is correct, not just that the code runs.
- Quality gates – Block work that fails a defined bar.
A good sensor follows one pattern: success is silent, failures are verbose. The agent only hears about what went wrong, with enough detail to fix it.
The best teams also ratchet. Every recurring mistake becomes a permanent rule or sensor, so the agent never repeats it.
Tools, memory, and execution environments
The last building blocks give the agent hands and a place to work. This is where autonomy becomes real.
- MCP servers and tools – Standard connections that let the agent call outside systems and data.
- Skills and sub-agents – Reusable capabilities and specialist helpers for focused tasks.
- Sandboxes – Isolated environments where the agent can run commands safely.
- Memory and context management – Filesystem, Git, and state handling that keep long tasks on track.
Notice what autonomy includes here: agents install packages and run commands on their own. That single fact is why security becomes a sensor you cannot skip.
The missing sensor: security in the harness
Most harnesses have sensors for correctness, style, and tests. Almost none have a sensor for security.
That gap is nobody's fault. Most security tooling was built for human-paced review cycles, not for agents that write and install code in seconds. But the same agents that produce working code also produce insecure code and pull risky dependencies, and the evidence is consistent across sources.
Start with our own numbers. Our AI code security benchmark found that over 80% of AI-generated code contains vulnerabilities.
Third-party research agrees. Veracode's 2025 GenAI code security report found that 45% of AI-generated code samples introduced OWASP Top 10 vulnerabilities, and that security did not improve with newer, larger models.
The pattern shows up in the wild too. In a large-scale study of AI code on GitHub, researchers found 4,241 CWE (Common Weakness Enumeration) instances across 77 vulnerability types in 7,703 AI-attributed files.
For engineering leaders, the cost shows up as friction. Bugs caught after code ships turn into blocked pull requests, rework, and interruptions late in the cycle.
A precise security sensor flips that. In our own data, teams see 83% fewer blocked pull requests, because findings are caught during development instead of at review. Security becomes one more capability that helps you ship faster.
So treat it as a first-class harness sensor, alongside the sensors you already run for maintainability, architecture, and behavior.
What a security sensor does in the loop
A security sensor does a few concrete jobs while the agent works. Each one produces a signal the agent can act on right away.
- Verify code as it is written – Run AI static analysis so insecure patterns are caught at the moment of authoring.
- Block risky packages – Stop malicious or hallucinated dependencies before the agent installs them.
- Detect secrets – Catch leaked keys and tokens before they reach a commit.
- Hand back a fix – Return an actionable remediation, not a wall of noise.
Precision is what keeps this useful. Endor Labs uses full-stack reachability to check which findings are actually reachable and exploitable, which cuts up to 95% of alert noise. In practice, that means the agent worries about the unlocked doors an attacker can actually open, not every door in the building.
Supply chain risk is part of the job too. Our research shows open source malware rising sharply, and an agent that installs packages on its own needs a sensor watching that surface.
Wiring security into coding agents
A security sensor only helps if it lives where the agent already works. That means plugging into the coding-agent harness through Hooks, Skills, MCP, and CLI.
Hooks give you deterministic enforcement – a check that runs every time the agent installs a package or commits code. See how hooks that govern coding agents bring visibility to agent actions. That control point matters, because the agent control plane needs a security layer of its own. Without one, no one can see or govern what the agent does.
AURI is that layer. It's Endor Labs' security harness for agentic software development – a security intelligence layer that plugs into these integration points and connects to the agents teams already use, including Claude Code, Codex, and Cursor. You can read the introduction to security intelligence for coding agents for the full picture, or see how we built the security foundation for agentic coding with Cursor.
How to start building your harness
You do not need to build a harness from scratch. Start small, add sensors, and let the agent's own failures tell you what to fix next.
- Pick a prebuilt harness and customize it. Start from a tool like Claude Code or Cursor, then adapt it to your team.
- Add a rules file. Write an
AGENTS.md
orCLAUDE.md
that captures your conventions, commands, and boundaries. - Add feedback sensors, including security. Wire in linters, tests, and a security sensor so risky code and packages are caught in the loop.
- Turn recurring failures into permanent rules. Every time the agent repeats a mistake, encode the fix so it cannot happen again.
- Measure what changed. Track linked pull requests, blocked findings, and rework to prove the harness is working.
Ship fast without shipping vulnerabilities
The harness is what makes an AI coding agent reliable. A security sensor is what makes that agent safe to ship. As agents write more of your code, both halves have to grow together.
Teams have a choice here. Treat security as a built-in sensor and it pays you back in fewer interruptions, fewer blocked pull requests, and evidence-based fixes. Leave it as a late review step and you inherit every finding the agent created, all at once, at the worst possible time.
Book a demo to see how AURI wires security into your agents.
Frequently Asked Questions
What is harness engineering?
Harness engineering is the practice of designing everything around an AI model (context, tools, constraints, feedback loops) so it becomes a reliable coding agent. The formula is Agent = Model + Harness.
Why is it called "harness engineering"?
The name reflects the idea that the harness is everything wrapped around the model. It works like scaffolding that steers and constrains the model so it can do real work safely.
What is a harness engineer?
A harness engineer is usually not a separate job title yet. It's a skill set held by developers and platform engineers who design the harness around coding agents.
How is harness engineering different from prompt and context engineering?
Prompt engineering shapes a single request, and context engineering shapes what the model sees. Harness engineering shapes the whole surrounding system of tools, constraints, and feedback.
What is the difference between harness engineering and agentic engineering?
Agentic engineering is the broad practice of building software with agents, while harness engineering is the specific discipline of designing the harness around the model.
Is Claude Code harness engineering?
Claude Code is itself a harness, so configuring and extending it with rules, hooks, tools, and security checks is harness engineering in practice.
Can harness engineering reduce security risks in AI-generated code?
Yes, by adding a security sensor that verifies code and blocks risky dependencies in the loop, as described in the security harness section above.
What's next?
When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help: