AI Doesn’t Create Bugs, but It’s Amplifying the Problem.

At this point, it is practically impossible to talk about software development without talking about AI. The two have become so closely intertwined that it now feels unusual not to have AI integrated into our IDE and working alongside us in our daily activities in one way or another.

This article starts from an important premise. AI brings us tremendous benefits and has become an indispensable tool, not only for software developers but also for other technical roles, including QA professionals like myself.

By now, there are countless articles discussing the advantages of using AI. However, I find it much harder to come across content that addresses some of the issues that are increasingly emerging due to a “less-than-conscious” use of this technology.

Apparent Productivity vs. Real Quality

AI has multiplied our ability to generate code and deliver features at a speed that would have seemed impossible just a few years ago. In most cases, that is undeniably a positive development.

The problem arises when we start measuring productivity based on the number of closed tickets, commits, automated tests, or even AI prompts executed without considering the quality of the output.

Speed has increased, but that does not necessarily mean quality has improved as well, or even remained at the same level.

Sometimes we rush, even when nobody is explicitly asking us to. If Real Betis could wait six months for Isco Alarcón to recover from injury, surely a software feature can be delivered two days later.

Just as a football player can relapse if they return before fully recovering, code that is delivered prematurely will likely require rework if it has not received the necessary attention throughout all development phases.

In fact, many projects are beginning to experience something concerning. More issues are being detected in later stages, regressions are increasing, and maintenance is becoming more complex, even though it appears that teams are "moving faster."

The Problem and Its Possible Causes

Although this article reflects my personal opinion, naturally shaped by my own experiences, I must admit that my motivation for writing it comes from conversations with several colleagues in the industry.

After speaking with them, we all identified a common issue that, to a greater or lesser extent, was affecting our projects:

The number of bugs has increased significantly since AI entered our lives.

I do not want anyone to misunderstand me. This is by no means a criticism of AI. We are simply capable of producing much more code in much less time, and not only the positive aspects get amplified.

That is why, as I mentioned earlier, I want to make one thing clear:

The problem is not AI. The problem is how we are using it in some cases.

Requirements Definition

Requirements are the foundation of every software project. They were important before, and they are even more important now.

Having well-defined requirements has always been necessary, although it is something that still does not happen as often as we would like. This is not a new problem. Naturally, neither humans nor AI can perform miracles and deliver software without a clear understanding of what is actually needed.

AI has one major characteristic: it dramatically amplifies the quality of the information it receives. When requirements are clear and well defined, AI can become an incredible asset:

• It accelerates development.
• It generates useful and maintainable structures.
• It proposes valid solutions.
• It significantly reduces repetitive work.

However, when requirements are ambiguous, incomplete, or constantly changing, the effect can be the exact opposite.

That opposite effect is becoming increasingly noticeable. Generally speaking, we have not improved the quality of our requirements, yet we are delivering a greater volume of AI-generated code. The result is predictable: a considerable increase in the number of bugs over recent months and years.

The Deprofessionalization of Software Quality

More and more frequently, test automation is being delegated to people whose primary expertise is not quality engineering. This often happens under the assumption that "anyone can automate tests."

Personally, I believe there is an important confusion here between knowing how to use a tool such as Cypress or Playwright and truly understanding how to ensure software quality.

Automation is not simply about generating and executing automated tests. The truly difficult part lies in making decisions such as:

• What is actually worth testing.
• What risks exist.
• What impact each change may have.
• Which scenarios are critical.

This is where the expertise of quality specialists remains essential.

AI can help tremendously when generating tests or even entire test suites much faster than a human could. However, that does not guarantee that those tests are useful, meaningful, or strategically valuable. Just like application code, tests must be analyzed and understood.

In fact, a new risk is already emerging. Many teams are developing a false sense of coverage and security. They see plenty of tests, extensive automation, and green pipelines, but in reality there is little meaningful validation of critical business behavior.

Ultimately, this leads back to the same issue that should already sound familiar:

Bugs are increasing because many automated tests are failing to fulfill their purpose when validating new developments and preventing regressions.

Conscious Development

Earlier, I said that requirements are the foundation of every software project, but I must admit that is not entirely true.

For me, people are and always will be the true foundation.

One of the biggest risks we are starting to see is how some people’s relationship with the code they produce is changing.

A conscious developer (fortunately, most are) is not simply someone who manages to make a feature "work." It is someone who takes the time to understand the requirement, challenge it when necessary, analyze impacts, think about alternative scenarios, and care deeply about the final quality of the software being delivered.

AI dramatically accelerates code generation, but developers remain responsible for the code produced. That means it is equally important that they analyze it, understand it, and test it before delivery.

Unfortunately, we are increasingly seeing situations where AI-generated code is delivered without being properly analyzed, understood, or tested, and even cases where an AI-generated pull request is approved without sufficient review.

In the long term, this can create several problems:

• Poorly maintainable code.
• Developers who become technically stagnant.
• Developers who no longer fully understand their own applications, either functionally or technically.

My experience tells me that developers who were engaged before AI remain engaged today, while those who were not engaged before simply have their shortcomings exposed more clearly because they are now producing significantly more code.

AI can help us become dramatically more productive, but it should never replace something fundamental: technical responsibility for what we deliver.

What Can We Do?

AI is here to stay, and who knows how far it will go. It would be absurd to reject all the value it brings.

The goal should not be to use it less, but to use it better. Generating code has never been easier, and we should embrace that opportunity.

Regardless of our role, I believe many of the solutions are common to everyone, and they all share one thing: the passion and professionalism with which we approach our work.

We must continue insisting on high-quality requirements, and if they are not provided, we should help define them, because no one understands an application better than the people who build it.

We must also continue emphasizing the importance of assigning each task to the appropriate specialist, while clearly explaining the real consequences of failing to do so.

Finally and perhaps most importantly we must maintain genuine involvement and enthusiasm throughout every phase of the product lifecycle, without forgetting that AI should be a support tool, not a replacement for our commitment and engagement.

“The real problem is not whether machines think, but whether men do.” — B. F. Skinner.