I11 · Independent assurance · 7 min read

Model judgment is advice. Never a gate.

A second model can find a defect. It cannot make a failed build safe. The engineering question is whether the system can refuse a change, and whether the author can change the terms of that refusal.

By Sam M. Sweilem, CEO of LockedIn Labs · Published 2026-09-06 · Reviewed 2026-09-06

Developed from thinking begun in late 2025.

When an engineering leader asks how an AI harness assures Java code quality, “another model reviews it” is an incomplete answer. It explains how we might obtain another opinion. It says little about what prevents a defective change from reaching the branch or environment that matters. That distinction is central to how I think about the AI software development lifecycle.

I want models in the review loop. They can identify suspicious assumptions, suggest missing cases, explain unfamiliar code, and give inexpensive feedback while a change is still easy to repair. A model can challenge another model usefully. But a persuasive explanation must never convert a required deterministic failure into a successful release decision. The surrounding system has to make that boundary real.

The generator proposes. The harness decides what is admissible.

The generation agent is the component that produces a candidate change. The harness supplies the execution environment, interfaces, feedback, and constraints around that work. Its acceptance policy must survive a change of generation tool. A client should inherit repository rules, tests, evidence, and an operating method that remain usable when the coding agent or model changes.

Record which model, context, and tools contributed to a change where that information is available and appropriate. That provenance supports investigation; it does not confer authority. Neither a premium model nor a named reviewer agent earns the right to bypass a failed contract. The candidate still has to satisfy the same acceptance conditions.

A check becomes a gate when promotion depends on it

Running a build locally is valuable early feedback. A release gate additionally needs a trusted execution path, a result tied to the candidate, and enforcement at promotion. Required checks should run against the version being admitted. Missing reports, skipped test execution, scanner errors, and exhausted repair attempts need explicit handling. None should quietly become permission to proceed.

This is why “CI is green” needs a second question: what actually executed? Protect the workflow, required-check configuration, test suite, thresholds, and suppression policy from unilateral weakening by the candidate author. Use an always-running aggregate gate that refuses absent or unsuccessful required jobs. Test the refusal path with an intentional defect. A green badge that can be obtained by skipping the work is weak evidence.

Permissions must support the design. Separate proposal and promotion authority where the delivery model requires it, and inspect the effective credentials, bypass rights, and protected paths. Do not assume a generic repository write role excludes merging, or that a prompt telling an agent not to merge creates an access-control boundary. The proof is the operation the identity is actually prevented from performing.

The authoritative-gate requirement in AISDLC-CQ-1.0 makes this expectation explicit. It is a requirement to implement and verify, not a claim that publishing the specification changes any repository’s permissions.

Ask each tool a question it can actually answer

Start with the real Maven or Gradle build and executed tests, including an explicit failure when expected tests are absent. Choose project-specific static and security checks, configure their failure behavior, and keep the versions and rule sets reviewable. More tools do not automatically produce stronger assurance; coherent coverage of the important failure modes does.

A Java verification stack with distinct jobs

Build and analyze: Compile against the actual dependencies and run JUnit tests. SpotBugs checks bug patterns; Find Security Bugs can extend security analysis. Checkstyle enforces selected source conventions. Each needs an agreed, blocking policy.
Challenge the tests: JaCoCo measures execution coverage. PIT changes code to test whether assertions detect the mutation. Examine surviving mutations and relevant changed code; a coverage percentage alone cannot demonstrate fault detection.
Encode architecture: Use ArchUnit to express package boundaries, dependency direction, and forbidden coupling. Review those rules as architecture decisions, so generated code cannot redefine the target merely to pass.
Inspect the supply chain: Use secret detection such as Gitleaks and dependency, vulnerability, and license checks under explicit policy. Preserve failure results and narrow exceptions; scanner output needs a decision, not an unread report.

The Java profile maps the controls to implementation choices. Set thresholds against the repository’s risks and baseline, and document the treatment of equivalent mutations, flaky tests, and accepted exceptions. Feed real failures back to the generator, cap repair attempts, and escalate unresolved work. Never let repair silently lower the bar.

Human review needs a purpose beyond clicking approve

Deterministic checks can refuse known classes of failure. They cannot decide whether an architecture is appropriate for the business, whether a data boundary matches the intended use, or whether remaining uncertainty is acceptable. Give those decisions to people with the context and responsibility to make them. For consequential changes, make the decision and its evidence visible.

Scale the review to the consequence. A documentation correction and a change to authorization logic should not consume identical approval effort. Preserve non-waivable baseline checks in both cases, then add domain, security, operational, or design review where the risk demands it. Requiring a person to approve every routine step can create a queue without improving judgment.

A useful delivery pod connects those responsibilities: an engineer who understands the actual workflow, a reviewer who challenges the candidate, and an owner who carries the released system into operation. Model reviewers can help each of them. Accountability remains with the people and controls that can act on the findings.

The strongest demonstration is a change the system rejected

Show a candidate that failed a required check, the retained failure output, the correction, and the later passing result. Bind each to its own commit and expose the relevant enforcement configuration. Label a deliberately seeded exercise as such. A repaired build demonstrates that check’s behavior in that scenario; broader conformance still requires evidence for the other controls.

Our controlled Java evidence summary records a cross-tenant test failure and a repair that passed the same nine tests. Branch protection was enabled after those runs. The trace demonstrates rejection and repair by the checks; it does not claim that promotion was blocked at the time or that the repository meets every conformance requirement.

This is the standard of explanation I want associated with LockedIn Labs: a specific claim, inspectable engineering, and a clear account of what remains to be implemented. The platform portfolio is context for that work, not a substitute for repository evidence.

For teams developing that discipline, LockedIn FDE Training and the FDE Benchmark offer related paths into the conversation. Bring the questions back to a real repository: what can fail, who can change the gate, and what proves the released version passed?

Primary sources

AISDLC Insights publishes source-informed editorial synthesis and implementation positions. It is reference material, not a standard, certification, legal opinion, or authorization to deploy an agent.