Tại Amazon, một số lập trình viên nói công việc của họ đã bắt đầu giống lao động trong kho

• Các lập trình viên Amazon đang chịu áp lực tăng tốc độ làm việc và sự đơn giản hóa công việc sau khi AI được đưa vào
• Các quản lý khuyến khích mạnh mẽ việc dùng công cụ AI với lý do nâng cao năng suất
• Một số người cho rằng nhờ giảm bớt việc lặp lại nên chất lượng công việc được cải thiện, nhưng cũng có lo ngại rằng lập trình viên mới vào nghề sẽ mất cơ hội phát triển
• Khi việc lập trình chuyển từ sáng tạo trực tiếp sang chủ yếu là rà soát và xác nhận, một số người cảm thấy như đó không còn là công việc của mình
• Các nhóm nội bộ như Amazon Employees for Climate Justice đang chia sẻ về căng thẳng công việc và nỗi bất an về triển vọng tương lai, trong đó có cả vấn đề này

---

At Amazon, Some Coders Say Their Jobs Have Begun to Resemble Warehouse Work

Ngay cả lập trình cũng bước vào thời đại ‘chạy đua tốc độ’

• Hiện tượng đơn giản hóa công việc do cơ giới hóa, lặp đi lặp lại từ sau Cách mạng Công nghiệp, cũng đang xuất hiện trong lĩnh vực lập trình
• AI không hẳn xóa bỏ việc làm mà đang chuyển đổi công việc hiện có thành dạng thực hiện đơn giản hơn và nhanh hơn
• Theo nghiên cứu của Microsoft, năng suất của lập trình viên dùng trợ lý AI ‘Copilot’ đã tăng hơn 25%
• Amazon chấp nhận xu hướng này và yêu cầu làm việc nhanh hơn, hiệu quả hơn bằng AI, đồng thời nhấn mạnh trong thư gửi cổ đông rằng đây là chìa khóa để ‘cắt giảm chi phí và duy trì năng lực cạnh tranh’
• Ví dụ, có một nhóm phát triển đang vận hành với quy mô chỉ bằng một nửa năm ngoái nhưng vẫn bị yêu cầu tạo ra lượng mã tương đương

Xu hướng trên toàn doanh nghiệp

• Shopify nêu rõ rằng việc sử dụng AI là yêu cầu mặc định với mọi nhân viên và còn được phản ánh trong đánh giá hiệu suất
• Google chọn chủ đề phát triển công cụ AI giúp tăng năng suất công việc hằng ngày cho các hackathon nội bộ. Hiện hơn 30% mã nguồn đã được tạo ra từ các đề xuất của AI

Mặt tích cực và những lo ngại

• Một số quản lý cho rằng việc đưa AI vào giúp giảm các công việc nhàm chán, lặp đi lặp lại, từ đó có thể tập trung hơn vào những công việc sáng tạo
• Amazon cho biết nhờ AI đã tiết kiệm được khối lượng công việc phát triển tương đương 4.500 năm
• Tuy nhiên, nhà kinh tế học Harvard Lawrence Katz chỉ ra rằng đối với lập trình viên mới, điều này làm biến mất cơ hội phát triển nghề nghiệp trong công việc
• Tương tự ‘cuộc đua tốc độ’ mà công nhân nhà máy từng trải qua, các lập trình viên cũng đang bị ép phải xử lý nhanh hơn và nhiều hơn

Những thay đổi mà lập trình viên cảm nhận

• Cũng giống như tại các kho vận của Amazon, các lập trình viên đang cảm nhận rõ sự tự động hóa công việc và phân chia lao động do AI gây ra
• Việc dùng AI là ‘tùy chọn’, nhưng trên thực tế gần như là bắt buộc nếu muốn đạt mục tiêu hiệu suất
• Những tính năng trước đây mất vài tuần để phát triển thì nay phải hoàn thành chỉ trong vài ngày, và để làm vậy thời gian họp bị cắt giảm còn việc dùng mã do AI tạo ra được mở rộng
• AI thậm chí có thể tạo cả chương trình hoàn chỉnh, nhưng công việc đọc và rà soát mã lại tăng lên, làm giảm sự thú vị và mức độ nhập tâm

Tăng trưởng nghề nghiệp và sự suy giảm mức độ gắn bó

• Lập trình viên mới vào nghề có thể mất cơ hội hiểu sâu về mã do tự động hóa kiểm thử
• AI đang hỗ trợ trong nhiều công việc như viết tài liệu đặc tả và kiểm thử mã, nhưng môi trường đánh giá đang chuyển dần sang kiểu đặt công cụ làm trung tâm thay vì con người
• Harper Reed, cựu CTO của chiến dịch Obama, cho rằng đây là thời đại không cần hiểu sâu mọi phần, và mô tả đây là một thay đổi tương tự ngành sản xuất
• Ngược lại, Simon Willison đánh giá tích cực AI ở chỗ nó giúp hiện thực hóa ý tưởng nhanh hơn

Bất mãn và phản ứng có tổ chức

• Do việc sử dụng AI và những thay đổi công việc đi kèm, nhiều lập trình viên đang chia sẻ nỗi bất an và căng thẳng trong nhóm Amazon Employees for Climate Justice
• Đặc biệt, có nhiều lo ngại về sự suy giảm chất lượng công việc và tính bất định của con đường sự nghiệp, điều này giống với căng thẳng do cuộc đua tốc độ mà công nhân ngành ô tô từng cảm nhận
• Dù hiện chưa có động thái thành lập công đoàn cho lập trình viên, sự đồng cảm nội bộ trong tổ chức đang ngày càng mở rộng

Bối cảnh lịch sử và triển vọng tương lai

• Giống như cuộc đình công của GM năm 1936, vấn đề về tốc độ công việc và quyền tự chủ có thể trở thành chất xúc tác cho hành động của người lao động
• Trước đây, mỗi cá nhân có thể tự điều chỉnh cách làm việc và tốc độ, nhưng hiện nay hệ thống đã chuyển sang kiểu toàn bộ quy trình bị giám sát và được đánh giá theo tốc độ làm trung tâm

[GN⁺]

Ý kiến trên Hacker News

• Chia sẻ nội dung từ liên kết archive.ph/HVZRL
• Tôi cảm thấy phát triển dựa trên LLM giống như một trào lưu bị thổi phồng kiểu crypto hay VR. Gần đây khi phải sửa lỗi trong một codebase được viết theo kiểu vibe coding, tôi thấy cách này là một khối hỗn loạn, nơi các vấn đề kinh doanh thiếu hệ thống bị chuyển thẳng thành mã mà không có cấu trúc. Các phần cần cải thiện lại bị vá bằng những bản sửa hẹp, kết quả là sinh ra mã phức tạp và thiếu tổ chức. Khi chạm đến giới hạn của context window, LLM thậm chí không nhớ nổi chính những bản vá mà nó đã tạo. Tiếng Anh (hay ngôn ngữ của con người nói chung) quá mơ hồ để mô tả chính xác đoạn mã tôi muốn, và việc bung toàn bộ kinh nghiệm cùng những lần thử-sai mà một lập trình viên senior đã đúc kết trong code thành prompt là việc cực kỳ nặng nề. Khác biệt nằm ở chỗ, thay vì trả lời “vì sao lại viết như vậy”, ta lại cần một danh sách cực kỳ cụ thể và vô tận kiểu “trong tình huống này đừng làm thế này, hãy làm thế kia”
  • Đây là nhận xét khớp hoàn toàn với mô tả về hầu hết mọi codebase (trừ đúng một cái) mà tôi đã thấy trong 30 năm qua
  • Ý kiến phản biện—AI cũng từng giúp tôi tìm ra các pattern trong code ở khoảng hơn 30 chỗ mà lẽ ra phải tự trích xuất cấu trúc. Vấn đề của vibe coding theo tôi là ở thái độ. Những người muốn né tự tay code có xu hướng chỉ tập trung vào sự tiện lợi trước mắt hơn là cấu trúc hay chất lượng dài hạn, như một kiểu bộ khuếch đại sự lười biếng
  • Thực tế, nhiều mã production chỉ là tập hợp các mảnh snippet hoạt động được nhờ chắp vá dần dần. Đáng buồn là CPU giờ quá nhanh nên loại mã như vậy vẫn cứ chạy được
  • Tôi đồng ý với nhận định rằng ngôn ngữ của con người không rõ ràng. Cuối cùng thì việc cố xử lý phần mềm một cách minh bạch bằng ngôn ngữ tự nhiên đã được thử lặp đi lặp lại nhiều lần, và giống như luật pháp, các vùng xám trong diễn giải vẫn không bao giờ hết. Nếu tương lai mà lập trình viên phải tranh cãi về ý nghĩa của chương trình trước khi compile thì đó là một tương lai khá u ám
  • Đúng là AI cũng có vẻ bị thổi phồng chẳng kém crypto hay VR. Nhưng ngay cả những nghề có tính kỹ thuật rất cao như kỹ sư phần mềm rồi cũng sẽ bị tự động hóa tác động. Suốt 10 năm qua, người trong ngành tech từng lầm tưởng mình không liên quan đến vấn đề của các lao động khác, nhưng với văn hóa layoff/cắt giảm, việc kìm hãm tiền lương giờ đã thật sự bắt đầu. Dù AI không thay thế toàn bộ ngay lập tức, chỉ cần công việc của 5 người được 4 người làm cùng AI, thì sẽ có 1 người bị cắt giảm, còn những người ở lại cũng không dám đòi tăng lương. Lập luận ở đây là giới làm tech cũng phải nhận ra mình rốt cuộc vẫn là người lao động
• Về ý kiến của Harper Reed rằng “không cần phải hiểu sâu về code”, tôi thấy kiểu phát biểu này lại giống một thứ ngụy biện chắp vá kiểu “compile được thì deploy thôi”. Trong dây chuyền tự động hóa, người ta liên tục đo chất lượng, nhưng máy móc thực tế không tự nhiên bị ảo giác kiểu nhầm góc hay hàn sai chỗ; còn phần mềm dựa trên LLM thì những sai lệch nhỏ như vậy cứ lặp đi lặp lại
• Tôi nghi ngờ liệu các công cụ dựa trên LLM có thật sự làm năng suất lập trình viên tăng mạnh hay không, hay chỉ là các tổ chức nhận ra rằng họ có thể dùng ít lập trình viên hơn—và ít được ưu đãi hơn trước—mà thôi. Tôi cũng không thấy nhiều ví dụ “nâng cao năng suất mang tính đột phá” trong các công ty công nghệ lớn; đến giờ chủ yếu vẫn chỉ là vài cải thiện nhỏ đủ để bù chi phí đầu tư
  • Phần lớn là vấn đề nhận thức. Trước đây phát triển phần mềm là việc khó, nhưng từ khi có công cụ AI, người ta thấy rào cản bước vào coding đã thấp hơn. Công việc phát triển phần mềm ngày càng giống việc nhà máy, và cảm giác thỏa mãn về mặt trí tuệ giảm đi
  • Tôi nghi ngờ khả năng bảo trì dài hạn của codebase. Vibe coding dần tích lũy độ phức tạp, bug tinh vi và các vấn đề trừu tượng hóa, cuối cùng làm tăng độ khó của bảo trì và phát triển tính năng mới. Có thể đang mắc kẹt trong năng suất ngắn hạn mà đánh đổi chất lượng dài hạn
  • Từ lâu các tổ chức đã dùng quy trình quan liêu để “thoát kỹ thuật”, tức thay thế người có tay nghề cao bằng lực lượng ít kỹ năng hơn nhưng được chuẩn hóa. Đây có thể là chiến lược độc hại về lâu dài, nhưng chỉ cần nhất quán là họ sẵn sàng hài lòng với những “giải pháp tạm ổn bình thường”
  • Để lập luận này có sức thuyết phục thì phải giả định rằng ban lãnh đạo Amazon coi trọng lợi nhuận ngắn hạn hơn chất lượng dài hạn, nhưng tôi không chắc về điều đó
• Với tư cách là người sắp nghỉ hưu, tôi thấy khá hụt hẫng trước những thay đổi gần đây. Khi bắt đầu sự nghiệp vào thập niên 90, tôi còn có thời gian để thử nghiệm lâu dài và đắm mình vào sáng tạo. Giờ đây, công việc bị chia nhỏ thành task, báo cáo trạng thái và phải liên tục tự biện minh. Sau này chắc vẫn sẽ có những lập trình viên làm việc thú vị, nhưng cơ hội như vậy đang ít dần. Thực ra đây chỉ là con đường giống hệt những nghề khác từng bị tự động hóa làm cho khó sống hơn, nên cũng là một kết cục công bằng
  • Những buổi stand-up báo cáo trạng thái hằng ngày vừa tốn thời gian, vừa chỉ là phản ứng hình thức để tôi được yên thêm một ngày trước những người không hiểu công việc của mình, và nó làm giảm giá trị của công việc
  • Tôi cũng vào nghề từ thập niên 90 và đồng cảm với hiện tượng bị kiểm soát chi li bằng JIRA. Dù vậy tôi không nghĩ trước đây lúc nào cũng là thời hoàng kim. Có lẽ cũng có hiệu ứng hoài niệm chỉ nhớ phần đẹp của quá khứ. Nhưng hiện tại vẫn có nhiều công việc hay, đầy thử thách và đáng học hỏi
  • Hướng đi thực tế không phải là tự động hóa việc làm kỹ sư, mà là thay thế vai trò quản lý bằng giám sát tập trung vào AI
• Nếu muốn tăng tốc phát triển phần mềm một cách đột phá, còn có cách là lấy nguyên mã nguồn mở của người khác về dùng rồi xóa dấu vết bản quyền/giấy phép trước khi áp dụng. Nếu lo bị phát hiện trực tiếp thì dùng công ty outsource để “rửa”, hoặc bây giờ có thể dùng AI để rửa rẻ và nhanh. Google trước đây còn kiềm chế những hành vi như vậy, thiếu đi sự táo bạo. Nhưng các startup nhỏ thì nhắm đến thành công nhanh bằng cách dùng AI và bỏ qua rủi ro vi phạm bản quyền
  • Trong ngành của tôi, vấn đề lớn hơn không phải là thiếu code mà là định nghĩa được “phải viết cái gì và viết như thế nào”. Có rất nhiều bài toán đặc thù mà Stackoverflow hay Github cũng không giải quyết được
  • Thực ra Google từ xưa cũng đã cào nội dung website rồi hiển thị trực tiếp trên kết quả tìm kiếm, tận dụng nội dung người khác mà không tạo traffic. Lần này cũng chỉ là chậm chân hơn thôi
  • Trớ trêu là có người lại muốn các tập đoàn lớn đi đạo mã nguồn mở. Vì từ góc nhìn người dùng, như vậy còn đỡ hơn bị ép dùng những cách làm lạnh lùng và kém hiệu quả do chính họ tự tạo ra
  • Tôi đồng cảm với giới hạn của việc đưa code lên mã nguồn mở. Các tập đoàn lớn có xu hướng khuyến khích mã nguồn mở như một cách lấy lao động miễn phí. Dù đóng góp có thể giảm trong ngắn hạn, tôi nghĩ về dài hạn ngành sẽ lành mạnh hơn
  • Có ý kiến chỉ trích sự thiếu trách nhiệm trong sự xuất hiện của ChatGPT và cách lãnh đạo của Sam Altman
• Tôi thấy ấn tượng với nhận định của Simon Willison rằng đọc code khó và chán hơn viết code, cũng như trường hợp một lập trình viên Amazon nói AI đang giúp rất nhiều cho các việc phụ như viết tài liệu và testing. Giờ đây vai trò đang dịch chuyển từ coding sang review code hiện có và sửa bug
  • Tôi nhớ thời mới vào nghề khi việc viết code rất vui. Giờ sửa bug lại thú vị hơn, và LLM thay tôi làm phần coding lặp đi lặp lại nên tôi có thể tập trung vào các thách thức. Nhờ LLM mà một phần niềm vui của nghề phát triển vẫn còn giữ được
  • Không khí toát ra từ bài này khá tiêu cực
• Khi có công nghệ năng suất mới, doanh nghiệp sẽ nhanh chóng lấy hiệu quả đó về và chuẩn hóa nó. Nếu muốn tiếp tục theo kịp thì phải học liên tục, và đến một lúc nào đó cũng nên cân nhắc chuyển sang môi trường nơi bản thân trực tiếp hưởng lợi từ tăng trưởng của mình, như tự doanh chẳng hạn. Nhưng làm một mình cũng có nghĩa là phải cạnh tranh với những người rất thành thạo AI, nên không có lời giải dễ dàng
  • Tôi hình dung ba kịch bản tương lai. 1) Codebase dần sụp đổ trong hỗn loạn và bất ổn, rồi cuối cùng có thể phải tái thuê các lập trình viên giàu kinh nghiệm với giá cao. 2) AI tạo ra được lượng code tạm dùng được, chất lượng hay độ tin cậy không cao nhưng cũng không gây thảm họa lớn. 3) AI thông minh lên rất nhanh đến mức khái niệm codebase biến mất, nhường chỗ cho thời đại phần mềm được tạo và tiến hóa động theo nhu cầu. LLM hiện tại còn rất xa mốc này. Các lãnh đạo doanh nghiệp tin vào kịch bản 3, nhưng thực tế trước mắt vẫn là 1 hoặc 2. Nếu quản trị tốt thì cũng có thể chuyển sang góc nhìn cân bằng của kịch bản 2
  • Cũng có mô hình nơi lợi ích năng suất được phân phối công bằng hơn, như rút ngắn giờ làm kiểu châu Âu ngày trước. Bây giờ thậm chí cả người lao động cũng có vẻ đang bận bịu với những việc lặt vặt khó hiểu chỉ để trông cho có vẻ bận
  • Thực ra bạn đang nói theo góc nhìn gần như Marxist, nhưng thú vị là kết luận lại rơi vào sự tha hóa cá nhân. Chỉ cần cùng nhau hợp sức một chút là có thể cải thiện, nhưng người ta lại không làm vậy
  • Thay vì chấp nhận rằng phải sống bằng cách không ngừng tự phát triển bản thân, vẫn có cách là hợp sức với các thành viên khác trong xã hội để cùng đòi hỏi với chủ lao động. Tuần làm 5 ngày, ngày làm 8 tiếng, cấm lao động trẻ em đều là thành quả của hành động tập thể. Không nhất thiết chỉ chăm chăm làm tốt việc của mình và để tâm người khác có thành công hay không
• Tôi luôn ngạc nhiên khi thấy ngành của chúng ta trở nên trẻ con hóa. Ai từng trải nghiệm công ty lớn và codebase lớn đều biết rằng việc tạo code mới chỉ là một phần nhỏ của công việc phát triển
  • Thực ra cả những việc ngoài chuyện viết code mới, tức các phần phụ trợ khác, trong công ty lớn cũng rất kém hiệu quả. AI có thể thay đổi cả điều đó và giúp giảm bớt các cuộc họp liên miên hay những cuộc thảo luận quá trừu tượng
  • Phần lớn những người đang hưng phấn hiện nay thật ra là người bị mắc kẹt trong các paradigm mới nhất đến mức bản thân việc viết code đã trở nên khó khăn. Họ dùng các công cụ LLM như Copilot để nhanh chóng tạo POC rồi đẩy thẳng lên production mà không suy nghĩ sâu về chất lượng, khả năng mở rộng, v.v. Và chính những người này lại quảng bá vô điều kiện các trường hợp năng suất tăng nhờ AI, lặp lại đúng những luận điểm có lợi cho doanh nghiệp lớn. Trong khi đó, những ai thực sự sử dụng trong công việc đều biết vẫn còn rất nhiều điểm chưa ổn
  • Tôi cũng chỉ dành khoảng 20% thời gian để code, còn lại là thu thập yêu cầu, thiết kế, testing và quản lý tiến độ. Nếu phần 20% đó được giảm một nửa thì có lẽ tôi sẽ dùng thời gian còn lại để làm testing hoặc tài liệu tốt hơn
• Có một ảo tưởng rằng nhờ LLM, hiệu suất phát triển sẽ tăng mạnh trên diện rộng. Thực ra chỉ khi có nền tảng đủ vững thì mới tăng năng suất mà không làm giảm chất lượng. Nói cách khác, với người có tay nghề thì đó là công cụ khuếch đại năng suất, còn nếu phát cho cả một đội quân người mới chỉ để mở rộng quy mô thì rất khó làm ra phần mềm chất lượng cao
  • Lập luận này được nhắc đi nhắc lại, nhưng điều quan trọng là ngưỡng của “chất lượng” nằm ở đâu. Thực tế, đội study dev trẻ chỗ tôi có một người bạn làm SRE review hằng tuần và họ dùng LLM rất tích cực; chất lượng code hay khả năng mở rộng vẫn hoàn toàn ổn. Chỉ là tốc độ chậm thôi, còn độ hoàn thiện không hề tệ
  • Chỉ một số nơi mới thật sự cần phần mềm “tốt”; nhìn vào mô hình doanh thu của Deloitte hay Accenture thì phần lớn doanh nghiệp thậm chí còn chẳng quan tâm đến chất lượng. Đa số chỉ cần phần mềm “trông có vẻ ổn” là đủ