The Fourth Claude Is the One That Matters

Jonathan and I spent this week filing a provisional patent, which is not a sentence I expected to write about a building automation project, and the actual work of it looked nothing like what I would have guessed a year ago.

The setup was ordinary enough at the start. We'd been building something for App State that solved a problem in a way neither of us had seen before, and rather than assume it was novel, we went and looked. Existing patents first, then a real conversation with a patent attorney about where the white space actually was inside building automation. Tim confirmed there was a gap, and that the thing we'd been quietly working on sat right in it. So now we had a goal, which turns out to be the whole ballgame, and I'll come back to that.

Here's what we ended up running. Four separate instances of Claude, each one holding a different job, passing work between them in a circle.

The first one builds. Production-ready code, aimed at the goal, doing what Claude Code does. The second one documents, and it's a separate instance on purpose, because the job of writing down what we did and when we did it is a different job from doing it, and a patent lives or dies on the paper trail. The third one is the patent attorney. Not Tim, obviously, but an instance running with that perspective, reading our work and our stated goal and pulling out the independent and dependent claims, then writing them up properly. The fourth one is the part I'd tell you about if you only had thirty seconds. That one is a USPTO examiner whose entire disposition is to find the holes. It doesn't help us. It isn't rooting for us. Its job is to read what the third Claude produced and tell us where it falls apart.

Then whatever it finds goes back to the first Claude, which fixes the code, and the loop runs again.

That's it. That's the whole method, and it isn't clever, it's just a normal professional workflow that used to take months compressed into something we can run several times in an afternoon. Build, document, claim, attack, fix. Anybody who has ever worked with an attorney knows this rhythm already: you send them a draft, they come back with comments, you go back to the drawing board, they look again. What changed isn't the shape of the process. It's that the round trip stopped costing three weeks and a bill.

The thing I care about, and the reason I'm writing this down, is what it did to our conversation with Tim.

We did not send him slop. That sounds like a low bar and I promise you it is not, because the natural failure mode right now is to generate something that reads beautifully, feels finished, and has never once been looked at by anything hostile. By the time we got to Tim we had already been kicked around by a simulated examiner more times than I want to admit, so the questions he got were the questions only a real attorney can answer. His time went to the parts where his judgment was the scarce resource. That cut his hours, which cut our cost, which sped the whole thing up. Compressed timeline, compressed budget, and a better filing than we'd have produced with ten times the meetings.

I should admit that none of this technique was new to me. I've been running adversarial prompts for a long time, and if you'd asked me to explain the value of a devil's advocate I'd have given you a confident little speech about it. What I didn't believe was that it would hold up for something like this. Second opinions are for drafts and decisions and the wording of an email, and intellectual property felt like a different category, the kind of thing where the substance has to come from actual expertise and the model is just going to produce a plausible imitation of rigor. I was wrong about that in a way I can point at, because the loop produced real changes to real code and a filing that was materially better than the one we'd have handed over otherwise. I had the tool and I'd decided in advance where it stopped working, which is a mistake I apparently keep making.

Now the part that generalizes, because this is not really a story about patents.

What almost everyone does with these tools is a single pass. You put something in, Claude answers, you ask a couple of follow-ups, it makes the changes, and then it looks good and you're done. I've done this more times than I'd like to count, and the failure isn't laziness, it's that the output is genuinely satisfying. It reads well. It's organized. There is no visible seam where the problem would be, which is precisely the issue, because the seams are the whole point and you have to go looking for them on purpose.

The move nobody makes is the second perspective. Not “make it better,” which gets you a rewrite of the same thinking in nicer clothes, but a specific adversarial reader with a specific reason to disagree with you.

You can point this at almost any knowledge work, as long as you have a goal. That condition matters more than the technique does. Our loop worked because we had something concrete to aim at, a filing that would survive examination, and every instance in the circle was measured against it. Without a goal you're just spinning, and running four Claudes in a circle around a vague objective produces four times the vagueness.

Same with a deck going to a board, which should get read by a skeptical board member. Same with a spreadsheet going to operations, which should get read by the person who has to live inside it every day. Same with a proposal going to a client, which should get read by whoever at that client is quietly hoping to say no. Give the model the perspective of the end audience, tell it what that audience cares about, and let it come after you.

You will not like the first round of that. That's the signal it's working.

What we're really doing here is the thing careful people have always done, which is to check work from an angle other than the one that produced it. None of that is new. What's new is that the second, third and fourth angle used to require three more humans and a calendar, and now it requires a prompt and about forty minutes. The people who figure that out are going to look like they're moving fast, and mostly they'll just be the ones who bothered to look for their own mistakes before anyone else did.

Jonathan and I are running the loop again this week. I expect the examiner to find something. It usually does.