AI coding agents increase code production faster than engineers can review it, which encourages skipped reviews and rubber-stamping.
2
Agents optimize for code that runs and makes progress, so they can add hidden defaults, failure conditions, brittle recovery paths, and source-code entropy.
3
Teams should preserve human judgment at high-stakes points, using code structure and mechanical checks to make those points visible.
Summary
Armin Ronacher and Cristina Poncela Cubeiro describe a problem with AI coding agents that is partly psychological and partly architectural. Agents make coding feel productive and addictive, but their speed creates pressure to ship more code than engineers can understand and review. They optimize for making progress and passing tests, which can produce hidden defaults, brittle recovery behavior, duplicated code, and technical debt. The speakers compare libraries with products: libraries often have tighter boundaries, while products contain interacting UI, APIs, permissions, billing, and feature flags that agents cannot understand as one global system. Their response is an agent-legible codebase with modular components, explicit code flow, known patterns, and mechanical rules. They also recommend a review extension that separates automatic fixes from changes requiring human judgment, such as database migrations, permission changes, dependency choices, and reliability decisions. Friction is useful when it gives engineers a moment to steer.
AI speed creates more code than engineers can responsibly review
The speakers say AI tools first gave engineers extra time and made work more enjoyable. Once everyone was expected to use them, that free time became pressure to ship faster and produce more code. Each engineer gained much more production capacity than review capacity, so pull requests grew and reviews were skipped or rubber-stamped. The imbalance also brings more people into code creation, including marketing staff and former CEOs, while responsibility still rests with the engineering team. A 5,000-line pull request is therefore a warning that the review process has become overwhelmed, not evidence that the team is moving efficiently.
Agents optimize for progress rather than maintainable system behavior
Agents are optimized to write code, run tests, and make progress. The speakers give a configuration example: code may silently load default settings when it cannot read a config file. An engineer may only discover the problem after writing incorrect database records. Agents also add recovery paths for local failures, which can leave services hobbling along and create brittle systems. As the codebase grows, the agent may stop reading relevant files and create a new implementation of something that already exists. This produces more failure conditions and more source-code entropy than the speakers normally expect from human-written code.
Libraries are easier for agents than products because their boundaries are tighter
The speakers have found that agents tend to perform better on libraries than on products. A library often has a clearly defined problem, a constrained feature set, and a simple core that other code can build on. Products combine many interacting concerns, including UI, API responses, permissions, feature flags, and billing. Those relationships are difficult for an agent to fit into its context and understand globally. An agent can make a locally reasonable change while missing how it affects the rest of the product. This is why the codebase must be designed so the agent can read its structure and boundaries.
An agent-legible codebase makes components and code flow explicit
The speakers propose treating the codebase as infrastructure for the agent. Modular components let an agent add a feature in one place without corrupting unrelated code. The flow inside those components also needs clear boundaries. Cristina describes an assistant whose main steps are receiving a user message, passing it into the agent loop, and handling the output. The agent tends to add fuzz between those steps, such as extra state or conversions between types. Clear stages make those additions easier to see. The speakers also recommend simple cores, complexity in separate abstraction layers, and established patterns that fit the agent's learned behavior.
Mechanical rules expose mistakes before the agent can spread them
The team uses linting and conventions to reduce the number of places where an agent can make inconsistent changes. Their examples include banning bare catch rules, putting SQL through one query interface, using one primitives component library for UI, avoiding dynamic imports, and requiring unique function names. Unique names also improve token efficiency because a search returns a single relevant result. They are exploring erasable syntax-only TypeScript mode, where JavaScript with type annotations remains the source of truth and there is no separate transpiling direction for the agent to confuse with the source. These rules make intent easier to find and enforce.
Human review should be triggered by the kind of change, not every line equally
The speakers built a review extension that separates mechanical bugs from changes that require a human decision. The agent can automatically fix the first category, while the review calls out places where a person's judgment must reactivate. Database migrations need review because the decision depends on locks and the amount of production data. Permission changes need review because they can be under-documented. Dependency changes also prompt a human to ask whether the dependency belongs in the codebase and whether its maintainers are acceptable. The goal is to feel the pain the agent cannot feel and to slow down where mistakes are costly.
Friction gives engineers the control needed to steer systems
The speakers accept that some shipping friction is annoying and should be removed. They distinguish it from deliberate constraints such as SLOs, which make teams consider a service's reliability needs, criticality, and staffing. AI agents create pressure to remove all such checks because they make work feel faster. The speakers argue that this is a mistake. Friction gives engineers a physical point of control, much as friction makes steering possible. It is where experience and judgment enter the process. Their practical advice is to identify the areas where speed feels harmful and deliberately add review or other resistance there.
"The agents are writing kind of code that is when you as a human, as a software engineer, start learning how to write code you wouldn't necessarily write."07:37
Who should watch
You are reviewing large AI-generated pull requests and finding that the team can produce code faster than it can understand it.
Your product has tangled UI, API, permissions, billing, or feature-flag logic, and agents keep making locally sensible changes that break global behavior.
You want practical review gates for migrations, permission changes, dependencies, and other changes where automatic fixes are unsafe.
