AI và sự "hạ cấp" kỹ năng lập trình: Bài học từ thập kỷ mất mát của Frontend

Những gì AI đang làm với công việc của các lập trình viên hiện nay cảm thấy vô cùng quen thuộc với nhiều người làm phát triển Frontend (giao diện) – bởi vì chúng ta đã từng trải qua chuyện này rồi.

Hãy cùng nhìn lại sự chuyển biến của Frontend và lập trình dựa trên tác nhân AI (agentic coding) dưới lăng kính của sự "hạ cấp kỹ năng" (deskilling), sau đó xem xét cả hai thay đổi này ở mức độ trừu tượng hóa cao hơn. Cuối cùng, chúng ta sẽ xem xét những thay đổi trong quá khứ, như sự trỗi dậy của việc copy-paste từ Stack Overflow, và cách phong trào Bauhaus phản ứng lại sự công nghiệp hóa gia tăng.

Sự hạ cấp kỹ năng

Cũng giống như AI đang hạ cấp kỹ năng lập trình hiện nay, các framework JavaScript đã hạ cấp kỹ năng phát triển Frontend trong thập kỷ qua. Là một người bắt đầu với HTML/CSS và một chút PHP, sau đó làm việc với Ruby on Rails, và từng là trưởng nhóm Frontend của một tờ báo lớn Thụy Sĩ (sử dụng Next.js lúc bấy giờ), tôi đã chứng kiến sự chuyển biến này tận mắt. Và không cần phải chỉ nghe tôi nói! Tôi không phải người đầu tiên đưa ra nhận định này. Alex Russell từng gọi đây là "Thập kỷ mất mát của Frontend" (Frontend’s Lost Decade).

Vậy sự hạ cấp kỹ năng là gì? Theo Wikipedia:

"Hạ cấp kỹ năng là quá trình loại bỏ lao động có tay nghề trong một ngành hoặc nền kinh tế thông qua việc giới thiệu các công nghệ được vận hành bởi người lao động bán chuyên hoặc không có tay nghề. Điều này dẫn đến tiết kiệm chi phí [...] và giảm rào cản gia nhập, làm suy yếu quyền lực thương lượng của [người lao động]."

Hãy xem điều này áp dụng như thế nào cho Frontend, và sau đó là cho lập trình tác nhân AI.

Sự hạ cấp của Frontend

Nhiều lập trình viên có thể không biết điều này, nhưng Frontend từng là một kỹ năng chuyên môn hóa cao, đòi hỏi kiến thức về HTML ngữ nghĩa, CSS, sự khác biệt của các trình duyệt, khả năng truy cập (accessibility), tăng cường tiến bộ (progressive enhancement), hiệu suất mạng, thiết kế giao diện và kiểm thử người dùng – chỉ để kể ra một vài thứ. Để phân biệt những gì họ đang làm với "Frontend" hiện nay, những người thực hành nghệ thuật huyền bí này ngày nay thường gọi nó là "mặt trận của Frontend" (front of the frontend).

Sự hạ cấp của Frontend là sự ra đời của các framework và công cụ khác nhau coi trình duyệt chỉ là một mục tiêu biên dịch – giống như bất kỳ môi trường chạy ứng dụng nào khác (ví dụ: JVM hoặc iOS). Sau đó, bạn có thể chỉ cần nạp vào "quái vật" đó là một nút radio từ Shadcn, mà không cần hiểu HTML bên dưới, bất kỳ sự tinh tế nào liên quan đến các trình duyệt khác nhau, hiệu suất tải trang và khả năng truy cập.

Như đoạn trích Wikipedia ở trên chỉ ra, điều này "dẫn đến tiết kiệm chi phí" cho các doanh nghiệp, vì sau đó họ có thể dễ dàng giao bất kỳ lập trình viên chung nào để làm việc trên Frontend. Thường thì một "lập trình viên full-stack" đáng buồn thay không phải là người hiểu sâu về cả Frontend và Backend, mà là một người tổng quát chỉ biết đủ để vặn vẹo một framework JavaScript để làm cả hai. Điều này cho phép các doanh nghiệp dễ dàng chuyển đổi lập trình viên giữa các dự án khác nhau. Cùng một người tổng quát đó thậm chí có thể làm cả ứng dụng native với React Native và Electron! Để hoàn thành câu trích Wikipedia: điều này "giảm rào cản gia nhập" (điều mà tôi luôn trân trọng), nhưng nó cũng "làm suy yếu quyền lực thương lượng của người lao động".

AI đang hạ cấp kỹ năng lập trình

Những gì đang xảy ra với các lập trình viên nói chung dường như rất giống với những gì các nhà phát triển web cụ thể đã trải qua. Công việc có tay nghề là viết code thủ công đang bị "loại bỏ bằng sự giới thiệu các công nghệ, được vận hành bởi người lao động bán chuyên hoặc không có tay nghề."

Chúng ta vẫn chưa biết chính xác bộ kỹ năng mà những người lao động điều khiển AI tác nhân sẽ cần phải có vào cuối sự chuyển đổi này, và ở mức giá nào chúng ta sẽ đạt được – cho cả lao động, và cho các mô hình LLM cục bộ và từ xa. Nhưng điều rõ ràng ngay bây giờ là các doanh nghiệp chắc chắn sẽ sử dụng công nghệ này để tiết kiệm chi phí và làm suy yếu quyền lực thương lượng của người lao động.

Cảm giác mất mát sâu sắc

Cũng giống như những người thợ thủ công và nghệ nhân bị thay thế bởi công nhân dây chuyền lắp ráp hơn một thế kỷ trước, chúng ta cảm thấy một sự mất mát sâu sắc. Chúng ta đau buồn vì một kỹ năng mà chúng ta đã dành nửa cuộc đời để mài giũa không còn được thị trường đánh giá cao nữa. Và chúng ta buồn bã vì quy trình mới tạo ra kết quả chất lượng thấp hơn, và rất nhiều người dường như không quan tâm.

Hoạt động ở mức độ trừu tượng hóa cao hơn

Một cách nhìn khác về "sự hạ cấp kỹ năng" tất nhiên là lập luận rằng đây chỉ là tăng hiệu quả sử dụng tự động hóa. Và kỹ sư nào mà không thích tự động hóa mọi thứ? Đó là một phần lớn trong công việc của chúng ta sau tất cả!

Trong cách nhìn này, công nghệ mới được giới thiệu đơn giản là hoạt động ở mức độ trừu tượng hóa cao hơn, cho phép người vận hành nó tập trung vào bức tranh lớn hơn, mà không phải bận tâm về các chi tiết không quan trọng. Nhưng chính xác thì những chi tiết nào được coi là "không quan trọng" là một quyết định rất quan trọng và đôi khi mang tính chủ quan. Và cuối cùng, các chi tiết đó luôn luôn bị rò rỉ ra ngoài.

Frontend "hiện đại": tháp của sự trừu tượng hóa rò rỉ

Một sự trừu tượng hóa thường đi kèm với chi phí về hiệu suất. Nhưng vì máy tính ngày nay rất nhanh, chúng ta thường sẵn sàng đánh đổi một chút hiệu suất thời gian chạy để tăng năng suất của lập trình viên (bộ thu gom rác là một ví dụ). Và đối với các máy chủ mạnh mẽ dưới tải vừa phải, đây là một sự đánh đổi rất hợp lý. Nhưng điện thoại di động trên mạng chậm lại là một câu chuyện khác.

Bằng cách sử dụng một framework JavaScript phía máy khách nặng nề như React và nhiều gói từ hệ sinh thái đó, bạn đang trừu tượng hóa hóa những thứ như khả năng truy cập và hiệu suất trên các điện thoại cấp thấp hoặc mạng chậm. Về hiệu quả, bạn đang chọn không suy nghĩ về những thứ đó, và bạn chọn không quan tâm đến chúng.

Lập trình tác nhân AI: một sự trừu tượng hóa không xác định

Bằng cách sử dụng AI tác nhân để viết một tính năng hoặc sửa lỗi, bạn đang mô tả thay đổi ở mức độ trừu tượng hóa cao hơn, viết ít từ hơn so với việc viết tất cả code bằng tay. AI sẽ điền vào các chi tiết bạn bỏ sót bằng cách nhìn vào dữ liệu đào tạo và bối cảnh xung quanh – đôi khi đoán đúng, đôi khi không. Việc bạn thấy điều này hữu ích hay không phụ thuộc phần lớn vào quan điểm của bạn về điều gì là quan trọng khi lập trình.

Nhưng so với các sự trừu tượng hóa trước đây trong lập trình, lập trình tác nhân AI là một sự trừu tượng hóa rất rò rỉ. Nó không xác định như một trình biên dịch, và các biến thể nhỏ trong đầu vào hoặc mô hình có thể cho ra kết quả rất khác nhau. Điều này đã khiến mọi người so sánh AI với "kỹ sư cấp junior", vì những người đó cũng không xác định. Nhưng một sự khác biệt là con người có khả năng học hỏi, mà không cần bạn phải liên tục tinh chỉnh các tệp AGENTS.md hoặc SKILL.md của họ.

LLM như một phần mở rộng của việc copy-paste từ Stack Overflow

Như vậy, sự tương đồng tốt nhất tôi tìm thấy cho việc sử dụng LLM cho đến nay là cách một tìm kiếm Google từng hoạt động. Đó là một kỹ năng mà tất cả chúng ta đều phải học vào một thời điểm nào đó: chọn đúng từ khóa, để bài đăng diễn đàn phù hợp (và sau này là bài đăng Stack Overflow) xuất hiện trên trang kết quả đầu tiên của Google. Cũng giống như việc gợi ý (prompt) cho một LLM, để trả về tập hợp đúng dữ liệu đào tạo của nó, một tìm kiếm web mờ là một tra cứu trong một không gian chiều rất cao. Và giống như với LLM, việc tra cứu từng rất nhạy cảm với những thay đổi nhỏ của cách diễn đạt và thay đổi chỉ mục tìm kiếm của Google.

Trong những năm gần đây, cùng với những thứ khác, Google đã thay đổi tìm kiếm để chuẩn hóa các thuật ngữ nhập vào mạnh mẽ hơn nhiều. Đối với những người không thành thạo nghệ thuật tối thượng Google-fu, điều này làm cho tìm kiếm dễ sử dụng hơn nhiều. Nhưng đối với những người trong chúng ta đã có kỹ năng đó, nó làm cho tìm kiếm Google kém mạnh mẽ hơn nhiều. Các từ khóa chuyên biệt từng đưa chúng ta trực tiếp đến một câu trả lời. Bây giờ chúng bị chuẩn hóa thành một từ đồng nghĩa, hoặc một từ liên quan chặt chẽ, và chúng ta kết thúc trên một trang chung chung hơn.

Nhưng sự ra đời của Google, và sau đó là Stack Overflow, đã thay đổi lập trình một cách không thể đảo ngược. Thay vì đọc cái đống tài liệu hướng dẫn (RTFM), các lập trình viên giờ đây có thể chỉ cần mù quáng copy & paste các câu trả lời từ Stack Overflow, và đáng ngạc nhiên là thường nhận được một thứ gì đó hoạt động ổn. Nhìn dưới lăng kính này, LLM chỉ là sự tiếp tục của cùng một xu hướng: các công cụ và sự trừu tượng hóa làm cho những người biết mình đang làm gì nhanh hơn một chút, và cho phép những người thực sự không biết mình đang làm gì đạt được một thứ gì đó thường hoạt động ổn. Và bạn biết đấy không? Điều đó thật tuyệt!

Nhưng chúng ta không nên tự lừa mình: tại một số điểm, sự trừu tượng hóa sẽ bị rò rỉ. Và sau đó ai đó phải đầu tư thời gian để thực sự hiểu sâu những gì đang diễn ra – và sửa chữa nó. Cũng giống như chúng ta đã dạy các lập trình viên cấp junior đọc và hiểu câu trả lời Stack Overflow trước khi sử dụng nó, bây giờ chúng ta cần dạy mọi người đọc và hiểu những thứ mà LLM nhả ra, và hiểu nó phù hợp với cơ sở mã hiện tại như thế nào.

Chất lượng có quan trọng không?

Thật không may, một số lập trình viên chưa bao giờ tiến đến giai đoạn cố gắng thực sự hiểu câu trả lời Stack Overflow. Tại sao phải làm phiền nếu nó hoạt động? Và trong khi không được công khai thừa nhận, rất nhiều công ty thực sự hạnh phúc với cách tiếp cận này. Điều khác biệt bây giờ là các công ty đi xa hơn để công khai tuyên bố họ đang sử dụng AI bao nhiêu, mà không cần giả vờ nhìn vào kết quả đầu ra.

Mặc dù chắc chắn có các trường hợp sử dụng hợp lệ cho LLM, nhưng cũng có nhiều cách mới để làm hỏng mã của bạn, và làm hỏng giao tiếp và quy trình của tổ chức bạn. Điều này dường như đặc biệt khó khăn để tìm ra như một nhóm. Cũng giống như với xem xét mã (code review), có rất nhiều quan điểm khác nhau về cách sử dụng và tích hợp LLM vào quy trình làm việc của chúng ta (nếu có). Và nếu nhóm không thống nhất về những thứ họ coi trọng, điều này thực sự có thể gây rắc rối lớn.

Đó cũng là một sự thật buồn của cuộc sống rằng rất nhiều công ty đang hoạt động rất tốt, mặc dù họ đang churn ra (sản xuất ồ ạt) phần mềm tồi tệ. Mặc dù chúng tôi - các lập trình viên - muốn tin, thành công kinh doanh và chất lượng phần mềm rất ít khi tương quan. Thông thường, các yếu tố khác chiếm ưu thế. Thường thì các dự án phần mềm được coi như những hộp đen, được biết là thất bại thường xuyên như chúng thành công, và được giảm rủi ro theo nhiều cách khác nhau (trong trường hợp tồi tệ nhất, một nhóm khác sẽ có cơ hội khác).

Và điều tương tự cũng xảy ra đối với phát triển Frontend. Thật không may, một trang web tồi tệ có tác động tương đối nhỏ đến lợi nhuận ròng. Một trang web chậm và rất nhiều biểu ngữ cookie có làm tổn thương tỷ lệ chuyển đổi không? Chắc chắn, nhưng hiệu ứng đó tương đối nhỏ so với các yếu tố khác như lòng trung thành của thương hiệu và định giá. Và tất cả các đối thủ cũng có các trang web chậm! Ngoài ra, chưa ai từng bị sa thải vì chọn React.

Điều đó có nghĩa là chúng ta nên ngừng quan tâm đến người dùng và nghề thủ công của mình không? Không. Nhưng điều đó có nghĩa là việc tìm một công việc nơi bạn được phép làm như vậy đã trở nên khó khăn hơn nhiều. Hy vọng rằng, con lắc sẽ dao động lại một chút, once cơn sốt đã qua đi, và chúng ta có sự hiểu biết tốt hơn về những nhiệm vụ nào LLM thực sự phù hợp và những nhiệm vụ nào không. Nhưng có thể nói chắc chắn rằng nghề nghiệp của chúng ta sẽ không còn giống như trước đây nữa.

Phong trào Bauhaus

Các thế hệ người thợ thủ công trước đây đã làm gì khi hàng hóa và tòa nhà hàng ngày đột nhiên có thể được sản xuất hàng loạt bằng các quy trình công nghiệp? Một phản ứng là sao chép phong cách cũ, và khiến công nghiệp crank ra các tiện ích và tòa nhà trông ít nhất như thể chúng được làm thủ công.

Để chống lại xu hướng lịch sử này, một cách tiếp cận thay thế đã được phát triển bởi phong trào Bauhaus đầu thế kỷ 20. Thay vì đặt công nhân nhà máy chống lại người thợ thủ công, mục tiêu được tuyên bố của họ là để họ làm việc cùng nhau, và phát triển lại nghệ thuật và thủ công với các quy trình sản xuất công nghiệp trong tâm trí. Bauhaus thúc đẩy các nhà thiết kế quay lại các xưởng, và làm việc trực tiếp với vật liệu. Vẫn với mục tiêu đến được các thiết kế sau đó sẽ được sản xuất hàng loạt. Nhưng luôn luôn giữ người dùng cuối trong tâm trí và quan tâm sâu sắc đến họ. Thiết kế công nghiệp hiện đại, như được thể hiện bởi Dieter Rams và Jonathan Ive, có thể truy nguyên nguồn gốc của nó trực tiếp trở lại Bauhaus.

Quan tâm đến chất lượng và người dùng

Làm thế nào chúng ta có thể dịch dòng tư duy này sang phần mềm?

Phần mềm nằm ở đâu đó giữa nghề thủ công ở một phía (chương trình chúng ta viết được gửi "nguyên trạng" cho người dùng của chúng ta, mà không cần trải qua bước sản xuất trước), và thiết kế công nghiệp ở phía kia (chúng tôi gửi cùng một thứ cho hàng nghìn người dùng tiềm năng, những người chúng ta không bao giờ thấy tương tác với sản phẩm của chúng ta).

Nhu cầu có thể viết code bằng tay là rõ ràng. Cũng giống như các nhà thiết kế công nghiệp cần biết vật liệu mà sản phẩm của họ sẽ được làm từ đó, một nhà thiết kế web cần phải thân thuộc với HTML và CSS.

Mặc dù thật tuyệt vời rằng các công cụ như Google, Stack Overflow, các thư viện sẵn sàng sử dụng, và bây giờ là LLM đang làm cho mọi thứ dễ dàng hơn cho người mới bắt đầu, điều này cũng có nghĩa là rào cản tự nhiên để bất cứ thứ gì hoạt động được liên tục được hạ thấp.

Khi có rào cản gia nhập cao vào một lĩnh vực, rất khó để tìm thấy những tác phẩm khủng khiếp tuyệt đối. Một khi một người thợ thủ công được dạy cách xây dựng một chiếc ghế gỗ, họ chắc chắn cũng được dạy cách không làm một công việc tồi tệ ở đó.

Sự công nghiệp hóa cho phép rất nhiều sản phẩm nhựa rẻ tiền, được thiết kế bởi những người không dành thời gian để suy nghĩ cách chúng sẽ được sử dụng và bởi ai – nhưng thiết kế công nghiệp tốt vẫn tồn tại. Sự phát minh của bộ xử lý văn bản cho phép rất nhiều tài liệu được định dạng tồi tệ – nhưng typography và thiết kế đồ họa vẫn tồn tại. Và phần mềm như Wix và Next.js cho phép tạo ra rất nhiều trang web tải cực chậm và không thể truy cập được – nhưng vẫn có những người thực hành "mặt trận của Frontend" ở đó. Tương tự như vậy, AI đang cho phép rất nhiều rác thải AI (AI slop) – nhưng điều này không có nghĩa là chúng ta không còn cần những người biết mình đang làm gì, và quan tâm đến những gì họ đang làm.

Mọi thứ sẽ diễn ra như thế nào?

Nhưng giống như trong các ngành công nghiệp khác, làm mọi thứ đúng cách sẽ trở thành một miếng bánh ngày càng nhỏ hơn. Nhưng vì bây giờ dễ dàng và rẻ hơn để làm như vậy, kích thước của chiếc bánh sẽ tiếp tục tăng lên. Rất khó để nói tại thời điểm này liệu số lượng tuyệt đối người, được trả tiền để làm mọi thứ tốt, sẽ tăng hay giảm. Nếu bạn hỏi tôi, có quá nhiều sản phẩm nhựa được thiết kế tồi ngoài kia. Và đó là một sự thật buồn rằng thiết kế các phông chữ mới không còn là một công việc toàn thời gian bền vững nữa. Nhưng cùng một lúc, vẫn có rất nhiều công việc tuyệt vời đang được thực hiện trong tất cả các lĩnh vực đó.

Và bạn biết đấy không? Đôi khi churn ra một nguyên mẫu hoặc MVP nhanh chóng là điều đúng đắn cần làm. Nếu bạn chưa có sự phù hợp giữa sản phẩm và thị trường (product-market-fit), việc lặp lại nhanh chóng và học hỏi quan trọng hơn là bảo đảm mọi thứ cho tương lai. Nhưng bạn cần biết bạn đang cố gắng học hỏi gì, và cách bạn xác thực những bài học đó. Và khi thời điểm đã đến, thường tốt hơn nên lùi lại một bước và làm mọi việc đúng ngay từ đầu (ví dụ: hiệu suất tốt rất khó để thêm vào một Frontend có kiến trúc tồi sau này).

Đối với bất kỳ phần nào của hệ thống, bạn cần biết những sự đánh đổi nào bạn đang thực hiện, và sau đó quyết định liệu bạn nên mua một dịch vụ, sử dụng một thư viện mã nguồn mở, để LLM churn ra nó, hay tự viết nó. Khi cơn sốt đã lắng xuống, ngành công nghiệp sẽ nhận ra nó chỉ là một công cụ khác trong hộp công cụ. Nhưng cho đến lúc đó, chúng ta sẽ thấy rất nhiều thứ xấu xí: code xấu xí, giao tiếp bị hỏng, và những đợt sa thải tồi tệ dưới danh nghĩa AI.