Tóm tắt 30 giây
Bạn giao việc cho AI, nó làm rất nhanh. Nhưng sau đó bạn phải mở kết quả, kiểm tra từng chỗ, chụp màn hình lỗi, gửi lại và chờ nó sửa. Một lúc sau, bạn nhận ra mình đang quản lý AI còn vất vả hơn tự làm.
Trong video này, Lauren Tan — được giới thiệu là kỹ sư SpaceXAI — chia sẻ hành trình từ việc phải theo sát từng thao tác của agent đến mức hoàn thành khoảng 1.000 PR trong một tháng. Có buổi sáng, Lauren thức dậy và thấy khoảng 20 PR đã được agent tự hợp nhất.
Bài viết dưới đây tóm tắt những ý đáng chú ý nhất của cuộc trò chuyện. Dù phần lớn ví dụ đến từ lập trình, câu hỏi rất gần với người đi làm: làm sao giao việc cho AI mà không phải đứng bên cạnh kiểm tra mọi bước?
Điều đáng chú ý trong chia sẻ của Lauren là cách xây dựng niềm tin: cho agent khả năng kiểm tra kết quả, hướng dẫn nó hiểu môi trường làm việc và đặt những quy tắc thực sự có thể được kiểm soát.
Bài viết được biên tập từ bản chép lời video Lauren Tan - SpaceXAI engineer. Các lượt hỏi–đáp dưới đây được diễn đạt lại và sắp xếp theo chủ đề, không phải trích dẫn nguyên văn. Những đoạn “Chú thích” và ví dụ công việc ngoài lập trình là phần giải thích bổ sung của bài viết. Các số liệu về PR là chia sẻ của diễn giả trong bản chép lời.
Người hỏi: Tôi thấy một nghịch lý: AI giúp viết mã nhanh, nhưng thời gian kiểm tra và sửa lại có khi còn nhiều hơn. Có phải mình đang dùng sai cách?
Lauren: Cá nhân tôi nghĩ cách sử dụng AI tốt nhất là xem nó như một cộng sự cùng làm việc, thay vì chỉ là công cụ thay thế việc viết mã, hoặc giao luôn cho nó phần suy nghĩ.
AI đang rất hấp dẫn, nên mọi người dễ bị cuốn vào áp lực phải tăng năng suất: hoàn thành thật nhiều thay đổi, xây sản phẩm thật nhanh, dù chưa thực sự hiểu điều mình đang làm.
Tôi cũng từng thấy mình tiết kiệm thời gian viết mã nhưng mất thêm thời gian kiểm tra những gì AI tạo ra. Ngay cả khi yêu cầu AI viết bản đặc tả trước, rồi mình duyệt và mới triển khai, vấn đề tin tưởng vẫn còn đó.
Người hỏi: Nghĩa là tạo được nhiều kết quả chưa chắc đã giúp mình làm việc hiệu quả hơn?
Lauren: Đúng. Nếu agent cứ đoán mò, bịa thông tin rồi tự tin tuyên bố đã tìm ra nguyên nhân, bạn sẽ mất niềm tin. Khi không tin nó, bạn phải theo sát từng việc. Và khi phải theo sát như vậy, bạn rất khó tận dụng hết khả năng của agent.
💡 Chú thích — AI Agent là gì?
Trong bài này, agent là hệ thống AI có thể dùng công cụ để thực hiện công việc: đọc dữ liệu, thao tác ứng dụng, chỉnh sửa tệp hoặc chạy chương trình trong phạm vi được giao. Ví dụ, AI chỉ hướng dẫn cách làm báo cáo thì bạn vẫn phải thực hiện; agent có thể lấy dữ liệu, tạo báo cáo và kiểm tra kết quả nếu đã được cấp công cụ và quyền phù hợp.
“Lập trình cùng AI”, hay pair programming, có thể hình dung như làm cùng một đồng nghiệp: bạn giữ mục tiêu và quyền quyết định, còn AI hỗ trợ phân tích, triển khai và kiểm tra.
Người hỏi: Vì sao anh so sánh làm việc với agent với việc quản lý nhân sự?
Lauren: Hãy tưởng tượng bạn là quản lý kỹ thuật nhưng không tin đội ngũ. Bạn sẽ phải kiểm soát từng việc nhỏ, liên tục xem họ làm gì và liệu có đưa lỗi vào sản phẩm hay không.
Với agent cũng vậy. Ban đầu tôi chỉ dùng một hoặc vài agent, xem từng kết quả, đưa yêu cầu liên tục. Tôi không thể chạy 100 agent nếu còn chưa tin kết quả của một agent.
Trong khoảng năm tháng, tôi dần xây được niềm tin đó. Tôi đã đến mức để agent tự hợp nhất các thay đổi vào mã nguồn. Có buổi sáng thức dậy, tôi thấy khoảng 20 PR đã được hợp nhất, rồi xem lại chúng trên nhánh chính.
Người hỏi: Vậy số lượng công việc hoàn thành tăng lên sau khi anh xây được niềm tin?
Lauren: Đúng. Khi mới vào Cursor, tôi còn đang tìm hiểu mã nguồn nên chưa làm được nhiều. Khi tự tin hơn với agent, năng suất tăng lên rất mạnh. Theo số liệu tôi chia sẻ, có tháng tôi hoàn thành khoảng một nghìn PR.
Nhưng hỏi “bao nhiêu mã trong đó thực sự tốt?” là hoàn toàn hợp lý. Muốn đạt được tốc độ đó, phải thiết lập agent tốt.
💡 Chú thích — PR, hợp nhất mã và nhánh main là gì?
PR, viết tắt của pull request, là một đề nghị đưa một nhóm thay đổi vào mã nguồn chung. Có thể hình dung nó như một bộ hồ sơ thay đổi để xem xét: sửa gì, vì sao sửa và kết quả kiểm tra thế nào.
Merge là hợp nhất những thay đổi đó. Main là nhánh mã chính của dự án. Đưa mã vào main không phải lúc nào cũng đồng nghĩa với phát hành ngay cho người dùng; điều đó phụ thuộc quy trình của từng đội.
Trong công việc văn phòng, tình huống gần nhất là chuyển một bản nháp vào tài liệu hoặc dữ liệu chính thức. Khả năng AI tự làm bước này cần được đánh giá theo từng công việc, không thể suy ra chỉ từ tốc độ tạo bản nháp.
Người hỏi: Nếu chỉ chọn một khả năng cần xây trước, anh sẽ chọn gì?
Lauren: Kiểm chứng, hay verification.
Agent cần có khả năng thực sự chạy mã và kiểm tra ứng dụng. Nó có thể mở ứng dụng như người dùng, thực hiện thao tác, lấy dữ liệu hiệu năng hoặc xem trạng thái bộ nhớ. Như vậy, quy trình mới khép kín: làm xong rồi kiểm tra kết quả.
Nếu không có khả năng đó, bạn chính là người kiểm chứng. Agent viết mã, bạn mở ứng dụng, thấy lỗi, sao chép ảnh chụp màn hình hoặc thông báo lỗi cho nó. Nó sửa, rồi bạn lại kiểm tra. Bạn luôn nằm trong vòng lặp và trở thành điểm nghẽn.
Người hỏi: Chỉ cần agent tự kiểm tra là có thể yên tâm hoàn toàn?
Lauren: Không. Kiểm chứng không bảo đảm nó viết mã tốt về mặt thiết kế, nhưng giúp nó ít nhất tạo ra mã hoạt động đúng. Đó là bước rất lớn để bắt đầu tin tưởng.
💡 Chú thích — “Chạy đúng” khác “làm tốt” thế nào?
Một báo cáo có thể mở được, đủ cột và cộng số đúng, nhưng vẫn chọn sai chỉ số để đánh giá kinh doanh. Một email có thể gửi thành công, nhưng nội dung chưa phù hợp với khách hàng.
Kiểm chứng kỹ thuật trả lời những câu như “tệp có được tạo không?”, “tổng có khớp không?”, “nút có hoạt động không?”. Chất lượng công việc còn cần câu hỏi “kết quả này có đúng mục tiêu và hữu ích không?”. Người giao việc cần xác định cả hai.
Ví dụ áp dụng: Với agent làm báo cáo bán hàng, đừng chỉ yêu cầu “tạo báo cáo”. Hãy thêm tiêu chí: lấy đúng kỳ dữ liệu, đối chiếu tổng doanh thu với nguồn, báo rõ dữ liệu thiếu và xác nhận tệp đầu ra mở được. Mỗi tiêu chí cần một cách kiểm tra cụ thể.
Người hỏi: Khi agent đã điều khiển được ứng dụng, vì sao anh còn cần “bản đồ tính năng”?
Lauren: Vì biết điều khiển ứng dụng khác với hiểu ứng dụng.
Tôi từng xây skill giúp agent mở cửa sổ agent của Cursor và thu thập dữ liệu hiệu năng. Nhưng khi ai đó báo “thanh bên trái bị chậm” hoặc “thẻ PR không hoạt động”, nó vẫn loay hoay. Nó không biết tính năng nằm ở đâu và phải mở bằng cách nào.
Bản đồ tính năng giải quyết việc đó. Nó mô tả từng tính năng, cách truy cập, các tính năng con, phím tắt và những thuộc tính giao diện mà agent có thể dùng để tìm đúng thành phần.
Nhờ vậy, một phản hồi mơ hồ, thậm chí chỉ có ảnh chụp màn hình kèm “???”, cũng có thể được liên hệ với đúng khu vực ứng dụng.
💡 Chú thích — Feature map là gì?
Feature map, hay bản đồ tính năng, giống tài liệu hướng dẫn đường đi trong phần mềm dành cho agent. Nó trả lời: tính năng ở đâu, vào bằng cách nào, cần điều kiện gì và dấu hiệu nào cho thấy đã đến đúng chỗ.
Ví dụ với CRM: muốn xem khách hàng chưa được liên hệ, hãy mở mục Khách hàng tiềm năng, chọn trạng thái Mới, lọc nhân viên phụ trách rồi đọc bảng kết quả. Nếu chỉ giao “tìm khách hàng chưa liên hệ” mà không cung cấp đường đi hoặc công cụ truy vấn, agent có thể hiểu mục tiêu nhưng vẫn thao tác sai.
Trong video còn có CDP, một giao thức giúp chương trình điều khiển và kiểm tra trình duyệt, và DOM, cấu trúc các thành phần của trang web. Có thể hình dung: CDP là cách agent thao tác với trình duyệt; DOM giúp nó nhận diện đúng nút, ô nhập hoặc vùng nội dung.
Người hỏi: Bộ skill pstack của anh bắt đầu từ đâu?
Lauren: Tôi không đặt mục tiêu xây một bộ plugin ngay từ đầu. Tôi bắt đầu bằng vài skill rồi bổ sung dần từ những gì quan sát được.
Có lần tôi hỏi tại sao một tính năng không hoạt động. Agent khẳng định chắc chắn nguyên nhân, nhưng khi xem các lần gọi công cụ, tôi phát hiện nó chưa đọc phần mã đáng lẽ phải liên quan.
Rất dễ nghĩ “agent này không đáng tin” rồi cảm thấy bất lực. Nhưng hãy tưởng tượng bạn vừa tuyển một kỹ sư giỏi, chưa biết gì về doanh nghiệp và mới làm quen công việc được vài giây. Bạn cần cung cấp bối cảnh và cách làm việc cho họ.
Với agent, tôi làm điều đó bằng skill. Mỗi khi thấy một kiểu thất bại, tôi biến nó thành hướng dẫn: đừng đoán; hãy tìm kiếm, đọc mã; dùng agent phụ khi phù hợp.
💡 Chú thích — Skill khác một câu yêu cầu thế nào?
Trong bối cảnh này, skill là bộ hướng dẫn có thể dùng lại cho một loại công việc. Nó có thể quy định nguồn cần đọc, các bước cần làm, cách xử lý trường hợp thiếu dữ liệu, tiêu chí kiểm tra và dạng kết quả phải trả về.
Ví dụ, câu yêu cầu là “viết email chăm sóc khách hàng”. Một skill có thể hướng dẫn agent đọc lịch sử trao đổi, xác định giai đoạn mua hàng, không tự tạo ưu đãi, soạn nội dung theo giọng thương hiệu và để người phụ trách duyệt trước khi gửi.
Skill giống quy trình làm việc được viết để AI sử dụng. Nó giúp giảm sự tùy hứng, nhưng bản thân tài liệu hướng dẫn không bảo đảm AI sẽ luôn tuân thủ.
pstack là tên bộ plugin gồm các skill mà diễn giả xây theo cách làm việc của mình. Tên gọi vui này xuất phát từ “potato stack”.
Người hỏi: Sản phẩm thay đổi liên tục. Làm sao duy trì skill và biết hệ thống kiểm chứng đủ đáng tin?
Lauren: Tôi dùng eval. Bạn có thể xem nó như bài kiểm thử dành cho agent. Không nhất thiết cần một bộ khung chuyên dụng; bạn tự xây theo mức độ chặt chẽ mình cần.
Tôi để agent điều phối xây bộ tiêu chí, rồi tạo các agent phụ làm việc trong môi trường riêng. Tôi cũng đánh giá trên nhiều mô hình khác nhau, đặc biệt là những mô hình mình sử dụng.
Mỗi khi sửa skill, tôi chạy đánh giá để xem nó có tạo ra kết quả mong muốn không. Tôi có thể dùng một mô hình khác làm người chấm để đối chiếu và giảm thiên lệch.
Người hỏi: Có thể để hệ thống tự cải tiến qua nhiều vòng?
Lauren: Có. Bạn có thể lặp việc đánh giá và sửa đổi để nâng điểm. Tôi từng dùng cách này để cải tiến skill điều khiển ứng dụng. Nhưng lúc đầu không trơn tru; cần nhiều vòng quan sát và điều chỉnh.
Trong giai đoạn xây skill, đừng chỉ quan sát thụ động. Hãy xem agent gọi công cụ nào, đọc dữ liệu nào và thất bại ở đâu.
💡 Chú thích — Eval và rubric là gì?
Eval là một bài hoặc bộ bài đánh giá agent. Rubric là bộ tiêu chí dùng để chấm. Thay vì hỏi “AI làm tốt không?”, bạn chuyển sang những điều có thể kiểm tra.
Ví dụ với agent phân loại email:
Một lần đạt 10/10 trên bài đánh giá không có nghĩa sẽ đúng với mọi tình huống. Nếu bộ bài chỉ chứa trường hợp dễ hoặc quá giống nhau, điểm cao có thể khiến bạn tự tin quá mức. Khi áp dụng, cần có trường hợp khó, dữ liệu thiếu và tình huống mới để thử lại.
Người hỏi: Tôi nên bắt đầu trên máy mình hay đưa agent lên đám mây luôn?
Lauren: Nên bắt đầu trên máy, vì bạn có thể nhìn thấy nó đang thao tác như thế nào, mở ứng dụng ra sao và gọi những công cụ nào.
Khi đã thiết lập tốt khả năng điều khiển và kiểm chứng, agent trên đám mây có thể mang lại lợi ích cho cả nhóm.
Chúng tôi có Benny, một agent tiếp nhận báo cáo lỗi, mở môi trường làm việc riêng trên đám mây, chạy Cursor và cố tái hiện lỗi.
Trong một trường hợp, nó tái hiện được lỗi nhưng xác nhận vấn đề đã được sửa trên nhánh main. Nhờ vậy, tôi biết chỉ cần phát hành bản mới, thay vì ngồi một tiếng tìm hiểu xem lỗi đã sửa hay chưa.
Nhưng đây là một hành trình. Nếu chưa tin agent, đừng nhảy ngay sang chạy hàng trăm hoặc hàng nghìn agent. Bạn sẽ lãng phí rất nhiều token.
💡 Chú thích — Local, cloud và agent phụ là gì?
Local nghĩa là chạy trên máy của bạn. Cloud nghĩa là chạy trong môi trường máy tính từ xa. Sub-agent, hay agent phụ, là agent được giao một phần việc trong quy trình lớn hơn, chẳng hạn một agent xử lý dữ liệu còn agent khác kiểm tra kết quả.
Token là đơn vị mà mô hình dùng để xử lý nội dung, không tương đương cố định với một từ. Nhiều công cụ tính chi phí hoặc giới hạn sử dụng dựa trên token. Agent càng đọc nhiều, làm nhiều vòng hoặc phối hợp nhiều agent, mức sử dụng có thể càng tăng.
Ví dụ áp dụng: Hãy để một agent làm tốt báo cáo cho một nhóm trước, đo độ chính xác và thời gian bạn phải sửa. Khi quy trình ổn, mới mở rộng cho nhiều nhóm. Nếu quy trình còn lỗi, nhân số agent có thể nhân cả số lỗi.
Người hỏi: Anh nói nhiều về tái cấu trúc mã nguồn và ràng buộc. Điều đó liên quan gì đến niềm tin?
Lauren: Agent thích chọn cách nhanh nhất để giải quyết việc được giao. Nếu không có ràng buộc, nó có thể tạo ra kiến trúc tự phát: mỗi lần sửa lại dùng một cách tiện, rồi mã nguồn dần mất kiểm soát.
Các công ty công nghệ lớn đã gặp vấn đề này từ trước AI. Họ xây bộ khung, quy ước và giới hạn quyền để cả người ít kinh nghiệm cũng không gây hỏng hệ thống.
Agent cũng hưởng lợi từ những cơ chế đó.
Tôi đã đầu tư hơn 600 PR để tái cấu trúc Grokbot sang kiến trúc mới. Đó là lý do tôi có thể giảm việc kiểm tra trực tiếp từng thay đổi.
Người hỏi: Cụ thể, anh thực thi các quy tắc bằng cách nào?
Lauren: Chúng tôi dùng nhiều lớp. Có những quy tắc trong hướng dẫn và skill. Nhưng cũng có quy tắc được hệ thống kiểm tra tự động thực thi: vi phạm thì không được đi tiếp.
Chẳng hạn, trong kiến trúc Dune của Grokbot, chúng tôi cấm useEffect và cấm chú thích trong mã vì những vấn đề quan sát được ở agent.
Chúng tôi còn tách khu vực xử lý chính và khu vực hiển thị giao diện, kiểm tra quan hệ phụ thuộc để mã không bị đưa sang sai chỗ.
Chỉ dựa vào tài liệu quy chuẩn là quá mềm. Agent vẫn có thể quên hoặc áp dụng không nhất quán.
💡 Chú thích — Tái cấu trúc, CI và lint là gì?
Refactor, hay tái cấu trúc, là sửa cách tổ chức mã mà chủ yếu giữ nguyên hành vi hiện có. Khác với làm lại toàn bộ, mục tiêu thường là khiến hệ thống dễ hiểu, dễ sửa và dễ kiểm soát hơn.
CI, viết tắt của tích hợp liên tục, là quy trình tự động chạy các kiểm tra khi mã thay đổi. Trong bài này, hãy hình dung nó như trạm kiểm tra: thay đổi không đạt yêu cầu thì chưa được đi tiếp.
Lint là công cụ phát hiện những mẫu mã vi phạm quy tắc. Với công việc văn phòng, ví dụ gần nhất là biểu mẫu không cho lưu nếu thiếu trường bắt buộc, hoặc hệ thống không cho gửi khi chưa có người duyệt. Chúng không phải CI theo nghĩa kỹ thuật, nhưng cùng minh họa việc quy tắc được thực thi bằng hệ thống.
useEffect là một cơ chế của React để xử lý việc đồng bộ với những thứ bên ngoài thành phần giao diện. Việc cấm nó trong kiến trúc của diễn giả là lựa chọn riêng; không có nghĩa mọi phần mềm dùng useEffect đều sai.
Ví dụ áp dụng: Dặn agent “đừng tự gửi email cho khách” là một hướng dẫn. Thiết lập để agent chỉ có quyền tạo bản nháp và thao tác gửi cần người duyệt là một ràng buộc cụ thể. Nếu đó là điều bắt buộc, nên thể hiện nó trong quyền truy cập hoặc quy trình thực tế.
Người hỏi: Nguyên tắc thiết kế môi trường làm việc cho agent của anh là gì?
Lauren: Đường ngắn nhất phải là đường tốt nhất.
Agent thích sao chép mẫu có sẵn và thích đi đường tắt. Vậy hãy tổ chức công việc để cách nhanh nhất cũng chính là cách phù hợp.
Trong Grokbot, một tính năng có thư mục riêng và các quy ước rõ ràng. Agent không phải đi khắp mã nguồn tìm các phần liên quan. Khoảng 80% công việc được gói trong khu vực tính năng đó.
Khi phát hiện một quy tắc mà người kiểm tra cứ phải nhắc đi nhắc lại, tôi muốn biến nó thành quy tắc tự động kiểm tra, hoặc thay đổi kiến trúc để vấn đề đó không còn xuất hiện.
💡 Chú thích — Vì sao cách tổ chức môi trường lại quan trọng?
Bạn có thể áp dụng nguyên tắc này ngoài lập trình: nguồn dữ liệu chuẩn ở một nơi, mẫu kết quả có sẵn, tên thư mục dễ hiểu và bước kiểm tra được đặt ngay trong quy trình.
Ví dụ, agent viết nội dung sẽ ít phải đoán hơn nếu có thư mục chứa thông tin sản phẩm đã duyệt, giọng thương hiệu, những cam kết được phép dùng và mẫu bài. Nếu dữ liệu cũ mới trộn lẫn, dù lời yêu cầu rất hay, agent vẫn có thể chọn nhầm nguồn.
Trong phần hiệu năng, diễn giả còn nhắc đến renderer, bộ phận hiển thị giao diện, và main, bộ phận xử lý chính của ứng dụng Electron. Tách chúng tốt giúp việc xử lý nặng không làm màn hình giật. Đây là một ví dụ cụ thể cho việc đưa cách làm đúng vào cấu trúc hệ thống.
Người hỏi: Anh có lượng token gần như không giới hạn. Người dùng thông thường có làm theo được không?
Lauren: Tôi không thể nói ai cũng nên làm giống hệt mình. Xây các ràng buộc và tái cấu trúc mã nguồn tốn nhiều token ở giai đoạn đầu.
Nhưng nếu là người điều hành hoặc lãnh đạo kỹ thuật, tôi xem đây là câu hỏi về ROI. Trước khi có agent, một mình tôi có thể mất nhiều năm để xây hệ thống này, kiểm thử và chuyển đổi mã nguồn.
Khoản đầu tư không chỉ giúp tôi. Nó giúp quản lý sản phẩm, nhà thiết kế và kỹ sư chưa quen mã nguồn vẫn đóng góp được. Khi môi trường được thiết kế tốt, bạn cũng không nhất thiết luôn cần mô hình lớn nhất.
Người hỏi: Người không chuyên kỹ thuật cũng có thể trực tiếp triển khai tính năng?
Lauren: Chúng tôi đã thấy điều đó. Quản lý sản phẩm có thể báo rằng họ đã sửa một lỗi và nhờ tôi xem lại. Khi kiểm tra, kết quả tốt và tôi duyệt.
Giao diện quen thuộc giúp họ tiếp cận agent dễ hơn. Còn các ràng buộc chặt trong kiến trúc giúp những đóng góp ấy đứng vững. Đó là điều khiến tôi hào hứng.
💡 Chú thích — ROI nên tính thế nào với người đi làm?
ROI là hiệu quả thu được so với khoản đầu tư. Với agent, đừng chỉ đếm số tệp, số bài viết hoặc số tác vụ hoàn thành. Hãy tính cả phí công cụ, thời gian thiết lập, thời gian kiểm tra và sửa, rồi đối chiếu với giá trị công việc thực sự tạo ra.
Một agent tạo 100 bài nhưng cần sửa gần hết chưa chắc hiệu quả hơn một agent tạo 10 bài dùng được. Tương tự, số PR cao là thông tin về tốc độ thay đổi mã, không tự nó chứng minh giá trị kinh doanh hay chất lượng sản phẩm.
Nếu đang muốn giao thêm việc cho AI, bạn có thể bắt đầu với một công việc lặp lại và làm rõ bốn điều:
Một góc nhìn đáng giữ lại: tin tưởng agent là kết quả của việc quan sát, kiểm chứng và thiết kế môi trường làm việc.
Nhưng cũng cần tự hỏi ngược lại: hệ thống kiểm tra có đang kiểm tra đúng thứ quan trọng không? Nếu tiêu chí sai, agent có thể tuân thủ rất tốt mà vẫn tạo ra kết quả không hữu ích.
Vai trò của người giao việc vì thế vẫn rất rõ: chọn đúng mục tiêu, đặt tiêu chuẩn và quyết định mức tự chủ phù hợp. Như hình ảnh Lauren dùng trong cuộc trò chuyện, bạn dần trở thành bếp trưởng: thiết kế căn bếp, giao việc và giữ chất lượng của món ăn được đưa ra.
Học cách ứng dụng AI Agent vào công việc qua 4 buổi online với 15 tình huống thực tế.
