Ralph Loops: Build Dumb AI Loops That Ship — Chris Parsons, Cherrypick

• Ralph Loop là một phương pháp lặp lại, cho phép Trí tuệ nhân tạo (AI) tự sửa lỗi và cải thiện công việc bằng cách thực hiện lại cùng một tác vụ dựa trên một lời nhắc duy nhất.
• Phương pháp này đánh dấu một sự chuyển đổi quan trọng từ các workflow tự động hóa AI phức tạp (như N8N) sang các Agent Loop đơn giản và hiệu quả hơn, nơi AI tự điều phối các bước.
• Ralph Loop không chỉ hữu ích trong lập trình mà còn được áp dụng rộng rãi cho nhiều tác vụ hàng ngày khác, từ viết email đến tạo nội dung, nhờ khả năng tự hoàn thiện của AI.

• Triển khai Ralph Loop bằng cách nhắc lại cùng một tác vụ cho AI sau khi nó hoàn thành, thúc đẩy quá trình tự kiểm tra và cải thiện mã hoặc nội dung.
• Chuyển đổi từ các workflow AI phức tạp (ví dụ: N8N) sang các Agent Loop đơn giản hóa, nơi AI tự điều phối các bước, giảm độ "dễ hỏng" và dễ bảo trì hơn.
• Sử dụng các mô hình ngôn ngữ lớn (LLM) mới nhất (như GPT 5.8.X+ hoặc Claude Opus/Sonnet 4.6+) là cần thiết để tận dụng tối đa khả năng của Agent Loop và Ralph Loop.
• Nhận thức rằng AI (đặc biệt là các công cụ như Claude Code) đang dần đảm nhiệm toàn bộ quá trình viết mã, đòi hỏi các lập trình viên phải thích nghi với vai trò mới.
• Áp dụng Agent Loop và Ralph Loop không chỉ trong lập trình mà còn trong các tác vụ phi kỹ thuật hàng ngày như viết email, tạo nội dung, để tự động hóa và nâng cao hiệu quả công việc cá nhân.
• Thiết kế các "kỹ năng" hoặc "lời nhắc" để AI có thể tự cập nhật và tinh chỉnh dựa trên phản hồi hoặc kết quả từ các phiên làm việc trước đó.
• Các nguyên tắc phát triển phần mềm linh hoạt (agile) vẫn còn giá trị đáng kể khi làm việc với Trí tuệ nhân tạo.

• Ralph Loop — Chu trình Ralph
• Trí tuệ nhân tạo — Artificial Intelligence (AI)
• Agent Loop — Chu trình Tác nhân
• workflow — quy trình làm việc
• lời nhắc — prompt
• kỹ năng — skill (trong ngữ cảnh AI)
• live demos — lập trình trực tiếp
• brittle — dễ hỏng (khi nói về hệ thống)
• automation — tự động hóa
• mô hình — model (trong ngữ cảnh AI/LLM)

Giới thiệu Hội thảo về Ralph Loop

Chào mừng. Vậy thì, hội thảo này sẽ nói về các Ralph loop. À, xin hỏi có ai ở đây biết Ralph loop là gì không? Hầu như là tất cả mọi người. Tôi đoán rằng những người khác đến đây chỉ vì họ thấy cái tên nghe lạ tai, hoặc có lẽ đang tìm một nơi yên tĩnh để làm việc. Tôi không rõ, nhưng rất hoan nghênh tất cả các bạn. Vậy, chúng ta sẽ làm gì hôm nay? Đây là một hội thảo kéo dài hai giờ. Chúng ta sẽ, à, nếu các bạn có thể nhường một chút chỗ khi mọi người đang vào, thì sẽ rất hữu ích. Cảm ơn. Đây là hội thảo hai giờ. Chúng ta thực sự sẽ cùng nhau xây dựng các Ralph Loop. Chúng ta sẽ làm điều này cùng nhau trên máy tính xách tay của mình để, à, để tạo ra một số thứ và hoàn thành một số việc. Vì vậy, đây không chỉ là lý thuyết. Đây là một buổi thực hành rất cụ thể. Nếu bạn có máy tính xách tay, bạn có thể lấy ra ngay bây giờ. Chúng ta thực sự sẽ tự mình thử làm điều này. À, tôi có một vài slide, nhưng không nhiều. Phần lớn sẽ là các buổi live demos (lập trình trực tiếp) và các điểm tương tác. Và ý tưởng là vào cuối buổi, bạn sẽ có thể ra về với một thứ gì đó hoạt động được mà chúng ta sẽ, à, áp dụng nó vào một cơ sở mã "đồ chơi" chỉ để giải trí, để tạo ra một Bộ hẹn giờ Pomodoro. Nhưng, à, hy vọng rằng ý tưởng là bạn sẽ có thể sử dụng điều này trong công việc thực tế của mình khi chúng ta hoàn thành.

Khảo sát việc sử dụng AI trong lập trình và kinh nghiệm với Ralph Loop

Vậy, thêm một lần giơ tay nữa nào. Được rồi. Ai đang sử dụng Claude Code hoặc CodeX đặc biệt để viết mã? Xin mời giơ tay. Ồ, khá nhiều người đang sử dụng đặc biệt để viết mã. Được rồi. Ai đang sử dụng nó để viết TẤT CẢ mã của mình? Ai không còn viết bất kỳ mã nào nữa? Khá nhiều người đó. Hãy nhìn xung quanh một chút. Đó là một sự thay đổi rất lớn. Nếu tôi hỏi một nhóm lập trình viên sáu tháng trước rằng ai không còn viết mã nữa, bạn sẽ nhận được một câu trả lời rất khác. À, câu hỏi tiếp theo, ai đang sử dụng Claude Code hoặc CodeX? Ừm, và tôi cũng sẽ bao gồm Cursor ở đây, trong công việc không liên quan đến lập trình của họ. Được rồi, khá nhiều bạn. Còn về tất cả công việc không liên quan đến lập trình thông thường của bạn thì sao? Được rồi. Thú vị thật. Thú vị thật. Vậy, bạn có thể thấy tương lai, ừm, trong căn phòng này không? Đúng vậy. Có một vài người đang bắt đầu nhưng chúng ta vẫn đang trong hành trình đó, chắc chắn rồi. Và ai đã từng xây dựng Ralph Loops trước đây? Lần giơ tay cuối cùng. Một hoặc hai người. Được rồi, tuyệt vời. Tôi sẽ trông cậy vào các bạn để có tất cả các câu trả lời. Ừm, vậy thì thật tuyệt vời.

Về diễn giả và việc ứng dụng Trí tuệ nhân tạo

Vậy, à, một chút về bản thân tôi. Tên tôi là Chris Parsons. Ừm, dạo gần đây tôi dành phần lớn thời gian để cố gắng giúp các nhóm, như nhóm mà tôi từng quản lý, tìm ra xem rốt cuộc phải làm gì với Trí tuệ nhân tạo là chủ yếu. Vậy, à, tôi là một CTO (Giám đốc Công nghệ) theo kinh nghiệm nền tảng. Tôi đã thực hiện một vài startup (công ty khởi nghiệp) và scaleup (công ty mở rộng) được quỹ VC (Vốn đầu tư mạo hiểm) hậu thuẫn, và, à, điều này đã thực sự làm tôi và bạn bè tôi choáng váng, và chúng tôi vẫn đang cùng nhau tìm cách giải quyết chuyên nghiệp về cách giúp các nhóm của chúng tôi chấp nhận và sử dụng Trí tuệ nhân tạo. Vậy đó là công việc tôi làm để kiếm sống những ngày này. Tôi có khoảng 30 năm kinh nghiệm xây dựng phần mềm chuyên nghiệp, từng là CEO (Tổng Giám đốc) của một agency (công ty dịch vụ). Tôi đã thực hiện rất nhiều hoạt động tư vấn agile (linh hoạt) — nhớ không? — và cả những loại hình đào tạo đó từ trước đây. Và, à, thật buồn cười — đây là một chủ đề khác hoàn toàn — tất cả những, à, nguyên tắc và thực hành mà chúng ta đã dạy trong nhiều năm và không ai thực sự lắng nghe, thì vẫn rất hữu ích, ừm, đối với Trí tuệ nhân tạo. Vậy thì, chúng ta đã rõ. Ừm, nên dạo gần đây tôi thực sự đang chạy các Ralph loop liên tục, 24 giờ một ngày, để hoàn thành công việc của mình. Vì vậy, tôi đang sử dụng chúng để viết email, để kiểm tra lịch của mình, để viết nội dung và các bản tin. Tôi đang sử dụng chúng để giúp tôi thực hiện công việc cho khách hàng. Vì vậy, tôi đang sử dụng chúng trong mọi thứ tuyệt đối. Tôi cũng sử dụng chúng để viết mã, đây là trọng tâm của chúng ta hôm nay, nhưng chúng thực sự rất hữu ích cho mọi khía cạnh trong cuộc sống của chúng ta. Vậy nên, vào cuối buổi, ý tưởng là bạn cũng sẽ có thể làm được điều đó.

Từ Workflow N8N phức tạp đến Agent Loop đơn giản hơn

À, vậy đây là cách tôi từng làm việc với Trí tuệ nhân tạo cho đến gần đây. À, có lẽ bạn không thể nhìn rõ lắm. Đây là một workflow (quy trình làm việc) N8N mà tôi đã sử dụng để tạo bản tin hàng tuần của mình. Nó tốn của tôi, à, có lẽ cả một tuần để viết, chứ chưa nói đến việc thực sự test (kiểm thử) và debug (gỡ lỗi). À, nó có rất nhiều thứ khác nhau ở đây. Đây, đây giống như một featured article flow (luồng bài viết nổi bật) sẽ đọc nhiều bài viết khác nhau từ blog của tôi và tìm ra xem tôi đã đăng nó trước đây chưa, tóm tắt nó bằng Trí tuệ nhân tạo và đặt nó vào đó. Và sau đó có một cái khác để lấy, à, các liên kết mà tôi đã đăng vào một danh sách cụ thể và nó đã bình luận một chút về điều đó. Nó thực sự khá phức tạp và, và khó vận hành và duy trì. Và nó hoạt động khá ổn, ngoại trừ việc vào 2 giờ chiều thứ Hai, hầu như mỗi thứ Hai, tôi sẽ nhận được thông báo đáng sợ từ N8N rằng workflow của tôi đã thất bại. Và tôi chỉ kiểu, "Ôi, không." Và sau đó tôi phải vào đó và tìm ra bất cứ thứ gì đã bị hỏng và cố gắng chạy và sửa chữa nó. Bây giờ, điều này không có gì chống lại N8N. N8N là một công cụ thực sự tuyệt vời và nó có thể làm được một số điều rất hay. Và tôi sẽ không bao giờ có thể điều phối Trí tuệ nhân tạo theo cách tôi đã làm trước đây nếu không có một công cụ như N8N. Mặc dù là một coder (người viết mã), việc quản lý nó ở đây dễ dàng hơn rất nhiều. Và bạn có thể quản lý tất cả các Khóa API một cách rất dễ dàng, và đó là một công cụ tốt để kết nối mọi thứ lại với nhau, nhưng nó lại rất brittle (dễ hỏng) khi sử dụng ở mức độ phức tạp này. Và tôi không nhận được nhiều giá trị từ nó. Ừm, và sau đó mỗi khi tôi sửa nó, tôi lại làm một việc khác. Và thế là, thành thật mà nói, có lẽ tôi chỉ cần tự viết bản tin còn dễ hơn là duy trì cái thứ đã viết bản tin đó. Và có lẽ tôi cũng có một bản tin tốt hơn một chút. À, vậy điều này không tuyệt vời. Ừm, nhưng, nhưng đây là theo suy nghĩ của tôi vài tháng trước, thực sự là cách duy nhất để sử dụng Trí tuệ nhân tạo. Bạn phải điều phối và quản lý nó, cung cấp cho nó dữ liệu phù hợp và xử lý tất cả ngữ cảnh. Và tôi nghĩ rằng đây là tương lai của automation (tự động hóa), nhưng nó thực sự không phải là tương lai của automation.

Tương lai của Automation với Agent Loop và Claude Code

Tương lai của automation (tự động hóa) giống với thứ gì đó như thế này nhiều hơn, à, chạy trong Claude Code. Vậy, đây rõ ràng không phải là kỹ năng thực tế, nhưng, ừm, tôi hiện có trong Claude Code một kỹ năng viết bản tin cho tôi và nó có tất cả các hướng dẫn đó. Trên thực tế, tôi đã sao chép và dán mã JSON từ N8N vào Claude Code và nói, "Hãy viết một kỹ năng dựa trên flow (luồng) này," và nó đã làm rất tốt. Ừm, và sau đó điều nó làm là nó đi qua và thực hiện tất cả các việc. Nhưng điều thú vị về điều đó là Claude Code hoạt động như thế nào? Chà, nó đọc điều đầu tiên, nó quyết định bước tiếp theo, và sau đó nó đọc phần tiếp theo, và sau đó nó quyết định bước tiếp theo, và nó cứ thế làm việc trong vài phút để thực sự viết và sản xuất bản tin mà tôi đang viết. Và điều đó cũng đúng với mã. Điều đó cũng đúng với bất cứ thứ gì chúng ta muốn xây dựng bằng Claude Code. Claude chỉ cần xử lý nó. Bạn mô tả những thứ bạn muốn và nó sẽ làm. Bây giờ, điều thú vị là Claude Code về cơ bản đang chạy trong một Agent Loop, phải không? Nó chỉ đọc kỹ năng, gọi một công cụ, quay trở lại từ đầu, đọc lại kỹ năng, gọi một công cụ, gọi một công cụ, và sau đó tại một thời điểm nào đó nó nhận ra rằng nó đã hoàn thành và nó dừng lại và nó cung cấp cho bạn bản tin của bạn dưới bất kỳ hình thức nào bạn muốn. Ừm, vậy điều thú vị là điều này cho ra đời những bản tin tốt hơn, mạch lạc hơn nhiều so với workflow trước đây. Tôi vẫn phải thay đổi chúng, viết chúng, chỉnh sửa chúng, nhưng, nhưng chúng, à, chúng là một bản nháp đầu tiên tốt hơn nhiều so với trước đây. Và tôi thực sự chưa động đến kỹ năng này. Tất cả những gì tôi thực sự làm với kỹ năng này là tôi nói vào cuối quy trình viết bản tin, "Vui lòng cập nhật kỹ năng với bất cứ điều gì bạn có thể tìm ra từ phiên làm việc mà bạn lẽ ra phải làm khác đi." Và nó thực hiện một vài tinh chỉnh nhỏ đây đó. Ừm, vậy đó là một Agent Loop, là một hình thức làm việc theo Agent Loop với Trí tuệ nhân tạo. Vì vậy, các tác nhân ban đầu bắt đầu trong các workflow mà bạn có một kiểu điều phối orchestration khá phức tạp trông giống như thứ gì đó kinh khủng như thế này, cuối cùng lại kết thúc trong một Agent Loop khá đơn giản, có lẽ với một ngữ cảnh tốt hơn một chút. Bây giờ, điều này đã không hoạt động trong một thời gian dài, nhưng giờ đây nó đang bắt đầu hoạt động với các mô hình mới nhất và với mô hình mới nhất tôi thực sự muốn nói đến GPT 5.8.X, thực sự là GPT 5.12 trở đi, à, và Claude Opus 4.6 hoặc Sonnet 4.6 trở lên. Vậy, những mô hình đó bắt đầu xuất hiện vào khoảng, à, cuối tháng 11. À, tôi không có ý kiến gì về Mythos đâu. Tôi, tôi đã nói chuyện với những người đã sử dụng nó và họ nói rằng nó, nó, nó tốt, nhưng chủ yếu là marketing, nhưng chúng ta sẽ xem. À, nhưng, ừm, nhưng vâng, à, chúng ta sẽ xem điều đó sẽ đưa chúng ta đến đâu. Có thể chúng ta thậm chí sẽ không cần kỹ năng. Có thể chúng ta sẽ chỉ nói "Hãy viết một bản tin" và nó sẽ làm. Ai biết được? Ừm, nhưng điều tôi đang cố gắng, điểm của tôi là, thay vì sử dụng các workflow phức tạp, chúng ta thực sự đang sử dụng các kỹ năng và Agent Loop nhiều hơn trong ngữ cảnh và các Agent Loop. Và bất kỳ loại tác nhân nào mà chúng ta chạy đều là một Agent Loop theo một cách nào đó rồi. Được rồi. Và kiểu cấu trúc lặp mạnh mẽ này là thứ mà bạn có thể áp dụng một cách tổng quát hơn.

Khái niệm và nguồn gốc của Ralph Loop

Ừm, vậy điều gì sẽ xảy ra khi chúng ta đẩy các Agent Loop đi xa hơn một chút? Vậy, ừm, giai đoạn đầu tiên, ừm, là ý tưởng này, hoặc ý tưởng đầu tiên đến từ Jeffrey Huntley, à, cách đây một thời gian — bạn biết đấy, "thời cổ đại" trong Trí tuệ nhân tạo nghĩa là khoảng tháng Sáu năm ngoái — và về cơ bản anh ấy nói rằng, điều chúng ta nên làm là bất cứ khi nào chúng ta hoàn thành việc sử dụng Trí tuệ nhân tạo để làm bất cứ điều gì, chúng ta nên thử lại điều đó bằng một cách nào đó, chúng ta nên, à, chỉ cần đưa cho nó chính xác cùng một lời nhắc và xem điều gì xảy ra, xem nó làm gì lần nữa, à, và nghe có vẻ, nghe có vẻ hơi ngớ ngẩn và nó dựa trên. Có ai biết câu chuyện này từ đâu không? Ai biết tại sao nó được gọi là Ralph loop? Khoảng hai người. Nó được gọi là Ralph loop vì Ralph Wiggum, một nhân vật trong phim The Simpsons mà về cơ bản nói rằng, ừm, à, anh ấy cứ thử đi thử lại cùng một việc và cuối cùng nó cũng hoạt động. Ừm, và đó thực sự là tất cả. Tất cả những gì một Ralph loop là, là, à, xây dựng hoặc làm điều này bên trong một lời nhắc. Sau đó, Trí tuệ nhân tạo sẽ đi và làm điều đó, và sau đó nó kết thúc và nói, "Được rồi, tôi đã làm xong rồi." Và sau đó nó nói, "Được rồi, tuyệt vời. Hãy đi và xây dựng điều này." Và, bạn biết đấy, và làm tất cả những điều tôi đã nói để xây dựng điều này. Và nó nói, "Ồ, được rồi. Tôi sẽ làm lại." Và, và cái, cái bản chất đột phá của điều đó có nghĩa là, à, Trí tuệ nhân tạo thường sẽ xem xét lại mã của nó và nhận ra rằng nó đã bỏ lỡ điều gì đó bằng một cách nào đó, phải không? Vì vậy, nó nhận ra rằng, à, nó chưa, nó chưa hoàn thành hẳn. Và đây là một vấn đề khá phổ biến với các công cụ lập trình AI vào năm ngoái. Nó chưa hoàn thành hẳn. Nó chưa kết thúc hoàn toàn và do đó nó nói, "Ồ, đúng rồi, tôi lẽ ra nên sửa phần đó," và sau đó làm lại, và sau đó, và sau đó khi nó dừng lại và nói, "Được rồi, bây giờ tôi chắc chắn đã hoàn thành 100%, xong rồi, xong rồi," và sau đó bạn làm gì? Bạn lại đưa cho nó một lời nhắc khác, nói, "Đi và xây dựng tính năng đó." Nó giống như, "Tôi đã xây dựng tính năng đó," và thử và nhìn lại, "Ồ, đúng vậy, thực ra có cái thứ nhỏ xíu này mà tôi lẽ ra phải làm. Bây giờ tôi thực sự đã hoàn thành rồi," và cứ thế. Vì vậy, bạn có thể thấy tính hữu dụng của việc đi qua Agent Loop đó, ừm, nơi bạn chỉ cần xây dựng tính năng và sau đó yêu cầu nó xây dựng tính năng và sau đó bạn yêu cầu nó xây dựng tính năng.

Chuẩn bị cho buổi Lập trình trực tiếp

Vậy, vậy đó là giai đoạn đầu tiên của Ralph loop. Và điều tôi muốn chúng ta làm là tôi muốn chúng ta thử điều đó. Vì vậy, trước tiên, tôi sẽ, à, thực hiện một chút lập trình trực tiếp. Hãy chuẩn bị tinh thần đi nhé. À, chúng ta sẽ xem nó diễn ra như thế nào. Và, à, chúng ta sẽ cố gắng thực hiện quy trình đó bằng Claude Code để xem nó sẽ đưa chúng ta đến đâu. Vậy, ừm, hãy để tôi bắt đầu thay đổi màn hình chia sẻ. Xin lỗi, chỉ mất một chút thời gian. Được rồi, tuyệt vời. À, cái này, mọi người có nhìn thấy không? Được rồi, những người ở phía sau có nhìn thấy không? Được rồi, bạn có muốn tôi tăng kích thước không? Nhận được nút like rồi. Tuyệt vời. Được rồi, đây là một đoạn mã mà tôi đã viết vội trong khoảng ba phút tối qua. Vì vậy, nó không tốt, nhưng chúng ta sẽ, đó là toàn bộ vấn đề. Chúng ta sẽ sửa nó. Ừm, vậy nó thực sự là một Bộ hẹn giờ Pomodoro, và bạn có thể thấy nó hoạt động như thế nào. Vậy, nếu tôi vào Python và gõ Pomodoro start, chà chà, chúng ta đã có một Bộ hẹn giờ Pomodoro.

Giới Thiệu Dự Án Pomodoro và Hệ Thống Ticket

Đó là tất cả những gì nó làm. Nó chỉ đơn giản là bắt đầu. Không có cách nào để biết liệu nó đã hoàn thành hay chưa, hoặc bất cứ điều gì tương tự, nhưng đó là điều chúng ta sẽ thay đổi. Một điều thú vị khác, rất quan trọng đối với bất kỳ dự án AI được mã hóa cẩn thận nào, là nó có các kiểm thử. Hãy xem, nó có một kiểm thử. Chỉ có một kiểm thử để kiểm tra xem nó có bắt đầu hay không. Thật tuyệt vời.

Nếu chúng ta xem xét nhanh, và bạn sẽ phải bỏ qua cho tôi nếu bạn không phải là fan của Vim vì tôi là một người như vậy, mặc dù giờ tôi hiếm khi sử dụng nó, thật buồn, 20 năm thói quen ghi nhớ đã biến mất. Nhưng vâng, tất cả những gì nó làm là chạy lệnh start và sau đó lưu thời gian bắt đầu vào thư mục gốc của bạn, trong tệp Pomodoro. Thực sự rất đơn giản. Vì vậy, đây là một dự án rất đơn giản và khá dễ hiểu.

Điểm khác biệt là nó có một thư mục mới với những thứ khác bên trong, và đó là các ticket. Có rất nhiều cách để chúng ta có thể cải thiện bộ hẹn giờ Pomodoro này. Và ticket đầu tiên là sẽ rất hay nếu chúng ta biết còn bao nhiêu thời gian cho phiên Pomodoro của mình, thay vì chỉ bắt đầu nó. Vì vậy, những gì tôi đã làm là tạo ra một hệ thống ticket rất đơn giản để chúng ta có thể ghi lại một số thay đổi. Những ticket này không phải là hoàn hảo, tôi đã viết chúng một lần duy nhất, nên tôi không biết liệu chúng có thực sự tốt hay không. Thực tế, tôi chưa xem xét một số ticket trong số đó. Chúng ta sẽ xem xét sau. Nhưng ý tưởng là chúng ta có thể sử dụng chúng để bắt đầu xây dựng một Agent Loop (chu trình làm việc) để hoàn thành công việc.

Khởi Động Tác Nhân AI và Sự Cố Kỹ Thuật

Để bắt đầu, tôi sẽ khởi động Claude và sẽ nói thẳng rằng hãy viết ticket đầu tiên. Hãy kiên nhẫn trong khi Claude khởi động. Một cách nào đó, tôi khá vui vì họ không phát hành Mythos ngày hôm qua, vì tôi nghĩ rằng nếu họ làm vậy, nó sẽ không hoạt động hôm nay. Nó thực sự không hoạt động, phải không? Thật khó chịu.

>> Tuyệt vời. Hãy thử lại. >> Có vấn đề với Wi-Fi. >> Ồ, được thôi. Ý tôi là, điều đó có thể gây ra một số vấn đề cho bài nói chuyện của tôi, nhưng chúng ta sẽ phải xem mọi việc diễn ra thế nào. Tôi không có một trong những chiếc máy Mac mới sang trọng cho phép bạn chạy... Không, cái này đã làm treo máy tính của tôi. Bạn có tin được không? Nó đã hoạt động cách đây 10 phút. Để tôi kiểm tra một chút. Hãy đợi tôi trong khi tôi gỡ lỗi máy của mình.

>> Có lẽ tôi đang ở trên một mạng Wi-Fi khác, nên nó sẽ... Không. Đúng vậy, Wi-Fi đã mất rồi. Vui thật. >> Đến lúc dùng mạng chia sẻ (tethering). >> Có lẽ vậy. Được rồi, đợi một chút trong khi tôi chia sẻ mạng từ điện thoại của mình, tôi nghĩ nó có 5G khá tốt, nên chúng ta sẽ ổn thôi. Được rồi, hãy xem nó có tốt hơn không.

>> Hoan hô. Được rồi, hãy thử lại. Không phải cái đó. Tuyệt. Vậy thì, Pomodoro workshop mã nguồn. Ổn chứ, nó đủ lớn không? >> Được rồi, tốt. Hãy thử Claude này thông qua sức mạnh của 5G. Nhìn kìa, nó hoạt động rồi! Thật tuyệt vời.

Claude Thực Hiện Ticket Đầu Tiên

Được rồi. Vậy thì, như tôi đã nói, chúng ta có một bộ hẹn giờ Pomodoro rất, rất đơn giản, thậm chí có thể coi là ngớ ngẩn. Và chúng ta sẽ triển khai một ticket. Tôi sẽ nói là "implement this ticket". Nó nằm trong doc/tickets/001. Tuyệt vời. Và tôi sẽ chỉ nói vậy thôi. Hãy xem điều gì sẽ xảy ra.

Vậy thì, nó sẽ đọc ticket mà tôi đã cho các bạn xem nhanh lúc nãy. Nó rất đơn giản. Và tất cả những gì nó làm là triển khai một status để xem chúng ta đã đi được bao xa. Sau đó, điều tôi muốn nó làm, điều tôi sẽ làm sau việc này, là tôi sẽ nói khi nào nó hoàn tất, vì sẽ chỉ có hai tệp. Nó sẽ không khó để làm. Và sau đó tôi sẽ nói, bạn biết đấy, "implement it again" và xem điều gì xảy ra. Có một vài cách khác nhau để bạn có thể làm điều này. Và không có một cách cố định nào để thực hiện một Ralph loop. Điều quan trọng thực sự là khái niệm, không phải bất cứ điều gì khác.

Tuyệt vời. Vậy là nó đã làm xong ticket. Nếu tôi nhanh chóng thực hiện một git diff, bạn có thể thấy rằng những gì nó đã làm là thêm một lệnh status. Tôi nghĩ khi tôi hỏi những người giơ tay lúc trước, hầu hết các bạn đều là lập trình viên. Vì vậy, hy vọng điều này không khó để theo dõi. Và sau đó chúng ta có một kiểm thử mới. Nhìn kìa! Nó đã thêm một kiểm thử. Nó thậm chí còn không được yêu cầu. Nó đã thêm một kiểm thử! Ôi trời ơi, thế giới đang đi về đâu vậy?

Sự Tiến Bộ của Agent Loop và Xóa Ngữ Cảnh

Vậy thì, bây giờ tôi sẽ nói chính xác điều tương tự. Một năm trước, đây sẽ là một bước rất quan trọng vì nó chắc chắn sẽ bỏ sót điều gì đó. Trong khi bây giờ thì giống như "Bạn đã làm xong rồi, ổn thôi". Phải không? Vậy nên Opus (một mô hình LLM mới hơn) giờ đã tốt hơn rất nhiều trong việc nhận ra khi nào công việc đã hoàn thành. Một Ralph loop truyền thống sẽ chỉ tiếp tục làm điều này, đúng không? Nó sẽ tiếp tục với kiểu "implement this ticket", "implement this ticket", "implement this ticket". Và điều này khá nhàm chán và nó sẽ không làm được gì nhiều hơn.

Và thực ra, ở một thời điểm nào đó, khi tôi thử điều này trước đó, thật thú vị. Nó đã làm một điều khác biệt. Nó thực sự nhận thấy rằng đáng lẽ nó phải cập nhật trạng thái thành "done". Vậy là quy trình này đã hoạt động, điều mà trước đó không xảy ra. Vậy thì, điều đó thật tuyệt. Nó thực sự đã nhận ra một điều mà nó đã bỏ sót. Vì vậy, ở đây bạn có thể thấy nguyên tắc cơ bản ban đầu của các Ralph loop đời đầu, đúng không? Ý tưởng rằng bạn có thể nhanh chóng thực hiện một điều gì đó và cuối cùng nó sẽ tìm thấy những thứ mà nó đã bỏ lỡ. Bởi vì nó đã bỏ lỡ điều đó. Tôi sẽ thử thêm một lần nữa, nhưng tôi không nghĩ nó sẽ đưa ra bất cứ điều gì khác. Như tôi đã nói, các mô hình mới nhất thực sự không cần bước này theo cách tương tự. Chúng có xu hướng chỉ hoàn thành công việc. Thực tế, lần này nó chỉ đơn giản là, ừm, "À, nếu bạn đang chạy một Ralph loop mà chọn ticket tiếp theo." Ôi, thật buồn cười. Nó đang tiết lộ bài thuyết trình của tôi một cách trực tiếp. Thật tuyệt vời!

Điều tôi muốn chúng ta làm là, tôi nghĩ, như một điểm khởi đầu, điều khác bạn có thể làm là bạn có thể xóa ngữ cảnh và sau đó bạn có thể làm điều tương tự một lần nữa và bạn có thể nói "implement doc/tickets/001". Và tôi không thể bận tâm đến việc đánh vần nó. Nó sẽ tìm thấy. Và sau đó, bây giờ, những gì tôi đang làm về cơ bản là làm điều tương tự, nhưng mà không để nó biết về ngữ cảnh trước đó. Vì vậy, sẽ khá thú vị để xem nó làm gì với điều này. Tôi đoán là nó sẽ tìm thấy, giả sử nó đã tìm thấy ticket. Vâng, nó đã tìm thấy ticket. Điều đó khá dễ dàng để nó làm. Nó chỉ đang chạy kiểm thử để đảm bảo rằng chúng hoạt động. Và tất cả đều vượt qua. Được rồi. Vậy thì, nó hài lòng.

Các Phương Pháp Agent Loop Cơ Bản và Bài Tập Thực Hành

Một số người, khi chúng tôi mới bắt đầu sử dụng các Ralph loop, họ không làm việc đó trong cùng một trạng thái. Và có một plugin Claude Code đời đầu mà chỉ trong stop hook (đó là thứ chạy ngay bây giờ khi nó dừng chạy) nó sẽ thực hiện lại cùng một lệnh. Và vì vậy, giống như tôi cứ gõ đi gõ lại cùng một thứ mỗi lần, nhưng điều đó không thực sự hiệu quả lắm vì nó không đi được xa. Trong khi bây giờ, điều hữu ích hơn, hoặc điều mọi người bắt đầu làm là chỉ chạy Claude Code trong một kiểu Agent Loop. Vì vậy, họ sẽ làm điều gì đó như while true và sau đó do claude implement ticket 001, đúng không? Và sau đó done. Và sau đó nó sẽ cứ thế mà chạy. Không hoàn toàn chính xác vì tôi đã không làm claude P, nhưng về cơ bản, đó là những gì họ đang làm. Ồ không, bây giờ tôi đã thực sự làm hỏng nó. Đáng lẽ tôi không nên nhấn Enter vào cái đó, đúng không? Được rồi, đây rồi. Vậy đó là những gì mọi người đang làm. Ralph loop ngu ngốc nhất theo đúng nghĩa đen chỉ là một vòng lặp while và nó cứ thế mà thực hiện công việc, siêu siêu dễ dàng.

Vậy thì, bước tiếp theo trong một Ralph loop là gì? Chà, thực tế bây giờ chúng ta sẽ làm là tôi sẽ yêu cầu bạn đạt đến điểm đó và sau đó tôi sẽ nhận câu hỏi từ những người khác. Vậy thì, hãy để tôi chuyển trở lại đây. Tôi hy vọng. Đây rồi. Vâng, tuyệt vời.

Vậy thì, điều tôi muốn các bạn làm là nếu bạn có thể mở máy tính xách tay của mình và lấy codebase từ đây. Nó nằm trên GitHub của tôi dưới tên Pomodoro workshop. Bạn sẽ có thể tìm thấy nó khá dễ dàng. Và bạn đã thấy tôi chạy nó như thế nào. Nó rất đơn giản. Bạn có thể cần thiết lập Python trong máy của mình. Hy vọng điều đó sẽ không quá khó hoặc bạn chỉ cần chạy python Pomodoro.py trần sẽ cung cấp cho bạn lệnh bạn có thể gõ và sau đó là kiểm thử đơn vị để chạy test pomodoro. Siêu dễ dàng. Và sau đó ở bước bốn, tôi muốn bạn khởi động Claude Code hoặc Codeex và tôi muốn bạn thử xây dựng ticket đó và đảm bảo rằng nó hoạt động. Và đó sẽ là một điểm khởi đầu tuyệt vời. Nhưng đừng xây dựng thêm ticket nào nữa. Đừng để nó đưa bạn đi quá xa. Và sau đó, nếu bạn thực sự quen với điều đó và nó giống như một việc hiển nhiên đối với bạn, hãy thử trong Codeex, thử trong một thứ khác. Có thể thử thiết lập một cái gì đó tương tự trong một trong các dự án của riêng bạn. Vậy là một cái gì đó khác biệt.

Bây giờ tôi sẽ nhận câu hỏi trong khi mọi người đang gõ. Tôi sẽ cho các bạn vài phút để thiết lập và sau đó chúng ta sẽ chuyển sang bước tiếp theo. Có ai có câu hỏi, bình luận hoặc suy nghĩ gì không? Tôi có một micro ở đây, nếu mọi người muốn hỏi bất cứ điều gì. Vâng, đây rồi.

>> Nó sẽ hoạt động trong một giây. >> Hy vọng rằng các bạn ở phía sau... Có thể nó không bật. Nó có bật không? >> Vâng, bạn có thể hét lên và tôi sẽ lặp lại. Vâng, điều đó có thể hiệu quả. >> Nó có bật không? Tôi có thể kiểm tra xem nó có bật trước không? >> Vâng, có vẻ như nó đang bật. Lạ thật. Hét lên và tôi lặp lại. Dù sao, ồ, đây rồi. Đây rồi. >> Tuyệt vời.

Thảo Luận về Ralph Loop và Chu Trình Phát Triển Phần Mềm

Tôi đã thử nghiệm một chút với phương pháp BMAD, tôi không biết bạn đã thấy nó chưa. Có một người đàn ông về cơ bản đã viết rất nhiều skill và lệnh để tuân theo một quy trình agile đầy đủ từ... bạn biết đấy, và anh ấy có một tác nhân để xây dựng, kiểm thử... bạn biết đấy, mọi thứ. Và tôi đoán là... vậy thì, bạn đã làm bất cứ điều gì mà sử dụng loại quy trình Ralph loop này để bạn đi qua chu trình đó, bạn đi qua toàn bộ vòng đời phát triển phần mềm ở mỗi giai đoạn rồi phải không?

Vâng. Tôi có thể sẽ đạt được điều đó ở cuối buổi. Nhưng vâng, tôi đã thử một số thứ đó. Nó thực sự thú vị và nó trả lời, nó đặt ra một số câu hỏi rất hay cả về ngữ cảnh và thực sự là giá trị của công việc. Rất thú vị. Vậy thì vâng, chúng ta sẽ nói về điều đó nhiều hơn một chút ở cuối buổi. Vậy nên hãy hỏi lại nếu tôi chưa đề cập đến, cứ hỏi lại câu hỏi đó và chúng ta sẽ tìm ra trong một Ralph loop.

>> Được rồi. Cảm ơn bạn. >> Có ai khác có câu hỏi không? Mọi người đang làm thế nào với việc thiết lập đó? Có ai đã thiết lập được chưa? Hãy vẫy tay nếu bạn đã chạy được nó. Tuyệt vời. Khởi đầu tốt. Có ai đã triển khai được ticket đầu tiên chưa? Hoan hô! Một vài người. Bạn có câu hỏi à? >> Ồ, làm đi. Bạn đã làm xong rồi. Tuyệt vời. Tuyệt. Vâng, tôi có lẽ nên đưa ra các hướng dẫn khác nhau cho việc đặt câu hỏi so với việc đã hoàn thành. Điều đó thật tuyệt. Vậy thì, một vài người đã bắt đầu. Tuyệt vời. Tuyệt vời.

Vậy thì, bạn có thể biết điều này sẽ đi đến đâu. Và nếu bạn đã chú ý đến bản demo trực tiếp, bạn sẽ biết câu trả lời rồi. Tôi sẽ lấy mic từ bạn để bạn không phải giữ nó nữa. Cảm ơn bạn. Nhưng vâng, bạn không cần phải dừng lại ở một ticket. Bây giờ, Matt PCO có ở trong phòng không? Tôi biết anh ấy sẽ làm buổi workshop sau buổi này. Anh ấy là người tôi đã học được điều này. Vì vậy, nếu anh ấy đang xem video, cảm ơn Matt. Đây là một sự khám phá đối với tôi vào khoảng tháng 9 năm ngoái. Anh ấy đã đăng một video YouTube tuyệt vời về cách nâng Ralph loop lên một tầm cao mới, bởi vì khi chúng mới ra mắt, tôi đã thấy chúng trên internet. Tôi đã thử nghiệm và tôi nghĩ, "Vâng, cái này ổn. Nó khá hay. Nó kiểu như phát hiện ra những điều AI có thể làm khi nó đã bỏ lỡ mọi thứ và nó có thể làm tốt hơn một chút, nhưng nó sẽ không thay đổi mọi thứ tôi làm."

Thay đổi quy trình làm việc và những thất bại ban đầu

Và câu trả lời thực sự là nó đã thay đổi hoàn toàn cách tôi làm việc và tiếp cận code hiện nay. Vì vậy, điều thực sự thú vị không phải là làm thế nào để đảm bảo Claude đã hoàn thành một việc này. Mà là điều gì sẽ xảy ra nếu tôi hướng kiểu Agent Loop này vào một loạt các công việc cần làm? Điều gì sẽ xảy ra khi chúng ta hướng nó vào một danh sách toàn bộ các việc cần làm?

Tôi đã thử điều này. Tôi đã viết một bài blog về nó, bài đó hơi đáng buồn vì nó chỉ cho thấy thất bại hoàn toàn trong toàn bộ bài viết, thành thật mà nói. Nhưng nó nói nhiều hơn về việc tôi đã cố gắng làm gì: Tôi đã cố gắng để Claude, tôi nghĩ lúc đó là Claude, chia một dự án lớn thành nhiều ticket khác nhau. Sau đó, tôi yêu cầu nó chia tất cả các ticket đó thành các ticket nhỏ hơn. Rồi tôi yêu cầu nó tìm ra tất cả các phụ thuộc giữa các ticket đó và ghi lại chúng thật cẩn thận. Và sau đó, tôi yêu cầu nó tìm ra cách tôi có thể sử dụng hàng tấn tác nhân khác nhau. [transcript bị gián đoạn]

Thử nghiệm Agent Loop và bài học về quy trình Waterfall

Vậy ý tưởng chỉ tạo ra một Agent Loop để làm một việc dường như hơi vô nghĩa và nó chỉ đang khắc phục một vài hạn chế. Nếu bạn hướng Agent Loop này vào một khối lượng công việc lớn, thì nó sẽ trở nên vô cùng mạnh mẽ. Như tôi đã nói trước đó, tôi đã tạo ra một biểu đồ phụ thuộc phức tạp khổng lồ với hàng tấn ticket khác nhau về cách tôi sẽ xây dựng một hệ thống thực sự phức tạp. Và sau đó, tôi đã khởi động khoảng sáu hoặc bảy tác nhân song song và tôi nói: "Được rồi, bạn làm luồng này, bạn làm luồng kia và bạn lấy ticket này." Và nó đã thất bại thảm hại bởi vì hệ thống đơn giản là không thể biết được cái gì đã được làm và cái gì chưa được làm. Có rất nhiều sự tranh chấp giữa các ticket kiểu như: "Chà, tôi không thể làm gì cho đến khi ticket đó được hoàn thành, vì vậy tôi sẽ làm nó." Và một Claude khác lại nói: "Chà, tôi không thể làm gì cho đến khi ticket đó được hoàn thành, vì vậy tôi cũng sẽ làm nó." Và sau đó cả hai đều triển khai cùng một thứ và đó là một mớ hỗn độn khổng lồ.

Vì vậy, điều đó thực sự rất đáng buồn và tôi đã viết một bài toàn bộ về nó và về cơ bản tôi nói rằng: "Không thể orchestrate một số lượng lớn tác nhân được, bạn không thể làm được." Điều đó rõ ràng là vô lý, nhưng đó là cảm giác của tôi vào thời điểm đó. Và điều thú vị là những gì tôi đã làm một cách hiệu quả là tái tạo các quy trình waterfall được thấy ở một số công ty tồi tệ nhất vào những năm 90, khi tôi bắt đầu tự code, nơi mọi người viết các tài liệu yêu cầu mà bạn phải khó khăn lắm mới mang vào các cuộc họp yêu cầu, nơi toàn bộ dự án được chỉ định từ đầu với tất cả các phụ thuộc phức tạp được giao cho nhóm phát triển và sau đó được cho hai năm để xây dựng. Tôi có thể thấy một số người có lẽ "già dặn" hơn một chút trong phòng đang gật đầu và mỉm cười với tôi khi họ nghe tôi nói về điều này, nhưng vâng, may mắn thay tôi đã tránh được việc làm việc trong bất kỳ nhóm nào trong số đó, nhưng một số bạn bè của tôi đã làm và nó thực sự rất tệ. Và những gì tôi đã làm về cơ bản là tôi đã giao quy trình waterfall đó cho Claude để nó sắp xếp và tìm ra khi nó diễn ra, điều đó thực sự tệ. Vì vậy, không có gì ngạc nhiên khi nó không hoạt động. Nếu con người không thể làm được điều đó, làm thế nào Trí tuệ nhân tạo lại có thể làm tốt hơn?

Đơn giản hóa với Agent Loop tuần tự

Tuy nhiên, thay vì nói với tất cả các ticket của bạn rằng: "Được rồi, cái đầu tiên là quan trọng nhất, sau đó là cái này, và sau đó bạn nên làm cái này, nhưng đừng nghĩ về cái này cho đến khi bạn làm xong cái kia." Thay vì làm điều đó, bạn có thể chỉ cần chạy một Agent Loop nơi bạn nói một cái gì đó như: "Này, chỉ cần chọn ticket quan trọng tiếp theo." Đơn giản như vậy. Chỉ cần tìm ra đây là tất cả các ticket. Chỉ cần tìm ra ticket quan trọng nhất tiếp theo để chạy là gì. Được chứ? Bạn không phải lo lắng về các phụ thuộc. Bạn không phải tự mình tìm ra chúng. Trí tuệ nhân tạo hoàn toàn có khả năng xem xét tất cả chúng, tìm ra các phụ thuộc ngay lập tức dựa trên những gì vừa được thực hiện và tìm ra điều quan trọng nhất tiếp theo cần làm. Điều đó thực sự khá dễ dàng đối với một Trí tuệ nhân tạo. Điều duy nhất nó không thể làm dễ dàng là quản lý quy trình đó theo song song. Nhưng thành thật mà nói, khi chúng ta chạy kiểu Agent Loop này, nếu bạn chạy chúng liên tục, nút thắt cổ chai thường không phải là số lượng tác nhân. Mà thường là bạn chỉ theo kịp Trí tuệ nhân tạo đang làm việc hết lần này đến lần khác.

Vì vậy, hãy quên song song hóa đi một lát và chỉ bắt đầu với một Agent Loop. Nếu bạn có thể theo kịp một Trí tuệ nhân tạo, chỉ một Trí tuệ nhân tạo đang chạy liên tục, bạn sẽ ổn thôi. Đừng lo lắng về song song hóa ngay bây giờ. Đừng lo lắng về Gas Town, hay bất kỳ thứ gì tương tự ngay bây giờ. Mặc dù những dự án đó ấn tượng, bạn có thể bắt đầu với một Agent Loop đơn giản. Không sao cả.

Minh họa Agent Loop thực tế

Vậy, điều tôi muốn bạn làm một lần nữa tại thời điểm này là tôi sẽ nhanh chóng trình bày cách thức hoạt động của điều này cho những người không có máy tính xách tay của mình, nhưng sau đó tôi muốn bạn tự mình thử nó trên máy tính của mình. Vì vậy, một lần nữa, hãy để tôi tìm chuột và sau đó chuyển sang chia sẻ màn hình của mình một lần nữa. Ok, tuyệt vời.

Vì vậy, nếu tôi quay lại Claude, trên thực tế, tôi sẽ quay lại Vim trước và xem thư mục tickets. Vì vậy, tôi có một loạt các ticket ở đây. Tôi có lệnh status, tôi có lệnh stop, tôi có custom durations. Dù sao thì tôi cũng không bao giờ sử dụng cái đó. Tôi sử dụng những thứ khác như labels và tất cả những thứ đó. Tôi có thể cố gắng tự mình tìm ra các phụ thuộc nhưng tôi thực sự không cần. Tôi chỉ có thể đơn giản vào Claude và nói "implement the next most important ticket using TDD principles from doc tickets commit when done." Đại loại như vậy. Được rồi.

Vậy, hãy xem nó làm gì. Vậy là nó đang đọc một loạt các ticket. Như bạn thấy, nó đã đọc số một, hai và ba, và nó đã quyết định rằng cái tiếp theo là số hai. Nó sẽ làm nó. Tuyệt vời. Vậy là nó sẽ làm việc. Bây giờ điều thú vị là khi cái này kết thúc, bây giờ nó đang sử dụng TDD, vì vậy nó đọc test trước. Khi nó kết thúc, hy vọng là, vâng, nó đã đánh dấu là "xong". Rất tốt. Ghi nhớ thời gian đó và sau đó nó sẽ commit. Hãy xem nó có làm không.

Đây là một phiên hoàn toàn mới. Mặc dù tôi nghĩ nó có thể vẫn giữ thư mục làm việc từ phiên trước. Thực ra tôi nghĩ là có. Vậy điều nó chưa làm là commit các thay đổi một cách nguyên tử, đây chắc chắn là điều tôi có thể cải thiện trong lời nhắc của mình, nhưng chúng ta có thể nói về điều đó trong giây lát. Vậy thì hy vọng nó sẽ làm điều đó và sau đó nó sẽ kết thúc. Vâng, tuyệt vời. Nó đã làm được. Tuyệt vời.

Bây giờ tôi có thể làm điều đó một lần nữa dưới dạng một Agent Loop hoặc tôi có thể khởi động lại một phiên mới. Chỉ cần làm tương tự và lần này nó sẽ chọn một thứ khác và sau đó nó sẽ tiếp tục làm việc. Bây giờ bạn có thể hình dung rằng nếu tôi đặt cái này vào một vòng lặp while, thì về lý thuyết nó sẽ xử lý tất cả các ticket theo một cách nào đó. Bây giờ việc đầu ra cuối cùng có phải là thứ tôi muốn hay không lại là một câu hỏi hoàn toàn khác. Nhưng nó chắc chắn sẽ hoàn thành rất nhiều việc liên tiếp. Vì vậy tôi rất muốn bạn thử nó.

Những lưu ý khi triển khai Agent Loop

Vì vậy, nếu bạn đang chạy ứng dụng trên máy tính của mình, hãy xem liệu bạn có thể làm cho nó xử lý nhiều ticket tùy thích trong khoảng thời gian đó không. Vì vậy, nó sẽ có thể tiếp tục. Hãy xem liệu bạn có thể làm cho nó thực sự, có thể viết một tập lệnh bash nhỏ, giống như tôi đã làm, nơi bạn thực hiện while true, và sau đó claude. Tôi sẽ chỉ cho bạn cách làm điều đó một cách nhanh chóng. Thực ra, nếu tôi nhanh chóng git reset để nó có thể bắt đầu lại từ đầu. Và thực tế, tôi sẽ quay lại một hard head nữa. Đó rồi. Tuyệt vời. Vâng, đó là nơi đúng để bắt đầu.

Vì vậy, nếu bạn có thể làm được điều đó thì rất tuyệt. Điều khác mà bạn có thể làm là thay vì sử dụng claude như thế này, bạn có thể thực hiện claude -p. Mọi người có thể thấy rõ không? Nhân tiện, tôi không chắc làm thế nào tôi có thể làm cho nó to hơn. Vâng. Vâng, clear là một lựa chọn tốt. clear claude. Đó rồi. Vậy điều chúng ta có thể làm là thực sự sử dụng claude.p như thế này. Và bạn có thể làm cho nó xuất output bằng cách chỉ cần thực hiện stream JSON hoặc một cái gì đó tương tự. Nó được gọi là gì? Một cái gì đó như stream JSON. Chờ một chút. Hãy xem nào. Tôi nghĩ họ đã gỡ bỏ nó rồi. Thật khó chịu. Không sao cả. Nó sẽ không thấy bất kỳ output nào. Vì vậy, không có gì ngăn cản bạn thiết lập nó như thế này và sau đó bạn có thể làm điều đó.

Vâng. Vì vậy, cách duy nhất điều này hoạt động là nếu bạn muốn chạy nó đúng cách và để nó không dừng lại, bạn phải khá chọn lọc về quyền hạn mà bạn cấp cho nó. Vì vậy, câu hỏi là có lẽ bạn phải chạy claude với toàn quyền để điều này hoạt động. Vâng. Vâng, bạn phải làm vậy. Điều đó phụ thuộc vào những gì bạn đang làm. Vâng, nếu bạn đang làm việc trong một dự án môi trường biệt lập nhỏ như thế này, khả năng nó đi nơi khác để tìm kiếm thông tin là rất nhỏ. Tôi có một dự án gọi là lockbox và mục đích duy nhất của nó là cố gắng ngăn nó làm những điều ngớ ngẩn bằng cách khi nó đọc các mã thông báo không đáng tin cậy có khả năng làm nó đi chệch hướng, nó về cơ bản chỉ ngăn chặn bất kỳ quyền truy cập hệ thống tệp nào hoặc bất cứ điều gì sau đó. Vì vậy, có những cách để quản lý nó.

Vậy điều này đang làm trong nền là bạn không thể thực sự thấy nó làm bất cứ điều gì, bởi vì tôi không có chế độ output đó, nhưng về cơ bản bạn có thể tìm ra để chạy cái này trong một tập lệnh. Và thực ra nếu tôi thoát khỏi đó, hy vọng nó sẽ dừng lại. Đó rồi. Không, hãy cứ tiếp tục. Xin lỗi. Rõ ràng một Agent Loop sẵn sàng cho sản xuất hơn sẽ không trông như thế này. Nhưng bạn có thể thấy nó đã làm một loạt công việc. Vì vậy, nếu tôi đến đây, bạn có thể thấy nó đã bắt đầu lệnh status. Và nó đang xử lý cái đó vào lúc này. Vì vậy, nó đã bắt đầu lại từ đầu. Nó chỉ đang hoạt động.

Vì vậy, có một vài điều cần lưu ý ở đây. Một là phản hồi thực sự rất quan trọng với các Agent Loop. Bạn biết đấy, bạn cần có khả năng làm cho nó chạy theo cách mà bạn có thể biết nó đang làm gì và làm như thế nào. Vì vậy, cái cơ bản siêu đơn giản mà tôi đã cung cấp cho bạn không tốt lắm. Đó không phải là cái tôi khuyên bạn nên chạy trong môi trường sản xuất. Tương tự, bạn cần tìm ra chính xác lời nhắc là gì cho Ralph. Và đó là một điểm thực sự, thực sự quan trọng. Và tôi nghĩ điều tôi muốn bạn làm khi bạn thử điều này là vâng, nó sẽ xây dựng một loạt các ticket liên tiếp, nhưng đồng thời, nó cũng sẽ làm chúng theo cách mà bạn không thích.

Ví dụ, nếu chúng ta chạy test này, chỉ là triển khai điều quan trọng nhất tiếp theo, hãy bắt đầu với cái này, tôi có thể sẽ làm một cái gì đó như chạy simplify là một skill thực sự hữu ích từ Claude của nhóm Anthropic khi hoàn thành và đảm bảo bạn refactor để giảm sự trùng lặp. Bạn có thể hình dung rằng bạn có thể tạo ra một skill khá phức tạp cho điều này. Và tôi sẽ cho bạn thấy skill thực tế của tôi cho điều này ở cuối.

Tối ưu hóa Tác nhân và Lời nhắc

Khi bạn làm việc với điều này, hãy cố gắng tìm ra cách bạn có thể cải thiện những gì nó đang làm. Vì vậy, hãy thử nghiệm, để nó đưa ra quyết định, sau đó để nó viết mã. Sau đó, hãy đọc mã và nghĩ: "À, tôi có thể đã cải thiện gì trong quy trình đó?". Sau đó, đặt lại mọi thứ và cải thiện lời nhắc sau đó. Hãy thử điều đó và xem nó hoạt động như thế nào. Trong khi mọi người đang làm việc trên máy của họ, tôi rất vui được trả lời câu hỏi.

>> Vâng. >> Bạn đã sử dụng các kỹ năng như Superpowers chưa? >> Cái nào? Xin lỗi. >> Superpowers. >> À, kỹ năng Superpowers. Điều tôi đã làm là tôi đã chỉ Claude vào toàn bộ kho lưu trữ (repository) và nói rằng hãy tìm bất cứ điều gì hiện không có trong bộ kỹ năng của tôi và triển khai chúng cho tôi với ngữ cảnh của riêng tôi. Điều đó hoạt động khá tốt. Vì vậy, tôi chưa sử dụng những kỹ năng đó một cách cụ thể, nhưng về cơ bản tôi đã tái sử dụng chúng.

Làm việc với Agent Teams và Điều phối Tác nhân

>> Tuyệt vời. Um, bởi vì tôi sử dụng Superpowers rất nhiều và sau đó tôi chỉ giao các nhiệm vụ như thế này và yêu cầu nó... >> Chạy nhiều tác nhân trong nền. Vâng. Và bạn đã làm điều đó chưa, đó là điều tôi... >> Vâng. Vâng. Vậy thì, điều bạn có thể làm là có một phiên bản agent teams mà tôi nghĩ rằng tôi đã tắt trong phiên bản Claude code cụ thể này. Nhưng điều có thể xảy ra là bạn có thể yêu cầu Claude sử dụng các sub-agent (tác nhân con) trong một đội. Trên thực tế, tôi nghĩ mình có thể bật nó lên nếu tìm thấy agent teams. Đây rồi. Claude code experimental agent teams. Vì vậy, nếu tôi lấy đó và sau đó chạy Claude với tính năng đó được bật, thì bạn sẽ có thể nói: "Sử dụng một agent team để triển khai các dock tickets trong repo này" hoặc một cái gì đó tương tự. Và điều này thực sự không chạy trong T-Max. Vì vậy, um, thực ra có thể điều này sẽ không hoạt động. Vì vậy, tôi có thể thử lại điều này. Xin chờ một chút. Vì vậy, nếu tôi lấy đó và sau đó dán vào đó. Sau đó lấy đó và sau đó chạy T-Max. Và sau đó chạy nó về mặt lý thuyết.

Về mặt lý thuyết, um, điều này sẽ bắt đầu kéo các tác nhân khác lên và bởi vì như tôi đã nói, cố gắng điều phối các Ralph loop hoặc điều phối các tác nhân bằng chính tôi để cố gắng tổ chức tất cả các dependency (phụ thuộc) và complexity (độ phức tạp) thực sự rất, rất khó làm. Nhưng, um, điều bạn có thể làm là chỉ cần giao công việc cho Claude và nó sẽ quản lý tốt hơn nhiều. Như bạn có thể thấy, nó đã quyết định in toàn bộ nội dung, tên tệp và ticket cho từng cái và nó có rất nhiều thứ ở đó. Vì vậy, nó thực sự đã quyết định rằng tất cả chúng đều tuần tự. Do đó, nó nên chạy... nó không nên chạy song song cái nào cả, điều này khá thú vị. Um, và sau đó về mặt lý thuyết nó sẽ bắt đầu một tác nhân triển khai. Hãy xem liệu nó có... tôi nghĩ nó chỉ đang chạy như một sub-agent. Không sao cả. Tôi không chắc điều đó sẽ hoạt động. Không sao cả. Nếu bạn có thể làm cho nó hoạt động, hãy cho tôi biết. Nhưng nhưng nhưng về cơ bản, đó là một tính năng thử nghiệm mới ra mắt vài tuần trước cho phép nó bắt đầu các sub-agent trong Claude để làm mọi việc. Có câu hỏi nào khác trong khi mọi người đang làm việc không?

Định nghĩa "Tốt" và Vòng lặp phản hồi của AI

>> Bạn nói rằng bạn đã xây dựng một Ralph loop với tự động hóa, đúng không? Vậy tiêu chí feedback là gì? Điều gì quyết định đó là một bài báo hay, giống như một framework trang web? Nhưng "tốt" trông như thế nào, nếu nó năng động hay tĩnh? Bạn có đưa nó vào tệp CLAUDE.md không? >> Vâng, câu hỏi rất hay. Điều đó hoạt động như thế nào? Um, câu hỏi là, để nhắc lại nửa đầu câu hỏi đó, khi tôi sử dụng workflow NA10 để xây dựng một Ralph loop cho người tạo bản tin, làm thế nào tôi biết... làm thế nào tác nhân biết điều gì là tốt? >> Làm thế nào tôi định nghĩa "tốt"? Được, câu hỏi tuyệt vời. Vậy thì, về mặt bản tin, tôi đã viết bản tin của mình theo cách thủ công. Vì vậy, tôi biết đại khái mình muốn nó đọc và nghe như thế nào. Tôi cũng đã thực hiện rất nhiều nghiên cứu bằng cách sử dụng một kỹ năng nghiên cứu mà tôi đã xây dựng, chẳng hạn như "những bản tin tuyệt vời". Tôi cũng đã nói những điều như: "Đây là một bản tin mới được viết rất hay" – thực ra tôi sẽ... tôi không làm thế này, tôi thực sự làm thế này: "Đây là một bản tin tuyệt vời mà tôi đã viết, hoặc tôi đã đọc ở đâu đó. Bạn có thể vui lòng tìm ra lý do tại sao nó lại tốt đến vậy và những nguyên tắc biên tập nào đã được áp dụng vào bản tin này để nó thực sự hoạt động hiệu quả không?". Và sau đó tôi sẽ dán bản tin vào, để nó tìm ra điều gì tốt về bản tin, và sau đó tôi sẽ kiểm tra nó và nói: "Vâng, vẫn có yếu tố sở thích của con người ở đây. Bạn không thể hoàn toàn thoát khỏi điều đó."

Mặc dù vậy, tôi cũng có một kỹ năng mô phỏng khán giả, về cơ bản sử dụng một loạt các persona khác nhau cho các khách hàng hoặc khách hàng tiềm năng mà tôi làm việc. Và sau đó tôi sẽ chạy bản tin đã hoàn thiện thông qua đó và nói: "Hãy chạy tất cả những điều này song song, và sau khi bạn hoàn thành, hãy tìm ra cách tôi có thể cải thiện bản tin này hoặc kỹ năng bản tin để làm điều đó." Vì vậy, có một số cách khác nhau bạn có thể làm điều đó. Việc mô phỏng khán giả này siêu thử nghiệm, nhưng nó thực sự hiệu quả và thường sẽ đưa ra những hiểu biết mà tôi chưa từng nghĩ đến. Um, tính cách của tôi là hơi lộn xộn một chút, kiểu cách tôi nói chuyện và giao tiếp thường không giống khách hàng của tôi. Vì vậy, um, tôi có xu hướng cung cấp quá nhiều thông tin cho mọi người và đôi khi kỹ năng của tôi sẽ nói: "Được rồi, có rất nhiều ý tưởng trong cái này, Chris, bạn chỉ cần tập trung vào một điểm chính có ý nghĩa thôi" và tôi nghĩ: "Điều đó thật hữu ích." Vì vậy, um, điều khá hữu ích và thú vị là bạn có thể sử dụng AI để đưa ra feedback (phản hồi) về AI như vậy.

Điều tuyệt vời về dự án cụ thể này mà chúng ta đang viết, cái công cụ pomodoro nhỏ mà mọi người đang viết, là nó là một công cụ dòng lệnh (command line tool) và rất đơn giản để biết liệu nó có hoạt động hay không. Vì vậy, nó hoàn hảo cho một Ralph loop. Và trên thực tế, những công cụ nhỏ mà chúng ta tự xây dựng cho mình, ví dụ như kỹ năng bản tin, hoàn hảo cho loại loop này. Tôi thường sẽ nói: "Tôi muốn cải thiện kỹ năng này. Bạn có thể vui lòng qua lại, viết nội dung, sau đó sử dụng một tác nhân khác để đọc nội dung, quyết định xem nó có tốt không, đưa ra những điều cần cải thiện, sau đó gửi lại và chỉ cần chạy nó như một loop." Um, có một tính năng rất hay... tôi không định nói với bạn về điều này cho đến cuối, nhưng tôi sẽ nói bây giờ.

Tự động hóa Quy trình làm việc với Vòng lặp Tác nhân (Agent Loop)

Um, có một tính năng rất hay trong Claude code gọi là loop (vòng lặp), thay vì phải tự tạo while loop (vòng lặp while) của riêng bạn – trên thực tế, tôi sẽ bắt đầu điều này trong một phiên mới. Thay vì chỉ làm điều này mà bạn phải tự tạo while loop, bạn có thể nói: "Lặp lại mỗi phút, xây dựng ticket tiếp theo từ các doc tickets". Và sau đó, loop sẽ thiết lập một kiểu như bộ hẹn giờ lặp lại. Và như bạn thấy, nó có một cron create tool – đối với những người chưa biết, điều này có nghĩa là "làm gì đó mỗi phút". Đây là ý nghĩa của năm dấu sao đó. Và um, điều nó sẽ làm là nó sẽ theo nghĩa đen chỉ xây dựng ticket tiếp theo. Khi nó hoàn thành, nó sẽ kiểm tra cron một lần nữa, xây dựng ticket tiếp theo. Khi nó hoàn thành, nó sẽ kiểm tra cron một lần nữa và tiếp tục.

Vì vậy, điều đó rất tuyệt để xử lý một loạt các ticket, nhưng nó không chỉ áp dụng cho một tập hợp những thứ bạn đã có từ trước. Nếu bạn nghĩ về nó, tôi sẽ để nó chạy ở đó. Bạn có thể có một loop làm điều gì đó như thế này: "Lặp lại mỗi giờ, kiểm tra Linear để tìm các báo cáo lỗi mới từ nhóm kiểm thử." Um, và sau đó tôi chỉ để nó chạy. Um, ồ, không thể đánh vần. Um, chỉ cần để nó chạy và um, bạn sẽ làm phiền nhóm kiểm thử của mình.

Nhưng dù sao, vấn đề là bạn có thể chạy những loại loop này để hoàn thành công việc theo một cách khá thú vị, tôi đoán là năng động. Mặc dù nó là một loop khá đơn giản, nó chỉ là "tìm thứ tiếp theo, làm thứ tiếp theo". Nếu bạn nghĩ về nó, rất nhiều công việc của chúng ta chỉ là các loop. Nếu chúng ta là nhà phát triển phần mềm, chúng ta làm gì? Chúng ta xem backlog. Chúng ta chọn mục hàng đầu từ backlog. Chúng ta kéo nó sang, bạn biết đấy, "đang tiến hành". Chúng ta gán nó cho chính mình. Chúng ta kiểm tra kiến trúc. Chúng ta tìm hiểu xem liệu có ngữ cảnh nào khác mà chúng ta cần không. Chúng ta xem xét thay đổi. Chúng ta thực hiện thay đổi. Chúng ta gửi PR (Pull Request). Chúng ta um, bạn biết đấy, chờ review. Chúng ta um, bình luận về review. Chúng ta từ chối review. Chúng ta thỉnh thoảng triển khai các thay đổi. Chúng ta gửi PR. Chúng ta merge PR. Sau đó chúng ta trải qua quy trình release. Sau đó chúng ta bắt đầu lại, chọn ticket tiếp theo, và cứ thế. Đó là một loop. Nó khá phức tạp. Um, như chúng ta đã nói cách đây một phút, nhưng nó vẫn là một loop. Có thể nhờ AI chạy toàn bộ loop đó. Không có lý do gì để không làm vậy. Um, và đó là điều thực sự đang xảy ra ở đây khi um, bạn có thể thiết lập... thực ra bạn sẽ không bao giờ thực sự viết điều này. Bạn sẽ có nhiều khả năng viết thứ gì đó như thế này hơn, nơi bạn sẽ nói: "Mỗi giờ, tìm lỗi Linear" và bạn sẽ có một skill mã hóa tất cả những phần thông tin mà tôi vừa cung cấp theo cách sẽ phù hợp với bạn và nhóm cụ thể của bạn.

Sức mạnh của Kỹ năng (Skills) trong AI

Mọi người có ai không biết skill là gì trước khi tôi đi xa hơn không? Không. Tôi nghĩ gần như mọi người đều biết skill là gì. Nếu bạn chưa tìm hiểu skill là gì, thì đây là bài tập về nhà của bạn. Hãy tìm hiểu cách skill hoạt động. Chúng là cách tốt nhất mà chúng ta có hiện nay để đóng gói các phần nhỏ hữu ích của ngữ cảnh và script và di chuyển chúng đến các nơi khác nhau hoặc tạo ra những thứ khác nhau. Ví dụ, tôi có khoảng 50 skill mà tôi đã viết. Um, và sau đó chúng chỉ làm rất nhiều việc khác nhau. Điều tuyệt vời về skill là bạn có thể kéo chúng vào ngữ cảnh của mình bất cứ khi nào bạn cần.

Vì vậy, ví dụ, và tôi sẽ làm điều này. Tôi có thể nói: "Bạn có biết cách tạo hình ảnh bằng Nanabanana không?". Và tôi có thể hỏi AI câu hỏi, và câu trả lời là, à, tôi có thể tra cứu điều này, nhưng nó thực sự biết rằng tôi có một skill hình ảnh cho việc này, khá buồn cười. Nhưng nếu bạn không có, nó sẽ không biết. Nhưng nếu tôi sau đó thực hiện images và nói: "Bạn tạo hình ảnh như thế nào? Hãy cho tôi từng bước một." Thì điều nó sẽ làm là nó sẽ kéo skill hình ảnh đó vào. Um, và sau đó nó cho tôi biết chính xác cách nó làm điều đó. Và tôi thực sự đã viết... thực ra tôi sẽ làm cho nó lớn hơn để bạn có thể thấy... tôi thực sự đã viết một script trong skill đó thực hiện việc tạo ra hình ảnh cho tôi. Um, vì vậy nó đã mã hóa quá trình làm điều đó và nó chỉ chọn bất kỳ mô hình nào nó muốn và nó cung cấp nội dung, và tôi có những template cụ thể mà tôi sử dụng để tạo ra các skill Nanabanana cụ thể. Nanaban thật tuyệt vời. Um, đây là cách tôi đã tạo ra bài thuyết trình mà bạn đang xem. Tôi có một skill slide và một skill hình ảnh hoạt động song song để tạo ra các bài thuyết trình này. Tuyệt vời.

Tác nhân AI Liên tục và Phiên làm việc Kéo dài

Vậy, hãy xem cái kia đã làm gì. Như bạn thấy, nó đã đến ticket thứ sáu. Um, điều tuyệt vời về Ralph loop là bạn cứ tiếp tục làm việc và nói chuyện về điều khác, còn nó đã hoàn thành rất nhiều việc ở đây. Và nó vừa dừng lại ở thời điểm này, nhưng trong một giây, um, hy vọng nếu chúng ta đợi, nó sẽ bắt đầu lại toàn bộ quá trình. Đây rồi. Nó đã có tác vụ được lên lịch để chạy và nó đang hoạt động trở lại. Um, vì vậy bạn chỉ có thể để các phiên Claude code chạy với những loại loop này. Chúng kéo dài khoảng ba ngày, vì vậy bạn phải liên tục làm mới chúng. Um, nhưng bạn có thể làm điều đó và để nó chạy ngay cả trước khi bạn phải viết một script phức tạp hơn để wrap (bọc) Claude để làm một việc gì đó và tất cả những điều tương tự. Um, có câu hỏi nào khác không? Có ai nhận được điều gì thú vị hay bất ngờ từ Ralph loop của mình chưa? Có ai đã thử điều này trong công việc thực tế của mình chưa? Điều này sẽ là thú vị. Vâng.

Trải Nghiệm và Phản Hồi Từ Chụp Màn Hình Claude

Trải nghiệm của bạn thế nào? Bạn còn giữ mic không? >> Vâng. >> Vâng. Vâng. Tôi vừa tạo một Ralph loop chụp màn hình cho một framework kỹ thuật ngữ cảnh trang web. Claude chỉ chụp ảnh màn hình và sau đó xem bố cục vì nó gặp vấn đề với các yếu tố hình học, như khoảng cách. >> Nó hoạt động tốt. >> Tuyệt vời. Hay đấy. Vậy bạn thực sự đang sử dụng tính năng chụp màn hình của Claude để nhận phản hồi, phải không? >> Vâng. Điều đó khá tiên tiến. Không nhiều người đang làm điều đó. Mọi người cũng đang cố gắng sử dụng Playwright và những thứ tương tự để chụp ảnh màn hình, và plugin Claude-in-Chrome đi kèm với Claude cũng có thể sử dụng để điều khiển Chrome và sau đó chụp ảnh màn hình những gì đang diễn ra. Tôi đã đạt được thành công lẫn lộn với điều đó vì nó khá phức tạp để quản lý. Nhưng đối với những ảnh chụp màn hình cơ bản, nó hoạt động thực sự tốt. Đối với hình ảnh và nội dung mà tôi viết, khi nó chạy các kỹ năng hình ảnh đó, nó sẽ luôn xem xét hình ảnh trước để xem có bất kỳ loại AI garble text kỳ lạ nào hay không, và nó sẽ từ chối chúng mà không cần hiển thị cho tôi nếu có vấn đề với hình ảnh. Có câu hỏi hoặc bình luận nào khác không? Vâng, có một câu hỏi ở phía sau đây. Bạn có thể chuyển mic được không? Được chứ? Cảm ơn rất nhiều.

Vòng Lặp Ralph và Hệ Thống Ticketing

>> Tôi nghĩ nó gần với một câu hỏi đã được hỏi rồi. Bởi vì tôi không thực sự quen thuộc với Ralph loop. Nếu tôi yêu cầu tác nhân thực hiện nhiệm vụ một đã được triển khai, liệu nó có thực sự kiểm tra chất lượng của những gì đã được triển khai, hay chỉ kiểm tra xem nó đã hoàn thành hay chưa, hoặc đã được đánh dấu hay chưa? >> Điều đó phụ thuộc rất nhiều vào những gì bạn thiết lập cho nó. Vì vậy, không có gì kỳ diệu ở một Ralph loop. Nó chỉ là một vòng lặp. Vậy, vòng lặp mà tôi đang chạy lúc này – thực ra, tôi có lẽ nên nói loop stop – nếu không, nó sẽ tiếp tục chạy và sử dụng hết hạn mức của tôi. Tôi nghĩ bạn có thể dừng như vậy. Chúng ta hiện đã có một thiết lập Pomodoro khá đầy đủ tính năng. Thôi nào. Đến lúc dừng lại. Vì vậy, nó hoàn toàn phụ thuộc vào những gì bạn viết. Nếu bạn xem xét vòng lặp mà tôi đã thiết lập là gì? Tôi nghĩ là cái này. Tôi chỉ nói "xây dựng ticket tiếp theo". Điều đó rất mơ hồ và không thực sự hữu ích. Vì vậy, nó có thể không thực sự hoàn thành nó. Nó có thể chỉ quyết định xây dựng nó mà không triển khai. Nó có thể không thực sự hữu ích. Vậy, điều thú vị hơn là nếu bạn đến – hãy để tôi làm điều dễ nhất. Nếu tôi tải kỹ năng Ralph của mình, đây là kỹ năng thực tế mà tôi sử dụng cho các Ralph loop. Và điều tôi đang làm, thực ra, cái này hơi lỗi thời. Nhưng cái tôi có ở đây thực sự đang sử dụng một thư mục doc changes. Bạn có thể thấy ở đó, nhưng tôi đang sử dụng doc tickets trong ví dụ này, nhưng tôi đã thay đổi nó trên phiên bản mới nhất. Nhưng cuối cùng, bạn không nhất thiết phải sử dụng một hệ thống ticketing như một flat file trong một repository GitHub. Bạn có thể sử dụng Beads, đó là phiên bản tiếp cận này của Steve Yaki, khá hay. Tôi đã sử dụng nó. Bạn có thể sử dụng Linear, bạn có thể sử dụng Jira, bạn biết đấy, miễn là bạn có thể truy cập nó từ AI, bạn có thể sử dụng bất kỳ hệ thống ticketing nào bạn muốn. Đối với mục đích của bài tập này mà bạn đang thực hiện, tôi thường chỉ sử dụng flat files vì chúng chỉ đơn giản là hoạt động. Bạn không thực sự cần bất kỳ thứ gì phức tạp. Theo cách tương tự, Ralph loop hoàn toàn là những gì bạn tạo ra nó về mặt hiệu quả. Ví dụ, trong trường hợp cụ thể này, tôi đã giao cho nó một vai trò thích hợp theo nghĩa rằng: "Bạn là một kỹ sư trong một relay team. Thực hiện chính xác một thay đổi, sau đó loại bỏ ngữ cảnh và dừng lại. Bắt đầu lại." Đó là ý tưởng. Vì vậy, đối với cái này, nó được thiết kế để chạy trong một shell script nơi nó có một ngữ cảnh hoàn toàn mới mỗi lần bởi vì tôi không muốn ngữ cảnh bị ô nhiễm mỗi lần. Ngày nay, tôi ít quan tâm đến điều đó hơn vì ngữ cảnh lớn hơn rất nhiều so với trước đây. Nhưng khi tôi viết cái này, điều đó rất quan trọng. Như bạn có thể thấy, nó dành riêng cho mã không cần đánh giá của con người trước khi triển khai. Và sau đó, về cơ bản, nó cho bạn biết khi nào công việc nên được đưa vào đó. Thời điểm thích hợp cho công cụ là gì, đọc CLAUDE.md, thay đổi định dạng. Đây là định dạng của một ticket. Đây là tất cả các lý do. Đây là các giá trị trạng thái khác nhau. Tôi yêu cầu nó kiểm tra trạng thái Git để đảm bảo rằng nó không có một working directory. Nó cũng có các trạng thái khôi phục. Vì vậy, nếu nó bị lỗi, nó biết rằng nếu có một dirty working tree, nhưng các bài kiểm tra đều vượt qua, thì có lẽ bạn đã hoàn thành. Nhưng bạn có thể chưa, vì vậy hãy kiểm tra kỹ. Nếu các bài kiểm tra thất bại, thì có lẽ nó đang trong quá trình thực hiện, nhưng bị hỏng, vì vậy bạn nên vứt bỏ nó hoặc xử lý khác đi. Vì vậy, bạn có thể hình dung rằng điều này được xây dựng theo thời gian khi cố gắng làm cho nó hoạt động, cố gắng hiểu người dùng muốn gì, đảm bảo kiểm tra vượt qua là chưa đủ, xác minh hành vi thực tế hoạt động, chạy song song, đánh dấu đã hoàn thành, v.v. Có rất nhiều điều đang diễn ra. Vì vậy, với một Ralph loop thực sự, bạn muốn xây dựng theo thời gian cho dự án cụ thể của mình chính xác cách kiểm tra một thứ gì đó đang hoạt động, chính xác cách chạy kiểm thử trong framework và dialect cụ thể của bạn, cách bạn gửi mọi thứ cho nhóm kiểm thử, cách bạn muốn bình luận về những thay đổi cụ thể, style bạn muốn sử dụng, liệu bạn muốn chọn điều rõ ràng nhất đối với bạn hay điều có ưu tiên cao nhất hoặc kết hợp cả hai tùy thuộc vào cảm giác của bạn ngày hôm đó. Bất cứ điều gì bạn muốn đều cần được mã hóa trong đó. Vì vậy, khi bạn đang viết một Ralph loop, tôi sẽ chỉ cho bạn một liên kết để lấy cái này vào cuối, nhưng không cần thiết phải chỉ sử dụng của tôi hay thứ gì khác. Chỉ cần bắt đầu với của tôi và sau đó nói "sửa cái này cho dự án của tôi" và cho phép nó thay đổi, biến đổi và phát triển. Vài câu hỏi. Vậy, hãy tiến lên. Cảm ơn bạn.

Bảo Mật và Môi Trường Biệt Lập (Sandboxing)

>> Chào. Cảm ơn bài nói chuyện. Bạn có thể nói rõ hơn một chút về chủ đề sandbox vì đó sẽ là điều ngăn tôi chạy cái này. >> Vâng, điều đó hợp lý. Vâng, hoàn toàn. Có một số cách khác nhau để sandbox cái này. Đối với dự án nhỏ cụ thể này, tôi không làm điều đó. Hầu hết công việc của tôi diễn ra trên một VPS nằm tách biệt khỏi máy chính của tôi. Nó có một vài khóa cụ thể cho những gì tôi muốn nó thực hiện. Và nó có thể truy cập các developer tool. Rất nhiều trong số đó nó chỉ có thể truy cập read-only. Nó cũng có thể truy cập email của tôi, nhưng một lần nữa, nó có các quyền truy cập Claw rất chặt chẽ, chi tiết để không gửi email vì điều đó khá quan trọng. Tôi không bao giờ cho phép nó gửi email. Tôi chỉ cho phép nó soạn thảo. Vì vậy, tôi sử dụng kết hợp việc đặt mã vật lý – không phải theo nghĩa vật lý, mà là tách biệt khỏi máy trên một máy khác, một VPS. Tôi cũng sử dụng quyền truy cập Claw cho việc đó. Hệ thống quyền truy cập hơi lỗi, nhưng phần lớn là hoạt động. Tôi đang cố gắng xây dựng Lockbox để làm cho nó tốt hơn nữa. Tôi sử dụng, tôi còn làm gì nữa? Vậy, các khóa mà tôi sử dụng là các khóa riêng biệt. Vì vậy, AI có quyền truy cập vào các khóa riêng của nó mà tôi không sử dụng cho những thứ khác của mình. Vì vậy, tôi có thể xem nhật ký kiểm tra (audit trail) về những gì nó đã thực hiện. Vì vậy, có một số cách khác nhau để làm điều đó. Nếu bạn chỉ muốn chạy mọi thứ đơn giản trên máy của mình, có Docker sandbox, khá hay. Đây là một tính năng mới trong Docker cho phép bạn thực hiện Docker sandbox cla và chạy claw trong sandbox đó. Vì vậy, bạn có thể cách ly nó trong một vùng chứa cụ thể. Điều đó khá mạnh mẽ vì nó cho phép bạn chỉ thay đổi mọi thứ trong một vị trí cụ thể đó trong hệ thống tệp. Thử thách với điều đó là nó vẫn có thể rò rỉ dữ liệu từ một hệ thống của bạn sang một hệ thống khác của bạn. Có một điều gọi là bộ ba chết người (lethal trifecta). Tôi không biết bạn đã nghe về điều đó chưa. Simon Wilson đã đặt ra thuật ngữ này – một ý tưởng rằng nếu bạn có các mã thông báo không đáng tin cậy, quyền truy cập Internet, và quyền truy cập vào dữ liệu bí mật quan trọng mà bạn không muốn mất, thì bạn sẽ mất dữ liệu đó. Về cơ bản, đó là mấu chốt của vấn đề. Vì vậy, bạn phải giảm thiểu số lần những yếu tố đó va chạm trong cùng một ngữ cảnh. Vì vậy, có rất nhiều điều để nói về bảo mật và sandbox nói riêng. Tôi có xu hướng chạy, tôi không chạy với dangerously skip permissions (bỏ qua quyền một cách nguy hiểm), nhưng tôi chạy với một số thứ được bật theo mặc định, nhưng về cơ bản không phải mọi thứ. Và bạn phải xem xét và tìm ra hồ sơ rủi ro của mình là gì và bạn quan tâm đến những điều đó đến mức nào. Và chắc chắn khi bạn đang cấp quyền, những điều chính cần đọc nếu bạn quan tâm là đọc về bộ ba chết người nếu bạn chưa biết về nó. Và hãy suy nghĩ kỹ về lượng quyền lực và quyền hạn bạn đang cấp cho tác nhân của mình, đặc biệt nếu bạn đang sử dụng thứ gì đó như OpenClaw, vốn không an toàn theo mặc định. Tôi biết rằng họ đã làm việc rất nhiều trên OpenClaw để làm cho nó an toàn hơn, nhưng đó vẫn là một thách thức đối với những loại tác nhân đó. Chúng có quyền truy cập vào rất nhiều thứ. Có câu hỏi nào khác không? Vâng.

Xác Thực Bằng Tác Nhân Con (Sub Agent) và Phát Triển Dựa Trên Đặc Tả

>> Ờ vâng, bạn có một bước xác thực trong Agent Loop. >> Điều này có thể là bằng chứng giai thoại, nhưng ngay sau khi tôi thay đổi của mình để sử dụng các tác nhân con (sub agent) ở đây cho bước xác thực, nó bắt đầu tìm thấy các vấn đề. >> À, thú vị đấy. >> Trong khi đó, miễn là bạn thực hiện việc xác thực trong cùng một bước với cùng một ngữ cảnh, nó chỉ tự vỗ lưng và kiểu như, "À, ổn rồi." >> Đó là một điểm thực sự, thực sự hay. Chắc chắn có thiên kiến xác nhận (confirmation bias) đang diễn ra với các tác nhân khi chúng nói, "Ồ vâng, tất nhiên tôi đã viết nó ổn. Nó ổn mà. Tôi đã kiểm tra nó cách đây một phút." Vâng, sử dụng các tác nhân con thực sự mạnh mẽ vì một tác nhân con chỉ bắt đầu với một phần nhỏ ngữ cảnh. Nó không bắt đầu với toàn bộ ngữ cảnh, phải không? Vì vậy, bạn có thể nhận được nhiều sức mạnh hơn từ nó. Ví dụ điển hình từ dự án cụ thể này, một kỹ năng thực sự hữu ích mà tôi đã đề cập trước đó là simplify. Simplify là một kỹ năng đóng gói mã hóa Claw và điều nó làm là nó sẽ xem xét những thay đổi gần đây nhất và nó sẽ chạy ba tác nhân con để cố gắng tìm hiểu xem mã của bạn có nên được cải thiện hay không. Vậy, bạn có thể thấy ở đây những gì nó đang làm. Hy vọng rằng những điều này sẽ được tải và nó có lẽ sẽ tìm thấy một loạt vấn đề. Vâng, một điểm tuyệt vời. >> Bài thuyết trình rất hay. Cảm ơn bạn. Bạn đã thử OpenSpec hoặc kết hợp với OpenSpec hoặc bất kỳ phát triển dựa trên đặc tả (spec-driven development) nào khác chưa? >> Không, thành thật mà nói, tôi không phải là một người hâm mộ lớn của phát triển dựa trên đặc tả. Tôi biết điều đó gây tranh cãi, và tôi sẽ giải thích thêm. Tôi lo lắng rằng phát triển dựa trên đặc tả, ở mức cực đoan, đang đưa chúng ta trở lại những ngày tồi tệ của mô hình waterfall, nơi chúng ta sẽ đặc tả toàn bộ hoặc cố gắng overspecify (đặc tả quá mức) một dự án. Ngay cả với những bộ ticket nhỏ này tôi cũng không cảm thấy thoải mái lắm. Tôi cảm thấy rằng spec (đặc tả) nên mang tính lặp lại hơn nhiều, và những điều chúng ta có thể thấy, nó đã khắc phục một loạt vấn đề, khá hay. Vậy, nó đã tìm thấy – để kết thúc điểm đó – nó đã tìm thấy một loạt vấn đề ở đó, và nó có một số bản sửa lỗi. Vâng, về specs, tôi thích just-in-time specs (đặc tả đúng lúc). Tôi thích ý tưởng xây dựng hoặc suy nghĩ về những gì bạn đang cố gắng xây dựng, tạo ra một loại kế hoạch và mã Claw, và sau đó thực thi nó. Điều đó ổn. Tôi hài lòng về điều đó và tôi nghĩ đó là một bước hữu ích. Điều tôi lo lắng là, tôi lo lắng về những thứ như Kira, nơi họ đã mã hóa điều đó vào công cụ. Tôi lo lắng rằng điều đó gần như sẽ hóa thạch hóa một phương pháp AI hoạt động ngày nay nhưng có thể sẽ không hoạt động nữa khi Mythos cuối cùng ra mắt, phải không? Vì vậy, tôi lo lắng rằng các công cụ đang quá nhanh chóng chuyển sang một cấu trúc công việc cụ thể mà có thể không phải là điều đúng đắn trong tương lai. Vì vậy, tôi thận trọng về điều đó. Tôi nghĩ điều đó là hiển nhiên.

Tầm quan trọng của ngữ cảnh AI và rủi ro từ việc quy định quá mức

Đó là một sự thật hiển nhiên rằng Trí tuệ nhân tạo cần nhiều ngữ cảnh hơn để hoạt động tốt. Vì vậy, chúng ta nên cố gắng cung cấp cho nó nhiều ngữ cảnh hơn. Nhưng tôi nghĩ rằng ý tưởng về việc lạm dụng điều đó và quy định quá mức một dự án là điều cần cẩn trọng, cũng như việc cấu trúc hóa quá mức quy trình của chúng ta dựa trên những gì chúng ta biết về các tác nhân hiện nay. Bởi vì sau đó chúng ta sẽ mắc kẹt với một quy trình do AI điều khiển mới, hoạt động tốt nhất với các tác nhân ra đời vào năm 2025 hoặc 2026. Bạn biết đấy, chúng ta sẽ vẫn sử dụng nó vào năm 2030, và điều đó sẽ là một sự lãng phí thời gian vô ích. Đó là những mối quan ngại mà tôi có về điều đó. Có câu hỏi nào khác không?

Vâng, một buổi nói chuyện tuyệt vời. Anh có đề cập rằng anh không thích việc bị điều khiển bởi thông số kỹ thuật và anh sử dụng Ralph. Vậy về cơ bản, không có con người nào trong vòng lặp đó. Câu hỏi đặt ra là Claude có thực sự cần anh ở đó không? Đóng góp của anh ở đâu?

Vai trò của con người trong vòng lặp AI

Một câu hỏi tuyệt vời. Gần đây tôi đã suy nghĩ rất nhiều về điều này và có một chút khủng hoảng hiện sinh. Tôi không biết người khác thì sao, nhưng tôi tự hỏi: giá trị nào tôi đang thêm vào đây? Chắc chắn không phải với việc viết một Pomodoro timer. Tôi không chắc mình đang thêm bất kỳ giá trị nào cả. Ý tôi là, tôi đã nói rằng tôi hoàn thành nhanh các thông số kỹ thuật đó, và điều đó hoàn toàn vô nghĩa. Tôi không nói rằng tôi không thích lập kế hoạch cho một hệ thống. Điều tôi quan tâm tại thời điểm này, và tôi không có câu trả lời, là thực tế Trí tuệ nhân tạo thường sẽ chọn các thông số kỹ thuật tốt hơn và viết các thông số kỹ thuật tốt hơn tôi có thể viết, và thường sẽ có ý tưởng tốt hơn về hướng mà phần mềm của tôi nên đi so với tôi. Vì vậy, tôi thích ý tưởng thực sự có các Ralph loop tạo ra các Ralph loop khác, hoặc có các Ralph loop theo dõi toàn bộ các tương tác với khách hàng, hoặc thậm chí toàn bộ các startup.

Dự án "Startup" và Vòng lặp AI

Tôi có một kỹ năng mà tôi đang phát triển. Tôi có nên trình bày nó không? Tôi sẽ trình bày nó. Mọi chuyện sẽ ổn thôi. Có gì sai được chứ? Nó được gọi là Startup. Khá tham vọng, nhưng ý tưởng là nó sẽ cơ bản hướng dẫn một sản phẩm thông qua toàn bộ khung làm việc khởi nghiệp. Vì vậy, nó được thiết kế để chạy như một loop. Ý tưởng là nó... Ồ, tôi thấy tất cả các bạn đang chụp ảnh rồi. Giờ tôi đang sở hữu thứ này.

Chết tiệt. Nhưng tôi rất cảm ơn Ash Maru, người đã viết một số tài liệu xuất sắc về chủ đề này. Tôi nên nói điều đó để ghi âm lại. Điều này thực sự hữu ích cho tôi. Tôi đã xây dựng cái này từ tất cả những cuốn sách hay mà tôi đã đọc. Tôi là một người sáng lập startup, đồng sáng lập kiêm CTO. Vì vậy, điều này rất gần gũi với trái tim tôi. Và điều tôi đang cố gắng làm ở đây là cung cấp cho Trí tuệ nhân tạo đủ ngữ cảnh để nó có thể điều hành startup của tôi và có khả năng tìm ra điều quan trọng nhất tiếp theo cần làm, sau đó thực hiện điều đó trong một loop. Bạn biết đấy, và sau đó có một outer loop lớn chạy và nói: "Được rồi, điều quan trọng nhất tiếp theo cần làm là gì? Hãy làm điều đó."

Nó chưa hoạt động, nhưng nó thú vị và đang tiến triển. Và nó thường... điều đầu tiên nó làm, tôi không nghĩ tôi đã có nó để trình bày. Nhưng... ồ vâng, tôi sẽ trình bày nó vì nó rất buồn cười. Xin chờ một chút. Có một lần tôi hỏi nó đang hoạt động thế nào trong một trong các loop của nó, và nó đã tạo ra một bản cập nhật startup dưới dạng một bản ghi nhớ nhà đầu tư mà tôi thậm chí không yêu cầu nó làm. Tôi sẽ cho bạn xem bản demo. Xin chờ một chút, bởi vì nó hoàn toàn xuất sắc. Hãy xem liệu tôi có thể chỉ hiển thị cửa sổ này không. Đây rồi. Air Skills Startup Update.

Và vì vậy, nó nói: "Vâng, tôi cần cung cấp cho anh ấy một bản cập nhật." Vì vậy, những gì tôi đã làm là nó nói về cơ bản đây là những gì chúng ta đã đạt được. Đây là những vấn đề chưa ai giải quyết. Đây là những gì chúng ta biết là có thật. Đây là số lượng... đây là một công cụ quản lý kỹ năng mà tôi đang làm ở phía sau. Đây là tất cả các loại vấn đề. Và nó đã đưa ra tất cả những điều thú vị này có thể đưa vào một bộ tài liệu nhà đầu tư. Thành thật mà nói, điều đó không tệ. Đó không phải là một điều tồi tệ. Tôi nghĩ nó thực sự là GitHub cho các kỹ năng AI, nhưng thôi được rồi. Và bạn biết đấy, ai sẽ trả tiền cho thứ này? Họ sẽ trả bao nhiêu? Những con số đó chắc chắn không đúng. Nhưng điều thú vị là nó đã quyết định làm điều này và tìm ra tất cả những con số này dựa trên điều này, mà tôi nghĩ thật buồn cười và nó khá tự hào về bản tài liệu này. Thành thật mà nói, tôi phải kiểu như: "Chờ một chút, chúng ta chưa... bạn cần suy nghĩ nghiêm túc trước khi tiếp tục đến đó."

Liệu họ có trả tiền cho quản trị kỹ năng không? Tất cả các bạn có trả tiền cho quản trị kỹ năng không? Câu hỏi tuyệt vời. Vẫn chưa chắc. Dù sao, lý do để trình bày điều đó là để chỉ ra rằng Trí tuệ nhân tạo có thể làm được rất nhiều điều và nó chưa làm tốt startup, nhưng điều đó có lẽ là do tệp kỹ năng của tôi, chứ không phải do chính tác nhân. Tôi có cảm giác rằng có rất nhiều thứ có thể sẽ là loop trong tương lai.

Thử thách và Tiềm năng của Vòng lặp AI

Tôi chỉ mới đi đến đoạn này trong các slide của mình. Ôi trời ơi. Xin chờ một chút. Chúng ta đã làm điều đó. Chúng ta đã làm điều đó. Nếu bạn vẫn đang... nếu bạn không chỉ lắng nghe tôi và vẫn đang làm việc với bản demo này, tôi có một vài thử thách dành cho bạn nếu bạn muốn làm điều này. Một là bạn có thể thử nâng cấp định dạng phiếu làm việc của mình. Nếu bạn thích tệp markdown thô, các phiếu tài liệu thì ổn. Nếu bạn muốn chỉ cần gõ bd install hoặc cài đặt beads, điều đó rất dễ dàng. Và nếu bạn muốn Ralph loop hoạt động với beads của mình, hãy thử điều đó. Xem liệu nó có hoạt động không. Không có áp lực nào để bạn phải đạt được bất cứ điều gì trong thư mục nhỏ này. Beads rất tuyệt vì nó chỉ hoạt động trong thư mục của bạn. Và nó chỉ cài đặt một công cụ nhỏ. Vì vậy, đó là một thứ khá hữu ích để thử. Vì vậy, nếu bạn muốn thử một định dạng phiếu làm việc khác hoặc bạn muốn chuyển cái này vào dự án chính của mình và kết nối Ralph loop của bạn với hệ thống quản lý phiếu làm việc của mình để xem cảm giác thế nào. Vâng, có thể chưa gửi phiếu làm việc, nhưng bạn có thể thử điều đó và xem nó dẫn bạn đến đâu.

Đó là một tùy chọn. Cái còn lại là kỹ năng. Bạn sẽ cần tiếp tục nâng cấp và phát triển loop của mình. Loop về cơ bản chứa tất cả kiến thức chuyên môn về cách bạn, với tư cách là một người, sẽ thực hiện điều đó. Bạn có thể bắt đầu từ "thực hiện phiếu làm việc tiếp theo" và bạn có thể nâng cấp lên "thực hiện bước tiếp theo trong startup thống trị thế giới mà bạn đang cố gắng xây dựng" hoặc bất cứ điều gì đó. Bạn biết đấy, nó hoạt động cho tất cả những loại việc đó. Điều siêu thú vị về điều này là tôi ngày càng tin rằng mọi thứ thực sự là một loop. Có lẽ với tư cách là một kỹ sư, tôi chắc chắn đang ở trong một loop trong rất nhiều công việc tôi làm. Có lẽ với tư cách là một quản lý dự án, tôi đang ở trong một loop. Có lẽ với tư cách là một CEO, tôi đang ở trong một loop. Ai biết được? Chắc chắn rất nhiều chu kỳ mà tôi làm việc cũng chạy trong các loop.

Tối ưu hóa Quy trình làm việc cá nhân bằng AI

Vì vậy, tôi có một kỹ năng và nếu bạn đang chạy một Open Claw bot, bạn đang làm một việc tương tự, đó là nó chỉ chạy một tín hiệu kiểm tra định kỳ cứ sau 15 phút. Trên VPS của tôi, nó chỉ khởi động Claude, kiểm tra một vài thứ, kiểm tra lịch của tôi xem có gì đang diễn ra không, và gửi cho tôi tin nhắn Telegram. Có lẽ đó là một loop, và đúng vậy, nó chắc chắn là một loop. Nó là 15 phút. Tôi có một worker loop, mà tôi sẽ cho bạn xem trong một phút. Và tôi có một morning loop nơi mỗi sáng lúc 6 giờ sáng, nó đưa ra một bản tóm tắt đầy đủ về ngày của tôi, tìm ra chính xác những gì tôi nên làm, và cung cấp cho tôi tất cả thông tin tôi cần đã xảy ra qua đêm, tất cả các email đến, tất cả những thứ đó. Worker loop đặc biệt thú vị bởi vì về cơ bản tôi không chắc liệu tôi có thể thực sự trình bày cái này không. Hãy xem liệu tôi có thể tìm thấy thứ gì đó tôi có thể trình bày không. Không, lý do tôi không thể là vì nó có rất nhiều thông tin khách hàng trong đó. Vì vậy, tôi không thể cho bạn xem cái đó.

Nhưng những gì tôi có thể cho bạn xem là, ví dụ, màn hình này tôi có thể cho bạn xem. Vì vậy, nếu tôi nhanh chóng chuyển sang cái này... Đây là một ứng dụng. Tôi sẽ phóng to một chút. Đây là cách tôi điều hành worker loop của mình bây giờ. Đây là một ứng dụng mà tôi đã viết để quản lý dự án. Vì vậy, tôi không có phiếu làm việc trong kho công việc của mình. Tôi có tệp dự án và mỗi dự án là một tập hợp các công việc tôi cần làm. Và sau đó thỉnh thoảng tôi có một... về cơ bản tôi lập trình một hệ thống Kanban theo cảm hứng cá nhân, và một worker sẽ tiếp tục và thực hiện bước tiếp theo trong dự án. Vì vậy, nếu bước tiếp theo trong dự án là viết một email vì nó có một tổng quan hoặc nó đang kiểm tra mọi thứ hoặc nó đang tạo ra các slide cho dự án của tôi, nó sẽ thực hiện bước tiếp theo. Ví dụ, đây là dự án thông số kỹ thuật chuẩn bị hội thảo mà nó đang làm. Và nó có một loạt thông tin đầu mục trông như vậy. Và nó có một số câu hỏi cho tôi. Tôi chưa cập nhật cái này; nó cần được cập nhật. Nó có ngữ cảnh. Nó có một nhật ký quyết định về những gì nó đã làm và tại sao nó làm chúng. Và vì vậy, về cơ bản, đối với mọi điều khác nhau đang xảy ra, nó chỉ đang tìm ra điều tiếp theo.

Nó cũng có ghi chú về các bài nói chuyện khác mà tôi có thể đã trình bày nhưng cuối cùng không xảy ra. Nó có phản hồi từ một hội thảo trước đó tôi đã làm về một chủ đề tương tự, mà bạn có thể nhấp vào. Thực ra, tôi không thể nhấp vào đó. Có một lỗi. Nhưng về cơ bản nó sẽ hiển thị các ghi chú từ một buổi phản hồi. Vì vậy, dự án này tập hợp mọi thứ từ tất cả ngữ cảnh bạn có thể tìm thấy và sau đó thực hiện bước tiếp theo trong một loop. Vì vậy, bạn có thể chạy mọi thứ trong một loop. Bạn có thể chạy tất cả công việc của mình trong một loop. Khi tôi thức dậy vào buổi sáng, thông thường tôi có khoảng 15 hoặc 16 email nháp nơi mọi người đã trả lời tôi, và nó đã cố gắng trả lời chúng. Tôi luôn phải chỉnh sửa chúng. Chúng luôn ổn. Nhưng nó chắc chắn cố gắng bắt đầu lên lịch một số công việc của tôi. Tôi có những quy tắc rất cụ thể về những gì nó có thể và không thể làm. Quy tắc cơ bản của tôi là: điều này có thể đảo ngược mà không gây xấu hổ cho tôi không? Và nếu câu trả lời là không, đừng làm điều đó. Nhưng chỉ cần ghi một ghi chú nhỏ vào dự án và trả lại cho tôi.

Định nghĩa lại vai trò của con người trong kỷ nguyên AI

Vì vậy, gửi email không được phép làm. Tạo một bộ slide như ví dụ này, cái này có thể đảo ngược. Nó không gây ra bất kỳ xấu hổ nào cho tôi. Vì vậy, nó đã tiếp tục làm và đưa cho tôi. Ví dụ, nó không đăng lên LinkedIn cho tôi. Nó không gửi email. Nó không gửi tin nhắn. Nhưng nó chuẩn bị mọi thứ để tôi xem xét. Quay trở lại điểm của bạn trước đó, đây là một câu trả lời rất dài cho câu hỏi của bạn, nó đã khiến tôi thực sự đặt câu hỏi về những gì tôi giỏi và những gì tôi ở đây để làm. Rất nhiều lần tôi đã đến một điểm mà tôi chỉ là người duyệt email, chỉ kiểm tra email và gửi, kiểm tra email, gửi, kiểm tra. Điều đó không giống một công việc đúng nghĩa. Điều đó không mang lại cảm giác tốt. Vậy thì, điều đó có ý nghĩa gì đối với công việc của tôi? Và tôi đã phải đưa ra một quyết định có ý thức. Phần nào của công việc tôi muốn làm và phần nào của công việc tôi không muốn làm? Tôi không muốn là người duyệt email, nhưng tôi muốn là nhà chiến lược. Tôi muốn giúp các tổ chức suy nghĩ kỹ về những gì đang xảy ra với Trí tuệ nhân tạo và làm thế nào để khắc phục nó cho tổ chức của họ. Bây giờ, tôi có thể để Trí tuệ nhân tạo làm một bản nháp đầu tiên tệ, nhưng tôi không muốn xem xét bản nháp của AI. Tôi thực sự muốn tự mình suy nghĩ điều đó. Vì vậy, tôi về cơ bản đã nói, "Đừng làm bất kỳ công việc nào đó. Tôi muốn làm công việc đó. Chỉ cần cung cấp cho tôi tất cả thông tin tôi cần, và tôi sẽ làm công việc đó vì tôi thích công việc đó và tôi giỏi nó." Vì vậy, Trí tuệ nhân tạo có thể làm tất cả công việc vặt, nhưng nó không thể và không nên làm công việc mà tôi giỏi một cách độc đáo. Nhưng bởi vì mọi thứ là một loop và Ralph, điều này đang trở nên quá hiện sinh bởi vì Ralph loop thực sự là tất cả mọi thứ và có thể được sử dụng cho mọi thứ. Chúng ta phải bắt đầu đặt ra những câu hỏi khó về những phần công việc nào của chúng ta mà chúng ta thực sự muốn làm.

Xác định Điểm Dừng cho Tác vụ Không Xác định

Chúng ta muốn đạt được gì từ công việc này? Giờ đây, vấn đề không chỉ là AI có thể làm được hay không làm được nữa. Vâng, có rất nhiều câu hỏi. Một câu hỏi từ khán giả: Với các tác vụ không xác định, bạn nghĩ khi nào nên dừng lại? Bạn có thiết lập các KPIs ngay từ đầu không, hay làm cách nào để bạn biết khi nào công việc hoàn thành?

Đó là một câu hỏi tuyệt vời. Tôi yêu cầu nó dừng lại. Lại một lần nữa, điều này quay trở lại việc nâng cấp loop của bạn và bạn phải cơ bản cho nó biết khi nào nên dừng. Vì vậy, tôi không chỉ có một tệp Ralph loop duy nhất hoạt động cho tất cả các loop khác nhau mà tôi đã trình bày trước đó. Tôi có các tệp khác nhau cho mỗi loại. Ví dụ, tác nhân làm việc nói rằng: "Khi bạn đạt đến một điểm mà context đã cạn kiệt hoặc bạn đã đến một điểm mà có một việc không thể đảo ngược, thì tôi muốn bạn dừng lại và báo cáo." Và "báo cáo" trong trường hợp này có nghĩa là cập nhật tệp project, đó chỉ là một tệp trong repository với những gì bạn đã đạt được và theo cách bạn trình bày cho tôi để xem xét.

Hiện tại tôi đang nỗ lực khá nhiều vào bước trình bày đó, bởi vì tôi chắc chắn không muốn xem lại một diff và chỉ đọc văn bản, tôi thấy điều đó thực sự khó khăn, chỉ vì thường có một khối lượng lớn thông tin và khó có thể dừng lại. Vì vậy, tôi đang yêu cầu nó bắt đầu đưa ra mọi thứ từng bước một theo định dạng slide. Tôi đang cố gắng để nó hiển thị mọi thứ trên giao diện mà tôi đã chỉ cho bạn trước đây. Bạn có thể thấy một chút cách tôi đang cố gắng để nó hiển thị mọi thứ ở những nơi khác nhau, theo những cách khác nhau để nó đạt được những gì tôi cần làm tiếp theo một cách độc đáo. Tôi cho rằng, câu trả lời cho câu hỏi của bạn phụ thuộc vào việc bạn đang làm gì. Tôi nghĩ điều quan trọng nhất là bạn tự mình tìm ra các ranh giới và có khoảnh khắc thực sự tự hỏi: "Tôi thực sự muốn làm gì? Tôi muốn tham gia vào công việc này như thế nào?" Không chỉ là AI giúp tôi làm việc và là người đồng hành, mà bây giờ còn là những phần nào tôi thậm chí không cần biết đến.

Mức độ Tham gia của Con người và Quy trình Tạo Ticket

Một câu hỏi từ khán giả: Bạn đã đề cập đến chủ đề về sự tham gia của chúng ta, vậy chúng ta thực sự tham gia vào giai đoạn nào? Bạn đã nói rằng bạn không thực sự xem xét các diff. Tôi đoán phần quan trọng nhất trong công việc của chúng ta bây giờ là tạo ticket, đúng không? Đầu tiên là xác định tính năng hữu ích nhất cần triển khai và sau đó mô tả theo cách mà bạn dự đoán tất cả các edge cases khác nhau hoặc chỉ giải thích theo cách tốt nhất có thể để kết quả là thứ bạn mong muốn ngay từ đầu. Vậy quy trình tạo ticket của bạn là gì? Một mối lo ngại của tôi là đôi khi bạn không thực sự biết cho đến khi bạn bắt đầu triển khai. Ý tôi là cách chúng ta từng làm, đúng không? Trong quá trình phát triển, bạn gặp phải những trường hợp khác nhau nơi bạn cần một custom logic, bạn cần. Thật khó để dự đoán những điều này ngay từ đầu. Bạn có liên tục cải thiện ticket và triển khai lại chúng hay quy trình của bạn là gì?

Đó là một câu hỏi tuyệt vời. Về cách tôi làm việc, có hai chế độ làm việc được thực hiện thay mặt tôi. Một là công việc hoàn toàn tự động mà chúng ta đang nói đến ở đây, nơi tôi chỉ cần hoàn thành một việc gì đó. Tôi không cần tham gia vào công việc đó khi tôi có một spec hợp lý mà tôi tin tưởng và có cách phản hồi để AI biết rằng nó tốt. Công việc đó có thể tự động xảy ra. Đối với mọi công việc khác tôi làm, tôi làm việc với và trong Claude code. Với hệ thống mà tôi đã trình bày trước đó, ở cuối bất kỳ project nào mà nó đang chạy cho tôi, có một thứ nhỏ ở đây, đây chỉ là một ứng dụng vioded mà tôi đã viết cho riêng mình, không ai khác có quyền truy cập vào nó. Nó có một lệnh vCP nhỏ mà nếu tôi lấy nó và gõ vào cửa sổ terminal, điều đó sẽ khởi tạo một session Claude code mới. Session đó biết cách tìm project đó và kéo toàn bộ project context. Giống như việc tải một skill, nó tải project đó. Nó đọc toàn bộ tệp project và biết mọi thứ khác ở đâu. Tại thời điểm đó, nó đã tải tất cả những gì cần thiết để "siêu sạc" session đó với tôi và sau đó chúng tôi cùng nhau làm việc trên nó.

Ví dụ, về điểm của bạn về việc chỉ định ticket, tôi sẽ có một ticket, có lẽ là một project cho tính năng cụ thể đó, và sau đó tôi sẽ nói: "Được rồi, tải tất cả những gì bạn biết về điều đó," và nó sẽ tải tất cả và sau đó chúng tôi sẽ làm việc qua lại để chỉ định các ticket đó và output sẽ là bất cứ điều gì tôi cần để hoàn thành công việc đó. Vì vậy, nếu tôi đang làm một việc mà tôi muốn tự mình làm một cách hữu ích và độc đáo, đó là khi tôi sẽ tham gia vào một project với Claude code. Và khi tôi nói "tự mình làm", tôi không có nghĩa là tự mình gõ hoặc tự mình suy nghĩ tất cả. Tôi thường có nghĩa là tôi yêu cầu Claude phỏng vấn tôi để đặt câu hỏi để tôi có thể cung cấp thông tin cần thiết để nó hình thành và thực hiện việc viết, vì tôi không thích gõ, nhưng tôi yêu cầu nó kéo thông tin từ tôi để hoàn thành công việc đó. Vì vậy, đó là hai chế độ: việc lặp đi lặp lại qua lại và sau đó là công việc tự động.

Tôi cũng nên chỉ ra rằng tôi không thích đọc diffs, nhưng cuối cùng đó là cách duy nhất để bạn xem xét code. Khi tôi đọc một bản tin, tôi không muốn đọc diff. Tôi muốn đọc bản tin. Trong khi đó, nếu tôi xem xét code quan trọng dành cho người khác, thì vâng, tôi đọc diffs. Tôi không thích làm điều đó. Không ai thích đọc diffs, nhưng tôi kiểm tra để đảm bảo nó hoạt động. Và tôi không thể thấy mình không làm điều đó trong một thời gian, đặc biệt là với code liên quan đến bảo mật. Có lẽ với mythos hoặc chỉ ủy quyền nó. Điều đó sẽ rất tuyệt.

Giải quyết Vấn đề Context Rot và Quản lý Session

Một câu hỏi khác: Bạn xử lý context rot như thế nào? Ví dụ, trong ví dụ của bạn, nơi bạn có một loop và nó thực hiện từng tác vụ một. Liệu cùng một Claude code session có thực hiện tất cả các tác vụ đó không?

Chúng tôi sẽ phải thử nghiệm điều đó với lệnh /loop. Vâng, đúng vậy. Đó là cùng một session. Khi bạn chạy nó như một while loop bên ngoài Claude, thì đó là một session khác. Bạn có những đánh đổi khác nhau với điều đó. Với cùng một session, bạn có tất cả context của các ticket và các thay đổi trước đó. Điều đó có thể hữu ích. Trên thực tế, tôi chưa thấy điều đó hữu ích lắm vì nó có thể chỉ kéo các tệp khi nó chạy. Nếu bạn không gõ bất cứ điều gì vào session, bạn không thực sự thêm bất cứ điều gì vào đó. Vì vậy, không có gì thực sự hữu ích ở đó. Vì vậy, trong quá khứ, tôi có xu hướng thích bắt đầu một context mới cho mỗi session mới. Nhưng loop rất dễ chạy, lệnh /loop rất dễ chạy và nó hoạt sự hoạt động rất tốt, đặc biệt là Opus rất tốt trong việc truy xuất long context. Vì vậy, nó ít gây ra vấn đề hơn rất nhiều.

Quy trình Đánh giá và Quản lý Codebase

Một câu hỏi khác: Bạn đang xem xét các session được thực hiện bởi loop của bạn hay bạn chỉ xem xét diffs trên GitHub?

Đó là một câu hỏi tuyệt vời. Tôi không cho phép bất kỳ tác nhân làm việc nào của mình đóng một project. Vì vậy, tôi sẽ luôn nói rằng nếu bạn nghĩ bạn đã hoàn thành, hãy cho tôi biết những gì đã hoàn thành và tôi sẽ đóng nó lại. Vì vậy, có thể có một danh sách dài các việc đã hoàn thành mà tôi cần tự mình kiểm tra, nhưng tôi muốn là bước verification cuối cùng đó. Lý do tôi thêm điều đó là vì tôi lo lắng rằng mình sẽ bỏ lỡ điều gì đó. Gần đây có một khái niệm mà ai đó đã đặt ra gọi là "cognitive debt" (gánh nặng nhận thức), đó là ý tưởng về việc không theo kịp tất cả những gì codebase của bạn có thể làm hoặc tất cả code trong codebase của bạn. Và điều đó làm tôi lo lắng. Vì vậy, tôi có xu hướng muốn ít nhất hiểu cách code khớp với nhau và cách hoặc cách phần công việc mà tôi đang làm khớp với nhau. Vì vậy, tôi không để AI thoát khỏi việc đưa một thứ gì đó ra khỏi tầm nhìn của tôi mà không có cơ hội để tôi xem xét nó. Nếu không, tôi cảm thấy mình sẽ mất dấu những gì đang xảy ra.

Một người khác phản hồi: Vì tôi đang sử dụng các session để theo dõi các ticket. Vì vậy, thay vì xem xét code hoặc diffs trong code, tôi chỉ xem xét những gì session cụ thể đang làm và tôi thậm chí còn có một hệ thống đánh dấu session nào đang ở trạng thái nào. Bạn có làm theo cách tương tự không?

Tương tự. Vâng, tôi nghĩ các session và trạng thái tôi nghĩ rằng điều đó có thể hoạt động. Tôi chưa có xu hướng sử dụng các session như vậy. Những gì tôi có xu hướng làm với các session là tôi yêu cầu Claude mỗi đêm đi qua tất cả các session trước đó mà tôi đã chạy trong ngày trên tất cả các máy tôi chạy Claude, nó lưu tất cả vào một tệp JSON file cho tôi. Và sau đó tôi yêu cầu nó vừa tìm ra cách hệ thống của tôi có thể cải thiện vừa chỉ những gì tôi đã làm để tôi không quên những gì đã xảy ra. Và vì vậy nó viết một đoạn văn ngắn về những gì tôi đã làm. Và tôi sử dụng điều đó để theo dõi công việc, nhưng nó không hoàn toàn giống như một ticket mỗi session. Tôi khá thích ý tưởng có một context mỗi session. Tôi nghĩ đó là một ý tưởng khá hay và một, xin lỗi, một đơn vị công việc. Tôi chỉ chưa thực hiện được điều đó.

Người khác tiếp tục: Tôi thấy nó thực sự hữu ích vì sau đó tôi có thể quay lại session cụ thể khi suy nghĩ cụ thể đang diễn ra.

Vâng. Và tôi đôi khi cũng làm điều đó khi tôi có một project chạy qua nhiều session, tôi có thể quay lại session trước đó. Thay vì lệnh vCP tôi đã chỉ cho bạn, tôi có thể gõ VCR và nó sẽ làm điều tương tự. Nhưng trên thực tế, tôi thích kỷ luật của việc nó phải tiếp tục lại, bởi vì nếu nó phải tiếp tục lại từ một context mới, điều đó có nghĩa là tất cả thông tin trong session đó thực sự đã được mã hóa vào những nơi khác mà bất kỳ Claude code session hoặc con người nào cũng có thể tìm thấy, điều đó có nghĩa là bạn sẽ có một repository kiến thức phong phú hơn nhiều mà bạn đang làm việc. Vì vậy, có một dấu hỏi xung quanh việc nếu các session thực sự không ephemeral (tạm thời) và bạn có chúng như một kho lưu trữ, liệu chúng có thể truy cập được dưới dạng context trong tương lai không? Nếu bạn coi chúng là ephemeral và đảm bảo bạn nắm bắt mọi thứ trong chúng vào repository của bạn hoặc vào các tệp documentation hoặc bất cứ điều gì, tôi nghĩ điều đó có thể mạnh mẽ hơn. Vì vậy, chắc chắn đáng để suy nghĩ kỹ.

Có vẻ như chúng ta đã đi một chặng đường dài từ việc chỉ viết ticket, nhưng mọi thứ đều tốt đẹp.

Một câu hỏi khác: Cảm ơn rất nhiều về buổi nói chuyện. Tôi có một câu hỏi. Có vẻ như trong loop, một số bước có thể không cần thiết, chẳng hạn như bạn có thể đi đến code và sau đó không tìm thấy gì ở đó.

Tối ưu hóa việc sử dụng mã thông báo và mô hình mới

Y: Và bạn có cân nhắc tối ưu hóa nó bằng cách nào đó hay bạn cứ để mã thông báo bị "đốt cháy"?

Người nói: Không, cứ đốt cháy mã thông báo thôi. Chúng không đắt đến thế. Điều này còn tùy thuộc vào việc bạn đang làm gì. Tôi nghĩ chúng ta đang ở thời điểm mà tôi nên... đây là một vấn đề hoàn toàn khác. Về cơ bản, chúng ta đang ở kỷ nguyên của mã thông báo miễn phí. Bạn biết đấy, tôi có gói đăng ký Max 20. Tôi chắc chắn sử dụng nhiều hơn mức trung bình của một người có lẽ đang trả tiền cho một trong số đó. Vì vậy, tôi nghĩ tại thời điểm này, tôi sẽ ưu tiên tối ưu hóa để giải phóng thời gian của mình thay vì tối ưu hóa việc đốt thêm một vài mã thông báo. Tôi không nghĩ mã thông báo sẽ trở nên đắt đỏ đến thế. Tôi nghĩ rằng các mô hình tiên tiến có thể sẽ rất đắt, nhưng chúng ta có những giải pháp thay thế rẻ hơn hoặc miễn phí thực sự tốt, ngay trước mắt. Chúng không tốt bằng cho loại công việc mới nhất mà chúng ta đang cố gắng thực hiện, nhưng chúng thực sự rất tốt.

Vì vậy, bạn biết đấy, tôi nghĩ có ít nhất một mô hình vừa ra mắt, GLM trông rất hứa hẹn. Đó là ZAI đó. Tôi nghĩ nó vừa ra mắt trong tuần này. Thực sự rất thú vị. Tôi vẫn đang chạy Claude, nhưng điều đó không nhất thiết luôn đúng. Vì vậy, tôi nghĩ tôi sẽ cứ đốt chúng thôi. Như tôi đã nói ngay từ đầu, tôi đã dành một thời gian dài để thực hiện toàn bộ quá trình tối ưu hóa này, nơi tôi làm điều này, nếu bạn không ở đây lúc đầu, thì điều này, bạn biết đấy, tôi đã dành rất nhiều thời gian để cố gắng mày mò với tất cả những thứ này, nhưng cuối cùng, bây giờ tôi chỉ để nó tự chạy. Nó đơn giản hơn nhiều. Tuy nhiên, đôi khi tôi cũng gần hết gói Max của mình. Tôi hơi lo lắng về ý nghĩa của điều đó. Tôi phải tìm cách để có một tài khoản khác.

Y: 200 đô la.

Người nói: Đúng vậy, gói Max 200 đô la một tháng. Yeah. Yeah, tôi khá gần với mức đó mỗi tuần. Hiện tại tôi khoảng 80%. Bắt đầu lo lắng rồi. Vâng, bạn có một câu hỏi. Bạn có muốn đưa mic xuống không? Được chứ? Cảm ơn.

Y: Tôi không xem cái đó nữa.

Người nói: Chào. Tôi muốn hỏi bạn về, cảm ơn rất nhiều vì bài thuyết trình.

Người nói: Về việc fine-tuning (tinh chỉnh) cho lời nhắc.

Y: Bạn có phiên bản hóa nó không? Bạn có bộ dữ liệu nào mà bạn sử dụng để fine-tune toàn bộ Agent Loop của mình không?

Người nói: À, về việc phiên bản hóa Agent Loop nói riêng, như lời nhắc cho Agent Loop đó.

Y: Vâng.

Người nói: Vì vậy, tôi sử dụng kỹ năng cho việc đó. Như tôi đã chỉ ra trước đây, mọi thứ như vậy đều đi vào kỹ năng và tôi nhờ Claude viết kỹ năng cho tôi. Và điều đó được lưu trong thư mục docu skills của bạn trong dự án hoặc nó đi vào thư mục gốc của bạn dưới doclaude skills. Tôi sử dụng GitHub để phiên bản hóa tất cả những thứ đó cho riêng mình. Tôi không nghĩ Git là định dạng kỹ năng đúng đắn cho việc này về lâu dài. Tôi nghĩ chúng ta cần một thứ mới. Do đó, tôi đang cố gắng xây dựng Air Skills, đây là ý tưởng cố gắng làm cho kỹ năng dễ di chuyển và chia sẻ hơn nhiều trong các nhóm mà tôi đang cố gắng tìm cách thực hiện.

Vì vậy, vâng, tôi kiểm soát phiên bản chúng và tôi coi chúng là mã khá quan trọng và tôi không thực sự... tôi có chia sẻ một số trong số chúng, nhưng tôi không chia sẻ tất cả chúng một cách thường xuyên vì chúng có rất nhiều IP (sở hữu trí tuệ) của riêng tôi trong đó và thực sự rất nhiều IP của khách hàng của tôi cũng có trong đó.

Y: Vâng, câu hỏi liên quan nhiều hơn đến hiệu suất của lời nhắc.

Người nói: Vậy thì, bạn đã nói rằng lúc đầu bạn đã cải thiện lời nhắc khi bạn tiếp tục làm việc, nhưng bạn có đang phiên bản hóa quá trình đó không và bạn có đang phiên bản hóa hiệu suất tổng thể của lời nhắc không?

Người nói: Vậy khi bạn nói lời nhắc, bạn có ý là bản thân kỹ năng mà tôi đang sử dụng không?

Y: Vâng. Vâng. Vâng. Vâng.

Người nói: Vâng. Vì vậy, kỹ năng — lời nhắc nằm trong kỹ năng. Vì vậy, khi tôi gõ /bugtracking hoặc /alph, đó là lời nhắc được Claude viết và quản lý bởi Claude, điều đó có nghĩa là toàn bộ tệp đó là lời nhắc và do đó nó được kiểm soát phiên bản. Vì vậy, tôi luôn có một Git chạy trong thiết lập đó và sau đó mỗi khi tôi thay đổi nó, tôi sẽ cập nhật. Nhưng bạn vẫn mang tính chủ quan về cách bạn nói rằng bạn đã cải thiện. Giả sử rằng bộ dữ liệu của bạn sẽ là một vấn đề. Tôi nói vậy và đầu ra mong đợi sẽ là tính năng mới được thêm vào kho lưu trữ.

Y: Vâng.

Người nói: Vậy bạn có thể...

Người nói: Nó thiên về việc làm thế nào để tôi đánh giá liệu nó có tốt không, hay làm thế nào?

Y: Vâng, chính xác. Làm thế nào bạn biết mình đang thực sự cải thiện?

Người nói: Tôi hiểu. Vậy làm thế nào để bạn biết mình đang cải thiện? Đó là một câu hỏi thực sự hay. Tôi stress test các kỹ năng của mình. Với các kỹ năng khác, tôi hỏi: "Liệu kỹ năng này có tốt không? Bạn có thể cải thiện nó không? Bạn có thể viết nó không?" Tôi dành khá nhiều thời gian để mày mò hệ thống và các kỹ năng của mình, có lẽ nhiều hơn mức cần thiết. Tôi nghĩ, hiện tại nó hơi chủ quan. Điều tôi chưa làm, và đây sẽ là một bài tập thực sự tốt, là thử chạy thử nghiệm mù (blind testing), nơi bạn sẽ chạy một bộ ticket với một kỹ năng và một bộ ticket với một kỹ năng khác. Cuối cùng, vì Claude vốn đã không xác định (non-deterministic), tôi nghĩ có một mức độ biến thiên cao với bất kỳ loại thử nghiệm nào như vậy. Vì vậy, thực sự khó để suy nghĩ về cách xây dựng một thử nghiệm hữu ích theo cách đó để biết liệu bạn có thực sự cải thiện hay không. Nhìn chung, bạn càng cung cấp nhiều ngữ cảnh vào lời nhắc của mình, nó sẽ hoạt động tốt hơn cho đến một điểm mà không dễ dàng và rõ ràng để tìm ra nơi nó trở nên tệ hơn. Vì vậy, đó là về việc cân bằng điều đó. Nhưng vâng, tôi chưa thực hiện một quá trình cải thiện khách quan nào. Mặc dù đó là một câu hỏi tuyệt vời. Có một câu hỏi ngay phía sau bạn.

Y: Bạn đang kiểm soát phiên bản các kỹ năng như thế nào?

Người nói: Hiện tại tôi đang sử dụng GitHub. Tôi có một sản phẩm mà tôi đang cố gắng xây dựng, ý tôi là thứ này đây. Nếu bạn muốn kỹ năng của tôi, đó là cách bạn có được nó. Đó là một dự án có tên Air Skills mà bạn đã thấy một bản xem trước ngắn gọn trước đó từ bộ slide của tôi do tác nhân của tôi tổng hợp. Nhưng ý tưởng là bạn có thể đóng gói và quản lý các kỹ năng đó như một đơn vị. Vì vậy, bạn có thể tạo kỹ năng cho tổ chức của mình, bạn có thể tạo gói kỹ năng. Bạn có thể tạo một bộ kỹ năng cho tổ chức của mình, hoạt động cho các nhóm khác nhau trong tổ chức của bạn. Và sau đó tất cả những thứ đó sẽ được phiên bản hóa và cập nhật cho bạn mà không cần mọi người phải học cách sử dụng Git và GitHub. Đó là ý tưởng.

Đó thực sự là một rắc rối vào lúc này. Tôi thấy việc quản lý nó thực sự, thực sự khó khăn. Ngay cả đối với bản thân tôi khi chỉ đưa một kỹ năng lên GitHub. Bạn biết đấy, tôi không thể tưởng tượng bất kỳ ai từ đó... đó là một sự cản trở khá lớn đối với một lập trình viên như tôi. Tôi không thể tưởng tượng những người không phải lập trình viên sử dụng nó. Vì vậy, vâng, tôi đang cố gắng xây dựng thứ này. Vậy thì, hãy chạy lệnh đó trên máy của bạn, bạn sẽ có kỹ năng của tôi.

Y: Xin lỗi, có một câu hỏi ngay đây trước, sau đó đến người tiếp theo. Vâng.

Người nói: Bạn đã đề cập đến điều này một chút, nhưng về việc quản lý kiến thức. Tôi đoán, bạn biết đấy, tôi sử dụng Claude để hỏi "Tại sao VPN của tôi không hoạt động?" Và sau đó tôi học được điều gì đó và tôi muốn ghi lại điều đó, và sau đó tôi có một cuộc họp với ai đó có bản transcript và tôi có nó ở một nơi khác, và tôi có một chút mã mà tôi đang viết và tất cả những ngữ cảnh này đều rất lộn xộn. Bạn có cách nào để suy nghĩ về cách bạn tổ chức tất cả những điều đó không?

Người nói: Vâng. Tôi có một thư mục code (mã) và một thư mục vault (kho dữ liệu), và đó là hai thư mục tôi làm việc. Thư mục code chứa một vài dự án khác nhau mà tôi làm việc theo cách truyền thống hơn. Thư mục vault là nơi tôi thực hiện tất cả các công việc khác của mình và thành thật mà nói, tôi hầu hết bắt đầu làm việc ở đó ngay cả khi tôi đang làm mã và chỉ cho nó biết mã ở đâu. Bởi vì vault chứa vài nghìn tệp với tất cả những thứ khác nhau mà tôi đã thu thập, học hỏi, làm việc với Claude trong vài năm qua. À, không phải với Claude lâu đến thế, nhưng bạn hiểu ý tôi mà.

Tôi bắt đầu với Obsidian từ rất lâu trước đây và tôi đã làm việc trên vault đó trong một thời gian dài. Và với Claude bây giờ, nó chỉ hoạt động trên đó cho tôi. Vì vậy, khi tôi nghiên cứu cách sửa VPN của mình hoặc bất cứ điều gì, nó chỉ lưu một tệp vào đó. Tôi có một số quy tắc cụ thể về cách cấu trúc và quản lý điều đó. Nếu bạn quan tâm nhiều hơn, tôi chưa viết nhiều về điều này, nhưng tôi biết Andrej Karpathy vừa viết về việc sử dụng Mô hình Ngôn ngữ Lớn (LLM) như một wiki. Đó là một bài viết tuyệt vời nếu bạn chưa xem. Tôi biết Minjovich thực ra cũng đã làm một việc về Mepalace của tôi ngày hôm qua. Đó là một phiên bản khác của điều này. Bạn có thể sử dụng cái đó nữa. Có rất nhiều hệ thống khác nhau cho việc đó ngoài kia. Cách tốt nhất để bắt đầu là các tệp Markdown trong hệ thống tệp và sử dụng nó như một wiki. Vì vậy, hãy chạy Obsidian trong một cửa sổ và Claude trong cửa sổ kia và cứ làm việc với nó và lưu mọi thứ khi bạn đi. Và sau đó bạn có một tác nhân sắp xếp và đưa các vault đó vào các thư mục hay gì đó tương tự?

Người nói: Vâng. Điều đó tùy thuộc vào phương pháp của bạn. Tôi sử dụng phương pháp Zettelkasten, tức là phương pháp mà bạn có một ghi chú cho mỗi ý tưởng. Vì vậy, bất kỳ ý tưởng nào cũng chỉ đi vào một thư mục phẳng. Sau đó, tôi có một mục /projects chứa tất cả các dự án mà bạn đã thấy, bao gồm một dự án cho bài thuyết trình này. Đây là đơn vị công việc của tôi cho một tác nhân mà chúng tôi làm việc cùng nhau. Nó làm rất nhiều việc và sau đó tôi làm một số việc và sau đó nó làm một số việc. Tôi có các transcript ở đó. Tất cả các cuộc gọi mà tôi đã từng ghi lại đều được lưu ở đó.

Và tôi sử dụng một công cụ có tên Leanne, một công cụ nhúng dòng lệnh (CLI embeddings tool). Vì vậy, về cơ bản, nó chỉ chạy các nhúng trên toàn bộ tất cả văn bản trong kho lưu trữ, tất cả các transcript, tất cả các liên kết tôi đã từng lưu, bao gồm tất cả nội dung. Nó rất lớn. Và sau đó nó có thể tìm thấy mọi thứ một cách hữu ích và dễ dàng ở đó. Vì vậy, thời điểm tốt nhất để bắt đầu điều đó là hôm nay bởi vì nó chỉ mất nhiều năm để tổng hợp lại. Tôi cần viết nhiều hơn về điều đó. Có câu hỏi nào khác không? Vâng, một câu hỏi ở đây.

Y: Bạn nói bạn gặp khó khăn khi phiên bản hóa các kỹ năng của mình. Tôi mới sử dụng kỹ năng được một tháng, vì vậy tôi không biết về khó khăn này. Bạn có thể giải thích khó khăn đó là gì không?

Người nói: Tôi có thể... tôi chắc chắn có. Có ai ở đây gặp khó khăn với việc quản lý và sử dụng kỹ năng của tôi chưa? Có ai khác không? Vâng, khá nhiều người. Vì vậy, vâng, đó là một điều mới nổi. Không có gì ngạc nhiên khi bạn chưa trải nghiệm nó nếu bạn chưa sử dụng nó lâu. Điều tôi thấy là nếu bạn chỉ tự mình sử dụng chúng, việc tạo tệp kỹ năng và quản lý chúng khá đơn giản. Đặt chúng lên GitHub cũng khá đơn giản. Đó là symlink và kho lưu trữ GitHub. Nó ổn. Điều khó khăn là cách bạn chia sẻ điều đó.

Vậy làm thế nào bạn có thể chia sẻ một kỹ năng? Được thôi. Nếu bạn muốn sử dụng kỹ năng MPX, bạn phải đặt nó vào kho lưu trữ GitHub riêng của nó. Điều đó cảm thấy khá nặng nề chỉ cho một kỹ năng. Tôi sẽ phải có 50 cái để chia sẻ tất cả các kỹ năng của mình. Vì vậy, điều đó không thực sự hiệu quả. Sau đó, nó giống như, được rồi, nếu tôi không muốn làm điều đó, tôi chỉ gửi cho họ tệp kỹ năng ư? Tôi gửi cho họ tệp zip ư? Ý tôi là, tôi không thể nghĩ ra một cách tốt hơn để làm điều đó. Tôi có phải có một submodule trong thư mục kỹ năng của mình cho mỗi kho lưu trữ Git mà tôi chia sẻ kỹ năng không? Điều đó hoàn toàn vô lý. Vì vậy, tôi nghĩ ý tưởng của Claude có một số thứ liên quan đến thị trường plugin nơi bạn có thể có một plugin có một loạt kỹ năng. Đó là cách tốt nhất, nhưng sau đó bạn đang phiên bản hóa plugin, không phải kỹ năng. Vì vậy, đó có lẽ là cách liền mạch nhất. Nó chỉ... nó không hoạt động tốt lắm.

Quản lý Đóng góp Kỹ năng và Vấn đề Chưa có Lời giải

Ngoài ra, có một thách thức là nếu ai đó đóng góp vào kỹ năng của bạn, bạn có muốn chấp nhận thay đổi của họ hay không? Điều này sẽ phụ thuộc vào bản chất của đóng góp. Chúng có chỉ áp dụng riêng cho họ hay là những thay đổi có thể được tích hợp chung, và điều đó tùy thuộc vào kỹ năng cũng như người đóng góp. Vì vậy, bạn phải quản lý việc đó. Liệu bạn có nên duy trì một backlog cho mỗi kỹ năng với các ticket để cải thiện chúng? Bạn có thấy rằng đây đều là những vấn đề chưa có lời giải? Đóng góp của tôi đang cố gắng giải quyết một số trong số đó, nhưng đây là những vấn đề lớn mà chúng ta vẫn chưa tìm ra cách xử lý.

Còn câu hỏi nào khác không? Có một câu hỏi ở phía sau cùng. Nếu có mic thì thật tuyệt. Cảm ơn. Một, hai, một. Được rồi, nó hoạt động. Câu hỏi của tôi là làm thế nào chúng ta có thể mở rộng quy mô cách tiếp cận này với Ralph loop cho một đội sản xuất thực tế, ví dụ như ba kỹ sư? Làm thế nào để điều phối, làm thế nào để hợp tác? Anh có ý tưởng hay kinh nghiệm nào về cách tổ chức không?

Mở rộng Quy mô Ralph Loop trong Đội nhóm Lớn

Đó là một câu hỏi lớn. Để đảm bảo tôi đã hiểu đúng, làm thế nào để mở rộng quy mô cách tiếp cận này để bạn có thể điều phối toàn bộ đội nhóm bằng phương pháp Agent Loop này? Vâng, đúng rồi, với tất cả các ticket và kỹ năng. Hoàn toàn chính xác. Đúng vậy, nó khó khăn. Tôi nghĩ rằng những đội nhóm mà tôi thấy phương pháp này hoạt động hiệu quả là những đội chủ động trong việc cập nhật ticket. Điều tuyệt vời là nếu bạn kết nối hệ thống ticket của mình với Trí tuệ nhân tạo, nó rất giỏi trong việc cập nhật. Vì vậy, bạn chắc chắn nên làm điều đó. Hãy đảm bảo rằng bạn yêu cầu ticket và chuyển nó vào cột "đang thực hiện" trước khi bắt đầu công việc. Và đảm bảo rằng không ai khác vừa làm điều đó trước khi bạn bắt đầu. Bạn hiểu ý tôi chứ? Điều đó thực sự quan trọng để tránh xung đột. Đây luôn là những vấn đề với các đội nhóm lớn hơn.

Tương tự như vậy, có một vài điều gây tranh cãi. Cũng giống như cách Ralph loops hoạt động rất hiệu quả bằng cách chỉ thực hiện một việc trong một vòng lặp và khá tuần tự. Bạn biết đấy, rất có thể chi phí điều phối trong các đội của chúng ta là do chúng ta có quá nhiều người trong đội và có lẽ chúng ta nên có các đội nhỏ hơn nhưng nhiều đội hơn, phải không? Vậy có lẽ nếu bạn đang cố gắng khiến 10 người điều phối và sử dụng Trí tuệ nhân tạo cùng với Ralph loops và tất cả những thứ đó, thì điều đó sẽ không hiệu quả. Có lẽ bạn chỉ cần ba người, và có thể đó là cách để điều hành dự án đó, sau đó bạn chia nhỏ ra và để bảy người còn lại làm việc khác hoặc bất cứ điều gì. Điều đó có hợp lý không?

Xác định và Khắc phục Nút thắt

Vì vậy, việc loại bỏ vấn đề là bước đầu tiên và đảm bảo rằng bạn đã sử dụng các cơ chế điều phối hiện có là bước thứ hai. Và sau đó, hãy thử và tìm ra những nút thắt là gì. Hãy thực sự, bạn biết đấy, hãy giỏi trong việc đánh giá hồi cứu với những vấn đề này. Tôi nghĩ rằng các buổi đánh giá hồi cứu trong các đội nhóm thường khá yếu ớt. Nó giống như "chúng ta nên giảm bớt điều gì? Chúng ta nên làm nhiều hơn điều gì?". Đó chỉ là một công thức cho sự lặp lại, nhiều hơn nữa của cùng một thứ. Và chỉ thay đổi từng chút một, điều này có thể tốt, nhưng cuối cùng thì điều này đòi hỏi một sự suy nghĩ lại hoàn toàn triệt để. Vì vậy, hãy thực sự tỉnh táo trong việc đảm bảo rằng các buổi đánh giá hồi cứu của bạn đang thay đổi những điều thực sự về cách bạn làm việc hoặc có không gian để thử nghiệm. Hãy thử sử dụng Ralph loop cho tất cả công việc của chúng ta trong một tuần và xem điều gì xảy ra, bạn biết đấy? Và nếu nó không hiệu quả sau hai ngày, thì cũng không sao.

Và nếu bạn là người đang ở vị trí lãnh đạo và có khả năng tài trợ cho loại công việc đó, thì đây chính là ý nghĩa của việc cố gắng chuyển sang Trí tuệ nhân tạo. Nếu bạn muốn chuyển đổi đội nhóm của mình, bạn sẽ phải tài trợ cho những thử nghiệm như vậy và chấp nhận thất bại, bởi vì – tôi đang nói chuyện với các nhà lãnh đạo ở đây một lát – bởi vì nó sẽ rất lộn xộn và nó sẽ thất bại rất nhiều. Nhưng nếu bạn muốn một sự chuyển đổi thực sự, đó là cách duy nhất để đạt được nó. Bạn phải cho đội của mình không gian để thử nhiều điều khác nhau. Vì vậy, hãy cung cấp cho họ sự hỗ trợ. Vâng, đó là một câu hỏi lớn và phức tạp.

Tôi nghĩ nếu bạn có khả năng và quyền tự quyết để thử và xem nó sẽ đi đến đâu. Có một khái niệm hoàn toàn riêng biệt được gọi là lý thuyết về các ràng buộc mà tôi chưa hề đề cập, đó là ý tưởng rằng trong bất kỳ đội nhóm nào, trong bất kỳ hệ thống nào, luôn có một nút thắt. Luôn có một nút thắt lớn nhất. Nếu bạn không xử lý nút thắt đó, tất cả những công việc khác mà bạn có thể làm để tối ưu hóa và cải thiện hệ thống đều vô nghĩa và trên thực tế có thể phản tác dụng. Đây là lý do tại sao một số đội khi sử dụng công cụ Trí tuệ nhân tạo và các công cụ Trí tuệ nhân tạo tiên tiến như Ralph Loops – mà về cơ bản chỉ là Trí tuệ nhân tạo hoặc những gì chúng ta đang làm bây giờ nhưng ở mức độ cao hơn – một số đội khi triển khai lại thực sự làm việc chậm hơn. Một số đội làm việc nhanh đáng kinh ngạc, một số lại chậm. Tại sao vậy? Bởi vì họ không giải quyết ràng buộc (hay nút thắt). Ràng buộc trong các đội đó có thể là quy trình xem xét hoặc quy trình phát hành. Nếu bạn phát hành code một lần mỗi tháng, và bạn đang gửi 200 Pull Request (không phải 20) trong lần phát hành đó, bạn nghĩ điều đó sẽ diễn ra như thế nào? Bạn biết đấy, nó sẽ không suôn sẻ. Vì vậy, đó là lý do tại sao các đội làm việc chậm hơn, bởi vì điều họ cần làm là sửa quy trình phát hành của họ, chứ không phải tốc độ viết mã. Vì vậy, hãy luôn khắc phục điều lớn nhất là nút thắt trước tiên. Sau đó tìm ra nút thắt di chuyển đến đâu trong hệ thống, và điều đó không thể đoán trước được. Nó ngẫu nhiên. Vì vậy, bạn phải tìm ra điều đó. Sau đó di chuyển và sửa chữa điều tiếp theo trong hệ thống. Để biết thêm về điều đó, hãy đọc cuốn "Mục tiêu" (The Goal) của Eliyahu Goldratt từ năm 1984, không hơn không kém. Đó là một cuốn sách tuyệt vời, một cuốn sách tuyệt vời.

Quản lý Microservice và Repository với AI

Còn một câu nữa. Có câu hỏi nào ở đây không? Có mic khác không? Mic đâu rồi?

Tôi có mic. Ồ, bạn có mic. Tuyệt vời. Cứ tiếp tục. Nhân tiện anh đang nói về phần ràng buộc, điều này khiến tôi nhớ rằng tôi là một phần của đội Trí tuệ nhân tạo, và chúng tôi có một đội NI và họ viết rất nhiều microservice nằm trong các repository khác nhau. Được rồi. Làm thế nào để giải quyết việc viết code bây giờ, khi mà liệu nó có phải là một monorepo lớn hay là nhiều repo nhỏ? Bạn phải thử nhiều cách khác nhau và xem sao. Tôi không nghĩ rằng kiến trúc Git, dù là nhiều repo hay một repo, thực sự quan trọng. Bạn luôn có thể bắt đầu Trí tuệ nhân tạo của mình trong một thư mục nằm trên tất cả các repo khác của bạn và làm cho nó hoạt động. Nó làm rất tốt việc đó. Vì vậy, điều đó không sao cả. Tôi nghĩ câu hỏi lớn hơn là các mô hình điều phối trong các đội nhóm và dịch vụ của bạn là gì? Ai chịu trách nhiệm về điều gì? Và điều đó thay đổi như thế nào với Trí tuệ nhân tạo? Tôi nghĩ đó là một thách thức thú vị hơn.

Lý do chính tôi hỏi điều này là vì một số microservice phụ thuộc vào những microservice khác.

và sau đó bạn phải phát hành một trong số chúng, bạn cần phát hành một tag và sau đó cập nhật cái khác, và điều đó chỉ là... Vâng, tôi nghĩ điều mà Trí tuệ nhân tạo sẽ làm là nó sẽ phơi bày tất cả những nơi mà quy trình đó không hiệu quả, bởi vì nó sẽ làm mọi thứ nhanh hơn. Điều đó có nghĩa là nếu bạn đang thấy những nút thắt mà bạn gặp phải sự phụ thuộc giữa các microservice của mình, thì đoán xem, đó chính là nút thắt lớn nhất của bạn, do đó bạn phải khắc phục nó. Vậy làm thế nào để khắc phục nút thắt đó? Chà, bạn có thể thử một hệ thống phát hành nguyên tử hoặc bạn có thể xây dựng một thứ gì đó sử dụng Claude và một Ralph loop để tìm ra cách điều phối việc phát hành trên nhiều repo thành công hơn. Tôi không biết. Nhưng đó là điều bạn sẽ làm. Đó là nơi bạn cần tập trung. Đừng làm bất cứ điều gì khác cho đến khi điều đó được sửa chữa. Nếu đó là nút thắt.

Phản hồi và Câu hỏi Thêm

Vâng, có một câu hỏi ở đây. Bạn có muốn chuyển mic không? Vâng. Tôi phải nói rằng tôi đã gần hết nội dung rồi. Có lẽ điều này đã rõ ràng từ nửa giờ trước. Điều duy nhất khác mà tôi có, ý tôi là tôi có một slide Hỏi & Đáp. Nếu bạn muốn rời đi, bạn có thể, nhưng bạn cũng có thể ở lại để đặt thêm câu hỏi. Tuy nhiên, tôi rất mong nhận được phản hồi. Mã QR này là thứ duy nhất tôi tự thêm vào các slide này. Nếu bạn có thể điền vào, điều đó sẽ rất tuyệt vời. Cảm ơn. Nó chỉ mất ba phút, bốn câu hỏi thôi. Nó chỉ giúp tôi cải thiện và đảm bảo rằng tôi thực hiện tốt các hội thảo này trong tương lai. Đó cũng là LinkedIn của tôi. Tôi đăng rất nhiều nội dung ở đó. Hãy kết nối với tôi. Bạn có thể, trong trường hợp bạn có ý kiến về những điều này, hãy không đồng ý với tôi. Tôi yêu sự bất đồng. Tôi thích khi mọi người nói, "Chắc chắn rồi Chris, điều đó thật điên rồ. Anh không nên làm vậy." Tôi yêu những bình luận như vậy. Bởi vì nó thực sự giúp tôi suy nghĩ và cải thiện, điều mà tôi thích làm, và bởi vì Ralph Loops đang làm tất cả các công việc khác của tôi. Vì vậy, tôi không còn gì để làm cả. Tuyệt vời. Cảm ơn. Tôi chỉ muốn đặt điều đó lên đó. Tôi rất vui khi tiếp tục trả lời câu hỏi. Nhưng nếu mọi người muốn rời đi, thì đó có thể là thời điểm tốt. Cứ tự nhiên.

Công cụ Orchestration Đa Tác nhân và Lý thuyết Ràng buộc

Câu hỏi của tôi liên quan đến các công cụ orchestration đa tác nhân. Tôi tò mò liệu anh đã thử những thứ như Gasttown của CVG hay chưa, hoặc vâng,

có một người khác làm kiểu MCP agent mail. Vâng, có một số thứ thực sự hay ho và thú vị. Tôi vẫn nghĩ chúng ta đang ở trong thời kỳ "miền Tây hoang dã" với Gasttown và những thứ tương tự, nhưng chúng ta thực sự không biết nó sẽ diễn ra như thế nào. Tôi đã thử Gasttown. Tôi không thực sự làm cho nó hoạt động được, nhưng đó là vào giai đoạn khá sớm. Đối với tôi, tôi cảm thấy rằng khía cạnh orchestration tác nhân là, tôi nghĩ rằng chúng ta làm mọi thứ phức tạp hơn khi giả định rằng chúng cần phải song song. Tôi khá thích ý tưởng bắt đầu với một Agent Loop trước tiên. Tôi không cảm thấy cần phải để Trí tuệ nhân tạo của mình làm nhiều việc cùng lúc trước khi tôi có thể khiến nó làm tốt một việc duy nhất. Chà, điều đó lại quay trở lại với lý thuyết về các ràng buộc. Tôi không nghĩ rằng tốc độ, bạn biết đấy, số lượng mã thông báo mỗi giây là nút thắt. Tôi nghĩ rằng đó là khả năng của chúng ta trong việc chỉ định những gì chúng ta muốn và xem xét những gì Trí tuệ nhân tạo đã làm. Vì vậy, nếu đó là nút thắt của tôi, tôi không muốn giới thiệu thêm tác nhân. Vì vậy, tôi không dành nhiều thời gian với những công cụ đó vì lý do đó. Tôi cảm thấy chúng đang giải quyết một vấn đề mà chưa nhiều người gặp phải. Vâng. Vậy thì... Xin chào. Vâng. Vâng. Không chỉ vì tốc độ, mà ví dụ, tôi không biết anh đã thử nghiệm với MCP agent mail chưa. Vậy nên các tác nhân có thể khóa tệp và giao tiếp với nhau để họ không giẫm chân lên nhau, và bạn có thể sử dụng các mô hình khác nhau như Claude Opus và Codecs cùng làm việc trên cùng một dự án để bạn có được những "bộ não" khác nhau cùng làm việc trên một dự án. Hay đấy. Vâng. Không, tôi chưa thử, tôi nghĩ tôi đã nghe nói về nó nhưng chưa thử. Nghe có vẻ là một ý tưởng siêu thú vị, giống như ai đó đã đề cập trước đó về các tác nhân phụ cố gắng nhìn nhận mọi thứ từ một góc độ khác. Tôi đã nhận được rất nhiều giá trị khi làm điều đó. Tôi đã đề cập trước đó về phương pháp mô phỏng khán giả của mình, về cơ bản, cách nó hoạt động là nó lấy các bản ghi và cả các phản hồi khảo sát trên trang web của tôi, và nó tạo ra các chân dung và khiến các chân dung đó suy nghĩ khác biệt trong các tác nhân phụ song song để có cái nhìn mới mẻ về nội dung từ các góc độ khác nhau. Vì vậy, toàn bộ ý tưởng về việc có hai thứ khác nhau và hai mô hình khác nhau trong trường hợp đó là một điều siêu thú vị. Tôi nghĩ chúng ta sẽ thấy nhiều hơn điều đó. Tôi thấy rất nhiều giá trị trong nó. Chúng ta chắc chắn biết rằng chúng khá giỏi trong việc tự đồng ý với chính mình, và bạn thường nhận được một quan điểm phản biện tốt hơn nếu bạn loại bỏ ngữ cảnh và xem xét lại nó. Vì vậy, một nguyên tắc tuyệt vời. Tôi nghĩ rằng bộ công cụ vẫn còn rất sơ khai, điều mà tất cả chúng ta đều biết, nhưng chúng chắc chắn là những ý tưởng thú vị. Có một câu hỏi ngay phía sau bạn. Vâng, cứ tiếp tục đi. Tất cả đều bật lên rồi. Nhân tiện, bài nói chuyện rất tuyệt vời. Cảm ơn anh.

CI/CD và Kiểm thử Tự động cho AI

Hỏi: Bạn đặt tầm quan trọng như thế nào vào các giai đoạn phát triển, khi bạn dành nhiều thời gian để xây dựng context, tạo các ticket và có một hệ thống để chạy chúng theo trình tự, rồi đẩy lên? Bạn tập trung hay nhấn mạnh bao nhiêu vào CI/CD, chạy các bài kiểm tra tự động, linting? Liệu điều đó có mang lại cho bạn sự tự tin để giảm lượng mã bạn cần xem xét không?

Đáp: Chắc chắn rồi. Ờ, vừa có vừa không. Điều đó phụ thuộc vào loại mã là gì. Tôi nghĩ, trước hết, CI/CD và kiểm thử tốt là hoàn toàn cần thiết. Linting và tất cả những thứ đó. Nếu bạn muốn một tác nhân AI làm tốt công việc cho bạn, tại sao bạn không cung cấp cho nó những công cụ đó để giúp nó làm việc hiệu quả, phải không? Giống như cách con người làm việc tốt hơn nhiều khi họ có linting, CI/CD và các bài kiểm tra tốt. Điều đó hoàn toàn giống nhau. Nó cũng tương tự với các cơ sở mã sạch. Bạn biết đấy, ừm, đáng để thực hiện tất cả công việc đó để làm cho một AI hoạt động tốt. Vì vậy, điều đó mang lại cho tôi sự tự tin hơn vào những gì tôi đang làm.

Hạn chế của AI và Vấn đề Bảo mật

Đáp (tiếp theo): Thử thách là nếu AI viết các bài kiểm tra và cũng viết mã, thì có khả năng nó đã làm sai điều gì đó về những gì bạn đang cố gắng xây dựng. Thường thì nó không mắc những lỗi hiển nhiên. Những gì nó làm sai là nó hoàn toàn hiểu sai một tính năng, xây dựng và nói, "Vâng, ổn thôi." Và sau đó deploy nó, rồi tôi sẽ nói, "Ôi chúa ơi, tôi không... tôi không hoàn toàn cho phép nó deploy tất cả mọi thứ." Chỉ với các dự án pre-release tôi mới làm điều đó. Nhưng ừm, nhưng vâng, ừm, điều đó mang lại cho tôi sự tự tin trong việc biết rằng thứ đó, tôi đoán, về mặt chức năng là chấp nhận được để phát hành.

Tôi vẫn muốn đọc các diffs vì tôi vẫn không tin tưởng một AI về bảo mật. Ờm, vậy nên, ừm, tôi không biết liệu tôi có làm mất màn hình không. Đây rồi. Cảm ơn bạn. Ờm, tôi nghĩ máy tính của tôi đã ngủ. Tôi... tôi không hoàn toàn tin tưởng AI sẽ không làm mất dữ liệu khách hàng của tôi và tôi sẽ không thỏa hiệp về điều đó. Vì vậy, tôi sẽ đọc các diffs vì tôi không muốn chịu trách nhiệm về việc đó. Ờm, tôi cảm thấy có một số vấn đề mà bạn có thể tin tưởng AI hoàn toàn, ví dụ như linting, testing. Có một số vấn đề mà bạn không thể thực sự tin tưởng AI chỉ vì không có trách nhiệm để làm như vậy. Vì vậy, có thể những thay đổi cụ thể liên quan đến bảo mật. Nếu bạn đang chạy các database migrations trong môi trường sản xuất, bạn nên kiểm tra xem chúng đã hoạt động trước khi chạy chúng trong sản xuất.

Tối ưu hóa Vòng lặp Phản hồi của AI

Đáp (tiếp theo): Và có một số vấn đề hơi mơ hồ và không rõ ràng hơn. Vì vậy, ừm, UI testing khá thú vị lúc đầu. Ý tưởng về việc có một cơ chế phản hồi tuyệt vời. Nếu bạn có thể khiến một AI nhấp qua dự án của mình để kiểm tra xem nó có hoạt động không, điều đó thực sự mạnh mẽ. Theo kinh nghiệm của tôi, nó hoạt động 50% thời gian, nhưng nó có thể khá hữu ích ít nhất là để thử lần đầu.

Việc có các bài kiểm tra end-to-end tốt thực sự rất hữu ích nếu bạn đang sử dụng Playwright hoặc thứ gì đó tương tự mà nó duy trì cho dự án skills tôi đã cho bạn xem. Ờm, tôi có một số bài kiểm tra end-to-end rất toàn diện thiết lập đầy đủ file systems của skills và khiến AI tạo ra hai persona khác nhau với việc chạy từng cái, bạn biết đấy, một publisher và một creator và nó chỉ kiểm tra tất cả các tệp có ở đúng vị trí hay không và điều đó thực sự rất hữu ích cho những loại bài kiểm tra end-to-end toàn diện đó. Tương tự, ừm, nếu bạn có thể xây dựng những cơ chế phản hồi đó và cho AI cơ hội để thực sự biết liệu nó đã làm tốt hay chưa, thì đó là một vị trí tuyệt vời. Và vì vậy, tôi luôn tìm cách tìm ra cách nếu một AI có thể biết liệu một thứ gì đó có tốt hay không thay vì tôi. Và khi tôi có thể loại bỏ bản thân khỏi loop đó, nó sẽ cải thiện đáng kể toàn bộ quy trình. Điều đó không phải lúc nào cũng khả thi hoặc mong muốn, nhưng tôi sẽ làm hết sức có thể.

Hỏi: Bạn đang thiết kế quy trình phản hồi, bạn đang...

Đáp: Bạn đang quyết định các tiêu chí và sau đó để AI thực thi dựa trên đó.

Hỏi: Vâng.

Đáp: Vâng. Ờm, nếu tôi làm việc một mình, vâng. Nếu tôi làm việc với một product owner hoặc product manager hoặc một designer, tôi thực sự quan tâm đến việc tận dụng kỹ năng của họ và cả các tester để tìm ra cách thiết kế những quy trình đó. Đây là những gì họ... đây là giá trị mà họ mang lại cho các quy trình này, đúng không? Đó là cách, giống như cách các coder đang nghĩ làm thế nào chúng ta có thể tránh tự mình gõ, bây giờ, ừm, còn về việc nếu bạn là một product manager, làm thế nào bạn có thể khiến AI làm những việc dễ dàng để bạn không phải làm? Bạn biết đấy, làm thế nào bạn đi qua quy trình đó? Ờm, tương tự với các tester, một lĩnh vực nghiên cứu cực kỳ thú vị.

Điểm nghẽn trong Quy trình Đánh giá

Hỏi: Hai điều nảy ra trong đầu tôi về điều này: điều gì hoạt động tốt cho một nhóm nhỏ? Điều gì đã hoạt động tốt cho tôi là thiết lập các adversarial reviews (đánh giá đối kháng) nơi bạn có spec. Tác nhân dev phát triển một reviewer thực hiện adversarial review. Bạn truyền ngữ cảnh đó trở lại. Tác nhân dev lặp lại, nói chung là bắt được rất nhiều thứ, tăng mức độ tự tin của tôi để deploy nó. Nhưng ngay cả với điều đó, với tốc độ mà bạn có thể tạo specs và lượng mã bạn thực sự phải xem xét, tôi vẫn là điểm nghẽn trong quy trình review.

Đáp: Vâng. Tôi luôn là một điểm nghẽn. Tôi có 30 thứ khác nhau mà tôi cần review mà AI của tôi đã làm qua đêm hoặc đại loại thế, và tôi chỉ nói, "Ôi chúa ơi", bạn biết đấy, và thách thức đối với tôi là rất nhiều công việc đó không phải là việc tôi nên làm. Lý do duy nhất nó giao cho tôi là vì tôi không thể tin tưởng AI với nó, nhưng bất kỳ con người nào cũng có thể làm công việc đó.

Tương lai của Công việc trong kỷ nguyên AI

Đáp (tiếp theo): Vì vậy, bây giờ tôi nghĩ, "Tôi có nên thuê người chỉ để làm công việc nhàm chán không? Điều đó có đạo đức không?" Bạn biết đấy, đây là những câu hỏi thực sự thú vị để chúng ta suy nghĩ, nhưng bạn nói đúng. Nếu chúng ta có thể thiết kế hệ thống, tôi thích quan điểm adversarial của bạn để xây dựng dựa trên những gì người khác đã nói. Ờm, nếu chúng ta có thể làm điều đó và thiết kế các hệ thống này sao cho chúng ta không phải ở trong loop, tôi nghĩ điều đó tốt hơn cho tất cả chúng ta vì tôi không chỉ muốn giao cho một người một công việc tồi tệ.

Hỏi: Cho đến lúc đó, chúng ta vẫn có việc làm. Vì vậy,

Đáp: Vâng, tôi đoán vậy.

Hỏi: Cảm ơn bạn.

Đáp: Không có gì. Còn câu hỏi nào khác không? Chúng ta nên dừng ở đây chứ? Mọi người, rất vui được ở bên các bạn. Ờm, thực sự, thực sự vui.