Amir Netz: context engineering là kỹ năng cần học

1. Lần đầu Amir Netz lên Fabric Insider

Đây là tập 26 của Fabric Insider, loạt video của RADACAD trong đó Reza Rad ngồi trò chuyện với thành viên product team của Microsoft, MVP và chuyên gia cộng đồng về cách Fabric và Power BI vận hành (theo mô tả video đăng ngày 29/10/2026). Mô tả video giới thiệu Reza là Microsoft Regional Director, Microsoft Data Platform MVP 16 năm liên tiếp và đồng sáng lập RADACAD, còn khách mời Amir Netz là người đứng sau Microsoft Fabric và Power BI (theo mô tả video đăng ngày 29/10/2026).

Reza mở đầu: chào mừng mọi người đến với một tập Fabric Insider nữa, anh rất hào hứng, và đây là lần đầu tiên Amir có mặt trong một buổi phỏng vấn Fabric Insider (video đăng ngày 29/10/2026). "Amir, chào mừng anh." Amir đáp: "Rất, rất vui." Reza nói tiếp: rất vui được gặp anh, cảm ơn anh đã dành thời gian.

Reza nói Amir đã gắn bó với các sản phẩm Data Analytics của Microsoft rất lâu; Reza nhớ từ thời VertiPaq, Analysis Services. Amir đáp: còn trước cả thời đó nữa, anh đã làm việc này 30 năm ở Microsoft (tính đến video đăng ngày 29/10/2026). Reza thốt lên "Wow", rồi nói rất vui có Amir ở đây. Trước khi nói về các announcement, Reza xin Amir tự giới thiệu: anh là ai, anh làm gì.

Amir giới thiệu (video đăng ngày 29/10/2026): anh là Amir Netz, technical fellow ở Microsoft. Anh là CTO của Fabric, và anh cũng đã làm nhiều sản phẩm BI khác của Microsoft, như OLAP Services, SQL Server Analysis Services, VertiPaq engine, Power Pivot, Power View, Q&A, rồi Power BI, và đến Fabric. Reza: "Amazing. Một hành trình tuyệt vời."

2. Thương vụ Osmos: một harness khác cho agent làm data engineering

Reza nói anh sẽ đi qua các câu hỏi không theo thứ tự đã chuẩn bị. Một trong những điều anh thấy khá nổi bật là thương vụ mua lại Osmos. Anh xin Amir kể thêm: thương vụ đó mở ra điều gì? (câu hỏi trong video đăng ngày 29/10/2026)

Theo Amir (video đăng ngày 29/10/2026), Osmos rất, rất thú vị vì Osmos đi theo khái niệm AI agent làm được data engineering. Agent rất, rất mạnh. Chúng viết được code tuyệt vời, đặc biệt là Python, chúng rất giỏi viết Python. Amir nói anh có thể lấy những model hàng đầu: một model của OpenAI, hay Opus 5.5 của Anthropic. Model nào cũng biết viết code, cũng viết được Python để làm data engineering.

Nhưng điều anh và nhóm phát hiện ra, theo Amir (video đăng ngày 29/10/2026), là khi dự án rất, rất phức tạp và cần chạy trong nhiều giờ, agent sẽ viết code, code sẽ chạy, nhưng độ chính xác của kết quả thì bạn không bao giờ biết có thực sự tốt hay không. Khi anh và nhóm kiểm thử với một dự án thực sự phức tạp, gồm nhiều phép biến đổi từ dữ liệu unstructured sang structured, từ format này sang format khác, cùng nhiều thao tác rất phức tạp khác, thì ngay cả những agent tốt nhất cũng làm sai.

Điều anh và nhóm tìm ra (theo Amir, video đăng ngày 29/10/2026): nếu cấu hình một harness khác cho AI agent, có thể buộc chúng làm việc theo cách tập trung hơn và cho kết quả tốt hơn: chạy nhanh hơn, tốn ít token hơn, và quan trọng nhất là chính xác hơn. Mức chính xác anh và nhóm đạt được tốt hơn rất nhiều so với những gì có được, kể cả với các frontier model của Anthropic và OpenAI.

Reza tóm lại: vậy về cơ bản, trong tương lai nó sẽ được tích hợp vào Fabric, và ta sẽ có trải nghiệm data engineering tốt hơn. Amir xác nhận: "Chính xác." Theo Amir (video đăng ngày 29/10/2026), không chỉ là trải nghiệm. Bạn đưa cho nó việc bạn muốn làm, giống như đưa cho bất kỳ agent nào. Nhưng bên dưới, quy trình agentic là một quy trình rất riêng. Không phải kiểu "nào, đưa cho OpenAI, đưa cho Anthropic". Đó là một thứ rất, rất đặc biệt. Reza: "Fantastic."

3. CI/CD trong Fabric: deployment plans và branch workspace

Reza chuyển sang một thách thức trong Fabric suốt nhiều năm: làm việc với CI/CD. Giờ cũng có cập nhật ở mảng này, anh xin Amir kể thêm (câu hỏi trong video đăng ngày 29/10/2026).

Amir nói CI/CD là điều anh và nhóm luôn nghe từ cộng đồng, và cũng là điều rất gần gũi với chính anh và nhóm. Theo Amir (video đăng ngày 29/10/2026), anh và nhóm đã làm việc rất chăm chỉ trong năm qua để bảo đảm phần triển khai CI/CD hoàn chỉnh trên mọi workload đang có.

Anh kể thêm các khả năng để làm CI/CD theo cách tối ưu (theo Amir, video đăng ngày 29/10/2026): có workspace chỉ chứa một phần các item; diff giữa các item khi chuyển từ bên này sang bên kia, từ branch sang main line, hay từ dev sang test rồi sang production; và deployment được kiểm soát chặt.

Một trong những điểm được chú ý nhiều nhất "từ hôm qua", theo lời Amir trong video đăng ngày 29/10/2026, là việc giới thiệu deployment plans. Deployment plans cho bạn toàn quyền kiểm soát thứ tự các thao tác: item nào được deploy trước item nào, và code nào có thể chạy giữa các thao tác. Nhìn chung, Amir cảm thấy anh và nhóm đã tới được một chỗ tốt.

Còn một điều khác (theo Amir, video đăng ngày 29/10/2026): để làm việc trên một branch, bạn cần có một workspace khác. Đó từng là thách thức, vì các workspace của branch làm rối namespace của workspace. Mọi người không thích điều đó, nên giờ anh và nhóm đưa thêm trải nghiệm mà ở đó bạn không thấy các branch workspace nằm trong danh sách lớn. Anh và nhóm liên tục cải thiện mảng này. Amir không nghĩ đã xong, nhưng so với một năm trước thì đã ở một chỗ tốt hơn rất nhiều.

Reza nói: và nó vẫn là một work in progress. Amir lặp lại: "It's a work in progress." Reza nói anh vẫn luôn nhắc rằng không thể có được 100% những gì mọi người muốn. Amir: "It's a work in progress." (video đăng ngày 29/10/2026)

4. Fabric F0: không dùng thì không trả tiền

Reza nói một điều khác anh rất thích là Fabric F0, kiểu như một điểm khởi đầu. Nó hoạt động thế nào? (câu hỏi trong video đăng ngày 29/10/2026)

Amir giải thích cách hình dung tốt nhất về F0 (theo Amir, video đăng ngày 29/10/2026). Trước hết, có cả một dải SKU: anh kể từ F8000, xuống F4000, rồi cứ chia đôi, chia đôi, chia đôi cho tới F2. Mọi SKU này có một điểm chung: bạn mua chúng và trả một mức giá cố định dù có dùng hay không, dù chúng idle hay rất bận, chi phí vẫn y như nhau.

F0 đưa mọi thứ xuống thêm một bậc, thấp hơn F2 (theo Amir, video đăng ngày 29/10/2026). Không phải F1 mà là F0, nghĩa là bạn không có provisioned capacity nào cả. Nếu không dùng gì, bạn không tốn gì. F0 giá bằng 0. Provision F0 không tốn gì. Cái tốn tiền là khi bạn bắt đầu dùng: lúc đó có CU bị tiêu thụ, và bạn trả cho các CU đã tiêu thụ. Tính theo từng CU, các CU này đắt hơn, nhưng bạn không trả cho thứ mình không dùng.

Nói chung (theo Amir, video đăng ngày 29/10/2026), F0 hợp khi bạn dùng một cách rời rạc, khi có những ngày không dùng: bạn có việc kinh doanh, bạn đi công tác, bạn pause. Rồi bạn sẽ thấy: "tôi thậm chí không phải pause. Không dùng thì không dùng. Có thể tôi dùng năm giờ vào thứ Hai, tôi chỉ trả cho năm giờ tôi dùng. Tôi không phải nhớ bật lên, tắt đi, không phải lên lịch gì cả. Nó cứ vận hành như vậy."

Theo Amir (video đăng ngày 29/10/2026), F0 rất hợp khi bạn có thứ gì đó rất spiky rồi hoàn toàn idle. Nó không làm smoothing nào, và cũng không cần smoothing. Đó là mô hình của F0.

5. Reserved instance hay on-demand mode

Nếu bạn dùng nặng, theo Amir (video đăng ngày 29/10/2026), thì nên provision capacity, đặc biệt là với reserved instance, vì bạn được giảm giá rất, rất tốt. Anh cho rằng với hầu hết khách hàng, tiếp tục ở lại với reserved instance là một ý hay. Nó sẽ giúp họ tiết kiệm chi phí đáng kể, và cho họ khả năng dự đoán chi phí cao.

Nhưng nếu bạn có những thứ spiky hoặc không được dùng nhiều, hoặc có những workload cụ thể rất spiky còn các workload khác thì không, thì có thể cấu hình riêng workload đó chạy ở chế độ mà anh và nhóm gọi là on-demand mode (theo Amir, video đăng ngày 29/10/2026). Reza: "Right." Amir nói tiếp: các workload khác vẫn ở lại trên capacity.

Reza hỏi lại để chắc: vậy nó hoạt động cả trong trường hợp, giả sử anh có F64 và muốn scale up vào một lúc nào đó, thì dùng on-demand mode? (câu hỏi trong video đăng ngày 29/10/2026)

Amir đưa ví dụ (theo Amir, video đăng ngày 29/10/2026): bạn có thể nói, capacity của tôi ổn, mọi thứ đang chạy tốt. Chỉ là thỉnh thoảng tôi có một job Spark lớn. Tôi không muốn phải nâng capacity lên bậc tiếp theo. Tôi chỉ muốn job Spark này chạy on-demand, còn mọi thứ khác ở lại trên F64. Reza: "Right. Amazing." Anh nói anh rất thích điều đó.

6. Ontology và semantic model

Reza chuyển sang semantic model: ta cũng nghe nói về ontology, và ontology như một lớp nằm trên semantic model. Ta có thực sự cần nó không, và vì sao cần? (câu hỏi trong video đăng ngày 29/10/2026)

Amir nói đó là một câu hỏi hay. Trước hết, có cần ontology không? Theo Amir (video đăng ngày 29/10/2026), ta cần ontology như một chức năng. Ontology cho bạn khả năng lấy semantic model và thêm năng lực cho nó. Bạn có thể thêm action. Có lẽ yếu tố phân biệt rõ nhất của ontology là giờ bạn có thể nói: tôi có một entity customer và tôi có một action trên nó, chẳng hạn tôi muốn gửi một promotion cho khách hàng, hay tôi muốn chuyển khách hàng sang bộ phận customer service.

Vậy là có nhiều entity khác nhau, và nhiều action khác nhau trên các entity đó (theo Amir, video đăng ngày 29/10/2026). Ví dụ: có một entity máy bay, và tôi muốn đưa nó tới một gate, hay gán một tổ bay (crew) cho máy bay. Đó đều là action trên entity. Tôi cũng có thể có policy. Quay lại chiếc máy bay: không chỉ chuyện phi công này được gán cho máy bay này, mà một phi công cần chứng chỉ gì để được gán cho một máy bay, hay phi công cần nghỉ bao nhiêu giờ trước khi được bay. Đó đều là policy.

Theo Amir (video đăng ngày 29/10/2026), đó là những thứ semantic model không có. Chúng là phần mở rộng. Chúng cho một bức tranh đầy đủ hơn nhiều về doanh nghiệp, và cho phép agent lẫn con người bắt đầu vận hành doanh nghiệp, bắt đầu hành động. Thông thường semantic model phục vụ analytics, phục vụ reporting. Còn với ontology, ý tưởng là bạn có thể bước vào thế giới của action.

Amir tự nêu điều anh nghĩ là gây tranh cãi: có nhất thiết phải gọi chúng là ontology không? Sao không đơn giản vẫn là semantic model? Reza chen vào: "Câu hỏi hay." Amir nói đôi khi chính anh cũng tự hỏi câu đó (video đăng ngày 29/10/2026).

Có lẽ anh và nhóm đã làm mọi người bối rối, chưa làm đủ tốt việc giải thích cho rõ (theo Amir, video đăng ngày 29/10/2026). Một số người nghĩ rằng bạn phải chọn hoặc semantic model hoặc ontology, trong khi câu trả lời thực sự là ontology chỉ là semantic model được làm giàu. Không phải cái này hay cái kia. Ontology chỉ là phần bổ sung cho semantic model. Bên dưới, nó dựa trên cùng một thứ, cùng một format, nên không mất gì khi bạn nâng cấp semantic model lên ontology: mọi DAX measure đều đi theo.

Vậy có nên gọi là ontology, hay nên giữ tên semantic model? Amir nói: "Không, tôi để các bạn đánh giá, rồi sẽ thấy. Tôi không chắc chúng tôi đã quyết định đúng, nhưng đó là quyết định đã đưa ra." (video đăng ngày 29/10/2026)

Reza hỏi thêm: việc đồng bộ giữa hai thứ này hoạt động thế nào, nếu anh cập nhật semantic model gắn với ontology của mình? Amir trả lời (video đăng ngày 29/10/2026): ý tưởng là có. Anh không nhớ việc này đã có trong sản phẩm hay chưa, nhưng nó được thiết kế để phát hiện semantic model đã được cập nhật và kéo phần cập nhật vào ontology.

Trang Microsoft Learn về ontology (preview) mô tả item này trong Fabric IQ là một biểu diễn chung, máy hiểu được, về doanh nghiệp: định nghĩa các khái niệm như customers, products, assets, orders, locations, cùng thuộc tính, quan hệ, rules và metrics của chúng (đọc ngày 03/11/2026).

7. Microsoft IQ: agent thành đồng đội

Reza nói: ta đã nói về ontology, giờ nói về Fabric IQ, và tính năng lớn hơn là Microsoft IQ. Anh nhớ có lần dự một buổi trình bày mà Amir là diễn giả, và Amir có một tầm nhìn rất hay: ngày nay các công ty có thể có AI employee. Toàn bộ Microsoft IQ giúp làm được điều đó. Anh xin Amir nói thêm (câu hỏi trong video đăng ngày 29/10/2026).

Theo Amir (video đăng ngày 29/10/2026), ta đang đi tới một thế giới mà agent sẽ không còn là ứng dụng phần mềm. Chúng sẽ là đồng đội thật sự. Chúng sẽ làm việc bên cạnh nhân viên bình thường. Chúng sẽ là một phần của doanh nghiệp. Chúng sẽ có manager. Chúng sẽ có email. Và chúng sẽ đảm nhận những vai trò mà trước đây có lẽ bạn đã tuyển một nhân viên mới, còn giờ bạn nói: tôi có thể để một agent làm việc đó. Có thể bạn từng gặp vấn đề, không tuyển được nhân viên mới, và giờ bạn có thể hoàn thành chức năng đó mà không phải tuyển ai.

Là đồng đội, theo Amir (video đăng ngày 29/10/2026), ta muốn chúng thực sự cư xử đúng mực. Ta muốn giao việc cho chúng. Ta muốn chúng cư xử theo cách ta mong ở bất kỳ đồng đội nào: suy luận đúng, hành động đúng, suy nghĩ như ta suy nghĩ. Và context là thứ làm điều đó thành hiện thực.

Context cho phép agent hiểu ta, hiểu doanh nghiệp của ta, hiểu cách mọi việc được làm ở đây, hiểu điều đang diễn ra ngay lúc này, hiểu mục tiêu của ta, thứ ta đang cố đạt được (theo Amir, video đăng ngày 29/10/2026). Vì vậy khi chúng nhìn vào một tình huống, khi chúng đánh giá hành động đúng nên làm là gì, ta muốn tin tưởng và nói: chúng nghĩ giống ta. Để nghĩ giống ta, chúng phải hiểu thế giới, hiểu doanh nghiệp, hiểu team, hiểu các policy của ta giống như cách ta hiểu. Đó thực sự là vai trò của context.

Microsoft IQ chính là như vậy (theo Amir, video đăng ngày 29/10/2026): đó là bức tranh đầy đủ của toàn bộ context mà ta có thể trao cho agent, để chúng nghĩ giống ta và thực sự hành động giống ta. Microsoft IQ được tạo từ nhiều IQ con khác.

• Work IQ: tất cả là để hiểu team, hiểu cách ta làm việc. Nó thấy email, thấy document, thấy chat, thấy lịch. Nó thực sự hiểu từ thế giới dữ liệu unstructured, hiểu điều đang diễn ra ở phía đó (theo Amir, video đăng ngày 29/10/2026).
• Foundry IQ: nơi có các knowledge base, ở đó ta ghi lại mọi quy trình nội bộ và giải thích cho agent cách ta làm việc ở đây (theo Amir, video đăng ngày 29/10/2026).
• Fabric IQ: vẽ nên bức tranh về điều đang diễn ra trong doanh nghiệp ngay lúc này. Doanh số đang thế nào? Đang có những escalation nào cần giải quyết? Có headcount để tuyển không? Tất cả những thứ đến từ thế giới dữ liệu structured (theo Amir, video đăng ngày 29/10/2026).

Gộp lại, theo Amir (video đăng ngày 29/10/2026), agent có được bức tranh đầy đủ, kiểu như: được rồi, giờ tôi hiểu ta đang ở đâu, bạn là ai, các đồng đội của tôi, tôi làm gì, bạn làm gì, điều gì đang diễn ra ngay lúc này trong doanh nghiệp, mọi việc được làm thế nào ở đây; và chúng có thể thực sự tham gia và ra quyết định theo cách mà chính ta, những con người, đã ra quyết định.

Reza nói thật tuyệt khi thấy thế giới đang thay đổi ra sao, và Microsoft đang đi những bước tiên phong (frontier steps) trong việc này (video đăng ngày 29/10/2026).

8. Coding đang thành việc của compiler

Reza nói AI làm được rất nhiều việc cho ta, đúng không? Amir: "Đúng." Reza nói tiếp: trước đây ta dùng AI chỉ để giúp viết code, còn giờ, ví dụ, AI có thể đi build cả medallion architecture trong Fabric. Developer Fabric nên dùng nó thế nào? Có nên chỉ upload công việc lên và nói "làm việc này giúp tôi"? Hay Amir có lời khuyên nào? (câu hỏi trong video đăng ngày 29/10/2026)

Theo Amir (video đăng ngày 29/10/2026), khái niệm coding đang chuyển sang trạng thái giống những gì compiler làm. Nếu nghĩ lại, ngày xưa lập trình viên viết machine code trực tiếp vào máy tính. Rồi người ta nghĩ ra mức trừu tượng cao hơn gọi là ngôn ngữ lập trình, và nói: ta không phải tự viết machine code nữa. Ta có thể viết bằng Fortran, bằng C#, C++, JavaScript hay Python, rồi để máy compile code thành binary, thành thứ machine code mà trước đây ta làm bằng tay. Cái quá khứ đó là thập niên 1950 và 1960.

Amir nghĩ (video đăng ngày 29/10/2026) điều ta đang làm bây giờ là một dạng compile khác: ta lấy một spec và compile nó thành code, rồi code đó lại được compile thành ngôn ngữ máy. Theo anh, đó là điều đang xảy ra. Cũng như người ta không còn tự viết machine code, người ta không còn tự viết từng dòng code.

Theo Amir (video đăng ngày 29/10/2026), agent ngày nay viết code tốt hơn hầu như bất kỳ coder con người nào. Ở thời điểm này chúng là những super coder. Vậy điều ta làm là nâng mình lên một tầng: việc của ta là cung cấp những spec thật tốt cho agent.

9. Tám file spec và AI chạy 24 giờ

Amir kể về một người bạn của anh, chief architect của Fabric, một trong những coder xuất sắc nhất (theo Amir, video đăng ngày 29/10/2026). Người này đã viết VertiPaq gần như một mình từ nhiều năm trước, hai triệu dòng code. Đó là một coder tuyệt vời: chất lượng cao, throughput khổng lồ, ý tưởng thiên tài.

Và chính người đó nói (theo lời Amir thuật lại trong video đăng ngày 29/10/2026): hôm nay tôi không phải tự làm nữa, việc tôi phải làm là tạo ra một spec thật tốt. Spec phải chi tiết. Spec phải được nghĩ thấu đáo. Nó có mọi thứ để bảo đảm agent thực sự viết ra code ta muốn, với chất lượng ta muốn, với những cân nhắc ta muốn, với các policy ta muốn.

Đôi khi nhìn vào spec của người này, theo Amir (video đăng ngày 29/10/2026), spec có thể là tám file spec khác nhau, mỗi file nhiều trang, rất, rất chi tiết. Anh ấy đưa toàn bộ cho AI, và AI đôi khi chạy 24 giờ, nhưng rồi xong: hệ thống được viết ra với chất lượng cao. Anh ấy nói: tôi review nó, tôi không tìm thấy lỗi nào. Còn nếu tìm thấy lỗi, anh ấy nói: được rồi, tôi chỉ cần sửa spec để lần sau nó không lặp lại lỗi đó; chỉ là tôi đã chưa đủ cụ thể về chỗ đó.

Amir cho rằng (video đăng ngày 29/10/2026) đó thực sự là hướng thế giới đang đi: từ chỗ ta làm phần việc nặng nhọc (grunt work), viết từng dòng code, đặt từng box của pipeline lên màn hình và mọi thứ như thế, sang chỉ viết đúng spec, với đúng design, đúng suy nghĩ, đúng ý tưởng.

10. Spec engineering và context engineering

Reza: "Right." Anh hỏi: đây có phải cùng là thuật ngữ mà Amir từng dùng trước đây, kiểu như context engineering? (câu hỏi trong video đăng ngày 29/10/2026)

Amir trả lời context engineering có lẽ hơi khác một chút, và anh sẽ nói về context ngay sau đây. Theo Amir (video đăng ngày 29/10/2026), điều vừa nói không phải context engineering. Đó thực sự là khả năng cung cấp, anh sẽ gọi là spec engineering. "Có lẽ gọi vậy thì hay hơn."

Còn context engineering, theo Amir (video đăng ngày 29/10/2026), gần với điều đã nói lúc trước hơn. Đó là chuyện làm sao bảo đảm agent thực sự có mọi context cần thiết để suy nghĩ. Làm sao cung cấp một bức tranh hoàn chỉnh cho agent. Và không nhất thiết là cho coding, mà cho bất kỳ công việc nào khác.

Amir đưa ví dụ (video đăng ngày 29/10/2026): bạn muốn agent làm customer service agent? Làm sao nó trở thành customer service agent của bạn, thực sự đại diện cho công ty bạn? Bạn muốn nó làm salesperson của bạn? Làm sao nó trở thành salesperson thực sự hiểu khách hàng của bạn, hiểu value proposition của bạn, hiểu cách pitch cho đúng? Tới mức bạn nói: wow, tuyệt quá, tôi thực sự tự hào về agent của mình, tôi không thể làm tốt hơn thế.

Theo Amir (video đăng ngày 29/10/2026), điều đó đang trở thành bài toán: tạo ra context hoàn chỉnh để agent hành xử đúng vai trò của nó, không chỉ vai trò coding, mà bất kỳ vai trò nào. Reza hỏi lại: vậy đó là phần bàn về Microsoft IQ. Amir: "Đó chính là Microsoft IQ, chính xác."

11. Security rules trong Mirroring

Reza nói: "Awesome, amazing. Vậy là AI, tuyệt." Anh chuyển sang những thứ khác có trong keynote, như security rules trong Mirroring. Anh rất thích tính năng này. Nó thực sự hoạt động thế nào? (câu hỏi trong video đăng ngày 29/10/2026)

Amir nói nó không thực sự là chuyện cao siêu (rocket science). Theo Amir (video đăng ngày 29/10/2026), vì làm mirroring nên anh và nhóm đã biết cách kết nối tới database nguồn. Và cũng như đọc được nội dung bảng, cấu trúc bảng, định nghĩa view, anh và nhóm cũng đọc được các security policy: chỉ cần gọi API của database, đọc các security policy.

Sau đó (theo Amir, video đăng ngày 29/10/2026), anh và nhóm dùng AI để chuyển từ format này sang format kia, và giờ có thể áp dụng cùng security policy đó trong OneLake, trong OneLake security. Thực chất chỉ có vậy. Anh và nhóm bắt đầu với Snowflake, mọi người hỏi về các database quen thuộc khác ("the usual suspects"), và chúng sẽ đến. Khi làm xong một cái, bạn có một pattern, bạn bắt đầu nhân rộng, và nó đến khá nhanh.

Reza hỏi tính năng này hiện ở mức object level hay một mức khác. Amir trả lời (video đăng ngày 29/10/2026): hiện tại là object level; mức còn lại sẽ đến sớm, rồi anh và nhóm sẽ làm tất cả các database khác.

Reza nói: "Awesome." Theo Reza (video đăng ngày 29/10/2026), đây là một bước tiến tuyệt vời, vì nhiều người ngần ngại dùng mirroring, đặc biệt vì họ phải tự build security rules. Amir: "Đúng." Reza: giờ anh và nhóm build việc đó cho họ.

Amir: "Chính xác. Và đó chính là mục đích." Theo Amir (video đăng ngày 29/10/2026), anh và nhóm thực sự không muốn bất kỳ ai có bất kỳ lý do nào để không dùng mirroring, không dùng shortcuts. Mục tiêu từ trước tới nay là loại bỏ toàn bộ friction khỏi hệ thống. Vì thế anh và nhóm không tính phí mirroring, không tính phí shortcuts. Ý tưởng là: cứ đưa hết dữ liệu vào OneLake, để có một single pane of glass, hình thành bức tranh đầy đủ về mọi data item bạn có, toàn bộ data estate.

Trang Microsoft Learn về Mirroring mô tả đây là giải pháp low-cost, low-latency, sao chép liên tục data estate hiện có vào OneLake của Fabric từ nhiều database Azure và nguồn dữ liệu bên ngoài (đọc ngày 03/11/2026).

12. Fabric App và tương lai của Power BI report

Reza nói: "Amazing." Anh chuyển sang Fabric App, một mảng hay khác mà nhóm đã làm, và anh rất vui vì đây là một sản phẩm tuyệt vời. Anh hỏi: liệu nó sẽ thay thế Power BI, hay ít nhất thay đổi Power BI như ta vẫn biết? (câu hỏi trong video đăng ngày 29/10/2026)

Amir nghĩ là có (video đăng ngày 29/10/2026). Cũng như đã nói về chuyện coding sẽ thay đổi, khi ta không còn mong user hay developer tự viết từng dòng code, ta cũng không còn mong user tự tay sắp xếp visual trên màn hình. Amir không nghĩ có ai thực sự thích làm việc đó. Cách đó đã tốt hơn mọi thứ khác ngoài kia. Nhưng nếu có AI làm cho mình, thì sao lại không?

Theo Amir (video đăng ngày 29/10/2026), điều này lại nâng toàn bộ mô hình tương tác lên một tầng cao hơn: bạn chỉ cần nói mình muốn thấy gì, và để AI tìm ra cách thể hiện tốt nhất. Rồi, giống như với code, bạn xem AI đã làm gì và quyết định có thích hay không, đưa AI chỉ dẫn để sửa. Có thêm ý tưởng thì mở rộng chỉ dẫn để AI làm thêm.

Và đôi khi, Amir kể (video đăng ngày 29/10/2026), anh chỉ muốn nói: tôi đang viết cả đống chữ để giải thích một thứ cho AI, để tôi tự vào đổi title, tự đổi màu cho xong. Đôi khi anh hơi mất kiên nhẫn với việc viết nhiều chữ. Nhưng nó đúng là thay đổi mô hình tương tác.

Theo Amir (video đăng ngày 29/10/2026), công nghệ bên dưới cũng rất khác, nên nó không bị giới hạn trong visual stack của Power BI. Power BI có một visual stack rất tốt so với thời của nó: có tất cả các built-in visual và custom visual, làm được rất nhiều thứ. Nhưng giờ, với mọi thứ coding agent làm được, chúng có thể build những ứng dụng rất phong phú, dùng bất kỳ thư viện visualization nào trên thế giới. Không còn giới hạn cho những gì có thể làm.

Kết quả, theo Amir (video đăng ngày 29/10/2026), là sáng tạo hơn nhiều, và cũng nhanh hơn nhiều. Không cần nhiều code ở phía client; đó thực sự là một ứng dụng React rất nhẹ. Nhờ vậy có thể ra những dashboard đẹp ấn tượng, chạy rất nhanh. Và nếu nhìn chất lượng mặc định đang đạt được, thì đó là thứ mà trước đây bạn cần một report designer chuyên nghiệp làm hàng giờ, có khi hàng ngày mới tới được mức đó; còn đây chỉ là chất lượng mặc định bạn có từ trải nghiệm Power BI mới với Fabric Apps.

13. MCP server, và AI từ "hit and miss" tới xuất sắc

Reza: "Right, yeah." Anh nói còn có khả năng build modeling bằng MCP server, cũng rất hữu ích. Anh hỏi Amir có đo việc này không: đã có nhiều người dùng MCP server để build model chưa? (câu hỏi trong video đăng ngày 29/10/2026)

Amir xác nhận điều đó hoàn toàn đúng (video đăng ngày 29/10/2026). Anh nói anh và nhóm thấy rằng khi người ta bắt đầu dùng AI cho ngày càng nhiều việc, họ trở nên hơi được chiều hư (spoiled) và không thích làm việc nặng nữa. Amir kể đã khá lâu rồi anh không tự tay viết một document dài hơn hai trang; thường thì anh để agent viết cho anh. Điều đó đúng với các dòng code, đúng với presentation: anh thấy rất nhiều presentation đẹp do AI tạo ra. Và anh nghĩ nó sẽ đúng với mọi thứ khác.

Vậy nên, theo Amir (video đăng ngày 29/10/2026), điều đó cũng đúng với các dự án Fabric: người ta không muốn làm hết phần việc nặng khi AI có thể giúp. Và AI đang làm việc rất, rất tốt.

Amir nói (video đăng ngày 29/10/2026): nếu hai năm trước bạn hỏi anh AI làm thế nào, anh sẽ nói "hit and miss", lúc trúng lúc trượt. Nếu hỏi anh một năm rưỡi trước, anh sẽ nói khá tốt. Còn giờ anh có thể nói nó xuất sắc. Thực sự là vậy. Anh nghĩ đã có điều gì đó xảy ra khoảng 10 tháng trước (tính từ video đăng ngày 29/10/2026): Opus 4.5 là một khoảnh khắc bước ngoặt (watershed moment). Anh nghĩ bỗng nhiên nó chuyển từ gần như tốt sang rất tốt. Và đó là điều anh và nhóm đang thấy ở mọi nơi.

14. Feedback và lời chào

Reza: "Yes. Amazing. Fantastic." Anh hỏi khán giả có thể liên hệ Amir thế nào nếu có câu hỏi, về Fabric nói chung, và gửi feedback ra sao (câu hỏi trong video đăng ngày 29/10/2026).

Amir nói có rất, rất nhiều kênh, có các kênh cộng đồng. Mọi người cũng có thể liên hệ anh qua LinkedIn, và hầu như mọi người trong nhóm đều có mặt trên LinkedIn để trao đổi và đặt câu hỏi (theo Amir, video đăng ngày 29/10/2026). Anh và nhóm rất thích feedback. Mọi người cứ biết vậy, đừng ngại.

Theo Amir (video đăng ngày 29/10/2026), mỗi câu hỏi bạn đặt ra là một feedback cho anh và nhóm. Ngay từ bản thân câu hỏi, trước cả câu trả lời, câu hỏi đã cho thấy anh và nhóm có thể làm điều gì đó tốt hơn: đã làm bạn bối rối, bạn chưa hiểu cách anh và nhóm làm việc. Đó là những điều anh và nhóm học được. Amir nói anh học được rất nhiều từ các câu hỏi anh nhận từ cộng đồng. Vì vậy đừng ngần ngại: liên hệ anh, liên hệ Arun, Bogdan, Yitzhak và những người còn lại trong nhóm.

Reza nói: "Amazing", cảm ơn Amir đã dành thời gian, thật tuyệt khi có anh ở đây. Amir đáp: thật tuyệt. Reza cảm ơn, rồi cảm ơn mọi người đã xem.