The Permission to Build · Article 3 · The Bus-Factor App: What Happens When Your Vibe Coder Quits?
The demo was excellent.
Leadership loved it.
The little internal tool solved a real problem. Then it solved another one. Somebody asked for a button. The agency started using it. Three rooftops became twelve. Twelve became forty. Eventually, an important operating process began depending on it.
Then Kyle left.
Nobody is entirely sure where the production source code lives.
The deployment appears to be connected to Kyle’s account. One API credential belongs to an employee who changed departments. The cloud bill is hitting a corporate card, although nobody remembers exactly whose. There is a database running somewhere. The application uses several external services, a couple of model providers, more software packages than anyone recalls intentionally installing, and an automation that apparently becomes load-bearing if someone deletes a Google Sheet called Dealer_Master_FINAL_2.
There is documentation.
It says: Ask Kyle.
Welcome to the bus-factor app.
If the business cannot transfer an important AI project to another competent operator, the business does not own an application… it owns a dependency.
This problem did not begin with vibe coding. Software organizations have worried about key-person dependency, undocumented systems, abandoned libraries, credential sprawl, technical debt, third-party components and questionable IP ownership for decades.
AI changes the velocity.
Article 1 explored what happens when far more people suddenly gain the ability to create software, and Article 2 followed the idea into enterprise data. Now suppose we did all of that well: the application is useful, the data access is appropriate, the customer is better off and the organization wants to keep it.
Can the business survive the person who made it?
That question becomes considerably more important as AI allows organizations to accumulate useful software faster than they accumulate institutional understanding of what they now depend on.
The traditional bus-factor question is intentionally morbid: how many people can disappear before nobody left understands how an important system works?
The person does not need to be hit by a bus. They can get promoted, take parental leave, join another company, become an agency consultant, finish the engagement, decide they are now an AI thought leader, or simply move on to something more interesting.
The operational outcome is the same. If an important system only works because one specific person remains available, the organization has not institutionalized the capability. This matters because internal AI projects rarely announce themselves as future infrastructure. They become important gradually.
Nobody wakes up intending to create an undocumented enterprise dependency on one human being. The application begins as an experiment, so one person understanding everything because one person built everything is completely reasonable. The pilot succeeds, a few more people begin using it, another integration gets added, somebody connects it to a live workflow and another department asks for access. Six months later, the prototype is processing real work and the architecture increasingly exists inside one person’s head.
The project changed categories again. Just as the quality bar should rise when an application gains access to more sensitive data, the continuity requirement should rise when the organization gains more dependency on the application. A prototype can reasonably depend on the builder. A business process should not.
The more the enterprise depends on the project, the less the project should depend on its original builder.
That does not require turning every useful internal app into a Fortune 100 software-development program. It means institutional knowledge has to begin replacing personal memory as consequence grows. The business should be able to identify where the code lives, how it deploys, which systems it touches, which credentials it uses, what it depends on, how a failure becomes visible and who is responsible for keeping it alive.
Those are more than bureaucracy questions. They are the difference between having a capability and having a person who can perform a magic trick.
This is where the seemingly simple sentence “we own the app” starts falling apart. The company may own the computer the developer used while the repository lives inside a personal GitHub account. It may pay the hosting bill while an outside contractor controls the cloud tenant. It may possess a copy of the code without controlling the production deployment, or control the source while someone else owns the domain, API account, OAuth application, signing certificate, model-provider account or database underneath it.
The business may even possess all of those things and still have unanswered intellectual-property questions. Ownership in an enterprise AI project is a collection of rights and controls, not a checkbox.
Some of those assets may be owned outright, some licensed, some governed by open-source or third-party terms, and some controlled primarily because the original builder still has access to an account the company does not.
That is why the intellectual-property discussion is worth having before an internal experiment quietly becomes strategically important. Under U.S. copyright law, work created by an employee within the scope of employment can qualify as a work made for hire. Independent-contractor work requires more care; simply paying someone to build custom software does not automatically resolve ownership. Where copyright ownership needs to be transferred, 17 U.S.C. § 204 generally requires a signed writing.
The practical lesson for the executive is easier than the law: if an outside builder is creating something the enterprise may depend on, get the rights, access and turnover expectations clear while everyone still likes each other.
The agreement and operating model should make clear what newly created code the enterprise owns, which pre-existing or licensed components the builder brought into the project, whether another developer can modify and operate it, what happens to confidential information when the engagement ends, and whether repositories, documentation, credentials and deployment artifacts are part of the turnover requirement.
An innovation project becomes materially less innovative when the enterprise discovers its continuity depends on negotiating with the person who just left.
Then we add AI-assisted development.
An employee may direct a coding agent that creates substantial portions of the implementation. A contractor may use another model. An agency may bring existing components. The final application may contain human-written code, AI-assisted revisions, generated code, open-source packages, vendor SDKs, configuration files and proprietary business logic sitting beside one another in the same repository.
Calling all of that “AI-generated code” does not answer much.
The U.S. Copyright Office addressed generative-AI copyrightability directly in its 2025 report. Its conclusion was not that using AI destroys copyright protection. Human-created expressive contributions can remain protectable, and human selection, arrangement or modification may support protection depending on the facts. But the Office also concluded that merely providing prompts does not, by itself, establish the human authorship required for copyright protection over purely generated output.
The Copyright Office’s AI work is another reminder that the organization should not assume every right traditionally associated with software magically attaches in the same way merely because an employee typed the prompt on company time.
Copyright is only one layer. Contract rights, open-source licenses, API terms, confidentiality, trade secrets, third-party dependencies and the business’s practical ability to continue operating the application all matter as well.
What exactly did we just put into the company… and do we have the rights and control required to keep using it?
That is a considerably better executive question than trying to determine whether the AI deserves a spot on the engineering org chart.
The visible application is rarely the whole application. Modern software is assembled from layers of other software, and intelligent development environments make that assembly extraordinarily fast. A builder asks the coding agent to add authentication, a database, PDF parsing, browser capability, analytics, a vector store, model SDKs and social integration, and twenty minutes later the feature works beautifully. The builder may never have consciously selected many of the components now sitting underneath it.
This is not uniquely an AI problem. Modern software development has depended on third-party and open-source components for years. AI simply makes it easier to add dependencies faster than humans build awareness of them.
NIST describes a Software Bill of Materials, or SBOM, as a formal record of the components and supply-chain relationships used to build software—essentially an ingredient list. That concept is useful even for organizations nowhere near a federal software procurement.
A company materially depending on an application should increasingly understand which packages and versions are present, which open-source licenses apply, which external APIs and model providers the system relies on, where data is hosted, which authentication and automation services are involved, whether those dependencies remain supported, and whether another component could replace one that changes its pricing, terms or API tomorrow.
An internal prototype may not need a formal enterprise SBOM on the day it is created. But an enterprise that materially depends on software should have increasing visibility into what the software materially depends on.
You inherit more than the capability of the dependencies inside your AI project… you inherit part of their lifecycle risk too.
Technical debt used to have the courtesy to accumulate gradually.
AI has made major improvements in this area.
A coding agent can produce an enormous amount of functional software quickly, and functional is a wonderfully seductive word. The button works, the database returns the answer, the agent performs the task and the API connects. Everyone watching the demo sees a successful result.
Underneath that success may be duplicated logic, unnecessary complexity, hard-coded assumptions, packages the system no longer needs, weak error handling, inconsistent data models, tightly coupled integrations, minimal test coverage and architectural decisions that made perfect sense three hundred prompts ago but nobody remembers making.
This does not mean AI creates bad software. Humans have been producing unmaintainable software with remarkable consistency for decades.
The difference is the marginal cost of producing more of it. When generating another function is easier than understanding the existing one, organizations can accumulate complexity faster than they accumulate comprehension. That turns AI-assisted technical debt into an executive continuity issue rather than merely a developer preference.
The pain usually appears later, when the CRM changes, the dealer group acquires ten stores, the OEM modifies a requirement, the model provider changes an API, a dependency is deprecated, a security vulnerability appears or somebody asks the application to do one slightly different thing and discovers that the architecture was built around an assumption nobody documented.
NIST’s Secure Software Development Framework treats secure development as a lifecycle discipline rather than treating successful deployment as the finish line. That framework was not written for vibe coding, but the principle fits it extremely well.
Shipping quickly and understanding what was shipped need to remain on speaking terms.
Fast code is an advantage. Fast code nobody can safely change is delayed expense.
This is probably the simplest executive test in the article. Take an important internal AI project and imagine the person who built it is unavailable Monday morning—not hostile, not withholding information, just unavailable. Could another competent operator take over using only the assets, accounts and knowledge the enterprise actually controls?
If the answer to several of those questions is Kyle knows…, Kyle is still part of the architecture.
The same principle applies when Kyle is a consultant, agency developer, vendor or startup founder. The company’s important application should not exist because one employee’s personal GitHub account exists. The cloud tenant should not disappear when the agency relationship does. The model API should not stop working because a developer’s credit card expired. Multi-factor authentication for an enterprise production system should not terminate on the phone of somebody who left three weeks ago.
This has very little to do with distrust and everything to do with making the business capable of ordinary change. As a project becomes important, the control plane should increasingly belong to the enterprise: repositories, cloud accounts, billing relationships, domains, credentials, deployment infrastructure, logging, recovery mechanisms and the authority to grant or revoke access.
The person should have access to the project. The project should not belong to the person’s access.
Offboarding changes too. Disabling someone’s Microsoft account may remove them from email without removing a production API key, transferring a repository, rotating a secret embedded in an automation, changing the administrator on a database or identifying a scheduled workflow still communicating with customers every morning. Modern builder offboarding increasingly has to account for the systems, agents, codebases, credentials, integrations and third-party services the person created or controlled.
Because the builder can leave. Their automations usually do not have the same HR paperwork.
The most expensive long-term failure mode may not be one badly documented project. It may be allowing every project to develop a separate understanding of the enterprise.
One developer creates a dealership profile inside an agent while an agency creates another operating brief, a marketer builds custom instructions in a different model, another employee creates an inventory knowledge base and a consultant separately encodes OEM rules and dealership taxonomy. Every project may be useful, while together they create an organization with extraordinary amounts of intelligence and remarkably little organizational intelligence.
When the employee leaves, some knowledge leaves with the employee. When the agency changes, another version disappears. When the model changes, teams rebuild context. When a new project begins, everybody starts teaching the dealership to another machine.
That is a terrible compounding strategy.
The more durable architecture separates the knowledge of the business from the temporary interface being used to work with it. This is one of the central reasons we have leaned so aggressively into interoperability through Hrizn MCP and Hrizn v6.
Dealer DNA, Brand Voice, staff context, IdeaCloud research, inventory, vehicle intelligence, market context, content, compliance and operating workflows can persist as a dealership intelligence layer while authorized builders work through different environments. Codex, Claude Code, Cursor, Google’s development environments, the agency, the developer and the application can all change without forcing the business underneath them to relearn itself every time.
That changes the bus-factor equation because the value created by a talented builder can compound into a shared operating environment instead of remaining trapped inside the application they happened to build. A useful research workflow can become reusable context, a new dealership insight can strengthen broader organizational knowledge, a compliance rule can support the next application, and the next builder can begin with more institutional understanding than the previous builder had.
Great enterprise architecture does not make the builder permanent. It makes the builder’s contribution durable.
That is a much better relationship between human creativity and software. Give talented people extraordinary leverage, let them build quickly, capture what they learn and institutionalize what proves useful. Make the business smarter because they were there… and keep the business smarter when they are not.
Then we can address the next permission. The data is governed, the application is transferable, the organization knows what it owns and the dependency chain is visible. The project survives Kyle. Excellent.
Now the agent wants permission to do something—to read a record, recommend an action, send the message, change the price, update the CRM, publish the content or execute the workflow.
Those are very different forms of authority.
Next: Your Agent Should Not Have the Nuclear Codes. →
Previous: Your CRM Is Not a Sandbox. →
Return to the series hub: The Permission to Build: AI Made Software Cheap. Leadership Still Owns the Consequences.
U.S. Copyright Office: Copyright and Artificial Intelligence →
The Copyright Office’s work on AI, human authorship and copyrightability.
17 U.S.C. § 101: Work Made for Hire →
The statutory definition governing employee-created works and the limited circumstances in which specially commissioned work can qualify as work made for hire.
17 U.S.C. § 204: Transfers of Copyright Ownership →
Federal copyright law’s written-instrument requirement for transfers of copyright ownership.
NIST: Software Bill of Materials →
Guidance on understanding the components and supply-chain relationships underlying software.
NIST Secure Software Development Framework →
A lifecycle framework for producing, maintaining and responding to software security risk.
Hrizn MCP →
Explore how dealership intelligence can remain attached to a governed operating environment while authorized builders work through different AI and development interfaces.
Great builders should leave an organization more capable than they found it—not more dependent on personal accounts, undocumented integrations, private prompts and institutional memory.
Hrizn v6 and Hrizn MCP create a durable intelligence layer beneath that work, keeping dealership identity, research, inventory, staff knowledge, market context, content, compliance and operating capabilities connected to the enterprise while builders and intelligent interfaces change around them.
Let people build quickly. Capture what they learn. Make every important contribution transferable.
Hrizn v6 helps dealership marketing teams move from fragmented activity toward a connected operating advantage—bringing intelligence, creation, human participation, distribution, proof and improvement into a more coherent system.
The goal of enterprise AI is turning great human ideas into governed capabilities that compound inside the organization long after the original builder, model or interface has changed.
We Rise Together.
