The pyramid was never wrong, it was a cost model
The classic testing pyramid — lots of unit tests, a healthy layer of integration tests, a thin cap of E2E tests — was never really a statement about which tests matter most. It was a statement about cost. Unit tests are cheap to write and run in milliseconds. E2E tests are slow, need a real browser, and break every time someone renames a CSS class or moves a button three pixels to the left. So the advice was: push as much verification as possible down to the cheap layer, and treat E2E as a scarce resource you spend only on your most critical flows.
That advice still holds as a principle. What's changed is the number attached to "expensive." We're seeing more client teams in 2026 shift toward a shape people are now calling the testing diamond — still a small number of true unit tests, a much wider integration layer, and an E2E layer that's grown considerably fatter than pyramid orthodoxy would recommend. The trigger isn't a change in testing theory. It's that two things happened to the cost side of the equation at once.
First, AI coding agents are now generating and shipping user-facing flows — new pages, new form steps, new checkout variants — faster than a human QA team can hand-write E2E scripts to keep up. If your E2E suite only grows at the rate a person can type Playwright tests, you fall permanently behind the rate at which your product surface changes. Second, the tooling got cheaper to maintain. Faster runners, better parallelization, and test frameworks that tolerate minor DOM churn without snapping have lowered the ongoing cost of keeping a large E2E suite green. When the two big costs of E2E — authoring time and maintenance time — both drop, the "keep it thin" advice stops making sense as a blanket rule.
What "self-healing" actually buys you
We want to be precise here because the term gets thrown around loosely. "Self-healing" E2E tooling, in the practical sense teams are adopting in 2026, generally means test infrastructure that can tolerate small, non-semantic changes to the page — a selector that shifted because a div got wrapped in another div, a class name that changed after a CSS refactor, an element that moved slightly in the DOM tree but is still findable by its role or visible text. Combined with locator strategies that favor accessible roles and text over brittle CSS paths, this cuts down a huge share of the false-positive failures that used to make E2E suites a chore to maintain — the failures where nothing is actually broken, the test is just outdated.
AI-assisted E2E generation is a related but separate capability: describe a user flow in plain language — "a returning customer logs in, adds an item to their cart, and completes checkout with a saved card" — and get a first draft of the test scaffolding back. This is genuinely useful for getting new coverage started quickly, especially for flows that are tedious to script by hand.
Here's the part we're honest with clients about: none of this replaces engineering judgment about what to assert. A self-healing locator strategy means your test survives a div refactor. It says nothing about whether the test is checking the right thing. An AI-generated test might click through a login flow correctly and then assert only that the page didn't crash, missing the actual business requirement — that the user's cart contents survived the login redirect, or that a specific error message appears for a locked account. Generated tests need a human pass to tighten and correct assertions before they're trustworthy. Treat AI-assisted generation as a fast first draft, not a finished test.
Structuring a growing E2E suite around flows, not pages
The mistake we see when teams try to take advantage of "E2E is cheaper now" is defaulting to page-by-page coverage — a test per route, checking that the page renders. That's not what the lower cost buys you. What it buys you is the ability to cover more critical user journeys end to end without the suite becoming unmanageable. The organizing unit should stay the flow, not the page.
A sketch of how we structure this on a Next.js client project, using standard Playwright APIs:
import { test, expect } from "@playwright/test";
test.describe("returning customer checkout", () => {
test("logs in, keeps cart contents, and completes payment with a saved card", async ({ page }) => {
await page.goto("/login");
await page.getByLabel("Email").fill("returning-customer@example.com");
await page.getByLabel("Password").fill("test-password");
await page.getByRole("button", { name: "Log in" }).click();
// Assert the thing that actually matters for this flow: state survives the redirect
await expect(page.getByTestId("cart-count")).toHaveText("2");
await page.getByRole("link", { name: "Checkout" }).click();
await page.getByRole("radio", { name: /saved card ending in/i }).check();
await page.getByRole("button", { name: "Place order" }).click();
await expect(page.getByRole("heading", { name: "Order confirmed" })).toBeVisible();
});
});Notice the assertion in the middle — cart count surviving a login redirect — is the actual business risk in this flow, not just "did the button click work." That's the kind of assertion an AI-generated first draft is likely to skip unless a human adds it deliberately.
We group tests by journey (onboarding, checkout, account-recovery, subscription-changes) rather than by route, and we keep a short, explicit list of which journeys are "must never break in production" versus "nice to cover." That list is a product conversation, not just an engineering one — it's where the actual risk tolerance of the business gets encoded.
webhani's recommendation for test investment
For a typical Next.js/React client project, here's the balance we advise in 2026:
- Keep pure logic, pricing rules, data transforms, and isolated component behavior as fast unit tests. This layer should stay small and fast — nothing about the diamond shape argues for growing it, and it's still your cheapest, fastest feedback signal.
- Move most "does this component correctly talk to this API route" verification into integration tests. This is genuinely the layer that grows the most under the diamond shape — testing component and route interaction without the overhead of a full browser.
- Expand E2E coverage specifically for critical, cross-boundary user journeys — anything involving auth redirects, payment providers, multi-step forms, or state that has to survive navigation. This is where the lowered cost of E2E is actually worth spending; broad, shallow page-render checks are not a good use of that budget even though they're now cheap to write.
- Use AI-assisted generation to draft new E2E cases, but require a human review pass on every generated test before it merges — specifically checking that the assertions match the real business requirement, not just that nothing threw an error. We treat this the same way we treat AI-generated code: a competent first draft, not a finished artifact.
- Watch your flaky-test rate as the suite grows, even with self-healing locators. Track it explicitly rather than assuming the tooling has solved flakiness for you — it reduces one category of false failures, not all of them.
The diamond shape isn't a rejection of the pyramid's logic — it's the same logic applied to a cost structure that's genuinely different than it was a few years ago. The teams getting the most value from this shift aren't the ones writing the most tests. They're the ones who've been deliberate about which user journeys are worth the now-cheaper cost of full E2E coverage, and who still put a human eye on every assertion before trusting it in CI.