Khi canvas AI không nằm ở model

Khi canvas AI không nằm ở model

Figma đang đặt cược vào human judgment, không phải tự build model. Với builder, đây là tín hiệu để chọn đúng lớp mình nên kiểm soát.

“Team mình có nên tự build model cho tool thiết kế nội bộ không?” — câu này mình nghe ngày càng nhiều, thường xuất hiện sau một buổi demo mà AI dựng được UI, viết code, thêm animation, rồi còn nói chuyện như product designer tăng ca.

Cảm giác rất dễ hiểu. Khi mọi công cụ đều gắn chữ AI vào canvas, IDE, repo, vector database, agent workflow, bạn sẽ có cảm giác đội nào không sở hữu model riêng thì đang đá thiếu người. Nhưng nhìn kỹ động thái của Figma tại Config 2026, câu chuyện thú vị lại nằm ở chỗ ngược lại: Figma không cố thắng bằng việc sở hữu model, mà bằng việc kiểm soát nơi con người ra quyết định.

Đó mới là điểm đáng để developer và tech lead ngồi xuống bàn bạc.

Sơ đồ minh họa cho bài Khi canvas AI không nằm ở model

Sơ đồ tóm tắt ý chính của bài viết.

Chuyện đang diễn ra: AI đã vào canvas, nhưng quyền quyết định vẫn ở người

Figma đang mở rộng canvas từ chỗ vẽ layout tĩnh sang một không gian có code, motion, hiệu ứng 3D, surface effects và AI agents. Figma Make kéo production code vào canvas, làm việc qua branch, commit, pull request mà không bắt designer mở terminal. Code Layers thì đặt design và code cạnh nhau: bạn có thể generate code từ thiết kế, prompt agent chỉnh sửa, hoặc import repo từ GitHub.

Ở bề mặt, đây giống một cuộc đua “ai generate UI nhanh hơn”. Nhưng nếu chỉ nhìn vậy thì hơi phí.

Điểm đáng chú ý hơn là Figma đang thêm các tính năng cộng tác quanh AI: chia sẻ prompt tốt, workflow tốt, custom plugin tốt. Tức là họ không chỉ hỏi “model trả lời gì?”, mà hỏi “team học được gì từ lần dùng AI trước?”.

Trong một đội bóng, tiền đạo ghi bàn dễ lên highlight. Nhưng hệ thống chuyền bóng, vị trí đứng, cách cả đội phản ứng sau khi mất bóng mới quyết định mùa giải dài. Với AI product cũng vậy: output đẹp trong demo là bàn thắng; workflow giữ được chất lượng qua nhiều sprint mới là đội hình.

Lớp bị hiểu sai: model không phải thứ duy nhất tạo lợi thế

Nhiều team đang nhầm giữa AI capability và product advantage.

Figma đang bị kẹp ở một thế rất thật: AI là động cơ tăng trưởng, nhưng inference cost — chi phí chạy model khi người dùng gửi yêu cầu — lại ăn vào margin. Model đến từ bên ngoài, trong khi chính các provider như Anthropic hay OpenAI cũng có thể làm công cụ generate interface cạnh tranh trực tiếp.

Nói thẳng ra thì, đây là bài toán “mượn chân sút của đội khác nhưng vẫn phải thắng giải”. Nếu bạn không sở hữu model, bạn phải sở hữu thứ khác: context, workflow, collaboration layer, design system, code integration, governance.

Với builder, câu hỏi không còn là “model nào mạnh nhất?”. Câu hỏi nên đổi thành:

Lớp nào trong hệ thống AI của mình thật sự đáng kiểm soát?

Mổ xẻ 4 lớp quyết định cho builder

Thay vì chạy theo tool mới nhất, mình sẽ tách hệ thống AI thành 4 lớp. Mỗi lớp có mức độ nên kiểm soát khác nhau.

1. Model layer: thuê trước, tự build sau

Model layer là lớp foundation model — model nền được train rộng rồi dùng cho nhiều tác vụ. Với phần lớn team sản phẩm, tự build model không phải điểm bắt đầu khôn ngoan.

Bạn có thể dùng API từ các model lớn, hoặc chọn model open-source nếu cần kiểm soát dữ liệu và chi phí. Nhưng trong cả hai trường hợp, model nên được xem như năng lực có thể thay thế, không phải linh hồn sản phẩm.

Điều kiện để nghĩ tới tự host hoặc tự fine-tune:

Nếu chưa có ba điều này, tự build model dễ biến thành hiệp phụ kéo dài: mệt hơn, tốn hơn, mà chưa chắc thắng.

2. Context layer: nơi nhiều team đang bỏ tiền rơi vãi

Context layer là cách bạn đưa thông tin đúng vào model đúng lúc. Nó gồm tài liệu, repo, design system, ticket, lịch sử quyết định, guideline nội bộ.

Đây là lớp Figma đang đẩy mạnh khi đưa production code vào canvas và để design/code sống cạnh nhau. Vì khi context tốt hơn, model không phải đoán nhiều. Token dùng cũng thông minh hơn.

Với hệ thống nội bộ, context layer thường đáng đầu tư hơn đổi model. Ví dụ cụ thể: team bạn có một design system với component Button, Modal, CheckoutFlow. Nếu AI chỉ nhìn screenshot rồi generate lại từ đầu, output có thể đẹp nhưng lệch chuẩn. Nếu AI thấy luôn component thật trong repo, nó có cơ hội đề xuất thay đổi đúng hơn, ít “sáng tác” hơn.

Ở đây, RAG — truy xuất tài liệu liên quan để đưa vào prompt — vẫn hữu ích, nhưng đừng dừng ở search cơ bản. Các tín hiệu từ cộng đồng vector database như Qdrant cho thấy builder đang quan tâm nhiều hơn tới agents, memory, hybrid search và edge use case. Dịch sang công việc: tìm kiếm không chỉ là “lấy 5 đoạn gần nhất”, mà là chọn đúng ngữ cảnh cho đúng bước hành động.

3. Workflow layer: prompt hay cần thành tài sản chung

Một prompt tốt nằm trong chat cá nhân thì giống bài phối hợp hay nhưng chỉ một cầu thủ nhớ. Figma đưa việc chia sẻ prompt, workflow, custom plugin vào sản phẩm là nước đi đáng học.

Builder nên hỏi:

Nếu team bạn đang dùng AI coding tool, từ Copilot đến các nền tảng build app bằng prompt, đừng chỉ đo “tool nào viết code nhanh”. Hãy đo xem output đó có đi qua review, test, branch, pull request, logging và ownership rõ không.

Generative coding tool năm 2026 đang tiến từ autocomplete sang full app generation, multi-agent build pipeline và natural-language interface với codebase. Hay đấy. Nhưng càng generate nhiều, workflow layer càng quan trọng. Không có lớp này, bạn chỉ đang tăng tốc độ tạo việc cho reviewer.

4. Judgment layer: thứ khó outsource nhất

Judgment layer là nơi con người quyết định: cái gì đúng với brand, user, accessibility, performance, maintainability, roadmap.

Đây là phần Figma đang đặt cược: AI sinh ra nhiều phương án, nhưng designer và team vẫn giữ quyền chỉnh, chọn, loại, kết hợp. Với sản phẩm AI, human judgment không phải cái phanh chống đổi mới. Nó là VAR của hệ thống: không xuất hiện trong mọi pha bóng, nhưng lúc cần thì cứu cả trận.

Builder cần biến judgment thành quy trình nhìn thấy được:

Nếu không làm rõ lớp này, bạn sẽ có một hệ thống trông rất tự động nhưng thực chất phụ thuộc vào vài người senior âm thầm sửa tay.

Framework chọn đường: dùng, chờ, hay bỏ qua?

Đây là phần mình muốn bạn mang về sau khi đọc: đừng chọn tool AI theo độ ồn; hãy chọn theo lớp bạn cần kiểm soát.

| Tình huống team | Nên làm | Tránh làm |
|---|---|---|
| Team nhỏ, cần prototype nhanh | Dùng AI coding/design tool để dựng bản đầu, giữ review thủ công | Tự build model hoặc agent pipeline phức tạp |
| Team có design system và repo ổn | Đầu tư context layer: nối component, code, guideline vào workflow AI | Để AI generate UI tách khỏi component thật |
| Team dùng AI nhiều nhưng output loạn | Chuẩn hóa prompt/workflow thành asset chung | Mỗi người tự prompt, tự lưu, tự nhớ |
| Team bị chi phí inference đè | Tối ưu token, cache, chọn model theo tác vụ, giới hạn scope agent | Đổi sang model “mạnh hơn” mà không đo cost per workflow |
| Sản phẩm cần chất lượng domain cao | Xây evaluation và human review trước khi fine-tune | Fine-tune vì thấy prompt chưa đủ đẹp |

Giả sử team bạn 6 người đang build một công cụ tạo landing page nội bộ. Cách ít đau nhất thường không phải “tạo model riêng để generate HTML”. Bạn có thể bắt đầu bằng:

  1. Cho AI đọc component library hiện có.
  2. Bắt output đi qua branch và pull request.
  3. Lưu lại prompt tạo kết quả tốt thành template.
  4. Tạo checklist review cho design lead và frontend lead.
  5. Sau vài tuần mới xem bottleneck nằm ở model, context, hay review.

Nếu bottleneck là model không hiểu domain dù context đã tốt, lúc đó mới tính tới fine-tuning — tinh chỉnh model bằng dữ liệu riêng. Nếu bottleneck là review mất thời gian, hãy sửa workflow. Nếu bottleneck là chi phí, hãy tối ưu inference trước.

Điều đáng giữ và điều nên bỏ qua

Điều đáng giữ từ hướng đi của Figma không phải là “canvas nào cũng phải có AI agent”. Cũng không phải “designer sắp code hết”. Cái đáng giữ là chiến lược: khi model nằm ngoài tay mình, hãy làm cho phần còn lại của hệ thống trở nên khó sao chép hơn.

Cụ thể:

Điều nên bỏ qua là nỗi FOMO rằng tool nào vừa ra cũng phải đưa vào stack. Một danh sách “top generative AI coding tools” có thể hữu ích để khảo sát thị trường, nhưng không thay cho quyết định kiến trúc. Tool mới chỉ là cầu thủ mới; bạn vẫn phải biết đội hình mình thiếu hậu vệ, tiền vệ hay người giữ nhịp.

Nếu là mình, mình sẽ chọn thế này

Với team builder ở Việt Nam, ngân sách và nhân lực thường không dư để thử mọi thứ. Mình sẽ ra quyết định theo thứ tự:

  1. Thuê model trước, trừ khi dữ liệu hoặc chi phí buộc phải khác.
  2. Kiểm soát context layer thật chặt, vì đây là nơi giảm hallucination — lỗi model bịa nhưng nói rất tự tin — và giảm token lãng phí.
  3. Đóng gói workflow tốt thành chuẩn team, thay vì để prompt nằm rải rác trong chat.
  4. Đặt human judgment ở các cổng quan trọng, không review mọi thứ bằng cảm tính nhưng cũng không thả agent chạy mù.
  5. Chỉ đổi model khi có bằng chứng bottleneck nằm ở model.

Sau bài này, điều mình mong bạn nghĩ khác là: AI product không thắng chỉ nhờ model mạnh hơn; nó thắng nhờ biết lớp nào cần thuê, lớp nào cần sở hữu, và lớp nào nhất định phải để con người cầm còi.

Còn nếu một tool mới hứa sẽ làm thay cả designer, developer, PM và QA trong một cú prompt, mình xin giơ thẻ vàng trước đã.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo