The Rise of Vibe Coding: Is AI changing who gets to build?

The first episode of The One About AI opens with the topic that walks through Old.St Labs' door more than any other: vibe coding. Rob Woodhead is joined by co-founder Rob Lynch and Technical Consultant Ben Burch to work out what the term actually means, why it stopped meaning what Andrej Karpathy meant when he coined it in February 2025, and what happens when someone arrives with a working product they built for the price of a monthly subscription. The conversation is deliberately jargon free. It covers the difference between a developer using AI and a layperson using AI, why the barrier to a first version has collapsed while the barrier to a finished one has not, and where a software agency adds value once writing code stops being the expensive part.

Key takeaways

• Vibe coding originally described developers letting an AI assistant write code they stopped closely reading. It now usually means non-developers building software they could not read even if they opened it.
• The tooling is an extension of decades of developer convenience, from IDE autocomplete to imported packages, rather than a clean break from it.
• A developer using AI and a layperson using AI are in fundamentally different positions, whatever either activity gets called.
• The real shift is upstream: the requirement now goes straight from the person who wants the thing into a working prototype, skipping the translation layer the industry spent years building.
• Barriers to a first version keep falling, but the gap between a prototype and a production system is unchanged, which is why a $20 build turns into a five figure conversation.
• Vibe-coded products can ship when they are simple and the data is not sensitive. Security, scale and maintainability are where most of them stop.
• Technical debt has not changed shape, it has compressed. What used to accumulate over a year can now accumulate in an afternoon, and so can the refactor.
• As the cost of producing code falls, the value moves to understanding the business problem, which is where agencies either survive or do not.

Episode chapters

• 00:00 Introducing The One About AI
• 01:32 Rob Lynch on co-founding Old.St Labs
• 02:02 Ben Burch on technology and operations
• 03:04 What vibe coding originally meant
• 04:52 Why the output is so alluring
• 05:20 From autocomplete to whole applications
• 06:16 The gap between developers and everyone else
• 08:03 Vibe coding versus AI-assisted coding
• 09:38 The requirement problem the industry never solved
• 10:56 Who is turning up with a prototype now
• 13:29 The $20 to $10,000 conversation
• 15:09 Which products can actually go to market
• 17:15 Technical debt at speed
• 19:44 Where does this go next
• 21:55 Why the next model generation matters
• 24:32 What a software agency is actually for
• 26:24 The unknown unknowns worth being excited about

What does vibe coding actually mean?

The term is barely more than a year old. Rob Lynch traces it to February 2025 and Andrej Karpathy, and to a narrower idea than the one in circulation now: a developer building with an AI assistant, someone who should be paying attention to the underlying code, who at some point stops and simply trusts the model to write it.

That is not how the phrase gets used today. Platforms like Lovable, Replit and Base44 have moved it to mean something broader and more consequential. It now tends to describe anyone building software, including people who would not understand the code if they opened it. Rob is positive about what that has unlocked. For the first time, people who are not developers can build close to exactly what they want without waiting on someone else to do it.

Is this new, or just a bigger autocomplete?

Ben's answer is that the direction of travel is old and the size of the jump is new.

Developers have always used tools. Autocomplete in the IDE, then libraries, modules and packages imported wholesale into a project. Nobody has written their own packages for years. On that reading, hands-off building is an evolution rather than an invention.

What has changed is the distance covered in one step. You type a prompt and instead of a line of code you get an output, and inside that leap a great deal happens without your knowledge. Ben's observation is that the interface is now genuinely excellent, and excellent interfaces are very good at hiding what is underneath.

Rob Lynch wants a sharper line drawn through the middle of it. A developer using an AI coding assistant, who fundamentally understands what the model is doing, is in a very different position to a layperson prompting the same tool. Call one vibe coding and the other AI-assisted coding or vibe engineering, the label does not matter much. What matters is whether anyone is reading the output. A developer who reads it can shepherd the model and stop it wandering, and the result is a velocity gain rather than a liability.

What changes when a client arrives with a working prototype?

Ben makes the point that gets missed in most vibe coding conversations. The industry's long-running challenge was never really the coding. It was translation: taking a business requirement and turning it into something a development team could action correctly. Enormous amounts of process exist to bridge that gap.

AI tooling does speed up parts of the build, but the structural change is upstream. The person who wants the thing can now express it directly, in their own terms, and get something that runs. Instead of a sketch on a napkin and a fairly ethereal idea of what it might do, a client can arrive with a working demonstration of exactly what they mean.

Rob Lynch says that is genuinely different from where projects used to start, at least on the entrepreneurial side. The prototype often still gets taken apart and rethought before it is built properly, but the starting base has moved. Established businesses are doing this far less so far, though Rob Woodhead notes hearing more of it anecdotally, including platforms designed to gateway vibe-coded products onto real company data.

For founders, the effect is on risk. Getting from napkin to something demonstrable used to cost real money. Now it can cost the price of a monthly subscription.

Why does a $20 prototype become a $10,000 problem?

Because the cheap part got cheaper and the expensive part did not move.

Rob Woodhead describes the conversation that follows, and it is an emotional one as much as a commercial one. Someone has spent twenty dollars and is holding something that works. Being told there is a problem they cannot see, and that fixing it properly costs several thousand, is a hard message to receive when you are not technical enough to verify it yourself.

Ben has watched this pattern before in a different costume. A few years ago the blocker was not code, it was hardware. You could not launch without buying servers and racks of equipment. Ten thousand pounds bought you a machine with nothing on it. Then infrastructure became something you switch on and pay for by the second, and the barrier fell.

Each time a barrier drops, the same problem survives it: you can get a long way very quickly, and the last stretch is still the last stretch. His view is that this fragments the market and makes it genuinely hard for buyers to navigate, because the price of the first 80% no longer tells you anything useful about the price of the rest.

That gap is exactly what our Vibe Code Audit is built to price. If something is most of the way there, the useful question is what the remainder will cost in security, scalability and maintenance.

Can a vibe-coded product actually go to market?

Sometimes, and Rob Lynch is clear that it depends entirely on what it is. If all you need is a basic MVP and the industry allows it, you can put something functional into production. He would still want someone to audit it first and check there are no howlers in it. The real question is what happens afterwards.

Rob Woodhead draws the line at data. Products that do not touch deep or sensitive data points can potentially go out. The majority cannot, because they need security around them and they need to scale, and most of these builds are not constructed for either.

There is also a compounding problem in how the code accumulates. Rob Lynch describes ending up with something bloated, full of obsolete code left behind by features that went in different directions. Every new feature means the model has to work with its own previous output, and if it has gone far enough down that road, getting a human in to unpick it is extremely tough.

Both hosts refer to unverified reports about app store review times slowing under the volume of AI-built submissions. Treat that as the anecdote it is presented as in the episode.

Is vibe-coded technical debt different from the normal kind?

Ben argues it is the same debt on a much shorter clock.

Build an application with a conventional software team and it moves through states, accumulating technical debt as it goes, until at some point you want to refactor. That cycle used to take a year. Now it can happen in an afternoon. The other difference is that you can simply say rewrite it, which carries a cost, but a different kind of cost to the one an engineering team would have quoted.

His conclusion is that vibe coding does not introduce new problems so much as surface the existing ones faster and with less visibility into the process while it happens.

Rob Lynch agrees the parallels are real but pushes back on the equivalence. A product vibe coded to the limit, which he has done himself, can end up genuinely unmaintainable. A team doing spec-driven development, running agents they understand, with the right amount of skilled human oversight, is somewhere else entirely. Rewriting in an afternoon may be a stretch for anything complicated, but that is where the real velocity gains sit.

Where does this leave software development agencies?

Rob Woodhead asks the question directly: does this eat our lunch?

Nobody on the call argues the pace will slow. Ben describes his own experience going from wanting to punch his screens during early attempts to building two internal applications recently with a fundamentally different experience, largely because he plans the work out rather than starting with a single prompt. He does not see how the next generation of models fails to push this much further, and notes that the open questions are commercial ones about who carries the risk and who stands behind the warranty.

Rob Lynch agrees, and adds that improvement is arriving at three levels simultaneously: the underlying models, the products built on top of them, and the human practices around both, including spec-driven development and agent skills. The compound effect is that more ambitious projects become possible, not just the same projects faster.

On the agency question, his answer is that pure code production is a difficult business model to defend over a five year horizon. What holds is understanding a client's business and solving the actual problem rather than turning out code. Ben frames it as a value shift rather than a value loss. Any task where a human is effectively working like a computer gets cheaper. Understanding a business, drawing on experience across projects and turning that into something real does not, because the people running those businesses do not have the time to do it themselves. He is realistic that the transition will be messy rather than smooth.

Rob Lynch's closing note is the optimistic one. Every previous unlock, cloud and APIs among them, did more than compress timelines. It opened up categories of product that were not previously possible, and the unknown unknowns of this one are worth being excited about. You can see how we approach AI software development across client projects.

About the guests

Rob Lynch is a co-founder of Old.St Labs. He founded a startup in 2016 and started Old.St Labs with Rob Woodhead in 2020. His focus is staying on top of developments in AI and helping clients navigate them.

Ben Burch is Technical Consultant at Old.St Labs, working across the technical aspects of client projects. His career spans multiple industries, consistently on the technology and operations side, with an emphasis on implementation rather than theory.

About the host

Rob Woodhead is a co-founder of Old.St Labs, a London-based AI software development agency building web and mobile products for startups and scale-ups. He hosts The One About AI alongside Rob Lynch.

Frequently asked questions

What is vibe coding?

Vibe coding describes building software by prompting an AI rather than writing the code yourself. Rob Lynch notes the term was coined by Andrej Karpathy in February 2025 to describe developers who stopped closely reading AI-generated output. It is now used more broadly for non-developers building on platforms like Lovable and Replit.

What is the difference between vibe coding and AI-assisted coding?

Rob Lynch draws the distinction by who is reading the code. A developer using an AI assistant understands what the model is producing and can correct it. A layperson prompting the same tool cannot. The activity looks similar and the risk profile is not.

Can you launch a vibe-coded app?

Sometimes. Rob Lynch says a basic MVP with no sensitive data can go into production, ideally after an audit. Rob Woodhead adds that most products need security and scalability that vibe-coded builds do not typically have.

Does vibe coding create technical debt?

Ben Burch argues it creates the same technical debt as conventional development, compressed into a much shorter timeframe and with less visibility into the process. What accumulated over a year can now accumulate in an afternoon.

Will AI replace software development agencies?

Rob Lynch thinks agencies that only produce code will struggle within about five years, while those that understand the client's business will not. Ben Burch describes it as a shift in where the value sits rather than a removal of it.

‍