TL;DR
- The real product of building software is a theory of why the system does what it does. Code records the result, not the understanding.
- Companies carry a theory too, spread across people, routines and systems. Agents make it cheap to add to that system and no cheaper to subtract from it.
- Every team has some authority to add. The authority to remove usually sits nowhere in particular, because the benefit is spread and the risk lands on whoever proposed it.
- Before adding, ask what it replaces. If it replaces nothing, decide now when it gets reviewed and who is allowed to take it out.
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. That is the same failure of measurement I wrote about in Goodhart's Law and the wrong measures for agent outputs: counting what was produced rather than what it was for.
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.
Where Moative fits
Moative works as an AI operating partner with mid-market companies, and this is the part of an AI rollout that rarely appears in the business case. When we sequence work in healthcare revenue cycle management or claims processing, we look as hard at what a change lets you stop doing as at what it adds, because a process that only ever accretes gets more expensive to run every quarter. That means naming, up front, who is allowed to remove a check, a report or an exception once it stops earning its place. If your AI programme has an owner for every addition and no owner for removal, that gap will cost you more than the tooling did.
Frequently asked questions
What is Peter Naur's "Programming as Theory Building"?
A 1985 essay arguing that the real product of software work is a theory held by the builders: why the system does what it does, what it is for, and which parts carry weight. Code records the result of that theory. Documentation records what somebody chose to explain. Neither transfers the theory itself to the next person.
Why does AI make software and processes harder to remove?
Because it removes the friction that used to force choices. A request once had to compete for an engineer, a budget and a release slot, and most requests lost. Agents make it cheap to turn any reasonable request into something permanent, so far more of them survive, and each one still has to be reviewed, tested and fitted to everything already running.
Who owns the decision to remove a process or feature?
In most companies, nobody in particular. Every team has some authority to add. Removal is rarely anyone's job, because the benefit is spread across the whole company while the risk lands on the individual who proposed it. That asymmetry, not laziness, is why things accumulate.
Do context and memory systems solve process bloat?
No. They solve the record, not the judgment. A good context system preserves the request, the debate, the rejected alternatives and the reason a decision was made. It still cannot tell you which of three competing reasons should yield when they conflict. You can remember why everything was added and have no theory of what to keep.
How do you stop an AI rollout from adding complexity faster than value?
Make replacement the default question. Before adding something, ask what it replaces. If it replaces nothing, set a review date and name the person allowed to remove it. The cost of skipping that step is not visible in the first quarter; it shows up a year later as a system nobody would have designed.
What is the sign that a company has lost its theory of itself?
It can explain every individual part and cannot say which parts matter most. Product teams know why each customer-specific addition was made but not which customers still rely on them. Checks keep running because stopping them is nobody's decision. Tools get bought on what they add, with no account of what they let you stop doing.