Tôi vẫn còn nhớ những ngày đầu tiên tập tành làm website.
Khi ấy, chưa có ChatGPT hay những công cụ AI có thể viết code theo yêu cầu như bây giờ. Mỗi khi muốn thay đổi một chi tiết trên website, tôi thường lên Google tìm kiếm, đọc những bài blog hướng dẫn rồi thử làm theo.
Có khi chỉ là một đoạn CSS để thay đổi cách hiển thị tiêu đề H2, thêm một đường kẻ trang trí, chỉnh khoảng cách giữa các đoạn văn, hoặc làm cho thẻ trích dẫn (blockquote) trông đẹp hơn một chút.
Tôi sẽ tìm được một đoạn code ở đâu đó trên mạng, sao chép nó vào phần Custom CSS, lưu lại rồi tải lại trang để xem điều gì xảy ra.
Nếu kết quả không giống hình minh họa, tôi lại tiếp tục tìm hiểu xem mình đã làm sai ở đâu. Đôi khi chỉ thiếu một dấu ngoặc, sai tên class hoặc có một thuộc tính CSS bị theme ghi đè.
Nhưng tôi thực sự thấy rất hào hứng với những việc ấy.
Cảm giác tự tay thay đổi được một chi tiết nhỏ trên website của mình, dù chỉ là màu sắc hay kiểu hiển thị của một tiêu đề, cũng đủ khiến tôi ngồi mày mò hàng giờ.
Tôi nghĩ những ai từng bắt đầu làm website bằng WordPress, Blogger hoặc tự chỉnh sửa HTML và CSS chắc sẽ hiểu cảm giác này.
Có một điều khá buồn cười là khi ấy, chỉ cần tìm được một đoạn CSS đẹp trên một blog nước ngoài và áp dụng thành công vào website của mình, tôi đã cảm thấy như vừa học được một kỹ năng rất ghê gớm.
Vậy mà chỉ khoảng ba năm sau, tôi đã có thể tạo ra cả một website hoàn chỉnh chỉ bằng một câu prompt.
Không còn phải tìm từng đoạn CSS, tự sửa từng thành phần giao diện hay dành hàng giờ để tìm hiểu vì sao một thứ gì đó không hoạt động như mong muốn.
Bạn có thể mô tả website mình muốn, giao nhiệm vụ cho AI, để nó tự viết code, chạy thử, phát hiện lỗi và tiếp tục chỉnh sửa.
Tất nhiên, một câu prompt không phải lúc nào cũng tạo ra ngay một sản phẩm hoàn hảo. Vẫn có những thứ cần kiểm tra và thay đổi. Nhưng khoảng cách giữa việc có một ý tưởng và nhìn thấy nó trở thành một website thực sự đã ngắn đi đến mức mà vài năm trước tôi khó có thể tưởng tượng.
Và đó thậm chí chưa phải lần đầu tiên AI khiến tôi bất ngờ.
Vào thời điểm mới bắt đầu sử dụng ChatGPT 3.5, khi ấy, một trong những việc tôi thường nhờ AI làm là viết Google Apps Script để dán vào Google Sheets, nhằm tạo thêm một vài hàm tùy chỉnh hoặc tự động hóa những thao tác mà các công thức có sẵn chưa đáp ứng được.
Tôi chỉ cần mô tả mình muốn bảng tính xử lý dữ liệu như thế nào, ChatGPT sẽ viết cho tôi một đoạn JavaScript. Sau đó, tôi mở Apps Script, dán code vào, chạy thử và quay lại nhờ nó sửa nếu có lỗi.
Chỉ riêng việc đó đã khiến tôi cảm thấy AI thật sự rất khủng khiếp.
Một người không biết nhiều về JavaScript vẫn có thể tạo ra những hàm xử lý dữ liệu theo đúng nhu cầu của mình, chỉ bằng cách mô tả chúng bằng ngôn ngữ tự nhiên.
Nhưng dù đã rất ấn tượng với ChatGPT 3.5, tôi cũng chưa từng hình dung rằng chỉ vài năm sau, AI sẽ có thể làm được những việc như hiện nay.
Ban đầu, chúng ta thấy AI viết nội dung, dịch thuật, tóm tắt tài liệu. Những công việc trước đây cần đến người viết content, biên tập viên hoặc người dịch bắt đầu có thể được tự động hóa một phần đáng kể.
Rồi đến lập trình.
Từ chỗ chỉ viết những đoạn code nhỏ để con người sao chép và chạy thử, AI dần có thể đọc cả codebase, xây dựng tính năng, tự chạy kiểm thử, sửa lỗi và triển khai ứng dụng.
Sau đó là hình ảnh.
Những bức ảnh quảng cáo, hình minh họa hay hình ảnh sản phẩm vốn cần máy ảnh, ánh sáng, người mẫu, bối cảnh và công việc hậu kỳ giờ có thể được tạo ra từ một đoạn mô tả.
Và rồi đến video.
Không chỉ là những đoạn clip ngắn mang tính thử nghiệm, AI ngày càng có khả năng tạo ra những cảnh quay, chuyển động, âm thanh và sản phẩm nghe nhìn phức tạp hơn.
Tất nhiên, nói AI có thể thực hiện một phần công việc của người viết nội dung, lập trình viên, nhiếp ảnh gia hay người làm video không có nghĩa là những nghề ấy đã biến mất, hoặc AI luôn tạo ra kết quả tốt hơn con người.
Nhưng điều khiến tôi kinh ngạc là tốc độ thay đổi.
Có những việc mà chỉ một hoặc hai năm trước chúng ta vẫn xem là giới hạn của AI, giờ đã trở thành những khả năng khá bình thường.
Và mỗi khi nghĩ rằng mình đã bắt đầu quen với những gì AI có thể làm, lại có một công cụ hoặc một cách sử dụng mới khiến tôi phải xem xét lại điều đó.
Tôi cũng nhận ra cách mình làm việc với AI đã thay đổi rất nhiều.
Thời ChatGPT 3.5, tôi thường yêu cầu AI viết một đoạn code, sao chép nó vào nơi cần sử dụng, chạy thử rồi mang thông báo lỗi quay lại cuộc trò chuyện.
Khi đó, tôi là người thực hiện phần lớn các thao tác, còn AI đóng vai trò như một người hướng dẫn hoặc một người viết code hộ.
Nhưng với những AI Agents hiện nay, tôi không nhất thiết phải làm như vậy nữa.
AI có thể tự mở file, đọc tài liệu, sử dụng terminal, chạy chương trình, kiểm tra kết quả và thử những phương án khác khi gặp vấn đề.
Thay vì phải hỏi từng bước, tôi có thể giao cho nó một nhiệm vụ lớn hơn và yêu cầu nó chứng minh rằng công việc đã hoàn thành.
Điều này khiến tôi nghĩ rằng thay đổi quan trọng nhất của AI có lẽ không còn nằm ở việc nó trả lời thông minh hơn hay viết code nhanh hơn.
Mà là chúng ta đang chuyển từ việc dùng AI để hỗ trợ từng thao tác, sang việc giao cho AI thực hiện cả một quy trình công việc.
Và khi điều đó xảy ra, cách sử dụng AI hiệu quả cũng phải thay đổi theo.
Gần đây, tôi đọc một bài đăng trên X của Thorsten Ball, có tiêu đề How I work with Agents, chia sẻ 15 nguyên tắc anh đang áp dụng khi làm việc với AI Agents tính đến tháng 10/2026.
Điều thú vị là Thorsten không tập trung vào những mẹo viết prompt hay cách khiến AI tạo ra code đẹp hơn.
Anh nói về việc sử dụng mô hình mạnh nhất, giao mục tiêu thay vì chỉ dẫn từng bước, để Agent tự xây dựng công cụ kiểm thử, yêu cầu bằng chứng thay vì tin vào lời khẳng định, và thậm chí không còn đọc phần lớn code mà AI viết ra.
Có những quan điểm nghe khá cực đoan nếu nhìn từ cách phát triển phần mềm truyền thống.
Nhưng khi đặt chúng cạnh những gì đã thay đổi chỉ trong vài năm qua, tôi nghĩ chúng rất đáng để suy ngẫm.
Bởi nếu một ngày nào đó AI có thể tự thực hiện phần lớn những thao tác mà trước đây chúng ta phải học rất lâu mới làm được, thì có lẽ câu hỏi quan trọng không còn là làm thế nào để sử dụng AI như một công cụ lập trình.
Mà là:
Chúng ta nên tổ chức công việc như thế nào khi AI đã có thể tự sử dụng những công cụ ấy?
Dưới đây là 15 nguyên tắc của Thorsten Ball, cùng những suy nghĩ của tôi về cách chúng có thể thay đổi việc phát triển phần mềm và sử dụng AI trong công việc.
1. Hãy sử dụng những mô hình tốt nhất mà bạn có thể tiếp cận
Thorsten mở đầu bằng một quan điểm khá dứt khoát: Hãy sử dụng những mô hình mới nhất và mạnh nhất.
Bởi sử dụng một mô hình yếu hơn để tiết kiệm chi phí đôi khi lại khiến chúng ta tốn nhiều thời gian và tiền bạc hơn.
Giả sử một mô hình đưa ra kết quả sai trong 10% trường hợp.
Vấn đề không chỉ nằm ở tỷ lệ sai 10% ấy, mà là chúng ta không biết trước nó sẽ sai ở trường hợp nào.
Vì vậy, chúng ta phải kiểm tra nhiều hơn, thử lại nhiều lần hơn, hoặc mất thêm thời gian sửa những lỗi đáng lẽ có thể tránh được.
Thorsten đưa ra một so sánh khá thú vị: Bạn có thực sự muốn tuyển một nhân viên đa năng có chi phí thấp hơn 50%, nhưng lại kém thông minh hơn 20% theo những cách không thể dự đoán trước không?
Tôi nghĩ điều này đặc biệt đúng khi sử dụng AI Agents cho những công việc dài.
Nếu chỉ yêu cầu AI dịch một đoạn văn hoặc giải thích một khái niệm, sự khác biệt giữa các mô hình đôi khi không quá lớn.
Nhưng nếu giao cho nó một nhiệm vụ kéo dài hàng giờ, phải đọc code, sử dụng công cụ, đưa ra quyết định, kiểm thử rồi sửa lỗi, một sai sót ở giai đoạn đầu có thể ảnh hưởng đến toàn bộ quá trình phía sau.
Tất nhiên, mô hình mạnh nhất không phải lúc nào cũng là lựa chọn kinh tế nhất. Với những nhiệm vụ đơn giản, lặp lại và dễ kiểm chứng, mô hình nhỏ hơn vẫn có thể phù hợp.
Nhưng tôi hiểu ý Thorsten ở đây: Đừng chỉ nhìn vào chi phí của mỗi lần gọi mô hình. Hãy nhìn vào tổng chi phí để hoàn thành công việc.
Một mô hình rẻ hơn nhưng khiến chúng ta phải làm lại ba lần chưa chắc đã thực sự rẻ.
2. Đừng quá ám ảnh với việc AI tạo ra code rác
Một trong những lời chỉ trích phổ biến đối với AI coding là nó sẽ khiến codebase trở thành một mớ hỗn độn không thể bảo trì.
AI có thể viết những đoạn code trùng lặp, lựa chọn kiến trúc thiếu hợp lý hoặc thêm những giải pháp phức tạp không cần thiết.
Và nếu tiếp tục để AI viết code mà không kiểm soát, dự án có thể ngày càng khó hiểu.
Thorsten không phủ nhận rằng điều này từng là một vấn đề.
Nhưng anh đặt câu hỏi liệu những lo ngại từ sáu tháng trước còn đúng với năng lực của các mô hình hiện tại hay không.
Ngay cả khi AI tạo ra một lượng code chưa tối ưu, liệu điều đó có thực sự khiến hệ thống không thể bảo trì?
Tôi nghĩ đây là một điểm khá đáng tranh luận.
Trong lập trình truyền thống, chúng ta thường xem khả năng đọc hiểu và bảo trì code là một trong những tiêu chí quan trọng nhất.
Điều đó hoàn toàn hợp lý, bởi con người phải trực tiếp đọc, hiểu và chỉnh sửa code.
Nhưng nếu AI ngày càng có khả năng tìm hiểu một codebase lớn, xác định những phần liên quan và thực hiện thay đổi chính xác, chi phí bảo trì có thể thay đổi.
Một đoạn code mà con người thấy hơi dài dòng chưa chắc đã trở thành trở ngại lớn đối với một Agent có thể tìm kiếm, phân tích và kiểm thử toàn bộ hệ thống.
Tất nhiên, điều này không có nghĩa là chúng ta nên chấp nhận mọi loại code kém chất lượng.
Những vấn đề như bảo mật, tính đúng đắn của dữ liệu, độ ổn định và khả năng kiểm soát hệ thống vẫn rất quan trọng.
Nhưng có lẽ chúng ta cần phân biệt rõ hơn giữa code không đẹp và code thực sự gây ra rủi ro.
Đôi khi, việc dành quá nhiều thời gian tranh luận về tên biến, cách tổ chức class hay một chút trùng lặp có thể khiến chúng ta bỏ qua câu hỏi quan trọng hơn: Sản phẩm có hoạt động đúng và có thể tiếp tục phát triển hay không?
3. Hãy mô tả điều bạn muốn, thay vì chỉ cách thực hiện
Đây có lẽ là một trong những nguyên tắc tôi thích nhất.
Thorsten gọi nó là Prompt the What, not the How.
Nghĩa là hãy mô tả kết quả bạn muốn đạt được, thay vì hướng dẫn AI từng bước phải thực hiện như thế nào.
Ví dụ, thay vì yêu cầu AI tối ưu một hàm cụ thể bằng một thuật toán do mình lựa chọn, anh có thể giao nhiệm vụ:
Hãy khiến trình biên dịch bytecode và máy ảo chạy nhanh nhất có thể. Đừng dừng lại cho đến khi hiệu suất tăng gấp đôi.
Hoặc đơn giản là mô tả hệ thống cuối cùng cần hoạt động như thế nào.
Tại sao cách này có thể tốt hơn?
Bởi khi chúng ta hướng dẫn AI quá chi tiết về cách thực hiện, vô tình chúng ta đang giới hạn không gian giải pháp của nó trong những gì bản thân đã biết.
Nếu tôi yêu cầu AI sửa một vấn đề bằng phương án A, nó có thể sẽ tập trung thực hiện phương án A.
Nhưng nếu tôi mô tả vấn đề và kết quả mong muốn, nó có thể phát hiện phương án B hoặc C tốt hơn.
Đây cũng là điều tôi thấy khá rõ khi tự học lập trình bằng AI.
Có những lúc tôi không biết tên thuật toán, thư viện hay phương pháp kỹ thuật phù hợp. Nếu phải mô tả chính xác cách thực hiện, có lẽ tôi đã không thể bắt đầu.
Nhưng tôi vẫn có thể mô tả sản phẩm mình muốn xây dựng, những điều kiện nó phải đáp ứng và cách kiểm tra xem nó có hoạt động đúng hay không.
Tất nhiên, không phải lúc nào cũng nên bỏ qua phần How.
Nếu có những ràng buộc quan trọng về bảo mật, kiến trúc, công nghệ hoặc chi phí, chúng ta vẫn phải nói rõ.
Nhưng tôi nghĩ nguyên tắc này có giá trị ở chỗ: Đừng biến hiểu biết hiện tại của mình thành giới hạn tối đa của giải pháp.
4. Hãy để Agent nhìn thấy toàn bộ vòng đời phát triển phần mềm
Thorsten đặt ra một câu hỏi khá thú vị: Điều gì đã giúp giảm bớt hiện tượng AI bịa ra những thứ không có thật?
Câu trả lời của anh là tool calls, tức khả năng sử dụng công cụ.
Trước đây, mô hình ngôn ngữ chủ yếu hoạt động dựa trên những gì có trong ngữ cảnh và kiến thức đã học.
Nếu không biết trạng thái thực tế của một hệ thống, nó có thể suy đoán.
Và đôi khi, suy đoán ấy hoàn toàn sai.
Nhưng khi AI có thể sử dụng công cụ, nó bắt đầu có khả năng tương tác trực tiếp với thế giới mà chúng ta đang làm việc.
Nó có thể đọc file, chạy chương trình, truy vấn dữ liệu, kiểm tra log, gọi API và quan sát kết quả.
Thorsten cho rằng nếu một Agent không thể nhìn thấy điều gì đó, nó có xu hướng phải tự suy đoán về điều ấy.
Vì vậy, hãy khiến toàn bộ vòng đời phát triển phần mềm (Software Development Life Cycle — SDLC) trở nên có thể quan sát được đối với Agent.
Đừng chỉ cho nó quyền viết code.
Hãy cho nó khả năng chạy sản phẩm từ đầu đến cuối, đọc log production, triển khai phiên bản mới, theo dõi quá trình rollout, phát hành bản cập nhật, bật hoặc tắt feature flag, xử lý báo cáo lỗi và thậm chí liên hệ với khách hàng khi phù hợp.
Ý tưởng ở đây khá đơn giản:
Những gì con người cần nhìn thấy để hoàn thành công việc, Agent cũng nên có khả năng nhìn thấy.
Tôi nghĩ đây là một trong những thay đổi quan trọng nhất khi chuyển từ AI chatbot sang AI Agent.
Một chatbot có thể giải thích cách sửa lỗi.
Một Agent có đủ công cụ có thể tái hiện lỗi, xác định nguyên nhân, sửa code, chạy kiểm thử rồi kiểm tra kết quả thực tế.
Tuy nhiên, khả năng quan sát và quyền hành động là hai vấn đề khác nhau.
Tôi nghĩ việc cho Agent đọc log, chạy kiểm thử hoặc xem trạng thái hệ thống thường dễ chấp nhận hơn việc cho nó tự triển khai production, thay đổi dữ liệu hay gửi email cho khách hàng.
Với những hành động có rủi ro cao, vẫn cần cơ chế phân quyền, phê duyệt và khả năng khôi phục.
Nhưng nguyên tắc chung của Thorsten vẫn rất đáng chú ý: Đừng bắt AI làm việc trong bóng tối rồi trách nó vì không hiểu thực tế.
5. Xây dựng công cụ riêng cho những quy trình mà Agent cần thực hiện
Tiếp nối ý trên, Thorsten cho biết nhóm của anh đã xây dựng các plugin tùy chỉnh cho những công việc như xử lý báo cáo lỗi, gửi email cho người dùng, kiểm tra sức khỏe hệ thống và cấp quyền sử dụng tính năng thông qua feature flags.
Điều này khiến tôi nghĩ đến một điểm mà nhiều người thường bỏ qua khi nói về AI Agents.
Chúng ta hay tập trung vào khả năng của mô hình, nhưng đôi khi giới hạn thực sự nằm ở môi trường làm việc xung quanh nó.
Một Agent rất thông minh nhưng không thể truy cập hệ thống báo lỗi, không thể kiểm tra trạng thái production và không thể chạy kiểm thử thì vẫn bị giới hạn đáng kể.
Ngược lại, khi có những công cụ được thiết kế phù hợp, Agent có thể thực hiện những quy trình dài mà không cần con người liên tục sao chép thông tin từ hệ thống này sang hệ thống khác.
Ví dụ, nếu muốn Agent xử lý lỗi từ khách hàng, thay vì mỗi lần phải dán nội dung báo lỗi vào cuộc trò chuyện, chúng ta có thể xây dựng một công cụ để nó tự lấy thông tin cần thiết.
Nếu muốn nó kiểm tra hệ thống có đang hoạt động ổn định không, hãy cung cấp một công cụ tổng hợp các chỉ số sức khỏe quan trọng.
Điểm quan trọng không nhất thiết là xây dựng thật nhiều công cụ.
Mà là xác định những điểm trong quy trình mà AI vẫn đang phải chờ con người làm trung gian, rồi tìm cách giảm bớt sự phụ thuộc ấy.
6. Đừng chỉ tích lũy kiến thức cho Agent, hãy kiểm chứng xem nó có thực sự sử dụng kiến thức đó không
Khi làm việc với AI coding, chúng ta thường tạo ra rất nhiều tài liệu hướng dẫn.
Có thể là file AGENTS.md, các skill, script, tài liệu kiến trúc, quy ước lập trình hoặc hướng dẫn kiểm thử.
Theo thời gian, những tài liệu này trở thành một kho kiến thức về dự án.
Nhưng Thorsten đặt ra một câu hỏi khá quan trọng:
Liệu Agent có thực sự sử dụng chúng không?
Chúng ta có thể dành hàng giờ viết một file hướng dẫn rất chi tiết, nhưng không có gì bảo đảm rằng nó thực sự cải thiện kết quả.
Có thể Agent đã biết những điều đó.
Có thể hướng dẫn quá dài khiến nó bỏ qua những phần quan trọng.
Hoặc có thể một số quy tắc còn khiến Agent thực hiện công việc kém hiệu quả hơn.
Thorsten đề xuất sử dụng thực nghiệm.
Hãy tạo năm Agent không biết trước mục tiêu của cuộc kiểm tra, chia thành nhóm đối chứng và nhóm được cung cấp hướng dẫn, sau đó so sánh kết quả.
Đây là cách tiếp cận khá giống một thí nghiệm A/B.
Thay vì tin rằng một file hướng dẫn có ích chỉ vì chúng ta đã viết nó rất cẩn thận, hãy đo lường xem nó có thực sự tạo ra khác biệt hay không.
Tôi nghĩ nguyên tắc này có thể áp dụng rộng hơn nhiều so với lập trình.
Nếu chúng ta xây dựng một bộ prompt cho AI viết nội dung, hãy thử so sánh chất lượng với và không có bộ prompt đó.
Nếu tạo một skill để AI phân tích dữ liệu, hãy kiểm tra xem nó có giúp giảm lỗi hoặc cải thiện kết quả hay không.
Và nếu một hướng dẫn không tạo ra khác biệt đáng kể, có lẽ không cần giữ nó chỉ vì chúng ta đã mất công viết.
Một hướng dẫn tốt không phải là hướng dẫn nghe có vẻ hợp lý, mà là hướng dẫn thực sự cải thiện kết quả.
7. Môi trường phát triển trên máy cá nhân đang trở nên bất tiện
Thorsten có một nhận xét khá hài hước: Làm việc với môi trường phát triển cục bộ (local development) giờ khiến anh cảm thấy khó chịu.
Lý do là mỗi Agent nên có khả năng tự cài đặt và chạy những thứ nó cần để hoàn thành công việc.
Điều này tương đối dễ nếu mỗi Agent có một máy tính hoặc môi trường độc lập trên đám mây.
Nhưng nếu tất cả cùng làm việc trên một máy tính cá nhân, xung đột tài nguyên sẽ nhanh chóng xuất hiện.
Agent này muốn chạy một database.
Agent kia cần sử dụng cùng một cổng mạng.
Một Agent khác đang chạy bộ kiểm thử tiêu tốn nhiều CPU hoặc bộ nhớ.
Nếu nhiều Agent cùng sửa file, cài dependency hoặc thay đổi cấu hình môi trường, mọi thứ có thể trở nên rất khó quản lý.
Đây là một vấn đề khá thú vị vì nó cho thấy mô hình làm việc nhiều Agent không chỉ đòi hỏi thay đổi phần mềm, mà còn thay đổi cả cách chúng ta tổ chức hạ tầng phát triển.
Trước đây, môi trường local thường được thiết kế cho một lập trình viên trực tiếp làm việc với một hoặc vài dự án.
Nhưng nếu chúng ta muốn hàng chục Agent cùng hoạt động, mỗi Agent có nhiệm vụ và bộ công cụ riêng, môi trường đó có thể không còn phù hợp.
Tôi nghĩ đây là lý do các môi trường làm việc độc lập, container và máy tính đám mây sẽ ngày càng có vai trò lớn hơn trong những quy trình phát triển phần mềm bằng AI.
8. Đừng liên tục thử từng phương án với Agent, hãy để nó xây dựng công cụ giúp bạn thử nhiều phương án
Đây là một trong những ý tôi thấy thực dụng nhất.
Khi làm việc với AI, chúng ta rất dễ rơi vào một vòng lặp quen thuộc.
“Hãy thử cách này.”
AI làm xong.
“Không ổn, thử cách khác.”
AI tiếp tục sửa.
“Vẫn chưa đúng, thay đổi thêm một chút.”
Cứ như vậy, chúng ta trở thành người điều khiển từng bước của một quá trình thử nghiệm.
Thorsten đề xuất một cách khác.
Thay vì yêu cầu Agent thử từng phương án, hãy yêu cầu nó xây dựng công cụ để chúng ta có thể thử nhiều phương án cùng lúc.
Ví dụ:
Hãy tạo 20 biến thể khác nhau và xây dựng một trang nhỏ cho phép tôi kết hợp, so sánh và thử nghiệm chúng.
Lúc này, thay vì phải chờ AI tạo từng phiên bản, chúng ta có một môi trường để tự khám phá không gian giải pháp.
Điều này không chỉ áp dụng cho thiết kế giao diện.
Nó còn có thể áp dụng cho việc tìm hiểu chính vấn đề cần giải quyết.
Ví dụ:
Hãy đưa ra bốn giả thuyết về nguyên nhân khiến hệ thống chạy chậm, sau đó thiết kế và thực hiện các phép kiểm tra để đánh giá cả bốn giả thuyết.
Tôi thích cách làm này vì nó thay đổi vai trò của Agent.
Nó không còn chỉ là một người thực hiện những yêu cầu nối tiếp nhau.
Nó trở thành người xây dựng một hệ thống thử nghiệm để chúng ta có thể đưa ra quyết định tốt hơn.
Và đôi khi, việc tạo ra công cụ giúp khám phá vấn đề còn có giá trị hơn việc đưa ra ngay một lời giải.
9. Hãy yêu cầu bằng chứng không thể dễ dàng bác bỏ
Thorsten gọi đây là thay đổi lớn nhất trong cách anh làm việc với Agents.
Đừng chỉ yêu cầu AI hoàn thành nhiệm vụ.
Hãy yêu cầu nó chứng minh rằng nhiệm vụ đã được hoàn thành.
Bằng chứng có thể là một quy trình kiểm thử từ đầu đến cuối, video demo, số liệu trước và sau khi tối ưu, hoặc kết quả chạy thực tế của hệ thống.
Tôi nghĩ đây là một trong những bài học quan trọng nhất khi sử dụng AI cho công việc kỹ thuật.
Bởi AI có thể rất giỏi giải thích tại sao một giải pháp sẽ hoạt động.
Nhưng một lời giải thích thuyết phục không đồng nghĩa với việc giải pháp ấy thực sự hoạt động.
Nếu yêu cầu Agent sửa một lỗi, câu trả lời “Tôi đã sửa xong” không phải là bằng chứng.
Nếu yêu cầu tăng hiệu suất, việc nó nói “Tôi đã tối ưu thuật toán” cũng chưa chứng minh được điều gì.
Chúng ta cần những thứ có thể kiểm tra độc lập.
Ví dụ, với một lỗi phần mềm, Agent có thể cung cấp bộ kiểm thử tái hiện lỗi trước khi sửa và cho thấy bộ kiểm thử ấy chạy thành công sau khi sửa.
Với một nhiệm vụ tối ưu hiệu suất, nó có thể cung cấp kết quả benchmark trước và sau trong cùng điều kiện.
Với một giao diện, nó có thể cung cấp video thao tác thực tế thay vì chỉ ảnh chụp màn hình tĩnh.
Thorsten thậm chí gợi ý thêm một quy tắc vào AGENTS.md:
“This is not evidence.”
Tức là buộc Agent phải phân biệt giữa lời khẳng định và bằng chứng thực sự.
Tất nhiên, không phải bằng chứng nào cũng tuyệt đối không thể bác bỏ. Một bộ kiểm thử có thể thiếu trường hợp quan trọng, và số liệu benchmark có thể bị ảnh hưởng bởi điều kiện đo.
Nhưng việc yêu cầu bằng chứng khiến cuộc trò chuyện chuyển từ “AI nói rằng nó đã làm xong” sang “Chúng ta có thể quan sát và kiểm tra kết quả”.
Đối với tôi, đây là một thay đổi rất lớn.
10. Đừng ngồi chờ Agents, hãy để Agents chờ bạn
Trong những cuộc trò chuyện với AI, chúng ta thường quan tâm đến tốc độ phản hồi.
Một mô hình mất vài giây để bắt đầu trả lời có thể khiến người dùng cảm thấy chậm.
Nhưng Thorsten cho rằng nếu chúng ta vẫn quá lo lắng về Time To First Token — thời gian chờ token đầu tiên — có lẽ chúng ta đang sử dụng Agents chưa đúng cách.
Bởi Agent không nhất thiết phải là một hệ thống phản hồi tức thì.
Nó có thể là một hệ thống nhận nhiệm vụ, làm việc trong thời gian dài rồi quay lại với kết quả.
Thay vì giao những việc nhỏ và liên tục chờ phản hồi, hãy giao những nhiệm vụ lớn hơn.
Thay vì trao đổi qua lại từng bước, hãy gom nhiều yêu cầu thành một công việc có mục tiêu rõ ràng.
Và thay vì ngồi nhìn Agent làm việc, hãy để nó tiếp tục thực hiện trong khi chúng ta làm việc khác.
Tôi nghĩ điều này phản ánh một sự thay đổi trong cách sử dụng thời gian.
Khi làm việc với chatbot, chúng ta thường ở trong một vòng lặp đồng bộ: hỏi, chờ, đọc, hỏi tiếp.
Nhưng khi làm việc với Agent, chúng ta có thể chuyển sang cách làm bất đồng bộ.
Giao nhiệm vụ, đặt tiêu chí hoàn thành, rồi quay lại khi có kết quả hoặc khi cần đưa ra quyết định.
Điều quan trọng không còn chỉ là Agent trả lời nhanh bao nhiêu, mà là nó có thể hoàn thành bao nhiêu công việc hữu ích mà không cần chúng ta liên tục can thiệp.
11. Tự động hóa và lịch chạy định kỳ là những tính năng cực kỳ quan trọng
Thorsten kể rằng anh không nhận ra mình phụ thuộc vào các tính năng tự động hóa, lịch chạy và cơ chế đánh thức Agent nhiều đến mức nào, cho đến khi chúng tạm thời không còn hoạt động.
Anh sử dụng chúng thường xuyên cho những yêu cầu như:
- “Hai giờ nữa hãy kiểm tra log.”
- “Thông báo cho tôi khi phiên bản này được triển khai thành công.”
- “Kiểm tra hệ thống mỗi ngày lúc 9 giờ sáng.”
Những yêu cầu này nghe có vẻ đơn giản.
Nhưng chúng thay đổi bản chất của mối quan hệ giữa con người và Agent.
Thay vì phải nhớ quay lại kiểm tra một vấn đề, chúng ta có thể giao trách nhiệm theo dõi cho hệ thống.
Ví dụ, sau khi triển khai một tính năng mới, thay vì liên tục mở dashboard để xem có lỗi hay không, chúng ta có thể yêu cầu Agent theo dõi các chỉ số quan trọng trong vài giờ.
Nếu phát hiện bất thường, nó có thể thông báo hoặc thực hiện những hành động đã được cho phép.
Tôi nghĩ đây là bước chuyển từ AI phản ứng theo yêu cầu sang AI có thể duy trì công việc theo thời gian.
Một Agent thực sự hữu ích không chỉ biết làm việc khi chúng ta đang trò chuyện với nó.
Nó còn cần biết khi nào nên tiếp tục công việc, khi nào nên kiểm tra lại kết quả và khi nào cần gọi con người quay lại.
12. Đừng quản lý context bằng tay nữa
Khi sử dụng các mô hình ngôn ngữ, nhiều người thường lo lắng về context window.
Cuộc trò chuyện đã dài bao nhiêu?
Đang sử dụng 300.000 hay 380.000 token?
Có nên tạo cuộc trò chuyện mới để tránh mô hình quên thông tin không?
Có nên tự tóm tắt nội dung cũ rồi chuyển sang một thread khác không?
Thorsten cho rằng phần lớn thời gian dành cho những suy nghĩ ấy là lãng phí.
Theo kinh nghiệm của anh, cơ chế nén ngữ cảnh (compaction) hiện đã hoạt động rất tốt.
Thay vì liên tục quản lý context thủ công, anh sử dụng một nguyên tắc đơn giản:
Một thread cho một nhiệm vụ.
Có những thread chỉ dài 46 tin nhắn.
Có những thread dài đến 3.714 tin nhắn.
Điều quyết định khi nào nên kết thúc thread không phải là số lượng token, mà là công việc đã hoàn thành hay chưa.
Tôi nghĩ đây là một quan điểm đáng chú ý, dù hiệu quả thực tế vẫn phụ thuộc vào hệ thống và mô hình được sử dụng.
Không phải mọi công cụ AI đều có khả năng quản lý ngữ cảnh tốt như nhau. Và với những nhiệm vụ có yêu cầu chính xác cao, việc kiểm tra lại những quyết định quan trọng vẫn cần thiết.
Nhưng nguyên tắc chung khá hợp lý.
Chúng ta không nên dành quá nhiều năng lượng để quản lý những chi tiết kỹ thuật mà công cụ có thể tự xử lý.
Thay vào đó, hãy tập trung vào việc mô tả nhiệm vụ rõ ràng, cung cấp dữ liệu cần thiết và xác định tiêu chí hoàn thành.
13. Các thread có thể trở thành bộ nhớ của cả công ty
Trong công cụ Amp mà Thorsten sử dụng, các thread không chỉ là lịch sử trò chuyện.
Chúng còn có thể trở thành một phần trong bộ nhớ tổ chức.
Giả sử vài tháng sau, một thành viên trong nhóm hỏi:
“Tại sao chúng ta lại thiết kế hệ thống theo cách này?”
Nếu quyết định trước đó được thực hiện thông qua một thread Agent và thread ấy được liên kết với commit Git tương ứng, nhóm có thể truy lại quá trình thảo luận và lý do dẫn đến quyết định.
Điều này khác với cách lưu trữ tài liệu truyền thống.
Thông thường, code cho chúng ta biết hệ thống hiện đang hoạt động như thế nào.
Commit message cho biết những thay đổi đã được thực hiện.
Nhưng lý do thực sự phía sau một quyết định đôi khi nằm trong các cuộc họp, tin nhắn hoặc trí nhớ của một vài người.
Khi những người đó rời nhóm hoặc thời gian trôi qua, kiến thức ấy dễ dàng bị mất.
Thorsten cho rằng càng nhiều thành viên sử dụng Amp, lượng kiến thức tích lũy càng có thể nhân lên, giúp tránh việc nhiều người phải nghiên cứu lại cùng một vấn đề.
Tôi thấy ý tưởng này khá thú vị.
Nếu được tổ chức tốt, lịch sử làm việc với Agent có thể không chỉ ghi lại kết quả mà còn ghi lại cả quá trình suy luận, thử nghiệm và lựa chọn.
Tuy nhiên, lịch sử hội thoại cũng có thể chứa rất nhiều thông tin nhiễu, giả thuyết sai hoặc những phương án đã bị loại bỏ.
Vì vậy, để thực sự trở thành bộ nhớ hữu ích, hệ thống cần giúp phân biệt giữa điều đã được quyết định, điều chỉ mới được đề xuất và điều đã được chứng minh là sai.
Nhưng tiềm năng của cách làm này là khá rõ ràng.
14. Đừng để Agents viết thay những nội dung dành cho con người
Đây là một ý khá bất ngờ trong danh sách của Thorsten.
Sau khi khuyến khích giao nhiều công việc hơn cho Agents, anh lại đưa ra một giới hạn:
Đừng để Agents viết những nội dung dành cho con người.
Anh có một số ngoại lệ, chẳng hạn như hướng dẫn debug, báo cáo sự cố và một số loại tài liệu kỹ thuật, nơi nội dung mang tính cơ học và yếu tố con người không quá quan trọng.
Tôi nghĩ đây là một quan điểm rất đáng suy nghĩ, đặc biệt khi AI ngày càng được sử dụng rộng rãi để viết email, bài blog, bài đăng mạng xã hội và các loại nội dung khác.
AI có thể tạo ra một đoạn văn đúng ngữ pháp, có cấu trúc rõ ràng và đầy đủ thông tin.
Nhưng điều đó không có nghĩa là đoạn văn ấy có điều gì đáng để người khác đọc.
Một bài viết cá nhân có giá trị không chỉ vì nó trình bày thông tin chính xác, mà còn vì nó phản ánh trải nghiệm, cách nhìn và những điều người viết thực sự quan tâm.
Nếu để AI tự quyết định toàn bộ nội dung, chúng ta rất dễ nhận được một bài viết trơn tru nhưng thiếu cá tính.
Tôi nghĩ điều này cũng liên quan trực tiếp đến cách mình đang sử dụng AI để viết blog.
Tôi có thể dùng AI để dịch tài liệu, hệ thống hóa ý tưởng, kiểm tra lập luận hoặc giúp diễn đạt những điều mình đang nghĩ.
Nhưng những trải nghiệm cá nhân, những câu hỏi khiến tôi tò mò và những quan điểm tôi muốn chia sẻ vẫn cần đến từ chính mình.
Chẳng hạn, câu chuyện tôi từng học một năm tại Học viện Kỹ thuật Mật mã, hay việc tôi bắt đầu làm được những công việc lập trình nhờ tự học và sử dụng AI, không phải là những điều AI có thể tự tạo ra một cách chân thực nếu tôi chưa từng kể.
Nó có thể giúp tôi viết rõ ràng hơn về những trải nghiệm ấy.
Nhưng nó không thể thay tôi thực sự sống qua chúng.
Và có lẽ đó là sự khác biệt giữa sử dụng AI như một công cụ hỗ trợ viết và giao toàn bộ tiếng nói của mình cho AI.
15. Chỉ trực tiếp review những phần code có phạm vi ảnh hưởng lớn
Nguyên tắc cuối cùng của Thorsten có lẽ sẽ khiến nhiều lập trình viên truyền thống cảm thấy không thoải mái.
Anh không còn muốn review mọi thay đổi trong code.
Thay vào đó, anh chỉ tập trung vào những phần có blast radius lớn, tức những thay đổi mà nếu xảy ra lỗi có thể ảnh hưởng đến nhiều thành phần của hệ thống.
Theo anh, trong codebase mình đang làm việc có chưa đến năm file trung tâm thuộc nhóm cần đặc biệt chú ý.
Những thay đổi liên quan đến database migration cũng cần được review.
Nhưng những chuyện như nên sử dụng closure hay class, kiểu dữ liệu nào gọn hơn, tên biến ra sao hoặc một chút trùng lặp trong code thì anh không còn quá quan tâm.
Thay vào đó, Thorsten đặt ra những câu hỏi khác:
- Hệ thống có hoạt động đúng không?
- Tôi có hiểu nó ở mức độ kiến trúc, như những mũi tên trong một sơ đồ không?
- Agent đã kiểm thử toàn bộ quy trình từ đầu đến cuối chưa?
- Nếu một tháng sau cần thay đổi, tôi có thể làm được không?
Nếu những điều này đều ổn, anh thậm chí có thể không cần đọc code chi tiết.
Tôi nghĩ đây là một sự thay đổi khá lớn trong cách đánh giá công việc lập trình.
Trước đây, code review thường được xem là một trong những cơ chế quan trọng nhất để bảo đảm chất lượng.
Nhưng khi AI có thể tạo ra lượng code lớn trong thời gian ngắn, việc con người cố gắng đọc từng dòng có thể trở thành nút thắt cổ chai.
Điều đó không có nghĩa là code review không còn cần thiết.
Mà có lẽ chúng ta phải phân bổ sự chú ý dựa trên mức độ rủi ro.
Một thay đổi nhỏ về giao diện không nhất thiết cần cùng mức độ kiểm tra với một thay đổi liên quan đến xác thực người dùng, phân quyền truy cập hoặc cấu trúc dữ liệu.
Một database migration có thể gây mất dữ liệu cần được xem xét kỹ hơn nhiều so với việc đổi tên một biến.
Tôi nghĩ tư duy này khá gần với cách quản lý rủi ro trong những lĩnh vực khác.
Chúng ta không thể kiểm tra mọi thứ với cùng một mức độ nghiêm ngặt.
Vì vậy, điều quan trọng là xác định đúng những nơi mà sai sót có thể gây ra hậu quả lớn nhất.
16. Từ người trực tiếp làm việc đến người thiết kế cách công việc được thực hiện
Sau khi đọc hết 15 nguyên tắc của Thorsten, tôi nhận ra chúng có một điểm chung.
Anh không còn xem AI Agent đơn thuần là một công cụ giúp lập trình viên viết code nhanh hơn.
Anh đang tổ chức công việc như thể mình có một nhóm nhân sự kỹ thuật có thể tự sử dụng công cụ, thực hiện nhiệm vụ, kiểm tra kết quả và phối hợp với nhau.
Và khi cách làm việc thay đổi, những kỹ năng quan trọng cũng bắt đầu thay đổi theo.
Thay vì phải trực tiếp biết cách thực hiện từng thao tác, chúng ta cần biết cách mô tả kết quả mong muốn.
Thay vì tự tay thử từng phương án, chúng ta có thể thiết kế những thí nghiệm để Agent kiểm tra nhiều phương án.
Thay vì đọc mọi dòng code, chúng ta cần biết cách xây dựng cơ chế kiểm chứng và xác định những rủi ro quan trọng.
Thay vì ngồi chờ AI phản hồi, chúng ta có thể giao nhiệm vụ dài hơn và làm việc bất đồng bộ.
Và thay vì liên tục quản lý từng chi tiết của quá trình thực hiện, chúng ta bắt đầu quan tâm nhiều hơn đến mục tiêu, kết quả và những quyết định mà con người thực sự cần đưa ra.
Điều này khiến tôi nhớ đến trải nghiệm của chính mình.
Vì không có nền tảng lập trình chính quy đầy đủ, tôi từng phải phụ thuộc rất nhiều vào AI để giải thích những khái niệm và hướng dẫn cách làm.
Nhưng khi công cụ trở nên mạnh hơn, tôi nhận thấy mình không còn nhất thiết phải hiểu mọi chi tiết trước khi bắt đầu một dự án.
Tôi có thể học trong quá trình thực hiện, sử dụng AI để khám phá những phương án khác nhau và tập trung vào việc kiểm tra xem sản phẩm có đáp ứng điều mình muốn hay không.
Tất nhiên, điều đó không có nghĩa là tôi đã trở thành một kỹ sư giỏi chỉ nhờ sử dụng AI.
Có những kiến thức nền tảng mà tôi vẫn cần học. Có những vấn đề kỹ thuật mà nếu không hiểu đủ sâu, tôi sẽ khó nhận ra những rủi ro tiềm ẩn.
Nhưng điều quan trọng là tôi không còn xem việc chưa biết cách làm là lý do để không bắt đầu.
Và có lẽ đây cũng là thay đổi lớn nhất mà AI Agents đang mang lại.
Trước đây, để xây dựng một sản phẩm, chúng ta thường phải bắt đầu bằng việc xác định mình biết những công nghệ nào, có những kỹ năng gì và cần thêm bao nhiêu người.
Giờ đây, chúng ta có thể bắt đầu bằng một câu hỏi khác:
“Tôi muốn tạo ra điều gì, và làm thế nào để tổ chức các công cụ hiện có nhằm biến nó thành hiện thực?”
Tôi không nghĩ AI sẽ khiến việc học lập trình trở nên vô nghĩa.
Nhưng tôi nghĩ nó đang thay đổi lý do và cách chúng ta học.
Thay vì học một công nghệ chỉ để có thể tự tay thực hiện mọi thao tác, chúng ta có thể học để hiểu hệ thống tốt hơn, đưa ra những quyết định chính xác hơn và biết khi nào kết quả của AI đáng tin cậy.
Có lẽ trong tương lai, một người làm kỹ thuật giỏi không chỉ được đánh giá bằng số dòng code họ có thể viết, mà còn bằng khả năng tổ chức những hệ thống có thể tạo ra phần mềm chất lượng.
Và nếu điều đó thực sự xảy ra, chúng ta sẽ phải học lại khá nhiều thói quen đã hình thành trong nhiều năm.
Tôi nghĩ đó chính là điều khiến bài viết của Thorsten đáng đọc.
Nó không đơn thuần là danh sách những mẹo sử dụng AI.
Nó là một cái nhìn khá rõ về cách công việc kỹ thuật có thể thay đổi khi AI không còn chỉ biết trả lời câu hỏi, mà bắt đầu có khả năng tự thực hiện công việc.
Có lẽ câu hỏi quan trọng nhất không còn là AI có thể viết code tốt đến đâu, mà là chúng ta có sẵn sàng thay đổi cách làm việc để tận dụng năng lực ấy hay không.
Bài viết được dịch ý, diễn giải và mở rộng từ bài đăng “How I work with Agents” của Thorsten Ball (@thorstenball), tháng 10/2026. Các nguyên tắc và ví dụ về cách sử dụng Agents được lấy từ bài đăng gốc; những phân tích, liên hệ với trải nghiệm tự học lập trình và suy nghĩ về tương lai công việc kỹ thuật là góc nhìn cá nhân của tôi.
Lưu ý: Những nhận xét về mô hình, công cụ và quy trình làm việc phản ánh trải nghiệm mà Thorsten chia sẻ tại thời điểm tháng 10/2026, không nhất thiết áp dụng giống nhau cho mọi nền tảng AI.