AI, Quality, and an Old Lesson Returning

You know you’ve been around a while when old patterns come back.

Skinny ties came back.Bell bottoms came back.

And I’m beginning to wonder if trying to inspect quality into a product is coming back, too.

There’s a growing debate around AI-generated software. AI can generate code remarkably quickly. That puts new pressure on everything that follows: review, testing, integration, and validation.

And the conversation often turns into:

• How do we test all this code?

• How much review do we need?

• How many people do we need checking it?

We’ve seen a version of this movie before.

When I was at GE, we implemented Six Sigma methodology in our design practices. One of the lessons was simple:

Quality shouldn’t depend on finding defects at the end. You design the process to prevent them in the first place.

Decades earlier, W. Edwards Deming argued for building quality into the product rather than depending on inspection to find problems afterward.

That feels remarkably relevant again.

Not because testing and code review are unnecessary. Quite the opposite.

Good automated testing, code review, and fast feedback are part of building quality into a modern software-development system.

But the primary question should not be only, “How do we inspect more AI-generated output?”

It should also be, “How do we design the development system so quality is created as the work is produced?”

AI may not be creating an entirely new quality problem.

It may simply be amplifying the strengths and weaknesses that were already there.