This article is going to be a bit controversial. So let me start by saying that I have nothing against AI. I think it is an amazing tool with plenty of use cases where it is useful and helpful, but like many tools before it, it is simply a tool. It is up to us, as professionals, regardless of the field, to decide when to use it and how to use it. Making this decision should be a conscious action based on knowledge and experience.
With that said, I must add that we are taking the wrong approach. Let’s see a few scenarios:
Scenario 1
An engineer is reviewing a pull request created by another engineer to fix a performance problem. While reviewing it, one of the changes looks ‘weird’. At this point, the reviewer decides to ask the author what the logic behind the change is. The reviewer wants to know why they think the change will offer better performance and solve the problem. Surprisingly, the author responds with ‘I don’t know, the AI suggested that’.
Scenario 2
An engineer is digging into a project and finds some code belonging to a not-very-popular framework. While the engineer is not very experienced with this particular framework, they know that their teammates have been battling with it for some time now. They turn around and ask the rest of the team for help. Most of them look at the code and come back with ‘ I have no idea’, but one of them provides what looks like a very solid answer. As a follow-up, and trying to learn a bit more, the initial engineer asks some further questions and wonders whether references to documentation can be provided. At some point in that conversation, the second engineer ends up admitting that they have no idea either; the first response was simply what the AI told them.
Scenario 3
Two engineers have been working together for a very long time. After all this time, they know each other and they know their code styles: how each one structures code, what constructions they favour, and so on. One of them, while reviewing a PR, realises that the style in which the code is written deviates from what their colleague usually writes. Additionally, they see some constructions that they have never seen in the codebase, such as some ‘clever’ bitwise logic. After thinking hard to understand the logic, the reviewer realises that some edge cases are not covered. With that information, they go to the author and ask about it. The author replies with something similar to: ‘I have no idea; the AI wrote it, and the code looks elegant and efficient.’
Individually, these seem harmless. Collectively, they point to something more concerning.
I am sure that if you work regularly with other engineers, you will recognise some, if not all, of those scenarios. And that is the problem that I am finding lately: people applying modifications or creating new code in complex and critical codebases without having an understanding of what they are doing, just trusting AI responses without double-checking why the response was suggested, or why something was implemented in this or that way.
As I said at the beginning of the article, AI is a fantastic tool. If you want to implement scripts, one-off tools, or anything you do not care about how it was built, just about the final result, you can do in hours what used to take days. But I think we need to have more discipline when we are modifying codebases that run in production, that are complex and critical, that need troubleshooting at 3 a.m. when we are on call. Making changes without understanding does not seem like the right way to go, or to survive in the long run.
Maybe, one day, AI will be reliable and trustworthy enough to write code without human supervision, AI reviews, for example, for mission-critical projects, but until we get there, we need to keep humans in the loop. And not only to push the ‘Approved’ button to comply with SOC2 requirements, but making the effort to understand what we submit for review and what we review.
It seems that the pressure to be more productive, and especially the FOMO (fear of missing out) is pushing us to be less effective, less disciplined, less knowledgeable. How long will it take for a project to turn into a beast that can only be modified by using AI because no one knows anymore what is under the hood? How long will it take to troubleshoot it when the AI cannot do it, which is not uncommon nowadays?
Let me be clear: the problem is not AI; it is engineers outsourcing understanding. It is engineers pushing changes without understanding what they are pushing. This is why a ‘zero-knowledge era’ is emerging, an environment where code is written, modified, and deployed without anyone fully understanding it, and where systems continue to function until they suddenly don’t, unless we stop it.
What do you think?
Top comments (0)