The Trust Ladder for AI Coding Agents: Install the Brakes Before Building the Software Factory

AI coding agents are evolving from "help you write code" to "run the factory for you," but the most overlooked part of this evolution isn't model capability—it's the order in which trust gets established. A deep conversation about software factories, verification mechanisms, and human taste delivers a counterintuitive answer: step on the brakes first, then the gas.

The Trust Ladder: From 90% to 95%, How Many Agents Can You Run?

According to cross-discussions among multiple developers on Bilibili and YouTube channels, a consensus is forming in the AI coding world: the core of a software factory isn't "more agents" but "higher trust." Someone proposed the concept of a "trust ladder"—if you trust that an agent has a 90% chance of doing the right thing, maybe you can run 50 agents simultaneously; if you can get to 95%, the number you can run rises significantly. Every step up the trust ladder multiplies the scale of parallel automation.

The way to put this logic into practice is to break the "idea to production" process into a chain of checkpoints. Every gate where humans intervene is a door that can be gradually removed. The first one to dismantle is "initiating work": when the system can trigger agent sessions on its own—say, scanning GitHub issues on a schedule and automatically dispatching sub-agents—only then have you truly crossed the threshold of a software factory.

But removing doors doesn't mean removing all guardrails. During the conversation, someone stressed that once you start imagining "fully unmanned," another class of problems immediately surfaces: how does the factory manage itself long-term? Almost everyone who has tried frontier approaches has hit the same phenomenon—agents plant bad seeds in the environment, keep producing garbage, and eventually the factory grinds to a halt on its own.

Why the "Dark Factory" Falls Into a Death Spiral

To understand this stalling mechanism, you have to see agents as stateful processes. The codebase isn't a static backdrop; every line an agent writes changes the environment, and the changed environment in turn affects the agent's next judgment. This two-way feedback produces "strange trajectories": one error gets planted in the codebase, and every subsequent generation is skewed by it, drifting further and further off course.

According to observations from multiple frontline developers, no architecture today can fully sidestep this problem—unless a human with good judgment intervenes at key nodes. This is exactly the boundary of the term "software factory": it describes removing humans from parts of the loop, not showing them the door entirely.

Install the Brakes First: Verification Capability Sets the Speed Limit

One judgment was repeated throughout the conversation: "You have to install the brakes first—otherwise quality won't be high enough, and your app becomes a machine that spews garbage." Personal software and production software are two different things. Personal tools can be played with freely, but production software faces real constraints—other people's kids might actually be depending on this software to make a living.

Many organizations can't get their agents running not because the models are inadequate, but because agents can't prove their code actually works. Complex microservices and deeply nested infrastructure make "just run it and see" a luxury. So when an agent submits a PR, if it can run against a production-like database, show you screenshots, and assess the blast radius of the change itself, the team's sense of trust is completely different.

This also explains a common mistake: organizations want to build customer-facing features right away, when what they should build first is the DevOps layer—raising the floor for failure. First figure out "how do we detect problems fast and catch them when things go wrong," then talk about raising the ceiling.

Three Layers of Anti-Cheating: Lint, Automated Review, Human Spot-Checks

Agents cut corners, take detours, and pick the easiest path. The solution offered in the conversation is a three-layer structure:

The first layer is automated checks. Lint rules running on the implementation agent can intercept bad patterns at the type-system level; frameworks like Effect ship with a set of such rules.

The second layer is automated review, and it's severely underrated. Most teams only use an implementation agent and never give it a second look. But telling the implementation agent "don't do X" may actually fill its head with X; give the same requirement to a review agent instead, and it becomes a positive instruction—go find X in the diff and delete it.

The third layer is human review, and the goal is to need as little of it as possible. The key concepts here are "one-way doors" and "two-way doors": changes that can be easily rolled back are two-way doors and can be waved through boldly; anything that can't be taken back once sent—like emailing 50,000 people—is a one-way door. Every one-way door must have a human gatekeeper. Industries like law and medicine have more one-way doors, so the speed dividend agents can deliver is naturally smaller.

Lint is the collective term for static code analysis tools, originally used in C to detect suspicious code patterns that might cause bugs; today mature implementations exist in most language ecosystems (ESLint, RuboCop, Clippy). It differs from testing in that tests verify "whether code behavior matches expectations," while lint checks—without running the code—whether "the code's writing style itself belongs to a known bad pattern": unused variables, unsafe type casts, naming that violates team conventions, and so on. For agents, lint's value lies in its extremely fast feedback, clear rules, and machine-readable output, requiring almost no extra explanation cost—making it ideal as the first line of automated guardrails. Combined with the type system, it can block at compile time a large volume of code that agents tend to write—code that "looks like it runs but has a landmine buried inside"—raising the overall quality of the diff that review agents and human reviewers later face.

The Codebase Itself Is the Biggest agents.md

An easily overlooked insight: many people treat agents.md as the place to store all instructions, but the codebase itself is a giant agents.md written entirely in code. Agents read it, understand it, search it. Any improvement you make to the codebase becomes a contextual dividend for every subsequent session.

So the highest-priority automation tasks are the scheduled jobs that "just stare at the codebase and make it better." The returns from this kind of loop compound—every subsequent coding session stands on a better foundation.

Paired with this is "intentional statelessness": the implementation agent is loaded with work—exploring, coding, verifying, debugging—while the review agent is extremely lightweight, receiving only a diff, so a large volume of coding standards can be packed into it and judgment made with a fresh context window. Some take the opposite route, building a complete stateful knowledge base and benefiting from it. Both opposing routes work, which itself shows there is no single answer today.

Language and Frameworks: Old Books Find New Life in the Agent Era

Classics like DDD and design patterns were hard to push inside organizations in the past because of the conversion cost of "teaching everyone." Now agents actually read what you give them, and these language constraints become executable for the first time. Some developers have turned large collections of classic PDFs into semantically searchable knowledge bases, letting agents dig through them for patterns and abstractions suited to the current system.

The conversation also mentioned a term: leading words—phrases that compress a complex process into a few words, like "grill me relentlessly." Such phrases act like seeds that repeatedly reinforce themselves within an agent's chain of thought, steering it down a certain path. Choose words carefully, because once a pattern is written down, it gets replicated over and over.

At the framework level, strong typing is favored by agents because constraints are guardrails. One participant redefined the value of Effect: not error handling, but dependency injection—putting the program into a value so the type system knows what it will produce, what it needs, and what errors it might throw, giving the agent a wealth of pullable feedback loops.

DDD (Domain-Driven Design) was introduced by Eric Evans in his 2003 book of the same name. Its core claim is that software structure should faithfully map the real concepts of the business domain: use "bounded contexts" to divide system boundaries, express domain rules with patterns like "aggregates," "entities," and "value objects," and push developers and domain experts to share a single "ubiquitous language." It has long been hard to push inside organizations because its benefits are long-term and diffuse, while its costs—unifying terminology, refactoring models, training everyone—are immediate and concentrated. What's different in the agent era: LLMs can read and retrieve these classic texts, proactively citing the relevant patterns during actual coding, turning "language constraints" that once depended on senior engineers' mentorship into executable prompt context. In other words, classic methodologies finally have a low-marginal-cost vehicle for dissemination.

Design patterns (the GoF's 23 patterns and others) are the same: they essentially compress recurring structural trade-offs into nameable vocabulary, and vocabulary is the most effective anchor for agents to understand intent.

Dependency injection means not constructing dependency objects directly inside a function, but having them passed in from outside as parameters, so components are decoupled, replaceable, and testable. Effect is a functional effect system in the TypeScript ecosystem that models the "program" itself as a lazy, descriptive value: this value carries three kinds of type information—what it produces on success (Success), what it may throw on failure (Error), and what environment it needs to run (Requirements). This is precisely what the speaker meant by "Effect's value isn't error handling but dependency injection": the type system fully records the program's input-output contract, and when an agent modifies code it gets precise feedback directly from type errors—"which dependency did I forget to pass," "what new kind of failure did I introduce"—forming a high-frequency, low-cost self-correction loop without having to actually run the service.

Taste Remains the Human Divide

The conversation lands back on people. Agents can raise the floor of a product, but it's hard to push the ceiling up to the level of something like Linear—that takes taste, and making hard trade-offs when information is incomplete. Strategic programming is hard because the feedback loop is so slow that you might change jobs before a strategic mistake catches up with you.

So the starting move is simple: one issue a day, start slow, build trust first. Find data sources that haven't been exploited yet—bug trackers, issue lists—hook them into agents via CLI, and turn them into reusable scheduled loops. Once the brakes are installed and the chain of evidence runs, ease off the accelerator little by little.

As for the claim that "learning is dead," the participants disagree. In an era when agents can write code for you, stopping to truly learn a framework or read a classic is actually preserving for yourself the one thing agents can't give you: judgment.

Background Notes

One-way door / two-way door is a decision taxonomy that Bezos popularized inside Amazon: two-way-door decisions are reversible and can be undone at low cost if wrong, so they should be decided quickly by individuals or small teams; one-way-door decisions are hard to retract once executed and require more deliberate processes and higher-level sign-off. This framework maps very directly onto agent governance—reversible code changes can safely be auto-merged by agents, while irreversible actions such as sending emails, modifying production data, touching payment configurations, or publishing externally must have human approval nodes. Its practical value is turning "should humans intervene" from a vague gut feeling about trust into a rule table that can be pre-classified by action type, making automation boundaries auditable, discussable, and gradually loosened.

One-line Summary

Scaling AI coding agents is bottlenecked not by model capability but by establishing verification and trust first, then gradually easing off the accelerator.

Paragraph Summary

Based on conversations with multiple developers, the article argues that AI coding agents are moving from assisting with code toward the "software factory," but the core variable is trust rather than agent count: each step up the trust ladder multiplies the scale of parallelism. The path to execution is to break the idea-to-production process into checkpoints, automating the "initiating work" stage first while keeping key human gates, because agents and the codebase form a stateful two-way feedback loop in which a bad seed can trigger a "dark factory" death spiral. The author stresses installing the brakes first—letting agents verify code against production-like environments, capture screenshots as evidence, and assess blast radius—putting DevOps and failure fallbacks ahead of customer-facing features. Anti-cheating relies on a three-layer structure: type-level lint, automated review agents using positive instructions to search diffs, and human approval for one-way-door changes. The codebase itself is the biggest agents.md, and scheduled loops that continuously improve it yield compound returns. Ultimately, strategic judgment and taste remain the human divide, and the starting move is one issue a day, starting slow to build trust.