The shared question
Armin Ronacher and Simon Willison published these posts one day apart, apparently without responding to each other. But they raised the same underlying problem from different angles: when a coding agent lets one person ship a change without pulling anyone else in, what disappears along with the friction?
Ronacher’s answer is that teams lose shared understanding of their own systems. Willison’s answer is that agents should never blur who is accountable when something breaks.
What Ronacher says
Armin Ronacher, founder of the startup Earendil and previously a longtime engineer at Sentry, argues in The Tower Keeps Rising that software teams have always needed a shared language beyond the programming language itself.
“The shared language of a software project is not English or Python but it is the common understanding of what its concepts mean, where the boundaries are, which invariants matter, who owns what, and why the system has the shape it does,” he writes.
That understanding used to form through friction: pull requests, code review, and the conversations required to change someone else’s part of a system. Ronacher treats this friction as useful, not just overhead. “This friction synchronizes people,” he writes.
His worry is that a coding agent removes the friction without replacing what it built. One engineer can now hand an agent a task like “add caching” and merge the result without any of the coordination that used to accompany that kind of change. Nothing breaks right away. The codebase keeps working.
That is exactly what concerns him. “The tower does not fall, and so we do not notice what was lost. It just keeps rising,” he writes.
What Willison says
Simon Willison, an independent AI researcher and the creator of the Datasette and LLM open source projects, took up a narrower but related question in a short post on Directly Responsible Individuals. The term names the one person accountable for a project’s success or failure, an idea that started at Apple and is now common at companies like GitLab.
Willison’s position is direct: “I don’t think an agent should ever be considered the DRI for a project - that’s something that feels uniquely human to me, because humans can take accountability for their actions where machines cannot.”
He points to an old IBM training slide from 1979 to show this is not a new idea: “A computer can never be held accountable, therefore a computer must never make a management decision.”
Where they agree, and where they diverge
Both posts share a premise. Agents can now absorb work that used to require a person, and that shift changes something structural about how teams operate, not just how fast individuals move.
They diverge on what is actually at risk. Ronacher is worried about tacit knowledge, whether anyone still understands why a system looks the way it does. Willison is worried about a formal designation, whether a human stays clearly answerable when something goes wrong.
Put together, the two posts describe a gap opening on both ends of a project. Nobody had to build a shared mental model before a change shipped, and nobody is clearly on the hook for it afterward.
What’s incomplete in both
Ronacher’s essay is strong on diagnosis and light on remedy. He does not say what a team should do differently. Should code review stay mandatory even when an agent could ship without it? He leaves that unresolved.
Willison’s post is short enough that it reads more like a principle than an argument. It is easy to agree an agent should not be the DRI. It is harder to say what changes in practice when the human named as DRI approved a change they only skimmed, because an agent wrote most of it.
Neither writer connects the two problems directly, but the connection matters. A DRI who lacks the tacit understanding Ronacher describes is a DRI in name only. Accountability without comprehension is a weaker form of accountability.
What it means for builders
If your team ships more changes through agents with fewer people involved, treat that as a deliberate tradeoff, not a free efficiency gain. Decide which categories of change still require a second person to read and understand the result, not just approve it.
Keep the DRI model, but tie it to something concrete. The named accountable person should be able to explain why a system works the way it does, not just that a task was marked complete. If they cannot explain it, the review was not real, even if it happened.
Speed from agents is not free. Somewhere, a team has to decide where it will keep paying the coordination cost on purpose, because the alternative is losing track of both how the system works and who answers for it.
End of article