Vibe Coding "It was built by Bob"

The following article will be part of a 5 part LinkedIn thought leadership series "the vibe coding revolution"

Vibe Coding: The Agile Innovation Revolution we have to Govern

Anyone can build software now, also the knowledge workers in companies have been adapted this. Should everyone in a company be allowed to deploy something they have build. And what are the risks we are facing?

Something fundamental is changing in the way organizations create software. With AI coding assistants and what is increasingly called vibe coding, the barrier to creating software has dropped dramatically.

You simply describe what you want, let AI generate te code, refine it through conversation, and within hours, sometimes even in minutes you have something that actually works.

That is powerful and also potentially incredible dangerous, not because vibe coding is bad but because our ability to create software is evolving much faster than our ability to govern it.

Today someone in HR, Finance, Operations even the managers or ceo's can potentially create an application themselves. And ofcourse that is fantastic until the application becomes important and requires support.

A vibe coded application can work beautifully, solves a problem, save someone hours every week, make a team significantly more productive and still be completely unsuitable for production. Why? Because functionality is only one dimension of a product. There are more.

• Security

• Data Protection

• Architecture

• Scalability

• Maintainabiltiy

• Support

• Monitoring

• Business Continuity

• Compliance

• Technical Debt

And perhaps the most uncomfortable question: What happens when te person wo created the solution leaves the company?

As an Agile coach I have worked with many software and hardware teams. With Vibe Coding something new is introduced "Shadow WIP" Normally we monitor the Work in Progress to check all the work related to alll initiatives and projects in an organization. With Vibe Coding software solutions are being built that nobody considers as a project anymore. Nobody has put it on the portfolio or roadmap, nobody has prioritized it, nobody assigned capacity to maintain it, nobody has assessed its risks. Yet people depend on it.

Imagine an organization where Human Resources builds there own recruitment tool, Project planning builds a planning application, Finance builds a reporting automation, Operations creates an AI agent, a manager builds a dashboard and team creates an integration between two of these solutions. Individually every initiative may look sensible. Did we just create collectively an entirely new technology landscape without designing one?

When looking at Agile organisations an interesting paradox is created. Agile encourages us to Experiment, Learn quickly, Reduce Feedback cycles, Empower teams, Deliver Value. What is very interesting is that Vibe Coding enables exactly that. So why should we restrict it? Trying to prohibit vibe coding will probably create something even worse called Shadow IT 2.0. People will continue creating solutions, They will simply stop telling IT, Security and Management about what kind of solutions they have created. The answer isn't more bureaucracy but should be more and better guardrails.

Then there is the ITIL approach where the main question will be "Who is going to operate this and support this" The question is not Can we build it? The question here is Can we responsibly operate it? For Every Solution that becomes important for an organisation Who owns it?, Wo Supports it? Who approves Changes, Where is it documented? What data does it process? What happens when the solution fails? How is it monitored, How is it secured, How is it recovered, When will it be retired (software lifecycle)? Those questions are not to raise bureacracy but are about responsibility and resilence. And I even not adressed security and governance .

The Security part, this is actually the part where the conversation becomes even more serious. AI can generate code incredibly quickly where it does not say AI generated code is automatically secure code. The creator who created the solution might unintentionally introduce insecure authentication, incorrect authorization, exposed secrets, vulnerable dependencies, use insecure API's, poor data protection, weak logging, etc etc. Potentially AI coding agents can interact with files, repositories, development environments and infrastructure. The risk that is being introduced is "what is the AI allowed to access, change and execute?". That is a fundamentally different governance question.

I believe organisations should avoid 2 extremes.

Extreme 1: No Governance. "Everybody can build whatever they want." This creates chaos .

Extreme 2: Centralized Control "Nothing can be built whithout going trough IT" This kills innovation

There is a third option. RISK based Governance. The governance required should depend on the impact of the solution, not simply on how it is created.

You could think about the following levels

• Personal Experiment: minimal governance required

• Team Tool: Governance (team ownership + basic controls)

• Shared Solution: Used by multiple teams. Governance (Architecture en security review)

• Business Services: Support a critical business process : Formal Governance required + ITIL

• Critical Services: Customer, financial or operationally critical: Full DevSecOps+ ITIL+Security

A guardrail system like this gives people freedom to experiment while creating expectations when something becomes important.

Whe should be aware that we democratise software creation. Also we should not democratise operational risk without appropriate controls. The process could be:

Idea > Experiment > Validate > Product > Service

And governance should increase as we go along this path.

Agile organisations coud also rethink the definition of done.

A production ready solution should have at minimum:

• BUSINESS: Clear Purpose, Business Owner, Defined Users, Clear Value

• ARCHITECTURE: Known dependencies, Appropriate integration, No Unnecessary duplication

• SECURITY: Authentication, Authorization, Secrets Management, Vulnerabilty scanning, Dependency scanning, data classification

• OPERATIONS: Support ownership, Monitoring, Logging, Backup/Recovery, Documentation

• ITIL: Service Ownership, Change Approach, Incident/Support model, Lifecycle management

• AGILE: Product Backlog, Priotisation, Technical debt visibility, Continous improvement

Design the AI assisted development model:

Let people experiment while introducing guardrails around: Data, Security, Access, Integration, Business criticality, Operational impact, Compliance, Customer impact.

The Governance conversation should be not "Are you allowed to build this? " The question should be "What happens if this becomes important?" That is much more an Agile approached question.

I believe organisations now have an opportunity to create something much better than traditional IT governance. The model that is being created is a model where anyone can create, everything important is visible, every important solution should have an owner and governance is proportional to risk, security is built in, and lifecycle of the solutions is explicit and transparent available based on the following rule:

Create>Experiment>Validate<Operate>Improve>Retire

Leadership in organisations should be organised so there is freedom to create, responisility to scale. Maybe even more explicit : Anyone can build, Not everyone should operate.

Vibe Coding is not the enemy of Agile, ITIL or DevSecOps. Quite the opposite. It could become one of the biggest accelerators of Agile ways of working we have seen. But only if we evolve our thinking about governance at the same time. Because the future isn't going to be about controlling who can create software. It will be more about creating the environment where people can innovate safely, quickly and responsibly. And that, to me, is exactly what modern Agile, ITIL and DevSecOps should be about. Not controlling people.

Make people great and give them the guardrails to succeed.