AI không đơn giản hóa kỹ nghệ phần mềm: nó chỉ khiến việc làm kỹ nghệ tồi trở nên dễ hơn

• LLM đã tăng tốc độ viết mã, nhưng không làm giảm độ phức tạp cốt lõi của kỹ nghệ phần mềm
• Khi việc sinh mã trở nên dễ dàng hơn, một ảo tưởng rằng không còn cần chuyên môn đang lan rộng, và một số tổ chức đang cắt giảm kỹ sư dựa trên lập luận đó
• Khó khăn thực sự không nằm ở việc viết mã mà ở thiết kế hệ thống, đặc tả, kiểm chứng và duy trì tính nhất quán, và AI thậm chí còn làm tăng tốc gánh nặng trong những lĩnh vực này
• Sự lệch pha giữa đặc tả (specification), kiểm thử và triển khai (spec drift) đang nhanh chóng trầm trọng hơn, làm tăng nguy cơ hệ thống đánh mất độ tin cậy
• Đây là một mô thức đã được quan sát lặp đi lặp lại trong hơn 40 năm kinh nghiệm; ngay cả thời kỳ Visual Basic những năm 1990 cũng từng xuất hiện cùng một lập luận rằng "không cần chuyên môn", để rồi cuối cùng nhu cầu về kỷ luật kỹ nghệ lại một lần nữa được khẳng định
• LLM là công cụ xuất sắc để khám phá thiết kế và tăng tốc triển khai ban đầu, nhưng cần được sử dụng theo hướng củng cố chứ không thay thế kỷ luật kỹ nghệ

---

Ảo tưởng nguy hiểm của ngành

• Khi LLM có thể sinh mã, ngành phần mềm dường như đi đến kết luận rằng bản thân kỹ nghệ phần mềm không còn cần thiết nữa
• Những kỷ luật như kiến trúc, đặc tả và kiểm chứng cẩn trọng đang bị đối xử như tàn tích của một thời đã qua
• Ở một số tổ chức, ý tưởng này đã được phản ánh vào chính sách, dẫn đến các trường hợp sa thải kỹ sư quy mô lớn với lý do AI phát triển
• AI chỉ là cái cớ mới nhất để né tránh các quyết định kinh doanh sai lầm hoặc áp lực thị trường
• Việc nhập prompt cho AI ngày càng được tô vẽ như thể nó có thể thay thế những kỷ luật từng định nghĩa kỹ nghệ phần mềm

Mô thức lịch sử lặp lại

• Trong hơn 40 năm sự nghiệp, cùng một mô thức đã lặp đi lặp lại: công cụ mới xuất hiện → tuyên bố rằng vấn đề khó đã được giải quyết → năng suất tăng vọt và demo ấn tượng → cắt giảm nhân sự → độ phức tạp hệ thống gia tăng → cuối cùng kết quả khác xa kỳ vọng
• Công cụ và lập luận có thay đổi, nhưng bản thân mô thức thì hầu như không đổi

Phép so sánh với bảo trì máy bay

• Lĩnh vực bảo trì máy bay đã đạt nhiều tiến bộ lớn như cải tiến công cụ, chẩn đoán bằng máy tính, sổ tay số và diễn giải telemetry bằng AI, nhưng nhu cầu với thợ máy lành nghề vẫn còn nguyên
• Máy bay thương mại là hệ thống cực kỳ phức tạp gồm hàng triệu bộ phận và hàng nghìn phân hệ liên kết với nhau
• Chẩn đoán sự cố không chỉ là có đúng công cụ hay làm theo checklist, mà còn đòi hỏi kinh nghiệm và khả năng phán đoán về cách hệ thống vận hành trong điều kiện khai thác thực tế
• Không hãng hàng không nào đề xuất bỏ thợ máy được đào tạo chỉ vì công cụ tốt hơn rồi giao việc sửa chữa cho nhân viên cổng ra máy bay
• Thế nhưng ngành phần mềm lại đang đưa ra lập luận rất giống hệt như vậy về chính mình

DIY vs hệ thống chuyên nghiệp

• Các dự án sở thích, ứng dụng cá nhân quy mô nhỏ hay thử nghiệm ý tưởng mới hoàn toàn không có vấn đề gì, và nhiều ý tưởng thú vị nhất trong lịch sử điện toán đã ra đời từ những thử nghiệm như vậy
• Tuy nhiên, phát triển phần mềm chuyên nghiệp là một phạm trù hoàn toàn khác: xử lý thanh toán, lưu trữ dữ liệu nhạy cảm, quản lý hạ tầng, vận hành các hệ thống mà con người phụ thuộc mỗi ngày
• Khách hàng đương nhiên kỳ vọng hệ thống hoạt động đúng, vẫn đúng khi tiếp tục tiến hóa, và những người xây dựng nó hiểu cách hệ thống thực sự vận hành
• Những kỳ vọng đó là điều kiện cơ bản của kỹ nghệ chuyên nghiệp, và là điểm mà kỷ luật cùng chuyên môn trở thành điều không thể tránh khỏi

Mã chưa bao giờ là phần khó nhất

• Việc cho rằng phần khó của phát triển phần mềm là viết mã là một ngộ nhận lâu đời
• Việc gõ cú pháp (syntax) từ trước đến nay luôn là phần ít thú vị nhất trong xây dựng hệ thống; công việc thực sự khó là quyết định hệ thống phải vận hành thế nào, thiết kế tương tác giữa các thành phần và duy trì khả năng hiểu được khi độ phức tạp tăng lên
• Đây không phải vấn đề coding mà là vấn đề kỹ nghệ
• Việc giảm công sức tạo ra mã không loại bỏ những vấn đề này; nó chỉ cho phép tạo ra các hệ thống lớn hơn và phức tạp hơn nhanh hơn mà thôi
• Việc gọi đó là tăng năng suất là một ảo tưởng: gánh nặng chỉ chuyển sang nơi khác
  • Tải nhận thức cần cho review mã và xử lý mã được sinh ra còn là yếu tố làm giảm năng suất lớn hơn cả việc tự viết mã
  • Nếu chỉ tăng tốc mà không hiểu đủ hành vi nền tảng, thì điều đó chỉ đẩy nhanh thời điểm độ phức tạp trở nên không thể kiểm soát, và kết quả cuối cùng vẫn sai

Mô thức đã thấy trước đây: thời đại Visual Basic

• Những năm 1990, với Visual Basic cũng từng có lời hứa tương tự: lập trình đã được dân chủ hóa và không còn cần kiến thức chuyên môn
• Trên thực tế, Visual Basic đã giúp tạo ra nhiều ứng dụng vốn sẽ không bao giờ được xây dựng nếu không có nó
• Nhưng khi hệ thống lớn dần và kết nối với nhau nhiều hơn, người ta lại phát hiện rằng sản xuất ra sản phẩm phần mềm không đồng nghĩa với kỹ nghệ hệ thống đáng tin cậy
• Hiện tại là phiên bản khuếch đại của đúng mô thức đó: không chỉ hạ thấp rào cản xây dựng ứng dụng mà còn hạ thấp rào cản sản xuất chính mã nguồn
• Từ đây nảy sinh niềm tin đầy cám dỗ rằng chuyên môn không còn cần thiết nữa

Vấn đề căn chỉnh (Alignment)

• Phần mềm đáng tin cậy phụ thuộc vào một dạng căn chỉnh (alignment) gần như không được bàn đến ngoài giới kỹ nghệ
• Hệ thống bắt đầu từ ý tưởng về cách nó phải vận hành → được ghi lại thành đặc tả (specification) → kỹ sư chuyển đặc tả thành kiểm thử và mã production
• Để hệ thống giữ được độ tin cậy lâu dài, đặc tả, kiểm thử và triển khai phải luôn ở trạng thái căn chỉnh với nhau
• Khi ba yếu tố này bắt đầu lệch nhau, hệ thống sẽ dần đánh mất tính toàn vẹn
  • Đặc tả mô tả hành vi không còn được triển khai nữa
  • Kiểm thử chỉ xác minh một phần hành vi và bỏ sót phần còn lại
  • Kỹ sư tham gia sau này đọc mã rồi đoán cách hệ thống hoạt động, dù đoạn mã đó có thể phản ánh hoặc không phản ánh thiết kế ban đầu
• Theo thời gian, những phỏng đoán tích tụ lại, và cuối cùng hệ thống trở thành thứ không ai thực sự hiểu hoàn toàn
• Hiện tượng này được gọi là "spec drift": mô tả về hệ thống và chính hệ thống dần dần tách rời nhau
  • Mã đã thay đổi nhưng đặc tả vẫn đứng yên
  • Đặc tả đã tiến hóa nhưng kiểm thử vẫn cố định
  • Hành vi thay đổi dần đến mức không ai còn chắc ý định ban đầu là gì
• Khi sự căn chỉnh bị phá vỡ, độ tin cậy sẽ không thể duy trì lâu dài

AI đang tăng tốc drift

• LLM tăng tốc việc sản xuất mã một cách mạnh mẽ, và đó vừa là điểm mạnh lớn nhất vừa là nơi rủi ro xuất hiện
• Khi mã được tạo ra nhanh hơn các kỷ luật kỹ nghệ bao quanh nó, lực tạo ra spec drift cũng tăng tốc
• Những thay đổi từng đòi hỏi suy nghĩ cẩn trọng và triển khai thủ công giờ đây có thể diễn ra chỉ trong vài giây
• Toàn bộ các phần của hệ thống có thể bị viết lại trước khi bất kỳ ai kiểm tra xem hành vi đó còn phù hợp với đặc tả hay không
• Mã nhìn chung có vẻ hợp lý, biên dịch được, dễ đọc, thậm chí có thể vượt qua các kiểm thử hiện có, nhưng sự căn chỉnh từng chi phối hệ thống có thể đã biến mất
• Cái trông như năng suất thực chất là khả năng di chuyển về phía lệch căn chỉnh (misalignment) nhanh hơn trước

Những lĩnh vực AI thực sự hữu ích

• LLM không phải là sai lầm, và nếu được sử dụng một cách thận trọng, chúng có thể cải thiện mạnh mẽ cách kỹ sư khám phá và thiết kế hệ thống
• Những lĩnh vực đặc biệt mạnh gồm: suy luận về vấn đề, khám phá các phương án thiết kế, tóm tắt hệ thống phức tạp và tạo bản nháp để tăng tốc giai đoạn triển khai ban đầu
• Những lĩnh vực khó là nơi đòi hỏi kỷ luật nghiêm ngặt và tính nhất quán theo thời gian
• Việc duy trì sự căn chỉnh giữa đặc tả, kiểm thử và triển khai vẫn là trách nhiệm kỹ nghệ, và không công cụ nào có thể thay thế trách nhiệm đó (dù có thể hỗ trợ)
• Cơ hội thực sự là dùng LLM theo hướng tăng cường quy trình kỹ nghệ, chứ không phải âm thầm thay thế nó

Kỹ nghệ phần mềm mang tính hội thoại

• Một trong những khả năng thú vị mà LLM mở ra là một phần của kỹ nghệ phần mềm có thể trở nên mang tính hội thoại (conversational) hơn
• Trong nhiều thập kỷ, công cụ thiết kế hệ thống đã rất cứng nhắc: đặc tả là tài liệu, kiến trúc là sơ đồ, còn quá trình suy luận dẫn tới chúng thì biến mất trong các cuộc họp và những cuộc trò chuyện ngoài hành lang
• Với LLM, kỹ sư có thể khám phá ý tưởng một cách tương tác, kiểm tra giả định và thực hiện công việc thiết kế theo cách gần với đối thoại tự nhiên hơn
• Nhưng đối thoại không phải là kỹ nghệ: đối thoại là cách khám phá ý tưởng, còn kỹ nghệ chỉ bắt đầu khi ý tưởng được ghi lại dưới dạng có thể kiểm chứng, kiểm thử và bảo trì
• Thử thách của thế hệ công cụ kỹ nghệ tiếp theo là học cách kết nối hai thế giới này mà không làm mất đi kỷ luật mà các hệ thống phức tạp đòi hỏi

Chuyên môn vẫn quan trọng

• Phần mềm chuyên nghiệp vẫn cần những kỹ sư hiểu cách các hệ thống họ xây dựng thực sự hoạt động
• Công cụ có thể tăng tốc phát triển, nhưng không thể loại bỏ chuyên môn cần thiết để thiết kế, suy luận và duy trì các hệ thống phức tạp
• Ngành này đang ở rất gần mức nguy hiểm của việc quên mất điều đó
• LLM có thể giúp kỹ sư giàu kinh nghiệm trở nên năng suất hơn nhiều, nhưng không thay thế kỷ luật kỹ nghệ cần thiết để xây dựng các hệ thống đáng tin cậy
• Cần sử dụng những công cụ này một cách hiệu quả, chứ không phải sùng bái

[GN⁺]

Ý kiến trên Hacker News

• Tôi không đồng ý với tiền đề của bài viết. Tôi nghĩ kỹ thuật phần mềm nói chung đã trở nên dễ hơn, theo cả hướng tốt lẫn xấu. Trước đây tôi cũng đã thấy nhiều người chỉ nhồi nhét kiểm tra null thay vì thực sự hiểu vấn đề. Giờ thì điều đó chỉ đơn giản là được mở rộng ở quy mô lớn hơn. Ngược lại, kỹ thuật tốt cũng được khuếch đại hơn; tôi từng thấy những tính năng trước đây mất vài tuần thì giờ làm xong chỉ trong vài ngày

  • Tôi cho rằng bài viết có phần hơi cường điệu. Kỹ thuật tốt cũng có thể nhận được trợ giúp từ các agent dựa trên LLM, nhưng việc xác minh kết quả vẫn là phần của con người. Kỹ thuật tệ thì bỏ qua bước đó, nên nếu nhìn từ góc độ định luật Amdahl, LLM sẽ tăng tốc kỹ thuật tệ mạnh hơn nhiều
  • Kỹ thuật tệ đã trở nên dễ hơn rất nhiều, còn kỹ thuật tốt thì chỉ dễ hơn một chút. Vì vậy những người trước đây làm kỹ thuật tốt giờ lại tạo ra lượng kỹ thuật tệ nhiều gấp ba
  • Trong phát triển ứng dụng doanh nghiệp, tôi từng thấy các bài mock test chỉ kiểm tra xem có trả về đúng giá trị mong đợi hay không. Tôi thật sự không hiểu như vậy thì có ý nghĩa gì
  • Rất dễ quên rằng LLM không phải là một oracle ma thuật. Cách bạn xử lý đầu ra của nó sẽ quyết định chất lượng kết quả. Có lúc có thể dùng nguyên xi, nhưng đa phần vẫn cần chỉnh sửa. Rất dễ rơi vào cái bẫy “LLM nói vậy chắc đúng”, và điều đó khiến kỹ thuật tệ trở nên dễ hơn
  • Dù có đồng ý với bài gốc đi nữa, trên thực tế vẫn có rất nhiều miền ứng dụng mà chất lượng phần mềm tốt hay xấu không quá quan trọng. Trong nhiều trường hợp, chỉ cần nó chạy được là đủ

• Có những trường hợp ngay cả một trăm bài unit test cũng khó chứng minh được tính đúng đắn của mã. Phần lớn lập trình viên không biết thế nào là đủ. Những người dùng nhiều vibe coding thậm chí còn giao cả việc viết test cho máy. Khi lên đến bước thiết kế hệ thống, bạn cần một thiết kế có thể đảm bảo tính an toàn và các bất biến theo thời gian cho toàn bộ hệ thống. Nhưng đa số chỉ đơn giản vẽ hộp và mũi tên rồi trích dẫn “best practice”. Phần mềm gần với khoa học tự nhiên hơn, giống như hiệu ứng Sussman, nên ta sẽ dành nhiều thời gian hơn cho việc quan sát. Dùng GenAI như một công cụ có thể hữu ích, nhưng ngừng suy nghĩ rồi phụ thuộc vào công cụ thì rất nguy hiểm

  • Tôi thậm chí còn không biết unit test là gì, nhưng nhờ AI tôi vẫn có thể tạo ra những chương trình cực kỳ hữu ích cho công việc thực tế. Các lập trình viên tinh hoa thì có trả tiền họ cũng chẳng buồn trả lời email

• Cứ vài năm, mỗi khi có công cụ mới xuất hiện, người ta lại nói rằng “phần khó của kỹ thuật phần mềm đã được giải quyết”. Năng suất tăng vọt, demo rất ấn tượng, và ngành thì tự vỗ tay khen mình. Nhưng rồi chẳng bao lâu sau cắt giảm nhân sự sẽ theo tới. Sẽ rất tuyệt nếu đây là một bước đột phá thực sự, nhưng nếu kết quả là sa thải thì điều đó chẳng có nhiều ý nghĩa. Cuối cùng câu hỏi vẫn vậy — nếu mục tiêu là giảm số lượng việc làm, thì tầm nhìn của doanh nghiệp là gì khi con người không còn cách kiếm sống?

  • Mục tiêu không phải là việc làm cho từng cá nhân. Xây dựng AGI mới là mục tiêu tối thượng, và trong quá trình đó tôi nghĩ lương cũng như cơ hội việc làm của lập trình viên đã qua thời đỉnh cao rồi. Chỉ một số siêu lập trình viên AI là ngoại lệ
  • Tôi nghĩ không thể loại bỏ sự phức tạp. Thực tế và con người vốn dĩ phức tạp. Ý tưởng cho rằng phần mềm có thể đơn giản là phi thực tế. Nhìn ở góc độ lớn hơn, mục tiêu cuối cùng dường như là sự biến mất của tầng lớp trung lưu
  • Nếu không có nhu cầu thì phải làm việc khác. Từ chối thì phải chịu đói
  • Chủ nghĩa tư bản phụ thuộc vào sự tồn tại của tầng lớp dưới. Họ tạo áp lực lên những người lao động khác để buộc họ chấp nhận mức lương thấp hơn và điều kiện tệ hơn. Lập trình viên chỉ là đã được bảo vệ khỏi thực tế đó trong một thời gian. Cấu trúc này cũng gắn với lao động nhập cư, nơi doanh nghiệp có thể bắt họ làm việc nguy hiểm và trục xuất nếu họ không phục tùng. Cuối cùng, tất cả chỉ là một hệ thống để giảm chi phí lao động

• Tôi đồng ý với câu “viết code vốn không phải là phần khó”. Các chuyên gia vốn đã biết cần xây cái gì, chỉ là họ thấy phiền vì công việc lặp đi lặp lại

  • Bảo trì mã vẫn là vấn đề của con người và kinh nghiệm. “Không nên viết loại mã nào” đã trở nên quan trọng hơn. Bây giờ việc sinh mã quá dễ, nên đây là thời đại rất dễ sản xuất hàng loạt spaghetti code
  • Trọng tâm của tranh luận về LLM nằm ở đây. Có người chỉ muốn kết quả đầu ra, có người lại muốn khả năng bảo trì và độ ổn định. Cả hai lập trường đều cần thiết, và vai trò của prototype với production rồi sẽ tự nhiên tách ra
  • Người thực sự giỏi thì vẫn muốn tự làm lấy. Không phải vì LLM, mà vốn dĩ họ đã vậy. Ngược lại, những người từng nói “gõ cú pháp thì chán lắm” mới là nhóm hưởng lợi nhiều nhất. Với tôi, việc gõ code tự thân lại là phần duy nhất thú vị

• Các lập trình viên junior phụ thuộc quá nhiều vào AI sau này sẽ phải trả giá vì thiếu nền tảng cơ bản. Cuối cùng chỉ những người nhiều kinh nghiệm mới có được sự ổn định trong công việc

• Tôi khó mà đồng ý với lập luận “viết code không phải phần khó”. Dĩ nhiên không phải lúc nào cũng khó, nhưng khi có áp lực thời gian, việc viết code trở thành nút thắt cổ chai. AI cho phép thử những điều trước đây là bất khả thi, và giúp giải phóng thêm thời gian kỹ thuật

  • Có một mâu thuẫn là vừa nói “khó mà xem trọng” nhưng rốt cuộc lại đồng ý. Bản gốc chứa những sắc thái tinh tế hơn nhiều
  • Viết code là công việc ngốn thời gian nhất, và AI làm nổi bật điều đó. Ai cũng có thể gõ phím, nhưng khả năng đọc code mới là năng lực thật sự. Giống như tiều phu cầm cưa máy thay vì rìu, hiệu suất cao hơn nhưng thiệt hại cũng có thể lớn hơn

• AI cũng đã khiến kỹ thuật tốt trở nên dễ hơn. Xét cho cùng, nó là một bộ khuếch đại hành vi

  • Kỹ sư giỏi có thể làm tốt hơn nữa, nhưng phần lớn mọi người còn chẳng biết property testing là gì. Với những người như vậy, AI thực sự hữu ích đến mức nào thì còn phải nghi ngờ
  • Internet đã kết nối tri thức toàn cầu, nhưng con người rốt cuộc vẫn lao vào tán gẫu và nội dung tiêu hao. Xét đến bản chất con người, AI có lẽ cũng sẽ đi theo con đường tương tự
  • Những vấn đề sáng tạo thường được giải quyết trong chính quá trình tự tay viết code. Dùng AI thì mạch tư duy đó ít được kích hoạt hơn
  • Dữ liệu như báo cáo DORA cũng ủng hộ điều này
  • Câu “AI là bộ khuếch đại của hành vi sẵn có” thực sự quá chuẩn. Tôi muốn dùng nguyên câu đó

• Tôi là một người hoài nghi AI, nhưng không nghĩ nó đang cướp việc của đồng nghiệp. Thay vào đó, nó giúp tiết kiệm thời gian cho tôi. Tôi dùng nó như một công cụ nghiên cứu tốt hơn Google, và nó hữu ích cho việc khám phá codebase, tạo hàm trợ giúp, cũng như rà soát lỗi

  • Tôi cũng đồng ý. Tôi nghĩ cách dùng như vậy rốt cuộc sẽ là điểm đến cuối cùng của việc ứng dụng AI

• Dạo này ranh giới giữa kỹ thuật phần mềm và nghiên cứu đang trở nên rõ hơn. AI là một công cụ tuyệt vời cho nghiên cứu khám phá. Khi đã thấy có tiềm năng, tôi chuyển sang chế độ SWE, tự hiểu và sửa mã, rồi tinh chỉnh bằng kinh nghiệm của mình. Vai trò của AI có giới hạn, nhưng vẫn hữu ích

  • LLM có thể ngay lập tức khám phá bề rộng tri thức lớn hơn con người rất nhiều. Nhưng phán đoán cuối cùng vẫn phụ thuộc vào gu và cảm nhận chất lượng của con người

• Cần thêm bao nhiêu thế hệ model nữa thì những người như vậy (phe bi quan) mới chịu bỏ cuộc? Hai lần? Ba lần?