46 điểm bởi GN⁺ 2025-05-28 | 19 bình luận | Chia sẻ qua WhatsApp
  • Từ NoCode đến AI, các công nghệ tuyên bố sẽ thay thế lập trình viên liên tục xuất hiện, nhưng trên thực tế vai trò chỉ được biến đổi theo thay đổi của công nghệ
  • NoCode không xóa bỏ lập trình viên mà tạo ra chuyên gia NoCode và những người tích hợp hệ thống, còn cloud tạo ra vị trí chuyên sâu là kỹ sư DevOps
  • Các công cụ phát triển AI hiện nay cũng đang đi theo con đường tương tự, và ngay cả trong thời đại AI viết code, năng lực thiết kế kiến trúc hệ thống vẫn là cốt lõi
  • AI giỏi tối ưu cục bộ nhưng yếu trong thiết kế toàn hệ thống, và tốc độ sinh mã nhanh có thể khiến các sai lầm cấu trúc bị cố định hóa nhanh hơn
  • Việc thay thế lập trình viên rốt cuộc chỉ là sự tiến hóa và nâng cấp theo thay đổi của tech stack, còn vai trò bản chất vẫn luôn cần thiết

From NoCode to AI-Assisted

  • Cứ vài năm một lần, lại xuất hiện một công nghệ mới được tuyên bố sẽ thay thế các lập trình viên phần mềm
  • Những tiêu đề na ná nhau với kỳ vọng bị thổi phồng như "cái chết của việc lập trình", "giờ thì ai cũng có thể tạo app", "trẻ con cũng code được" liên tục lặp lại
  • Ban lãnh đạo và các tư vấn viên chú ý tới làn sóng này, và ngân sách bắt đầu dịch chuyển
  • Nhưng thực tế chưa bao giờ là “thay thế”, mà luôn là “biến đổi
    • Một lần nữa lại xuất hiện những vai trò mớicác nghề chuyên môn cao hơn để xử lý công nghệ ngày càng phức tạp, đồng thời mức lương cũng có xu hướng tăng
  • NoCode tạo ra kỳ vọng có thể làm ứng dụng mà không cần chuyên gia kỹ thuật, nhưng cuối cùng vẫn tồn tại những vấn đề phức tạp như mô hình dữ liệu, tích hợp, bảo trì và từ đó sinh ra những vị trí mới để giải quyết
  • Cloud từng tạo cảm giác có thể vận hành mà không cần quản trị hệ thống, nhưng trên thực tế lại đòi hỏi chuyên môn cao cấp mang tên kỹ sư DevOps, và mức lương cũng tăng
  • AI cũng vậy: tưởng như “AI có thể viết code thay”, nhưng thực tế tầm quan trọng của những lập trình viên lành nghề có thể quản lý và điều phối AI lại càng lớn hơn

Vòng quay bất tận của những lời hứa thay thế (The Endless Carousel of Replacement Promises)

Cuộc cách mạng NoCode/LowCode

  • Cuộc cách mạng NoCode/LowCode xuất hiện với lời hứa rằng mọi người dùng đều có thể tạo ứng dụng bằng giao diện trực quan
  • Nhưng trong thực tế triển khai, lại nảy sinh những vấn đề mới như thiết kế mô hình dữ liệu, tích hợp với hệ thống cũ và cơ sở dữ liệu, xử lý ngoại lệ, bảo trì
  • Vì thế, thay vì chỉ cần lập trình viên thông thường, người ta cần chuyên gia NoCode vừa hiểu domain vừa hiểu các giới hạn kỹ thuật
  • Họ nhận mức lương cao hơn cả lập trình viên truyền thống

Cuộc cách mạng cloud

  • Từng có kỳ vọng rất lớn rằng chuyển lên cloud sẽ khiến quản trị viên hệ thống không còn cần thiết
  • Nhưng trên thực tế, độ phức tạp và nhu cầu về chuyên môn quản trị cloud lại tăng lên
  • Các quản trị viên hệ thống truyền thống chuyển mình thành kỹ sư DevOps với mức lương cao hơn, và công việc cũng được nâng lên tầm mới như tự động hóa hạ tầng, pipeline triển khai, quản lý hệ thống phân tán
  • Công việc không biến mất, mà tiến hóa thành một hình thức lao động mới
  • Ngay cả khi chuyển sang microservices, độ phức tạp vẫn tăng, và cuối cùng cho thấy vai trò của những chuyên gia thực sự quản trị hệ thống ở tầng gốc là cực kỳ quan trọng

Làn sóng phát triển offshore

  • Từng xuất hiện niềm tin rằng có thể cắt giảm chi phí bằng cách outsourcing ra nước ngoài, nhưng rồi phát sinh khó khăn do vấn đề giao tiếp, chất lượng suy giảm, thiếu kiến thức domain
  • Cuối cùng chiến lược phải thay đổi theo hướng tái cấu trúc đội ngũ phân tán, quyền sở hữu rõ ràng, kiến trúc mạnh mẽ, và kết quả là tổng chi phí còn tăng cao hơn kỳ vọng ban đầu

Cuộc cách mạng trợ lý code AI

  • Giờ đây, lời hứa đang được nhắc tới là AI sẽ tự động sinh code
  • Trong thực tế ban đầu, code do AI tạo ra thường chứa những lỗi tinh vi và vấn đề thiếu nhất quán
  • Các kỹ sư senior phải dành nhiều thời gian để rà soát và chỉnh sửa kết quả từ AI, và càng là lập trình viên giàu kinh nghiệm thì càng tạo ra nhiều giá trị hơn
  • Các hệ thống được xây dựng chủ yếu bằng trợ giúp AI thường thiếu một kiến trúc bài bản
  • Nói cách khác, công nghệ không thay thế người làm kỹ thuật mà nâng chuyên môn của họ lên một tầng trừu tượng cao hơn

Vì sao chu kỳ lần này đặc biệt

  • Điều cốt lõi mà nhiều người bỏ qua: code không phải là tài sản mà là nợ
  • Càng tạo code nhanh và dễ, gánh nặng bảo trì, bảo mật và refactor càng lớn
  • AI có thể tối ưu ở mức hàm nhưng thiếu năng lực thiết kế toàn bộ hệ thống
  • Tốc độ triển khai càng nhanh thì rủi ro các sai lầm cấu trúc bị cố định hóa nhanh càng lớn
  • Cuối cùng, trong thời đại AI, tài sản thực sự vẫn là năng lực thiết kế kiến trúc hệ thống, và đây là thứ được tăng cường chứ không bị thay thế
  • Khẳng định rằng "AI sẽ thay thế lập trình viên" bắt nguồn từ những hiểu lầm nền tảng sau
    • Code không phải là tài sản mà là nợ
    • Code luôn cần được bảo trì, kiểm chứng, quản lý bảo mật và thay thế liên tục, và số dòng code càng nhiều thì khoản nợ càng tăng
  • Việc AI tạo code nhanh hơn thực chất chỉ có nghĩa là nó tạo ra khoản nợ nhanh hơn bấy nhiêu
  • Nói cách khác, AI giỏi tối ưu cục bộ (hàm, chức năng nhỏ), nhưng yếu ở thiết kế tổng thể và quyết định kiến trúc
  • Tốc độ triển khai càng nhanh thì rủi ro một thiết kế sai bị 'đóng cứng' trên toàn hệ thống càng lớn
  • Với những website ngắn hạn, làm một lần, điều này có thể không thành vấn đề; nhưng với các hệ thống phát triển dài hạn thì đó là điểm chí mạng
  • Mô thức của các cuộc đổi mới công nghệ vẫn không thay đổi
    • Quản trị viên hệ thống trở thành kỹ sư DevOps, còn lập trình viên backend trở thành kiến trúc sư cloud
  • Nhưng AI tăng tốc mọi thứ. Kỹ năng giúp bạn tồn tại và phát triển không phải là viết code
  • Mà là thiết kế hệ thống (Architecting systems). Đó chính là việc duy nhất AI không thể làm

19 bình luận

 
aer0700 2025-05-31

Tôi là kiểu người làm việc khá bảo thủ, nên chưa từng đưa công cụ AI vào các công việc quan trọng; cùng lắm chỉ là thay việc tìm trên Google hay Stack Overflow bằng hỏi Gemini hoặc ChatGPT thôi? Vẫn đang dùng, nhưng...
Khi nhờ AI làm gì đó, tôi nghĩ có lẽ sẽ ổn nếu dùng theo kiểu yêu cầu nó tạo các hàm ở mức đơn vị hàm, kiểu nhập gì thì ra gì, rồi tự mình viết phần logic để kiểm tra xem giá trị trả về từ hàm do AI tạo có đúng hay không.

 
dbs0829 2025-05-30

Tôi khá hoài nghi về câu hỏi liệu có thể sắp xếp toàn bộ ngữ cảnh thành một định dạng mà AI có thể hiểu tốt hay không. Con người không chỉ có ngữ cảnh bề mặt cần thiết trực tiếp cho việc phát triển đang làm ngay lúc này, mà còn có cả những ngữ cảnh tiềm ẩn, và khi phát triển, họ cũng cân nhắc những phần đó; nhưng tôi vẫn chưa nghĩ rằng con người có thể viết ra những ngữ cảnh này bằng các biểu đạt được tinh luyện tốt. Tôi nghĩ đây không hẳn là vấn đề của AI mà có lẽ là giới hạn của con người. Đặc biệt, tôi cũng cho rằng khả năng viết lách của con người hiện đại không thực sự tốt lắm.

 
geirdev 2025-05-29

Điều đáng sợ có lẽ không phải là khoảnh khắc này, mà là xu hướng..

 
hey23 2025-05-29

Bây giờ hoàn toàn khác.

Tương lai mà mọi nghề nghiệp đều sẽ bị thay thế đã ở ngay trước mắt, và lập trình viên chỉ là một trong số đó.

Chuyện kiểu này chưa từng là một trào lưu lần nào cả.

 
kaykim 2025-05-29

Có lẽ sẽ không có sự thay đổi nào giống hệt như vậy.

Nhưng đây là kiểu thay đổi mà từ rất lâu trước, nhiều nghề nghiệp trong thời cận đại đã từng trải qua. Ví dụ như những thay đổi mà nghệ sĩ đối mặt khi nhiếp ảnh xuất hiện, hay thợ thủ công đối mặt khi các nhà máy tự động hóa ra đời. Việc viết code có lẽ cũng không khác.

Tôi dự đoán rằng khi đổi mới trở thành chuyện thường nhật, rốt cuộc sẽ cần nhiều kỹ sư hơn bây giờ. Kỳ vọng của người dùng sẽ cao hơn, và chúng ta sẽ phải tạo ra những thứ lớn hơn, phức tạp hơn. Giống như điều được nói đến trong giả thuyết Nữ hoàng Đỏ vậy.

Tất nhiên, khả năng loại hình công việc thay đổi hoặc một số nhiệm vụ cụ thể biến mất là rất cao. Giống như nghề sắp chữ thủ công đã biến mất lúc nào không hay vậy. Trong bối cảnh đó, việc thiết kế hệ thống có lẽ sẽ là một phép ẩn dụ hay ví dụ cho mức độ trừu tượng đã được nâng cao hơn.

 
pcj9024 2025-05-29

Tôi nghĩ là vì ai cũng muốn thay thế lập trình viên bằng một thứ gì đó
Có vẻ khá nhiều người cho rằng họ chẳng làm gì mà vẫn được trả rất nhiều tiền

 
draupnir 2025-05-29

Tôi nghĩ rằng bất kể có thực sự bị thay thế hay không, kiểu nội dung đó vẫn liên tục được nhắc đến vì nó rất giật gân.
Phần lớn những trường hợp giật những tiêu đề kiểu đó một cách đầy sảng khoái thì ngay từ đầu vốn không có khả năng là kết quả của một quá trình suy nghĩ sâu sắc về việc thực tế ra sao, hay có thể định nghĩa cái gọi là thay thế như thế nào.
Ngược lại, những nội dung được suy nghĩ nghiêm túc thường sẽ nói về việc hiện tại AI hay các công cụ khác có thể làm được đến đâu và đang phát triển theo hướng nào. Nhưng những tiêu đề chán ngắt như vậy thì người bình thường sẽ chẳng bấm vào đâu.

 
fanotify 2025-05-29

Nhiều tiêu đề rất giật gân..

 
kimjoin2 2025-05-29

Tôi nghĩ nên xem đó là sự thay thế diễn ra dần dần.
Số người cần投入 để tạo ra cùng một kết quả công việc thực sự đang giảm đi.

Ngay cả với việc "thiết kế hệ thống", nếu trước đây 10 người làm mà giờ 8 người + hỗ trợ AI là giải quyết được
thì thực chất đã là tình huống 2 người bị thay thế rồi.

 
callakrsos 2025-05-29

Xét cả khía cạnh thiết kế hệ thống
Có lẽ là vì người ta thường đưa nó vào prompt mà không cân nhắc điều đó

 
ahwjdekf 2025-05-28

Có vẻ vấn đề là rất khó gánh hậu quả của vibe coding.

 
tkddls8848 2025-05-30

Tôi đồng ý với ý kiến này từ trải nghiệm cá nhân. Xét cho cùng AI cũng chỉ là một công cụ, nên từ 1 đến 99 thì thực sự rất nhanh và tốt, nhưng luôn có cảm giác thiếu mất 1 phần còn lại.

 
ethanhur 2025-05-28

Tôi đồng ý, nhưng có lẽ cốt lõi không phải là "thiết kế hệ thống" mà là "giải quyết các vấn đề phức tạp thông qua thiết kế hệ thống".

Tôi tin rằng việc dễ sẽ càng dễ hơn, còn việc khó thì sẽ tiếp tục ngày càng khó hơn.

 
ididid393939 2025-05-28

haha

 
GN⁺ 2025-05-28
Ý kiến trên Hacker News
  • Từ trải nghiệm gần đây khi sửa freelance những việc như “landing page marketing dùng một lần”, có ý kiến cho rằng các khách hàng thích kiểm soát luôn thêm vào những yêu cầu kỳ quặc mà AI không xử lý nổi, để rồi cuối cùng vẫn phải nhờ con người dọn dẹp hậu quả; dù AI có thông minh đến đâu thì vấn đề của phần mềm thường không hẳn là kỹ thuật, mà là con người liên tục tạo ra “độ phức tạp không cần thiết”; rốt cuộc vũ khí lớn nhất của lập trình viên là biết “nói không”, nhưng nếu để AI cạnh tranh với nhau thì sẽ luôn có ít nhất một bên nói “có”, điều này khá đáng lo

    • Phần mềm có thể được triển khai hoàn hảo, nhưng nếu bản thân yêu cầu không phản ánh hiện thực kỹ thuật thì rốt cuộc chỉ sinh ra hỗn loạn; đó là khái niệm cổ điển về “lỗi yêu cầu”; AI giờ cũng có thể xử lý các giới hạn thực tế như định dạng hay khả năng hỗ trợ (ví dụ: gif không hỗ trợ độ trong suốt), nhưng con người sẽ vẫn tiếp tục viết ra những yêu cầu vô lý kiểu “hãy làm logo thành một hình vuông mà mỗi điểm đều nằm cách tâm một khoảng bằng nhau”; lỗi gõ nhầm jpg cũng được nhắc tới như một chi tiết gây cười

    • Giữa “không” và “có” tồn tại 50 sắc độ xám của câu hỏi “ý này có đúng không”; có người từng muốn một trang web “có thể tải xuống cơ sở dữ liệu”, nhưng thực ra chỉ muốn xuất file csv đơn giản, cho thấy việc diễn giải ngữ cảnh quan trọng đến mức nào; cũng có góc nhìn tò mò liệu chatgpt có thật sự nắm được sắc thái này không

    • “Từ chối” mới thật sự là phần khó nhất và mệt nhất trong công việc lập trình viên; nhiều lập trình viên thực ra không thích vai trò này hoặc cho rằng đó không phải việc của mình; cuối cùng, thành công thực sự của dự án không do kỹ thuật quyết định mà do giao tiếp “người với người” với các bên liên quan, nên vẫn luôn cần một “lập trình viên kiêm vai trò PM trên thực tế” như vậy

    • Tất cả điều này được nói rất rõ trong cuốn sách gọi là ‘Peopleware’; lý do người viết thích câu chúc “mong mọi vấn đề của bạn đều là vấn đề kỹ thuật”; vì trên thực tế, những bài toán giải bằng code, trừ một số edge case rất hiếm, vốn chưa bao giờ quá khó

    • Có ý kiến cho rằng đây là một điểm rất hay, đồng thời AI có thể ngày càng giỏi trong việc ước lượng độ phức tạp và đưa ra cảnh báo; ví dụ so sánh với cờ vua, nơi AI đã cho thấy khả năng đánh giá/phán đoán tốt hơn con người rất nhiều; ở đây AI không chỉ giới hạn ở LLM, dù vẫn thừa nhận tiến bộ trong chính nhóm đó

  • Có quan điểm không đồng ý với nhận định trong bài rằng “AI không thể thiết kế hệ thống”; thực tế AI đã và đang tiến bộ dần trong lĩnh vực này, và có hiện tượng liên tục đổi nghĩa các điều kiện cần để dời mục tiêu tranh luận; tuy vậy AI vẫn không thể tự quyết định mình nên muốn gì, hay thay người dùng xác định luôn động cơ của họ (dù tất nhiên có thể gợi ý ý tưởng); trong tương lai vẫn phải có ai đó trực tiếp hành động và muốn giải quyết vấn đề thì xã hội mới vận hành được, vai trò của lập trình viên có thể thay đổi nhưng việc giải quyết vấn đề vẫn là phần của con người

    • Có người nói ý nghĩa của từ “lập trình viên” sẽ thay đổi, nhưng một góc nhìn khác cho rằng bản chất của nó từ đầu đến giờ vẫn vậy; lập trình về cơ bản là biến những yêu cầu mơ hồ thành code rõ ràng; khác biệt qua thời gian chỉ là phương pháp, từ machine code và thẻ đục lỗ đến framework, GUI và các công cụ trực quan, nhưng viết code vẫn hiệu quả nhất vì tính rõ ràng và khả năng truyền đạt; LLM rất mạnh ở việc lặp lại cái có sẵn, nhưng khi thử làm điều hoàn toàn mới hoặc giải thích bằng ngôn ngữ tự nhiên thì lại khá bức bối; thị trường đang ở trạng thái hype cực đại, nhưng rốt cuộc cứ mỗi lần có công nghệ mới thì mô thức thay đổi cục bộ này lại lặp lại

    • Có quan sát rằng các công ty đã bắt đầu giảm tuyển junior vì AI, tức là thay đổi đã có thể cảm nhận được; nếu AI làm được mọi thứ trừ architecting thì kết quả cuối cùng sẽ là chỉ cần ít kỹ sư hơn

    • Có người khẳng định AI vẫn chưa thể làm architecture; architecture và planning là hai việc khác nhau; planning là khả năng phân bổ giới hạn, giải pháp, tài nguyên và dự đoán, và AI vẫn còn rất xa mới làm hiệu quả được; architecture thực sự là thiết kế hợp tác và cạnh tranh trên nhiều lớp, chỉ cần AI sai ở một lớp là toàn bộ hệ thống có thể lệch hướng, và loại hệ thống như vậy chỉ con người mới có thể thiết kế và giám sát an toàn

    • Có ý kiến rằng nếu có đủ thông tin ngữ cảnh thì AI cũng có thể hiểu khá tốt điều người ta muốn; điều này thực ra còn dẫn tới cảnh báo về xâm phạm quyền riêng tư; nếu tổ chức nắm trong tay hệ thống mạnh và công nghệ nhận biết ngữ cảnh, phần đáng sợ hơn là AI có thể dự đoán “đủ tốt” cả nhu cầu lẫn hành động tiếp theo của bạn

    • Cũng có nhận xét thẳng thắn rằng AI hiện không làm architecture mà chỉ đang mô phỏng, thậm chí nhiều khi ngay cả việc code cũng chưa làm tử tế

  • Có quan điểm cho rằng ngay cả giả định doanh nghiệp coi trọng chất lượng cũng đã sai; doanh nghiệp chỉ quan tâm đến lợi nhuận, và chỉ cung cấp chất lượng cao khi khách hàng thật sự muốn; nói thẳng ra thì khách hàng ngoài đời cũng thường thích món “đáng tiền nhất” hơn là chất lượng, nên họ mua công cụ rẻ nhất trên Amazon rồi lặp đi lặp lại việc sản xuất những đoạn code lỏng lẻo kiểu tương tự (vibe code); rốt cuộc nhóm thực sự coi trọng chất lượng chỉ có các kỹ sư, nên các dự đoán tương lai dựa trên góc nhìn kỹ sư rằng chất lượng là quan trọng có thể bị bỏ qua một cách mạnh tay

    • Có ý kiến phản biện rằng chất lượng có thể là điểm khác biệt; thời iPhone xuất hiện, đối thủ có rất nhiều tính năng, nhưng cuối cùng một UI mượt và tinh tế hơn đã áp đảo cả thị trường

    • Có người giới thiệu Fractal Audio là công ty lấy chất lượng làm trung tâm mà họ thích nhất; đây là một công ty nhỏ làm modeler phần cứng cho guitar (mô phỏng ampli và pedal board), nổi bật với các bản cập nhật đổi mới liên tiếp và sự ám ảnh của CEO với chất lượng mô hình analog; chất lượng của họ vượt xa doanh nghiệp lớn, và họ định vị chỉ bằng bán trực tiếp cùng cập nhật thuật toán miễn phí, không hoa hồng, không thuê bao, không marketing người nổi tiếng; đây là ví dụ sống cho thấy có thể giành thị phần bằng chất lượng, và không phải mọi doanh nghiệp đều chỉ lao vào cuộc đua “rẻ nhất, chất lượng thấp nhất”

    • Có phản ứng bác bỏ quan điểm khách hàng không coi trọng chất lượng: nếu chất lượng vô nghĩa thì mọi startup lẽ ra chỉ cần làm sản phẩm lỗi nhưng rẻ là đã đạt doanh thu khổng lồ và thành công lớn rồi

    • Có người liệt kê rằng hầu hết các sản phẩm phần mềm thành công thực sự đều có chất lượng rất tốt; Google, iPhone, Stripe, Notion và những sản phẩm sống lâu trên thị trường đều không phải thứ chậm chạp hay đầy lỗi; ngược lại, chất lượng chính là một yếu tố dẫn tới thành công, và người này thắc mắc vì chưa từng nghe được ví dụ ngược lại nào thuyết phục

    • Có lo ngại rằng chất lượng có thể bị làm mờ dần đến một mức nào đó bởi tính mô-đun hóa, thuê bao hóa và yêu cầu kết nối Internet, nhưng rồi có thể xuất hiện một tương lai nơi mọi thứ sụp đổ nhanh chóng: thiết bị hóa cục gạch, một trang web đơn giản cũng mất 12 giây để chạy, hạ tầng xã hội và hệ thống chính phủ đổ hàng tỷ vẫn bất ổn, và đối thoại thường ngày lại thành nói chuyện với LLM

  • Có hồi tưởng rằng cuộc cách mạng tổ chức kiểu UML trước đây, nơi “kiến trúc sư làm đặc tả còn lập trình viên điền vào chỗ trống”, thực ra lại tạo ra các hệ thống quá phức tạp và làm mất tính linh hoạt; rồi đến “Agile” cũng bị hiểu sai, dẫn tới vi quản lý lập trình viên, thiếu niềm tin và lan rộng văn hóa tổ chức thiếu sáng tạo; cuối cùng, đặc điểm của các nhóm thành công không phụ thuộc công cụ hay quy trình, mà là việc người không phải lập trình viên thật sự quan tâm tới công việc của lập trình viên và cùng nhau giải bài toán; ngược lại, mọi nỗ lực nhằm hạ thấp độ phức tạp đều bị đánh giá là thất bại

  • Trước nhận định rằng “architecting là kỹ năng có giá trị nhất nhưng là phần AI không thể thay thế”, có ý kiến phản bác rằng nếu thực sự yêu cầu AI thiết kế kiến trúc hệ thống một cách rõ ràng, thì trong rất nhiều trường hợp nó còn cho ra kết quả tốt hơn ít nhất 30% số người thiết kế mà họ từng gặp ngoài đời; chỉ là người dùng AI chưa hay yêu cầu kiểu đó mà thôi

    • LLM hiện chủ yếu được huấn luyện trên rất nhiều câu trả lời mức trung bình khá theo best practice, nên tự nhiên sẽ cho ra kết quả tốt hơn khoảng 1/3 số nhà thiết kế con người theo kiểu “thiết kế ổn, hợp lý, giàu common sense”; ngược lại, ở các lĩnh vực hoàn toàn mới không có trong dữ liệu huấn luyện hoặc các ngành cần hiệu năng cực cao, tư duy dựa trên first principles của con người vẫn cần thiết hơn, và DB kernel do LLM thiết kế có lẽ cũng chỉ dừng ở mức cơ bản chứ khó mà đột phá

    • Có phê phán rằng bản thân bài viết mang đúng kiểu văn phong do ChatGPT tạo ra, với câu ngắn, lặp cấu trúc, lạm dụng các thủ pháp như “không phải X mà là X+1”, “không phải X mà là phản-X”, đồng thời ngạc nhiên khi những bài kiểu này lại nhận được nhiều upvote trên HN

    • Có nhận xét rằng tác giả thực chất đang rơi vào “wishful thinking” vì tưởng kỹ năng riêng của mình là architecture thì bất biến và không thể thay thế; nếu người đó giỏi ở năng lực khác thì hẳn cũng sẽ xem chính năng lực ấy là thứ không thể thay thế

    • Có tóm lược rằng bản chất của kiến trúc sư là khả năng hiểu chính xác yêu cầu và ràng buộc rồi phản ánh chúng vào hệ thống; tức là biết viết prompt tốt, đọc câu trả lời cho kỹ và khi cần thì biết phản biện quyết liệt

    • Có ý kiến rằng khá nhiều “architect” ngoài đời thực ra thiếu năng lực thực chất, nghĩ rằng chỉ cần biết công cụ vẽ sơ đồ hay Excel là đủ dù không có chuyên môn hạ tầng CNTT; trông có vẻ giống manager nhưng trên thực tế chỉ một số ít mới làm được phần việc cốt lõi

  • Có quan điểm cho rằng các công ty phụ thuộc “quá mức” vào AI lại đang tự làm tăng rủi ro bị sóng đổi mới cuốn trôi; trong thời đại AI, cốt lõi không phải năng suất tạo code mà là quản trị chất lượng code, nhưng thị trường lại đang tập trung quá mức vào việc sinh code tự động; có nhắc tới phát biểu của Satya Nadella rằng “30% code của MS được viết bằng AI”, cũng như xu hướng trung bình hơn 20 sự cố mỗi tháng trên Github (liên kết nguồn: githubstatus.com/history); có dự đoán rằng những công ty chỉ chăm chăm tối ưu hiệu suất rồi sau đó phải trả giá vì chất lượng suy giảm sẽ còn nhiều, đặc biệt các công ty nhỏ và vừa chứ không phải doanh nghiệp khổng lồ cỡ MS có thể sụp đổ

    • Có ý kiến phản biện rằng chính các công ty phớt lờ AI mới là bên sẽ gặp khó khăn

    • Có người khẳng định “các công ty lạm dụng AI rốt cuộc sẽ gánh chi phí rất lớn về dài hạn” và giới thiệu bài viết liên quan (AI: Accelerated Incompetence)

  • Có người đồng cảm 100% với nhận định “code không phải tài sản mà là nợ”; mục tiêu là đạt được mục đích với lượng code ít nhất có thể; điều đáng lo là AI khiến việc sản xuất code quá dễ, nên nợ code có thể còn phình to hơn nhiều

    • Có chia sẻ liên kết wiki về nghịch lý năng suất của tiến bộ kỹ thuật, tức năng suất tăng nhưng hiệu quả bị bù trừ bởi độ phức tạp hệ thống tăng lên (Productivity paradox)

    • Có ví von rằng thời đại sinh code bằng AI hiện nay giống thời làm website bằng MS FrontPage ngày trước, khi html đầy 90% là code rác vô dụng, một “kỷ nguyên của cruft”

    • Có người đặt ngược vấn đề rằng nếu code nay đã dễ thay thế thì có lẽ góc nhìn coi code là nợ cũng mất ý nghĩa; sau này hễ có lỗi thì lập trình viên chỉ việc bảo AI viết lại, nên gánh nặng có thể giảm đi

    • Cũng có người xem code là một hình thức biểu đạt sáng tạo và nghệ thuật; họ chia sẻ rằng khi nhìn thấy code đẹp, dễ đọc và tinh tế thì có thể cảm nhận ngay vẻ đẹp đó

  • Có người chia sẻ một liên kết nhắc lại rằng ngay từ thời FORTRAN mới ra mắt (1954) đã có khẩu hiệu kiểu “Fortran sẽ xóa bỏ hẳn việc coding và debugging” (BackusEtAl-Preliminary Report)

    • Cũng có người chia sẻ giai thoại “liên tục sai rồi bỗng một lúc nào đó đúng”, tức “ảo tưởng con gà tây” (ví dụ con gà tây ngày nào cũng được cho ăn nên tưởng mọi chuyện sẽ luôn vậy, rồi một ngày bị đem đi làm thịt; Turkey illusion)
  • Có ý kiến cho rằng giả định nằm bên dưới mọi tranh luận này là tiến bộ công nghệ sẽ sớm chạm trần; nhưng nếu giả định đó sai thì biết đâu một ngày nào đó AI sẽ nắm được toàn bộ hạ tầng, log, tài chính và tài liệu để hiểu và thiết kế cả doanh nghiệp một cách tổng thể; mô hình AI vẫn đang mở rộng, khả năng thì ngày càng tốt hơn và rẻ hơn, nên có người nghiêng về phía cho rằng sớm muộn gì nó cũng tiến đến bản chất thật sự của việc thay thế

    • Tuy vậy, nếu điều đó xảy ra thì các hệ thống do AI tạo ra có thể ngày càng trở nên “xa lạ như người ngoài hành tinh” và khó hiểu, còn hệ sinh thái phát triển phần mềm lấy con người làm trung tâm hiện nay có nguy cơ bị thu nhỏ tối đa; vì thế vẫn cần một số chuyên gia giám sát và điều phối lộ trình kỹ nghệ phần mềm của AI như một hình thức kiểm soát xã hội, và đây sẽ là một giai đoạn chuyển đổi dài và phức tạp
  • Có góc nhìn cho rằng việc sa thải lập trình viên không phải do tiến bộ kỹ thuật, mà là hành động tiếp theo của sự bất định, còn công nghệ/AI chỉ là cái cớ hợp lý hóa về sau; ví dụ được nêu là chỉ 5 năm trước, các công ty vẫn sẵn sàng tăng số lượng kỹ sư phần mềm để mở rộng năng suất dù phải chấp nhận chi phí; vì vậy có ý kiến rằng chi phí không phải là gốc rễ

    • Có phản biện rằng “phần năng suất tăng thêm ấy chẳng hiện ra ở bất kỳ chỉ số kinh tế nào”; nếu năng suất thực sự tăng thì lẽ ra phải thấy được trên bình diện toàn nền kinh tế, nhưng thực tế lại không như vậy khiến người ta nghi ngờ
 
click 2025-05-28

Tôi đang tìm người kiểm tra giúp phần vibe coding bằng AI; mọi thứ đã làm xong rồi nhưng đang bị lỗi, chỉ cần sửa nhẹ giúp thôi — kiểu yêu cầu thuê ngoài như vậy đã xuất hiện rồi, nhưng thường thì làm mới từ đầu còn nhanh hơn.

 
aer0700 2025-05-31

Chuyện này tôi cũng từng gặp rồi, kinh khủng thật...

 
mentee313 2025-05-29

Không biết là họ không hiểu hay là không quan tâm nữa, dù sao thì cũng có khá nhiều người như vậy... Dịch thuật cũng vậy... AI đúng là dùng được đấy? Nhưng có vẻ đang khiến rất nhiều người vất vả... Thoạt nhìn thì có vẻ hợp lý, nhưng từ góc độ người phải sửa lại thì công việc còn tăng lên nữa hu hu

 
heim2 2025-05-28

Nổi da gà luôn haha