AI helps QA when someone gives it a job narrower than test generation.
A weak use case asks AI to generate volume. A stronger use case asks it to help choose the right checks for a specific code change.
On one project, I used AI-assisted analysis to connect pull-request changes to the tests most likely to matter. The team reduced test time by 30-35% without treating every change as equally risky.
The risk model still came from people who understood the product. AI helped apply that model faster.
Project note
Problem: The team ran too many tests for every pull request.
Action: I used AI-assisted analysis to map code changes to the tests most likely to matter for that change.
Result: Pull-request test time dropped 30-35% because the team ran a more targeted set of checks.
Lesson: AI helps when a human risk model defines relevance. Test generation without that model adds noise.
Why it matters
Broad test execution slows feedback and teaches teams to treat all changes the same.
Targeted execution needs guardrails: some checks still run every time, skipped checks run on a schedule, and release gates remain explicit.
What teams should check
Use these checks when a release depends on similar behavior.
- Which files, services, workflows, and tests map to each other?
- Which checks must run on every pull request?
- Which checks can run based on code-change relevance?
- When do skipped checks run?
- Who owns the risk model behind test selection?