Evaluating Agent Code Proposals Before Commits Happen

An AI coding agent decides to refactor a caching layer. Three seconds later, it mutates seven files across three directories, formats the buffers, and pushes a branch.

The resulting pull request contains 420 lines of syntactically valid TypeScript. CI runs, the unit tests pass, and the diff lands on a senior engineer's dashboard. That reviewer now has to answer three questions that the diff cannot answer for itself: Where did this logic come from? Does it introduce an incompatible license or unvetted dependency? Does it violate an architectural boundary that unit tests do not cover?

Treating the pull request as the first checkpoint fails. By the time a change reaches git, the agent has already decided how to solve the problem and obscured why it chose those specific primitives. Traditional code review automation checks the syntax and test suites after mutation. It does nothing to inspect the agent's intent before the repository changes state.

The Cost of Downstream Inspection

When you allow AI coding agents to write directly to the local filesystem or push commits directly to a remote branch, you invert standard engineering controls.

In a traditional workflow, a developer designs a change, selects an internal or external library, verifies the license, and writes the implementation. With an autonomous agent, those steps happen inside an opaque context window. The agent picks dependencies based on statistical likelihood rather than repository policy.

If the agent pulls in a library with a copyleft license or writes an ad-hoc implementation of a cryptographic routine, that decision is buried in a multi-file diff. Human reviewers suffer from review fatigue. They catch typo-level bugs and obvious syntax flaws, but they routinely miss subtle licensing contamination and violated architectural boundaries.

The failure point is not the model's reasoning capacity. The failure point is architectural: the agent possesses write access before its proposal has cleared a deterministic verification boundary.

Intercepting at the Build Gate

The control point must move upstream. Instead of granting an agent direct write permissions to git, the execution environment must route all proposed code additions through a build gate.

In this topology, the agent cannot directly mutate files. When it determines that a task requires a specific capability—such as an idempotency layer, a token bucket rate limiter, or a binary parser—it must construct an explicit build intent proposal.

Agent Context
     │
     ▼
[ Build Intent Proposal ]  ──( Contains: Target capability, required contract )
     │
     ▼
[ Build Gate ]             ──( Evaluates: Invariants, licensing, purity )
     │
     ├── REJECTED ─────────► Returns terminal failure to Agent context
     └── ACCEPTED ─────────► Resolves deterministic, verified artifact

This gate evaluates the request against hard rules implemented in code, not prompts:

1. Licensing constraints: Does this capability introduce unapproved dependencies or ambiguous provenance?
2. Contract invariants: Does the proposed interface match the exact type contract and purity expectations of the host system?
3. Deterministic resolution: Can this intent be satisfied by an owned, verified implementation rather than freshly hallucinated code?

This architectural boundary is the core premise of effective agent governance. When an intent fails verification, the gate returns a terminal state immediately. The file system remains untouched, no spurious commits pollute git history, and the human reviewer is never asked to reverse-engineer an unverified diff.

Deterministic Code Over Model Memory

Gating an agent's intent requires admitting a real limit: static analysis on arbitrary, novel code generated on the fly is extremely hard. If an agent writes 300 lines of raw logic, inspecting it programmatically for deep side effects before writing it to disk is computationally expensive and often indecisive.

The practical path is capability resolution. Instead of asking the agent to author low-level primitives from scratch, the build gate should resolve the agent's intent against a verified library of deterministic artifacts. If the agent needs a state machine, it requests one through the gate. The gate provides a verified, certified implementation whose boundaries and licensing are already settled.

The agent handles orchestration and glue. The gate handles the logic primitives.

How SHPBL Enforces Build Intent

SHPBL eliminates blind agent writes by sitting directly at this boundary. Our software operates without runtime AI models: every artifact in the catalog is model-independent, owned code with no hallucination surface.

When an agent interfaces with SHPBL—either over our HTTP API or via agent access over MCP—it passes through a Build Intent gate. The agent registers its proposal, and the system resolves invariants and licensing deterministically. Previewing an intent resolution costs nothing; retrieving the complete, certified artifact requires repository entitlement. Teams can run a free repository evaluation to map their current capability surface, or subscribe to the Practitioner tier ($39/month) to run the full verification gauntlet against their stack.

What to Change on Monday

Take one repository where team members or CI pipelines run AI coding agents.

Remove the agent's ambient write credentials to the default branch and isolate its file-system permissions. Introduce a pre-execution check: before the agent is allowed to generate new files for a task, require it to output a JSON payload listing the external capabilities and packages it intends to introduce.

Run a lightweight script against that payload to check licenses and package allowlists. If the intent contains unvetted packages or forbidden patterns, fail the run before a single line of application code is generated. Stop inspecting agent output at the pull request; inspect the intent before the write happens.