Podcast Wiki

AI Verification

6 min read

Summary: Don’t trust what an agent says it did; make it prove it. Read its outputs instead of “bypass reading”, demand evidence (“show me, prove it”), and build concrete, proportional checks: open and quote sources, check links and logic. For code, verification becomes proof of work: after aligning on spec and plan, the agent must show the feature running end to end (e.g. a recorded browser run), with tracing so the harness can see what the code did. Green tests aren’t enough on their own, since models can fake them and huge AI-written diffs are unreviewable, so build in small steps and check that tests match requirements. Each check, once built, becomes a guardrail, so the effort drops over time.

Key ideas

  • An article she’d polished turned out to have wrong links, wrong references, and wrong content: the retrieval had been guessing (osim-tochna—second-brain-and-llm-wiki, dana-maman).
  • Rule: fact-checking means open the source, read it, quote it properly, then report; plus a separate logic checker (osim-tochna—second-brain-and-llm-wiki).
  • On “safe to delete 4.86 GB”: “Are you sure? Where is it stored? Show me, prove it” (osim-tochna—second-brain-and-llm-wiki).
  • Verification should be concrete and proportional, e.g. open every link in a browser for something that must be 100% right; connects to loop engineering (osim-tochna—second-brain-and-llm-wiki, amit-bendor).
  • Coding alignment ladder: spec (product) → plan (technical) → proof of work (it really runs). Before this, agents delivered buggy code that didn’t even compile (langtalks—73-harness-engineering).
  • Frontend proof of work: a Playwright MCP/browser the agent controls (DOM, logs, snapshots) that records a video of the feature clicked through end to end (langtalks—73-harness-engineering).
  • A custom agent browser profile can hand off to a human when intervention is needed and record sessions built in (langtalks—73-harness-engineering).
  • Add PR-time agents that check code standards, security, and review quality (langtalks—73-harness-engineering).
  • Tracing (OpenTelemetry, VictoriaLogs) lets the harness query what the code actually did. In microservices a change touches several services, and without queryable logs the agent is blind (langtalks—73-harness-engineering).
  • With spec-driven development and proof of work (E2E tests, unit tests, linting), one host reports reading code diffs less and less (langtalks—71-claw-architectures).
  • Definition of done as a contract: the agent mustn’t stop until it’s met. For UI, design first (Pencil.dev or Claude Design with your design system) and require visual parity (langtalks—70-our-claude-code-tips).
  • Some DoDs are hard to automate (e.g. is recorded voice free of echo?); agents also still produce odd UX logic that needs a human pass (langtalks—70-our-claude-code-tips).
  • Code review is alignment, not just a quality gate: an agent won’t catch a PR introducing a technology the architect never approved, or drift between spec and implementation; feed it broader org context (langtalks—68-ai-sdlc, yonatan-maor).
  • AI validates AI at every step (PRD, tech design, code review, CI) with different prompts than those that generated the artifact, but a human always stays accountable (langtalks—62-ai-rd-rollout).
  • A million-line AI-generated PR porting Bun from Zig to Rust passed tests, but the community panicked: nobody can review a million lines, and models are known to fake tests (“return true”) (explainable—163-hidden-cost-of-agents).
  • A professor found ~60% of an LLM’s working code irrelevant; dead code bites at 3 a.m. when you must know where to look. Agents can’t debug an outage fast without human direction (explainable—163-hidden-cost-of-agents).
  • Practical rule: build in small steps, understand the logic and business requirements of what goes in, and check the tests are meaningful and tied to requirements (explainable—163-hidden-cost-of-agents).
  • Mandatory AI review on every PR (backward compatibility, dependencies, SQL injection, XSS, circular dependencies) that flags rather than blocks, with a human override button. AI can survey a many-file commit more broadly than a human reviewer (osim-tochna—gong-ai-for-developers, ohad-parush).
  • Design-first: have the agent analyze alternatives with criteria (cost, ease of migration, maintenance) and write a plan before code; afterwards, sync the design doc back to Confluence from the code so docs stay a source of truth (osim-tochna—gong-ai-for-developers, ohad-parush).
  • Generation and review have opposite incentives: coding agents are built to finish and please (they rarely refuse), while a reviewer must stop you and explore every case, a “criminal mind” like hardware verification. So review needs different technology (memory, context collection, continuous learning), not the coding agent with another prompt (hidden-layers—qodo-itamar-friedman, itamar-friedman).
  • “Code quality” becomes measurable by splitting it: direct intent (vs the ticket or Figma), architectural intent, maintainability and best-practice rules, testability, and compliance. Tribal knowledge (PR discussions, Slack, code later changed) can be mined into rules and skills, with violations tracked over time (hidden-layers—qodo-itamar-friedman, itamar-friedman).
  • Best practice: review during generation (inject “why CPU here when every past project used GPU?”) rather than only at the end (hidden-layers—qodo-itamar-friedman, itamar-friedman).
  • Give remote agents a developer’s self-testing tools as skills: deploy the microservice via MirrorD, test the backend with real production data, open a browser and run Playwright, and attach before/after screenshots and video to the PR so the reviewer sees the intent was met (ai-engineering-podcast—atlas-ai-teammate, tomer-brook)
  • The goal is a developer who arrives at a green PR with evidence and just merges; that visible proof builds trust, and FOMO, among developers (ai-engineering-podcast—atlas-ai-teammate, tomer-brook)
  • Candor builds trust: an agent that reports “honestly, I can’t guarantee this works, these external triggers never ran” earns more trust than one claiming everything is fixed. Acknowledging the request before acting helps too (startup-for-startup—366-qa-for-agents, roy-mann)

Disagreements & open questions

  • Should the code generator also review its own code? Anthropic launched Claude Code review (validating that review is worth $15–25 each); Friedman calls its results underwhelming and argues for an independent reviewer because of expertise and conflict of interest, like observability and security that AWS never displaced (hidden-layers—qodo-itamar-friedman, itamar-friedman).
  • How much code must humans read? With spec-driven development and proof of work, one LangTalks host reads diffs less and less (langtalks—71-claw-architectures); the ExplAInable hosts argue you must understand what goes in, or you can’t fix it at 3 a.m., and that tests alone can be faked (explainable—163-hidden-cost-of-agents).

Takeaways

ai-guardrails · wiki-retrieval · harness-engineering · ai-sdlc

Graph View

Backlinks