YT YouTube2Text

YouTube2Text → Transcripts → Dave Farley - Vibe Coding - Is this really the best we can do? - AI Native DevCon June 2026

Dave Farley - Vibe Coding - Is this really the best we can do? - AI Native DevCon June 2026 — Transcript

by AI Native Dev · 4,836 words · 798 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00I'm not going to say [music] we saved
0:01the best for last cuz that's probably
0:03not doing justice for our other speakers
0:04as well. But I'm really interested in
0:06this session and Dave Farley is a great
0:08a great speaker.
0:09So vibe coding is this the best we can
0:11do? I think this is going to be an
0:12interesting look at the processes and
0:15the practices we do today with vibe
0:16coding. What needs to go forward into
0:19our new practices?
0:21This is the last session of the day
0:22before the party. So afterwards I'll let
0:24you know a little bit more about what
0:26the party is doing. But in the meantime,
0:28please make sure you're still doing your
0:30ratings and and things like that on the
0:31app.
0:32But without further ado, please give it
0:34up for Dave Farley.
0:37>> [applause]
0:40>> Thank you.
0:43Thank you. I'm the last speaker between
0:45you and beer.
0:47So I'll try not to go on too long. Um
0:51I'm interested in the the things that
0:54seem durable. And that's may seem odd
0:57when we're talking about such a
0:58disruptive change as we are talking
1:00about when we're talking about
1:03the adoption of AI for programming.
1:06Um but I think there's quite a lot of
1:08things that are durable. There's a lot
1:10of behaviors
1:12that sta- have stood the test of time
1:14and seem to continue to be important.
1:17And I'm not the only person that's been
1:19saying that today. If you've been
1:21listening carefully, there's been people
1:22saying very similar things as we go
1:25through. I'd like to look at maybe some
1:28of the reasons why why this matters and
1:32question some of the the things that
1:34that we might otherwise think about the
1:36new world of agentic programming.
1:40I think one of the things that we can
1:42certainly say though is that whatever
1:43does come next, it's going to be
1:45different. This is a huge change. This
1:49is a sea change in the way that our
1:52industry and probably our industry is
1:55just a forerunner, how our world is
1:57going to work.
1:59So so so what does this really mean?
2:01What what does this mean in terms of
2:03the impact on people like us who are
2:06involved in the production of software
2:08at the moment and
2:09I suppose to some degree the pathfinders
2:13for everybody else in the world as they
2:15start to adapt to some of these things.
2:18I think a starting point, if you'll
2:20forgive me for being slightly
2:21provocative, some of the differences
2:23that we talk about kind of just dumb.
2:26So I would argue that vibe coding,
2:29programming with natural languages,
2:32while having a place,
2:35are also kind of bad ideas. And I want
2:38to talk a little bit about what I mean
2:39by that and we'll get into it.
2:42I think
2:44sacking all junior developers, AIs will
2:46write all the code, we don't need no
2:48programmers. Some of these are kind of
2:51right, some of them are probably true,
2:53and some of these are a terrible idea.
2:57I think AI generated tests
3:01also a terrible idea. So I'd like to
3:03explore all of these things in a bit
3:05more detail and there's quite a lot of
3:06nuance in this because there are aspects
3:09of these where they're all true.
3:11But let's talk about it.
3:14So first of all, I'd like to I'm a I'm a
3:17old school card carrying test-driven
3:20development developer. So let's start
3:22with tests cuz that's where you're
3:24supposed to start.
3:25What's a test for? Is it to prove
3:27success?
3:29Not really.
3:32Is it to find our mistakes?
3:34Well, kind of but not really. Is it to
3:36challenge my genius as a programmer?
3:38Certainly not.
3:40It's not those are not really what tests
3:42are for.
3:44They're not what make tests useful. I
3:46would argue that what tests are for us,
3:50they're a form of measurement. They are
3:53equivalent of a carpenter having a tape
3:55measure in his pocket
3:57that he can measure things with.
4:00We use tests to figure out that we're
4:03doing the right things. We use tests to
4:06figure out that when we've done them,
4:08they they continue to be the right
4:09things.
4:10They're [snorts] measurements to see if
4:12we've achieved our goals.
4:15But for that, we've got to define what
4:16our goals are.
4:19And we can't infer the the goals from
4:22the solution cuz the solution can always
4:24be wrong. So, anybody that's selling you
4:28free AI testing that will come in and
4:30look at your existing system and test
4:32it,
4:33that might have some value, but it's not
4:36the same value as proper testing that we
4:39need as part of a development process.
4:41It's a different thing. And the reason
4:44for that is fairly obviously. If I If I
4:46write a function something like this,
4:49calculate tax,
4:52and
4:53I'm going to return 50 times the amount
4:55that I put in. That's a very bad place
4:57to live if that's what your tax looks
4:58like.
5:00But if that's my starting point, the
5:02only thing that an agentic AI or any
5:04other kind of AI can do
5:06is look at that and say, "Okay,
5:09here's my test."
5:11He's just going to reinforce the
5:12wrongness that I wrote into that
5:14function. All that a test can do at that
5:17point because the only input it's got
5:20is the test
5:22is the working code. He's verified that
5:24the working code does what the working
5:25code does.
5:27That has its use uses. That's very good
5:30if you want to refactor the code, do
5:32behavior-preserving change, and not
5:34break anything.
5:36But it's rubbish if you want to develop
5:37a new system and verify that this new
5:40system continues to do or does the right
5:43things because now it's proving that it
5:46does the wrong thing
5:48because that's where we started from.
5:50So, that that's not giving us our
5:52ability an ability
5:54to
5:55define what we really wanted.
5:57AI-generated tests, if the code is the
5:59only input, we can only verify that the
6:01code remains the same.
6:03We can't infer the goals from the
6:05solution because the solution [laughter]
6:07can always be wrong.
6:13>> [clears throat and snorts]
6:13>> So, they're mostly a dumb idea.
6:16They have a They have a place, but
6:18mostly a dumb idea. They tend to be a
6:20cop-out for people who don't can't be
6:22bothered to state their goals. And I
6:24think that's a problem because
6:26specifying the goals is kind of what our
6:29job is. It's kind of what we're here to
6:31do as software developers.
6:38My next question, what's a program for?
6:41To define a sequence of instructions.
6:45Well, not really. That's not the goal.
6:47It might be what it is, but to encode
6:50algorithms. That's not the goal again of
6:53what of a program. That's not what we do
6:55it for. That's not the value that it
6:57brings.
7:00To implement our brilliant design.
7:02Again, that's some of the
7:04self-fulfillment that I as a programmer
7:07might get from it, but that's not the
7:09goal. That's That's not the goal. That's
7:11not the reason that people pay me to do
7:13it.
7:16So, the commercial pressure is not none
7:18of those things. That's not really what
7:21it's for as much as we might might like
7:23to think of it in that way as
7:24programmers.
7:25Programming languages I would argue have
7:27three goals as tools.
7:31So, first, they are tools that have been
7:34designed to help us to organize our
7:36thinking about a problem. They allow us
7:39to explore the surface area of of a
7:41problem and kind of understand it in
7:43more detail, in more depth. And they're
7:46designed to work that way. Programming
7:48languages aren't difficult because we
7:51want it to be obscure and abstruse. We
7:54wanted tools that would help us to
7:56explore the problems in in these kind of
7:58way. They're designed to help us to do
8:01that.
8:03They're also a means of communicating
8:05our understanding with other
8:06programmers, other humans.
8:09So, they are communication tool between
8:10us so we can work as part of a team and
8:13understand what we are in some technical
8:15detail exploring the depth and the
8:18breadth and the complexity of a
8:20of a the problem that we're trying to
8:22solve and the solution that we've come
8:24up with
8:25encoded as a program in in a programming
8:27language.
8:29And ultimately, they're there to tell a
8:32computer what to do. But, that's kind of
8:34the last part because assembly language
8:36instructions in in form a computer what
8:39to do perfectly well. And we don't not
8:41many of us write spend our time writing
8:43programs in assembly language.
8:52There are also three techniques that are
8:54embodied in programming languages that
8:56are I think are important
8:58for us to think about and to remember
9:00when we're talking about programming as
9:02a discipline.
9:04The first is we have a simple consistent
9:07grammar. It allows us to
9:10express our ideas in in a concrete,
9:14specific, precise way,
9:17precisely enough to be executable by a
9:18computer.
9:21They are an unambiguous expression of
9:24our intent in that respect. And that
9:26this this matters.
9:28And they're repeatable and deterministic
9:30in terms of execution. And this matters
9:32a lot, too. If we write something in the
9:35programming language of our choice and
9:38run it twice
9:40given the same inputs, we're going to
9:41get the same result every time.
9:45That's important. It means that we can
9:47reason about it. It means that we can
9:48test it. It means that we can understand
9:51what it means and we can design systems
9:53that are more or less repeatable in that
9:55sense, but the tools themselves are
9:57repeatable.
10:01How does natural language measure up to
10:03that? Because natural language Somebody
10:05said today I I think they quoted Andre
10:08Karpathy saying that the programming
10:11language of the future is English.
10:14I don't like that idea very much for the
10:16reasons that I'm talking about. It's not
10:18precise enough. It's
10:20too vague.
10:22Natural language helps us
10:24How does that measure up? Helps us to
10:25organize our thinking about a problem.
10:28Well, it's too vague, really.
10:31Natural language is open to
10:33misinterpretation.
10:35If anybody's been around, I can't really
10:36see you very well, but if you've got a
10:39gray beard like mine or you've been
10:40around enough,
10:42I bet that you've been in a situation
10:45where somebody's coming down from on
10:47high and given a
10:49a very vague instruction to a bunch of
10:51programmers, gone away, and then been
10:53really disappointed in the result cuz
10:55they didn't tell us in enough detail.
10:57That's really common. It's really easy
10:59to misinterpret what what the goal
11:01really is.
11:07Natural language is always open to
11:09interpretation.
11:11Time flies like an arrow. These are some
11:13time flies like an arrows.
11:19Vibe coding alone is simply not good
11:22enough. If we're just chatting with the
11:24computer to express our needs, that's
11:26not enough. We need tools that allow us
11:30to be more precise than that, to be more
11:32specific than that, to be better prompts
11:35of what it is that we want to achieve.
11:37That doesn't mean
11:39that we need to look at all the code and
11:42are only allowed to do this in a
11:44programming language.
11:45I mean I'm in the category of it's been
11:48a long time now since I've So I've
11:50written any code by hand cuz my AI agent
11:54writes all the code. But I've been more
11:56precise than just natural language in
11:59some respects in specifying what I want
12:02from it.
12:03I'm able to get what I want from it by
12:05using a precise prescriptive version of
12:08natural language in order to be able to
12:10prompt it. And that's what I'm really
12:12talking about here.
12:14So,
12:15does it communicate our understanding
12:17with other humans?
12:20It's a bit too ambiguous to do that very
12:22well because we all as we've as we all
12:25know.
12:26Does it tell a computer what we want it
12:28to do? It's too imprecise for that. So
12:30it's very easy unless what we're telling
12:33it is something very obvious like asking
12:36our AI assistant to implement FizzBuzz
12:38for us.
12:40It might do that in a repeated way, but
12:42otherwise it's probably not. It's going
12:44to be a little bit different and give us
12:45something a little bit different every
12:47time.
12:49Certainly in the earlier versions of AI
12:52coding assistants, we've all seen that.
12:55Where we've asked our assistant to build
12:57something, you ask it the same thing
12:59again, and you get something very
13:00different.
13:03That certainly happened to me a few
13:05times.
13:12So, we've got these What about these
13:14three techniques that we have? Simple
13:16consistent formal grammar.
13:19Does natural language give us that?
13:22No, it's complex and inconsistent.
13:26Unambiguous expression of intent. Now,
13:28it's ambiguous and vague. Repeatable
13:30deterministic
13:31execution. Not repeatable, not
13:34deterministic, not version controllable
13:35as a result. We can if we version
13:38control the language that we prompted
13:40our AI with, that's not enough to get
13:42back to a the same result again.
13:46On its own.
13:48So, programming with AI presents three
13:52important problems for us to replace
13:56traditional programming.
13:59So, how do we specify what we want with
14:02precision? That's problem one.
14:06Problem two is how do we confirm that we
14:09got what we wanted? This is the
14:11verification problem.
14:14And problem three is that we don't work
14:17in the same way as the machines. They
14:21don't work in the same way as us. Either
14:23way, which which you
14:25look at that. The way that we do things
14:28is that we tend to deal with problems
14:31with with the limits of our own context
14:33window. So, what will fit inside our
14:35heads at a time. We might have a picture
14:37of what it is that we want to build, but
14:39then
14:40small change by small change, the way
14:43that we deal with it is that we do it
14:45incrementally. We do a small piece of
14:46work, we evaluate that piece of work,
14:49and then we then we move on to the next
14:51small piece of work. I would argue that
14:55high-quality system development
14:59uh in software is always an incremental
15:03process of learning and discovery.
15:05We are always exploring the problem
15:08space and trying to understand it over
15:11time, bit by bit by bit. I'd go further
15:13than that. I would say that's all
15:15engineering. All engineering is a is an
15:18act of
15:21incrementally improving on what we know
15:24about the problem and in dealing with
15:27the with the new things that we learn as
15:29we do that over time.
15:32And that's a hard part of software
15:34development, a hard part of engineering
15:36in general. And then we've got to verify
15:40that we got what we wanted and it does
15:42all of the things that we need in a
15:44repeatable reliable way. And that's a
15:47hard part of software development as
15:49well.
15:51And what have we done? We sped up the
15:53coding bit. That was the easy part of
15:55software development, which is good.
15:58It's great. It does accelerate us,
16:01but it also moves the bottleneck. If
16:04you've ever read The Goal, the theory of
16:06constraints, that's what we've done.
16:08We've just moved the bottleneck to
16:10somewhere else. And actually, we
16:12probably haven't moved the bottleneck
16:13cuz the bottleneck was nearly always
16:15about verification and release rather
16:17and figuring out what that we really
16:19wanted rather than the encoding of it if
16:21we were any good
16:23as delivery agents.
16:27So, an AI works differently. An AI works
16:30It kind of builds this context, this
16:32picture,
16:34and then it goes bang and it makes a
16:36huge change.
16:38Probably
16:40until recently you you kind of rewrite
16:42the whole system every time.
16:44And there's nothing really to stop it
16:45while it's building your stock control
16:47system to write Space Invaders instead
16:50if we haven't told it not to, if we
16:52haven't defined what our goals are and
16:55are in a in a position where we're able
16:57to evaluate it. Now, part of the problem
16:59here
17:01is that a lot of people that talk about
17:04using AI AI's and
17:07agents to help with coding
17:10are often talking from a perspective of
17:12building small simple systems. I don't
17:14know about all of you, but those aren't
17:16the sorts of systems that I generally
17:19build professionally. They're certainly
17:20how I've played with the AIs. I've I've
17:23written Space Invaders with an AI agent,
17:26and I've done simple things like that.
17:28All those nice straightforward things.
17:30But my professional building of software
17:33has been for bigger, more complicated
17:36systems than that.
17:37And that's not good enough. Just Just
17:39being able to check them manually to see
17:41if they're okay is not even close to
17:44being good enough to verify that we get
17:47what we wanted.
17:50So,
17:52if the AI is making huge steps and
17:55changing things in one big
17:57big big um
17:59change at a time, and we're not able to
18:02verify that we got what we wanted
18:03effectively, how do we learn? How do we
18:06find our understanding? How do we
18:08reliably update our solution to improve
18:10it? And how do we regenerate if if it's
18:13regenerating it from scratch every time?
18:16We can't. It's not really helping us to
18:18learn and adapt and figure out where we
18:21are and figure out what we need to do
18:22next.
18:25It's It's It's a problem.
18:31The last two problems, problems two and
18:33three, mean that we're losing our
18:35ability to work incrementally. And that
18:38is
18:39fundamental to
18:41building complex systems of any kind,
18:44but certainly complex software systems.
18:47It's a this process of learning and
18:49discovery. So, how do we keep our
18:51ability to learn, discover, and
18:53incrementally add to our systems as we
18:56go?
18:57We have to have We have to have a means
19:00that can keep up with the rate at which
19:02we can produce software.
19:04I spoke to somebody not very long ago
19:06who who's who's engaged wholeheartedly
19:10in the adoption of agentic programming
19:12using multiple agents to build systems.
19:15He's writing a game. He reckons he make
19:17he writes 12,000 lines of code per day.
19:21No human being can review 12,000 lines
19:25of code per day. No human being can test
19:29manually test the output of 12,000 lines
19:32a day behavior to figure out whether
19:34it's doing the right things. We've got
19:36to find ways of speeding up the rate of
19:39verification and assurance to tell what
19:41the whether we got what we wanted to
19:43keep up with that speed of generation of
19:46code. It's the only thing that makes
19:48sense, it seems to me, if we're not to
19:50suffer from
19:51um the theory of constraints problem.
19:58How do we
19:59confirm then
20:01that we always get what we want? So,
20:04first we've got to specify what we want
20:07clearly, reproduce in a reproduceable
20:10manner, and then we've got to be able to
20:12verify repeatably that we still have it
20:15after every change.
20:19If you're familiar with my work with
20:20continuous delivery and so on, that
20:23might sound familiar.
20:25It's cuz it is. It It It It's the same
20:28that we've been doing when we're talking
20:29about practicing continuous delivery.
20:31It's table stakes. We have to have this
20:34fast cycle of verifying that we got what
20:37we want.
20:41So, how should programming change to
20:43keep up with all of this?
20:47So, problem one,
20:48specifying what we want with precision.
20:51In the past, the way that we did this
20:54was that a program was a precise
20:56solution encoded as algorithms.
21:00Weirdly, we kind of lost what the
21:02problem was. It's kind of implicit in
21:04our solution, but we'd keep that in our
21:06heads we'd build a solution and that
21:09would
21:10be our definition
21:12that we'd work to.
21:16But the the solution itself was
21:17implicit.
21:20So in this in my example, this is a
21:22routing algorithm. So I'd like to find
21:25my way home is the outcome that I'm
21:27trying to achieve here.
21:34In the future,
21:36a program as is a will be a precise
21:39description of what it is that we want,
21:41I think. Encoded as specifications,
21:44translated into executable instructions
21:47by the AI that will verify that we got
21:50what we wanted and what we want now is
21:53explicitly part of, if you like, the
21:56program. So the program moves away from
22:00being
22:01solution focused to being a more
22:04accurate description of the problem that
22:06we're trying to solve.
22:09I'm describing a form of spec spec
22:11driven development, but the
22:12specification takes the form of
22:14executable specifications, tests, if you
22:17like, that both specify what we want and
22:21also verify that we got it.
22:26>> [clears throat]
22:28>> What it takes to achieve that. Program
22:30uh I've just This is I'm just repeating
22:32what I said. Designing a domain specific
22:34language, if you like, for specifying
22:36what it is that we want from our
22:37software with a deal of precision.
22:41And then specifying what we want aim to
22:43achieve in detail all of the time. And
22:46those are those are all of the behaviors
22:48of the system.
22:50Not just the conventional user behaviors
22:53that we might think about. We're not
22:54talking about sketchy testing of the
22:56system, but all of the behaviors of the
22:57system. So how fast would we like the
23:00results back if performance matters? How
23:02secure do we want it to be? If we want
23:04secure that system to be secure, because
23:07all of those are contextual. You can't
23:08have the AI to infer that, to make it
23:11up, cuz it depends.
23:13The real you know, how secure do you
23:15want your system to be? You'd be stupid
23:18to apply the level of security to a
23:22single user game than you would if you
23:24were building a system for a bank, cuz
23:26you'd be over-engineering the game and
23:28probably under-engineering the bank.
23:31So, you need to be specific about what
23:34it is that you're trying to achieve
23:36in all of the dimensions of architecture
23:38and design. So, some of those are
23:39behaviors of the system that we need to
23:40specify, too.
23:42The second problem, how does it how
23:44about that? So, how do we confirm that
23:46we got what we wanted? In the past, we
23:49hoped that our solution solved the
23:50problem.
23:52Language verified some aspects of this
23:54in terms of the syntax that we use,
23:56particularly if we use types languages
23:58and stuff like that.
24:01But, they didn't it it didn't work to
24:03verify functional correctness. If you
24:06were a well-behaved test-driven
24:07development developer,
24:09then testing would would fill that gap
24:12and would verify that our code did what
24:15we wanted it to do from that set from
24:17that in that sense, but otherwise maybe
24:19not.
24:22In the future,
24:23uh executable specifications
24:26will work as the verification of our
24:29system as well as the specification of
24:32what it is that we aim to achieve.
24:35I think.
24:37This makes the AI we can do this in in
24:41human language. This doesn't have to be
24:43difficult or hard. The way that I do it
24:46is that I teach my AI how to do the kind
24:50of
24:51BDD style uh tests that I like to use,
24:55and I specify what I want, and my AI
24:58fills in the gaps from relatively simple
25:00English descriptions of what it is what
25:02the specification that I that I of what
25:05I want.
25:08AI generates solutions that match the
25:10specifications.
25:12And now we can run those tests against
25:15those solutions. We can
25:17verify that the AI is doing the right
25:19thing by giving test test values that it
25:22hasn't seen before, so it can't cheat
25:24the tests.
25:27And get feedback that we got we actually
25:29did get what we wanted. What it takes to
25:32achieve that,
25:33the programmer
25:37invents problem-specific DSL,
25:40defines all of the desired behavior of
25:42the system as prompts to the AI in the
25:44form of BDD-style specifications,
25:47and the AI
25:49takes the specifications, builds test
25:51infrastructure to make them executable,
25:53generates code to fulfill all of the
25:55executable specifications,
26:00and we've got what we wanted. We've got
26:01the the def a precise definition of the
26:04behaviors that we want, and a
26:06verification that we got those
26:08behaviors.
26:11Regaining the last of the three,
26:13regaining incrementalism.
26:15So, in the past, we would work
26:17iteratively in small steps, adding new
26:19tests and code.
26:21We would gather feedback validated by
26:24our deployment pipelines.
26:26Build systems incrementally, treat each
26:28change as an experiment, and value
26:30empirical learning.
26:31In the future,
26:36we're going to work iteratively in small
26:38steps, adding new tests and code. The AI
26:41will generate the code.
26:43Gather feedback to validate every
26:44change.
26:48Build systems incrementally, many small
26:50changes, treat each change as an
26:51experiment, and value empirical
26:53learning. So, it's exactly the same. So,
26:55the stuff if you've been practicing
26:56continuous delivery
26:58as
27:00two of the speakers that I heard
27:01speaking today
27:04said
27:05at least implicitly
27:09then
27:10things become easier
27:12because that's what we're doing the same
27:14things. We're evaluating stuff as we go,
27:17working in small steps, and we're
27:18understanding where we are at all times.
27:21And so are our AI agents.
27:24What does this take to regain the
27:26incrementalism in this sense? Well, we
27:27version control of the specifications
27:29cuz those are now in effect a program.
27:34We run the tests ourselves in a
27:36deployment pipeline.
27:38Otherwise, the AI is going to cheat.
27:42I'm going to stop the AI gaming the test
27:44by using the sorts of techniques that I
27:45mentioned about maybe keeping some tests
27:48back and not showing the AI. Uh for
27:51going to what's
27:52so it can't cheat them.
27:55Most of this that I've described is how
27:57acceptance testing with behavior-driven
27:59development already works. So, this
28:01isn't anything necessarily new. If
28:04you've been working this way before,
28:06this is a really simple step.
28:11Here's an example that I've used.
28:15I've done this now several times, many
28:18times for building real systems. This is
28:21not a real system. This is a This is an
28:23example from a training course that I
28:25that I did an exercise with.
28:27So, here are some These kinds of
28:29specifications that I'm talking about.
28:31If you think about what I'm trying to
28:33describe
28:34we start off with a vague wish of what
28:36we want. We get to a slightly more
28:38formal version of describing that, which
28:40is a user story. And then we come up
28:43with some examples that would
28:44demonstrate that the feature that the
28:45story describes exists. Those are our
28:48examples, those are our executable
28:50specifications. That's what these things
28:52are on the screen. These are the ones
28:54that prompted building a system that
28:56actually did this. It actually did
28:58flight planning in this way.
29:05My conclusions are that natural language
29:08alone is not good enough.
29:11BDD style domain-specific languages are
29:14the best alternative for prompting
29:16effectively and giving us the
29:18combination of precise specification of
29:21what we want and built-in verification
29:24that we got it.
29:26Automating testing from a solution
29:30is a bit of a joke. It's it's a niche
29:33it has some utility, but it's a corner
29:36case. It doesn't solve the real problem.
29:40We should treat skills to analyze and
29:42decompose problems as the real core of
29:44our discipline. That's the real
29:46discipline that we as engineers,
29:49technologists bring. It's that
29:52way of reasoning about a problem, of
29:54decomposing it and thinking about the
29:56corner cases.
29:58Thinking about the kind of the
30:00architectural level. One of the ways of
30:02thinking about all of this is that
30:04effectively what we're doing is we're
30:06involved in invoking a fifth-generation
30:10programming language, a fifth-generation
30:12programming system. And I think that's
30:14where we're at.
30:17So, we need a different model for the
30:18role of AI. AI assistance is rather like
30:21the compiler. We're not going to
30:23care for very much longer at all if we
30:26do now about the code that it generates
30:28cuz we'll verify that we got the
30:30results. And as long as we get the
30:31results, who cares about the
30:32implementation? It's rather like the
30:35move from assembly language programming
30:38to high-level language programming. I
30:40don't know whether anybody in the room
30:42is old enough to remember that. I
30:44I don't quite, but I I was an assembly
30:46language programmer for a while. And for
30:48a while
30:50I used to look at what the assembly
30:52language was that was generated by my
30:54compilers, but I haven't done that for
30:56years. And most people have never done
30:58that.
30:59So, why should we care about what the
31:01code that was generated was if we can
31:03verify that the behaviors that we wanted
31:05are the ones that we got.
31:06>> [snorts]
31:09>> If you'd like to see a demonstration of
31:11this in use, there's an open source
31:13project called Nwave that's worth a
31:15look.
31:16Um that imply
31:18that applies this thinking and promotes
31:21this way of development.
31:28Skip.
31:38So, that's
31:42I'm going to skip over here cuz I got uh
31:45Where am I? There.
31:49That's the end of my talk. Thank you
31:51very much.

About this transcript

This page contains the full transcript of Dave Farley - Vibe Coding - Is this really the best we can do? - AI Native DevCon June 2026 by AI Native Dev, generated from the public captions YouTube serves with the video. The transcript has 4,836 words across 798 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.