Full Walkthrough: Workflow for AI Coding — Matt Pocock

1
00:00:00,000 --> 00:00:05,794
[เสียงดนตรี] >> ครับ เราพร้อมแล้ว ทุกคนครับ เรามาเต็มความจุแล้ว

2
00:00:05,794 --> 00:00:11,128
มาเริ่มกันเลยดีกว่า ผมไม่อยากให้ทุกคนต้องมารออยู่ตรงนี้อีก

3
00:00:11,128 --> 00:00:16,278
25 นาทีเพื่อรอเส้นตายอะไรก็ตาม ขอต้อนรับครับ ผมชื่อแมตต์

4
00:00:16,278 --> 00:00:21,887
เป็นครู และตอนนี้ก็สอนเรื่อง AI ด้วยครับ เรามีลิงก์อยู่ตรงนี้

5
00:00:21,887 --> 00:00:27,957
ถ้ายังไม่ได้เข้าไปดู ก็จะมีแบบฝึกหัดสำหรับสิ่งที่เราจะทำวันนี้ครับ

6
00:00:27,957 --> 00:00:33,199
งานนี้จะใช้เวลาราวๆ 2 ชั่วโมง เราอาจจะเริ่มกันแบบนี้ไปอีก

7
00:00:33,199 --> 00:00:39,636
2 ชั่วโมงข้างหน้า โอเคไหมไมค์? ครับ เยี่ยมเลย แนวคิดเบื้องหลังทอล์กนี้

8
00:00:39,636 --> 00:00:44,327
หรืออย่างน้อยก็ข้อเสนอหลักที่ผมใช้ดำเนินงานมาในช่วง

9
00:00:44,327 --> 00:00:51,132
6 เดือนที่ผ่านมา คือการที่เราทุกคนคิดว่า AI เป็นกระบวนทัศน์ใหม่ใช่ไหมครับ?

10
00:00:51,132 --> 00:00:57,018
AI กำลังเปลี่ยนแปลงหลายอย่างแน่นอน พวกคุณก็สนใจเรื่องนี้อยู่แล้ว

11
00:00:57,018 --> 00:01:02,260
และนั่นคือเหตุผลที่มาฟังทอล์กนี้ และผมรู้สึกว่าเวลาพูดถึง

12
00:01:02,260 --> 00:01:09,157
AI ว่าเป็นกระบวนทัศน์ใหม่ เรามักลืมไปว่า จริงๆ แล้วพื้นฐานวิศวกรรมซอฟต์แวร์

13
00:01:09,157 --> 00:01:14,215
สิ่งที่สำคัญมากในการทำงานร่วมกับมนุษย์ ก็ทำงานได้ดีสุดๆ

14
00:01:14,215 --> 00:01:20,744
กับ AI ด้วยเหมือนกัน และนี่คือสิ่งที่คีย์โน้ตของผมพรุ่งนี้จะพูดถึงจริงๆ

15
00:01:20,744 --> 00:01:26,170
ครับ ผมจะลงรายละเอียดเรื่องนี้ให้มากกว่านี้ ในเวิร์กช็อปนี้

16
00:01:26,170 --> 00:01:33,619
ผมหวังว่าจะได้ชี้ให้พวกคุณเห็นสิ่งเหล่านั้น และหวังว่าจะพิสูจน์ให้เห็นว่าผมพูดถูก

17
00:01:33,619 --> 00:01:39,045
แต่ค่อยว่ากันอีกทีครับ เอาล่ะ ขอสำรวจคร่าวๆ ก่อนได้ไหมครับ?

18
00:01:39,045 --> 00:01:44,471
มีใครบ้างที่เคยเขียนโค้ดกับ AI? ยกมือขึ้นถ้าเคยเขียนโค้ดกับ

19
00:01:44,471 --> 00:01:51,552
AI ครับ เยี่ยม โอเค เก็บมือไว้แบบนั้นนะครับ ให้โลกได้เห็นรักแร้ของเรากันหน่อย

20
00:01:51,552 --> 00:01:56,426
มีใครเขียนโค้ดกับ AI ทุกวันบ้าง? เจ๋ง โอเค เก็บมือไว้

21
00:01:56,426 --> 00:02:01,024
ถ้าเคยหงุดหงิดกับ AI ให้ยกมือขึ้นนะครับ โอเค ดีมาก

22
00:02:01,024 --> 00:02:06,174
วางมือลงได้ครับ ขอบคุณที่เชื่อฟังกันขนาดนี้ ผมซาบซึ้งมาก

23
00:02:06,174 --> 00:02:11,141
และตอนนี้เรากำลังถ่ายทอดสดไปยังห้อง Gilgood ด้วยนะครับ

24
00:02:11,141 --> 00:02:18,130
ผมยังไม่ได้... เราส่งใครไปที่ห้อง Gilgood เพื่อเช็กว่าเขาสบายดีไหมหรือเปล่า?

25
00:02:18,130 --> 00:02:23,648
ไม่รู้เหมือนกัน แต่ผมเห็นพวกคุณ และมีวิธีที่คุณจะร่วมสนุกได้

26
00:02:23,648 --> 00:02:27,970
คือเรามีช่วงถาม-ตอบครับ เราจะทำแบบที่ไม่ค่อยชอบ

27
00:02:27,970 --> 00:02:33,764
Q&A ทั่วไป เพราะมันไม่ค่อยเป็นประชาธิปไตย ส่วนใหญ่คนที่พูดเก่งๆ

28
00:02:33,764 --> 00:02:39,098
เท่านั้นแหละที่ได้มีส่วนร่วมและได้แชร์ ดังนั้นเราจะใช้ระบบ

29
00:02:39,098 --> 00:02:44,339
Q&A แบบนี้กัน แล้วทำไมเราต้องรอถึง 3:45 ล่ะ? ห้องเต็มแล้ว

30
00:02:44,339 --> 00:02:48,846
ประตูปิดแล้ว เห็นด้วย 100% ดังนั้นถ้าอยากถามคำถาม

31
00:02:48,846 --> 00:02:55,191
ผมอยากให้ทุกคนเข้าไปถามในแอป async นี้ แล้วเราก็โหวตคำถามของกันและกัน

32
00:02:55,191 --> 00:02:59,973
หวังว่าคำถามที่ดีที่สุดจะถูกโหวตขึ้นมาให้ทั้งห้องได้

33
00:02:59,973 --> 00:03:04,388
enjoy กัน ผมอยากพูดถึงข้อจำกัดแปลกๆ ของ LLM ก่อน

34
00:03:04,388 --> 00:03:10,917
และข้อจำกัดแปลกๆ เหล่านั้นคือสิ่งที่เราต้องใช้เป็นฐานในการทำงานส่วนใหญ่

35
00:03:10,917 --> 00:03:15,239
มีคนชื่อ Dex Hardy บริหารบริษัทชื่อ Human Layer

36
00:03:15,239 --> 00:03:19,654
เขาเสนอแนวคิดว่าเวลาทำงานกับ LLM พวกมันมีโซนฉลาด

37
00:03:19,654 --> 00:03:24,896
(smart zone) กับโซนโง่ (dumb zone) ตอนที่คุณเริ่มทำงานกับ

38
00:03:24,896 --> 00:03:30,413
LLM ครั้งแรก เหมือนเพิ่งเริ่มคอนเวอร์เซชันใหม่ เริ่มจากศูนย์

39
00:03:30,413 --> 00:03:35,655
นั่นคือตอนที่ LLM จะทำงานได้ดีที่สุด เพราะในสถานการณ์นั้น

40
00:03:35,655 --> 00:03:40,346
ความสัมพันธ์ของ attention (attention relationships)

41
00:03:40,346 --> 00:03:44,852
ถูกบีบรัดน้อยที่สุด ทุกครั้งที่คุณเพิ่ม token ให้

42
00:03:44,852 --> 00:03:49,266
LLM มันเหมือนกับการเพิ่มทีมใหม่เข้าไปในลีกฟุตบอล

43
00:03:49,266 --> 00:03:55,703
ลองคิดดูว่าจำนวนแมตช์เพิ่มขึ้นแค่ไหนทุกครั้งที่เพิ่มทีมใหม่ในลีกฟุตบอล

44
00:03:55,703 --> 00:04:00,853
มันขยายตัวแบบกำลังสอง (quadratic) เพราะมีความสัมพันธ์ของ

45
00:04:00,853 --> 00:04:08,119
attention ระหว่างทุก token กับ token อื่นๆ ทั้งในเชิงตำแหน่งและความหมายของแต่ละ

46
00:04:08,119 --> 00:04:12,809
token ดังนั้น พอถึงราวๆ 40% หรือผมว่าที่ประมาณ 100K

47
00:04:12,809 --> 00:04:18,143
คือจุดวัดใหม่ของผมสำหรับเรื่องนี้ เพราะไม่สำคัญว่าคุณจะใช้

48
00:04:18,143 --> 00:04:23,385
context window ขนาด 1 ล้าน หรือ 200K ผลมันจะประมาณนี้เสมอ

49
00:04:23,385 --> 00:04:27,799
เริ่มโง่ลงเรื่อยๆ ยิ่งคุณเติมของเข้าไปใน context

50
00:04:27,799 --> 00:04:33,501
window เดิมเรื่อยๆ มันก็ยิ่งโง่ลงเรื่อยๆ จนกระทั่งตัดสินใจโง่ๆ

51
00:04:33,501 --> 00:04:41,593
ยกมือขึ้นถ้ารู้สึกคุ้นเคยกับอาการนี้ ใช่ เจ๋ง นี่แปลว่าเราควรแบ่งขนาดงานให้อยู่ในโซนฉลาด

52
00:04:41,593 --> 00:04:46,651
ใช่ไหมครับ? เราไม่อยากให้ AI รับปากเกินตัว คำแนะนำเก่าๆ

53
00:04:46,651 --> 00:04:51,250
อย่าง Martin Fowler ในหนังสือ Refactoring หรือ The

54
00:04:51,250 --> 00:04:56,584
Pragmatic Programmer ก็พูดถึงเรื่องนี้ อย่ากัดเกินคำเคี้ยว

55
00:04:56,584 --> 00:05:04,952
ทำงานเล็กๆ ไว้ เพื่อที่ตัวคุณในฐานะนักพัฒนา จะได้ไม่เครียดจนทำอะไรไม่ถูกและตกไปอยู่ในโซนโง่

56
00:05:04,952 --> 00:05:09,642
แต่จะจัดการงานใหญ่ยังไงล่ะ? ถ้ามีงานใหญ่ๆ แบบว่า...

57
00:05:09,642 --> 00:05:15,160
ไม่รู้สิ อย่างการลอกเลียนบริษัททั้งบริษัท หรือทำอะไรที่บ้าบอ

58
00:05:15,160 --> 00:05:19,850
จะแบ่งมันเป็นงานย่อยๆ ยังไงให้ทุกส่วนอยู่ในโซนฉลาด?

59
00:05:19,850 --> 00:05:24,908
วิธีหนึ่งที่คุณทำได้ คือแบบที่บริษัท AI อาจอยากให้คุณทำ

60
00:05:24,908 --> 00:05:31,622
หรือวิธีธรรมชาติก็คือทำไปเรื่อยๆ ไปเรื่อยๆ จนสุดท้ายคุณก็ตกไปอยู่ในโซนโง่

61
00:05:31,622 --> 00:05:36,128
เสีย token เต็มจำนวนต่อทุก request แล้วก็ compact

62
00:05:36,128 --> 00:05:42,657
(บีบอัด) กลับลงมา เดี๋ยวเราจะพูดถึงการ compact อย่างจริงจังในอีกสักครู่

63
00:05:42,657 --> 00:05:47,072
แล้วก็ทำต่อไปเรื่อยๆ compact ลงมา ทำต่อไปเรื่อยๆ

64
00:05:47,072 --> 00:05:51,394
ผมว่าวิธีนั้นไม่ค่อยเวิร์คเท่าไหร่ เพราะยิ่ง...

65
00:05:51,394 --> 00:05:55,808
[ฟังไม่ชัด] เดี๋ยวจะพูดถึงอีกที ทฤษฎีของผมตอนนี้

66
00:05:55,808 --> 00:06:00,774
และที่ผมทำมาสักพัก คือการใช้แผนแบบหลายเฟส (multi-phase

67
00:06:00,774 --> 00:06:05,924
plan) คือผมจะบอกว่า "โอเค เรามีงานใหญ่ๆ อยู่งานนึงตรงนี้

68
00:06:05,924 --> 00:06:11,718
มาแบ่งเป็นส่วนเล็กๆ กัน แล้วค่อยๆ แยกย่อยทำงานทีละนิดในโซนฉลาด"

69
00:06:11,718 --> 00:06:18,523
ยกมือขึ้นถ้าเคยใช้แผนแบบหลายเฟส ใช่ เป็นวิธีปฏิบัติที่ธรรมดามากใช่ไหมครับ?

70
00:06:18,523 --> 00:06:25,972
นี่คือวิธีที่เราทำกันมา จริงๆ แล้วนี่คือวิธีที่ผมทำมาจนถึงธันวาคมปีที่แล้วเลยแหละ

71
00:06:25,972 --> 00:06:30,295
และนักพัฒนาที่เก่งจริงๆ จะมองแล้วบอกว่า "นี่มัน

72
00:06:30,295 --> 00:06:34,709
loop ชัดๆ" ใช่ไหม? นี่คือ loop เรามีเฟสหนึ่ง สอง

73
00:06:34,709 --> 00:06:40,687
สาม สี่ แล้วทำไมเราไม่ใช้แค่เฟส N ล่ะ? เฟส N คือเราจะพูดประมาณว่า

74
00:06:40,687 --> 00:06:45,285
"โอเค เรามีแผนทำงานอยู่เบื้องหลัง แล้วเราก็วน loop

75
00:06:45,285 --> 00:06:49,791
ทับมันไปเรื่อยๆ จนกว่าจะเสร็จ" และนี่คือจุดที่...

76
00:06:49,791 --> 00:06:56,137
ยกมือขึ้นถ้าเคยได้ยินคำว่า Ralph Wiggum ในฐานะแนวปฏิบัติด้านซอฟต์แวร์

77
00:06:56,137 --> 00:07:00,919
โอเค เจ๋ง ทีนี้ยกมือขึ้นถ้าไม่เคยได้ยิน Ralph Wiggum

78
00:07:00,919 --> 00:07:05,425
ในฐานะแนวปฏิบัติด้านซอฟต์แวร์ อันนั้นดูสมจริงกว่า

79
00:07:05,425 --> 00:07:11,311
โอเค มีแนวคิดที่ชื่อว่า Ralph Wiggum ซึ่งมีพื้นฐานมาจากเรื่องนี้

80
00:07:11,311 --> 00:07:16,369
คือสิ่งที่คุณต้องทำก็แค่ระบุจุดหมายปลายทางของการเดินทาง

81
00:07:16,369 --> 00:07:20,691
คือคุณแค่บอกว่า "โอเค เราสร้าง PRD หรือ product

82
00:07:20,691 --> 00:07:25,013
requirements document (เอกสารข้อกำหนดผลิตภัณฑ์)

83
00:07:25,013 --> 00:07:29,428
ขึ้นมา เพื่ออธิบายว่าเราจะไปทางไหน" จากนั้นก็บอก

84
00:07:29,428 --> 00:07:37,153
AI ว่า "แก้เล็กๆ น้อยๆ หน่อย แก้ทีละนิดที่จะพาเราเข้าใกล้เป้าหมายนั้นมากขึ้นเรื่อยๆ"

85
00:07:37,153 --> 00:07:42,946
Ralph ใช้ได้โอเค ครับ แต่ผมชอบอะไรที่มีโครงสร้างมากกว่านี้หน่อย

86
00:07:42,946 --> 00:07:49,936
นี่คือจุดที่เราคุยกันเรื่องโซนฉลาด และนี่คือจุดแรกที่ผมอยากให้คุณเริ่มคิดถึง

87
00:07:49,936 --> 00:07:55,453
อีกหนึ่งข้อจำกัดแปลกๆ ของ LLM คือ LLM เป็นเหมือนพระเอกในหนัง

88
00:07:55,453 --> 00:08:02,902
Memento (จดจำไม่ได้สักที) คือมันลืมตลอดเวลา มันรีเซ็ตกลับไปสู่สถานะพื้นฐานได้ตลอด

89
00:08:02,902 --> 00:08:09,064
ขอเปิดไดอะแกรมนี้หน่อย ผมควรใช้สไลด์จริงๆ แต่ผมชอบเลื่อนดูไปเรื่อยๆ

90
00:08:09,064 --> 00:08:13,478
บนแคนวาส tldraw แบบไม่มีที่สิ้นสุดมากกว่า ขอบคุณ

91
00:08:13,478 --> 00:08:17,985
Steve อีกแนวคิดที่อยากให้คุณจำไว้ คือทุกเซสชันกับ

92
00:08:17,985 --> 00:08:22,675
LLM จะผ่านขั้นตอนเดิมๆ เหมือนกัน อย่างแรกคือ system

93
00:08:22,675 --> 00:08:27,825
prompt (พรอมป์ระบบ) ตรงนี้ กล่องสีเทานี้คือสิ่งที่อยู่ใน

94
00:08:27,825 --> 00:08:33,342
context ของคุณตลอดเวลา คุณอยากให้มันเล็กที่สุดเท่าที่จะทำได้

95
00:08:33,342 --> 00:08:40,332
เพราะถ้ามีของเยอะแยะในนี้ ถ้ามี 250K tokens ซึ่งผมเคยเห็นคนใส่เข้าไปขนาดนั้น

96
00:08:40,332 --> 00:08:46,861
คุณจะพุ่งเข้าโซนโง่ทันทีโดยไม่ต้องทำอะไรเลย ดังนั้นอยากให้มันจิ๋วที่สุด

97
00:08:46,861 --> 00:08:52,195
>> [หัวเราะเบาๆ] >> จากนั้นก็เข้าสู่ช่วงสำรวจ (exploratory

98
00:08:52,195 --> 00:08:57,713
phase) ส่วนสีฟ้านี้คือตอนที่ coding agent (เอเจนต์เขียนโค้ด)

99
00:08:57,713 --> 00:09:02,679
ออกไปสำรวจโค้ดเบส แล้วก็เข้าสู่การ implement (ลงมือทำ)

100
00:09:02,679 --> 00:09:07,553
จากนั้นก็การทดสอบ ตรวจสอบว่ามันทำงานได้ วิ่ง feedback

101
00:09:07,553 --> 00:09:14,634
loop (วงจรป้อนกลับ) อะไรแบบนี้ ยกมือขึ้นถ้ารู้สึกคุ้นเคยกับสิ่งที่ตัวเองเคยทำ

102
00:09:14,634 --> 00:09:19,508
ใช่ นี่คือเสาหลักของทุกเซสชัน และเมื่อคุณล้าง context

103
00:09:19,508 --> 00:09:24,658
คุณก็กลับไปที่ system prompt ทันที โอ๊ย กลับไปตรงนั้นเลย

104
00:09:24,658 --> 00:09:29,532
คือลบทุกอย่างที่ผ่านมาแล้ว ยกมือขึ้นถ้าเคยได้ยินคำว่า

105
00:09:29,532 --> 00:09:35,602
compacting (การบีบอัด) ด้วย ใช่ โอเค บางคนอาจยังไม่เคยได้ยินเรื่อง

106
00:09:35,602 --> 00:09:40,016
compacting เดี๋ยวขอสาธิตให้ดูเร็วๆ ว่ามันคืออะไร

107
00:09:40,016 --> 00:09:45,442
เช่น ผมเพิ่งคุยกับ LLM ของผมไปนิดหน่อย ผมอยากให้แน่ใจว่าเรา

108
00:09:45,442 --> 00:09:50,132
cover พื้นฐานกันแล้วจะได้เข้าใจตรงกัน ผมเพิ่งคุยกับ

109
00:09:50,132 --> 00:09:54,822
LLM เรื่องสิ่งที่อยากจะสร้าง แบบอักษรเป็นยังไงบ้าง?

110
00:09:54,822 --> 00:09:59,421
ควรเพิ่มขนาดไหม? คนแถวหลังว่าไง? เพิ่ม เพิ่ม เพิ่ม

111
00:09:59,421 --> 00:10:04,847
เพิ่ม เพิ่ม โอเค ผมใช้ Claude Code (เครื่องมือเขียนโค้ดด้วย

112
00:10:04,847 --> 00:10:09,445
AI) ในเซสชันนี้ แต่คุณไม่จำเป็นต้องใช้ Claude Code

113
00:10:09,445 --> 00:10:14,227
ที่จริงแล้ว การไม่ใช้ Claude Code ก็มักจะดีเหมือนกัน

114
00:10:14,227 --> 00:10:20,388
ผมเพิ่งคุยกับ LLM เรื่องวางแผนว่าต่อไปจะทำอะไร มันถามคำถามผมหลายข้อ

115
00:10:20,388 --> 00:10:25,171
และผมแนะนำให้คุณทำแบบนี้มากๆ ตรงนี้มีสเตตัสไลน์เล็กๆ

116
00:10:25,171 --> 00:10:30,596
ที่บอกว่าผมใช้ token ไปกี่ตัว จำนวน token ที่แน่นอนที่ผมใช้

117
00:10:30,596 --> 00:10:35,103
ผมมีบทความบนเว็บ AI Hero ถ้าอยากลอกโค้ดไปใช้ อุ๊ย

118
00:10:35,103 --> 00:10:40,529
ว้าว มันสั่นนะเนี่ย? นี่คือข้อมูลจำเป็นของทุกโค้ดดิ้งเซสชัน

119
00:10:40,529 --> 00:10:47,794
เพราะคุณต้องรู้ว่ากำลังใช้ token ไปเท่าไหร่ เพื่อจะได้รู้ว่าคุณใกล้โซนโง่แค่ไหน

120
00:10:47,794 --> 00:10:54,691
สำคัญมากๆ เลย มาดูกัน ผมมีสองตัวเลือก คือล้างทั้งหมดแล้วกลับไปเริ่มจากศูนย์

121
00:10:54,691 --> 00:11:00,209
หรือไม่ก็ compact และเมื่อผม compact มันจะบีบการสนทนาทั้งหมด

122
00:11:00,209 --> 00:11:05,451
ซึ่งจริงๆ ก็ไม่มากเท่าไหร่ ให้ไปอยู่ในพื้นที่ที่เล็กลงมาก

123
00:11:05,451 --> 00:11:11,704
ถ้าเป็นแผนภาพก็จะประมาณนี้ คือคุณนำข้อมูลทั้งหมดจากเซสชันมาสร้างเป็น

124
00:11:11,704 --> 00:11:17,314
history (ประวัติ) บันทึกเป็นลายลักษณ์อักษรว่าเกิดอะไรขึ้นบ้าง

125
00:11:17,314 --> 00:11:22,924
นักพัฒนาเนี่ยชอบ compacting ด้วยเหตุผลบางอย่าง แต่ผมเกลียดมัน

126
00:11:22,924 --> 00:11:27,706
ผมชอบให้ AI ของผม behave แบบพระเอกใน Memento มากกว่า

127
00:11:27,706 --> 00:11:32,672
เพราะสเตตัสนี้จะเหมือนเดิมเสมอ เหมือนเดิมทุกครั้งที่ทำ

128
00:11:32,672 --> 00:11:37,270
คุณล้างแล้วกลับไปจุดเริ่มต้น ถ้าคุณทำแบบนั้นได้และ

129
00:11:37,270 --> 00:11:41,593
optimize เพื่อมันได้ คุณก็อยู่ในจุดที่ยอดเยี่ยม

130
00:11:41,593 --> 00:11:48,582
นี่คือสองสิ่งที่อยากให้คิดถึงกับ LLM ซึ่งเป็นข้อจำกัดสองอย่างที่เราทำงานด้วย

131
00:11:48,582 --> 00:11:53,364
พวกมันมีโซนฉลาดกับโซนโง่ และเป็นเหมือนพระเอก Memento

132
00:11:53,364 --> 00:11:59,158
งั้นมาดูแบบฝึกหัดแรกกัน และระหว่างที่ผมทำ วิธีที่อยากให้เป็นคือ

133
00:11:59,158 --> 00:12:04,124
ผมจะสาธิตให้ดูบนจอ และอยากให้พวกคุณลงมือพิมพ์ตามไปด้วย

134
00:12:04,124 --> 00:12:09,550
นั่นเป็นแค่ส่วนบรรยายเล็กน้อย ต่อไปมาลงมือเขียนโค้ดกันจริงๆ

135
00:12:09,550 --> 00:12:15,343
สำหรับใครที่มาสาย หรือใครที่อยู่ในห้อง Gilgood ให้ไปที่ลิงก์นี้

136
00:12:15,343 --> 00:12:19,942
ลิงก์ด้านบนนี้ เพื่อดูแบบฝึกหัดและ clone โค้ด repo

137
00:12:19,942 --> 00:12:26,747
(ที่เก็บโค้ด) ไป ไม่จำเป็นต้องทำตามก็ได้ จะนั่งดูผมทำอย่างเดียวก็ได้ถ้าชอบ

138
00:12:26,747 --> 00:12:31,161
แต่ผมจะเข้าไปดูเองก่อน ว่าแบบฝึกหัดอะไรรอเราอยู่

139
00:12:31,161 --> 00:12:38,150
จริงๆ แล้วผมสร้างแพลตฟอร์มนี้มาจากคอร์สของผม มันคือแพลตฟอร์มจัดการคอร์สเรียน

140
00:12:38,150 --> 00:12:42,933
เป็น CMS (ระบบจัดการเนื้อหา) สำหรับผู้สอนและผู้เรียน

141
00:12:42,933 --> 00:12:49,830
และนี่คือสิ่งที่เราจะสร้างฟีเจอร์ใหม่ให้ วันนี้ผมจะพาคุณจากไอเดียของฟีเจอร์

142
00:12:49,830 --> 00:12:54,244
ไปจนถึงการสร้าง PRD สำหรับฟีเจอร์นั้น ไปจนถึงการ

143
00:12:54,244 --> 00:13:01,877
implement ฟีเจอร์จริง และหวังว่าคุณจะได้แรงบันดาลใจจากกระบวนการนี้ไปใช้กับงานตัวเอง

144
00:13:01,877 --> 00:13:08,315
เริ่มกันเลย เราจะเริ่มด้วยการใช้ skill (ทักษะ) ที่ผมผูกพันมากเป็นพิเศษ

145
00:13:08,315 --> 00:13:12,637
มันคือ grill me skill grill me skill นี้เล็กมาก

146
00:13:12,637 --> 00:13:19,074
เล็กสุดๆ และช่วยป้องกันหนึ่งในปัญหาหลักที่ผมคิดว่าเกิดขึ้นเวลาทำงานกับ

147
00:13:19,074 --> 00:13:25,788
AI นั่นคือการเข้าใจผิดกัน (misalignment) แนวคิดที่ผมกำลังเถียงด้วยอยู่นี่

148
00:13:25,788 --> 00:13:30,386
คือกระแส specs to code (เขียนสเปกแล้วแปลงเป็นโค้ด)

149
00:13:30,386 --> 00:13:34,984
มีใครเคยได้ยินกระแส specs to code บ้าง? ยกมือหน่อย

150
00:13:34,984 --> 00:13:39,674
มันไม่เชิงเป็นกระแสขนาดนั้นหรอก มันก็แค่คนพูดกันว่า

151
00:13:39,674 --> 00:13:45,008
specs to code มันคือการที่คนพูดว่า "โอเค คุณจะเขียนโปรแกรม

152
00:13:45,008 --> 00:13:51,354
หรืออยากสร้างแอป วิธีที่ดีที่สุดคือการเขียนสเปกหรือเอกสารอะไรสักอย่าง

153
00:13:51,354 --> 00:13:56,044
แล้วก็แปลงเอกสารนั้นเป็นโค้ด" แล้วก็แปลงเป็นโค้ดเลย

154
00:13:56,044 --> 00:14:01,562
จะทำยังไง? ส่งให้ AI ทำ ถ้าโค้ดที่ได้มีปัญหา คุณไม่ดูที่โค้ด

155
00:14:01,562 --> 00:14:06,344
แต่กลับไปดูที่สเปก แก้สเปก แล้วก็ทำวนแบบนี้ไปเรื่อยๆ

156
00:14:06,344 --> 00:14:11,034
นี่มันคือ vibe coding (เขียนโค้ดแบบมั่วๆ ตามอารมณ์)

157
00:14:11,034 --> 00:14:17,379
อีกชื่อหนึ่ง ที่จริงๆ แล้วคุณกำลังเมินโค้ดทิ้ง คุณไม่ต้องกังวลกับโค้ด

158
00:14:17,379 --> 00:14:22,345
แค่แก้สเปกไปเรื่อยๆ แล้วก็ทำต่อไป ผมลองแล้วนะ ลองจริงๆ

159
00:14:22,345 --> 00:14:26,760
และมันแย่มาก ไม่เวิร์ค เพราะคุณต้องควบคุมโค้ดไว้

160
00:14:26,760 --> 00:14:31,082
คุณต้องเข้าใจว่ามีอะไรอยู่ในนั้น คุณต้องปั้นมัน

161
00:14:31,082 --> 00:14:36,140
เพราะโค้ดคือสนามรบของคุณ และนี่คือจุดที่เรากำลังจะไปกัน

162
00:14:36,140 --> 00:14:40,554
มาดูแบบฝึกหัดกัน สิ่งที่อยากให้ทำคือไปที่หน้านี้

163
00:14:40,554 --> 00:14:45,153
grill me skill แล้วใน repo นี้ เรามี slack message

164
00:14:45,153 --> 00:14:49,935
(ข้อความใน Slack) จากเพื่อนเรา อยู่ไหนนะ? มันอยู่ที่

165
00:14:49,935 --> 00:14:54,441
root ของ repo อยู่ใน... อ่า อยู่ไหนนะ? อืม client

166
00:14:54,441 --> 00:15:00,235
brief.md มันคือ slack message จาก Sarah Chen ด้วยเหตุผลบางอย่าง

167
00:15:00,235 --> 00:15:06,028
Claude ชอบเลือกชื่อ Sarah Chen เสมอ ไม่รู้ทำไม เนื้อหาประมาณว่า

168
00:15:06,028 --> 00:15:10,535
บนแพลตฟอร์มคอร์สเรียนของเราที่ชื่อ Cadence ตัวเลข

169
00:15:10,535 --> 00:15:18,719
retention (การรักษาผู้ใช้ให้อยู่ต่อ) ไม่ค่อยดี นักเรียนสมัครเรียนสองสามบทเรียนแล้วก็หายไป

170
00:15:18,719 --> 00:15:24,053
อยากเพิ่ม gamification (การทำให้เป็นเกม) เข้าไปในแพลตฟอร์ม

171
00:15:24,053 --> 00:15:29,111
และเมื่อคุณเจอไอเดียแบบนี้ คุณต้องหาทางทำให้มันเป็นจริง

172
00:15:29,111 --> 00:15:34,905
สมมติว่า Sarah Chen เป็นลูกค้าของคุณ งบจำกัด ต้องทำให้เสร็จเร็ว

173
00:15:34,905 --> 00:15:39,319
จะเริ่มยังไงดี? ยกมือขึ้นถ้าจะเข้าโหมด plan mode

174
00:15:39,319 --> 00:15:44,377
(โหมดวางแผน) ตอนทำเรื่องนี้ มีใครใช้ plan mode ตัวหนักๆ

175
00:15:44,377 --> 00:15:49,251
บ้าง? ใช่ อีก ใครมีไอเดียอื่นว่าจะทำยังไงกับเรื่องนี้

176
00:15:49,251 --> 00:15:54,585
ยกมือขึ้น อย่างแรกที่คุณจะทำคืออะไร? ใช่ ขอข้อมูลเพิ่มเติม

177
00:15:54,585 --> 00:15:59,735
อะไรนะ? ขอข้อมูลเพิ่มเติมเพื่อยืนยันว่าจุดประสงค์คืออะไร

178
00:15:59,735 --> 00:16:04,793
และสถานะตอนนี้เราอยู่ตรงไหน ใช่ ถูกต้อง ลองจินตนาการว่า

179
00:16:04,793 --> 00:16:09,116
Sarah Chen ไปเที่ยวพักร้อน แล้วคุณไม่รู้อะไรเลย

180
00:16:09,116 --> 00:16:13,990
เธอเพิ่งโพสต์ข้อความนี้มา และคุณต้องจัดการมันก่อนจะไป

181
00:16:13,990 --> 00:16:19,324
ผมจะเริ่มจาก skill ตัวนี้ ผมจะล้าง context ผมจะเอาคุณออกไป

182
00:16:19,324 --> 00:16:24,198
ไม่ต้องอยู่ตรงนั้นแล้ว แล้วผมจะเรียกใช้ skill ที่ชื่อ

183
00:16:24,198 --> 00:16:29,532
grill me skill ขอเช็กหน่อย ยกมือขึ้นถ้าไม่รู้ว่านี่คืออะไร

184
00:16:29,532 --> 00:16:39,280
เจ๋ง โอ้ ขอโทษๆ ขอพูดให้เฉพาะเจาะจงกว่านี้ ยกมือขึ้นถ้าไม่รู้ว่าผมกำลังทำอะไรอยู่ตอนที่พิมพ์เครื่องหมายทับ

185
00:16:39,280 --> 00:16:44,154
(/) แล้วตามด้วยคำสั่ง มีใครพอเข้าใจบ้างว่ามันคืออะไร?

186
00:16:44,154 --> 00:16:48,936
ผมกำลังเรียกใช้ skill ผมกำลังเรียกใช้ grill me skill

187
00:16:48,936 --> 00:16:53,626
และสิ่งที่ผมจะทำคือพิมพ์ว่า grill me แล้วส่ง client

188
00:16:53,626 --> 00:16:58,132
brief (เอกสารสรุปความต้องการลูกค้า) เข้าไป ตอนนี้

189
00:16:58,132 --> 00:17:04,018
LLM มีของอยู่แค่ไม่กี่อย่าง คือ skill กับคำอธิบายว่าผมอยากทำอะไร

190
00:17:04,018 --> 00:17:08,892
และนี่คือวิธีที่ผมเริ่มงานทุกชิ้นกับ AI แทบจะทุกครั้ง

191
00:17:08,892 --> 00:17:13,214
และระหว่างที่มันสำรวจโค้ดเบส ผมจะให้ดูว่า grill

192
00:17:13,214 --> 00:17:18,088
me skill ทำอะไรบ้าง skill นี้อยู่ใน repo คุณเปิดดูได้

193
00:17:18,088 --> 00:17:23,882
มันสั้นมากๆ "สัมภาษณ์ฉันอย่างไม่ลดละเกี่ยวกับทุกแง่มุมของแผนนี้

194
00:17:23,882 --> 00:17:28,664
จนกว่าเราจะเข้าใจตรงกัน เดินไล่ไปตามกิ่งของ decision

195
00:17:28,664 --> 00:17:33,171
tree (แผนผังการตัดสินใจ) แต่ละกิ่ง แก้ dependency

196
00:17:33,171 --> 00:17:37,677
(ความสัมพันธ์ระหว่างงาน) ทีละอัน สำหรับแต่ละคำถาม

197
00:17:37,677 --> 00:17:41,999
ให้คำตอบที่คุณแนะนำ ถามทีละคำถาม อะไรประมาณนี้"

198
00:17:41,999 --> 00:17:46,505
สิ่งที่ skill นี้ทำ และสิ่งที่ผมสังเกตตอนทำงานกับ

199
00:17:46,505 --> 00:17:52,667
AI โดยเฉพาะในโหมด plan mode คือมันกระตือรือร้นมากที่จะสร้างแผนให้ผม

200
00:17:52,667 --> 00:17:57,265
มันจะบอกว่า "โอเค ผมว่าข้อมูลเพียงพอแล้ว ฉันจะปุ๊บ

201
00:17:57,265 --> 00:18:04,346
แผน แผน เลยนะ" และสิ่งที่ผมพบคือ ผมกำลังพยายามหาคำพูดให้สิ่งที่ผมต้องการจริงๆ

202
00:18:04,346 --> 00:18:08,853
แทนที่จะเป็นแบบนั้น Frederick P. Brooks ในหนังสือ

203
00:18:08,853 --> 00:18:14,738
The Design of Design มีคำพูดที่ยอดเยี่ยมเกี่ยวกับแนวคิดการออกแบบ

204
00:18:14,738 --> 00:18:22,095
(design concept) เวลาคุณทำงานใหม่ๆ กับใครสักคน ตอนที่ทุกคนพยายามสร้างอะไรด้วยกัน

205
00:18:22,095 --> 00:18:26,418
จะมีความคิดร่วมกันที่แชร์ระหว่างผู้ร่วมงานทุกคน

206
00:18:26,418 --> 00:18:32,303
และนั่นคือ design concept และนั่นคือสิ่งที่ผมรู้ตัวว่าต้องการกับ

207
00:18:32,303 --> 00:18:37,177
Claude ผมต้องเข้าใจตรงกัน ผมต้องการ asset (ทรัพย์สิน)

208
00:18:37,177 --> 00:18:42,879
ไม่ใช่แผน ผมต้องอยู่ในคลื่นความถี่เดียวกับ AI หรือเอเจนต์ของผม

209
00:18:42,879 --> 00:18:47,385
และนี่คือวิธีที่ได้ผลมาก หวังว่า... เอาล่ะ เยี่ยม

210
00:18:47,385 --> 00:18:52,260
มันสำรวจเสร็จแล้ว มันเรียกใช้ sub agent (เอเจนต์ย่อย)

211
00:18:52,260 --> 00:18:57,593
ซึ่งใช้ไป 93.7K tokens บนโมเดล Opus แล้วก็ถามคำถามแรกกับผม

212
00:18:57,593 --> 00:19:02,100
เจ๋ง เราจะเห็นว่าแม้ sub agent จะเผา token ไปเยอะ

213
00:19:02,100 --> 00:19:06,790
แต่ token ที่ผมใช้จริงไม่ได้เพิ่มขึ้นมากมายขนาดนั้น

214
00:19:06,790 --> 00:19:11,664
ยกมือขึ้นถ้าไม่รู้ว่า sub agent คืออะไร คำถามนี้สำคัญ

215
00:19:11,664 --> 00:19:17,274
ทุกคนพอเข้าใจไหมว่า sub agent คืออะไร? โอเค ขอให้คำนิยามสั้นๆ

216
00:19:17,274 --> 00:19:22,148
ตัว sub agent ตรงนี้ ตัว explore sub agent มันไปเรียก

217
00:19:22,148 --> 00:19:26,654
LLM อีกตัวหนึ่งซึ่งมี context window แยกเป็นอิสระ

218
00:19:26,654 --> 00:19:32,724
แล้ว LLM ตัวนั้นก็รายงานสรุปกลับมา sub agent ก็เหมือนการมอบหมายงาน

219
00:19:32,724 --> 00:19:38,241
(delegation) คุณมอบงานให้ sub agent มันก็ไปทำอย่างขะมักเขม้น

220
00:19:38,241 --> 00:19:43,575
สำรวจของเยอะแยะ แล้วก็ค่อยๆ ส่งเฉพาะส่วนสำคัญกลับขึ้นมาให้

221
00:19:43,575 --> 00:19:48,174
orchestrator agent (เอเจนต์หลัก) หรือ parent agent

222
00:19:48,174 --> 00:19:52,496
(เอเจนต์แม่) โอเค หวังว่าทุกคนจะเห็นแบบเดียวกัน

223
00:19:52,496 --> 00:19:57,554
มันสำรวจเสร็จแล้ว และตอนนี้เรามีคำถามแรกแล้ว "ระบบคะแนน

224
00:19:57,554 --> 00:20:02,704
(points economy) การกระทำแบบไหนได้คะแนน และได้เท่าไหร่?"

225
00:20:02,704 --> 00:20:08,406
โอเค ระหว่างนี้คุณถามมันเพื่อทำความเข้าใจ repo ให้ลึกขึ้นก็ได้

226
00:20:08,406 --> 00:20:14,935
ผมรู้จัก repo นี้ดีมากเพราะผมเขียนมันเอง แต่คุณอาจไม่รู้ว่ามันเป็นยังไง

227
00:20:14,935 --> 00:20:20,453
ขอเสนอคำแนะนำผม คือให้ง่ายไว้ก่อน เริ่มจากแหล่งคะแนนสองแหล่ง

228
00:20:20,453 --> 00:20:25,879
สิ่งที่เจ๋งคือไม่เพียงแต่มันให้คำถามที่ทำให้เราเข้าใจตรงกัน

229
00:20:25,879 --> 00:20:31,029
แต่เรายังได้คำแนะนำด้วย และบ่อยครั้งที่ผมพบว่าคำแนะนำของ

230
00:20:31,029 --> 00:20:35,995
AI ดีมากจริงๆ ผมก็จะตอบว่า ข้าม event การดูวิดีโอไปเลย

231
00:20:35,995 --> 00:20:40,961
มัน noisy (มีสัญญาณรบกวน) และโกงได้ง่าย ใช่ ผมเห็นด้วย

232
00:20:40,961 --> 00:20:45,927
Sarah ขอให้เก็บบทเรียนเป็นแก่นหลักไว้ ใช่ ดูดีนะเพื่อน

233
00:20:45,927 --> 00:20:51,721
>> [หัวเราะเบาๆ] >> สิ่งที่ผมมักจะทำคือ ผมมักจะสั่งด้วยเสียงกับ

234
00:20:51,721 --> 00:20:57,698
AI จริงๆ แล้วผมพูดคุยกับ AI แทนการพิมพ์ แต่แล็ปท็อปเครื่องนี้ใหม่

235
00:20:57,698 --> 00:21:02,113
และผมลงซอฟต์แวร์สั่งเสียงไม่สำเร็จ เพราะ Windows

236
00:21:02,113 --> 00:21:07,354
มันห่วย แล้วก็ คำถามที่ว่า คะแนนควรย้อนหลัง (retroactive)

237
00:21:07,354 --> 00:21:12,412
ไหม? มันมีบันทึกความก้าวหน้าของบทเรียนเดิมอยู่แล้วพร้อม

238
00:21:12,412 --> 00:21:16,919
timestamp ตอนเรียนจบ นี่เป็นคำถามหินจริงๆ ใช่ไหม?

239
00:21:16,919 --> 00:21:21,701
เราควรย้อนกลับไป backfill (เติมข้อมูลย้อนหลัง) event

240
00:21:21,701 --> 00:21:28,506
ความก้าวหน้าบทเรียนทั้งหมดไหม? นี่คือคำถามประเภทที่คุณต้องตกลงกันให้ชัดเจน

241
00:21:28,506 --> 00:21:33,196
ถ้าจะทำฟีเจอร์นี้ให้ถูกต้อง ผมไม่ได้คิดถึงเรื่องนี้

242
00:21:33,196 --> 00:21:38,714
และ Sarah Chen ก็ไม่ได้คิดถึงแน่นอน ผมอยากให้มันย้อนหลังไหม?

243
00:21:38,714 --> 00:21:43,496
อืม ลองโหวตกันในห้องนี้ดีกว่า ควรย้อนกลับไป backfill

244
00:21:43,496 --> 00:21:48,186
ข้อมูลทั้งหมดไหม? ยกมือขึ้นถ้าคิดว่าเราควร backfill

245
00:21:48,186 --> 00:21:53,244
ทั้งหมด ยกมือขึ้นถ้าคิดว่าไม่ควร backfill มีคนนั่งกลางๆ

246
00:21:53,244 --> 00:21:58,211
ในห้องเยอะเลย ผมจะบอกว่า นี่คือการสนทนาแบบที่คุณคุยกับ

247
00:21:58,211 --> 00:22:03,912
AI คุณกำลังเข้าใจตรงกันมากขึ้นเรื่อยๆ ใช่ ผมจะตามคำแนะนำของมัน

248
00:22:03,912 --> 00:22:08,235
เพราะผมขี้เกียจ สังเกตด้วยว่าผมอยู่ในวงวนกับ AI

249
00:22:08,235 --> 00:22:14,304
ได้ตลอด ผมไม่ต้อง... มันยิงคำถามมาให้ผมเร็วมาก ผมไม่ต้องเผลอไปเปิด

250
00:22:14,304 --> 00:22:18,810
Twitter หรืออะไร Levels (ระดับ) เส้นโค้งการเติบโต

251
00:22:18,810 --> 00:22:23,409
(progression curve) เป็นยังไง? ใช่ ดูประมาณนั้นได้

252
00:22:23,409 --> 00:22:28,099
ตัวอย่างเช่น ใช่ โอเค หวังว่าคุณคงได้ลองทำแบบนี้กับ

253
00:22:28,099 --> 00:22:33,157
AI แล้ว >> [กระแอม] >> และพยายามให้เกิดความเข้าใจตรงกัน

254
00:22:33,157 --> 00:22:37,571
grill me skill นี้ใช้เวลานานได้นะ ผมเคยให้มันถาม

255
00:22:37,571 --> 00:22:42,353
40 คำถาม เคยถาม 80 คำถาม มีบางคนถามถึง 100 คำถามด้วย

256
00:22:42,353 --> 00:22:49,802
นั่งคุยกับ AI เป็นชั่วโมงจริงๆ และสิ่งที่คุณได้คือประวัติการสนทนาที่ทำงานได้ดีมาก

257
00:22:49,802 --> 00:22:56,424
เป็น asset ของ design concept ที่คุณกำลังสร้าง มันยังใช้แบบนี้ได้อีกด้วย

258
00:22:56,424 --> 00:23:01,666
คุณสามารถนัดประชุมกับใครสักคนที่เป็นผู้เชี่ยวชาญด้านโดเมน

259
00:23:01,666 --> 00:23:08,931
(domain expert) บางทีผมอาจนัดประชุมกับ Sarah แล้วส่งบันทึกการประชุมนั้นเข้าไปใน

260
00:23:08,931 --> 00:23:15,000
Gemini meetings หรืออะไรก็ตามที่คุณใช้ จากนั้นเอามันเข้าไปในเซสชัน

261
00:23:15,000 --> 00:23:20,610
grilling (การซักถาม) แล้วซักถามผ่านสมมติฐานที่คุณไม่ได้คิดไว้

262
00:23:20,610 --> 00:23:25,484
มันจึงกลายเป็นวิธีที่ดีมากในการรับ input จากโลกภายนอก

263
00:23:25,484 --> 00:23:32,565
แล้วเปลี่ยนมันและตรวจสอบมัน โอเค มาดูกัน ผมอยากไปให้ถึงจุดจบของเรื่องนี้จริงๆ

264
00:23:32,565 --> 00:23:37,164
แต่ก็ไม่อยากนั่งคุยกับ AI ต่อหน้าทุกคนเป็นพันๆ วัน

265
00:23:37,164 --> 00:23:42,038
ดังนั้นผมจะตอบว่า ใช่ มาดูกันว่าจะเกิดอะไรขึ้น เอาล่ะ

266
00:23:42,038 --> 00:23:47,831
ผมจะบอกให้ ขณะที่พวกคุณลองเล่นกับแบบฝึกหัดนี้ในเครื่องของตัวเอง

267
00:23:47,831 --> 00:23:52,798
เรามาเริ่มช่วง Q&A สั้นๆ กันเลยดีกว่า แล้วจะทำยังไงดี?

268
00:23:52,798 --> 00:23:58,499
ช่วยปิดประตู หรือเปิดไมโครโฟนดังๆ หน่อยได้ไหม? เสียงดังไปหน่อย

269
00:23:58,499 --> 00:24:03,006
ไมค์ ช่วยปิดประตูได้ไหม? โอ้ ปิดแล้ว Mark ตอบแล้ว

270
00:24:03,006 --> 00:24:08,156
เยี่ยม สิ่งที่อยากให้คุณทำคือ... มีแอร์ไหม? มีแอร์อยู่นะ

271
00:24:08,156 --> 00:24:12,478
ผมว่ามีแอร์ พวกคุณไม่โดนย่าง แต่ผมนี่โดนย่างสดๆ

272
00:24:12,478 --> 00:24:17,628
เลย สิ่งที่อยากให้ทำคือเข้าไปที่ Slido (แพลตฟอร์มถามตอบ)

273
00:24:17,628 --> 00:24:22,134
ซึ่งคุณ join ได้จากตรงนี้ ถ้าคุณไม่ได้ทำแบบฝึกหัด

274
00:24:22,134 --> 00:24:27,376
ก็เข้าไปที่ Slido เล่นๆ แล้วโหวตคำถามดีๆ หน่อย ผมจะคุยกับ

275
00:24:27,376 --> 00:24:32,250
AI สักครู่ จนกว่าเราจะถึงจุดที่หยุดได้ "สตรีค (streak

276
00:24:32,250 --> 00:24:37,032
การเรียนติดต่อกัน) ได้คะแนนไหม?" อืม สตรีคแยกต่างหาก

277
00:24:37,032 --> 00:24:42,458
มาดูกันว่ามันจะถามอะไรอีก "UI ของ gamification อยู่ที่ไหน?"

278
00:24:42,458 --> 00:24:47,148
เอาไว้ในแดชบอร์ด ผมจะกวาดดูแล้วตอบให้เร็วๆ เลย แล้ว

279
00:24:47,148 --> 00:24:51,838
Slido ของเราเป็นยังไงบ้าง? โอเค "ผมลองใช้ Spec Kit,

280
00:24:51,838 --> 00:24:56,345
Open Spec หรือ Taskmaster แทน Grill Me skill ไหม?

281
00:24:56,345 --> 00:25:02,782
ผมพบว่ามัน verbose (ร่ายยาว) กว่า หรือเป็นทางเลือกที่มีโครงสร้างกว่า?"

282
00:25:02,782 --> 00:25:09,128
เป็นคำถามที่ดีมาก มีเฟรมเวิร์กมากมายที่ช่วยสร้างกระบวนการวางแผนให้คุณ

283
00:25:09,128 --> 00:25:15,749
ผมเชื่อว่าในระยะนี้ ที่ยังไม่มีผู้ชนะชัดเจน ยังไม่มีหนทางเดียวที่ถูกต้อง

284
00:25:15,749 --> 00:25:21,083
และอะไรๆ ก็เปลี่ยนตลอดเวลา คุณต้องเป็นเจ้าของสแตกการวางแผน

285
00:25:21,083 --> 00:25:28,992
(planning stack) ให้ได้มากที่สุดเท่าที่จะทำได้ สิ่งที่ผมสังเกตเห็นจากนักศึกษาหลายคนคือ

286
00:25:28,992 --> 00:25:36,073
พวกเขามักใช้สแตกเดิมๆ มากเกินไป แล้วเจอปัญหา เพราะพวกเขาไม่ได้เป็นเจ้าของสแตก

287
00:25:36,073 --> 00:25:41,131
และไม่เห็นภาพรวมทั้งหมด พวกเขาก็แค่สรุปว่า มันไม่เวิร์ค

288
00:25:41,131 --> 00:25:47,017
มันห่วย ในขณะที่ถ้าคุณควบคุมทุกอย่างได้ อย่างน้อยคุณก็รู้วิธีแก้

289
00:25:47,017 --> 00:25:51,891
หรือมีโอกาสรู้วิธีแก้ ดังนั้น ถึงแม้ผมจะให้สแตกกับคุณ

290
00:25:51,891 --> 00:25:57,409
ผมเชื่อในหลักการ inversion of control (การกลับด้านการควบคุม)

291
00:25:57,409 --> 00:26:01,915
คือคุณควรควบคุมสแตกเอง แล้วก็... ขอกดศูนย์ได้ไหม?

292
00:26:01,915 --> 00:26:07,065
อะไรนะ? ขอโทษ ผมพึมพำเยอะไปหน่อย ขอ... ขอบคุณ ขอโทษจริงๆ

293
00:26:07,065 --> 00:26:11,755
>> [เสียงหัวเราะ] >> อะไรกัน คุณไม่อยากให้ feedback

294
00:26:11,755 --> 00:26:17,457
ดีๆ กับ Claude เหรอ? คุณเป็นอะไรไป? โอเค เจ๋ง "คำถามหลายข้อของ

295
00:26:17,457 --> 00:26:22,423
Grill Me skill ไม่เหมาะกับนักพัฒนาเท่าไหร่ แต่เหมาะกับ

296
00:26:22,423 --> 00:26:26,837
PO (product owner) ในทีมใหญ่ๆ ใครควรใช้มัน?" ใช่

297
00:26:26,837 --> 00:26:31,711
ยกมือขึ้นถ้าเคยทำ pair programming (เขียนโค้ดเป็นคู่)

298
00:26:31,711 --> 00:26:36,769
เคยทำกันไหม? ใช่ วางมือลง แล้วยกมือขึ้นอีกครั้งถ้าเคยทำ

299
00:26:36,769 --> 00:26:41,275
pair programming กับ AI ใช่ เป็นยังไงบ้าง? ดีไหม?

300
00:26:41,275 --> 00:26:46,793
สนุกไหม? ผมว่าการ pair programming กับ AI เป็นไอเดียที่ดีมาก

301
00:26:46,793 --> 00:26:52,771
เพราะคุณมีคนที่สามอยู่ในห้อง ที่จะซักไซ้และตั้งคำถามกับคุณไม่หยุด

302
00:26:52,771 --> 00:26:57,645
ถ้าคุณไม่รู้คำตอบ มันควรเป็นคุณ ผู้เชี่ยวชาญด้านโดเมน

303
00:26:57,645 --> 00:27:02,059
และ AI อยู่ในห้องเดียวกัน ถ้าคุณมีคำถามเรื่องการ

304
00:27:02,059 --> 00:27:07,577
implement ก็ควรเป็นคุณ นักพัฒนาด้วยกัน และ AI ในห้องเดียวกัน

305
00:27:07,577 --> 00:27:13,279
คุณสามารถทำงานผ่านคำถามเหล่านี้ในทีมได้ และเดี๋ยวเราจะดูเรื่อง

306
00:27:13,279 --> 00:27:18,245
implementation กันในอีกสักครู่ แล้วจะเห็นว่าทำยังไงให้

307
00:27:18,245 --> 00:27:23,947
implementation เร็วขึ้นมาก แต่ผมคิดว่าการตัดสินใจที่สำคัญจริงๆ

308
00:27:23,947 --> 00:27:31,488
ที่ต้องใช้มนุษย์ คุณต้องใช้มนุษย์จำนวนมาก และจำนวนมนุษย์ในนั้นไม่ค่อยสำคัญเท่าไหร่

309
00:27:31,488 --> 00:27:36,270
คุณสามารถระดมคนจำนวนมากเข้ามา เหมือน mob programming

310
00:27:36,270 --> 00:27:40,684
(เขียนโค้ดเป็นกลุ่ม) กับ AI นั่นแหละ "เครื่องมือ

311
00:27:40,684 --> 00:27:45,006
meta prompting (การเขียนพรอมป์เพื่อสร้างพรอมป์)

312
00:27:45,006 --> 00:27:49,880
ที่ผมชอบที่สุดคืออะไร?" ผมคิดว่าตอบไปแล้ว "ไม่มีแอร์"

313
00:27:49,880 --> 00:27:54,295
ช่างมันเถอะ "จะใช้บทสนทนาเป็น asset หลังจบเซสชัน

314
00:27:54,295 --> 00:28:02,571
Grill Me ยังไง?" เดี๋ยวเราจะไปถึงตรงนั้น โอเค ผมอยากเร่งความเร็วนี้แบบไม่เป็นธรรมชาติหน่อย

315
00:28:02,571 --> 00:28:06,986
นี่คือประเด็นสำคัญ มีคนเพิ่งพูดว่า "โอเค เอาไปวน

316
00:28:06,986 --> 00:28:11,400
Ralph loop เลย" แต่นี่คือจุดสำคัญ เพราะผมวน loop

317
00:28:11,400 --> 00:28:16,458
กับขั้นตอนนี้ไม่ได้ ใช่ไหม? ผมคิดว่ามีงานสองประเภทในยุค

318
00:28:16,458 --> 00:28:21,056
AI งานแบบ human in the loop (มนุษย์ต้องอยู่ควบคุม)

319
00:28:21,056 --> 00:28:26,666
ที่มนุษย์ต้องนั่งทำเอง ซึ่งก็คือขั้นตอนนี้ เราคือมนุษย์ในวงวน

320
00:28:26,666 --> 00:28:31,080
มีมนุษย์หลายคนอยู่ในวงวน และก็มีงานแบบ AFK (away

321
00:28:31,080 --> 00:28:38,253
from keyboard ห่างจากคีย์บอร์ดได้) งานที่มนุษย์ไม่อยู่หน้าคีย์บอร์ดก็ไม่เป็นไร

322
00:28:38,253 --> 00:28:43,403
อย่าง implementation อย่างที่เราจะได้เห็น เปลี่ยนเป็นงาน

323
00:28:43,403 --> 00:28:48,094
AFK ได้ แต่การวางแผน เฟสการสร้างความเข้าใจตรงกันนี้

324
00:28:48,094 --> 00:28:53,703
ต้องเป็น human in the loop เท่านั้น ต้องเป็น ผมก็เลยต้องทำเอง

325
00:28:53,703 --> 00:28:59,313
เซ็งจริงๆ ไม่รู้สิ "ส่งลิสต์คำแนะนำทั้งหมดของคุณมาให้ฉันหน่อย

326
00:28:59,313 --> 00:29:06,762
ฉันกำลังจัดเวิร์กช็อปอยู่ตอนนี้ ฉันต้องการให้คุณรับภาระมากขึ้นแบบไม่เป็นธรรมชาติ"

327
00:29:06,762 --> 00:29:12,372
มาดูกันว่ามันจะทำอะไร แล้วตอบอีกสองสามคำถามระหว่างที่มันทำงาน

328
00:29:12,372 --> 00:29:17,430
"ผมคิดยังไงกับ PM (product manager) หรือคนที่ไม่ได้เป็น

329
00:29:17,430 --> 00:29:22,764
dev มาทำงาน vibe coding?" อืม ผมจะกลับมาตอบเรื่องนี้ทีหลัง

330
00:29:22,764 --> 00:29:28,006
คงปล่อยไว้ไม่ตอบก่อน ลุ้นกันหน่อย "ผมสังเกตว่าผมไม่ได้ใช้

331
00:29:28,006 --> 00:29:32,512
UI ถามผู้ใช้สำหรับ Grill Me ทำไม?" ใน Claude Code

332
00:29:32,512 --> 00:29:38,858
มี UI เฉพาะที่เรียกขึ้นมาได้ ผมจะตอบสั้นๆ ว่า "ถามฉันโดยใช้เครื่องมือ

333
00:29:38,858 --> 00:29:43,640
ask user question" >> [หัวเราะเบาๆ] >> UI นี้มันพังๆ

334
00:29:43,640 --> 00:29:48,146
อยู่ใน Claude และผมเกลียดมันมาก คุณจะเห็นว่าผมใช้

335
00:29:48,146 --> 00:29:57,710
Claude แต่ผมไม่ได้ชอบ Claude มากเท่าไหร่ ด้วยวิธีนี้คุณมีอิสระเต็มที่ในการเลือกใช้ระบบอะไรก็ได้ที่คุณชอบ

336
00:29:57,710 --> 00:30:04,608
และ UI นี้หน้าตาแบบนี้ มันดูสวยงามตอนแรกเจอ แต่พอใช้ไปก็รู้ว่ามันพังในหลายๆ

337
00:30:04,608 --> 00:30:09,850
ทาง เอาล่ะ มันตอบอะไรกลับมา? โอ้ ไม่นะ ระหว่างที่มันทำงาน

338
00:30:09,850 --> 00:30:14,908
ผมขอสอนอะไรหน่อย แผนคือ เราจะนำ Grill Me skill ของเรามา

339
00:30:14,908 --> 00:30:20,425
และต้องหาทางเปลี่ยนมันให้เป็น "จุดหมายปลายทาง" (destination)

340
00:30:20,425 --> 00:30:25,759
เราต้องลงไป... จริงๆ แล้วเรากำลังหาทางปั้นรูปทรงของสิ่งนี้

341
00:30:25,759 --> 00:30:31,553
นั่นคือสิ่งที่เราทำ เรากำลังหาว่างานมีรูปร่างยังไงระหว่างเซสชัน

342
00:30:31,553 --> 00:30:35,967
grilling และเพื่อเปลี่ยนมันเป็นชุดการกระทำที่ AI

343
00:30:35,967 --> 00:30:41,117
ทำตามได้ เราจำเป็นต้องรู้จุดหมาย ต้องรู้ว่าเราจะไปทางไหน

344
00:30:41,117 --> 00:30:47,279
ต้องรู้รูปทรงทั้งหมดของสิ่งนี้ ผมคิดว่าเราต้องการเอกสารสำคัญสองฉบับ

345
00:30:47,279 --> 00:30:51,601
เราต้องการเอกสารที่บันทึกจุดหมายปลายทาง โอ้ ไม่

346
00:30:51,601 --> 00:30:58,590
สว่างไม่พอ เอาล่ะ ยังไม่สว่างขึ้น เอาล่ะ เราต้องมีเอกสารบันทึกจุดหมายปลายทาง

347
00:30:58,590 --> 00:31:08,339
และเอกสารบันทึกเส้นทางการเดินทาง พูดอีกแบบคือ เราต้องมีเอกสารที่ช่วยกำหนดว่าสิ่งนี้หน้าตาเป็นยังไงในแง่ของ

348
00:31:08,339 --> 00:31:12,937
user stories (เรื่องเล่าความต้องการผู้ใช้) ทั้งหมด

349
00:31:12,937 --> 00:31:20,478
กำหนดนิยามของความสำเร็จ (definition of done) แล้วก็ต้องหาว่าการแบ่งงานควรเป็นยังไง

350
00:31:20,478 --> 00:31:25,168
นั่นคือสิ่งที่เราจะทำต่อไป พอจบเซสชัน grilling แล้ว

351
00:31:25,168 --> 00:31:29,858
ใช่ มันดูดีมาก สุดยอด ผมชอบมาก มันตอบคำถามของมันเอง

352
00:31:29,858 --> 00:31:35,652
22 ข้อ เอาล่ะ นี่คือภาพแทนของเซสชัน grilling ทั่วไปได้ดีทีเดียว

353
00:31:35,652 --> 00:31:40,986
ณ จุดนี้ ผมใช้ไป 25K tokens และเนื้อหาส่วนใหญ่เป็นทองคำแท้

354
00:31:40,986 --> 00:31:45,308
ผมอยากเก็บมันไว้ ผมมี token ดีๆ 25K อยู่ตรงนั้น

355
00:31:45,308 --> 00:31:49,906
และสิ่งที่อยากทำคือสรุปมันเป็นเอกสารจุดหมายปลายทาง

356
00:31:49,906 --> 00:31:54,688
นี่คือแบบฝึกหัดถัดไป เราจะเขียน product requirements

357
00:31:54,688 --> 00:32:03,609
document (เอกสารข้อกำหนดผลิตภัณฑ์) หรือ PRD ซึ่งหน้าที่ของมันคือการเป็นเอกสารจุดหมายปลายทางนี่เอง

358
00:32:03,609 --> 00:32:08,299
รูปแบบไม่สำคัญเท่าไหร่ ผมมีรูปแบบที่ชอบและถูกใจอยู่

359
00:32:08,299 --> 00:32:13,541
แต่คุณเลือกใช้รูปแบบของคุณเอง หรือแบบที่บริษัทคุณใช้ก็ได้

360
00:32:13,541 --> 00:32:18,415
สิ่งที่เราทำจริงๆ คือ ผมไม่ได้กังวลเรื่องนั้นเท่าไหร่

361
00:32:18,415 --> 00:32:24,117
สิ่งที่เราทำจริงๆ คือการสรุป design concept ที่เรามีอยู่ตอนนี้

362
00:32:24,117 --> 00:32:30,554
มาลองกัน ผมจะเริ่มมัน ผมจะเลื่อนลงไปล่างสุด สิ่งที่ผมจะทำก็แค่พิมพ์ว่า

363
00:32:30,554 --> 00:32:34,877
"write a PRD" แล้วเรามาดู skill นั้นกัน write a

364
00:32:34,877 --> 00:32:42,050
PRD skill นี้ทำหลายอย่าง อย่างแรกคือถามผู้ใช้ให้อธิบายปัญหาอย่างละเอียดและยาวๆ

365
00:32:42,050 --> 00:32:47,016
คุณใช้ write a PRD โดยไม่ต้อง grill ก่อนก็ได้ แต่ผมชอบ

366
00:32:47,016 --> 00:32:52,258
grill ก่อนแล้วค่อยเขียน PRD ทีหลัง จากนั้นก็ให้มันติดตั้ง

367
00:32:52,258 --> 00:32:57,592
repo ซึ่งเราทำไปแล้ว จากนั้นให้มันสัมภาษณ์ผู้ใช้แบบไม่ลดละ

368
00:32:57,592 --> 00:33:02,374
ได้ grilling session อีกรอบ แล้วก็เริ่มประกอบเทมเพลต

369
00:33:02,374 --> 00:33:06,788
PRD ขึ้นมา skill นี้อยู่ใน repo ถ้าอยากลองเปิดดู

370
00:33:06,788 --> 00:33:11,202
และหน้าตาของมันก็ประมาณนี้ มี problem statements

371
00:33:11,202 --> 00:33:16,076
(คำอธิบายปัญหา) ปัญหาที่ผู้ใช้เจอ วิธีแก้ปัญหา และชุด

372
00:33:16,076 --> 00:33:21,870
user stories user stories เหล่านี้เป็นตัวนิยามว่าสิ่งนี้คืออะไร

373
00:33:21,870 --> 00:33:26,652
ถ้าคุณเคยเป็นนักพัฒนามาก่อน ก็น่าจะเคยเห็นอะไรแบบนี้

374
00:33:26,652 --> 00:33:31,250
ภาษาที่ใช้เขียนคือ Cucumber หรือเราจะเขียนเองก็ได้

375
00:33:31,250 --> 00:33:36,033
จากนั้นก็มีลิสต์การตัดสินใจด้านการ implement ที่ทำไป

376
00:33:36,033 --> 00:33:41,275
และที่สำคัญคือลิสต์การตัดสินใจด้านการทดสอบด้วย ผมจะรันมัน

377
00:33:41,275 --> 00:33:46,057
โอเค มันเสร็จแล้ว อ่า! Windows ขอปิดหน้าต่างนี้หน่อย

378
00:33:46,057 --> 00:33:52,402
ขอบคุณ ไม่รู้ว่าทำไมผมถึงซื้อแล็ปท็อป Windows ผมว่าผมแค่ชอบความท้าทาย

379
00:33:52,402 --> 00:33:58,288
>> [กระแอม] >> สิ่งแรกที่มันจะให้ผมคือชุดโมดูลที่เสนอว่าควรแก้ไข

380
00:33:58,288 --> 00:34:03,530
ตอนนี้มีเหตุผลลึกๆ ที่ผมคิดเรื่องนี้ ในขั้นนี้เรามีไอเดีย

381
00:34:03,530 --> 00:34:09,783
เราเขียนสเปกคร่าวๆ ของไอเดียแล้ว เราเข้าใจตรงกันแล้วว่ากำลังจะทำอะไร

382
00:34:09,783 --> 00:34:14,841
จากนั้นต้องเริ่มคิดถึงโค้ด เพราะถึงจุดนี้แล้ว นี่ไม่ใช่

383
00:34:14,841 --> 00:34:22,106
specs to code นี่ไม่ใช่จุดที่เราจะเมินโค้ด เราคำนึงถึงโค้ดอยู่ตลอดทั้งกระบวนการ

384
00:34:22,106 --> 00:34:34,430
วิธีที่ผมชอบคือการคิดถึงชุดโมดูลที่เสนอให้แก้ เราจะกลับมาที่แนวคิดเรื่องการออกแบบระบบของคุณอย่างต่อเนื่องและคำนึงถึงระบบของคุณอยู่เสมอ

385
00:34:34,430 --> 00:34:42,890
มันบอกว่า "แนะนำให้ทดสอบ gamification service เพราะมันเป็นโมดูลลึกโมดูลเดียวที่มีตรรกะสำคัญ"

386
00:34:42,890 --> 00:34:47,397
โมดูลเหล่านี้ดูถูกต้อง ใช่ ดูดี และมันจะสร้าง PRD

387
00:34:47,397 --> 00:34:52,179
ออกมา เพื่อความง่ายในการตั้งค่า ผมตั้งให้มันสร้างชุด

388
00:34:52,179 --> 00:34:57,513
issues (งาน) ในเครื่อง ดังนั้นมันจะสร้าง PRD ไว้ในโฟลเดอร์

389
00:34:57,513 --> 00:35:02,019
issues นี้ แต่วิธีที่ผมทำปกติ และคุณลองไปดูเองได้

390
00:35:02,019 --> 00:35:08,916
คือไปที่ repo งานของผม ซึ่งก็คือ github.com/MattPocock/course-video-manager

391
00:35:08,916 --> 00:35:15,997
ตามลิงก์ข้างบนนี้ ในนี้เป็นแอปที่ผมสร้างขึ้นมา ใช้ตลอดเวลาเพื่ออัดวิดีโอของผม

392
00:35:15,997 --> 00:35:22,619
ผมเคยดึงสถิติออกมาดู ผมอัดวิดีโอในนี้ไปประมาณพันกว่าเรื่องอะไรประมาณนั้น

393
00:35:22,619 --> 00:35:27,493
และคุณจะเห็นว่ามี issues ที่ปิดแล้ว 744 ตัว และนี่คือ

394
00:35:27,493 --> 00:35:33,470
PRD ทั้งหมดกับ issues ด้าน implementation ทั้งหมดที่ผมใส่ไว้ในนี้

395
00:35:33,470 --> 00:35:39,264
นี่คือวิธีที่ผมชอบทำ >> [กระแอม] >> นั่นคือสิ่งที่ผมกำลังทำอยู่

396
00:35:39,264 --> 00:35:43,770
เอาล่ะ ผมจะตอบว่า ใช่ แล้วก็สร้าง issue นั้นออกมา

397
00:35:43,770 --> 00:35:48,277
มาดูกัน มันอยู่ในนี้แล้ว เรามี problem statements

398
00:35:48,277 --> 00:35:52,967
คนที่สมัครเรียนคอร์ส วิธีแก้ user stories 18 เรื่อง

399
00:35:52,967 --> 00:35:57,841
ดูดี การตัดสินใจด้าน implementation เกณฑ์ระดับ (level

400
00:35:57,841 --> 00:36:05,198
thresholds) อะไรพวกนี้ ข้อมูลเพียงพอแล้ว เราเคลียร์แล้วว่าเราจะไปทางไหนและทำอะไร

401
00:36:05,198 --> 00:36:09,704
นั่นคือสิ่งที่เราทำ เรามีเซสชัน grilling และสร้าง

402
00:36:09,704 --> 00:36:15,038
asset ออกมาจากมัน ทีนี้ ยกมือหน่อย ผมควรทบทวนเอกสารนี้ไหม?

403
00:36:15,038 --> 00:36:20,372
ยกมือขึ้นถ้าคิดว่าผมควรทบทวนเอกสาร ใช่ ผมไม่ดูเอกสารพวกนี้

404
00:36:20,372 --> 00:36:24,878
ผมไม่ดู เพราะสิ่งที่ผมกำลังทดสอบ ณ จุดนี้คืออะไร?

405
00:36:24,878 --> 00:36:30,856
เวลาผมอ่านมัน ผมกำลังทดสอบอะไร? failure modes (รูปแบบความล้มเหลว)

406
00:36:30,856 --> 00:36:36,282
ที่ผมกำลังพยายามเช็กคืออะไร? ผมรู้ว่า LLM เก่งเรื่องการสรุป

407
00:36:36,282 --> 00:36:40,880
เพราะมันเก่งจริงๆ ผมอยู่ในคลื่นความถี่เดียวกับ LLM

408
00:36:40,880 --> 00:36:45,662
แล้ว ใช่ไหม? การใช้ grill me skill ทำให้เรามี design

409
00:36:45,662 --> 00:36:50,352
concept ร่วมกัน ถ้าเรามี design concept ร่วมกันแล้ว

410
00:36:50,352 --> 00:36:55,410
สิ่งที่ผมทำก็แค่เช็กความสามารถในการสรุปของ LLM เท่านั้น

411
00:36:55,410 --> 00:37:02,400
ผมเลยไม่ค่อยอ่านพวกนี้ มาทำ Q&A กันดีกว่า เพราะผมรู้สึกว่าทุกคนอยากถามเต็มที

412
00:37:02,400 --> 00:37:06,906
และผมว่าเราน่าจะพักเบรกสัก 5 นาที เพื่อพักเสียงผม

413
00:37:06,906 --> 00:37:11,412
และให้ทุกคนได้ตามแบบฝึกหัดทันสักครู่ ถ้าไม่ว่ากัน

414
00:37:11,412 --> 00:37:17,022
มาทำ Q&A สั้นๆ กัน "ถ้าผมไม่ชอบ Claude Code แล้วผมชอบตัวไหน?"

415
00:37:17,022 --> 00:37:23,275
เคยได้ยินคำพูดที่ว่า "ประชาธิปไตยเป็นวิธีการปกครองประเทศที่แย่ที่สุด

416
00:37:23,275 --> 00:37:27,690
ยกเว้นวิธีอื่นๆ ทั้งหมด" ไหม? ผมรู้สึกแบบนั้นกับ

417
00:37:27,690 --> 00:37:33,483
Claude Code ตอบข้อนั้นแล้ว "คุณคิดยังไงกับนักพัฒนาที่ต้องเข้าใจ

418
00:37:33,483 --> 00:37:37,990
TypeScript อย่างลึกซึ้ง ในเมื่อตอนนี้มีเครื่องมือ

419
00:37:37,990 --> 00:37:44,059
fix the TS / make no mistakes อยู่แล้ว?" ผมไม่เข้าใจรูปแบบคำถามนี้

420
00:37:44,059 --> 00:37:49,025
แต่คิดว่าเข้าใจความหมาย ซึ่งคือ ผมเชื่อว่าโค้ดสำคัญมาก

421
00:37:49,025 --> 00:37:55,279
และสิ่งนี้จะแทรกซึมไปทั้งเซสชัน และโค้ดเบสที่แย่จะสร้างเอเจนต์ที่แย่

422
00:37:55,279 --> 00:38:01,716
ถ้าคุณมีโค้ดเบสที่ขยะๆ คุณจะได้ขยะออกมาจากเอเจนต์ที่ทำงานในโค้ดเบสนั้น

423
00:38:01,716 --> 00:38:09,441
เดี๋ยวเราจะพูดเรื่องนี้เพิ่มอีกที และผมคิดว่าการเข้าใจเครื่องมือเหล่านี้อย่างลึกซึ้ง

424
00:38:09,441 --> 00:38:14,683
เข้าใจโค้ดอย่างลึกซึ้ง จะทำให้คุณเป็นนักพัฒนาที่ดีขึ้นมาก

425
00:38:14,683 --> 00:38:19,649
และได้ประโยชน์จาก AI มากขึ้น และนั่นก็ตอบคำถามนั้นด้วย

426
00:38:19,649 --> 00:38:23,972
เยี่ยม ออกไปจากตรงนั้นหน่อย เอาล่ะ "ตอนนี้เรามี

427
00:38:23,972 --> 00:38:29,673
context window 1 ล้าน token แล้ว เราอยากใช้ประโยชน์จากมันจริงๆ

428
00:38:29,673 --> 00:38:34,915
ไหม? ผมสังเกตว่าโซนโง่ดูโง่น้อยลงช่วงนี้" โอเค คำถามดีมาก

429
00:38:34,915 --> 00:38:39,421
เรื่องนี้ย้อนกลับไปที่แนวคิดแรกของเราเรื่องโซนโง่

430
00:38:39,421 --> 00:38:43,928
ผมอัดคอร์ส Claude Code โดยใช้ context window ขนาด

431
00:38:43,928 --> 00:38:48,802
200K และในวันที่ผมเปิดตัวคอร์ส พวกเขาก็ประกาศ context

432
00:38:48,802 --> 00:38:53,124
window 1 ล้าน ความเห็นผมคือ สิ่งที่ Claude Code

433
00:38:53,124 --> 00:38:58,274
ทำคือประมาณนี้ แหม! พวกเขาส่งโซนโง่เพิ่มให้คุณอีกเยอะมาก

434
00:38:58,274 --> 00:39:02,780
นี่เป็นเรื่องดีสำหรับงานที่คุณต้องการดึงข้อมูลจาก

435
00:39:02,780 --> 00:39:07,470
context window ขนาดใหญ่ ถ้าคุณอยากส่ง War and Peace

436
00:39:07,470 --> 00:39:13,172
(สงครามและสันติภาพ) ห้าเล่มเข้าไป แล้วให้มันหาว่ามีอะไรบ้าง...

437
00:39:13,172 --> 00:39:19,702
ผมนึกชื่อตัวละครใน War and Peace ไม่ได้เลย ทำไมผมถึงเริ่มด้วยอันนั้นนะ?

438
00:39:19,702 --> 00:39:25,495
มันดีสำหรับการค้นคืน (retrieval) แต่ไม่ค่อยดีสำหรับการเขียนโค้ด

439
00:39:25,495 --> 00:39:31,933
ผมเลยมองว่าตอนนี้โซนฉลาดอยู่ที่ประมาณ 100K และโซนฉลาดจะใหญ่ขึ้นเรื่อยๆ

440
00:39:31,933 --> 00:39:36,347
ซึ่งจะเป็นการพัฒนาที่ดีมาก ทุกคน เราจะพักเบรกสัก

441
00:39:36,347 --> 00:39:41,589
5 นาที ถ้าไม่ว่ากัน เพื่อพักเสียงผม และคุณอาจจะได้ขยับตัว

442
00:39:41,589 --> 00:39:49,130
หรือไปหาน้ำดื่ม ผมเห็นสายตาที่เริ่มง่วงๆ และอยากให้ทุกคนตื่นเต็มที่สำหรับช่วงต่อไป

443
00:39:49,130 --> 00:39:54,004
ถ้าไม่ว่ากัน เราจะพัก 5 นาที แล้วเจอกันที่นี่อีกครั้ง

444
00:39:54,004 --> 00:40:00,166
โอเคไหม? เรามี PRD ซึ่งผมจะไม่อ่าน มันคือเอกสารจุดหมายปลายทางของเรา

445
00:40:00,166 --> 00:40:08,535
ขอกวาดดูคำถามดีๆ ก่อนที่จะพุ่งไปต่อ "การค้นพบบทบาทของวิศวกรรมซอฟต์แวร์ในโลกปัจจุบันอีกครั้ง

446
00:40:08,535 --> 00:40:13,133
สามสาขาที่คุณแนะนำ" อืม เทควันโดก็ดีนะ เคยได้ยินมา

447
00:40:13,133 --> 00:40:18,834
ผมไม่รู้จะตอบคำถามนี้ยังไงเลย ขอบคุณที่ถามนะ สามสาขาที่ผมแนะนำ

448
00:40:18,834 --> 00:40:24,536
หมายถึง... อะไรนะ? ช่างประปา (plumbing) ช่างประปาก็ดีเหมือนกัน

449
00:40:24,536 --> 00:40:32,813
ใช่ ใช่ ใช่ ไม่รู้ว่ามันเป็นสาขาไหมนะ ช่างประปาที่ผมจ้างมามักไม่ค่อยมีระเบียบวินัยเท่าไหร่

450
00:40:32,813 --> 00:40:37,411
เอาล่ะ โอเค ตอนนี้เรามีจุดหมายแล้ว โอเคไหม? เยี่ยม

451
00:40:37,411 --> 00:40:42,285
แล้วเราจะไปถึงจุดหมายได้ยังไง? เรามี PRD ที่คลุมเครือ

452
00:40:42,285 --> 00:40:47,251
จะแบ่งมันยังไงเพื่อไม่ให้ของตกไปในโซนโง่? พูดอีกแบบคือ

453
00:40:47,251 --> 00:40:52,401
เรามีงานใหญ่งานหนึ่ง จะแบ่งมันเป็นแผนหลายเฟสแบบนี้ยังไง?

454
00:40:52,401 --> 00:41:00,218
สิ่งที่คุณอาจทำตอนนี้คือบอกว่า "โอเค Claude ขอแผนหลายเฟสที่พาเราไปถึงจุดหมายนี้หน่อย"

455
00:41:00,218 --> 00:41:06,656
ฟังดูสมเหตุสมผล นี่คือสิ่งที่เราทำกันมาก่อน แต่ตอนนี้ผมมีวิธีที่ดีกว่า

456
00:41:06,656 --> 00:41:11,254
คือผมชอบสร้างคัมบังบอร์ด (Kanban board) จากสิ่งนี้

457
00:41:11,254 --> 00:41:15,944
ยกมือขึ้นถ้าไม่รู้ว่า Kanban board คืออะไร อืม เจ๋ง

458
00:41:15,944 --> 00:41:21,830
โอเค Kanban board ก็คือชุดการ์ดงาน (tickets) ที่คุณแปะไว้บนกำแพง

459
00:41:21,830 --> 00:41:26,520
โดยมีการ์ดแต่ละใบมี ความสัมพันธ์แบบบล็อก (blocking)

460
00:41:26,520 --> 00:41:34,153
ระหว่างกัน มาดูกันว่ามันหน้าตาเป็นยังไง นี่คือวิธีที่เราทำงานกันในฐานะนักพัฒนามานาน

461
00:41:34,153 --> 00:41:39,395
ตั้งแต่ยุค Agile เกิดขึ้น และสิ่งที่มันทำ เราจะเห็นตรงนี้

462
00:41:39,395 --> 00:41:43,993
มันเสนอให้แบ่งการตั้งค่านี้ออกเป็นห้างาน งานแรกคือ

463
00:41:43,993 --> 00:41:48,775
schema (โครงสร้างฐานข้อมูล) และ gamification service

464
00:41:48,775 --> 00:41:56,132
ใช่ ดูดีทีเดียว งานนี้ไม่ถูกบล็อกโดยอะไร และเราจะเห็นด้วยว่ามันระบุประเภทงานเป็น

465
00:41:56,132 --> 00:42:00,730
AFK ด้วย จำได้ไหมที่ผมพูดถึง human in the loop กับ

466
00:42:00,730 --> 00:42:06,984
AFK ก่อนหน้านี้? นี่คืองาน AFK คืองานที่เราส่งให้เอเจนต์จัดการได้เลย

467
00:42:06,984 --> 00:42:16,456
การติดตามสตรีค (streak tracking) โอเค ดูดี แล้วก็เชื่อมคะแนนและสตรีคเข้ากับการเรียนบทเรียน/ทำแบบทดสอบจบ

468
00:42:16,456 --> 00:42:21,330
งานนี้ถูกบล็อกโดยงานหนึ่งและสอง การ backfill ย้อนหลัง

469
00:42:21,330 --> 00:42:26,848
ถูกบล็อกโดยงานหนึ่งเท่านั้น และงานนี้อีกตัวถูกบล็อกโดยทุกงาน

470
00:42:26,848 --> 00:42:31,538
เจ๋ง อืม ตอนนี้ผมคิดว่า คุณอาจถามว่า "ทำไมเราไม่ให้

471
00:42:31,538 --> 00:42:36,872
AI สร้าง issues พวกนี้เลยล่ะ? ทำไมผมต้องมายุ่งตรงนี้ด้วย?"

472
00:42:36,872 --> 00:42:44,413
เพราะมันให้เครื่องมือที่ดีๆ มาเยอะแยะ ทำไมผมต้องมาตรวจสอบและคิดว่างานต่อไปคืออะไร?

473
00:42:44,413 --> 00:42:49,012
ความเห็นผมคือ ขั้นนี้ทำได้ถูกมาก ทำได้เร็วมาก พอทำ

474
00:42:49,012 --> 00:42:53,978
PR เสร็จ ผมก็เห็นปัญหาได้ทันที มันมีเทคนิคที่สำคัญมากๆ

475
00:42:53,978 --> 00:42:59,311
ตอนที่คุณกำลังหาว่ารูปทรงของการเดินทางครั้งนี้ควรเป็นยังไง

476
00:42:59,311 --> 00:43:04,461
มันมาจากแนวคิดคลาสสิกจากหนังสือ The Pragmatic Programmer

477
00:43:04,461 --> 00:43:09,152
ที่เรียกว่า traceable bullets (กระสุนเรืองแสง) หรือ

478
00:43:09,152 --> 00:43:13,842
vertical slices (ชิ้นแนวตั้ง) และ traceable bullets

479
00:43:13,842 --> 00:43:20,003
เปลี่ยนวิธีคิดของผมเกี่ยวกับการให้ AI เลือกงานของตัวเองอย่างแท้จริง

480
00:43:20,003 --> 00:43:26,533
ระบบมีเลเยอร์ใช่ไหม? มีเลเยอร์อยู่ในระบบของคุณ สิ่งเหล่านี้อาจเป็นหน่วย

481
00:43:26,533 --> 00:43:33,522
deployable (หน่วยที่นำไปติดตั้งได้) ที่ต่างกัน คุณอาจมีฐานข้อมูลอยู่ที่หนึ่ง

482
00:43:33,522 --> 00:43:41,523
API อาจอยู่ใกล้ฐานข้อมูลแต่แยกส่วนกัน คุณอาจมีฟรอนต์เอนด์ที่อยู่คนละที่โดยสิ้นเชิงอย่าง

483
00:43:41,523 --> 00:43:46,673
CDN หรือภายในหน่วย deployable เหล่านี้ อาจมีเลเยอร์ย่อยๆ

484
00:43:46,673 --> 00:43:51,547
อยู่ข้างใน เช่นในโค้ดเบสที่เราทำงานด้วย เรามี service

485
00:43:51,547 --> 00:43:56,421
มากมาย ทั้ง quiz service, team service, user service,

486
00:43:56,421 --> 00:44:01,111
coupon service, core service และ service เหล่านี้มี

487
00:44:01,111 --> 00:44:05,434
dependency ต่อกัน มันก็เหมือนเป็นเลเยอร์เดี่ยวๆ

488
00:44:05,434 --> 00:44:10,492
สิ่งที่ผมสังเกตคือ AI ชอบเขียนโค้ดแนวนอน (horizontally)

489
00:44:10,492 --> 00:44:17,849
คือชอบเขียนทีละเลเยอร์ พูดอีกแบบ ในเฟสหนึ่ง มันจะทำทุกอย่างที่เกี่ยวกับฐานข้อมูล

490
00:44:17,849 --> 00:44:23,918
schema ทั้งหมด อะไรก็ตามที่เกี่ยวกับหน่วยนั้น จากนั้นเข้าสู่เฟสสอง

491
00:44:23,918 --> 00:44:29,252
ทำทุกอย่างที่เกี่ยวกับ API แล้วค่อยเพิ่มฟรอนต์เอนด์ทับลงไป

492
00:44:29,252 --> 00:44:33,942
มีใครบอกได้ไหมว่าภาพนั้นผิดตรงไหน? ทำไมมันถึงไม่ดี?

493
00:44:33,942 --> 00:44:39,460
ยกมือขึ้นถ้ามีคำตอบ ใช่ >> ได้ feedback loop ทั้งหมดนั่นแหละ

494
00:44:39,460 --> 00:44:45,990
ถูกต้อง คุณจะไม่ได้ feedback กับงานของคุณจนกว่าจะเริ่มหรือทำเฟสสามเสร็จ

495
00:44:45,990 --> 00:44:51,323
สิ่งที่คุณต้องทำคือ กว่าคุณจะถึงเฟสสาม คุณไม่ได้ทดสอบจริงๆ

496
00:44:51,323 --> 00:44:57,209
ว่าเลเยอร์ทั้งหมดทำงานร่วมกัน คุณยังไม่มีระบบแบบบูรณาการให้ทดสอบ

497
00:44:57,209 --> 00:45:02,083
ดังนั้นแทนที่จะคิดแบบนั้น คุณต้องคิดถึงเลเยอร์แนวตั้ง

498
00:45:02,083 --> 00:45:07,509
(vertical layers) คุณต้องคิดถึงชิ้นส่วนฟังก์ชันการทำงานบางๆ

499
00:45:07,509 --> 00:45:13,027
ที่ตัดผ่านทุกเลเยอร์ที่จำเป็น และนี่คือวิธีทำงานที่ดีกว่ามาก

500
00:45:13,027 --> 00:45:19,556
ดีกว่าสำหรับ AI ด้วย เพราะหมายความว่าในตอนจบเฟสหนึ่งหรือระหว่างเฟสหนึ่ง

501
00:45:19,556 --> 00:45:24,247
มันจะได้ feedback กับทั้งโฟลว์ของมัน สิ่งนี้หมายถึง

502
00:45:24,247 --> 00:45:29,580
ใน skill ชื่อ PRD to issues ที่อยู่ข้างบนนี้ ผมเขียนไว้ว่า

503
00:45:29,580 --> 00:45:33,903
"แบ่ง PRD เป็น issues ที่หยิบจับได้อิสระ โดยใช้

504
00:45:33,903 --> 00:45:38,409
vertical slices / traceable bullets เขียนเป็นไฟล์

505
00:45:38,409 --> 00:45:43,191
markdown ในเครื่อง" >> [หัวเราะเบาๆ] >> ขั้นแรกเราหา

506
00:45:43,191 --> 00:45:47,513
PRD เจอ ถ้าเป็นเซสชันใหม่ก็สำรวจโค้ดเบสอีกครั้ง

507
00:45:47,513 --> 00:45:52,204
เราร่าง vertical slices แล้วแบ่ง PRD ออกเป็น issues

508
00:45:52,204 --> 00:46:00,204
ที่ติดตามได้ อธิบาย traceable bullet หน่อย มันเหมือนตอนที่คุณเป็นพลยิงปืนต่อสู้อากาศยาน

509
00:46:00,204 --> 00:46:05,906
มันเป็นแนวคิดที่ค่อนข้างรุนแรงนะ และคุณมองขึ้นไปบนฟ้ายามค่ำคืน

510
00:46:05,906 --> 00:46:10,872
ถ้าคุณยิงกระสุนธรรมดา คุณไม่รู้เลยว่ากำลังยิงไปโดนอะไร

511
00:46:10,872 --> 00:46:15,930
คุณเห็นเครื่องบิน แต่ไม่เห็นว่ากระสุนไปทางไหน traceable

512
00:46:15,930 --> 00:46:20,253
bullet คือการติดสารเรืองแสงเล็กน้อยไว้กับกระสุน

513
00:46:20,253 --> 00:46:24,759
เพื่อให้มันเรืองแสงระหว่างทาง นั่นหมายความว่าทุกๆ

514
00:46:24,759 --> 00:46:29,265
กระสุนนัดที่หก คุณจะเห็นเส้นแสงบนท้องฟ้า คุณจะได้

515
00:46:29,265 --> 00:46:34,231
feedback ว่ากำลังเล็งไปทางไหน แนวคิดคือเราจะเพิ่มระดับ

516
00:46:34,231 --> 00:46:39,749
feedback และได้ feedback เกือบจะทันทีกับสิ่งที่เรากำลังสร้าง

517
00:46:39,749 --> 00:46:44,807
เพราะถ้าไม่มีมัน AI จะเขียนโค้ดแบบมืดบอดไปจนถึงเฟสหลังๆ

518
00:46:44,807 --> 00:46:49,497
เรามีกฎ vertical slice เราถามผู้ใช้ แล้วก็สร้างไฟล์

519
00:46:49,497 --> 00:46:54,187
issues สิ่งที่ผมเห็นตรงนี้คือ ถึงแม้ผมจะบอกให้มันทำ

520
00:46:54,187 --> 00:46:58,602
vertical slices มันกลับเสนอให้สร้าง gamification

521
00:46:58,602 --> 00:47:04,947
service ก่อนเป็นงานแรก นั่นคือชิ้นเดียวตรงนั้น และสำหรับผมมันดูเหมือน

522
00:47:04,947 --> 00:47:09,453
horizontal slice (ชิ้นแนวนอน) สิ่งที่ผมอยากเห็นใน

523
00:47:09,453 --> 00:47:14,235
vertical slice แรกเป็นพิเศษคือ การเปลี่ยนแปลง schema

524
00:47:14,235 --> 00:47:19,477
หรือบางส่วนของ schema ผมอยากเห็น service ใหม่ถูกสร้างขึ้น

525
00:47:19,477 --> 00:47:26,007
และอยากเห็นการแสดงผลขั้นต่ำของมันบนฟรอนต์เอนด์ ผมอยากให้มันทำตามแนวตั้ง

526
00:47:26,007 --> 00:47:30,421
ไม่ใช่แค่แนวนอน เข้าใจไหม? โอเค ผมจะด่า AI หน่อย

527
00:47:30,421 --> 00:47:35,479
"ไอ้เด็กไม่ดี" ไม่ล่ะ ผมจะไม่เสีย token ไปกับการด่าเฉยๆ

528
00:47:35,479 --> 00:47:41,825
"slice แรกมันแนวนอนเกินไป" ผมจะเริ่มแค่ตรงนั้นแล้วดูว่ามันจะรับได้ไหม

529
00:47:41,825 --> 00:47:48,538
เข้าใจแนวคิดไหม? และสิ่งที่ผมชอบมากเกี่ยวกับการย้อนกลับไปอ่านหนังสือเก่าๆ

530
00:47:48,538 --> 00:47:57,091
เหล่านั้นคือ ในยุคสมัยนี้เราพยายามหาคำพูดเป็นภาษาอังกฤษมาอธิบายแนวปฏิบัติซอฟต์แวร์ที่ดีที่สุด

531
00:47:57,091 --> 00:48:05,091
และหนังสืออายุ 20 ปีเหล่านี้ทำมันไว้แล้ว และมันคือเหมืองทองคำถ้าอยากเอามันไปใส่ในพรอมป์

532
00:48:05,091 --> 00:48:09,966
แต่ถึงอย่างนั้น มันก็ไม่ได้ทำงานได้สมบูรณ์แบบทุกครั้ง

533
00:48:09,966 --> 00:48:14,288
"ให้คะแนนเมื่อเรียนบทเรียนจบ และแสดงบนแดชบอร์ด"

534
00:48:14,288 --> 00:48:19,990
ใช่ นี่คือ vertical slice ที่สวยงาม เพราะมันเป็นงานก้อนโตจริงๆ

535
00:48:19,990 --> 00:48:26,427
มันทำหลาย user stories ในนั้น แต่ตอนจบเราจะได้เห็นของที่มองเห็นได้จริง

536
00:48:26,427 --> 00:48:32,865
แล้ว AI ก็จะต่อยอดจากตรงนั้นได้ คุณเห็นไหมว่าทำไมอันนี้ถึงดีกว่าอันแรก

537
00:48:32,865 --> 00:48:39,210
เจ๋ง ดูดีมาก เรากำลังเข้าใกล้ขึ้นเรื่อยๆ แล้ว ใครที่ตามอยู่ที่บ้าน...

538
00:48:39,210 --> 00:48:45,004
เอาเถอะ ไม่ใช่ที่บ้าน แต่คุณคงพอเข้าใจ หวังว่าจะเห็นแบบเดียวกัน

539
00:48:45,004 --> 00:48:50,981
และเริ่มมีสัญชาตญาณเดียวกัน ขอเปิดรับคำถาม ระหว่างที่ผมกำลังสร้าง

540
00:48:50,981 --> 00:48:55,580
GitHub issues เหล่านี้ อ่า... ไม่ใช่ GitHub issues

541
00:48:55,580 --> 00:48:59,994
แต่อยู่ในเครื่อง "เมื่อไหร่ผมจะเลิกใช้ Windows?"

542
00:48:59,994 --> 00:49:05,328
ไม่มีวัน "เมื่อพูดกับฉัน จงยอมเสียไวยากรณ์เพื่อความกระชับ"

543
00:49:05,328 --> 00:49:12,133
พรอมป์นี้มีประโยชน์มากกับผมตอนอ่านแผน เพราะมันทำให้แผนที่ออกมามีความกระชับ

544
00:49:12,133 --> 00:49:17,191
อ่านง่าย ดีมาก แต่ผมเลิกใช้แนวคิดนี้แล้ว หันไปชอบเซสชัน

545
00:49:17,191 --> 00:49:22,801
grilling แทน เพราะสิ่งที่ผมสังเกตคือ ผมไม่อยากอ่านแผนอีกต่อไป

546
00:49:22,801 --> 00:49:29,146
ผมอยากอยู่ในคลื่นความถี่เดียวกับ LLM ผมอยากให้มันถามคำถามเชิงรุกกับผม

547
00:49:29,146 --> 00:49:34,021
และพอผมเลิกอ่านแผน ผมก็ไม่ต้องการให้มันกระชับอีกต่อไป

548
00:49:34,021 --> 00:49:38,527
ผมมองแผนในเอกสารจุดหมายปลายทางว่าเป็นสถานะสุดท้าย

549
00:49:38,527 --> 00:49:43,309
(end state) และผมไม่ต้องการให้สถานะสุดท้ายนั้นกระชับ

550
00:49:43,309 --> 00:49:49,562
หวังว่าคงตอบคำถามได้ "คุณคิดว่าผลลัพธ์ของสถานการณ์เม็กซิกันสแตนด์ออฟ

551
00:49:49,562 --> 00:49:53,885
(การเผชิญหน้าแบบไม่มีใครยอมถอย) ระหว่างบทบาทของ

552
00:49:53,885 --> 00:49:58,943
PM ในอนาคตกับบทบาทอื่นๆ ที่กำลังมาบรรจบกันจะเป็นยังไง?"

553
00:49:58,943 --> 00:50:05,380
ไม่รู้สิ ผมไม่ใช่นักวิเคราะห์ ไม่รู้ โอเค หลังจากการอนุมัติสองสามครั้ง

554
00:50:05,380 --> 00:50:12,002
เราก็จะได้ชุด issues ออกมา issues ที่เราสร้างถูกออกแบบให้หยิบจับได้อิสระ

555
00:50:12,002 --> 00:50:16,692
นั่นหมายความว่า Kanban board นี้จะมีหน้าตาประมาณนี้

556
00:50:16,692 --> 00:50:21,842
คุณจะได้ชุดการ์ดงานที่มีความสัมพันธ์แบบอิสระต่อกันมากมาย

557
00:50:21,842 --> 00:50:27,452
งานนี้ต้องทำก่อนงานนี้ งานนี้ต้องทำก่อนงานนี้ และงานนี้อีกตัว

558
00:50:27,452 --> 00:50:34,625
สมมติว่ามีอีกตัวตรงนี้ งานนี้ต้องทำก่อนงานนี้ นั่นหมายความว่าคุณเริ่มทำแบบขนาน

559
00:50:34,625 --> 00:50:40,694
(parallelize) ได้ เริ่มให้เอเจนต์หลายตัวทำงานพร้อมกันในงานเหล่านี้

560
00:50:40,694 --> 00:50:48,511
เพราะใช่ งานนี้ต้องทำก่อน แล้วสองงานนี้สามารถถูกหยิบไปทำพร้อมกันโดยเอเจนต์อิสระสองตัว

561
00:50:48,511 --> 00:50:52,834
ยกมือขึ้นถ้าเคยทำงานแบบขนานกับเอเจนต์ โอเค เจ๋ง

562
00:50:52,834 --> 00:50:57,432
สิ่งนี้ทำให้คุณเปลี่ยนแผนเหล่านั้นให้เป็น directed

563
00:50:57,432 --> 00:51:02,950
acyclic graphs (กราฟไร้รอบแบบมีทิศทาง) ได้อย่างเหมาะสมที่สุด

564
00:51:02,950 --> 00:51:07,640
โดยคุณจะมีสามเฟสตรงนี้ เฟสหนึ่ง... ขอเลื่อนนี่หน่อย

565
00:51:07,640 --> 00:51:12,606
เหนือเส้นนี้ คุณทำงานนี้ เฟสสอง คุณทำงานสองงานด้านล่าง

566
00:51:12,606 --> 00:51:17,848
และเฟสสาม คุณทำงานชิ้นที่สามแล้วต่อเข้ากับมัน และลองคิดดู

567
00:51:17,848 --> 00:51:23,366
มันอาจมี... นี่เป็นแผนที่ค่อนข้างง่าย แต่คุณสามารถมีแผนต่างๆ

568
00:51:23,366 --> 00:51:28,424
มากมายทำงานพร้อมกันได้ หมายความว่าคุณทำ parallelization

569
00:51:28,424 --> 00:51:33,758
(การทำงานขนาน) ได้ดีมาก และเดี๋ยวเราจะพูดถึงเรื่องนี้อีกที

570
00:51:33,758 --> 00:51:39,643
นั่นคือเหตุผลที่ผมชอบ Kanban board แบบนี้มากกว่าแผนแบบเรียงลำดับ

571
00:51:39,643 --> 00:51:46,265
(sequential plan) เพราะแผนแบบเรียงลำดับมีเอเจนต์เดียวเท่านั้นที่ทำงานได้

572
00:51:46,265 --> 00:51:50,771
ตรงนี้... มันหายไปไหน? ตรงนี้ ใช่ แผนนี้เป็น loop

573
00:51:50,771 --> 00:51:56,105
เดียวจริงๆ ใช่ไหม? มีเอเจนต์เดียวเท่านั้นที่ทำงานกับมันได้

574
00:51:56,105 --> 00:52:00,427
เพราะเรามีเฟสที่เป็นเลขลำดับ และมัน parallelize

575
00:52:00,427 --> 00:52:05,025
ไม่ได้ เข้าใจไหม? เจ๋ง เรามี issues ของเราแล้ว อ่า

576
00:52:05,025 --> 00:52:09,807
ไม่เอาน่า หยุดถามฉันได้แล้ว ฉันรู้ว่ามันกำลังสร้างบน

577
00:52:09,807 --> 00:52:14,406
GitHub ฉันไม่ต้องการแบบนั้น โอ้ ไม่ ไอ้โง่ สร้างใน

578
00:52:14,406 --> 00:52:19,647
issues แทนสิ ไม่ นั่นยังไม่แม่นยำพอ "ไอ้โง่ สร้างเป็นไฟล์

579
00:52:19,647 --> 00:52:24,154
markdown ในเครื่องแทน โดยอ้างอิงเวอร์ชันท้องถิ่น"

580
00:52:24,154 --> 00:52:28,844
ขอโทษที พอมาถึงจุดนี้ เรามี issues ในเครื่องเป็นชุด

581
00:52:28,844 --> 00:52:35,557
ที่เราสามารถวน loop และ implement ได้ และ ณ จุดนี้แหละที่มนุษย์ออกจากวงวน

582
00:52:35,557 --> 00:52:40,523
ถึงตอนนี้ ขอเปิดภาพรวมของโฟลว์ที่เรากำลังสำรวจนี้ให้ดู

583
00:52:40,523 --> 00:52:48,064
เรามีไอเดียหนึ่ง ขอซูมให้คนแถวหลังดูหน่อย แล้วเราก็ซักถามตัวเองเกี่ยวกับไอเดียนั้น

584
00:52:48,064 --> 00:52:53,214
เราข้ามงานวิจัยและโปรโตไทป์ไปได้ แต่เราเปลี่ยนไอเดียเป็น

585
00:52:53,214 --> 00:52:57,537
PRD เป็นเอกสารจุดหมายปลายทาง จากนั้นเปลี่ยน PRD

586
00:52:57,537 --> 00:53:03,330
เป็น Kanban board และทุกขั้นตอนเหล่านั้นผ่านการตรวจสอบโดยมนุษย์

587
00:53:03,330 --> 00:53:09,860
และตอนนี้ถึงขั้น implementation เราถอยออกมา และปล่อยให้เอเจนต์ทำงานผ่าน

588
00:53:09,860 --> 00:53:14,642
Kanban board นั้น หรือเอเจนต์หลายตัวทำงานผ่าน Kanban

589
00:53:14,642 --> 00:53:19,884
board นี่หมายความว่า ใช่ เราทุ่มเวลาไปกับการวางแผนเยอะมาก

590
00:53:19,884 --> 00:53:24,206
แต่หมายความว่าเราได้จัดคิวงานให้เอเจนต์ไว้เพียบ

591
00:53:24,206 --> 00:53:30,092
เรามองมันได้เหมือนกะกลางวันกับกะกลางคืน นี่คือกะกลางวันของมนุษย์

592
00:53:30,092 --> 00:53:36,345
ใช่ไหม? วางแผนทุกอย่าง เตรียมของให้พร้อม แล้วพอเราส่งต่อให้กะกลางคืน

593
00:53:36,345 --> 00:53:40,668
AI ก็ทำงานแบบ AFK ได้เลย แต่หน้าตามันเป็นยังไง?

594
00:53:40,668 --> 00:53:46,186
ผมจะ... โอ้ ใช่ ปล่อยมันไปเถอะ สมบูรณ์แบบ นี่คือหน้าตาของมัน

595
00:53:46,186 --> 00:53:51,703
ถ้าเราไปที่แบบฝึกหัดถัดไป ซึ่งจริงๆ แล้วเป็นแบบฝึกหัดสุดท้าย

596
00:53:51,703 --> 00:53:56,210
คือการรัน AFK agent ของคุณ ผมตั้งชื่อมันว่า Ralph

597
00:53:56,210 --> 00:54:02,187
เพราะมันคือ Ralph loop จริงๆ และพรอมป์นี้ ผมอยากไล่ดูอย่างละเอียด

598
00:54:02,187 --> 00:54:08,165
สิ่งแรกที่มันทำคือ เราจะรัน Claude และพยายามกระตุ้นให้มันทำงานแบบ

599
00:54:08,165 --> 00:54:13,499
AFK เต็มรูปแบบ เดี๋ยวผมจะให้ดูสคริปต์ของมัน ถ้าคุณดูในไฟล์

600
00:54:13,499 --> 00:54:18,097
once.sh ใน repo เราจะเห็นว่ามันเป็นแค่ bash script

601
00:54:18,097 --> 00:54:22,511
ที่เราดึง issues ทั้งหมด ซึ่งอยู่ในไฟล์ markdown

602
00:54:22,511 --> 00:54:27,109
มาวางรวมไว้ในตัวแปรท้องถิ่น ตัวแปร issues นั้นเก็บ

603
00:54:27,109 --> 00:54:32,443
issues ทั้งหมดใน backlog (คิวงานค้าง) ของเรา จากนั้นดึงห้า

604
00:54:32,443 --> 00:54:37,409
commits ล่าสุด เดี๋ยวจะอธิบายว่าทำไม แล้วก็ดึงพรอมป์มา

605
00:54:37,409 --> 00:54:41,732
แล้วรัน Claude Code ด้วยโหมดสิทธิ์ accept edits

606
00:54:41,732 --> 00:54:46,882
แล้วก็ส่งข้อมูลทั้งหมดให้มัน นี่คือหน้าตาของ implementer

607
00:54:46,882 --> 00:54:51,480
(ตัวลงมือทำ) นี่คือเวอร์ชันที่เรียบง่ายมากของ loop

608
00:54:51,480 --> 00:54:56,630
แบบนี้ และแน่นอนว่านี่ไม่ใช่ loop นี่คือการรันครั้งเดียว

609
00:54:56,630 --> 00:55:01,228
loop อยู่ในเวอร์ชัน AFK ด้านบน ซึ่งซับซ้อนกว่าเยอะ

610
00:55:01,228 --> 00:55:06,286
และส่วนสำคัญคือ เรารันมันใน Docker sandbox (แซนด์บ็อกซ์

611
00:55:06,286 --> 00:55:11,160
Docker) ด้วย ผมไม่อยากให้คุณติดตั้ง Docker บนแล็ปท็อป

612
00:55:11,160 --> 00:55:15,574
เพราะเราจะต้องดาวน์โหลดอิมเมจพิเศษ และเราจะทำให้

613
00:55:15,574 --> 00:55:19,989
Wi-Fi ของงานประชุมล่มถ้าทำแบบนั้น ผมจะสาธิตให้ดู

614
00:55:19,989 --> 00:55:24,403
แต่คุณไม่จำเป็นต้องรันเอง ผมจะอธิบายในอีกสักครู่

615
00:55:24,403 --> 00:55:31,944
โดยพื้นฐานแล้ว once loop ตรงนี้ แบ้มๆๆๆ คือเราแค่รันเวอร์ชันหนึ่งของสิ่งที่เราจะวน

616
00:55:31,944 --> 00:55:36,266
loop ซ้ำแล้วซ้ำเล่า นี่คือเวอร์ชัน human in the

617
00:55:36,266 --> 00:55:41,324
loop และมันจำเป็นมาก การรันซ้ำแล้วซ้ำเล่าเป็นสิ่งจำเป็น

618
00:55:41,324 --> 00:55:45,831
เพราะคุณจะได้เห็นว่าเอเจนต์ทำอะไร และทำงานจบยังไง

619
00:55:45,831 --> 00:55:51,164
และถ้าต้องปรับแต่งพรอมป์เพิ่มเติม คุณก็ทำได้ มาดูพรอมป์กัน

620
00:55:51,164 --> 00:55:55,763
"ไฟล์ issues ในเครื่องถูกส่งเข้ามา คุณจะทำงานเฉพาะ

621
00:55:55,763 --> 00:56:00,085
issues แบบ AFK เท่านั้น" สมเหตุสมผล "ถ้างาน AFK

622
00:56:00,085 --> 00:56:04,867
ทั้งหมดเสร็จสิ้น ให้ output ข้อความว่าไม่มีงานเหลือ"

623
00:56:04,867 --> 00:56:10,109
และสิ่งถัดไปคือ เลือกงานถัดไป สิ่งที่เราทำตรงนี้คือการรัน

624
00:56:10,109 --> 00:56:15,627
backlog หรือคัดสรร backlog ที่ AFK agent ของเราจะมาหยิบงานไป

625
00:56:15,627 --> 00:56:19,949
นั่นคือจุดประสงค์ของการตั้งค่าทั้งหมดตั้งแต่แรก

626
00:56:19,949 --> 00:56:24,271
ตั้งแต่ต้นจนถึง Kanban board ตรงนี้ เราแค่สร้าง

627
00:56:24,271 --> 00:56:28,686
backlog ของงานสำหรับกะกลางคืนมาหยิบ และกะกลางคืน

628
00:56:28,686 --> 00:56:34,847
หรือพรอมป์ Ralph นี้ มีแนวคิดของตัวเองว่างานแบบไหนที่ดีควรหยิบต่อไป

629
00:56:34,847 --> 00:56:40,733
ผมพูดถึงเรื่อง parallelization ไปแล้ว และเดี๋ยวจะโชว์ให้ดูทีหลัง

630
00:56:40,733 --> 00:56:45,607
แต่นี่คือ loop แบบเรียงลำดับ เราจะรันทีละหนึ่ง coding

631
00:56:45,607 --> 00:56:52,137
agent นี่เป็นวิธีที่ดีในการเริ่มหัดลงน้ำ เอเจนต์จะจัดลำดับความสำคัญเป็น

632
00:56:52,137 --> 00:56:56,827
การแก้บั๊กวิกฤต โครงสร้างพื้นฐานสำหรับพัฒนา จากนั้น

633
00:56:56,827 --> 00:57:01,609
trace bullets ตามด้วยการขัดเกลา งานที่ได้เร็ว (quick

634
00:57:01,609 --> 00:57:07,494
wins) และ refactor (การปรับโครงสร้างโค้ด) จากนั้นก็มีคำสั่งง่ายๆ

635
00:57:07,494 --> 00:57:13,564
เกี่ยวกับวิธีทำงานให้เสร็จ "สำรวจ repo ใช้ TDD เพื่อทำงานให้เสร็จ"

636
00:57:13,564 --> 00:57:18,346
เดี๋ยวจะพูดถึงเรื่องนั้นทีหลัง แล้วเราก็รัน feedback

637
00:57:18,346 --> 00:57:23,680
loop บางอย่าง มาลองกัน ดูว่าจะเกิดอะไรขึ้น ดี มันสร้างไฟล์

638
00:57:23,680 --> 00:57:29,198
issues แล้ว พร้อมไปต่อได้เลย ผมจะยกเลิกอันนี้ ล้างแล้วรัน...

639
00:57:29,198 --> 00:57:33,612
อยู่ไหนนะ? Ralph once.sh และถ้าคุณกำลังทำตามอยู่

640
00:57:33,612 --> 00:57:37,935
ก็ทำแบบเดียวกันได้เลย เราจะเห็นว่ามันรัน Claude

641
00:57:37,935 --> 00:57:43,912
ในนี้พร้อมพรอมป์และ issues ทั้งหมดที่ส่งเข้าไป ระหว่างที่มันทำงาน

642
00:57:43,912 --> 00:57:52,097
คุณอาจมีคำถามเกี่ยวกับการตั้งค่านี้ และการตัดสินใจของผมที่จะมอบหมายงานเขียนโค้ดทั้งหมดให้

643
00:57:52,097 --> 00:57:56,879
AI ใช่ไหม? มาทำ Q&A เร็วๆ ระหว่างที่มันเริ่มทำงานกัน

644
00:57:56,879 --> 00:58:01,845
โอเค อ่าๆๆ ผมจะลบพวกนั้นทิ้ง "คุณเก็บการตัดสินใจเชิงลบ

645
00:58:01,845 --> 00:58:08,007
สิ่งที่คุณตัดสินใจไม่เอา และเหตุผล ไว้ยังไง ตอนที่บันทึกผลจากเซสชัน

646
00:58:08,007 --> 00:58:12,605
grill me?" คำถามดีมาก คำตอบง่ายมาก คือในส่วน write

647
00:58:12,605 --> 00:58:18,858
a PRD ของ PRD จะมีหัวข้ออยู่ด้านล่าง เป็นส่วนของสิ่งที่อยู่นอกขอบเขต

648
00:58:18,858 --> 00:58:23,365
(out of scope) คือสิ่งที่เราจะไม่จัดการใน PRD นี้

649
00:58:23,365 --> 00:58:29,434
ซึ่งสำคัญมากสำหรับการให้นิยามความสำเร็จ ถ้ามีคำถามเพิ่มเติมก็ถามใน

650
00:58:29,434 --> 00:58:34,033
Slido ได้เลย "เวิร์กโฟลว์ฟรอนต์เอนด์ของผมคืออะไร?"

651
00:58:34,033 --> 00:58:43,229
โอเค คำถามดีมาก ผมจะตอบคำถามนั้นในอีกสักครู่ "จะจัดการยังไงกับเอเจนต์ที่สร้างโค้ดมากเกินกว่าที่เราจะ

652
00:58:43,229 --> 00:58:49,850
review ไหว? จะ parallelize และใช้เอเจนต์หลายตัวอย่างถูกวิธีแยกกันยังไง?"

653
00:58:49,850 --> 00:58:54,816
โอเค นั่นเป็นสองคำถาม ยกมือขึ้นถ้ารู้สึกว่าตอนนี้คุณทำ

654
00:58:54,816 --> 00:59:01,162
code review (ทบทวนโค้ด) มากกว่าเดิม ใช่ แน่นอน ผมไม่คิดว่ามีทางเลี่ยง

655
00:59:01,162 --> 00:59:06,404
ถ้าเรามอบหมายงานเขียนโค้ดทั้งหมดให้เอเจนต์ คุณจะสังเกตว่า

656
00:59:06,404 --> 00:59:11,646
implementation คือส่วน AFK เพียงส่วนเดียวจริงๆ เรายังต้อง

657
00:59:11,646 --> 00:59:16,244
QA งานและ code review งานด้วย ใช่ไหม? และถ้าเรารัน

658
00:59:16,244 --> 00:59:21,026
loop แบบนี้ ที่มันจะ implement สี่ issues ในรอบเดียว

659
00:59:21,026 --> 00:59:26,636
มันก็ขัดกับหลักที่ว่า pull requests ควรเล็กและเป็นอิสระต่อกัน

660
00:59:26,636 --> 00:59:32,797
ใช่ไหม? pull requests เล็กๆ ที่เป็นอิสระต่อกัน หมายความว่าคุณต้องวน

661
00:59:32,797 --> 00:59:38,223
loop น้อยลง หรือ loop สั้นลง หรือบางทีอาจทำ PR เป็นกองใหญ่ๆ

662
00:59:38,223 --> 00:59:42,730
แต่ก็ดูแย่เหมือนกัน นั่นก็ยังเป็นโค้ดที่แยกกันให้

663
00:59:42,730 --> 00:59:47,328
review เพิ่มขึ้น ผมยังไม่รู้คำตอบของเรื่องนี้จริงๆ

664
00:59:47,328 --> 00:59:51,926
ผมคิดว่าเราต้องเตรียมใจที่จะทำ code review มากขึ้น

665
00:59:51,926 --> 00:59:56,432
ซึ่งไม่สนุกเลย การพูดแบบนั้นไม่สนุกเลย ผมไม่รู้สิ

666
00:59:56,432 --> 01:00:02,410
ผมไม่ค่อยสบายใจที่พูดแบบนั้น แต่ผมคิดว่าน่าจะเป็นทิศทางที่กำลังไป

667
01:00:02,410 --> 01:00:07,008
คำถามดีมาก ขอถามจากในห้องบ้างได้ไหม? เราไม่ใช้ไมค์

668
01:00:07,008 --> 01:00:12,342
แต่ยกมือถ้ามีคำถามถามผมตอนนี้ ใช่ "แนวทางนี้เป็นเส้นตรงมาก

669
01:00:12,342 --> 01:00:19,975
ตั้งแต่ไอเดียไปจนถึง QA และ code review แน่นอนว่าโลกความจริงมันยุ่งเหยิงกว่านั้นมาก

670
01:00:19,975 --> 01:00:26,045
คุณมีไอเดียหลายอย่างที่ดำเนินคู่ขนานกัน และไม่มีใครเห็นภาพทั้งหมด"

671
01:00:26,045 --> 01:00:31,654
และระหว่างที่คุณทำงานบางอย่างอยู่ ก็มีอย่างอื่นเข้ามาเป็นบั๊ก

672
01:00:31,654 --> 01:00:36,345
คุณจัดการกับความยุ่งเหยิงยังไง? ทำยังไงให้ feedback

673
01:00:36,345 --> 01:00:42,966
loop แน่นขึ้น? คำถามดีมาก คำถามคือ ถ้าเรื่องนี้ดูดีสำหรับนักพัฒนาคนเดียว

674
01:00:42,966 --> 01:00:48,300
แต่จะ implement ในทีมยังไง? จะรวบรวม feedback จากทีมยังไง?

675
01:00:48,300 --> 01:00:57,312
คำตอบของผมคือ ถ้าคุณมีไอเดียอยู่บนนั้น เส้นทางจากไอเดียไปสู่จุดหมายเป็นสิ่งที่คุณต้องคิดร่วมกับทีม

676
01:00:57,312 --> 01:01:01,727
ใช่ไหม? ทุกอย่างที่อยู่บนนี้ มันเป็นเรื่องของทีม

677
01:01:01,727 --> 01:01:06,325
เข้าใจที่ผมหมายถึงไหม? ถ้าคุณมีไอเดีย แล้วทำเซสชัน

678
01:01:06,325 --> 01:01:14,785
grilling กับมัน แล้วมีคำถามที่ตอบไม่ได้ คุณต้องดึงทีมเข้ามาในวงวนอย่างที่เราอธิบายไปก่อนหน้า

679
01:01:14,785 --> 01:01:20,211
บางทีคุณอาจต้องบอกว่า "โอเค เราต้องสร้างโปรโตไทป์ของสิ่งนี้

680
01:01:20,211 --> 01:01:26,005
เราต้องลองทำจริง เราต้องการของที่ผู้เชี่ยวชาญโดเมนจะได้ลองเล่น"

681
01:01:26,005 --> 01:01:31,339
หรือ "โอเค เราอาจต้อง integrate ไลบรารีของบริษัทอื่นเข้ามา

682
01:01:31,339 --> 01:01:36,121
เราอาจต้องทำงานวิจัย" เราอาจต้องโยนความคิดไปมา และหา

683
01:01:36,121 --> 01:01:40,903
service ของบริษัทที่สามที่เราใช้ประโยชน์ได้มากที่สุด

684
01:01:40,903 --> 01:01:45,869
เราอาจต้องนำข้อมูลที่เก็บได้กลับไปที่เฟสไอเดีย ดังนั้น

685
01:01:45,869 --> 01:01:51,203
ตลอดเส้นทางจนถึง PRD นั่นคือสิ่งที่คุณต้องให้ทีมมีส่วนร่วม

686
01:01:51,203 --> 01:01:56,997
นั่นคือจุดที่ asset เหล่านี้จะถูกแชร์ต่อ และจะมีคำขอความคิดเห็น

687
01:01:56,997 --> 01:02:02,423
(requests for comments) กับมัน และ loop นั้นก็จะบดไปเรื่อยๆ

688
01:02:02,423 --> 01:02:07,297
จนกว่าคุณจะรู้ว่าจะไปทางไหน พอคุณรู้ว่าจะไปทางไหนแล้ว

689
01:02:07,297 --> 01:02:11,803
คุณถึงเริ่มทำ Kanban board และ implementation ได้

690
01:02:11,803 --> 01:02:17,965
แต่นี่เป็นเรื่องที่ถกเถียงกันได้มาก และคุณจะเด้งไปมาระหว่างเฟสต่างๆ

691
01:02:17,965 --> 01:02:23,023
เข้าใจไหม? ใช่ "คุณไม่ต้องการ PRD สำหรับโปรโตไทป์เหรอ?"

692
01:02:23,023 --> 01:02:29,092
พูดอีกทีได้ไหม ขอโทษ "คุณไม่อยากมี PRD สำหรับโปรโตไทป์ของคุณเหรอ?"

693
01:02:29,092 --> 01:02:34,794
คำถามคือ คุณอยากผ่านกระบวนการทั้งหมดนี้เพื่อสร้างโปรโตไทป์เฉยๆ

694
01:02:34,794 --> 01:02:41,140
เหรอ? คุณไม่จำเป็นต้องมี PRD สำหรับโปรโตไทป์ ขอพูดถึงโปรโตไทป์สักครู่

695
01:02:41,140 --> 01:02:45,646
มีคำถามว่า ทำยังไงให้วิธีนี้ใช้กับฟรอนต์เอนด์ได้?

696
01:02:45,646 --> 01:02:54,934
เพราะฟรอนต์เอนด์ไวต่อสายตามนุษย์มาก คุณต้องมีสายตามนุษย์มองฟรอนต์เอนด์ตลอดเวลาเพื่อให้แน่ใจว่ามันดูดี

697
01:02:54,934 --> 01:03:00,820
AI ไม่มีตา มันดูโค้ดได้ แต่ฟรอนต์เอนด์เป็นสิ่งที่ต้องมองหลายมิติ

698
01:03:00,820 --> 01:03:05,694
(multimodal) จากประสบการณ์ของผมในการลองต่อ AI เข้ากับ

699
01:03:05,694 --> 01:03:12,407
agent browser หรือ Playwright MCP (โปรโตคอลที่ให้โมเดลเรียกใช้เครื่องมือ)

700
01:03:12,407 --> 01:03:16,913
เพื่อให้มันมีเครื่องมือมองผ่านฟรอนต์เอนด์และดูภาพ

701
01:03:16,913 --> 01:03:21,328
แต่จากประสบการณ์ มันยังไม่เก่งเรื่องนั้นเท่าไหร่

702
01:03:21,328 --> 01:03:26,662
และมันสร้างฟรอนต์เอนด์ที่สวยงามในโค้ดเบสที่โตเต็มที่ไม่ได้

703
01:03:26,662 --> 01:03:31,536
มันทำได้แค่พ่นๆ ออกมา แต่สิ่งที่มันทำได้คือ คุณบอกว่า

704
01:03:31,536 --> 01:03:36,686
"โอเค ผมอยากได้ไอเดียว่าฟรอนต์เอนด์นี้ควรหน้าตาเป็นยังไง

705
01:03:36,686 --> 01:03:41,928
สร้างโปรโตไทป์สามแบบให้ฉัน สลับดูได้ใน route แบบทิ้งขว้าง

706
01:03:41,928 --> 01:03:46,894
(throwaway route) แล้วฉันจะตัดสินใจว่าอันไหนสวยที่สุด"

707
01:03:46,894 --> 01:03:51,676
แล้วคุณก็นำ asset ของโปรโตไทป์นั้นกลับเข้าไปในเซสชัน

708
01:03:51,676 --> 01:03:57,378
grilling หรือขอ feedback กับมัน อะไรแบบนั้น ตอบคำถามคุณได้ไหม?

709
01:03:57,378 --> 01:04:01,976
โปรโตไทป์มันก็แค่ของที่เละๆ มันมีไว้เพื่อให้คุณได้

710
01:04:01,976 --> 01:04:08,689
feedback เร็วขึ้นในกระบวนการ นั่นคือวิธีที่ดีในการทำงานกับโค้ดฟรอนต์เอนด์

711
01:04:08,689 --> 01:04:13,287
และเป็นวิธีที่ดีในการมองสถาปัตยกรรมซอฟต์แวร์โดยรวม

712
01:04:13,287 --> 01:04:17,702
ขออีกหนึ่งคำถาม ใช่ >> [กระแอม] >> "ในระบบของคุณ

713
01:04:17,702 --> 01:04:22,116
คุณ integrate การเคารพสถาปัตยกรรมและการออกแบบกับ

714
01:04:22,116 --> 01:04:27,910
API contracts (สัญญา API) และการเข้ากับระบบที่ใหญ่กว่าได้ยังไง?

715
01:04:27,910 --> 01:04:32,416
ข้อจำกัดด้านความปลอดภัย ข้อจำกัดทุกประเภทแบบนั้น"

716
01:04:32,416 --> 01:04:39,589
ใช่ คำถามนี้มีอะไรเยอะแยะ คำถามคือ คุณทำให้มันสอดคล้องกับสถาปัตยกรรมเดิมยังไง?

717
01:04:39,589 --> 01:04:45,291
ทำยังไงให้มันเป็นไปตามมาตรฐานโค้ดของโค้ดเบสคุณ หรือสถาปัตยกรรม

718
01:04:45,291 --> 01:04:49,889
การออกแบบ API กฎความปลอดภัยที่จำกัดการออกแบบของคุณ

719
01:04:49,889 --> 01:04:56,234
ใช่ ผมจะตอบเรื่องนั้นอีกสักครู่ โอเค หวังว่าเราจะเริ่มมีอะไรเดือดปุดๆ

720
01:04:56,234 --> 01:05:00,557
แล้ว มันกำลังอยู่ในเฟสสำรวจ อืม อยากเริ่มรันแบบ

721
01:05:00,557 --> 01:05:05,707
AFK เลยจัง บางทีอาจทำ บางทีอาจไม่ทำ สิ่งที่มันทำคือสำรวจ

722
01:05:05,707 --> 01:05:13,248
repo จากนั้นจะเริ่ม implement ตามที่เราต้องการ ขออีกหนึ่งคำถามระหว่างที่มันรันอยู่

723
01:05:13,248 --> 01:05:17,570
ใช่ "ทำไมไม่ให้ AI QA ทุกอย่างเลยล่ะ?" คำถามคือ

724
01:05:17,570 --> 01:05:24,835
ทำไมคุณไม่ให้ AI ทำ QA? AI มาทำ QA ผมเพิ่งเจอศัพท์เทคนิคทะลักเข้าหัวไปแป๊บหนึ่ง

725
01:05:24,835 --> 01:05:29,801
ทำไมคุณไม่ให้ AI ทดสอบโค้ดของตัวเอง? แน่นอนว่าคุณทำได้

726
01:05:29,801 --> 01:05:35,043
และระหว่างที่มันกำลังทำ ระหว่างที่มันเดือดปุดๆ อยู่ตรงนี้

727
01:05:35,043 --> 01:05:39,458
โอเค มันเห็นภาพโค้ดเบสชัดเจนแล้ว มันกำลังประเมิน

728
01:05:39,458 --> 01:05:45,343
issues มันเลือกทำ issue 02 เป็นงานถัดไป เดี๋ยวผมจะโชว์ให้ดูอีกที

729
01:05:45,343 --> 01:05:50,493
เพราะคุณควรทำขั้นตอน review แบบอัตโนมัติเป็นส่วนหนึ่งของ

730
01:05:50,493 --> 01:05:55,183
implementation อย่างแน่นอน พอมี implementation แล้ว

731
01:05:55,183 --> 01:05:59,782
เพราะ token ราคาถูกและ AI เก่งเรื่องการ review มาก

732
01:05:59,782 --> 01:06:04,288
คุณควรให้มัน review โค้ดของตัวเองก่อน แล้วค่อย QA

733
01:06:04,288 --> 01:06:08,794
ผมพบว่ามันจับบั๊กได้เยอะมาก และวิธีที่มันทำงานคือ

734
01:06:08,794 --> 01:06:13,116
ขอวาดไดอะแกรมเล็กๆ ถ้าคุณมีการ implement ที่ใช้

735
01:06:13,116 --> 01:06:17,898
token ไปเยอะในโซนฉลาด แล้วให้มันลอง review ต่อเนื่อง

736
01:06:17,898 --> 01:06:22,956
มันจะ review ในโซนโง่ ดังนั้นผู้ review จะโง่กว่าตัวที่

737
01:06:22,956 --> 01:06:28,934
implement จริงๆ ถ้าเราจินตนาการว่านี่คือ... ขอให้สอดคล้องกันหน่อย

738
01:06:28,934 --> 01:06:34,084
นั่นคือ review นั่นคือ implementation ในขณะที่ถ้าคุณล้าง

739
01:06:34,084 --> 01:06:40,062
context คุณจะสามารถ review ในโซนฉลาดได้ ซึ่งเป็นที่ที่คุณอยากอยู่

740
01:06:40,062 --> 01:06:44,568
มาดูกันว่า implementation ของเราเป็นยังไง โอเค ดี

741
01:06:44,568 --> 01:06:49,626
มันกำลังสร้าง migration (ไฟล์ย้ายฐานข้อมูล) ดูดีทีเดียว

742
01:06:49,626 --> 01:06:54,408
เราได้โค้ดพ่นออกมาแล้ว และระหว่างที่ผม... อ่า เอาล่ะ

743
01:06:54,408 --> 01:06:59,374
TDD มาพูดถึง TDD กัน แล้วคิดว่าเราจะพักเบรกอีกสักหน่อย

744
01:06:59,374 --> 01:07:03,696
TDD ผมพบว่าจำเป็นสุดๆ ในการดึงศักยภาพจากเอเจนต์

745
01:07:03,696 --> 01:07:08,111
ยกมือขึ้นถ้ารู้ว่า TDD คืออะไร เจ๋ง โอเค TDD คือ

746
01:07:08,111 --> 01:07:12,801
test-driven development (การพัฒนาแบบเขียนเทสต์ก่อน)

747
01:07:12,801 --> 01:07:17,307
สิ่งที่มันทำคือสิ่งที่เรียกว่า red-green-refactor

748
01:07:17,307 --> 01:07:21,997
(แดง-เขียว-รีแฟกเตอร์) และถ้าคุณดูในโค้ดเบส คุณจะพบ

749
01:07:21,997 --> 01:07:26,320
skill ที่อธิบายวิธีทำ red green refactor และสอน

750
01:07:26,320 --> 01:07:31,929
AI ว่าต้องทำยังไง สิ่งที่มันทำคือเขียนเทสต์ที่ต้องล้มเหลวก่อน

751
01:07:31,929 --> 01:07:37,907
มันบอกว่า "โอเค ผมแยกย่อยแนวคิดที่กำลังทำ แล้วจะเขียนเทสต์เดี่ยวๆ

752
01:07:37,907 --> 01:07:42,781
ที่ล้มเหลว จากนั้นต้องทำให้ implementation ผ่านเทสต์"

753
01:07:42,781 --> 01:07:48,851
ผมพบว่า อย่างแรก มันเพิ่มเทสต์เข้าไปในโค้ดเบส และมักเป็นเทสต์ที่ดี

754
01:07:48,851 --> 01:07:56,944
เรามี gamification service แบบนี้ มันดูเหมือนใช้ของเดิมที่มีอยู่เพื่อสร้างเทสต์ฐานข้อมูล

755
01:07:56,944 --> 01:08:02,185
เทสต์ล้มเหลวเพราะโมดูลยังไม่มี โอเค เรายืนยันสถานะแดงแล้ว

756
01:08:02,185 --> 01:08:07,244
จากนั้นมันก็ไปรันและหวังว่ามันจะผ่าน ยกมือขึ้นถ้าเคยเจอ

757
01:08:07,244 --> 01:08:13,497
AI เขียนเทสต์ห่วยๆ ใช่ มันมักจะพยายามโกงเทสต์ เพราะมันทำแบบเป็นชั้นๆ

758
01:08:13,497 --> 01:08:20,026
มันจะทำ implementation ทั้งหมดก่อน แล้วค่อยทำเลเยอร์เทสต์ทั้งหมดตามลงมา

759
01:08:20,026 --> 01:08:24,901
ผมจะตอบว่า ใช่ คุณใช้ NPX vitest ได้ และด้วยเทคนิคนี้

760
01:08:24,901 --> 01:08:29,683
การโกงทำได้ยากขึ้นมาก เพราะมันต้องสร้างเครื่องมือวัด

761
01:08:29,683 --> 01:08:34,281
(instrument) โค้ดก่อน แล้วค่อยเขียนโค้ด ผมเลยพบว่า

762
01:08:34,281 --> 01:08:41,914
TDD ดีมากๆ สำหรับที่ที่ทำได้จริง ที่จริงมันดีขนาดที่ผมบิดเทคนิคทั้งหมดของผมเพื่อให้

763
01:08:41,914 --> 01:08:47,432
TDD ทำงานได้ดีขึ้น ผมเห็นสายตาที่เริ่มเคลิ้ม มันร้อนมากในนี้

764
01:08:47,432 --> 01:08:51,754
คุณนึกภาพไม่ออกว่าบนเวทีร้อนแค่ไหน พักเบรกอีก 5

765
01:08:51,754 --> 01:08:57,272
นาทีดีกว่า กลับมาเวลาสี่สิบห้านาที น่าจะได้ พักให้เต็มที่เลย

766
01:08:57,272 --> 01:09:03,433
แล้วเราจะกลับมาอีกทีในราว 6-7 นาที แล้วผมจะพูดถึงวิธีคิดเรื่องโมดูล

767
01:09:03,433 --> 01:09:07,940
การสร้างโค้ดเบสให้สิ่งนี้เป็นไปได้ ผมเพิ่งเล่นกับ

768
01:09:07,940 --> 01:09:12,998
AI ตรงนี้ และเราได้ commit มาหนึ่งอัน มีของให้ทดสอบแล้ว

769
01:09:12,998 --> 01:09:18,424
issue หมายเลขสองเสร็จแล้ว นี่คือสิ่งที่ทำไป นี่คือหน้าตาตอน

770
01:09:18,424 --> 01:09:25,137
Ralph loop เสร็จสมบูรณ์ คือคุณจะได้บทสรุปเล็กๆ และตอนนี้เรามีของที่สามารถ

771
01:09:25,137 --> 01:09:29,643
QA ได้ เพราะเราทำ feedback loops เพราะเราทำ trace

772
01:09:29,643 --> 01:09:35,161
bullets เพราะเราบอกว่า "โอเค ให้ของที่ review ได้ตอนจบหน่อย"

773
01:09:35,161 --> 01:09:40,311
เราก็เข้าไป QA ได้ทันที ไม่มีอะไรน่าเบื่อเท่าการดูคนอื่น

774
01:09:40,311 --> 01:09:45,921
QA แล้ว หวังว่าเราจะได้ลองเล่นกันบ้าง ขอเช็กว่ามันทำงานได้ไหม

775
01:09:45,921 --> 01:09:50,703
ที่จริง ก่อนไปตรงนั้น ผมอยากไล่ดูว่าเกิดอะไรขึ้นบ้าง

776
01:09:50,703 --> 01:09:55,761
คือเราเห็นว่ามันสร้างของบางอย่างบนแดชบอร์ด แล้วมันก็รัน

777
01:09:55,761 --> 01:10:01,095
feedback loops คือรันเทสต์และเช็ก types TDD สำคัญมากแน่นอน

778
01:10:01,095 --> 01:10:05,601
และมันสำคัญเพราะ feedback loops เหล่านี้จำเป็นต่อ

779
01:10:05,601 --> 01:10:11,119
AI จำเป็นต่อการให้ AI ผลิตอะไรที่สมเหตุสมผล เพราะถ้าไม่มีมัน

780
01:10:11,119 --> 01:10:15,625
AI จะเขียนโค้ดแบบมืดบอดสนิท ถ้าโค้ดเบสของคุณไม่มี

781
01:10:15,625 --> 01:10:19,947
feedback loops คุณจะไม่มีวันได้ output ที่ดีจาก

782
01:10:19,947 --> 01:10:24,546
AI และบ่อยครั้งคุณจะพบว่า คุณภาพของ feedback loops

783
01:10:24,546 --> 01:10:29,236
คือตัวกำหนดว่า AI เขียนโค้ดได้ดีแค่ไหน นั่นคือเพดาน

784
01:10:29,236 --> 01:10:34,110
ถ้าคุณได้ output แย่ๆ จาก AI คุณมักต้องเพิ่มคุณภาพของ

785
01:10:34,110 --> 01:10:38,708
feedback loops เดี๋ยวเราจะพูดถึงวิธีทำในอีกสักครู่

786
01:10:38,708 --> 01:10:43,122
ตอนนี้มันรัน npm run test และ npm run type check

787
01:10:43,122 --> 01:10:47,904
มันเจอ type error หนึ่งตัว และต้องแก้ด้วย TypeScript

788
01:10:47,904 --> 01:10:52,411
magic สักหน่อย ดีมาก ใช่ type ของ level threshold

789
01:10:52,411 --> 01:10:57,653
เป็น number โอเค คุณเห็นไหมว่าทำไมผมถึงเลิกสอน TypeScript

790
01:10:57,653 --> 01:11:02,251
เพราะตอนนี้ AI รู้ทุกอย่างแล้ว มันรันเทสต์แล้วผ่าน

791
01:11:02,251 --> 01:11:07,125
ดูดีมาก ตอนนี้เรามีเทสต์ 284 ตัวใน repo นี้ ดีทีเดียว

792
01:11:07,125 --> 01:11:12,275
ผมพบว่าฟรอนต์เอนด์ทดสอบยากจริงๆ ในโครงการนี้ เราทดสอบแค่

793
01:11:12,275 --> 01:11:17,149
service เป็นหลัก เราสร้าง gamification service ขึ้นมา

794
01:11:17,149 --> 01:11:22,115
ถ้าดูตรงนี้ แล้วก็มีเทสต์สำหรับ service นั้น คุณจะเห็น

795
01:11:22,115 --> 01:11:26,437
service กับเทสต์ของมัน ถ้าผมกำลังทำ code review

796
01:11:26,437 --> 01:11:32,875
ผมจะเริ่มจาก review เทสต์ก่อน ให้แน่ใจว่าเทสต์ตรวจสอบสิ่งที่สมเหตุสมผล

797
01:11:32,875 --> 01:11:38,944
แล้วค่อย review ตัวโค้ดเพื่อให้แน่ใจว่ามันไม่ได้ทำอะไรเพี้ยนเกินไป

798
01:11:38,944 --> 01:11:44,186
สิ่งสำคัญคือผมต้องดูแดชบอร์ดจริงๆ ผมจะล็อกอินเป็นนักเรียน

799
01:11:44,186 --> 01:11:49,428
โอ้ ถ้ามันยอมให้ล็อกอิน บางทีมันอาจไม่ยอม ไม่เอาน่าเพื่อน

800
01:11:49,428 --> 01:11:53,843
เอาล่ะ ล็อกอินเป็น Emma Wilson เข้าไปที่ courses

801
01:11:53,843 --> 01:11:58,901
สมมติว่าผมมีคอร์ส Introduction to TypeScript กดเรียนต่อ

802
01:11:58,901 --> 01:12:03,775
ใช่ ผมเรียนบทเรียนนี้จบแล้ว แล้วมีอะไรบางอย่างผิดพลาด

803
01:12:03,775 --> 01:12:09,384
ผมเดาว่าเพราะผมไม่มี... เออเร่อ SQLite ผมไม่มีตารางที่ถูกต้อง

804
01:12:09,384 --> 01:12:15,178
ผมต้องมีตาราง point events point events เป็นชื่อตารางที่แปลกมาก

805
01:12:15,178 --> 01:12:19,960
ไม่รู้ว่ามันคิดอะไรอยู่ ขอพักก่อน รัน npm db:migrate

806
01:12:19,960 --> 01:12:24,834
หรือ push ผมจำไม่ได้ว่าอันไหน แต่คุณคงพอเข้าใจใช่ไหม?

807
01:12:24,834 --> 01:12:29,525
ผมจะไม่ทรมานคุณด้วยการดูผมทำ QA เพราะมันน่าเบื่อมาก

808
01:12:29,525 --> 01:12:33,939
แต่ ณ จุดนี้ ผมจะกลับเข้าไป ขอเปิดโปรเจกต์กลับมา

809
01:12:33,939 --> 01:12:38,629
และผมจะ... นี่คือช่วงเวลาสำคัญ และสำคัญมากที่จะต้อง

810
01:12:38,629 --> 01:12:43,043
QA ด้วยมือตรงนี้ เพราะ QA โอ้ ไม่ๆ เกิดอะไรขึ้น?

811
01:12:43,043 --> 01:12:49,021
เอาล่ะ QA คือวิธีที่ผมยัดเยียดความคิดเห็นของผมกลับเข้าไปในโค้ดเบส

812
01:12:49,021 --> 01:12:53,343
วิธีที่ผมยัดเยียดรสนิยมของผม สิ่งที่คุณมักพบคือ

813
01:12:53,343 --> 01:12:58,769
มีทีมที่พยายามทำให้ทุกอย่างอัตโนมัติ ทุกส่วนของกระบวนการนี้

814
01:12:58,769 --> 01:13:03,275
และถ้าคุณลองทำให้การสร้างไอเดียอัตโนมัติ ทำให้ QA

815
01:13:03,275 --> 01:13:08,425
อัตโนมัติ ทำให้งานวิจัยอัตโนมัติ ทำให้โปรโตไทป์อัตโนมัติ

816
01:13:08,425 --> 01:13:13,667
คุณจะได้แอปที่ผมรู้สึกว่าขาดรสนิยมและแย่ บางทีมันไม่ทำงาน

817
01:13:13,667 --> 01:13:21,944
หรือทำงานไม่ตรงตามที่ตั้งใจ หรือมันไม่มี... คุณต้องมีสัมผัสของมนุษย์ในการสร้างสิ่งเหล่านี้

818
01:13:21,944 --> 01:13:28,289
เพราะถ้าไม่มี คุณจะได้แค่ของเละๆ (slop) และเราที่นี่ไม่ได้ผลิตของเละๆ

819
01:13:28,289 --> 01:13:32,980
เราพยายามผลิตของที่มีคุณภาพสูง นั่นคือจุดประสงค์ของ

820
01:13:32,980 --> 01:13:38,497
QA ในส่วนสุดท้ายนี้ผมจะทำสองอย่าง อย่างแรกคือ ผมจะบอกวิธี...

821
01:13:38,497 --> 01:13:43,464
ในใจคุณอาจมีคำถามว่า สมมติผมมีโค้ดเบสที่กำลังทำงานด้วย

822
01:13:43,464 --> 01:13:48,981
และมันเป็นโค้ดเบสที่แย่ ซับซ้อนมาก AI ไม่เคยทำงานในนั้นได้ดี

823
01:13:48,981 --> 01:13:55,419
และจริงๆ แล้วมนุษย์ส่วนใหญ่ที่เข้าไปในโค้ดเบสนั้นก็ทำงานไม่ดีเหมือนกัน

824
01:13:55,419 --> 01:14:01,856
จะปรับปรุงโค้ดเบสนั้นยังไง? และอย่างที่สองคือ ผมจะโชว์การตั้งค่าสำหรับ

825
01:14:01,856 --> 01:14:06,914
parallelization ของผม เริ่มจากโค้ดที่แย่ก่อน อยู่ไหนนะ?

826
01:14:06,914 --> 01:14:11,237
ไดอะแกรมอยู่ไหน? นี่ไง ในหนังสือ The Philosophy

827
01:14:11,237 --> 01:14:16,938
of Software Design ของ John Ousterhout เขาพูดถึงโมดูลในอุดมคติ

828
01:14:16,938 --> 01:14:22,824
ลองจินตนาการว่าคุณมีโค้ดเบสหน้าตาแบบนี้ แต่ละบล็อกคือไฟล์เดี่ยวๆ

829
01:14:22,824 --> 01:14:29,813
และไฟล์เหล่านี้ export สิ่งต่างๆ ออกมา มีสิ่งที่คุณดึงจากไฟล์ไปใช้ในสิ่งอื่น

830
01:14:29,813 --> 01:14:34,320
คุณอาจมี dependency แปลกๆ ที่ไฟล์นี้พึ่งพาไฟล์นี้

831
01:14:34,320 --> 01:14:38,734
หรือพึ่งพาไฟล์นั้น ถ้าไฟล์เหล่านี้เล็กและไม่ค่อย

832
01:14:38,734 --> 01:14:43,056
export อะไรมากมาย John Ousterhout จะเรียกมันว่า

833
01:14:43,056 --> 01:14:47,654
shallow modules (โมดูลตื้น) พวกมันจะดูประมาณนี้...

834
01:14:47,654 --> 01:14:52,712
ไม่ ไม่ใช่ ฉันวาดไดอะแกรมสวยๆ ไม่ได้ พวกมันคือก้อนเล็กๆ

835
01:14:52,712 --> 01:15:00,345
มากมายมหาศาล ซึ่งยากที่ AI จะสำรวจ เพราะมันไม่เข้าใจความสัมพันธ์ระหว่างทุกสิ่งจริงๆ

836
01:15:00,345 --> 01:15:05,863
มันหาว่าอะไรอยู่ตรงไหนไม่เจอ มันต้องไล่ตามกราฟทั้งหมดด้วยมือ

837
01:15:05,863 --> 01:15:10,829
แล้วบอกว่า "โอเค อันนี้พึ่งพาอันนี้ อันนี้พึ่งพาอันนี้

838
01:15:10,829 --> 01:15:18,002
อันนี้พึ่งพาอันนี้" แล้วมันก็ยากที่จะทดสอบด้วย เพราะคุณจะขีดเส้นขอบเขตการทดสอบ

839
01:15:18,002 --> 01:15:23,152
(test boundaries) ตรงไหน? คุณจะทดสอบแต่ละโมดูลแยกกันไหม?

840
01:15:23,152 --> 01:15:28,026
ขีดเส้นขอบเขตการทดสอบ... ไม่ อย่าทำแบบนั้น รอบอันนี้?

841
01:15:28,026 --> 01:15:34,280
แล้วก็เส้นอีกอันรอบอันถัดไป แล้วก็อันถัดไป? หรือคุณควรรวมกลุ่มใหญ่ๆ?

842
01:15:34,280 --> 01:15:40,350
คุณจะบอกว่า "โอเค เราจะทดสอบโมดูลที่เกี่ยวข้องกันทั้งหมดนี้ด้วยกัน

843
01:15:40,350 --> 01:15:44,764
แล้วก็หวังและอธิษฐานว่ามันจะทำงาน" >> [ถอนหายใจ]

844
01:15:44,764 --> 01:15:50,558
>> นี่หมายความว่า ถ้าผมคิดว่าเทสต์ที่แย่ๆ ส่วนใหญ่หน้าตาแบบนั้น

845
01:15:50,558 --> 01:15:56,075
คือ AI พยายามห่อทุกฟังก์ชันเล็กๆ ด้วยขอบเขตการทดสอบของมันเอง

846
01:15:56,075 --> 01:16:00,582
แล้วก็แค่ทดสอบว่ามันทำงานเดี่ยวๆ แต่ผลที่ตามมาคือ

847
01:16:00,582 --> 01:16:05,732
สมมติว่าโมดูลตรงนี้เรียกสองโมดูลนั้น มันพึ่งพาทั้งสองตัว

848
01:16:05,732 --> 01:16:14,192
โมดูลนี้อาจเรียกใช้ฟังก์ชันผิดลำดับ หรืออาจมีอะไรในโมดูลที่น่าสงสารนั้นที่ควรทดสอบแยกต่างหาก

849
01:16:14,192 --> 01:16:18,607
แล้วถ้าคุณห่อมันด้วยขอบเขตการทดสอบ คุณจะทำยังไง?

850
01:16:18,607 --> 01:16:23,113
คุณจะ mock (จำลอง) อีกสองโมดูลไหม? มันทำงานยังไง?

851
01:16:23,113 --> 01:16:28,447
ดังนั้น การหาวิธีสร้างโค้ดเบสที่ทดสอบง่ายจึงเป็นสิ่งจำเป็น

852
01:16:28,447 --> 01:16:33,413
เพราะถ้าโค้ดเบสทดสอบง่าย feedback loops ของเราจะดีขึ้น

853
01:16:33,413 --> 01:16:37,919
และ AI จะทำงานได้ดีขึ้นในโค้ดเบสของเรา เข้าใจไหม?

854
01:16:37,919 --> 01:16:43,437
แล้วโค้ดเบสที่ดีหน้าตาเป็นยังไง? ไม่ใช่แบบนั้น มันเป็นแบบนี้

855
01:16:43,437 --> 01:16:48,035
คือมีสิ่งที่ John Ousterhout เรียกว่า deep modules

856
01:16:48,035 --> 01:16:55,668
(โมดูลลึก) โมดูลที่มีอินเทอร์เฟซเล็กๆ ข้างนอก เปิดเผยอินเทอร์เฟซที่เล็กและเรียบง่าย

857
01:16:55,668 --> 01:17:01,462
แต่ข้างในมีฟังก์ชันการทำงานมากมาย นี่หมายความว่าพวกมันทดสอบง่าย

858
01:17:01,462 --> 01:17:06,888
เพราะคุณแค่... สมมติว่ามี dependency ระหว่างอันนี้กับอันนี้

859
01:17:06,888 --> 01:17:11,302
ลูกศรผมใช้ได้ไหม? ใช่ เอาล่ะ แล้วสิ่งที่คุณทำคือ

860
01:17:11,302 --> 01:17:16,544
ขีดเส้นขอบเขตการทดสอบขนาดใหญ่รอบโมดูลนั้น รอบอันนี้ข้างบน

861
01:17:16,544 --> 01:17:22,705
แล้วคุณจะจับของดีๆ ได้เยอะ เพราะมีฟังก์ชันการทำงานมากมายที่คุณทดสอบ

862
01:17:22,705 --> 01:17:28,223
และผู้เรียกใช้ (caller) คนที่เรียกโมดูล จะมีอินเทอร์เฟซง่ายๆ

863
01:17:28,223 --> 01:17:33,281
ให้ใช้งาน ไม่ยากเกินไป เข้าใจไหม? deep modules เทียบกับ

864
01:17:33,281 --> 01:17:37,696
shallow modules อันนี้ดี เวอร์ชันตื้นๆ แบบนี้แย่

865
01:17:37,696 --> 01:17:43,121
และสิ่งที่ผมพบคือ ถ้าไม่มีการช่วยเหลือ หรือถ้าคุณไม่จับตาดู

866
01:17:43,121 --> 01:17:49,007
AI อย่างใกล้ชิด มันจะผลิตโค้ดเบสหน้าตาแบบนี้ คุณต้องระวังให้มากๆ

867
01:17:49,007 --> 01:17:53,605
ตอนที่คุมมัน และนั่นคือเหตุผลที่ ถ้าเรามองเข้าไปใน

868
01:17:53,605 --> 01:17:58,204
PRD PRD หายไปไหน? มันอยู่ใน issues ใน gamification

869
01:17:58,204 --> 01:18:03,262
system หาไม่เจอ แน่นอนสิว่าหาไม่เจอ นี่ไง แล้วในนี้ผมมี

870
01:18:03,262 --> 01:18:08,503
data model โมดูลต่างๆ มันระบุชัดเจนว่า "โอเค gamification

871
01:18:08,503 --> 01:18:13,378
service นี้เป็น deep module ใหม่ ซึ่งเราจะทดสอบรอบมัน

872
01:18:13,378 --> 01:18:18,068
มันจะมีอินเทอร์เฟซแบบนี้โดยเฉพาะ และมันจะมี... โอเค

873
01:18:18,068 --> 01:18:22,574
เรากำลังแก้ progress service ด้วย กำลังแก้ lesson

874
01:18:22,574 --> 01:18:30,207
route กำลังแก้ dashboard route อะไรพวกนี้ ผมระบุโมดูลที่กำลังแก้อย่างเฉพาะเจาะจงมาก

875
01:18:30,207 --> 01:18:36,001
และทำให้แน่ใจว่าผมเก็บแผนที่โมดูล (module map) ไว้ในหัวตลอดเวลา

876
01:18:36,001 --> 01:18:40,875
ทั้งระหว่างวางแผนและระหว่าง implementation เข้าใจไหม?

877
01:18:40,875 --> 01:18:45,381
มีประโยชน์มากๆ และยังมีประโยชน์อีกเหตุผลหนึ่งด้วย

878
01:18:45,381 --> 01:18:52,002
ไม่เพียงแต่ทำให้แอปของคุณทดสอบง่ายขึ้น แต่คุณยังได้เล่นกลทางความคิดเล็กๆ

879
01:18:52,002 --> 01:18:56,325
ขอเติมน้ำก่อน ในระหว่างที่คุณรอฟังว่ามันคืออะไร

880
01:18:56,325 --> 01:19:02,210
ขอถามจากพวกคุณหน่อย ยกมือขึ้นถ้ารู้สึกว่าทำงานหนักกว่าเดิมมากกับ

881
01:19:02,210 --> 01:19:08,372
AI ใช่ ยกมือขึ้นถ้ารู้สึกว่ารู้จักโค้ดเบสของตัวเองน้อยกว่าเมื่อก่อน

882
01:19:08,372 --> 01:19:14,717
ใช่ นี่คือเรื่องจริง เพราะเราเคลื่อนที่เร็ว เพราะเรามอบหมายงานมากขึ้น

883
01:19:14,717 --> 01:19:21,155
เราจึงสูญเสียความรู้สึกต่อโค้ดเบส และถ้าเราสูญเสียความรู้สึกต่อโค้ดเบส

884
01:19:21,155 --> 01:19:26,581
เราจะไม่สามารถปรับปรุงมันได้ และเรากำลังมอบรูปร่างของมันให้

885
01:19:26,581 --> 01:19:35,961
AI จริงๆ ผมไม่คิดว่านั่นเป็นสิ่งที่ดี แล้วเราจะทำยังไงให้เคลื่อนที่เร็วพร้อมกับเก็บพื้นที่ในสมองไว้พอ?

886
01:19:35,961 --> 01:19:43,318
ผมว่านี่คือหนทาง เพราะสิ่งที่คุณทำตรงนี้ ไม่เพียงแต่คุณคิดถึงการสร้างรูปทรงใหญ่ๆ

887
01:19:43,318 --> 01:19:47,916
ในโค้ดเบส service ใหญ่ๆ สิ่งที่ผมคิดว่าคุณควรทำคือ

888
01:19:47,916 --> 01:19:52,331
ออกแบบอินเทอร์เฟซของโมดูลเหล่านี้ แล้วมอบหมายการ

889
01:19:52,331 --> 01:19:58,032
implement ให้คนอื่น พูดอีกแบบคือ โมดูลเหล่านี้กลายเป็นกล่องเทา

890
01:19:58,032 --> 01:20:03,458
(gray box) ที่คุณแค่ต้องรู้รูปทรงของมัน ต้องรู้ว่ามันทำอะไร

891
01:20:03,458 --> 01:20:08,608
รู้พฤติกรรมของมัน แต่คุณมอบหมายการ implement ภายในมันได้

892
01:20:08,608 --> 01:20:14,402
ผมพบว่านี่ดีมาก ผมไม่จำเป็นต้อง code review ทุกอย่างในโมดูลนั้น

893
01:20:14,402 --> 01:20:23,323
ผมไม่จำเป็นต้องรู้ทุกอย่างว่ามันทำอะไร ผมแค่ต้องรู้ว่ามันมีพฤติกรรมแบบหนึ่งภายใต้เงื่อนไขบางอย่าง

894
01:20:23,323 --> 01:20:29,484
และมันทำหน้าที่ของมัน มันเหมือนกับว่า โอเค ผมมีภาพรวมใหญ่ของโค้ดเบส

895
01:20:29,484 --> 01:20:34,818
เข้าใจรูปทรงต่างๆ ข้างใน เข้าใจว่าอินเทอร์เฟซทั้งหมดทำอะไร

896
01:20:34,818 --> 01:20:46,130
แต่ผมสามารถมอบหมายสิ่งที่อยู่ข้างในได้ ผมพบว่านี่เป็นวิธีที่ดีมากในการรักษาความรู้สึกต่อโค้ดเบสไว้พร้อมกับรักษาสติของตัวเอง

897
01:20:46,130 --> 01:20:52,751
เข้าใจไหม? คุณอาจถามว่า จะเปลี่ยนโค้ดเบสแบบนี้ให้เป็นโค้ดเบสแบบนี้ยังไง?

898
01:20:52,751 --> 01:20:57,901
จะทำให้โมดูลลึกขึ้นยังไง? เรามี... หวังว่ามันจะอยู่ในนี้

899
01:20:57,901 --> 01:21:02,591
ค่อนข้างแน่ใจว่าอยู่ เรามี skill ที่ชื่อว่า improve

900
01:21:02,591 --> 01:21:06,913
code base architecture ตรงไปตรงมาดี มาลองรันกัน

901
01:21:06,913 --> 01:21:11,788
skill นี้จะสแกนโค้ดเบสของเราและมองหาว่ามีอะไรอยู่บ้าง

902
01:21:11,788 --> 01:21:17,305
ถ้าคุณกำลังทำแบบฝึกหัดอยู่ก็ลองรันได้เลย มันสำรวจสถาปัตยกรรม

903
01:21:17,305 --> 01:21:23,375
สำรวจวิธีทำงานในโค้ดเบสนี้ และจะพยายามหาจุดที่ทำให้โมดูลลึกขึ้นได้

904
01:21:23,375 --> 01:21:28,341
ง่ายๆ สิ่งที่เจ๋งมากที่มันเจอตรงนี้คือ ส่วนหนึ่งของแอป

905
01:21:28,341 --> 01:21:35,606
course video manager ของผมคือ video editor ตัวตัดต่อวิดีโอที่ทำงานในเบราว์เซอร์

906
01:21:35,606 --> 01:21:46,182
ซึ่งโหดมาก มันเป็นงานวิศวกรรมที่หนักหน่อย และผมต้องการวิธีห่อฟรอนต์เอนด์ทั้งหมดจนถึงแบ็กเอนด์เป็นโมดูลใหญ่ก้อนเดียว

907
01:21:46,182 --> 01:21:53,631
เพื่อที่ผมจะได้ทดสอบว่าการกดอะไรบางอย่างบนฟรอนต์เอนด์แล้วมันส่งผลไปจนถึงแบ็กเอนด์

908
01:21:53,631 --> 01:21:58,781
ผมหาวิธีได้โดยใช้ discriminated union (ยูเนียนแบบแยกแยะ)

909
01:21:58,781 --> 01:22:06,322
ระหว่างสอง type ตรงนี้ ผมใช้ skill นี้เพื่อสร้างโมดูลยักษ์ใหญ่ที่ทดสอบจากภายนอกได้

910
01:22:06,322 --> 01:22:11,288
โครงสร้างพื้นฐานของ video editor นี้ และมันหมายความว่า

911
01:22:11,288 --> 01:22:17,450
AI เห็นโฟลว์ทั้งหมด ลงมือกับโฟลว์ทั้งหมด และทดสอบกับโฟลว์ทั้งหมดได้

912
01:22:17,450 --> 01:22:23,427
และจริงๆ แล้ว มันต่างกันเหมือนกลางวันกับกลางคืนในแง่ความสามารถของ

913
01:22:23,427 --> 01:22:27,934
AI ในการแก้ไขอะไรจริงๆ เพราะ AI ที่ทำงานกับ video

914
01:22:27,934 --> 01:22:32,440
editor ค่อนข้างโหดร้ายถ้าคุณไม่ให้เทสต์ดีๆ กับมัน

915
01:22:32,440 --> 01:22:37,038
เอาจริงๆ ถ้าจะให้จำอะไรติดตัวไปจากวันนี้หนึ่งอย่าง

916
01:22:37,038 --> 01:22:42,188
ก็ลองรัน skill นี้บน repo ของคุณดู แล้วดูว่าเกิดอะไรขึ้น

917
01:22:42,188 --> 01:22:47,246
ไปดู Slido กัน ขอเช็กคำถามสองสามข้อระหว่างที่มันรันอยู่

918
01:22:47,246 --> 01:22:51,752
มาดูกัน "คุณลองใช้ auto mode ของ Claude กับคำสั่ง

919
01:22:51,752 --> 01:22:57,638
'enable auto mode' ไหม?" วิธีนั้นจะช่วยให้คุณเลี่ยงการเช็กสิทธิ์

920
01:22:57,638 --> 01:23:02,788
(permission checks) ที่ชัดเจนหลายอย่างได้ เดี๋ยวจะพูดถึง

921
01:23:02,788 --> 01:23:07,294
permission checks อีกสักครู่ "ผมเก็บแผนและ issues

922
01:23:07,294 --> 01:23:12,168
แบบ markdown ไว้ใช้อ้างอิงทีหลังไหม?" โอเค คำถามดีมาก

923
01:23:12,168 --> 01:23:16,583
สมมติว่าคุณมีไอเดียดีๆ เปลี่ยนมันเป็น PRD ขึ้นมา

924
01:23:16,583 --> 01:23:20,997
แล้ว implement PRD นั้น และ PRD เสร็จสมบูรณ์แล้ว

925
01:23:20,997 --> 01:23:26,055
ยกมือขึ้นถ้าคุณเก็บข้อมูลนั้นไว้ใน repo โดยแปลงเป็นไฟล์

926
01:23:26,055 --> 01:23:33,228
markdown ยกมือขึ้นถ้าอยากเก็บมันไว้ เจ๋ง โอเค และยกมือขึ้นถ้าไม่อยากเก็บมันไว้

927
01:23:33,228 --> 01:23:38,930
ถ้าอยากกำจัดมันให้เร็วที่สุด ใช่ ผมว่าคำถามนี้ไม่มีคำตอบชัดเจน

928
01:23:38,930 --> 01:23:43,620
สิ่งที่ผมกลัวมากเกี่ยวกับการตัดสินใจเรื่องเอกสารคือ

929
01:23:43,620 --> 01:23:48,034
สมมติว่าเรามี PRD สำหรับ gamification system นี้

930
01:23:48,034 --> 01:23:53,736
เราเก็บมันไว้ใน repo เราทำงานต่อไปเรื่อยๆ สมมติหนึ่งเดือนต่อมา

931
01:23:53,736 --> 01:23:58,242
เราอยากแก้ไข gamification system แล้วเราเข้าไปกับ

932
01:23:58,242 --> 01:24:04,680
Claude และมันเจอ PRD เก่านี้แล้วบอกว่า "ใช่ ฉันเจอเอกสารต้นฉบับของระบบ

933
01:24:04,680 --> 01:24:10,841
PRD แล้ว" แล้วปรากฏว่าโค้ดจริงเปลี่ยนไปจาก PRD เดิมมากจนแทบจำไม่ได้

934
01:24:10,841 --> 01:24:15,347
ชื่อของสิ่งต่างๆ เปลี่ยนไป โครงสร้างไฟล์เปลี่ยนไป

935
01:24:15,347 --> 01:24:19,670
แม้แต่ความต้องการ (requirements) ก็อาจเปลี่ยนไป

936
01:24:19,670 --> 01:24:24,084
เราอาจเอาไปทดสอบกับผู้ใช้จริงแล้ว นี่คือ doc rot

937
01:24:24,084 --> 01:24:29,050
(เอกสารเน่า) คือเอกสารของบางอย่างกำลังเน่าเปื่อยอยู่ใน

938
01:24:29,050 --> 01:24:35,671
repo ของคุณ และมีอิทธิพลกับ Claude ในทางที่แย่ หรือกับเอเจนต์ในทางที่แย่

939
01:24:35,671 --> 01:24:40,362
ผมเลยมักไม่เก็บมันไว้ ผมมักกำจัดมันทิ้ง และสำหรับผม

940
01:24:40,362 --> 01:24:44,960
เพราะการตั้งค่าของผมใช้ GitHub issues ผมก็แค่ mark

941
01:24:44,960 --> 01:24:49,834
เป็น closed (ปิดแล้ว) มันดึงข้อมูลกลับมาได้ถ้าต้องการ

942
01:24:49,834 --> 01:24:56,915
แต่มันมีตัวบ่งชี้ว่าจบแล้ว ผมเลยชอบทิ้งพวกมัน "ความคิดเห็นเกี่ยวกับเฟรมเวิร์ก

943
01:24:56,915 --> 01:25:02,985
BEADS ของ Steve?" ผมยังไม่ได้ทดสอบมัน แต่ดูเหมือนเป็นอีกวิธีจัดการ

944
01:25:02,985 --> 01:25:07,399
Kanban boards และ issues ดูดีมาก แต่ยังไม่ได้ลอง

945
01:25:07,399 --> 01:25:13,653
>> [กระแอม] >> ขอเช็กการตั้งค่าตรงนี้หน่อย ขอถามจากในห้องสองสามคำถาม

946
01:25:13,653 --> 01:25:18,343
มีใครมีคำถามเกี่ยวกับสิ่งที่เราครอบคลุมมา ถึงตอนนี้

947
01:25:18,343 --> 01:25:23,677
โดยเฉพาะส่วนสุดท้ายนี้ไหม? ใช่ "ผมว่าคำตอบของคุณเรื่องไฟล์

948
01:25:23,677 --> 01:25:28,367
markdown ที่คุณลบเพราะมันสร้าง doc rot น่าสนใจ แล้ว

949
01:25:28,367 --> 01:25:32,781
migration ล่ะ? ไฟล์ migration คุณจะ squash (รวม)

950
01:25:32,781 --> 01:25:38,115
มันทีหลังไหม? แบบ database migrations (การย้ายฐานข้อมูล)?"

951
01:25:38,115 --> 01:25:42,621
ใช่ ไม่รู้สิ หวังว่าคงตอบคำถามคุณได้ ขอโทษที ไม่ๆ

952
01:25:42,621 --> 01:25:51,082
ผมคิดว่า database migrations เป็นคนละเรื่องกัน เพราะคุณมีบันทึกต่อเนื่องว่าอะไรเปลี่ยนไปบ้าง

953
01:25:51,082 --> 01:25:55,404
และมันกำหนดผลลัพธ์ได้แน่นอนกว่า และผมว่า... ใช่

954
01:25:55,404 --> 01:25:59,910
มันเป็นการเปรียบเทียบที่น่าสนใจ ไม่แน่ใจเหมือนกัน

955
01:25:59,910 --> 01:26:04,785
คุยกันทีหลังนะ นั่นคือวิธีพูดอย่างสุภาพว่า "ผมไม่รู้"

956
01:26:04,785 --> 01:26:09,475
ใช่ ใช่ "คุณพูดว่าคุณไม่ลบ PRD คุณพูดว่าคุณไม่ทบทวน

957
01:26:09,475 --> 01:26:16,096
PRD เมื่อมันเสร็จแล้ว" ขอโทษนะทุกคน ผมกำลังฟังคำถามของคุณผู้ชายคนนี้อยู่

958
01:26:16,096 --> 01:26:20,602
"คุณเคยลองใช้ deep think อย่าง ChatGPT อะไรแบบนี้

959
01:26:20,602 --> 01:26:26,028
ให้มันดู PRD แล้วบอกว่ามัน..." มันใช้เวลาประมาณหนึ่งชั่วโมง

960
01:26:26,028 --> 01:26:31,546
ใช่ คำถามคือ ผมควรพยายาม optimize แผนในช่วงวางแผนช่วงแรกไหม?

961
01:26:31,546 --> 01:26:36,328
นี่คือสิ่งที่ผมเห็นคนทำกันเยอะ และเป็นไอเดียที่ดีมาก

962
01:26:36,328 --> 01:26:41,938
ตอนที่คุณ... กลับไปที่เฟสต่างๆ กัน สมมติว่าคุณมีเฟสทั้งหมดนี้

963
01:26:41,938 --> 01:26:47,916
แล้วคุณมาถึงจุดที่คิดทุกอย่างกับ LLM แล้ว เข้าใจแล้วว่าจะไปทางไหน

964
01:26:47,916 --> 01:26:53,525
สร้างเอกสารจุดหมายปลายทางของการเดินทางแล้ว แล้วคุณควรจะพยายาม

965
01:26:53,525 --> 01:27:01,618
optimize PRD ซ้ำแล้วซ้ำเล่าจนกว่าจะเป็น PRD ที่สมบูรณ์แบบที่สุดเท่าที่จะจินตนาการได้ไหม?

966
01:27:01,618 --> 01:27:08,424
ผมว่าไม่มีคุณค่ามากนักในนั้น เพราะผมว่าการเดินทางเป็นแค่การบอกทิศทางคร่าวๆ

967
01:27:08,424 --> 01:27:12,838
ว่าคุณอยากไปทางไหน และจุดที่คุณควรทุ่มเททำงานคือ

968
01:27:12,838 --> 01:27:17,344
QA และคุณทำแบบ AFK ได้ด้วย ผมว่า แต่จากประสบการณ์

969
01:27:17,344 --> 01:27:21,850
คุณจะไม่ได้ประโยชน์จากมันมากนัก สิ่งที่สำคัญจริงๆ

970
01:27:21,850 --> 01:27:26,540
คือการสร้างความเข้าใจตรงกันกับ AI ซึ่งคุณทำในเซสชัน

971
01:27:26,540 --> 01:27:30,955
grilling ตั้งแต่แรก ขออีกหนึ่งคำถาม มีใครอีกไหม?

972
01:27:30,955 --> 01:27:37,208
ใช่ "ในเวิร์กโฟลว์ของคุณ ทำยังไงให้มันเขียนโค้ดแบบที่คุณอยากให้เขียน

973
01:27:37,208 --> 01:27:43,278
เพื่อที่พอถึงขั้น code review มันจะคุ้นเคย ใช้ไลบรารีที่คุณอยากใช้

974
01:27:43,278 --> 01:27:51,279
ใช่" จริงๆ เรามีคำถามนี้มาก่อนแล้ว คือจะบังคับมาตรฐานการเขียนโค้ดของคุณกับเอเจนต์ยังไง?

975
01:27:51,279 --> 01:27:56,705
จะให้มันเขียนโค้ดแบบที่คุณอยากให้เขียนยังไง? มีสองวิธีหลักๆ

976
01:27:56,705 --> 01:28:01,763
คือ... ไม่รู้สิ เอาน่า "push" กับ "pull" ผมหมายถึงอะไร?

977
01:28:01,763 --> 01:28:06,821
Push คือการผลักคำสั่งไปให้ LLM เช่น ถ้าคุณใส่บางอย่างใน

978
01:28:06,821 --> 01:28:13,534
Claude.md อย่าง "พูดเหมือนโจรสลัด" คำสั่งนั้นจะถูกส่งไปให้เอเจนต์ตลอดเวลา

979
01:28:13,534 --> 01:28:18,224
นั่นคือ push จริงๆ คุณกำลังผลัก token ไปให้มัน ส่วน

980
01:28:18,224 --> 01:28:22,546
Pull คือการให้โอกาสเอเจนต์ดึงข้อมูลเพิ่มเติมเอง

981
01:28:22,546 --> 01:28:28,432
เช่น skill skill คือสิ่งที่อยู่ใน repo และมีส่วนหัวคำอธิบายเล็กๆ

982
01:28:28,432 --> 01:28:33,950
บอกว่า "โอเค เอเจนต์ เธอสามารถดึงอันนี้มาใช้ได้เมื่อต้องการ"

983
01:28:33,950 --> 01:28:40,571
ความคิดของผมตอนนี้เกี่ยวกับ code review และมาตรฐานการเขียนโค้ดเป็นแบบนี้

984
01:28:40,571 --> 01:28:45,629
เมื่อคุณมี implementer เกิดอะไรขึ้น? เอาล่ะ Implementer

985
01:28:45,629 --> 01:28:52,803
เดี๋ยวจะทำให้มันแดงน้อยลงหน่อย คุณต้องการให้มาตรฐานการเขียนโค้ดพร้อมใช้งานผ่าน

986
01:28:52,803 --> 01:28:58,044
pull ถ้ามันมีคำถาม คุณอยากให้มันหาคำตอบได้เอง แต่ถ้าคุณมี

987
01:28:58,044 --> 01:29:02,459
automated reviewer (ผู้ตรวจสอบอัตโนมัติ) ตามหลัง

988
01:29:02,459 --> 01:29:07,149
คุณอยากให้มัน push คือผลักข้อมูลนั้นไปให้ผู้ review

989
01:29:07,149 --> 01:29:14,966
คุณอยากบอกว่า "นี่คือมาตรฐานการเขียนโค้ดของเรา ตรวจสอบให้แน่ใจว่าโค้ดนี้ทำตามมาตรฐาน"

990
01:29:14,966 --> 01:29:20,116
ดังนั้นถ้าคุณมี skill เช่น คุณอยาก push สิ่งนั้นไปให้ผู้

991
01:29:20,116 --> 01:29:27,657
review เพื่อให้ผู้ review มีทั้งโค้ดที่เขียนเสร็จและมาตรฐานการเขียนโค้ดไว้เทียบกัน

992
01:29:27,657 --> 01:29:34,830
หวังว่าคงตอบคำถามคุณได้ ที่จริงผมโชว์เวอร์ชันอัตโนมัติของเรื่องนี้ให้ดูได้ด้วย

993
01:29:34,830 --> 01:29:39,980
ใช่ มาทำตอนนี้เลย ระหว่างที่ยังจำได้สดๆ เมื่อไม่นานมานี้

994
01:29:39,980 --> 01:29:44,302
ผมใช้เวลาประมาณหนึ่งอาทิตย์สร้างสิ่งที่เรียกว่า

995
01:29:44,302 --> 01:29:52,027
Sandcastle Sandcastle คือ... ผมไม่ค่อยพอใจกับตัวเลือกที่มีอยู่สำหรับการรันเอเจนต์แบบ

996
01:29:52,027 --> 01:29:56,993
AFK สิ่งที่มันทำคือ มันคือไลบรารี TypeScript สำหรับรัน

997
01:29:56,993 --> 01:30:01,408
loop พวกนี้ คุณมีฟังก์ชัน run ที่สร้าง work tree

998
01:30:01,408 --> 01:30:08,305
(ต้นไม้งาน) แซนด์บ็อกซ์มันใน Docker container แล้วให้คุณรันพรอมป์ข้างในนั้น

999
01:30:08,305 --> 01:30:13,639
และใน work tree นั้น มันก็เป็นแค่ Git branch คุณมีโค้ดนั้น

1000
01:30:13,639 --> 01:30:19,525
แล้วค่อย merge ทีหลังได้ ถ้าผมเปิด... มันมีวิธีดูผลลัพธ์ที่ดีมาก

1001
01:30:19,525 --> 01:30:24,307
และมันให้คุณรัน loop อัตโนมัติแบบนี้ และ parallelize

1002
01:30:24,307 --> 01:30:28,721
ระหว่างเอเจนต์หลายตัวได้ง่ายมาก ผมจะเข้าไปในไฟล์

1003
01:30:28,721 --> 01:30:35,066
Sandcastle ไปที่ main.ts ตรงนี้ มาดูกัน นี่คือแบบที่ผมโชว์ให้ดูตอนแรก

1004
01:30:35,066 --> 01:30:42,424
ซึ่งเป็นเวอร์ชันของ Ralph loop นี่คือจุดที่เราเปลี่ยนจากแบบเรียงลำดับเป็นแบบขนาน

1005
01:30:42,424 --> 01:30:47,022
ตรงนี้เรามี planner (ตัววางแผน) ซึ่งมี plan prompt

1006
01:30:47,022 --> 01:30:52,723
ที่ดู backlog และเลือกจำนวน issues จำนวนหนึ่งเพื่อทำงานแบบขนาน

1007
01:30:52,723 --> 01:30:58,609
จำได้ไหมที่ผมโชว์ Kanban board ที่มีความสัมพันธ์แบบบล็อกทั้งหมด?

1008
01:30:58,609 --> 01:31:04,127
มันคำนวณเฟสทั้งหมดออกมา ตัวนี้จะบอกว่า โอเค สมมติว่าเรามี...

1009
01:31:04,127 --> 01:31:08,633
คุณข้าม glue code (โค้ดเชื่อมต่อ) ทั้งหมดนี้ไปได้

1010
01:31:08,633 --> 01:31:14,335
นี่ก็แค่ชุด issues ซึ่งเป็น GitHub issues ที่มีชื่อเรื่องและมี

1011
01:31:14,335 --> 01:31:19,117
branch ให้คุณทำงาน จากนั้นสำหรับแต่ละ issue เราสร้าง

1012
01:31:19,117 --> 01:31:24,359
sandbox แล้วรัน implementer ใน sandbox นั้น โดยส่งหมายเลข

1013
01:31:24,359 --> 01:31:30,521
issue ชื่อ issue และ branch เข้าไป นี่คือ loop ที่เรารันก่อนหน้านี้

1014
01:31:30,521 --> 01:31:35,487
จากนั้นถ้ามันสร้าง commits ขึ้นมา เราก็ review commits

1015
01:31:35,487 --> 01:31:40,085
เหล่านั้น นี่คือ loop จริงๆ เราจะทำอะไรกับ commits

1016
01:31:40,085 --> 01:31:44,407
เหล่านั้น? ส่งให้ merger agent (เอเจนต์รวมโค้ด)

1017
01:31:44,407 --> 01:31:48,729
ซึ่งรับ merge prompt รับ branch ที่ถูกสร้าง รับ

1018
01:31:48,729 --> 01:31:53,144
issues แล้วก็ merge เข้าด้วยกัน ถ้ามีปัญหากับการ

1019
01:31:53,144 --> 01:31:58,386
merge อย่างปัญหา types หรือ tests อะไรแบบนั้น มันก็แก้ให้

1020
01:31:58,386 --> 01:32:04,547
และนี่คือโฟลว์ของผมมาสักพักใหญ่แล้วสำหรับการทำงานในโปรเจกต์ส่วนใหญ่

1021
01:32:04,547 --> 01:32:08,962
มันเวิร์คดีมาก และใช่ ผมแนะนำให้ลองดู Sandcastle

1022
01:32:08,962 --> 01:32:13,560
ถ้าอยากเรียนรู้เพิ่มเติม และเพื่อตอบคำถามคุณให้ตรง

1023
01:32:13,560 --> 01:32:18,434
คือ ในผู้ review ผมจะ push มาตรฐานการเขียนโค้ด ส่วนใน

1024
01:32:18,434 --> 01:32:22,940
implementer ผมจะให้มัน pull ได้เอง และจริงๆ ผมใช้

1025
01:32:22,940 --> 01:32:27,722
Sonnet สำหรับการ implement และ Opus สำหรับการ review

1026
01:32:27,722 --> 01:32:32,780
เพราะผมว่าการ review ต้องใช้ความฉลาดตรงนั้น มีคำถามไหม?

1027
01:32:32,780 --> 01:32:37,470
เอาแบบนี้ ก่อนที่จะถามคำถามเพิ่ม ขอกลับมาตรงนี้ก่อน

1028
01:32:37,470 --> 01:32:45,103
โอเค เราอยู่ตรงไหนแล้ว? โอเค เราซูมไปมาในทอล์กนี้เพราะผมต้องรันอะไรหลายอย่างแบบขนาน

1029
01:32:45,103 --> 01:32:50,621
กลับไปที่ improve code base architecture กัน มันรันเสร็จแล้ว

1030
01:32:50,621 --> 01:32:57,151
และเจอตัวเลือกการปรับปรุงสถาปัตยกรรมหลายจุด มันมีคลัสเตอร์ของโมดูลต่างๆ

1031
01:32:57,151 --> 01:33:01,841
ที่เกี่ยวข้องกัน ซึ่งน่าจะทดสอบเป็นหน่วยเดียวกันได้

1032
01:33:01,841 --> 01:33:08,554
อันดับหนึ่งคือ quiz scoring service มีการแยกตรรกะการจัดเรียงลำดับใหม่ด้วย

1033
01:33:08,554 --> 01:33:13,704
มันให้เหตุผลว่าทำไมมันถึง coupled (ผูกกัน) และมีหมวดหมู่

1034
01:33:13,704 --> 01:33:20,417
dependency ด้วย "ทดแทนได้ในเครื่อง ใน SQLite ฐานข้อมูลทดสอบในหน่วยความจำ"

1035
01:33:20,417 --> 01:33:26,947
quiz scoring service ตอนนี้มีเทสต์เป็นศูนย์ นี่คือช่องว่างที่ใหญ่ที่สุด

1036
01:33:26,947 --> 01:33:32,281
นี่คือหน้าตาตอนเรากลับมาของ improve code base architecture

1037
01:33:32,281 --> 01:33:37,339
โอเค เรามีเวลาเหลือประมาณ 17 นาที ไม่รู้ว่าคุณเป็นยังไง

1038
01:33:37,339 --> 01:33:42,397
แต่ผมเหนื่อยมาก >> [เสียงหัวเราะ] >> ผมอยาก >> [กระแอม]

1039
01:33:42,397 --> 01:33:48,558
>> ขอสรุปให้ฟังหน่อย เพราะผมว่าเรากำลังถึงขีดจำกัดความอึดของเราแล้ว

1040
01:33:48,558 --> 01:33:54,444
ผมจะอยู่ให้ครบเวลา ถ้าใครอยากมาถามคำถาม ผมอาจจะเช็กสไลด์อีกครั้ง

1041
01:33:54,444 --> 01:34:00,514
แต่ขอสรุปว่ามาถึงจุดไหนแล้ว นี่คือโฟลว์โดยรวม ตลอดกระบวนการทั้งหมด

1042
01:34:00,514 --> 01:34:07,043
เราคำนึงถึงรูปทรงของโค้ดเบสอยู่เสมอ นี่ไม่ใช่คอมไพเลอร์แปลงสเปกเป็นโค้ด

1043
01:34:07,043 --> 01:34:16,240
นี่ไม่ใช่ AI ที่พ่นโค้ดออกมาอย่างเดียว เราตั้งใจมากกับประเภทของโมดูลและรูปทรงของโค้ดเบสที่เราต้องการ

1044
01:34:16,240 --> 01:34:21,022
เราทำให้แน่ใจว่าเราเข้าใจตรงกันมากที่สุดโดยใช้เซสชัน

1045
01:34:21,022 --> 01:34:26,907
grilling โดยการตีแผ่ไอเดียของเราอย่างจริงจัง เราไม่ได้หมกมุ่นกับ

1046
01:34:26,907 --> 01:34:34,356
PRD มากเกินไป เราไม่ได้พยายามอ่านทุกส่วนของมัน เราไม่ได้คิดถึงมันมากเกินไปด้วยซ้ำ

1047
01:34:34,356 --> 01:34:39,414
จากนั้นเราก็เปลี่ยนมันเป็นชุด issues ที่ parallelizable

1048
01:34:39,414 --> 01:34:43,829
ซึ่งเอเจนต์ทำงานคู่ขนานกันได้ เราทำการ implement

1049
01:34:43,829 --> 01:34:49,255
และ QA และ code review อย่างเอาเป็นเอาตาย แล้วก็วนกลับไปที่

1050
01:34:49,255 --> 01:34:54,864
implementation นั้นเรื่อยๆ มีสิ่งหนึ่งที่ผมไม่ได้พูดถึงมากนัก

1051
01:34:54,864 --> 01:34:59,187
คือในเฟส QA จุดประสงค์ของ QA คือการสร้าง issues

1052
01:34:59,187 --> 01:35:04,613
เพิ่มเติมให้ Kanban board นั้น ดังนั้นแม้ระหว่างที่มันกำลัง

1053
01:35:04,613 --> 01:35:09,303
implement คุณก็สามารถ QA ไปพร้อมกัน แล้วกลับไปเพิ่ม

1054
01:35:09,303 --> 01:35:16,476
issues ได้ และ Kanban board ให้คุณเพิ่ม issues แบบบล็อกได้แทบจะไม่มีที่สิ้นสุด

1055
01:35:16,476 --> 01:35:22,454
แล้วเมื่อทุกอย่างเสร็จ เมื่อคุณพอใจกับโค้ด เมื่อคุณพอใจกับงานแล้ว

1056
01:35:22,454 --> 01:35:26,776
คุณก็แชร์ให้ทีมและรับการ review อย่างเต็มรูปแบบ

1057
01:35:26,776 --> 01:35:33,581
นี่คือตอนที่คุณมาถึงตรงนี้ จะมีนักพัฒนาหนึ่งคนหรือสองสามคนคอยจัดการสิ่งนี้

1058
01:35:33,581 --> 01:35:38,179
แล้วก็ขึ้นอยู่กับคุณว่าจะ merge มันกลับเข้าไปยังไง

1059
01:35:38,179 --> 01:35:43,053
>> [ถอนหายใจ] >> แน่นอนว่าทั้งหมดนี้คุณปรับแต่งได้หมด

1060
01:35:43,053 --> 01:35:49,583
นี่เป็นเพียงสิ่งที่ผมพบว่ามันเวิร์ค ผมไม่ได้พยายามขายแนวทางอะไรให้คุณนะ

1061
01:35:49,583 --> 01:35:55,009
สิ่งที่ผมแนะนำ ถ้าจะให้จำอะไรติดตัวไปจากเซสชันนี้หนึ่งอย่าง

1062
01:35:55,009 --> 01:35:59,331
คือกลับบ้านไป แล้วไปที่ Amazon ซื้อหนังสือเก่าๆ

1063
01:35:59,331 --> 01:36:04,389
พวกนั้นมากองหนึ่ง เพราะผมพบว่าการอ่านมันให้ข้อคิดมากมาย

1064
01:36:04,389 --> 01:36:08,987
งานเขียนยุคก่อน AI อ่านสนุกอยู่แล้ว และในทุกๆ หน้า

1065
01:36:08,987 --> 01:36:13,310
ผมพบว่ามีอะไรที่มีประโยชน์และน่าสนใจให้อ่านเสมอ

1066
01:36:13,310 --> 01:36:21,127
ขอบคุณมากๆ ขอบคุณที่ทนกับความร้อนนะ หวังว่าอุณหภูมิร่างกายของคุณจะกลับสู่ปกติในไม่ช้า

1067
01:36:21,127 --> 01:36:25,081
ขอบคุณมากครับ >> [เสียงปรบมือ] [เสียงดนตรี]