Inspection guide / free and ungated
What to inspect in an agent-built codebase.
For engineering leaders reviewing a delivery, an adoption effort or a technical investment. Eighteen questions about the software and the process that produced it—not the percentage of code an agent wrote.
The same questions we use in our harness review.
Attach evidence, not a score.
For each question, record what you inspected, the owner and the next decision. Sort findings into supported, unresolved and accepted-with-risk, and keep the evidence with each one.
01 / inspect
Outcome & architecture
- Is the intended user outcome explicit, with exclusions and a case that should be rejected even if it looks successful?
- Does the change use the existing owner of each business rule, rather than introduce a second implementation that can drift?
- Can the receiving engineer explain the design, its tradeoffs and how the next change would be made?
Evidence to requestThe task specification, acceptance criteria, design decisions and the actual diff.
02 / inspect
Context & repository legibility
- Can a fresh contributor locate the relevant code, run the application and reproduce the checks without a private chat history?
- Are requirements, examples and dependency assumptions tied to current sources, with stale or conflicting guidance identified?
- Are generated dependencies, copied material and sensitive inputs reviewed for provenance and permitted use?
Evidence to requestRepository guidance, source revisions, working commands and dependency records.
03 / inspect
Authority & execution boundaries
- Are allowed files, commands, network destinations and data explicit—and enforced beyond a written prompt?
- Are credentials and client data kept out of unapproved model inputs, logs and execution environments?
- Are permissions to edit, merge, deploy and make external changes granted separately, with a named owner for consequential actions?
Evidence to requestAccess policies, isolated environments, tool configuration and approval records.
04 / inspect
Evidence & independent acceptance
- Do tests exercise the requested behavior, negative cases and invariants—not just compilation or the implementation’s happy path?
- Can the implementer change or skip the acceptance criteria without a separate decision? Are review findings examined rather than treated as automatic truth?
- Do the results and review describe the same candidate and environment, with missing checks visibly marked as missing?
Evidence to requestA review packet: exact revision, selected checks, observed results, findings and unresolved risks.
05 / inspect
Budget & review capacity
- Are time, compute and retry limits explicit, with a defined response when the work reaches them?
- Is review capacity keeping pace with generated changes, without routine bypasses of important checks?
- Does the comparison include failed attempts, human correction and ongoing maintenance rather than only code-generation speed?
Evidence to requestAttempt limits, queue age, review and rework effort, and known or unmeasured costs.
06 / inspect
Recovery & transfer
- Can a new session distinguish completed work from intended work and identify partial edits, running jobs and uncertain external effects?
- Are integration and release decisions explicit, with a tested recovery path and limits on what a revert can undo?
- Can the named receiving team run the checks, operate the workflow and continue the work using the agreed accounts and documentation?
Evidence to requestInterruption records, release decisions, recovery procedures and a demonstrated handoff.
Apply the questions to your system.
Bring a defined scope to a review, or discuss an engineering engagement directly. For an investment or acquisition, ask about technical and AI diligence.