# Lộ trình AI engineer 2027: code review, forward deployed engineer và 12 layer production agent

[Maryam Miradi](https://homus.dev/speakers/maryam-miradi) · [Dr. Maryam Miradi](https://homus.dev/orgs/dr-maryam-miradi)

> Vì sao code review thành bottleneck khi AI viết code, sense of good và forward deployed engineer, rồi 12 layer production AI agent cùng công cụ cho từng layer.

Topics: Agents, Context Engineering, Evals

Canonical: https://homus.dev/talks/my-exact-2027-ai-engineer-roadmap-in-the-era-of-ai-coding

## 1. Một lộ trình cho 5 đến 10 năm tới

Maryam mở đầu bằng một lời mời tưởng tượng: giả sử bạn có thể nhìn vào tương lai của AI engineering và biết chính xác nên học kỹ năng nào, nên chọn công việc nào, và làm sao để vẫn có giá trị ngay cả khi các AI coding agent đang dần tiếp quản việc lập trình (theo video đăng ngày 01/11/2026).

Chị nói đây không phải là vài ý tưởng trừu tượng, mà là một roadmap rõ ràng, kèm công cụ chính xác và những năng lực bạn cần cho 5 đến 10 năm tới, bất kể chỉ riêng tuần này có thêm bao nhiêu AI coding assistant mới ra mắt (theo video đăng ngày 01/11/2026). Đó là điều chị muốn dạy trong video: dù bạn là junior AI engineer, senior AI engineer hay vừa bước vào ngành, bạn sẽ biết chính xác nên đầu tư thời gian vào đâu để có lợi nhiều nhất.

Với người mới, chị giới thiệu mình là Maryam, có bằng PhD và hơn 20 năm kinh nghiệm xây dựng hệ thống AI trong nhiều ngành khác nhau (theo video đăng ngày 01/11/2026).

Câu hỏi Maryam đặt ra ở đầu video đăng ngày 01/11/2026: với người mới, junior hay senior, nên đầu tư thời gian vào đâu cho 5 đến 10 năm tới.

## 2. AI engineer: một chức danh ra đời năm 2023

Maryam kể lại rằng năm 2023, swyx, một AI developer người Singapore, đưa ra chữ "AI engineer" trong một bài blog mà chị đánh giá là rất hay (bài "The Rise of the AI Engineer" trên Latent Space, tháng 6/2023). Từ đó, theo chị, ai cũng bắt đầu tuyển AI engineer (theo video đăng ngày 01/11/2026).

Thuật ngữ ra đời và mọi người đều rất vui, vì đó là một cú "shift right" chỉ có một lần trong một thế hệ đối với applied AI, và nhất là vì mọi thứ được làm qua API. Chị nói trong một thời gian, điều đó là tốt, vì nghề này bắt đầu có một bản sắc riêng, giống như hồi data science và data scientist được trao một danh tính (theo video đăng ngày 01/11/2026).

Rồi AI coding bắt đầu cất cánh. Lúc đầu, theo Maryam, chúng ta không coi các công cụ đó là nghiêm túc vì chúng chưa giỏi lắm. Nhưng sang năm 2026, chất lượng bắt đầu tăng thật sự. Phần lập trình mà chúng ta vẫn làm với sự trợ giúp của AI dần bị lấy khỏi tay mình, và thứ còn lại chủ yếu là review (theo video đăng ngày 01/11/2026).

Diễn biến Maryam kể trong video đăng ngày 01/11/2026: từ chữ "AI engineer" năm 2023 tới lúc AI coding tiếp quản phần lập trình và để lại phần review.

## 3. Nhiều code hơn, nhưng ship không nhanh hơn bao nhiêu

Maryam đưa ra một loạt số liệu. Chị nói chúng ta đang viết nhiều code hơn gần 800%, trong khi số release chỉ tăng 30%; slide của chị ghi cụ thể "8x more code, 1.3x faster shipping", với dòng NBER ghi +741% code và +30% releases, kèm chú thích đây là các ước tính khác nhau, không phải một phép so sánh khớp cặp (slide trong video đăng ngày 01/11/2026).

Tiếp theo, theo chị, dữ liệu từ 8 triệu pull request cho thấy thời gian chờ review dài hơn 4,6 lần (slide ghi LinearB, 8M PRs, "4.6x longer review wait"). Cisco cho thấy khoảng 450 dòng là mức tối đa một người có thể review trong một giờ; slide ghi Cisco / SmartBear, khoảng 450 LOC/hour, và hiệu quả review giảm khi vượt quá khoảng 400 đến 500 LOC/hour (video đăng ngày 01/11/2026).

Với dữ liệu thứ ba, chị nói thời gian review cao hơn khoảng 440%, và khi không có review nào thì vào khoảng 31%; slide ghi Faros, 22K developers, +440% review time, +240% incidents per PR và +31% unreviewed merges. Chị nhấn mạnh khoảng chênh này lớn đến mức nào (theo video đăng ngày 01/11/2026).

Maryam cũng dẫn Anthropic: theo chị, Anthropic vừa cho biết 80% code được merge của họ là do Claude viết; slide ghi "80%+ merged code written by Claude" (video đăng ngày 01/11/2026).

![Slide AI Coding: More Code, Slower Delivery? với các thanh số liệu từ NBER, LinearB, Cisco / SmartBear, Faros và Anthropic](https://homus.dev/photos/EY-xc-Cyelk-0148.jpg)

Slide "AI Coding: More Code, Slower Delivery?" gom năm nguồn số liệu: NBER (+741% code, +30% releases), LinearB (8M PRs, review chờ lâu hơn 4,6 lần), Cisco / SmartBear (khoảng 450 LOC/hour), Faros (22K developers) và Anthropic (80%+ code merge do Claude viết) (slide trong video đăng ngày 01/11/2026).

## 4. Code review là bottleneck

Về code review, Maryam nói hiện nay chúng ta đưa vào khoảng 10.000 dòng code. Với mức 450 dòng mỗi giờ, cần khoảng 22 giờ review để xem xét các bản sửa, các test và các thảo luận. Slide của chị ghi phép tính "10,000 ÷ 450 ≈ 22 review hours", kèm dòng "before fixes, tests & discussion" (chưa tính sửa lỗi, test và thảo luận) (video đăng ngày 01/11/2026).

![Slide Code Review Is the Bottleneck: robot đẩy chồng diff 10.000 dòng vào hàng đợi review, người review khoảng 450 dòng mỗi giờ](https://homus.dev/photos/EY-xc-Cyelk-0247.jpg)

Slide "Code Review Is the Bottleneck": một diff 10.000 dòng dồn vào review queue, trong khi người review làm được khoảng 450 dòng mỗi giờ, thành khoảng 22 giờ review (slide trong video đăng ngày 01/11/2026).

Theo Maryam, có thể lập luận rằng thứ tiếp theo sẽ bị lấy khỏi tay chúng ta là code review. Nhưng chị chỉ ra rằng nếu đưa việc review đó cho bốn agent, bạn sẽ nhận được những cách sửa khác nhau, và không cái nào thật sự là thứ người maintainer muốn (theo video đăng ngày 01/11/2026).

Chị dẫn một bài kiểm tra: benchmark nói 87% bản sửa vượt qua được, nhưng nếu hỏi chính người maintainer của code đó, chỉ 54% được họ cho qua. Lý do là maintainer sẽ nói: còn thiếu lịch sử (history), thiếu hiểu biết về hệ thống (systems), có side effect, có chuyện style. Tất cả những thứ đó nằm trong đầu người maintainer, và agent không biết (theo video đăng ngày 01/11/2026).

![Slide Passing Tests khác Merge-Ready: 87% qua benchmark tests, 54% maintainer sẽ merge](https://homus.dev/photos/EY-xc-Cyelk-0323.jpg)

Slide "Passing Tests ≠ Merge-Ready": 87% qua benchmark tests nhưng chỉ 54% được maintainer merge, vì đó là "different question"; quanh người review là bốn thứ style, side effects, systems, history (slide trong video đăng ngày 01/11/2026).

Phần đó là gì? Maryam gọi nó là cảm nhận về thế nào là "good" (a sense of what good means). Theo chị, thứ agent đang thiếu lúc này chính là cảm nhận về định nghĩa thật sự của "good" (video đăng ngày 01/11/2026).

## 5. Bottleneck kế tiếp: operations và security

Maryam nói bottleneck của chúng ta lúc này là review, cụ thể là code review. Theo chị, nếu giải được nó, bottleneck sẽ chuyển sang chỗ kế tiếp, và chỗ đó có thể là operations và security (theo video đăng ngày 01/11/2026).

Chị nói chúng ta cũng biết mình có rất nhiều dữ liệu về operations và security, và có lẽ đến một lúc nào đó chúng ta cũng sẽ giao phần đó cho agent. Vậy nếu đó là tất cả, và chúng ta cứ giải bottleneck này rồi tới bottleneck kế tiếp, thì phần nào sẽ còn lại cho chúng ta (theo video đăng ngày 01/11/2026)?

Theo Maryam, thứ ở lại có liên quan tới việc chúng ta giải thích được tới mức nào cái cảm nhận về việc làm tốt một điều gì đó (video đăng ngày 01/11/2026).

## 6. Cùng một yêu cầu, ba định nghĩa "good"

Nhưng "good", theo Maryam, khác nhau trong từng hoàn cảnh. Chị lấy ví dụ yêu cầu "track my order" (theo dõi đơn hàng của tôi). Một tiệm bánh sẽ nhìn vào độ tươi và giờ lấy hàng, và điều đó rất đặc thù cho ngành của họ. Với phụ tùng ô tô thì hoàn toàn khác: tồn kho, độ tương thích với các hãng xe và mọi thứ liên quan. Còn trong sản xuất, người ta nhìn vào các nhà cung cấp và lịch sản xuất, một câu chuyện hoàn toàn khác (theo video đăng ngày 01/11/2026).

![Slide Same Request, Different Definition of GOOD: Track my orders cho tiệm bánh, phụ tùng ô tô và nhà máy](https://homus.dev/photos/EY-xc-Cyelk-0448.jpg)

Slide "Same Request. Different Definition of GOOD.": cùng câu "Track my orders", tiệm bánh cần freshness và pickup times, auto parts cần part compatibility và stock, manufacturing cần suppliers và production schedule; dòng kết ghi "Requirements live in the customer's head." (slide trong video đăng ngày 01/11/2026).

Như vậy, chỉ với ba ngành, chúng ta đã có ba định nghĩa về "good". Câu hỏi Maryam đặt ra là làm sao quyết định cái "good" đó. Theo chị, nếu biết thế nào là good, chúng ta có thể đào tạo các engineer cho tương lai để phát triển cảm nhận đó, vì có vẻ đó là một phần công việc mới của chúng ta; nhưng chúng ta cần hiểu cách làm điều đó (theo video đăng ngày 01/11/2026).

## 7. Hành trình AI qua nhiều ngành

Nhìn lại hành trình AI của chính mình, Maryam kể chị bắt đầu xây các giải pháp AI nghiêm túc cho nhiều ngành khác nhau, và chị cố ý đi từ loại ngành này sang loại ngành khác, giải quyết rất nhiều bài toán khác nhau (theo video đăng ngày 01/11/2026).

![Slide My AI Journey Across Industries 2002 đến 2026 với các ngành từ food engineering tới cybersecurity](https://homus.dev/photos/EY-xc-Cyelk-0603.jpg)

Slide "My AI Journey Across Industries, 2002 - 2026": dòng thời gian qua food engineering, supply chain, road engineering, tax & accounting, retail, e-commerce, medical imaging, financial crime detection (được tô nổi), energy production & networks, anti-money laundering, cybersecurity và "+ more" (slide trong video đăng ngày 01/11/2026).

Với những người chưa ở trong ngành AI lâu, chị giải thích AI trước đây trông như thế nào: machine learning, deep learning, computer vision và natural language processing. Theo chị, natural language processing là phiên bản trước của large language model, còn computer vision là phiên bản trước của các model generative AI về hình ảnh ngày nay (theo video đăng ngày 01/11/2026).

Machine learning và deep learning, nơi có rất nhiều neural network, theo Maryam là nền tảng của mọi loại dự đoán và mọi loại pattern recognition trong toàn bộ AI. Machine learning, deep learning và tất cả các lĩnh vực này đều là một phần của AI nói chung (theo video đăng ngày 01/11/2026).

Lời khuyên đầu tiên của chị để phát triển cảm nhận về "good": hãy cố trải nghiệm càng nhiều project càng tốt, với bản chất hoàn toàn khác nhau, trong những ngành hoàn toàn khác nhau (theo video đăng ngày 01/11/2026).

## 8. Bài học từ một phòng financial crime detection

Một điều nữa, Maryam kể về thời chị làm financial crime detection, lý do chị tô nổi mục này trên slide. Đó là một bộ phận 4.000 người ở Amsterdam, với khoảng hơn 400 developer, AI developer. Họ nhờ chị tìm hiểu vì sao các giải pháp không khớp với output người dùng muốn, và về cơ bản là phát triển các giải pháp tốt hơn (theo video đăng ngày 01/11/2026).

Việc đầu tiên chị làm là phỏng vấn các chuyên gia, những người bên mảng criminology, những người sẽ nói: đây là các nghi phạm, đây là những người mà chúng tôi chọn dựa trên các đặc điểm này. Chị nhớ sau một ngày phỏng vấn, một buổi phỏng vấn rất sâu với một nhóm trong cùng một phòng, chị có thể phát triển ý tưởng cho khoảng ba năm, và những ý tưởng đó khớp với nhu cầu của các chuyên gia (theo video đăng ngày 01/11/2026).

Câu chuyện Maryam kể trong video đăng ngày 01/11/2026: một ngày phỏng vấn sâu các chuyên gia đem lại khoảng ba năm ý tưởng khớp với nhu cầu của họ.

Theo Maryam, đó chính là phần chị biết chắc AI agent sẽ không tiếp quản trong những năm tới, vì người dùng có những nhu cầu hoàn toàn khác nhau đối với giải pháp bạn đưa ra. Chị nói điều đó rất khó có được, vì nó quá đặc thù cho văn hoá của một công ty bên trong một quốc gia, nên vẫn chưa phải là thứ bạn có thể giao cho máy móc (theo video đăng ngày 01/11/2026).

Một điều nữa, theo chị: khi làm việc qua nhiều ngành, bạn bắt đầu phát triển cảm nhận về "good" cho cả một cụm ngành giống nhau. Ví dụ road engineering và energy production đều có tài sản (assets): mặt đường nhựa là tài sản rất đắt nằm trên mặt đất, còn cáp điện thì luôn nằm dưới mặt đất, nhưng độ phức tạp thì giống hệt nhau. Điều đó cũng đúng với nhiều mảng healthcare, medical imaging: dù là MRI hay X-ray, độ phức tạp trông giống nhau (theo video đăng ngày 01/11/2026).

## 9. Sense of good chính là spec

Maryam nói cảm nhận về "good" đó chính là spec, hay specification. Phần accidental complexity mà chúng ta tự tạo ra thì AI thu nhỏ lại cho chúng ta bằng việc viết code. Nhưng thứ chúng ta cần bây giờ là: đang giải bài toán gì, và thế nào thì được tính là đã giải xong. Theo chị, phần đó vẫn rất khó, và đó là phần chúng ta muốn giữ lại cho con người (theo video đăng ngày 01/11/2026).

Hai phía Maryam đặt cạnh nhau trong video đăng ngày 01/11/2026: AI thu nhỏ accidental complexity, còn câu hỏi giải bài toán gì và thế nào là xong vẫn rất khó.

## 10. Forward deployed engineer và product judgment

Khi chúng ta nói một thứ là "good", theo Maryam, đó là lúc chúng ta nói đây là một sản phẩm, một sản phẩm mà tôi sẽ dùng. Và tư duy sản phẩm đó đã có nhãn riêng trong thế giới AI: khi nói về việc làm, thị trường đang trả tiền cho những engineer có tư duy sản phẩm, dưới nhãn forward deployed engineering. Chị nói thẳng rằng một data scientist giỏi thời trước lẽ ra cũng phải có đúng những năng lực đó, nhưng thôi cứ đi theo các nhãn mới (theo video đăng ngày 01/11/2026).

Chị nói số tin tuyển forward deployed engineer tăng khoảng 800%, kèm mức lương "điên rồ" (insane salaries) đi cùng. Slide ghi "+800% FDE job postings" từ Jan 2025 tới Sep 2025, và "$240K - $600K" là ví dụ một khoảng lương đã đăng tuyển, với chú thích nhỏ rằng lương thay đổi tuỳ vị trí (slide trong video đăng ngày 01/11/2026).

![Slide The Market Is Paying for Product-Minded Engineers: +800% FDE job postings, khoảng lương 240K đến 600K đô](https://homus.dev/photos/EY-xc-Cyelk-0923.jpg)

Slide "The Market Is Paying for Product-Minded Engineers": +800% FDE job postings (Jan đến Sep 2025), $240K - $600K là ví dụ khoảng lương đăng tuyển, và công thức "Engineering + Product Judgment = High Demand" (slide trong video đăng ngày 01/11/2026).

Theo Maryam, điều duy nhất là forward deployed engineer phải có kỹ năng engineering như bạn vẫn luôn cần, nhưng thêm product judgment và cái cảm nhận về "good" mà chị vừa nói. Chị nói các con số cho thấy nhu cầu này cao tới mức nào (theo video đăng ngày 01/11/2026).

Vì sao lại trả nhiều như vậy? Theo chị, vì như đã giải thích, business rất lộn xộn và khá tốn kém, giống như bộ phận 4.000 người kia: bạn có thể hình dung nó tốn kém tới đâu khi phải chống lại tội phạm tài chính. Vì vậy bạn muốn tạo ra một vai trò như forward deployed engineer để biến nó thành một sản phẩm chạy được. Nếu bạn biến được sự mơ hồ của business (business ambiguity) thành phần mềm chạy được, thì bạn là một forward deployed engineer (theo video đăng ngày 01/11/2026).

Maryam nói vui rằng còn có một nhãn khác cho vai trò này, gọi là AI Translator. Nhưng như chị nói, chúng ta rất thích các nhãn, và cứ sáu tháng lại có một cái tên mới. Lời khuyên của chị: đừng bận tâm tới các tên gọi đó, nhưng hãy ý thức rất rõ bên trong mỗi nhãn là gì và bạn nên học gì. Và lúc này, theo chị, đó là việc giảm sự mơ hồ của business thành bất kỳ loại sản phẩm nào chạy được (theo video đăng ngày 01/11/2026).

## 11. Developer và programmer không phải là một

Theo Maryam, kỹ năng đó trước đây, thời của data scientist, chỉ là "có thì tốt", còn bây giờ là thiết yếu. Vì sao? Chị nói không còn lập trình nữa: bạn không được tuyển vì bạn là một lập trình viên rất giỏi, phần đó coi như đã qua (theo video đăng ngày 01/11/2026).

Chị nói điều này đúng cả với người như chị, người viết code từ năm 16 tuổi, năm đầu đại học, hơn 30 năm nay, và việc không còn code nữa làm chị rất đau lòng. Theo chị, phần lớn các AI coding agent giờ đã quá giỏi, và bạn phải chấp nhận thực tế đó, tiếc là cả trong tương lai (theo video đăng ngày 01/11/2026).

Vậy developer và programmer không phải là một. Với những người đã ở trong ngành AI thì không sao, vì trước đây chúng ta lập trình rất nhiều và giờ lập trình ít hơn. Nhưng Maryam bảo hãy hình dung các junior developer: trước đây chúng ta giao cho họ một task cụ thể, họ đi làm nó, còn chúng ta làm phần việc phía trước, các buổi phỏng vấn và mọi thứ. Giờ phần việc của junior đã bị lấy đi hoàn toàn, nên khoảng cách giữa một junior engineer vừa vào thị trường và một product engineer là rất lớn (theo video đăng ngày 01/11/2026).

## 12. Khoảng trống đào tạo product engineer

Maryam nói đây không phải chuyện tưởng tượng, đây là số liệu lao động. Theo chị, nhóm 41 đến 49 tuổi đang tăng, và đó là số liệu của năm 2025; năm 2026 có lẽ còn tệ hơn, nếu cuối năm có người đo. Nhóm tới 40 tuổi vẫn bám sát nhóm đó. Nhưng hãy nhìn nhóm 22 đến 25 tuổi: các con số khá kịch tính, nghĩa là họ thật sự không được tuyển (theo video đăng ngày 01/11/2026).

![Biểu đồ US software developer employment by age, nhóm 22 đến 25 tuổi giảm 19% so với đỉnh sau khi ChatGPT ra mắt](https://homus.dev/photos/EY-xc-Cyelk-1223.jpg)

Biểu đồ "US software developer employment by age" (dữ liệu ADP payroll, lấy mốc Oct 2022 = 1.0, số hoá từ Brynjolfsson, Chandar & Chen, 2025): sau mốc ChatGPT ra mắt, nhóm 41-49 và 35-40 đi lên, nhóm 26-30 đi ngang rồi giảm nhẹ, nhóm 22-25 giảm "-19% from peak" (biểu đồ trong video đăng ngày 01/11/2026).

Theo Maryam, chúng ta đã vô tình tạo ra vấn đề này, và giờ phải thiết kế một thứ khác. Chị nói chúng ta phải thiết kế ngày mai sao cho người junior đi qua một quy trình để trở thành forward deployed engineer, product engineer, hay bất kỳ nhãn nào mà chúng ta nghĩ ra, những vị trí đang có nhu cầu cao (theo video đăng ngày 01/11/2026).

Nhưng ngay lúc này, theo chị, chúng ta đang tụt lại phía sau. Ngay cả công ty như Google cũng chỉ tuyển khoảng 50 người từ 12.000 đơn. Có những chương trình tương tự, nhưng họ nói chỉ tuyển khoảng 1.000 người, trong khi chúng ta cần khoảng 10.000 người mỗi năm (theo video đăng ngày 01/11/2026).

![Slide The Product Engineer Training Gap: Google APM 50 mỗi năm, chương trình tương tự khoảng 1.000 mỗi năm, cần 10.000 mỗi năm, khoảng cách 10 lần](https://homus.dev/photos/EY-xc-Cyelk-1312.jpg)

Slide "The Product Engineer Training Gap": Google APM 50/year, similar programs khoảng 1,000/year, needed 10,000/year, "10x GAP!"; bên dưới là University (data structures), Bootcamp (React) và câu hỏi "Who teaches THIS?" cho việc "Talk to customer → write the spec" (slide trong video đăng ngày 01/11/2026).

Thêm vào đó, theo Maryam, trường đại học dạy những thứ như data structure, machine learning; các bootcamp thì đưa cho bạn kiểu "đây là React cho agent". Nhưng không ai thật sự dạy họ cách nói chuyện với business rồi lấy ra được các specification, và đó là đúng công việc chị vừa giải thích (theo video đăng ngày 01/11/2026).

## 13. Khi việc viết code biến mất, niềm vui còn không?

Một khía cạnh khác, theo Maryam: những người này chọn computer science, AI engineering, data science hay bất kỳ chương trình nào trong số đó vì họ yêu cái nghề (the craft). Giờ cái nghề và niềm vui đó coi như mất đi, vì AI đang tiếp quản. Chị nói chị đã có niềm vui đó suốt hơn 30 năm và giờ nó bị lấy khỏi chị; còn hãy tưởng tượng nó bị lấy khỏi bạn ngay từ ngày đầu tiên (theo video đăng ngày 01/11/2026).

Câu hỏi Maryam đặt ra trong video đăng ngày 01/11/2026: thứ bạn thích là lập trình, hay là giải bài toán mà bạn muốn giải trước khi bắt đầu gõ.

Rồi chị đặt câu hỏi: thứ bạn thật sự thích là lập trình, hay là giải quyết vấn đề? Ngay trước khi bắt đầu gõ, bạn muốn giải quyết điều gì? Theo Maryam, tất cả những khía cạnh, những khối việc mà bạn muốn giải quyết đó, bạn vẫn sẽ giữ được (theo video đăng ngày 01/11/2026).

Chị nói sẽ chỉ cho người xem cách giữ lại phần kỹ thuật: bạn sẽ học thêm phía business và vẫn giữ được phần kỹ thuật. Theo chị, trong tương lai, bạn đang ở cấp độ nào không quan trọng, nếu bạn đi theo con đường này (theo video đăng ngày 01/11/2026).

## 14. 12 layer của production AI agent

Con đường đó, theo Maryam, là các layer của production agent. Đích đến là gì? Một sản phẩm hoàn toàn sẵn sàng, đã được deploy và đã được đưa vào production. Chị nói đây là những bước chị biết chắc sẽ không thay đổi, vì các hệ thống này đã tồn tại từ 20 năm trước dưới những cái tên khác, và hệ thống sẽ giữ nguyên trong hàng trăm năm, trong khi công cụ thì thay đổi (theo video đăng ngày 01/11/2026).

Theo chị, hệ thống là thế này: bạn bắt đầu với business understanding, sang data understanding, rồi hiểu knowledge, rồi xem xét model, rồi context, semantic, và làm agent engineering. Sau đó bạn sang vùng production, nơi bạn làm loop engineering, evaluation engineering, harness engineering, infrastructure engineering và continual learning (theo video đăng ngày 01/11/2026).

![Slide 12 Layers of Production AI Agents: bảy khối xanh dương Layer 1 AI Agent Development và năm khối xanh lá Layer 2 Production Engineering](https://homus.dev/photos/EY-xc-Cyelk-1458.jpg)

Slide "12 Layers of Production AI Agents, two connected engineering layers": khối "AI Agent Development" gồm 1 Business Understanding tới 7 Agent Engineering, nối sang khối "Production Engineering" gồm 8 Loop Engineering tới 12 Continual Learning (slide trong video đăng ngày 01/11/2026).

## 15. Layer 1 đến 4: business, data, knowledge, model

**Business understanding.** Theo Maryam, ở bước này bạn luôn chuyển vấn đề của mình thành một mục tiêu AI đo lường được. Nó cho bạn thấy ở mức cao hơn người ta thật sự cần gì, dù bạn vẫn chưa biết điều đó có khả thi hay không (theo video đăng ngày 01/11/2026).

**Data understanding.** Ở bước này, chị nói bạn tìm hiểu business có loại thông tin, dữ liệu, văn bản, hình ảnh gì, rồi đối chiếu xem những thứ họ muốn có khả thi dựa trên dữ liệu họ có hay không (theo video đăng ngày 01/11/2026).

![Slide Production AI Agents: Layers 1-4 mô tả Business Understanding, Data Understanding, Knowledge Engineering, Model Engineering](https://homus.dev/photos/EY-xc-Cyelk-1552.jpg)

Slide "Production AI Agents: Layers 1-4, Understanding, Data & Intelligence": business understanding qua domain analysis, KPIs, requirements engineering, acceptance criteria; data understanding qua EDA, statistical profiling, data lineage, anomaly detection; knowledge engineering qua knowledge graph, ontology, embedding, RAG, entity resolution; model engineering qua benchmarking, fine-tuning (LoRA/QLoRA), quantization, inference optimization (slide trong video đăng ngày 01/11/2026).

**Knowledge engineering.** Theo Maryam, đây là chỗ mà những thông tin kia hiện chưa dùng được. Có rất nhiều dữ liệu, nhưng bạn nghĩ: mình cần các mối quan hệ. Chị lấy ví dụ road engineering: bạn cần biết con đường này nối với con đường kia trước khi có thể nói tới bảo trì hay chặn một con đường, vì điều đó ảnh hưởng rất nhiều. Đó là những việc bạn làm trong knowledge engineering, và theo chị, đó là lý do graph engineering, vốn đã tồn tại 20 năm, giờ lại được ưa chuộng: nó vẫn rất phù hợp (theo video đăng ngày 01/11/2026).

**Model engineering.** Maryam nói trước đây là khi chị làm các model machine learning hay deep learning, còn giờ là các model cho agent, tức các LLM. Rốt cuộc câu hỏi vẫn là: dùng model nhỏ hơn? Dùng model đã train sẵn? Dùng model fine-tune? Với model y tế, chúng ta muốn một model thật sự hiểu khái niệm của mọi thứ liên quan tới y khoa, và có thể các model generic không làm được; bạn cũng muốn biết tốc độ. Theo chị, đó là phần việc bạn làm, và nó vẫn y hệt như 20, 30 năm trước: hình dạng đã đổi nhưng cái nghề vẫn giữ nguyên (theo video đăng ngày 01/11/2026).

## 16. Layer 5 đến 8: context, semantic, agent, loop

**Context engineering.** Maryam hỏi: context engineering 20 năm trước là gì? Theo chị, đó là feature engineering, tức tất cả các biến đầu vào mà một model machine learning hay deep learning cần. Giờ chúng ta có context: chúng ta phải nói với LLM rằng đây là bài toán bạn đang giải, đây là tất cả tài liệu tôi có, đây là những thứ quan trọng với công ty. Cách đưa vào là qua context window, vì nó luôn là văn bản và hình ảnh. Nhưng rốt cuộc, bên dưới vẫn chỉ là thông tin (theo video đăng ngày 01/11/2026).

**Semantic engineering.** Sau context engineering, theo chị, bạn làm semantic engineering: đây là chỗ bạn muốn mỗi thuật ngữ và mỗi dữ liệu thật rõ ràng rằng chúng ta đang nói về các thuật ngữ đặc thù của lĩnh vực, nên chúng ta cần hiểu chúng (theo video đăng ngày 01/11/2026).

**Agent engineering.** Rồi mới tới agent engineering. Maryam lưu ý đây là bước thứ bảy: bạn đi qua rất nhiều bước trước khi tới phần orchestration các agent. Chị nói chị luôn nhấn mạnh rằng phải qua sáu bước mới tới phần lõi của agent, nghĩa là việc chuẩn bị và dữ liệu cực kỳ quan trọng để agent đạt được mục tiêu, tức sản phẩm mà bạn đang nói tới (theo video đăng ngày 01/11/2026).

**Loop engineering.** Theo Maryam, đây lại là thứ đã tồn tại suốt 30 năm và giờ mới được đặt tên. Nó có nghĩa là bạn muốn cải thiện agent theo một vòng lặp, và đó là việc model tự cải thiện (theo video đăng ngày 01/11/2026).

Hai so sánh Maryam đưa ra trong video đăng ngày 01/11/2026: context engineering là feature engineering của 20 năm trước, và agent engineering chỉ đến ở bước thứ bảy, sau sáu bước chuẩn bị.

## 17. Layer 9 đến 12: evaluation, harness, infrastructure, continual learning

**Evaluation engineering.** Maryam nói chị không cần phải nói với bạn rằng mọi thứ bạn làm, nếu không theo dõi, thì bạn sẽ không biết chất lượng và kết quả ra sao, bạn đã thành công hay chưa (theo video đăng ngày 01/11/2026).

**Harness engineering.** Tiếp theo là harness engineering mà chị gọi là "nổi tiếng", vì chúng ta có rất nhiều nút để bật và tắt trong môi trường của mình. Theo chị, chúng ta muốn có một kiểu versioning cho môi trường mà bạn đang thử nghiệm AI agent, cũng như trước đây với các model machine learning: tìm ra model tốt nhất và giữ lại nó, nhưng đồng thời track và trace được (theo video đăng ngày 01/11/2026).

**Infrastructure engineering.** Ở bước này, theo Maryam, bạn deploy bất cứ thứ gì bạn có vào một hệ thống IT. Dù là AWS hay Microsoft Azure, phần lớn trường hợp đó là một kiểu môi trường cloud. Nếu trong môi trường đó có Databricks, bạn phải xử lý tất cả các yêu cầu IT đi kèm. Bạn không làm việc tách biệt, build agent hay build bất cứ thứ gì AI rồi để nó trong một notebook, vì nó phải nằm trong một môi trường nào đó, và mọi tương tác đó cũng có thể hỏng (theo video đăng ngày 01/11/2026).

Chị tự hỏi: vì thế, phần này có bị tự động hoá không? Và tự trả lời: không, nó quá phức tạp, bạn vẫn cần sự giám sát của engineer (theo video đăng ngày 01/11/2026).

![Slide Production AI Agents: Layers 9-12 mô tả Evaluation, Harness, Infrastructure Engineering và Continual Learning](https://homus.dev/photos/EY-xc-Cyelk-1923.jpg)

Slide "Production AI Agents: Layers 9-12, Reliability, Production & Continuous Improvement": evaluation qua golden datasets, LLM-as-a-Judge, trajectory evaluations, adversarial testing, regression tests; harness qua execution sandboxes, tool permissions, policy enforcement, approval gates, runtime guardrails; infrastructure qua containerization, orchestration, observability, caching; continual learning qua production feedback, drift detection, error analysis, memory updates, model retraining (slide trong video đăng ngày 01/11/2026).

**Continual learning.** Bước cuối là thứ mới, gọi là continual learning: bạn có học từ các pattern, từ các vấn đề và lỗi mình đã gặp không? Theo Maryam, sửa một lỗi thì chỉ là sửa lỗi đó. Nhưng nếu bạn gặp lỗi đó 300 lần, bạn muốn quay lại và học từ pattern của dữ liệu đó. Chị lấy ví dụ agent y tế: nếu có chuyện dị ứng xảy ra và mọi người bị dị ứng đều nhận sai thuốc, thì phải có một kiểu sửa nào đó cho chuyện này (theo video đăng ngày 01/11/2026).

## 18. Công cụ cần học cho từng layer

Để đưa ra một roadmap dùng được, Maryam nói với mỗi layer, bạn cũng có các kỹ thuật cần học. Chị nói sẽ còn tiếp tục nhắc: bạn cần học SQL và Python. Theo chị, việc đó mất tối đa khoảng một tháng, mỗi tuần vài giờ, và nếu học xong, bạn sẽ hiểu code rất tốt ngay. Đúng là bạn không còn viết nó thường xuyên, nhưng bạn phải hiểu thứ được sinh ra. Chị ví nó như tới một đất nước mà không nói được tiếng Anh: Python là ngôn ngữ của AI (theo video đăng ngày 01/11/2026).

![Slide AI Agent Tools: Layers 4-6 với công cụ cho Model Engineering, Context Engineering, Semantic Engineering](https://homus.dev/photos/EY-xc-Cyelk-2223.jpg)

Slide "AI Agent Tools: Layers 4-6": Model Engineering (PyTorch, Hugging Face, PEFT, vLLM, MLflow, Ollama), Context Engineering (LangGraph, LlamaIndex, Redis, Zep, Mem0, pgvector), Semantic Engineering (spaCy, RDFLib, Neo4j, Protégé, Sentence Transformers, Pydantic), với dòng "Choose a focused stack. Master the engineering." (slide trong video đăng ngày 01/11/2026).

Các công cụ chị đọc lên, theo từng layer (video đăng ngày 01/11/2026):

- Data understanding: Pandas, PySpark và nhiều công cụ khác (theo video đăng ngày 01/11/2026).

- Knowledge engineering: làm RAG thì có Qdrant, làm graph engineering thì có Neo4j, còn Docling dùng để parse file PDF (theo video đăng ngày 01/11/2026).

- Model engineering: những thứ như PEFT và Ollama (theo video đăng ngày 01/11/2026).

- Context engineering: LangGraph, phần memory, Zep, Mem0 (theo video đăng ngày 01/11/2026).

- Semantic engineering: Pydantic, và cũng rất hay làm với graph như Neo4j (theo video đăng ngày 01/11/2026).

Với harness engineering, infrastructure engineering và continual learning, chị chỉ vào slide các kỹ thuật tương ứng. Slide "AI Agent Tools: Layers 10-12" ghi: harness engineering với Docker, Pydantic, OPA, NeMo Guardrails, Promptfoo, MCP; infrastructure engineering với Docker, Kubernetes, Terraform, FastAPI, OpenTelemetry, Grafana; continual learning với MLflow, Phoenix, Evidently, Hugging Face Datasets, PEFT, DVC (slide trong video đăng ngày 01/11/2026).

Với continual learning, theo Maryam, rất thường bạn có thể dùng bất cứ thứ gì từ machine learning. Chị kể trong một bài toán continual learning về năng lượng điện gió (wind turbine), chị đã dùng isolation forest cho anomaly detection; đó cũng là một phương pháp dùng để phát hiện tội phạm tài chính, hay ở những lĩnh vực hoàn toàn khác. Theo chị, bạn có thể dùng bất kỳ kỹ thuật nào để nhận ra các pattern (video đăng ngày 01/11/2026).

## Nguồn và liên kết

- Tên gốc: My EXACT 2027 AI Engineer Roadmap in the Era of AI Coding
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=EY-xc-Cyelk](https://www.youtube.com/watch?v=EY-xc-Cyelk)

- Kênh YouTube Dr. Maryam Miradi (Maryam Miradi): [youtube.com/channel/UCIQzTfzErmrixae2oFqRxyg](https://www.youtube.com/channel/UCIQzTfzErmrixae2oFqRxyg)

- Bài "The Rise of the AI Engineer" của swyx trên Latent Space (đọc ngày 05/11/2026): [latent.space/p/ai-engineer](https://latent.space/p/ai-engineer/)

- Docling, công cụ chuẩn bị tài liệu cho gen AI (đọc ngày 05/11/2026): [github.com/docling-project/docling](https://github.com/docling-project/docling)

- Qdrant, vector search engine (đọc ngày 05/11/2026): [qdrant.tech](https://qdrant.tech/)

- Neo4j (đọc ngày 05/11/2026): [neo4j.com](https://neo4j.com/)

- PEFT, Parameter-Efficient Fine-Tuning của Hugging Face (đọc ngày 05/11/2026): [github.com/huggingface/peft](https://github.com/huggingface/peft)

- Ollama (đọc ngày 05/11/2026): [ollama.com](https://ollama.com/)

- LangGraph (đọc ngày 05/11/2026): [github.com/langchain-ai/langgraph](https://github.com/langchain-ai/langgraph)

- Zep (đọc ngày 05/11/2026): [github.com/getzep/zep](https://github.com/getzep/zep)

- Mem0, memory layer cho AI agent (đọc ngày 05/11/2026): [github.com/mem0ai/mem0](https://github.com/mem0ai/mem0)

- Pydantic docs (đọc ngày 05/11/2026): [pydantic.dev/docs](https://pydantic.dev/docs/)

- pandas (đọc ngày 05/11/2026): [pandas.pydata.org](https://pandas.pydata.org/)

- PySpark (đọc ngày 05/11/2026): [spark.apache.org/docs/latest/api/python](https://spark.apache.org/docs/latest/api/python/)

Nguồn: https://homus.dev/talks/my-exact-2027-ai-engineer-roadmap-in-the-era-of-ai-coding · cập nhật 2026-11-05