14 điểm bởi GN⁺ 2025-08-06 | 10 bình luận | Chia sẻ qua WhatsApp
  • Những tuyên bố rằng AI có thể nâng năng suất của kỹ sư lên 10~100 lần là không thực tế
  • Khi thực sự sử dụng sâu các công cụ lập trình AI, có thể thấy mức cải thiện hiệu quả là có giới hạn, và chỉ ở các công việc lặp lại, đơn giản mới xuất hiện sự bùng nổ năng suất tạm thời
  • Các điểm nghẽn của phát triển phần mềm (review code, cộng tác, lập kế hoạch, v.v.) không thể được AI vượt qua, nên không thể tăng gấp 10 lần trên toàn bộ công việc
  • Huyền thoại kỹ sư 10x bắt nguồn từ nhiều động cơ khác nhau như bóp méo số liệu, lợi ích của các bên trong ngành, hoặc việc gây bất an trong tổ chức
  • Duy trì cách phát triển và niềm vui làm việc theo cách của riêng mình sẽ tạo ra kết quả tốt hơn về lâu dài và một văn hóa tổ chức lành mạnh

Sự hoài nghi về huyền thoại kỹ sư AI 10x

Cảm giác bất an về năng suất và trải nghiệm dùng công cụ AI trong thực tế

  • Trên LinkedIn, Twitter và các nền tảng khác, những câu chuyện rằng AI có thể nâng năng suất kỹ sư lên 10~100 lần đang lan rộng, khiến nhiều lập trình viên cảm thấy lo lắng rằng mình có thể bị tụt lại phía sau
  • Tác giả cũng đã đưa nhiều agent sinh mã bằng AI vào sử dụng thực tế (Claude Code, Cursor, Roo Code, Zed v.v.), nhưng dù thuận tiện trong các công việc đơn giản, lặp lại, chúng không tạo ra sự chuyển đổi căn bản trong công việc thực tế phức tạp
    • Có thể viết nhanh mã lặp đi lặp lại (boilerplate) trong JavaScript (đặc biệt là React)
    • Nhưng với các tiêu chuẩn riêng của codebase hoặc các thư viện đặc thù, AI không thể theo kịp một cách chính xác
    • Với các ngôn ngữ như Terraform, hiệu năng giảm vì AI không quen thuộc
    • Do hiện tượng hallucination, AI có thể tạo ra cả những thư viện không hề tồn tại, thậm chí gây ra lỗ hổng bảo mật
  • Khả năng hiểu ngữ cảnh của AI hiện vẫn còn hạn chế. Codebase thực tế càng phức tạp thì càng phát sinh prompt lặp đi lặp lại, lỗi và lãng phí thời gian
  • Kết quả là tác giả dùng AI cho các script nhỏ hoặc công việc không cốt lõi, còn các công việc phức tạp hoặc quan trọng thì vẫn tự làm

Vấn đề định lượng năng suất trong phát triển phần mềm

  • Tuyên bố rằng năng suất có thể tăng 10~100 lần nhờ AI là con số xa rời thực tế
  • Năng suất 10x, 100x không đơn giản là số dòng code, mà có nghĩa là một việc vốn mất 3 tháng (bao gồm phát triển tổng thể, review code, QA, v.v.) sẽ hoàn thành trong 1,5 tuần
  • Trong phát triển phần mềm luôn tồn tại nhiều điểm nghẽn như lập kế hoạch, ước tính story point, sửa bug, review code, chờ triển khai, test, QA
    • Muốn đạt mục tiêu đó, mọi công đoạn đều phải nhanh hơn 10 lần theo cùng một tỷ lệ
    • Trên thực tế, thời gian dành riêng cho việc viết code là ít, còn phần lớn thời gian được đầu tư vào hiểu vấn đề, thiết kế, xem xét, giao tiếp
  • Trong thực tế, review code, cộng tác, giao tiếp, QA, v.v. không thể rút ngắn bằng AI
  • Điểm nghẽn trong công việc kỹ thuật thực tế nằm ở con người, quy trình và giao tiếp
  • LLM (mô hình ngôn ngữ lớn) có thể giảm thời gian gõ bàn phím, nhưng thời gian cho chất lượng code, test và review vẫn luôn cần thiết
  • Dù AI có thể tạm thời tăng tốc độ viết code, nhưng do tỷ lệ lỗi tăng, không đáp ứng chuẩn code, phải re-prompt lại, v.v., nó không tạo ra tác động mang tính quyết định lên mức tăng năng suất tổng thể
    • Năng suất gấp 10 lần trên thực tế là mục tiêu gần như bất khả thi

Bản chất và giới hạn của kỹ sư 10x

  • Về sự tồn tại của "kỹ sư 10x", tác giả cho rằng điều đó có thể xảy ra tạm thời và trong phạm vi hạn chế
    • Lý do lớn nhất là năng lực ngăn chặn công việc không cần thiết (tránh phát triển không cần thiết ngay từ giai đoạn lập kế hoạch, cải thiện trải nghiệm phát triển, tài liệu hóa, v.v.) được tích lũy theo thời gian
    • Nhưng không phải kỹ sư nào cũng gặp tình huống như vậy mọi lúc
  • Những kỹ sư xuất sắc có thể ngăn chặn việc thừa thãi hoặc nâng hiệu quả của cả tổ chức thông qua cải tiến hệ thống, nhưng trên thực tế gần như không có trường hợp nào liên tục đạt hiệu suất gấp 10 lần
  • Các công cụ lập trình AI không đóng góp nhiều vào việc ngăn ngừa công việc không cần thiết
    • Ngược lại, từ các gợi ý của AI có thể dẫn đến triển khai quá mức hoặc đề xuất kiến trúc sai
    • Viết code nhanh không phải lúc nào cũng có nghĩa là một kỹ sư giỏi

Bối cảnh và động cơ của huyền thoại AI 10x

Phần lớn các tuyên bố về "năng suất gấp 10 lần" bắt nguồn từ những yếu tố sau

  • Những kỹ sư thiện chí nhưng mắc lỗi đo lường
    • Với công cụ AI, đôi khi có thể trải nghiệm mức hiệu quả bùng nổ trong một khoảnh khắc ngắn (ví dụ: tự động viết custom rule cho ESLint)
    • Nhưng khi những công việc đó lặp lại, chênh lệch năng suất cuối cùng sẽ nhanh chóng thu hẹp
    • Sự mới lạ về kỹ thuật, việc thích nghi với môi trường mới, v.v. ở giai đoạn đầu có thể tạo ra ảo giác hiệu quả bị phóng đại
  • Incentive và các bên liên quan
    • Các nhà sáng lập startup AI, nhà đầu tư, v.v. thường trích dẫn các con số phóng đại để phục vụ thành công kinh doanh
    • Kỹ sư hoặc lãnh đạo cũng có thể nói đến năng suất bị thổi phồng để đáp ứng kỳ vọng trong tổ chức
  • Mục đích xấu
    • Một số lãnh đạo lan truyền những tuyên bố phóng đại với ý đồ tạo bất an cho kỹ sư nhằm ngăn chặn biến động nội bộ như chuyển việc hay đòi tăng lương
    • Nỗi sợ rằng AI sẽ khiến ai cũng dễ dàng bị thay thế cứ lặp đi lặp lại theo chu kỳ (tương tự tranh cãi về bootcamp lập trình trước đây)

Kết quả AI trong open source và các dự án thực chiến ngoài đời thực

  • Phần lớn các câu chuyện thực tế về việc AI giúp tăng năng suất đều có một khoảng cách giữa người viết và kỹ sư thực sự được cho là đã tăng năng suất.
    • Những trường hợp do chính kỹ sư trực tiếp chứng minh việc sử dụng công cụ AI cho thấy một bức tranh thực tế, không cường điệu
    • Kết quả ứng dụng AI trong các dự án open source nhiều khi cũng cho thấy hiệu quả dưới kỳ vọng hoặc thậm chí thất bại
  • Trong các demo công khai hoặc các trường hợp kỹ sư thực tế, AI đôi lúc có vẻ như phép màu, nhưng phần lớn vẫn không khác nhiều so với một "máy sinh văn bản" truyền thống

Giá trị quan trọng hơn "năng suất" - Hãy giữ cách phát triển phù hợp với chính mình

  • Dùng AI đôi khi có thể giúp viết code nhanh hơn, nhưng tác giả vẫn coi trọng niềm vui của chính việc lập trình hơn
  • Nếu bạn không thích hoặc không thấy vui khi lập trình với AI, thì việc từ bỏ một phần năng suất cũng không sao
    • Ngay cả khi phải chấp nhận một mức độ kém hiệu quả nào đó, làm việc theo cách phù hợp với bản thân vẫn tạo ra kết quả lành mạnh và tốt hơn về lâu dài
  • Khi làm việc một cách vui vẻ, bạn có thể có khả năng giải quyết vấn đề, thiết kế và cộng tác với đồng nghiệp tốt hơn
    • Niềm vui và sự nhập tâm quan trọng hơn đối với năng suất dài hạn và chất lượng code, còn nếu chỉ ép mình chạy theo năng suất thì nguy cơ burnout sẽ tăng lên
  • Ngược lại, nếu lập trình với AI thực sự thú vị và hữu ích thì hoàn toàn có thể tận dụng tích cực

Lời khuyên để xây dựng văn hóa tổ chức lành mạnh

  • Khi triển khai công cụ AI, việc tạo ra kỳ vọng phi thực tế và cảm giác bất an cho toàn bộ kỹ sư sẽ gây hại cho năng suất của tổ chức
  • Sự ám ảnh tối đa hóa năng suất sẽ dẫn đến giảm chất lượng, làm xấu đi codebase và gây tổn thất dài hạn
  • Điều hợp lý là trao cho kỹ sư đủ quyền tự chủ và sự tin tưởng, đồng thời để việc sử dụng AI được lựa chọn theo cách phù hợp với từng người
    • Tổ chức nên tạo cơ hội để sử dụng AI, nhưng bầu không khí đảm bảo tính tự chủ mới là điều quan trọng
  • Nếu LLM và đổi mới lập trình bằng AI thực sự mang lại năng suất gấp 10 lần, các lập trình viên tự nhiên sẽ tự tìm đến nó

Kết luận

  • Cuộc cách mạng kỹ sư 10x nhờ AI gần với một huyền thoại hơn, và thực tế không có công thức bí mật nào đang bị bỏ lỡ
  • Niềm tin vào năng lực và cách làm của chính mình là quan trọng nhất
  • SNS (đặc biệt là LinkedIn, Twitter) khuếch đại những huyền thoại bị phóng đại, nên có thể bỏ ngoài tai

10 bình luận

 
aliveornot 2025-08-06

Có ai thật sự hiểu 10x là đúng gấp 10 lần không. Tôi đương nhiên nghĩ đó chỉ là kiểu nói phóng đại để marketing/tự PR, nên thấy mọi người nghiêm túc quá mà cũng bối rối.

 
zziuni 2025-08-07

Dù chưa đến mức 10x, vẫn có khá nhiều tổ chức thực sự tin vào mức tăng trưởng năng suất kiểu Nx. Họ kỳ vọng thay thế chi phí nhân sự bằng chi phí AI và đạt được kết quả còn cao hơn thế…
Điều đó cũng không hẳn là ảo tưởng vô căn cứ, vì khi PM muốn thử một PoC đơn giản hay làm các công cụ cho công việc lặp lại thì mọi thứ có thể được dựng lên rất nhanh.
Vì vậy, liệu trong số các lập trình viên có ai thực sự tin điều này không... thì tôi nghĩ bầu không khí trong ngành hiện nay đã lan rộng đến mức ai cũng có thể cảm thấy đủ bất an, tùy vào hoàn cảnh mình đang đối mặt.
Tôi nghĩ những cuộc thảo luận nghiêm túc như thế này là cần thiết, kể cả chỉ để giao tiếp với các vị trí không làm phát triển và với lãnh đạo tổ chức.

 
aliveornot 2025-08-07

Tất nhiên tôi không phủ nhận những thứ giúp tăng năng suất. (Ở trình độ AI tại thời điểm hiện tại) tôi nghĩ chuyện 10x đương nhiên là không hợp lý, nhưng vì nội dung bài gốc là nghiêm túc nói rằng "không thể gấp 10 lần", nên tôi thấy điều đó khá khó hiểu nên mới viết bình luận này, dù có vẻ cách diễn đạt của tôi hơi không được hay cho lắm.

 
1q2w3e4r 2025-08-07

Cũng như việc anh/chị nói rằng năng suất do AI mang lại là cách diễn đạt phóng đại phục vụ cho marketing/tự PR, tôi cũng cho rằng bài viết đó có phần hơi cường điệu.

Vì vậy, nội dung kiểu như "thật sự có ai hiểu 10x là gấp đúng 10 lần không" tạo cảm giác như đang bắt bẻ tiểu tiết, nên có lẽ đã khiến người ta phản cảm.

 
chihyeon921 2025-08-06

Có vẻ như bạn đã trả lời mà chưa đọc bản gốc nhỉ, vì ở đâu trong bài gốc cũng không hề làm quá mọi chuyện một cách nghiêm túc cả...

Vậy thì việc mức sử dụng của DataTube.tv, dịch vụ tìm ý tưởng viral YouTube do tác giả phát triển, được nói là "gấp hàng chục lần" so với Viewtrap, đương nhiên cũng chỉ là cách diễn đạt phóng đại để marketing/tự PR thôi đúng không?

Không biết là vì trên mạng nên vậy hay vốn dĩ bạn vẫn thế, nhưng phần lớn bình luận đều được viết với góc nhìn khá phê phán.
Mong bạn có thể nhìn nhận cởi mở hơn một chút.

 
crawler 2025-08-06

Tôi cũng nghĩ đã có kiểu tung hô quá đà về AI thì cũng có cả phản ứng ngược lại, nên tôi không có nhiều suy nghĩ về phần nội dung chính...
Bình luận này đúng là ghê thật; nhìn cả bài viết trước đây rồi mới để lại bình luận nên hôm nay bạn vừa mới đăng ký mà cũng thấy sợ

 
aliveornot 2025-08-06

Nhìn vào bình luận của bạn và cả lịch sử của tôi, tôi không thấy có bình luận nào thực sự đáng xấu hổ cả; vấn đề là ở việc nhìn nhận mọi thứ bằng góc nhìn phê phán sao? Hay là phải sống tốt như bạn, tức là không để lại bất kỳ bình luận nào...

 
aliveornot 2025-08-06

Hả? Tôi còn quy đổi con số 10 lần đó ra cả số tháng nữa mà... Nếu cụm từ kiểu "nghiêm túc quá" làm bạn khó chịu thì tôi cũng hiểu. Mấy chục lần của Datatube là con số định lượng. Mà thôi, dù sao giờ cũng không còn vận hành nó nữa...

 
GN⁺ 2025-08-06
Ý kiến Hacker News
  • Tôi không hiểu vì sao chỉ riêng ngành kỹ nghệ phần mềm lại ám ảnh với huyền thoại năng suất "10x", trong khi kỹ sư cơ khí, điện, xây dựng hay hóa học không hề có khái niệm này
    Một kỹ sư giỏi là người có khả năng giảm rủi ro và thiết kế hệ thống trong nhiều ràng buộc khác nhau
    Thiết kế là quá trình hiểu miền bài toán thông qua mô hình, rồi nắm được phạm vi hiệu lực và giới hạn của mô hình
    Không có cái gọi là "10x", chỉ có việc chịu trách nhiệm cho những hệ thống tốt
    Nếu có một kỹ sư phần mềm "10x", thì đó sẽ là người ngăn được các sự cố như rò rỉ dữ liệu, và tôi muốn thấy những sự cố kiểu đó giảm đi gấp 10 lần hơn

  • Tôi cũng đồng ý với phần lớn bài viết này
    Tôi là fan lớn của việc phát triển với công cụ AI, nhưng các tuyên bố về năng suất 10x chưa bao giờ thuyết phục được tôi
    Nhờ LLM, một số công việc như gõ code đã nhanh hơn 2~5 lần, nhưng đó chỉ là một phần của toàn bộ công việc
    Trên thực tế, nhiều kỹ sư nghĩ rằng một số tác vụ cụ thể có thể nhanh hơn 20~50%, nhưng điều đó không đồng nghĩa năng suất tổng thể tăng 20% hay tăng lên 10x
    Tất nhiên, người dùng AI thực sự giỏi có thể cảm nhận mức tăng năng suất lớn hơn 0.2x, nhưng vì độ phức tạp bản chất của phát triển phần mềm nên 10x phần lớn là không thực tế

    • Khi dùng AI, tôi vẫn phải liên tục ngồi bên cạnh trông chừng nên không thấy nó hiệu quả đến vậy
      Đôi khi gợi ý của copilot khớp hoàn hảo với suy nghĩ của tôi và khiến tôi trầm trồ, nhưng nhìn chung nó không giống một lập trình viên junior rất lành nghề mà giống một "senior developer say xỉn" hay không chịu nghe lời hơn
      Một nửa số code được tạo ra còn không biên dịch nổi, mà kể cả có biên dịch được thì cũng không chạy đúng

    • Theo trải nghiệm của tôi, AI không tạo ra cú nhảy năng suất quá lớn ở mảng tạo mới (creation), nhưng lại cực kỳ hữu ích cho khám phá (discovery), học tập, gỡ chỗ bị tắc và viết code lặp lại
      Tuy vậy, thay đổi thực sự lại xảy ra ở các side project
      Trước đây tôi thường quá mệt để dành thời gian cho việc làm thêm, còn giờ thì dù code chưa hoàn hảo, tôi vẫn có thể nhanh chóng biến ý tưởng thành hiện thực với ít hao tổn tinh thần hơn
      Kỹ năng AI engineering cũng có thể được thử nghiệm tự do mà không bị ràng buộc bởi deadline, quyền riêng tư hay công cụ

    • Tôi nghĩ ngay cả những người được gọi là "kỹ sư 10x" cũng sẽ chỉ được hưởng mức tăng năng suất rất nhỏ từ AI
      Lập trình viên giỏi nhất tôi từng biết có hai năng lực cốt lõi: trí nhớ phi thường và nhớ như in chi tiết của mọi ngôn ngữ/thư viện, cùng với khả năng sáng tạo và giải quyết vấn đề gần như kỳ diệu
      Điều ấn tượng là dù không biết công thức hay lý thuyết gì, họ vẫn tìm ra được lời giải độc đáo và gọn gàng nhất cho đúng vấn đề đó
      Khi pair programming với AI để đi tới một lời giải tương tự, AI cần vô số lần thử-sai-lặp lại, và kết quả là còn làm chậm tốc độ của thiên tài con người
      Nhưng vì phổ năng lực quá đa dạng nên ở vị trí của tôi, AI lại có thể mang đến mức tăng năng suất 10 lần
      Chuyên môn của tôi không phải phần mềm, và vì xu hướng cầu toàn nên tôi phát triển rất chậm; nhờ AI, tôi có thể nhanh chóng làm ra bản đầu tiên còn thô nhưng hữu ích để hiện thực hóa ý tưởng

    • Tôi cũng ủng hộ việc phát triển AI assistant và nghĩ rằng trong một số tình huống, mức tăng tốc 2~10 lần là có thể tồn tại
      Nhưng phần lớn khi nói "năng suất 10x", người ta đang phóng đại như thể toàn bộ quá trình phát triển từ đầu đến cuối để làm ra một tính năng đã nhanh hơn 10 lần
      Thực tế là nhiều phần của quy trình phát triển tổng thể (ngoài việc coding) không thể nhanh hơn 10 lần
      Dù vậy, trong môi trường thật sự rất nhỏ hoặc làm việc một mình, ta có thể bỏ qua nhiều thủ tục rườm rà nên tốc độ thực tế tăng đáng kể
      Theo nghĩa đó, đây là thời đại mà các nhóm nhỏ và lập trình viên solo đột nhiên có được năng lực cạnh tranh

    • Cảm ơn bình luận của Simon
      Đây đúng là kiểu bình luận cho thấy người viết thực sự đã đọc bài
      Tôi cũng công nhận rằng ở một số công việc chuyên biệt theo ngôn ngữ hay công cụ, mức tăng năng suất 2 lần là có thật

  • Tôi đã mơ về tự động hóa phát triển phần mềm suốt nhiều thập kỷ, và cảm giác như LLM đã hiện thực hóa giấc mơ đó theo một cách hoàn toàn khác
    Những thứ trước đây như công cụ CASE, UML hay IDE đều hứa rằng sẽ "giúp ta tập trung vào logic thật sự", nhưng LLM thì đơn giản là tạo ra ngay code có thể chạy được từ ngôn ngữ tự nhiên
    Nhiều lập trình viên thấy bất an vì những nghi thức nhập môn cũ đang sụp đổ, và lo mình sẽ bị tụt lại trong thế giới mới này (hội chứng kẻ mạo danh)
    Giờ đây người ta lại phải hỏi kỹ nghệ phần mềm thực chất là gì
    LLM là hình thái tối hậu của các công cụ CASE trước kia, nhưng quá trình này diễn ra quá nhanh, quá hỗn loạn và quá mang tính phá hủy
    Ngay cả những người không biết "ngôn ngữ thiêng" của kỹ sư phần mềm giờ cũng có được quyền lực, và nhiều kỹ sư bắt đầu tự hỏi ở mức căn bản rằng "rốt cuộc mình đang làm công việc gì vậy?"

    • Giờ thì tôi mới hiểu cảm giác của các nghệ sĩ khi nhìn thấy stable diffusion
      Code do AI tạo ra rốt cuộc thường sai, đầy bug, đầy quy ước kỳ quặc hoặc những thứ thừa thãi
      Sửa hết các vấn đề đó đôi khi còn mất thời gian ngang với tự làm
      Dù có thử nhiều model hay tinh chỉnh prompt đi nữa, tôi vẫn thấy thứ code chất lượng cao thực sự mình muốn vẫn chưa với tới được
      Giống như trong stable diffusion, người không để ý sẽ không nhận ra có gì đó kỳ quặc; người không rành AI code cũng không biết rằng nó có vấn đề
      Gần đây tôi xem code của một đồng nghiệp vì thấy có gì đó lạ, thì phát hiện debugger cũng không chạy được và đầy rẫy vấn đề, sau đó người đó thú nhận là "chỉ code theo cảm giác"

    • Nhìn thế giới gần đây, tôi cảm thấy vốn đang liên tục phá hủy lao động
      Lương thấp, điều kiện làm việc tệ, giám sát, áp lực KPI, doanh nghiệp phi đạo đức, hợp đồng ngắn hạn... thực tế mà đa số người lao động đang phải chịu ngày càng xấu đi
      Bấy lâu nay chúng ta được bảo vệ quá nhiều nên chưa cảm nhận rõ điều đó, nhưng giờ thì chính chúng ta cũng đang đối mặt với một tương lai bất ổn

    • "Kỹ nghệ phần mềm" rốt cuộc sẽ biến thành công việc sửa lại vibe
      Rất nhiều nghề có thể bị thay thế bằng phần mềm, nhưng thực tế là các nhà quản lý vốn đã không muốn thuê SWE nếu không chứng minh được giá trị rõ ràng
      Với việc áp dụng AI, các nhà quản lý sẽ cho tạo ra hàng đống code mà chính họ không hiểu, và ba năm sau khi mọi thứ vỡ tung thì lại gọi SWE quay lại sửa
      Trái lại, rất có thể sẽ có nhiều việc làm khó và giá trị cao hơn để sửa những "vấn đề mà AI không giải quyết nổi"

    • LLM tạo code trực tiếp mà không cần mô hình hay sơ đồ chính thức
      Tôi lại muốn AI tạo ra những thiết kế hay sơ đồ chính thức đó hơn
      Những công cụ như vậy hữu ích cho việc hiểu code và làm rõ thiết kế
      Tôi mong AI hỗ trợ được cả phần này

    • Nút thắt của phát triển phần mềm không phải tốc độ gõ hay tạo ra code mà là kiểm chứng và thấu hiểu
      Ngay cả nếu LLM hoạt động hoàn hảo mà không hề nói bậy (hallucination), một lập trình viên có trách nhiệm vẫn phải rà soát từng dòng code
      Vì con người không thể hiểu code nhanh hơn gấp 10 lần, nên trên thực tế việc lần ngược code sinh tự động và giải mã cả ý đồ ẩn bên trong còn có thể tốn nhiều thời gian hơn
      Cụm từ "năng suất 10x" chỉ phù hợp khi người ta chuyển nguyên đầu ra mà không kiểm chứng, hoặc khi đang xử lý loại code cực đơn giản mà lỗi không quan trọng
      Với phần mềm production nơi lỗi có thể là thảm họa, năng lực nhận thức của con người vẫn là nút thắt, và vì LLM chuyển gánh nặng từ viết sang rà soát nên nó còn có thể khiến năng suất tổng thể âm đi

  • Cuộc tranh luận này cho cảm giác như các lập trình viên trung bình đang tự bộc lộ năng suất của chính mình
    Nếu hiểu công nghệ của dự án và biết chia nhỏ công việc tốt, bạn có thể dự đoán trước độ phức tạp của code rồi giao việc cho AI ở đơn vị phù hợp
    AI không phải phép màu, và nó có một trần độ phức tạp có thể xử lý
    Nếu hiểu rõ giới hạn đó và công nghệ của dự án mình đang làm, bạn có thể tách các component xuống dưới ngưỡng đó rồi chỉ thị cho AI
    Cách này hoạt động khá tốt

    • Điều này gần như là một kiểu nói lặp ý
      Nếu bạn đơn giản hóa chỉ dẫn để AI hoạt động tốt thì dĩ nhiên nó sẽ hoạt động tốt
      Nhưng trên thực tế bạn phải đút cho AI chỉ dẫn quá chi tiết, mà ngay cả vậy vẫn phải rà soát kỹ đầu ra và không thể tin tưởng hoàn toàn
      Thậm chí chính việc băm nhỏ rồi giải thích cho AI còn có thể phiền hơn tự viết code
      Nếu AI may mắn cho đúng đáp án ngay từ đầu thì có hiệu quả, nhưng thực tế thường là phải sửa đi sửa lại hoặc cuối cùng làm lại từ đầu, gây lãng phí thời gian và công sức
      Phần nguy hiểm là code có cấu trúc đẹp mắt do AI tạo ra trong thực tế lại thường sai

    • Phần thật sự khó và tốn thời gian là thiết kế những chỗ phức tạp
      Những phần vặt vãnh thì chỉ cần nhập vào là được, nhưng giải quyết phần phức tạp mới là thứ thực sự ngốn thời gian

    • Ẩn dưới bình luận này có cảm giác như đang hỏi: "Bạn nghĩ mình là lập trình viên trên trung bình à?"

    • Thực ra có thể là ngược lại
      Những lập trình viên kém lại nộp auto PR vô nghĩa và trầm trồ trước kết quả AI làm ra, còn người có tiêu chuẩn cao thì có thể không hề ấn tượng với đầu ra đó
      Vì rất khó phân biệt ai là người đáng tin nếu chưa thực sự làm việc cùng, nên tôi giữ thái độ trung lập

    • AI cũng có giới hạn, con người cũng có giới hạn
      Rốt cuộc thứ cần thiết là quản lý dự án nhàm chán
      Nếu có yêu cầu tử tế, thiết kế tử tế và đủ thông tin để chia thành các đơn vị công việc nhỏ, bạn có thể bảo AI "hãy triển khai GitHub issue #42" rồi ngồi xem TV trong lúc chờ
      Nhưng nếu nói "hãy làm facebook cho tôi" thì đương nhiên sẽ đi vào ngõ cụt

  • Một lĩnh vực khác mà AI giúp rất nhiều là tìm bug
    Tôi chủ yếu làm mô phỏng số, và có một vấn đề bị kẹt nhiều ngày liền (sai thang đo của biểu thức do thiếu vài dấu ngoặc); tôi đưa file và mô tả hiện tượng cho chatgpt thì nó nhanh chóng tìm ra nguyên nhân
    Đôi khi AI đóng vai trò chỉ ra rất rõ phần mà tôi đã bỏ sót
    Điều đó không biến tôi thành lập trình viên 10x, nhưng nếu dùng đúng cách thì hiệu ứng tích cực là rất lớn

    • Tôi cũng tương tự
      Dùng AI để tạo code thì chỉ ở mức tạm được, nhưng debug thì đúng là một cú nhảy năng suất rất lớn
      Nó giống như một con "vịt cao su" cực kỳ thông minh

    • (Từ góc nhìn người code như sở thích) Nhờ LLM mà việc phát triển vào đêm muộn khi đầu óc không còn tỉnh táo trở nên dễ hơn nhiều

    • Tôi cũng đã tiết kiệm được vô số thời gian nhờ AI
      Với tôi nó nằm đâu đó giữa 10 lần và vô hạn

  • Tôi không nghĩ mình là kỹ sư 10x
    Lý do tôi làm việc năng suất hơn đồng nghiệp là vì tôi thiết kế hệ thống và không làm theo nguyên xi các ticket yêu cầu kinh doanh vốn mơ hồ
    Lý do AI không thể đơn giản hóa đồng nghiệp của tôi là vì ngay từ đầu nó không thay đổi được thói quen thích làm mọi thứ phức tạp của họ
    AI không giải quyết được cả vấn đề này

    • Tôi còn không nghĩ mình là kỹ sư 2x
      Ở công ty, lương của tôi không chênh gấp đôi đồng nghiệp nên tôi nghĩ vậy
      Việc áp dụng công cụ AI cũng không thay đổi được thực tế này
  • Bài này giống như ghi chép về nỗ lực cá nhân của tác giả nhằm vượt qua một tiêu chuẩn quá cao là "10x"
    Vì vậy tôi nghĩ tác giả đã chia người ủng hộ AI thành ba loại: người tự huyễn hoặc, người bán hàng, và những quản lý tồi chuyên khai thác tâm lý bất an
    Cá nhân tôi xem những lời phàn nàn về "hallucination" hơi giống một loại "tín hiệu"

    • Tôi nghĩ nói về hallucination là rất cần thiết
      Các cuộc thảo luận về LLM đang bị đẩy về hai cực quá mức (hoàn toàn vô dụng vs thay thế lập trình viên)
      Ví dụ Claude 4 Sonnet từng trả lời sai rằng Godbolt sai về nội dung liên quan đến biên dịch clang
      Dù vậy, tôi vẫn nhận được rất nhiều trợ giúp trong toàn bộ phiên làm việc đó, nên chỉ cần luôn nhớ rằng phải nhìn kết quả với con mắt phê phán
      Hallucination là có thật, và ta luôn phải cảnh giác với đầu ra

    • Cảm ơn bạn đã để lại bình luận; nhờ những bài viết về AI của bạn mà tôi đã bớt hội chứng kẻ mạo danh
      Trong bài, tôi chỉ phân loại những người khẳng định mình đã "liên tục thành công 10x", chứ không vơ đũa cả nắm mọi người ủng hộ AI
      Tôi cũng tò mò không biết bạn đã tìm ra cách nào hoàn toàn không có hallucination chưa
      Đặc biệt với Terraform chẳng hạn, LLM vẫn bịa ra các property không tồn tại, và với JS khi dùng các thư viện hiếm thì nó vẫn rất hay tưởng tượng sai

    • Nếu lời phàn nàn về "hallucination" là tín hiệu, thì suy nghĩ đó bản thân nó cũng là tín hiệu…
      (Một phản bác ngắn)

    • Chuẩn 10x này là kiểu marketing phóng đại phổ biến trong toàn ngành
      Ví dụ: tuyên bố 10x của Sam Altman
      quảng bá năng suất của Cursor AI
      lập trình viên 10x được tăng cường bởi AI

  • Giả sử một người không biết làm web app phải học 6 tuần, mỗi ngày 4 tiếng (120 giờ) mới vất vả làm được một cái
    Còn nếu tận dụng AI như Claude code để làm cùng web app đó trong hai ngày cuối tuần (12 giờ), thì năng suất tăng 10 lần
    Điều này khá giống với chuyện thực sự đã xảy ra với tôi
    Trước đây vì thiếu động lực hoặc năng lượng nên tôi không làm nổi, còn giờ nhờ AI tôi có thể hoàn thành trong cuối tuần

    • Nhưng cách thứ nhất có kèm quá trình học, nên lần sau khi cần thay đổi gì đó sẽ có ích hơn

    • Thực ra nếu để AI như Claude Code dựng web app ngoài React thì nó khá thảm
      Người không có kinh nghiệm phát triển app khó mà làm ra một ứng dụng hoàn chỉnh tử tế chỉ trong cuối tuần
      Chỉ cần người dùng đầu tiên đăng nhập là có thể vỡ ngay

    • Xét về dài hạn, tôi nghĩ phép tính đó không hợp lý
      Ban đầu dùng LLM thì tạo app rất nhanh, nhưng dần dần khả năng bảo trì suy giảm, và tới một lúc nào đó hệ thống trở nên quá phức tạp để còn nhét vừa vào “context window” và quản lý nổi
      Kết quả là năng suất thậm chí có thể tiến gần về 0

    • Đó thực chất là bạn đã thuê ngoài luôn cả bộ não và trải nghiệm học tập của mình, nên dù có ứng dụng rồi nhưng gần như không có sự trưởng thành hay học hỏi nào

    • Bạn định triển khai thẳng cái đó luôn à?
      Thực tế hai thứ không cùng mặt bằng để so sánh
      Đầu ra của một lập trình viên 1x vốn đã khó đo, đem đi nhân lên lại càng vô nghĩa

  • Tôi thấy AI nâng mạnh "năng suất side quest"
    Những việc tôi cứ trì hoãn vì ngại như làm mockup, viết test, tách thư viện, viết tài liệu... thì AI rất hợp
    Nó có thể không rút ngắn thời gian làm ra tính năng, nhưng nếu tính cả những việc phụ trợ thì đầu ra sẽ gần mức hoàn thiện hơn một chút
    Tôi hy vọng chính các việc phụ trợ này sẽ giúp giảm thời gian tìm bug về sau

    • (Trải nghiệm cá nhân)
      Chỉ nói trong trường hợp của tôi thôi, nhưng ở công ty tôi, code test do LLM tạo ra thường bị buộc quá chặt với code triển khai
      Tình trạng lạm dụng các pattern như test spy là rất phổ biến
      Kết quả là có nhiều bài test mơ hồ chỉ kiểm tra chi tiết triển khai nội bộ thay vì hành vi từ góc nhìn người dùng
      Test vì thế vỡ quá thường xuyên theo các thay đổi triển khai, khiến nó trở thành gánh nặng chứ không phải công cụ tăng năng suất
      Đây không chỉ là vấn đề của LLM; vốn dĩ những lập trình viên đã không biết viết test đúng cách thì khi có LLM, vấn đề còn nặng hơn
      Với những người thiếu kinh nghiệm về TDD và code test được thiết kế tốt, LLM làm khuếch đại các anti-pattern kiểu này

    • Tôi thích cách diễn đạt "năng suất side quest"
      AI không phải là "ngàn nhát cắt dẫn tới cái chết", mà giống như "một cuộc đời mới được ghép lại từ ngàn miếng băng cá nhân"

    • Tôi đồng ý với khái niệm "side quest"
      Thực ra thay đổi lớn nhất là nhờ AI mà tôi có thể làm ra các tool hay tính năng mà nếu không có AI tôi đã chẳng bao giờ làm
      Không phải chỉ là tiết kiệm được 2 tuần, mà là tạo ra được một kết quả vốn trước đây không tồn tại

  • Kỳ vọng dành cho LLM đang cao hơn thực tế, nhưng trong nhiều tình huống nó vẫn cực kỳ hữu ích
    Nếu nhìn theo "zoom level", từ kiểu làm đại như "vibe coding" cho tới mức tách nhỏ thành "hãy viết hàm này", càng chia theo từng tầng thì kết quả càng tốt
    Ngoài sinh code, nó còn hiệu quả trong nhiều mục đích khác như học công nghệ mới
    Nếu vai trò của tôi có nhiều cuộc họp hoặc nhiều việc quản lý thì mức hỗ trợ từ LLM sẽ giảm đi
    Về sau, tôi nghĩ LLM còn có thể được dùng cho cả workflow PR, dọn commit, sắp xếp lại thứ tự công việc, v.v.

 
reagea0 2025-08-07

Thực ra chỉ cần dùng nó để phản biện những kỹ sư hay buột miệng nói kiểu 'không được đâu', 'không khả thi' thì cũng có vẻ sẽ tạo ra hiệu quả X10 rồi.

Vì tôi đã thường xuyên chứng kiến cảnh họ coi những người không phải lập trình viên là hạng chẳng biết gì rồi khăng khăng bảo cái gì cũng không làm được.