---
title: An introductory guide to harness engineering
date: 2026-07-10
---

<figure class="writing-figure writing-figure--cover">
  <img src="/writing/harness-engineering/cover.jpg" alt="An illustration of a person directing a large mechanical system" />
</figure>

<p class="writing-credit"><em>credit to <a href="https://x.com/AbstractDL">@AbstractDL</a> for the image</em></p>

Regardless of where you personally land in the grand spectrum of AI adoption/psychosis, if you are a software engineer of any kind in the age of AI, you must have wondered: what value do I stand to contribute if AI really does take over? If coding is solved, will there be any engineering left to do?

The truth is, in some ways, code has always been trivial. Sure, it has always required a certain level of skill, but at the end of the day, code is simply the medium through which we express **engineering decisions**. Whether you are coming up with new memory synchronization techniques for a concurrent runtime or choosing to make a variable’s type a short over an integer, the implementation is the easy part once every engineering decision has been made. **What’s interesting about agents is not their ability to fill in the code but the new possibility of offloading these engineering decisions to them.**

I’m sure some people will recoil at the idea of offloading engineering decisions to agents, but what my examples above are meant to illustrate is that big or small, decisions are decisions, and if you are a person interested in ~~vibe coding~~ *Agentic Engineering*™, you’re guilty of wanting to offload them to agents yourself! If you actually wanted to make a spec of your entire project down to the data structures you’re using, how you’re traversing them, and whether you’re passing variables by reference or value, we’d be calling that coding, and you don’t need a model to do that.

So we can see that there is this tension: we want to take advantage of coding agents to offload the engineering decisions we don’t particularly care about. At the same time, we want good output from the agents, and what’s tricky here is that "good" isn’t obvious to the model; a lot of the time, it's undefined. Here is where harness engineering (finally) comes into play, as the meta layer of engineering that systematically helps shape how our agents behave.

## Harness Engineering

When I talk about agent harnesses, I’m sure names such as [@cursor_ai](https://x.com/cursor_ai) or Hermes Agent ([@NousResearch](https://x.com/NousResearch)) come to mind. These are great examples of deeply technical harnesses that fundamentally shape the model’s output or function. The team at Cursor works tirelessly on their harness, and by concerning themselves with things such as prompt-cache mechanics, context management, or tool design, they manage to have an agent that consistently scores better on coding benchmarks than the same models on the provider’s own harness.

<blockquote class="twitter-tweet" data-theme="dark">
  <p lang="en" dir="ltr">Cursor's biggest underrated advantage is that they've somehow tamed Gemini. It's the only harness that actually keeps Google models productive and on task.</p>
  &mdash; Theo (@theo) <a href="https://x.com/theo/status/2024839053900910612">February 20, 2026</a>
</blockquote>

On the other hand, Hermes Agent deeply shapes how the model behaves, turning it from a passive tool that reacts to your query to an active participant that is able to drive tasks to completion and take on initiative. Now, I’m not trying to say that in the future we’re all going to be working at Cursor doing this type of work, but I need you to understand that **there is real engineering to be done here**.

> So how can I benefit from harness engineering right now?

By adding abstractions, and creating custom harnesses for your own work.

Starting a project in 2026 shouldn’t be so much about choosing the technical stack you’re going to use, as it should be about **deciding what engineering decisions are going to define your project**, which decisions will constitute your comparative advantage over the model’s default answer (in twitter words: where your *taste* will create your *moat*), and what decisions you are willing to offload to agents.

Once these decisions are nailed down, your job then becomes to set up the system that allows the project to be developed in this way. Now, this is something that we have all been doing inadvertently and to different extents. Vibe coding with Copilot and sometimes choosing to review the code where it matters, vs letting it rip for the front end, is technically a system, but in this article I am advocating for the use of custom harnesses, especially as projects grow in size.

I’ve recently been doing some work in overhauling my personal website, after many months of work-shopping interesting gimmicks, I came up with the idea of featuring a Nintendo 64 emulator with a custom ROM. My idea was that since I am the one writing the game, I control its memory, and since this game will be running on an emulator on my website, the emulator’s memory should be accessible from the website. Therefore, I wanted to set apart a limited chunk of memory from the game, treat it as a “mailbox” and have my website react according to events that happen in the game.

<blockquote class="twitter-tweet" data-theme="dark" data-conversation="none">
  <p lang="en" dir="ltr">Cool personal website bro, but can you interact with it through a custom n64 ROM that is using left over space in the emulator's RAM to communicate with the site?</p>
  &mdash; Miguel Serna (@miguelfserna) <a href="https://x.com/miguelfserna/status/2074933520162549996">July 8, 2026</a>
</blockquote>

This is a simple premise, but one with a couple of moving parts:

<figure class="writing-figure">
  <a href="/writing/harness-engineering/parts-at-play.jpg" target="_blank" rel="noreferrer">
    <img src="/writing/harness-engineering/parts-at-play.jpg" alt="The website project's 3D models, game, emulator, website, and mailbox layers" />
  </a>
  <figcaption>parts at play</figcaption>
</figure>

Once the parts are laid out, it is my job to discern what decisions I want to make and put the tasks into different buckets. I really don’t care how the website is built as long as it is lightweight and supports the emulator correctly; this task and the decisions that emerge from it I can happily offload. Game feel on the other hand, is where my taste and vision can really shine in making the project unique, so I’ll position myself close to the development.

<figure class="writing-figure">
  <a href="/writing/harness-engineering/decision-buckets.jpg" target="_blank" rel="noreferrer">
    <img src="/writing/harness-engineering/decision-buckets.jpg" alt="Project decisions divided into decisions the author keeps and decisions delegated to agents" />
  </a>
  <figcaption>decision buckets</figcaption>
</figure>

Finally, we set the harness up, and start the development.

<figure class="writing-figure">
  <a href="/writing/harness-engineering/harness-machine.jpg" target="_blank" rel="noreferrer">
    <img src="/writing/harness-engineering/harness-machine.jpg" alt="A harness workflow with context, build, automated checks, taste review, rollback, and memory loops" />
  </a>
  <figcaption>the harness as a machine</figcaption>
</figure>

The actual setting up of the system this time was simple; models are extremely good at calling each other and scripting events, at the same time, I want to point out that this diagram mainly describes a *workflow* that is enforced by the harness, the actual workflow is not the harness. In my definition of these "custom harnesses," I also include the rules, skills, and guardrails you set up for the project.

This is where the other half of the new engineering lives: you observe the model's behavior and use this tool set to shape it. For example, an agent's default Blender output completely ignores the N64's constraints (polygon budgets, vertex colors instead of textures, the emulator's rendering quirks) in my project, it was extremely important for me to observe the work, notice the point of failure, and write skills so that my agents would not make the same mistakes.

<figure class="writing-figure">
  <a href="/writing/harness-engineering/chassis.jpg" target="_blank" rel="noreferrer">
    <img src="/writing/harness-engineering/chassis.jpg" alt="The harness chassis: rules, skills, guardrails, and review passes" />
  </a>
  <figcaption>the chassis</figcaption>
</figure>

In conclusion, I hope this article helps illustrate what the new meta layer of engineering that is starting to form looks like, and I urge anyone reading this to start experimenting with custom harnesses in their projects. My example was highly abstracted and it still worked wonders on the project; there is a lot of real technical work to be done in setting up these “code factories”.

personal note: I am a rising senior studying computer science at UT Austin. If you’re looking to hire people who get working with agents, I am looking for jobs after I graduate. I’ve been cooking up some cool projects this summer and will start releasing them soon.
