Agentic development is fast. An agent can scaffold a feature, write the tests it thinks it needs, and open a pull request before you’ve finished your morning coffee. That speed is real, and agentic development is not going away. Which means the QA analysts who thrive in this brave new world won’t be the ones raging against it. They’ll be the ones who pick up the same class of tools and put them to work on their own side of the process.
Development cycles are shrinking and speeding up, but verification and testing can’t shrink at the same rate. If anything, it needs to slow down and expand. The faster the development process moves, the more scrutiny each change actually deserves.
Happy Path? More like Crappy Path
When developing twice the features in half the time, work piles up in the QA queue, and when it does, it’s tempting to just test the happy path. This feature was built for the user using it like this so just do that. This is the wrong move. Developers, and now agents, are already testing the happy path by construction; it’s baked into the spec they built against. If QA only re-confirms what the spec already assumed, we’re duplicating work instead of finding what the spec missed. If we are not testing for edge cases, weird input and bad states, QA stops being a distinct role and just becomes a slower second developer.
At the end of the day, or the end of the development process, a real human being is going to use this application. This means at some point, a real blood sweat and tears human has to sit down and manually click through the feature the way a customer will, and let’s be honest, it probably isn’t going to be the developers doing that. They’re moving on to the next ticket, or the next agent run, which means if QA doesn’t step in, nobody will.
That kind of testing takes more than clicking through steps: it takes the expert mindset of someone trained to think like a skeptical, curious user, question what “should” be true, and know which broken thing actually matters. That’s not a mindset an agent has and it’s not one most developers are paid to have either. While it is validating to see the importance of one’s QA work, this doesn’t reduce the uncomfortable truth: quality analysts run the risk of being overwhelmed with work as every other aspect of the project accelerates.
Skills pay the bills
The move isn’t to slow development back down or dig our heels against the tools being implemented by our developers. It’s to adopt the same agentic approach QA is being asked to keep up with so there’s more time left for the part of the job only a person can do.
I built a Claude skill for exactly this: it turns an annotated Snagit screenshot directly into a structured Linear issue. If I see an issue when testing I just grab a screenshot and add a short sentence describing the issue and the ticket writes itself. Title, reproducible steps and context are pulled straight from the screenshot and pushed to a Linear ticket in the backlog or as a comment on the ticket being tested. It doesn’t replace the testing process or the eye for what’s actually broken but it kills the bug filing slog so more of the day goes toward testing the application. An hour’s work with an agent produced a skill that will save me precious time across projects.
A fellow QA analyst took this further and built a skill that catches missing requirements before a single line of code gets written. Feed it a user story, a design, or a set of acceptance criteria, and it reads through for what’s actually changing and flags the gaps. It writes each concern up in plain language anyone can weigh in on so a PM or designer can look at it and make a call. It keeps the list short and focused on what actually matters instead of dumping a giant generic checklist and it can hand you a clean shareable report or just talk you through the questions one at a time.
Use the Darn Knowledge Base
If your team has an internal knowledge base, use it. A lot of QA time disappears into asking around for clarification: pinging a developer to check if a behavior is expected, or whether it’s already covered by an upcoming ticket. An agent that can query the knowledge base and the current codebase directly can answer a lot of that without waiting on a colleague. It doesn’t replace confirming a genuinely ambiguous case with a person, but it clears out the questions that already have a clear answer sitting in a document or the codebase.
QA analysts who treat agentic tools as something only developers get to use are going to fall further behind every sprint. The ones who adopt them for triage, ticket-writing, and research are the ones who’ll actually have the bandwidth left to do real testing.
Developers May Have Downtime, Use It
The other half of this is cultural, not technical. Agentic workflows don’t just save developers time on writing code, they create gaps: time waiting on an agent to finish a task, review a diff, or run a build. Multiply that across a sprint and it’s meaningful added capacity. This can be a natural place for developers to pick up QA work: verifying an agent’s own output, running a test plan, or pairing with QA on a tricky edge case.
Now convincing developers on your team to pick up this work is another story. Maybe there’s a skill for that?
Don’t let the team disappear along with the busywork
One thing worth watching as all of this rolls out: a lot of what used to pull developers and QA into the same conversation is exactly the kind of thing agents and knowledge bases are now designed to absorb. That’s good for speed but it is not necessarily good for the team. Collaboration was never just overhead to optimize away; it’s how context spreads and how working relationships get built. Adopt these tools, but keep an eye on whether the team is still actually talking to each other. If nothing else we can share the skills, triumphs and frustrations of the agentic delivery process.
Agentic development isn’t a threat to QA. It’s a toolkit QA hasn’t fully picked up yet. The teams that come out ahead won’t be the ones with the fastest agents. They’ll be the ones where QA adopted the same speed, and used it to test harder, smarter and faster.