Gareth Bowen

The Theory Building View of programming as proposed by Peter Naur in 1985 has aged exceptionally well, and still explains issues with maintaining software that I've experienced during my career. However, a lot has changed in the last 40 years, for example, the original paper doesn't attempt to address any conflicts between the theory and AI assisted programming. This is an exploration of what the theory predicts for the future of coding.

If you haven't already, I recommend reading the paper, or listening to the Future of Coding podcast which was how I was introduced to the idea.

"A main claim of the Theory Building View of programming is that an essential part of any program, the theory of it, is something that could not conceivably be expressed, but is inextricably bound to human beings."

My TL;DR is that the act of programming is to build a theory of the software and how it relates to the real world problems it aims to solve. This theory is the primary output of the activity, and more important than the code itself or any documentation. It is impossible to adequately document the theory and the only way to build the theory is by programming, ideally with another programmer who has already built the theory for themselves. If no programmers with the theory of the software remain, then the product is effectively dead, and if significant changes are required it will be cheaper to rewrite the software entirely.

"On the Theory Building View of programming the theory built by the programmers has primacy over such other products as program texts, user documentation, and additional documentation such as specifications."

Most programmers use AI assistants for what is essentially an advanced autocomplete tool. For example, when given a function definition it will propose an implementation which is then reviewed by the programmer before committing it. Using AI this way means the programmer misses out on understanding the minutia of the implementation, but so long as it's used only for low level functionality it's not likely to contribute to the overall theory. In fact this likely means the programmer can spend more time on higher level considerations, deepening their understanding of the theory. This is similar to invoking a third party library for specific functionality, in that the programmer is intentionally choosing to delegate the details and focus on the theory at a higher level.

"The building of the program is the same as the building of the theory of it by and in the team of programmers."

A more advanced use case is to use AI to write the tests for the human written code. Again, if this is used for low level unit tests then this likely won't impact on theory building, but high level testing is essential for challenging the programmers assumptions about the software and therefore the theory. One of the key features of Test Driven Development is that the testing forces the programmer to think about the real world requirements first - AI generated testing is the antithesis of TDD, because it reduces the amount of time the programmer must spend considering the requirements.

"What characterizes intellectual activity, over and beyond activity that is merely intelligent, is the person's building and having a theory, where theory is understood as the knowledge a person must have in order not only to do certain things intelligently but also to explain them, to answer queries about them, to argue about them, and so forth."

AI assistants are also used to review changes, either as a synchronous pair, or an asynchronous PR reviewer. This approach is much more consistent with theory building as the human is driving the change, and their understanding of the theory is being challenged by the assistant. Here you get many of the benefits of Pair Programming without the downsides of co-location, inflexible schedules, and cost.

However Naur posits that the only way for new programmers to build the theory of the program is to be actively engaged in developing it, ideally with other programmers who already have a working theory. If the team relies on AI for pairing or reviewing then this opportunity for theory building is lost, and any new programmers will struggle to build the model leading to poor quality contributions. If you accept that working together is essential as a theory building tool, then it cannot be replaced by AI. Instead, use assistants to complement existing processes, for example, as an additional code reviewer.

"For a new programmer to come to possess an existing theory of a program it is insufficient that he or she has the opportunity to become familiar with the program text and other documentation. What is required is that the new programmer has the opportunity to work in close contact with the programmers who already possess the theory..."

When taken to the ultimate extreme, the entire software development process, including theory building, can be outsourced to AI. Much like outsourcing to human programmers outside your organisation, this can be appropriate if software sustainability is not required, for example, a throwaway proof of concept, or the software is not core business. However if the product is vital to your business then any form of outsourcing has risks. While the ownership of the code and documentation is clear, Naur proposes that the theory is the primary output, and without any way to communicate the theory you cannot take ownership of it.

"The conclusion seems inescapable that at least with certain kinds of large programs, the continued adaptation, modification, and correction of errors in them, is essentially dependent on a certain kind of knowledge possessed by a group of programmers who are closely and continuously connected with them."

It would be possible to retain ownership of the AI that has built a theory of the software so long as its “memory” was owned by your organisation, but beware of relying on a third party who could change terms of service, price, or implementation without recourse. If access to the theory is lost, then the product is effectively dead.

"The death of a program happens when the programmer team possessing its theory is dissolved."

"A very important consequence of the Theory Building View is that program revival, that is reestablishing the theory of a program merely from the documentation, is strictly impossible."

Naur's theory of Programming as Theory Building shows there are no shortcuts to building a team with a theory of the software and how it relates to the real world. The theory is the primary output of software development, more important than the code or documentation. However it is also impossible to adequately communicate the theory, so it needs to be continuously built and refined by a team of programmers working together. If the team is replaced either by human or artificial intelligence the theory is lost and a complete rewrite will be the cheapest option for making future modifications.

"Since this theory by its very nature is part of the mental possession of each programmer, it follows that the notion of the programmer as an easily replaceable component in the program production activity has to be abandoned."

Perhaps AI will prove Naur wrong, or become advanced enough to build the theory itself, but until then a team of full time human programmers is still required for any form of sustainable software development.