Skip to content

A melhor forma de entender a engenharia por trás de um Harness

Read the Portuguese translation →

Author: Cortes do Rafael Quintanilha · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: A melhor forma de entender a engenharia por trás de um Harness · Channel: Cortes do Rafael Quintanilha · 06:47 · Watch on YouTube

Topics: AI agents, AI evaluation and benchmarks, Software engineering with AI, AI developer tools

Harness engineering is the practice of building systems that guide and control AI models, which can behave unpredictably. A harness combines tools, context management, permissions, sandboxing, orchestration, and observability to help a model perform tasks as intended. Harnesses range from larger products such as Codex, Claude Code, and Cursor to minimalist options like pi, which users can extend to suit their needs. Software engineers may build harnesses for personal workflows or for a specific company or team domain.

  • A harness is compared to straps or a leash that controls where an animal goes; for AI, it is a system that guides a model’s actions.
  • Harness engineering becomes important as AI models gain freedom to perform more tasks, because models are stochastic and unpredictable.
  • Tools in a harness can include MCPs, CLIs, terminal commands, and file reading and writing.
  • Context management includes instructions, memory, compression, and summaries.
  • Permissions and sandboxing help keep a model in a controlled environment.
  • Orchestration can delegate execution to cheaper and faster sub-agents after a more capable model has planned the work.
  • Codex, Claude Code, Cursor, and antigravity are named as examples of harnesses; pi is described as a minimalist harness that can be extended.
  • Observability, including traces and evals, helps assess whether a harness is behaving as intended and diagnose problems.
  • Engineers may build harnesses for personal use or create domain-specific harnesses for a company or team.
Start Chapter Summary
00:00 What a harness is A harness is introduced as a system that guides and controls an unpredictable AI model.
01:33 The anatomy of a harness The discussion covers models, tools, context management, permissions, and sandboxing.
03:07 Orchestration and harness examples The speaker explains sub-agent orchestration and compares larger harnesses with the minimalist pi.
05:13 Observability and use cases Traces and evals help diagnose model choices, and engineers can build harnesses for themselves or for a team or company.

we are talking about building a system, a system that controls an AI model. — 00:30

Another thing the harness needs to have is context — 02:35

It is a minimalist harness. — 04:42

Here we are usually talking about traces, we are talking about evals — 05:13

the software engineer now needs to learn how to build this harness for two distinct situations. — 06:15

Harness Engineering, Harness, GPT-4, GPT-6 Astra, MCP, Codex, Claude Code, Cursor, Pi, Luna

00:00 So let’s start by understanding that we are talking about this new discipline called harness engineering, so engineering a harness, building a harness, knowing how to create a harness in the best way. Obviously, we need to understand what a harness is, right, so I can build one, what is it, okay? The best way I see to explain what a harness is is through this figure right here. A harness is nothing more than this set of bands and straps, right, things you put on to tie something, to secure an animal, for

00:30 example, right? In other words, so that you can control it, so it doesn’t just run off wildly, or go in directions you don’t want it to go. So this right here is a harness, okay? This thing holding the dog, restraining it, controlling it , that is a harness. So, when we talk about harness engineering, we are talking about building a system, a system that controls an AI model. So, you have an AI model here. An AI model is unpredictable. It can do things you

01:02 don’t want it to do. You need to put a harness on it. You need to put a leash on it. You need to tell it where it should go. You do that by building a harness. All right? So from this, you can naturally see that it’s interesting to learn harness engineering if you want to give more and more freedom to AI models. If you want increasingly intelligent AI models to take various actions, to perform various tasks, you need to ensure that the model, which is

01:33 unpredictable, which is stochastic, which you don’t fully master or understand, only does what you want, okay? So, when we talk about harness engineering, we need to understand its anatomy, the anatomy of a harness, that is, what composes a harness, right? What are the elements you put into a harness to build it? So, remembering, we have the model here. So, the model, what is the model here, folks? Here we are talking about GPT-4, Claude, we are

02:03 talking about Llama, GLM, or even Grok. These are the models we use, okay? Each model will need its own harness to place it, right, where it needs to be, correct? So what will a harness need? What is the anatomy? What is it composed of? First thing that comes to mind, a harness, it has tools. Rafael, what are tools? Well, here we’re talking about MCPs, CLIs, terminal commands, file reading and writing, etc., etc. So, a harness gives that

02:35 model a set of tools it can use, right? Another thing the harness needs to have is context, right? Meaning, we need the model to understand instructions, not forget things it did in the past, and know what it can and cannot do. So here we can talk about instructions, memory, and various other things that will manage the context. For example, compression. How am I going to manage this, right? So I need to compress that

03:07 context at some point, I need summaries of the context, and so on. So context is another component here in harness engineering, but we have other things. We have, for example, permissions or a sandbox, right? We want that model to run in a controlled environment. What else do we have? Ah, our friend Uncle Bob will be happy about this. We have orchestration issues, meaning a model on its own is just, well, it’s the model. It’s the model, but I might want

03:39 to dispatch sub-agents here. Why would I do that, folks? Why would I dispatch sub-agents? For a few reasons. You might have a very smart model, GPT-6 Astra, consuming all your tokens. But then at the execution stage, after you’ve made a plan, you can dispatch a much cheaper and faster model. So you save tokens and get the same result, but without spending as much, right? So this is an extremely important part of harness engineering too, specifically

04:09 in this context of Codex, or ChatGPT; I recently made a video about Codex orchestration using Luna, right? Which is excellent for this type of thing. I’ll leave the link if you are particularly interested in doing orchestration in Codex. But of course, Codex is an example of a harness, right ? I didn’t even mention that here. Let’s take a small detour, let’s go back to talk about which famous harnesses we have today, right? We have Codex, we have Cloud Code, we have Cursor, we have antigravy. All of these

04:42 are harnesses that will incorporate, or rather, implement these issues I’m showing you here. Of course, these are larger harnesses, there are simpler ones, like, for example, pi. It is a minimalist harness. What is the advantage of pi? It’s so minimalist that it doesn’t even come with some things by default. For instance, it doesn’t come with subagents. So you add subagents if you want. So you build the harness to your liking. It is perfect for harness engineering because of that . Now, another thing a harness can give you is observability. All right? What

05:13 is this ugly word here, folks? Observability. Here we are usually talking about traces, we are talking about evals, that is, ways for you to analyze if the harness is doing what it should be doing. Why? Because the artificial intelligence model is stochastic. It goes into this mix of things it can use here, and it will decide what it’s going to do. How do you know it chose the right way? How do you know that, for example, you gave it a toolbox? And here in this toolbox,

05:43 there’s a Phillips screwdriver, a lug wrench, a drill, and then you gave it a task: I need to assemble this chair. And then it chose the lug wrench, for example, instead of choosing the Phillips screwdriver, I don’t know, you say: “Whoa, wait a minute, this model chose the wrong tool.” What is wrong here? Could it be my tool instruction manual? Could it be that my context wasn’t adequate? Could it be that my model is dumb and can’t understand this ? All of this is part of harness engineering. And now you understand why this is part of a software engineer’s

06:15 job, right? So the software engineer now needs to learn how to build this harness for two distinct situations. And here is perhaps where the main confusion comes in, okay? Situation number one, folks, when would you build a harness? Well, you’re a programmer, so for yourself. And I’ll explain what you’re going to do in this context. And the second situation where you would build a harness is for a company or a team. It’s what people here called a

06:47 domain-specific harness, right? So for a specific domain. What is a specific domain in this sense here, Rafael? Well , here we’re talking about a company, here we’re talking about a team. So, anywhere you can apply an AI agent, you can apply it here in the specific domain of that team or that company, got it?