In my last post I argued that most teams test upside down: a thick layer of slow, flaky UI tests on top and a thin sliver of unit tests underneath. The fix is the pyramid. Lots of fast unit tests, a solid middle of integration and API tests, and a few end-to-end tests for the paths that make money.
That advice is older than most of the frameworks we use. What is new is that, in 2026, a growing share of tests are not written by a person. They are written, run and repaired by AI agents. So the obvious question is: do agents push us towards the pyramid, or back into the cone?
My honest answer after a year of using them daily: both, depending on which layer you point them at.
Where agents make the pyramid stronger
The base: unit tests
This is where coding agents are quietly excellent. A unit test has a small, well-defined input (one function), a clear oracle (the return value), and a fast feedback loop. An agent can read the function, write the test, run it, see it fail, and fix it in seconds. That loop is exactly what agents are good at.
The catch is the oracle. An agent that reads your implementation and writes a test that asserts what the code currently does has not tested anything. It has taken a snapshot. The useful version is the one where the agent works from the requirement, the ticket or the docstring, and the implementation is what is under test.
The middle: integration and API tests
The middle layer is where my background in ERP, CRM and payment integrations taught me the most, and it is also where agents surprise me. Given an OpenAPI spec or a few recorded requests, an agent will happily produce the boring, valuable tests nobody writes by hand: every status code, every required field missing, every boundary on a quantity or a date.
With MCP, the agent can also call the real system while it writes the test, so it checks its own assumptions against the API instead of guessing. That is the closest thing I have seen to a junior tester who never gets bored of negative cases.
Where agents drag you back into the cone
The top: end-to-end tests
Here is the trap. The most impressive demo of agentic testing is always an agent clicking through a browser. Give it a URL, it explores the app, writes a plan, and produces a pile of end-to-end tests. It looks like a month of QA work done in an afternoon.
But every one of those tests lives at the narrow, expensive top of the pyramid. If you accept them all, you have built an ice-cream cone faster than any human team ever could. The suite gets slower, the flakiness goes up, and the next UI refactor breaks fifty tests at once.
Self-healing makes the cone comfortable
Self-healing tests make this worse in a subtle way. When a locator breaks, a healer finds a new one and the test goes green again. That removes the pain that used to push teams down the pyramid. A brittle suite that fixes itself does not feel brittle anymore, so nobody asks why it has 400 UI tests and 30 unit tests.
A heal is a code change. It deserves the same review as any other code change, because sometimes the button moved, and sometimes the button is genuinely broken and the healer just found a way around it.
A rule of thumb I use
When an agent proposes a test, I ask one question before reading the code: what is the lowest layer that could catch this bug?
- If a unit test could catch it, the agent writes a unit test, even if it found the bug by clicking through the UI.
- If it needs two components talking, it goes into the API or integration layer.
- Only if the risk is in the full user journey (checkout, sign-up, the money path) does it stay end-to-end.
Agents are very good at finding bugs from the top. That is fine. The skill that stays human is deciding where the test that guards against that bug should live.
What this means for QA engineers
The pyramid is still the right shape. What has changed is the cost of each layer. Writing tests is now cheap at every level, so the old excuse ("we don't have time for unit tests") is gone. The scarce resource is judgement: choosing the layer, choosing the oracle, and reviewing what the agent produced.
That is the part of the job I think is worth getting better at, and it is what I will be writing about here for the rest of the year: testing with agents, and testing the agents themselves.
Where are agents writing most of the tests in your team right now: at the base of the pyramid, or at the top?
