20 điểm bởi GN⁺ 2026-02-16 | 6 bình luận | Chia sẻ qua WhatsApp
  • Việc AI tạo ra hàng loạt mã phức tạp đang lan rộng, kéo theo hiện tượng tạo ra những đoạn mã mà con người không đọc đến trên toàn ngành
  • Ban lãnh đạo dùng cắt giảm nhân sự do AI để biện minh, còn lập trình viên thì bị gây áp lực phải đạt tỷ lệ mã do AI tạo ra
  • Kiểu ‘vibe coding’ này gây ra trạng thái ‘dark flow’ tương tự cơ chế gây nghiện của cờ bạc, tạo ra ảo giác về năng suất
  • Thực tế, có nghiên cứu cho thấy khi dùng công cụ lập trình AI, người dùng cảm thấy năng suất tăng 20% nhưng thực ra lại chậm hơn 19%
  • AI hữu ích, nhưng khả năng tư duy, sáng tạo và kỹ nghệ phần mềm của con người không bị thay thế, và nếu từ bỏ chúng thì ngược lại còn có nguy cơ thụt lùi

Sự lan rộng của vibe coding và nhận thức về vấn đề

  • Vibe coding là hành vi sản xuất hàng loạt mã phức tạp do AI tạo ra, khiến con người khó đọc hoặc bảo trì
    • Một số công ty biện minh cho sa thải với lý do AI có thể thay thế công việc của con người
    • Lập trình viên bị gây áp lực rằng nếu không đạt tỷ lệ mã do AI tạo ra thì sẽ bị bất lợi trong đánh giá hiệu suất
    • Cả sinh viên lẫn người đi làm đều rơi vào tâm lý lo âu rằng “AI sắp thay thế công việc của mình”, từ đó ngần ngại đầu tư phát triển bản thân
  • AI thực sự hữu ích, nhưng cần thận trọng với vibe coding, và nếu dùng sai có thể dẫn tới hệ quả tiêu cực

Sự khác biệt giữa ‘flow’ và ‘dark flow’

  • Nhà tâm lý học Mihaly Csikszentmihalyi định nghĩa ‘flow’ là trạng thái đắm chìm khi thử thách và kỹ năng ở thế cân bằng
  • Ngược lại, cảm giác đắm chìm cũng có thể xuất hiện trong những hoạt động không liên quan đến kỹ năng như cờ bạc, và đó là một dạng ‘flow giả’
    • Giống trường hợp Loss Disguised as a Win (LDW) của máy đánh bạc, thực chất là thua nhưng lại gây ảo giác như vừa chiến thắng
    • Nghiên cứu cho thấy LDW tạo ra phản ứng sinh lý tương tự một chiến thắng thật, từ đó làm mạnh thêm sự đắm chìm mang tính gây nghiện
  • Hiện tượng này được gọi là ‘dark flow’ hoặc ‘junk flow’, tức sự đắm chìm gây nghiện nhưng không có tăng trưởng

Sự tương đồng giữa vibe coding và cờ bạc

  • Lập trình viên Armin Ronacher cho biết sau khi dùng công cụ lập trình AI, anh tạo ra rất nhiều mã nhưng thực tế gần như không dùng được
    • Đây là một cấu trúc ảo giác tương tự ‘chiến thắng giả’ trong cờ bạc
  • Vibe coding vi phạm các điều kiện của flow ở những điểm sau
    • Thiếu phản hồi rõ ràng về kết quả, thậm chí còn tạo ra cảm giác thành tựu sai lệch
    • Mất cân bằng giữa mức độ thử thách và trình độ kỹ năng
    • Khiến người dùng tin rằng mình có thể điều khiển kết quả thông qua ảo giác kiểm soát
  • Chất lượng mã do AI tạo ra thường chỉ sau vài tuần mới nhận ra vấn đề, khi đó bug và độ phức tạp không thể bảo trì mới lộ rõ
  • Cả LLM lẫn máy đánh bạc đều được thiết kế để tối đa hóa phản ứng tâm lý của người dùng, nhằm thúc đẩy việc tiếp tục sử dụng

Ảo giác năng suất và ‘người kể chuyện không đáng tin’

  • Theo nghiên cứu của METR, các lập trình viên dùng công cụ AI cảm thấy mình nhanh hơn 20% nhưng thực tế lại chậm hơn 19%
    • Điều này có nghĩa là có khoảng cách 40% giữa hiệu quả cảm nhận và hiệu quả thực tế
  • Các bài viết do AI viết cũng trông có vẻ tương tự nhưng đôi khi chất lượng thấp hơn
    • Một bài blog của một nhà nghiên cứu AI sau khi được viết bằng AI đã chuyển sang văn phong kém dễ đọc hơn trước
  • Con người khó đánh giá năng suất của chính mình một cách khách quan, và có xu hướng đánh giá quá cao sau khi dùng AI

Dự đoán sai và rủi ro sự nghiệp

  • Những dự đoán rằng AI sẽ thay thế hoàn toàn việc lập trình đã nhiều lần sai lệch
    • Geoffrey Hinton từng dự đoán đến năm 2021 AI sẽ thay thế bác sĩ chẩn đoán hình ảnh, nhưng điều đó không xảy ra
    • Sundar Pichai và Jeff Dean của Google từng nói đến năm 2023 mọi nhà khoa học dữ liệu sẽ dùng công cụ thiết kế mạng nơ-ron tự động, nhưng điều này cũng không thành hiện thực
    • Dario Amodei của Anthropic dự đoán đến cuối năm 2025 AI sẽ viết 90% toàn bộ mã, nhưng dự đoán này không có cơ sở
  • Vì những viễn cảnh bị thổi phồng như vậy, việc ngừng phát triển kỹ năng của bản thân là rất rủi ro
    • Tốc độ tiến bộ của AI từ trước đến nay luôn bị đánh giá quá cao một cách liên tục

Tầm quan trọng bền vững của tư duy và sáng tạo của con người

  • Các tác tử lập trình AI có thể tạo ra mã đúng về mặt cú pháp, nhưng
    • không thể tạo ra các trừu tượng hữu ích, mô-đun hóa, hay cải thiện cấu trúc mã
    • Nói cách khác, việc viết mã đã được tự động hóa, nhưng kỹ nghệ phần mềm thì chưa được tự động hóa
  • Văn bản do AI tạo ra cũng trôi chảy về mặt ngữ pháp, nhưng không thể mài sắc tư duy hay nắm bắt cốt lõi vấn đề
  • Jeremy Howard cảnh báo rằng “nếu giao phó hoàn toàn việc tư duy cho AI, chúng ta sẽ đánh mất khả năng học hỏi và phát triển
    • AI hữu ích như một công cụ, nhưng không thay thế được năng lực cốt lõi của con người

6 bình luận

 

Khi đánh giá năng lực làm việc của một người, có một yếu tố là 'thái độ'. Ngoài quy trình công việc và mệnh lệnh từ cấp trên, thái độ mà bản thân họ chủ động đối diện với công việc cũng rất quan trọng. Thái độ đó được thể hiện qua sự quan tâm liên tục, sự thấu hiểu và tinh thần trách nhiệm đối với công việc. Trong số đó, tinh thần trách nhiệm là quan trọng nhất. Trí tuệ nhân tạo có thể bắt chước những thứ khác, nhưng không có tinh thần trách nhiệm. Trí tuệ nhân tạo có thể đánh giá kết quả đầu ra, nhưng không thể đánh giá tinh thần trách nhiệm trong suốt quá trình.

 

AI biết rõ "làm thế nào (How)" nhưng không biết "vì sao" phải làm. Chỉ con người mới có thể cố gắng nắm bắt mục đích cốt lõi của công việc, dám chấp nhận thử và sai để tìm con đường mới, đồng thời quyết định phương hướng hướng tới mục tiêu. Tinh thần trách nhiệm không chỉ là theo đuổi kết quả, mà còn là thái độ không đánh mất mục đích trong suốt quá trình, liên tục đặt câu hỏi và khám phá.

 

Khả năng sáng tạo tìm ra những cách khác ngoài cẩm nang và chỉ dẫn cũng bắt nguồn từ một thái độ có trách nhiệm.

 
dieafterwork 2026-02-17

Hoàn toàn đồng cảm.

 
GN⁺ 2026-02-16
Ý kiến trên Hacker News
  • Đang suy nghĩ xem giữa rủi ro dùng AI quá nhiềurủi ro dùng quá ít thì bên nào lớn hơn
    Hiện tại tôi cảm thấy vế đầu nguy hiểm hơn nhiều. Có bug kiểu bịa đặt, kiến trúc đi vào ngõ cụt, vấn đề bảo mật, cảm giác sở hữu code suy giảm và mất cơ hội học hỏi
    Ngược lại, nếu dùng AI ít hơn thì năng suất có thể giảm, nhưng sự hiểu biết sâu về codebase và quá trình rèn luyện có thể trở thành tài sản lớn hơn về lâu dài
    Cá nhân tôi nghĩ ý tưởng sáng tạo nảy ra khi trực tiếp vật lộn trong code mới là thứ giá trị nhất
    Điều đáng tiếc là nếu giao cho AI quá sớm thì sẽ đánh mất những cơ hội như vậy
    • Ngay cả khi lập trình có AI hỗ trợ, nếu không hạ thấp tiêu chuẩn thì ngược lại còn có thể tập trung sâu hơn
      Bớt việc lặp đi lặp lại nên đầu óc đỡ mệt hơn, có thể tập trung vào vấn đề khó và nảy ra ý tưởng tốt hơn
      Điều cốt lõi là giữ được gu và tiêu chuẩn tốt
    • Tôi từng thử agentic coding và bị dẫn vào một kiến trúc ngõ cụt
      Khi chuẩn bị trước thiết kế và tài liệu thật kỹ thì tỷ lệ thành công cao hơn
      Phần thực sự khó không phải là sinh code mà là giai đoạn lập kế hoạch và thiết kế
      Bù lại, dùng LLM để viết tài liệu hay boilerplate giúp tiết kiệm rất nhiều thời gian
    • Mỗi người dùng AI để code theo một cách rất khác nhau
      Có người muốn hoàn thiện cả ứng dụng trong một lần, có người chỉ dùng ở mức tự động hoàn thành đơn giản
      Vì liên tục xuất hiện cách làm mới nên tốt nhất là giữ đầu óc cởi mở và thử nhiều hướng khác nhau
    • Tôi nghĩ khung nhìn “AI quá nhiều vs quá ít” là cách tiếp cận sai
      Với công nghệ mới, nguyên tắc chuẩn luôn là kiểm chứng ở quy mô nhỏ rồi mở rộng dần
      Mức dùng AI đúng là mức ‘đã được kiểm chứng’
      Việc đẩy thảo luận kiểu này theo hướng cược Pascal thật đáng buồn, và thường là logic của những người đang cố bán thứ gì đó
  • Ở góc độ người làm công cụ tự động hóa kế toán, Vibe coding là thảm họa
    Dù AI có viết code tốt đến đâu thì các chế độ thất bại vô hình như lỗi tinh vi trong tính thuế mới là nguy hiểm nhất
    Những con số sai có thể âm thầm được phản ánh vào hệ thống kế toán thật
    Vì vậy tôi chỉ dùng AI như một công cụ tự động hoàn thành cao cấp — kiến trúc và logic nghiệp vụ thì tự thiết kế, chỉ dùng cho code lặp lại hoặc dựng khung test
    Cuối cùng, vấn đề không phải là “code do AI viết”, mà là code mà chính tôi cũng không hiểu rõ
    • Việc không nhìn thấy chế độ thất bại thì code của con người cũng vậy
      • Ngược lại, loại rủi ro này thậm chí có thể trở thành dịp để bộc lộ sự thiếu vắng quản trị rủi ro
    • Rốt cuộc những vấn đề này là vấn đề của thiếu test
      • Dù là code người viết hay AI viết, nếu không có test thì thất bại sẽ không lộ ra
    • Cũng có người hỏi liệu lỗi tính thuế chẳng phải sẽ bị hệ thống kế toán kép phát hiện sao
    • Có người nói “tôi xử lý cả tác vụ phức tạp bằng AI vẫn ổn”, và cho rằng cuối cùng đó là khác biệt về kỹ năng viết prompt
    • Người khác nữa thì nói “mấy vấn đề đó phải giải quyết ở tầng kiến trúc”, và cho rằng khả năng audit và cấu trúc rollback mới là mấu chốt
  • Tôi rất đồng cảm với câu “coding đã được tự động hóa nhưng software engineering thì chưa
    LLM viết hàm khá tốt, nhưng không quyết định được cần những hàm nào
    Kiến trúc của dự án thực tế là thứ được tạo ra bằng cách va chạm với các nút thắt của đời thực
    AI chỉ giúp tăng tốc độ triển khai, còn phán đoán mang tính cấu trúc hoàn toàn là phần việc của con người
    Đặc biệt, bug nghiệp vụ là thứ LLM tuyệt đối không thể bắt được
    Cuối cùng, con người vẫn phải chịu trách nhiệm cho kiến trúc và tri thức miền nghiệp vụ
    • Có người hỏi vặn lại: “Bạn đã thử hỏi LLM thiết kế kiến trúc chưa?”
      Nếu chỉ bảo nó ‘viết code’ thì đương nhiên nó không làm được chuyện đó vì đó đâu phải mục tiêu
    • Có người khác nhắc đến lợi ích rất thực tế là nhờ AI mà đau cổ tay giảm đi
  • Tôi nghĩ không cần phải ngừng đầu tư cho sự phát triển của bản thân chỉ vì các dự đoán của giới nghiên cứu AI
    Trong 1 năm qua tôi đã học song song cả thiết kế phần mềm và Vibe coding
    Nhờ học nhiều sách về DDD, Clean Architecture, Agile, tôi đã trở thành một kỹ sư tốt hơn rất nhiều
    Dù dùng AI thì trách nhiệm với code vẫn là phần của tôi
    Hoàn toàn có thể cùng lúc phát triển ở cả hai mảng
    • Biết dùng tốt công cụ hỗ trợ code bằng AI cũng là một kỹ năng lành nghề
      Nó cần đầu tư thời gian và luyện tập, nhưng rất đáng học và không thay thế các kỹ năng khác
    • Tôi cũng tương tự, chọn đọc những cuốn như triết lý thiết kế phần mềmthiết kế hướng dữ liệu
      Vì thứ LLM làm không tốt là phán đoán cấp cao và thiết kế cấu trúc
      Một hệ thống được thiết kế tốt sẽ tối đa hóa hiệu quả của AI
      Đồng thời, học các paradigm mới cũng giúp đánh giá và cải thiện code do LLM tạo ra tốt hơn
      Các kỹ thuật như BDD, PBT, kiểm chứng mô hình là công cụ giúp việc code với AI an toàn hơn
    • Trong khi đó, một người có 20 năm kinh nghiệm lại khuyên nên mạnh tay vứt bỏ, nói rằng “DDD là vô dụng
    • Cũng có người hỏi “trong ba cuốn sách về DDD thì cuốn nào hữu ích nhất?”
  • Tôi đã làm hai dự án phức tạp với Claude Code; ban đầu tốc độ thật đáng kinh ngạc nhưng cuối cùng mọi lợi ích đều biến mất vì một giả định sai mang tính chí mạng
    Bề ngoài trông như một chiến thắng, nhưng thực ra đó là chiến thắng đội lốt thất bại
    Có người ví cách mô tả đó giống hệt cơn phê thuốc và cú rơi sau đó
  • Không phải cứ là lập trình viên giỏi thì sẽ là kiến trúc sư, nhà thiết kế hay PM giỏi
    Muốn tận dụng LLM cho đúng thì phải có đủ cơ bắp của cả ba vai trò đó
    • Người khác phản bác rằng “một kỹ sư giỏi thì vốn dĩ đã phải là PM và kiến trúc sư giỏi”
    • Có người lại phê phán văn hóa thiết kế đồng phục, nói rằng ‘thiết kế tốt’ trong mắt UI designer thường lệch khỏi nhu cầu người dùng thật
    • Có người châm biếm rằng rốt cuộc vẫn đang làm việc của kiến trúc sư, designer, manager nhưng chỉ được đối xử như lập trình viên
  • Chìa khóa của thành công là khả năng định nghĩa cụ thể tiêu chí thành công
    Nếu có thể hình dung rõ UI/UX mình muốn thì với các model hiện nay cũng đã đủ để cho ra kết quả rất tốt
    Ngược lại, kiểu prompt “làm đại cho tôi đi” thì rất nguy hiểm
    Cần đối xử với AI như một bộ giáp cơ khí cao cấp — con người phải ở trong vòng lặp thì mới thật sự nhanh
  • GPT năm 2017 tạo ra văn bản giả trông có vẻ hợp lý, nhưng đến 2023 thì đã hoàn toàn khác
    Tốc độ phát triển công nghệ quá nhanh, việc năm ngoái còn khó thì giờ đã trở nên tầm thường
    Ngay cả công cụ AI từng dùng nội bộ cũng đang bị thay bằng model mã nguồn mở
    Bây giờ có cảm giác như đang ở thời kỳ “Don’t Look Up phiên bản AI” — ai cũng phải kịp thời tái định vị bản thân cho kỷ nguyên AI trước khi quá muộn
  • Mỗi người có cách tiếp cận AI coding khác nhau, nhưng vibe coding vô định hướng như Armin nói là rất nguy hiểm
    Một người bạn đã dùng Cursor làm sản phẩm suốt 3 tháng, nhưng nhiều tính năng mà vô dụng
    Cuối cùng vấn đề là không có ai thực sự hiểu code
    • Tôi chỉ dùng AI cho công việc lặp lại và brainstorm bug
    • AI xử lý corner case khá nhất quán nên tôi tập trung vào thiết kế và kiến trúc
  • Thật ngạc nhiên khi có những lập trình viên tạo code rồi thậm chí không thèm review
    Thật khó hiểu khi họ còn không làm nổi một bước kiểm tra tinh thần cơ bản (sanity check)
    • Có người nói vì code AI phần lớn là đúng nên dần sinh ra mệt mỏi khi review
      • Vấn đề lại thường ẩn ở các pattern kiến trúc hơn là bản thân đoạn code
    • Có người khác khuyên nên xác minh từ sớm, nói rằng theo nghiên cứu của IBM thì sửa lỗi ở giai đoạn thiết kế rẻ hơn 15 lần
    • Có người khẳng định thẳng rằng “những người đó không phải lập trình viên thật”
    • Người khác nữa phân tích rằng có lẽ là do tầng thấp bên dưới đã trở nên quá đáng tin
      • Giống như chúng ta không tự đi kiểm tra binary đã biên dịch, họ cũng ngộ nhận rằng với AI thì có thể như vậy
 
shakespeares 2026-02-19

Không thể thực hiện các cải thiện hữu ích về trừu tượng hóa, mô-đun hóa và cấu trúc mã
>> Tôi đồng ý.