Salesforce dùng Claude Code thế nào: effective output, maturity curve và skill marketplace

1. Claudeforce và một codebase hàng chục năm tuổi chuyển sang headless

Đây là một buổi Office Hours trên kênh Claude, đăng ngày 06/11/2026. Boris Cherny dẫn buổi trò chuyện, ngồi cùng hai lãnh đạo kỹ thuật của Salesforce: Muralidhar Krishnaprasad (Boris gọi anh là MK) và Richard Pack. Theo trang Office Hours của Claude (đọc ngày 06/11/2026), MK là President và CTO, còn Richard là Distinguished Architect tại Salesforce; theo mô tả video đăng ngày 06/11/2026, chủ đề là cách Salesforce đưa Claude Code tới hàng nghìn kỹ sư.

Ngay đầu video, MK nói: mọi ứng dụng mới, mọi UX mới mà bạn thấy ở Dreamforce có lẽ đều có ít nhiều ảnh hưởng của Claude trong đó (theo MK, video đăng ngày 06/11/2026).

Câu hỏi đầu tiên của Boris: có những ví dụ nào về sản phẩm hay feature mà team đã ship, thứ mà một năm trước, có lẽ là ở Dreamforce năm ngoái, đơn giản là không thể làm được trước khi có Claude Code (câu hỏi trong video đăng ngày 06/11/2026)?

MK trả lời: anh nghĩ là rất nhiều. Toàn bộ Claudeforce có được là nhờ headless. Như mọi người biết, Salesforce đã tồn tại hàng chục năm, nên không phải thứ gì cũng có API. Vì vậy anh và đồng nghiệp ở Salesforce đã thử biến tất cả thành headless. Theo MK, việc biến mọi ứng dụng của Salesforce thành headless lẽ ra sẽ là một project kéo dài sáu tháng hoặc một năm: phải đi qua từng trang một, nhìn vào các API, xem còn thiếu chỗ nào (theo MK, video đăng ngày 06/11/2026).

Thay vào đó, anh và nhóm làm xong trong vòng vài tuần và vài tháng. Tính tới lúc quay video (đăng ngày 06/11/2026), theo MK, Salesforce đã đạt khoảng 80, 90% độ phủ API (API coverage) cho tất cả các cloud, trong vòng chưa tới vài tháng, và không cần cuộc họp nào giữa các team. MK nói đó là một trong những khoảnh khắc "wow". Hãy tưởng tượng: đây không phải code mới, mà là code đã có từ hàng chục năm, vậy mà vẫn làm được việc đó. Anh thấy chuyện này khá tuyệt vời (theo MK, video đăng ngày 06/11/2026).

MK nói còn rất nhiều ví dụ như vậy: mọi ứng dụng mới, mọi UX mới mà bạn thấy ở Dreamforce có lẽ đều có ít nhiều ảnh hưởng của Claude trong đó (theo MK, video đăng ngày 06/11/2026).

2. Đo ROI bằng "effective output"

Boris hỏi tiếp: đó có phải cách Salesforce nghĩ về ROI không? Theo những gì anh nghe, bạn có một project và giờ có thể build nó nhanh hơn nhiều; hoặc bạn có một project và giờ cần ít người hơn; vậy là team có thông lượng (throughput) lớn hơn nhiều. Ngoài ra Salesforce còn nghĩ về ROI theo những cách nào (câu hỏi của Boris, video đăng ngày 06/11/2026)?

MK nói từ góc độ coding, đây là một chuyện khó. Anh và đồng nghiệp đã tranh luận ROI nghĩa là gì: làm sao biết nó tốt hơn, nhiều hơn? Nó không thể chỉ là số dòng code, vì như vậy người ta cứ việc thêm thật nhiều comment (theo MK, video đăng ngày 06/11/2026).

Salesforce đã làm việc với các nhà nghiên cứu ở Stanford để tạo ra một thứ gọi là "effective output". Theo MK, đó là một điểm số cố gắng trả lời: đoạn code đang được tạo ra này là gì, nó tốt tới đâu, hiệu quả tới đâu? Điểm sẽ thấp nếu thay đổi chỉ là vài sửa đổi đơn giản hay thêm comment, và cao hơn nếu thay đổi thật sự sửa logic hoặc tạo ra thứ mới (theo MK, video đăng ngày 06/11/2026).

MK nói chỉ số này cực kỳ hữu ích với Salesforce, vì nhờ nó anh và đồng nghiệp nhìn được xem con số đã thay đổi thế nào khi dùng AI. Ngoài ra còn có chỉ số đô la trên mỗi effective output (dollar per effective output): nhờ đó Salesforce thật sự thấy được một cách đo đếm được mình đang làm gì, có đang tạo ra khác biệt (moving the needle) hay không. Theo MK, con số đó đã tăng khoảng 2x với Salesforce, một mức khá lớn (theo MK, video đăng ngày 06/11/2026). Mô tả video đăng ngày 06/11/2026 ghi rằng Salesforce đã tăng gấp đôi effective output.

3. Tìm chỉ số đúng cho từng function

Theo MK, tính tới lúc quay video (đăng ngày 06/11/2026), Salesforce đang cố tìm ra chỉ số đúng cho tất cả các function khác ngoài coding. Đo nó thế nào? Được rồi, họ làm tốt hơn, nhưng "tốt hơn" nghĩa là gì? Họ có đóng được nhiều việc hơn không? Họ có xử lý được nhiều case hơn không (theo MK, video đăng ngày 06/11/2026)?

Vì vậy với mỗi function, Salesforce đang cố tìm chỉ số hợp lý cho function đó, rồi so trước và sau (before and after) để thấy ROI. Boris chen vào: trước và sau, kiểu như khi đưa agent vào hay thay đổi workflow. MK nói thêm: hay khi thay đổi tổ chức (video đăng ngày 06/11/2026).

MK nói thêm: Salesforce cũng biết mọi người đang dùng gì, đang tiêu thụ bao nhiêu xét về token. Rồi anh và đồng nghiệp nhìn vào trước và sau để xem có khác biệt đáng kể (material difference) hay không. Nếu không thì tại sao? Có phải vì bạn đang dùng sai cách, hay đơn giản nó không phải công cụ phù hợp cho việc đó? Là vì điều gì (theo MK, video đăng ngày 06/11/2026)?

4. Agent maturity curve: đẩy kỹ sư lên P3 và P4

Boris đề nghị MK kể Salesforce dùng Claude Code thế nào và đã mở rộng nó ra sao trong năm vừa qua (câu hỏi trong video đăng ngày 06/11/2026).

MK nói Salesforce dùng Claude Code cho gần như toàn bộ vòng đời PDLC, anh sửa lại là SDLC. Ban đầu mọi người làm đủ thứ, rồi Salesforce bắt đầu đưa thêm cấu trúc vào. Một trong những việc lớn, theo anh là làm cùng cả phía của Boris (anh nói "with you folks as well"), là tạo ra một đường cong trưởng thành (maturity curve), đường cong trưởng thành về agent (agentic maturity curve) (theo MK, video đăng ngày 06/11/2026).

Lý do: Salesforce nhận thấy kể cả sau tất cả nỗ lực thúc đẩy, mọi người vẫn dùng nó cho những task rất cấp thấp, chưa thật sự vượt qua được khoảng cách (jumping the chasm) để agent làm việc cho mình. Trong khoảng một hai tháng, Salesforce đã đẩy được một lượng rất lớn kỹ sư từ chỗ chỉ làm những việc cơ bản lên P3 và P4, tức là thật sự dùng agent, một cách code kiểu agentic. MK thấy thay đổi đó khá ngoạn mục (theo MK, video đăng ngày 06/11/2026).

Trên tất cả các stack, theo MK, Salesforce thấy rõ output tăng 2x, và chất lượng còn cao hơn: không phải gấp đôi số bug hay gấp đôi số vấn đề (theo MK, video đăng ngày 06/11/2026).

Boris hỏi: các bước trong thứ bậc này là gì? Nó vận hành ra sao? Một kỹ sư đi từ nấc thứ nhất lên nấc thứ hai thế nào (câu hỏi trong video đăng ngày 06/11/2026)?

5. Các nấc trên đường cong: từ một câu lệnh tới autonomy

Richard trả lời. Ở nấc đầu, bạn chỉ có những câu lệnh đơn giản (simple utterances), và đó là chỗ ai cũng bắt đầu: gõ vào Claude Code kiểu "đi làm cái này", nhưng không biết "tốt" trông như thế nào, và không diễn đạt "tốt" trông như thế nào. Claude Code xử lý được một số task đơn giản hơn. Nhưng khi đi vào những việc dài hơi hơn (long horizon), những câu hỏi dài hơi hơn, họ sẽ thấy nó không đạt, vì họ không diễn đạt trong câu lệnh thế nào là tốt, thế nào là tệ, và không dựng một plan đầy đủ (theo Richard, video đăng ngày 06/11/2026).

Theo Richard, các bước trên đường cong là những gì bạn nên nghĩ tới. Tiếp theo là teams và subagent, cách để harness giúp bạn điều phối việc chia nhỏ các phần việc chạy song song (decomposition of parallel work), quản lý các worktree, và thật sự đẩy mức song song lên cao (theo Richard, video đăng ngày 06/11/2026).

Cuối đường cong là autonomy và automation: bạn điều khiển tất cả các agent này, quản lý các workflow xuyên suốt các task của SDLC. Ví dụ Richard đưa ra: một test fail trong CI/CD, một agent sẽ nhận việc đó và sửa test fail, dù lý do là gì; rồi một agent khác nhận phần code review và merge thay đổi. Đó là đủ loại task khác nhau trong automation (theo Richard, video đăng ngày 06/11/2026).

Richard nói Salesforce bắt đầu với tất cả mọi người ở nấc đầu tiên, nhưng tính tới lúc quay video (đăng ngày 06/11/2026), đã có hàng nghìn người ở chế độ autonomous này (theo Richard, video đăng ngày 06/11/2026).

6. Enablement: demo trực tiếp và dữ liệu thật

MK nói thách thức lớn hơn còn nằm ở enablement: giải thích được rằng lên P3 hay P4 không phải một trò chơi có tổng bằng không (zero-sum game), mà thật sự là bước vào một thế giới mới trong cách dùng agent. Theo anh, đó là một việc enablement lớn và cũng là bài học cho tất cả mọi người (theo MK, video đăng ngày 06/11/2026).

Boris hỏi: Salesforce tiếp cận chuyện đó thế nào? Có tiếng trả lời: cảm hứng và dữ liệu thật (inspiration and real data) (video đăng ngày 06/11/2026).

Theo Richard (video đăng ngày 06/11/2026), có rất nhiều người demo cách họ làm việc: "đây là cách tôi làm, giờ tôi sẽ giải một vấn đề, và giải ngay tại chỗ". Mọi thứ rất, rất cởi mở, nhiều người khác nhau cho thấy phiên bản của riêng mình.

MK nói thêm: cloud nào rồi cũng có một kiểu đổi mới tạo ra bằng agent, thứ lẽ ra mất nhiều tháng mà họ làm được trong vài tuần. Đó là những sản phẩm thật, đang ship, những thứ được công bố ở Dreamforce. MK nghĩ điều đó cũng giúp rất nhiều để mọi người thấy: à, thứ này chạy được thật, nó thật sự hữu ích và có thể tạo ra khác biệt (theo MK, video đăng ngày 06/11/2026).

MK kể về một kiến trúc sư (architect) trong team. Chị nói bình thường chị phải mất vài ngày nếu cần hiểu một đoạn code mới, vì phải nói chuyện với ba, bốn team khác nhau. Chỉ riêng việc agent loại bỏ được những cuộc họp để hiểu code của người khác đã là một thay đổi rất lớn với họ (theo MK, video đăng ngày 06/11/2026).

Điều thứ hai, tự phát hơn, theo MK là chuyện incident: mọi người dành rất nhiều thời gian cho incident, và việc có agent đưa cho họ đúng thông tin là một làn sóng ủng hộ lớn nữa từ bên dưới (groundswell) (theo MK, video đăng ngày 06/11/2026).

Có tiếng nói tiếp: tính tới lúc đó, team nào cũng có agent xử lý incident (incident resolving agent) của riêng mình (video đăng ngày 06/11/2026).

7. Agent xử lý incident và chín team không bị đánh thức

Richard kể anh từng lướt qua một thread trên Slack về một incident. Service bên ngoài (outer service), nơi request đi tới, bị page, nhưng thật ra lỗi nằm ở một trong các service bên trong (inner service). Agent chỉ nói: đây là nguyên nhân gốc (root cause), đây là team phụ trách, tôi đã tạo page cho họ, ta sẽ chuyển incident sang đó; còn đây là người liên hệ (POC), cứ nhắn Slack cho họ (theo Richard kể, video đăng ngày 06/11/2026).

MK chen vào: hãy tưởng tượng lẽ ra đã có chín team bị đánh thức, và câu trả lời là: không phải bên tôi, sang team kia đi. Theo MK, đó là chuyện kỳ diệu; là một kỹ sư, bạn sẽ thốt lên "wow" (theo MK, video đăng ngày 06/11/2026).

8. Một marketplace cho skill, có eval đi kèm

Boris hỏi: vậy là các anh chỉ bảo mọi người "hãy nghĩ ra ý tưởng hay, post demo lên kênh nào cũng được" thôi sao (câu hỏi trong video đăng ngày 06/11/2026)?

Richard kể một bộ công cụ (suite) của Salesforce ban đầu chỉ là một ý tưởng: làm sao lấy tất cả các skill mà mọi người đang tạo ra và chia sẻ chúng. Ý tưởng ban đầu là: một marketplace sẽ trông thế nào? Có thể làm eval cho các skill này để cho thấy hiệu quả của chúng không? Có thể làm một online eval để replay lại các session (with or without), và có thể để Claude gợi ý cải tiến cho skill, để skill tiết kiệm token hơn, hay đi tới kết luận nhanh hơn, hay bất kỳ thay đổi nào khác không (theo Richard, video đăng ngày 06/11/2026)?

Từ đó, theo Richard, nó lớn dần thành một "uber skill marketplace", nơi Salesforce cho thấy được các skill được chia sẻ thật sự có giá trị với kết quả. Nó là một phần trong engineering harness của Salesforce, và là cách để nhìn thấy không chỉ các task coding mà cả những phần khác nhau của SDLC đang được tự động hoá, cách thiết kế workflow (theo Richard, video đăng ngày 06/11/2026).

Richard nói nó cũng cho phép làm phần thứ bậc: có những skill ở mức dùng chung cho toàn bộ engineering, có những thứ ở mức team, ở mức scrum team nhỏ nhất, đủ cả (theo Richard, video đăng ngày 06/11/2026).

Theo Richard, Salesforce có hàng nghìn repo (tính tới video đăng ngày 06/11/2026). Nên nếu muốn dân chủ hoá việc sửa một con bug ở bất kỳ đâu trong codebase, bạn phải biết: tôi sẽ lấy những repo này, đây là phần API (API surface area) tôi muốn nhắm tới. Rồi tôi dùng workflow nào để thật sự xử lý một codebase mà tôi chưa từng làm, và tạo ra một PR có chất lượng (theo Richard, video đăng ngày 06/11/2026).

9. Guardrail: lượng code gần gấp đôi, bug lại ít hơn

Boris tóm lại: vậy là các anh để đổi mới diễn ra từ dưới lên (bottoms up), rồi khi thấy nó bắt đầu chạy được thì giúp nó scale. Anh hỏi: cần thêm những guardrail nào (câu hỏi của Boris, video đăng ngày 06/11/2026)?

Richard nói có lẽ khía cạnh quan trọng nhất mà Salesforce phải nhìn vào là chất lượng: tiếp cận khoa học hơn trong việc đánh giá khả năng và tính hữu ích của một thứ trong những bối cảnh khác nhau. Theo anh, nó giống như đơn giản là trò chuyện giữa người với người, để hiểu họ đang cố đạt được gì, và họ nghĩ giá trị (value proposition) của thứ mình làm là gì. Rồi khi họ chia sẻ nó ra, phải đảm bảo những developer khác thật sự đạt được giá trị đó (theo Richard, video đăng ngày 06/11/2026).

MK nói chuyện này trở nên đặc biệt cấp thiết vì chỉ trong vài tháng gần đây (tính tới video đăng ngày 06/11/2026), kể từ khi Salesforce thúc đẩy làm nhanh hơn, tốt hơn, lượng code của Salesforce đã gần như tăng gấp đôi. Rủi ro lúc nào cũng có là: vậy có phải sẽ gấp đôi số bug, gấp đôi số case không (theo MK, video đăng ngày 06/11/2026)?

May mắn là, theo MK, Salesforce thấy điều đó đã không xảy ra: con số thấp hơn rất, rất nhiều. Tính trung bình, số bug trên lượng code được tạo ra thật ra còn ít hơn, trong khi lượng code tăng vọt. Và đó là nhờ tất cả các guardrail mà Richard vừa nói: đảm bảo có cơ chế kiểm soát và cân bằng (checks and balances) với những gì mọi người làm, đảm bảo cả các cơ chế truyền thống lẫn các cơ chế mới đều giữ vững về chất lượng của code (theo MK, video đăng ngày 06/11/2026).

10. Bộ benchmark để replay và các task "fail to fail"

Boris hỏi: với ai đang nghe và muốn làm lại bài tập này, họ làm thế nào? Chẳng lẽ đi qua từng commit và gắn nhãn "cái này có phải bug không, cái này có phải bug không"? Làm sao để định lượng được theo cách này (câu hỏi trong video đăng ngày 06/11/2026)?

Richard trả lời: ở Salesforce mọi thứ đều đã được gắn nhãn sẵn, và ai cũng theo cùng một quy trình SDLC chuẩn. Mọi người dùng hệ thống ticket và mọi thứ được gắn nhãn nhất quán, nên đã có một bộ dữ liệu khá được chọn lọc để bắt đầu, và tất cả đều liên kết tới các PR (theo Richard, video đăng ngày 06/11/2026).

MK nói thêm: một việc lớn khác mà Richard và team đã tạo ra là một bộ benchmark eval. Giả sử ai đó muốn thử skill mới, hay muốn thử một model mới, Salesforce muốn thử và hỏi: ROI của model này là bao nhiêu? Nếu có thể mô phỏng với tất cả những thứ này: model đó sẽ chạy thế nào, chi phí là bao nhiêu, tốt hơn hay tệ hơn? Theo MK, việc đó rất, rất hữu ích với Salesforce (theo MK, video đăng ngày 06/11/2026).

Richard nói tiếp: thay đổi model đó mở khoá được frontier nào, giờ ta lấy được gì từ model này? Tất cả các task ngắn và dài hơi (short and long horizon) trong PDLC mà Salesforce đã tạo benchmark, anh và nhóm chỉ việc replay chúng. Thêm vào đó, thứ mới mà nhóm vừa bổ sung là "fail to fail": những task mà các model liên tục thất bại, kiểu những task dài hơi, để khi thấy chúng bắt đầu pass, nhóm sẽ nói: đó là lý do ta nên chọn model này. Theo Richard, giờ có cả loạt việc nhóm có thể làm để nắm bắt những khả năng đó (theo Richard, video đăng ngày 06/11/2026).

11. "Autonomy without validation is confidence theater"

Boris nhắc tới một câu nói của Richard: "autonomy without validation is confidence theater" (tự động mà không kiểm chứng thì chỉ là diễn kịch tự tin). Anh hỏi: Richard bắt một agent đưa ra bằng chứng công việc (proof of work) gì trước khi tin nó? Và chuyện đó có giống nhau cho việc coding và việc không phải coding không (câu hỏi trong video đăng ngày 06/11/2026)?

Richard nói anh cố tìm một số tiêu chí khách quan để đo các task anh đã giao: đây là "tệ" trông như thế nào, đây là "tốt" trông như thế nào (theo Richard, video đăng ngày 06/11/2026).

Theo Richard, "tệ" sẽ là kiểu một negative test case: bạn có làm hỏng thứ gì khác không? Khi tôi bảo bạn tạo một schema mới, bạn có thêm field vào một entity đã có không? Bạn có động vào bất cứ thứ gì trong một schema đã có không? Tức là anh chỉ tìm những tiêu chí chấm được một cách khách quan, những thứ mà bình thường anh vẫn tự tìm. Trong output có những đặc điểm (feature) nào cho thấy chất lượng, hay cho thấy thất bại (theo Richard, video đăng ngày 06/11/2026)?

Rồi thay vì chỉ bảo agent tự review chính nó, Richard hỏi: bạn có đi tìm các đặc điểm đó không? Cho tôi xem bằng chứng của các đặc điểm. Cho tôi xem bằng chứng của các đặc điểm tiêu cực (theo Richard, video đăng ngày 06/11/2026).

Boris chen vào: vậy là chỉ cần đưa ra nguồn. Có tiếng đáp "Yeah". Richard nói tiếp: hãy cho thấy công việc của bạn (show your work). Lập một ma trận (matrix) tất cả các đặc điểm bạn tìm được, rồi ta sẽ đi vào chi tiết (theo Richard, video đăng ngày 06/11/2026).

Theo lời Richard (video đăng ngày 06/11/2026), đây là những câu anh hỏi agent:

Did you go find the features?
Show me the evidence of the features.
Show me the evidence of the negative features.
Show your work. Build a matrix of all the features that you found,
and then we'll go into the details of it.

12. Giao cho agent một task cỡ nào

Boris hỏi: làm sao quyết định giao cho agent một task cỡ nào? Bạn có một đống ticket, có story point, một điểm, hai điểm, đại loại vậy. Khi model ngày càng thông minh hơn, làm sao quyết định độ cao (altitude) phù hợp, cỡ task phù hợp (câu hỏi trong video đăng ngày 06/11/2026)?

Richard trả lời: nhiều story point hơn thường tốt hơn. Anh cảm thấy lượng công sức bạn phải bỏ vào một task rất nhỏ có thể không đáng. Nên anh sẽ cắt ra một tập feature lớn hơn nhiều gộp lại, rồi để model hoặc harness, làm việc cùng model, tìm cách chia nó ra thành những task nhỏ hơn, tách biệt, để thực thi (theo Richard, video đăng ngày 06/11/2026).

Theo Richard, việc gì mất vài phút thì trong đầu anh là một phiên tương tác nhanh (quick interactive session); còn mọi thứ khác, anh cố gom lại thành một khối việc lớn (theo Richard, video đăng ngày 06/11/2026).

Richard nói là con người, chúng ta vẫn luôn cố chia nhỏ mọi task: nhận một việc lớn kiểu "đi build cái feature lớn này", rồi chẻ xuống thành những đơn vị một, hai, ba story point và đi làm từng cái. Nhưng nếu bạn có một team agent làm việc cho mình, nó có thể tự làm phần chia nhỏ; chúng ta không cần làm hết phần chia nhỏ đó cho chúng. Plan từ đầu càng tốt, bạn càng nhận được nhiều output hơn, và output càng tốt hơn (theo Richard, video đăng ngày 06/11/2026).

13. Sai lầm lớn nhất: chọn model theo task, và con bug 24 giờ

Boris hỏi: sai lầm lớn nhất khi rollout Claude trong vài tháng qua, trong năm qua là gì? Một điều các anh đã làm sai là gì (câu hỏi trong video đăng ngày 06/11/2026)?

MK trả lời: dùng đúng model cho đúng task, thứ cho bạn đúng ROI với đúng mức giá. Đó là chuyện độ dài và độ phức tạp của task, vì Salesforce đã thấy có người chỉ dùng nó để sinh ra những file thông thường mà họ không cần. Nên độ dài và độ phức tạp của task là cách Salesforce nhìn vào chuyện này (theo MK, video đăng ngày 06/11/2026).

Boris hỏi: có ví dụ nào về một bài toán dành cho Fable so với một bài toán dành cho Sonnet không (câu hỏi trong video đăng ngày 06/11/2026)?

Richard kể: có một con bug mà nhóm biết là tồn tại trong một sản phẩm của Salesforce. Nhóm không tìm ra nó, không tìm ra nguyên nhân gốc. Theo anh, đã có vài lần điều tra để tìm và sửa vấn đề. Rồi nhóm đưa Opus vào việc này: cho nó debug code, sửa code, compile, rồi debug tiếp và cố tìm ra lỗi. Sau 24 giờ, nó tìm ra, và đưa ra một bản sửa đề xuất (theo Richard kể, video đăng ngày 06/11/2026).

Richard nghĩ phần kiểm chứng (validation) ở đây là phần quan trọng nhất, vì đây là một phần mềm doanh nghiệp khá quan trọng với nhiều khách hàng của Salesforce, nên một câu trả lời sai có thể ảnh hưởng tới tài chính hay những thứ khác. Đó là một con bug nhỏ; nhóm chỉ không muốn bản sửa biến thành một con bug lớn, cũng khó tìm và khó sửa như vậy. Theo Richard, đó là một ví dụ rất hay về một task dài hơi phù hợp với một model rất lớn (theo Richard, video đăng ngày 06/11/2026).

14. Lời khuyên cho kỹ sư và cho CTO

Boris hỏi câu cuối: Richard có một lời khuyên gì cho các kỹ sư đang nghe? Và MK có một lời khuyên gì cho các CTO (câu hỏi trong video đăng ngày 06/11/2026)?

MK nói lời khuyên của anh là: hãy mạnh dạn (be bold). Và điều quan trọng trước hết là bạn cần nghĩ tới chuyện đi từ một hệ thống tương tác (system of engagement) sang một hệ thống hành động (system of agency), vì bạn phải để đổi mới diễn ra (theo MK, video đăng ngày 06/11/2026).

Theo MK, đổi mới không thể chỉ đến từ trên xuống (top-down). Nó phải đến cả từ trên xuống lẫn từ dưới lên (bottom-up), với những guardrail phù hợp. Anh nghĩ đó là một điều lớn, cùng với việc tạo ra một môi trường học hỏi nơi mọi người có thể chia sẻ. Đó là những điều lớn anh khuyên (theo MK, video đăng ngày 06/11/2026).

Richard nói anh luôn có một backlog những việc muốn làm, và giờ anh có thể xử lý hết backlog đó rất, rất nhanh. Kể cả khi cần đi gặp một team: họ đã làm gì, codebase đã thay đổi những gì? Anh có thể làm rất nhiều việc mà anh chưa từng nghĩ là làm được (theo Richard, video đăng ngày 06/11/2026).

Lời khuyên của Richard cho các kỹ sư: hãy đào thật sâu. Có rất nhiều thứ để khám phá, rất nhiều thứ để học, và có rất nhiều niềm vui trong quá trình này (theo Richard, video đăng ngày 06/11/2026).

Buổi trò chuyện khép lại bằng những lời cảm ơn qua lại, trong đó có một câu "Thanks for having us" (cảm ơn đã mời chúng tôi).