Verification outside the agent: what keeps a team standing when AI writes the code

On October 12, 2026, Bloomberg reported that Epic Games delayed a project and, per the report, asked developers to move to an "AI-first" production model with no more handwritten code. Tim Sweeney confirmed the company's AI pivot, not the details of the directive. The next day, Microsoft published a piece about the agent that resolves production network incidents in Azure Networking, with a lesson attached: no single mechanism is enough, and the four boundaries described are all deterministic. When the mandate is "the agent writes", what sits between it and production?

At Develoz, we bring these checks together in the rails-quality-assurance gem. It combines code analysis, security audits and tests in development and CI. The agent receives the results to correct its work, but does not decide on its own whether that work can be accepted.

How we use rails-quality-assurance

These checks run in development and CI across all of our Rails projects, inside rails-quality-assurance, a gem of ours. The bin/ci command runs the sequence: RuboCop, Reek, Flay, JavaScript linting, markdown and YAML linting, dependency audits, Brakeman and RSpec. Coverage comes from SimpleCov configured by the gem, with 100% line and branch criteria, and the pre-commit hook is generated in the same pipeline. Each project inherits the RuboCop base from a single line, and local configuration adjustments stay explicit at the application level.

Review today is advice, not a gatekeeper

The most useful snapshot of the current state comes from the State of AI Code Review 2026 by Kodus, published at kodus.io/data, based on 180,739 suggestions. Three numbers matter: AI-written PRs receive 1.6x more findings, break internal team rules 2.1x more often, and 71.8% of PRs flagged with a problem were merged anyway, with the flag still open.

That last number defines the situation: review delivers a comment, and who decides to act on it is the author. When the author is an agent that never pauses, advice without consequence becomes debt at scale.

What each step checks

An agent that works well still fails in predictable ways, and each failure has a check that intercepts it.

Structural duplication and design problems. When solving two similar tickets, the agent tends to copy the solution instead of extracting an abstraction. Flay and Reek name identical fragments and structural problems, something the PR author rarely sees.

Static security and dependencies. The agent reproduces insecure patterns it read elsewhere. Brakeman flags attack surfaces in Rails code, and dependency auditing catches versions with known vulnerabilities. The GenAI Code Security Report by Veracode, published July 28, 2026, provides the backdrop: about 44% of code generation tasks produced a known vulnerability, and the security pass rate remains stagnant around 56%. The problem is not specific to one model.

Branch coverage. The agent tests the happy path and forgets the alternatives: a nil value, the external service throwing, a missing record. Requiring 100% line and branch coverage turns that omission into a build failure. In our own case, an &. over a never-nil value becomes an unreachable branch and fails the build: the check ends up policing the test itself.

Pre-commit hook. Before the PR exists, a hook runs RuboCop, Reek and RSpec on every commit. The agent receives the correction with context loaded, cheaper than discovering everything in CI.

Why the check must live outside the agent

Could the agent evaluate itself? On October 13, 2026, Martin Fowler's site published "Are Harnesses Worth the Cost?" by Naresh Jain. The experiment pairs two models on a single greenfield Java service, across 10 runs. GPT-6 Sol, the frontier model, passed all 178 acceptance tests in all 10 runs, with or without a verification harness; the harness multiplied cost by roughly 7. GPT-6 Luna, the cheaper model, went from 3 of 10 without the harness to 10 with it, and still cost about 33% less per run than Sol without one: $0.273 versus $0.406. The cost estimate excludes setting up and maintaining the harness. An observed direction on a single service, not universal proof or a savings guarantee.

The article's conclusion supports this post: what changes with model capability is sensor frequency, not the need for independent verification. For frontier models, the article suggests running checks once, as a final acceptance gate. We pick a practical side: cheap sensors compared to the cost of an error reaching production, so we keep verification in every cycle, even with strong models.

There is a second reason: the agent is probabilistic. Microsoft sums up its architecture in one principle: deterministic skeleton, probabilistic filling. What decides whether something reaches production cannot be the same component that guesses. On September 1, 2026, Manifold Security disclosed eight flaws, across seven CLI agents, that let the repository's own .git/config run attacker code before any trust prompt, with four of the eight unpatched at publication. The agent's environment is also an attack surface, the same point as the credential boundaries of the previous post.

The direction also shows up in the evolution of the stack itself. On October 13, 2026, the Rails Foundation published stage three of Agents on Rails, the same benchmark as the previous post, now with large, multi-step tasks where the agent extends its own prior work. Our reading: in those cases, the gap between what the agent believes it did and what the code does grows, and that gap is what the checks measure.

flowchart TD
  A[Agent writes code] --> B[Pre-commit hook<br/>RuboCop, Reek, RSpec]
  B -- fails --> A
  B -- passes --> C[CI pipeline<br/>style, security, tests,<br/>line and branch coverage]
  C -- fails --> A
  C -- passes --> D[Acceptance gate<br/>human review]
  D -- approved --> E[Merge and release]

The same idea in JavaScript and, next, Go

Rails remains our main stack, and the idea did not stay confined to it: @develoz/quality-assurance carries the same suite to JavaScript and TypeScript, released October 3, 2026. The package is too new to call battle-tested, and we do not make that claim. The structure differs, Biome, Vitest with v8 coverage, pnpm, but the design is the same: criteria that fail the build, outside the agent. It answers: "does this only work because you chose Ruby?". No.

An equivalent kit for Go is being prepared, with no announced date yet.

In summary

• rails-quality-assurance combines code analysis, security audits and tests to verify the agent's work.
• The Kodus study exposes a problem: 71.8% of flagged PRs were merged with findings still open. We do not recommend treating review as optional advice.
• At Develoz, we run checks in development and CI. Results guide corrections; business decisions stay with people.
• Rails is our main stack. The JavaScript and TypeScript toolkit exists; its Go counterpart is being prepared.

In another of our posts, human review and automation limits, we detail where human approval belongs when an automated flow ends. The same holds at the end of this pipeline: the checks remove the mechanical work, and the business decision stays with people.

Want to assess where agents and AI can enter your operation, connected to the systems already running? Request a diagnostic.