The importance of clean code
Are clean code and AI a contradiction in terms? Or has clean code become even more important in times of AI tools?
The topic Clean Code has become a core topic in software development over the past few years. The principles and practices of the Clean Code Developer Initiative are widely recognized and are applied more or less intensively. Even automated tests are written. Sometimes... But in recent months, there has been a development that requires a reassessment of the topic of clean code: AI.
In the beginning, AI was a tool for us software developers that simplified our work in the IDE. The code suggestions got better and better, but basically we still wrote most of the code ourselves. The odd code snippet was generated and then, hopefully, adapted according to the rules of the art so that it not only fulfilled its purpose, but also adhered to the clean code principles and thus obeyed the values of changeability and correctness. However, the current development of „agentic AI“ is turning things upside down. Put simply, I can formulate my requirements in Claude Code and receive code that at least does what it is supposed to do. This is ensured by the tests that are also generated. Agentic AI enables the tool to interact directly with the code base and tools such as the compiler and test runner. It can also access the web to search for libraries and documentation. The AI can thus take over software development autonomously. The key to all of this is the MCP server.
AI has very quickly developed into a relevant tool that is dramatically changing the way software developers work. There is still a lot of fear and rejection. But we have also become accustomed to compilers and high-level languages very quickly. Nobody looks at the machine code generated by the compiler. The same will happen with AI: no one will look at the code when AI turns requirements into executable software. And in case of doubt, as with the compiler, everything or at least relevant parts will be regenerated after every change.
I often hear and read the criticism that AI produces such poor code that it cannot be used to create software that is adaptable in the long term. But that is exactly what I question. Of course, such a powerful tool needs an equally powerful operator. Anyone who has never developed software in their life will, at present, only achieve mediocre code quality with AI. But on the one hand, I remain convinced that this will change very quickly. On the other hand, we need to use the potential of AI and ask ourselves how we need to change the way we work. I have experienced productivity increases in the range of 5 - 10 times more output myself. We can't ignore that. So the question is, how do we integrate AI into our software development process in such a way that we get at least the same quality as we currently get with handmade software?.
From the requirements to the code
In our training courses, we teach a software development process that leads from requirements to code in 8 steps. I have worked in this post reported about it. These are the steps:
Requirements
- Decompose requirements vertically
- Design in width
- Select a request
- Refining the design in depth
- Work organization
- Implementation incl. tests
- Integration incl. tests
- Code Review
Code
The first thing I wondered was whether powerful AI tools would bring us back to waterfall instead of agility. But I quickly rejected this idea. Even if I as a developer can develop 10 times as many features per unit of time, I still need to receive feedback from the customer or product owner. We may have to rethink how many features we can include in a sprint and shorten the sprint duration further because the results are available so much faster. But there is no way around agility, even with the use of AI.
Agility = regular short-term feedback
Design in width
The second step also remains useful. Essentially, the aim here is to clarify what the user's input is and what output they expect. The following illustration shows this using the example of a CSV viewer.
This step leads to a specification of the requirements and at the same time clarifies which data a dialog must provide and which data is returned as a result.
Select a request
The selection of an individual requirement also remains important, as implementation should continue to take place in increments on which we obtain feedback. The product owner is still responsible for selecting the next relevant requirement that provides the greatest benefit for him or the customer. The focus on user needs remains a central task.
Refining the design in depth
However, refining the design in depth is now the task of the AI. As a developer, I no longer have to think through the details in advance, but can leave this to the AI. As long as I describe to the AI exactly what my requirements are, it can generate code and tests. However, it is important to make a distinction between creating a plan and implementing it. This step could therefore be when using AI:
- Planning the implementation
Here, we ask the AI to ask us questions about the requirements and the technical implementation and then generate a plan for the implementation. We review and improve this until we are satisfied with the result. This is the point where the „vibe coder“ can no longer keep up. It takes the expertise of a software developer to evaluate and adapt the implementation plan. Mind you, no code is generated here, only the plan.
Work organization
The next step, work organization, can be completely eliminated. As the AI takes over the pure programming work completely, we no longer need to divide this activity between several team members. Component orientation and contract first are no longer necessary.
Implementation incl. tests
This is followed by implementation by the AI. It probably makes sense to define the generation of tests as a separate work step for the AI. The item „Implementation incl. tests“ is therefore split into
- Generate implementation
- Generate tests
However, we need to look at the tests in particular and assess whether they actually check our requirements. Code coverage analysis is also important here to find out whether the tests generated by the AI are sufficient.
Integration incl. tests
As we have eliminated the division of labor for implementation by the team, the integration of the individually created code areas is also no longer necessary. I see the integration tests under the previous point „Generate tests“. It should be noted that this step was intended to merge the individual results of the work-sharing implementation by several developers. The integration of the result of the iteration into version control and the „rest“ of the application remains. Here too, the AI supports us by handing over control of version management to it. Commit messages and merge conflicts can be processed by it.
Code Review
A code review is still fundamental, as it ensures that the principles in the code base continue to be adhered to. However, we will also use AI for this. In a separate step, we instruct the AI to evaluate the code according to the clean code principles. The AI will therefore evaluate the code that it has previously generated and refactor it if necessary. The tests must of course remain green. At the same time, the tests should also be evaluated. Here, the AI can, for example, determine the test coverage and, if necessary, add tests to fill gaps.
This step must be accompanied by the developer. The results of the AI are often very good. However, as developers, we have to look at the changes and assess whether we want to adopt them. However, this is much quicker than without AI.
In summary, the procedure is as follows:
Requirements
- Decompose requirements vertically (Dev/Team)
- Design in width (Dev/Team)
- Select a requirement (Product Owner)
- Implementation planning (AI)
- Carrying out the implementation (AI)
- Generate tests (AI)
- Code Review (AI, Dev/Team)
Code
The individual steps are followed by the role that is primarily responsible for them.
It is noticeable that only the first three steps require human labor. The third step, selecting a requirement, falls within the remit of the product owner and will usually only require them to think for a short time. In order for the AI to produce reasonable output, it needs reasonable input. Although this is also the case in a software development process without AI, it is not really addressed in many projects. Developers are often confronted with incomplete requirements and then make something up as they go along. Those days are now over. However, as developers, we are not left on our own; the AI will ask us or the product owner questions and make suggestions to bring clarity to the requirements. This alone can mean a gain in productivity, as less reworking is required following feedback if we ensure clarity from the outset.
Conclusion
This is the current state of my thoughts. I have used this process for myself in small examples and larger applications. It works. However, I do not rule out the possibility that new findings will result in changes to this procedure. The original 8 steps were also developed over a longer period of time.
We are currently revising our training content and will be integrating AI step by step. Does this mean that clean code is obsolete? No, not at all. It remains extremely important to understand and apply the principles and practices of the Clean Code Developer Initiative. However, our approach to the daily development process is changing significantly. As an academy, we want to continue to impart this additionally required know-how and thus take current developments into account.
I am happy about every comment!
English 
German