Góc nhìn của kỹ sư frontend về quy trình thiết kế-sản phẩm mới trong kỷ nguyên AI
Một con số không tưởng
12 ngày. Hai người: một nhà thiết kế sản phẩm và một kỹ sư frontend. Một lần tái xây dựng nền tảng hoàn chỉnh.
Không phải nguyên mẫu. Không phải MVP. Là sự thay thế hoàn toàn một ứng dụng đang vận hành, kết thúc bằng một PR duy nhất xóa 26,000 dòng mã cũ. Mỗi trang, mỗi tuyến, mỗi tương tác đều được xây dựng lại từ đầu và chuyển giao cho người dùng thực tế.
Trong bất kỳ quy trình phát triển sản phẩm truyền thống nào, tiến độ này là phi lý. Một dự án quy mô này thường mất hàng tháng: nhiều tuần khám phá thiết kế trên Figma, các vòng duyệt của các bên liên quan, lễ bàn giao, lên kế hoạch sprint, rồi quá trình thực thi tỉ mỉ từng pixel. Những gì diễn ra ở đây hoàn toàn khác biệt. Không phải vì chúng tôi làm việc chăm chỉ hơn, mà vì cách chúng tôi phối hợp đã thay đổi.
Đây là câu chuyện về cách chúng tôi ra mắt nền tảng Zero tại VM0, và những gì tôi học được về tương lai của sự hợp tác giữa thiết kế và kỹ thuật sản phẩm.
Nút thắt cổ chai cũ
Mọi kỹ sư frontend đều biết quy trình truyền thống:
- Nhà thiết kế tạo mockup trên Figma
- Duyệt thiết kế, lặp lại, phê duyệt
- Tài liệu chú thích với khoảng cách, màu sắc, điểm ngắt
- Kỹ sư chuyển đổi thông số hình ảnh thành mã
- Qua lại: "Bạn có thể di chuyển cái này sang trái 4px không?"
- Cuối cùng, kết nối với lớp API
- Kiểm thử tích hợp, lại tiếp tục trao đổi
Nút thắt không nằm ở bất kỳ bước nào riêng lẻ. Nó nằm ở khoảng cách giữa các bước: chờ đợi, mất mát khi chuyển đổi, chuyển đổi ngữ cảnh. Mô hình tư duy của nhà thiết kế về một tương tác, khi bị làm phẳng thành khung Figma tĩnh và chú thích bằng đường đỏ, đến tay kỹ sư đã bị giảm chất lượng. Kỹ sư xây dựng lại một phiên bản theo tưởng tượng của nhà thiết kế, nhưng không tránh khỏi là một bản sao bị mất mát.
Chúng ta đã quá quen với sự ma sát này đến mức không còn nhận ra nó. Đó chỉ là "cách mọi thứ vận hành".
Thử nghiệm: Nếu nhà thiết kế tự chuyển giao mã?
Ngày 5 tháng 3 năm 2026, Ming, nhà thiết kế sản phẩm của chúng tôi, mở PR #3685: feat(platform): add zero app with shell, pages and polish. Nó bổ sung 4,146 dòng mã React hoạt động.
Không phải file Figma. Không phải xuất token thiết kế. Là một ứng dụng đang chạy.
PR này chứa toàn bộ khung ứng dụng: điều hướng sidebar, cấu trúc tuyến, khung trang cho chat, lịch biểu, hoạt động, quản lý nhóm và cài đặt, tất cả đều được tạo kiểu với hệ thống thiết kế của chúng tôi, hiển thị trực tiếp trên trình duyệt. Dữ liệu được giả lập, nhưng giao diện là thật. Bạn có thể npm run dev và nhấp qua từng trang.
Ming không viết mã này từ đầu theo cách truyền thống. Cô ấy sử dụng công cụ lập trình AI (đầu tiên là Cursor, sau đó là Claude Code) để chuyển đổi trực tiếp ý tưởng thiết kế thành các thành phần React. AI xử lý phần chuyển đổi kỹ thuật (cấu trúc JSX, thuộc tính CSS, tổ hợp thành phần), còn Ming quyết định các yếu tố thị giác và tương tác mà AI không thể thay thế: nhịp điệu bố cục, thứ bậc thông tin, cảm giác chuyển động.
Bốn ngày tiếp theo, ba PR nữa được gửi lên:
| Ngày | PR | Ming đã chuyển giao |
|---|---|---|
| Mar 5 | #3685 | Khung ứng dụng, sidebar, tất cả khung trang (+4,146 dòng) |
| Mar 6 | #3825 | Trang lịch biểu, hoàn thiện giao diện (+2,650 dòng) |
| Mar 9 | #3993 | Quy trình onboarding, hộp thoại cấu hình Slack (+1,146 dòng) |
| Mar 9 | #4050 | Trang giới thiệu, thẻ điều hướng nổi |
Đến ngày 9 tháng Ba, toàn bộ giao diện frontend của nền tảng mới đã tồn tại dưới dạng mã chạy được. Mỗi trang mà bạn sẽ thấy trên môi trường thực tế đều đã có thể nhấp thử trong môi trường dev. Chỉ là nó chưa thực hiện chức năng thực tế nào.
Đó là lúc tôi tham gia.
Công việc mới của tôi: Thổi hồn vào sản phẩm
Khi tôi mở mã nguồn ngày 9 tháng Ba, tôi không còn đối mặt với thách thức quen thuộc là chuyển đổi thiết kế phẳng thành mã. Mã đã có sẵn. Việc của tôi là thay thế mọi dữ liệu giả lập bằng dữ liệu thực, kết nối từng bề mặt thiết kế đẹp mắt với backend sống động phía dưới.
Điều này thay đổi căn bản cách tôi làm việc. Thay vì nghĩ về pixel, tôi nghĩ về luồng dữ liệu. Thay vì hỏi "cái này có giống mockup không?", tôi hỏi "trang này cần gọi API nào, và nếu thất bại thì sao?"
Đây là tuần đầu tiên của tôi:
Ngày 1 (9 tháng Ba): Xác thực và chuyển đổi tổ chức. Tôi kết nối khung ứng dụng của Ming với xác thực Clerk, thêm chuyển hướng đa miền, và làm cho bộ chuyển đổi tổ chức hoạt động thực sự. Hai PR, đều được merge trong ngày.
Ngày 2 (10 tháng Ba): Kết nối và lịch biểu. Tôi thay thế lưới kết nối giả lập bằng dữ liệu API thực, kết nối tab lịch biểu với các cron job thực tế, và liên kết trình chỉnh sửa hướng dẫn với backend. Bốn PR.
Ngày 3 (11 tháng Ba): Ngày kết nối lớn. Trang nhóm nhận dữ liệu subagent thực (+3,271 dòng). Trang hoạt động nhận log thực. Và điểm nhấn: trang chat được kết nối với pipeline chạy agent thực, thay thế ~1,200 dòng mã demo bằng giao diện hội thoại AI hoạt động. Cùng ngày, tôi giới thiệu FeatureSwitchKey.Zero, một cờ tính năng cho phép chạy song song nền tảng cũ và mới.
Ngày 4-5 (12-13 tháng Ba): Đính kèm tệp, quản lý phiên, chat đa agent, lưu cài đặt. Mỗi trang Ming xây dựng giờ đều hoạt động thực sự.
Nhịp độ làm việc gần như âm nhạc. Mỗi sáng tôi chọn một trang từ khung của Ming, nghiên cứu cấu trúc thành phần, xác định dữ liệu cần thiết, xây dựng tích hợp API, xử lý trạng thái lỗi và đẩy lên. Đến chiều, lại có thêm một trang hoạt động.
Công tắc tính năng: Hai thế giới song song
Cờ tính năng FeatureSwitchKey.Zero xứng đáng được nhắc riêng, vì nó giúp quá trình chuyển đổi này an toàn thay vì liều lĩnh.
Từ ngày 11 tháng Ba, ứng dụng sản xuất của chúng tôi chạy song song hai giao diện hoàn chỉnh. Người dùng hệ thống cũ vẫn thấy các tuyến cũ. Người kiểm thử nội bộ trên hệ thống mới thấy Zero. Mỗi trang tôi kết nối đều có thể kiểm thử trong môi trường thực tế mà không ảnh hưởng đến quy trình của bất kỳ người dùng nào.
Điều này không phải là cách mạng. Cờ tính năng là thực tiễn tiêu chuẩn. Nhưng sự kết hợp giữa cờ tính năng và quy trình thiết kế như mã tạo ra điều đặc biệt: chúng tôi có thể kiểm chứng toàn bộ trải nghiệm người dùng của nền tảng mới (vì Ming đã xây dựng giao diện hoàn chỉnh, có thể duyệt), đồng thời từng bước làm cho từng trang hoạt động (vì tôi kết nối từng trang một). Nếu có sự cố, chỉ cần chuyển lại công tắc.
Không có sự cố nào xảy ra.
Ngày 12: Bật công tắc lớn
Ngày 17 tháng Ba, tôi mở PR #5095: refactor: remove all non-zero platform pages and feature flag.
Sự khác biệt: +456 dòng, -26,041 dòng.
Trước: VM0 Platform cũ. Bảng, ID run, và dữ liệu phiên thô.
Sau: Zero mới. Không gian làm việc AI hội thoại với agent được ghim và thẻ trường hợp sử dụng.
Chỉ với một lần merge, mọi tuyến cũ đều bị xóa. Cờ tính năng bị loại bỏ. Zero không còn là tùy chọn; nó là chế độ duy nhất. Một PR tiếp theo (#5155) loại bỏ hoàn toàn tiền tố URL /zero: những gì từng là /zero/chat giờ chỉ còn là /chat.
Tại sao tôi tự tin thực hiện bước này? Vì:
- Mỗi trang đã chạy dưới cờ tính năng ít nhất 5 ngày
- Mỗi tích hợp API đều được kiểm thử với dữ liệu thực tế
- Hệ thống cũ và mới dùng chung backend. Đây chỉ là thay đổi frontend, không phải di chuyển dữ liệu
- Chúng tôi có người dùng thực trên hệ thống mới phản hồi liên tục
26,000 dòng mã không bị xóa trong lo lắng. Chúng bị xóa trong nhẹ nhõm.
Mô hình lặp lại
Điều khiến tôi bất ngờ nhất không phải là quá trình chuyển đổi. Mà là quy trình chúng tôi phát hiện ra đã trở thành mặc định cho mọi tính năng tiếp theo. Ming xây dựng khung giao diện với sự hỗ trợ của AI, tôi kết nối logic và mở rộng kiến trúc. Cùng một mô hình thiết kế như mã, ở quy mô tính năng:
Hệ thống phân quyền (19 tháng 3 → 7 tháng 4)
Ming gửi PR #5467, giao diện ngăn kéo phân quyền với thành phần Sheet và nút chuyển đổi. Ba lần commit, giao diện sạch sẽ.
Tôi thêm 13 commit vào cùng PR: di chuyển cơ sở dữ liệu cho firewall_access_requests, endpoint API, kiểm thử tích hợp, sửa lint. Hai tuần tiếp theo, hơn 10 PR bổ sung xây dựng đầy đủ lớp phân quyền: thiết kế lại thẻ phê duyệt, thông báo Slack cho yêu cầu truy cập, lệnh CLI doctor để chẩn đoán vấn đề phân quyền, và cuối cùng đổi tên toàn bộ khái niệm từ "firewall" thành "permission" trong mã nguồn.
Ngăn kéo của Ming là hạt giống. Hệ thống phân quyền là cái cây.
Hệ thống lịch biểu (23 tháng 3 → 13 tháng 4)
Ming thiết kế tuyến chi tiết lịch biểu và trải nghiệm lịch (#6155). Ba lần commit giao diện sạch sẽ.
Tôi thêm 14 commit: chỉnh sửa mô tả với tự động sinh, chọn kênh Slack cho thông báo, hộp thoại xác nhận khi chưa lưu, hợp nhất chế độ xem lịch/danh sách, và kiểm thử toàn diện. Sau đó, hơn 15 PR tiếp theo mở rộng thành hệ thống tác vụ định kỳ hoàn chỉnh với lịch sử run, xử lý múi giờ và hỗ trợ biểu thức cron.
Tích hợp Telegram (27 tháng 4 → 28 tháng 4)
Đến thời điểm này, quy trình đã thành thạo đến mức chúng tôi triển khai tích hợp nền tảng hoàn chỉnh chỉ trong 48 giờ. Ming xây dựng giao diện Cài đặt (#11196) và quy trình Onboarding (#11399). Tôi xây dựng API đa bot, gửi/nhận tin nhắn, tải lên/xuống tệp, ngữ cảnh tin nhắn phong phú, cập nhật thời gian thực qua Ably, và kiểm thử E2E. Ngày hôm sau, tính năng được bật cho toàn bộ người dùng.
Vai trò của AI
Tôi muốn nói rõ về vai trò của AI ở đây, vì rất dễ bị thổi phồng hoặc đánh giá thấp.
AI giúp nhà thiết kế viết mã. Ming là nhà thiết kế sản phẩm, không phải kỹ sư phần mềm. Cô ấy tư duy về bố cục, thứ bậc, tương tác, không phải hook React hay generic TypeScript. Công cụ AI (Cursor, rồi Claude Code) lấp đầy khoảng cách đó bằng cách chuyển đổi ý định thiết kế thành mã hoạt động. Ming chỉ đạo; AI gõ phím. Kết quả là mã do nhà thiết kế tạo ra nhưng kỹ sư có thể phát triển tiếp.
AI tăng tốc vòng lặp kiểm tra. Ở các PR hợp tác, AI agent của tôi sẽ kiểm tra mã của Ming, phân loại vấn đề theo mức độ ưu tiên (P0/P1/P2), và đẩy commit sửa trực tiếp. PR #5060 trải qua năm vòng kiểm tra trong 38 phút. PR #5467 hoàn thành ba vòng trong 20 phút. Đây không phải "AI thay thế kiểm tra mã". Tôi vẫn đọc từng thay đổi. Nhưng các việc máy móc như phát hiện lỗi lint, thiếu kiểu, thiếu kiểm thử đều được tự động hóa.
AI không quyết định thiết kế. Kiến trúc thông tin của từng trang, mẫu tương tác, thứ bậc thị giác: tất cả đến từ trực giác sản phẩm của Ming, dựa trên nghiên cứu người dùng và hiểu biết lĩnh vực. AI có thể sinh ra một trang cài đặt, nhưng không thể quyết định cái gì nên là nút chuyển đổi, cái gì là dropdown, khi nào cần hộp thoại xác nhận và khi nào thì không.
AI không quyết định kiến trúc. Việc chọn dùng cờ tính năng để triển khai song song, chiến lược tách lớp API, quyết định kết nối từng trang thay vì tất cả cùng lúc: đều là quyết định kỹ thuật của con người. AI giúp tôi viết mã nhanh hơn, nhưng trình tự và quản lý rủi ro là do con người quyết định.
Tóm lại: AI loại bỏ lớp chuyển đổi giữa thiết kế và kỹ thuật. Nó không thay thế lĩnh vực nào; nó xóa bỏ khoảng cách giữa hai bên.
Vai trò của tôi đã thay đổi thế nào
Sau ba tháng sống trong quy trình này, tôi nhìn nhận vai trò kỹ sư frontend của mình khác đi.
Tôi không còn là người chuyển đổi hình ảnh sang mã. Ngày nhận file Figma và ngồi hàng giờ căn chỉnh khoảng cách đã qua. Không phải vì tôi làm nhanh hơn, mà vì đó không còn là việc của tôi. Ý định của nhà thiết kế đến dưới dạng mã, không phải hình ảnh mã.
Tôi là người mở rộng kiến trúc. Giá trị chính của tôi là nhận một giao diện hoạt động và xây dựng hạ tầng vô hình bên dưới: tích hợp API, kiểm tra dữ liệu, xử lý lỗi, kiểm tra quyền, cập nhật thời gian thực, kiểm thử. Tỷ lệ commit trên các PR hợp tác nói lên tất cả. Ming đóng góp 3 commit giao diện, tôi đóng góp 13 commit cho phần còn lại.
Tôi là người kiểm soát chất lượng. Với vòng lặp kiểm tra hỗ trợ AI, tôi có thể duy trì chất lượng mã trên diện rộng hơn trước. Kiểm tra tự động bắt các lỗi máy móc; tôi tập trung vào kiến trúc, trường hợp biên và đảm bảo tính năng hoạt động đầu-cuối.
Tôi là người chiến lược chuyển giao. Cờ tính năng, kết nối từng phần, triển khai song song: trình tự đưa tính năng từ mã ra sản xuất giờ là phần cốt lõi công việc của tôi, không còn là suy nghĩ sau cùng.
Những con số
Ba tháng. Hai người. Luôn có AI hỗ trợ.
- 914 PR đã merge (679 của tôi, 235 của Ming)
- 12 ngày từ khung đầu tiên đến thay thế toàn bộ nền tảng
- 48 giờ cho tích hợp Telegram hoàn chỉnh (tính năng nhanh nhất)
- 26,000 dòng bị xóa chỉ trong một lần merge tự tin
- 88% PR của tôi và 66% của Ming có đồng tác giả AI
Đây không phải chỉ số làm việc quá sức. Không ai làm cuối tuần hay thức trắng đêm. Tốc độ đến từ việc loại bỏ thời gian chết: họp bàn giao, hiểu sai tài liệu, trao đổi "di chuyển 4px". Khi ý định thiết kế đi thẳng vào mã, và kỹ sư mở rộng mã đó tại chỗ, lãng phí giảm đi rõ rệt.
Ý nghĩa với các nhóm
Tôi không nói mọi nhóm đều nên làm như vậy. Quy trình này xuất phát từ bối cảnh riêng: nhóm nhỏ, cơ hội xây mới hoàn toàn, và tiếp cận sớm công cụ AI lập trình mạnh. Kết quả của bạn có thể khác.
Nhưng tôi tin sự thay đổi nền tảng là phổ quát: ranh giới giữa thiết kế và kỹ thuật đang mờ dần, và AI là chất xúc tác. Khi AI ngày càng giỏi chuyển ý định thành mã, nhiều nhà thiết kế sẽ trực tiếp chuyển giao mã. Khi đó, kỹ sư sẽ dành ít thời gian chuyển đổi, nhiều thời gian hơn cho kiến trúc, chất lượng và chuyển giao.
Công việc kỹ sư frontend không biến mất. Nó đang thay đổi hình dạng. Và thật lòng? Hình dạng mới thú vị hơn nhiều.
Yuma là kỹ sư frontend tại VM0, nơi anh xây dựng nền tảng vận hành Zero, hệ điều hành AI agent. Anh đã xóa nhiều mã cũ hơn mức muốn thừa nhận.
