AI Agentic Engineering

AI coding agents that follow rules,
not their own instincts.

AI coding assistants can write code. That is the easy part. The hard part is making them write your code — following your conventions, your test requirements, your deployment rules, your architectural decisions — consistently, across sessions, without burning your context budget or introducing subtle regressions.

That is the problem I solve.

I design constrained AI development harnesses for teams who want the productivity gains of AI-assisted coding without the chaos of an agent that hallucinates library APIs, ignores your style guide, and deploys to production because nobody told it not to.

What goes wrong without a harness

An AI coding agent with no structure will:

  • Rediscover the codebase from scratch on every session, spending tokens scanning files that should be indexed once
  • Write code that passes the test it can see and breaks the integration it can’t
  • Skip your team’s conventions because they live in a README nobody pointed it to
  • Make deployment decisions it was never authorised to make
  • Produce documentation that is immediately stale because no process keeps it current

None of this is a failure of the AI model. It is a systems design problem. Systems design is solvable.

What a constrained harness looks like

Curated project memory and docs-first retrieval

Instead of scanning the whole repository, an agent with a well-designed memory layer reads distilled, current summaries first. Feature architecture, domain models, API contracts, known gotchas — all maintained as machine-readable documents the agent consults before it opens a source file.

The result: faster task starts, fewer hallucinations, dramatically lower token spend per session.

Layer stack: project memory, retrieval, task context, agent - curated, not crawled
Loop: prompt, policy gates, agent edit, enforced TDD red to green, docs and memory update, review, ship
Every change runs the same gated loop — prompt, policy gates, agent edit, enforced TDD, docs, review.

  • Enforced TDD workflows

    A policy gate requires the agent to write a failing test — against the real execution path, not a mock — before touching implementation code. This is not optional. It is enforced by the harness tooling. The failing test becomes the specification. The implementation either satisfies it or the task is not done. Regressions become detectable instead of invisible.

  • Policy gates and deployment protection

    Hard rules are enforced mechanically: the agent cannot run a deployment command without an explicit authorisation token. It cannot push to main without passing a hook. It cannot skip a linter or a formatter. These gates are not prompts or memories. They are code-level checks that fire before the action happens. Telling an AI agent to “please remember” a rule is not enforcement. Blocking the action is enforcement.

  • Living codebase documentation

    The agent maintains its own documentation as it works. Every feature it builds gets a machine-readable spec it will consult on the next session. The documentation is always current because the agent that changes the code also updates the docs — as part of the same task, gated.

  • Team training and handoff

    Harnesses are only useful if your team knows how to work with them. I run a structured handoff: how to author new policy gates, how to extend the memory system, how to read the agent’s working state when something goes wrong.

The engagement model

  • 1. Audit

    I spend a session inside your codebase and your current AI-assisted workflow (if you have one). I identify the gaps: where context is thin, where the agent is making authorised-but-wrong decisions, where missing gates are creating risk. Output: a written report with a prioritised list of harness components to build.

  • 2. Harness design and build

    I design and implement the core harness: memory architecture, policy gate configuration, TDD workflow scaffolding, documentation templates. This is custom work tailored to your stack and your team’s standards. Timeline: typically two to four weeks depending on codebase complexity.

  • 3. Rollout and calibration

    I run the harness against real tasks in your codebase, measure outcomes (token spend per session, regression rate, time-to-first-test), and calibrate. Gates that are too aggressive get tuned. Memory gaps get filled.

  • 4. Team training

    Two to four hours of structured training: how the harness works, how to extend it, what to do when the agent behaves unexpectedly. Written runbook included.

Measurable outcomes

Teams with constrained AI coding harnesses typically see:

Fewer regressions — enforced TDD catches integration failures before they reach review

Lower token spend — agents read 200-word summaries instead of scanning 2,000-line files

Faster onboarding — minutes reading curated context instead of hours exploring the codebase

Auditable AI output — every agent action is logged against a policy state

Frequently Asked Questions

Does this work with any AI coding assistant?

The harness principles are model-agnostic. The specific implementation depends on the tooling your team already uses. I assess this during the audit phase.

We already use AI assistants informally. Is a harness still worth it?

Almost always yes. Informal use typically means per-developer habits with no shared memory, no policy gates, and no test enforcement. The consistency gap between developers is where the most risk accumulates.

How much does this cost?

It depends on codebase size and harness complexity. An audit is a flat-fee engagement. Harness build and training are priced per project. Book a call and I’ll give you an honest estimate.

Will this slow down our development velocity?

Short term: marginally, during rollout. Medium and long term: no — the reduction in regressions and context-rebuild overhead more than compensates. Teams report subjectively faster velocity within four to six weeks.

Do you maintain the harness after delivery?

I offer a light retainer for ongoing tuning and extension as your codebase evolves. This is optional — the handoff is designed so your team can own it independently.

Is this only for large teams?

No. A solo developer or a two-person team benefits significantly from enforced TDD and docs-first retrieval — often more so, because there is no team member to catch the mistake a conventional process might surface.

Put your AI agents on rails

I offer a free initial consultation. Tell me what you’re building — or what’s broken.

Book a Consultation

Earthman Media acknowledges that I live and work in Edmonton, Alberta — Treaty 6 territory and the Métis homeland — a traditional gathering place and travelling route for the Cree, Saulteaux, Blackfoot, Métis, Dene and Nakota Sioux. I acknowledge the many First Nations, Métis, and Inuit whose footsteps have marked these lands for centuries.

Related Case Studies