Everybody Is a Developer Now. Somebody Still Has to Be the Adult.

The Permission to Build · Article 1 · Everybody Is a Developer Now. Somebody Still Has to Be the Adult.

Somewhere in automotive right now, somebody who had never opened a terminal six months ago has API credentials to three systems, a working prototype on their laptop, and has started referring to their “agentic architecture.”

I love this.

Mostly.

There is something genuinely important happening underneath all the noise around vibe coding, coding agents, AI applications, autonomous workflows and whatever new development environment appeared while you were reading this sentence. The ability to create software is moving closer to the people who actually understand the problems software is supposed to solve.

A fixed-operations director who has spent twenty years watching the same service process fail can increasingly prototype a better version without first translating twenty years of operating scar tissue into a software requirements document. A dealership marketer who rebuilds the same report every Monday can ask an intelligent development environment to help remove the work entirely. An agency strategist can turn a good operating idea into a working application before the client meeting instead of presenting a mockup of what somebody might build someday. A dealer principal can test whether an idea deserves investment before turning it into a procurement exercise.

That is an extraordinary expansion of human capability, particularly in an industry where some of the people with the deepest understanding of the customer experience have historically had the least direct ability to change the technology supporting it. We should want more of this.

The complication is that the cost of creating software has collapsed much faster than the disciplines surrounding software have changed. A person can now move from idea to application before an organization has necessarily encountered the questions that used to arrive naturally with a conventional technology project: Who owns this? What data does it touch? Which credentials does it use? What happens if it fails? Who maintains it? What third parties are involved? Can it write back to production systems? Can another person operate it? How do we shut it down?

Historically, those questions often appeared because software was difficult and expensive enough to attract attention. AI removed a lot of that friction. It did not remove the consequences.

AI did not eliminate the difference between a prototype and a production system. It made it dramatically easier to cross that line without noticing.

That is the leadership problem at the center of this series.

Software Got Cheap. Consequences Didn’t.

For most of automotive technology history, building meaningful software required enough money, specialization, infrastructure and organizational coordination that development created its own friction. You needed engineers, environments, deployment and probably budget. Somebody eventually wanted a contract. Somebody wanted to know where the data was going. Somebody from IT asked why the application needed administrator access. Somebody in legal ruined lunch.

It was not an especially elegant governance system, but the cost and complexity of software development created checkpoints almost accidentally. Generative AI has changed that economic model. The same person who understands a dealership problem can now collaborate with a coding model, describe desired behavior conversationally, inspect working software, connect APIs, build a database, create an interface, automate a workflow and iterate against the result at extraordinary speed. Much of the translation layer between subject-matter expertise and technical execution is disappearing.

That matters far beyond productivity. The person who has watched customers stumble over a process for fifteen years may have a better idea for fixing it than the person who owns the product roadmap for the system creating the problem. The service advisor who explains the same confusing repair every day may understand the information architecture customers need better than anyone sitting in a corporate innovation lab. The regional operator reconciling six reports every morning understands exactly which questions the enterprise cannot currently answer. Those people suddenly have tools capable of turning operational understanding into executable ideas.

But some of the economic friction that disappeared was doing more than slowing development. It was giving organizations time to recognize when an idea had become consequential. Today the application can arrive before the governance meeting, the integration before procurement, the customer-data request before data classification, and the agent before anybody has decided whether the organization permits agents to act.

This is one reason the addition of a dedicated Govern function to the NIST Cybersecurity Framework 2.0 is so relevant to the current AI moment. NIST elevated governance to make the relationship between cybersecurity, enterprise risk, organizational responsibilities, policy, legal obligations and risk tolerance more explicit. NIST CSF 2.0 is not an AI-development manual, but its governance principle travels extremely well into this environment: once technology can create meaningful enterprise consequences, the associated risk stops being merely an implementation detail.

That does not mean the C-suite needs to review Python. It means somebody needs to know when the Python became infrastructure.

Vibe Coding Is the Opportunity

It would be easy to make “vibe coding” the villain here, and it would miss the point. At its best, vibe coding describes something legitimately transformative: people can focus more directly on the problem they are trying to solve while intelligent development tools absorb an increasing amount of the mechanical work required to express the solution in software.

For automotive, that dramatically expands the pool of potential innovators. The person building an application no longer has to begin as a professional software engineer. They can begin as a professional dealer operator who happens to know exactly why a process is broken… and that inversion matters.

Traditional software development frequently required the business expert to explain the problem to a product person, who explained it to a designer, who explained it to a developer, who translated it into software, which eventually returned to the business expert several months later so everyone could discover what had been lost in translation. AI compresses that loop, sometimes dramatically.

If a dealership employee can build a working prototype in an afternoon and discover immediately that the idea does not work, the company may have just saved six months and $100,000. If the idea does work, the organization has gained something equally valuable: evidence. That is exactly what prototypes should do. They should let ideas encounter reality at low cost and low operational risk.

We should therefore be careful not to respond to the risks of democratized software creation by rebuilding all the barriers AI just removed. Requiring every experiment to survive enterprise procurement, legal review, formal architecture, security certification and executive approval before anyone can learn whether the underlying idea has value would be an excellent way to make innovation expensive again.

The better answer is to preserve a generous experimentation environment while becoming much clearer about what happens when the experiment begins asking the enterprise for additional authority.

Vibe coding is an extraordinary way to discover what might be possible. The enterprise still has to decide what becomes trustworthy enough to depend on.

The Moment the Prototype Becomes Something Else

Imagine a dealership marketing director builds a small inventory application. The original idea is simple: the tool looks at sample inventory records and identifies vehicles that may deserve more merchandising attention based on age, model, content coverage and local market conditions. The first version runs locally against synthetic data, which is exactly where a cheap experiment should begin. The employee can throw away bad ideas, change the architecture, ask the model dumb questions, break the application, start over and learn something useful before dinner.

The prototype works, so the employee wants live inventory. Still reasonable. The project moves from synthetic information to a production data source, perhaps through a narrowly scoped read-only connection. Then the application improves and someone realizes it could make better recommendations if it understood campaign performance and selected CRM signals. The code may not look materially more impressive, but the data conversation has changed.

Next somebody wants the application to create merchandising content automatically, then publish it, then adjust campaign behavior based on performance. A regional leader sees the result and wants the capability across fifty rooftops. Every individual step may be rational, useful and even well designed.

At some point during that sequence, however, the little application stopped being an employee experiment and became organizational infrastructure. There was no dramatic ceremony, no ribbon cutting and no enterprise software agreement arriving by courier. The program simply accumulated enough data, users, permissions, actions and organizational dependency that the consequences became larger than the original idea.

This is the transition executives need to become good at recognizing and evaluating. A prototype asks whether an idea can work. Production asks whether the idea can work repeatedly, safely, securely, legally, observably, maintainably and inside the organization’s accepted level of risk. That distinction does not require a 400-item checklist on day one. It requires the organization to notice when the project changes categories.

The code may barely change while the enterprise consequences change completely.

Governance should therefore follow consequence rather than novelty. A two-hour experiment using synthetic information does not deserve the same controls as an autonomous workflow touching customer records across 150 rooftops, and the second project should not inherit the casual operating assumptions of the first simply because they happen to share a repository.

Shadow IT Just Learned to Code

None of this is entirely new. Large organizations have always had shadow technology. The operating system of corporate America is still, in many places, a spreadsheet created by someone named Susan in 2017 that nobody is allowed to delete because three departments quietly depend on column G.

Employees route around official infrastructure when official infrastructure does not help them do the work. They adopt an unapproved SaaS product because the approved system cannot solve the problem, create a spreadsheet because the reporting stack is too slow, build an unofficial database because no sanctioned system contains the information in a usable form, or text customers because the official communication workflow requires seven screens and a blood oath.

Shadow IT frequently tells leadership something important: the sanctioned path is failing. AI changes what happens after the employee decides to route around it.

Yesterday’s workaround may have been a spreadsheet. Today’s workaround can be a spreadsheet feeding an LLM, database, agent, CRM update, customer communication and scheduled automation that nobody else knew existed.

The employee may have had an excellent idea and the workflow may produce real value. The architecture may also have quietly created several new places where business information lives, new credentials nobody centrally manages, a service-provider relationship nobody reviewed and an operational process nobody knows how to stop.

We should resist the temptation to blame the builder for noticing a problem and using the available tools to fix it. The more useful executive question is why the governed enterprise path made the unsafe path easier. That changes the governance conversation substantially.

CISA’s Guidelines for Secure AI System Development, developed with the UK National Cyber Security Centre and international partners, place secure-by-design thinking throughout AI system design, development, deployment and operation. That lifecycle framing matters because security cannot be the department that appears after the application is finished and asks whether the architecture can somehow be made acceptable. By then, the data flows, dependencies, credentials, permissions, model providers and autonomous capabilities may already be embedded into the design.

The cheaper time to question production write access is before an agent is built around it. The cheaper time to ask whether real customer data is necessary is before that data has been copied into several development environments. The cheaper time to establish an enterprise-controlled repository is before forty stores depend on code living in someone’s personal account.

Secure by design is therefore more than a cybersecurity principle in the AI era. It is an economic one.

Governance Is Now an Operating-Design Problem

This leads to an uncomfortable conclusion for enterprise technology leaders: if the safe path is dramatically harder than the unsafe path, writing a stronger policy may not solve the problem. People will continue using the path that allows them to get useful work done with less resistance, which means governance increasingly has to behave like product design.

An organization that wants people to build should make approved development environments easy to access, provide enterprise identities and clear places for company code, distinguish approved model environments in language employees can understand, classify data in ways operators can actually use, and expose useful business capabilities through secure interfaces. Read-only access should be easier to obtain than unrestricted credentials. Testing environments should exist. The move from experiment to production should be visible. The standards should become more demanding as the consequences become more material.

This is where a permission model becomes more useful than a prohibition model. Let an employee explore an idea using public, synthetic or approved non-sensitive context with very little friction. When the idea needs live enterprise information, bring in the data owner and appropriate access controls. When the application becomes operationally important, move its code, accounts, credentials, documentation, dependencies and support responsibility into enterprise control. When it gains the power to publish, communicate, update records, change pricing or otherwise create external consequences, evaluate the authority attached to those actions. When leadership wants to scale it, require the deeper evidence that the application can actually sustain that responsibility.

The quality bar should rise with the blast radius.

That approach preserves the inexpensive experimentation AI has unlocked without pretending every idea deserves the same authority on the day it is created. The person with the insight can begin tonight. The enterprise simply needs to recognize when “I built something useful” starts becoming “customers and the business now depend on this.”

Give Builders a Better Road

The biggest opportunity here is cultural. Automotive should not emerge from the AI revolution with a smaller group of people authorized to create. It should emerge with a dramatically larger one. Let operators build, let agencies experiment, let dealership employees turn local expertise into useful applications, and let developers use Codex, Claude Code, Cursor, Google development environments and whatever better tools arrive next. Let your most talented people move outrageously fast.

Then stop forcing each of those talented people to rebuild the enterprise underneath the idea. A builder should not need to invent another dealership profile because reusable context does not exist, request another CRM export because there is no governed way to ask the business a question, create another copy of inventory because existing intelligence cannot travel, or separately recreate authentication, OEM compliance, Brand Voice and organizational knowledge inside every new project.

Every time an enterprise forces a builder to reproduce those foundations, it increases development effort while recreating risk. That is why interoperability is becoming much more consequential than the ability to connect one application to another. The larger opportunity is a governed intelligence layer beneath the applications: organizational context that can persist while interfaces change, permissions that can be managed without burying authority inside individual scripts, and knowledge that can compound instead of being copied.

This is a central architectural conviction behind Hrizn MCP and the broader interoperability work in Hrizn v6. Dealer DNA, Brand Voice, staff context, IdeaCloud research, inventory, vehicle intelligence, market context, content, compliance and connected workflows can become part of a durable dealership intelligence layer. Authorized people and intelligent development environments can work with that shared context without requiring the dealership to become a different dealership inside every new AI client.

The development environment, model, agency or builder can change without forcing the business underneath them to begin again. The objective is an enterprise that becomes smarter each time somebody contributes rather than an enterprise that accumulates isolated islands of intelligence every time somebody discovers a new tool.

The fastest way to slow enterprise AI innovation is to make every new idea invent its own security model, data layer, permissions and organizational memory.

Give builders the road and make that road easier to use than the shortcut through the field. Because everybody becoming a developer may turn out to be one of the best things to happen to automotive technology in decades.

The executive job is not deciding who gets to have ideas. It is creating an environment where a good idea can move from someone’s laptop into durable enterprise capability without the organization losing track of the data, authority, ownership, customer impact and responsibility it acquired along the way.

That is the permission to build. The first permission after building is access, which brings us to a system containing considerably more than most experimental applications should ever casually receive.

Your CRM.

Next: Your CRM Is Not a Sandbox. →

Return to the series hub: The Permission to Build: AI Made Software Cheap. Leadership Still Owns the Consequences.