Vì sao AI dở ở front-end

Nghe bài viết:

AI là một “tay dev wannabe” thích chiều lòng người dùng, đã lướt qua một núi tutorial. Những gì bạn nhận được thực chất là kết quả của một phép đoán xác suất dựa trên các mẫu mà nó từng thấy trong quá trình huấn luyện. Nó được huấn luyện trên gì? Những giải pháp cũ kỹ, các mẫu UI thiếu sáng tạo, và một đống nội dung nhạt nhòa bị pha loãng.

Tôi sắp than phiền về việc điều này vừa hữu ích vừa đáng chán như thế nào.

Vì sao AI dở ở front-end

Điều tốt

AI rất thích những việc nhàm chán. Nó phát huy tốt nhất ở những công việc tầm trung, có tính lặp lại.

Nếu bạn muốn một giao diện an toàn, quen thuộc, không quá sáng tạo nhưng hoàn thành nhanh, AI sẽ hỗ trợ khá tốt 😜

Scaffolding: Việc dựng khung dựa trên các mẫu quen thuộc mà nó từng thấy? Làm được.

Tokens: Di chuyển token hoặc lập sơ đồ hệ thống token? Nó xử lý những việc tẻ nhạt này khá ổn.

Phác thảo tính năng: Những danh sách tính năng mang tính khái quát? Không thành vấn đề.

Tự tin đưa ra kết quả sai: Đây là một “đặc sản”. Nó sẽ ném cho bạn một đoạn code trông có vẻ hợp lý, phủi tay và tuyên bố công việc đã xong. Nhưng thực tế thì chưa.

Nói ngắn gọn: nếu đó là một mẫu đã được dùng đi dùng lại, AI giúp bạn copy-paste nhanh hơn. Và với khá nhiều công việc lập trình, điều đó thực sự hữu ích. Cá nhân tôi cũng đã nhận được không ít giá trị từ kiểu hỗ trợ này.

Điều tệ

Sự hoàn hảo đến từng pixel hay những giải pháp được thiết kế riêng? Đó không phải thế mạnh của AI.

Ngay khi bạn bước ra khỏi con đường quen thuộc của những mẫu có sẵn, nó bắt đầu gặp vấn đề.

Khi yêu cầu các tương tác tùy biến như animation theo cuộn trang hay micro-interaction đặc thù, AI thường bịa ra những đoạn CSS kỳ quặc như thể đang sống ở thời Internet Explorer 6.

Với bố cục và khoảng cách, vấn đề còn rõ hơn. Front-end hiện đại đòi hỏi xử lý rất nhiều phép tính động liên quan đến kích thước nội tại, ngoại tại, responsive layout và hành vi render thực tế. Đây không phải điểm mạnh của một mô hình vốn đã không giỏi toán học.

Quản lý state phức tạp cũng là một điểm yếu khác. Khi component bắt đầu có nhiều trạng thái kết hợp, việc xác định chính xác cần chỉnh sửa ở đâu trở nên khó khăn rõ rệt.

Khả năng truy cập cũng không khá hơn. AI thường áp dụng các thuộc tính như aria-hidden="true" một cách máy móc, như thể ném giải pháp vào tường rồi hy vọng nó bám lại.

Về hiệu năng, nếu bạn không chủ động yêu cầu tối ưu, nó thường đưa ra giải pháp nặng nề, dư thừa và dễ gây giật lag.

Còn kiểm thử? Nó có thể viết rất nhiều test, nhưng số lượng không đồng nghĩa với chất lượng.

Điều thú vị nhất là component càng phức tạp thì chất lượng hỗ trợ front-end của AI càng giảm. Nó có thể tạo ra một giao diện đầu tiên khá ổn chỉ trong một lần, nhưng lại chật vật với những yêu cầu chỉnh sửa tiếp theo. Điều đó cho thấy rất rõ nó mạnh ở việc tái tạo mẫu quen thuộc hơn là hiểu sâu để phát triển tiếp.

Vì sao?

1. Nó được huấn luyện trên dữ liệu cũ

AI thiếu dữ liệu huấn luyện thực sự hiện đại.

Internet chứa đầy các template, snippet và giải pháp đại trà, nên không ngạc nhiên khi AI dựa rất nhiều vào những mẫu đó. Với các kỹ thuật CSS hiện đại, khả năng cập nhật của nó thường không thật sự đáng tin.

2. Nó thực sự không thể nhìn

Nó là một LLM, không phải rendering engine.

Nó không render giao diện như trình duyệt. Nó không “nhìn thấy” kết quả như con người nhìn thấy một trang web thực tế.

Vì vậy mới xuất hiện kiểu hội thoại quen thuộc:

AI: “Tôi xong rồi, đây là giao diện hoàn hảo.”
Tôi: “Icon bị mất hoàn toàn.”
AI: “Bạn hoàn toàn đúng, để tôi sửa lại.”

Ngay cả khi bạn cung cấp screenshot, khả năng phân tích thị giác của nó vẫn không tương đương với việc hiểu chính xác điều gì đang xảy ra trong DOM, CSS cascade hay layout engine.

3. Nó không hiểu vì sao chúng ta thiết kế như vậy

AI không thực sự hiểu động cơ đằng sau các quyết định kiến trúc.

Nó có thể bắt chước pattern, nhưng không nhất thiết hiểu tại sao pattern đó tồn tại.

Những phương pháp như SDD, BDD hay state machine có thể giúp định hướng đầu ra tốt hơn, nhưng bản thân các mô hình này không được huấn luyện sâu với vô số ví dụ chất lượng cao theo đúng ngữ cảnh đó.

Thực chất, chúng ta đang yêu cầu một cỗ máy dự đoán văn bản khổng lồ tạo ra các kết nối thiết kế hợp lý ngay tức thì. Nó có thể làm được đến một mức nào đó, nhưng thường chỉ khi con người mô tả cực kỳ chi tiết.

4. Không có quyền kiểm soát môi trường thực thi

AI không kiểm soát được môi trường nơi đoạn code sẽ chạy.

Đó là lý do nó thường làm tốt hơn với Rust, Python hay TypeScript thuần logic — những môi trường có thể dự đoán, có thể cố định phiên bản, và ít biến số hơn.

Front-end thì ngược lại.

HTML và CSS phải chạy trong một môi trường hỗn loạn: trình duyệt khác nhau, phiên bản khác nhau, kích thước màn hình khác nhau, thiết bị khác nhau, phương thức nhập liệu khác nhau, tùy chọn accessibility khác nhau, dark mode, touch input, keyboard navigation, voice interaction…

Và đó mới chỉ là phần nổi.

Rendering engine phải xử lý hàng loạt ngữ cảnh, điều kiện và biến số trước khi hiển thị kết quả cuối cùng. LLM không kiểm soát được những yếu tố đó, nên mặc định sẽ bỏ qua chúng trừ khi bạn chủ động chỉ rõ.

Ngay cả những kỹ thuật CSS nên được xem là mặc định tốt, bạn vẫn phải yêu cầu cụ thể. Và kể cả khi đã cung cấp tài liệu hay hướng dẫn chi tiết, đầu ra đúng vẫn không được đảm bảo.

Front-end là một mục tiêu luôn thay đổi. LLM vốn không giỏi với kiểu mục tiêu như vậy.

Vấn đề còn nằm ở con người

Con người là biến số khiến mọi thứ phức tạp hơn nhiều.

Chúng ta không hành xử theo một mẫu cố định. Có lúc đổi ý giữa chừng, có lúc chuyển từ desktop sang điện thoại, đổi trình duyệt, thay phiên bản trình duyệt, chuyển từ chuột sang cảm ứng, bật dark mode rồi lại tắt, thay đổi preference accessibility hoặc đơn giản là sử dụng sản phẩm theo cách mà không ai dự đoán trước.

LLM hoạt động tốt khi có những mẫu hành vi phổ biến đủ lớn để học theo. Nhưng toàn bộ phổ hành vi thực tế của con người thì hỗn loạn hơn rất nhiều.

Ít nhất ở thời điểm hiện tại, đó vẫn là một bài toán mà AI chưa thể xử lý tốt.