Full Walkthrough: Workflow for AI Coding — Matt Pocock

• Mặc dù AI là một mô hình công nghệ mới, các nguyên tắc cơ bản của kỹ thuật phần mềm vẫn cực kỳ quan trọng và hiệu quả khi làm việc với AI, đặc biệt trong việc chia nhỏ tác vụ và quản lý dự án.
• Các Mô hình ngôn ngữ lớn (LLM) có "vùng thông minh" (khi mới bắt đầu) và "vùng kém hiệu quả" (sau khi ngữ cảnh quá dài, khoảng 100K token), đòi hỏi người dùng phải chủ động quản lý ngữ cảnh để duy trì hiệu suất.
• Để tương tác hiệu quả với AI, cần đạt được sự hiểu biết chung (design concept) thông qua các kỹ năng phỏng vấn chủ động (như "Grille Me skill"), thay vì chỉ giao đặc tả và mong AI tự sinh mã mà không có sự kiểm soát của con người.

• Chia nhỏ tác vụ: LLM hoạt động tốt nhất trong "vùng thông minh" khi ngữ cảnh ngắn gọn. Hãy chia các tác vụ lớn thành các phần nhỏ để AI xử lý hiệu quả, tránh để AI "ôm đồm" quá nhiều thông tin trong cùng một cửa sổ ngữ cảnh.
• Ưu tiên xóa ngữ cảnh (clear context): Thay vì nén ngữ cảnh (compacting) liên tục, hãy "xóa ngữ cảnh" để quay về trạng thái ban đầu của lời nhắc hệ thống (system prompt). Điều này giúp duy trì tính nhất quán và hiệu quả của LLM.
• Giữ lời nhắc hệ thống (system prompt) nhỏ gọn: system prompt nên càng ngắn gọn càng tốt để tránh đẩy LLM vào "vùng kém hiệu quả" ngay từ đầu.
• Áp dụng kế hoạch đa giai đoạn (multi-phase plans): Sử dụng các vòng lặp hoặc kế hoạch lặp đi lặp lại để thực hiện từng phần nhỏ của một tác vụ lớn, giống như nguyên tắc "giai đoạn N" trong kỹ thuật phần mềm.
• Theo dõi mức sử dụng token: Việc biết chính xác số lượng token đang sử dụng là thiết yếu để đánh giá mức độ gần "vùng kém hiệu quả" của LLM và tối ưu hóa chi phí.
• Phê phán phong trào "specs to code": Tránh việc chỉ chỉnh sửa đặc tả và kỳ vọng AI tự động tạo ra mã hoàn chỉnh. Người phát triển cần giữ quyền kiểm soát và hiểu rõ mã nguồn, coi mã là "chiến trường" chính.
• Sử dụng kỹ năng tùy chỉnh để đạt được sự hiểu biết chung: Phát triển các "kỹ năng" hoặc "tác nhân" đặc biệt (ví dụ: "Grille Me skill") để phỏng vấn và làm rõ yêu cầu với AI, đảm bảo cả người và AI cùng đạt được một "khái niệm thiết kế" chung trước khi bắt đầu triển khai.
• Hiểu về subagent: Các tác nhân phụ (subagents) là các LLM được gọi bởi một LLM chính. Chúng có thể tiêu thụ nhiều token nhưng không nhất thiết làm tăng mức sử dụng token tổng thể của phiên chính một cách đáng kể.

• paradigm — mô hình
• software engineering fundamentals — nguyên tắc cơ bản của kỹ thuật phần mềm
• LLM (Large Language Model) — Mô hình ngôn ngữ lớn
• smart zone / dumb zone — vùng thông minh / vùng kém hiệu quả
• token — mã thông báo
• context window — cửa sổ ngữ cảnh
• system prompt — lời nhắc hệ thống
• clear context — xóa ngữ cảnh
• compacting — nén ngữ cảnh
• specs to code movements — phong trào "từ đặc tả ra mã"
• subagent — tác nhân phụ

Giới Thiệu Workshop và Mục Tiêu

Xin chào các bạn, chúng ta đã đủ chỗ rồi. Hãy bắt đầu thôi. Tôi không muốn các bạn phải đợi thêm 25 phút nữa trước khi chúng ta có một thời hạn tùy ý. Chào mừng các bạn. Tôi tên là Matt. Tôi là giáo viên, và tôi đoán là bây giờ tôi dạy về AI. Chúng ta có một đường link ở đây, nếu các bạn chưa truy cập, nó chứa các bài tập cho những gì tôi sẽ trình bày hôm nay. Buổi này sẽ kéo dài khoảng hai giờ, vậy nên chúng ta có thể bắt đầu ngay bây giờ, được chứ Mike? Tuyệt vời.

Và lý thuyết đằng sau buổi nói chuyện này, hay ít nhất là luận điểm mà tôi đã theo đuổi trong khoảng sáu tháng qua, là chúng ta đều nghĩ AI là một paradigm mới, đúng không? AI rõ ràng đang thay đổi rất nhiều thứ. Các bạn rõ ràng quan tâm đến điều này và đó là lý do các bạn đến đây. Và tôi cảm thấy rằng khi chúng ta nói về AI là một paradigm mới, chúng ta quên mất rằng các nguyên tắc cơ bản của kỹ thuật phần mềm (software engineering fundamentals), những thứ thực sự quan trọng khi làm việc với con người, cũng hoạt động rất tốt với AI. Đây chính là chủ đề chính của bài phát biểu quan trọng của tôi vào ngày mai. Tôi sẽ khai thác sâu hơn về điều đó. Và trong buổi workshop này, tôi hy vọng sẽ có thể hướng sự chú ý của các bạn đến những điều đó và hy vọng chứng minh rằng tôi đúng. Nhưng chúng ta hãy chờ xem.

Khảo Sát Khán Giả và Phương Thức Tương Tác

Đầu tiên, tôi có thể hỏi nhanh một chút không? Bao nhiêu bạn ở đây đã từng lập trình với AI? Hãy giơ tay nếu bạn đã từng lập trình với AI? Tuyệt vời. Được rồi. Giữ tay lên nhé. Chúng ta hãy cùng chia sẻ những cái nách đó với thế giới. Bao nhiêu bạn lập trình hàng ngày với AI? Tốt. Được rồi. Giữ tay lên nếu bạn đã từng cảm thấy thất vọng với AI. Được rồi. Rất tốt. Các bạn có thể hạ tay xuống. Cảm ơn vì sự tuân thủ đó. Tôi thực sự đánh giá cao.

Và chúng ta cũng đang được live stream qua phòng Gilgur. Tôi chưa, chúng ta đã cử ai đó lên phòng Gilgur để kiểm tra chưa? Được rồi. Tôi không biết. Nhưng tôi thấy các bạn. Và có một cách để các bạn có thể tham gia, đó là chúng ta có phần Q&A. Tôi có một chút ác cảm với các buổi Q&A truyền thống, vì chúng không thực sự dân chủ. Hầu hết những người nói nhiều nhất mới có thể tham gia và chia sẻ. Vì vậy, chúng ta sẽ xem xét các câu hỏi ở đây. Vậy tại sao chúng ta không phải đợi đến 3 giờ 45? Phòng đã chật kín. Các cửa đã đóng. Tôi hoàn toàn đồng ý. Và vì vậy, nếu bạn muốn đặt câu hỏi, tôi muốn các bạn đưa vào kênh async này. Sau đó chúng ta có thể bình chọn cho các câu hỏi của nhau và hy vọng có được những câu hỏi hay nhất từ khắp căn phòng để cùng thảo luận.

Hạn Chế Của LLM: Vùng Thông Minh và Vùng Kém Hiệu Quả

Vì vậy, đầu tiên tôi muốn nói về những hạn chế kỳ lạ mà các LLM có. Và những hạn chế kỳ lạ đó chính là nền tảng cho nhiều công việc của chúng ta. Có một người tên là Dex Horley, điều hành một công ty tên là Human Layer. Anh ấy đã đưa ra ý tưởng rằng khi bạn làm việc với các LLM, chúng có một smart zone (vùng thông minh) và một dumb zone (vùng kém hiệu quả). Khi bạn mới bắt đầu làm việc với một LLM và bắt đầu một cuộc hội thoại mới từ con số không, đó là lúc LLM sẽ hoạt động tốt nhất. Bởi vì trong tình huống đó, các mối quan hệ attention là ít kỳ lạ nhất. Mỗi khi bạn thêm một token vào một LLM, nó giống như bạn đang thêm một đội vào một giải bóng đá. Hãy nghĩ về số lượng trận đấu được thêm vào mỗi khi bạn thêm một đội vào một giải bóng đá, nó tăng lên theo cấp số mũ 2 (quadratically). Và điều đó là do bạn có các mối quan hệ attention đi từ bản chất mỗi token này đến token khác, dựa trên vị trí và ý nghĩa của từng token riêng lẻ.

Và điều này có nghĩa là, khoảng 40% hoặc tôi sẽ nói khoảng 100K là mốc mới của tôi cho điều này, bởi vì không quan trọng bạn đang sử dụng context window 1 triệu hay 200K. Nó sẽ luôn là khoảng chừng này. Nó bắt đầu trở nên kém thông minh hơn. Vì vậy, khi bạn liên tục thêm nội dung vào cùng một context window, nó sẽ ngày càng trở nên kém thông minh hơn cho đến khi đưa ra những quyết định ngớ ngẩn. Giơ tay nếu bạn cảm thấy điều này quen thuộc. Đúng không? Tuyệt vời.

Vì vậy, điều này có nghĩa là chúng ta muốn phân chia các tác vụ của mình theo cách nằm trong smart zone. Chúng ta không muốn AI ôm đồm quá nhiều việc. Và điều này quay trở lại những lời khuyên cũ của Martin Fowler về refactoring, hoặc cuốn sách The Pragmatic Programmer nói về điều này: đừng ôm đồm quá nhiều việc. Hãy giữ các tác vụ của bạn nhỏ gọn để bạn, với tư cách là một nhà phát triển con người, không bị căng thẳng và không bắt đầu hành động một cách kém hiệu quả. Nhưng làm thế nào để bạn xử lý các tác vụ lớn? Làm thế nào để bạn thực hiện một tác vụ lớn như, tôi không biết, sao chép một công ty hoặc làm điều gì đó điên rồ? Và làm thế nào để bạn chia nó thành các tác vụ nhỏ để tất cả chúng đều nằm trong dumb zone? Một cách bạn có thể làm, ý tôi là, có lẽ các công ty AI muốn bạn làm hoặc cách tự nhiên để làm là cứ tiếp tục đi và đi và đi và đi. Bạn kết thúc trong dumb zone, tốn rất nhiều token cho mỗi yêu cầu, bạn sau đó compact (nén) trở lại, chúng ta sẽ nói về compacting một cách đúng đắn trong một phút nữa và bạn cứ tiếp tục, tiếp tục, tiếp tục, compact trở lại, tiếp tục, tiếp tục, tiếp tục, tiếp tục. Và tôi nghĩ điều đó không thực sự hiệu quả lắm vì càng nhiều "cặn" (sediment), tôi sẽ nói về điều đó trong một phút nữa.

Vì vậy, lý thuyết ở đây là, và đây là điều tôi đã làm trong một thời gian, là tôi sẽ sử dụng các loại multi-phase plans (kế hoạch đa giai đoạn) này, nơi tôi sẽ nói, được rồi, chúng ta có cái thứ số bốn này, tác vụ rất lớn này, hãy chia nó thành các phần nhỏ để chúng ta có thể chia nhỏ nó và thực hiện từng chút công việc trong smart zone. Giơ tay nếu bạn đã từng sử dụng một multi-phase plan trước đây. Đúng vậy, một thực hành rất phổ biến, phải không? Và đây là cách chúng ta đã làm. Chắc chắn, đây là cách tôi đã làm cho đến tháng 12 năm ngoái. Và bất kỳ nhà phát triển nào có giá trị đều sẽ nhìn vào điều này và nói, đây là một loop (vòng lặp), đúng không? Đây là một loop. Chúng ta chỉ có giai đoạn một, giai đoạn hai, giai đoạn ba, giai đoạn bốn. Tại sao chúng ta không chỉ có giai đoạn N? Đúng không? Giai đoạn N, nơi chúng ta về cơ bản chỉ nói, được rồi, chúng ta có, giả sử, một kế hoạch hoạt động ngầm, và sau đó chúng ta chỉ loop qua nó, và chúng ta thực hiện cho đến khi hoàn thành.

Và đây là lúc, giơ tay nếu bạn đã từng nghe về Ralph Wiggum như một thực hành phần mềm. Được rồi, tốt. Thực ra, giơ tay nếu bạn chưa từng nghe về Ralph Wiggum như một thực hành phần mềm. Đúng hơn là như vậy. Được rồi, vậy có một ý tưởng gọi là Ralph Wiggum, nó hơi dựa trên điều này, về cơ bản tất cả những gì bạn cần làm là chỉ định điểm cuối của hành trình, nơi bạn chỉ nói, được rồi, chúng ta tạo một PRD, một product requirements document (tài liệu yêu cầu sản phẩm) để nói, được rồi, hãy mô tả nơi chúng ta sẽ đến. Và sau đó chúng ta chỉ nói với AI, hãy thực hiện một thay đổi nhỏ, một thay đổi nhỏ giúp chúng ta ngày càng gần hơn với điều đó. Và Ralph hoạt động ổn, nhưng tôi thích một cấu trúc chặt chẽ hơn một chút. Vì vậy, đó là nơi chúng ta đã đi đến khi suy nghĩ về smart set. Và đó là điều tôi muốn bạn bắt đầu suy nghĩ ở đây.

Hạn Chế Của LLM: Khái Niệm Về Trạng Thái Ban Đầu và Chu Kỳ Phiên Làm Việc

Một hạn chế kỳ lạ khác của các LLM là, các LLM giống như anh chàng trong phim Memento, phải không? Chúng cứ liên tục quên mất rằng bạn có thể reset (đặt lại) về trạng thái cơ bản. Để tôi mở sơ đồ này. Tôi thực sự nên dùng slide, nhưng tôi chỉ thích cuộn lung tung trên một TL drill canvas vô hạn. Cảm ơn Steve.

Vậy, một khái niệm khác mà tôi muốn các bạn ghi nhớ là mỗi phiên làm việc với một LLM đều trải qua các giai đoạn giống nhau. Đầu tiên, bạn có system prompt ở đây, cái hộp màu xám này về cơ bản là những nội dung luôn nằm trong context của bạn. Bạn muốn điều này càng nhỏ càng tốt. Bởi vì nếu bạn có rất nhiều thứ ở đây, nếu bạn có 250K token, như tôi đã thấy mọi người đưa vào đó, thì bạn sẽ đi thẳng vào dumb zone mà không thể làm được gì. Vì vậy, bạn muốn điều này phải thật nhỏ. Sau đó bạn chuyển sang một loại exploratory phase (giai đoạn thăm dò), đây là nơi coding agent (tác nhân lập trình) đi ra ngoài và khám phá code base (cơ sở mã). Sau đó bạn chuyển sang implementation (triển khai), và sau đó bạn chuyển sang testing (kiểm thử). Và đảm bảo rằng nó hoạt động, chạy các feedback loops (vòng lặp phản hồi) và những thứ tương tự. Giơ tay nếu điều đó quen thuộc với những gì bạn đã làm. Đúng vậy, giống như những trụ cột chính của bất kỳ phiên làm việc nào. Và khi bạn clear the context (xóa ngữ cảnh), bạn quay trở lại ngay system prompt. Bạn quay lại đó. Tức là bạn xóa mọi thứ đã có trước đó.

Nén Ngữ Cảnh (Compacting) và Xóa Ngữ Cảnh (Clearing Context)

Và giơ tay nếu bạn cũng đã từng nghe về compacting (nén ngữ cảnh). Đúng vậy, được rồi, có một số người chưa nghe về compacting. Vậy hãy nhanh chóng cho thấy điều đó có nghĩa là gì. Ví dụ, tôi vừa trò chuyện một chút với LLM của mình. Tôi muốn đảm bảo chúng ta đều, bạn biết đấy, nắm được những kiến thức cơ bản để chúng ta cùng hiểu ý nhau. Tôi vừa trò chuyện với LLM của mình. Tôi đang nói về một thứ mà tôi muốn xây dựng. Kích thước phông chữ thế nào? Tôi có nên phóng to không? Các bạn ở phía sau? Phóng to, phóng to, phóng to. Tôi đang sử dụng claw code cho phiên này, nhưng bạn không cần phải sử dụng claw code. Thực tế, việc không sử dụng claw code thường tốt hơn.

Vì vậy, tôi đã trò chuyện với LLM để vạch ra những gì tôi sẽ làm tiếp theo. Nó đang hỏi tôi một loạt câu hỏi. Và tôi có thể. Tôi thực sự khuyên bạn nên làm điều này. Có một dòng trạng thái nhỏ ở đây cho tôi biết tôi đang sử dụng bao nhiêu token. Con số chính xác của các token mà tôi đang sử dụng. Tôi có một bài viết trên trang web của mình, AI Hero, nếu bạn muốn sao chép điều này. Đây là, ồ wow, nó rung lắc, phải không? Đây là thông tin cần thiết trong mỗi phiên lập trình, vì bạn cần biết chính xác mình đang sử dụng bao nhiêu token để biết mình đang ở gần dumb zone đến mức nào. Hoàn toàn thiết yếu.

Và bây giờ chúng ta hãy xem. Tôi có hai lựa chọn. Tôi có thể clear (xóa), sai, và quay về con số không, hoặc tôi có thể compact (nén). Và khi tôi compact, nó sẽ nén toàn bộ cuộc trò chuyện đó, mà thực ra không nhiều lắm, vào một không gian nhỏ hơn nhiều. Và điều này, về mặt sơ đồ, trông như thế này. Chúng ta lấy tất cả thông tin từ phiên làm việc và về cơ bản bạn tạo ra một lịch sử từ đó, một bản ghi chép về những gì đã xảy ra. Và các nhà phát triển (devs) vì một lý do nào đó rất thích compacting, nhưng tôi thì ghét nó. Tôi thích AI của mình hành xử giống như anh chàng trong phim Memento hơn, bởi vì trạng thái này luôn giống nhau, luôn giống nhau, mỗi khi bạn làm điều đó, bạn clear, và bạn quay trở lại ban đầu. Và nếu bạn có thể làm điều đó, và bạn có thể tối ưu hóa cho điều đó, thì bạn đang ở một vị trí tuyệt vời. Vậy đó là hai điều tôi muốn bạn suy nghĩ về các LLM, hai hạn chế mà chúng ta đang phải đối mặt. Chúng có một smart zone và một dumb zone, và chúng giống như anh chàng trong phim Memento.

Bắt Đầu Thực Hành: Xây Dựng Tính Năng và Kỹ Năng Grilme

Vậy bây giờ chúng ta hãy xem bài tập đầu tiên. Và trong khi tôi làm điều này, cách tôi muốn nó hoạt động là tôi sẽ trình bày cách tôi thực hiện nó ở đây. Và tôi muốn các bạn cũng thực hành theo. Vậy đó chỉ là một phần lý thuyết nhỏ. Bây giờ chúng ta hãy bắt tay vào lập trình. Đối với bất kỳ ai đến muộn, bất kỳ ai ở phòng Gilgur, hãy truy cập đường link này, đường link ở trên đây, để xem các bài tập và claim (nhận) repo. Bạn hoàn toàn không bắt buộc phải làm, bạn chỉ có thể xem tôi làm nếu muốn. Nhưng hãy để tôi tự truy cập vào đó và xem các bài tập đang chờ chúng ta.

Về cơ bản, tôi đã xây dựng một cái này, đây là từ khóa học của tôi. Đây là một course management platform (nền tảng quản lý khóa học), về cơ bản là một loại CMS (hệ thống quản lý nội dung) cho người hướng dẫn, cho sinh viên. Và đây là nơi chúng ta sẽ xây dựng một tính năng. Vì vậy, tôi sẽ đưa bạn từ ý tưởng ban đầu cho tính năng đó, đến việc xây dựng một PRD cho tính năng, cho đến khi triển khai tính năng đó. Và hy vọng bạn có thể lấy cảm hứng từ quy trình này và áp dụng nó vào công việc của mình. Vậy hãy bắt đầu. Chúng ta sẽ bắt đầu bằng cách sử dụng một kỹ năng rất gần gũi với tôi. Đó là Grilme skill. Và Grilme skill này nhỏ gọn một cách đáng kinh ngạc, vô cùng nhỏ. Và nó giúp ngăn chặn một trong những vấn đề chính khi bạn làm việc với AI, mà tôi nghĩ đó là sự misalignment (không khớp). Cái ý tưởng thầm lặng mà tôi đang nói đến ở đây, cái mà tôi đang tranh luận chống lại, là phong trào specs to code movements.

Phê phán Phong trào "Specs to Code"

Có ai đã từng nghe về phong trào specs to code chưa? Hãy giơ tay. Thực ra đây không hẳn là một phong trào, mà chỉ là cách mọi người nói về specs to code. Nó là gì ư? Mọi người nói rằng, bạn có thể viết một chương trình hoặc muốn xây dựng một ứng dụng. Cách tốt nhất để xây dựng ứng dụng đó là lấy một số specifications (đặc tả), tức là viết một loại tài liệu nào đó, sau đó biến tài liệu đó thành mã. Đơn giản là biến nó thành mã. Làm thế nào để làm điều đó? Bạn chuyển nó cho AI. Nếu có điều gì sai với mã kết quả, bạn không nhìn vào mã, bạn quay lại nhìn vào specs. Bạn thay đổi specs, và bạn cứ tiếp tục như vậy. Đây giống như việc vibe coding dưới một tên gọi khác, nơi bạn về cơ bản là bỏ qua mã. Bạn không cần phải lo lắng về mã. Bạn chỉ cần tiếp tục chỉnh sửa specs, và cuối cùng, bạn cứ thế mà tiếp tục. Và tôi đã thử điều này. Tôi thực sự đã thử, và nó tệ, nó không hoạt động. Bởi vì bạn cần phải kiểm soát được mã. Bạn cần hiểu rõ nó có gì. Bạn cần định hình nó, bởi vì mã chính là chiến trường của bạn. Và đây, một lần nữa, là nơi chúng ta sẽ đến. Hãy cùng làm một số bài tập.

Bài tập: Gamification cho Cadence

Điều tôi muốn các bạn làm là truy cập trang này, the grill me skill, và bên trong repo ở đây, chúng ta có một tin nhắn Slack từ bạn của chúng ta. Nó ở đâu nhỉ? Nó nằm ở thư mục gốc của repo, và nó nằm trong tệp Clientbrief.md. Đó là một tin nhắn Slack từ Sarah Chen. Vì lý do nào đó, Claude luôn chọn Sarah Chen làm tên. Tôi không biết tại sao. Tin nhắn nói rằng trong Cadence, nền tảng khóa học của chúng ta, số liệu retention (duy trì) không tốt. Sinh viên đăng ký một vài bài học rồi bỏ dở. Tôi rất muốn thêm một số tính năng gamification (trò chơi hóa) vào nền tảng.

Và khi bạn được trình bày một ý tưởng như thế này, bạn cần tìm cách biến nó thành hiện thực. Giả sử Sarah Chen là khách hàng của bạn, bạn có ngân sách eo hẹp, bạn cần hoàn thành việc này nhanh chóng. Bạn sẽ làm thế nào? Hãy giơ tay nếu bạn sẽ vào plan mode khi làm việc này.

Sử dụng "Grille Me Skill" để làm rõ yêu cầu

Còn những người khác thì sao? Có ai sử dụng plan mode nhiều không? Hãy cùng nói nhanh nào. Có ý tưởng nào khác về việc bạn sẽ làm gì với điều này không? Giơ tay nếu bạn... Bước đầu tiên của bạn sẽ là gì? Xin lỗi? Vâng, chính xác. Hãy tưởng tượng Sarah Chen đã tạm ngừng. Bạn không biết gì cả. Cô ấy chỉ đăng cái này và bạn cần phải hành động trước khi cô ấy đi.

Chà, bước đầu tiên của tôi là tôi sử dụng skill đặc biệt này. Tôi sẽ xóa context của mình. Tôi sẽ loại bỏ bạn. Bạn không cần phải ở đó. Và tôi sẽ nói, tôi sẽ gọi một skill là Grille Me skill. Hãy nhanh chóng kiểm tra. Giơ tay nếu bạn không biết đây là gì. Tuyệt. Ồ, xin lỗi, xin lỗi. Hãy để tôi cụ thể hơn. Giơ tay nếu bạn không biết tôi đang làm gì khi tôi gõ dấu / và sau đó gõ một cái gì đó. Giờ thì mọi người đều hiểu điều đó là gì rồi. Tôi đang gọi một skill. Tôi đang gọi Grille Me skill. Và điều tôi sẽ làm là tôi sẽ nói, Grille Me và tôi sẽ truyền client brief vào. Vậy là giờ đây, LLM thực sự chỉ có một vài thứ ở đây. Nó chỉ có skill và mô tả về những gì tôi muốn làm. Và đây hầu như là cách tôi bắt đầu mọi công việc với AI.

Mục đích của "Grille Me Skill": Đạt được sự Hiểu biết Chung

Trong khi nó đang khám phá code base, tôi sẽ chỉ cho bạn thấy Grille Me skill làm gì. Nó nằm trong repo nên bạn có thể kiểm tra. Nó cực kỳ ngắn gọn: "Phỏng vấn tôi không ngừng về mọi khía cạnh của kế hoạch này cho đến khi chúng ta đạt được sự hiểu biết chung. Đi xuống từng nhánh của design tree, giải quyết các dependencies từng cái một cho mỗi câu hỏi, cung cấp câu trả lời được đề xuất. Hỏi từng câu hỏi một. Vâng vâng và vâng vâng."

Điều này làm được gì, và điều tôi nhận thấy khi làm việc với AI, đặc biệt là trong plan mode, là nó sẽ rất háo hức cố gắng đưa ra một kế hoạch cho tôi. Nó sẽ nói, "Ok, tôi nghĩ tôi đã có đủ rồi, tôi sẽ lên kế hoạch, kế hoạch." Và điều tôi nhận ra là tôi thực sự đang cố gắng tìm từ ngữ cho điều mình muốn thay vì điều đó. Và Frederick P. Brooks trong cuốn The Design of Design, ông ấy có một câu nói rất hay về design concept. Khi bạn làm việc trên một thứ gì đó mới với ai đó, khi tất cả các bạn đang cố gắng xây dựng thứ gì đó cùng nhau, thì có một ý tưởng chung được chia sẻ giữa tất cả những người tham gia. Và đó chính là design concept. Và đó là điều tôi nhận ra mình cần với Claude. Tôi cần đạt được một sự hiểu biết chung. Tôi không cần một asset, tôi không cần một kế hoạch, tôi cần phải cùng tần số với AI, với agent của mình. Và đây là một cách cực kỳ hiệu quả để làm điều đó.

"Grille Me Skill" hoạt động và Khái niệm "Subagent"

Vậy thì hy vọng, đây rồi, tốt. Đầu tiên, nó đã hoàn thành việc khám phá, nó đã gọi một subagent, đã sử dụng 93.7K tokens trên Opus. Và nó đã hỏi tôi câu hỏi đầu tiên. Tuyệt. Chúng ta có thể thấy rằng mặc dù subagent đã tiêu tốn rất nhiều tokens, nhưng mức sử dụng token của tôi thực sự không tăng nhiều.

Hãy giơ tay nếu bạn không biết subagents là gì. Đó là một câu hỏi quan trọng. Mọi người đều hiểu subagents là gì đúng không? Ok, tôi sẽ đưa ra một định nghĩa ngắn gọn, đó là cái subagents này, explore subagents này, về cơ bản đã gọi một LLM khác, với một context window bị cô lập. Và sau đó LLM đó đã báo cáo lại một bản tóm tắt. Vì vậy, một subagent giống như một sự ủy quyền. Bạn đang ủy quyền một nhiệm vụ cho một subagent. Nó hăm hở làm mọi thứ, khám phá rất nhiều, và sau đó chỉ nhỏ giọt những thông tin quan trọng trở lại cho orchestrator agent, cho parent agent. Vậy thì, ok. Hy vọng các bạn cũng đã thấy điều tương tự, nó đã thực hiện một cuộc khám phá.

Tương tác và Định nghĩa Yêu cầu với AI

Và bây giờ chúng ta có câu hỏi đầu tiên: "Hệ thống điểm, những hành động nào kiếm được điểm và bao nhiêu?" Ok. Tại thời điểm này, bạn có thể hỏi nó các câu hỏi để đào sâu sự hiểu biết của bạn về repo. Rõ ràng tôi biết repo này rất rõ, vì tôi đã viết nó, nhưng bạn có thể không biết chuyện gì đang xảy ra.

Vậy hãy nói rằng, khuyến nghị của tôi là "giữ mọi thứ đơn giản với các nguồn điểm ban đầu." Điều tuyệt vời về điều này là nó không chỉ đưa ra cho chúng ta một câu hỏi giúp chúng ta đồng điệu, mà chúng ta còn nhận được một khuyến nghị. Và thường thì tôi thấy các khuyến nghị của AI rất tốt. Vì vậy, tôi sẽ chỉ nói, "bỏ qua video, các sự kiện xem video, sau đó gây tiếng ồn trong trò chơi." Tôi đồng ý. Sarah đã yêu cầu giữ các bài học là yếu tố cốt lõi. Vâng. Trông tốt, Paul.

Thông thường, tôi thường dictate (đọc chính tả) cho AI. Thực ra tôi thường trò chuyện với AI thay vì gõ ở đây, nhưng đây là một chiếc máy tính xách tay tương đối mới và tôi không thể làm cho phần mềm dictation của mình hoạt động trên đó, vì Windows tệ.

Vậy thì, "Điểm có nên được tính lùi (retroactive) không? Có các bản ghi tiến độ bài học hiện có với thời gian hoàn thành." Đây là một câu hỏi thực sự khó nhằn, đúng không? Chúng ta có thực sự nên quay lại và backfill tất cả các sự kiện tiến độ bài học không? Đây là loại câu hỏi mà bạn cần phải có sự thống nhất nếu bạn muốn thực hiện tính năng một cách chính xác. Đó không phải là điều tôi đã xem xét. Và Sarah Chen chắc chắn cũng không xem xét. Tôi có muốn nó retroactive không? Hừm. Hãy cùng bỏ phiếu ở đây. Chúng ta có nên quay lại và backfill tất cả các bản ghi không? Giơ tay nếu bạn nghĩ chúng ta nên backfill tất cả các bản ghi. Giơ tay nếu bạn nghĩ chúng ta không nên backfill tất cả các bản ghi. Có rất nhiều người đang lưỡng lự trong phòng. Tôi sẽ nói, bạn biết đấy, đây là kiểu thảo luận mà bạn có với AI để ngày càng đồng điệu hơn. Vâng, tôi sẽ đi theo khuyến nghị của nó. Tôi lười biếng.

Cũng hãy chú ý cách tôi có thể giữ mình trong vòng lặp ở đây với AI. Tôi không, bạn biết đấy, nó đang ping tôi những câu hỏi này khá nhanh. Tôi không phải rời đi và kiểm tra Twitter hay gì đó. "Cấp độ. Đường cong tiến triển là gì?" Vâng, trông khá đúng, ví dụ, vâng, ok. Vì vậy, hy vọng bạn sẽ có thể làm việc thông qua điều này với AI. Và về cơ bản là cố gắng đạt được sự đồng điệu. Và grill me skill này có thể kéo dài rất lâu. Nó có thể, tôi đã từng được nó hỏi 40 câu hỏi. Tôi đã từng được nó hỏi 80 câu hỏi. Tôi đã thấy một số người được hỏi 100 câu hỏi, nghĩa là bạn ngồi đó một giờ trò chuyện với AI. Và điều bạn nhận được về cơ bản là lịch sử cuộc trò chuyện này hoạt động rất tốt và hoạt động rất tốt như một asset của design concept mà bạn đang tạo ra.

Điều này cũng có thể hoạt động như thế này. Bạn có thể có một cuộc họp với một người nào đó có thể là một domain expert. Có lẽ tôi có một cuộc họp với Sarah. Tôi đưa bản transcript cuộc họp đó vào, tôi không biết, Gemini meetings hoặc bất cứ thứ gì các bạn đang sử dụng. Bạn lấy bản đó, bạn đưa nó vào một phiên grilling và bạn grill qua những giả định mà bạn chưa có. Vì vậy, điều này cuối cùng trở thành một cách thực sự tốt để chỉ lấy đầu vào từ thế giới và sau đó biến đổi và xác thực chúng.

Chuyển sang Hỏi & Đáp và Tiếp tục Tương tác với AI

Vậy thì ok. Hãy xem. Tôi thực sự muốn đi đến cuối cùng của điều này nhưng tôi cũng không muốn chỉ ngồi đây nói chuyện với AI trước mặt các bạn trong một nghìn ngày. Vì vậy tôi sẽ chỉ nói "có", hãy xem điều gì sẽ xảy ra.

Vậy tôi sẽ nói cho các bạn biết, trong khi các bạn tự mình thử nghiệm một chút với cái này, hãy bắt đầu một phiên hỏi đáp nhỏ ngay bây giờ và hãy xem, điều này sẽ hoạt động như thế nào? Chúng ta có thể đóng cửa không? Tôi sẽ bật micro lên. Khá ồn ào. Hãy xem. Mike, chúng ta có thể đóng cửa không? Ồ, nó đã được đóng rồi. Mark đã trả lời. Tuyệt vời.

Vậy điều tôi muốn các bạn làm là có điều hòa không? Vâng, tôi nghĩ là có điều hòa. Có một số điều hòa. Các bạn không bị nướng ở đây. Tôi thì đang bị nướng sống từ một căn phòng ở đây. Vì vậy, điều tôi muốn làm là hãy vào Slido, mà các bạn có thể tham gia ở đây, hãy, nếu bạn không làm bài tập, hãy vào Slido, thử một chút và bình chọn cho một số câu hỏi hay. Tôi sẽ trò chuyện với AI một lát cho đến khi chúng ta đạt đến một điểm dừng. Vậy thì chỉ streaks (chuỗi) và điểm, streaks là độc lập. Hãy xem nó còn đưa ra điều gì nữa. UI của gamification nằm ở đâu? Hãy để nó ở dashboard. Tôi sẽ chỉ quét qua những câu hỏi này và trả lời nhanh chóng.

Q&A: Sở hữu "Planning Stack" và Lập trình Cặp với AI

Vậy Slido của chúng ta thế nào rồi? Ok. "Tôi đã thử spec kit, open spec hay taskmaster vào Grille-Me skill chưa? Tôi có thấy chúng dài dòng hơn hay là một structural tenant không?" Đây là một câu hỏi tuyệt vời.

Có rất nhiều framework ngoài kia cho phép bạn xây dựng quy trình lập kế hoạch này cho mình. Cá nhân tôi tin rằng ở giai đoạn này, khi không có người thắng cuộc rõ ràng, khi không có một cách duy nhất đúng và khi mọi thứ thay đổi liên tục, bạn cần sở hữu càng nhiều planning stack của mình càng tốt. Điều tôi nhận thấy ở nhiều sinh viên của mình là họ có xu hướng lạm dụng một stack nhất định. Họ gặp rắc rối và bởi vì họ không sở hữu stack này và họ không có observability (khả năng quan sát) toàn bộ mọi thứ, họ chỉ nói, "cái này không hoạt động, tệ quá." Trong khi nếu bạn có quyền kiểm soát toàn bộ mọi thứ, thì ít nhất bạn biết cách khắc phục hoặc có khả năng biết cách khắc phục nó. Vì vậy tôi đang cung cấp cho bạn một stack về cơ bản. Tôi tin vào inversion of control (đảo ngược kiểm soát) và bạn nên là người kiểm soát stack.

Tôi có thể ban phước cho không? Đó là rất nhiều tiếng lẩm bẩm. Cảm ơn bạn. Tôi rất xin lỗi. Chà, bạn không muốn đưa feedback tốt cho Claude khi anh ấy đang... Bạn ở đâu? Tuyệt.

"Nhiều câu hỏi do Grille-Me skill hỏi không nhất thiết phù hợp với nhà phát triển, mà là một PO (Product Owner), trong các nhóm lớn hơn thì ai nên sử dụng nó?" Vâng.

Hãy giơ tay nếu bạn đã từng pair programming (lập trình cặp). Ai đã từng pair programming rồi, đúng không? Hãy hạ tay xuống và giơ tay lại nếu bạn đã từng thực hiện một phiên pair programming với AI. Đúng. Nó diễn ra thế nào? Có tốt không? Thích không? Tôi nghĩ các phiên pair programming với AI là một ý tưởng tuyệt vời vì bạn có một người thứ ba trong phòng sẽ không ngừng chất vấn và hỏi bạn các câu hỏi. Nếu bạn không biết câu trả lời, đó nên là bạn, domain expert và AI trong cùng một phòng. Nếu bạn có câu hỏi về implementation, đó nên là bạn, một nhà phát triển đồng nghiệp và AI trong cùng một phòng. Bạn có thể giải quyết những câu hỏi này trong nhóm của mình. Và tôi nghĩ thực ra chúng ta sẽ xem xét implementation một chút và chúng ta sẽ thấy cách bạn có thể làm cho implementation nhanh hơn rất nhiều.

Quyết định Quan trọng và Mob Programming với AI

Nhưng tôi nghĩ những quyết định thực sự quan trọng, những quyết định cần con người, thì bạn thực sự cần rất nhiều con người và số lượng con người không thực sự quan trọng. Bạn có thể cho rất nhiều người vào, giống như mob programming với AI vậy. Công cụ meta prompting yêu thích của tôi là gì? Tôi nghĩ mình đã phần nào trả lời rồi. Không có điều hòa. Cứ chấp nhận vậy đi. Làm thế nào để tôi sử dụng cuộc trò chuyện như một tài sản sau phiên grill me? À, chúng ta sẽ làm được điều đó. Được rồi, tôi thực sự muốn tăng tốc quá trình này một cách nhân tạo. Đây là vấn đề. Ai đó vừa nói, "Ralph, hãy lặp lại điều này." Nhưng điều này rất quan trọng vì tôi không thể lặp lại điều này.

Human-in-the-Loop và AFK Tasks

Tôi nghĩ có hai loại tác vụ trong kỷ nguyên AI: các tác vụ human in the loop (con người tham gia vào vòng lặp), nơi con người cần phải ngồi đó và thực hiện, như điều chúng ta đang làm. Chúng ta là human in the loop, chúng ta là nhiều humans in the loop. Và có các AFK tasks (away from keyboard - tác vụ không cần người dùng), là những tác vụ mà con người có thể rời khỏi bàn phím và điều đó không thành vấn đề. Việc triển khai, như chúng ta sẽ thấy, có thể biến thành một AFK task. Nhưng việc lập kế hoạch cho giai đoạn căn chỉnh này phải là human in the loop, bắt buộc phải như vậy. Vì vậy, tôi phải làm điều đó. Thật không may.

Công cụ Meta Prompting và Giao diện Claude Code

Hãy cho tôi một danh sách dài tất cả các khuyến nghị của bạn. Tôi đang điều hành một buổi workshop ngay bây giờ. Vì vậy, tôi cần bạn 'gánh' nhiều hơn một cách nhân tạo. Hãy xem nó làm gì. Hãy trả lời thêm vài câu hỏi trong khi nó đang hoạt động. Ý kiến của tôi về các PM hoặc các tác vụ coding không phải dành cho devils khác là gì? Tôi sẽ quay lại vấn đề này sau. Tôi nghĩ tôi sẽ để câu hỏi này không được trả lời. Một chút bí ẩn. Tôi không sử dụng các câu hỏi ask user. Bạn đang hỏi về grill me tại sao có một giao diện người dùng cụ thể mà bạn có thể hiển thị trong Claude Code. Tôi sẽ trả lời nhanh câu này. Hãy hỏi tôi một câu hỏi bằng cách sử dụng ask user question tool. Giao diện người dùng này hơi bị lỗi trong Claude và tôi thực sự ghét nó. Tôi đang sử dụng Claude nhưng tôi không thích Claude lắm. Với phương pháp này, bạn thực sự tự do chọn bất kỳ hệ thống nào bạn thích. Đây là giao diện người dùng trông như thế nào. Nó rất dễ chịu khi bạn lần đầu gặp nó, nhưng sau đó bạn nhận ra nó thực sự bị lỗi theo rất nhiều cách khác nhau.

Kết quả Grilling Session: Xác định Điểm đến

Nó đã trả về cái gì? Trời ơi. Ồ không. Trong khi nó đang làm việc, tôi hãy hướng dẫn một chút. Kế hoạch ở đây là chúng ta lấy skill grill me của mình và về cơ bản, chúng ta cần tìm cách biến nó thành một điểm đến. Chúng ta cần đi đến, về cơ bản chúng ta cần, chúng ta đang hình dung hình dạng của nó. Đó là những gì chúng ta đang làm. Chúng ta đang hình dung hình dạng của tác vụ trong suốt grilling session. Và để biến nó thành một loạt các hành động có thể thực hiện được cho AI, chúng ta về cơ bản cần xác định điểm đến. Chúng ta cần biết mình đang đi đâu. Chúng ta cần biết hình dạng của toàn bộ thứ này. Vì vậy, tôi nghĩ có hai tài liệu thiết yếu mà chúng ta cần. Chúng ta cần tài liệu đó, tài liệu về điểm đến. Ồ không. Nó không đủ sáng. Được rồi. Chúng ta cần một cái gì đó để ghi lại điểm đến và chúng ta cần một cái gì đó để ghi lại hành trình.

Nói cách khác, chúng ta cần một cái gì đó, một tài liệu sẽ hình dung xem điều này trông như thế nào trong tất cả các user stories của nó và xác định một definition of done (định nghĩa hoàn thành). Và sau đó chúng ta cần tìm hiểu xem sự phân chia trông như thế nào. Đó là nơi chúng ta sẽ đến tiếp theo. Vì vậy, một khi chúng ta kết thúc grilling session, ừ, nó trông rất tuyệt. Tuyệt vời. Tôi thích nó. Nó đã trả lời, nó đã tự trả lời 22 câu hỏi của mình. Đó là một hình ảnh khá tiêu biểu về một grilling session. Vì vậy, đến thời điểm này, tôi đã sử dụng 25 nghìn token và tất cả hoặc rất nhiều thứ đó là vàng. Tôi muốn giữ lại chúng. Tôi có 25 nghìn token tuyệt vời ở đó. Và điều tôi muốn làm là tóm tắt nó vào một loại destination documents. Vậy đây là bài tập tiếp theo mà chúng ta sẽ làm: viết một product requirements document.

Viết Product Requirements Document (PRD)

Và product requirements document hay PRD về cơ bản là tài liệu chức năng đó. Nó là destination document. Và hình dạng của nó không thực sự quan trọng. Tôi có một hình dạng mà tôi thích và khá ưng ý. Nhưng bạn có thể chọn hình dạng của riêng mình hoặc bất cứ thứ gì công ty bạn sử dụng. Và tất cả những gì chúng ta thực sự đang làm là lo lắng về điều đó. Tất cả những gì chúng ta thực sự đang làm là tóm tắt khái niệm thiết kế mà chúng ta đã có cho đến nay. Và vì vậy, hãy thử điều này. Vì vậy, tôi sẽ bắt đầu điều này. Tôi sẽ nói cuộn xuống dưới cùng. Tất cả những gì tôi sẽ làm là nói "viết một PRD". Và bây giờ chúng ta có thể xem xét skill đó. "Viết một PRD".

Skill PRD và Cấu trúc Tài liệu

Vì vậy, skill này làm một vài điều. Đầu tiên nó yêu cầu người dùng mô tả chi tiết dài về vấn đề. Bạn có thể sử dụng write a PRD mà không cần grilling trước, nhưng tôi chỉ thích grill trước rồi sau đó viết PRD. Sau đó, bạn có thể yêu cầu nó khám phá repo mà chúng ta đã làm. Sau đó, chúng ta yêu cầu nó phỏng vấn người dùng một cách không ngừng nghỉ. Vì vậy, tôi không thể có một grilling session nữa. Và sau đó chúng ta bắt đầu xây dựng một PRD template. Vì vậy, mẫu này có sẵn trong repo nếu bạn muốn kiểm tra. Và về cơ bản, đây là những gì nó trông như thế nào. Chúng ta có một số problem statements (tuyên bố vấn đề). Vấn đề mà người dùng đang gặp phải. Giải pháp cho vấn đề và một tập hợp các user stories. Và những user stories này phần nào định nghĩa đây là gì. Như các bạn có lẽ đã thấy những điều tương tự nếu bạn đã từng là một nhà phát triển. Có Cucumber là một ngôn ngữ bạn có thể sử dụng để viết chúng, hoặc chúng ta chỉ tự viết chúng. Sau đó, chúng ta có một danh sách các implementation decisions (quyết định triển khai) đã được đưa ra và quan trọng hơn là danh sách các testing decisions (quyết định kiểm thử) nữa.

Đề xuất Modules và Tích hợp GitHub Issues

Vì vậy, tôi sẽ chạy cái này. Được rồi. Và nó đã hoàn thành công việc của mình. Windows hãy để tôi đóng cái này lại. Cảm ơn. Tôi không biết tại sao nhưng máy tính xách tay Windows. Tôi nghĩ tôi chỉ thích thử thách thôi. Vì vậy, điều đầu tiên nó sẽ cung cấp cho tôi là một tập hợp các proposed modules (module đề xuất) mà nó muốn sửa đổi. Có một lý do sâu sắc đằng sau việc tôi nghĩ về điều này. Vì vậy, ở giai đoạn này, chúng ta có một ý tưởng. Chúng ta đã phần nào specced out (đặc tả) ý tưởng. Chúng ta đã đạt được một sự hiểu biết về những gì chúng ta đang cố gắng làm và sau đó chúng ta cần bắt đầu nghĩ về mã code vì tại thời điểm này, chúng ta cần—đây không phải là specced a code. Đây không phải là nơi chúng ta bỏ qua mã code. Chúng ta thực sự giữ mã code trong tâm trí xuyên suốt toàn bộ quá trình. Và cách tôi thích làm điều này là tôi thích suy nghĩ về một tập hợp các proposed modules để sửa đổi. Chúng ta sẽ quay lại ý tưởng này về việc liên tục thiết kế hệ thống của bạn và giữ hệ thống của bạn trong tâm trí. Vì vậy, nó đang nói đề xuất kiểm thử cho gamification service. Nó là module sâu duy nhất có logic ý nghĩa. Các module này có vẻ đúng. Ừ. Trông tốt. Và nó sẽ xuất ra một PRD.

Bây giờ để dễ thiết lập, tôi đã thiết lập nó để tạo một tập hợp các issues cục bộ. Vì vậy, nó sẽ tạo về cơ bản một PRD bên trong thư mục issues này. Nhưng cách tôi thường làm và bạn có thể tự kiểm tra điều này là bạn có thể vào repo công việc của tôi, đó là github.com/macpokock/course-video-manager ở đây. Và trong đó, đây về cơ bản là một app mà tôi tạo và sử dụng mọi lúc để quay video của mình và những thứ tương tự. Tôi nghĩ tôi đã quay như tôi kéo xuống một tập hợp gì đó, tôi đã quay khoảng một nghìn video ở đây hoặc một điều gì đó điên rồ. Và bạn có thể thấy ở đây nó có 744 closed issues (vấn đề đã đóng). Và đây về cơ bản là tất cả các PRD và tất cả các implementation issues (vấn đề triển khai) mà tôi đã đưa vào đây. Vì vậy, đây là cách tôi thường làm. Vậy đó là những gì tôi đang làm với, đó rồi. Ừ. Tôi sẽ nói 'có' và lấy issue đó ra. Hãy xem nó có ở bên trong đây không. Vì vậy, chúng ta có problem statement. Mọi người đăng ký các khóa học. Giải pháp, các user stories. 18 user stories trông đẹp. Một số implementation decisions, level thresholds, v.v. Đây là đủ thông tin. Chúng ta đã phần nào làm rõ mình đang đi đâu và làm gì. Vậy đó là những gì chúng ta làm. Chúng ta về cơ bản có một grilling session và chúng ta đã tạo ra một asset (tài sản) từ nó.

Tại sao không Đọc PRD đã Tạo?

Bây giờ hãy giơ tay. Tôi có nên xem xét tài liệu này không? Hãy giơ tay nếu bạn nghĩ tôi nên xem xét tài liệu. Vâng, tôi không xem những cái này. Tôi không xem những cái này. Lý do tôi không xem chúng là vì tôi đang kiểm tra điều gì vào thời điểm này? Khi tôi đọc nó, tôi đang kiểm tra điều gì? Những failure modes (chế độ lỗi) nào tôi đang cố gắng kiểm tra? Tôi biết rằng các LLM rất giỏi trong việc summarization (tóm tắt) vì chúng thực sự giỏi. Chúng thực sự giỏi summarization. Tôi đã đạt được cùng một wavelength (tần số) với LLM, đúng không? Sử dụng skill Grill-Me, chúng ta có một shared design concept (khái niệm thiết kế chung). Vì vậy, nếu tôi có một shared design concept, tất cả những gì tôi đang làm về cơ bản là kiểm tra khả năng summarize của LLM. Tôi không có xu hướng đọc những cái này.

Q&A: Suy nghĩ về Claude, TypeScript và Context Window

Hãy cùng Q&A vì tôi có thể lừa các bạn rằng các bạn đang muốn hỏi. Tôi nghĩ chúng ta có thể nghỉ giải lao năm phút để tôi nghỉ giọng và để các bạn có thể bắt kịp các bài tập một chút. Hãy có một buổi Q&A nhỏ. Nếu tôi không thích Claude code, vậy thì tôi thực sự thích cái nào? Bạn đã bao giờ nghe câu "dân chủ là cách tệ nhất để điều hành một đất nước, ngoại trừ tất cả những cách khác" chưa? Đó là cảm giác của tôi về Claude. Chúng ta đã trả lời câu đó rồi. Suy nghĩ của bạn về các developer và việc bạn cần hiểu rất sâu TypeScript bây giờ khi fix the TS make-no mistakes đã tồn tại là gì? Tôi không hiểu cách diễn đạt này, nhưng tôi nghĩ tôi hiểu ý nghĩa, đó là tôi tin rằng code rất quan trọng, và điều này sẽ xuyên suốt toàn bộ buổi nói chuyện, và rằng bad code bases (cơ sở mã tệ) tạo ra bad agents (tác nhân tệ). Nếu bạn có một garbage code base (cơ sở mã rác), bạn sẽ nhận được garbage out of the agent (kết quả rác từ tác nhân) đang làm việc trong code base đó. Chúng ta sẽ nói thêm về điều đó một chút. Vì vậy, tôi nghĩ việc hiểu sâu các công cụ này, hiểu sâu code sẽ khiến bạn trở thành một developer tốt hơn rất nhiều và khai thác được nhiều hơn từ AI. Điều đó cũng trả lời câu hỏi đó, tuyệt vời. Thoát khỏi đây.

Bây giờ chúng ta có một triệu tokens khả dụng, chúng ta có thực sự muốn tận dụng nó không? Tôi nhận thấy rằng dumb zone (vùng ngu ngốc) gần đây đã trở nên ít 'ngu ngốc' hơn. Được rồi, câu hỏi tuyệt vời. Điều này quay trở lại ý tưởng ban đầu của chúng ta về dumb zone. Tôi đã ghi lại khóa học Claude code của mình bằng context window 200k và vào ngày tôi ra mắt khóa học, họ đã công bố context window 1 triệu. Quan điểm của tôi về điều này là Claude về cơ bản chỉ làm điều này. Wee! Họ đã cung cấp cho bạn nhiều dumb zone hơn, về cơ bản là vậy. Bây giờ điều này tốt cho các tác vụ mà bạn muốn retrieve things (truy xuất mọi thứ) từ một context window lớn. Nếu bạn muốn truyền năm bản War and Peace hoặc thứ gì đó vào đó và bạn muốn tìm tất cả những thứ mà tôi không thể nhớ một nhân vật nào từ War and Peace. Tại sao tôi lại bắt đầu với điều đó? Nó tốt cho retrieval (truy xuất). Nó ít tốt hơn cho coding. Tôi cho rằng hiện tại nó khoảng 100k. Đó là smart zone (vùng thông minh). Smart zone sẽ lớn hơn và đó sẽ là một cải thiện thực sự tốt đẹp.

Nghỉ Giải Lao và Chuẩn bị cho Bước Tiếp Theo

Vì vậy, mọi người, chúng ta sẽ nghỉ giải lao khoảng năm phút nếu được, chỉ để tôi nghỉ giọng và có thể các bạn có thể di chuyển một chút hoặc uống nước. Tôi chỉ nhận thấy một vài đôi mắt buồn ngủ và tôi muốn đảm bảo rằng chúng ta tỉnh táo cho phần tiếp theo nếu được. Vì vậy, chúng ta sẽ nghỉ năm phút và tôi sẽ gặp lại các bạn ở đây sau. Được rồi. Vậy chúng ta có PRD mà tôi sẽ không đọc. Một loại destination document. Hãy nhanh chóng quét xem có câu hỏi hay nào không trước khi chúng ta tăng tốc và chúng ta đang khám phá vai trò của software engineering trong thế giới ngày nay, top three disciplines (ba ngành hàng đầu) bạn đề xuất. Tôi nghe nói Ty Quanto rất tốt. Tôi không biết trả lời câu hỏi này như thế nào. Cảm ơn bạn đã hỏi. Đó là tất cả ba ngành tôi đề xuất. Ý tôi là, xin lỗi? Leo núi là một cái hay. Vâng, tôi không biết đó có phải là một ngành không. Những người thợ sửa ống nước tôi thuê thường không kỷ luật lắm. Đúng vậy. Không sao. Bây giờ chúng ta đã có điểm đến. Được rồi. Vậy làm thế nào chúng ta thực sự đến được điểm đến của mình? Làm thế nào chúng ta có một PRD mơ hồ? Làm thế nào chúng ta chia nó để chúng ta không đưa mọi thứ vào dump zone? Nói cách khác, chúng ta có số bốn.

Phân chia kế hoạch đa giai đoạn và Bảng Kanban

Làm thế nào để chúng ta chia nhỏ một dự án thành kế hoạch đa giai đoạn? Có lẽ ở thời điểm này, bạn sẽ yêu cầu Claude đưa ra một kế hoạch đa giai đoạn để đạt được mục tiêu. Điều đó có lý. Đây là cách chúng ta vẫn làm trước đây. Nhưng tôi có một cách tốt hơn để làm điều đó hiện tại, đó là tôi thích tạo một bảng Kanban board từ kế hoạch này. Một bảng Kanban board về cơ bản là một tập hợp các ticket mà bạn dán lên tường, có các mối quan hệ blocking với nhau.

Chúng ta sẽ xem nó trông như thế nào. Đây là cách chúng ta đã làm việc với tư cách là nhà phát triển trong một thời gian dài, đặc biệt là kể từ khi Agile ra đời. Và như chúng ta có thể thấy ở đây, nó đã đề xuất chia nhỏ thiết lập này thành năm nhiệm vụ khác nhau. Nhiệm vụ đầu tiên là Schema và Gamification Service. Có vẻ khá tốt. Nhiệm vụ này không bị block bởi bất kỳ điều gì. Và chúng ta thậm chí có thể thấy ở đây nó được gán loại AFK. Nhớ lại tôi đã nói về human in the loop và AFK trước đó. Đây là một tác vụ AFK, tức là một nhiệm vụ mà chúng ta có thể giao cho một agent tự thực hiện. Strict tracking, ổn, trông tốt. Sau đó là wire points and streaks into lessons quiz completion. Nhiệm vụ này bị block bởi nhiệm vụ một và hai. Retractive backfill thì chỉ bị block bởi nhiệm vụ một. Và nhiệm vụ cuối cùng bị block bởi tất cả các nhiệm vụ còn lại.

Đánh giá kế hoạch do AI tạo ra và Tracer Bullets

Bạn có thể tự hỏi, tại sao chúng ta không chỉ để AI tự động tạo ra các issue? Tại sao tôi lại phải tham gia vào đây? Vì AI đã cung cấp cho chúng ta một lựa chọn công cụ khá tốt rồi. Tại sao tôi cần xem xét và tìm ra bước tiếp theo? Theo quan điểm của tôi, việc này rất rẻ và nhanh chóng thực hiện sau khi tôi hoàn thành PR. Và tôi có thể ngay lập tức nhìn thấy một số vấn đề. Có một kỹ thuật thực sự, thực sự quan trọng khi bạn hình dung hình dạng của hành trình này sẽ như thế nào. Và nó đến từ một ý tưởng rất cổ điển, từ một chương trình thực dụng có tên là Tracer Bullets hoặc Vertical Slices. Và Tracer Bullets đã thực sự thay đổi cách tôi nghĩ về việc để AI tự chọn nhiệm vụ của nó.

Các hệ thống có các layer, phải không? Có các layer trong hệ thống của bạn. Đây có thể là các deployable unit khác nhau. Bạn có thể có một database ở một nơi nào đó. Bạn có thể có một API nằm gần database, nhưng ở một phần riêng biệt. Bạn có thể có một front end nằm ở một nơi hoàn toàn khác, như một CDN. Hoặc trong các deployable unit này, bạn có thể có các layer khác nhau bên trong chúng. Ví dụ, trong code base mà chúng ta đang làm việc, chúng ta có rất nhiều service khác nhau. Chúng ta có quiz service, team service, user service, coupon service, course service. Và các service này có dependencies lẫn nhau, vì vậy chúng chúng giống như các layer riêng lẻ.

Vấn đề với cách AI lập trình theo chiều ngang (Horizontal Slices)

Điều tôi nhận thấy là AI rất thích lập trình theo chiều ngang (horizontally). Vì vậy, nó thích lập trình từng layer một. Nói cách khác, trong giai đoạn một, nó sẽ làm tất cả các công việc về database, tất cả schema, tất cả những thứ liên quan đến đơn vị đó. Sau đó, nó sẽ chuyển sang giai đoạn hai và làm tất cả các công việc về API, sau đó nó sẽ thêm front end lên trên đó. Có ai có thể cho tôi biết điều gì sai với bức tranh đó không? Tại sao đó không phải là một điều tốt để làm?

Chính xác! Bạn sẽ không nhận được feedback về công việc của mình cho đến khi bạn thực sự bắt đầu hoặc hoàn thành giai đoạn ba. Vì vậy, điều bạn thực sự cần làm là, cho đến khi bạn đến giai đoạn ba, bạn không thực sự kiểm tra xem tất cả các layer có hoạt động cùng nhau hay không. Bạn không có một hệ thống integrated để kiểm tra. Thay vào đó, bạn cần nghĩ về các vertical layers. Bạn cần nghĩ về các thin slices of functionality (các lát cắt chức năng mỏng) đi qua tất cả các layer mà bạn cần. Và đây là một cách làm việc tốt hơn nhiều, một cách tốt hơn nhiều để AI làm việc, bởi vì điều đó có nghĩa là vào cuối giai đoạn một hoặc trong giai đoạn một, nó có thể nhận được feedback về toàn bộ luồng công việc của mình.

Ứng dụng Vertical Slices và hướng dẫn AI

Điều này có ý nghĩa với tôi là trong kỹ năng PRD to issues skill up ở đây, tôi đã có lệnh "chia một PRD thành các issue có thể tự grab (independently grabable issues) bằng cách sử dụng các vertical slices có thể trace được. Nó được viết dưới dạng các tệp markdown cục bộ. Chúng ta đầu tiên định vị PRD. Một lần nữa, khám phá code base nếu đây là một phiên làm việc mới. Chúng ta phác thảo các vertical slices. Vì vậy, chúng ta chia PRD thành các traceable issues.

Tracer bullet thực chất giống như khi bạn là một xạ thủ phòng không, một ý tưởng khá bạo lực. Và bạn nhìn lên bầu trời vào ban đêm. Nếu bạn chỉ bắn đạn thông thường, bạn không biết mình đang bắn vào cái gì. Bạn chỉ thấy máy bay, nhưng bạn không thấy viên đạn của mình đi đâu. Tracer bullet là họ gắn một chút phosphorescence hoặc phosphol hoặc thứ gì đó để làm nó phát sáng khi bay. Điều này có nghĩa là cứ mỗi sáu viên đạn hay gì đó, bạn sẽ thấy một vệt sáng trên bầu trời. Vì vậy, bạn có feedback về nơi bạn đang nhắm. Đây chính là ý tưởng ở đây, chúng ta tăng mức độ feedback và nhận được feedback gần như tức thì về những gì chúng ta đang xây dựng. Bởi vì nếu không có điều đó, AI sẽ lập trình mù cho đến khi đạt đến các giai đoạn sau.

Chúng ta có một số quy tắc vertical slice. Chúng ta hỏi người dùng. Và sau đó chúng ta tạo các tệp issue. Vì vậy, điều tôi thấy ở đây là mặc dù tôi đã yêu cầu nó làm vertical slices, nó lại đề xuất tạo gamification service trước tiên một mình. Đó chỉ là một lát cắt ở đó. Và đó thực sự giống như một horizontal slice. Điều tôi muốn thấy trong vertical slice đầu tiên, đặc biệt là tôi muốn thấy các thay đổi schema hoặc một số thay đổi schema. Tôi muốn thấy một service mới được tạo và tôi muốn có một minimal representation (đại diện tối thiểu) của điều đó trên front end. Vì vậy, tôi muốn nó đi qua các vertical slices, không chỉ horizontal. Bạn hiểu chứ?

Được rồi. Vì vậy, tôi sẽ chỉnh đốn AI. Không. Tôi sẽ không lãng phí token chỉ để đùa cợt. Vì vậy, lát cắt đầu tiên là quá ngang. Tôi sẽ bắt đầu bằng điều đó và xem liệu nó có hiểu được không. Điều đó có ý nghĩa như một khái niệm không? Và tôi nghĩ rằng điều tôi thực sự thích khi quay lại những cuốn sách cũ đó là chúng ta thực sự đang cố gắng, trong thời đại này, để verbalize (diễn đạt bằng lời) các best software practices (thực tiễn phần mềm tốt nhất) bằng tiếng Anh. Và những cuốn sách 20 năm tuổi này đã làm được điều đó rồi. Và đó là một "mỏ vàng" tuyệt đối nếu bạn muốn đưa vào các prompt. Nhưng ngay cả với điều đó, nó cũng sẽ không làm hoàn hảo mỗi lần.

Vì vậy, "Trao điểm cho việc hoàn thành bài học hiển thị trên dashboard." Vâng, đó là một vertical slice đẹp bởi vì nó chắc chắn là một phần lớn công việc. Nó đang thực hiện rất nhiều story ở đó. Nhưng chúng ta sẽ thấy một cái gì đó hiển thị ở cuối và AI sau đó sẽ chỉ có thể thêm vào đó. Bạn hiểu tại sao điều đó lại được ưu tiên hơn so với cái đầu tiên. Tuyệt vời. Trông rất tuyệt. Vì vậy, chúng ta đang tiến gần hơn rồi.

Giải đáp thắc mắc và tối ưu hóa quy trình

Có ai theo dõi ở nhà không? Bạn biết ở nhà, nhưng bạn hiểu ý. Chúng ta sẽ hy vọng thấy điều tương tự để bắt đầu phát triển những instinct tương tự. Hãy mở phần câu hỏi trong khi tôi đang tạo các GitHub issue này. Không, không phải GitHub issue. Local issues. Khi nào tôi sẽ ngừng dùng Windows? Không bao giờ! Câu hỏi của bạn, được rồi, chúng ta sẽ đến đó sau.

Làm thế nào AI quyết định khi nào ngừng grilling (hỏi dồn)? Bởi vì AI có thể hỏi không ngừng, chúng ta có thể có một cách thông minh hơn để quyết định stop point (điểm dừng) không? Vâng, nó thực sự có xu hướng, những grilling sessions đó có thể cực kỳ căng thẳng. Và điều đặc biệt về những skill này là bạn có thể điều chỉnh chúng nếu muốn. Nếu bạn cảm thấy AI đang liên tục tấn công, thì bạn có thể bảo nó giảm bớt hoặc bảo nó làm, bạn biết đấy, stop point và những thứ tương tự. Vì vậy, nếu đó là một failure mode (chế độ lỗi) mà bạn gặp phải nhiều, thì bạn chỉ cần thay đổi skill.

Tôi có còn sử dụng ngữ pháp cực kỳ cô đọng "hy sinh ngữ pháp để nhượng bộ" không? Có một mẹo mà tôi đã đưa ra cho mọi người năm tháng trước, đó là về cơ bản để tăng readability (khả năng đọc) của các kế hoạch của bạn. Vì vậy, khi bạn sử dụng plan mode, bạn có thể đưa nó vào tệp Claude.MD của mình và bạn có thể nói, được rồi, vâng, chấp thuận điều đó. Hãy mở tệp Claude.MD. Tôi có tệp Claude.MD không? Có lẽ là không. Tôi thực sự không sử dụng Claude.MD nhiều. Tôi sẽ chỉ đặt một cái giả vào đây. Khi, không, khi nói chuyện với tôi, "hy sinh ngữ pháp để nhượng bộ". Và prompt này thực sự hữu ích cho tôi khi tôi đọc các kế hoạch bởi vì nó có nghĩa là các kế hoạch sẽ rất cô đọng, thực sự tốt, dễ đọc, thường rất cô đọng. Nhưng tôi đã từ bỏ ý tưởng này để ưu tiên một grilling session bởi vì điều tôi nhận thấy là, tôi không muốn đọc các kế hoạch. Tôi muốn có cùng wavelength (tần số) với LLM. Tôi muốn nó hỏi tôi những aggressive questions (câu hỏi gay gắt). Và khi tôi ngừng đọc các kế hoạch, tôi ngừng cần chúng phải cô đọng. Vì vậy, tôi coi các kế hoạch thực sự trong destination document là end state (trạng thái cuối cùng). Và tôi không cần end state đó phải cô đọng. Hy vọng điều đó trả lời câu hỏi của bạn.

Tôi nghĩ kết quả của "cuộc đối đầu kiểu Mexico" về vai trò tương lai của PM và các vai trò khác hội tụ sẽ như thế nào? Tôi không có ý kiến gì cả. Tôi không phải là một pundit. Tôi không có ý kiến gì.

Parallelization với Kanban Board và Directed Acyclic Graphs

Được rồi. Vì vậy, sau một vài lần phê duyệt, chúng ta sẽ có một tập hợp các issue. Các issue mà chúng ta đang tạo này được thiết kế để có thể grab độc lập (independently grabable), có nghĩa là bảng Kanban board này sẽ trông như thế này, nơi bạn về cơ bản có một tập hợp các ticket với rất nhiều independent relationships (mối quan hệ độc lập). Ví dụ, ticket này cần được thực hiện sau ticket số bốn, ticket này, và ticket này. Điều này có nghĩa là bạn có thể bắt đầu parallelize (song song hóa). Bạn có thể bắt đầu để các agent làm việc cùng lúc trên các nhiệm vụ này, bởi vì vâng, nhiệm vụ này cần được thực hiện trước. Và sau đó hai nhiệm vụ kia có thể được grab cùng lúc bởi các independent agent.

Điều này cho phép bạn biến những kế hoạch đó thành, nói một cách tối ưu, một dạng directed acyclic graph (đồ thị không chu trình có hướng), nơi bạn về cơ bản có ba giai đoạn ở đây: giai đoạn một, bạn làm nhiệm vụ này. Sau đó giai đoạn hai, bạn làm hai nhiệm vụ bên dưới nó. Và sau đó giai đoạn ba, bạn làm nhiệm vụ thứ ba này và thêm nó vào đó. Và khi bạn nghĩ về việc có thể có, đây là một kế hoạch tương đối đơn giản, nhưng bạn có thể có nhiều kế hoạch khác nhau hoạt động cùng một lúc, điều đó có nghĩa là bạn có thể thực hiện parallelization thực sự tốt, và chúng ta sẽ nói thêm về điều đó một chút nữa. Nhưng đó là lý do tại sao tôi thích một thiết lập Kanban board như thế này hơn là một sequential plan (kế hoạch tuần tự), bởi vì một sequential plan thực sự chỉ có thể được một agent đảm nhận. Vì vậy, kế hoạch này ở đây, nó thực sự chỉ là một loop, phải không? Chỉ một agent có thể làm việc trên những nhiệm vụ này bởi vì chúng ta có các giai đoạn được đánh số và chúng không thể parallelize được. Bạn hiểu chứ?

Chuyển giao quá trình thực thi cho Agent

Tuyệt vời. Vì vậy, chúng ta đã có các issue của mình. Nào, ngừng hỏi tôi về, tôi biết nó đang tạo chúng trên GitHub, tôi thực sự không muốn điều đó. Không, không, bạn sai rồi. Hãy tạo chúng trong issues thay vì thế. Không, điều đó không đủ chính xác. Bạn sai rồi. Hãy tạo chúng trong các tệp markdown cục bộ thay vì thế, tham chiếu phiên bản cục bộ, xin lỗi về điều này.

Vì vậy, một khi chúng ta đạt đến điểm này, chúng ta có một loạt issue cục bộ mà chúng ta có thể bắt đầu loop (lặp lại) và thực hiện. Và chính tại thời điểm này, con người rời khỏi loop (human leaves the loop). Cho đến nay, hãy để tôi đưa ra một cái nhìn tổng quan về luồng công việc mà chúng ta đang khám phá ở đây. Cho đến nay, chúng ta đã lấy một ý tưởng, như chúng ta đã thấy, và chúng ta đã tự grill (nghiền ngẫm) về ý tưởng đó. Chúng ta có thể bỏ qua research and prototype (nghiên cứu và tạo mẫu), nhưng chúng ta biến điều đó thành một PRD thành một destination document. Sau đó, chúng ta đã biến PRD đó thành một Kanban board, và tất cả các bước đó đều được con người review (human reviewed). Và bây giờ, ở implementation stage (giai đoạn thực hiện), chúng ta lùi lại và để một agent làm việc thông qua Kanban board đó hoặc nhiều agent làm việc thông qua Kanban board đó.

Khai thác tác nhân AFK (Away From Keyboard)

Việc lập kế hoạch kỹ lưỡng đã tốn nhiều thời gian, nhưng đồng nghĩa với việc chúng ta đã xếp hàng rất nhiều công việc cho agent. Có thể hình dung đây như là ca ngày và ca đêm. Ca ngày dành cho con người, để lên kế hoạch mọi thứ, chuẩn bị mọi thứ sẵn sàng. Và sau khi chuyển sang ca đêm, AI có thể làm việc hoàn toàn AFK.

Chạy tác nhân AFK của bạn

Vậy, điều đó trông như thế nào? Chúng ta sẽ chuyển sang bài tập tiếp theo, cũng là bài tập cuối cùng ở đây: chạy agent AFK của bạn. Tôi gọi đây là Ralph vì về cơ bản nó là một Ralph loop. Tôi muốn đi sâu vào prompt này. Điều đầu tiên nó làm ở đây là chúng ta sẽ chạy Claude và cố gắng khuyến khích nó làm việc hoàn toàn AFK. Tôi sẽ cho bạn thấy script trông như thế nào trong ít phút nữa.

Bạn nói rằng các file local issue từ các issue được cung cấp ở đầu ngữ cảnh. Cách chúng ta làm điều đó là nếu bạn nhìn vào once.sh trong repo, đó về cơ bản chỉ là một bash script nơi chúng ta lấy tất cả các issue nằm trong các file markdown và chuyển chúng vào một biến cục bộ. Vì vậy, biến issues đó chứa tất cả các issue trong toàn bộ backlog của chúng ta. Sau đó, chúng ta lấy năm commit cuối cùng (tôi sẽ giải thích lý do sau), sau đó chúng ta lấy prompt và chỉ chạy Claude code với permission mode accept edits. Sau đó, về cơ bản chỉ cần chuyển tất cả thông tin cho nó. Đây là giao diện của trình triển khai.

Đó là một phiên bản rất đơn giản của loại loop này. Và tất nhiên, đây không phải là một loop, đây chỉ là chạy nó một lần. Loop nằm trong phiên bản AFK ở trên, phức tạp hơn đáng kể. Phần quan trọng ở đây là chúng ta cũng chạy nó trong Docker sandbox. Tôi không muốn bạn cài đặt Docker trên máy tính xách tay của mình vì chúng ta sẽ cần tải xuống một image đặc biệt và chúng ta sẽ làm tắc nghẽn Wi-Fi hội nghị nếu làm vậy. Vì vậy, tôi sẽ trình diễn điều này cho bạn, nhưng bạn sẽ không cần tự chạy nó, tuy nhiên tôi sẽ nói về nó trong ít phút nữa. Về cơ bản, once loop này, chúng ta chỉ chạy một phiên bản của thứ mà chúng ta sẽ lặp lại liên tục. Đây giống như phiên bản human in the loop. Và việc chạy cái này lặp đi lặp lại là rất quan trọng vì bạn sẽ thấy agent làm gì và cách nó hoạt động. Mọi điều chỉnh bạn cần thêm vào prompt, bạn đều có thể làm được.

Prompt sẽ được chuyển các file local issue. Bạn sẽ chỉ làm việc trên các AFK issue, điều này hợp lý. Nếu tất cả các AFK task đã hoàn thành, hãy xuất ra no more tasks. Và sau đó, điều tiếp theo, chọn task tiếp theo. Điều chúng ta đang làm ở đây là chúng ta về cơ bản đang chạy một backlog hoặc sắp xếp một backlog mà AFK agent của chúng ta sẽ thực hiện. Đó là mục đích của tất cả các thiết lập này ở phần đầu. Trong đó, cho đến Kanban board này, chúng ta về cơ bản chỉ đang tạo một backlog các task để ca đêm thực hiện. Và ca đêm, loại Ralph Prompt này, nó có ý tưởng riêng về một task tốt trông như thế nào để chọn tiếp theo.

Tôi đã nói về parallelization (song song hóa), tôi sẽ trình bày điều này sau, nhưng đây về cơ bản là một sequential loop (vòng lặp tuần tự). Chúng ta sẽ chỉ chạy một coding agent tại một thời điểm. Đây là một cách tốt để bạn làm quen với nó. Vì vậy, nó ưu tiên sửa lỗi nghiêm trọng (critical bug fixes), hạ tầng phát triển (development infrastructure), sau đó là có thể theo dõi (traceable), sau đó là các chiến thắng nhanh chóng (quick wins) và refactor. Và sau đó chúng ta chỉ có một hướng dẫn rất đơn giản về cách hoàn thành task. Vì vậy, chúng ta khám phá repo, sử dụng TDD để hoàn thành task (tôi sẽ nói về điều đó sau). Và sau đó chúng ta chạy một số feedback loop.

Vì vậy, hãy thử điều này và xem điều gì sẽ xảy ra. Tốt, nó đã tạo các file issue, chúng ta nên sẵn sàng. Tôi sẽ hủy bỏ điều này, tôi đã xóa màn hình và tôi sẽ chạy Ralph once.sh. Bạn có thể thoải mái làm điều tương tự nếu bạn đang theo dõi. Vì vậy, chúng ta có thể thấy nó chỉ đang chạy Claude bên trong với prompt và với tất cả các issue đã được chuyển vào. Và trong khi nó đang thực hiện công việc của mình, bạn có thể có một số câu hỏi về thiết lập này và về những quyết định mà tôi đã đưa ra để về cơ bản giao phó tất cả công việc viết mã của mình cho AI, phải không? Vì vậy, hãy làm một phần hỏi đáp nhanh trong khi nó đang khởi động.

Hỏi & Đáp: Những thách thức khi phát triển cùng AI Agent

Giữ lại các quyết định bị bác bỏ

Câu hỏi: Làm thế nào để bạn giữ lại các quyết định bị bác bỏ, những thứ bạn đã thiết kế chống lại và lý do khi lưu trữ kết quả từ phiên grommy?

Trả lời: Đó là một câu hỏi rất hay, có một câu trả lời rất đơn giản, đó là trong PRD (Product Requirements Document), ở mục PRD section, có một phần ở dưới cùng, một phần về những thứ nằm ngoài phạm vi (out of scope). Vì vậy, những thứ chúng ta sẽ không giải quyết trong PRD này, điều rất quan trọng để đưa ra định nghĩa về hoàn thành (definition of done).

Quy trình làm việc Front-end và Parallelization

Câu hỏi: Quy trình làm việc front-end của tôi là gì? Làm thế nào để xử lý việc các agent tạo ra nhiều mã hơn mức chúng ta có thể review? Làm thế nào để parallelize (song song hóa) và sử dụng nhiều agent một cách riêng biệt?

Trả lời: Có hai câu hỏi ở đó. Ai cảm thấy mình đang code review nhiều hơn trước đây? Chắc chắn rồi. Tôi không nghĩ có cách nào để tránh điều này. Nếu chúng ta giao phó tất cả công việc viết mã của mình cho agent, bạn sẽ nhận thấy rằng việc triển khai ở đây thực sự là phần AFK duy nhất. Sau đó, chúng ta cũng cần QA (kiểm thử) và code review công việc đó, phải không? Và nếu chúng ta đang chạy các loop mà về cơ bản nó sẽ triển khai bốn issue trong một lần, thì khó có thể kết hợp điều đó với quy tắc rằng bạn nên giữ các pull request nhỏ và tự chứa. Pull request nhỏ và tự chứa có nghĩa là bạn cần thực hiện ít loop hơn hoặc loop ngắn hơn hoặc có thể bạn làm một chồng lớn các PR, nhưng điều đó cũng có vẻ kinh khủng. Đó vẫn chỉ là nhiều mã tách rời hơn để review. Tôi thực sự chưa biết câu trả lời cho điều này. Tôi nghĩ chúng ta chỉ cần sẵn sàng làm nhiều code review hơn, về cơ bản. Điều đó không vui. Điều đó không vui, tôi không vui, tôi không biết. Tôi không cảm thấy tốt khi nói điều đó, nhưng tôi nghĩ đó có lẽ là xu hướng.

Phối hợp nhóm và phản hồi

Câu hỏi: Nếu điều này có vẻ tuyệt vời cho một nhà phát triển độc lập, nhưng làm thế nào để bạn triển khai điều này trong một nhóm? Làm thế nào để bạn thu thập phản hồi của nhóm về điều này?

Trả lời: Nếu bạn có một ý tưởng ở đó, và về cơ bản, hành trình từ ý tưởng đến đích là thứ bạn cần tìm ra với nhóm, phải không? Vì vậy, tất cả những thứ ở trên, đây giống như công việc của nhóm. Nếu bạn có một ý tưởng và bạn có một phiên grilling về nó và bạn có một câu hỏi mà bạn không biết cách trả lời, thì bạn cần đưa nhóm của mình vào cuộc như chúng ta đã mô tả trước đây. Sau đó, bạn có thể cần phải nói, được rồi, chúng ta chỉ cần xây dựng một prototype của cái này. Chúng ta cần thực sự phát triển cái này. Chúng ta cần thứ gì đó mà các chuyên gia lĩnh vực có thể thử nghiệm. Ồ, được rồi, chúng ta có thể cần tích hợp một thư viện bên thứ ba vào cái này. Chúng ta có thể cần thực hiện một số nghiên cứu. Chúng ta có thể cần thực sự xem xét và tìm một dịch vụ bên thứ ba mà chúng ta có thể khai thác tối đa. Chúng ta có thể cần quay lại với thông tin đã thu thập được ở đó để đến giai đoạn ý tưởng. Vì vậy, tất cả cho đến PRD và hành trình, đó là điều bạn cần thu hút nhóm của mình. Đó là nơi các tài sản này sẽ được chia sẻ và tranh luận, và bạn sẽ có các yêu cầu nhận xét về chúng và loop đó sẽ tiếp tục hoạt động cho đến khi bạn tìm ra nơi bạn đang đi. Khi bạn đã tìm ra nơi bạn đang đi, bạn có thể bắt đầu làm việc trên bảng Kanban. Nhưng điều này về cơ bản rất dễ tranh cãi và bạn sẽ di chuyển qua lại giữa các giai đoạn.

Prototype và Front-end

Câu hỏi: Bạn có cần một PRD cho prototype của mình không?

Trả lời: Hãy nói nhanh về prototype. Có một câu hỏi về cách bạn làm cho điều này hoạt động cho front-end. Làm thế nào để bạn, bởi vì front-end rất nhạy cảm với mắt người. Bạn cần mắt người nhìn vào front-end mọi lúc để đảm bảo rằng nó trông đẹp. AI không thực sự có mắt. Nó có thể nhìn vào mã, nhưng front-end là đa phương thức. Kinh nghiệm của tôi là cố gắng tích hợp AI vào, ví dụ, agent browser hoặc Playwright để cung cấp cho nó các tool cho phép nó xem qua front-end và nhìn vào hình ảnh. Nhưng theo kinh nghiệm của tôi, nó chưa giỏi lắm trong việc đó và nó không thể tạo ra một front-end đẹp trong một cơ sở mã trưởng thành. Nó có thể tạo ra một cái gì đó. Nhưng điều nó có thể làm là bạn nói, được rồi, tôi muốn một số ý tưởng về giao diện front-end này có thể trông như thế nào. Hãy cho tôi ba prototype mà tôi có thể nhấp qua lại trong một route dùng một lần mà tôi có thể quyết định cái nào trông đẹp nhất. Và bạn lấy tài sản của prototype đó và sau đó đưa nó trở lại phiên grilling hoặc bạn nhận được phản hồi về nó. Prototype chỉ là, bạn biết đấy, nó lộn xộn. Nó được cho là cung cấp cho bạn phản hồi sớm trong quá trình. Vì vậy, đó là một cách tuyệt vời để làm việc với mã front-end, một cách tuyệt vời để xem xét kiến trúc phần mềm nói chung.

Tuân thủ kiến trúc và AI QA

Câu hỏi: Làm thế nào để tuân thủ kiến trúc hiện có? Làm thế nào để làm cho nó tuân thủ các tiêu chuẩn mã của cơ sở mã của bạn?

Trả lời: Tôi sẽ trả lời điều đó sau. Hy vọng chúng ta đã bắt đầu có một số thứ đang hoạt động. Nó chỉ đang trong giai đoạn explore (khám phá) ở đây. Nó đang khám phá repo, sau đó sẽ bắt đầu triển khai dựa trên những gì chúng ta muốn.

Câu hỏi: Tại sao bạn không để AI làm QA? Tại sao bạn không để AI kiểm tra mã của chính nó?

Trả lời: Tất nhiên, bạn hoàn toàn có thể. Và tôi nghĩ trong khi nó đang hoạt động ở đây, được rồi, nó đã có một bức tranh rõ ràng về cơ sở mã. Nó đang đánh giá các issue. Nó đang thực hiện issue O2 là task tiếp theo. Tôi sẽ cho bạn thấy điều đó sau. Tôi nghĩ rằng, bởi vì bạn chắc chắn nên thực hiện một bước review tự động như một phần của việc triển khai. Vì vậy, bạn có phần triển khai của mình. Sau đó, bạn nên, bởi vì token khá rẻ và AI thực sự rất giỏi trong việc review mọi thứ. Bạn nên để nó review mã của chính nó trước khi bạn QA nó. Tôi thấy rằng điều đó bắt được rất nhiều lỗi khác nhau. Và cách đó hoạt động, nếu bạn có một triển khai đã sử dụng một loạt token trong vùng thông minh (smart zone), nếu bạn yêu cầu nó cố gắng review, nó sẽ thực hiện review trong vùng ngớ ngẩn (dumb zone). Và vì vậy người review sẽ "ngớ ngẩn" hơn thứ thực sự đã triển khai nó. Nếu chúng ta hình dung đây là, hãy nhất quán, đó là review, đó là triển khai. Trong khi đó, nếu bạn xóa ngữ cảnh, thì về cơ bản bạn sẽ có thể chỉ review trong vùng thông minh, đó là nơi bạn muốn.

Hãy xem việc triển khai của chúng ta đang diễn ra như thế nào. Tốt. Nó đang tạo ra một migration. Điều đó trông khá đẹp. Chúng ta đang có một số mã được xuất ra.

TDD (Test-Driven Development) với tác nhân

Tôi thấy TDD là hoàn toàn cần thiết để khai thác tối đa các agent.

Phát triển hướng kiểm thử (TDD)

TDD là phát triển hướng kiểm thử (test-driven development). Về cơ bản, nó thực hiện một quy trình gọi là red-green-refactor. Nếu bạn xem trong codebase, bạn sẽ tìm thấy một skill thực sự mô tả cách thực hiện red-green-refactor và dạy cho AI cách làm điều đó. Vậy nên, điều nó đang làm là viết một test thất bại trước. Nó nói, "Được rồi, tôi đã phân tích ý tưởng về những gì tôi đang làm. Và tôi sẽ viết một test duy nhất bị thất bại, sau đó tôi cần làm cho implementation vượt qua test đó."

Tôi nhận thấy rằng, trước hết, điều này thêm các test vào codebase. Và nó có xu hướng thêm các test tốt vào codebase. Chúng ta có một loại gamification service này. Có vẻ như nó đang sử dụng một số thứ có sẵn để tạo một test database. Test thất bại vì module chưa tồn tại. Được rồi, chúng ta đã xác nhận trạng thái red. Và sau đó, nó chạy và, hy vọng, nó vượt qua.

Hãy giơ tay nếu bạn đã từng có AI viết test tệ. Đúng vậy. Nó có xu hướng cố gắng "gian lận" trong các test vì nó thực hiện theo từng lớp. Nó sẽ thực hiện toàn bộ implementation và sau đó sẽ thực hiện toàn bộ test layer ngay bên dưới. Tôi chỉ muốn nói, vâng, bạn được phép sử dụng NPXB text. Và sử dụng kỹ thuật này, nhìn chung sẽ khó gian lận hơn nhiều vì nó giống như đang instrumenting (theo dõi/kiểm soát) code trước khi viết code.

Vì vậy, tôi thấy rằng TDD cực kỳ tốt cho những nơi bạn có thể áp dụng nó. Và thực tế, nó tốt đến mức tôi gần như điều chỉnh toàn bộ kỹ thuật của mình xung quanh việc làm cho TDD hoạt động hiệu quả hơn.

Tôi thấy một vài ánh mắt đang cụp xuống. Trời nóng quá. Bạn không thể tưởng tượng được trên này nóng thế nào đâu. Chúng ta hãy nghỉ giải lao năm phút nữa nhé. Tôi nghĩ chúng ta sẽ quay lại lúc kém mười lăm. Tôi có một quãng nghỉ khá thoải mái. Và chúng ta sẽ trở lại sau khoảng sáu, bảy phút. Sau đó, tôi sẽ nói về cách tôi suy nghĩ về modules, suy nghĩ về việc xây dựng một codebase để làm cho điều này khả thi.

Vòng lặp phản hồi và tầm quan trọng đối với AI

Tôi vừa thử nghiệm với AI ở đây và chúng ta đã có một commit. Vì vậy, chúng ta có thứ để kiểm thử. Vấn đề số hai đã hoàn tất. Đây là những gì đã được thực hiện. Đây là hình ảnh khi một Ralph loop hoàn thành, bạn sẽ có một bản tóm tắt nhỏ. Và bây giờ chúng ta có thứ để QA (đảm bảo chất lượng) bởi vì chúng ta đã thực hiện các feedback loops, bởi vì chúng ta đã thực hiện traceable (khả năng truy vết), đó là bởi vì chúng ta đã nói, "được rồi, hãy cung cấp cho chúng tôi thứ gì đó có thể review (đánh giá) được vào cuối quá trình này", chúng ta có thể ngay lập tức đi và QA nó.

Giờ đây, không có gì kém thú vị hơn việc xem người khác QA một thứ gì đó. Nhưng hy vọng chúng ta có thể thử một chút. Hãy kiểm tra xem nó có hoạt động không. Thực ra, trước khi đi sâu vào đó, tôi muốn xem xét những gì vừa xảy ra, đó là, chúng ta thấy nó đã tạo ra một số thứ trên dashboard. Và sau đó nó đã chạy các feedback loops. Vì vậy, nó đã chạy các test và types.

Rõ ràng, TDD thực sự quan trọng. Và nó thực sự quan trọng vì các feedback loops này là cần thiết cho AI. Điều cần thiết là để AI tạo ra bất kỳ thứ gì hợp lý. Bởi vì nếu không có điều này, AI hoàn toàn coding blind (lập trình mù quáng), phải không? Nếu codebase của bạn không có feedback loops, bạn sẽ không bao giờ, bao giờ, bao giờ nhận được output AI tử tế từ AI. Và thường thì bạn sẽ thấy rằng chất lượng của feedback loops của bạn ảnh hưởng đến việc AI của bạn có thể viết code tốt đến mức nào. Về cơ bản, đó là giới hạn. Vì vậy, nếu bạn nhận được output kém từ AI của mình, bạn thường cần nâng cao chất lượng của feedback loops. Chúng ta sẽ nói về cách làm điều đó trong một phút nữa.

Vậy nên, nó đã chạy npm run test, npm run type check. Nó nhận được một lỗi type error, và nó cần sửa lỗi đó bằng một chút TypeScript magic thú vị. Rất tốt. Đúng vậy, type của level thresholds number. Được rồi. Bạn thấy tại sao tôi ngừng dạy TypeScript rồi chứ, vì giờ AI biết mọi thứ. Vì vậy, nó đã chạy các test, và nó đã vượt qua, và trông rất ổn. Vậy là chúng ta có 284 test trong repo này. Khá tốt. Tôi thấy front-end thực sự khó test ở đây, nơi về cơ bản chỉ test service. Vì vậy, chúng ta đã tạo ra một gamification service, nếu chúng ta nhìn lên đây, và sau đó chúng ta có một test cho service đó. Bạn có thể thấy service và chính test đó. Bây giờ, nếu tôi đang thực hiện code review ở đây, tôi sẽ đi đến, tôi sẽ kiểm tra các test trước, đảm bảo rằng các test đang kiểm tra những điều hợp lý, và sau đó mới xem xét code đó để đảm bảo rằng nó không làm điều gì quá điên rồ.

Đảm bảo chất lượng (QA) thủ công và "Gu" cá nhân

Điều cốt yếu là tôi cần thực sự xem dashboard. Tôi sẽ đăng nhập với tư cách là một sinh viên. Ồ, nếu nó cho phép tôi, có lẽ nó sẽ không cho phép tôi. Nào con, đây rồi. Vậy thì đăng nhập với tư cách Emma Wilson, vào các khóa học. Vậy là tôi có "Introduction to TypeScript", tiếp tục học. Vâng, tôi đã hoàn thành bài học này. Có gì đó không ổn. Tôi đoán là do tôi không có lỗi SQLite, tôi không có table (bảng) chính xác. Vì vậy, tôi cần một table point events. Point events là một tên table lạ. Tôi không chắc nó đang nghĩ gì ở đó. Hãy tạm dừng. Hãy chạy npm db migrate push. Tôi nghĩ, ừm, tôi muốn cái nào, nhưng bạn hiểu ý rồi chứ? Tôi sẽ không bắt bạn xem tôi làm QA vì nó rất nhàm chán.

Nhưng tại thời điểm này, về cơ bản tôi sẽ quay lại. Tôi sẽ, hãy để tôi mở lại dự án. Và tôi sẽ, đây là một khoảnh khắc quan trọng. Và việc QA thủ công ở đây rất quan trọng bởi vì QA, ôi chao, có gì sai vậy? Đây rồi. QA là cách tôi áp đặt ý kiến của mình trở lại codebase, cách tôi áp đặt taste (gu thẩm mỹ) của mình. Điều bạn thường thấy là có những nhóm đang cố gắng automate (tự động hóa) mọi thứ, giống như mọi phần của quy trình này. Và họ sẽ có xu hướng, nếu bạn cố gắng automate việc tạo ý tưởng, automate QA, automate nghiên cứu, automate prototype (nguyên mẫu), bạn sẽ tạo ra những ứng dụng mà tôi cảm thấy thiếu taste và tệ. Có thể chúng chỉ không hoạt động hoặc không hoạt động như mong đợi. Hoặc chỉ là không có, bạn cần một human touch (chạm của con người) khi xây dựng những thứ này bởi vì nếu không có nó, bạn sẽ chỉ tạo ra slop (sản phẩm cẩu thả). Và chúng ta không tạo ra slop ở đây. Chúng ta đang cố gắng tạo ra những thứ chất lượng cao. Và đó là lý do QA tồn tại.

Cải thiện chất lượng Codebase: Module sâu và Module nông

Vì vậy, tôi sẽ làm hai điều trong phần cuối cùng này: thứ nhất, tôi sẽ cho bạn biết cách, có lẽ có một câu hỏi trong đầu bạn ở đây, đó là, giả sử tôi có một codebase mà tôi đang làm việc. Và đó là một codebase tệ. Đó là một codebase thực sự phức tạp. AI chỉ không bao giờ làm việc tốt trong đó và có lẽ hầu hết con người khi tham gia codebase đó cũng không làm việc tốt. Làm thế nào để tôi cải thiện codebase đó? Và điều thứ hai là tôi sẽ cho bạn xem thiết lập của tôi cho parallelization (song song hóa).

Vậy thì hãy bắt đầu với code tệ trước. Giờ đâu rồi? Biểu đồ đâu? Đây rồi. Trong cuốn sách The Philosophy of Software Design, John Ousterhout nói về loại module lý tưởng. Và hãy tưởng tượng rằng bạn có một codebase trông như thế này. Mỗi khối ở đây là các file riêng lẻ. Và các file này export (xuất) những thứ từ chúng. Bạn biết đấy, chúng có những thứ mà bạn lấy từ các file đó để sau đó sử dụng trong những thứ khác. Và vì vậy bạn có thể có những dependencies (phụ thuộc) kỳ lạ, nơi file này ở đây có thể dựa vào file kia, hoặc có thể dựa vào file đó, chẳng hạn.

Giờ đây, nếu các file này nhỏ và chúng không export nhiều thứ, thì John Ousterhout gọi đây là shallow modules (module nông), về cơ bản là chúng không quá, chúng trông giống như thế này. Nếu tôi thực sự biết, tôi không thể nghĩ ra một diagram tốt. Về cơ bản có rất nhiều chunks (khối nhỏ) nhỏ. Giờ đây, điều này khó để AI điều hướng, bởi vì nó không thực sự hiểu các dependencies giữa mọi thứ. Nó không thể tìm ra mọi thứ ở đâu. Bạn biết đấy, nó phải tự mình theo dõi toàn bộ graph (biểu đồ phụ thuộc) và nói, "được rồi, cái này phụ thuộc vào cái này. Cái này phụ thuộc vào cái này. Cái này phụ thuộc vào cái này."

Và sau đó, cũng khó để test điều này, bởi vì bạn vẽ test boundaries (ranh giới kiểm thử) ở đâu đây? Bạn có test từng module riêng lẻ không? Giống như chỉ cần vẽ một test boundary? Không, đừng làm vậy. Xung quanh cái này. Và sau đó có thể một test boundary khác xung quanh cái tiếp theo. Và sau đó cái tiếp theo. Hay bạn nên làm việc theo nhóm lớn? Bạn nên nói, "được rồi, chúng ta sẽ test tất cả các modules liên quan này cùng nhau, và chỉ kiểu, bạn biết đấy, hy vọng và cầu nguyện rằng chúng hoạt động."

Điều này có nghĩa là nếu tôi nghĩ rằng các test tệ hầu hết trông như vậy, nơi AI về cơ bản cố gắng gói gọn mọi function nhỏ trong test boundary riêng của nó, và sau đó chỉ test từng cái một cách riêng lẻ. Nhưng điều đó làm là nó có nghĩa là khi, giả sử, module này ở đây gọi hai module kia, vì vậy nó phụ thuộc vào cả hai, thì module này có thể sắp xếp sai thứ tự các function, hoặc có thể có những thứ bên trong module kém chất lượng đó đáng để test riêng. Và nếu sau đó bạn gói gọn cái này trong một test boundary, bạn làm gì? Bạn có mock (giả lập) hai module kia không? Điều đó hoạt động thế nào? Vì vậy, việc thực sự tìm ra cách xây dựng một codebase dễ test là điều cần thiết ở đây. Bởi vì codebase của chúng ta dễ test, thì feedback loops của chúng ta sẽ tốt hơn, và AI sẽ làm việc tốt hơn trong codebase của chúng ta. Điều đó có hợp lý không?

Vậy một codebase tốt trông như thế nào? Chà, không phải như vậy. Nó trông như thế này. Nơi bạn có cái mà John Ousterhout gọi là deep modules (module sâu). Các module có một interface nhỏ ở đó, expose (lộ ra) một interface nhỏ, đơn giản mà có rất nhiều functionality (chức năng) bên trong chúng. Giờ đây, điều này có nghĩa là chúng dễ test, bởi vì bạn chỉ cần, giả sử có một dependency giữa cái này và cái kia. Mũi tên của tôi hoạt động, vâng, đây rồi. Vậy thì bạn chỉ cần gói một test boundary lớn xung quanh module đó, xung quanh cái này ở trên, và bạn sẽ bắt được rất nhiều thứ tốt vì có rất nhiều functionality mà bạn đang testing, và thực sự caller (người gọi), người gọi module, sẽ có một interface đơn giản để làm việc. Vì vậy, nó không quá phức tạp. Điều đó có lý. Deep modules so với shallow modules. Điều này tốt. Phiên bản shallow này tệ. Và điều tôi nhận thấy là nếu không được hỗ trợ, hoặc nếu bạn không theo dõi AI cẩn thận, nó sẽ tạo ra một codebase trông như thế này. Vì vậy, bạn cần phải thực sự, thực sự cẩn thận khi điều hướng nó.

Chỉ đạo AI xây dựng cấu trúc Codebase

Và đó cũng là lý do tại sao, nếu chúng ta nhìn vào trong PRD (Product Requirements Document), PRD ở đâu? Nó nằm trong các issues. Nó nằm trong gamification system. Không tìm thấy. Tất nhiên là không rồi. Sau đó tôi có ở đây, data model (mô hình dữ liệu) các modules. Vì vậy, nó đặc biệt nói, "được rồi, gamification service này là một deep module (module sâu) mới, mà chúng ta sẽ test xung quanh nó. Nó sẽ có interface (giao diện) cụ thể này. Và nó sẽ có, được rồi, chúng ta cũng đang sửa đổi progress service. Chúng ta đang sửa đổi lesson room, sửa đổi dashboard routes, v.v." Vì vậy, tôi đang rất cụ thể về các modules mà tôi đang chỉnh sửa. Và tôi đảm bảo rằng tôi giữ module map (sơ đồ module) đó trong đầu mình mọi lúc trong suốt quá trình lập kế hoạch và sau đó trong suốt quá trình implementation. Điều đó có hợp lý không?

Giữ vững kiểm soát và sự hiểu biết Codebase

Nó cũng hữu ích vì một lý do khác. Không chỉ nó làm cho AI của bạn dễ test hơn, mà bạn còn thực hiện một mẹo nhỏ trong tâm trí. Để tôi hỏi các bạn một câu hỏi. Vậy, hãy giơ tay nếu bạn cảm thấy mình đang làm việc vất vả hơn bao giờ hết với AI. Đúng vậy. Hãy giơ tay nếu bạn cảm thấy mình hiểu codebase của mình kém hơn trước đây. Đúng vậy. Đây là một điều có thật. Bởi vì chúng ta đang di chuyển nhanh, bởi vì chúng ta đang ủy quyền nhiều thứ hơn, chúng ta cuối cùng mất đi cảm giác về codebase của mình. Và nếu chúng ta mất đi cảm giác về codebase của mình, chúng ta sẽ không thể cải thiện nó. Và chúng ta về cơ bản đang ủy quyền hình dạng của nó cho AI. Tôi không nghĩ điều đó tốt. Nhưng làm thế nào để chúng ta có thể di chuyển nhanh trong khi vẫn giữ đủ không gian trong bộ não của mình? Tôi nghĩ đây là một cách để làm điều đó. Bởi vì điều bạn đang làm ở đây không chỉ là bạn đang nghĩ về việc tạo ra các hình dạng lớn trong codebase của mình, các services lớn. Điều tôi nghĩ bạn nên làm là thiết kế interface (giao diện) cho các modules này nhưng sau đó ủy quyền implementation (triển khai) cho AI.

Ủy Quyền Triển Khai Module và Lợi Ích

Nói cách khác, các module này có thể trở thành những gray boxes (hộp xám), nơi bạn chỉ cần biết hình dạng của chúng, biết chúng làm gì và cách chúng hoạt động, nhưng bạn có thể ủy quyền việc triển khai các module đó. Tôi thấy điều này thực sự rất hay. Tôi không nhất thiết phải cùng review mọi thứ bên trong module đó. Tôi không nhất thiết phải biết mọi thứ hoặc những gì nó đang làm. Tôi chỉ cần biết rằng nó hoạt động theo một cách nhất định trong những điều kiện nhất định và hoàn thành công việc của nó. Vì vậy, nó giống như: "Được rồi, tôi có một cái nhìn tổng quan lớn về code base của mình và tôi hiểu các hình dạng bên trong nó, hiểu tất cả các interface làm gì, nhưng tôi có thể ủy quyền những gì bên trong." Tôi thấy đó là một cách rất tốt để duy trì cảm giác về code base trong khi vẫn giữ được sự tỉnh táo của mình. Điều đó có lý.

Skill: Cải Thiện Kiến Trúc Codebase

Vậy bạn có thể hỏi làm thế nào để tôi biến một code base trông như thế này thành một code base trông như thế này? Làm thế nào để tôi làm sâu sắc các module? Chà, chúng ta có một skill (kỹ năng) - hy vọng nó ở đây, tôi khá chắc là vậy - chúng ta có một skill. Và skill đó được gọi là "cải thiện kiến trúc code base" (improve code base architecture). Rất trực tiếp và rõ ràng. Hãy chạy nó. Skill này sẽ thực hiện một bản quét code base của chúng ta và tìm kiếm những gì có sẵn ở đây. Bạn cứ thoải mái chạy nó nếu đang thực hiện các bài tập. Và nó sẽ khám phá kiến trúc, khám phá cách làm việc trong code base này và nó sẽ cố gắng tìm những nơi để làm sâu sắc các module. Khá đơn giản.

Ví Dụ Cải Thiện Kiến Trúc: Trình Chỉnh Sửa Video

Một điều thực sự thú vị mà nó tìm thấy ở đây là một phần của ứng dụng quản lý video khóa học của tôi là một trình chỉnh sửa video. Một trình chỉnh sửa video được xây dựng trên trình duyệt, điều này thực sự "hardcore". Đó là một phần kỹ thuật khá tốt. Và tôi muốn có một cách để gói gọn toàn bộ front-end cho đến back-end vào một module lớn duy nhất để tôi có thể kiểm tra thực tế rằng tôi nhấn một thứ gì đó trên front-end và nó đi thẳng đến back-end. Và vì vậy, tôi đã tìm ra một cách cơ bản bằng cách sử dụng một loại discriminated union giữa hai loại ở đây. Bằng cách nào đó, tôi đã có thể sử dụng skill này để có một module lớn, khổng lồ chỉ kiểm tra từ bên ngoài hoặc có thể kiểm tra từ bên ngoài cấu trúc trình chỉnh sửa video này. Và điều đó có nghĩa là AI có thể nhìn thấy toàn bộ luồng, có thể hành động trên toàn bộ luồng và kiểm tra trên toàn bộ luồng. Và thành thật mà nói, đó thực sự là một sự khác biệt lớn về khả năng của AI trong việc thực hiện các thay đổi, bởi vì AI làm việc trên một trình chỉnh sửa video là khá "brutal" nếu bạn không cung cấp cho nó các test tốt. Vì vậy, nếu bạn chỉ mang một điều từ hôm nay, thì đó là: hãy thử chạy skill này trên repo của bạn và xem điều gì xảy ra.

Câu Hỏi & Trả Lời

Sử dụng Claude's Auto Mode

Hãy đến slider, hãy hỏi một vài câu hỏi nữa. Cái này đang chạy. Vậy thì, bạn đã thử auto mode của Claude với Claude enable auto mode chưa? Bằng cách đó, bạn có thể tránh nhiều kiểm tra quyền rõ ràng. Chúng ta sẽ nói về kiểm tra quyền trong giây lát.

Lưu Trữ Kế Hoạch Markdown và Issues (DocRot)

Tôi có nên giữ các kế hoạch và issues dưới dạng markdown để tham khảo sau này không? Được rồi, đây là một câu hỏi tuyệt vời. Vậy giả sử bạn có một ý tưởng tuyệt vời, bạn biến nó thành một PRD (Product Requirement Document), sau đó bạn triển khai PRD đó và PRD về cơ bản đã hoàn thành. Hãy giơ tay nếu bạn giữ thông tin đó trong repo. Vì vậy, bạn biến nó thành một tệp markdown, hãy giơ tay nếu bạn muốn giữ nó lại. Tuyệt vời, được chứ? Và giơ tay nếu bạn không muốn giữ nó lại, nếu bạn muốn loại bỏ nó càng sớm càng tốt. Vâng, tôi nghĩ đây là một câu hỏi không có câu trả lời rõ ràng. Điều tôi thực sự sợ hãi với bất kỳ quyết định tài liệu nào là giả sử chúng ta có một PRD cho hệ thống gamification này, chúng ta giữ nó trong repo. Chúng ta tiếp tục, tiếp tục, tiếp tục, giả sử một tháng sau, chúng ta muốn chỉnh sửa một số thứ cho hệ thống gamification và chúng ta dùng Claude và nó tìm thấy PRD cũ này và nói: "Vâng, tôi đã tìm thấy tài liệu gốc cho hệ thống PRD." Chà, hóa ra code thực tế đã thay đổi quá nhiều so với PRD gốc đến nỗi gần như không thể nhận ra - tên của mọi thứ đã thay đổi, cấu trúc tệp đã thay đổi, thậm chí các yêu cầu có thể đã thay đổi, chúng ta thậm chí có thể đã kiểm thử nó với người dùng. Đây là DocRot, nơi tài liệu cho một thứ gì đó đang mục rữa trong repo của bạn và ảnh hưởng xấu đến Claude hoặc các agent của Claude. Vì vậy, tôi có xu hướng không giữ nó lại. Tôi có xu hướng loại bỏ nó, và đối với tôi, vì thiết lập của tôi sử dụng GitHub issues, tôi chỉ đánh dấu nó là đã đóng. Nó có thể tìm nạp nếu muốn, nhưng nó có một chỉ báo trực quan rằng nó đã hoàn thành. Vì vậy, tôi có xu hướng thích loại bỏ những thứ này.

Khung BEADS của Steve

Suy nghĩ về khung BEADS của Steve: tôi chưa thử nghiệm nó nhưng nó có vẻ giống như một cách khác để quản lý các kanban boards và issues, có vẻ rất tốt nhưng tôi chưa thử.

Database Migrations

Để tôi kiểm tra nhanh thiết lập ở đây. Hãy lấy một vài câu hỏi từ khán phòng. Có ai có bất kỳ câu hỏi nào tại thời điểm này về bất cứ điều gì chúng ta đã đề cập cho đến nay, đặc biệt là phần cuối này không? Vâng. Giống như database migrations (di chuyển cơ sở dữ liệu)? Tôi không biết. Tôi hy vọng điều đó trả lời câu hỏi của bạn. Tôi xin lỗi. Không, không, tôi nghĩ database migrations là một điều khác vì bạn có một bản ghi đang chạy chính xác những gì đã thay đổi và nó mang tính xác định hơn. Và tôi nghĩ, vâng, đó là một sự tương tự thú vị. Tôi không chắc. Hãy nói về nó sau. Đó là một cách hay để nói tôi không có ý tưởng. Vâng, vâng. Xin lỗi các bạn. Tôi chỉ đang cố gắng lắng nghe câu hỏi của anh chàng này.

Tối Ưu Hóa Kế Hoạch Sớm

Vâng, câu hỏi ở đây là, liệu tôi có nên cố gắng tối ưu hóa kế hoạch ở giai đoạn lập kế hoạch ban đầu không? Đây là điều tôi thực sự thấy nhiều người làm và đó là một ý tưởng thực sự hay. Vậy khi bạn - hãy quay lại các giai đoạn. Giả sử bạn có tất cả các giai đoạn này ở đây và bạn đến điểm mà bạn đã tìm ra mọi thứ với LLM (mô hình ngôn ngữ lớn), bạn hiểu mình đang đi đâu, bạn đã tạo ra tài liệu điểm đến hành trình này ở đây. Vậy bạn có nên cố gắng tối ưu hóa, tối ưu hóa và tối ưu hóa PRD đó cho đến khi nó là PRD hoàn hảo nhất mà bạn có thể tưởng tượng không? Tôi không nghĩ có nhiều giá trị trong việc đó vì tôi nghĩ hành trình thực sự chỉ là một gợi ý về nơi bạn muốn đến và nơi bạn cần đặt công việc là ở QA (đảm bảo chất lượng). Và bạn có thể làm điều đó AFK (away from keyboard), tôi cho là vậy, nhưng theo kinh nghiệm của tôi, bạn sẽ không nhận được nhiều giá trị từ nó. Điều thực sự quan trọng là đạt được sự đồng thuận với AI, điều mà bạn làm trong phiên "grilling" ban đầu.

Thực Thi Tiêu Chuẩn Code trên Agent (Push và Pull)

Hãy có thêm một câu hỏi nữa. Tôi sẽ tiếp tục. Vâng, vâng. Chúng ta đã có câu hỏi này trước đây rồi, đó là làm thế nào để bạn thực thi các tiêu chuẩn code của mình trên các agent? Làm thế nào để bạn khiến nó code theo cách bạn muốn? Hiện có hai cách khác nhau để làm điều đó. Bạn có push (đẩy) và bạn có pull (kéo). Push và pull nghĩa là gì? Push là khi bạn đẩy hướng dẫn đến LLM. Vì vậy, bạn nói: "Được rồi, nếu bạn đặt một thứ gì đó vào CLAUDE.md, hãy nói như một tên cướp biển," hướng dẫn đó sẽ luôn được gửi đến các agent. Vậy đó là một push, bạn đang đẩy tokens đến nó. Pull là khi bạn cho agent cơ hội để lấy thêm thông tin. Và đó là, ví dụ, các skills. Vì vậy, một skill là thứ có thể nằm trong repo và có một tiêu đề mô tả nhỏ nói: "Được rồi, agent, bạn có thể lấy cái này khi bạn muốn." Suy nghĩ hiện tại của tôi về code review và về các tiêu chuẩn code như sau: Khi bạn có một implementer (người triển khai), điều gì đang xảy ra? Đó rồi, implementer. Tôi sẽ làm cho cái này dễ đọc hơn trong giây lát. Thì bạn muốn các tiêu chuẩn code có sẵn thông qua pull. Nếu nó có một câu hỏi, bạn muốn nó có thể tự trả lời. Nhưng nếu sau đó bạn có một reviewer (người đánh giá) tự động, thì bạn muốn nó push. Bạn muốn đẩy thông tin đó đến reviewer. Bạn muốn nói: "Đây là các tiêu chuẩn code của chúng ta. Hãy đảm bảo rằng code này tuân thủ chúng." Vì vậy, nếu bạn có các skills, ví dụ, thì bạn muốn đẩy những thứ đó đến reviewer để reviewer có cả code được viết và các tiêu chuẩn code để so sánh. Hy vọng điều đó trả lời câu hỏi của bạn. Tôi cũng có thể cho bạn thấy một phiên bản tự động của điều này. Hãy làm điều đó ngay bây giờ, khi nó vẫn còn mới trong tâm trí tôi.

Giới Thiệu Sandcastle: Song Song Hóa Agent Loops

Gần đây tôi đã dành khoảng một tuần để xây dựng thứ gọi là Sandcastle. Sandcastle là một... tôi không hài lòng với các tùy chọn có sẵn để chạy agent AFK. Cái này về cơ bản là một thư viện TypeScript để chạy các vòng lặp này. Vì vậy, bạn có một hàm run tạo ra một work tree, sandbox nó trong một Docker container, và sau đó cho phép bạn chạy một prompt bên trong đó. Và trong work tree đó, nó chỉ là một git branch, và bạn có code đó, và bạn có thể merge nó sau này. Nếu tôi mở ra, có một số cách thực sự, thực sự hay để xem cái này, và về cơ bản nó cho phép bạn chạy các loại vòng lặp tự động này và cho phép bạn song song hóa trên nhiều agent khác nhau, thực sự đơn giản. Vì vậy, tôi sẽ vào tệp sandcastle của mình, vào main.ts ở đây, và chúng ta hãy cùng xem qua. Vì vậy, đây giống như, tôi đã cho bạn thấy một phiên bản của Ralph loop trước đó. Đây là nơi chúng ta chuyển từ tuần tự sang song song. Đầu tiên, chúng ta có một planner (người lập kế hoạch) nhận vào, nó có một plan prompt (lời nhắc kế hoạch) ở đây nhìn vào backlog và chọn một số issues để làm việc song song. Bạn còn nhớ kanban board mà tôi đã cho bạn xem, nơi nó có tất cả các mối quan hệ chặn không? Nó giải quyết tất cả các giai đoạn. Vì vậy, cái này sẽ nói: "Được rồi, giả sử chúng ta có..." bạn có thể bỏ qua tất cả glue code ở đây. Về cơ bản, đây chỉ là một tập hợp các issues, GitHub issues, với một tiêu đề và với một branch để bạn làm việc. Và sau đó, đối với mỗi issue, chúng ta tạo một sandbox, và sau đó chúng ta chạy một implementer (người triển khai) trong sandbox đó, truyền vào số issue, tiêu đề issue trong branch. Đây giống như vòng lặp mà chúng ta đã chạy ngay trước đó. Sau đó, nếu nó tạo ra một số commit, chúng ta sẽ review những commit đó. Đây về cơ bản là vòng lặp. Chúng ta làm gì với những commit đó? Chúng ta chuyển những commit đó cho một merger agent (agent hợp nhất), cái này nhận vào một merge prompt (lời nhắc hợp nhất), nhận vào các branch đã được tạo, nhận vào các issues và nó chỉ hợp nhất chúng lại. Nếu có bất kỳ issue nào với quá trình merge, ví dụ, với các loại và test và những thứ tương tự, nó sẽ giải quyết chúng. Và đây đã là quy trình làm việc của tôi trong một thời gian khá dài cho hầu hết các dự án. Nó hoạt động siêu, siêu tốt. Và tôi khuyên bạn nên xem Sandcastle nếu bạn muốn tìm hiểu thêm. Và để trả lời câu hỏi của bạn một cách đúng đắn là: trong reviewer, tôi sẽ push các tiêu chuẩn code; trong implementer, tôi sẽ cho phép nó pull. Và tôi thực sự đang sử dụng Sonnet cho triển khai và Opus cho review. Bởi vì tôi coi review là một loại, tôi cần sự thông minh ở đó.

Kết Quả Chạy Skill "Cải Thiện Kiến Trúc Codebase"

Chúng ta đang nói chuyện một cách khá nhanh vì tôi phải chạy nhiều thứ song song. Vì vậy, hãy quay lại skill cải thiện kiến trúc code base. Nó cuối cùng đã chạy xong và nó đã tìm thấy một loạt các ứng cử viên cải thiện kiến trúc. Vì vậy, về cơ bản nó đã có một cụm các module khác nhau, tất cả đều có liên quan với nhau mà có thể được kiểm thử như một đơn vị. Có số một, dịch vụ tính điểm câu đố (quiz scoring service). Ngoài ra còn có việc trích xuất logic sắp xếp lại. Nó cũng có các lập luận cho lý do tại sao chúng được ghép nối và nó cũng có một danh mục phụ thuộc. Vì vậy, có thể thay thế cục bộ trong SQLite trong test DB trong bộ nhớ. Dịch vụ tính điểm câu đố, hiện tại là không có test. Đây là khoảng trống lớn nhất. Vì vậy, đây là những gì nó trông như khi chúng ta quay lại từ việc cải thiện kiến trúc code base.

Tổng Kết

Được rồi. Vậy chúng ta còn khoảng 17 phút. Tôi không biết bạn thế nào, nhưng tôi khá mệt mỏi rồi. Tôi muốn, hãy để tôi tóm tắt lại cho bạn. Bởi vì tôi nghĩ chúng ta đang đi đến cuối sức bền của mình. Tôi sẽ có mặt trong suốt thời gian nếu bạn muốn đến và hỏi tôi câu hỏi. Tôi có thể kiểm tra lại slide một lần nữa. Nhưng hãy tóm tắt lại những gì chúng ta đã đạt được. Vì vậy, đây về cơ bản là luồng làm việc. Xuyên suốt quá trình này, chúng ta đều ghi nhớ hình dạng (shape) của code base của chúng ta. Đây không phải là một trình biên dịch spectacode. Đây không phải là một AI chỉ đơn thuần là tạo ra code.

Quy Trình Phát Triển và Đảm Bảo Chất Lượng

Chúng tôi rất chú trọng đến loại module và cấu trúc của code base mà chúng tôi mong muốn. Chúng tôi đảm bảo sự đồng bộ tối đa bằng cách sử dụng các buổi grilling session để trau chuốt ý tưởng của mình. Chúng tôi không quá phụ thuộc vào PRD (Product Requirements Document), không cố gắng đọc mọi phần hay suy nghĩ quá nhiều về nó. Thay vào đó, chúng tôi biến ý tưởng đó thành một tập hợp các vấn đề có thể song song hóa (parallelizable issues) để các agent có thể xử lý song song. Chúng tôi triển khai, thực hiện QA (Quality Assurance) và code review một cách triệt để, sau đó liên tục lặp lại và cải tiến phần triển khai.

Quản Lý Vấn Đề và Hợp Nhất

Một điều tôi chưa đề cập là trong giai đoạn QA, mục đích chính là tạo ra thêm các vấn đề cho Kanban board. Ngay cả khi đã triển khai, bạn vẫn có thể thực hiện QA, quay lại, thêm các vấn đề mới, và Kanban board cho phép bạn thêm các blocking issues một cách không giới hạn. Sau khi hoàn tất mọi thứ, khi bạn đã có code và công việc ưng ý, bạn có thể chia sẻ với nhóm của mình để nhận được review đầy đủ. Ở giai đoạn này, một hoặc vài nhà phát triển sẽ quản lý công việc, và việc hợp nhất (merge) nó trở lại là tùy thuộc vào bạn. Tất nhiên, tất cả những điều này đều có thể được bạn tùy chỉnh. Đây chỉ là một phương pháp mà tôi đã thử nghiệm và thấy hiệu quả. Tôi không cố gắng giới thiệu một cách tiếp cận cụ thể nào cho bạn.

Lời Khuyên và Tài Nguyên Tham Khảo

Điều tôi muốn khuyên nếu bạn rút ra một điều từ buổi này là hãy quay lại Amazon và mua thật nhiều những cuốn sách cũ đó, bởi vì tôi thấy việc đọc chúng thực sự khai sáng. Những tác phẩm viết trước thời AI luôn rất thú vị để đọc. Và tôi đã tìm thấy điều gì đó hữu ích, điều gì đó thú vị để đọc trên mỗi trang sách.

Lời Cảm Ơn

Cảm ơn rất nhiều. Cảm ơn vì đã chịu đựng cái nóng. Hy vọng nhiệt độ cơ thể bạn sẽ sớm trở lại bình thường. Xin cảm ơn rất nhiều.