Last week, I wrote about the hidden cost of inefficiency: the work we keep doing without stopping to ask whether the process still makes sense.

This month’s Windows updates made me think about a related question: what happens when we dramatically accelerate one part of a process, and everything downstream has to keep up?

AI is helping Microsoft discover more vulnerabilities in its software. That is a welcome development. Finding weaknesses before attackers exploit them is exactly what we want.

But it also raises a question worth asking:

As the volume of fixes increases, could the patches themselves introduce more defects, or new vulnerabilities?

More findings do not necessarily mean worse software

Microsoft has explained that AI is helping its engineers and security researchers examine code more deeply and at greater scale. Some findings involve code that had already received substantial scrutiny. AI is one contributor to the increase, alongside improved automation and broader researcher participation. (Microsoft’s explanation of larger security releases)

That distinction matters. Discovering more vulnerabilities does not establish that the software suddenly became less secure. It may mean we are getting better at seeing weaknesses that were already there.

We should also be careful with the numbers. A thousand vulnerabilities addressed does not mean a thousand separate updates for someone to install. Windows packages fixes together, and Microsoft-wide totals can include products beyond Windows.

The headline number tells us something about discovery. It tells us much less about the quality of the changes.

Fixing one problem can create another

A security patch changes software behavior. The intended result is to close a weakness while preserving everything else that needs to work.

Sometimes, something else breaks.

Microsoft’s October 13 Windows 11 release notes provide a concrete example: they include a fix for Always On VPN connection problems that occurred after a September update. (October Windows 11 release notes)

That is a functional problem. It is not, by itself, evidence of a newly introduced security vulnerability. Nor do those release notes establish that AI caused it.

Still, it illustrates why the question matters. A fix can solve its immediate problem and have consequences elsewhere.

A new security vulnerability is another possible consequence of a code change, but we need evidence before claiming that a particular patch created one.

Volume creates pressure. Quality determines the outcome.

My concern is whether discovery will outpace the capacity to review, repair, test, and safely deploy what it finds.

If more changes move through a process while its ability to catch mistakes stays the same, more defects could escape. But that outcome is not inevitable. Better testing, stronger review, and improvements to the underlying code could offset the additional volume.

Microsoft says it is using AI to propose candidate fixes and select the regression tests most likely to be affected by a change, and investing in AI-assisted validation, while keeping humans in code review. Those are relevant investments. Their effectiveness needs to be demonstrated through results. (Microsoft’s Windows vulnerability management approach)

From an audit and governance perspective, I would want to see whether:

• Updates cause more incidents or require more corrective releases.
• Testing covers the business processes and configurations that actually matter.
• Fixes address underlying weaknesses rather than repeatedly treating symptoms.
• Organizations can deploy urgent protections without overwhelming their support teams.

Counting vulnerabilities closed is useful. Understanding the risk remaining after deployment is more useful.

The answer cannot be to stop patching

Concern about update quality should lead to better deployment practices, not indefinite delay.

For organizations, that means testing representative systems, deploying in stages where appropriate, monitoring critical workflows, and preparing recovery options. Urgent exposure may require faster action; lower-risk systems may allow more observation time.

The decision needs to account for both sides: the risk of changing the system and the risk of leaving a known weakness in place.

AI-assisted discovery gives defenders an opportunity to remove vulnerabilities that might otherwise remain hidden. We should take that opportunity seriously.

We should apply the same scrutiny to the process that turns those discoveries into changes on our devices.

Finding more problems is progress. The measure of success is whether the systems we depend on become safer and remain reliable after we fix them.

---

This post is part of an ongoing series on AI governance and audit. If you’re working through these questions too, I’d like to hear from you: get in touch.