The Harness — Where Constraints Elevate Effectiveness

In my previous post, I explored how AI’s non-determinism isn’t a flaw — it’s the feature that lets us automate problems where the rules are too hard to write. Now the question becomes: how do we harness that chaos?

A powerful model with no constraints is like a search algorithm with no bounds. It might find the answer. It might also wander forever. As the task gets more complex — multi-step reasoning, domain-specific accuracy, safety-critical decisions — the probability of a bad output grows. The space of possible responses is enormous, and without guidance, the model can land anywhere in it.

So we add constraints. Not to limit what AI can do, but to make its output reliable.

The Harness

This is what I’m calling “the harness” — the system of guardrails, rules, prompts, and feedback mechanisms we build around AI models. It’s not a cage. It’s what makes the model’s vast output space navigable.

RLHF constrains model behavior through human preferences. OpenAI’s InstructGPT — 1.3 billion parameters fine-tuned with RLHF — was preferred by evaluators over the base GPT-3 at 175 billion parameters. A model 100x smaller, but constrained by human feedback, outperformed the unconstrained giant.

Constitutional AI bakes constraints into training itself. Anthropic’s approach has the model critique and revise its own outputs against explicit principles — a “constitution” — learning to self-correct within defined boundaries without a human in every loop.

Prompt engineering is the most accessible form. “You are a senior TypeScript developer. Only respond with working code. Do not use deprecated APIs.” Each instruction cuts away possible responses to focus on the region where useful answers live.

Runtime guardrails like NVIDIA’s NeMo Guardrails enforce constraints in real-time — topic control, PII detection, jailbreak prevention. They sit between the application and the model, filtering against defined policies.

Every one of these is the same pattern: reduce the output space so the model lands on useful answers more reliably. The constraints don’t weaken the tool. They make it usable.

What Happens Without the Harness

The harness above describes what we build around the model — prompt constraints, RLHF, guardrails. But there’s another layer: the system-level harness around the teams and processes that use AI. When that one is missing, things fall apart differently.

Theory is nice. From my own experience, here’s what that looks like.

In a large-scale networking project — spanning multiple teams across organisations, external vendors, and multi-month timelines — I watched AI-assisted automation fail in a way that perfectly illustrates the problem.

It wasn’t a skills gap. The engineers were talented. The AI tools were capable. Code got generated in minutes. Automations were built and shipped fast. Congratulations emails went out. Progress was celebrated.

But the system kept failing. Edge cases. Manual overrides. Alignment meetings that — by some measures — may have consumed more time than the manual process, though nobody was tracking the right metrics to know for sure.

The speed of AI-generated solutions created a perverse incentive. Team A built an automation for their piece. Team B built another for theirs. Each solution worked in isolation. Each was delivered quickly. Each looked like progress. Team C didn’t have time to improve their solution, so Team D built their own workaround to make it work — which became a permanent piece in the system.

But nobody stepped back to ask whether these pieces fit together. The problem space was too large for any single person to draft a perfect prompt — too many interconnected systems, too many unforeseen factors, too many organizational boundaries.

Solutions got created so fast that the real complexity was hidden. Every quick fix masked a deeper architectural question that never got asked. The system grew into a web of small, interconnected “solutions” — each correct in isolation, incomprehensible as a whole. The real tech debt wasn’t in the code. It was at the system level — in the gap between what was built and what was understood.

That gap created something worse than bugs: distrust between teams. Data flows across components got modified and transformed at every boundary — like a game of chinese whispers played across hundreds of branches. Each team adapted the data to fit their solution, added their own transformations, their own assumptions. The result was a system so complex that nobody could trace a single value from end to end. So we called them “edge cases” — but combined, they weren’t edge cases at all. They were a large portion of the problem. It was easier to create solutions that fit the data as it arrived than to put constraints in place that forced things into shape upstream. This is the kind of complexity that even AI will fail at — not because the models aren’t capable, but because the problem is no longer legible to anyone or anything. When nobody can understand the whole system, every team suspects the others are the source of the problems. Coordination breaks down. More meetings. More patches. The cycle accelerates.

Replacing a hammer with a nail gun doesn’t mean we should nail everything.

The Engineering Discipline Lives On

Given a problem space and a set of tools, engineers build systems that work and produce results consistently. That’s what we do. That’s what we’ve always done. The tools changed — we went from deterministic algorithms to probabilistic models. But the discipline is the same.

Manufacturing engineers don’t expect zero defects. They design quality control systems that keep defect rates within tolerance. Civil engineers don’t expect zero variability in materials. They design with safety margins.

We’re doing the same thing with AI. The harness is how we get reliable outcomes from a probabilistic system. Not perfect outcomes. Reliable ones.

When building is cheap, the expensive thing is knowing what to build. When generating code takes minutes, the valuable skill is knowing which code should exist at all. The harness isn’t just a technical construct — it’s the practice of defining constraints before reaching for the tool, understanding the problem before generating the solution, asking “who owns this?” before shipping it.

The Takeaway

Artificial intelligence — as we call it now — is not a replacement for thinking. It’s an amplifier of our ability.

It amplifies good engineering and bad engineering alike. It amplifies clarity and confusion. Discipline and carelessness. The output scales with whatever you feed in.

The harness is not to limit what AI can do, but to reduce the likelihood of bad outcomes and increase the likelihood of good ones. Define the boundaries before you build. Map the ownership before you automate. Understand the problem before you generate the solution.

My most important constraint isn’t technical. It’s critical thinking.

The tool changed. The thinking didn’t.