Vibe coding is coming for your delivery pipeline

Non-technical people are building working software in an afternoon now. Not prototypes. Not mockups. Functional applications, databases and authentication included, assembled by talking to an AI tool.

The takes I keep seeing fall into two camps. Either this is going to replace developers, or the code quality is so bad it will never matter. Understandable reactions. Wrong diagnosis.

Here's what I think the real problem is.

Delivery frameworks assume that only developers can build software. That assumption is baked into everything: how you estimate work, how you run sprints, how you staff a team, what your backlog even looks like. When that assumption breaks, the framework breaks with it.

It starts quietly. A product manager builds a working prototype over the weekend to unblock a decision. A business analyst creates a small internal tool because the ticket was deprioritised for the fourth time. A senior leader commissions something from an AI tool and shares it with the team before anyone in IT knows it exists.

None of those people did anything wrong. They solved a real problem at real speed. But the output is now running somewhere, owned by no one, invisible to every governance function in the organisation.

That's the unsupported prototype graveyard. Every large organisation has one, growing quietly in shared drives and personal accounts. Vibe coding doesn't create the conditions for it. It just makes the graveyard grow faster.

Then there's the estimation problem. When business owners and analysts start building in parallel with development teams, sprint velocity stops meaning what it used to. Capacity planning, resource allocation — all of it sits on the premise that software delivery is a scarce resource. When it stops being scarce, the numbers stop being meaningful.

Sounds like a good problem to have. In practice it's where the confusion starts.

The third thing nobody talks about is what "done" actually means. Vibe coded applications look done. They work, in a demo, on a laptop, for the use case that was tested. What they don't have is security review, accessibility compliance, monitoring, integration with your identity provider, disaster recovery, or a support model. The surface area of production-ready software doesn't shrink just because the build was fast.

Not evidence that vibe coding doesn't work. Evidence that "done" means something different inside a regulated organisation than it does in a weekend project.

The organisations moving well here aren't banning the tools. They're building intake. What's the fast-track path from "something that works" to "something we can support"? Who decides when a vibe-coded prototype crosses the line from personal productivity tool into something that needs AI governance review, an operating model, and a funding conversation?

In most large organisations, that question doesn't have a clean answer yet. What exists is a process built for a different era: formal AI approvals, region-specific governance gates, a productionisation model that assumes the hard work of building is what took the time. When the build takes an afternoon, the process around it doesn't shrink accordingly.

That's the actual challenge. Not whether non-technical people should be building. Not whether the code is good enough. Whether your delivery framework can absorb an input it was never designed for.

Most organisations are still working that out. The ones that get ahead of it will move faster. The ones that don't will have a very large, very unsupported graveyard.

---

These are my personal views and do not reflect the position of my employer or any organisation I am affiliated with.