We still argue about the release where this finally landed for one of us. Our E2E suite took about forty minutes and failed halfway through. Nobody trusted the result anyway. We had a pile of unit tests, a handful of integration tests, and a few Selenium flows that had been quietly rotting for three sprints. The pyramid was working exactly as designed: it was steering us away from a layer that cost more than it returned.
That is the problem the pyramid was built for. The constraint behind it has since moved.
The short answer on the testing pyramid
The testing pyramid says keep many cheap unit tests, fewer integration tests, and very few expensive end-to-end tests. Agentic AI makes the top layer cheap to write, cheap to maintain and stable to run, so the shape flattens out. It looks more like a diamond, or maybe even a pentagon.
That is the part everyone argues about.
Here is our actual position. The pyramid is a model for a suite you run repeatedly. The question worth asking now is how much belongs in that scheduled suite. What we recommend, and what we run ourselves, is two things together: a small scheduled regression suite covering only the flows that must never break, plus dynamic testing on every pull request, generated against what actually changed in the diff and run as part of that review. The generated tests persist as Drafts labelled ephemeral, outside the scheduled suite. That label describes their role, not a lifespan.
The pyramid's layers can describe those tests, but its shape alone does not tell you when they run or which deserve recurring coverage. Keeping a test is not the same as scheduling it. That is the real distinction.
Where the pyramid came from, and what it was really about
Mike Cohn drew the first version of it; Martin Fowler popularised it. The version most teams carry in their heads has three layers.
At the bottom, unit tests. Fast, independent, cheap, written by developers to catch logic errors. In the middle, integration tests, checking that parts of the system actually talk to each other. At the top, end-to-end tests, validating how the whole application behaves for a real user.
Every layer is dynamic testing. Each one runs the code and watches what it does. The pyramid's job was to allocate a budget across those layers.
Kent C. Dodds reshaped it into the testing trophy: static analysis at the base, then unit, then integration carrying most of the weight, then a thin end-to-end tier. Why he redrew it matters. He argued the pyramid assumed tooling that was no longer true of JavaScript, and re-derived the shape from the tooling he actually had. That is the same move we are making here. He left end-to-end thin because when he drew it, end-to-end was still expensive.
Both models were built on the same lived reality. Writing an E2E test meant grinding through a long script, hunting for selectors that broke, watching the suite fail after every cosmetic change, and spending more time debugging the test than the feature. Cost went up as you climbed. Stability went down. Minimising E2E was a cost-benefit decision, and at the time it was the right one.
Change the cost structure and you have to work the advice out again.
What agentic AI actually changed
Most discussions of AI and the testing pyramid focus on what agents can do. The thing worth looking at is what they do to cost per test, which means the cost of writing, maintaining and running one.
Writing. You describe intent in plain language instead of scripting steps. A test that took an afternoon takes minutes. The barrier that kept the top layer small was mostly authoring time, and it is largely gone.
Maintenance. Scripted E2E tests break on UI changes, timing, missing selectors. An agent navigating toward a goal absorbs most of that. Fewer failures for reasons unrelated to actual bugs.
Execution. Runs happen in parallel across environments without you building the infrastructure for it.
Flakiness. The classic E2E failure was usually a popup, a race or a layout shift rather than a bug. Agents handle more of those, and teams start trusting results again.
If E2E tests are faster to write, easier to keep alive and more stable to run, then "keep them to a minimum" loses its force. The advice made sense on its premise, and that premise has expired.
So the shape changes. That is not the headline.
With those costs flattened, the picture stops being a triangle. The top widens. Two layers appear that the original model had no slot for, and they are worth naming properly.
Agentic exploratory testing. This replaces what a QA engineer used to do by hand with a new feature in front of them: poke at it, simulate real user behaviour, check it against internal standards and basic good practice, wander off the scripted path and find the edge case nobody wrote down. A person still starts it, and points it at an area worth exploring. What changes is that it is no longer rationed to whoever has an afternoon free before a release.
Agentic regression testing. Traditional regression leans on rigid scripts. Agentic regression tests assert on expected outcomes and navigate to them, so a moved button does not fail a run on a changed selector. This is only ever half of what we recommend: keep this tier small and scheduled, covering the flows that must never break, and let dynamic testing generated from each pull request's diff carry the depth on whatever changed.
Airpelago is the clearest example of the top layer growing. Their Playwright scripts struggled with map-based interactions, like planning drone inspection routes or exporting reports. After moving to QA.tech, all 20 of their primary user journeys are being handled by agents, including interactive map widgets that manual scripts couldn't reliably manage. Coverage that nobody had scripted before, because nobody could. Twenty journeys is the whole scheduled tier, not a floor to build on, and the per-PR half still does the work on whatever a given change touches.
So yes, redraw the triangle. Diamond, pentagon, whatever you like. It matters less than it looks, and here is why.
The question the shape hides
A pyramid, a trophy, a diamond: they all answer the same question. Given a scheduled suite you maintain and re-run, how should its mass be distributed?
The prior question is which tests deserve to run on a schedule, rather than only as part of a change review.
Daniel, our co-founder, said the uncomfortable version of this out loud on a call in August. The customers who run the most tests with us, he said, "are the ones with big regression suites. But you don't want to be there – that's running thousands of tests once a week and just getting everything green."
Running everything and getting green is a ritual. You learn almost nothing from a thousand passing tests on code that did not change, and you pay for every one of them in minutes, money and attention.
His view on what we keep instead: "I don't want a regression suite that checks that the dots are green in a certain view. It's too nitty-gritty and I don't want it blocking things if they look a little off. It costs too much and takes too long for what I get out of it. We've chosen a tighter regression suite for what's important – you can sign up, you can pay."
And the hypothesis underneath it: "My hypothesis is that we can build dynamic testing so good that we don't need a mass of regression tests. Test in depth around what changed, but don't test it over and over again."
That is the pairing, and both halves are load-bearing. A small scheduled regression suite covering sign-up, payment and the handful of flows that ruin your week if they break. Plus dynamic testing on every pull request, which is what PR testing does: generated from the diff, run against what changed, and retained in Draft without automatically joining scheduled regression.
Keep the tests; be selective about scheduling them. Concretely: a PR touches the tax calculation on checkout. The agent reads the diff, works out which flows reach that code, and runs them deeply against the preview environment. A domestic order, a cross-border order, a discounted order, a refund. Those generated tests stay in Draft, labelled ephemeral, and keep running as part of the review while staying out of the scheduled suite. They are not deleted after the merge.
If you have enabled the opt-in post-merge agent, it reviews the test cases surfaced during that PR's review and activates the ones worth keeping as regression coverage, labelling them regression and auto-added. It is selective: the GitHub documentation explicitly says, "Promoting nothing is a normal outcome." Nothing joins the scheduled suite simply because it was generated. The suite grows only through deliberate promotion.
The arithmetic that kills big suites
Here is an illustration, not a statistic. Take a run of 100 tests and give each one a 1% chance of failing for a reason that has nothing to do with your code. About two runs in three come back red. Push the suite to a thousand tests at the same rate and it is effectively every run. Meanwhile maybe five of those tests touch what you actually changed.
So every run produces a red thing to investigate, and the red thing is almost never the bug. Engineers work that out fast, and then they treat the suite as weather. They stop reading it. The expensive asset has become a thing you route around.
Shrinking the suite is how the remaining failures get believed. And shrinking only works if the depth goes somewhere: that is what the per-PR half is for, generating tests against the diff so the five that matter get written fresh instead of hunted for among a thousand. More on the first half in why a large regression suite is a liability, and on why a green suite is thin evidence in passing tests are not proof.
Generated tests break the pyramid's cost assumption
There is a second-order effect almost nobody has priced in, and a customer put it better than we have.
A QA lead at a games company, translated from Swedish, described what his team had built: "One of the big things we've done is to build a lot of AI aids for the developers to write ordinary tests. It makes it easier in the sense that you can get a lot more help writing ordinary unit tests and other kinds of integration tests at a lower level."
Then he followed the line forward. "Because potentially now, if the AI writes a hell of a lot more test cases for us, we'll get to a point where we have trouble running all the test cases. We're not there yet, but today we can do everything."
Read that again, because it inverts the pyramid's founding assumption. The base was supposed to be the cheap layer. Cheap to write, cheap to run, so pile them up. But if generation is near-free at every level, the constraint moves from writing tests to running them, and from running them to reading the output. Unit tests stop being free the moment a developer has to decide which of the morning's failures matter.
The pyramid's shape was a budget allocation for authoring effort, and authoring effort is no longer what you are short of. You are short of attention.
Layer by layer, as it stands now
| Layer | Who writes it now | What changed | What you keep |
|---|---|---|---|
| Unit | Developers, heavily AI-assisted | Generation is near-free; coverage gaps get filled automatically | Keep. Still the fastest way to pin down what a function does |
| Integration / contract | Developers, with agentic API testing covering contracts | Cheaper, but needs more human oversight than the other layers, because the documentation an agent would read is often missing or wrong | Keep, and review |
| Agentic regression (E2E) | Agents, from stated intent | Cheap to write and stable to run, which is exactly why it is tempting to over-keep | Keep only the flows that must never break, and pair it with the row below |
| Dynamic PR testing (review-specific coverage) | Agents, from the diff | Separates change-review execution from scheduled regression | Persist as Drafts labelled ephemeral; deliberately promote only worthwhile regression coverage |
| Agentic exploratory | Agents, unscripted | Absorbs most of what manual visual validation used to catch | Keep the practice, not the tests |
| Manual | Humans | Visual checks and routine click-through largely absorbed by agents | Keep judgment work: UX, risk, ambiguous requirements |
The integration row deserves its caveat spelled out. Agents are good at inferring intent from an interface a human can see. They are much worse at inferring a contract between two services when the documentation is a stale README and a Slack thread. That layer still wants a person in it.
Not everything belongs at the top
An AI champion at a travel technology company said something we keep coming back to, translated from Swedish: "I understand that end-to-end is what you want to test. But not everything can be tested end-to-end."
He is right, and the cheap-E2E argument gets abused in exactly this direction. A rounding error in a pricing function, a date-boundary bug, a parser that mishandles one encoding: you can reach those through the UI, but you are paying a lot of machinery to assert something a unit test pins in milliseconds. Depth at the bottom is still the right tool for logic. The top layer tells you whether a user can get through the door.
The pushback, which is fair
Not everyone is sold, and the sharpest objection we have heard came from the same games company QA lead: "It's cheaper if you can just write a simple test case and run it. It's cheaper than having to ask an AI. It's easy to define steps 1–10 and just submit it and it's done automatically. Instead of having to query an AI: what should we do now? Well, you should click that button."
For a stable, simple, high-frequency flow, he is correct about the per-run cost. A scripted click is cheaper than reasoning about a click, and it always will be.
The answer is not that he is wrong. It is that per-run cost is the wrong unit. The scripted test is cheaper to run and more expensive to own, and ownership is where the money goes: the rewrite after the redesign, the flake triage, the week someone spends deciding which of these tests still mean anything. If a flow is stable and simple, script it and keep it. That is a sensible use of the lean regression tier. The reasoning cost is worth paying where the UI moves, where the flow is long, or where you want the test written for you against a diff you have not read yet.
Where this contradicts our own advice
We have an article arguing roughly the opposite: how to automate full regression runs without slowing builds. Keep the big suite, make it fast, parallelise it, shard it.
Both are on the site on purpose, so we will be explicit. Lean critical-path regression plus dynamic testing on the diff is the recommended model. Scaling full runs is the fallback for teams who are not ready to shrink, and there are good reasons not to be ready: a regulated audit trail, a monolith nobody fully understands, a suite that is the only surviving documentation of how the product is supposed to behave. If that is you, make the big suite fast. Just do not mistake it for the destination.
What agents still cannot do
Four things agents are still bad at.
AI improves testing and it still lacks human judgment. It does not have a view on whether an experience is good, only on whether a flow completes. Ethical questions do not show up as failures. Complex business logic, the kind encoded in six years of policy decisions rather than in code, is not something an agent can infer from the UI. It struggles with risk prioritisation: given twenty findings, which three actually matter to this business this week is a question that needs someone who knows the business. And it will cheerfully misinterpret an ambiguous requirement, confidently, in a way that produces a green run.
The human work relocates: test strategy, failure analysis, deciding what is worth checking at all, keeping the whole thing anchored to something real. We have said in the past that regression testing can be fully automated. That was wrong. It cannot.
What this means for your team
Stop scripting. Start writing intent. That shift is real.
But the more useful change to make this quarter is smaller and more concrete. Go look at your scheduled suite and ask which tests have ever caught a bug that mattered. Most teams find it is a short list. Keep that list, make it the scheduled tier, and let the diff drive everything else.
The question stops being "do we need another E2E test?" and becomes two questions. Which flows must never break? And what changed in this pull request that nobody has looked at yet?
So: is the pyramid disappearing, or just evolving? It still helps allocate tests across layers, and the shape is now flatter. But it is not the whole strategy. Keep the scheduled suite focused and put your depth where the change is. PR-generated tests persist, while recurring regression coverage grows only through deliberate promotion. A layer diagram alone cannot describe that separation between what you retain and what you schedule.
If you want to see what that looks like on a real flow, book a demo, or read Designing Tests for Intent, Not Selectors.
FAQ
What is the testing pyramid? It is a model for distributing a test suite across layers: many fast unit tests at the base, fewer integration tests in the middle, and a small number of end-to-end tests at the top. It was popularised by Martin Fowler. The logic is cost-based, because E2E tests were historically the slowest and most fragile layer to own.
Is the testing pyramid still relevant in 2026? As a budget model for a scheduled suite, partly. The cost ordering it assumed has changed, because agentic tools make E2E tests cheap to write and stable to run, so the top layer widens. The deeper limitation is that it does not distinguish review-specific coverage from scheduled regression. PR-generated tests persist as Drafts labelled ephemeral, outside the scheduled suite; only deliberate promotion makes them active regression tests.
What is the difference between the testing pyramid and the testing trophy? The trophy, from Kent C. Dodds, has four layers rather than three: static analysis, unit, integration and end-to-end, with integration carrying most of the weight. Both keep end-to-end thin because it was expensive, and both describe a suite you maintain forever. The trophy is the better of the two, and it is still answering the allocation question rather than the prior one: how much suite should there be?
How big should a regression suite be? Small enough that every failure gets read. In practice that means the flows that must never break: sign-up, payment, and whatever specifically ruins your week when it goes down. Everything else is better handled by generating tests against what changed in each pull request.
Why not just keep a large regression suite and run it faster? You can, and sometimes you should. The problem is not duration, it is signal. As an illustration: at a 1% flake rate, a hundred-test run comes back red about two times in three, and a thousand-test run comes back red almost every time, while only a handful of tests touch your change. Teams stop believing the red. The recommendation is a small scheduled suite of the flows that must never break, plus dynamic testing generated from each pull request's diff. Scaling full runs is the fallback when you cannot shrink yet.
Can AI fully automate regression testing? No. Agents handle generation, navigation and maintenance well, and they absorb a lot of what manual visual checking used to cover. They do not have judgment about user experience, ethical concerns or complex business logic, they are weak at prioritising risk, and they will misread an ambiguous requirement without flagging it.
Do unit tests still matter if AI can write end-to-end tests? Yes. Logic errors are cheaper and more precisely located at the unit level, and not everything can be reached sensibly through a UI. What has changed is that AI assistance makes unit and integration tests far easier to generate, which moves the bottleneck from writing tests to running and reading them.