One reason European art advanced so dramatically during the Renaissance was that paper became cheaper and more widely available.
Before paper, artists often worked on expensive surfaces (e.g., parchment), so the experimentation was constrained. More accessible paper changed that. Artists could make preparatory sketches, study anatomy, experiment with perspective before committing to a final work.
Paper was not the only reason for the increase in quality, but it gave artists something essential: more opportunities to practise. And practice makes perfect.
AI agents may create a similar shift in software development. They make it dramatically cheaper to sketch things out. A developer can explore multiple architectures, rewrite a component several ways or build prototypes that would previously have required too much time.
The downside is a loss of what Martin Thompson calls mechanical sympathy: an understanding of how the underlying machine works and how to work with its constraints rather than against them.
When agents write more of our code, we may understand the computer less. More importantly, we may also understand the systems we are building less. We lose not only sympathy for the machine, but also a broader sympathy for the software system itself.
Software Sympathy
The loss of software sympathy can be felt acutely. When you build a system yourself, you develop an intuitive sense of how it works and how different decisions will affect it. It is like living in the same neighborhood for ten years: you carry a detailed mental map in your head and can find your way around without thinking.
Without that familiarity, every decision comes with a lingering question: “Is this right?” You are never quite sure.
This will almost certainly have negative consequences: hidden complexity, fragile abstractions and systems that become difficult to debug when something goes wrong.
What we do not yet know is how large those consequences will be.
At the same time, agents give us the ability to practise at a scale that was previously impossible. A developer might understand any single implementation less deeply, while developing a much broader understanding of the overall solution space. Instead of spending a week implementing one approach they might explore five approaches.
That broader experience could partially compensate for the loss of software sympathy. It may even produce a different kind of expertise: stronger intuition for architectures, tradeoffs, failure modes, and possible solutions.
The analogy is imperfect. Renaissance artists still made their own sketches, while developers often delegate the implementation itself to agents. Producing more work is not necessarily the same as practising, especially when the person does not study the result or understand why it works.
Perhaps the best approach is to preserve enough sympathy to evaluate what agents produce, while using agents to explore the solution space. The goal should be to minimize the loss of depth while capturing as much of the new breadth as possible.
Of course, not every use of an agent reduces your understanding of the system. For many kinds of work, such as cross-cutting updates and refactorings, agents can be a huge net positive without weakening your understanding of the codebase.
This is where meta-harnesses like Polygraph are meant to help: they make agents much more effective at these kinds of tasks.
