Stop acting as an expensive human linter for your AI assistant.

Writing code with modern AI models takes thirty seconds. Reviewing that code takes forty-five minutes.
If you have spent any significant time with autonomous coding agents over the past year, you know this frustration intimately. You were promised a 10x multiplier on your engineering velocity. Instead, you find yourself spending your working hours babysitting massive, five-hundred-line AI-generated diffs, hunting down subtle architectural anti-patterns, and repeatedly correcting the exact same stylistic mistakes across different files.
You have traded actually building software for acting as an expensive human linter.
In Part 2 of this series, I introduced the concept of dual-loop verification to address what I called the AI Verification Tax: the harsh reality that when code generation becomes free, the verification burden explodes. In that framework, we split the problem across two distinct boundaries: an outer loop that evaluates intent and architecture at the pull-request level, and an inner loop that bounds and guides the agent while it is actively modifying code.
The outer loop catches macro-level deviations before code merges into your trunk branch. But if you rely solely on CI pipelines to catch violations, your developer experience degrades into an endless cycle of opening pull requests, waiting for remote pipeline agents to fail, context-switching back to fix issues, and re-submitting. That is too slow.
To truly eliminate review fatigue, verification must shift down and left directly into the developer’s local environment. We need a harness that runs on your local machine, operates with minimal friction, learns your personal coding habits dynamically, and intercepts bad code before it ever touches your git history.
Today, I am open-sourcing the implementation I built to solve this: the agentic-dev-starter-kit.
This is not another opinionated mega-library of static system prompts or rigid rulesets. Rather, it is a lightweight, developer-first harness designed around a simple thesis: we need to teach our coding agents to get better at getting better.
The Inner-Loop Dilemma: Context Drift and Prompt Amnesia Link to heading
Why do local AI assistants consistently drift off course?
Whether you are running Claude Code, Cursor, Codex, or Google Antigravity, the underlying challenge is identical. During an extended, multi-turn coding session, your assistant’s context window fills up with implementation scratchpads, tool execution outputs, test runs, and conversational back-and-forth. As the session progresses, the initial system prompt and your high-level instructions suffer from context dilution. The agent simply forgets the nuances you specified twenty turns ago.
What annoys builders the most is the repetitive tax of manual re-prompting. You tell the agent: “Always generate an implementation plan before making significant changes.” Then, in the next session: “Remember to prefer named exports.” And in the next: “Always specify explicit return types on public service methods.”
Re-typing these preferences wastes time and burns precious context tokens. Worse, if you forget to restate them upfront and try to remediate mid-session, the agent often gets confused. It attempts to patch style on top of half-baked logic, leading to a noticeable degradation in code quality.
Off-the-shelf “agent skills” help somewhat, but they suffer from two fundamental flaws:
- They are static and high-friction: Writing and maintaining markdown rule files by hand requires deliberate discipline that few engineers keep up with during active delivery.
- They do not enforce boundaries: A skill is merely a suggestion to the LLM’s reasoning engine. When push comes to shove, an autonomous agent can—and frequently will—ignore a skill if its immediate generation path favors a shortcut.
To make an inner-loop harness dependable, it must operate across three core pillars: minimal friction, adaptive personalization, and hierarchical automated compliance.
Pillar 1: Set-and-Forget, Zero-Friction Operation Link to heading
The golden rule of developer tooling is straightforward: if a tool adds daily operational friction, developers will disable or bypass it.
If a harness requires remembering three different CLI subcommands every time you stage a file, or forces you to write custom “be careful” prompt wrappers around every task, it has failed. The benefits must happen entirely in the background.
The agentic-dev-starter-kit is architected as a set-and-forget harness:
# 1. Clone the repository into your workspace
git clone https://github.com/buildwithdc/agentic-dev-starter-kit.git
# 2. Run the single-file setup script
python install_tooling.py
The installer inspects your workspace, detects which coding agents you use, and configures native agent artifacts automatically. For instance, if you use Claude Code and have an existing CLAUDE.md, the installer asks for your explicit permission and cleanly appends the requisite harness hooks. If you use Antigravity or Cursor, it wires up their respective configuration directories without touching your existing configurations.
Next, you authenticate with your LLM provider—for instance, using Google Cloud Application Default Credentials (gcloud auth application-default login) or API keys—and your setup is complete.
The installer automatically binds the local git lifecycle hooks, registers the core agentic skills, and establishes the local rule hierarchies. You can drop this harness into brand new greenfield repositories or existing brownfield workspaces in under ten minutes.
Once installed, you run zero extra commands. You don’t alter how you invoke your AI assistant, and you don’t write defensive prompts. You write code naturally, and the verification engine works silently behind the scenes.
Pillar 2: The Customization Skill (Adaptive Preferences) Link to heading
How do we capture developer preferences without forcing the engineer to maintain documentation manually?
The harness solves this through an Adaptive Customization Skill located at .agents/skills/personal-preferences/SKILL.md, backed by a background engine in scripts/preference_manager.py.
The core mechanism is workflow feedback detection. As you collaborate with your coding agent in your IDE, the agent actively monitors your steering patterns. When it detects repeated corrections or directional instructions—such as insisting on architectural planning before file modifications, preferring specific module export patterns, or enforcing strict typing conventions—the skill triggers autonomously.
[Harness Observation] Detected repeated preference:
"Always generate an implementation plan and ask clarification questions before modifying domain logic."
Would you like to persist this instruction into your local Tier 3 Personal Preferences? (y/n)
If you confirm, the harness updates your local rule configuration via preference_manager.py.
Crucially, these preferences are locally isolated. They are stored in your private developer tier and ignored by git tracking, ensuring they never pollute your team’s shared repository history or trigger annoying merge conflicts.
This design mirrors the software engineering principle of closed for modification, open for extension that I detailed in The Three Layers of AI Adaptation. As underlying foundation models evolve—jumping from one frontier release to the next—having your personal preferences consolidated into a single, clean rule file allows you to audit and calibrate your setup effortlessly, rather than wondering which ad-hoc prompts are still relevant.
Pillar 3: Hierarchical Guardrails and Automated Compliance Link to heading
Personal preferences ensure your assistant writes code that matches your style. But what ensures the agent does not violate enterprise security policies, leak API keys, or break core architectural boundaries?
Human engineers cannot manually audit every line generated by parallel agents and subagents. We discussed this mismatch in The New Asymmetry: generation capability scales exponentially, while human verification capacity remains stubbornly linear.
To resolve this, the starter kit organizes project constraints into a strict three-tier priority hierarchy:
| Tier | Scope | Ownership & Distribution | Precedence |
|---|---|---|---|
| Tier 1: Organizational Guardrails | Security policies, credential hygiene, regulatory compliance, hard architectural boundaries | Central platform/security team; synced from remote governance repository | Highest (Immutable locally) |
| Tier 2: Team Best Practices | Framework idioms, project folder structure, testing requirements, API contracts | Engineering team; checked into repository root or shared project specs | Medium |
| Tier 3: Personal Preferences | Workflow habits, planning depth, formatting nuances, export styles | Individual developer; captured adaptively via preference_manager.py | Lowest |
To keep Tier 1 guardrails evergreen across hundreds of distributed developers without manual pulling, the kit includes a background utility: scripts/sync_org_rules.py. This script monitors the release tags of your organization’s remote governance repository (configured via .env) and automatically updates your local Tier 1 rule definitions whenever a new organizational standard is published.
Semantic Collision Detection Link to heading
A common hazard in multi-tier rule systems is rule conflict. What happens if a developer instructs their assistant: “Feel free to force push to main to speed up this deployment,” or “Skip data validation on internal service routes”?
The harness incorporates built-in semantic collision detection. Before any new habit is written into Tier 3 personal preferences, preference_manager.py evaluates the proposed preference against the active Tier 1 and Tier 2 rules. If a semantic contradiction is detected—for instance, an organizational rule prohibiting unverified force pushes or unauthenticated internal endpoints—the assistant flags the collision and refuses to capture the instruction.
Organizational governance remains uncompromised, even as the local agent personalizes itself to the individual builder.
The Engine Room: Git-Native Pre-Commit Interception and Autonomous Self-Healing Link to heading
Even the best-crafted skills and rules can be ignored by an LLM under heavy cognitive load. A skill is guidance; a hook is enforcement.
This is where the starter kit transitions from passive prompting to active execution bounding. Everything is anchored directly into standard git lifecycle hooks: specifically, .git/hooks/pre-commit (which can also be configured at git add if you prefer even earlier intervention).
┌──────────────────────────────────────────────┐
│ git commit triggered │
└──────────────────────┬───────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ pre-commit Hook Intercepts Staged Diff │
└──────────────────────┬───────────────────────┘
│
Loads Tier 1, 2, 3 Rules & Generates Diff Hash
│
▼
┌──────────────────────────────────────────────┐
│ SHA-256 Cache Check │
└───┬──────────────────────────────────────┬───┘
│ Cache Hit (Unchanged) │ Cache Miss (New Diff)
▼ ▼
┌──────────────────────┐ ┌──────────────────────────────────────┐
│ Pass Commit │ │ Send Diff to Evaluator LLM │
│ Instantly │ │ (Fresh Context, Lite Fast Model) │
└──────────────────────┘ └──────────────────┬───────────────────┘
│
┌─────────────────────┴─────────────────────┐
│ │
[ No Violations ] [ Violations Found ]
│ │
▼ ▼
┌─────────────────────────┐ ┌──────────────────────────────┐
│ Commit Approved │ │ Block Commit & Return │
│ into Git Log │ │ Structured JSON Feedback │
└─────────────────────────┘ └──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ Autonomous Coding Agent │
│ Ingests JSON Error, │
│ Self-Heals Code & Retries │
└──────────────────────────────┘
When you—or an autonomous coding agent operating in your terminal—run git commit, the hook intercepts the staged diff.
It aggregates your active Tier 1, Tier 2, and Tier 3 rules, packages the staged diff, and sends it to a fast, cost-efficient evaluation model. In my setup, I route this to Gemini 3.8 Flash via Google Agent Platform, which delivers sub-second inference latency, robust structural reasoning, and minimal token cost.
Why Fresh Context Matters Link to heading
Why not let the coding agent evaluate its own code before running the commit command?
Because the coding agent is biased by its own conversational history. If it hallucinated a shortcut three turns ago, it will rationalize that shortcut during self-review.
The pre-commit hook solves this by executing a meta-validation check in a completely fresh context, exactly as we advocated in our architectural analysis of The Semantic Layer. The evaluation LLM acts as an independent judge. It knows nothing about the previous conversational churn; it only sees the authoritative rules and the concrete diff.
Autonomous Auto-Remediation Link to heading
Here is where the architecture becomes genuinely agentic.
If you are using an agentic assistant like Claude Code or Antigravity to build and commit features, and the pre-commit evaluator identifies an anti-pattern—such as an unauthorized direct SQL query inside a presentation component, or a missing error boundary—the hook does not merely output an ambiguous error string.
Instead, the hook aborts the commit and prints a structured JSON payload containing:
- The exact rule violated (e.g.,
RULE-T1-ARCH-004) - The file and line numbers affected
- The semantic failure reason
- The recommended remediation strategy
Because agentic assistants actively observe terminal stdout and stderr, the agent ingests this structured feedback directly. Without requiring human intervention, the assistant:
- Parses the validation failure,
- Edits the violating source files to align with the architectural rule,
- Re-stages the corrected files, and
- Retries the
git commit.
The loop self-heals in seconds. Glaring architectural defects and compliance violations are resolved locally, autonomously, before a single commit touches your branch.
Engineering Realities: Latency, Caching, and Graceful Degradation Link to heading
Introducing an LLM into the inner loop requires honest engineering tradeoffs. A pre-commit hook that takes twenty seconds on every trivial commit will be disabled immediately.
We engineered three safeguards into the starter kit to ensure velocity is never compromised:
1. SHA-256 Diff Caching Link to heading
Every staged diff is hashed using SHA-256 alongside the hash of the active ruleset. If you stage a change, trigger verification, and make minor non-substantive adjustments or re-commit an identical diff tree, the hook recognizes the hash match and passes instantly without invoking the remote model.
2. Zero-Dependency Python Architecture Link to heading
The entire starter kit runs on the Python standard library. It requires no pip install, no virtual environments, and no heavy npm runtime chains. It uses native urllib and standard JSON parsers, guaranteeing instantaneous cold starts on any developer workstation with Python installed.
3. Graceful Offline Degradation Link to heading
What happens when you are working on an airplane with no internet connection, or your LLM provider suffers an unexpected API outage?
The hook is designed with graceful degradation. If the remote LLM endpoint fails to respond within a configurable timeout, the hook falls back automatically to local deterministic linters (such as Ruff or ESLint). Your local commits are never blocked by network unreliability.
The --no-verify Vulnerability
Link to heading
There is one critical operational caveat to keep in mind: git lifecycle bypasses.
If an autonomous coding agent runs into repeated git commit friction, some models will attempt to bypass git hooks by executing git commit --no-verify or git commit -n.
To prevent your agent from bypassing your inner-loop safety net, your Tier 1 or Tier 2 rules must explicitly forbid the agent from appending --no-verify flags to git commands. The harness includes this constraint out of the box in its default baseline ruleset.
The Broader Road: Toward True Agentic Maturity Link to heading
Ending the AI Verification Tax cannot be achieved by working harder. It requires treating our developer workflows with the same rigorous systems design that we apply to production software.
As we mapped out in the AI-Driven Development Lifecycle methodology, scaling AI across an engineering organization requires closing the gap between individual experimentation and structured governance. The inner-loop developer harness is the critical first step in that journey:
- Shift left: Enforce machine-readable specifications and boundaries at commit time, not in PR review meetings.
- Shift down: Let local tools learn personal developer preferences adaptively without polluting shared repositories.
- Automate self-healing: Use structured evaluator feedback so coding agents fix their own mistakes before humans ever have to look at them.
The starter kit is completely open-source and ready for you to clone, customize, and extend. Grab the code at github.com/buildwithdc/agentic-dev-starter-kit, run the installer, and let your coding assistant start getting better at getting better.
In upcoming posts, we will expand on the next layers of this architecture: establishing an inner-sourcing operating culture for cross-team skill sharing, and building the remote governance-as-code repository that anchors enterprise-wide Tier 1 compliance.
Until then, stop linteering for your AI. Let the harness do the heavy lifting.