A front-end engineer hits refresh and the browser shows her exactly what broke. A lawyer redlines a clause and waits two years to learn whether it was a mistake, if she ever learns at all.
That gap is a missing element of whether legal judgment can live in code. Yoko Li at a16z published an argument last week about visual AI that names the mechanism, even though law never comes up in her piece. It also sharpens something I wrote earlier this year about legal AI.
Yoko Li
Her claim: visual AI is moving from generating pixels to generating code. For years the field judged image and video models by how the final output looked, texture, lighting, realism. That made sense when the comparison was a camera or Photoshop. It stops making sense for design, UI, and 3D, because the practitioner does not want a finished picture. A designer wants layers and components. An animator wants keyframes and timing curves. A 3D artist wants geometry, materials, and scene structure. So the better tools stopped generating the finished image and started generating the source behind it: SVG, HTML, a React component, a Blender script. The pixels are still the output. The code is the source of truth.
What makes the code version better is the loop. Code, render, inspect, revise. The model writes the artifact, renders it, sees what broke, and patches the source. Every pass improves the underlying thing instead of rolling the dice on a new sample. Pixel-native generation gives you twenty images and asks you to pick one. Code-native generation gives you one artifact and lets you fix it.
The loop only converges because of the renderer. The browser executes the HTML and shows you what is wrong. Blender runs the scene and tells you the hinge does not rotate. The runtime is the verifier, and its feedback is fast, local, and unambiguous, the machine version of a designer seeing a bad comp in three seconds. That last part is what law has to reckon with.
The vocabulary I was missing
I argued earlier this year that Anthropic, with Claude Design, used code as a harness for taste. They did not teach the model taste. They built a scaffold where a designer's tacit judgment could express itself in code, the brand pre-loaded as context, the canvas as the artifact, inline knobs for direct manipulation, a handoff bundle that carried intent downstream. My claim is that legal judgment is the same kind of tacit knowledge, and that it might live in a harness too.
Ken Priore
Yoko Li is describing that same move from inside a domain where it is starting to work, and she supplies the two terms my piece was reaching for. A symbolic representation as the source of truth. A renderer as the feedback environment. Put those together and you have the actual engine behind "code as a harness for taste."
Which exposes the problem I didn't quite shape fully. A legal harness has aspects of the symbolic representation. The organization's positions, the deal context, the structured handoff: those can be written down and made editable. What legal does not have is a renderer.
No engine runs a clause
There is no engine that executes a clause and tells you it is wrong. A contract gets rendered only when reality runs it, a renewal, a dispute, a breach, a regulator's letter. The feedback arrives slow, global, and tangled with a dozen other variables. A redline can sit for two years before anyone learns whether the indemnity cap was a mistake, and by the time the answer shows up it is impossible to isolate from everything else that happened to the account. You cannot debug a clause the way a browser lets you debug a layout.
This is why the design loop and the legal loop are not the same shape. A designer's signal is the renderer. A lawyer's signal is the consequence, and the consequence is delayed, noisy, and sometimes never observed at all. The harness can hold the lawyer's positions perfectly and still have nothing to check them against in the moment they are written.
So the engineering question for legal AI is not only integration, which is what I emphasized before. Pulling CRM, matter history, and communications onto the same surface as the draft matters, and it is hard. But it only feeds the harness better inputs. It does not give the harness a way to test its own output. The deeper question is what plays the renderer's role when no renderer exists.
What stands in for a renderer
The closest thing to a runtime in legal work is the counterparty. Opposing counsel's response renders your position, it tells you what held and what got pushed. That is real feedback, and a redlining agent that watches accept-reject patterns is already learning from it. But it is adversarial and partial. The other side is optimizing against you, not reporting ground truth, and most of their reasoning never reaches your surface.
Outcome data, litigation results, claims history, which clauses actually triggered losses, is the truest signal legal has, and the slowest. The lag runs in years and the result sits buried in settlement noise. Useful for training the next generation of positions. Useless for closing the loop on the deal in front of you.
The most renderer-like option on the table is simulation against the organization's own history. A harness that replays a proposed clause against prior matters, flags where it departs from what the organization has accepted before, and surfaces the cases where similar language led to a fight, that approximates a runtime. It is not a browser. It will not catch a novel risk. But it converts a clause into something the system can inspect against a corpus, which is the move that made code work for design. That is the part of the stack I would build toward.
What this means for product counsel
This reframes what you are buying when a vendor sells a legal AI harness. The pitch frontier today is context and integration: how many systems it reads, how much of the deal it can see. Those are inputs. Ask the harder question: what closes the loop? What in this product plays the role the browser plays for a front-end engineer? If the honest answer is nothing, then the product is a very good drafting surface and should be priced and supervised as one, not as a system that improves its own judgment over time.
The visual AI field got its renderer for free. Every browser, every game engine, every 3D tool already executes the artifact and reports what broke. Legal has to build the verifier or find something to stand in for it, and that work is harder than any integration. Until it exists, the part of judgment that needs a renderer stays exactly where it has always been: in the lawyer.
