The first thing AI did to content was remove the cost of production.
A PRD that used to take three days can take three hours. A prototype that took two weeks can be done in a few evenings. A blog post, a slide deck, a marketing brief - all faster, all cheaper, all easier to spin up than they’ve ever been. This is genuinely useful. I’ve written about it directly from experience.
But there’s a second-order effect that I think is getting underweighted: when volume becomes cheap, quality becomes the scarce resource. And the people who understand that distinction, and can enforce it, become more valuable, not less.
The volume trap
Here’s the problem with frictionless generation: most of it is fine. Not bad, not broken, just fine. It passes a casual read. It looks like the thing it’s supposed to be.
And that’s exactly what makes it dangerous in the wrong context.
Software engineers already have a name for this class of problem. Code that compiles and runs is not the same as code that’s correct, secure, and maintainable. AI-generated code has a specific failure mode: it confidently produces output that looks right, follows conventions, and contains subtle vulnerabilities that are easy to miss on first review.
Security researchers have been documenting this for a while now. AI-generated code tends to replicate common patterns, including those that are inherently insecure. It doesn’t reason about threat models. It doesn’t know your specific attack surface. It doesn’t consider what happens when a malicious actor probes edge cases. None of that shows up in a code review if you’re just checking that the function does what it says.
Quality requires a different skill than generation
This is where I think the “AI replaces experts” narrative breaks down hardest. The people who catch these problems aren’t just reading code. They’re applying a framework: threat modeling, adversarial thinking, pattern recognition across failure modes they’ve seen before. That’s not a process that scales through generation. It scales through expertise.
The same applies outside engineering. A product manager reviewing an AI-drafted PRD isn’t just checking whether it’s readable. They’re checking whether the problem statement reflects what customers actually said, whether the edge cases make sense for the real user population, and whether the success metrics are ones the business can actually measure. Those are judgment calls that require context the model doesn’t have.
A designer reviewing AI-generated UI isn’t just checking whether it’s aesthetically passable. They’re checking whether a 60-year-old with low vision can navigate it, whether the interaction model maps to what users expect, and whether the layout breaks at edge-case content lengths. That requires a trained eye and accumulated knowledge of failure modes.
None of these are things you can automate. You can use automation to move through them faster, such as automated testing, static analysis, and accessibility checkers, but someone still has to design the tests, interpret the results, and decide what constitutes acceptable risk.
The expert’s job changes, not disappears
Here’s the reframe: AI doesn’t eliminate the need for experts. It changes what experts spend their time doing. The execution layer gets cheaper. The judgment layer gets more exposed.
A senior security engineer who used to spend half their time writing implementation code now spends more time on the things only they can do, such as architecture decisions, threat modeling, review, and incident response. That’s not a demotion. That’s a better allocation of a scarce resource.
The same thing happens in product. If a PM is spending 60% of their time writing documents that AI can now draft in 20 minutes, and they take those 20 minutes and call it done, they’ve missed the point. The 60% that was document production should become 60% of sharper thinking, better customer research, and harder prioritization conversations.
The floor on output has risen. The ceiling on judgment hasn’t moved.
What this means for how you evaluate AI tools
If you’re assessing an AI workflow — for yourself or for your team — the right question isn’t “how much faster can we produce things?” It’s “who is doing the quality verification, and do they know what to look for?”
Fast generation without robust review isn’t acceleration. It’s technical debt at scale. Or, in the security case, it’s risk accumulation that you won’t see until something fails.
The teams that get this right are the ones that use AI to increase throughput on the execution layer and reinvest that time into deeper expert review — not teams that use AI to reduce the number of experts.
Volume is now free. Quality still takes work. And the people who can tell the difference between them are the ones you want on your team.