5 khái niệm cần biết khi code cùng AI agent

1. Một phi công điều hành cả một team agent

Cedric Clyburn, Senior Developer Advocate ở Red Hat, mở đầu video trong series "think" của IBM Technology bằng một câu chuyện gần đây. Anh đang nói chuyện với một kỹ sư phần mềm thì giữa chừng người đó dừng lại, rút điện thoại ra, approve một thay đổi code, rồi nói chuyện tiếp như không có gì.

Hoá ra người này có nhiều agent chạy ngầm cùng lúc, mỗi agent đảm nhận một vai trò mà bình thường bạn sẽ có trong một team: một developer, một code reviewer, một người lo operations, và còn nhiều vai nữa. Điều bất ngờ là anh ta vốn không phải kỹ sư phần mềm. Anh ta thực ra là một phi công.

Vì vậy, mỗi khi có người hỏi AI có thay thế developer không, Cedric luôn trả lời là không. Anh còn thấy nhiều người bắt đầu đến với lập trình hơn chính nhờ AI. Nhưng thứ AI sẽ làm là thay đổi hình dạng của việc phát triển phần mềm. Trong video, anh đi qua năm khái niệm then chốt bạn cần biết để chuẩn bị, và anh nhắn người xem ở lại tới cuối, vì khái niệm cuối cùng là quan trọng nhất.

2. Khái niệm 1: điểm bùng phát (inflection point)

Khái niệm đầu tiên là inflection point, điểm bùng phát. Cedric giải thích: trong khoảng một năm qua, anh và cả team đều bắt đầu nói cùng một điều. AI giờ hoàn thành được những việc mà trước đây thường mất của họ vài tuần, thậm chí vài tháng, chỉ trong vài phút.

Trước đây, anh dùng AI như một công cụ autocomplete để viết function và test tốt hơn. Nhưng nhiều khi anh mất nhiều thời gian sửa output của AI hơn là nếu tự tay viết từ đầu.

Còn bây giờ, team của anh thường giao nguyên một feature cho AI coding agent. Không chỉ là viết code, mà còn là hiểu codebase và những gì đang diễn ra bên trong nó, viết và chạy test, rồi merge các thay đổi vào codebase thật. Tất cả chỉ từ một prompt duy nhất, hoặc một vòng lặp (loop) có định nghĩa khi nào agent được coi là xong việc.

3. Từ prompt qua lại sang spec development

Nói tới chuyện định nghĩa khi nào agent nên dừng, Cedric chỉ ra cách làm cũ: làm mọi thứ qua prompt. Vấn đề là prompt có thể được các loại coding model khác nhau hiểu theo những cách khác nhau, và bạn phải "cãi nhau" với AI để có được output đúng.

Thứ họ thấy phổ biến bây giờ là một cách tiếp cận gọi là spec development (spec-driven development). Bạn viết ra một bản specification gồm các yêu cầu và tất cả những kết quả (outcome) mà bạn muốn thấy ở dự án phần mềm. Sau đó bạn gửi bản spec đó cho AI coding agent và model để nó tạo ra dự án cùng các artifact của dự án.

4. Khái niệm 2: từ implement sang conduct

Khái niệm thứ hai là sự chuyển dịch từ implementing (tự tay hiện thực) sang conducting (chỉ huy, như một nhạc trưởng). Cedric nhắc lại điều anh nói ở đầu: anh không nghĩ developer sẽ biến mất, nhưng thứ tự ưu tiên chắc chắn đang thay đổi.

Lý do là trong nhiều thập kỷ, nút thắt lớn nhất để đưa code ra ship gồm hai thứ: một là bạn viết code nhanh tới đâu, hai là chất lượng code đó cao tới đâu. Các công ty tuyển những người mà họ cho là lập trình viên thi đấu (competitive programmer) giỏi nhất, hay những người giải được những bài lập trình phức tạp nhất.

Vấn đề là giờ đây hầu hết các AI model đã biết sẵn các ngôn ngữ lập trình, ví dụ Java, Python hay Rust. Chúng dùng những ngôn ngữ mà chúng rất thành thạo đó để hoàn thành công việc, chẳng hạn những ticket team gửi vào, rồi đưa thay đổi đi tiếp qua staging, production, QA và nhiều bước khác nữa. Vậy nếu phần implement đã làm được bằng AI, thì điều gì trở nên quan trọng với developer?

5. Người nhạc trưởng: đặt mục tiêu, chia việc, quản lý context

Câu trả lời của Cedric: trở thành một conductor, một người thuyền trưởng (captain), người có thể đưa ra những quyết định kiến trúc quan trọng sẽ ảnh hưởng tới phần mềm, ví dụ, một năm sau tính từ bây giờ.

Thay vì tự tay viết từng function, thứ họ thấy bây giờ là bạn định nghĩa mục tiêu (define goals), rồi chia công việc (break down work) thành những milestone cụ thể để một AI model hay agent hoàn thành.

Lý do là bạn phải bắt đầu nghĩ về những khái niệm như quản lý context hiệu quả (effective context management). Context management là việc hiểu giới hạn tài nguyên của context window của một AI model, cùng tất cả những thành phần được thêm vào bên cạnh codebase của bạn khi bạn dùng model cho công việc kỹ thuật, ví dụ tools, skills hay MCP server để đưa dữ liệu bên ngoài vào cho model. Đó chính là context engineering.

6. Loop engineering: thiết kế vòng lặp thay vì tự prompt

Bên cạnh context engineering còn có ý tưởng loop engineering. Thay vì bạn là người prompt agent qua lại và liên tục lặp đi lặp lại, bạn thiết kế một hệ thống làm việc đó thay bạn.

Loop engineering vận hành như một mục tiêu đệ quy (recursive goal): con người định nghĩa mục đích (purpose), còn AI lặp đi lặp lại cho tới khi hoàn thành việc cần làm, dù đó là việc gì.

7. Khái niệm 3: hiểu nền tảng của AI, ví dụ game RPG

Khái niệm thứ ba là AI fundamentals: hiểu những điều cơ bản về AI model cũng rất quan trọng. Cedric đưa ra một ví dụ. Nếu bạn hỏi một AI model mất bao lâu để làm một game nhập vai góc nhìn thứ ba (third person RPG), nó có thể trả lời đại loại "vài tuần tới vài tháng" là thời gian nó ước tính để làm xong game đó. Trên bảng anh ghi "1-3 Months".

Nhưng nếu bạn đưa đúng model đó, cùng một coding agent, đi làm thật game đó, thì nó có thể đưa cho bạn một bản chạy được chỉ trong khoảng năm phút. Vậy chuyện này là sao?

Theo Cedric, đó là một trong những giới hạn của LLM: nó không thật sự hiểu thời gian và bộ nhớ (time and memory) như con người chúng ta. Vì thế hiểu những điều cơ bản về cách các LLM và model hoạt động là rất quan trọng.

8. Model nằm trong GPU ra sao: weights và KV cache

Ví dụ thứ hai về nền tảng là cách LLM được lưu trong bộ nhớ GPU và cách bạn thật sự dùng chúng lúc inference. Một phần là weights của model, được nạp vào bộ nhớ của GPU. Phần còn lại là KV cache, được tạo ra và lưu lại khi bạn gửi request tới model và nhận kết quả về.

Cedric cho rằng hiểu tất cả những điều này sẽ cho bạn một lợi thế lớn khi tiếp tục dùng AI model với tư cách một software developer.

9. Skills, automations và sub-agent

Sau đó, anh cộng thêm các khả năng của context engineering vừa nói ở trên. Thứ nhất là skills: về bản chất là các file markdown, nhưng chúng thêm thông tin có thể tái sử dụng và mang tính ngữ cảnh về code và dự án của bạn vào mỗi request gửi tới AI. Trên bảng, anh ghi chú skills như một "reusable prompt".

Thứ hai là automations: dựng những thứ kiểu cron job và các action được kích hoạt bởi sự kiện (event-triggered action). Ví dụ, khi có người vào website của bạn và điền một form, việc đó có thể khởi động một automation.

Thứ ba là sub-agent. Sub-agent về cơ bản dùng cho những tình huống như khi bạn đang điều tra một vấn đề trong code và gửi một sub-agent đi xem một library hoạt động thế nào, tự nó chạy thử, rồi quay lại báo cho agent chính.

Tất cả đều là ví dụ về các khả năng context engineering mà bạn có thể bắt đầu đưa vào quy trình làm phần mềm của mình để dùng AI model tốt hơn, và trên bảng anh còn ghi thêm "+ More". Theo Cedric, đây là những kiến thức nền quan trọng cần biết.

10. Khái niệm 4: bảo mật và prompt injection

Khái niệm thứ tư là security. Cũng giống như SQL injection có thể xâm nhập ứng dụng của chúng ta, prompt injection cũng là chuyện rất thật. Lý do là các hệ thống AI có quyền truy cập dữ liệu nhạy cảm, có tiếp xúc với web, và cũng có khả năng gửi dữ liệu ra ngoài.

Khi agent của bạn có đủ cả ba điều này cùng lúc, hoàn toàn có thể xảy ra chuyện nó đọc một pull request trên mạng, như agent nhỏ Cedric vẽ ở giữa bảng đang nhìn vào pull request, và bị lừa gửi thông tin đăng nhập (credentials) của bạn cho người khác. Anh vẽ thêm một chiếc chìa khoá tượng trưng cho credentials riêng tư bạn để trên máy. Và việc này có thể xảy ra mà bạn thậm chí không hề biết.

11. Chạy coding agent trong sandbox

Chính vì vậy mà các team đang chạy coding agent bên trong những sandbox dùng một lần (disposable sandbox) bất cứ khi nào có thể.

Trên bảng, Cedric đóng khung agent cùng phần code mà bạn đang làm việc trong một môi trường riêng của nó. Mục đích là giảm bề mặt tấn công (attack surface) nếu một AI agent bị chiếm quyền (compromised).

12. Khái niệm 5: tương lai, AI là "điện năng mới"

Khái niệm cuối cùng, và cũng là khái niệm Cedric nói là quan trọng nhất, là tương lai. Gần đây anh có dịp làm việc với "huyền thoại AI" Andrew Ng, và anh nhớ câu nói của ông: AI đang trở thành điện năng mới (AI is the new electricity). Vậy câu đó thật ra có nghĩa là gì?

Điện đã biến đổi mọi thứ xung quanh nó. Bây giờ chúng ta dùng điện để sạc điện thoại, bật đèn và sưởi ấm nhà cửa. Nhưng cũng có cả những ngành công nghiệp và hàng nghìn người, ví dụ làm việc ở các trạm biến áp (substation) để đảm bảo lưới điện vận hành. Họ cũng ra hiện trường giúp mọi người, chẳng hạn sửa đèn đường hay hỗ trợ tại nhà. Và họ đảm bảo rằng ai cũng có thể tiếp cận được điện.

AI có thể đi theo đúng con đường đó. Chúng ta sẽ cần những kỹ sư có thể bảo trì các hệ thống này: "lưới điện" để đảm bảo kết nối, giúp mọi người tiếp cận được các AI model và hệ thống AI, và đảm bảo các hệ thống AI an toàn, đáng tin cậy và có chất lượng.

13. Từ viết code sang thiết kế và điều phối hệ thống

Vì vậy Cedric bảo người xem đừng lo. Anh nghĩ software engineering sẽ không đi đâu cả, và anh lạc quan về tương lai của developer cũng như những gì họ sẽ tạo ra được.

Đúng là nghề này đang dịch chuyển, rời khỏi việc chỉ tự tay viết code để sang thiết kế (designing) và điều phối (orchestrating) các hệ thống và AI agent. Những người xuất sắc ở giai đoạn kiến trúc và tư duy phản biện (critical thinking) sẽ càng trở nên giá trị hơn khi các AI coding agent tiếp tục tiến bộ.

Anh cảm ơn mọi người đã xem và mời ai thấy video hữu ích bấm like, subscribe để xem thêm nội dung về AI và phát triển phần mềm.