AI
The Productivity Illusion
Engineers hit a shift with these tools: early on they saved time, then everyone adopted them and the baseline expectation became shipping faster. The free time converted to pressure. The trap has two parts. The tools are addictive. One more prompt might finish the feature or collapse the product. And the volume of output tricks engineers into feeling productive while they actually spend less time on design. Agents keep running, reading files they should never touch. The engineer who holds responsibility has to be the one who stops.
How Agents Produce Brittle Code
Agents are trained to make progress. That means writing code that recovers from failures rather than halting, which creates systems that hide problems silently. Armin’s example: an agent reads a config file, falls back to defaults on error, and a developer spends two hours writing database records with wrong data before noticing. Agents also expand codebases faster than they can later read them, duplicating code and losing track of what exists. Months of technical debt accumulate in days. Human engineers feel bad writing code like this. Agents do not.
Designing a Codebase the Agent Can Read
Cristina’s framing: treat your codebase as infrastructure, designed to be legible to the agent’s context window. In practice, that means modularizing code flow so the agent adds fuzz only between defined steps, and following known patterns to align with its reinforcement learning. At Earendil, linting bans bare catch blocks and raw SQL outside a single query interface. One UI primitives library, no dynamic imports, and enforced unique function names. A grep for one function returns one result, which keeps the agent’s token budget low and stops it from duplicating code that already exists elsewhere.
Where Your Judgment Still Has to Live
Some changes require human judgment regardless of how clean the codebase is. Database migrations depend on lock behavior and production data size. Permission changes can be underdocumented. At Earendil, a custom PI extension splits review output into two buckets: items the agent can fix automatically (mechanical violations, AGENTS.md breaches) and items that need a human decision. The separation is intentional. Armin’s analogy to SLOs: engineering has always used friction deliberately, to make you ask whether you have the staffing and reliability to support what you are about to ship. Removing that friction removes steering.
Notable Quotes
the ones that can carry responsibility. Armin Ronacher · ▶ 6:39
the global scale it becomes a bit demented. Cristina Poncela Cubeiro · ▶ 10:31
But it is so devious if you start Armin Ronacher · ▶ 15:54
Key Takeaways
- Agents produce code that silently swallows errors; humans need to feel that pain deliberately.
- An agent-legible codebase uses linting, unique function names, and a single SQL interface to keep context clean.
- Friction in code review is not waste — it is the mechanism that keeps human judgment in the loop.