Most companies I talk to complain about the same three things: AI slop, ownership, and a pace so fast it's hard to understand what's going on. Many of them try to build software to make it all run smoother, and step away from their core work to do it.
One prospect told me what it cost them. A client-facing feature was presenting made-up data. What they heard from the client was: "you are not serious." It had taken them a long time to land that client. And poof, it was gone.
When something like that happens, the usual answer is more automation: more unit tests, more end-to-end tests. Until now, most teams have tried to automate testing so they wouldn't need QA.
Automated tests matter. But they can't answer the question that cost my prospect their client: does this even make sense? They also can't tell you who's responsible for what goes out.
My answer is the thing most teams worked hard to get rid of: bring manual QA back, as a senior role that owns what ships and reports back. AI is what makes that role easy to run now.
Code Is Cheap Now. Knowing What Shipped Isn't.
Code gets generated so quickly now that features go in faster than anyone can follow. Things break, and the mess is hard to manage.
Take a team of three developers. One pushed to staging. The second is waiting to push. The third pushed without a clue what was already there. Nobody knows what's on staging right now, and nobody owns the decision to send it out. That's the ownership problem those companies describe.
Accountability breaks down the same way. Developers test what they built. QA tests what the customer needs. When a developer says "works," it often means it works on their machine, on the path they wrote. Testing is a different job from building, and most developers trained for only one of them. Let them do what they like best, which is building.
Why Everyone Automated QA Away (And Why That Made Sense)
QA didn't get pushed out for no reason. Working with QA used to be slow. You handed things over in a specific format, waited for a report, then someone had to decide whether each finding was a blocker and what it did to the release. Every handoff was a wait.
So companies did the reasonable thing. They automated testing to get rid of the wait, and the QA went with it.
I'm not against automated tests. My last big launch had about 3,600 unit tests and 99 end-to-end tests, and real users hit no crashes. I still don't have 100% confidence that everything works. Some scenarios need real devices and real conditions. I'm setting those up, and it takes time.
A bigger gap sits where no test reaches: things that "work" but don't make sense. A test checks that a feature does what the code says. It can't check whether the code should say that. A person who knows the product can. Take my prospect's made-up data. Someone who knows what that feature should show sees the problem. The screen shows something that isn't true.
What AI Changed
The overhead around QA caused the pain: the handoffs, the waiting, the arguments over what counts as a blocker. That overhead is the kind of work LLMs are good at.
- What to test. An LLM can generate a working sheet for the QA, listing what to test based on what changed in the release.
- Tracking. The sheet is saved and tracked, so nothing lives only in someone's head or a chat thread.
- Reporting. When something comes up, the QA sends a summary with conclusions straight to the VP Engineering. No meeting to argue about whether it's a blocker.
- Releases. The company can make the QA the release manager, so the person who knows what's going on decides what goes out.
I haven't run this workflow inside a company yet. I'm proposing it. Each company will build its own version, and the pieces are available: LLMs are powerful enough, and the workflows are ours to build.
Not a Box-Ticker, and Not a Junior Role
When I say QA, I mean someone with a deep understanding of the product. The gatekeeper.
QA and the project manager work closely together and own different things. The project manager owns the process. The QA owns the results, knows what's actually going on, and answers the VP Engineering on "what went through?" and "what needs another cycle?"
Here's the strongest objection: if AI makes developers ship faster and everything goes through one person, that person becomes the bottleneck again.
Yes, it's a chokepoint, and chokepoints work when they're fast and staffed. The LLM takes over the sheet-building, tracking, and reporting, so the QA's hours go to judgment: using the product the way a customer would. The role also needs a named backup, so a vacation doesn't freeze releases. All of this points to a specific kind of person, someone who can work async and sees the big picture. It's no junior role.
How Big the Role Is Depends on You
This applies to every company. What changes is the size of the role. QA for an e-commerce store, held as one job among several, looks nothing like QA for a cybersecurity company with 30 developers. In some companies it grows into a department.
How to Set It Up
1. Define the role
Before you look for a person, write down what the role owns, which processes it runs, who it manages, and who it reports to.
2. Assign someone, or hire
Depending on your company, give the role to someone you already have or hire for it. You don't need to hire on day one: your own people can do the QA once the role and workflows exist. When the load grows, recruit someone to be the central hub of all of it. Either way, look for the person who fits the role you defined.
3. Build the workflows
Build them around your own needs. At minimum you need a way to decide what to test and a way to report. That's where the LLM-generated working sheet and the summary to the VP Engineering come in. Make someone responsible for the release cycle: a release manager, if you will.
4. Keep the gatekeeper in the loop
Congratulations, you now have a reliable gatekeeper. Keep them in the loop with management and operations so they always know what's up.
Confidence Is the Point
You want confidence in what your team ships. AI made writing code cheap. Knowing what went out still takes a person. A layer that monitors and reports back gives you that confidence.
A feature showing made-up data reached a client. Someone who knew what to expect would have caught it before the client did.
I run a 2 to 4 week audit that maps how AI-generated code moves through your process and who owns each release decision. If you recognized your team in this post, book a conversation.
