There is one thing that is certain: If there is code, that code is prone to break.
In today’s AI age, where programmers can generate hundreds of lines of code within minutes, we must remember that more code isn’t always the best solution. As a project’s codebase grows, system complexity increases—and with each line added, there’s a hidden maintenance cost lurking in the background. You might not feel it now or tomorrow, but eventually, you’ll look at the system and ask yourself, “Why?” Why does this simple dialog box need 2,000 lines of code? Why does a basic file upload button require so many engineering hours just for programmers to understand what it does?
Although this has been a problem for years, only in recent years has the idea of “code explosion” truly taken off.
Code Explosion
A study by IT Revolution reveals that ever since AI came onto the scene, developer “productivity” has increased—if productivity is measured by the number of lines of code added to a project.
Junior developers have improved their code output by 21% to 40%, while senior developers show a more modest 7% to 16% increase.
I cannot argue against the fact that AI assistants help programmers iterate more quickly—that is an undeniable fact. What I do believe, though, is that after generating a working iteration, programmers often lack the motivation to refactor, clean up, or even fully understand and simplify the code. This can lead to an “AI-driven development” style, especially with tools like Cursor’s agent/composer, which practically drive the development process.
Since AI tools generate code so quickly and often produce overly verbose implementations, the end result tends to be difficult to read and maintain. It becomes a tangled mess—understandable in isolation but convoluted when considering the bigger picture. This is much like how AI-generated text can be technically correct yet say little of real substance.
A Cry for Minimalism
Although AI assistants speed up development, I firmly believe that one should not entrust a codebase’s architectural decisions to an AI model.
Programming is not just about creating something that works—it’s about creating something that is maintainable and understandable. A 700-line file, mostly generated by AI, is rarely easy to read.
When programmers make decisions themselves, their natural inclination toward efficiency (a good thing in this context) often leads them to more minimal and elegant solutions. These solutions are typically easier for fellow programmers to read and understand, taking a fraction of the time compared to deciphering an AI-generated behemoth.
Not Everything Needs to Be Code (or at Least Our Code)
As programmers, we are often tempted to solve a problem by writing custom code. Whether it’s a complex calculation or an innovative workflow that connects GitHub to Slack in a way not natively supported, we instinctively reach for code.
While these projects can be fun, in a corporate setting, they might not be ideal. The moment we add code, we own it. We need to maintain it. Others may depend on it. Requirements change. Bugs emerge. The overhead increases.
An alternative is to seek minimal-code or no-code solutions. Instead of creating a CLI tool for some calculation, use Excel. You can still inject data via code but avoid handling complex calculations within your codebase. Instead of developing a custom workflow with webhooks, use a tool like Make.com to generate the workflow and call it from your app.
You will always need code—but it’s better when you are not the one who has to maintain all of it.
Conclusion
Minimalism is not about avoiding code; it’s about making smart decisions about when and how to use it. AI tools can be powerful assistants, but they should not dictate our software’s architecture. The best systems are those that balance automation with human insight, complexity with simplicity, and speed with maintainability. Before writing a single line of code, consider whether there is a simpler way. And if you must code, write only what is necessary—because every additional line is another potential point of failure.