Know What You're Building
Vibe coding is powerful. But power without context is how things break. Here's a framework for knowing when it's enough — and when it isn't.
The level of governance your software needs depends on what happens when it breaks, who's affected, and how forgiving the environment is when things go wrong.
So let me offer a framework. Not a rulebook — a way of thinking about what you're building and what that demands from you. Because vibe coding is genuinely powerful. The question isn't whether it works. The question is whether it works for this.
Three Zones
I think about software existing in three zones, defined not by how it was built but by the consequences of its failure.
Zone 1: Personal and Disposable
This is software built for yourself, your team meeting, your weekend project, or your curiosity. It might be a dashboard that helps you see a pattern in your data. A script that reformats a spreadsheet. A prototype that communicates an idea to your stakeholders. A tool you built on a Saturday afternoon because you were curious whether it was possible.
In this zone, errors are expected and forgiveness is immediate. If the output is wrong 30 or 40 percent of the time, that's probably fine — because you're looking at it, you can tell when it's off, and the cost of being wrong is low. Nobody's credit card gets charged incorrectly. No customer data gets exposed. No one's night gets ruined by a pager going off.
Vibe coding thrives here. Describe what you want, iterate until it feels right, deploy it or don't. The feedback loop is tight, the stakes are low, and the speed is the point. This is where AI-assisted development is most transformative — it lets people who never would have built software create tools that solve real problems in their daily work.
The key characteristic of Zone 1 software: the audience is you, or a small group that understands the limitations. Everyone involved knows the software is imperfect, and that's acceptable because the alternative was not having it at all.
Zone 2: Internal and Collaborative
This is software that multiple teams depend on. An internal analytics tool. A reporting dashboard. A workflow automation that connects systems. A data pipeline that feeds decisions across departments. It's not customer-facing, but it's not disposable either — people are making real decisions based on what it produces.
In this zone, the forgiveness barrier shifts from personal to interpersonal. When something breaks, the cost isn't just your inconvenience — it's someone else's missed deadline, bad report, or wrong conclusion. But the environment is still internal. You can send a Slack message. You can say "hey, that number looks off, we're looking into it." There's a human handshake available, and the people affected understand that the tool is evolving.
Zone 2 is where vibe coding starts to need scaffolding. The software works, but now multiple people depend on it, and they're not all sitting next to you. Questions start to emerge that vibe coding doesn't naturally answer: How do people report issues? Who fixes them? What happens when the original builder moves on to something else? Is there documentation? Are there tests — even basic ones — that catch the most obvious failures before they reach the people who depend on the output?
You can build Zone 2 software with AI. You can even build it mostly with AI. But someone needs to be thinking about the lifecycle, not just the launch. Humans, augmented developers, or AI-assisted workflows can all maintain this software — but someone has to be accountable for it. The tool doesn't maintain itself just because a model generated it.
The key characteristic of Zone 2 software: the audience extends beyond the builder, and the forgiveness model is interpersonal. People will tolerate imperfection if they trust that someone is paying attention.
Zone 3: Critical and Consequential
This is the software your livelihood depends on. Your e-commerce platform. Your native applications. Your cloud infrastructure. Your payment processing pipeline. The legacy system that twelve other systems rely on that was built in 2014 by someone who left four years ago. The single point of failure that nobody talks about until it fails.
When Zone 3 software breaks, the consequences are immediate and material. Revenue stops. Customers leave. Legal exposure materializes. The incident response team gets paged at 3am, and their ability to diagnose, communicate, and recover depends entirely on how well the system was built, instrumented, documented, and governed.
It's not that AI cannot operate in this zone. It can and increasingly will. But the outputs and the diligence around those outputs directly impact an organization's ability to navigate, repair, and recover from failure. If the system was generated without tests, without observability, without architecture that someone understands well enough to debug under pressure — then you haven't just shipped code. You've shipped a liability that won't reveal itself until the worst possible moment.
Zone 3 demands governance. Is a precondition. The testing, the architectural review, the security validation, the performance profiling, the incident response planning, the operational readiness — these exist because someone, at some point, learned what happens without them. Usually the hard way.
Vibe coding alone does not produce Zone 3 software. It can produce components, prototypes, and accelerated starting points that Zone 3 teams refine into production systems. But the refinement is the work. The governance is the work. The model doesn't cover ensuring its outputs are understood, maintainable, secure, and observable — that's not its job. Its job is to print code based on a text input. Expecting a prompt or a sequence of prompts to also encode compliance requirements, performance budgets, failure mode analysis, and architectural coherence isn't realistic. It's a different kind of work entirely.
The key characteristic of Zone 3 software: failure has material consequences, and the ability to respond depends on decisions made long before the incident.
The Zones Aren't Fixed
Software moves between zones. That's part of what makes this framework useful — and part of what makes it dangerous to ignore.
The internal analytics tool that three people used in January? By June, the VP is presenting its output to the board. It moved from Zone 2 to Zone 3 while nobody was looking. The prototype you vibed into existence to test an idea? It works, stakeholders love it, and now someone wants to put it in front of customers. Zone 1 to Zone 3, overnight.
This is the most common failure pattern I see with AI-generated software: something gets built at the governance level appropriate for one zone and then gets promoted to a zone with different requirements. The software doesn't change. The consequences do.
Being intentional about which zone you're building for — and having an honest conversation when software is about to cross a zone boundary — is one of the simplest and most impactful things engineering leaders can do right now.
At a Glance
| Zone 1: Personal | Zone 2: Shared | Zone 3: Critical | |
|---|---|---|---|
| Who it serves | You, or a small group that knows the limitations | Multiple teams who make decisions based on its output | Customers, revenue, or operations that depend on uptime |
| Error tolerance | 30–40% error rate is workable — you can see when it's wrong | Errors are tolerable if someone is accountable and responsive | Errors have material consequences — revenue, trust, legal exposure |
| Forgiveness model | Personal — you shrug and fix it | Interpersonal — a Slack message, a handshake, a known limitation | Institutional — incident response, postmortems, SLAs |
| Vibe coding fit | Thrives here — speed is the point | Needs scaffolding — lifecycle ownership, basic tests, issue tracking | Starting point at best — governance, review, and operational readiness are preconditions |
| Governance heuristic | Does it solve my problem right now? If yes, ship it. | Could someone else be harmed or misled if this breaks? If yes, add accountability. | Could this failure wake someone up at 3am, cost money, or erode customer trust? If yes, treat it like production. |
| Who maintains it | The builder, when they feel like it | Someone accountable — human, augmented, or AI-assisted | A team with operational discipline, observability, and incident response capability |
| Documentation need | None, or whatever helps you remember next month | Enough for someone else to report an issue and someone to fix it | Architecture decisions, runbooks, dependency maps, and enough context to debug under pressure |
| What to watch for | Nothing — this is the safe zone | The moment leadership starts treating the output as authoritative | The moment a prototype gets promoted to production without the governance it needs |
Where This Gets Interesting
I want to be transparent: I'm not writing all of this from a place of certainty. I'm writing from a place of genuine curiosity about how to make deliberate choices that lead to autonomous software outcomes. That's the exploration I've been on for the last several months — through the Autonomous Maintainability Index, the dark factory concept, the governance research, and the vibe coding distinction.
And here's where I think the conversation gets really interesting — because the answer to "how do we govern AI-generated software at scale" might not look anything like how we organize ourselves today.
Consider this: what if the first change isn't better prompts or stricter code review? What if it's that every SaaS platform, every PaaS, every data vendor ships MCP and agent interactions to market first — before building the dashboards, the charts, the login screens, the admin panels we've been constructing for decades?
Instead of building complex UIs that serve as the interface between humans and data, what if we authenticate an agent set? Staff equipped with MCP clients simply attach resources, auto-generate their personal applications to interact with the data coming from these external systems, and hook those insights into other tightly scoped agentic applications they build and manage on their own. The Zone 1 and Zone 2 software that organizations spend enormous energy building and maintaining internally — the dashboards, the reporting tools, the workflow automations — those become personal, disposable, and regenerable. They cost almost nothing to build because they're composed from governed data sources, not engineered from scratch.
That shifts where governance lives. Instead of governing every application, you govern the data layer, the API contracts, the agent permissions, and the compliance boundaries. The applications themselves become ephemeral — built on demand, used for a purpose, discarded when the need changes. The governance infrastructure underneath them is the durable asset.
This isn't a prediction. It's a direction that I think is worth exploring. And it's going to require insights from teams of professionals across multiple disciplines — security, data engineering, product design, legal, operations — to pull a coherent and complete operation together. No single discipline has the full picture. But the conversation about how to get there is one I think we need to start having.
Because the question isn't really whether vibe coding is good or bad. The question is: what does it mean for how we organize ourselves, govern our systems, and think about what software even is when the cost of creating it approaches zero?
Cheers,
~ John