A year or two ago, the slow part of building a feature was writing it. Today, a developer working with an AI coding assistant can go from a description to a working pull request in an afternoon. Designers and founders with no engineering background are shipping real sites with AI app builders.
That's genuinely great. It also moved the bottleneck.
When code is cheap to produce, the expensive part becomes knowing whether it's right. Does the page work on a phone? Does the form submit when the user pastes their email instead of typing it? Did fixing the header break the footer? AI made writing faster. It didn't make checking faster, and in some ways it made checking harder.
Why AI-built software needs more feedback, not less
There's more of it. Teams ship more changes, more often. Every change is a chance for something to break somewhere nobody looked.
Fewer people read every line. When a model writes a few hundred lines in seconds, review tends to focus on whether it runs, not on every edge case. The bugs that slip through are the ones that only show up in a real browser with real data.
The person who built it may not know how it works. If you generated a site with an AI builder, you might not be able to open the code and debug a layout issue yourself. What you can do is describe the problem precisely and hand it back to the tool.
That last point is the interesting one. In an AI-assisted workflow, the bug report isn't just for a human developer anymore. It's often the prompt.
The bug report is the prompt
Ask an AI coding assistant to "fix the broken button on the pricing page" and you'll get a confident guess. Give it the URL, the element, the browser and viewport, the console error, and what the user expected to happen, and you'll usually get a real fix.
Language models are only as good as the context they're given. The same five facts that make a bug report useful to a human make it useful to a model:
- The exact page and element.
- The device, browser, and screen size.
- Console errors and warnings.
- The steps that led to the problem.
- What should have happened instead.
This is why we added a Copy for LLM button to every FeedbackDots report. It turns the report into clean, structured Markdown, with the description, severity, page, pins, device details, and console lines, ready to paste into whichever assistant your team uses. The reporter didn't have to know anything about prompting. The report already has what the model needs.
A QA loop for AI-assisted teams
Here's a workflow that holds up well when most of your code is written with AI help:
- Ship to a preview or staging URL with the feedback widget installed.
- Have humans use it like humans. Clients, teammates, a few real users. Not to read the code, just to click around and drop a dot on anything that feels wrong.
- Triage the reports. Merge duplicates, set severity, and decide what's actually a bug.
- Hand each report to your AI assistant with its full context, and review the fix it proposes.
- Check the fix in the same place it broke. Same page, same device size, and close the loop with the reporter.
Notice that humans stay in the loop at the two points where judgment matters most: noticing that something is wrong and deciding whether the fix is right. The model handles the part in the middle where speed matters.
What not to automate
It's tempting to point an AI agent at your site and ask it to find all the bugs. Automated checks are worth having, and they'll catch broken links, failed requests, and obvious crashes. But many of the bugs that matter to users aren't errors at all. The button works, it's just impossible to find on mobile. The copy is technically accurate but confusing. The flow is correct and still feels broken.
Those are judgment calls, and they come from people. The goal isn't to replace human feedback with AI. It's to make human feedback so complete that acting on it, with or without AI help, takes minutes instead of days.
The new shape of QA
QA used to be a phase at the end. On fast-moving, AI-assisted teams it's becoming a continuous layer: always on, built into the site, collecting precise feedback from whoever happens to notice a problem, and feeding it straight back into the tools that write the fix.
The teams that do well with AI won't be the ones that generate the most code. They'll be the ones that find out fastest when that code is wrong.