31 điểm bởi GN⁺ 2025-03-19 | 29 bình luận | Chia sẻ qua WhatsApp
  • Việc các công cụ LLM giúp tăng năng suất phát triển là sự thật
  • Tuy nhiên, về lâu dài, việc phụ thuộc vào các công cụ này sẽ khiến khả năng tự giải quyết vấn đề bị suy giảm
  • Cảm giác thành tựu có được trong quá trình viết mã biến mất, và thay vì giải quyết vấn đề, ta lại chờ câu trả lời từ AI

Sự suy yếu của đam mê và tinh thần chinh phục trong phát triển phần mềm

  • Cũng có những người không thích bản thân việc lập trình → trong trường hợp đó, có thể lĩnh vực phát triển phần mềm không phù hợp
  • Những kỹ sư giỏi nhất mà tôi từng gặp đều tự nguyện tạo ra công cụ hoặc phần mềm vào cả cuối tuần và theo đuổi sự đổi mới
  • Việc cải thiện hiệu năng của hệ thống chỉ có thể làm được khi có sự hiểu biết nền tảng; nếu không thì cũng chỉ là thử bừa mà thôi

Hiện tượng 'Copilot Lag'

  • 'Copilot Lag' là trạng thái chờ chỉ dẫn tiếp theo từ AI
  • Nó giống như một lập trình viên mới vào nghề đang chờ chỉ dẫn từ người đi trước
  • Khi dùng GitHub Copilot, người ta thậm chí có thể quên cả các thành phần ngôn ngữ và cú pháp cơ bản
  • Tốc độ được cải thiện trong ngắn hạn khiến tri thức dài hạn bị mai một

LLM có thể cản trở quá trình học tập

  • Khi học "Writing An Interpreter In Go" của Thorsten Ball, Copilot đã tạo mã giúp, nhưng tôi lại không có được khả năng tự viết lại nó
  • Những khái niệm quan trọng như quản lý bộ nhớ hay thiết kế hướng dữ liệu có thể bị bỏ lỡ
  • Mã do AI tạo ra có thể trông bề ngoài là đúng, nhưng nếu không hiểu nguyên lý nền tảng thì cũng vô nghĩa

Cách tận dụng LLM hiệu quả

  • Có thể dùng LLM hữu ích như một công cụ tìm kiếm
  • Giống như khi tìm trên Stack Overflow, ta có thể tham khảo câu trả lời của LLM
  • Tuy nhiên, LLM không phản ánh nguyên vẹn tri thức của chuyên gia thực sự mà tạo câu trả lời dựa trên các mẫu đã học và chuỗi token → nên có nhiều lỗi
  • Đừng chấp nhận nguyên xi câu trả lời của LLM; hãy phân tích vì sao nó đề xuất cách tiếp cận đó
  • Khi có điều chưa biết, cần tự mình tìm hiểu và học
  • Khi học một ngôn ngữ mới (như Zig), việc ghi chép lại những gì đã học sẽ rất hữu ích
  • Ghi chú có thể trở thành tài liệu tham khảo cho việc học và cũng hữu ích khi chia sẻ với người khác

Kết luận

  • Công cụ AI rất hữu ích, nhưng nếu phụ thuộc mù quáng thì ngược lại sẽ phản tác dụng
  • Điều quan trọng là phải hiểu nguyên lý của lời giải mà AI đưa ra và giữ thái độ tự học
  • Cuối cùng, điều quan trọng nhất là duy trì năng lực giải quyết vấn đề cốt lõi mà không phụ thuộc vào công cụ

29 bình luận

 
madnix 2025-03-27

Hmm... Có vẻ đây vốn là sự khác biệt về góc nhìn giữa việc xem AI là công cụ hay xem nó là trí tuệ.. Điều tôi không thể đồng ý với bài viết này là, như tôi đã nói ở bình luận bên dưới, bản thân việc chỉ nhìn nhà phát triển ở cấp độ code đã là một cách nghĩ sai lầm. Ngay cả khi cuộc Cách mạng Công nghiệp nổ ra ở Anh trước đây, nông dân cũng từng kêu gào rằng họ sẽ chết đói, nhưng kết quả là nó đã tạo ra nhiều việc làm hơn và mang lại rất nhiều lợi ích cho nhân loại. Ngoài ra, khi máy tính xuất hiện trước đây, cũng từng có những lời nói rằng vì máy tính mà con người sẽ ngày càng trở nên ngu ngốc hơn, nhưng rốt cuộc chúng ta đã giải quyết được nhiều việc hơn trong thời gian ngắn hơn và con người cũng trở nên thông minh hơn.

 
jokerized 2025-03-24

LLM, bao gồm cả deep research, vẫn chưa hữu ích cho việc giải quyết các vấn đề ở cấp độ cao. (Ví dụ như phát triển thuật toán ở mức bài báo học thuật)
Việc tối ưu hóa đến mức cực hạn, hay lập trình đòi hỏi phải hiểu nhiều đặc tính hệ thống và các vấn đề kỹ thuật khác nhau, cũng tương tự như vậy, hiện vẫn cần bàn tay con người. Nhà phát triển không chỉ là lập trình viên đơn thuần mà là người giải quyết vấn đề. Dù một ngày nào đó việc giải quyết vấn đề end-to-end có thể trở nên khả thi, nhưng ở thời điểm hiện tại, việc tiết kiệm thời gian cho khâu gõ code và lập trình đơn giản để đầu tư vào cách tiếp cận những vấn đề khó hơn là một tín hiệu tích cực về mặt năng suất.

 
skarl86 2025-03-22

Từ lúc nào đó, tôi cảm thấy mình thường dùng nó theo kiểu giống như review code. Tôi nhận đề xuất mã, trao đổi về định hướng của đoạn mã, suy nghĩ và đề xuất những cách tốt hơn, rồi khi có được kết quả khiến mình hài lòng thì tôi trích dùng nó.

 
kaydash 2025-03-22

Toàn bộ logic ứng dụng và logic nghiệp vụ phải do con người suy nghĩ.

 
elbanic 2025-03-22

Nếu giới hạn lập trình viên chỉ ở việc viết code thì mới nảy sinh kiểu lo ngại này. Thực ra lập trình viên còn làm nhiều việc hơn thế; có thể cho rằng việc phụ thuộc vào AI ở phần viết code là trở nên ngu ngốc, nhưng cũng có thể xem đó là cách giúp họ tập trung hơn vào những phần việc khác.

 
pcj9024 2025-03-21

Ttuyatyai... tôi là lập trình viên ngốc...

 
dongyagn1 2025-03-20

Cũng từng có người nói Unity đang làm các nhà phát triển game trở nên ngốc đi, nhưng rốt cuộc chẳng ai ngốc cả, mà còn học thêm được nhiều thứ khác nên chỉ thấy việc ngày càng nhiều hơn thôi, haha

 
halfenif 2025-03-21

Chỉ là công việc lại nhiều hơn thôi... Sao có thể thế này chứ..

 
nimgnos 2025-03-20

Tôi khó mà đồng ý với cách nói rằng AI đang làm lập trình viên trở nên ngốc đi...
Vì sau khi áp dụng AI, năng suất thực sự đã tăng vọt.

 
vhzkfltmdnpxm 2025-08-18

Có một kẻ ngốc ở đây nè

 
alpharoom 2025-03-19

Giờ là thời mà nếu không đồng ý với quan điểm rằng AI làm được hết mọi thứ thì sẽ bị chửi thôi mà

 
play1204dev 2025-03-19

Nếu là những thứ như tính năng của thư viện mà trước đây mình chưa biết, hoặc shell script không thể nghĩ ra ngay, thì còn ổn, nhưng vì nó còn trộn cả những tính năng đã deprecated, những function không hề tồn tại, nên cuối cùng toàn tốn thời gian để debug thôi.

> Đừng chấp nhận nguyên xi câu trả lời của LLM, mà phải phân tích vì sao nó lại khuyến nghị cách tiếp cận như vậy.

Tôi nghĩ đây mới là ý cốt lõi.

 
dongwon 2025-03-19

Tôi nghĩ công cụ dường như lúc nào cũng vừa mở rộng tư duy, vừa phá hủy tư duy. Lẽ ra chúng ta phải có thể tiến tới việc mở rộng tư duy ở cấp độ cao hơn thông qua sự phá hủy đó, nhưng vào những thời điểm chưa có sự chuẩn bị như vậy, có vẻ như những vấn đề này luôn đi kèm.

Vì vậy, rốt cuộc khi sử dụng công cụ, tôi nghĩ những trăn trở như thế này lúc nào cũng đi cùng. Tôi cho rằng đó là những quá trình nhất định phải trải qua. Thay vì đơn thuần từ chối hay sử dụng một cách mù quáng, tôi nghĩ điều đáng mong muốn là tập trung vào việc nên dùng công cụ này như thế nào cho tốt, và làm sao có thể tận dụng những công cụ này để dồn nguồn lực vào các phần quan trọng hơn về bản chất. (cursor usage đã vượt quá 1.000 lần mỗi tháng...)

 
amarese 2025-03-19

Anh Kim. Tôi mạo muội muốn góp một lời khuyên. Không có gì khác, chỉ là xin đừng dùng hàm Excel quá nhiều. Nếu có sự tiện lợi, thì rủi ro cũng tăng lên. Muốn mổ bò thì có lưỡi dao tương xứng, còn bắt gà thì có cần đến dao không? Đôi khi thứ đơn giản mới là đáp án đúng.

 
codemasterkimc 2025-03-19

Bài trên đúng là phiên bản GPT của hàm Excel luôn ấy chứ haha

 
losoowmik 2025-03-19

Theo ý kiến của tôi, nhẩm tính có thể nhanh và máy tính thì hữu ích. Tôi xin nêu ý kiến rằng máy tính chẳng phải là con dao mổ trâu sao.

 
jingjing2222 2025-03-19

Tôi sẽ không bao giờ dùng chatGPT nữa
Tôi cũng từng viết một bài tương tự.

Rõ ràng là có hiệu quả giúp tăng năng suất, nhưng tôi nghĩ nên tránh chính việc phó mặc bộ não của mình cho nó.

 
dicebattle 2025-03-19

Tôi vẫn là một người rất tin dùng cursor và anthropic, nhưng đến một lúc nào đó tôi nhận ra mình dần không còn dùng chế độ agent như trước nữa, mà chuyển sang dùng chế độ ask để hỏi trước về kiến trúc và cách triển khai, rồi chỉ khi đã thực sự hiểu và thấy thuyết phục thì mới tự mình chấp nhận từng đề xuất thay đổi của AI một cách cẩn trọng.
Điều này bắt đầu thay đổi sau khi tôi trực tiếp chứng kiến một mô-đun không quá lớn (nhưng khá quan trọng trong dự án công việc của chúng tôi) được 2 kỹ sư, mỗi người dùng chế độ agent để refactor và bổ sung cấu trúc, rồi đến một lúc, thứ code vốn được định hướng là để sắp xếp lại kiến trúc thì trên thực tế lại khiến cả tính dễ đọc lẫn cấu trúc trở nên rối rắm hơn.

 
onixboox 2025-03-20

Tôi cũng đang dùng như vậy. Nếu là một ngôn ngữ mà tôi thật sự hoàn toàn mới bắt đầu đụng vào thì tôi dùng chế độ agent, còn nếu là ngôn ngữ mình biết thì lại có xu hướng kiểm tra trước xem đó có phải là đoạn mã hợp lý, có thể chấp nhận được hay không.

 
iolothebard 2025-03-19

Thay vì nói AI đang biến lập trình viên thành kẻ ngốc…
thì phải nói rằng… lập trình viên ngốc, dù có dùng AI, vẫn là lập trình viên ngốc…
Garbage in, garbage out

 
ehdgns104 2025-03-24

Hoàn toàn đúng luôn haha

 
powerkid 2025-03-21

Tôi đồng ý. Có vẻ đây chỉ là thêm một công cụ năng suất hữu ích, không hẳn hoàn toàn xấu cũng không hẳn hoàn toàn tốt.

 
halfenif 2025-03-21

Tôi đồng cảm.

Từ trước tôi vẫn thường nói rằng, không phải cứ là lập trình viên thì đều là cùng một kiểu lập trình viên.

 
aer0700 2025-03-20

Có vẻ lời này là đúng...

 
white9s 2025-03-19

Nói hơi thô nhưng cũng không hẳn là sai. Cũng giống như câu hỏi hay thì sẽ có câu trả lời hay..

 
j2sus91 2025-03-19

Có vẻ như tác giả đang nói về việc sử dụng một cách mù quáng và chỉ phụ thuộc vào các công cụ AI thôi.

Ý kiến cá nhân của tôi là, nếu việc tận dụng AI đã giúp nâng cao hiệu suất công việc,
thì nên tích cực sử dụng nó để giảm bớt các tác vụ lặp đi lặp lại,
và dùng khoảng thời gian có được để đầu tư vào những phạm vi rộng hơn (ví dụ: lập trình viên backend mở rộng sang cả frontend hoặc phát triển ứng dụng)
hay theo những hướng phát triển hơn như thiết kế kiến trúc thì sẽ hợp lý hơn.

Nhìn vào toàn bộ nội dung thì có lẽ tác giả cũng sẽ đồng ý với ý kiến trên,
nhưng vì đôi khi vẫn có những lập trình viên hoàn toàn từ chối AI nên tôi viết vài dòng phản hồi thôi.. haha
.

 
tsboard 2025-03-20

Tôi cũng đồng ý. Điều đó khiến tôi nhớ đến bài viết từng nói rằng đừng dùng các hàm của Excel.
Tôi nghĩ nếu biết tận dụng tốt các tính năng sẵn có để nâng cao hiệu quả sử dụng thì sẽ có lợi.

 
zinisuni 2025-03-19

Tôi đồng ý. ^^

 
GN⁺ 2025-03-19
Ý kiến trên Hacker News
  • Một số người có thể không thích tự viết code của mình. Trong trường hợp đó, có thể xem là họ đang cố làm việc trong một lĩnh vực không phù hợp với mình
    • Tôi đã chịu đựng việc tự viết code của mình suốt hàng chục năm. Đôi khi điều đó mang lại cảm giác thỏa mãn, nhưng phần lớn nó chỉ là một lớp trừu tượng nằm giữa ý tưởng của tôi và tôi
    • Tôi thích làm ra thứ gì đó thật nhanh, và khi có ý tưởng, tôi muốn nó được triển khai hiệu quả và gọn gàng nhất có thể
    • Tôi đã chấp nhận làm việc cùng LLMs. Tôi không nghĩ điều đó khiến tôi trở nên lười biếng hơn
    • Ngược lại, nó truyền cảm hứng để tôi bắt đầu khi bị mắc kẹt. Khi LLM khởi động công việc, tôi sẽ tiếp quản và hoàn thiện theo cách của mình
    • Tôi đang tạo ra nhiều sản phẩm hơn trước
    • Tôi đã làm việc cùng nhiều người, và một số trong họ là bạn của tôi. Họ nghĩ code và phương pháp luận của mình là thứ thiêng liêng
    • Tôi nghĩ khi AI tràn vào, sẽ không còn chỗ cho họ. Tôi bước vào cuộc chơi này vì sự sáng tạo, và đó là lý do tôi ở đây
    • Công cụ và cú pháp đều chỉ là phương tiện để đạt mục đích
    • Điều này lặp đi lặp lại mỗi khi một tầng trừu tượng mới được phát triển, giúp việc tạo ra code chạy được trở nên dễ dàng hơn mà không cần hiểu tầng bên dưới
    • Đó gần như luôn là một lớp trừu tượng bị rò rỉ. Đôi khi bạn vẫn cần biết tầng dưới thực sự hoạt động như thế nào
    • Những lập trình viên đã đầu tư rất nhiều thời gian và năng lượng cảm xúc để hiểu tầng dưới sẽ cho rằng những người dựa vào lớp trừu tượng là kém thông minh hơn
    • Tất cả chúng ta sẽ thông minh hơn nếu tự viết code mà không phụ thuộc vào thư viện bên thứ ba
    • Chúng ta sẽ thông minh hơn nếu tự quản lý bộ nhớ thủ công
    • Chúng ta sẽ thông minh hơn nếu viết toàn bộ code bằng assembly và không phụ thuộc vào compiler
    • Chúng ta sẽ thông minh hơn nếu tự đi dây các transistor của mình
    • Học các tầng thấp hơn mang tính giáo dục. Nó thường cần thiết để vắt kiệt hiệu năng tối đa
    • Nhưng không cần hiểu tầng dưới để mang lại giá trị cho khách hàng
    • Điều tôi thích nhất là dùng coding LLMs để nhờ chúng giúp tôi hiểu phần code mà tôi chưa hiểu
    • Dù đôi khi câu trả lời sai, chúng vẫn thường đưa ra manh mối để tôi có thể tự giải quyết
  • Tôi cũng đã có trải nghiệm tương tự. Tôi dùng LLM để xây dựng tính năng, nhưng rồi phát hiện code đó lấy từ một thư viện đã tồn tại sẵn
    • Nếu nghiên cứu cho đúng thì tôi đã không tạo ra một phiên bản tệ hơn rất nhiều
    • Giờ tôi chỉ dùng nó để lấy tính năng prototype trong editor dựa trên comment, còn lại tôi tự làm
    • Việc thiết lập pipeline AI lấy đi toàn bộ niềm vui và khiến nó giống như một công việc cực kỳ quá sức
    • Tôi thà đi code còn hơn
    • Khi LLM sai liên tiếp lần 2, 3, 4 thì cơn bực thật sự bắt đầu dâng lên
    • Nó rất mệt mỏi
    • Tôi kỳ vọng trong 1–2 năm tới mọi thứ sẽ dễ hơn và UX sẽ được cải thiện, nhưng tôi không biết sẽ ra sao
    • Có lẽ là do tôi thiếu tầm nhìn
  • LLMs lấy đi động lực để sinh viên hiểu sâu và tập trung vào các vấn đề kỹ thuật
    • Thay vào đó, họ copy, paste rồi bỏ qua mà không hiểu
    • Phép so sánh với máy tính cầm tay có thể phù hợp. Nó chỉ là công cụ thích hợp sau khi bạn đã học cách tính bằng tay
    • Trong một thí nghiệm, người ta giao cho sinh viên kinh doanh ChatGPT và một bài tập khoa học dữ liệu
    • Họ tìm được lời giải mà không có kiến thức nền, nhưng lại không thu được kiến thức
    • Một người bạn đã nói rằng "mô hình ngôn ngữ này không nên được cung cấp cho đại chúng"
  • Một giai thoại cá nhân từ chỗ làm trước đây
    • Một lập trình viên junior được giao nhiệm vụ viết script tạo danh sách các branch đã lâu không được dùng
    • Tôi nhận được yêu cầu review, và phần lớn được viết bằng awk
    • Họ đã nhập định nghĩa nhiệm vụ vào LLM, rồi copy câu trả lời và dán vào pull request
  • Plato, Phaedrus, năm 370 TCN: "Họ sẽ không còn dùng trí nhớ của chính mình nữa, vì họ sẽ gợi lại ký ức thông qua các dấu hiệu bên ngoài"
  • Có thể tôi đã lỗi thời, nhưng tôi vẫn nhớ thời mà silent failure được xem là một trong những điều tệ nhất mà hệ thống có thể làm
    • LLMs là cỗ máy tạo ra silent failure
    • Chúng hữu ích đúng chỗ của chúng, nhưng nếu sếp nghe theo chuyện thay thế lao động con người bằng AI, tôi tin họ sẽ phải gánh lấy thảm họa do chính mình gây ra
  • Lý do tôi bước vào software engineering là vì tôi thích tạo ra thứ gì đó và tìm hiểu cách nó hoạt động
    • Việc gõ code bằng bàn phím chỉ là tác dụng phụ của kỹ năng đó
    • Điều đó giống như nói rằng muốn trở thành nhà toán học thì phải thích viết phương trình lên bảng trắng
    • Trong engineering, tìm ra lời giải thường mới là mục tiêu cuối cùng
    • Khi việc tự tay gõ mọi thứ là có giá trị, một kỹ sư giỏi nên tự tay làm
    • Nếu import thư viện bên thứ ba là cách dùng tốt nhất thì nên làm như vậy
    • Nếu giao một phần việc coding cho LLM là con đường dễ nhất thì cũng nên làm vậy
  • Có một khái niệm gọi là "Copilot Lag"
    • Nó chỉ trạng thái kỹ sư ngồi chờ xem sau mỗi tác vụ thì nên làm gì tiếp theo
    • Tôi đã có trải nghiệm đó suốt 10–15 năm
    • LLM sẽ không gây hại nhiều đến thế đâu
  • Tôi gần như đã đến mức từ bỏ coding copilot
    • Tôi dành phần lớn thời gian để vật lộn với chúng
    • Một phần có thể là lỗi của tôi
    • Cũng có vấn đề về UX/triển khai
    • LLMs hữu ích như những chuyên gia tầm trung trong nhiều chủ đề khác nhau
    • Nhưng rất dễ rơi vào echo chamber
    • Thật sốc khi đâm sầm vào bức tường ở đúng những khoảnh khắc cần trực giác, sự tò mò, sáng tạo và cá tính của con người
    • Tôi hài lòng khi xem nó như một công cụ nữa trong hộp đồ nghề
    • Nhưng tôi vẫn thích cộng tác với người thật hơn