Building Trust in Coding Agents: Verification, Evals, and Agent Fleets

Trust is the central bottleneck to scaling AI coding agents effectively, and building verification skills, feature maps, and strict codebase constraints allo...

By Sean Weldon

Building Trust in Coding Agents: Verification, Evals, and Agent Fleets

TL;DR

Trust, not model capability, is the real bottleneck for scaling AI coding agents. By building verification skills (like Control Glass), a feature map, and strict codebase constraints (the Dune architecture), engineers can move from micromanaging a single agent to running autonomous agent fleets that automerge pull requests - scaling from near-zero output to roughly 1,000 shipped PRs a month.

Key Takeaways

What Is the Trust Curve in Agent Management?

Distrust in AI coding agents produces the exact same behavior as distrust in a human direct report: constant oversight and micromanagement. When engineers see agents "winging it" - guessing, hallucinating, or confidently claiming to have found the "smoking gun" for the hundredth time - trust erodes fast. This forces engineers back into the loop, copying errors and screenshots manually instead of letting agents work independently.

The speaker's own trajectory illustrates the curve directly. Month one output was low because of heavy manual oversight; by later months, productivity scaled to roughly 1,000 PRs shipped, with agents automerging code straight to main. Waking up to 20 already-landed, already-good PRs became the new baseline.

Management skills transfer almost one-to-one to agent management. Coaching, onboarding, and delegation - skills engineers already use with human reports - are the same skills needed to run agent fleets effectively.

How Does Verification Become the Core Skill?

Verification means giving agents the actual ability to run code, take CPU traces, capture heap snapshots, or drive simulators to test their own work. Without this capability, humans become the bottleneck, manually shuttling screenshots and error logs back and forth between the bug report and the agent. Verification doesn't guarantee good code, but it does guarantee correct code.

Two concrete tools operationalize this:

Together, these give agents a closed loop: reproduce the bug, instrument the app, apply a fix, and confirm the fix worked - all without human intervention.

How Are Skills Built and Maintained With PStack?

PStack ("potato snack") is a plugin of skills built incrementally by watching agents fail and codifying the fix as a markdown-based skill. These skills act like onboarding documentation for a highly skilled engineer who simply lacks organizational context - agents "assume too much" and often do things in stupid ways without this guidance.

Evals function as unit tests for agents, verifying that a skill actually works across different models. Two techniques prevent gaming the system:

Skills get "hill-climbed" using looped iteration - like the /loop command in Cursor - repeating until eval scores hit a maximum, such as 10/10.

How Do Teams Scale to Cloud Agent Fleets?

Local verification needs to be established before scaling to cloud-based fleets. Skipping straight to spawning thousands of cloud agents without trust-building wastes tokens and money on unverified, unreliable output.

Cloud agents - referred to internally as "Benny" - can autonomously reproduce bug reports using the same control skills built for local verification, confirming that fixes already exist on main without consuming any human time. The benefit compounds beyond the individual engineer to the entire team or company, since verified fixes propagate without manual review cycles.

What Is the Dune Framework and Why Does Architecture Matter?

Dune is the internal codename for Grokbot's architecture, described as "Next.js for Electron apps" but designed specifically for agent-written code. It bans patterns known to cause problems for agents and reviewers alike:

Dune enforces strict separation between Electron's renderer and main threads via import dependency checks in CI, preventing performance regressions that could break the 16ms/frame budget needed for 60fps. Features live in fully collocated directories so agents never need to search across the codebase - "shortest path is the best path."

Enforcement strength ranks in a clear hierarchy:

  1. Codebase architecture / import constraints (strongest)
  2. Static analysis, CI, compiler diagnostics
  3. Rules, skills, bugbot (softest)

Any repeated human code review comment should be converted into a hard rule, lint, or CI failure rather than relied upon for manual review indefinitely.

Is Rewriting or Working With Brownfield Code Better for Agents?

Brownfield or big-tech codebases often already have guardrails built for the "least capable engineer," making them surprisingly agent-friendly out of the box. Greenfield, vibe-coded apps have no such guardrails, leading to "organic architecture" that spirals as agents take shortcuts under no constraints.

Grokbot itself went through 600+ PRs to migrate from a vibe-coded prototype into the strict Dune architecture. The upfront investment in constraints pays off later through near-zero code review overhead.

What Are the Token Economics and Organizational Impacts?

Upfront refactoring and constraint-building consumes significant tokens, but this is framed as an ROI question against the cost of hiring more engineers - not as pure overhead. Grok 4.6 was announced at the same cost-per-token as 4.5 but with improved intelligence, reflecting an industry-wide focus on cost-intelligence tradeoffs over raw model size.

Strict architecture also has an organizational effect: it enables non-engineers - PMs, designers, GTM - to ship code directly. Grokbot's accessible, iMessage-like interface is described as a "ChatGPT moment" for non-technical users, contrasting with the more developer-centric Cursor IDE/CLI.

What the Experts Say

"When you see agents just winging it and guessing, hallucinating, confidently stating that they found the smoking gun for the hundredth time, but it's actually not the real problem, you lose a lot of trust."

This captures exactly why verification matters more than raw model intelligence - trust breaks down not from wrong answers, but from confidently wrong answers with no way to check them.

"Verification... doesn't guarantee your agent writes good code but it allows them to at least write correct code."

This distinction reframes what engineers should actually be optimizing for: not "smarter" agents, but agents with the infrastructure to prove their own correctness.

"I woke up today and there were 20 PRs landed and I just reviewed them on main - they were already landed and they were good."

This is the tangible end-state of the trust curve - full delegation, after-the-fact review, and confidence the output is solid.

Frequently Asked Questions

Q: What does "trust" mean in the context of AI coding agents?

Trust means an engineer's confidence that an agent's code is correct without needing to verify every step manually. Low trust leads to micromanagement - checking every action - while high trust allows autonomous operation, including automerging PRs to main without human review beforehand.

Q: What is a "feature map" and why is it useful?

A feature map is a file encoding navigation paths, DOM/CDP selectors, and keyboard shortcuts for every feature in an application. It helps agents convert vague bug reports, like a screenshot with "???," into concrete investigation paths inside the actual codebase.

Q: What is Control Glass?

Control Glass is a skill that teaches agents to use the Chrome DevTools Protocol or Apple simulator utilities for programmatic control and performance tracing. It lets agents reproduce bugs, instrument the app, and confirm their own fixes without human intervention.

Q: How do evals prevent agents from gaming their own tests?

Evals spawn sub-agents in isolated, cleverly-named directories so agents can't detect they're being evaluated, since detection changes behavior. A separate judge agent, running a different model, cross-references scores to reduce bias from self-evaluation.

Q: Why does Grokbot's Dune architecture ban code comments and useEffect?

Agents frequently write irrelevant or misleading code comments and misuse useEffect in ways that cause bugs. Banning these patterns via CI hard failures removes reliance on manual review, enforcing correctness at the architecture level instead of through soft rules.

Q: Is it better to start with a brownfield codebase or build greenfield for agents?

Brownfield, big-tech codebases often already have guardrails built for the "least capable engineer," making them relatively agent-friendly. Greenfield, vibe-coded apps lack these guardrails, leading to "organic architecture" that spirals out of control as agents take undisciplined shortcuts.

Q: What is the ROI argument for investing tokens in refactoring?

Refactoring and building constraints consumes significant tokens upfront, but the framing compares this cost against hiring additional engineers rather than against doing nothing. Grokbot's 600+ PR refactor into the Dune architecture enabled near-zero code review overhead afterward.

Q: Can non-engineers use agent fleets built this way?

Yes. Strict architecture and constraints reduce the risk of agents shipping broken code, enabling PMs, designers, and GTM staff to ship code directly through interfaces like Grokbot's iMessage-style app, described as a "ChatGPT moment" for non-technical users.

The Bottom Line

The central insight here is that scaling AI coding agents is a trust problem, not a raw capability problem - verification infrastructure, documented skills, and strict codebase constraints are what convert distrust into confident delegation. Engineers who skip straight to spawning thousands of cloud agents without building this foundation waste tokens and money on unreliable output they still have to babysit.

This matters because the payoff compounds: verification and architecture investments that feel expensive upfront (600+ PRs of refactoring, token-heavy eval loops) eventually produce near-zero review overhead and let entire teams - including non-engineers - ship code safely. The organizations winning with agents aren't necessarily using the smartest models; they're the ones who've built the guardrails that let agents work independently and correctly.

If you're building with coding agents today, start local: build a verification skill (like Control Glass), document a feature map, and convert every repeated code review comment into a hard CI r

Sources

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub