AI coding phơi bày nỗi buồn và sự chia rẽ của các lập trình viên

• Sự lan rộng của các công cụ AI coding đang đưa lên bề mặt khác biệt về động cơ vốn luôn tồn tại nhưng trước đây không dễ nhìn thấy giữa các lập trình viên
• Nỗi buồn vì đánh mất niềm thỏa mãn mang tính thủ công của chính việc viết code, và nỗi buồn trước sự thay đổi của hệ sinh thái và môi trường nghề nghiệp xoay quanh code là hai dạng mất mát khác nhau
• Từ góc nhìn của một lập trình viên đã viết code từ thập niên 1980, AI coding là sự nối dài tự nhiên của các tầng trừu tượng, từ C64 BASIC sang assembly, từ hàm đến thiết kế hệ thống
• Kinh nghiệm đọc và review code suốt nhiều thập kỷ vẫn còn nguyên giá trị như trực giác và khả năng phán đoán để đánh giá chất lượng code do AI tạo ra
• Điều cốt lõi là nhận ra mình đang cảm thấy kiểu nỗi buồn nào; mất mát mang tính nghề thủ công và mất mát về bối cảnh đòi hỏi những cách ứng phó khác nhau

---

Khởi đầu của sự tiếc nuối

• James Randall là một lập trình viên bắt đầu lập trình từ khi 7 tuổi vào thập niên 1980, và ông mô tả trải nghiệm khám phá và kiên trì để tự tìm ra điều gì đó đã bị "nén lại"
  • Không phải là nó biến mất hoàn toàn, nhưng đã có điều gì đó bị đánh mất trong quá trình nén này
• Nolan Lawson bày tỏ cảm giác mất mát một cách trực diện hơn trong bài viết "We Mourn Our Craft"
  • Chúng ta sẽ nhớ cảm giác tự tay nặn ra code, những lần bắt bug bằng debugger lúc 2 giờ sáng, và niềm tự hào rằng "chính mình đã tạo ra nó"
• Những cảm xúc này là cảm xúc thật trước một mất mát có thật, nhưng khi đọc, vẫn liên tục có cảm giác rằng họ đang tiếc nuối những điều khác nhau

Bản chất của sự chia rẽ

• AI coding đang làm lộ ra sự chia rẽ vốn có nhưng ít thấy rõ hơn giữa các lập trình viên
• Trước thời AI, cả hai phía đều làm việc theo cùng một cách: dùng cùng editor, cùng ngôn ngữ, cùng quy trình pull request
  • Lập trình viên thiên về tay nghề thủ công và lập trình viên thiên về kết quả ngồi cạnh nhau, cùng ship một sản phẩm mà gần như không thể phân biệt
  • Động cơ của công việc là thứ vô hình, vì quy trình thì giống nhau
• Giờ đây xuất hiện một ngã rẽ: giao code cho máy và chỉ huy thứ cần tạo ra, hoặc tự tay viết code
  • Chính tại khoảnh khắc lựa chọn này, lý do vì sao một người bắt đầu lập trình mới thật sự trở nên hữu hình
• Ngay từ thời đại học trong các lớp toán và khoa học máy tính cũng đã tồn tại kiểu chia rẽ đó: có người thích bản thân các chứng minh và định lý, còn có người chỉ thấy hứng thú khi áp dụng chúng vào thực tế

Nỗi buồn của tôi thì khác

• Trong 18–24 tháng qua, tôi thực sự đã trải qua một khoảng thời gian buồn bã và thích nghi
• Tôi từng sợ rằng mình sẽ không hiểu nổi các công cụ mới, nhưng thực tế là tôi vẫn hiểu được
• Tôi lo rằng mình sẽ mất khả năng đánh giá chất lượng code do AI tạo ra, nhưng kinh nghiệm đọc và review code suốt hàng chục năm không hề bay biến
  • Khi có điều gì đó sai, tôi vẫn nhận ra được, và con mắt nghề ấy vẫn còn nguyên
• Tôi sợ rằng cảm giác giải một câu đố sẽ kết thúc, nhưng thực ra chỉ là tôi đã bước lên một tầng cao hơn
  • Từ việc sắp byte trên C64 → viết hàm → thiết kế hệ thống, đây là cùng một kiểu chuyển đổi như mọi lần chuyển dịch trong sự nghiệp
  • Giờ đây câu đố đã chuyển sang địa hạt của kiến trúc, cấu hình và điều phối assistant
• Phần lớn những nỗi sợ đã không đứng vững khi va vào thực tế, nhưng vẫn còn sót lại một vài nỗi buồn

Nỗi buồn còn ở lại

• Không phải nỗi buồn vì không còn tự tay viết HTML, mà là nỗi buồn dành cho chính hệ sinh thái web mở
  • Việc AI học từ tài sản chung của cộng đồng, và sự tập trung hóa hơn nữa của những chủ thể định hình trải nghiệm internet của con người, là những mất mát có thật
  • Đây là vấn đề không biến mất chỉ vì năng suất cá nhân tăng lên
• Nỗi buồn trước sự thay đổi của địa hình sự nghiệp
  • Web development, thứ tôi đã làm hơn 30 năm, không còn là lĩnh vực nóng nhất nữa
  • Mobile app đã lấy đi một phần, và AI engineering hiện đang giữ vị trí chủ đạo
  • Tôi nghĩ mình đang chuyển đổi thành công, nhưng sự bất an là có thật và vẫn chưa kết thúc
• Trọng tâm của nỗi buồn này là: không phải tôi nhớ nhung hành động viết code tự thân
  • Mà là nỗi buồn khi thế giới xung quanh code đang thay đổi
  • Nỗi buồn của Randall và Lawson hướng đến chính tinh thần thủ công, còn nỗi buồn trong bài này là về bối cảnh và lý do

Không bên nào sai cả

• Kevin Lawver, trong bài viết phản hồi Lawson, cho rằng thay vì bám chặt vào quá khứ, ta nên định hướng lại tinh thần nghề thủ công và đam mê của mình
• Vượt qua cách đóng khung đơn giản kiểu hoài niệm đối đầu với chủ nghĩa thực dụng, điều thực sự hữu ích là nhận ra mình đang cảm thấy loại nỗi buồn nào
• Nếu đang tiếc nuối một mất mát mang tính nghề thủ công: câu "cứ thích nghi đi" sẽ không giải quyết được gì
  • Có thể phải tìm cảm giác thỏa mãn đó ở nơi khác, hoặc chấp nhận rằng cảm nhận về công việc sẽ thay đổi
  • Việc trước giờ có thể kiếm sống nhờ tinh thần nghề thủ công vốn dĩ đã là một sự may mắn
• Nếu đang tiếc nuối một mất mát về bối cảnh: ta có thể phản ứng theo cách khả thi hơn
  • Có thể học công cụ mới, nỗ lực vì kiểu web mà mình mong muốn dù chỉ là web nhỏ, và vừa buồn vừa thích nghi cùng lúc
• Trích lời Nolan Lawson: "Tôi không ca ngợi thế giới mới, cũng không chống lại nó. Mặt trời mọc rồi lặn, và tôi bất lực quay theo quỹ đạo của nó; sự phản đối của tôi không thể ngăn nó lại"
  • Nhưng việc thừa nhận rằng giữa nỗi buồn và nỗi sợ vẫn có chút hứng khởi là một sự thành thật

Khiến máy tính làm việc

• Kể từ khi bắt đầu lập trình vào thập niên 1980, mọi ngôn ngữ tôi học đều chỉ là phương tiện để đạt mục đích
  • Một cách mới để khiến máy tính làm điều mình muốn
• AI coding là bước mới nhất trong đường nối dài đó, không phải một sự đứt đoạn mà là nấc tiếp theo trên chiếc thang
• Chỉ có điều chính chiếc thang này đang thay đổi, và cả tòa nhà mà nó đang dựa vào cũng đổi khác, nên ta không thể biết chính xác nó dẫn tới đâu
• Điều chắc chắn là: cảm giác thỏa mãn khi thứ mình suy nghĩ ra thật sự hoạt động sau hơn 40 năm vẫn không thay đổi
  • Con đường để đi tới đoạn code đó có thể đã khác, nhưng khoảnh khắc nó vận hành thì vẫn vậy

[github88]

Làm quá lên rồi.

[ahwjdekf]

Tôi cho rằng việc để AI làm mấy thứ như lập trình web là điều quá tốt.

[brilliant08]

Có vẻ như những kiểu lập trình khác có thứ gì đó mang giá trị cao quý nhỉ.

[onetoday]

Đôi khi tôi cũng có cảm giác độ tuổi trung bình trên HN khá cao và giống như nhiều người đang bị tụt lại phía sau.
Vì thế tôi thường lướt qua và không đọc những bài viết tiêu cực kiểu này (không phải mang tính phê bình).

Tham khảo thêm thì thỉnh thoảng cũng không phải là không có lúc tôi nhớ lại niềm vui tự tay viết code,
nhưng vì tôi làm phía web nên có lẽ điều đó khả thi hơn chăng,
dù sao thì tôi cũng đã hơn 3 tháng không gõ code rồi.

Trên hết, cách phát triển như thế này quá vui nên tôi lại thường xuyên tự nguyện làm thêm giờ như hồi còn trẻ.

[snisper]

Nếu vì AI mà phải bận tâm đến thế thì cứ không dùng là xong chứ nhỉ

[savvykang]

Tôi tò mò không biết mọi người đã phản ứng như thế nào khi các công cụ RAD xuất hiện.

[GN⁺]

Ý kiến trên Hacker News

• Tôi nghĩ bài viết đã hiểu sai hoàn toàn. Ngay cả các lập trình viên theo kiểu “craft” cũng theo đuổi kết quả, nhưng là những kết quả bền vững lâu dài và có thể mở rộng
  Mục tiêu của một lập trình viên giỏi là tự khiến mình trở nên không còn cần thiết. Trước đây từng có thời phải đếm chu kỳ và nhồi bit bằng hợp ngữ, nhưng rồi việc dùng compiler trở thành điều hiển nhiên. Cũng từng có thời người ta tự viết app CRUD, nhưng giờ framework làm thay. Quản lý bộ nhớ, hệ thống kiểu, ngôn ngữ bậc cao, no-code/low-code đều là một phần của tiến bộ. Suy cho cùng, mục đích của lập trình là để máy tính giúp chúng ta khỏi phải tự làm những việc đó Tôi nghĩ sự chia rẽ thật sự là khác biệt trong tư duy giữa những người xem phần mềm là thứ có thể cải thiện và có thể hiểu được, với những người xem nó là chướng ngại vật khó hiểu do kẻ khác tạo ra
  • Tôi thích góc nhìn này. Khi làm việc với hệ thống đủ lâu, mọi chi tiết đều trở nên có ý nghĩa. Ta sẽ có cảm giác việc thay đổi một thứ sẽ ảnh hưởng ra sao đến toàn bộ hệ thống. Nhưng tôi lo rằng trong thời đại phần mềm do AI tạo ra, kiểu hiểu biết này sẽ trở nên bất khả thi. Quá nhiều mã sẽ được sinh tự động đến mức rất khó nắm được toàn cảnh. Cuối cùng, nếu sửa đổi đã khó thì có lẽ tạo lại bằng AI còn hợp lý hơn. Vì thế tôi nghĩ tính mô-đun (modularity) sẽ càng quan trọng hơn
  • Tôi đồng ý gần như toàn bộ, trừ câu cuối. Tôi nghĩ đó không hẳn là vấn đề trí tuệ, mà là vì trong thực tế, nhóm người thứ hai thường có năng lực thấp hơn
  • Tôi tự hỏi liệu cách phân chia này có giống với phân loại “cổ điển vs lãng mạn” của Pirsig không. Nhóm trước cố hiểu cấu trúc và nguyên lý, còn nhóm sau coi trọng hình thức, cảm giác và tính hữu dụng
  • Câu “lập trình viên giỏi sẽ tự khiến mình trở nên không còn cần thiết” trước đây nghe rất nhiều, nhưng dạo này gần như biến mất
• Sự chia rẽ thật sự nằm giữa những người tin rằng tiến bộ công nghệ về bản chất là tốt, với những người hiểu rằng trong lịch sử năng suất tăng không hề dẫn đến giảm giờ làm
  Chế độ làm việc 8 tiếng không phải do công nghệ mang lại mà là kết quả của đấu tranh chính trị
  • Sự chia rẽ thật sự là giữa người sở hữu tư bản và người lao động. Chủ tư bản sống bằng những mảnh giấy được thừa kế cho phép họ lấy một phần sản phẩm lao động của người khác
  • Thật thú vị khi thấy kiểu thảo luận này xuất hiện ở Hacker News thường xuyên hơn. Nếu AI thay thế lập trình viên, có lẽ những người thông minh và có động lực sẽ thức tỉnh về mặt chính trị. Trong lịch sử, khi doanh nghiệp phình to quá mức, cuối cùng nó cũng bị đối xử như một quốc gia
  • Có quá nhiều quan điểm cực đoan. Cuối cùng, sự chia rẽ thật sự là giữa người ủng hộ khoa học kỹ thuật và người căm ghét nó
• Giờ đây vấn đề không còn đơn giản là người thích gõ trên bàn phím cơ nữa. Khác biệt thật sự là giữa người thích hiểu hệ thống và tự xây cái mới, với người muốn giao việc đó cho kẻ khác rồi chỉ lấy kết quả
  Dù vậy, nếu “người khác” là con người thì ta vẫn có thể chia sẻ công lao thông qua cố vấn hay tạo môi trường làm việc
  • Thật buồn cười khi “sự chia rẽ thật sự” lúc nào cũng trôi về mô-típ “tôi vượt trội về trí tuệ hay đạo đức” đối lập với “đám người thấp kém kia”
  • Tôi vừa thích hiểu hệ thống và tự xây cái mới, vừa thích giao việc lặp đi lặp lại cho AI. Thế nghĩa là tôi không được phép tồn tại à? Tôi không đồng ý
  • Lập trình viên có hai kiểu. Kiểu A cẩn thận cả bảo mật, test, CI nhưng từ góc nhìn người dùng thì có thể gây bực bội. Kiểu B yếu hơn ở test hay triển khai nhưng lại coi trọng trải nghiệm người dùng. Cả hai đều cần thiết. Chỉ là AI có vẻ sẽ thay thế phần việc của kiểu A trước
  • Cảm giác như kiểu “Claude, giúp tôi nâng cái này lên”
  • Mỗi người cảm thấy vui ở một điểm khác nhau. Tôi thích quá trình giải câu đố. So với lên kế hoạch, việc ứng biến để giải quyết còn vui hơn
• Trước AI, cả hai nhóm đều làm cùng một công việc — cùng editor, cùng ngôn ngữ, cùng quy trình PR. Khác biệt nằm ở động cơ. Vì thế có người thích AI viết code thay mình, còn có người tiếc nuối vì phần họ từng thích nhất đã biến mất
  Bài viết của Kellan “Code has always been the easy part” cũng cùng mạch suy nghĩ đó. Thế hệ chúng ta lao vào công nghệ vì nghiện cảm giác có quyền chủ động mà web mang lại
  • Khác biệt thật sự là tiêu chuẩn chất lượng. Có người mất hàng giờ chỉ để đặt một cái tên biến, có người nghĩ “chạy được là được”. Cả hai đều có giá trị. Chỉ là tốc độ tiến bộ của model quá nhanh nên không thể đánh giá theo tiêu chuẩn của năm ngoái. Đầu ra mặc định thì ở mức trung bình, nhưng nếu biết dùng thì có thể đạt chất lượng cao hơn rất nhiều
  • Perl mà không vui về mặt thẩm mỹ ư? Tôi từng rất tự hào khi dùng Perl. Có một khoái cảm khi làm chủ trọn vẹn một ngôn ngữ khó đọc
  • Perl rõ ràng có sức hút riêng. Cú pháp như unless giúp diễn đạt luồng xử lý rất tự nhiên. Chỉ là khi nó ngừng tiến hóa, mọi người mở rộng theo những cách khác nhau và tạo ra codebase mong manh
  • Tôi không thấy bản thân việc viết code là vui, nhưng lại rất thích cảm giác thỏa mãn khi giải được vấn đề. Tôi cảm thấy kiểu tư duy này giúp đầu óc giữ được sự linh hoạt
  • Đây không phải nhị phân. Tôi là kiểu lai giữa hai nhóm. AI lo phần code cho công việc, nên ở nhà tôi lại có thời gian thoải mái để tận hưởng kiểu lập trình truyền thống
• Tôi là người thiên về kết quả. Tôi coi trọng chất lượng của kết quả. Tôi ám ảnh với độ hoàn thiện của sản phẩm hơn là quá trình viết code. Nhưng app ngày nay chậm hơn 15 năm trước và nhiều lỗi hơn. Ngay cả app Claude đôi khi cũng hiện nút không bấm được
  AI coding chỉ nâng năng suất chừng 10%. Nút thắt thật sự là quá trình hiểu xem nên làm gì và thuyết phục người khác. Viết code chỉ là phương tiện để hiểu điều đó
  • Tôi cũng dùng AI cho thu thập và kiểm chứng thông tin nhiều hơn là để viết code. Tôi để nhiều LLM làm reviewer rồi cho chúng phản biện lẫn nhau. Việc này rất hữu ích khi xử lý logic nghiệp vụ phức tạp. AI cũng hữu dụng trong khám phá edge case
  • Tôi đồng ý rằng viết code không phải nút thắt. Nói AI tạo ra năng suất gấp 10 lần là vô lý. Vốn dĩ tôi đã code rất nhanh nên AI không giúp được nhiều. Ngược lại, nó còn tạo ra tình huống bị ép ưu tiên tốc độ hơn chất lượng. Đồng đội của tôi dùng AI để đẩy ra hàng nghìn dòng code, khiến chất lượng tụt dốc mạnh
  • Có vẻ bạn đang nhầm giữa chất lượng code và độ hoàn thiện của sản phẩm. Phần lớn vấn đề xuất phát từ quyết định kinh doanh
  • Nếu “chỉ kết quả mới quan trọng” thì cũng có thể hỏi ngược lại là “vì sao không thuê ngoài luôn mà lại tự làm?”
• Tôi nhớ thời web còn được viết HTML bằng tay. Thật buồn khi hệ sinh thái web DIY, nơi cá nhân tự tay tạo ra mọi thứ, đang bị thay thế bởi các công cụ AI do doanh nghiệp sở hữu. Hiện tại vẫn là giai đoạn chuyển tiếp, nhưng sự suy tàn của web mở đang tăng tốc
• Generative AI cũng có thể được dùng như phần nối dài của tinh thần thủ công. Ta có thể gọi mã nguồn mở ra rồi hỏi “vì sao chỗ này lại hoạt động như vậy?” để làm phát triển dựa trên sự thấu hiểu
  • Niềm vui giải đố không biến mất mà chỉ dịch lên một tầng cao hơn. Giờ đây phần việc của người thợ là thiết kế cấu trúc tổng thể của hệ thống và lý do đằng sau nó
  • Tất nhiên rồi sau đó phải đóng góp ngược lên upstream
  • Thật ra kiểu này trước đây cũng làm được bằng công cụ tìm kiếm rồi
• Cả ba kịch bản đều tệ. ① AI yếu → Đại suy thoái 2.0, ② AI đạt mức dự đoán → một nhóm siêu giàu nhỏ độc chiếm mọi thứ, ③ AI siêu mạnh → loài người diệt vong. Lượng AI lý tưởng là 0
  Nhưng dù sao cũng phải thử phản kháng
  • Tôi trước đây cũng nghĩ vậy, nhưng dạo này nhìn vào những giới hạn thực tế sau cơn sốt AI thì thấy thị trường sớm muộn cũng sẽ điều chỉnh. Hiện tại nó giống thời AOL hơn
  • Trí tuệ thật sự không chỉ là biến văn bản thành lời gọi công cụ, mà còn phải bao gồm lập kế hoạch, phản biện và giải quyết vấn đề một cách sáng tạo
  • Thật ra ở cả kịch bản 1 và 2, người hưởng lợi đều là cùng một nhóm. Kịch bản 3 chỉ là ảo tưởng để đánh lạc hướng đám đông
• Sau nhiều năm làm ở startup, tôi đã bỏ ý niệm về “tinh thần thủ công”. Thay vào đó tôi có trực giác rõ ràng về mức độ nguy hiểm của việc thiếu code review cho mã do AI tạo ra hay PR quá lớn. Đây không phải vấn đề tinh thần thủ công mà là vấn đề của độ chính xác và quản lý nợ kỹ thuật
  • Vấn đề không phải là người “theo đuổi kết quả”, mà là những kẻ chỉ giành công rồi né việc. Dù code của họ có phá nát mọi thứ thì họ cũng đã chuyển sang dự án khác rồi
  • Theo kinh nghiệm của tôi, quan trọng hơn thế đối lập “thủ công vs kết quả” là cảm giác biết cách xây cả tòa nhà cho tốt. AI nhận một phần việc như nhà thầu phụ thì ổn, nhưng hiện giờ nó giống mức thuê ngoài cả công trình, nên kết quả rất tệ
• Lập trình viên có hai kiểu. Một là người mê code đến mức không trở thành quản lý, hai là người gặp cơ hội sẽ lập tức thành quản lý. Nhóm thứ hai hưởng lợi từ AI nhiều hơn
  • Người giỏi làm việc với con người thì nên làm quản lý. Và còn có kiểu thứ ba nữa — người thích thiết kế hệ thống và giao phần triển khai cho người khác