The Broken Rung: How AI is Rebuilding Software Development from the Ground Up

1. Mở đầu: software developer từng là nghề "an toàn"

Speaker là Tom (Tomislav Tipurić), CTO và CEO của Nephos; anh coach mọi người về cách dùng artificial intelligence, các multi-cloud platform và những practice phát triển phần mềm hiện đại. Chủ đề: nấc thang đầu tiên của career ladder dường như đang bị gãy.

Rất nhiều người đang bàn tới vấn đề này: nếu không có junior thì mình lấy đâu ra senior? Nhưng theo Tom, chuyện còn nghiêm trọng hơn thế, và mọi người sẽ thấy lý do trong talk.

Anh bắt đầu từ một điều ai cũng đã hiểu: AI sẽ ảnh hưởng tới mọi vị trí, mọi vai trò, trong mọi ngành trên hành tinh này. Và nó đã đang làm vậy rồi. Tuy nhiên ngành phần mềm đặc biệt quan trọng, vì đây là một phần của IT mà dù có cuộc cách mạng nào xảy ra, từ cloud computing, virtualization, cho tới microservices trở về sau, software developer vẫn gần như an toàn. Mọi thứ thay đổi xung quanh họ. Ngành đã mất dần system administrator, rồi system engineer, rồi rất nhiều việc của network engineer và kiến trúc mạng biến mất theo cloud computing, hoặc ít nhất là mình tưởng vậy. Nhưng software engineer thì luôn an toàn.

Rồi đột nhiên, năm 2022 ChatGPT xuất hiện. Năm 2023 có Codex và một số ứng dụng khác, có GitHub Copilot, có Cursor, và mọi thứ thay đổi. Vậy đây là hype, là chuyện sắp xảy ra, hay là chuyện đã đang xảy ra rồi?

Anh đưa ra con số đầu tiên: 50% code được commit hiện nay đã do AI generate. Đây là số mới nhất: một nửa số dòng code đi vào giai đoạn commit bên trong repository thực chất là do AI tạo ra. Và phần lớn code đó là scaffolding, rất nhiều thao tác CRUD, những thứ mà trước giờ mình vẫn luôn tự động hoá ở một mức nào đó, hoặc cố tự động hoá, hoặc giao cho các engineer ở mức junior hay mới ra trường làm.

2. 50% code đã do AI viết, và hai thái cực cùng lúc

Trong 50% đó còn có rất nhiều unit test, loại test mà trước đây không phổ biến trong codebase như vậy. Tom thừa nhận: mình vẫn viết unit test khi buộc phải viết, nhưng chưa bao giờ viết cho xong hết mọi thứ. Giờ có AI thì mình làm được điều đó, và đó là chuyện tốt. Ngoài ra còn một số refactor, một số documentation.

Anh nhấn mạnh một điểm dễ bị hiểu sai: con số 50% này không phải tính trên bất kỳ đoạn code nào đi vào repo, trên bất kỳ branch nào. Nó nói về code đi vào production. Nghĩa là 50% số dòng code được viết cho production trong khoảng một năm qua thực chất là do AI viết.

Khi đã ở mức đó, mình có thể nói chắc rằng những ai vẫn nghĩ "AI trong software development là tương lai" đều sai hoàn toàn. AI trong software development là hiện tại, vì nó đã xảy ra, nó ở đó và sẽ không biến mất. Dù mình làm gì, nói gì, nó đã ở đó rồi. Nó làm tăng năng suất, hoặc ít nhất là management cảm nhận như vậy. Và khi management đã cảm nhận như vậy thì mọi chuyện sẽ vận hành theo cảm nhận đó.

Vấn đề tiếp theo: mình đang gặp hai thái cực cùng lúc. Thái cực thứ nhất là generative AI, agentic AI, gọi thế nào tuỳ bạn, đang thay thế những gì junior từng làm. Mọi bước đầu tiên của nghề giờ AI làm khá dễ dàng. Đó là tự động hoá, ở một đầu. Ở đầu kia là một chuyện hoàn toàn khác: dân chủ hoá software development. Vibe coding đã khiến bất kỳ ai trên thế giới cũng có cảm giác rằng chỉ cần mở Cursor, viết vài dòng, nhận về một ứng dụng, là mình bỗng thành software developer.

Anh kể chuyện em trai mình. Cậu làm marketing từ trước tới giờ, hồi cấp ba có học chút coding. Một tháng trước cậu khoe: "Tom, xem em build cái này nè. Em nối Zapier, nối HubSpot, nối mấy CRM khác, nối Mailchimp, tất cả vào với nhau. Em có một dashboard duy nhất để nhìn. Em tự build từ đầu, không cần biết code." Cậu gửi link, và Tom mở app ra.

3. Citizen developer, và "broken rung" nhìn bằng số

Kết quả: đó là một trong những app chậm nhất Tom từng thấy trong đời. Nhưng em anh có cảm giác mình biết code, và chuyện đó đang xảy ra thật.

Ở phía khác, ngoài kia có vô số nền tảng low-code, no-code. Một số người có thể đã nghe về Power Platform, PowerApps và những thứ tương tự. Chúng đang được tích hợp với LLM thông qua Microsoft Copilot, nếu nói về Microsoft stack, và các stack khác cũng vậy. Giờ đây các citizen developer trong tổ chức, những người không hề biết software development life cycle thật sự là gì, đang build app. Những app đó đơn giản hoá quy trình kinh doanh của họ, trở thành một phần của quy trình kinh doanh, và mọi người bên trong bắt đầu dùng chúng.

Vậy là software development đang bị kéo theo hai hướng: một mặt rất nhiều thứ được tự động hoá, mặt khác những người trước đây không build phần mềm thì giờ đang build, và sẽ build ngày càng nhiều. Tất cả dẫn tới chủ đề hôm nay: the broken rung, nấc thang bị gãy.

Chuyện này thấy rõ trên thị trường lao động. Từ 2023 tới nay, hiệu ứng cộng dồn của số vị trí junior developer bị giảm là hơn 60%. Số vị trí từng có năm 2023 giờ không còn nữa, và mức giảm là hơn 60%. Anh nói: bạn có thể bảo "ừ thì đó là một con số", có rất nhiều con số, và ở lề dưới slide có ghi nguồn của từng con số, mọi người cứ tự kiểm tra, "trust me, check it out on your own".

Nhưng kể cả không cần con số đó, thị trường vẫn cho thấy điều này. Nhìn vào sinh viên mới tốt nghiệp trong sáu tháng tới một năm gần đây: tỷ lệ thất nghiệp của computer science graduate (từ bachelor trở lên) là 6,1%. Computer engineer, có người vào nghề ngay sau cấp ba, có người có bằng sau đại học, là 7,5%. Bạn có thể nói: kinh tế đang xấu, thất nghiệp đang nhiều. Điều đó đúng. Nhưng mức trung bình quốc gia ở Mỹ cho mọi sinh viên mới tốt nghiệp là 4,5%. Computer science, "con bò thiêng" của mọi trường đại học, bỗng khó xin việc hơn cả người học triết hay lịch sử hay các ngành nhân văn khác. Đây là thực tế, số liệu là như vậy.

4. Năng suất: input tăng 50 tới 100%, outcome chỉ khoảng 10%

Vì vậy mình không thể nói "không đâu, junior rồi sẽ ổn, toàn là phóng đại". Không phải phóng đại. Số liệu nằm đó, mọi người tự chọn nguồn mà xem.

Vậy còn những hiệu ứng nào khác? Năng suất đang tăng vọt. Ai cũng năng suất hơn. Mình sản xuất nhiều hơn hẳn nhờ AI, giỏi hơn, nhanh hơn. Và đó là lý do 84% developer đang dùng hoặc dự định dùng AI trong thời gian tới. Con số này năm ngoái thấp hơn 8 điểm (khớp với Stack Overflow Developer Survey 2025), và mình đang dần chạm trần. Lúc nào cũng sẽ có một người cuồng tín tuyên bố "không, nhà tôi không bao giờ dùng AI", nhưng đa số mọi người đã sống cùng AI assistant. Dù là playbook nào, công cụ giúp bạn vibe coding kiểu Cursor, hay kiểu cộng tác như GitHub Copilot, đều không quan trọng. Chúng đều là công cụ giúp mình trong lúc thiết kế phần mềm, ứng dụng, hay bất kỳ sản phẩm phần mềm nào.

Rồi mọi người tuyên bố: "Tôi năng suất hơn 55%, nghiên cứu của tôi chứng minh điều đó dựa trên số PR tôi tạo ra và được merge vào code." Hoặc: "Tôi năng suất hơn 100%, gấp đôi trước đây, trong cách tôi code và giải quyết task được giao."

Vấn đề là: tất cả đều đúng, nếu bạn đo thuần phần generation, phần input đổ vào hệ thống. Nhưng khi đo outcome, output của cả quy trình, thứ bạn thật sự tạo ra, business value bạn mang vào quy trình, thì con số chỉ khoảng 10%.

Vậy 10% năng suất có tốt không? Chắc chắn là có. Có phải một bước đột phá không? Anh nghĩ là có. Nhưng mình vẫn chưa tới nơi. Điều đó có nghĩa là nếu phần input mạnh tới vậy mà mình không đạt được mức tăng tương tự ở đầu ra, thì hẳn đang có gì đó sai về bản chất trong quy trình.

Anh hỏi khán giả: bao nhiêu người đến từ software agency, làm phần mềm custom cho khách hàng? Anh đã thấy chuyện này xảy ra. Vì mình bắt đầu nói rằng mình năng suất hơn nhiều, khách hàng bắt đầu đặt câu hỏi.

5. Agency bị ép giá, outcome pricing và forward deployed engineer

Câu hỏi của khách hàng: "Nếu anh dùng AI để viết code, sao hoá đơn của tôi vẫn như cũ? Nếu anh nói anh năng suất hơn 50%, sao tôi không trả ít hơn 50%, hay ít hơn 30%? Chia phần lợi đi: 25% cho anh, 25% cho tôi."

Thế là thứ lẽ ra là một cơ hội nhỏ để agency hưởng lợi từ năng suất nhờ AI lại biến thành vấn đề, vì mức lợi thật chỉ có 10%. Trong khi cảm nhận của mọi người là 50%, và đó là mức giảm giá khách hàng đang đòi.

Vì vậy agency phải chuyển từ kiểu tính giá time and material sang outcome pricing: "Anh muốn feature này, đây là những gì cần làm, và đây là số tiền chúng tôi tính khi xong. Chúng tôi cam kết đúng hạn, đúng spec, nó sẽ chạy, sẽ hoạt động, và đây là những bài test nó sẽ vượt qua." Thay vì: "Đây là số man-hour chúng tôi sẽ bỏ ra, nếu bỏ ra nhiều hơn thì anh trả nhiều hơn." Đó là cuộc thảo luận các agency đang có với khách hàng, ít nhất là theo lời họ kể khi làm việc với anh. Và mình đã thấy tác động lên doanh thu của các agency.

Đó cũng là lý do thuật ngữ forward deployed engineer trở nên quan trọng hơn hẳn. Mình phải đổi cách làm việc với khách hàng phần mềm: trở thành một phần trong quy trình kinh doanh của họ, mang lại cho họ nhiều giá trị hơn là chỉ phần mềm.

Vấn đề tiếp theo là security. Tom nói: tôi biết developer ghét security. Không phải vì mình ghét nó, mà vì mình đã chịu khổ dưới tay những người trong phòng IT, những người phát laptop cho mình rồi chặn mình làm bất cứ việc gì. Vì đó là việc security phải làm: chặn bạn gây ra bất kỳ tác hại nào. Còn mình là developer. Mình muốn tạo ra thứ mới, muốn đổi mới, muốn làm những ứng dụng tuyệt vời, và muốn dùng mọi thứ trong tầm tay. Những NPM package có vấn đề gần đây đã đủ rồi, vậy mà cứ ai chặn là mình khó chịu, mình là vậy đó. Đó là khác biệt văn hoá giữa người làm security và developer. Và giờ mình bỗng phải bắt đầu làm việc cùng nhau, vì những con số sau đây.

6. The dark side: 44% code AI có ít nhất một lỗ hổng

44% toàn bộ code do AI generate mang ít nhất một lỗi security. Đó là rất nhiều code. Và nếu nhìn kỹ, có những vấn đề mình tưởng đã thuộc về lịch sử. Nhưng SQL injection vẫn tệ. Cross-site scripting vẫn tệ.

Vì sao? Vì cách các AI model được train: chúng được train trên code tồi. Code tốt thường nằm giấu đâu đó, còn code tồi thì ở khắp nơi. Tom lấy ví dụ Stack Overflow: khi bạn tìm lời giải cho một vấn đề, bao nhiêu lần lời giải đó đúng? Một, có khi hai. Còn bao nhiêu lời giải sai bạn sẽ gặp? 5, 10, 15, 20. Mà LLM là cỗ máy xác suất. Với chúng, một thứ lặp lại 10 lần quan trọng hơn một câu trả lời đúng duy nhất. Và điều đó được "nướng" sẵn vào code do AI tạo ra. Đó là nguồn gốc các lỗ hổng security.

Chưa kể tới việc ngày nay mọi công cụ mình dùng để làm việc tốt thì hacker cũng dùng để làm việc xấu. Và họ có lợi thế, vì họ gỡ được guardrail khỏi công cụ của họ. Trong khi mình phải bảo vệ từng cánh cửa đang mở trong source code, họ chỉ cần tìm ra một cánh cửa. Đó mãi là một cuộc chơi không công bằng. Vì vậy những cuộc thảo luận này mang tính sống còn.

Nếu bạn không verify output của LLM, không verify những gì team bạn đang generate bằng Claude Code hay bất kỳ công cụ nào bạn chọn, bạn sẽ gặp sự cố security, và nó tới sớm hơn bao giờ hết. Ba năm trước, thời gian để exploit một zero-day trung bình là gần một năm. Giờ chỉ còn vài giờ. Mình không còn thời gian để patch nữa. Mình phải đảm bảo code mình generate ra là secure ngay từ định nghĩa. Công cụ để làm việc đó đã có sẵn, bạn chỉ cần biết và dùng chúng.

Tất cả những điều trên dẫn tới thứ Tom gọi là synthetic debt crisis. Mình đã có technical debt; tám năm qua có vô số cuộc thảo luận về technical debt, về việc code không được viết đúng, không có architectural review, và tất cả những thứ đó. Giờ hãy nhân debt đó lên tám lần, vì lượng code được generate cho một task điển hình đã tăng gấp tám.

7. Synthetic debt crisis: technical debt nhân tám

Chuyện này rất logic nếu nhìn kỹ. Tôi viết code, Joe viết code, Anita viết code. Với AI, AI sinh ra cùng một bộ dòng code, hoặc những bộ tương tự, cho từng người trong chúng ta. Mình không nói chuyện với nhau, không review gì cả, cứ commit hết vào codebase. Và bỗng bạn thấy vô số đoạn trùng lặp bên trong codebase. Hệ quả là gì? Nếu một đoạn code có một lỗ hổng security, thì nó có mặt ở mọi chỗ AI đã chép ra, và đó là điều rất khó xử lý.

Tóm lại, đây sẽ là một chặng đường gập ghềnh cho tất cả những ai đang bước vào, hoặc đã bước vào, kỷ nguyên AI-assisted coding. Tom nói anh chưa thấy nhiều bài viết về chuyện này, nhưng nếu nhìn ra sau hậu trường một chút, đi xuống dưới năm hay mười bài đầu tiên trên Google Search, bạn sẽ thấy mọi người đang báo cáo điều đó. Họ báo cáo ngày càng nhiều lỗ hổng security trong code. Họ thấy code thiếu ổn định: 60% team báo code bất ổn hơn nhiều so với trước khi dùng AI.

AI lẽ ra phải giúp mình viết code tốt hơn, làm app tốt hơn. Thế mà mình đang làm ra những app tệ hơn bao giờ hết. Anh hỏi: mọi người có gặp chuyện này không? Dùng công cụ trong sáu tới tám tháng qua, thấy bao nhiêu bug ngoài kia? Không phải vì mọi người không quan tâm, mà vì review hết mọi thứ là rất khó. Mình đang bước vào giai đoạn review fatigue: chỉ bấm "yes, we want this", yes, yes, yes, rồi AI generate xong thì coi như tôi xong.

Và management không giúp gì. Họ ép mình làm nhiều hơn, sản xuất nhiều hơn. Kết quả là lỗ hổng security: hơn 45% team báo đã gặp một dạng lỗ hổng security nào đó trên đường đi.

Rồi tới "army of juniors". Lượng code được generate, những architectural pattern được dùng, những kiểu cấu trúc chương trình bên trong ngôn ngữ đều rất điên rồ. Nhìn vào code đó, bạn biết nó chạy, nhưng bạn không đời nào viết như vậy. Nó chỉ được generate ra thôi. Có vô số thứ như vậy: bạn thấy một vòng lặp lồng trong một vòng lặp, rồi nhận ra chỗ đó lẽ ra không cần vòng lặp nào cả.

8. "Army of juniors", review, compliance và citizen developer cần sandbox

Đoạn đó thật ra chỉ là một điều kiện. Nó vẫn chạy, nhưng tốn nhiều thời gian hơn hẳn. Rồi bạn nói: "AI thân mến, tối ưu cái này được không?" Và AI đáp: "Oh yes, of course sir, I'm sorry, you were right, cái đó làm khác được." Khán giả cười. Nhưng cuối cùng, nếu bạn không tự đặt câu hỏi đó thì chẳng ai làm cả. Vì vậy review là sống còn.

Một điểm nữa: tuỳ ngành mình đang làm phần mềm, mình sẽ áp các quy định nội bộ và compliance vào ra sao? Đó là những câu hỏi phải được đặt ra khi AI bước vào quy trình software development.

Và cuối cùng, citizen developer, như đã nhắc. Tác động của một người cụ thể, giả sử là CMO, chief marketing officer, tự build app có thể rất lớn lên cả tổ chức, vì đó là người ngồi cùng CEO mỗi ngày, và nếu anh ta muốn gì thì anh ta có được thứ đó. Là IT nội bộ, mình phải tìm cách govern tất cả những nền tảng citizen development đó, tạo sandbox cho họ, nơi họ có thể thử nghiệm app thoải mái. Nhưng khi họ muốn đưa app lên production, họ phải đi theo đúng quy trình mà mình đang đi khi đưa app lên production. Cuối cùng, mình phải tạo ra một pipeline.

Tom nói: "Okay, giờ tôi đã doạ các bạn một chút, hoặc làm các bạn mỉm cười vì các bạn vốn đã biết tình hình tệ tới mức này." Vậy mình làm được gì? Con đường tiếp theo là gì?

Silver lining thật sự lại đến từ một công ty mà ai cũng quên: IBM. Họ đã trải qua chuyện này. Năm 2023 họ dừng toàn bộ tuyển junior. Không một junior nào được tuyển suốt cả năm. Họ bắt đầu dùng AI trong practice phát triển phần mềm, trong cách họ làm sản phẩm, giải pháp và dịch vụ. Và họ đâm vào tường. Họ là những người đầu tiên thừa nhận điều đó, và đổi hoàn toàn cách tuyển, quay lại tuyển junior, thậm chí nhiều hơn bao giờ hết (xem IBM: The bottom rung returns as AI reshapes entry-level jobs và Bloomberg: IBM to triple entry-level US hiring). Nhưng họ tạo ra một khác biệt lớn trong cách tiếp cận vai trò: họ định nghĩa lại vai trò junior. Không còn kiểu "ngồi đó nghe các developer khác làm gì, thỉnh thoảng viết vài mẩu code CRUD, review cho người khác, viết documentation" nữa.

9. Silver lining từ IBM: định nghĩa lại vai trò junior

Thay vào đó, IBM nói với junior: "Không. Tôi sẽ dạy bạn cách dùng AI tool cho đúng. Tôi sẽ dạy bạn problem solving là gì, và cách hiểu khách hàng thật sự muốn làm gì. Tôi sẽ dạy bạn rất nhiều thứ khác nhau về IT, cùng với IT. Tôi sẽ cho bạn dùng AI để generate code, nhưng tôi cũng muốn bạn biết cách review code đó, cách viết test cho code đó, và code đó được định hình ra sao, trước cả khi bạn bắt đầu project đầu tiên. Chúng ta sẽ đi qua tất cả."

Nghĩa là: "Tôi bắt đầu tạo ra những junior giống senior ngay từ đầu. Tôi sẽ không dạy bạn code trước, rồi theo thời gian bạn mới dần được tiếp xúc với khách hàng và hiểu business. Tôi bắt đầu bằng chính những thứ đó, và dẫn bạn đi suốt chặng đường."

Tom nói anh không khẳng định cách này hoàn hảo. Nhưng trường hợp IBM đã chứng minh đây là việc mình làm được. Mình có thể tái phát minh nấc thang đầu tiên đó, có thể thay đổi hình dạng của career ladder.

Việc thứ hai mình có thể làm là thay đổi cấu trúc team. Truyền thống là: một lead developer, dưới đó vài senior dev, rồi tới một đội quân junior developer. Bạn có thể gọi tên khác, có thể có tầng ở giữa như mid-level, thuật ngữ mỗi nơi mỗi khác, nhưng ai cũng có kiểu cấu trúc này. Giờ mình cần một cách tiếp cận hoàn toàn khác: vẫn có các tầng trên career ladder, nhưng tất cả đều là augmented engineer. Nghĩa là tất cả đều là AI professional: họ dùng AI trong công việc hằng ngày, với công cụ phù hợp tuỳ vai trò và quy trình. Và họ đều là một phần của cả hệ sinh thái, để mình bắt đầu gom các practice lại: AI làm được gì, AI được govern ra sao, ngay từ giai đoạn đầu khi engineer bước vào hệ thống.

Anh đoán trước phản bác: "Tom, vậy nghĩa là một người chưa từng tự viết một vòng for, tôi cứ để AI viết hộ họ à?" Câu hỏi ngược lại là: vậy tại sao bạn lại từng tuyển vào vị trí developer một người chưa từng viết vòng for?

10. Từ kim tự tháp sang đội hình kim cương: augmented engineer

Bạn có thể cãi: "Nhưng đó là những người mình tuyển được." Đúng, nhưng hãy nhìn những con số từ các trường đại học hiện nay. Bạn sẽ có quyền lựa chọn, vì nguồn người nhiều hơn nhu cầu. Nên đây là cơ hội tốt cho mọi bên. Ai muốn vào ngành phần mềm sẽ không chọn con đường này chỉ vì nó dễ. Họ chọn vì họ có đam mê. Và nếu có đam mê, họ sẽ học nền tảng trong những năm đại học, những năm định hình, có khi từ cấp ba, có khi từ tiểu học, như chính Tom. Khi tới nơi làm việc, họ sẽ biết những nền tảng mà AI đang làm thay họ, và bạn có thể bắt đầu dạy họ những thứ khác, để họ trở thành tài sản giá trị hơn cho công ty và cho mọi khách hàng của bạn.

Còn với chuyện citizen developer thì áp dụng thế nào? Và không chỉ citizen developer. Còn có citizen data scientist, citizen automator dùng Power Automate và những công cụ tương tự, citizen data scientist dùng Tableau, Looker trong thế giới Google, hay Power BI trong thế giới Microsoft. Tất cả đều là những người đang thay thế một loại engineer mà trước đây mình từng có: data scientist, data engineer; automation engineer, hay integration engineer; và developer. Giờ mình có những "công dân", hay nói cách khác là những người chuyên nghiệp bình thường trong vai trò của họ, muốn tự động hoá công việc. Họ không muốn gọi IT trung tâm cho việc đó, và họ làm được. Song song đó mình có các professional developer.

Điểm quan trọng là mình cần tạo ra một Center of Excellence, nơi đặt đúng các policy, đúng governance, đúng hạ tầng, để IT trung tâm, với vai trò engineer, enable được tất cả những người khác đang tác động lên phần mềm, giúp họ làm việc đó đúng cách.

Đã có công ty làm vậy. Tom có vài khách hàng như thế. Một công ty năng lượng lớn ở Florida đang làm đúng việc này: họ dạy nhân sự ở nhiều phòng ban, HR, finance, retail, bất kỳ đâu, cách code, hay cách tạo app và agent bằng các công cụ low-code, no-code. Nhưng ai dẫn dắt? IT trung tâm.

11. Fusion team và Center of Excellence cho citizen developer

IT trung tâm là người đặt governance, đặt các biện pháp security, phổ biến pipeline, và hướng dẫn cách đi từ sandbox lên môi trường production, cần những gì.

Cuối cùng, vẫn sẽ có những kỹ năng được cần tới. Tom nói: mình nhìn vào chính mình như những người làm nghề, và tôi còn ít nhất 25 năm nữa mới nghỉ hưu. Vậy kỹ năng nào sẽ cho phép mình tồn tại sau AI?

Anh nghĩ ai từng code cùng AI đều đã biết điều này. Thứ nhất, context articulation không thể do AI agent làm. Đó là việc của mình. Mình hiểu context. AI agent có thể hiểu sự tương đồng giữa hai thứ trong context, có thể đoán từ nào sẽ tới sau những keyword mình vừa gõ. Nhưng chỉ mình mới hiểu context thật sự là gì: context rộng, không phải context của một dòng code cụ thể.

Thứ hai, pattern recognition. AI giỏi pattern recognition. Mình giỏi hơn, vì mình hiểu những gì đang diễn ra trên thế giới, hiểu tất cả những điều đó tác động gì tới khách hàng. Đó sẽ luôn là phần mình nắm trong câu chuyện.

Thứ ba, orchestration của những hệ thống này. Bạn có thể cho một thứ tự động điều phối một phần hệ thống, nhưng xây dựng cả thực tại xung quanh nó thì luôn là việc của mình. Kể cả khi mình dùng 10.000 agent, mình vẫn phải nghĩ ra cách các agent đó nói chuyện với nhau, trao đổi thông tin, quy trình chạy tiếp ra sao, và feedback quay về thế nào.

Và cuối cùng, strategic review, cái nhìn chiến lược, là của mình. Mình biết doanh nghiệp vận hành ra sao, chỗ nào họ thật sự tạo khác biệt, policy security, policy governance và mọi policy khác nào phải áp dụng để mọi thứ chạy đúng.

Rồi tới verification architecture, một cách tiếp cận mới mà nhiều người đang khuyến nghị cho mọi dòng code đi vào hệ thống, vì cứ ba đoạn code AI thì có một đoạn mang lỗ hổng. Mỗi dòng code phải được tạo ra, được generate, được dẫn dắt bằng ví dụ, bằng những skill đã được chứng minh, những prompt đã được chứng minh, nằm ngay trong repository cùng với spec; được test ở cả unit test, integration test và mọi loại security test liên quan; và trở thành một phần gắn liền của cả quy trình đầy đủ.

12. Bốn kỹ năng bền vững trong thời AI

Slide của phần kỹ năng gom bốn ý Tom vừa nói thành một competency framework. Mỗi kỹ năng đi kèm một sự chuyển vai ("from ... to ...") và một primary output cụ thể, tức thứ bạn giao ra hằng ngày.

Điểm đáng chú ý là cả bốn kỹ năng đều không phải "viết code nhanh hơn". Chúng đều nằm ở phía trước (nói rõ mình muốn gì), ở phía trên (thiết kế hệ thống, điều phối agent), hoặc ở phía sau (kiểm lại những gì AI tạo ra). Đây cũng là nối tiếp tự nhiên của phần IBM: junior kiểu mới được dạy ngay chính bốn thứ này.

13. Verification architecture: trust, but verify in layers

Tom nói rõ: anh không chỉ nói về static testing và dynamic testing của code. Anh còn nói tới agentic testing: dùng LLM-as-a-judge để chấm code của mình, và dùng những công cụ chủ động tìm cách exploit các lỗ hổng tiềm ẩn trong code. Tất cả phải pass trước khi ship sản phẩm cuối cùng. Hãy đối xử với code do AI generate giống hệt như code tới từ một bên ngoài mà bạn không quen.

Để lại cho mọi người một điều, Tom đưa ra "developer roadmap 2026". Nếu bạn chưa bắt đầu với tất cả những thứ này, có vài việc bạn có thể làm ngay. Bắt đầu nhỏ: bắt đầu build agent của riêng mình ngay hôm nay. Và anh không có ý nói dùng công cụ low-code, no-code. Hãy mở một framework ra, dù đến từ Google, Microsoft hay Anthropic, không quan trọng. Bắt đầu build những hệ thống đơn giản, tìm hiểu nó chạy thế nào, tìm hiểu retrieval-augmented generation là gì và cách làm nó, hiểu MCP, hiểu A2A protocol, hiểu tất cả những gì đang diễn ra xung quanh, và build hệ thống agentic đầu tiên của bạn. Cuối cùng, hiểu cách evaluate hệ thống đó. Đó là thứ sẽ tạo khác biệt, và là thứ sẽ làm nên bạn.

14. Roadmap 2026 cho developer và ba việc cho sáng thứ Hai

Tom kết bằng ba việc để làm vào thứ Hai, "vì hôm nay là thứ Sáu".

Một: nếu bạn đang ở vị trí có thể thay đổi cách công ty tuyển người, thay đổi cách các vai trò được tạo ra, thì hãy thay nấc thang đó, đừng bỏ nó. Tìm cách tạo ra những kiểu engineer mới, những người sẽ trở thành lực lượng lao động tiếp theo của bạn.

Hai: vẽ lại org chart. Cái cũ chỉ là một kim tự tháp. Mình cần một hình dạng khác, và hình kim cương thì tốt, Tom đùa, "kim cương là thứ ai cũng thích". Nhưng mình cần định khung lại cách mọi người vận hành bên trong team. Có thể sẽ có những team nhỏ hơn, nhiều team nhỏ hơn, cùng tạo ra phần mềm từ nay về sau.

Ba, cũng là điều cuối cùng: verification, nhìn từ bất kỳ góc nào, không còn là tuỳ chọn. Nó là bắt buộc, và phải trở thành một phần gắn liền của mọi phần mềm.

Anita cảm ơn Tom, và session khép lại.