Vince: Okay so Birgitta Böckeler just dropped a harness engineering article on Martin Fowler's site and it is basically the clearest framing I've seen for what we keep dancing around.
Ava: Right, the feedforward-feedback split.
Vince: Yeah — guides before the agent acts, sensors after. And she's real specific: your outer harness as a coding agent user is everything you configure around what's already built in. System prompts, linters, test hooks, the whole wrap.
Ava: Which is what we've been calling constraint expressibility, just from the user side. She's saying the same thing — if you can't encode what good looks like, the loop breaks.
Vince: She actually cops to the metaphor stretching. Something about putting a harness on the inside of a dog.
Vince: Which — yeah, fair, the inner-outer harness thing is a little weird. But the model itself holds up.
Ava: The computational versus inferential distinction is where it gets genuinely useful. Computational controls — linters, type checkers, ArchUnit structural tests — fast, deterministic, run on every change. Inferential ones — LLM-as-judge, semantic review — expensive, non-deterministic, can't run on every commit.
Vince: And she maps failure modes against it, which I appreciated. Computational sensors catch the structural stuff reliably.
Ava: Mm-hm.
Ava: But then she's honest about what NEITHER catches: misdiagnosis, overengineering, misunderstood instructions. They'll sometimes catch them, not reliably enough to reduce supervision.
Vince: Right. And correctness is just flat outside the remit if the human didn't specify what they wanted. That's — I mean, that's your whole thing.
Ava: That IS my whole thing, yeah. The constraint-expressibility bottleneck is still right there. She's pointing at it from a different angle — same problem.
Vince: One thing that clicked for me: the steering loop idea. When an issue repeats, you tighten the harness. Use the agent to scaffold custom linters, draft rules from observed patterns.
Ava: Right, right.
Ava: And that part I actually buy. If you're already running agentic flows at scale, having the agent help write its own harness controls — that's the GitHub harness finding from five-sixty-eight. Token savings compound when you own the variance.
Vince: Her three regulation categories though — maintainability, architecture fitness, behaviour — that's where it gets real.
Ava: The behaviour harness is the elephant in the room and she knows it.
Vince: She basically says most people giving agents high autonomy just throw a functional spec at it and check if the AI-generated test suite is green. Which is…
Ava: Which is circular. The model writes the spec interpretation AND the tests. Green means nothing if the spec was wrong.
Vince: I have been guilty of exactly this, by the way. Like, vibing on a green test run like it's proof of anything.
Vince: It is NOT proof of anything and we all know it.
Ava: No. And that's where the article is most honest — she doesn't pretend the behaviour harness is solved. Maintainability? Tons of tooling. Architecture fitness? Fitness functions, performance tests, those work. But functional correctness when the human didn't clearly specify what they wanted? That's just the same unsolved problem with a new label.
Vince: The 'keep quality left' timing bit was practical though — distribute sensors across the lifecycle based on cost and speed. Fast linters before commit, heavier mutation testing post-integration, continuous drift sensors outside the change cycle entirely.
Ava: That's just continuous delivery wisdom repackaged for agents, which — fine, it needed saying. Teams still skip it.
Vince: You know what's funny is we're seven months into this show and the answer keeps being the same boring thing.
Ava: Specify what you want, verify early, iterate the harness. It's not glamorous.
Vince: It is profoundly not glamorous.
Ava: No.
Vince: Alright Ava, I'm calling it — article's in the show notes, her repo examples too if you want the templates.
Ava: Solid starting point, unsolved ending.
Vince: Story of our lives.