5 skill Claude Code Matt Pocock dùng mỗi ngày

1. Process quan trọng hơn bao giờ hết, và repo skill của Matt

Matt Pocock mở đầu bằng một nhận xét từ kinh nghiệm của chính anh: anh đã làm kỹ sư gần mười năm, và trong suốt quãng thời gian đó, chưa lúc nào process (quy trình làm việc) quan trọng như bây giờ. Lý do là ngay trong tầm tay chúng ta giờ có cả một đội kỹ sư, chất lượng từ trung bình tới khá, có thể đưa vào làm việc bất cứ lúc nào. Nhưng điểm kỳ lạ của những "kỹ sư" này là họ không có trí nhớ: họ không nhớ những gì mình đã làm trước đó. Vì vậy, muốn các agent làm ra thứ gì thực sự hữu ích, bạn cần những process cực kỳ chặt chẽ và được định nghĩa rõ ràng.

Điều đó có nghĩa là bạn, với tư cách developer, phải liên tục tìm cách điều khiển (steer) agent của mình, giữ chúng đi đúng đường ray. Với Matt, việc này dẫn tới rất nhiều lần tự xây skill. Anh mở repo chứa tất cả các skill anh đang dùng ngay lúc này, mỗi skill đều do anh tự đi qua và thiết kế. Có những skill anh dùng khá hiếm, nhưng có những skill anh dùng mỗi ngày. Các skill này giúp anh mã hoá (encode) process của mình, để AI có một con đường thật chặt để đi theo, lần nào cũng như lần nào.

Kết quả của việc dùng tất cả những skill này, theo Matt, là chất lượng code mà AI tạo ra đã tăng vọt. Video có một đoạn giới thiệu khoá học trả phí Claude Code for Real Engineers của chính Matt (một cohort hai tuần). Sau đó anh đi vào danh sách năm skill, bắt đầu từ skill có lẽ là yêu thích nhất của anh.

2. Skill số 1: grill-me, chỉ ba câu

Skill đầu tiên là grill-me ("hãy tra hỏi tôi"). Matt nhấn mạnh: đúng vậy, skill này dài đúng ba câu. Anh đọc to toàn bộ nội dung để giải thích nó làm gì. Câu một: phỏng vấn tôi không ngừng nghỉ về mọi khía cạnh của plan này cho tới khi hai bên đạt được một sự hiểu chung (shared understanding). Câu hai: đi xuống từng nhánh của design tree, giải quyết các phụ thuộc giữa những quyết định, lần lượt từng cái một. Và câu cuối: nếu một câu hỏi có thể trả lời bằng cách khám phá codebase, thì hãy khám phá codebase thay vì hỏi.

Nội dung file như trên màn hình, bạn có thể chép lại để dùng:

---
name: grill-me
description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
---

Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.

If a question can be answered by exploring the codebase, explore the codebase instead.

Phần description cho thấy khi nào skill được gọi: khi người dùng muốn stress-test một plan, muốn bị "tra hỏi" về thiết kế của mình, hoặc khi họ nhắc tới đúng cụm "grill me". Câu cuối trong thân skill quan trọng vì nó tiết kiệm sức của bạn: agent không hỏi những gì nó có thể tự đọc từ code.

3. Design tree: đi hết từng nhánh trước khi viết code

Khái niệm design tree, theo Matt, đến từ cuốn sách The Design of Design của Frederick P. Brooks. Rồi anh tự đính chính ngay: thật ra anh không chắc khái niệm này có bắt nguồn từ cuốn sách đó không, chỉ là đó là nơi anh nhìn thấy nó lần đầu. Ý tưởng của design tree là: khi bạn tiến dần tới một thiết kế, bạn cần đi xuống tất cả các nhánh của cây quyết định.

Ví dụ của anh: bạn đang thiết kế một trang tìm kiếm, và phải quyết định muốn một trang advanced search (tìm kiếm nâng cao) hay chỉ một ô text box. Nếu chọn advanced search, bạn lại phải xác định toàn bộ các bộ lọc (filter) và tất cả các cách sắp xếp (sorting) mà advanced search cần. Và bạn cứ tiếp tục đi xuống cây như vậy cho tới khi hình dung được thiết kế một cách đầy đủ, hoặc đầy đủ nhất có thể, trước khi thực sự cam kết viết code.

Matt gọi grill-me khi anh muốn đạt tới sự hiểu chung với LLM. Anh nhận thấy gần đây Claude Code có xu hướng nhả ra một plan rất sớm khi anh vào plan mode: nó tạo luôn một tài liệu trước khi anh cảm thấy hai bên đã thật sự hiểu nhau. Skill grill-me ép cuộc trò chuyện đó phải diễn ra, ép LLM phỏng vấn anh về từng phần một.

4. grill-me trong một cuộc trò chuyện thật: 16 câu hỏi

Matt mở một cuộc trò chuyện gần đây với Claude về việc thêm một tính năng vào codebase của công cụ biên tập video khoá học của anh (course video editor). Anh đưa cho nó một ít research mà anh đã làm, nằm trong một file markdown, và nói: grill me, tôi muốn suy nghĩ về việc thêm thứ này vào trang viết bài (write page). Claude tải skill lên. Điều anh muốn khoe là số lượng câu hỏi nó đã hỏi.

Việc đầu tiên nó làm là khám phá các phần liên quan trong codebase, điều mà Matt thấy là tốt. Kéo xuống dưới, ta thấy câu hỏi một: tài liệu nằm ở đâu? Câu hai: bố cục UI thế nào? Câu ba: những mode nào có panel tài liệu? Câu bốn: vòng đời (lifecycle) của tài liệu. Câu năm: tool ghi tài liệu trông như thế nào? Câu sáu: hình dạng của edit tool. Rồi câu bảy, và cứ thế xuống tới câu chín, câu mười, mười một, mười hai, cho tới tận câu "freaking" mười sáu.

Và theo tiêu chuẩn của Matt, đây còn là một buổi "tra hỏi" tương đối ngắn. Anh từng có những buổi ngồi gần nửa tiếng, 45 phút với AI để trả lời câu hỏi về những tính năng thực sự phức tạp. Có thể là 30, 40, 50 câu hỏi, tất cả sinh ra từ một skill bé xíu. Đó là điều anh muốn người xem mang về: skill không cần dài mới có tác dụng. Bạn chỉ cần chọn đúng từ ngữ cho LLM vào đúng thời điểm. Riêng cụm "design tree, resolving dependencies" đã giúp anh rất nhiều. Anh cũng nói các skill này có link ở phần mô tả video.

5. Skill số 2: write-a-prd

Khi đã đạt sự hiểu chung với LLM, khi đã "tra hỏi" ý tưởng của mình và hiểu hết các hệ quả của nó, nếu Matt quyết định muốn implement thì anh gọi skill tiếp theo: write-a-prd, skill viết PRD (product requirements document, tài liệu yêu cầu sản phẩm). Anh đã làm đúng việc này trong cuộc trò chuyện vừa xem: Claude hỏi "có gì tôi bỏ sót hay hiểu sai không", và anh trả lời bằng lệnh viết PRD. Anh gõ lệnh có hậu tố "user" (trên màn hình là /write-a-prd-user) vì anh có vài skill cùng tên nằm sẵn trong project, nên phải phân biệt.

Skill nói rằng nó được gọi khi người dùng muốn tạo PRD, và agent được phép bỏ qua các bước nếu thấy không cần thiết. Ví dụ, trong cuộc trò chuyện trước, Claude nói "chúng ta đã phỏng vấn kỹ rồi, chuyển sang bước bốn". Các bước, như trên màn hình:

This skill will be invoked when the user wants to create a PRD. You may skip steps if you don't consider them necessary.

1. Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.

2. Explore the repo to verify their assertions and understand the current state of the codebase.

3. Interview the user relentlessly about every aspect of this plan until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.

4. Sketch out the major modules you will need to build or modify to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation.

Matt giải thích từng bước: bước một hỏi người dùng một mô tả dài, chi tiết; bước hai khám phá repo để kiểm chứng những gì họ khẳng định; bước ba về cơ bản là phỏng vấn không ngừng, tức một bản sao của skill grill-me. Bước bốn phác thảo các module chính cần xây hoặc sửa; anh sẽ quay lại bước này sau vì nó nối với những skill anh trình bày ở cuối video. Cuối cùng, khi đã hiểu trọn vẹn vấn đề và giải pháp, agent dùng template bên dưới để viết PRD, và PRD phải được nộp thành một GitHub issue.

6. PRD nằm trong GitHub issue: user stories và implementation decisions

Matt mô tả dev flow của anh: anh giữ các PRD trong GitHub, biến chúng thành nhiều GitHub issue khác có tham chiếu ngược về PRD cha, rồi có một Ralph loop (vòng lặp agent tự động) chạy lần lượt qua từng issue cho tới khi xong. Quay lại cuộc trò chuyện, ta thấy nó đã tạo ra PRD này, từ bốn ngày trước như trên màn hình.

Có phần Problem Statement: trang viết bài hiện tạo lại toàn bộ tài liệu ở mỗi lần tương tác với AI. Giải pháp là thêm một trải nghiệm chỉnh sửa tài liệu dạng split pane (chia đôi màn hình) vào article writer: phần chat ở bên trái, một panel tài liệu mới ở bên phải, "blah, blah, blah" như Matt nói. Đây là một tính năng lớn: thêm khả năng chỉnh sửa tài liệu vào một tính năng kiểu AI chat.

Phần quan trọng là user stories. Có rất, rất nhiều user story trong PRD này. Khái niệm này đến từ phương pháp Agile, và về cơ bản là cố gắng mô tả hành vi mong muốn của hệ thống bằng ngôn ngữ tự nhiên, việc không hề dễ. Matt thừa nhận anh vẫn chưa thật sự chốt được định dạng đúng cho chúng, đây chỉ là kiểu anh thích. Bạn hoàn toàn có thể dùng ngôn ngữ Cucumber hay bất cứ định dạng nào bạn đã quen làm việc.

Kéo xuống cuối, PRD có thêm vài implementation decisions (quyết định triển khai). Ở đây Matt không muốn quá cụ thể, vì anh muốn các quyết định này bền (durable): nếu code trở nên lệch so với PRD thì khi bắt tay implement sẽ gặp rắc rối. Nhưng bạn thấy được tinh thần: PRD là một mô tả rất tốt về đích đến (destination). Điều PRD không cho ta là hành trình (journey), tức con đường thật sự để đi tới đích đó.

7. Skill số 3: prd-to-issues và vertical slices

Quay lại cuộc trò chuyện, đây là chỗ Matt dùng skill tiếp theo: prd-to-issues. Nó nhận một PRD, tức đích đến, và biến nó thành một Kanban board gồm các issue khác nhau mà từng cái có thể được nhặt lên làm độc lập. Bước đầu tiên là tìm PRD: nếu PRD chưa có trong context window, lấy nó về bằng lệnh được chỉ định (trên màn hình là gh issue view <number> kèm comments). Sau đó khám phá codebase nếu cần. Rồi đến phần Matt reo lên "oh, oh, oh": soạn vertical slices.

Không phải lúc nào cũng rõ nên chia một PRD thành các task riêng như thế nào. Đây là việc developer đã làm từ "yonks" (tiếng lóng Anh, nghĩa là từ rất lâu rồi), và chúng ta đã có một trực giác cho việc này. Theo Matt, cách tốt nhất là chia thành các task làm lộ ra những "unknown unknowns" (những điều ta không biết là mình không biết) thật nhanh. Ví dụ, nếu bạn tích hợp với một dịch vụ mới, hoặc nối hai thứ chưa từng nối với nhau, thì nên làm phần đó trước, vì nó cho bạn phản hồi về việc hướng tiếp cận có khả thi hay không. Phép so sánh đúng ở đây là tracer bullet (đạn vạch đường).

Matt nói anh sẽ không đi sâu vào ý nghĩa của nó, nhưng về cơ bản mỗi issue là một lát cắt dọc mỏng (thin vertical slice) xuyên qua mọi tầng tích hợp, chứ không phải một lát cắt ngang của một tầng. Phần này của skill, như trên màn hình:

### 3. Draft vertical slices

Break the PRD into **tracer bullet** issues. Each issue is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer.

Slices may be 'HITL' or 'AFK'. HITL slices require human interaction, such as an architectural decision or a design review. AFK slices can be implemented and merged without human interaction. Prefer AFK over HITL where possible.

<vertical-slice-rules>
- Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI, tests)
- A completed slice is demoable or verifiable on its own
- Prefer many thin slices over few thick ones
</vertical-slice-rules>

8. Bốn slice và quan hệ blocking giữa các issue

Trong cuộc trò chuyện, skill chia cái PRD rất phức tạp kia thành vỏn vẹn bốn slice. Slice đầu tiên tạo ra một loại engine (bộ máy chỉnh sửa tài liệu) có kèm test. Matt cho rằng đây thực sự là một vertical slice khá tốt, vì chính engine này sẽ cấp năng lượng cho phần còn lại của hệ thống. Nếu vì lý do nào đó engine không chạy được hoặc không khả thi, ta cần phát hiện điều đó thật nhanh, và đó chính là việc cách chia này làm.

prd-to-issues cũng thiết lập quan hệ blocking (chặn) giữa các task. Ví dụ, slice số hai không bị chặn bởi gì cả, nên có thể được nhặt lên làm độc lập với số một (trên màn hình ghi "can start immediately (parallel with #1)"). Điều này rất có ích nếu bạn có một setup agent chạy song song, nơi bạn có thể phóng hai agent vào cùng lúc, chẳng hạn dưới dạng background task. Nó cũng có nghĩa là về sau bạn có thể thêm issue khác vào, như các issue QA bạn phát hiện hoặc những thứ cần cải thiện, rồi thiết lập quan hệ blocking giữa chúng và mọi issue còn lại.

Ta thấy số ba bị chặn bởi số một (editing engine), và số bốn, Monaco editor toggle, bị chặn bởi số hai. Matt đồng ý với tất cả, và Claude tạo ra toàn bộ các GitHub issue tương ứng.

9. Ralph loop làm từng issue, và nhìn lại ba skill đầu

Các issue này tham chiếu tới PRD cha, để agent chạy local có thể lấy về và đọc nó. Mỗi issue về cơ bản chia nhỏ việc cần xây, và quan trọng nhất, nó tham chiếu tới các user story trước đó trong PRD.

Ta thấy một comment, thực ra là của Claude Code, phiên bản đã implement issue này: "engine chỉnh sửa tài liệu dạng pure function với 28 test bao phủ tất cả acceptance criteria". Và ta có thể xem commit tham chiếu tới issue. Về cơ bản, Ralph loop của Matt đã đến, implement dựa trên issue, comment vào đó, đóng nó lại, và issue tiếp theo được mở chặn.

Matt tổng kết đến đây: skill grill-me giúp bạn làm rõ (flesh out) một ý tưởng. Skill write-a-prd giúp biến ý tưởng đó thành một tài liệu. Và skill prd-to-issues giúp biến tài liệu đích đến đó thành một hành trình thực sự. Nhưng rồi làm sao để thực thi? Làm sao để phần implementation thật vững chắc và nâng chất lượng code được tạo ra?

10. Skill số 4: tdd, bắt đầu từ interface

Câu trả lời là skill tdd. TDD là test driven development (phát triển hướng kiểm thử). Khi gọi skill này, nó về cơ bản ép agent, hay đúng hơn là khuyến khích agent, đi theo vòng red green refactor. Khác thường so với các skill của Matt, skill này chứa khá nhiều thứ: không chỉ bản thân skill mà còn các ý tưởng về refactoring, về mocking, về deep module là gì. Theo anh, làm TDD thật tốt là cách nhất quán nhất mà anh từng dùng để cải thiện output của agent.

Matt lướt qua phần philosophy ("tôi để các bạn tự đọc") để xem phần workflow. Mục đầu tiên ở đây rất quan trọng: xác nhận với người dùng những thay đổi interface nào là cần thiết.

### 1. Planning

Before writing any code:

- [ ] Confirm with user what interface changes are needed
- [ ] Confirm with user which behaviors to test (prioritize)
- [ ] Identify opportunities for [deep modules](deep-modules.md) (small interface, deep implementation)
- [ ] Design interfaces for [testability](interface-design.md)
- [ ] List the behaviors to test (not implementation steps)
- [ ] Get user approval on the plan

Ask: "What should the public interface look like? Which behaviors are most important to test?"

Matt vừa làm một video về interfaces và implementations, nhưng anh tóm tắt nhanh ý chính. Khi AI nhìn vào một codebase tệ, nó sẽ thấy một thứ giống như hình dưới: hàng loạt module nhỏ xíu không phân biệt được với nhau. Chúng không thực sự được gom nhóm. AI không hiểu các thứ này liên quan với nhau thế nào, nên phải tốn rất nhiều công để tìm ra: được rồi, cái gì chịu trách nhiệm cho việc gì? Các phụ thuộc là gì? Codebase này thậm chí vận hành ra sao?

Ngược lại, nếu bạn cấu trúc lại thành vài module lớn hơn với những interface mỏng ở trên, interface ở đây là các hàm thực sự được export ra, những thứ mà nơi gọi (caller) thực sự gọi, thì AI dễ điều hướng codebase hơn nhiều. Và cũng dễ tìm cách test các module này hơn nhiều, vì bạn chỉ cần test chúng ở interface, ở ranh giới của chúng. Video đầy đủ về chủ đề này có link ở dưới video gốc. Vì vậy điều skill tdd khuyến khích là đưa những thay đổi interface lên hàng đầu trong suy nghĩ của AI, để nó hiểu rằng khi thay đổi một interface, đó là một quyết định quan trọng cần dành thời gian cân nhắc.

Tiếp theo, agent xác nhận với người dùng những hành vi (behavior) nào cần test. Nó thiết kế interface sao cho dễ test, có link sang một tài liệu riêng. Rồi còn vài bước nữa về lập kế hoạch.

11. Vòng red green refactor, và vì sao TDD đòi hỏi codebase tốt

Sau đó skill đi vào một vòng lặp đẹp đẽ, trong đó agent viết từng test một, và viết test trước. Matt đã từng nói về red green refactor (có link video ở dưới cho ai quan tâm), nhưng anh thấy red green refactor với agent thật sự tuyệt vời. Agent cứ lặp vòng này cho tới khi xong: viết một test fail (đỏ), rồi viết code để test đó pass (xanh). Trên màn hình, phần "2. Tracer Bullet" của skill yêu cầu viết MỘT test xác nhận MỘT điều về hệ thống, và gọi đó là viên đạn vạch đường chứng minh con đường chạy được end-to-end; phần "3. Incremental Loop" lặp lại cặp RED/GREEN cho mỗi hành vi còn lại.

### 2. Tracer Bullet

Write ONE test that confirms ONE thing about the system:

RED:   Write test for first behavior → test fails
GREEN: Write minimal code to pass → test passes

This is your tracer bullet - proves the path works end-to-end.

### 3. Incremental Loop

For each remaining behavior:

RED:   Write next test → fails
GREEN: Minimal code to pass → passes

Cuối cùng, agent đi tìm các ứng viên refactor. Matt thừa nhận phần này anh chưa thấy hay. Nó chưa xuất sắc, vì LLM thường khá ngại refactor code của chính mình. Nếu bạn xoá context của LLM, nó sẽ như tự xoá trí nhớ và bớt "nâng niu" đoạn code vừa viết đi nhiều. Nhưng khi code của chính nó còn nằm trong context window, nó khá miễn cưỡng khi phải thay đổi. Skill tdd này chính là thứ Matt dùng để prompt các Ralph loop của mình, để chúng làm red green refactor.

Có điều TDD đòi hỏi bạn rất nhiều, hay đúng hơn là đòi hỏi codebase của bạn rất nhiều. TDD rất khó làm trong một codebase có cấu trúc tệ, vì ranh giới để test không rõ ràng. Nên test riêng từng module này? Hay riêng từng module kia? Ranh giới nằm ở đâu? Còn khi codebase trông giống hình vài module lớn ở trên thì test dễ hơn nhiều, vì ranh giới module rất rõ ràng. Vậy chẳng phải sẽ tuyệt sao nếu có một skill giúp codebase của bạn trông giống như vậy? "Chà, chẳng phải hay sao", Matt nói: anh có skill cải thiện kiến trúc codebase.

12. Skill số 5: improve-codebase-architecture

Skill thứ năm là improve-codebase-architecture. Process của nó bắt đầu bằng việc khám phá codebase, khám phá một cách tự nhiên như một agent vẫn làm. Mục tiêu là tìm ra những chỗ gây bối rối. Không phải tìm kiểu có chủ đích, mà là để lộ ra một cách tự nhiên những gì AI thấy khó hiểu, để sau đó có thể giúp nó.

Skill hỏi một loạt câu: ở đâu mà việc hiểu một khái niệm buộc phải nhảy qua lại giữa nhiều file nhỏ? Ở đâu các pure function được tách ra chỉ để dễ test, trong khi lỗi thật lại nấp ở cách chúng được gọi? Ở đâu các module gắn chặt với nhau (tightly coupled) tạo ra rủi ro tích hợp ở những đường nối (seam) giữa chúng? Theo Matt, đây đều là những câu một senior engineer sẽ hỏi về codebase của bạn.

Bước hai là trình bày các ứng viên: một danh sách đánh số các cơ hội "làm sâu" (deepening opportunities), nói cách khác là các cơ hội biến module nông (shallow module) trong codebase thành module sâu hơn (deep module).

13. Thiết kế nhiều interface bằng sub-agent, rồi tạo RFC

Người dùng chọn một ứng viên, và sau đó agent thiết kế nhiều interface. Skill yêu cầu spawn ba sub-agent chạy song song, mỗi sub-agent phải tạo ra một interface khác biệt hoàn toàn (radically different) cho module được làm sâu. Nói cách khác, ta đang tách đoạn code đó ra và thiết kế các hình dạng nó có thể có trong tương lai. Thiết kế theo nhiều cách khác nhau là một cách rất hay để sau đó chọn ra ý tưởng đúng. Matt từng thấy agent này spawn tới năm sub-agent khác nhau cho một đợt refactor thật sự lớn. Điều hay nhất, theo anh, là bạn không cần biết nhiều về thiết kế interface thì cách này vẫn chạy được.

Sau khi so sánh, agent đưa ra khuyến nghị của mình: thiết kế nào nó cho là mạnh nhất và vì sao. Nếu các yếu tố từ những thiết kế khác nhau kết hợp tốt với nhau, nó đề xuất một bản lai (hybrid). Trên màn hình skill còn dặn agent hãy có chính kiến, vì người dùng muốn một nhận định rõ ràng chứ không chỉ một menu lựa chọn.

Matt lưu ý anh đã làm skill này rất trung lập về ngôn ngữ (language agnostic), thật ra trung lập với gần như mọi thứ. Bạn có thể chạy nó trong bất kỳ codebase nào và nhận được một câu trả lời tử tế về cách cải thiện. Có thể có bốn, năm ứng viên thực sự cần chỉnh sửa, nhưng theo anh chỉ nên làm từng cái một, vì chúng khá khó nắm bắt và cần một con người trong vòng lặp (human in the loop) ngồi cùng để cải thiện codebase, bởi những quyết định này đòi hỏi gu (taste).

Cuối cùng, skill tạo một GitHub issue: một refactor RFC dưới dạng GitHub issue bằng lệnh gh issue create. Thường sau khi xong bước này, Matt sẽ dùng skill prd-to-issues, tham chiếu tới GitHub issue vừa tạo. Issue đó mô tả đích đến, và ta lại cần một hành trình để đi tới đó.

14. Codebase rác sinh ra code rác: đối xử với agent như con người

Matt khuyên chạy skill này định kỳ trong một codebase, chẳng hạn mỗi tuần một lần, chỉ để nhận diện cơ hội. Hoặc khi có một đợt phát triển bùng nổ đột ngột và bạn tạo ra cả một "cánh" tính năng mới, skill này sẽ rất hữu ích để đảm bảo phần mới khớp với phần còn lại của codebase, đảm bảo nó không quá cẩu thả (sloppy). Và khi bạn cứ chạy nó, cứ tinh chỉnh codebase, bạn sẽ thấy chất lượng output của agent tăng lên. Vì câu ngạn ngữ cũ vẫn đúng: nếu codebase của bạn là rác, AI sẽ tạo ra rác trong codebase đó.

Nói thật, theo Matt, nếu bạn lấy tất cả những skill này và bảo đây là một cuốn sách markdown nhỏ về các process dành cho con người, thì nó cũng không hề lạc lõng. Anh thấy cách thành công nhất để nâng chất lượng code từ agent đơn giản là đối xử với chúng như con người. Những con người với các ràng buộc kỳ lạ, đúng vậy: không có trí nhớ, như được nhân bản, bước ra từ "lồng ấp" rồi đi làm ngay.

Video có thêm một đoạn giới thiệu lại khoá học của Matt; anh kể khi soạn khoá học, anh nhận ra mình thật ra không dạy Claude Code nhiều, mà dạy những thứ như sub-agent, các ràng buộc của LLM như chuyện "smart zone, dumb zone" của context window, steering (về bản chất là một cách ghi tài liệu ngay trong codebase), cách xử lý task khổng lồ, tracer bullet, vòng phản hồi (feedback loop) và cách nối chúng vào một agent tự động. Cuối video Matt cảm ơn người xem, nói tuần này anh sẽ quay lại với nhiều nội dung hơn, hỏi mọi người muốn anh làm chủ đề gì tiếp, và chia sẻ rằng giao điểm giữa kỹ thuật phần mềm thực thụ và AI là một chỗ tuyệt vời để làm nội dung.