Agentic engineering: 5 thuật ngữ mọi AI developer nên biết

1. Viết phần mềm mà không phải tự viết code

Cedric Clyburn, Sr. Developer Advocate tại Red Hat, mở đầu video trong series "think" của IBM Technology bằng một lời mời tưởng tượng: hãy hình dung bạn là một software developer mà không phải viết dòng code nào. Nghe thật dễ chịu, anh nói.

Theo Cedric (video đăng ngày 26/10/2026), với các team ở những công ty search engine và music streaming phổ biến, đó đã là thực tế: 80% hoặc hơn số code của họ được viết bởi AI và bởi những AI coding assistant mới. Anh gọi con số đó là đáng kinh ngạc, nhưng nhấn mạnh rằng đó là thực tế.

Thực tế ấy đi cùng sự lên ngôi của các cách làm phần mềm có AI hỗ trợ (AI-assisted development), và của thứ được gọi là agentic engineering. Câu hỏi đặt ra là nó vận hành thế nào và bạn cần biết gì. Trong vài phút tiếp theo, Cedric muốn giải thích năm thuật ngữ mà anh cho là quan trọng nhất để build và dùng AI model, kèm ví dụ và best practice, để bạn tận dụng AI giống như những team hàng đầu kia (video đăng ngày 26/10/2026). Anh đi từ cơ bản rồi đi lên dần.

2. Prompt engineering: soạn đúng chỉ dẫn cho model

Thuật ngữ đầu tiên trong danh sách của Cedric (video đăng ngày 26/10/2026) là thứ có lẽ bạn đã nghe: prompt engineering. Anh định nghĩa đó là việc soạn ra đúng những chỉ dẫn (instructions) để model làm theo.

Chỉ dẫn kiểu gì? Anh lấy hai ví dụ: "hey, bạn là một chuyên viên technical support", hoặc một câu như "chỉ trả lời dựa trên tài liệu được cung cấp".

You're a technical support specialist.
Only answer based on the provided documentation.

3. Giao tiếp và domain expertise quan trọng hơn chính model

Điều có thể bạn chưa biết, theo Cedric (video đăng ngày 26/10/2026): kể cả khi bạn có một LLM cực kỳ mạnh, anh nói là loại frontier nhất, model được chấm điểm cao nhất, thì việc biết cách giao tiếp, giải thích được bạn muốn gì từ model và model nên làm gì cho bạn, vẫn quan trọng hơn bản thân model.

Và đi kèm khả năng giao tiếp ấy là nhu cầu về domain expertise (trên bảng anh viết tắt "D.E."), tức chuyên môn trong lĩnh vực bạn đang làm, dù đó là lĩnh vực gì. Theo Cedric (video đăng ngày 26/10/2026), nhiều người nghĩ "mình phải là developer mới dùng được các model này". Không hẳn, anh nói, nhưng bạn cần có kinh nghiệm trong chính việc bạn đang nhờ model làm.

Để giao tiếp cho tốt khi làm prompt engineering, một số người dùng microphone: họ có thể nói vài phút liền với LLM bằng dictation (đọc chính tả). Theo Cedric (video đăng ngày 26/10/2026), cách này hiệu quả một cách ngoạn mục, vì các model tiên tiến thật sự có khả năng nắm được bạn đang muốn làm gì. Trên bảng, anh vẽ một chiếc microphone cạnh dòng "Communicate + D.E.".

4. Model nhỏ: few-shot prompt và chain of thought

Tiếp theo, Cedric nói về các model nhỏ hơn: model chạy local hoặc ở edge, thậm chí trên điện thoại di động, như anh mô tả trong video đăng ngày 26/10/2026. Với prompt engineering cho các model nhỏ này, điều anh thường thấy là đưa ví dụ dạng few-shot prompt: những cặp câu hỏi và câu trả lời mà bạn muốn model bắt chước theo.

Bạn đưa các ví dụ ấy (gọi là few-shot prompting) cùng với prompt bạn muốn giao cho model, kiểu "hey, tôi muốn bạn giải bài này" hoặc "lấy thông tin user mới này và đưa ra phản hồi". Bạn còn có thể đưa thêm cái gọi là ví dụ chain of thought (trên bảng viết tắt CoT). Theo Cedric (video đăng ngày 26/10/2026), chain of thought tạo khác biệt rất lớn khi bạn lấy phản hồi từ một LLM cỡ nhỏ, loại bạn có thể chạy ngay trên laptop hay smartphone.

Vậy tuỳ loại model bạn định dùng, chỉ dẫn của bạn có thể khác đi một chút. Nhưng rốt cuộc, Cedric nói với người xem (video đăng ngày 26/10/2026), tất cả là chuyện giao tiếp.

5. Context engineering: mọi thứ model nhìn thấy

Nhưng model không chỉ nhìn thấy chỉ dẫn bạn đưa, và đó là lúc context engineering vào cuộc. Cedric muốn bạn nghĩ về mọi thứ model đang thấy trong context window của nó. Theo danh sách anh đưa ra (video đăng ngày 26/10/2026), trong đó có system prompt, kiểu "đây là việc model phải làm cho use case này"; có tools, MCP server và skill được nạp vào; có PDF và thông tin kéo vào qua retrieval augmented generation (RAG) để trả lời câu hỏi về một chủ đề; và với coding agent, cả codebase của bạn cũng được thêm vào context window.

Và điều cần nhớ, theo Cedric (video đăng ngày 26/10/2026): kể cả khi model có context window rất lớn, chất lượng sẽ giảm đi ngay cả trước khi bạn chạm tới giới hạn được quảng cáo.

6. Compact, summarize và sub-agent

Đó là lý do bạn thấy các kỹ thuật như compact (compacting) hay summarize nội dung context window thành một prompt mới, sạch cho model. Ví dụ Cedric đưa ra (video đăng ngày 26/10/2026): tóm các hoạt động đã diễn ra trong cuộc hội thoại với model vào một phần nhỏ hơn, rồi chuyển phần đó sang một prompt mới tinh. Đây là những cách quản lý context window.

Bạn cũng sẽ thường thấy sub-agent được dùng. Theo Cedric (video đăng ngày 26/10/2026), sub-agent cho phép làm những việc như research, xem xét một thư viện hay đọc tài liệu mà không thêm bao nhiêu vào context window gốc. Các sub-agent này thường nhỏ hơn và có mục đích cụ thể hơn; khi làm xong, chúng đưa thông tin trở lại context window và giúp ta tiết kiệm một chút "chỗ chứa" (anh dùng chữ storage) trong lúc làm việc. Đó là toàn bộ ý của context engineering.

7. Harness engineering: mọi thứ bao quanh model

Dù context window được quản lý tốt, Cedric cho rằng bạn có lẽ vẫn nhận ra còn thiếu gì đó (video đăng ngày 26/10/2026). Với đủ thông tin liên quan, một LLM cực kỳ mạnh sẽ đưa ra được câu trả lời rất chính xác. Nhưng làm sao biết câu trả lời đó thật sự chạy được?

Đó chính là toàn bộ ý tưởng của harness engineering. Định nghĩa của Cedric (video đăng ngày 26/10/2026): harness là mọi thứ bao quanh model, cho phép nó hành động, rồi kiểm chứng việc nó vừa làm, và tiếp tục nhận output, input quay trở lại. Đó là runtime thật sự thực thi lệnh bạn muốn, chẳng hạn sửa file bằng tools.

Harness cũng quản lý context window. Giả sử ta làm quá tải context window ban đầu, thì làm sao vẫn giữ được cùng memory, cùng prompt và cùng quá trình thực thi? Đồng thời, ta muốn có sandbox, vì ta không muốn LLM được làm mọi thứ trên máy tính của mình. Theo Cedric (video đăng ngày 26/10/2026), harness cung cấp được những khả năng đó, cộng với orchestration, tức điều phối các sub-agent đã nói ở phần trước.

8. Feedback để agent tự lặp

Như Cedric mô tả (video đăng ngày 26/10/2026), harness là thứ cho phép ta tương tác với chính máy của mình, và cũng là thứ báo lại cho model. Ví dụ: khi ta dùng tool đó, test suite có pass sau thay đổi model đề xuất không? Hay: khi đưa code đó trở lại repository, giờ có merge conflict không? Trên bảng, anh ghi hai câu "Did tests pass?" và "Conflict?".

Chính feedback này cho phép một agent tự lặp lại (iterate) thay vì bạn phải approve từng bước. Theo Cedric (video đăng ngày 26/10/2026), phần lớn các AI harness ngoài kia đã kết nối với các tool và tiện ích như CI pipeline, observability stack và mọi thành phần bạn đang có sẵn.

9. Agent loop: một AI agent thực chất là gì

Bạn có thể cũng đã nghe nói về loop và loop engineering. Use case rõ nhất mà Cedric đưa ra là chính agent loop (video đăng ngày 26/10/2026). Bắt đầu từ một goal ban đầu (nhiều người chỉ đơn giản dùng prompt), loop cho phép agent hành động (act) bằng đủ loại tools, quan sát (observe) output, và tại điểm đó quyết định (decide) đó là thành công hay tiếp tục vòng lặp.

Và theo Cedric (video đăng ngày 26/10/2026), về cơ bản một AI agent chỉ là thế: vòng lặp này cứ tiếp diễn mãi.

10. Loop engineering: trigger thay cho người prompt

Rồi tới ý tưởng loop engineering. Theo Cedric (video đăng ngày 26/10/2026), thay vì một con người như bạn hay anh liên tục prompt agent, ta gắn vào đó một trigger. Trigger có thể là bất kỳ thứ gì:

• Mỗi sáng lúc 9 giờ, thứ được gọi là cron job.
• Ai đó mở một pull request trong repository.
• Một issue được tạo về một bug, hoặc một alert.

Loop engineering, theo định nghĩa của Cedric (video đăng ngày 26/10/2026), chỉ có nghĩa là thứ ta đang build là một hệ thống điều phối các agent cho bạn, hướng tới goal đã định.

Anh nói thêm rằng thường có một human in the loop để approve các thay đổi xảy ra. Bạn có thể đặt điểm duyệt đó sau khi agent đã bắt đầu hành động và dùng tools, hoặc sau khi nó đã quan sát output. Như vậy bạn cũng kiểm được những gì đang diễn ra trong workflow, và làm việc cùng agent để ship phần mềm hiệu quả hơn, chất lượng cao hơn và nhanh hơn, theo lời Cedric trong video đăng ngày 26/10/2026. Trên bảng, lúc này xuất hiện hai ký hiệu nhỏ màu đỏ, một trên mũi tên sau Act, một trên mũi tên sau Observe.

11. Graph engineering: nhiều agent chạy song song

Bây giờ bạn có nhiều agent làm được việc này, và từ đó có khái niệm graph engineering. Theo Cedric (video đăng ngày 26/10/2026), graph engineering là lấy cùng khái niệm loop nhưng nối song song nhiều agent với nhau. Từ một goal, một điểm bắt đầu hay một trigger, ta có thể có hai sub-agent: một làm market research, một tìm hiểu repository được tổ chức ra sao. Hai sub-agent này chuyển kết quả cho một agent sẽ thực sự implement.

Như vậy ta lấy ý tưởng loop rồi rẽ nhánh ra thành đủ loại cấu trúc graph. Nhưng, theo Cedric (video đăng ngày 26/10/2026), trừ khi bạn có token không giới hạn, bạn sẽ thấy cách triển khai này có thể khá tốn kém. Vì thế bạn không phải lúc nào cũng làm vậy, nhưng đó là khái niệm loop engineering và graph engineering.

12. Software factory: isolation, identity, observability

Cuối cùng là thứ được gọi là software factory. Theo định nghĩa của Cedric (video đăng ngày 26/10/2026), đó là tự động hoá vòng đời phát triển phần mềm (software development lifecycle) bằng AI agent: dựng những pipeline vững chắc cho các việc phát triển phần mềm truyền thống như quản lý task, implement code hay testing, việc gì cũng được.

Thay vì chỉ có một agent đa năng cố gắng xử lý mọi thứ, software factory dùng các agent riêng, mỗi agent cho một task. Theo Cedric (video đăng ngày 26/10/2026), mỗi agent đó cần ba thành phần:

• Isolation: cô lập, bằng container hay sandbox hay bất cứ thứ gì phù hợp (theo Cedric, video đăng ngày 26/10/2026).
• Identity: agent là ai và được truy cập những gì, ví dụ với Git hay với môi trường cloud của ta (theo Cedric, video đăng ngày 26/10/2026).
• Observability: trong lúc agent làm việc, nếu đêm qua chúng chạy lúc 3 giờ sáng, ta phải trace lại được mọi thứ một agent trong factory đã làm (theo Cedric, video đăng ngày 26/10/2026).

Theo Cedric (video đăng ngày 26/10/2026), nhiều team đang bắt đầu dựng những AI software factory như vậy, và khi model ngày càng tốt hơn, anh thấy chuyện này sẽ chỉ ngày càng phổ biến.

13. Ý tưởng cũ được làm mới, và ai cần biết gì

Vậy là năm thuật ngữ. Nếu bạn đã làm kỹ sư, Cedric nói, bạn sẽ nhận ra đây không hẳn là những ý tưởng mới. Graph, feedback loop, distributed system đều là những thực hành điện toán đã có, chỉ là giờ chúng đang được tái phát minh, theo nhận định của anh trong video đăng ngày 26/10/2026.

Nhưng anh nhấn mạnh: bạn không cần là chuyên gia ở tất cả những thứ này. Theo Cedric (video đăng ngày 26/10/2026), nếu bạn chỉ là một solo developer, bạn không cần một software factory. Còn những khái niệm như prompt, context window và harness engineering thì áp dụng cho tất cả mọi người, dù bạn là sinh viên, designer, manager hay bất kỳ ai.

Cedric kết video bằng lời mong mọi người đã học được điều gì đó hôm nay, và một tiếng "Cheers".