Does code need to be maintainable anymore?
The good news is the short answer is yes. But it is hard to understand that unless we go through the long answer. So let’s discuss.
First of all, AI is great. It helps you code way faster, deliver a lot, and move through prototypes and concepts way faster. It started where it could only build prototypes, but it is clearly at a state where it can build full-fledged software. If your design is solid, the AI is a fast implementation layer - it can implement all of it at breakneck speed and even course-correct as and when it finds failures or fixes it needs. And with time, the judgment layer of AI is improving further, so even if you make small mistakes, as long as your overall design is solid, AI can fix them when you ask it to.
So great - then why do we even need code reviews anymore? Why are they necessary? You would ask, because I can just ask the AI to make another fix later on, right? That hunch is in the right direction, but there is more to it. Companies are trying the concept of dark factories, where software builds itself and fixes itself and keeps growing and adding features. But there is a point where it becomes hard to manage, because every further AI edit may solve a problem and may also create more problems.
The physical limit is the context window. If AI has reached the point where it cannot really understand the whole system - because things are not designed well enough to give it the whole context - then there is a hard limit to how much it can help with: how much context fits in the window. We are working with one-million-token context windows right now, and maybe sometime in the future we will have more. But there will still be a limit. If your codebase is gigantic and unstructured, the AI has to understand all parts of it to make sense of what is going on - and to make sure it is not introducing an edge case while fixing the problem at hand.
So design is still important, and maintainability is still important. Good design and good software patterns architect the system into layers that are easy to maintain and give developers a shared vocabulary. Historically that mattered so a team of people could work on the same software. Now it matters for a new reason too: to make sure the physical limits of AI are not reached. Structure the software well, and the AI only needs a particular set of files in context to solve a particular problem - not the entire codebase. The less context it needs, the better it works.
And there is a second reason. Unless the code is maintainable, you can only use AI to verify AI’s work. There is no human who really knows what is going on under the hood, and it becomes hard to keep the software alive over the long term.
You can absolutely get to a certain point without any of this. A few years ago that point was an MVP. Some months ago it was a great product. Even now you can get a lot done by vibe coding. But as you add more and more features - to build a real SaaS that actually helps people - you will eventually hit a blocker. Over time, the percentage of cases where the AI fixes something but also introduces another bug will keep increasing. That is when you will want to restructure, to make the code maintainable, so that AI only needs to understand a part of your system to solve that part - and does not need the whole codebase in its context.
So yes. Code still needs to be maintainable, and it will always need to be maintainable - because at least so far, from what I see, code needs humans to maintain it, and for that it needs to be maintainable.
This connects to two threads I want to pull later: review as the bottleneck - the verification step does not disappear just because fixes got cheap - and whether humans in the loop are a bug or a feature. More on both soon.