Building your own software factory — Eric Zakariasson, Cursor

• Mô hình "nhà máy phần mềm" tận dụng các tác nhân AI để tự động hóa quy trình phát triển, giúp con người chuyển vai trò từ người thực thi trực tiếp sang người quản lý và giám sát.
• Sự tự động hóa này tiến triển qua nhiều cấp độ, từ hỗ trợ viết mã đến các hệ thống "hộp đen" tự vận hành hoàn toàn, có khả năng tạo, kiểm thử và triển khai mã.
• Để xây dựng nhà máy phần mềm hiệu quả, cần cấu trúc mã nguồn rõ ràng, thiết lập các "hàng rào bảo vệ" và quy tắc, cung cấp kỹ năng và ngữ cảnh rộng cho tác nhân, đồng thời thay đổi tư duy quản lý của con người.

• Hiểu Các Cấp Độ Tự Chủ: Nhận biết các cấp độ tự động hóa từ "tự động hoàn thành nâng cao" đến "nhà máy đen" nơi tác nhân tự làm việc, giúp định hướng chiến lược tích hợp AI.
• Thiết Kế Để Đạt Thông Lượng Cao và Đầu Ra Nhất Quán: Xây dựng nhà máy phần mềm với mục tiêu tăng thông lượng (tác nhân làm việc 24/7) và đảm bảo chất lượng đầu ra đồng nhất thông qua quy trình được xác định rõ.
• Cấu Trúc Mã Nguồn và Mẫu Hình Sử Dụng Rõ Ràng: Tổ chức cơ sở mã một cách mô-đun hóa và sử dụng các mẫu hình (boilerplate, script khởi động) để tác nhân dễ dàng hiểu, khám phá và tái tạo mã.
• Thiết Lập "Hàng Rào Bảo Vệ" Linh Hoạt: Triển khai các quy tắc, kiểm tra và móc nối (hooks) để kiểm soát hành vi của tác nhân, thêm chúng một cách linh hoạt khi phát hiện tác nhân đi chệch hướng, như một Quy trình Vận hành Tiêu chuẩn (SOP).
• Kích Hoạt Khả Năng Tự Xác Minh Công Việc Của Tác Nhân: Cho phép tác nhân tự chạy và xác minh công việc của mình thông qua kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử giao diện người dùng và kiểm thử end-to-end (ví dụ: dùng Playwright).
• Cung Cấp Ngữ Cảnh Bên Ngoài và Kỹ Năng Cho Tác Nhân: Trang bị cho tác nhân khả năng truy cập ngữ cảnh từ các công cụ khác (Linear, Notion, Slack, DataDog) và các kỹ năng cụ thể (ví dụ: gắn cờ tính năng) để mở rộng phạm vi hoạt động của chúng.
• Chuyển Đổi Từ Vai Trò Thực Thi Sang Quản Lý: Thay đổi tư duy từ việc trực tiếp viết mã sang quản lý và điều phối nhiều tác nhân làm việc đồng thời, tập trung vào việc xác định phạm vi công việc và tối ưu hóa luồng làm việc bất đồng bộ.
• Tự Động Hóa Vòng Đời Phát Triển Phần Mềm (SDLC): Mã hóa và tự động hóa các giai đoạn của SDLC như đánh giá mã (ví dụ: BugBot), kiểm thử và triển khai, tạo ra một quy trình phát triển phần mềm gần như hoàn toàn tự động.

• dogfooding — sử dụng nội bộ sản phẩm
• agent — tác nhân
• observability — khả năng quan sát
• throughput — thông lượng
• guardrails — hàng rào bảo vệ
• codebase — cơ sở mã
• boilerplate — mã mẫu/khuôn mẫu
• external context — ngữ cảnh bên ngoài
• feature flagging — gắn cờ tính năng
• SDLC (Software Development Life Cycle) — vòng đời phát triển phần mềm

Giới thiệu và Chương trình nghị sự

Xin chào mọi người, tôi là Eric, một kỹ sư tại Cursor, và tôi chủ yếu làm việc về trải nghiệm nhà phát triển và sản phẩm. Hôm nay, tôi muốn chia sẻ về những trải nghiệm của mình khi làm việc tại Cursor, sử dụng nội bộ sản phẩm (dogfooding), và cách để xây dựng một "nhà máy phần mềm" của riêng bạn, cũng như các bước thực tế để đạt được điều đó. Thành thật mà nói, tôi nghĩ chúng tôi chưa thực sự đạt đến cấp độ đó. Một số bộ phận của sản phẩm và công ty đang hoạt động khá tự động, nhưng để xây dựng một nhà máy phần mềm cần rất nhiều công sức. Hãy nhìn vào các nhà máy thực tế sản xuất phần cứng: có rất nhiều dây chuyền lắp ráp, rất nhiều người tham gia, rất nhiều công việc quản lý, khả năng quan sát, v.v. Và có rất nhiều khái niệm chúng ta có thể học hỏi từ thế giới đó và áp dụng vào thế giới phần mềm. Dưới đây là những quan sát của tôi trong quá trình thực hiện.

Trước tiên, về chương trình nghị sự: Tôi muốn nói về các cấp độ tự động hóa, tiền thân của nhà máy (ám chỉ một cách chơi chữ), xây dựng nhà máy, vận hành nhà máy, và sau đó là mở rộng quy mô nhà máy. Cuối cùng, tôi muốn kết thúc bằng phần hỏi đáp.

Các cấp độ tự chủ

Dan Shapiro đã đăng một bài viết trên blog vào tháng 1 hoặc tháng 2 (tôi nghĩ vậy) về sáu giai đoạn tự chủ trong việc tự động hóa phần mềm. Carpathias cũng từng đưa ra ví dụ về cursor trong việc chuyển đổi từ tab sang tác nhân. Tôi nghĩ điều này tóm tắt rất rõ ràng. Ban đầu, chúng ta có spicy autocomplete (tự động hoàn thành nâng cao). Đây là nơi Cursor bắt đầu vào năm 2022-2023, cách đây khá lâu. Và chúng tôi đã dần dần tiến lên, làm cho quá trình tạo phần mềm trở nên tự động hơn và cho phép các tác nhân làm được nhiều việc hơn.

Tôi nghĩ hầu hết mọi người sử dụng các công cụ AI đang ở đâu đó giữa cấp độ hai và cấp độ ba, nơi bạn có một lập trình viên cặp đôi. Về cơ bản, bạn tương tác qua lại với tác nhân, đặt câu hỏi, nhận gợi ý, yêu cầu tác nhân làm việc và cuối cùng hoàn thành nhiệm vụ. Cấp độ cao hơn đó là việc AI tự tạo ra phần lớn mã nguồn, điều mà chúng ta có thể thấy ở cấp độ ba (nhà phát triển), nơi bạn, với tư cách là con người, giống như người kiểm duyệt, theo dõi các dấu vết, v.v. Nhưng khi bạn tiến xa hơn, bạn sẽ trở thành một người quản lý nhiều hơn, và chúng ta sẽ nói về điều này sau.

Cuối cùng, ở cấp độ bốn, tôi nghĩ đây là cấp độ mà tôi đang ở đối với hầu hết các dự án phần mềm, nơi tôi giao càng nhiều việc càng tốt cho các tác nhân và có lẽ là xem xét các đầu ra trước khi tôi thực sự xem xét mã nguồn. Bởi vì đôi khi tôi vẫn xem mã nguồn. Và cuối cùng, chúng ta có nhà máy phần mềm, về cơ bản là một hộp đen. Dan Shapiro gọi nó là "nhà máy đen", nơi bạn không thực sự có cái nhìn sâu sắc. Đó chỉ là các tác nhân tự làm việc của mình, triển khai mã nguồn, kiểm thử mã nguồn, xây dựng mã nguồn, v.v. Và bạn, với tư cách là người quản lý, chỉ cung cấp ý định và các chỉ dẫn, cùng với mục tiêu bạn muốn đạt được từ nhà máy.

Tại sao cần Nhà máy Phần mềm?

Vậy tại sao bạn lại muốn tạo ra một nhà máy? Đầu tiên là về thông lượng cao. Bạn có thể muốn tạo ra nhiều mã nguồn hơn với ít tài nguyên hơn. Bạn có thể chạy tác nhân 24/7, bạn không phải phụ thuộc vào con người cần ngủ, ăn uống, v.v. Bạn có thể có nhiều tác nhân hơn.

Một điều khác với các nhà máy là bạn có các dây chuyền lắp ráp, và dây chuyền lắp ráp tạo ra các đầu ra nhất quán. Vì vậy, nếu bạn xây dựng nhà máy đúng cách, bạn có thể có đầu ra rất nhất quán. Nhưng tại một thời điểm nào đó, ban đầu, nếu bạn không có thiết lập phù hợp, bạn có thể cảm thấy các tác nhân ngày càng trở nên mang tính xác suất hơn và bạn đang mất đi tính xác định. Bởi vì chúng chỉ đi và làm những điều ngẫu nhiên. Đây có lẽ là dấu hiệu cho thấy bạn cần xây dựng thêm các hàng rào bảo vệ cho nhà máy. Và tôi nghĩ đây cũng là một chức năng của khả năng mô hình. Khi các mô hình trở nên tốt hơn, chúng có thể tuân theo các chỉ dẫn tốt hơn và thực hiện bất cứ điều gì bạn muốn chúng làm.

Thứ ba, bạn có thể muốn có một nhà máy vì bạn có thể tận dụng "gu" của mình tốt hơn. Bạn có thể khai thác nhiều hơn sự sáng tạo của mình thay vì chỉ chờ đợi bạn, với tư cách là con người, tạo ra chúng và sản xuất phần mềm mà bạn đang tạo ra. Và sau đó là phần bắt buộc "ngày ấy và bây giờ" – đây là hình ảnh nó từng trông như thế nào. Đây là một nhà máy thử nghiệm từ vài năm trước. Và đây là điều chúng tôi đang theo đuổi ở đây.

Xây dựng Nhà máy: Nguyên tắc cơ bản và Mẫu hình

Vậy để xây dựng một nhà máy, bạn thực sự cần gì? Tôi thích nghĩ về điều này như các nguyên tắc cơ bản (primitives) và mẫu hình (patterns).

Cấu trúc mã nguồn

Đầu tiên là cách bạn cấu trúc mã nguồn. Đây có phải là một cơ sở mã được mô-đun hóa không? Hay nó rải rác khắp nơi? Đó có phải là mã nguồn được đặt cùng vị trí, v.v.? Về cơ bản, đó là khoảng cách trong việc định vị. Nếu bạn có một tác nhân liệt kê một thư mục, nó có thể khám phá tất cả các tệp liên quan cùng một lúc thay vì phải tìm kiếm toàn bộ cơ sở mã. Nó có thể rất biệt lập để làm việc trong một phần duy nhất của cơ sở mã. Điều này cũng đúng với con người: nếu bạn dễ dàng làm quen với một cơ sở mã mới, một tác nhân có lẽ cũng sẽ như vậy.

Mẫu hình sử dụng

Thứ hai là các mẫu hình sử dụng. Bạn có các phương thức và dịch vụ cụ thể để xác thực người dùng không? Bạn có các script khởi động không? Bạn có cách để viết các kiểm thử không, v.v.? Bạn có sẵn boilerplate này không? Bởi vì nếu có, bạn có thể chỉ cho tác nhân các tham chiếu hiện có và chỉ yêu cầu chúng tái tạo theo thời gian. Đó là một số nguyên tắc cơ bản và cấu trúc khác của cơ sở mã.

Xây dựng Nhà máy: Hàng rào bảo vệ

Thứ hai sẽ là hàng rào bảo vệ. Bạn có thể muốn để các tác nhân tự do nhưng không quá tự do. Vì vậy, bạn muốn có một số quy tắc, kiểm tra và móc nối tại chỗ. Ví dụ, bạn có thể muốn có một móc nối liên quan đến việc chạm vào một phần cụ thể của cơ sở mã. Có thể tác nhân không nên thay đổi phần nhạy cảm nhất như mã hóa dữ liệu nhạy cảm hoặc xác thực hoặc bất cứ điều gì tương tự, nơi một sai lầm có thể gây ra chi phí rất rất rất lớn cho công ty hoặc cho bạn, với tư cách là con người, v.v.

Các quy tắc có lẽ là khái niệm bị hiểu lầm nhất kể từ khi chúng tôi ra mắt các quy tắc Cursor. Có cursor directory đã ra mắt một bộ sưu tập tốt các quy tắc khác nhau, và giả định thường là bạn nên cài đặt mọi quy tắc mà bạn có thể tùy thuộc vào stack phần mềm bạn đang sử dụng. Ví dụ, nếu bạn đang sử dụng Next.js, có thể bạn nên có các quy tắc Next.js. Nhưng điều tôi đã tìm thấy và điều tôi đang thấy giữa những người dùng của chúng tôi và nội bộ là các quy tắc chỉ nên xuất hiện một cách linh hoạt. Nếu bạn thấy các tác nhân đi chệch hướng, bạn có lẽ nên tạo một quy tắc cho điều đó. Và nó nên giống như một quy trình vận hành tiêu chuẩn (SOP) để chỉ cho các tác nhân những gì chúng có thể và không thể làm. Và một lần nữa, các mô hình đang trở nên rất giỏi trong việc tuân theo các quy tắc cụ thể đến mức chúng thường không đi chệch hướng nữa. Và tôi nghĩ điều đó sẽ tiếp tục phát triển theo thời gian.

Và tất nhiên, kiểm thử: tác nhân có thể tự xác minh công việc của nó không? Và nó có thể chạy kiểm thử và biết rằng "ồ, tôi đã làm hỏng một cái gì đó" hoặc "tôi đã thực hiện một thay đổi tùy thuộc vào khu vực cụ thể này của mã nguồn, nhưng nó vẫn vượt qua"? "Tôi vẫn có thể chạy mã nguồn và kiểm tra trông tốt."

Xây dựng Nhà máy: Yếu tố thúc đẩy

Cuối cùng, điều mà tôi nghĩ có lẽ thú vị nhất là các yếu tố thúc đẩy: bạn có thể cho phép các tác nhân làm gì để thực sự cho phép chúng tự do? Kỹ năng là tốt cho điều này. Chỉ cần cung cấp cho các tác nhân nhiều khả năng, kỹ năng và MCP. Truy cập ngữ cảnh bên ngoài, hiểu cách triển khai một thứ gì đó. Tôi sẽ cho bạn thấy một số ví dụ sau trong cơ sở mã Cursor về những gì chúng tôi đang làm. Ví dụ như gắn cờ tính năng (feature flagging). Chúng ta có thể cung cấp cho các tác nhân một kỹ năng để thêm một gắn cờ tính năng không? Vì vậy, khi chúng tôi triển khai chúng một cách tự động, chúng có thể chỉ cần gắn cờ những thay đổi thực tế được thực hiện và hợp nhất yêu cầu kéo (PR), sau đó quay lại với chúng tôi và nói "này, nếu bạn muốn thử điều này, chỉ cần bật cờ này lên." "Nếu bạn không thích nó, chúng tôi sẽ hoàn tác PR." "Nếu bạn thích nó, chúng tôi có thể mở rộng nó cho nhiều người dùng hơn."

Và cuối cùng, bạn đang cho phép các tác nhân chạy trong loại môi trường nào? Các tác nhân của bạn có thể khởi động môi trường phát triển (dev environment) của bạn không? Bạn có thể chỉ cần yêu cầu chúng "này, khởi động dự án của tôi" và để chúng làm điều đó mà không cần bất kỳ con người nào tham gia vào vòng lặp không? Bởi vì nếu vậy, bạn có thể cho chúng chạy. Bạn có thể mở rộng quy mô nó vô hạn trên các máy ảo (VMs) riêng biệt.

Danh sách kiểm tra xây dựng nhà máy

Và danh sách kiểm tra này là những gì tôi thường tuân theo khi nghĩ về việc xây dựng nhà máy thực sự. Và một phần trong đó là "nó có thể chạy được không?" (Có một lỗi chính tả ở đây, tôi đổ lỗi cho tiếng Thụy Điển của tôi). Có ngữ cảnh mà các tác nhân cần có được truy cập không? Chúng có thể giao tiếp với Linear hoặc Notion hoặc DataDog hoặc Slack, v.v. không? Và sau đó bạn có thể thấy ngữ cảnh rộng hơn về ý định mà người dùng có.

Và cuối cùng, điều mà tôi nghĩ mọi người nên dành nhiều thời gian hơn là xây dựng các hệ thống có thể xác minh được. Làm thế nào các tác nhân có thể tự xác minh công việc của mình? Cho dù đó là thông qua kiểm thử đơn vị (unit tests) hay kiểm thử tích hợp (integration tests) hay kiểm thử giao diện người dùng (UI tests). Thực sự nhấp xung quanh trong DOM và cố gắng tái tạo những gì đang thực sự xảy ra cho người dùng cuối. Điều này được cho là dễ dàng hơn đối với các hệ thống backend nơi không thực sự có UI nào xảy ra và bạn có thể có các hợp đồng và ranh giới rõ ràng hơn về những gì nên hoạt động và những gì không nên. Trong khi đối với web và UI và tất cả những thứ đó, bạn thực sự cần phải nhấp xung quanh và đảm bảo mọi thứ hoạt động. Các nút thực sự có một vòng quay tải (loading spinner), v.v.

Demo: Cursor 3 và Tác nhân Âm nhạc

Vậy đây là một phần của việc xây dựng các nhà máy. Nếu chúng ta chuyển sang Cursor ở đây, tôi không chắc bạn đã thấy điều này chưa, nhưng đây là Cursor 3. Chúng tôi đã ra mắt nó vài tuần trước và đó là một bản viết lại hoàn chỉnh của Cursor. Không còn VS Code nữa. Hầu hết các bạn có lẽ đã quen thuộc với loại Cursor này. Chúng tôi có các tệp và thanh bên và rất nhiều thứ khác nhau. Trong khi đó, cái này được đơn giản hóa hơn một chút cho một quy trình làm việc ưu tiên tác nhân (agent-first workflow). Và chúng ta sẽ nói về lý do tại sao chúng tôi tạo ra điều này sau này. Nhưng tôi muốn cho bạn thấy một số phần của các quy tắc, v.v. Để xem tôi đã đặt chúng ở đâu.

Ví dụ, tôi đã xây dựng dự án tác nhân âm nhạc này. Và nếu bạn đã từng sử dụng Ableton trước đây, bạn có lẽ sẽ nhận ra điều này. Vâng, vâng, vâng, tôi sẽ mở rộng nó. Thêm nữa? Được rồi. Vâng. Vì vậy, nếu bạn đã sử dụng Ableton hoặc bất kỳ phần mềm sản xuất âm nhạc nào, bạn có lẽ sẽ nhận ra giao diện này. Oái, nó không thực sự hoạt động ở kích thước này. Nhưng về cơ bản, điều tôi yêu cầu các tác nhân làm ở đây là: "Bạn có thể khởi động một máy chủ phát triển cục bộ (local dev server) không?"

Và chúng ta có thể thấy rằng nó đã hoạt động một lúc. Nó đã khám phá một số tệp, đọc package.json. Và dựa trên điều này, có một script khởi động. Vì vậy, package.json, tất cả các tệp phụ thuộc này rất phổ biến trong các mô hình đến mức chúng biết rằng chúng ta nên ngay lập tức chuyển đến package.json sau một dự án Node.js nơi nó tồn tại để tìm kiếm một script khởi động. Và đây là một ví dụ tốt về việc có một mẫu hình được định nghĩa trước và làm cho cơ sở mã của bạn "phổ biến" hơn theo cách đó. Bởi vì bây giờ, các tác nhân cực kỳ dễ dàng hiểu rằng: "Ồ, tôi chỉ cần vào đây và khởi động một máy chủ." Vì vậy, nó đã khởi động một máy chủ. Nó đang chạy ở localhost:3000.

Và hãy xem ở đây. Chúng ta có thể thấy rằng chúng ta có tệp agents MD này. Vì vậy, agents MD giống như các quy tắc của Cursor. Nó là một tập hợp các harnesses khác nhau. Và điều tôi muốn đạt được với dự án này về cơ bản là xây dựng một nhà máy xoay quanh ý tưởng xây dựng một công cụ tạo nhạc trực tuyến (online music creation tool). Và để làm điều đó, tôi đã buộc mình không bao giờ tự viết mã nguồn. Cố gắng không nhìn vào mã nguồn nhiều. Và chỉ cố gắng tìm ra những hệ thống và cấu trúc tôi cần xung quanh nó. Ngay lập tức, trở nên khá rõ ràng rằng chúng ta cần một cách để bắt đầu một dự án. Chúng ta cần một cách để tác nhân xác minh một số công việc.

Kiểm thử Tự động và Đánh giá Mã với Tác nhân

Tác nhân đã tạo các bài kiểm thử end-to-end này bằng cách sử dụng Playwright. Nhờ đó, nó có thể khởi tạo trình duyệt, điều hướng qua các trang gốc, v.v., nhấp chuột xung quanh và tìm kiếm theo ID kiểm thử. Điều này đảm bảo rằng với mỗi thay đổi khác nhau được thực hiện, ví dụ, nút phát vẫn hoạt động hoặc tôi có thể thêm ghi chú vào dự án này mà không gặp lỗi nào. Đây là một số ví dụ về cách bạn có thể tạo các đầu ra có thể kiểm chứng như vậy. Được rồi, chúng ta có VTES, chúng ta có điều này, v.v. Vậy hãy xem ở đây, nếu bạn quay lại.

Ồ vâng, một lựa chọn khác ở đây, khi cuộn Twitter ngẫu nhiên. Một cách khác để xác minh công việc là sử dụng một hệ thống tự động hóa để đánh giá mã. Bạn có thể yêu cầu tác nhân chỉ xem xét các thay đổi mà nó đã thực hiện, hoặc bạn có thể sử dụng một công cụ tích hợp hơn như BugBot mà chúng tôi có trong Cursor, nó xem xét các PR khác nhau trên GitHub, đánh giá chúng và phản hồi lại. Và đây cũng là một phần của toàn bộ "nhà máy" mà bạn nên có nhiều giai đoạn khác nhau: bạn lập kế hoạch, bạn sản xuất, bạn đánh giá và về cơ bản bạn tuân theo toàn bộ SDLC, nhưng bạn tự động hóa và codify công việc này. Tôi cũng muốn cho bạn thấy điều này.

Triển khai Tác nhân trên Claude và khả năng tự kiểm thử

Trong vài tuần qua, chúng tôi đã ra mắt các tác nhân trên Claude được cập nhật, nơi chúng tôi cấp cho mỗi tác nhân một VM riêng biệt, và bạn có thể khiến chúng tạo ra một môi trường có thể tái tạo rất tốt trên Claude. Điều này về cơ bản cho phép bạn mở rộng quy mô vô hạn. Nhưng chúng tôi cũng đã cung cấp cho tác nhân một công cụ để tự kiểm thử công việc của chính nó bằng cách điều khiển máy tính. Ví dụ, chúng ta có Glass ở đây, là giao diện. Và tôi đã yêu cầu tác nhân, xem nào. Các tác nhân Glass, xem liệu chúng có gặp khó khăn với bàn phím, Ctrl + Tab, v.v. để cải thiện khả năng tiếp cận và sử dụng bàn phím để điều hướng các tác nhân. Và tôi yêu cầu nó thực hiện một thay đổi và sau đó ghi lại điều này bằng trình soạn thảo đầy đủ, vì cái trước chỉ là một thanh bên. Vậy điều chúng tôi nhận được ở đây chỉ là một video về tác nhân thực sự tự kiểm thử công việc của chính nó. Chúng ta có thể thấy rằng nó có hàng được tô sáng này, tôi không chắc bạn có thể thấy nó không. Nhưng đây chỉ là một ngữ cảnh để tôi, với tư cách là con người, xác minh công việc. Và sau đó nó thực sự nhấp chuột xung quanh và sử dụng bàn phím để điều hướng.

Chuyển đổi tư duy: Từ người thực thi sang người quản lý

Với điều này, chúng ta đã tiến khá xa trong "nhà máy" của mình. Và nhiều thứ đã được tự động hóa, như đánh giá mã được tự động hóa, kiểm thử được tự động hóa. Chúng ta có một số quy tắc để điều khiển các tác nhân, v.v. Nhưng vẫn còn rất nhiều việc phải làm. Vì vậy, tôi nghĩ rằng khi bạn đã có những điều này, điều quan trọng nhất bạn có thể làm là thay đổi tư duy của mình. Bạn sẽ ít phải nhìn vào mã hơn rất nhiều. Vì vậy, bạn sẽ chuyển từ một người thực thi sang một người quản lý. Thay vì tự mình làm việc, bạn sẽ giám sát nhiều tác nhân thực hiện công việc cho bạn. Điều này cũng có nghĩa là chuyển từ mô hình đồng bộ sang bất đồng bộ vì hầu hết công việc sẽ diễn ra ở chế độ nền. Và bạn vẫn có thể kiểm tra và xem điều gì đang xảy ra với các tác nhân khác nhau. Nhưng càng nhiều tác nhân được khởi tạo theo thời gian, bạn sẽ càng khó khăn hơn trong việc hiểu điều gì đang diễn ra ở mỗi tác nhân. Vậy thì bạn cần một cách để tổng hợp các thay đổi này lên trên. Và tôi nghĩ thật thú vị là điều này giống hệt như trong các tổ chức của con người. Tất cả các nguyên tắc tương tự đều được áp dụng. Bạn vẫn bắt đầu với một nhóm rất nhỏ và sau đó bạn thêm ngày càng nhiều người vì bạn cần đạt được thông lượng cao hơn, và đột nhiên bạn cần một người quản lý để giám sát mọi thứ, và sau đó bạn thêm nhiều người quản lý hơn, và sau đó bạn cần một người quản lý của người quản lý. Và đây về cơ bản là những gì sẽ xảy ra với các tác nhân nữa. Nhưng bạn sẽ tiếp tục nâng cấp mức độ hướng dẫn.

Quản lý và Điều phối Luồng Công việc của Tác nhân

Vậy khi bạn là một người quản lý, bạn cần bắt đầu suy nghĩ về cách bạn xác định phạm vi và song song hóa công việc vì bạn muốn đạt được thông lượng cao. Nhưng một số việc không nhất thiết phải tốt khi thực hiện tất cả các thay đổi cùng một lúc. Ví dụ, nếu bạn có hai tác vụ khác nhau cùng làm việc trên cùng một phần của cơ sở mã, bạn sẽ gặp xung đột hợp nhất. Vì vậy, bạn vẫn cần phải lập kế hoạch, xác định phạm vi và song song hóa công việc. Một đơn vị công việc luôn có thể là một tác nhân. Vậy làm thế nào để bạn lấy một danh sách dài các việc bạn muốn làm và thực sự tận dụng tối đa điều đó, cũng như chạy số lượng tác nhân nhiều nhất có thể? Và để làm điều này, tôi nghĩ điều quan trọng là bạn phải duy trì kiến thức nội bộ về cơ sở mã. Bạn vẫn hiểu điều gì đang diễn ra trong các hệ thống khác nhau. Bạn biết dữ liệu chảy như thế nào, người dùng muốn gì, phần nào là quan trọng. Vì vậy, không nên outsourcing (thuê ngoài) quá nhiều cho các tác nhân, mà hãy quản lý chúng một cách rất trực tiếp và hiệu quả.

Niềm tin, Ngữ cảnh và Tối ưu hóa lời nhắc

Và khi bạn chuyển từ đồng bộ sang bất đồng bộ, bạn sẽ cần tin tưởng các tác nhân nhiều hơn. Bởi vì bạn sẽ giao cho chúng những tác vụ ngày càng dài hơn. Và khi làm như vậy, bạn cần cung cấp nhiều ngữ cảnh hơn ngay từ đầu. Vì vậy, bạn giống như cung cấp ngữ cảnh trước cho các tác nhân. Tôi đã làm điều đó như một kế hoạch hoặc một spec dài, sau đó bạn giao việc cho chúng và để chúng thực hiện. Và một khi bạn bắt đầu làm điều này thường xuyên, bạn sẽ bắt đầu "cảm nhận" được các tác nhân. Bạn sẽ hiểu các mô hình và bạn sẽ thấy đâu là điểm yếu, đâu là điểm mạnh và bạn sẽ có sự ăn khớp với các mô hình này. Vì vậy, bạn biết cách lời nhắc chúng và ý định nào cần cung cấp. Và một lần nữa, khi các mô hình tiếp tục tốt hơn, bạn phải cung cấp cho chúng các lời nhắc ngắn hơn hoặc ít hơn so với trước đây, nhưng bạn vẫn phải cung cấp ý định và nói rõ ràng về thay đổi bạn muốn các tác nhân thực hiện. Và không có phím tắt nào cho điều này theo những gì tôi và nhóm đã tìm thấy. Bạn chỉ cần khởi tạo một số lượng lớn tác nhân và để chúng làm việc, rồi xem điều gì xảy ra. Và miễn là bạn có các hàng rào bảo vệ an toàn tốt, bạn có thể cứ để chúng làm điều đó. Vì vậy, có lẽ bạn không nên để chúng đẩy lên môi trường sản xuất ngay lập tức.

Môi trường Biệt lập cho Tác nhân

Vâng, điều này cá nhân tôi luôn sử dụng các môi trường biệt lập trong các VM khác nhau. Tôi vừa tweet về điều này thực ra, bởi vì một mặt, nếu bạn chia sẻ không gian làm việc, bạn có thể có git worktrees nơi bạn có các bản sao nông của cơ sở mã trên cùng một máy và bạn có thể tái sử dụng dịch vụ. Nhưng bạn vẫn sẽ phải phân nhánh mọi cơ sở dữ liệu, bộ nhớ đệm hoặc quản lý người dùng để có các môi trường có thể tái tạo và tách biệt. Chẳng hạn, nếu bạn định thực hiện nhiều thay đổi, bạn muốn biết rằng chúng là thuần túy và không gây ra tác dụng phụ cho các nhánh khác. Và đó là lý do tại sao tôi thấy việc chỉ sử dụng các tác nhân trên Claude nơi tôi khởi tạo một VM, và VM này có thể chạy một cơ sở dữ liệu, công cụ nội bộ, các cơ sở dữ liệu khác, và ứng dụng Cursor, sau đó để tác nhân làm việc trong môi trường biệt lập đó là tốt hơn nhiều. Nó tốn kém hơn, sẽ mất nhiều công sức hơn để thiết lập "nhà máy" hoặc môi trường của bạn để hỗ trợ điều này. Nhưng một khi bạn đã thiết lập đúng cách, bạn có thể mở rộng quy mô này lên 100 hoặc 1000 tác nhân. Tôi không chắc hôm nay chúng tôi đang chạy bao nhiêu, nhưng tôi cá là có hàng nghìn tác nhân đang chạy hàng ngày trong cùng một hoặc các bản sao của cơ sở mã. Đó là điều tôi khuyên dùng.

Tự động hóa các Tương tác của Con người

Vâng, vậy khi bạn là một người quản lý, công việc của bạn thay đổi khá nhiều. Bạn phải nhìn vào hệ thống của mình như một tổng thể. Bạn phải nghĩ xem "con người trong vòng lặp" cần thiết ở đâu. Ví dụ, bạn có một dịch vụ ghi nhật ký như DataDog và bạn có cần sao chép nhật ký, dán vào cơ sở mã, và chạy các tác nhân để xác định và theo dõi các vấn đề không? Hay bạn có phản hồi người dùng mà bạn cần sao chép từ Twitter vào nơi khác và để các tác nhân làm gì đó với nó? Bạn có một thứ gì đó như Notion nơi bạn có tất cả các spec của mình không? Bạn cần sao chép Notion hoặc xuất chúng sang Markdown và sau đó đưa cho các tác nhân không? Có lẽ có một cách để tự động hóa tất cả những thứ khác nhau này. Hoặc đó là các kỹ năng hoặc MCP hoặc các tự động hóa riêng biệt. Vì vậy, hãy nghĩ xem "con người trong vòng lặp" cần thiết ở đâu và cố gắng tự động hóa nó.

Nâng cao Hiệu quả "Nhà máy" Tác nhân với Vòng quay liên tục Phản hồi

Điều thứ hai là làm thế nào để bạn có thể phát hiện các tác nhân đi chệch hướng, không làm những gì bạn thực sự muốn chúng làm. Và đây chính là vòng quay liên tục hoàn hảo để cải thiện "nhà máy" của bạn. Nếu bạn thấy các tác nhân tạo ra các schema sai trong cơ sở dữ liệu của bạn vì chúng không tuân thủ các quy ước đặt tên, v.v., thì có lẽ đó là một quy tắc ở đâu đó. Hoặc nếu chúng chỉ tạo ra giao diện người dùng thực sự xấu. Có lẽ có một cách để bạn tạo một hệ thống thiết kế và cho các tác nhân biết về các hệ thống thiết kế đó để chúng có thể tích hợp và sử dụng nó cho lần lặp tiếp theo của bạn. Và vâng, sau đó bạn lấy tất cả những kiến thức này và sử dụng chúng để thực sự cải thiện "nhà máy".

Mở rộng Quy mô "Nhà máy" Tác nhân

Và thứ ba là việc mở rộng quy mô "nhà máy". Vậy bây giờ bạn đã thiết lập môi trường, bạn biết cách trở thành một người quản lý, quản lý một đội ngũ tác nhân, bạn xác định phạm vi tác vụ và làm tất cả những điều này. Vậy làm thế nào để bạn thực sự đưa nó từ năm tác nhân lên mười tác nhân, lên 50, lên 100 tác nhân? Và điều quan trọng là, một lần nữa, việc không nhìn vào mã sẽ trở thành hiện thực nếu các mô hình trở nên tốt hơn, và chúng đang thực sự tốt hơn. Vì vậy, việc quan sát kết quả – cũng giống như trước đây – như chúng đi chệch hướng ở đâu, chúng đang sản xuất ra cái gì, các artifact là gì, v.v. Làm thế nào để bạn có thể khiến các tác nhân cũng có thể tự xác minh công việc của mình và xác minh kết quả mà chúng tạo ra? Bạn nên thiết lập các hệ thống tự động hóa. Bạn nên xem lại những việc bạn đang làm lặp đi lặp lại.

Tự động hóa các Tác vụ Lặp lại và Học hỏi từ Phản hồi của Con người

Vậy, một điều chúng ta có thể làm ở đây, ví dụ, nếu chúng ta vào Cursor và quay lại tác nhân âm nhạc này, tôi có thể hỏi, dựa trên lịch sử trò chuyện của mình, những tác vụ lặp đi lặp lại nào tôi đang làm. Vậy chúng ta có thể yêu cầu các tác nhân xem xét điều này và xác định các cơ hội tiềm năng. Vì vậy, nó đang tìm kiếm các bản ghi tác nhân và tạo ra một loại artifact nào đó từ đó. Vâng, chúng ta hãy tiếp tục. Tôi thực sự đã tích hợp điều này vào một plugin. Ồ, hãy xem nào. Lập kế hoạch vòng lặp thực thi, chúng ta đang bắt đầu định hướng sản phẩm. Hãy xem nào. Lần lặp giao diện người dùng giống Ableton. Tôi có lẽ nên đưa điều này vào một quy tắc, nói rằng hãy làm cho nó trông giống Ableton. Dọn dẹp công cụ, v.v. Vì vậy, sản phẩm này có tuổi thọ rất ngắn, nhưng nếu bạn đang xem xét một sản phẩm thực tế đang sản xuất mà bạn đã nhắc lời nhiều lần theo thời gian, bạn có thể sẽ tìm thấy những việc bạn đang làm lặp đi lặp lại. Và tôi muốn cho bạn thấy một số điều mà chúng tôi đang làm tại Cursor mà chúng tôi đang tự động hóa. Và một số điều này không phải lúc nào cũng rõ ràng, nhưng một ví dụ là, ví dụ, đánh giá hàng ngày. Vì vậy, tôi có tự động hóa này để kiểm tra đánh giá hàng ngày của riêng mình. Nó sẽ xem xét Slack. Nó sẽ xem xét GitHub và nó sẽ gửi cho tôi một bản tóm tắt về những việc tôi đã làm trong ngày qua. Trước đây tôi sẽ làm điều này bằng cách ghi chú, có thể suy nghĩ xem hôm nay tôi đã hoàn thành những gì, hoặc viết một tác nhân có quyền truy cập vào MCP. Nhưng bây giờ tôi có thể chỉ cần đặt lịch trình và làm điều này tự động hóa cho tôi.

Tôi muốn cho bạn xem một ví dụ khác. Chẳng hạn, đọc các bình luận PR đã hợp nhất. Đây cũng là một cách để bạn học hỏi theo thời gian. Vì vậy, đối với tất cả các PR mà chúng tôi hợp nhất vào kho lưu trữ chính của mình, chúng tôi có thể xem xét các bình luận và xem con người thực sự đã đánh giá gì ở đây và họ đã nói gì về những thay đổi tôi đã thực hiện. Bởi vì nếu một con người thực sự tham gia và đánh giá một PR và để lại một bình luận, thì có lẽ có giá trị cao, tín hiệu cao và ý định rõ ràng trong bình luận đó, và chúng tôi có thể lưu trữ điều đó sau này để các tác nhân thực sự học hỏi theo thời gian. Chúng tôi có một cái khác mà tôi có thể cho bạn xem ở đây. Cái này. Vâng, một lần nữa, code owners. Vì vậy, cái này cho phép chúng ta. Về cơ bản, chúng tôi đã gặp vấn đề này khi chúng tôi có các code owners trong cơ sở mã của mình và họ đúng hầu hết thời gian, khoảng 80% thời gian, nhưng trong 20% thời gian này, họ đã gây ra rất nhiều nút thắt cổ chai cho chúng tôi nội bộ. Chẳng hạn, chúng tôi bị chặn PR hợp nhất; chúng tôi cần người khác đánh giá giúp chúng tôi và có thể họ ở múi giờ khác.

Tác nhân Kiểm soát Mã nguồn và Đánh giá Rủi ro

Vì vậy, điều chúng tôi bắt đầu làm là xây dựng một công cụ agent code owner (tác nhân kiểm soát mã nguồn) này. Về cơ bản, nó sẽ xem xét các PR (Pull Request) và kiểm tra mức độ rủi ro: liệu đây có phải là việc đổi tên biến đơn giản hay là thay đổi một hằng số ảnh hưởng đến thời lượng đăng ký dùng thử chẳng hạn. Nếu rủi ro thấp, nó có thể tự động phê duyệt PR vì chúng tôi không muốn cản trở các kỹ sư của mình. Nhưng nếu là một PR có rủi ro cao, chúng tôi có thể tìm ra ai đã thực hiện các thay đổi trước đây và thu thập phản hồi của họ, tận dụng tối đa điều này để đảm bảo mã an toàn, không phá vỡ hệ thống, đồng thời giữ cho người dùng đã thực hiện thay đổi ban đầu được cập nhật và làm mới ngữ cảnh về những gì đang diễn ra. Vì vậy, nó mang lại lợi ích theo cả hai chiều và có nhiều giá trị gia tăng từ việc thực hiện điều này.

Tự động hóa Học hỏi Liên tục

Để xem còn gì nữa không. Không, tôi nghĩ đó là tất cả, hoặc đúng hơn, tôi còn một thứ nữa gọi là continue learning (học hỏi liên tục). Continue learning là một dạng tự động hóa khác mà tôi đã tạo ra vài tuần trước. Về cơ bản, nó làm những gì chúng ta đã làm với tác nhân. Chúng tôi xem xét các bản transcript (ghi chép) trước đây và có thể trích xuất ký ức và kiến thức học được từ những gì chúng ta đã nói. Ví dụ, nếu chúng ta đang sửa tác nhân để làm một việc nhất định – như sử dụng thành phần này thay vì thành phần kia, hoặc luôn mô tả rất chi tiết về những việc đang làm – thay vì mỗi lần tôi phải vào và yêu cầu, tôi có thể tạo một rule (quy tắc). Nhưng tôi khá lười nên không nhớ để tạo rule. Vì vậy, thay vào đó, chúng ta có thể có plugin continue learning này, nó sẽ xem xét các transcript và lưu trữ điều này dưới dạng một rule cho bạn. Đây là những ví dụ về các hệ thống để tự động hóa công việc của bạn, và tự động hóa những việc mà tác nhân có thể làm cho bạn. Tôi nghĩ đó là phần quan trọng của việc xây dựng các factory (nhà máy) này: làm thế nào để bạn có thể xác định các flywheel (vòng quay liên tục) và loop (vòng lặp) mà bạn có thể tự động hóa công việc của mình bằng cách xây dựng hệ thống.

Các Bài học Quan trọng và Thực tiễn Tốt nhất

Được rồi, và bạn sẽ loại bỏ những sự phân tâm. Hiện tại bạn đang quản lý 5 đến 10 tác nhân, nhưng ngày mai bạn có thể sẽ quản lý một tác nhân quản lý các tác nhân khác, và điều đó sẽ tiếp tục phát triển; bạn sẽ có rất nhiều tác nhân con làm việc dưới quyền bạn. Vì vậy, điều tôi muốn bạn rút ra từ đây là phải rất rõ ràng về ý định và thực sự suy nghĩ về vấn đề thực sự cần giải quyết ở đây là gì, chúng ta muốn đạt được điều gì từ việc này. Đừng outsourcing (thuê ngoài) các quyết định quan trọng; hãy đảm bảo bạn luôn nắm bắt các quyết định quan trọng, dù đó là về safety (an toàn), security (bảo mật), database (cơ sở dữ liệu), payments (thanh toán) hay authentication (xác thực). Một số thứ thực sự quan trọng và không nên do tác nhân quyết định mà phải do con người. Hãy build tools and systems (xây dựng công cụ và hệ thống), cố gắng tìm ra các flywheel này và codify (mã hóa) chúng, đưa chúng vào hệ thống của bạn và cho tác nhân quyền truy cập vào chúng. Lưu trữ context (ngữ cảnh) để sử dụng sau này, dù đó là các bản transcript của tác nhân hay artifact (hiện vật) của những thứ bạn cho là tốt, bởi vì điều này sẽ giúp tác nhân biết được cái gì là tốt và xấu theo thời gian, và nó sẽ thay đổi. Vì vậy, việc lưu trữ ngữ cảnh, xây dựng công cụ và giữ chúng cập nhật quan trọng hơn là thực sự làm công việc, bởi vì điều này sẽ cung cấp framework (khung làm việc) và hàng rào bảo vệ cho các tác nhân. Và cuối cùng, hãy để các tác nhân được tự do; hãy nghĩ xem chúng cần gì. Tôi có một người bạn, anh ấy đáng yêu, anh ấy kể rằng họ đã thiết lập một kênh Slack hoặc anh ấy đã cung cấp cho tác nhân một vent tool (công cụ để trút bầu tâm sự) để tác nhân có thể phàn nàn về mọi thứ khi nó đang chạy. Và tác nhân bắt đầu phàn nàn: "Này, tôi không thể truy cập hình ảnh này, tôi rất bực bội về điều này". Và sau đó nó đã đăng thẳng vào một kênh Slack. Họ đã thiết lập nó như một trò đùa, nhưng sau đó họ bắt đầu cuộn qua và nhận ra: "Ồ, điều này thực sự rất có giá trị! Có lẽ chúng ta nên cấp quyền truy cập hình ảnh cho tác nhân." Và họ đã làm vậy. Sau đó, nó lại bắt đầu phàn nàn về một vấn đề khác liên quan đến harness (hệ thống điều khiển). Vì vậy, hãy tìm cách để các tác nhân được tự do; tôi nghĩ đó là một điều rất quan trọng.

Chất lượng Mã nguồn và Kiến trúc với Tác nhân AI

Được rồi, đó là tất cả những gì tôi muốn chia sẻ, và đó cũng là định hướng và những điều chúng tôi đã tìm thấy khi xây dựng Cursor và phát triển Cursor hướng tới một software factory (nhà máy phần mềm). Tôi hy vọng bạn đã học được một vài điều và có thể áp dụng một số ý tưởng này. Tôi sẵn lòng trả lời mọi câu hỏi về Cursor. Vâng, thực ra bây giờ micro đang đến đây. Cảm ơn bạn rất nhiều. Tôi có một câu hỏi về code quality (chất lượng mã) hoặc architectural quality (chất lượng kiến trúc). Khi các tác nhân tạo ra hàng tấn mã và bạn hầu như không thể xem xét hết, làm thế nào để bạn đảm bảo mã đó có khả năng extensible (mở rộng) và các yếu tố khác? Ý tôi là, bạn có thể thiết lập các hook (điểm móc) hoặc hàng rào bảo vệ cho những thứ có thể đo lường được, ví dụ như số dòng trong một tệp không được vượt quá một giới hạn nào đó. Nhưng kiến trúc không được đo lường theo cách này, và các tác nhân có completion bias (thiên kiến hoàn thành), chúng muốn hoàn thành tác vụ càng sớm càng tốt và không suy nghĩ trước, chúng không có bức tranh về tương lai mã sẽ phát triển như thế nào, chúng chỉ muốn hoàn thành tác vụ hiện tại. Cảm ơn. Vâng, đó là một câu hỏi hay. Tôi nghĩ chúng ta, với tư cách là con người, cũng có vấn đề tương tự, nhưng chúng ta mất nhiều thời gian hơn để phát hiện ra chúng. Một pattern (mô hình) tốt về các tác nhân và model (mô hình) là chúng về cơ bản là những completion machine (máy hoàn thành tác vụ), chúng sẽ chỉ nhìn vào các tài liệu tham khảo hiện có và tiếp tục theo cùng một con đường đó. Vì vậy, nếu bạn có những thứ hiện có để chúng tham khảo, tôi nghĩ điều đó rất quan trọng. Nếu không, tôi nghĩ có một trường hợp bạn để các tác nhân thực hiện các implementation (triển khai) một lần ở đây và ở đó, và sau đó bạn sẽ có một tác nhân khác thực hiện refactoring (tái cấu trúc), giống như cách chúng ta làm với tư cách là con người. Ví dụ, để khái quát hóa và xây dựng các abstraction (trừu tượng hóa) và tất cả những điều này. Vậy làm thế nào để bạn có thể xây dựng một hệ thống để phát hiện điều này và xác minh rằng các abstraction đang được xây dựng cũng tốt và phù hợp với những gì bạn muốn làm. Nhưng tôi nghĩ cần phải có nhiều architectural review (đánh giá kiến trúc) hơn từ con người, cũng như scoping (xác định phạm vi) và planning (lập kế hoạch) về kiến trúc nên trông như thế nào và system design (thiết kế hệ thống). Nhưng vâng, đó là một vấn đề khó khăn.

Xây dựng Factory: Hợp tác trong Nhóm

Chào Eric. Cảm ơn bài nói chuyện của bạn. Khi nói đến các hoạt động xây dựng factory (nhà máy), một điều tôi nhận thấy, ví dụ như khi xây dựng các rule (quy tắc) trong một nhóm, là vì nó quá mới mẻ nên hầu hết mọi người đều cảm thấy "ồ, đây là rule dành cho tôi và tôi không muốn áp đặt nó lên người khác." Và tôi nhận thấy việc tạo ra các silo (hầm chứa/ngăn chứa thông tin riêng biệt) này, nơi mỗi kỹ sư cuối cùng lại có factory riêng, khác biệt của mình. Bạn có lời khuyên nào về cách đưa nó đến điểm mà cả nhóm cùng đóng góp vào việc tạo ra factory không? Đó là một câu hỏi tuyệt vời. Tôi nghĩ điều đó khó. Tôi nghĩ nó cũng mang tính văn hóa rất cao. Ý tôi là, chúng ta là nhà phát triển luôn tạo ra công cụ riêng của mình và chúng ta muốn có thiết lập tùy chỉnh riêng, nhưng đến một lúc nào đó, chúng ta phải thống nhất về một cấu trúc nhất định. Vì vậy, tôi nghĩ trong lịch sử, chúng ta đã có PR reviews (đánh giá Pull Request) và tất cả những thứ tương tự như một nghi thức để thống nhất về mã đang được tạo ra và đảm bảo nó nhất quán. Tôi nghĩ chúng ta sẽ áp dụng các nguyên tắc tương tự cho các công cụ mà chúng ta đang xây dựng, cũng như các hàng rào bảo vệ, enablers (công cụ hỗ trợ) và primitives (thành phần cơ bản). Vì vậy, tôi nghĩ, không biết, thiết lập một loại forum (diễn đàn) nơi bạn có thể thảo luận những điều này và lập kế hoạch xem chúng ta muốn các factory trông như thế nào? Chúng ta cần những component (thành phần) nào? Chúng ta cần những integration (tích hợp) nào? Bạn có ví dụ nào về những điều cụ thể cho mọi người không? Nó giống như flavor (hương vị) hay là những thay đổi lớn hơn mà các tác nhân đang thực hiện? Khi nói đến rule, họ tạo ra những thứ như "ồ, một người muốn viết test (kiểm thử) trước và họ tạo rule để viết test trước, nhưng họ biết rằng người khác không muốn làm theo cách đó." Vì vậy, sau đó họ chỉ có các rule trên máy của mình. Họ không chia sẻ nó vì nó độc đáo đối với những gì họ đang làm. Vì vậy, họ đang cộng tác. Cả nhóm đang cộng tác trong việc tạo ra codebase (cơ sở mã), nhưng sự hợp tác trong việc tạo ra factory trong việc suy nghĩ "chúng ta đã quyết định rằng factory sẽ viết test trước hay chưa?" Đó là một quyết định lớn, khó để mọi người thống nhất và chấp nhận. Giống như với tất cả các rule này, không phải ai cũng sẽ hoàn toàn đồng tình, và trong hầu hết các trường hợp, điều đó không quan trọng khi bạn trì hoãn một chút, nhưng nó khó thực hiện. Vâng, tôi đoán đó là một vấn đề của con người và một sự thay đổi của con người trong những gì chúng ta đã làm. Vâng, đó là một câu hỏi hay. Tôi nghĩ tôi thích nó. Cảm ơn bạn.

Hệ thống Doanh nghiệp, Brownfield và Quan trọng Sống còn

Cảm ơn bài nói chuyện. Rất nhiều pattern (mô hình) trùng khớp. Tôi tự hỏi điều gì là cần thiết, bạn có thể đề xuất những pattern nào để đưa nó lên cấp độ tiếp theo nếu bạn làm việc trên các hệ thống enterprise (doanh nghiệp), brownfield (kế thừa), mission critical (quan trọng sống còn) mà không thể thất bại, không thể thiếu bảo mật. Nếu bạn nhìn vào các cuộc tấn công supply chain (chuỗi cung ứng) gần đây và bạn cung cấp cho tác nhân của mình các môi trường biệt lập (sandbox), có lẽ điều đó vẫn chưa đủ. Vậy con người vẫn phải chịu trách nhiệm, và chúng ta không thể nói rằng "đó không phải lỗi của tôi, tác nhân của tôi đã làm điều đó". Bạn có bất kỳ pattern bổ sung nào không, hay chúng ta chỉ đơn thuần là phải tiếp tục đọc mã, điều có thể giống như đọc mã assembly (hợp ngữ) vào những năm 80? Tôi nghĩ nếu bạn có thể dành nhiều compute (tài nguyên tính toán) và mã thông báo (token) ngay từ đầu trước khi bạn, với tư cách là con người, thực sự cần tham gia. Tôi nghĩ đó là một pattern mà chúng tôi thấy khá thành công. Vì vậy, một điều là viết test (kiểm thử) thủ công cho các phần rất quan trọng của hệ thống và sau đó để các tác nhân chạy chúng rất nhiều. Phần thứ hai là xây dựng tự động hóa cho nhóm bảo mật của chúng tôi; họ đã xây dựng hệ thống bảo mật, đó là một tự động hóa chuyên tìm kiếm các invariance (bất biến) rất cụ thể của hệ thống và họ chạy 10 invariance này trên các PR nhất định thay đổi các tệp cụ thể. Và sau đó, vâng, tôi nghĩ nó cũng hơi phụ thuộc vào ngữ cảnh, nhưng vâng, chỉ cần chi tiêu nhiều mã thông báo trước đó và cố gắng tìm các variant (biến thể) khác nhau và gần như là red teaming (kiểm thử xâm nhập). Vì vậy, một điều tôi đã làm là thay vì tập trung vào velocity (tốc độ) và throughput (thông lượng), tôi tập trung vào quality (chất lượng). Xin lỗi, gì cơ? Tôi sử dụng AI để tập trung vào quality và chỉ cải thiện các test và làm cho nó hoàn toàn sẵn sàng cho AI. Vâng, tôi nghĩ điều đó rất tốt vì nếu bạn với tư cách là con người tin tưởng các test, bạn có thể đang tin tưởng output (đầu ra) ngay cả khi bạn không cần xem mã, và đó là nơi chúng ta đang hướng tới. Cảm ơn bài thuyết trình tuyệt vời của bạn.

AI Hỗ trợ Xây dựng Hàng rào Bảo vệ và Quy tắc

Tôi thấy mình thiếu sót trong việc sử dụng guide routes (lộ trình hướng dẫn), đặc biệt là các rule (quy tắc) và hook (điểm móc). Một phần là vì trong quá khứ, kiến thức về cách thực hiện điều đó đúng cách rất phân tán và phi tập trung trên toàn web, vì vậy bạn sẽ có những GitHub repo (kho lưu trữ GitHub) độc đáo sẽ không cố gắng tập trung kiến thức này, hoặc có thể bạn sẽ có một số bài viết trên Medium hoặc có thể Cursor cùng công ty Cursor sẽ viết một bài đăng trên blog về điều này. Mặc dù vậy, nó vẫn rất phát triển và khả năng của bản thân các model (mô hình), đặc biệt là về instruction following (tuân thủ hướng dẫn), cũng đang phát triển và chúng đang trở nên tốt hơn về mặt đó, và nó luôn cảm thấy giống như duct taping (chắp vá) đối với tôi. Vì vậy, về cơ bản, tôi tự hỏi liệu chúng ta có thể có AI giúp chúng ta điều đó không? Nghĩa là, ví dụ, Cursor có thể cung cấp cho chúng ta các tác nhân chủ động (proactive agent) hoặc một số thiết lập mới hoặc các loại thiết lập wizard (trợ lý) nơi chúng ta có thể xác định workflow (quy trình làm việc) của mình và sau đó giúp AI xây dựng các rule và hàng rào bảo vệ cũng như tất cả các artifact (hiện vật) rule đó cho chúng ta. Vì vậy, có lẽ chỉ là một tác nhân chủ động, có lẽ chúng ta sẽ có một tác nhân quét workflow của chúng ta trên toàn cầu và sau đó giúp chúng ta xây dựng những artifact đó. Bạn nghĩ sao về điều đó? Các bạn có nghĩ về điều này trong công ty không? Có lẽ các bạn có đang làm việc về điều đó không? Vâng, hoàn toàn có. Tôi nghĩ bây giờ có hai nơi chúng ta có thể làm điều này. Một là trong chính sản phẩm với toàn bộ, với sản phẩm continual learning (học hỏi liên tục). Để tôi xem. Ồ, tôi chưa cài đặt nó. Chúng ta có một marketplace (chợ ứng dụng).

Học liên tục và Sự tin cậy của Tác nhân AI

Vâng, với kiểu plugin học tập liên tục để thực sự xem xét các bản ghi transcript của bạn, các quy tắc trích xuất và bộ nhớ, v.v., đó là một cách để thực hiện. Sau đó, có một thế giới khác mà bạn thay đổi weight của mô hình tùy thuộc vào cơ sở mã của bạn trông như thế nào và các kỹ sư của bạn đang làm gì trong một nhóm cụ thể. Bạn điều chỉnh chúng và đó là học tập liên tục thực sự, không phải plugin "hacky" này, và bạn thực sự tích hợp điều đó vào mô hình để chúng thực sự biết sở thích của bạn, v.v. Nhưng hoàn toàn, bộ nhớ và các quy tắc, và tất cả những điều đó, tôi nghĩ điều đó ngày càng trở nên quan trọng hơn theo thời gian, bởi vì đó là điều đang thiếu. Đó là điều đang ngăn cản tôi có nhiều niềm tin vào các tác nhân đôi khi, bởi vì tôi nói điều gì đó và chúng quên mất, nhưng chúng trông giống như các máy trạng thái (stateless machines). Vậy làm thế nào để chúng ta nắm bắt được kiến thức này? Vì vậy, tôi nghĩ chúng ta nên dành nhiều thời gian và công sức hơn để xây dựng các hệ thống này.

Nếu tôi có thể tiếp lời, bạn nói rằng bạn dường như muốn bắt đầu một dự án hoặc đi sâu vào một dự án đã tồn tại trong cơ sở mã và sau đó xây dựng các quy tắc dựa trên đó. Còn nếu chúng ta có các quy tắc trước và muốn bắt đầu một cơ sở mã, một dự án mới thì sao? Làm thế nào để chúng ta thực sự có những quy tắc tốt cho chúng ta? Bạn có nghĩ rằng con người vẫn nên làm điều đó hay chúng ta cũng có thể tự động hóa nó? Chúng ta có quy trình làm việc (workflow) tốt nhất mới cho điều đó không? Tôi nghĩ điều đó khó, bởi vì quan điểm của tôi về các quy tắc giống như cầu nối giữa hành vi của mô hình và hành vi của con người, và làm thế nào để chúng ta điều khiển các mô hình theo cách mà chúng tuân theo những gì tôi, với tư cách là con người, muốn làm. Và trong một dự án mới, tôi không thực sự chắc chắn mình muốn làm gì. Tôi muốn outsource điều đó cho mô hình và xem chúng đang làm gì ở đây. Tôi có thể chạy các mô hình khác nhau không? Chúng có muốn kết hợp chúng không, hay tôi muốn loại bỏ mọi thứ? Vì vậy, tôi nghĩ điều đó khó. Ví dụ tốt nhất về một quy tắc mà tôi có thể nghĩ ra nội bộ là cho bug bot. Khi chúng tôi thực hiện các database migration, chúng tôi không thực sự sử dụng foreign key trên database vì lý do hiệu suất. Và các mô hình như cách đúng để làm là sử dụng foreign key. Vì vậy, chúng sẽ luôn thêm một foreign key. Nhưng khi nó hit GitHub và một PR được tạo, chúng tôi có bug bot kiểm tra và nó đang review. Nó nói, "Ồ, tôi có quy tắc này nói rằng chúng ta không bao giờ nên sử dụng foreign key." Vì vậy, sau đó nó gắn cờ điều này. Đó là khoảng cách giữa con người và mô hình và những gì chúng ta mong muốn (intent) so với những gì chúng có. Vì vậy, tôi nghĩ các quy tắc nên xuất hiện một cách linh hoạt theo thời gian. Và trước đó, bạn có lẽ nên điều chỉnh các spec và kế hoạch tạm thời (ephemeral) này.

Tự động hóa kiểm thử GUI và Kiểm thử chấp nhận người dùng

"Ồ, vâng. Cảm ơn Eric vì bài nói chuyện. Sự tiến hóa và niềm tin là một điểm lớn. Tôi muốn biết làm thế nào bạn thực hiện kiểm thử GUI và kiểm thử chấp nhận người dùng (user acceptance testing) một cách tự động và nếu bạn có thể trình bày quy trình làm việc (workflow) của mình. "

Hoàn toàn. Cách tốt nhất hoặc cách chính tôi làm là sử dụng... hãy xem nào. À vâng, tôi có cái này chẳng hạn. Cách chính tôi làm là sử dụng các agent trên Claude của Cursor cùng với computer vision mà chúng tôi có. Vì vậy, tôi sẽ xuất bản cái này. Tôi không biết, điều đó thật tệ. Tôi đoán chúng ta sẽ không làm điều đó. Tôi có trang web này đang chạy một... tôi có bảy component như một nút (button), một dropdown, v.v. Các web component và sau đó tôi đang tạo từng component này bằng một mô hình khác nhau. Và bởi vì tôi muốn so sánh dropdown của Composer trông như thế nào so với dropdown của GPT-5.4 và tôi đặt cái này vào một grid. Nhưng khi tôi tạo trang web này, có một lỗi ở chỗ tôi có nút "xem mã" (view code) này để tôi thực sự có thể xem mã được tạo (generated code). Nó không hoạt động bởi vì mô hình không bundle mã thực tế. Vì vậy, tôi đã vào Cursor và tôi đã nhấp khi nhấp vào "xem mã" trên component đó, nó hiển thị code loaded. Và nó giống như một mô tả rất ngắn gọn.

Vì vậy, tác nhân đã làm gì? Bạn có thể thấy ở đây, nó đã khởi tạo server cục bộ của tôi. Nó bắt đầu nhấp xung quanh và nhấn Enter. Chúng ta có thể thấy Cursor ở đây. Và nó đã tạo ra một bản ghi giống như Screen Studio, trong đó nó cắt, tăng tốc và phóng to, v.v. Vì vậy, ở đây, nó đã mất một lúc vì computer vision khá chậm. Nó đang tiêu thụ rất nhiều mã thông báo. Và chúng ta có thể thấy chúng ta có nút "xem mã" này. Và bây giờ chúng ta thực sự có thể thấy nó cũng đang hoạt động. Vì đây là một sản phẩm phụ đối với tôi, tôi không thực sự định xem mã. Tôi chỉ định xem nó có hoạt động không và tôi sẽ merge nó. Nhưng bạn có thể tiếp tục lời nhắc cho mô hình để làm những việc rất cụ thể cho bạn, chẳng hạn như: "Bạn có thể làm theo những hướng dẫn cụ thể này không, chẳng hạn như một luồng đăng nhập (login flow)?" Bạn nên nhấp vào nút. Bạn nên đăng nhập. Hầu hết các bước đăng nhập này có lẽ rất phổ biến đến mức bạn có thể chỉ cần lời nhắc mô hình để nói: "Đi tới URL này và nhấp vào đăng nhập" hoặc "đăng nhập." Và nó sẽ hiểu các bước cần thực hiện. Nhưng sau đó bạn có thể yêu cầu mô hình nhập mật khẩu sai hoặc nhập email sai và xem kết quả từ trang web là gì. Và có thể trang web đang đưa ra thông tin đăng nhập sai. Và sau đó tác nhân sẽ hiểu: "Ồ, tôi cần nhập thông tin đăng nhập đúng." Giống như bạn sẽ thuê một nhà tư vấn QA và đưa cho họ hướng dẫn. Bạn chỉ cần đưa cùng một hướng dẫn cho tác nhân. Vì vậy, đây là một cách để thực hiện. Tôi đoán cách khác sẽ là Playwright hoặc Puppeteer và chỉ tự động hóa một thứ trình duyệt, điều này có tính xác định hơn vì bạn có thể review nó. Và check in nó và để những người khác tái sử dụng nó. Điều đó có trả lời câu hỏi không?

Câu hỏi của tôi thiên về kiểm thử chấp nhận người dùng (user acceptance testing) để kiểm tra xem liệu thứ này có thực sự trông đúng không, bởi vì kiểm thử đăng nhập bạn có thể làm, bạn có thể tự động hóa điều đó mà không cần tác nhân. Trang web trông có đúng không? Nó có nhất quán trên tất cả các trang được tạo không và những thứ tương tự?

Kiểm tra tính nhất quán trực quan với Tác nhân AI

Vâng, tôi đã sử dụng rất nhiều Claude agent cho việc đó. Có một lần tôi không thể nhớ bây giờ. Nhưng tôi nghĩ tôi đã thực hiện một số thay đổi trong tài liệu. Và tôi chỉ yêu cầu nó mở mọi instance mà từ này được tham chiếu. Chụp ảnh màn hình và gửi lại cho tôi. Sau đó, tôi có thể xem tất cả các ảnh chụp màn hình khác nhau, mọi thứ đều tốt, và sau đó tôi có thể merge mã. Vì vậy, việc để các tác nhân thực hiện điều hướng và nhấp chuột xung quanh và kiểm thử cho bạn, tôi nghĩ nó hoạt động tốt một cách đáng ngạc nhiên. Đây giống như một khoảnh khắc AGI đối với tôi khi chúng tôi ra mắt tính năng này vào khoảng thời gian cuối năm ngoái nội bộ.

Bạn đã có thời gian thử Claude agent trong Cursor chưa? Bạn nên thử.

Cái nào? Cái này? Vâng, đó là câu hỏi ban đầu. Mất bao lâu? Rất đơn giản. Đối với cái này, tôi không thực hiện bất kỳ thiết lập cụ thể nào cho repository riêng của chúng tôi nơi chúng tôi có... khi chạy Cursor. Vì vậy, chúng ta thực sự có thể tái tạo bản demo này ở đây. Nó đang chạy tất cả các backend service cho Cursor. Nó đang chạy tất cả các thứ frontend. Và đây là rất, rất nhiều thứ khác nhau. Vì vậy, VM khá mạnh. Nhưng miễn là chúng ta đưa ra hướng dẫn đúng, nó hoạt động thực sự tốt. Những gì chúng tôi đã làm là tạo ra một CLI nội bộ mà tác nhân có thể sử dụng để giống như, chúng tôi gọi nó là Cursor Dev Tool, Cursor Dev Tool backend start, Cursor Dev Tool frontend start. Và điều đó trừu tượng hóa mọi thứ thực sự cần thiết để khởi chạy OrbStack để chạy ClickHouse và Postgres và Redis. Và sau đó frontend chạy Electron và sau đó là Glass ở đây. Nhưng sau đó chúng chỉ đơn giản là cùng tồn tại trong hai tiến trình khác nhau. Và chúng không có quyền truy cập vào mọi thứ như con người. Và bạn có thể có authenticated nếu bạn lưu trữ một snapshot nơi bạn đã authenticated.

Chi phí và Thiết lập Tác nhân AI

Ồ, xin lỗi, xin lỗi, xin lỗi. Được rồi, được rồi. Tôi sai rồi, tôi sai rồi. Vâng, cái này tôi không thực sự có. Tôi có thể tìm nó. Tôi đoán cái này khoảng 1 đô la hoặc gì đó. Có lẽ cái ban đầu này sẽ là 1 đô la. Và những cái khác tôi chỉ yêu cầu ghi lại một loạt các thứ khác nhau. Một cái gì đó giống như tôi có thể tìm nó sau, hoàn toàn. Vâng, tôi đoán nó cũng phụ thuộc vào mô hình bạn đang thấy.

Chuyển giao công việc giữa Con người và Tác nhân AI

Được rồi. Câu hỏi của tôi là về việc chuyển giao giữa con người và tác nhân bất cứ khi nào bạn đang sử dụng các công cụ khác nhau. Vì vậy, trong thiết lập hiện tại của tôi, tôi có một Product Owner và một Functional Analyst đang làm việc. Và họ prototype rất nhanh. Chúng tôi về cơ bản không cần suy nghĩ nhiều về backend, các lựa chọn kiến trúc hay bất cứ điều gì. Và sau đó họ chuyển quyền kiểm soát cho nhóm delivery sử dụng Cursor và phải làm cho những thứ đó thực sự hoạt động. Bạn đề xuất những best practice nào để đảm bảo một workflow phù hợp giữa những người về cơ bản không biết họ đang làm gì về mặt kỹ thuật, tất nhiên. Và những người cần mang thứ đó mà có thể có một số lựa chọn kém như: "được rồi, sử dụng database đó," hoặc sau đó Claude Code thay đổi ý tưởng và họ chuyển từ một Superbase sang một Turso sang bất kỳ loại database lạ mắt nào khác thực sự có trong môi trường đó. Và sau đó đưa điều đó vào một số lựa chọn kiến trúc hợp lý di chuyển từ Claude Code sang Cursor.

Tôi nghĩ những gì chúng tôi đang làm nội bộ là bằng cách một hoặc hai PM và họ đang xây dựng rất nhiều prototype khác nhau. Đôi khi nó thực sự nằm trong sản phẩm thực tế. Họ đang sử dụng có thể là Claude agent và chỉ lời nhắc chúng. Họ đang nhận được một video như thế này về các thay đổi. Và giống như: "Ồ, nó trông giống như tôi muốn và sau đó nó điều chỉnh các dấu hiệu một chút." Nhưng mã có thể rất tệ hoặc không tuân theo các best practice. Mà nếu họ có một factory tốt thì có lẽ sẽ có. Nhưng nếu trường hợp đó xảy ra, chúng tôi chuyển giao một link đến các Claude agent. Chúng tôi chỉ sao chép link và gửi nó cho các kỹ sư như: "Này, đây là thứ chúng tôi muốn xây dựng. Điều này có hợp lý không? Chúng ta có thể làm điều này không?" Và sau đó bạn đã có rất nhiều ý định (intent) được thể hiện. Nhưng trường hợp khác là PMs có một repo riêng gọi là prototypes. Và đó chỉ là một file HTML giống như một mega HTML file và tái tạo UI của Cursor hoặc dashboard.

Vâng, vấn đề là migration. Vì vậy, một trường hợp sử dụng cụ thể mà tôi đã có là PO và nhóm functional của tôi đã xây dựng một bản demo rất fancy sử dụng Prisma và Turso hoặc bất kỳ database nào, và sau đó lưu trữ dữ liệu trên Vercel Blob Storage. Và sau đó nhóm delivery của tôi phải di chuyển điều đó để sử dụng SQL Server và C# và Aspire cho backend. Và việc migration thực sự đau đớn. Vâng. Ngay cả khi họ sử dụng tác nhân một cách tự do mà không có ràng buộc, tác nhân đôi khi quyết định sử dụng Next.js, đôi khi quyết định sử dụng Vue và đôi khi quyết định sử dụng Svelte. Và việc đặt các ràng buộc dưới dạng quy tắc (rules) trong tác nhân đó đã định hình con đường đó, nhưng vấn đề là chúng ta cần viết rất nhiều quy tắc và làm cho chúng nhất quán và không dễ dàng để quản lý tất cả công việc. Vì vậy, chúng ta đang chuyển rất nhiều nỗ lực từ việc có người viết mã sang việc có người viết hướng dẫn (guidelines) và quy tắc và bất cứ thứ gì, và làm cho tất cả các phần nói chuyện với nhau.

Tôi hiểu, vâng, vâng. Tôi đoán nếu POs và PMs không thể truy cập vào cơ sở mã thực tế, thì việc chuyển giao một artifact giống như ý định khả thi tối thiểu (minimum viable intent), có thể giống như một Figma prototype (Figma prototype) ngày xưa, bạn có thể nhấp xung quanh và bạn có được cảm giác về nó. Bây giờ bạn có thể có chúng với độ trung thực cao hơn, nơi bạn có một interactive prototype sử dụng công nghệ web mà không cần chạm vào bất kỳ thứ gì trên backend, nơi nó không cần phải là một thứ hoạt động thực sự nếu nó chỉ là một prototype nội bộ, nhưng đủ để các kỹ sư của bạn có thể hiểu: "Ồ, đây là điều được ý định (intended). Nếu tôi nhấp vào điều này, điều đó sẽ xảy ra, hoặc nếu tôi nhập một số văn bản ở đây và nhấp vào gửi, một hàng sẽ xuất hiện ở đây." Và tôi nghĩ tất cả những điều đó có thể được thực hiện ở front-end giống như một hackathon.

Viết lại so với Di chuyển & Quản lý Kỳ vọng

Bạn không nghĩ đến việc di chuyển sản phẩm thành một thứ thực sự sẵn sàng để sản xuất mà thay vào đó là viết lại nó. Vâng, tôi nghĩ vậy. Tôi nghĩ chúng tôi đang viết lại, và tôi nghĩ rằng việc đặt ra kỳ vọng rõ ràng từ kỹ sư đến các PM (Quản lý sản phẩm) và từ PM đến kỹ sư về những gì kỹ sư mong muốn từ tổ chức sản phẩm và điều gì hữu ích nhất cho họ là quan trọng. Có lẽ việc không phải web-coding các SaaS products hoàn chỉnh là điều hiệu quả nhất.

Rủi ro từ Tác nhân & Chiến lược Giảm thiểu

Tôi xin cảm ơn bài trình bày của bạn. Câu hỏi của tôi là: Khi chúng ta xây dựng ngày càng nhiều tác nhân (agent) và chúng trở thành một phần của các quy trình quan trọng về thời gian, bạn nhìn nhận brownouts (sự cố ngừng hoạt động một phần) và blackouts (sự cố ngừng hoạt động toàn bộ) như một rủi ro mới như thế nào? Và quan điểm của bạn về cách giảm thiểu rủi ro và tác động của chúng là gì? Vâng, đó là một câu hỏi tuyệt vời, thực sự rất hay. Tôi nghĩ nó quay trở lại điều chúng ta đã thảo luận: Con người vẫn phải chịu trách nhiệm về những gì được triển khai. Vì vậy, con người cần xây dựng các hệ thống, khả năng quan sát (observability) và giám sát xung quanh các thay đổi đang được thực hiện. Và tôi nghĩ rằng điều đó vẫn đòi hỏi phải hiểu rõ đâu là những khu vực quan trọng của cơ sở mã (codebase), đảm bảo bạn có khả năng quan sát (observability) tốt và hiểu rõ mọi thứ đang diễn ra. Có lẽ mọi dòng mã trong những phần quan trọng này nên được con người viết, hoặc ít nhất là luôn được một hoặc hai người xem xét thủ công. Và vâng, rất dễ để viết mã nhanh chóng và bỏ qua các bước kiểm tra. Vì vậy, tôi nghĩ đó cũng là một vấn đề văn hóa, nơi bạn phải đảm bảo rằng con người vẫn chịu trách nhiệm về những gì được triển khai. Nhưng vâng, thiết lập các hệ thống tốt để hiểu các thay đổi đang được thực hiện, tôi nghĩ điều đó rất quan trọng, cùng với việc kiểm thử.

Quy trình làm việc cá nhân & Quản lý Tác nhân

Eric, cảm ơn bạn rất nhiều vì buổi nói chuyện. Tôi đoán rằng bạn có lẽ là một trong những người trên thế giới hiểu rõ nhất cách sử dụng các công nghệ này. Vì vậy, câu hỏi này đưa chúng ta quay lại từ khía cạnh công nghệ để nói về quy trình: Bạn quản lý bản thân như thế nào trong những ngày làm việc? Và tôi tự hỏi những tác vụ (task) này kéo dài bao lâu, hoặc bạn có thể rời xa các tác nhân (agent) của mình mà không cần giám sát liên tục (babysitting) chúng trong bao lâu? Và bạn thực sự tận dụng khoảng thời gian này như thế nào? Giả sử bạn có năm, mười, mười lăm phút, làm thế nào để bạn tận dụng tối đa thời gian của mình? Và có lẽ bạn có bao nhiêu tác nhân (agent) chạy song song, giống như các quy trình tinh thần, và bạn quản lý bản thân như thế nào? Cảm ơn rất nhiều. Vâng, đó là một câu hỏi tuyệt vời. Và tôi nghĩ rằng một khi bạn... có hai đòn bẩy để kéo. Một là phạm vi thay đổi (scope of the change). Phạm vi càng lớn thì các tác nhân (agent) sẽ chạy càng lâu. Và nếu bạn muốn chúng chạy trong một thời gian thực sự dài, bạn cần có một hệ thống rất khả thi để chúng có thể tự kiểm tra công việc của mình, v.v. Và điều còn lại là bạn có thể song song hóa (parallelize) bao nhiêu? Giống như bạn có thể khởi tạo bao nhiêu tác nhân (agent) trong số này? Và tôi nghĩ thực tế đáng buồn, ở một khía cạnh nào đó, là sẽ có rất nhiều chuyển đổi ngữ cảnh (context switching). Tôi có lẽ làm việc đồng thời trên bốn repo khác nhau hoặc bốn khu vực khác nhau của cơ sở mã (codebase), cho dù đó là thông qua một tính năng duy nhất yêu cầu front end, back end, database testing, v.v., hay đó là năm điều hoàn toàn khác nhau. Nó có thể là tài liệu (docs), có thể là các sản phẩm phụ (side products) tôi đang khám phá, có thể là sửa một lỗi từ một người dùng Twitter. Nhưng thông thường, chúng dao động từ khoảng năm đến mười tác nhân (agent) – năm tác nhân (agent) chạy bất đồng bộ (asynchronously) trên đám mây (Claude) mọi lúc. Và trong khi chờ đợi những điều này, tôi hoặc là cuộn Twitter, hoặc đúng vậy, tôi cũng có trình duyệt trong Cursor bây giờ, vì vậy tôi có thể ở ngay đây và làm việc. Hoặc tôi có các tác vụ đồng bộ (synchronous task) đang diễn ra mà tôi phải làm đi làm lại một chút. Có thể đó là sửa một lỗi nhỏ trong cơ sở mã (codebase), hoặc có thể đó là lập kế hoạch cho việc tiếp theo. Có thể tôi đang sourcing thông tin từ Notion và Slack và chỉ tạo một spec trong Cursor bằng cách sử dụng một mô hình (model). Vì vậy, tôi thích lập kế hoạch đồng bộ (synchronously) và sau đó thực hiện các kế hoạch bất đồng bộ (asynchronously). Và sau khi điều đó hoàn tất, một trong các tác nhân đám mây (Claude agents) của tôi có lẽ cũng đã hoàn thành. Vì vậy, tôi có thể quay lại và xem xét, tiếp tục tối ưu hóa lời nhắc (prompting) một chút, có thể hợp nhất một số phần tôi vẫn cần kiểm tra thủ công (manually). Ví dụ, có thể tôi cần tải xuống một bản sao của Glass hoặc Cursor 3, kiểm tra thủ công (manually), và nói, "Điều này có vẻ tốt đối với tôi, hãy tiến hành hợp nhất." Cảm ơn bạn.

Tổ chức "Nhà máy" Tác nhân & Tính năng Cursor

Một câu hỏi nhanh: Việc xây dựng nhà máy (factory building) này để lại cho chúng ta một hệ sinh thái phân tán với rất nhiều tệp Markdown (markdown files). Có cách nào dễ dàng để tổ chức các tệp này và giữ một cái nhìn tổng quan về nhà máy mà bạn đã xây dựng không? Vì việc duy trì một nhà máy sẽ yêu cầu bạn có cái nhìn tổng quan về các quy trình mà bạn muốn các tác nhân mã hóa (coding agent) của mình thực hiện. Bạn sử dụng những công cụ (tool) nào, bạn đề xuất những phương pháp (method) nào? Làm thế nào để bạn giữ một sơ đồ tư duy (mental map) về nhà máy bạn đã xây dựng và làm thế nào để bạn duy trì nó? Vâng, đó là một câu hỏi thực sự hay. Tôi nghĩ nó cũng còn khá là chưa được giải quyết. Một trong những lý do chúng tôi xây dựng lại Cursor để trông như thế này thay vì IDE truyền thống là vì chúng tôi đang sử dụng nhiều tác nhân (agent) hơn và chúng tôi cần một bảng điều khiển (control panel) tốt hơn, nơi bạn có thể xem tất cả các tác nhân (agent), quản lý và khởi tạo chúng, v.v. Vậy, điều gì sẽ xảy ra với Cursor 3 – đây là bước thử nghiệm đầu tiên cho một môi trường làm việc đa tác nhân (multi-agent workstation) – điều sẽ xảy ra là các tác nhân này sẽ được lồng vào nhau (nested agents). Vì vậy, bạn sẽ mở một tác nhân này ra và bạn sẽ có khoảng 10 tác nhân khác bên trong. Do đó, bạn vẫn có thể kiểm tra nội bộ (introspect) chúng và xem điều gì đang diễn ra bằng cách theo dõi các dấu vết (traces). Nhưng bạn có thể cũng sẽ có một chế độ xem dự án (project view) nào đó ở đây, nơi bạn có thể thấy các cập nhật trạng thái tổng hợp (aggregated status updates), chẳng hạn như "Đây là những gì mọi người đang làm" và "Đây là những thông tin mới nhất," "Đây là những gì người dùng (human) cần xem xét." Vì vậy, tôi nghĩ đây là những tính năng sản phẩm (product things) mà chúng tôi sẽ xây dựng vào Cursor. Nhưng để đặt spec cho nhà máy, tôi có lẽ sẽ có một thư mục trong cơ sở mã (codebase) của bạn, nơi bạn vạch ra cách một số thứ nhất định nên hoạt động. Có thể đó chỉ là các tệp Markdown (markdown files) nói rằng "Đây là một số best practices," có lẽ là các quy tắc, và thành lập một loại hội đồng (counsel) để quyết định điều gì sẽ đi vào nhà máy và điều gì không, và chúng ta đang thiếu gì để cải thiện nhà máy. Vì vậy, miễn là đó là thứ mà các tác nhân (agent) có thể hiểu và đọc được, tức là các tệp, thì đó có lẽ là điều tôi sẽ làm và chỉ lưu trữ chúng trong cơ sở mã (codebase) của bạn đã được check in ở đâu đó. Cảm ơn bạn.

Tương lai của Đội ngũ Kỹ thuật & Vai trò

Cảm ơn bạn. Tôi chỉ đang nghĩ về các nhóm trong tương lai. Bạn biết đấy, một hoặc hai năm trước, việc có một đội ngũ kỹ thuật (engineering team) gồm vài trăm người, thậm chí vài nghìn người là điều rất hợp lý. Vậy điều này sẽ tác động đến điều đó như thế nào, và những vai trò (roles) nào cho đội ngũ kỹ thuật? Đúng vậy, điều này giống như việc gần như trở thành sự kết hợp giữa một quản lý sản phẩm (product manager) và một kiến trúc sư (architect). Vậy các kỹ sư (engineer) sẽ có những vai trò (roles) gì? Vâng, tôi nghĩ điều đó rất chính xác. Rất khó để dự đoán những hiệu ứng bậc hai, ba, bốn (second, third, fourth order effects) của sự việc này. Và chắc chắn nó giống như việc viết ít mã hơn, xem ít mã hơn, khởi tạo nhiều tác nhân (agent) hơn. Nó sẽ là về việc làm thế nào để bạn... vì chúng ta vẫn chủ yếu xây dựng phần mềm cho con người, vậy làm thế nào để chúng ta biết những gì người khác muốn? Làm thế nào để chúng ta nói chuyện với khách hàng? Làm thế nào để chúng ta tiếp thị những gì chúng ta đang xây dựng? Làm thế nào để chúng ta làm tất cả những điều này và đưa chúng vào nhà máy thực tế? Ai đặt ra định hướng? Ý định là gì? Tất cả những điều này đều đến từ một nơi nào đó, hoặc là sự sáng tạo từ đầu óc của người khác, hoặc thực sự là nhu cầu người dùng (user demand). Vì vậy, việc có người làm điều đó sẽ rất quan trọng. Việc có người điều phối (aligning) điều đó giữa những người khác nhau trong tổ chức (org) tôi nghĩ sẽ rất quan trọng. Việc có người xây dựng giàn giáo (scaffolding) cho các tác nhân (agent) khác, chỉ cần xây dựng dây chuyền lắp ráp (assembly lines) nơi các tác nhân (agent) thực sự có thể chạy, tôi nghĩ điều đó cũng sẽ quan trọng. Nhưng ở mức độ nào và bao nhiêu người sẽ như thế... vâng, tôi không biết, thực sự rất khó. Bạn có thể làm rất nhiều với các mô hình (model) ngay bây giờ với một đội ngũ (team) rất nhỏ nếu bạn có những thiết lập phù hợp. Và vâng, tùy thuộc vào lĩnh vực (domain) bạn đang làm việc, tôi không biết. Bạn có bất kỳ dự đoán (predictions) nào không? Tôi thấy các vấn đề từ góc độ lao động (labor perspective) nếu bạn đang làm việc trong một môi trường dựa trên tác nhân (agentic environment) đáng kinh ngạc, nhu cầu của bạn là gì để... như là, điều gì sẽ xảy ra với việc đào tạo sinh viên mới ra trường (training new grads), tuyển dụng sinh viên mới ra trường (hiring new grads) và tương lai từ góc độ (perspective) đó? Điều gì sẽ xảy ra với chính trị công sở (office politics) và land grabbing? Đúng vậy, bởi vì về cơ bản, giá trị (value) của bạn bây giờ nằm ở khả năng cấu hình (configure) và thiết lập đội ngũ tác nhân (agentic team) của riêng bạn, chứ không phải ở khả năng lập trình và năng suất (productive) nữa. Kỹ thuật 10x (10x engineering) không còn là về, bạn biết đấy, số từ mỗi phút (words per minute); nó là về tối ưu hóa lời nhắc (prompting). Vâng, token usage. Vâng, tôi được trả tiền bằng mã thông báo (tokens). Vâng, bảng xếp hạng (leaderboard). Bạn biết đấy, tôi sẽ nói chuyện bên cạnh pader của tôi trong một mount, và sau đó token usage của tôi lấy đi từ đó. Bạn biết đấy, làm thế nào để bạn tối ưu hóa (optimize)? Chúng ta phải đào tạo mô hình (model) để trở nên chính trị (political) hơn. Tôi nghĩ đó là giải pháp, đúng không? Chúng ta cần nhiều hơn nữa, như là điều gì thú vị? Tôi đoán chúng ta sẽ có nhiều điều đó hơn nếu các tác nhân (agent) đang làm công việc của chúng ta.

Tích hợp Tác nhân với Công cụ Quản lý Vấn đề & Tự dùng Sản phẩm

Chào Eric. Này, chúng ta đang nói chuyện. Tôi tự hỏi, có lẽ bạn đang sử dụng ở Cursor một loại công cụ quản lý vấn đề (issue tracking tool) nào đó như Atlassian hoặc Jira, đúng không? Tôi tự hỏi liệu bạn có đang sử dụng các tác nhân (agent) để tự động kiểm tra và đọc các tác vụ (task) trực tiếp từ Jira chẳng hạn, và khởi tạo các tác nhân con (sub-agent) để thực hiện công việc, hay luôn có một con người bắt đầu làm việc bằng Cursor? Chúng tôi đang sử dụng Linear để quản lý vấn đề (issue management), và chúng tôi cũng có phần tích hợp (integration) đầu tiên này. Vì vậy, đối với mỗi ticket được tạo trong Linear, chúng tôi khởi tạo một tác nhân đám mây (Claude agent). Ví dụ, cách tôi giao tiếp (interface) nhiều nhất với điều này là khi chúng tôi có cờ tính năng (feature flags) trước khi một tính năng cụ thể được triển khai, và nếu nó đã được triển khai trong hai tuần với 100%, hệ thống sẽ tự động gửi tín hiệu, "Này, đây vẫn là một cờ tính năng (feature flag) vào thời điểm này, bạn có thể loại bỏ nó." Sau đó, chúng tôi có điều này để tạo một vấn đề tự động (automatic issue) trong Linear, và vì nó được kết nối (hooked up) với Cursor, nó kích hoạt một tác nhân đám mây (Claude agent) để loại bỏ cờ tính năng (feature flag). Vì vậy, nó giống như hoàn toàn tự động (automatic) một khi hệ thống biết rằng nó đã được triển khai cho tất cả mọi người. Và tôi có thể, ví dụ, tôi có lẽ có thể xem mã và nói, "Được rồi, chúng ta có thể hợp nhất cái này, tính năng này không còn hoạt động nữa." Và chúng tôi làm điều này cho mọi thứ. Vì vậy, một khi bạn đăng một cái gì đó lên Slack, chúng tôi hoặc có các tác nhân Slack của Linear (Linear Slack agents) xem xét nó, hoặc chúng tôi có một tự động hóa Cursor (Cursor automation) để xem xét tin nhắn đã được đăng và phân loại (trioshed) nó, và tìm kiếm các bản sao (duplicates), hoặc nếu nó được xác định là dễ dàng, bắt đầu triển khai sửa lỗi (fix) ngay lập tức. Và đây là một ví dụ về việc một con người ở trong vòng lặp (loop), nơi mà có thể không cần thiết phải như vậy. Có thể là tôi lên Twitter và thấy một tweet như, "Có gì đó bị hỏng với nút thả xuống plan mode." Tôi có thể sao chép nó vào Slack và sau đó để tác nhân (agent) thực hiện công việc. Nhưng có lẽ có một cách để chúng ta có thể thu thập (source) phản hồi này ngay lập tức mà không cần tôi phải quét (scan) nó, phân loại (trioshed) và copy-paste nó. Vì vậy, đó là một chút về cách chúng tôi làm việc với Linear quản lý vấn đề (issue management). Nhưng vâng, chúng tôi cũng vậy, vì chúng tôi đang khởi tạo một tác nhân đám mây (Claude agent) cho mọi thứ, nó cung cấp một cách tốt để chúng tôi tự dùng sản phẩm của mình (dog food the product) và thử nghiệm nó. Nhưng tôi không chắc liệu tôi có khuyên điều đó cho tất cả mọi người không vì nó có thể khá tốn kém vì các tác nhân đám mây (Claude agent) hơi đắt. Bạn có thứ gì đó trong lộ trình (roadmap) để chạy cục bộ không? Giống như, tôi chỉ đang nghĩ về một giải pháp thay thế gọi là dev containers và mở nó trong đó. Nhưng bạn có kế hoạch gì trong lộ trình (roadmap) cho điều đó không? Điều tôi nghĩ gần nhất bạn có thể làm có lẽ chỉ là tối ưu hóa lời nhắc (prompt) tác nhân (agent) để chạy trong một thời gian thực sự dài. Nó giống như việc chạy các mô hình (model) cục bộ. Và gần đây, từ khi thử nó, tôi có lẽ đã thử khoảng mỗi tháng một lần chạy những cái tốt nhất...

Nâng cao khả năng Tác nhân: Từ mô hình cục bộ đến Cursor Workers

Việc sử dụng các mô hình mã nguồn mở cục bộ và xem cách chúng hoạt động trong Cursor không bao giờ mang lại trải nghiệm tương tự như khi sử dụng các mô hình LLM đám mây như GPT, Claude, hoặc Composer. Tương tự, tôi nhận thấy việc chạy các tác vụ kéo dài cục bộ thường không hiệu quả. Nếu một tác vụ chạy quá lâu, nó có thể tái sử dụng cơ sở dữ liệu và các tài nguyên cục bộ khác của bạn, ngăn bạn thực hiện các công việc khác trên máy tính cục bộ trừ khi bạn tạo một VM riêng.

Chính vì những hạn chế đó, chúng tôi đã ra mắt Cursor Workers. Cursor Worker, được giới thiệu vào ngày hôm qua, là một cách để bạn chạy cùng một hạ tầng và lớp orchestration mà chúng tôi sử dụng cho các tác nhân đám mây, nhưng trên bất kỳ máy nào bạn có. Ví dụ, bạn có thể sử dụng CLI của Agent để khởi động worker: agent worker start.

Worker này sẽ hiển thị trong hệ thống của chúng tôi dưới dạng self-hosted. Về cơ bản, bạn có thể chạy worker này trên bất kỳ loại máy nào và truy cập nó từ Cursor Claude. Bạn có thể triển khai nhiều worker trên máy riêng của mình, hoặc chạy chúng trên một Mac mini, hoặc trong một VM trên bất kỳ nhà cung cấp nền tảng đám mây nào.

Như vậy, chúng ta có thể có các môi trường biệt lập cục bộ bằng cách sử dụng lệnh này, và nó sẽ tận dụng Cursor harness. Điều thú vị là worker sẽ chạy trên bất cứ đâu bạn khởi động daemon này. Tôi đã xây dựng một tác nhân Claw của Cursor chạy trên Mac mini của mình, có quyền truy cập vào iMessage và lịch cùng nhiều thứ khác. Ngày hôm qua, chúng tôi cũng đã ra mắt tính năng tự động hóa, cho phép tôi nhận báo cáo hàng ngày hoặc hàng tuần về mọi thứ đang diễn ra trên máy của mình. Một phiên bản cụ thể đang chạy daemon của Agent sẽ cho phép bạn truy cập những báo cáo này qua Slack, web và ứng dụng di động sắp ra mắt. Nó sẽ sử dụng Swifty wise, vì vậy có thể tương thích với các vấn đề liên quan đến i-possible.

Quản lý tác nhân và Tổ chức nhóm

Một câu hỏi đơn giản được đặt ra là làm thế nào để đảm bảo nhiều nhà phát triển trong công ty không giẫm chân lên nhau khi triển khai hàng trăm tác nhân để thực hiện nhiều loại công việc khác nhau. Liệu chúng ta có sử dụng Scrum hoặc các phương pháp Agile truyền thống không?

Thực tế, chúng tôi không tuân theo bất kỳ phương pháp luận truyền thống nào. Chúng tôi có các mục tiêu theo tháng và những gì chúng tôi muốn phát hành. Tuy nhiên, vì mọi người đều có rất nhiều quyền năng trong tầm tay với các tác nhân, điều này khiến họ có tinh thần sở hữu cao đối với một số công việc nhất định. Ví dụ, trong một thời gian dài, chỉ có một người xây dựng MCP và các quy tắc cùng tất cả các tính năng hỗ trợ tiếp cận. Hiện tại, chúng tôi có thể có một người tập trung vào MCP, nhưng họ có thể sở hữu mọi thứ xung quanh MCP và không cần tương tác quá nhiều với các nhóm khác.

Tuy nhiên, tại một thời điểm nào đó, cách này cũng sẽ có vấn đề. Trong lịch sử của Cursor, chúng tôi đã tìm cách khắc phục những điều này. Ví dụ, codebase của Agent có lẽ là nơi chúng tôi đã gặp phải sự chồng chéo công việc do code owners bị cấu hình sai. Thay vì có một quy trình cứng nhắc, chúng tôi có thể đưa những người liên quan vào đúng thời điểm. Những vấn đề tương tự có thể sẽ xuất hiện trong tương lai. Hiện tại, tool use vẫn đang trong early access và chúng tôi chưa phát hành phiên bản GA (General Availability), nhưng nó sẽ sớm có mặt và sẽ hoàn toàn tương đương với Claude agent.

Hồ sơ thành viên nhóm: PM, Designer, Kỹ sư

Vậy, hồ sơ của những cá nhân kết hợp giữa Quản lý sản phẩm (PM) và Kỹ sư mà đảm nhận vai trò sở hữu này như thế nào?

Các hình mẫu chính mà chúng tôi có bao gồm PM. Họ giao tiếp rất nhiều trong nội bộ Cursor, với nhóm go-to-market và sales, với các kỹ sư và người dùng. Họ quản lý sản phẩm, tổng hợp mọi thứ lại và đồng thời bảo vệ các kỹ sư khỏi nhiều yếu tố khác nhau.

Tiếp theo là các designer. Tôi có thể nói rằng các designer làm việc 50/50 trên Figma và code ở thời điểm hiện tại. Tất cả họ đều biết code và đều thực hiện push to production. Tuy nhiên, phần lớn công việc của họ là thăm dò, ví dụ như "nó sẽ trông như thế nào khi có 10 nested sub agents?". Bạn không thể thực sự cảm nhận được điều đó trong Figma; bạn phải thực sự phát triển và prototype nó. Họ làm việc chặt chẽ với các PM.

Và tất nhiên, chúng tôi có các kỹ sư. Tôi nghĩ Cursor rất may mắn khi xây dựng các developer product, vì vậy chính các nhà phát triển đang xây dựng developer product. Họ có gu thẩm mỹ tốt, họ biết cái gì tốt và cái gì tệ, họ biết các nhà phát triển muốn gì và không muốn gì. Tôi nghĩ chính vì điều đó mà họ có thể nắm quyền sở hữu và đi rất xa với một ý tưởng. Trong khi đó, PM có thể đặt ra các mục tiêu kinh doanh và định hướng tổng thể, sau đó các kỹ sư và designer sẽ hợp tác để hiện thực hóa ý tưởng đó trong code, cũng như tạo ra cảm giác và giao diện phù hợp cho một nhà phát triển.

Vai trò của Phân tích dữ liệu và Cấu trúc nhóm

Có các nhà phân tích trong nhóm này không, hay công việc đó do các Quản lý sản phẩm đảm nhận?

Vâng, chúng tôi cũng có một đội ngũ dữ liệu bao gồm các nhà khoa học dữ liệu và phân tích. Họ làm việc chặt chẽ với các PM để hiểu cách người dùng sử dụng sản phẩm, các nút thắt cổ chai ở đâu. Đồng thời, họ cũng làm việc với các kỹ sư để instrument code một cách chính xác, hiểu về các feature flags và lý do tại sao một số người dùng đi theo một con đường nhất định trong khi những người khác thì không. Mọi người đều làm việc cùng nhau.

Tôi nghĩ cách chúng tôi cấu trúc đội ngũ là theo miền (domain). Ví dụ, khả năng mở rộng có thể là một nhóm, đám mây có thể là một nhóm. Và các dịch vụ đám mây vẫn cần có khả năng mở rộng, vì vậy các nhóm này cũng phải làm việc cùng nhau. Tuy nhiên, chúng tôi cố gắng giữ cấu trúc modular và không quá phức tạp hóa tổ chức của mình.

Tối ưu hóa hiệu suất Tác nhân và Khả năng quan sát

Thỉnh thoảng, tôi gặp lỗi khi khởi động một Claude agent trong một repo sai hoặc nó đi lạc hướng, và sau một giờ, chúng tôi phải cố gắng truy cập lại repo đó. Có cách nào để phát hiện những tác nhân không tạo ra giá trị, chỉ tiếp tục thực hiện công việc nhưng không đạt được tiến bộ thực sự không?

Tôi nghĩ đây chắc chắn là trách nhiệm của chúng tôi. Trong năm qua, chúng tôi đã có nhiều cải tiến đối với các Claude agent. Ban đầu, khi chúng hoạt động, chúng cực kỳ hữu ích, nhưng hầu hết thời gian thì không. Các Claude agent cũng xuất phát từ nhu cầu nội bộ của chúng tôi là muốn chạy mọi thứ bất đồng bộ. Vì vậy, chúng tôi đã nỗ lực rất nhiều để cơ sở mã của chính chúng tôi hoạt động thực sự tốt trong các Claude agent.

Đôi khi, chúng tôi cần tạo các dự án mới, nhảy vào các dự án khác và nói chuyện với khách hàng để hiểu những điểm thiếu sót. Chúng tôi đã cố gắng instrument để theo dõi xem tác nhân có chạy trong X giờ hoặc phút không, có chạm vào bất kỳ tệp nào không, hay có đang quay vòng tròn không, và phát hiện các Agent Loop dạng này. Đây là một phần của khả năng quan sát mà tôi đã nói trước đây. Hầu hết những điều đó nên diễn ra ở phía chúng tôi. Tuy nhiên, sẽ luôn có những yếu tố ngữ cảnh rất cụ thể mà chủ sở hữu codebase cần thiết lập một số thứ.

Chúng tôi đang nỗ lực cải thiện vấn đề này. Nếu bạn có bất kỳ ví dụ nào, vui lòng liên hệ với tôi và tôi sẽ cố gắng xem xét. Trường hợp tệ nhất là khi tôi khởi động nó trên một repo sai, và nó cố gắng lấy MCP từ Slack và truy cập theo 10 cách khác nhau nhưng đều thất bại. Vâng, vâng, vâng, chúng tôi có thể làm điều đó tốt hơn rất nhiều và chúng tôi đang làm việc đó.

Cảm ơn tất cả mọi người đã đến. Tôi cũng sẽ ở đây trong hai ngày tới, vì vậy hãy tìm tôi nếu bạn muốn thảo luận bất cứ điều gì về Cursor hoặc bất cứ điều gì khác.