Programming as Theory Building: Why Senior Developers Have Become More Valuable Than Ever

In 1985, the scientist Peter Naur seemed to see into the future when he wrote his work titled "Programming as Theory Building," which has become highly relevant today. We increasingly see beginning developers mindlessly accepting AI-generated code they don't truly understand, while codebases expand with implementations lacking theoretical foundations. In light of all this, Naur's core idea stands out clearly: "a program is not its source code."

The Theory of Code

Naur argues that at its foundation, programming is the construction of a theory — a comprehensive mental model of how a system works, why it works that way, and how it should evolve. The source code is merely a written representation of that theory, and like any other representation, it cannot convey the theory fully. The most critical information about the intent, design, compromises, and reasoning behind particular architectural decisions exists only in the minds of the system's creators.

When those people leave, all that theory is lost. The code remains, but the program — the living, breathing system with all its premises and context — vanishes.

The Crisis of Lost Theoretical Foundation

The modern development world is approaching a serious catastrophe, caused by the creation of code devoid of theoretical foundations. Specifically, this manifests in several ways:

Mindless use of AI, which has already become the norm. Developers instinctively turn to LLM-generated solutions without any cognitive effort, which is impossible to achieve proper understanding without. This "mindless AI use" robs us of growth opportunities — those situations where you hit a dead end, stepped back to look at things differently, wrestled with the problem, and finally reached that coveted "Aha!" moment, becoming a more experienced engineer.

Generation of context-free code. This is even more troubling. Programs generated by models are not just lacking a fundamental theory — they are depersonalized. Such code is built on statistical patterns without understanding the problem domain, the conceptual model of the system, or the subtle compromises that experts embedded in its architecture. This code may pass tests, but it exists in a theoretical and subject-matter vacuum. Unable to find the author via git blame, we are severely constrained in our ability to understand "how" a particular piece of code works, and most importantly "why" it was written.

Integration problems. When developers accept AI-generated code without deep understanding, they're not just copying syntax — they're importing someone else's architectural decisions into their system. At best, such code will: 1) work and 2) not do anything dangerous. The embedded decisions may contradict the domain model, violate established patterns, or introduce barely perceptible inconsistencies that only surface when the system is under load.

And the result? We end up with codebases that seem to work at first but become increasingly incoherent as they grow. Systems where code no longer reflects the language of the domain. Technical debt that only accumulates because nobody understands the theoretical foundations that once gave the system its integrity.

This crisis is far from new, of course. I remember that unfortunate intern at my previous company who logged into production and ran rm -rf / because StackOverflow told him it would fix his symlink problems.

But now we're seeing all of this at a completely different scale! Roughly every five years, the number of developers doubles. That means at any given moment, half of all engineers have less than five years of experience. (If you add the adventurous vibe coders on top of that, the numbers become far more frightening.) Now arm those inexperienced programmers with AI tools that instantly generate entire functions, and you get a catastrophe: an unprecedented number of juniors wielding the most powerful copy-paste tools with minimal understanding of the process.

That intern at least had to find, read, and manually type his destructive command. Today's developers get AI-generated functions at the press of a key, importing critical decisions they don't review (not to mention outright dangerous code).

Why Experienced Developers Have Become More Valuable Than Ever

All of this brings us to the reasoning about why seasoned engineers have become critically important for the industry. These people:

Develop domain theory. Senior developers don't just write code — they build and maintain the theoretical framework that connects business domains to software architecture. They understand not only what the code does but why it exists, how it models the business domain, and how it should evolve as understanding deepens. These are the people who ensure that code speaks the language of domain experts.

Enforce the theory embedded in architecture. When a junior or an LLM produces code, the senior developer acts as a bridge between its raw implementation and the system's agreed-upon design. They can evaluate whether the written code aligns with the architecture's theoretical foundations — not just technically, but conceptually. These people understand the difference between code that works and code that fits the overall structure.

Use AI consciously. Senior developers use AI consciously rather than reflexively. They understand everything they ultimately integrate, question the models' suggestions, and ensure that generated code maintains the system's theoretical coherence rather than undermining it. If they use AI, it's typically for boilerplate tasks, reserving human judgment for the parts that require sound human reasoning. (If you're stuck in a situation where you need to write, say, twenty-plus factory methods that all do the same thing but for different services or properties, that can be delegated to Claude Code or another model with a clear conscience.)

Teach theory and craft. Perhaps the most important role of senior developers is passing on theoretical knowledge and skills to others. They teach junior specialists not just syntax or patterns, but the deep understanding that transforms disparate code into coherent programs. These people teach the art of problem-solving, explain the value of cognitive effort, and instill the discipline of always preceding implementation with thoughtful analysis and understanding.

The Human Element Is Irreplaceable

In his work, Naur also reminds us that programming by its nature belongs to human intellectual activity. Its real product is not code but the theory, understanding, and mental model that give a system its coherence. Yes, LLMs can generate syntactically correct code, but they cannot create theories. They cannot understand business context, grasp the necessary compromises, or maintain the conceptual integrity that separates quality software from merely working code.

While good documentation, recording architectural decisions, and clean, readable code are always welcome, all of these are merely words that cannot fully reflect what our programs are, what they do, and what meaning they carry.

The teams that will be most successful are those that recognize this fundamental difference. LLMs can be useful for specifically mechanistic tasks (generating boilerplate code, writing simple tests, creating those twenty-plus nearly identical factory methods). But the very essence of programming — developing the theory that transforms business requirements into coherent software models — must remain strictly in human hands.

Preserving Theory

Organizations that value the quality of their software must invest effort in preserving the theoretical foundation:

• Create documentation that reflects the meaning of the software, not just its implementation.
• Introduce knowledge-sharing practices where people share mental models, not just familiarize themselves with bare processes.
• Use code reviews to evaluate not just program correctness but also its alignment with theoretical foundations.
• Develop mentorship programs to cultivate theory-building skills in newcomers.

The Art of Theory Building

Peter Naur understood back in 1985 what we are rediscovering today. Programming is about human-made constructs whose development requires deep understanding. As we enter the era of unchecked code generation, developers who can build, preserve, and transmit the theories that give code its meaningful and coherent form become increasingly valuable.

This isn't about rejecting AI or defending some outdated practices. It's about preserving the crucial aspects of development that are uniquely human: domain understanding, architectural coherence, and the nuances of building systems that don't just work but also make sense. It's about preserving the ability to effectively wrestle with problems, to understand them before implementing them, and to ensure that code reflects the rich mental models that make software systems truly maintainable.

The question isn't whether LLMs can write code — they obviously can. The question is whether we can preserve the human-created theoretical structures that turn that code into coherent, domain-oriented, long-lasting programs.

In an era of striving toward mindless AI use, senior developers who apply AI consciously (if at all) while maintaining all necessary programming principles become the guardians of quality software. They are the only ones who ensure that our systems remain understandable to humans, aligned with their domains, and built on a solid theoretical foundation.

When the dust raised by the frantic chase for "free code" settles, the demand for senior developers will rise again.