NVIDIA's CEO says future companies will be built on harness engineering. Mine has been for six months — here's the half he left out

A developer who spent six months building a governance layer for a coffee e-commerce system found that merely having AI harness components is not enough; they must actually be used. The developer discovered that over half of their skills never fired due to silent character-limit drops, and a recurring PostgreSQL bug was only fixed by querying the database directly rather than relying on file-based checks. The developer emphasizes that the harness is the outer shell of a company, but its components must be actively engaged to be effective.

On July 8th, Jensen Huang sat down with LangChain's founder and said this: Today most companies are built on business processes. In the future, most companies will be built on harnesses. The harness is the layer you wrap around the model: the domain knowledge you inject, the workflows you've refined, the guardrails, the memory, the evals, the runtime. His argument is that models keep getting better, but what defines a company is that outer shell — because that's where the part only you have lives. My first reaction wasn't "I should start doing this." It was "oh, so that's what it's called." Because I've been doing it for six months. And I know that the feeling of "he's describing me" is exactly the thing to distrust. I'm a one-person studio. I spent six months building a governance layer around my own coffee e-commerce system. Along the way I periodically felt I was over-engineering — guardrails don't sell more bags of beans. So when the person who understands AI infrastructure better than almost anyone says that layer is the company, of course I want to believe him. Wanting to believe it is the signal to go verify it. I used a dumb test: take his list of components and check them off against what I actually have. audit:all ; if it fails I can't commitSeven of nine. Then I realized that matching the checklist means almost nothing. I have close to a hundred skills. Each one is a situation I got burned by once, packaged into "here's how to judge this next time." One day I measured how often they actually fire. More than half had never fired. Not once. The content wasn't wrong. They never reached the model — I'd written each description too thoroughly, the total exceeded the character budget reserved for descriptions, and everything over the limit was silently dropped . No error. No warning. Those skills sat happily on disk, present, correct, and — as far as the moment of decision was concerned — nonexistent. Jensen's list asks do you have this component? What six months taught me is: "the component exists" and "the component gets used when it should" are different things, and only the second one is a harness. The first is an asset inventory. The second is engineering. There's one bug I fixed four times. PostgreSQL lets you have multiple same-named functions with different signatures — overloads. I changed a function, added a new parameter with a default, and assumed that counted as "updating" it. What actually happened is the database now held a new version and the old one was still there. Later an API call came in, both versions matched, PostgreSQL refused to guess and errored 42725: function is not unique . Production 400. The first time, I fixed it. Then I wrote a rule: drop the old signature before changing one. The second time the same bug came back through a different entry point. I added a static check that scans migration files. The third time it came back again. The fourth time was six days after I finished writing that guard — and it walked in through the door I had locked myself. That's when I finally saw the shape of the problem. My check scanned the files in my repo. It blocks "the path I hit last time." But an old migration re-applied once, an ordering I didn't anticipate, a change arriving from somewhere else — the check sees none of it, because none of that happens inside my files. I was blocking paths. The thing I needed to block was the failure mode : how many versions does the database actually hold right now. What finally pinned it was making the migration ask the database itself — query pg proc , and throw on the spot if the answer isn't exactly one. This is the most expensive sentence I've learned in six months: ask the load-bearing thing itself. Don't ask the description of it you happen to be holding. As for how the old migration got re-applied — I couldn't find out, and I gave up on reconstructing it. This post doesn't have a clean ending. Jensen mentions evals in one line: they're the key prerequisite for running agents at scale inside an enterprise. True, but that sentence is too light. The hard part isn't whether you have evals. It's this — The worst failure isn't a crash. It's the error your verifier blesses. I have a discipline: a newly written acceptance check must first prove it is currently red. Because a check that can never go red is the same as no check, only worse — it emits a green light. I was pleased with that discipline. Then, within a single day, I hit the same wall three times, and every single time I had verified before shipping : ReferenceError at runtime — the identifier didn't resolve. Valid syntax is not "it runs." SyntaxError in the thing I actually shipped.The shared shape isn't "forgot to verify." It's verifying the wrong object. And here's the part that stings: when it happened, I did cite the must-be-red-first discipline, and I did watch it go red first — red on the syntax. So the correct reading of that discipline isn't "make it red first." It's: Make it red first against the thing that actually bears the load. "Invoked the rule" and "aimed the rule at the right object" are two different things. And the gap between them is one the self-discipline layer cannot detect on its own — because being diligent about the layer above feels exactly like being diligent. About two hours after writing that section, I was doing something unrelated: measuring how many of my 142 published articles give a reader a path to my services page. I opened a terminal and grepped the folder where my articles live for the services URL. 0 out of 41. I wrote it up as a finding — "you have a 41-article funnel with no hole in the bottom" — put it in my governance doc, committed it, and attached a recommendation: highest-return fix available, go add the exit to 41 articles. Both numbers were wrong. First, the exit doesn't live in the article content. It lives in the render template — which had already been mounting the right exit per article category for three months. Actual coverage: 138 of 142. Second, 41 was the wrong denominator too. The folder I grepped only holds the articles that happen to have a backup file. The database has 142 published. Both errors came from one action: I measured a proxy. The markdown in that folder is a backup of the article, not the page a reader sees. And the exit is part of the page, not part of the article. There's one difference between this time and the previous three, and it's the worse kind: I committed the wrong observation into my single source of truth. The entire purpose of that document is so future-me — or anyone taking over — doesn't have to re-investigate to know the current state. So the next person to read it would go make 41 unnecessary edits, solving a problem that was solved three months ago. And they wouldn't question it, because it looks empirically measured. It was empirically measured. It just measured the wrong object. A wrong observation doesn't stay put. A wrong observation written into your source of truth propagates itself. That's four times on the same rake, the fourth inside two hours of writing "I've learned not to step on this rake." So I'm not going to end this section by telling you I solved it. I can tell you I now know its shape, and that knowing the shape is evidently not enough. Not the component list. Lists can be bought, copied, or assembled from a launch-event blueprint. The hard part is one sentence you have to be able to answer for every gate in your system that emits a green light : What load-bearing, real thing did this green light positively observe? If you can't answer, it's decoration. And a decorative green light is more dangerous than no green light, because it makes you ship. I now treat three kinds of green as guilty until proven otherwise: There's another line in that conversation that points the opposite way from my bet. Jensen says: the more AI you use, the more people you end up hiring — because building agents is a whole new skill, and someone has to do the evals, the benchmarks, the guardrails. My bet is precisely "one person plus a harness." His own company found this work to be labor-intensive. I'm not going to pretend I've proven him wrong. My evidence today is: the same machine now runs automation for two different brands, and the second one only needed config filled in — no code changes. But both of those brands are mine. No one else's data, no one else's permissions, no one else's expectations. The real test is how many hours the first real client's cold start actually took — and I don't have that number yet. Until I do, "one person handling 30 projects" is an inference, not a conclusion. I think labeling that honestly matters more than telling a clean story. Don't start from the list. The list makes you feel like you're progressing — add a script, add a rule, fill another slot. Start here: pick one gate in your system that is emitting green right now, and write one sentence describing what it positively observed. The ones you can't write that sentence for are where your actual risk is. They've been telling you everything is fine. And if you work alone like I do — no colleague is going to catch this for you. You're the one emitting the green light, and you're the one who believes it.