VIBE CODING: "Bob Created SHADOW WIP"
Shadow WIP: The Agile "Vibe Coding" Problem Nobody Sees Coming
This article is nr 2 of 5 about Vibe Coding, the relationship with the organizational governance and the Agile Mindset.
We talk a lot about Work in Progress.
Too many projects.
Too many priorities.
Too many initiatives.
Too many things started and not finished.
Agile has taught us that excessive WIP destroys flow. But I think we're about to encounter a new form of WIP.
One that most organisations aren't even measuring is "Shadow WIP".
Imagine this.
Someone in Finance creates a small reporting application using AI.
Someone in HR creates an onboarding tool.
A team in Operations creates an automation.
Another department in the organization creates a planning dashboard.
A manager creates an AI assistant.
Another team creates an integration between two of these solutions.
Nobody calls them projects and ???? where is the funding?.
Nobody puts them on the portfolio.
Nobody asks for capacity.
Nobody asks for architectural alignment.
Because:
"It's just something I built."
But now (or at a certain moment) people depend on it. Congratulations.
You have just created another piece of organisational technology.
The democratisation of software is fantastic
I don't want to stop this.
Quite the opposite.
This is one of the most exciting opportunities AI gives organisations.
People closest to the problem can experiment directly.
They don't have to write a 30-page business case.
They don't have to wait six months for development capacity.
They can create something.
Show it. Learn from it. Improve it.
That's Agile thinking within the current AI area.
But there is a difference between creating something and creating something the organisation depends upon.
And that difference matters.
Local optimisation becomes organisational complexity
Every team can make a perfectly rational decision.
But when every team optimises locally, the organisation can become globally inefficient.
Team A creates solution A.
Team B creates solution B.
Both solve similar problems.
Both contain different data models.
Both have different owners.
Both have different security mechanisms.
Both have different integrations.
And eventually someone asks:
"Why do we have five systems doing essentially the same thing?"
Nobody deliberately created the complexity.
It emerged.
This is where Agile thinking matters
Agile isn't:
"Let every team do whatever they want."
Agile is about optimising the flow of value through the entire system.
That means we need visibility.
We need to know:
What are we building?
Why are we building it?
Who benefits?
Who owns it?
What does it depend on?
What does it replace?
What happens if we stop maintaining it and who is maintaining and support it now?
I would introduce an "Internal Solutions Portfolio"
Not just a project portfolio.
A portfolio containing:
Projects
Products
Automations
AI Agents
Vibe-Coded Applications
Process Improvements
Now leadership can see the whole picture. And something fascinating happens.
You can start asking:
"Where are we investing our organisational energy?"
Not just money.
Energy.
Attention.
People.
Complexity.
The goal isn't more governance
The goal is more transparency.
There's a big difference.
I don't want someone to ask permission before creating a prototype.
I want the organisation to know when that prototype becomes something people depend upon.
That's the moment governance needs to appear and step in.
From Shadow WIP to Visible Flow
I'd use a simple lifecycle:
IDEA - Anyone can propose.
↓
EXPERIMENT - Build quickly.
↓
VALIDATE - Does it actually create value?
↓
SCALE - Is it becoming important?
↓
SERVICE - Can we operate it responsibly?
↓
RETIRE - When it no longer creates value, remove it.
And yes...
"Retire" is an important step.
Because the easiest thing in the world is to create another application.
The hardest thing is sometimes admitting:
We don't need this anymore.
Vibe coding could potentially create thousands of small solutions inside organisations.
Our ability to create is becoming almost unlimited.
Our organisational capacity to maintain them isn't.
That's why WIP limits may soon need to apply not only to projects—but to technology itself.
The question isn't how fast we can build.
The question is how much complexity our organisation can sustainably carry.
#Agile #WIP #VibeCoding #AI #AgileTransformation #DigitalTransformation #Leadership #ProductManagement #Governance
