Why AI-Assisted Development Is Raising the Value of E2E Testing

For years, end-to-end and smoke tests have been at the top of the list of things that teams should be careful with. Even though end-to-end tests are good, they also add friction to the development velocity. They are often prone to errors and require a lot of maintenance. In addition, it is extremely difficult to debug if something goes wrong. This is the main reason why one should be careful with end-to-end tests, but rather rely on a higher number of tests. It is not a good idea to test all features using end-to-end tests.

However, things have changed in the field of software delivery. With AI coding tools, software engineers can now write, refactor, and extend their code much faster. While it is good that things are moving very fast in the field of software delivery, it also means that there is a higher chance that errors will go through undetected. This is when end-to-end testing becomes very important. It is not because it is becoming more important than before, but because the mistakes that teams should be able to find are changing.

The Traditional View

The classic testing pyramid is there for a reason. The bottom layer has unit tests, then integration tests, with E2E or smoke tests at the top in much smaller numbers. The key idea is that speed, isolation, and deterministic tests should provide the highest confidence, while full-system testing should validate only a small subset of critical workflows.

This model was successful because E2E tests contain real costs. They are slow, fragile, require predictable environments, and are harder to debug because failures can originate anywhere in the stack.

That is a widely held belief, which is why E2E test coverage was traditionally considered an anti-pattern. Many teams jokingly referred to it as the "ice cream cone" test pyramid: top-heavy, unbalanced, and overly expensive to support.

What AI Changes

AI-generated code has its unique risks. The problem is generally not whether the code is logically correct in isolation. AI tools are usually quite good at producing code that compiles, appears logical, and even passes the tests generated alongside it.

The greater risk occurs at the integration and behavioral level.

AI-generated code can make incorrect assumptions about API contracts, auth flows, data formats, event timing, feature flags, or state flow between modules. It may implement something close to the requirement, but not what the system or product behavior actually needs.

This confidence is dangerous because the workflow is broken: the code looks fine, and the unit tests pass, yet the workflow remains broken.

Where Unit Tests Fall Short With AI-Written Code

 AI tools are often good at writing code that:

•  passes the unit tests they generate
• looks correct in local context
• satisfies the immediate prompt

 But many real regressions appear in places unit tests will not catch well.

 For example, AI-generated code can introduce:

•  wrong assumptions about contracts between modules
• subtle behavioral drift from the actual requirement
•  broken cross-cutting concerns such as logging, middleware, or error handling

This is the key challenge: the implementation and its unit tests can both be wrong in the same consistent way. If AI writes the code and also writes the tests, both may agree with each other while still missing reality.

Why Smoke and E2E Tests Matter More Now 

Smoke and E2E tests are external validations of the system state. They don't check whether the implementation looks correct. They verify that the application behaves correctly for a real user. Thus, they are particularly valuable in the AI development process.

These tests are more effective at catching regression AI often introduces: integration breaks, behavioral mismatches, workflow regressions, and module issues that isolated tests may miss.

A simple terminology for this:

Unit tests verify that each block is correct. Smoke tests check if the wall is still standing.

Smoke tests are not just a helpful final check anymore. They are an important layer of sanity checks on top of AI-generated code.

More E2E Tests Do Not Mean Testing Everything

 This does not mean teams should swing to the other extreme and cover the whole product with E2E tests. It would recreate the same anti-pattern teams learned to avoid years ago.

The more reasonable conclusion is a more pragmatic one:

• write more E2E tests for critical user pathways
• use tests to cover key integration seams and business workflows
• do not use for every edge case or internal branch
• continue relying on unit and integration tests for most of the coverage

The E2E test count may need to go up, but selectivity still matters.

What Should Be Covered

The best candidates for smoke or E2E coverage are workflows critical to the business or product and where a regression would immediately affect users or the business.

Examples include login, signup, checkout, payment submission, onboarding, account recovery, document upload, and other critical paths that cross multiple systems.

These are the critical areas where AI-generated changes can cause expensive regressions, even when the local implementation appears correct. The aim is not to cover everything but confidence in the flows that matter most.

The New Testing Reality

The old lesson was to never invest too much in E2E tests.

The new lesson is not to assume green unit tests mean the system works, especially when AI helped write both the implementation and the tests. That is the real shift.

AI has not made the testing pyramid obsolete. But it has increased the value of the top layer. Smoke and E2E tests now serve as stronger guardrails against failures that AI-generated code is especially good at hiding.

Conclusion

The classic caution people had about E2E testing was indeed correct. Covering everything with smoke tests was never a good idea and still isn't. But AI-assisted coding changes the risk's location. The main issue is not usually about isolated correctness. It is about behavioral correctness, which applies to workflows, module boundaries, and integration seams.

This is exactly the reason why the teams should think about writing even more E2E tests, not in order to cover everything, but rather to protect key user journeys with a system-wide safety net.

In the AI era, smoke tests are no longer just nice to have. They are becoming one of the most reliable ways to verify that the product still works the way users experience it.