1
00:00:00,000 --> 00:00:04,480
Maybe you've been thinking, this journey has been interesting, it's been useful, I'm picking up new

2
00:00:04,480 --> 00:00:11,199
skills, but I wish it could go deeper, get more pro, get more hardcore. Well, good news, that's

3
00:00:11,199 --> 00:00:17,360
what we're doing. Welcome to week two, welcome to pro week. And today is a yellow day, which means

4
00:00:17,360 --> 00:00:23,760
it's a platform day, a product day. And of all the product days, this is the one, this is the one

5
00:00:23,760 --> 00:00:28,639
that's near and dear to my heart. This is Claude Code Day. I'm introducing Claude Code, which is

6
00:00:28,639 --> 00:00:33,759
going to be the main point of focus for the whole rest of the next two weeks. But we'll also look

7
00:00:33,759 --> 00:00:40,159
at OpenCode and maybe some others as well. So much to do today. At the beginning of the course last

8
00:00:40,159 --> 00:00:46,479
week, I'd taken you through Steve Yaggy's eight stages in the evolution of AI coding, starting

9
00:00:46,479 --> 00:00:52,880
with just using ChatGPT and ending up all the way with orchestration platforms like his own Gastown.

10
00:00:52,880 --> 00:00:58,400
And we talked about that sort of evolution as the first four being what we would do in week one,

11
00:00:58,400 --> 00:01:04,319
stage five is what we would really hammer in week two now, and then six, seven, and eight,

12
00:01:04,319 --> 00:01:11,839
the super fancy stuff, perhaps mostly in week three. And we also went through the kinds of

13
00:01:11,839 --> 00:01:18,639
the three stages, the three types of coding that were prevalent last year, which was mostly what

14
00:01:18,639 --> 00:01:24,319
we did at the end of last week about planning, executing, reviewing and test, writing out your

15
00:01:24,319 --> 00:01:30,080
spec, driving the process, and the trust but verify mindset, which I think you'll agree is very much

16
00:01:30,080 --> 00:01:35,199
what we had in our project on day five of last week. And these are the techniques that are typically

17
00:01:35,199 --> 00:01:41,279
used for mission critical software for big codebases, and for highly innovative code, which

18
00:01:41,279 --> 00:01:47,199
you're using sort of latest greatest libraries, where you have to work more carefully. But for MVPs

19
00:01:47,199 --> 00:01:51,680
for new build, where you have risk appetite, where you're just creating a lot of boilerplate front

20
00:01:51,760 --> 00:01:57,279
end code, say, which is, which is ripe for automation, then you can be more bold, you can go

21
00:01:57,279 --> 00:02:02,639
with YOLO, you can have what's called Ralph loops, which we will explore this week. And you can even

22
00:02:02,639 --> 00:02:09,520
go to this kind of multi agent swarms, orchestration stuff that we'll focus on next week. So this just

23
00:02:09,520 --> 00:02:14,160
gives you again, the kind of lay of the land, and I need to press home on the point that was

24
00:02:14,160 --> 00:02:20,399
emphasized in the jellyfin post, if you remember that, that it is your job and my job to deliver

25
00:02:20,399 --> 00:02:26,880
code that we are accountable for that we have proven to ourselves that it works, and it's good,

26
00:02:26,880 --> 00:02:33,919
we can use LLMs to help us, we can use them to expand our capabilities to use Andre's word. But

27
00:02:33,919 --> 00:02:38,240
the the key is that we are responsible for the quality of the code we deliver and for making

28
00:02:38,240 --> 00:02:43,279
sure that it works. Now, if last week was about vibe coding, by coding for fun and profit,

29
00:02:43,839 --> 00:02:49,600
this week is changing the conversation to be about something called vibe engineering. And that's not

30
00:02:49,600 --> 00:02:55,119
necessarily a proper phrase, it was a it was a term that was coined by Simon Willison,

31
00:02:55,119 --> 00:03:01,679
amazing AI engineer and writer who I will often often show you his stuff. But he made this this

32
00:03:01,679 --> 00:03:06,800
blog post, which I will show you. And he says, I feel like vibe coding pretty well established

33
00:03:06,800 --> 00:03:12,720
as covering the fast, loose, irresponsible way of building with AI, prompt driven, no attention to

34
00:03:12,720 --> 00:03:17,839
how the code actually works. And so this leaves us with with what he calls a terminology gap,

35
00:03:18,000 --> 00:03:22,960
missing word, what do we call the other end of the spectrum, where seasoned professionals

36
00:03:22,960 --> 00:03:28,880
accelerate their work with LLMs whilst proudly and confidently staying accountable for the

37
00:03:28,880 --> 00:03:34,960
software they produce. And he proposes we call it vibe engineering, and your tongue slightly in

38
00:03:34,960 --> 00:03:39,759
cheek, but not really, he really, really wants this term. And I see why and it is taking off

39
00:03:39,759 --> 00:03:45,039
somewhat. And certainly it's in the spirit of this exact right up here that we're going to go through

40
00:03:45,039 --> 00:03:48,960
our material this week. It's somewhat consistent with day five of last week. But just taking it

41
00:03:48,960 --> 00:03:55,919
further, it's about being highly productive, highly effective and impactful. But whilst keeping

42
00:03:55,919 --> 00:04:01,279
accountability for the code you build, doing it in a bulletproof way, that is vibe engineering.

43
00:04:01,279 --> 00:04:05,600
And so in fact, we will take a second to go through his post, just so I can show you some

44
00:04:05,600 --> 00:04:09,440
of the points he makes because it's so well done. Well, this is this is his blog. And it's an amazing

45
00:04:09,440 --> 00:04:13,679
blog. We've already gone through the first section, let me keep going. One of the lesser

46
00:04:13,679 --> 00:04:19,760
spoken truths of working with LLMs is that it's difficult. There's a lot of depth to understanding

47
00:04:19,760 --> 00:04:26,640
the tools, there are traps, and the pace at which they can churn out code. It can be crazy.

48
00:04:26,640 --> 00:04:34,160
The rise of coding agents like Claude Code, first released in February, Codex CLI, the CLI version,

49
00:04:34,160 --> 00:04:40,399
and Gemini CLI, the CLI version, we've been using the IDE versions of these, can iterate on code,

50
00:04:40,399 --> 00:04:46,239
test and modify until it achieves a goal. It's dramatically increased the usefulness of LLMs,

51
00:04:46,239 --> 00:04:51,279
as we will see when we use the CLI tools this week. And then he says, I'm increasingly hearing

52
00:04:51,279 --> 00:04:58,000
from experienced, credible engineers who are running multiple agents at once, tackling several

53
00:04:58,000 --> 00:05:03,200
projects in problems in parallel, and expanding the scope of what they can do. He was skeptical

54
00:05:03,200 --> 00:05:09,359
to start with, but now he's doing it himself. And it's effective, if mentally exhausting. And that's

55
00:05:09,359 --> 00:05:15,839
more what we'll be doing next week. It feels different from classic vibe coding. He built lots

56
00:05:15,839 --> 00:05:21,440
of tools that way, and his tools are amazing. But iterating with coding agents to produce production

57
00:05:21,440 --> 00:05:28,079
quality code feels like a different process entirely. And it's also clear that they reward

58
00:05:28,079 --> 00:05:34,160
top processes. Automated testing, building a testing process in, planning in advance. We've

59
00:05:34,160 --> 00:05:38,320
done a fair amount of that, with like the plan that we did on day five, and then executing it

60
00:05:38,320 --> 00:05:42,880
step by step. Comprehensive documentation, we've been doing that. We've been seeing how that works.

61
00:05:42,880 --> 00:05:48,320
Good version control habits. We've been taking Git checkpoints, but we're doing more this week

62
00:05:48,320 --> 00:05:54,160
with checkpointing built into Cloud Code. And highly effective automation, so we'll certainly

63
00:05:54,160 --> 00:05:59,519
be doing plenty of that this week. And now Simon makes some real pro points, I'd just love to share

64
00:05:59,519 --> 00:06:06,480
with you. A culture of code review, making sure that your LLM reviews its own work. We've done

65
00:06:06,480 --> 00:06:12,320
that already a couple of times, so powerful. A very weird form of management, getting good

66
00:06:12,320 --> 00:06:16,480
results feels uncomfortably close to getting good results out of a human collaborator, but with some

67
00:06:16,480 --> 00:06:23,200
differences that he points out. Really good manual QA, being able to do that as well as the automated

68
00:06:23,200 --> 00:06:28,799
sort. Strong research skills, understanding there's many different ways that you can ask for a problem,

69
00:06:28,799 --> 00:06:33,279
and sometimes you hit a blocker, it's good just to step back and just try again with a different

70
00:06:33,279 --> 00:06:37,519
way of doing it. And having that mindset, which is hard because you want to solve the problem

71
00:06:37,519 --> 00:06:42,720
you've got and knowing when to just try something different, it's a real skill. The ability to

72
00:06:42,720 --> 00:06:48,720
ship a preview is a very interesting point. An instinct for what you can outsource to an AI

73
00:06:48,720 --> 00:06:54,320
and what you cannot. This I just couldn't agree more with Simon, it's such a key point. I've

74
00:06:54,320 --> 00:06:59,279
developed over time this good sense of the fact that, for example, front-end is something that I

75
00:06:59,279 --> 00:07:04,160
can absolutely just delegate to the LLM, it will build a front-end, I can give it some feedback,

76
00:07:04,160 --> 00:07:10,079
it's gonna be great. When it comes to back-end and particularly, say, working actually with LLMs,

77
00:07:10,079 --> 00:07:16,399
it's often struggling. And for example, in week one, day five, I came back and looked at that

78
00:07:16,399 --> 00:07:21,440
main Python module, and whilst it was working, it was a mess, and it had a bunch of things in it

79
00:07:21,440 --> 00:07:27,920
which needed to be refactored. And that's why you need to have a really good instinct for what

80
00:07:27,920 --> 00:07:33,200
are the LLMs reliable at doing, and what are they not, and being able to jump in and help that.

81
00:07:33,200 --> 00:07:39,519
And an interesting point is that the way we estimate projects has changed. It's always been

82
00:07:39,519 --> 00:07:45,519
hard for a software engineer, and now in some ways it's easier, in some ways it's harder. Often, these

83
00:07:45,519 --> 00:07:49,760
tools like Cloud Code will be able to rattle out code really, really quickly, and you get this

84
00:07:49,760 --> 00:07:55,359
false sense that you can accomplish incredible things in minutes, but then you hit a wall, and

85
00:07:55,359 --> 00:07:59,920
then you could be stuck for several hours bashing your head against a wall on something that feels

86
00:07:59,920 --> 00:08:04,959
like it should be really easy. And so you need to factor that into your estimates. As I say,

87
00:08:04,959 --> 00:08:10,640
don't get caught up in the hype of the 10x. There's a huge efficiency improvement here,

88
00:08:10,640 --> 00:08:15,279
and to Andre's point, you can expand your capabilities, but there are definitely drawbacks,

89
00:08:15,279 --> 00:08:21,359
and you need to factor them in. And all of this is kind of summarized here by Simon. He says,

90
00:08:21,440 --> 00:08:25,200
if you're going to really exploit these capabilities, you need to be at the top of

91
00:08:25,200 --> 00:08:31,040
your game. Designing success criteria, remember that. We've done that many times. Designing

92
00:08:31,040 --> 00:08:39,359
agentic loops, planning QA, managing a growing army of weird digital interns who will absolutely

93
00:08:39,359 --> 00:08:46,239
cheat if you give them a chance, and spending so much time on code review. Very wise words.

94
00:08:46,239 --> 00:08:50,880
Read this whole blog post. Link in the resources. This is gold.