Programming as Theory Building: Implications for AI
An analysis of Peter Naur's 1985 paper arguing that programming is theory building rather than code generation. This executive brief explores the limitations of LLMs in maintaining software theory, the inadequacy of documentation for knowledge transfer, and strategic implications for team stability and legacy system management.
Theoretical Foundations of Software Maintenance
Peter Naur's 1985 paper, "Programming is Theory Building," posits that programming is not the mechanical generation of code but the development of a theory about how a system interacts with reality. This distinction is critical for modern software strategy, particularly in the era of Large Language Models (LLMs). The core argument is that the value of software lies in the team's collective understanding of the system's design and purpose, a theory that is inherently tacit and not fully codifiable in documentation.
Limitations of AI in Software Development
The rise of AI-driven code generation challenges traditional development models. While LLMs can produce syntactically correct code, they lack the capacity to build or maintain the underlying theory of the system. Without this theoretical framework, AI-generated code may function in isolation but fails to integrate coherently with the broader system architecture. This leads to "vibe coding" scenarios where software appears functional but lacks the structural integrity required for long-term maintenance. The absence of a truth model in LLMs means they cannot validate changes against the system's intended purpose, resulting in technical debt that is difficult to identify and resolve.
Strategic Implications for Knowledge Transfer
The paper highlights a fundamental flaw in relying on documentation for knowledge transfer. Documentation is a reduced representation of the team's knowledge and cannot capture the nuances of design decisions or the rationale behind specific implementations. When teams disband, the software effectively "dies" because the theory is lost. New teams attempting to maintain the system without this theoretical context often introduce changes that degrade the system's structure. This underscores the importance of team stability and active collaboration methods, such as pair programming, for effective knowledge transfer.
Actionable Frameworks for Leadership
Leaders must recognize that software is not a static asset but a dynamic theory held by a team. Strategies should focus on preserving team cohesion and facilitating active knowledge sharing rather than merely producing comprehensive documentation. For legacy systems, the cost of modification is lower than rebuilding, but only if the modifying team possesses the necessary theoretical understanding. Organizations should invest in collaborative practices that allow new members to internalize the system's logic through direct engagement with the code and existing team members. This approach ensures that the software remains maintainable and adaptable to changing business requirements, mitigating the risks associated with knowledge loss and AI-generated technical debt.
Key insights
-
Programming is defined as the construction of a theory about reality, not just code generation. This theory guides how the system responds to changes in the real world.
Impact: Reframes software development as an intellectual discipline, emphasizing the need for deep understanding over mechanical output.
-
Documentation is insufficient for transferring software knowledge because it cannot capture the tacit theory held by the development team. It serves only as a memory aid.
Impact: Challenges traditional handover processes, suggesting that documentation alone leads to system degradation and increased maintenance costs.
-
LLMs can generate code but cannot build or maintain the theoretical model of a system. They lack a model of truth and reality, leading to incoherent structures.
Impact: Highlights the risk of AI-driven development, where syntactically correct code may undermine long-term maintainability and architectural integrity.
-
The dissolution of a development team effectively kills the software, as the theory is lost. New teams cannot inherit the system's logic through documentation alone.
Impact: Identifies team stability as a critical business asset, with significant financial risks associated with team turnover and knowledge loss.
-
Effective knowledge transfer requires active collaboration, such as pair programming, rather than passive reading of documentation. This allows new members to internalize the system's theory.
Impact: Provides a practical framework for onboarding and handovers, reducing the time and cost associated with knowledge transfer.
Action items
-
Implement pair programming or mob programming for onboarding new team members to ensure active knowledge transfer of the system's theory.
Impact: Reduces the risk of system degradation during handovers and accelerates the time to productivity for new hires.
-
Limit the use of LLMs for unsupervised code generation. Use AI as a tool for assistance, but ensure human oversight to maintain the theoretical coherence of the system.
Impact: Prevents the accumulation of technical debt and ensures that AI-generated code aligns with the system's architectural principles.
-
Treat team stability as a strategic asset. Invest in retention strategies and cross-training to mitigate the risk of knowledge loss when team members leave.
Impact: Preserves the institutional knowledge necessary for long-term software maintenance and reduces the costs associated with re-learning the system.
-
View documentation as a memory aid rather than a primary source of knowledge. Supplement documentation with regular discussions and reviews to keep the team's theory aligned.
Impact: Ensures that the team's understanding of the system remains current and coherent, reducing the gap between documented and actual system behavior.
-
Evaluate legacy systems based on the availability of the team that holds the theory. If the team is gone, consider the cost of rebuilding versus the risk of maintaining without theoretical context.
Impact: Informs strategic decisions on legacy system management, avoiding costly maintenance of systems that have lost their theoretical foundation.
Quotes
“Programmierung ist eine Aktivität, bei der Programmierin eine Theorie über die Realität entwickeln.”
“Wenn das Team aufgelöst wird, stirbt das Programm.”
“Ein LLM Text generiert ohne Rücksicht auf die Wahrheit und dass es eben kein Modell von Wahrheit hat.”