The Friction is Your Judgment — Armin Ronacher & Cristina Poncela Cubeiro, Earendil

Armin Ronacher (creator of Flask, co-founder of Earendil) and Cristina Poncela Cubeiro (self-described 'native AI engineer' who learned engineering alongside AI tools, previously at Bending Spoons) deliver a candid, experience-driven talk arguing that the engineering instinct to eliminate all friction in shipping is actively harmful in the age of AI coding agents. The central thesis: friction is not waste — it is the mechanism of human judgment and steering quality.

The pair open with a concrete motivating example: a company's marketing tagline 'Ship without friction' appeared as a social preview on a forum post about a security incident caused by an accidentally deployed configuration change — illustrating in sharp irony how the absence of friction can directly produce production failures.

Ronacher identifies two interlocked problems. First, a psychological trap: AI coding tools are addictive in the same way slot machines are — engineers never know if the next prompt will ship a feature or introduce collapse-inducing slop. More insidiously, the high output velocity tricks engineers into feeling productive while they are actually skipping the design, review, and architectural thinking that produces quality software. The baseline expectation for speed has now risen across entire organisations, removing the slack that previously allowed thoughtful decision-making. He observes that the composition of engineering teams has shifted: marketing managers and former CEOs are shipping code via agents, but the responsibility for correctness still falls on engineers — creating a mismatch where the number of code producers dramatically outnumbers responsible reviewers, leading to rubber-stamped or skipped pull request reviews.

Second, an engineering challenge: agents are reinforcement-learning-optimised to produce code that runs, not code that is maintainable or architecturally sound. They silently swallow failures — for instance, writing config-loading logic that falls back to defaults without alerting developers, meaning wrong data may be written to databases for hours before anyone notices. Agents also create more failure conditions than human-written code, produce excessive entropy (duplicated logic, bloated PRs, unexpected state mutations), and eventually generate codebases too large and complex for the agent itself to navigate coherently. Products are particularly vulnerable compared to libraries; libraries have tight constraints and clear APIs, while products have deeply intertwined concerns (UI, permissions, billing, feature flags) that exceed any single context window.

To address these problems, the speakers propose designing 'agent-legible codebases' — treating the codebase as infrastructure the agent must be able to read. Concrete practices they have adopted at Earendil include: strict modularisation of both components and code flow so the agent can add features without corrupting unrelated areas; no bare catch-all exception handlers (enforced by linting); a single SQL query interface so the agent does not miss query sites; a single primitive UI component library (no raw input boxes); no dynamic imports; enforced unique function names for both legibility and token efficiency during grep operations; and adoption of TypeScript's erasable-syntax-only mode so there is one source of truth between source and compiler, helping the agent locate errors without transpilation confusion.

To reintroduce human judgment at high-stakes moments, they built a custom PyExtension (a review tool integration) that separates mechanical linting fixes (which the agent can auto-resolve) from human callout items: database migrations (where lock behaviour and production data size require human judgment) and permission changes (which tend to be under-documented and easy to get wrong). Seeing these callouts provides a cognitive 'hit' that reactivates careful thinking.

Ronacher closes with an analogy to SLOs: service-level objectives are friction deliberately engineered into shipping processes to force engineers to think about reliability and criticality. Agents have created pressure to eliminate all such friction, but without friction there is no steering. The speakers urge teams to identify the specific areas where speed is dangerous — system architecture, reliability design, database changes, permissions — and deliberately slow down there, while embracing agent speed for lower-stakes tasks like reproducing customer bugs or exploring product directions.