What happens when a bug appears in the code which was written, reviewed and shipped by AI? Who is taking the responsibility in such a case? Is it the developer who wrote the prompts? Or the one who approved the pull request? Or the team in general? Why these questions are necessary to be answered at all or we already know the answers?
I know that these are not very popular questions to ask and that it can look like a finger-pointing, but we need to have at least some sense of the ownership of the code which is shipped by AI. Lot of devs are seeing this as a real problem now, and this is something that needs to be addressed. Here, I am trying to investigate the reasons why this happens and to give my thoughts on how to improve it.
Quality vs Quantity
Are we actually producing better code or more code? Quantity is easy to measure, but quality is not. Tools like Cursor are providing dashboards where one of the measures is how many lines of code are generated and committed by AI agents. In my opinion, this is not a very smart measurement, especially because it can mislead some non-technical people to believe that lines of code are measure of productivity.
The whole AI movement made it seem like coding, and for some, even engineering, is an easy step of software production and that the main bottleneck is now finding new features and eventually product-market fit. I wrote in more details about a vibe coding traps and delusions in one of my older articles.
We need to keep in mind that code is not an asset but a liability. More code does not mean better features. It can mean totally opposite, more traps and more opportunities for the application to fail.
Knowing What the Code Does
We already know that the code generation alone is not the problem, the problem shifts towards understanding it and proving its right fit into existing architecture. How to ensure that when you didn’t write the single line?
It is not enough to just quickly look at the generated code, run tests and hope everything is ok. First thing, you need to understand that the code does what it is intended to do, if it fits the architecture, if it is written in the structured way, to not look like a spaghetti. Second, pay attention on the tests because generated tests are most likely just testing what the code already does, but tests need to test also what the code does not do. These are the edge cases where most bugs are coming from. Check edge cases in your logic and force the tests in that direction.
This is the place where engineering becomes even more important, because in the end, someone needs to understand the system well to be able to judge if generated code belongs there or not. Only comprehensive code review will help to verify the implementation, and challenge it to ensure it fully aligns with the requirements.
Time Pressure
The hype around AI somehow created an expectation that if code can be generated quickly, it also should be shipped quickly. As a result, this created pressure on the steps that come after code generation, especially the review and engineering judgment. We all need to understand that the time spent on some of these steps has just shifted from one side to another. Of course, if we keep in mind that we want to do things correctly.
Before, understanding what the code does and whether it fits the architecture was an ongoing process during the code creation. In the end, it was created from the same human source. The person who was writing the code was also building it and understanding its dependencies and architectural fit.
Now, when code generation is shifted towards AI, the responsibility for understanding it remains with the human. The human still has to read it, understand it and validate it.
Without these steps we are taking shortcuts towards hard- or even non-maintainable application(s) in a couple of weeks or months. Without proper assessment, we can easily become deluded into thinking that everything is fine and that AI did the things correctly, until this same things break. And, at that point, it might already be too late. I am not saying that before AI we didn’t have bugs in the code, this is not the point. But we had at least a decent level of understanding what the code was doing. Currently, I see this less and less.
(Not) Taking Shortcuts
One aspect that tends to be easily forgotten is revising the code after the implementation. What I mean by this is that somehow I see that AI makes it incredibly easy to say “just make it work” and clean it up later. That “later” usually never comes, as new requirements come in regularly. Then, within some period of time, a codebase is in such a shape that it is hard to improve without making a lot of cuts. This behavior is nothing new, we had this in the past as well, but now it is crucial since the pace is amplified.
There is a big difference between removing unnecessary work and skipping the important work that needs to be done. AI is very good at the first one, but it can also make the second one very tempting by creating a delusion that revising is not needed or that it can be done quickly.
Cost of Bad Code & Maintenance
The worst code does not usually mean the code that doesn’t work. It is the code that works today but becomes expensive tomorrow. All fairy tales about super-productivity might be ruined by one security issue, one deadlock, one race condition, one data leak. Things that seemed to be perfect can become a nightmare. At that point, it does not matter how fast your development was, when it was done wrong. And the worst thing is that you didn’t notice it in time.
Technical debt usually compounds when nobody understands the code well enough to refactor it and clean it up. Fear of breaking something increases as understanding decreases. Furthermore, as the codebase is growing, it means more surface area for future changes and potential failures. As a result, potential maintenance costs are increasing because it will require more time to debug something when an issue comes up.
All of this leads us to one conclusion. AI didn’t make things easier, it made some of them easier, but it also increased the burden on the other side. Now, we need to review more code, judge the engineering done by something else, be more cautious when approving code, etc. If we ignore these things, it will cost us eventually in the long run.
Accountability
Who is taking responsibility when something goes wrong? AI can write, review, test and even suggest architectural changes, but it doesn’t own the consequences. Someone has to be responsible for what gets merged and shipped. “AI generated it” cannot become an excuse when something goes wrong. We cannot blame AI when something happens, even if this would be easy to do. It just does not make sense, and in the end, it will not change the situation or influence anything, because AI is not a human to be held accountable in this way.
Accountability probably needs to be shared across the team, but that doesn’t mean it belongs to nobody. The first responsible person has to be the person who instructed AI to generate the code on their behalf. This means as a consequence that the same person has to fully understand what the generated code does. Secondly, the review is also important. A person who is approving a pull request cannot just go with “LGTM” and hope everything is fine. This person has to take the code review as seriously as they would have before AI agents. After all, the entire team has some sort of shared responsibility about the things they are shipping, no matter if it is AI-generated or not.
And finally, the fact that AI generated the code doesn’t change the fact that we are shipping it. And if we are shipping it, we need to understand it, review it and be held accountable for it.
All photos are from unsplash.com
Top comments (0)