Amruth Puppala | Senior Engineering Manager | Walmart.
For years, many software teams have treated 80% test coverage as a reasonable standard. It was never perfect, but it represented a practical compromise. Developers tested important workflows, covered known failures and relied on experienced engineers to identify what remained.
That model worked because people were still the primary authors of production code. An experienced engineer brings more than technical knowledge to a pull request. They remember past outages, undocumented service behavior and configuration changes that once triggered incidents. Much of this knowledge exists only as organizational memory and engineering instinct.
AI coding assistants do not carry that history. They can produce clean and convincing code in seconds. However, they may not know that a dependency has an undocumented rate limit or that an architectural decision was made after a production failure years ago.
As AI-generated code enters enterprise systems faster, the informal safety net provided by human experience becomes less dependable. It must be replaced with something measurable: stronger and more comprehensive testing.
The risk is plausible code.
The most dangerous AI-generated code is not obviously broken. It may handle expected input correctly but fail when the input is empty, unusually large or malformed. It may call another service using an outdated assumption. It may catch an exception without recovering from it. It may retry a request without exponential backoff, creating more load during an outage.
AI tools are often strongest at implementing clearly described, happy-path behavior. Their weaknesses appear around ambiguity, hidden dependencies, unusual boundaries and failures. This does not mean organizations should stop using AI coding tools. It means testing practices must evolve alongside them.
Coverage must mean more than counting lines.
A team can achieve 100% line coverage and still release unreliable software. A test might execute every line without checking whether the outcome is correct.
The goal should not be a perfect dashboard number, but confidence across the technology stack, beginning with unit tests that cover decisions, boundaries, exception paths and null conditions.
Integration tests should answer a simple question: do the pieces of the system actually work together as expected? That means checking how components exchange data, while contract tests make sure services still agree on schemas, status codes and other assumptions. Functional tests take a step back and ask whether the software does what the business actually needs, not simply what the AI assistant was asked to build.
From there, testing should account for what happens outside the code itself. System tests can expose problems caused by configuration or infrastructure differences, while security testing uncovers unsafe input handling, authentication mistakes and vulnerable dependencies. Resilience testing pushes the software beyond the happy path to see how it behaves when a service times out, a request needs to be retried or a dependency becomes unavailable. And chaos experiments take that one step further by deliberately introducing failures to see whether the system can recover when multiple things go wrong at once.
There are also ways to test whether the tests themselves are doing their job. Mutation testing, for example, makes small changes to the code and checks whether the test suite catches them. If you can remove an important statement or change a comparison without triggering a test failure, you may have a suite that looks comprehensive on paper but provides less protection than it appears to.
Fuzz testing offers another useful reality check. Rather than relying on people to think of every strange input, it bombards the software with malformed, unexpected and unusual data. That can be particularly revealing for APIs, parsers, file-processing systems and anything that handles user-controlled input.
These disciplines create a better definition of coverage: not simply whether code was executed, but whether realistic classes of failure were challenged.
AI changes the economics of testing.
Historically, comprehensive testing was expensive, but the same tools that generate production code can now propose test cases, identify branches, create mock data and enumerate boundary conditions. They can help refactor tightly coupled legacy code, introduce testable interfaces and generate an initial test harness.
AI can write a test that confirms the wrong expectation just as easily as it can implement the wrong requirement, but engineers are no longer starting every test from a blank file.
The productivity benefit of AI should not be used only to generate more features. Some of it should be reinvested in validation. Otherwise, organizations may produce code faster while accumulating risk even faster.
Adoption must be incremental.
Most teams cannot implement every discipline immediately, so adoption should happen in stages.
First, include strong unit and branch coverage, integration tests for external dependencies and static security scanning on every code change. Then, add contract tests—functional tests tied to business requirements and dependency vulnerability scanning. More mature teams can introduce production-like environments, deliberate fault injection and mutation testing to measure whether their tests are truly effective.
Finally, high-risk and AI-intensive systems should incorporate fuzz testing and controlled chaos experiments. These techniques are important for distributed platforms, financial applications, healthcare systems and fulfillment networks. Ensure that every reachable and meaningful behavior has an appropriate validation mechanism.
Quality engineering is becoming more strategic.
AI will not eliminate quality engineers. As test creation becomes more automated, their role will shift toward designing the overall quality strategy.
This means they must decide which risks require contract testing, where fuzzing provides value, which mutations must be detected and which failure scenarios deserve chaos experiments. They must also ensure that AI-generated tests are grounded in business requirements rather than copied from the implementation they are supposed to challenge.
All of this requires architecture knowledge, operational understanding and strong business judgment. It is a move from test execution to quality leadership.
The standard has changed.
Partial test coverage was once a rational response to limited time, high development costs and the difficulty of anticipating every failure. Those constraints have not disappeared, but they’re becoming less persuasive. While AI can help write code, generate tests, expose edge conditions and improve legacy testability, AI-generated code introduces risks that traditional testing practices were not designed to handle at today’s scale.
Don’t measure success by how quickly AI produces code, but by how confidently that code can be changed, deployed and operated. Succeeding with AI-assisted development doesn’t mean generating software faster, but building quality systems capable of moving at the same speed.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?