AI Sped Up Every Stage. Is Quality Keeping Up?
AI is now being used at every stage of the SDLC. Feature requirements are drafted by AI, code is written by AI, tests are generated by AI, and teams are shipping to live faster than ever.
But speed without quality is just faster failure.
If AI is involved at every stage, quality needs to be checked at every stage too, from the first line of a feature requirement to the moment a change is live.
Feature requirements: the stepping stone for everything
Before AI, feature requirements were written by the PO and verified with stakeholders.
Lately, more of that documentation is generated by AI. Sometimes it's bloated with unnecessary detail, or the important requirements are missing entirely.
Requirements are the foundation every feature is built on. If they're unclear, the team won't know the right questions to ask.
If AI is used to write requirements, make sure nothing is missing, nothing is confusing, and there isn't too much detail. Collaboration is key. The PO, developers and QA should go through the requirements together and ask questions early.
AI can help shape feature requirements. It shouldn't own them.
Development: acceptance criteria before code
With AI writing code, acceptance criteria need to exist before development starts, not after.
As QAs, we should take the PO's requirements, add our domain knowledge, and write clear acceptance criteria upfront. The AI then uses these to write tests alongside the code, so quality is built in from the start.
What we should expect in the code:
Unit tests: validate individual functions and business logic in isolation, so issues are caught at the smallest and cheapest point
Integration tests: confirm the service works correctly with its dependencies, such as its database and other internal services
Functional tests: validate behaviour against the acceptance criteria, using mocks where needed, before anything reaches staging
The metric to track: Test code coverage against quality gates. Tools like SonarQube let you set coverage gates, and every service should meet them before it moves forward.
But coverage alone isn't enough. AI can write tests just to hit a coverage number, without checking anything meaningful. That's why acceptance criteria matter.
Every test should prove real behaviour, not just a percentage.
Testing: confidence without the maintenance trap
The Test Pyramid still holds up. We want automation that's clean and easy to maintain, not something we spend all our time fixing. The Test Pyramid gives us that, building confidence early in the SDLC where tests are fastest and cheapest to run.
That frees us up for what really needs a human — exploratory testing, driven by domain knowledge.
Each layer of the Test Pyramid has a job:
Base — code-level tests: the unit, integration and functional tests covered above give us confidence before code reaches staging. This is where most tests should live, as they're fast, cheap and can run on every change.
Middle — API automation: automated tests against every endpoint on the staging environment. These confirm each endpoint behaves correctly in a real environment, including contracts, validation and error handling.
Top — UI automation: a focused set covering the main and critical user journeys, such as payments. Kept small on purpose, as UI tests are slower and more brittle, so they should be saved for the journeys that matter most to customers.
AI can write the API and UI automation scripts too. But just like the code-level tests, they should be guided by our acceptance criteria and domain knowledge, and reviewed before we rely on them.
Fast tests at the base, critical journeys at the top: defects caught early, with minimal maintenance
Live: be proactive, not reactive
Our responsibility doesn't end at deployment.
Monitoring live after every release means we catch problems early and react fast.
The essentials:
Post-release monitoring on every change we deploy. Dashboards that track success and failure rates on critical flows show straight away if something has changed after a release, so unexpected behaviour is spotted before it spreads.
A rollback plan for every release, before it goes out. Knowing exactly how to revert a change means recovery is quick, not improvised under pressure.
Alerts that notify us the moment a critical flow is degraded. When success rates on flows like payments drop below a set threshold, an automatic email goes to the team, rather than relying on someone noticing.
Canary deployments are the natural next step. A change is released to a small portion of traffic first. If failures cross a set threshold, it rolls back automatically, before most customers ever notice.
But good monitoring comes first. You can't automate a rollback on signals you're not tracking.
We shouldn't hear about issues from customers, we should know first.
Measuring it all: DORA metrics
DORA metrics measure how well a team delivers software. With AI, delivery is already faster, and it will only speed up as the tools improve. When speed increases this much, we need a reliable way to know whether quality is keeping up across every stage. That's why DORA metrics are key.
There are four core metrics, and every one of them matters to QA:
| Metric | What it measures |
|---|---|
| Deployment frequency | How often we release to live |
| Lead time for changes | How long it takes code to go from commit to live |
| Change failure rate | The percentage of deployments that cause an issue in live |
| Mean time to recover | How quickly we restore service when something breaks |
Why this matters to QA: AI is making development faster, so deployment frequency and lead time will likely hit elite levels.
But deployment frequency and lead time only measure speed. Change failure rate and mean time to recover tell us whether we're shipping quality.
Change failure rate: a low rate means quality is being built in early: feature requirements are clear, acceptance criteria are met, and our Test Pyramid is catching defects before they reach live. If the rate starts to climb as we deploy more often, it's a sign that speed is outpacing quality, and we need to find where issues are slipping through.
Mean time to recover: this one accepts a reality: at this pace, we won't catch every defect before live. What matters is how fast we detect it and fix it. Impact drives urgency, so the bigger the impact, the faster the fix needs to be.
Speed is easy to measure. Quality takes more intent.
The bottom line:
AI can speed up delivery. It can't own quality for us.
We're building software for humans. We bring the experience and the empathy to understand how real people will use it, and what it means for them when something goes wrong.
Quality is the whole team's responsibility. Do the requirements make sense? Are the acceptance criteria in place? Will live monitoring catch what we miss? These are questions anyone on the team can ask. When everyone takes ownership of the product and speaks up when a process is unclear, quality becomes part of how we work.
With AI doing so much of the work, it's easy to lose that human connection. But talking to each other, collaborating and asking questions is how we uncover what a feature really needs. Without it, we'll miss requirements no AI will catch.
Keep asking questions. Own it together. That's how quality keeps up with speed.