The platform engineering movement gave companies a name for something that had been happening quietly for years. A small, senior team builds the paved roads so every other engineer can ship faster. Backstage at Spotify, internal developer portals at Netflix, golden paths at GitLab. The pattern is the same everywhere: centralize the hard stuff, make the right thing the easy thing, stop hiring linearly to scale.
Quality is on the same path. Most engineering orgs haven't caught up. When customers come to me at Checksum, the headline is usually test automation; they can’t keep up, or they’re about to hire five more testers and aren’t sure that’s the right move. The real conversation, almost every time, is about org structure. And the customers who’ve figured it out are landing in roughly the same place: a quality function that looks like a platform team.
What changed
The old QA org was built for a world where humans wrote all the code at a roughly predictable rate. You scaled testing capacity linearly with engineering capacity. If you doubled your engineering team, you doubled your QA team a few quarters later. Headcount was the lever.
That math broke in 2024 and 2025. Tricentis CEO Kevin Thompson said at Transform 2025 that over 40% of code written last year was AI-generated. Developers using Cursor, Claude Code, and Copilot are opening more PRs, more often, with more code per PR. The validation load on QA teams went from "manageable backlog" to "structurally impossible" within about eighteen months. You can't hire your way out of it.
The teams getting this right have stopped trying to scale QA linearly. Instead of growing the org, they’re reshaping what’s already there.
The honest conversation
Before going further, I want to name something that comes up in almost every QA leader conversation I have, even when they don't say it directly: "Doesn't this just make my team redundant?"
One QA leader at an enterprise SaaS company put it to me plainly on our second call. He said something close to: in terms of job security, this only works if it's an enablement tool, not a replacement. He was telling me the truth about how his team would react if we got the framing wrong.
The teams I’ve seen do this well treat the system change and the role change as the same change. They’re moving the work down the stack so the team above it can finally do the work it’s always been blocked from doing. Get that framing wrong — bring in the system without changing what the team is responsible for — and you’ve told a group of senior people they’re being managed out. Your best ones leave before you can run the transition.
The shape of the new team
The pattern I keep seeing: QA is moving higher up the stack. The job shifts from executing tests to building the system that lets every engineer ship with confidence. The shape is the same as a platform team but the domain is different.
What customers actually do on day one of this transition isn't dramatic. They look at their QA org and ask three questions:
- Who on this team has been quietly building the automation framework everyone else uses? That person is the seed of the new team.
- What does the rest of the team spend its time on? If the honest answer is "executing test cases that should be automated" or "maintaining flaky tests that should be auto-healed," you have your roadmap.
- Where is engineering losing the most time on quality today? That's the first paved road the enablement team builds.
Where the line is
The cleanest mental model I've heard for this came out of a working session with a head of QA at a 350-engineer org going through the same transition. They split the work into two questions: what does the QE team own, and what does the system own.
The team owns Define. Coverage requirements by surface area. Risk tiers for different flows. The standards every test has to meet before it lands in main. The release confidence bar. These are product decisions about what the company is willing to ship, not decisions a tool should make.
The system owns Enforce. It makes those standards true everywhere, automatically. This is the part that breaks today. A 350-engineer org with opinionated developers (some preferring Cursor, some preferring Copilot, some refusing AI tooling entirely, all with different testing skill levels) cannot enforce a quality standard manually. The QE team can write the rules, but if enforcement depends on humans noticing in code review, the standard collapses inside a quarter.
What this looks like in practice
[Note to Brittany: insert customer name and detail here if shareable. The below works with or without naming them.]
The shift doesn't have to be dramatic. The teams I work with that have made it usually started by separating two things that used to be bundled together: the manual, day-to-day execution work of QA, and the strategic work of defining what quality means for their product.
The execution work such as writing the test cases, running them, debugging when they break, healing them when the UI changes — that's the work a system can take over. At Checksum we do this through a model we call Results as a Service. A human engineer verifies every test before it lands in the customer’s repo. The tests live in their codebase as real Playwright code. They keep them whether they stay with us or not. There’s no tool for the team to learn, configure, or maintain. The output is working tests in CI/CD, not a platform login.
What that frees up is the team. QA leads stop spending their week firefighting flaky tests. They start spending it in roadmap reviews, release planning, and conversations with their VP of Engineering about how to ship faster without losing confidence. The headcount doesn’t necessarily change. The work changes, and so does the way the rest of the org sees the team.
Indeed is the public example. They restructured their quality function around Checksum. Their team isn’t smaller. It’s reshaped.
Why engineering leaders are driving this shift
Engineering leaders don’t want to hire a QA org. They want to ship faster with fewer regressions. Reframing quality as a platform capability (something the system actually delivers) aligns the function with how the rest of engineering already operates. It’s also the reason this shift is happening from the top down, not the bottom up. The leaders pushing it aren’t QA leaders. They’re VPs of Engineering and CTOs who’ve already run this play on developer experience and want to run it again on quality.
What this means for engineering leaders
If you're running an engineering org with a traditional QA team and AI-generated code volume is climbing, the planning question for the next quarter isn't "how many QA hires do I need." It's "what does my quality enablement team look like and who's on it."
The teams I've seen do this well started small. They didn't blow up the QA org overnight. They identified one or two engineers who were already operating like quality enablers, gave them platform-team-shaped responsibilities, and built outward.
The shift from QA to QE has been talked about for a decade. What's different now is that AI made it urgent. The orgs that figure out the platform shape of quality in 2026 are the ones that will be shipping faster, with more confidence, on a smaller team. The ones that keep hiring linearly into a QA queue will be the ones explaining to their CTO why their release cycle is the bottleneck.
