The best essays about programming are mostly forgotten. They were written before the web, circulated as photocopies and conference proceedings, and survived into the present on internal mailing lists.
That is how I came across Peter Naur's "Programming as Theory Building" at Google nearly twenty years ago. Naur wrote it in 1985. It reads as though it were written for the last eighteen months.
His argument is that the real product of building software is a theory: what the builders understand about why the system does what it does, what it is for and which parts carry the influence and weight. Code records the result. Documentation records what somebody thought to explain. Neither guarantees the next person can change it sensibly.
Naur was writing about software teams. The idea also applies to a company. An organization also carries an understanding of how its parts fit together. That understanding is spread across its people, routines and systems. It knows which exceptions matter, who gets to decide and why a process that looks wasteful may still serve a purpose.
Craig Mod reached a related point from the user's side in his 2019 essay, "Fast Software, the Best Software." Fast software feels respectful because it asks less of its user. His example was Sublime Text, an app that both writers and software engineers use daily. It had grown lighter with age as the small, focused team that built it removed delays and unnecessary choices.
That kind of subtraction requires a view of the whole. Adding one more option needs a reason for the option. Removing it requires a judgment about whether the product is better without it.
Until recently, turning an idea into software or process consumed scarce time. A request had to compete for an engineer, a budget and a place in the release. That friction forced choices. Which customer exception matters enough to support? Does this approval need another step? Could the existing system handle it?
Agents do not make those requests. People do. Sales wants an exception for a large account. Finance wants another check. A manager wants a different report. The person supplies the local knowledge, and the agent makes it cheap to turn that request into something permanent.
Each decision can be reasonable. Together they can produce a company nobody would have designed.
We have watched this happen in our own work over the past two years. Agents shorten the distance between a request and a working artifact. The time saved does not disappear. It returns in review, testing and the work of fitting each new thing into everything already running.
The weight appears in the product first. One customer gets an export, another gets a field, and a third gets a different approval path. A year later the product team knows why each addition was made but cannot tell which customers still depend on them.
Then it appears in the company. An agent adds a check, summarizes its result and sends it for review. Another agent summarizes the review. The original check may once have caught something important. It keeps running because nobody owns the decision to stop it.
It appears in the tools companies buy as well. Chat where a button would do. A paragraph where a number would do. Each feature demonstrates activity. Few procurement processes ask what work the tool will allow the company to stop doing.
Context systems do help. They can preserve the request, the discussion, the rejected alternatives and the reason a decision was made. That is a substantial improvement on the documentation Naur knew.
The larger problem remains even when the record is complete. Sales had a reason for the exception. Finance had a reason for the check. Operations had a reason for the second review. Remembering all three reasons does not tell the company which one should yield when they begin to conflict.
A company can remember why everything was added and still have no theory of what it should keep.
This is where subtraction becomes an organizational craft. Someone must see across the local decisions, decide which concern matters now and have permission to act. Most companies give every team some authority to add. The authority to remove sits nowhere in particular. The benefit of removal is spread across the company, while the risk lands on the person who proposed it.
Before adding something, ask whether it can replace something already there. If it cannot, decide when it will be reviewed and who can remove it later.
The companies that stay fast will keep taking things out.