How Harness Enables Controllable AI Delivery for Automotive Software

Problem: Enterprise‑scale AI coding can lose control

A functional update added a fallback rule – “on download failure, revert to preset default” – hidden deep in a 200 k‑token PRD. The rule occupied only ~10 k tokens; the rest was unrelated analysis. The model missed the rule, causing a cascade of omissions:

Input : the rule was never presented to the model.

Design : downstream design omitted the exception branch.

Code : generated code lacked the corresponding path.

Self‑test : tests only exercised existing code, so the missing path was never verified.

QA : the defect surfaced only during real‑vehicle validation.

Scaling AI coding reveals five typical failure modes (Fig. 1):

Input bias – excessive context (≈200 k tokens) dilutes the decisive 10 k tokens.

Execution overrun – constructs such as heredoc bypass permission boundaries and modify published headers.

Verification gap – “self‑tested passed” defects reach customer validation.

Defect escape – code compiles and runs, but exception paths and interface contracts lack verification data.

Feedback break – the same issue recurs in subsequent tasks.

AutoSDK introduces a three‑layer defense line to address each risk.

1. Pre‑control: Context governance & behavior constraints

Context governance reduces the raw PRD from ~200 k tokens to the ~10 k tokens that actually drive decisions. AutoSDK implements a Layered Context Runtime (LCR) with four layers that define where context lives and which agents may read or write it. Progressive exploration via a pre‑built CodeGraph index limits the explore‑agent to relevant symbols, cutting the context‑peak by about 50 % . Data flow is separated from control flow: upstream agents write results to a Local Memory Bank and downstream agents retrieve only the JSON contract they need, keeping each agent’s context to a few kilobytes.

Behavior constraints answer “what the model may do”. AutoSDK adopts a four‑quadrant model (feed‑forward vs. feedback × deterministic vs. reasoning). Hooks rewrite include paths before file write, moving error correction from post‑compile to pre‑write. Example: the header auto_post_task.h must be included as async/auto_post_task.h. A Hook parses the include line, consults the compilation database, rewrites the path, and feeds the corrected path back to the model, eliminating the need for a later compile‑error fix.

The quadrant model distributes rules as follows:

Deterministic‑forward (Q1) and deterministic‑feedback (Q3) host pre‑write checks and post‑write validation.

Reasoning‑forward (Q2) and reasoning‑feedback (Q4) inject domain knowledge and perform semantic reviews at hand‑off points.

Result: include‑path errors are fixed before disk write; context‑peak reduction improves model focus.

2. Mid‑control: AI self‑testing & AI code review

AI self‑testing uses a dual‑Agent workflow: one Agent generates tests, a second grades them. Four validation criteria are enforced:

User‑scenario coverage.

Exception‑path coverage.

Contract assertions.

Impact coverage (key symbols actually exercised).

If any criterion fails, the test generation is retried up to two times; further failure escalates to human review. The system extracts verification evidence from three sources – PRD, code behavior, and existing tests – to build a business‑semantic model that guides test generation.

Typical failure patterns that the dual‑Agent catches include:

Tests that pass but only assert superficial state.

Missing business rules in assertions.

Complex execution chains where only the final callback is verified.

Undocumented parameters hidden in legacy tests.

AI code review separates deterministic “hard rules” (e.g., parameter count, forbidden APIs, include guards, naming conventions) from semantic “reasoning problems” (component boundaries, cross‑file consistency, exception handling). Four reviewer roles run at different stages:

Hard‑rule reviewer – scriptable checks that produce issues instantly.

Architecture reviewer – validates public interfaces and component boundaries.

General C++ reviewer – looks for logical defects and exception safety.

Verify sub‑Agent – de‑duplicates and aggregates severity across reviewers.

Review timing is staged:

During development: millisecond‑level hard‑rule checks.

Pre‑commit: add full style and LLM‑based semantic checks.

Code‑review (CR) stage: final human gate.

To limit cost, the system caps automatic retries at two; exceeding this threshold triggers manual escalation. This balances false‑positive cost (over‑blocking) against false‑negative risk (missed defects).

3. Post‑control: Feedback left‑shift

All execution logs, gate results, Hook hits, code diffs, and human feedback are stored and fed back into rule evolution. The same raw data serve two perspectives:

Business view – tracks quality, efficiency, and cost.

Capability view – monitors framework stability, rule hit rate, and manual interventions.

When a deterministic check fails, the failure is codified as a new rule; when a semantic check fails, the system prompts context enrichment, Agent re‑partitioning, or prompt refinement. The feedback loop is considered successful when the exposure point of a recurring error moves forward in the pipeline (e.g., from “compile‑error” to “pre‑write Hook”).

Quantitative outcomes after deploying AutoSDK

Context‑peak reduced by ~ 50 % .

Include‑path errors corrected before file write.

AI‑engineered defect leakage decreased by 73 % .

These metrics demonstrate that embedding control points throughout the AI‑generated code pipeline shifts risk from the final manual review to earlier generation, writing, and integration stages, making enterprise‑grade AI coding controllable despite higher per‑task cost.

Key artifacts

Figures referenced in the original article: