Vibe Coding Is The WORST IDEA Of 2025
Duration
17:10
Captions
1
Language
EN
Published
Aug 13, 2025
Description
Vibe coding might sound trendy, but in this video Dave Farley explains why vibe coding is one of the worst ideas in software engineering and software development in 2025. Discover what vibe coding really is, why it fails in real-world projects, and how relying on AI coding tools without proper engineering practices can lead to disaster. If you care about writing better code, improving your programming skills, and avoiding costly mistakes, you need to hear this. - ❗ Get 30% Off ALL Of Dave's BDD and Acceptance Testing Courses THIS WEEK ONLY ❗ Choose the course that's right for you, and use this code at checkout: at-bdd-j8x3k2 Find out more about the courses available HERE ➡️ https://courses.cd.training/pages/acceptance-testing - Dave on X ➡️ https://x.com/davefarley77 Dave on LinkedIn ➡️ https://www.linkedin.com/in/dave-farley-a67927/ Dave on bluesky ➡️ https://bsky.app/profile/davefarley77.bsky.social Modern Software Engineering on X ➡️ https://x.com/ModernSoftwareX Modern Software Engineering on LinkedIn ➡️ https://www.linkedin.com/company/modern-software-engineering Modern Software Engineering on bluesky ➡️ https://bsky.app/profile/modernswe.bsky.social - ⭐ PATREON: Join the Continuous Delivery community and access extra perks & content! ➡️ https://bit.ly/ContinuousDeliveryPatreon 🎥 Join Us On TikTok ➡️ https://www.tiktok.com/@modern.s.engineering - CHANNEL SPONSORS: Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ https://bit.ly/3ASy8n0 TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ https://transficc.com - 👕 T-SHIRTS: A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts! 🔗 Check out their collection HERE: ➡️ https://bit.ly/3Uby9iA 🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery - BOOKS: 📖 Dave’s Book "Modern Software Engineering" is available as paperback, or kindle here ➡️ https://amzn.to/3DwdwT3 and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible. 📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ https://amzn.to/2WxRYmx 📖 "Continuous Delivery Pipelines" by Dave Farley Paperback ➡️ https://amzn.to/3gIULlA ebook version ➡️ https://leanpub.com/cd-pipelines 📖 "The Software Developers’ Guidebook Amazon ➡️ https://amzn.to/4f9ozFK ebook version ➡️ https://leanpub.com/softwaredevelopersguidebook NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you. - #vibecoding #aicoding #aidevelopment #softwareengineering #softwaredevelopment #programming
Captions (1)
On February the 2nd this year, Andre
Karpathy, an OpenAI founder and formerly
head of AI at Tesla, introduced a new
term for a style of programming with AI
assistance. He called it vibe coding.
Now, I'm no stranger to the ideas of too
long didn't read and semantic diffusion,
but I think that this might have been
some kind of record. This was a thousand
character tweet, and it seemed that few
people even got to the second half.
Andre describes what he means by vibe
coding in the first 300 or so characters
of a thousand character tweet. The rest
describes some of the consequences of
this naive toy town approach to
programming. Now, I don't know Andre
personally, so I can't tell what he had
in mind with his tweet, but it reads to
me as sarcasm. Near the end of the
tweet, he says, "It's not too bad for
throwaway weekend projects, but it's not
really coding. I just see stuff, say
stuff, run stuff, and copy and paste
stuff, and mostly it works." So, I think
that Vibe coding is at least up for the
prize of the worst software idea of the
year so far. Nevertheless, it seems to
have gone viral and now is a well-known
phrase in our domain. And so, that's our
topic for today.
Hi, I'm Dave Farley and welcome to the
modern software engineering channel. If
you haven't been here before, please do
hit subscribe and if you enjoy the
content, hit like. It helps us reach a
bigger audience. Thank you for your
help. The idea and reality of having a
relaxed chat with a large language model
that results in a working system is
impressive and seductive, but it seems
to me to miss the point almost entirely
of what programming is really about.
This gets us back to that blight of the
software industry, the idea that writing
code is the hard part. Non-technical
people believe this is true because code
looks so complex and mysterious to them.
developers believe that it's true
because code is comforting and precious
to them and clearly defines their skills
and separates them from the
non-technical people who presumably
aren't as smart because they can't read
the code. We've built a technical
recruitment industry on this premise
that the defining characteristic of a
good programmer is the set of languages
and frameworks that they know. We have
people who define their jobs by the
tools that they use. I'm a Java
programmer. on a React developer and so
on. I've admitted before that I have
hired programmers who haven't used the
same technology that we were using on a
project and I've never regretted that so
far. In my experience, you can learn a
programming language if you're good at
programming enough to get by with it in
a few days, maybe a couple of weeks.
Doing software development well is hard,
very hard, but the difficulty is not
created by programming languages. So
let's think about the starting point in
Andre's tweet. We can give into the
vibes and forget that the code even
exists. Well, the other group of people
that do that are the sometimes
non-technical people who want to achieve
something via a computer. Up to now
though, we human programmers have played
the role of the coding assistant in this
conversation, translating what it is
that they want into something that
works. So how well does that usually go?
Not so well, I'd argue. certainly very
poorly for any software of any size or
complexity. This often goes very poorly
indeed. And so far we humans are still
smarter than the machines. This isn't
because it's so difficult to translate
what people want into a programming
language. It's because it's so hard to
bake problems down into the precise
deterministic instructions that LLM or
not are still how computers ultimately
work. Let me pause there and say thank
you to our sponsors. We're extremely
fortunate to be sponsored by Equal
Experts and Transfig. Transfig is a
financial technology company applying
advanced continuous delivery techniques
to deliver low latency trade routting
services to some of the biggest
financial institutions in the world.
Both of these companies though offer
products and services that are extremely
well aligned with the topics that we
discuss on this channel every week. So
if you're looking for excellence in
continuous delivery and software
engineering in general, please do click
on their links in the description below
and check them out. If you look at
programs from years ago and modern
programs, there's something kind of
weird going on. There's seemingly a
persistence, a consistency to the level
of detail that we need to express to
make a working program. And that's been
true for decades. However we encode the
level of detail that we need to define,
it's pretty consistent. Programming
languages aren't strange because of some
fashion or masochistic trait in
programmers. They are tools that have
evolved to be good at expressing an idea
clearly and with the required level of
precision to achieve an outcome from the
box of billions of switches that make up
a modern computing device. Programming
languages aren't more complex than real
world human languages. They're simpler,
more strictly constrained, and more
precise. That's to our advantage in
trying to achieve our goals when
programming. Programming languages are
tools that are designed to help us to
structure our thinking so that we can
decompose problems into the steps that
are necessary to achieve the outcomes
that we are striving for. So the idea
that we can do better if we adopt a
vague imprecise expressive richness
that's in human languages to precisely
define behaviors in a computer seems to
be very far from the truth and missing
the point almost entirely to me. So vibe
coding is not even close to being the
right answer really. Another example of
humans attempting to achieve clarity and
precision with natural language is the
law. And if you've ever had to read any
legal document for any purpose at all, I
think you'll agree with me that this is
not really what we might hope for in
terms of clarity and precision. We can
think of the act of programming from a
variety of different perspectives. I'm
sure that most the most common way to
think of this is probably to think of
the act of writing code in a programming
language. But I am somewhat skeptical of
the use utility of this. It's rather
like defining a plumber in terms of
their use of a wrench. There's more to
it than that. And the things beyond the
syntax and organization of code are more
interesting and more complicated parts
of programming. The shapes that we paint
with the code and the outcomes we
achieve with it are both more
interesting and more useful than the
code itself. I think that ultimately
there are three goals for programming
languages that really matter. One to
help us to organize our thinking about a
problem. Two to communicate our
understanding to other humans. And three
to tell a computer what we want it to
do. Each of these is important to the
act of programming and represent
different levels of value in the
programs that we write. The hardest part
of programming seems to me understanding
the problem that we're faced with in
enough detail that we can see that
whatever we come up with is likely to
make a good solution. Programming
languages solve this problem by giving
us tools to constrain our thinking in
ways that help us to compartmentalize
our picture of the solution that we're
aiming for so that we can scope it and
manage the complexity of it. They allow
us to deal with parts of the problem
separately from other parts using
techniques like modularity, cohesion,
separation of concerns, abstraction, and
managed coupling. This kind of thinking
about writing programs is a mix of
programming language constructs that
help us to build these structures into
our code and our innate knowledge and
understanding of design that we build up
from experience. Programming languages
can help to steer our thinking via their
design and the rest then is down to us.
A big problem for us as programmers and
for large language models as programmers
is that we need to learn to apply some
sense of good taste in our design
choices to make effective use of these
language constructs. And we've all seen
enough counter examples to know that not
everyone does that. But our poor large
language models have been trained on all
the code, the good, the bad, and the
ugly. And unfortunately, there's more
bad and ugly out there than there is
good. And we as a profession have also
not been very good at defining what good
really looks like to differentiate it
from the bad and the ugly. If you ask 10
programmers to tell you one thing that
makes the difference between good code
and bad, you'll probably get 15
different answers. This means that large
language models are probably not going
to have a great sense of what makes good
code from their training data. So we
either have to tell them or accept them
creating bad code. And to be fair, this
is all rather complex and nuanced
because what makes great code in one
context may be too simple or might be
overkill in another. I certainly have my
own set of defaults and my book is an
attempt to define some generic
cornerstone ideas that I think are
generally enough to help. But even then,
it's still contextual. My background and
experience has led me to a reasonably
defensive evolutionary approach to
design and development. I think that the
strongest mental approach is to assume
that our guesses, whatever they might
be, are probably wrong and so work in
ways that allow us to correct that when
we find out where we're wrong. I believe
that the only meaningful measure of
quality in our code then is our ability
to change it. So I always strive for the
simplest, easiest to read, easiest to
change solution that I can find. But
what does ease of change really mean
when a large language model rewrites all
of the code from scratch nearly every
time, however small the change? Does
that mean that all the code is now
equally easy to change? Well, not
really. The code's only easy to change
if we can also determine that after each
change, however big or small, it still
does everything that it's supposed to.
But how can we determine that unless we
specify it in detail precisely what our
system is meant to do? For humans, this
sense of what is it meant to do is often
implicit. It isn't usually written into
the code. But for AI generated code,
that's an even bigger problem. I think
there are three big problems that the
use of AI in programming highlights for
us. How do we specify what it is that we
want with any degree of precision? How
do we confirm that what we that we got
what we wanted? and how do we retain our
ability to make measurable progress in
small controlled steps? The first
problem goes to the vagueness and
imprecision of natural language. The
second highlights the even more
important role of automated testing for
code written by an AI. And the third is
about another quite deep problem, the
profound difference between the way that
machines write code and the way that we
humans do. Fundamentally, this matters
because of our ability to reliably
reproduce a result. All successful
systems evolve over time. That means
that we need to be able to change them
when our circumstances or our
understanding changes. Humans who are
good at building complex systems do so
by compartmentalizing the problems so
that they can retain their ability to
make change safely in one part of the
system without those changes leaking out
into other parts of the system. This is
true in physical engineering as well as
software engineering and it results in
all complex systems being built in this
sequence of small changes however we
organize the building of them. So my
idea that the definition of highquality
in software is defined by how easy it is
to change is I think rather important
because we must nearly always be able to
change it. This highlights the
importance of ideas like continuous
integration and continuous delivery for
building complex software systems. To me
this is independent of whether or not we
use AIs to write the code. AIS though
don't write code the way that we do.
Most of them generate the code from
scratch, often after every small change.
Ironically, this same problem in
ignoring the importance and ability to
revisit and correct or enhance code has
been the stumbling block that has seen
off every other attempt at raising the
level of abstraction in programming from
4G's and model driven development in the
1990s to low code and no code systems.
Now they are all built on the assumption
that the code would be right first time
and wouldn't need correcting and so
roundtpping the ability to go back to
existing code and correct or enhance it
was difficult if not impossible. Many of
these attempts were not even version
controllable and we seem to be in danger
of making the same mistake yet again
with AI programming. Ignoring the
problem of being able to update the code
is stupid because it relies on us and
the world being perfect and neither of
us are. AI has this problem and it
doesn't at the same time. If it can
recreate each even complex software from
scratch given some instructions then do
we still really need incrementalism? I
think there are two answers to this but
neither line up with vi well with vibe
coding. If I as a human programmer build
a complex system, complex enough so that
I can't hold every last detail of what I
want and what I did in my head and now I
want to make a small change to it
without breaking things. I can only be
confident of my ability to do that in
two ways. I can test everything and then
run all my tests again later to confirm
that they still pass. or I can design my
system in a ways that allow me to change
code in one part place without worrying
too much about what may happen
elsewhere. But that second approach is
foundationally built on the assumption
of deterministic in incrementalism in
execution and design. Can I be confident
that my compiler or language will
interpret the code that I didn't change
in exactly the same way as it did last
time? Can I be equally confident that my
AI can do the same? What do I version
control to achieve this? What can I
version control to achieve this? If I
can do this, I only have to worry if my
new change is correct and the isolation
between the old code and the new code is
good enough for me to rely on. But if I
can't, I'm lost. If the AI regenerates
all the code from scratch every time or
does that occasionally or is learning
new things and so changes how it
interprets my instructions, then I can
no longer trust it to recreate something
that works as it did before. So I need
to check that it does. This makes
automated testing, continuous
integration, and continuous delivery
even more important for AI generated
code than it is for human written code.
And this isn't just me saying this. I
recently saw an excellent video making
the same point from an open AI
researcher. My point and his point is
that the best way to prompt an AI is
with an executable specification. That
is a precise accurate example that
describes exactly how the system you
that you want to build should behave in
clearly defined repeatable
circumstances. So that these
specifications both clearly define what
we want the system to do and also allow
us to verify that it does it.
Programming moves then from specifying
implementation detail to more clearly
and more precisely specifying the intent
of the system that we want to build. If
you'd like to learn more about how to do
that, check out my training course,
Acceptance Testing BDD from Stories to
Executable Specifications, which
includes an example of programming out
with AI like this. So, Vibe coding
doesn't address any of these problems.
It's simply not good enough. Software
engineering isn't dying, it's changing.
I'd argue that these three problems are
fundamental to the nature of code, AI
generated or not. And any next step in
programming must address all of them or
it's not going to work. Thank you very
much indeed for watching. And if you
enjoy our stuff here on the Modern Stor
Engineering channel, please do consider
supporting our work by joining our
Patreon community. And if you're already
a Patreon member, thank you very much
indeed once again for your support. And
I hope you're enjoying the privileges
that you get from being a member. Thank
you and bye-bye.