Clean Coding Principles in the AI Era

Introduction

When you look at social media or follow the news from technology companies, the entire software development field nowadays revolves around generating code with AI. Every few days, a new Vibe coding system is launched by all kind of startups, claiming to be better than all the others. Terms like agentic coding and MCP (Model Context Protocol) are everywhere.

Productivity in Software Development

All these tools claim to drastically increase a software developer's productivity or even make them completely redundant. On the other hand, studies are emerging that question the productivity gains of such tools. However, the scientific reliability of these studies can also be questioned.

But what exactly is a developer's productivity? Can it be measured by counting the number of lines of code written per day? Or is it better measured by the often-debated velocity used in SCRUM projects? But then, you are not measuring individual speed but rather the speed of the team. And is that a problem since software development is still a team effort? Overall, it is quite challenging to quantify the added value of using AI by an individual developer.

The Relationship Between Code Generation and Code Quality

This article is not about proving the increased productivity of using AI to support developers in their roles. I believe most of us already use tools like GitHub Copilot, JetBrains AI Assistant, ChatGPT, Claude, and many others to some extent. These tools are, in my experience, particularly useful for writing boilerplate, and thus relatively dull, code. I use such tools daily.

However, all these tools also clearly indicate that the code they generate may contain errors. Some of these errors are easy to recognize simply because the code does not compile. Other errors surface because unit tests fail. Fortunately, these are the easy-to-recognize errors.

But what about structural errors? Code that does not adhere to clean code guidelines, such as the SOLID principles, contains repetitions (DRY), or includes unnecessary complexity (YAGNI). These errors are much harder to recognize but significantly impact the maintainability, testability, and extensibility of the code in the long term. The speed at which a product can be further developed is largely determined by the extent to which the code adheres to these guidelines. I think almost all developers who have been in the field for a while know examples of software products that were barely maintainable due to poor internal structure.

Assessing Code Quality by AI

It is difficult for AI to recognize when it generates code that does not meet these guidelines. The training data used for training code generators is generally based on open-source repositories like GitHub and public sites like Stack Overflow. But what about the quality of the code in those places, and does all this code adhere to clean guidelines? My personal repositories certainly do not, as they are mainly intended to explain topics, and additions for production support and clean code approaches can distract from the message I want to convey. And if that applies to my repositories, how many other repositories does that apply to? On Stack Overflow, you can vote on an answer, but is this score included in the training, and what does that vote say about the quality of the code? Does the score indicate the applicability of the answer or the quality of the code, or even both? In other words, the quality of the code was certainly not objectively included as a parameter in the training of the models. An additional problem with generation is the size of the context window. How can AI recognize that it is generating duplicate code if the entire code of a solution is not included in the context? But for the quality of the answer, you generally want to keep that context limited. So, these two goals are in conflict with each other.

Assessing Code Quality by the Software Developer

We should not expect much from AI in critically assessing adherence to clean principles at this time. Therefore, we as developers must keep an eye on this and be critical of the proposed code. And there are a few points to consider here.

Firstly, the risk of complacency. It is very tempting to accept an answer that seems correct immediately. Because then you can at least move on to the next challenge. This behavior is further reinforced if a management style focused on mere productivity is used. I saw this happen in the past, especially with junior developers who found an answer to a problem on, for example, Stack Overflow. The answer was copied directly into the solution without trying to understand the internal workings of the solution, and an evaluation of the clean principles was certainly not applied. But the same effect is also seen in many pull requests. I see a lot of feedback that does not go beyond commenting on the naming of methods and variables. Of course, good naming also contributes to clean code, but clean code goes beyond that. As developers, we need to pay much more attention to critical thinking skills and dare to question more things, not to criticize our colleagues but to learn from each other and ensure that the codebase remains in order. And this may also require more of our soft skills to convey this message effectively.

These critical thinking skills in clean coding are immediately the second risk. How do developers learn clean coding? Sometimes it is addressed in school. But in my experience, the teaching does not go much further than explaining the principles. Providing real feedback on the code written by students, for example, during projects, is generally not done. Often simply because the teachers either do not have the practical knowledge of applying clean code or simply do not have the time to look at the code from all the students in detail. Given helpful feedback does take a lot of time. And if that feedback is given and code quality is not part of the project's assessment criteria, it is often feedback that the student does nothing with. And that is not disinterest, but let us be honest, as a student, you focus most of your energy on the things you get study points for. So, it is more the fault of the education system in this area at the moment.

Learning Clean Coding Principles

Learning clean coding principles must therefore mainly take place in the workplace. And there, of course, we also have the necessary challenges. Many developers currently active in the workplace do not have a formal IT education. Basic knowledge of clean coding is therefore not always present. Fortunately, some developers have taken the time for learning the principles themselves and applying clean coding principles by giving each other critical feedback on the code written. This existing knowledge can then be passed on to the juniors who come to work in the company by providing feedback on the code those juniors write. So, a kind of master-apprentice construction, as was also used in the past to learn trades. But now two additional challenges arise. Juniors rely heavily on code generation by AI and write less code themselves. If they receive feedback on the code, there is a risk that they see it as feedback on the AI and do not use it as a learning point for themselves because it does not really feel like their code. Internal attribution is therefore a point of concern here. Another significant risk I see is that with the latest corporate developments, fewer juniors are hired because management sees AI as a good replacement for junior developers. Senior developers simply have much less chance now to pass on their knowledge. But these seniors generally move on to other positions in the company or retire at some point. And the gap they leave behind must be filled with new developers. This gap cannot be filled with juniors who have received feedback on the code they have written and thus have become more senior but can only be filled with real juniors who rely entirely on the AI they use. A significant risk, therefore, if you, as a company, decide not to hire and train juniors now.

Conclusion

But what conclusion can we draw from this? That our profession is dying out? I sincerely hope not. I would advocate paying more attention to teaching critical thinking skills about the quality of the (generated) code, including clean coding. And of course, we can point to the educational system, but I think we as a profession should also take responsibility. So, let us take action together! Share your experiences and insights on clean coding principles on LinkedIn and other social media platforms (i.e. TikTok). Engage with junior developers or students and offer your guidance and feedback. By fostering a community of continuous learning and improvement, we can ensure that the next generation of developers is well-equipped to maintain high standards of code quality in the AI era. So that after many years to come from now we can retire as software engineers with the confidence that the systems we rely on as a society in the broadest sense will still function in the future.