Sponsored by Packt · Live on August 20
The question I hear most often from engineering teams goes something like this: "Our coding agent nailed a gnarly refactor on Monday, then broke the build on Tuesday doing something trivial. What is wrong?"
The instinct is always to blame the model — or to go shopping for a new one. Claude Code versus Codex. This benchmark versus that one. Whatever shipped last week.
But after a year of watching teams adopt coding agents, I'm convinced the model is rarely the variable that matters. The teams getting dependable results aren't running smarter models than everyone else. They've simply built better systems around the model.
Think of it like electricity. Raw current is enormously powerful, but nobody wires a building by running bare cable through the walls. You add breakers, grounding, insulation, meters, and inspection standards — and only then does the power become something you can build on. A coding agent without specifications, permission boundaries, guardrails, automated validation, and review gates is bare cable: impressive output, unpredictable consequences.
Figure 1 is that comparison made literal. Bare model output, with nothing wrapped around it, produces the same current either way — the difference is entirely in whether anything stands between that current and something breaking.
Figure 1: Bare Current vs a Wired Harness
That surrounding system is what I call the harness. Harness engineering — not prompting — is what separates "the AI helped once" from "the AI is a trusted part of how we ship." And almost nobody teaches it.
So I built a workshop around it.
This post is free through the full agenda and who it's for. Paid subscribers get the discount link below — 40% off registration, first access before this goes out anywhere else.
This is a live, two-and-a-half-hour working session with Packt. Here's exactly how we'll spend the morning.
Figure 2 previews the five pieces we'll build up across the morning — they're the same five pieces that showed up in Figure 1's insulation and breakers, just named for software instead of electrical code.
Figure 2: The Core Harness Stack
9:00–9:15 · Why Harness Engineering What harness engineering means, why agent reliability depends on the surrounding system rather than the model alone, and the common failure modes hiding in coding agents.
9:15–9:30 · The Core Harness Stack Instructions and repo conventions. Tools and permissions. Hooks and policy checks. Tests and verification. Logging and observability.
9:30–9:50 · Spec-Driven Development Turning requirements into executable specs — clear scope, constraints, and acceptance criteria — and using those specs to guide Claude Code behavior.
Figure 3 traces that path from a fuzzy requirement to something an agent can actually be held to. The acceptance criteria step is the one teams skip most often, and it's the one that makes everything downstream — including the tests in Figure 5 — actually checkable.
Figure 3: Spec-Driven Development Flow
9:50–10:10 · Guardrails and Deterministic Hooks Controlling file access, shell actions, and network use. Pre-action and post-action checks. Safety and compliance boundaries.
Figure 4 shows what a guardrail actually is mechanically: a check that runs before the agent's action executes, with the power to block it outright, plus a second check afterward confirming the boundary held. Neither check depends on the model behaving — that's the entire point.
Figure 4: Guardrails as Pre- and Post-Action Checks
10:10–10:20 · Break + Open Q&A
10:20–10:35 · Tests as the Reliability Layer Unit, integration, and regression tests as validation for agent output — and how to turn past failures into permanent safeguards.
Figure 5 is the piece that turns "it worked this time" into "it will keep working." A regression test built from a real past failure is worth more than a dozen new unit tests, because it's the one guaranteed to catch the exact mistake the agent already made once.
Figure 5: Tests as the Reliability Layer
10:35–10:50 · Skills, Plugins, and MCP Tools Reusable skills for repeated workflows, plugins for extending agent capability, and MCP tools for safe external and internal integrations.
10:50–11:05 · Compound Engineering and Agent Teams Splitting work across planner, implementer, and reviewer roles. When multi-agent workflows pay off, managing handoffs and verification, and building a recursive self-improvement loop.
Figure 6 shows that split. The handoffs are the failure-prone part — a planner's output has to be specific enough for an implementer to act on without guessing, and an implementer's output has to be checkable enough for a reviewer to actually catch something instead of rubber-stamping it.
Figure 6: Compound Engineering — Planner, Implementer, Reviewer
11:05–11:15 · The Practical Workflow Pattern Putting it all together: spec first, constrained execution, deterministic checks, test verification, human review.
11:15–11:30 · Closing Principles and Q&A Make behavior predictable. Reduce ambiguity. Automate checks. Optimize for trust, not just speed.
The goal is not to help you generate more code. It's to help you build AI-assisted development workflows you can actually trust — ones that degrade gracefully when the model is wrong instead of failing loudly in production.
If you're using Claude Code, Codex, or any coding agent and the results feel like a coin flip — brilliant one session, baffling the next — this workshop was designed for exactly that frustration.
For paid subscribers: your discount link. Everything above is free for everyone. The registration link below — 40% off, first access before this goes out anywhere else — is a paid-subscriber perk.
