I can almost hear the words ringing out from the radio: “Oh, the times, they are a-changin’.” Without further dating myself, we all know that they are.
I’m a relative newbie in the software industry, having started my professional career around 2010. Sixteen years is actually a long time, but it feels like several lifetimes given how fast software development has changed. I started off in a shop that was wholly waterfall: very long, very large releases, sometimes months of development. But the promise of Agile was front of mind for everyone. Oh, what joy we would bring our stakeholders with consistent delivery! No more months-long cycles! No more weeks of testing after a dry spell broken only by a few critical defects or hotfixes.
After that, any number of variations started to land, all focused on making teams more productive. “Have you read about the Spotify Model?” “I think on a small team we can just do Kanban.” “For a large implementation you’ll probably want to run SAFe.” The conversations went on forever, and they’re still happening today. The goal of all of them was the same: make developers and teams more productive, and increase the throughput of the organization.
When Quality Moved Into the Team
One of the notable shifts was how teams looked at testing and quality, with some implementations of Agile requiring full-stack teams that included Quality Assurance. Before that, I’d sat happily on a QA team, adjacent to the developers, waiting for a crop of new stories to land so I could figure out what was wrong with them. After a couple of rounds we’d get a minimally buggy release, maybe some automated tests, and out the door it would go. Now we were going to sit with the developers and write the tests during the sprint, maybe even before they wrote the code!
Huzzah! The efficiency we’d all been looking for was finally here. What could ever be better than this?
I won’t pretend everything was great, and we all knew things were still changing. AI came in with more of a whisper than a bang at first, and I, like many people, was unsurprisingly pessimistic. While consulting, we ran an early test with two parallel teams. The results weren’t wildly impressive, but the team leveraging AI did see an improvement in throughput. Still, the organization I was with at the time published several articles about why AI wasn’t ready yet, which was a fair take back then.
Then the Gap Closed
That gap closed rapidly. Now the articles tell you that if you aren’t leveraging AI, you’re being left behind, and we’ve all seen the headlines about organizations shrinking their workforce or pushing for more AI adoption. “Breakneck” doesn’t even begin to describe the pace. Every day brings something new: a new frontier model, a new suggestion for using AI in your workflow, and as many AI-backed agentic workflows and assistant tools as your heart could ever desire.
We are churning out code at an ever-increasing rate, and we’ve only just started to wonder:
How are we going to test it all? Who wrangles all of the AI slop?
Some organizations are still turning to their old standby, the QA team. But that traditional testing role has been fading for years in favor of SDETs and Quality Engineers, and the landscape is shifting strongly once again.
The idea of a quality assistance approach isn’t new. Some organizations threw money at their testing problem, running staggering 2:1 developer-to-SDET ratios or offshoring entire teams of manual testers, and both approaches had their own challenges and benefits. But as teams chased efficiency while maintaining quality, the obvious next thing to optimize was the quality gates. The organizations that made the best use of their people leaned into shift-left quality engineering long ago and championed whole-team ownership of quality. Everyone writes tests, and everyone worries about quality. You don’t just throw things over the wall.
AI Didn’t Remove the Need for Quality Engineers. It Multiplied It.
The push to adopt AI tools has made developers more efficient, and has even made it easier for them to write tests. It hasn’t eliminated the need for quality engineers. In my opinion, it has increased that need dramatically.
As we lean on more AI agents and more workflows backed by agent teams, and hand off more day-to-day coding to AI, we are actually increasing the testing surface and its demands. We aren’t just testing outputs anymore. We aren’t waiting weeks for a release candidate so we can build tests for it. We might get several pushes a day and more frequent releases, and we definitely get TONS of new code: more than anyone could test on their own, even on a well-balanced full-stack team.
So the push now has to be toward thoroughly testing and reviewing the inputs and the outputs. A developer might ask a PM for more information about a ticket, or a designer for the updated comps for a UI. An agent, unless strictly instructed (and even then it might err), is more likely to make assumptions, and a less experienced developer is more likely to accept them. So when a user story is marked ready and a team, or just an agent, picks it up, it’s more important than ever that the story is well defined and refined. We need to have reviewed and tested our assumptions before they ever make it into the ticket.
When developers pick that work up, they’re more often than ever using coding agents to write the code. Great: we get more done. But if we aren’t also sharing the burden of testing, we’ve just moved the same bottleneck somewhere else.
What to Do About It
If we’re all testers now, it helps to be specific about what that means day to day. Here’s where I’d start:
- Test the ticket before anyone tests the code. Treat acceptance criteria as an input that gets reviewed like code. If a story is vague enough that an agent could reasonably guess, it isn’t ready.
- Make “done” include the tests, for humans and agents alike. Code that arrives without meaningful tests, or with tests the same agent wrote to agree with its own output, isn’t finished.
- Guard your regression suite. An agent empowered to write code will happily update tests to make them pass. Review changes to tests as carefully as changes to the product, and flag deleted or loosened assertions.
- Point quality engineers at leverage, not volume. Nobody can hand-test the flood. QEs earn their keep designing the strategy, the harnesses, and the guardrails that let everyone else test well.
- Review agent output like a new teammate’s pull request. Trust, but verify the assumptions it made, especially the ones nobody asked it to make.
To stay competitive in this landscape, we have to deliver at the pace of our competitors, with an eye for quality. That means reviewing what goes into the system as carefully as what comes out of it.
We’re all testers now.
