04.15.26 By Dom Profico
Why the panic over AI-generated software sounds exactly like every other moral panic in our industry, and what actually needs to change.
The criticism of vibe coding has become conventional wisdom almost overnight. People use Cursor, Claude Code, or Copilot, prompt their way to a working application, ship it, and the result has SQL injection vulnerabilities, no input validation, hardcoded secrets, spaghetti architecture, and zero tests.
And that’s all true. It happens constantly.
But here’s the question nobody seems willing to sit with: when has that not been true?
Every time our industry has lowered the barrier to building software, the same panic has followed.
The pattern is unmistakable. The tool gets blamed for the practitioner’s lack of engineering discipline. Every. Single. Time.
That said, dismissing the concern entirely would be intellectually dishonest. Agentic coding tools don’t just repeat history. They change the dynamics in three ways that genuinely matter.
None of these are new categories of problem. They’re amplifiers. But amplifiers deserve respect, and the response to an amplifier is not to blame the amplifier. It’s to make sure your controls scale with your throughput. All three dynamics make the case for environmental governance more urgent, not less.
The 2025 DORA Report from Google Cloud called this the “AI Mirror Effect”: AI doesn’t create elite performance. It amplifies existing engineering culture. It accelerates high-performing teams while magnifying dysfunction in struggling ones. As the report put it, AI is “a powerful, unforgiving mirror that reflects the truth of your existing systems, processes, and culture.”
Here’s the strongest version of the argument that vibe coding critics are missing: every mitigation that matters for AI-generated software is a mitigation we already invented.
Static analysis and linting tools like ESLint, Semgrep, and SonarQube don’t care whether a human or an AI wrote the code. They catch the same classes of bugs either way. Organizations that had these tools in their CI pipelines before agentic tools arrived are in good shape. The ones that didn’t were already shipping vulnerable code.
Automated testing enforces the same constraints regardless of who, or what, wrote the implementation. If your pipeline requires meaningful coverage before merge, the origin of the code is irrelevant.
Dependency scanning, secret detection, SAST, and DAST are all toolchain-level controls, all indifferent to authorship.
Architectural governance, including ADRs, service boundaries, and API contracts, are organizational decisions. Some frameworks enforce conventions and boundaries, but the higher-order architectural choices that determine whether a system remains maintainable at scale have always required intentional design. Code generation alone, whether by humans or agents, doesn’t produce these.
The honest assessment is straightforward: organizations that had mature engineering practices are absorbing agentic tools with fewer quality failures. Organizations that didn’t are producing the same problems they always produced, just faster.
The criticism of vibe coding often comes from experienced engineers who internalized good practices so deeply that they forgot those practices are learned, not innate. When a veteran engineer uses Claude Code, they unconsciously apply constraints. They reject insecure patterns, insist on modular design, and require error handling. They steer. They have a mental model of what good looks like.
A newcomer to software doesn’t have that model. They accept the output uncritically. But here’s what’s crucial: that person wasn’t going to write secure, maintainable software by hand either. The alternative to vibe-coded insecure software isn’t hand-crafted secure software. It’s no software at all, or equally insecure software written more slowly.
This leads to an uncomfortable but important question: should agentic coding tools only be wielded by people who’ve already learned “correct” engineering behavior?
The instinct to restrict access sounds reasonable until you realize we’ve never successfully enforced that boundary for any technology, nor should we have.
We didn’t say “only people who understand memory management should write software” when garbage-collected languages arrived. We didn’t say “only people who understand TCP should build web applications.” We didn’t say “only people who understand relational algebra should query databases.”
Each of those abstractions let people who lacked deep understanding produce useful work. Sometimes messy, sometimes fragile, but useful. And in every case, we moved the expertise into the platform rather than demanding it from the individual.
We didn’t make every PHP developer learn about SQL injection before writing a query. We built ORMs with parameterized queries as the default. We didn’t teach every JavaScript developer about XSS. We built frameworks that escape output automatically. React doesn’t trust you with raw HTML unless you literally type dangerouslySetInnerHTML. The name itself is the guardrail.
The pattern is always the same: move the expertise into the environment. If your software quality depends entirely on the person writing the code, you never had quality. You had luck.
The real landscape of agentic tool adoption looks something like three tiers, and each requires a different kind of environmental support.
Senior engineers using agentic tools need the least governance applied to them. But they play the most critical role in the overall system because they’re the ones who define and maintain the governance itself.
This is the mental model shift that matters. The senior engineer’s job in an agentic-first organization isn’t primarily writing or reviewing code. It’s designing the constraints, templates, architectural fitness functions, and policy sets that the automated governance layer enforces. They’re writing the building codes, not inspecting every building.
One senior engineer defining a well-crafted architectural fitness function has more quality impact than that same engineer reviewing fifty pull requests. Their leverage is systemic, not transactional.
This is where the code review volume problem becomes acute. The current model at most organizations is already straining: developers write code, open a PR, and a senior engineer reviews it. Senior engineers spend a significant and growing share of their time on reviews. They start rubber-stamping when volume gets too high. Adding a substantial output multiplier on top of an already overloaded process makes that model collapse entirely.
The answer isn’t to have AI naively replace the reviewer. It’s to decompose what code review actually accomplishes and address each function with the appropriate mechanism.
Code review has historically served several purposes at once. It catches bugs, but automated testing and static analysis catch bugs more consistently at higher volume. It enforces architectural consistency, but linters and fitness functions do this more reliably than a tired engineer scanning a 400-line diff. It transfers knowledge, but that can happen through pairing and mentorship. It validates business logic correctness, and this is the piece that genuinely requires human judgment.
The model that works is layered automated governance with targeted human review. The pipeline handles security, dependencies, architecture conformance, coverage, and style. All automated, all blocking. The senior engineer’s review surface shrinks from “the entire changeset” to “does this business logic correctly implement the requirement?” That review takes ten minutes instead of an hour, and it’s the review that actually benefits from expertise.
There’s a second critical element: the agent itself should be a governance participant, not just a code generator. The agentic tool should push back in real time, flagging architectural violations, known vulnerabilities, and thin test coverage, all operating against a codified policy set. The agent becomes the first reviewer. The senior engineer becomes the last, seeing only what survived automated and agent-level scrutiny.
The instinct is to sandbox citizen developers completely. Give them a walled garden, let them build internal tools, keep them away from production. But that wastes enormous potential.
What citizen developers need isn’t restriction. It’s opinionated scaffolding. They shouldn’t start from a blank file. They should start from a governed template that already embeds the security posture, the authentication pattern, the data access layer, and the logging standard.
Think of it as building codes for software. You don’t hand someone lumber and say, “build whatever you want but make sure it’s structurally sound.” You give them a pre-engineered framing system where the load-bearing decisions are already made. They choose the layout, the finishes, and the function. The structural integrity is baked in.
Practically, this means the agentic tool operates within a defined execution context: approved libraries, pre-configured API gateways with auth already wired, database access through governed abstraction layers, deployment only through pipelines that run the full scan suite. The citizen developer never sees this infrastructure. They describe what they want, the agent builds it within the constrained environment, and the governance is invisible.
The failure mode to avoid is making governance feel like friction. The moment someone hits a wall that says, “you can’t do that, ask an engineer,” you’ve destroyed the value proposition. The environment should make the unsafe thing impossible, not merely prohibited.
The obvious organizational response is to create separate tracks: Tier 3 builds prototypes, Tier 2 builds production features, Tier 1 builds platform and architecture. Each tier gets its own pipeline, standards, and deployment targets.
This sounds clean, but it creates serious problems.
It puts artificial boundaries around what citizen developers can contribute. If a business analyst builds a workflow tool that proves genuinely useful, the parallel track model demands that a “real developer” rebuild it for production. That’s wasteful and demoralizing. The tool works. The question is whether it meets production standards, not whether the right person built it.
It also creates integration nightmares. Three separate tracks producing artifacts that eventually need to interoperate means three architectural contexts requiring reconciliation, and that’s a coordination cost that grows faster than the organization.
Most importantly, it reinforces a hierarchy of people rather than a hierarchy of governance. It says your tier determines what you’re allowed to produce, rather than saying the governance system determines what’s allowed to ship.
The model that actually works has one pipeline, one set of standards, one deployment path. What varies by tier is the support structure around the developer, not the destination of their work.
A citizen developer works inside a heavily scaffolded environment with opinionated templates, constrained library access, and pre-wired infrastructure. Their code goes through the same pipeline as everyone else’s. If it passes, and the scaffolding is designed to make passing likely, it ships.
A professional developer works with fewer constraints and broader architectural freedom. Their code goes through the same pipeline. Automated governance handles most of the review surface. A senior engineer reviews integration points and business logic.
A senior engineer works with full freedom but also maintains the pipeline and governance layer itself. Their code goes through the same pipeline. Yes, even theirs. Because the standard is the pipeline, not the person.
The tiers describe the amount of scaffolding the environment provides, not the value of the output. A citizen developer’s tool and a senior engineer’s microservice pass through the same quality gates. The difference is how much help each person gets reaching those gates.
In practice, this means people and artifacts flow between tiers naturally. A Tier 3 contribution starts as a scaffolded tool. As it proves valuable, a Tier 2 developer extends it beyond the original constraints. A Tier 1 engineer integrates it into the broader architecture. The artifact evolves. The governance is continuous. Nobody rebuilds anything. They build on top of what exists, within the governed environment.
Even the tiers themselves are fluid. A professional developer tackling a simple CRUD feature might operate in essentially Tier 3 mode with heavy scaffolding and constrained choices. That same developer working on a complex integration might need Tier 1 support. The tier isn’t a label on the person. It’s a description of the task’s complexity and the corresponding environmental support.
The panic over vibe coding is, at its core, the sound of an industry confronting a truth it has avoided for decades: we never built the governance infrastructure that software production requires. We relied on individual expertise, tribal knowledge, and heroic code reviewers. That model was always fragile. Agentic tools just made the fragility impossible to ignore.
Gartner has started calling the downstream cost of this gap “AI Debt”: what accumulates when organizations prioritize short-term speed over long-term sustainability. A 2026 empirical study found that roughly a quarter of issues introduced by AI coding assistants survive into production and persist as long-term maintenance costs. The organizations treating AI as a shortcut are building debt. The ones treating it as a capability that requires governance infrastructure are building leverage.
The organizations that will thrive aren’t the ones restricting who can use agentic tools. They’re the ones building governed environments where those tools produce reliable output by default, where the expertise lives in the system, not just in the heads of senior engineers.
The tools don’t need to be restricted. The environment needs to be opinionated.
This is the first in a series on agentic development and enterprise governance. Part 2 explores what happens when the entire product team can contribute running software, not just engineers. If you don’t want to wait for the series to unfold and want to talk about how this applies to your organization, Bridgenext helps enterprises design and implement governed agentic development models. Let’s talk.
