Skip to content

Knowledge base

The surrounding quality system

AI magnifies the engineering practices a team already has. Solid source control, observability and small batches turn into speed, while a review bottleneck or a brittle pipeline turns into longer delays and more breakage. The rules, reviews and hard checks around the agent steer what it produces.

Written by

Updated:

Agentic Engineering 5

Our position. We hold that AI amplifies what an organization already is and does not repair a weak one. You feed AI slop, you get slop, so we fix the quality standards first (opens in a new tab) and then use AI within them.

The same amplification works on understanding. AI widens the gap between what the code does and what the team understands it to do, and that gap feeds ordinary technical debt.

Why does AI amplify the practices a team already has?

The 2025 DORA report’s core finding is that AI magnifies whatever practices already exist: if code review is already a bottleneck, higher change volume creates longer delays; if the deployment pipeline is brittle, it breaks more often; organizations lacking foundational capabilities see AI adoption correlate with decreased performance, more friction, and greater instability, while teams with solid source control, observability, and small-batch shipping gain speed and resilience (DORA 2025 Report and AI Strategy).

Practitioners converge on the same mechanism at codebase level: quality infrastructure is what steers the agent. The Code Quality Foundations article groups the techniques into rules (lint rules that ban any and type assertions, cap complexity, depth, and file size, and prohibit generic utils/helpers naming), reviews (feedback loops on produced output), and blocks (hard checks so neither can be bypassed); hitting a lint limit forces the agent to produce more modular, better-named code (Code Quality Foundations for AI-assisted Codebases (opens in a new tab)). A project report describes the same inversion from project experience: with verification set up front (tests, lint, type checks, strict mode, pre-commit hooks, mutation testing to close the agent’s self-feedback loop), “features just kind of happened”; quality is the enabler of fast delivery, not a tax on it (The way to deliver fast with AI: Quality (opens in a new tab)). One operational detail from the article sharpens the pattern. Keep one source of truth for conventions and have every tool point at it, so CLAUDE.md, the automatic reviewer agent (fired by a hook every time the agent finishes), and the CI reviewer all enforce the same files rather than three drifting copies (Code Quality Foundations for AI-assisted Codebases (opens in a new tab)). The article also locks the gates against the agent that is trying to pass them, which Deterministic quality gates covers.

Earendil, the company behind the pi coding agent, turns the same idea into a list of mechanical checks aimed at agent legibility. Lint rules ban bare catch-alls, so a concealed failure is detected without a reviewer remembering the convention. All SQL goes through one query interface and all UI through one primitives library, so an agent never has to hunt for a second site that also needs the change. Dynamic imports are banned, and function names are enforced unique, because a grep that returns one result costs the agent less context than one it has to disambiguate. The team is also trying TypeScript’s erasableSyntaxOnly mode, which rejects constructs such as enums that need runtime transformation, so the source the agent reads stays close to the code that runs (AI Engineer - The Friction is Your Judgment (opens in a new tab), AI Engineer Europe 2026).

The Dark Factory model names the failure mode when this order is reversed: the Bullshit Factory, production infrastructure without mature validation infrastructure. The factory produces high-volume output that is largely unusable, not because of bad agents but because weak quality gates are easy to pass, and agents optimize to pass the gates. The correct sequence is validation and observability first, production volume second; and the source of truth is programmatic tests and fitness functions, not the specification, because specs describe intent while tests check reality (Dark Factory Patterns).

AI amplifies a second thing besides the quality gates: the gap between what the code does and what the team understands it to do. The Triple Debt Model separates three places this risk accumulates. Technical debt lives in the code, observable and refactorable; cognitive debt lives in people, the erosion of a team’s shared understanding of the system over time; and intent debt lives in artifacts or their absence, the missing rationale, goals, and constraints that humans and agents both need to evolve the system safely. AI is a multiplier, and it multiplies the debts we are worst at managing: tools are good at generating code and even at measuring technical debt, but few improve understanding or preserve intent, so that is where the real risk shifts (From Technical Debt to Cognitive and Intent Debt (opens in a new tab), 23 March 2026).

Intent debt shows up as agents making plausible-but-wrong decisions and burning tokens because the architecture’s why was never written down; the mitigations are decision and rationale records (ADRs), domain-driven design that makes intent explicit before it is encoded, and executable intent such as BDD specs that reveal when the system drifts from its purpose. Thoughtworks tracks the same cognitive-debt idea and warns that AI’s higher change velocity widens it, especially with multiple contributors or agent swarms, until it forms a reinforcing loop with ordinary technical debt where each makes the other harder to pay down (Thoughtworks Technology Radar Vol 34, April 2026 (opens in a new tab)). The compounding cost is not just messy code. A team that no longer understands the system steers the agent worse, missing the edge cases and architectural traps a maintainer would have caught, so weaker understanding produces weaker code, which further weakens understanding.

This is the same shared mental model that code review exists to protect. On 9 February 2015, the Code Review Essentials article argued that review’s primary function is not catching bugs but keeping every team member’s model of the system aligned as it changes, ranking bug-catching and style below that; nitpicking indentation and names is work that should be automated at check-in so review can spend itself on the harder alignment (Code Review Essentials for Software Teams (opens in a new tab)). When generation is cheap and the reviewer’s attention is the scarce resource, protecting that shared model is exactly what is at risk. The research offers a blunt way to diagnose the erosion in a retrospective: can the team explain a module without opening the code, debug it at 2am without the AI, say why this implementation was chosen, and still maintain it if the AI went away. Enough “no” answers mean the understanding has already gone (From Technical Debt to Cognitive and Intent Debt (opens in a new tab), 23 March 2026).

Resources

Talks