Karpathy Loop trong Claude Code và auto loop tự cải thiện

1. Loop và Karpathy Loop: video này định làm gì

Mọi người đang dùng loop để cho AI agent tự build rất nhiều thứ, và lý do cách này chạy được là workflow có cấu trúc đứng sau mỗi loop. Chính vì có cấu trúc đó mà người ta dám để agent làm những task lớn hàng giờ liền, và kết quả họ nhận về khá tốt. Có rất nhiều cách dựng một workflow kiểu này, và một trong số đó là Karpathy Loop.

Nhóm AI LABS đã dựng Karpathy Loop trên chính các app của họ để xem nó thực sự trụ được tới đâu. Kết luận: nó trụ khá tốt, nhưng họ tìm ra một vấn đề mà loop không tự nhìn thấy được. Để sửa vấn đề đó, họ chỉ thay đổi đúng một chỗ trong loop. Kênh tự giới thiệu: họ là một công ty phần mềm và đây là kênh AI Labs của họ. Video sẽ đi qua ba phần: Karpathy loop là gì, cách dựng nó trên app của chính bạn, và thay đổi giúp sửa vấn đề kia. Nhưng trước khi vào workflow, họ quay lại phương pháp gốc của Karpathy, vì loop này được xây trên nền đó.

Nếu bạn chưa quen với khái niệm loop, kênh đã có một video đầy đủ về chủ đề này và khuyên bạn xem để hiểu loop rõ hơn trước khi đi tiếp.

2. AutoResearch: một file được sửa, một file chấm điểm

Andrej Karpathy từng làm một project tên là AutoResearch. Trong đó một AI agent liên tục làm việc với việc train một model, chạy code đi chạy lại cho tới khi model thực sự tốt lên. Agent làm việc này trong một loop, nên không ai cần chỉ cho nó từng bước phải làm gì.

Luật chơi trong AutoResearch rất chặt. Agent chỉ được phép sửa một file, và đó là file train model. Mỗi vòng là một thí nghiệm: agent thay đổi một chỗ trong file train đó, rồi train model trong vài phút.

Sau đó một file thứ hai chấm điểm model. Nếu điểm tốt lên, agent giữ thay đổi. Nếu điểm giữ nguyên hoặc tệ đi, agent hoàn tác thay đổi đó. Agent không được phép đụng vào file chấm điểm. Lý do: nếu agent sửa được file chấm điểm, nó có thể chỉ việc làm cho điểm dễ đạt hơn, thay vì làm cho model tốt hơn.

3. program.md, 700 thí nghiệm và CEO của Shopify

Còn một file thứ ba tên là program.md, nói cho agent biết cách chạy mỗi vòng. Về cơ bản program.md là một file hướng dẫn mà Karpathy viết bằng tiếng Anh thông thường. Trên màn hình, file này được minh hoạ với dòng đầu tiên "If the score got better, keep it." (nếu điểm tốt hơn thì giữ lại). Karpathy viết file hướng dẫn đó rồi để loop chạy trong hai ngày. Trong khoảng thời gian ấy agent chạy 700 thí nghiệm và tìm ra 20 thay đổi giúp model train nhanh hơn.

Thí nghiệm này cho thấy agent có thể cứ thế chạy tiếp và thử từng khả năng một, điều không thể làm được nếu bạn tự điều khiển mọi bước. Lý do là tự tay điều khiển 700 thí nghiệm mất rất nhiều thời gian, còn agent tự chạy chúng và tìm ra nhiều cách khác nhau có hiệu quả.

CEO của Shopify cũng chạy cùng kiểu loop đó và thu được kết quả tốt. Ông chạy nó trên một model của chính mình trong lúc ngủ, và agent chạy 37 thí nghiệm. Sáng ra, model của ông hoạt động tốt hơn 19%.

Vậy phương pháp của Karpathy chứng minh rằng khi agent chỉ được giao một mục tiêu, nó có thể tiếp tục thử và tự tốt lên mà bạn không phải chỉ đạo từng bước. Đây là lúc rất nhiều người bắt đầu lao vào loop engineering.

4. Khi nào mới nên dựng một loop: bốn điều kiện

Trước khi dựng loop, bạn cần biết khi nào thì nên dùng nó ngay từ đầu. Nếu dùng loop cho sai loại task, bạn sẽ tốn token mà có khi còn không nhận được thứ mình muốn. Loop thực sự hữu ích khi được đặt vào đúng tình huống, nhưng tình huống đúng phụ thuộc vào việc bạn thật sự muốn hoàn thành điều gì với task đó. Theo video, để một loop đáng công dựng, task cần đủ bốn điều:

1. Bạn lặp lại task đó thường xuyên. Dựng một loop tốn thời gian, và bạn chỉ lấy lại được thời gian ấy khi cứ lặp lại task đó. Với một việc chỉ làm một lần, một prompt tốt là đủ. Nếu dựng loop cho loại việc này, bạn sẽ mất nhiều thời gian cho phần setup hơn cả bản thân task.
2. Usage limit của bạn, vì loop dùng rất nhiều token. Trong một loop, agent đọc lại project của bạn và thử một cách sửa mới ở mỗi vòng. Việc đó tốn token cả ở những vòng thất bại, nên một loop dài trên gói 20 đô sẽ chạm usage limit trước khi công việc kịp xong.
3. Công việc kiểm được mà không cần con người, bằng một thứ cho ra điểm số rõ ràng. Trong một app, việc đó do những đoạn code nhỏ đảm nhận: chúng thử một feature và xác nhận nó chạy đúng.
4. Agent thực sự chạy được thứ nó vừa build và thấy được chỗ nào hỏng, để nó biết phải sửa gì ở vòng sau.

Nhóm dùng nhiều kiểu loop khác nhau trong workflow của mình, nhưng chỉ cho những task có một điểm số rõ ràng đo được. Và họ không bao giờ để cả một app được build trong một loop rồi coi như xong.

5. Mỗi loop chỉ một feature, và bắt đầu dựng setup

Họ chỉ dùng loop để build từng feature một, hoặc một phiên bản đơn giản của app mà checks của loop kiểm chứng được. (Trước khi vào setup, kênh có một lời nhờ đăng ký kênh và bấm nút hype.)

Karpathy đã chia sẻ khá nhiều về cách ông làm việc với AI agent. Nhóm AI LABS lấy những gì ông chia sẻ và biến nó thành một setup dùng được trong workflow của chính họ. Để loop của ông chạy được với app của họ, họ dựng vài skill và agent để tự động hoá công việc này. Video giải thích kỹ từng phần làm gì, để bạn có thể nhờ Claude build từng phần đó cho mình.

6. Skill project-context: memory bank của app

Thứ đầu tiên họ build là một skill rất quan trọng tên Project Context. Skill này gắn riêng với thứ bạn đang build và chứa mọi thứ cần biết về nó. Nó đóng vai một memory bank: app làm gì, có những trang nào, theo những quy ước nào, và những thứ cần tránh. Vì vậy khi model đang làm việc, nó có thể lấy context từ đó. Skill project-context lớn lên cùng app, nên lúc nào cũng khớp với phiên bản mới nhất.

Họ dùng skill thay vì một file thông thường, nơi những thông tin này hay được đặt, vì chỉ phần mô tả ngắn của skill nằm trong context window mọi lúc. Nghĩa là agent luôn biết skill đó tồn tại, nhưng chỉ tải toàn bộ chi tiết khi cần, thay vì mang hết theo vào mọi task. Cho nên dù bạn build gì, bạn cũng có thể nhờ agent mình đang dùng dựng một skill lưu toàn bộ context này. Trên màn hình, họ gõ đúng một câu cho Claude Code:

set up a skill with all the context for this project

7. Skill build và skill write-checks

Tiếp theo là một skill chính điều khiển toàn bộ, để loop chạy được mà bạn không phải ngồi canh. Đó là skill build, chứa tất cả hướng dẫn để chạy loop trên từng feature. Phần description của nó trên màn hình gọi nó là "the one command": đưa cho nó một feature hoặc một nhóm (first, next, last), nó sẽ viết checks, xin bạn đồng ý, khoá checks lại và chạy Karpathy loop trên từng feature mà không cần người trông; cách dùng là /build first hoặc /build split-bill.

Việc đầu tiên của skill build là viết checks, và nó không tự làm việc đó. Nó dùng một skill khác tên write checks. Write checks giống agent test author mà kênh đã dùng ở các video trước, nhưng được may riêng cho project và workflow này. Nhờ vậy checks luôn được viết trước khi bất kỳ feature nào được build, để agent có thứ để đối chiếu thay vì tự chấm code của chính mình.

8. Duyệt checks bằng lời thường rồi khoá lại

Khi checks đã viết xong, skill build liệt kê mỗi check kiểm tra cái gì bằng lời đơn giản. Đây là chỗ bạn cần trao đổi qua lại với agent, để chắc chắn checks bao được tất cả những lỗi hay gặp trong quá trình làm. Khi bạn bật đèn xanh, một chương trình nhỏ tên Approve Checks khoá chúng lại. Chương trình Approve Checks chuyển checks vào một thư mục bị khoá, và một rule trong settings của Claude Code chặn agent sửa thư mục đó, nên loop không thể tự làm checks của mình dễ hơn.

Khi bạn đã duyệt checks, skill build commit chúng. Việc này thêm một lớp bảo vệ nữa phòng khi agent tìm cách thay đổi chúng. Sau đó nó mới chạy loop.

9. Feature builder agent, file kết quả và program.md

Skill build không build feature trong context window của chính nó. Để context của mỗi feature tách biệt, nó giao từng feature cho feature builder agent. Agent này bắt đầu mới tinh mỗi lần và build feature theo đúng hướng dẫn. Kết quả của mỗi vòng được lưu vào một file để dùng về sau. Khi mọi feature xong, skill build xuất ra một báo cáo.

Tất cả hướng dẫn của loop, như các luật cố định (fixed rules) và cách làm việc (how to work), được viết trong program.md. Cách này theo đúng định dạng Karpathy đã dùng, và nó hoàn thiện setup để chạy loop theo kiểu này.

10. Demo 1: đặt món mang đi cho website nhà hàng

Video có một đoạn quảng cáo cho Upstash Box.

Quay lại demo. Vì project đang làm đã build được một nửa, họ prompt Claude dùng skill build và yêu cầu build một feature cho phép khách đặt đồ ăn mang đi (pickup) từ website của nhà hàng. Lệnh trên màn hình:

/build the online order feature next

Nhưng feature đó chưa có trong danh sách feature của họ. Claude báo FEATURES.md chưa có feature online order và hỏi nên build gì: thêm spec online-order, build nhóm "next" (happy-hour, supplier-reorder, kitchen-screen), hay cả hai. Thế là Claude thêm feature đó và viết các luật cho việc đặt món online vào FEATURES.md, file họ đang dùng để theo dõi feature. Trên màn hình, Claude ghi rằng nó đặt online-order trong một mục "Extra" mới, ngoài ba nhóm sẵn có để chúng vẫn so sánh công bằng, và đây là pickup only: khách đặt từ site public rồi tới lấy đồ.

Có luật trong tay, Claude đưa ra toàn bộ checks nó định làm. Danh sách đầu tiên có 10 checks: đơn có tên, số điện thoại, món và giờ lấy thì được nhận, tổng tiền theo giá menu (ví dụ 2 pizza và 1 espresso là 27 đô); đơn thiếu tên, số điện thoại hoặc món thì bị từ chối; giờ lấy phải cách lúc đặt ít nhất 30 phút; không nhận lấy đồ vào ngày nhà hàng nghỉ (thứ Hai); giờ lấy có thể đúng giờ mở cửa nhưng không sớm hơn; lần lấy cuối là 30 phút trước giờ đóng cửa; giờ mở cửa theo giờ Chicago chứ không theo đồng hồ server; giờ lấy phải rơi vào bước 15 phút; mỗi khung giờ nhận tối đa 4 đơn online; và nếu giá menu đổi sau đó thì đơn đã đặt giữ nguyên tổng tiền ban đầu.

Họ muốn có cả email của khách, nên bảo Claude thêm vào:

i want email as well along with name and phone number

Thế là thành 11 checks, và check mới đảm bảo email là một địa chỉ thật.

11. 11/11 ngay vòng đầu, và thứ điểm số không thấy

Khi họ duyệt checks, Claude commit chúng. Sau đó feature builder agent build feature, mất khoảng sáu phút. Cuối cùng báo cáo cho thấy cả 11 checks đều qua ngay vòng đầu, nên loop không cần thêm vòng nào.

Nhưng loop còn bắt được một thứ mà điểm số không cho thấy. Checks chỉ kiểm tra các luật đặt món, nên loop đã viết những luật đó nhưng chưa làm form đặt món mà khách dùng trên website. Vì vậy loop build form đặt món và nối nó với các luật kia rồi mới đánh dấu feature là done.

12. Vấn đề thói quen: loop không nhớ bài học

Kiểu loop này có một vấn đề: agent có thói quen. Trong một loop, nếu agent thấy một cách làm nào đó không hiệu quả, nó sẽ cải thiện cách đó ngay trong loop ấy, nhưng nó sẽ không nhớ điều đó cho lần sau chạy loop. Loop của họ cũng mắc đúng vấn đề này, vì mỗi feature bắt đầu với một feature builder agent mới tinh và cùng những file hướng dẫn cũ. Nên một lỗi model mắc ở một vòng sẽ lặp lại sang vòng sau.

Cách sửa là một loop thứ hai đọc xem loop thứ nhất đã chạy thế nào và thay đổi cách loop thứ nhất làm việc. Họ build phiên bản riêng của loop thứ hai đó dưới dạng một skill tên auto loop.

Trong phương pháp của Karpathy, một người viết program.md. Còn trong setup của họ, auto loop viết lại phần "How to work" của program.md thay cho họ. Để làm được, auto loop đọc file kết quả, nơi lưu mọi vòng loop đã chạy. Với mỗi vòng, file kết quả còn cho biết vòng đó được giữ hay bị hoàn tác, agent đã thử gì, và checks nào vẫn còn fail.

13. Auto loop: viết lại phần How to work, không được sửa checks

Về cơ bản auto loop tìm những vấn đề cứ quay lại, như cùng một lỗi agent liên tục mắc, hay cùng một lỗ hổng xuất hiện ở hai feature. Rồi nó ghi lại từng thói quen kèm những vòng chứng minh thói quen đó. Sau đó auto loop viết lại phần How to work trong program, để các feature tiếp theo được build với hướng dẫn mới.

Nhưng auto loop không được sửa checks. Nếu auto loop sửa được checks, nó có thể làm chúng dễ qua hơn. Khi đó các vòng sẽ thôi fail mà thói quen xấu chẳng bao giờ được sửa.

14. Demo 2: app quản lý project làm việc nhóm

Để thử loop trong loop, họ chạy nó trên một project khác: một app quản lý project chưa có cách nào để nhiều người gộp và chia sẻ workflow với nhau. Để chạy, họ nhờ Claude tạo một skill khác tên Auto Loop:

create another skill called auto-loop, that is a loop within a loop

Skill Auto Loop về cơ bản chạy cùng một loop, với cùng feature builder agent và skill write checks mà setup trước dùng, nhưng nó chạy loop đó bên trong một loop khác. Điểm khác với skill build dùng trước đó là skill build chỉ chạy một lượt: mọi feature nhận cùng một bộ hướng dẫn, các agent build nó, nhưng không điều gì loop học được được mang sang feature tiếp theo.

Skill auto loop cũng chạy loop từng feature một. Nhưng sau mỗi feature, nó xem lại công việc và cập nhật hướng dẫn, để feature tiếp theo bắt đầu từ cách làm đã thực sự hiệu quả. Theo video, điều này làm loop của bạn tốt hơn nhiều. Mục đích của skill này chính là cải thiện bản thân loop và sửa hướng dẫn, để lần chạy sau tốt hơn lần chạy trước.

Để thêm feature cho app, họ chạy skill Autoloop và nói điều họ muốn: một cách để nhiều người làm việc cùng nhau, chia sẻ focus session và cùng chạy project.

/autoloop i want you to add multiple people feature. like many people can work on things and create focus sessions together, also manage projects together

Skill Autoloop bắt đầu bằng việc thêm các feature đó vào file theo dõi. Giống lần trước, nó liệt kê checks trước. Bạn có thể sửa nếu cần, hoặc bảo agent bắt tay build luôn.

15. Hai thói quen auto loop thêm vào

Feature đầu tiên là một database dùng chung, để công việc của mọi người nằm ở một chỗ. Database qua cả 10 checks của nó, nhưng app chưa bao giờ lưu gì vào đó. Vì vậy auto loop thêm một thói quen vào hướng dẫn: nối mỗi feature vào app ngay trong vòng làm checks của nó pass.

Sau đó auto loop phát hiện vấn đề thứ hai với mentions, tính năng cho phép giao task bằng cách gõ tên một người sau ký tự @. Mentions qua checks của nó, nhưng một phần cũ hơn của app vẫn đọc ký tự @ theo cách cũ. Đó là lý do auto loop thêm thói quen thứ hai: tìm mọi chỗ trong app đã làm cùng một việc và bắt từng chỗ theo luật mới.

Cả hai thói quen đều có tác dụng, vì các feature tiếp theo đến cùng với màn hình đã được nối sẵn.

16. Checks hoạt động thế nào: ba vòng của shared projects

Để thấy checks hoạt động thật, hãy xem feature shared projects, nơi builder làm sai hai vòng. Ở vòng đầu, nó làm hỏng mentions, nên các check của mentions fail và vòng đó bị hoàn tác. Ở vòng hai, nó chia phần của mỗi người theo cách đơn giản, nên ba người mỗi người được 33, cộng lại chỉ ra 99. Check đó fail, và tới vòng ba builder sửa được và qua cả 10 checks.

Trên màn hình báo cáo nói thêm: vòng hai được 9/10 vì check "ba người trên một task thì 34, 33, 33" fail, vòng đó được giữ như một bước tiến nhưng feature chưa được tính là xong; vòng ba chia phần dư cho đúng và cả 10 checks qua.

Khi xong, nó đưa ra một báo cáo cho biết agent đã sai ở đâu và sửa thế nào, cùng với workflow trông ra sao. Nhờ vậy khi làm feature tiếp theo, bạn không phải gặp lại cùng vấn đề đó nữa.

Cuối video, kênh nói tất cả các skill tạo trong video cùng những tài nguyên khác có trong cộng đồng trả phí của họ, mời ủng hộ qua nút Super Thanks, cảm ơn người xem và hẹn gặp ở video sau.