- Sự xuất hiện của các công cụ lập trình LLM đã khiến tiền đề nền tảng của phát triển phần mềm tồn tại suốt hàng chục năm sụp đổ, và thay vì viết code, khả năng định nghĩa vấn đề và thiết kế cấu trúc trở thành năng lực cốt lõi
- Giờ đây, trọng tâm của phát triển đang chuyển từ “khả năng viết code giỏi” sang “khả năng nói” để hình dung vấn đề và giải thích nó rõ ràng
- Cấu trúc code gọn gàng, README và tài liệu được sắp xếp tốt không còn là tín hiệu đáng tin về sự chăm chỉ hay độ thành thạo, mà ngược lại, càng quá hoàn hảo thì khả năng là slop càng cao
- Khi việc phân biệt bề ngoài giữa code do AI tạo ra và code do con người viết gần như không thể, tiêu chí quyết định giá trị của code đang chuyển từ chất lượng sang tính trách nhiệm, nguồn gốc và tính con người
- Động lực hợp tác và chia sẻ vốn nâng đỡ hệ sinh thái FOSS đang suy yếu, và thay vì bản thân code, niềm tin, quản trị và năng lực tuyển chọn đang trở thành tài sản quan trọng hơn
- Những công cụ này là bộ khuếch đại mạnh mẽ với lập trình viên dày dạn kinh nghiệm, nhưng với người mới, chúng có thể là một con thần đèn (genie) nguy hiểm có thể cướp đi cơ hội xây nền tảng hiểu biết cơ bản
Mở đầu: Châm ngôn của Linus Torvalds và sự đảo ngược của nó
"Talk is cheap. Show me the code"
- Câu nói này của Linus Torvalds năm 2000 tượng trưng cho thái độ rằng nếu không chứng minh bằng code thực tế thì lời nói không có giá trị
- Khi đó, dù có kế hoạch phát triển rõ ràng đến đâu, việc hiện thực hóa một chương trình phức tạp tự thân đã đòi hỏi nỗ lực khổng lồ, thời gian dài và sự lặp lại nhàm chán
- Điểm nghẽn thực sự không phải công nghệ mà là giới hạn của con người: băng thông nhận thức, thời gian và năng lượng cá nhân, cùng cái giá sinh học của việc phải giữ cả hệ thống lớn trong đầu rồi viết từng dòng code
- Kết quả là phần lớn ý tưởng chỉ chất đống trong “wishlist muốn làm vào một ngày nào đó”, rồi biến mất mà chưa từng được thử nghiệm
25 năm sau: LLM đảo lộn mọi thứ
- Năm 2025, Linus Torvalds đã merge code do AI tạo ra vào dự án sở thích của mình và nhận xét: “Nó có tốt hơn những gì tôi tự tay viết không? Tất nhiên là có”
- Từ góc nhìn của một người đã làm phần mềm suốt hàng chục năm, tác giả khẳng định dứt khoát rằng cách phát triển phần mềm như chúng ta từng biết đã kết thúc
- Là người thuộc thế hệ từng trực tiếp đi qua nhiều lần chuyển dịch từ dial-up sang gigabit, từ Basic sang Node.js, từ SourceForge sang GitHub, tác giả nhận thức rõ rằng thay đổi lần này không phải mốt nhất thời mà là một đứt gãy về chất
Sự sụp đổ của tiêu chí đánh giá chất lượng code
- Trước đây, khi đánh giá một dự án FOSS, các tiêu chí như tuổi đời dự án, tần suất commit, tính nhất quán trong cấu trúc code, chất lượng README và tài liệu đóng vai trò quan trọng
- Những chú thích súc tích và tài liệu được tổ chức tốt được xem là tín hiệu cho thấy sự cẩn trọng của lập trình viên và sự quan tâm tới các lập trình viên khác
- Nhưng khi LLM có thể tạo ra ngay lập tức trang tài liệu hoàn chỉnh, README chi tiết quá mức, UI gọn gàng, pattern và comment ngăn nắp, các tín hiệu này không còn hiệu lực
- Kết quả là ngày càng khó phân biệt chỉ qua bề ngoài liệu một repository là sản phẩm vibe coding của người không chuyên, hay là kết quả do lập trình viên giàu kinh nghiệm thiết kế
- Trớ trêu thay, càng trông quá hoàn hảo thì lại càng phải nghi ngờ đó là sản phẩm one-shot ít công sức
- Nếu không có mức độ rà soát và phân tích tinh vi như chuyên gia, việc phân biệt wheat và slop ngày càng khó hơn
- Vì thế, thay vì bản thân code, các yếu tố như ai làm ra nó, vì sao làm, chủ thể đó có lịch sử thế nào, có quản trị và kế hoạch bảo trì hay không đang nổi lên như tiêu chí quan trọng hơn về provenance
Sự thay đổi trong giá trị của nỗ lực
- Trước đây, để tạo ra 10.000 dòng code chất lượng cao tạo ra kết quả có ý nghĩa, một lập trình viên giỏi phải trải qua thời gian dài tập trung và lặp đi lặp lại quá trình cải tiến
- Số dòng code tự thân không phải thước đo chất lượng, nhưng 10.000 dòng đã được gọt giũa tốt hàm ý rằng đã có thời gian, sự tập trung, kiên nhẫn, chuyên môn và một mức năng lực quản lý dự án nhất định được đầu tư vào đó
- LLM có thể tạo ra những kết quả như vậy chỉ trong vài giây, đồng thời xử lý toàn bộ workflow kỹ thuật từ test, cấu hình hệ thống đến triển khai
- Khi chuyên môn và phán đoán của con người cùng tham gia, kết quả có thể đạt tới chất lượng cao đủ để dùng thực tế
- Cá nhân tác giả cũng liên tục trải nghiệm việc những công việc từng mất vài tuần hoặc vài tháng giờ có thể hoàn thành trong vài ngày, đôi khi chỉ vài giờ
- Điều này có thể đạt được chỉ với một LLM agent CLI đơn giản, không cần AGENT.md hay orchestration đa tác tử phức tạp
- Chi phí sinh lý, nhận thức và cảm xúc từng phải trả để có được sản phẩm phần mềm đã giảm đi nhiều bậc
- Thời gian và dư địa nhận thức có được nhờ vậy lại được tái đầu tư vào tư duy kỹ thuật, thiết kế kiến trúc, thảo luận, thử nghiệm và mở rộng trí tưởng tượng
- Câu nói cũ “lập trình là 90% suy nghĩ và 10% gõ phím” giờ đây không còn là ẩn dụ mà đã thành hiện thực
Định nghĩa Slop và giá trị của code
- Trong tình huống mà ngay cả người chưa từng viết một dòng code cũng có thể tạo code ở quy mô công nghiệp chỉ trong vài giây, giá trị của bản thân sản phẩm gọi là code còn là gì?
- Lập luận kiểu “tôi chỉ muốn code thuần con người chứ không muốn code AI” nếu xét theo thực tế thì chỉ là một câu đùa gần như mang tính mỉa mai
- Đã có quá đủ các ví dụ về thảm họa lớn do code con người viết gây ra, như sự cố IT của CrowdStrike (2024), Boeing 737 MAX bị đình chỉ khai thác, vụ bê bối của Bưu điện Anh, vụ rò rỉ dữ liệu quy mô lớn ở Ấn Độ, hay vụ lộ dữ liệu Equifax
- Phần đáng kể trong lượng code mà con người viết ra mỗi ngày trên toàn cầu đang ở trạng thái giáp ranh về chất lượng
- Phát triển phần mềm vẫn là một lĩnh vực khó có thể xem là một ngành học chuyên môn đã đạt mức trưởng thành khách quan
- Bác sĩ hay kỹ sư xây dựng phải trải qua đào tạo nghiêm ngặt, cấp phép và chịu trách nhiệm về kết quả thực tế, trong khi phát triển phần mềm gần như không có cơ chế tương tự
- Xã hội ngày nay đang vận hành trên nền những hệ thống code thiết kế lỏng lẻo, chắp vá cẩu thả và bị thổi phồng quá mức
- Nếu nhìn theo lối lập luận giàu cảm tính, thậm chí có thể nói slop do AI tạo ra ít nhất còn sạch sẽ về hình thức, tài liệu gọn gàng và nhất quán về cú pháp trong nhiều trường hợp
- Việc đọc những câu văn và thông điệp vô hồn do LLM tạo ra tràn ngập Internet ngày càng bị xem như sự lãng phí kích hoạt nơ-ron hạch hạnh nhân theo đúng nghĩa đen
- Khi thiếu vắng quá trình sáng tạo của con người, cùng với sự hoàn hảo lẫn khiếm khuyết bên trong nó, ngôn ngữ, văn chương, nghệ thuật và âm nhạc trở thành thứ về bản chất không còn đáng thưởng thức
- Những gì có thể được tạo ra vô hạn, tức thì và không cần nỗ lực trở thành đối tượng cực kỳ khó để con người gán giá trị
Code khác với nghệ thuật
- Về bản chất, code luôn chỉ là phương tiện phục vụ mục đích, chứ chưa bao giờ là mục đích tự thân
- Người dùng cuối không đọc code, cũng không cần đọc, và cũng không quan tâm đến bản thân code
- Việc hàng trăm hệ thống phía sau một cổng dịch vụ được triển khai bằng ngôn ngữ, framework hay kiến trúc nào không có ý nghĩa với người dùng
- Code là thứ bị che giấu triệt để, và người dùng chỉ trải nghiệm kết quả cùng hiệu ứng mà code tạo ra thông qua UX
- Tiêu chí để phân biệt code AI có cùng chức năng là slop hay không nằm ở cấu trúc trách nhiệm (accountability) và mức độ có sự can dự của con người (humanness)
- Một PR do con người tự tay viết rồi đưa lên kho mã nguồn mở, bất kể chất lượng code ra sao, tự nhiên vẫn nhận được sự đồng cảm và giá trị gắn với giả định về thời gian và công sức con người đã bỏ vào đó
- Ngược lại, PR do LLM tạo ra thường dễ nhận phản ứng đầu tiên là “slop!” bất kể chất lượng, vì không thể ngay lập tức ước lượng công sức con người được chứa trong đó
- Đồng thời, gánh nặng phải đọc và xác minh đoạn code ấy lại tăng lên mất cân đối, theo cấp số nhân so với chi phí tạo ra nó
- Rốt cuộc, đó chỉ là một trong vô hạn biến thể được tạo ra không cần nỗ lực, không mang nguồn gốc hay ngữ cảnh có ý nghĩa
- Ở điểm này, thực tại của chúng ta ngày càng giống với “Thư viện Babel” mà Borges từng mô tả
Tương lai của FOSS
- FOSS có lẽ là một trong những hàng hóa công vĩ đại nhất mà nhân loại từng tạo ra
- Ở điểm khởi đầu của FOSS là tiền đề lịch sử rằng phần mềm cực kỳ đắt đỏ và chỉ một số rất ít chuyên gia mới có thể tạo ra
- Chỉ có số cực ít người trên toàn cầu có thể làm phần mềm, còn phần lớn những người khác chỉ có thể dừng ở vai trò sử dụng kết quả ấy
- Giờ đây, dù nhu cầu có ngách đến đâu, một chuyên gia cũng có thể nhanh chóng tạo ra thư viện nhỏ khớp chính xác với nhu cầu của mình
- Xa hơn nữa, chỉ cần thông minh ở mức nào đó, ai cũng có thể tự làm và dùng các công cụ nhỏ cần cho mục đích cá nhân bằng vibe coding
- Điều từng xảy ra với StackOverflow, tuy chậm hơn, cũng đang diễn ra tương tự trên toàn bộ phần mềm
- Đây có vẻ là một thay đổi rung chuyển trực diện cốt lõi của động lực con người, điều kiện xã hội và incentive tham gia từng chống đỡ cho hợp tác và chia sẻ trong FOSS
- Nếu tính đến vụ nổ kiểu Cambri của các dự án FOSS sẽ đổ ra với quy mô chưa từng có
- Thì ở những dự án FOSS chất lượng cao còn sống sót và phát triển, quản trị bởi chuyên gia, năng lực tuyển chọn và cấu trúc niềm tin có thể sẽ trở thành tài sản quan trọng hơn bản thân code
Hai thái cực chỉ thấy cây mà không thấy rừng
- Ngay cả thời chưa có syntax highlighting, IDE hay đủ loại công cụ, con người vẫn đã tạo ra phần mềm ở mức đáng kinh ngạc
- Ngược lại, ngay trong thời đại tràn ngập công cụ và tài nguyên như bây giờ, phần mềm tệ hại vẫn tiếp tục được tạo ra
- Lập trình viên giỏi, có khả năng diễn đạt và quan tâm đến chất lượng sẽ dùng LLM hay bất kỳ công cụ nào khác theo cách riêng để tạo ra kết quả tốt
- Trong khi đó, lập trình viên không thể giải thích vấn đề và không quan tâm đến chất lượng vẫn tạo ra sản phẩm tệ bất kể có dùng LLM hay không
- Cả những người cực đoan tôn thờ vibe coding kiểu “agentic” lẫn những người phủ nhận hoàn toàn LLM, rốt cuộc đều không thấy rừng mà chỉ bám vào cây
- Rõ ràng có một điểm trung dung thực dụng nơi người có kinh nghiệm, chuyên môn, tư duy và khả năng diễn đạt có thể chọn đúng trade-off để đạt kết quả mong muốn
- Vibe coding cũng là điểm vào quan trọng đầu tiên để người không chuyên có thể lần đầu chạm vào phần mềm, thử nghiệm, vui chơi và phát triển năng lực
- Nhưng những người tuyệt đối hóa vibe coding lại bỏ sót yếu tố cốt lõi khiến con người nghiêm túc tiếp nhận một sản phẩm, tức tính hữu hạn (finitude)
- Kết quả là họ cũng dễ lạc lối trong biển slop do những agent nịnh nọt tạo ra, và đang chất cao một thư viện kiểu Borges khổng lồ
- Những sản phẩm được tạo ra vô hạn không cần nỗ lực, không có nguồn gốc mang ý nghĩa thì cực kỳ khó để gán giá trị hoặc tiếp nhận một cách nghiêm túc
- Về bản chất, con người là loài không xử lý tốt nguồn cung vô hạn, đặc biệt là sự vô hạn của các lựa chọn
- Ở chiều ngược lại, những người phủ nhận LLM thường cũng không vượt qua được kiểu lập luận từ sự khó tin (argument from incredulity)
- Họ phủ nhận bản thân công nghệ chỉ vì không hợp gu cá nhân, không đạt được kết quả mong muốn, kỳ vọng bị lệch, hoặc đơn giản là đã chán
- Nhưng trước thực tế là có rất nhiều người đang dùng chính công cụ ấy hiệu quả và có trải nghiệm hoàn toàn ngược lại, lập trường đó mất sức thuyết phục
- Những triển khai ngu ngốc và có hại được thúc đẩy bởi cơn sốt, cuồng loạn và lòng tham chắc chắn là có thật, và là mối lo ngại nghiêm trọng
- Bong bóng kinh doanh AI có lẽ sẽ là một trong những bong bóng lớn nhất lịch sử
- Dù vậy, sự lan rộng của công nghệ FOSS AI rõ ràng là một tín hiệu đáng hy vọng
- Việc đồng nhất các tác nhân xấu, trò chơi số liệu và những triển khai lố bịch với năng lực nền tảng và mang tính vật lý mà công nghệ này thực sự sở hữu là điều phi lý
Chi phí mang tính con người
- Từ góc nhìn của các lập trình viên và kỹ sư giàu kinh nghiệm, những công nghệ AI này hoạt động như phương tiện hỗ trợ cực kỳ mạnh mẽ và hiệu quả
- Nhưng với người học giai đoạn đầu và junior vừa bước chân vào ngành, một vấn đề hoàn toàn khác được đặt ra
- Nếu nền tảng còn yếu, và chưa hình thành được sự hiểu biết nội tại, tinh tế về hệ thống và quy trình phát triển phần mềm, thì công nghệ này gần với một con thần đèn (genie) không đáng tin và nguy hiểm
- Cứ yêu cầu code là có code, yêu cầu chỉnh sửa là được sửa ngay, bề ngoài trông rất tiện
- Nhưng chẳng bao lâu người dùng sẽ bị mắc kẹt trong một codebase mà họ không hiểu nguyên lý vận hành, và phải tiếp tục phụ thuộc vào thần đèn để giải quyết vấn đề
- Nếu sự phụ thuộc này lặp lại, môi trường học tập nơi năng lực nền tảng và cốt lõi có thể hình thành một cách tự nhiên sẽ biến mất, thậm chí kéo theo nguy cơ thoái hóa nhận thức
- Kết quả là có thể xuất hiện cả một thế hệ junior không bao giờ có cơ hội trưởng thành thành senior thực thụ
- Nỗi lo thật sự là cơ hội để người học đạt được chuyên môn nhằm phân biệt một cách khách quan đâu là slop và đâu không phải đang biến mất
- Nghiêm trọng hơn, ngay cả những người giàu kinh nghiệm dùng thành thạo các công cụ này cũng có thể mất động lực để mentoring và đào tạo junior theo cách nền tảng
- Điều đó hàm chứa rủi ro vượt ra ngoài phát triển phần mềm, đẩy con người theo hướng ủy quyền toàn bộ tính chủ thể và việc ra quyết định cho các black box
Kết luận: Giờ đây lời nói có giá trị hơn code
- Ngay cả với những lập trình viên đã quen tự tay phát triển, giờ đây khả năng đọc và đánh giá code một cách phản biện còn quan trọng hơn năng lực học cú pháp và gõ từng dòng
- Dĩ nhiên, vế sau vẫn là kỹ năng quan trọng, và khả năng đọc code hiệu quả rốt cuộc vẫn hình thành trên nền tảng đó
- Dẫu vậy, bản thân workflow phát triển phần mềm hằng ngày đã bị đảo lộn hoàn toàn
- Lập trình viên giỏi trong việc diễn đạt, tức người có thể tưởng tượng, giải thích, định nghĩa vấn đề, thiết kế kiến trúc và làm engineering, đang có lợi thế lớn một cách mất cân đối hơn bao giờ hết so với người không làm được vậy
- Kiến thức về ngôn ngữ, cú pháp hay framework cụ thể không còn là điểm nghẽn chủ yếu nữa
- Những ràng buộc sinh lý và vật lý từng trói buộc lập trình viên trong quá khứ cũng không còn là trở ngại mang tính quyết định
- Cỗ máy có thể tạo code quy mô lớn ngay lập tức giờ đã trở thành công cụ hàng hóa hóa, ai cũng có thể tiếp cận ở mức
pip install - Trên thực tế, nhu cầu phải học bài bản riêng hay học thêm ngôn ngữ, framework mới cũng gần như biến mất
- Thứ được yêu cầu chỉ còn là năng lực tư duy phản biện kiểu cũ, những năng lực con người nền tảng, và khả năng vận hành tối thiểu để điều khiển cỗ máy này
- Kết quả là các phương pháp phát triển phần mềm và cách phân vai truyền thống — Waterfall và Agile, lập trình viên và tester, senior và junior — đang trải qua biến đổi ở cấp độ nền tảng
- Những ranh giới truyền thống đang được tích hợp vào các vòng lặp “agentic” lặp đi lặp lại nhanh đến mức khó tưởng tượng, cô đặc và ngày càng mờ nhòe
- Theo đó, động học của con người, tổ chức và cộng đồng công quanh phát triển phần mềm, cùng những incentive mang tính con người từng nâng đỡ việc chia sẻ và hợp tác, cũng đang thay đổi nhanh chóng
- Việc curl chấm dứt bug bounty, Zulip áp dụng hướng dẫn sử dụng AI, hay Ghostty có chính sách AI rõ ràng là những ví dụ cho điều đó
- Lần đầu tiên trong lịch sử, lời nói tốt (talk) trở thành yếu tố có giá trị lớn hơn theo cấp số nhân so với code tốt
- Tác động lan tỏa mà sự thay đổi này mang lại là nghiêm trọng, đồng thời cũng rất mang tính phá hủy
10 bình luận
"Ngay cả những người chưa từng viết một dòng code nào cũng có thể tạo ra code ở quy mô công nghiệp chỉ trong vài giây" -> Nếu xây chung cư bằng ống hút nhựa thì như vậy có được gọi là quy mô công nghiệp không?
Tôi từng rất thích câu nói đó của Torvalds... đúng là thời đại đã hoàn toàn thay đổi rồi.
Tôi rất đồng cảm sâu sắc với ý tưởng rằng "chính môi trường học tập đang biến mất". Trong một thế giới mà chi phí tiếp cận tri thức gần như bằng 0, giáo dục từ nay sẽ mang hình thái như thế nào?
Thực tế là trong phần lớn các đợt tuyển dụng, họ luôn yêu cầu ứng viên có từ N năm kinh nghiệm trở lên với các ngôn ngữ như Java.
"Lời nói" và "bài viết" là hai thứ khác nhau.
Thực ra có vẻ như phải viết "bài viết" cho tốt hơn là "lời nói".
🐎🐎🐎🐎🐎
Aiba Kimino kyun kyun~
Chỉ mới vài năm trước thôi, mỗi khi đi gặp đồng nghiệp trong công ty hoặc tham gia các buổi gặp gỡ của nhà phát triển, người ta còn hay chê bai những kỹ sư "chỉ được cái nói" mà không có thực lực (mù quáng bám lấy các xu hướng và từ khóa công nghệ mới nhất như một kiểu early adopter, cùng lắm chỉ có kinh nghiệm dùng framework hay library chứ chưa từng tự tay làm ra cả những thứ cơ bản...) là "lập trình viên bằng miệng"... Giờ thì "lập trình viên bằng miệng" lại trở thành hiện thực của nghề phát triển. Ha, đúng là cảm khái vì thời thế đổi thay.
Ý kiến trên Hacker News
Hôm nay tôi nhờ Codex viết unit test cho Redux
Ban đầu trông cũng ổn nên tôi cho qua, nhưng sau đó khi tự thêm test và xem lại thì có hàng chục chỗ khiến tôi phải nghĩ “cái gì đây?”
Chạy thì vẫn chạy, nhưng rất lộn xộn. Dù chỉ là đoạn code đơn giản mà cũng ở mức đó
Mỗi lần dùng AI tôi đều có trải nghiệm tương tự — bề ngoài có vẻ ổn, nhưng hễ muốn mở rộng là thành thảm họa, cuối cùng tôi vẫn phải tự dọn dẹp hết
Vấn đề của câu “code is cheap” là, tạo ra thì rẻ nhưng bảo trì thì đắt
Sinh ra hàng nghìn dòng mỗi ngày cũng giống như chất nợ bằng thẻ tín dụng. Tưởng là miễn phí, đến lúc hóa đơn bay tới mới biết
Không chắc chúng tôi có thể tác động trực tiếp được gì không, nhưng tôi muốn xem chuyện gì đã xảy ra
Tham khảo thêm, cách tiếp cận test của Redux được tổng hợp trong tài liệu chính thức
Trước tiên cần làm rõ phương pháp kiểm thử, rồi mới dựa vào đó để yêu cầu model
AI sẽ tự tiện giả định những phần không được nêu rõ, nên phải cẩn thận
Về bản chất thì test mới là cốt lõi. Đừng đánh giá code AI bằng cảm tính, mà phải xác minh bằng test
Giá trị của code tỷ lệ thuận với chất lượng test. Nếu chỉ kiểu “LGTM” rồi cho qua thì chẳng khác gì nhắm mắt lái xe máy
Có trường hợp nó làm tốt, nhưng cũng có lúc làm ra thứ hoàn toàn tệ hại
Ví dụ, tôi đưa đúng use case nhưng code lại sai, đến khi test fail thì AI quay sang viết lại test
Nghĩa là nó có nguy cơ tự định nghĩa tiêu chí thành công theo ý mình
Trước đây tôi từng chạy hai instance Claude, một cái lo test, một cái lo implementation, nhưng cấu hình quá phiền phức
Vì vậy tôi nghĩ đây cũng là một trong những lý do công nghệ này bị ép triển khai trong đội ngũ
Giống như chuyển sang cloud, chi phí thực sự chỉ lộ ra về sau. Chỉ là lần này có lẽ sẽ đến nhanh hơn nhiều
Nếu ví bằng chuyện lắp ráp ô tô,
thì người chỉ đơn thuần ráp linh kiện theo spec có lý do để lo cánh tay robot sẽ thay thế mình
Nhưng người thử nghiệm thiết kế, làm prototype và lập trình cho cánh tay robot thì ít phải lo về tự động hóa hơn
Nhiều phản biện nói theo kiểu “AI cũng sẽ tự động hóa cả vai trò thứ hai”, nhưng thực tế tôi thấy nhiều người đang nhầm công việc loại một thành loại hai
Vì họ có thể debug, đổi hướng và đưa ra chỉ dẫn cụ thể
Người dùng phổ thông chỉ lặp đi lặp lại câu “cái này không chạy, sửa giúp tôi”
Vì thế hình thức công việc sẽ thay đổi, nhưng bản thân nghề này sẽ không biến mất
Nếu AI có thể bắt chước điều đó thì nó cũng có thể thay thế tôi
Trong một nền kinh tế ít cạnh tranh, chỉ cần “bắt chước cho ra vẻ” thôi cũng đã đủ
Kể cả sản phẩm AI tệ hại, chỉ cần vẫn đảm bảo doanh thu và lối thoát đầu tư là đủ
Thế giới này lúc nào cũng chấp nhận kiểu ‘rác rưởi phân tán’. Cứ nhìn Windows thì rõ
Thực ra có rất nhiều phần hoàn toàn có thể tự động hóa, và có vẻ bấy lâu nay lòng tự tôn của tôi đã tự đánh giá mình quá cao
Nhưng LLM ngày nay tổng quát hơn nhiều, nên có thể đảm nhận đủ loại lớp công việc
Nếu bảo cánh tay robot “hãy cải tiến thiết kế xe năm nay” thì nó sẽ đứng hình, nhưng AI có thể đưa ra ý kiến
Nếu AI có thể làm trọn quy trình từ ý tưởng → thiết kế → chế tạo → test → đánh giá,
thì đây là một đổi mới khác biệt về bản chất so với các công nghệ trước đây
Câu “thời đại viết code bằng tay đã kết thúc” là cường điệu
Kiểu cường điệu này là chiêu nhằm lung lay chuyên môn của người khác và kích thích FOMO
Đừng sợ, hãy tin vào phán đoán của chính mình
Chỉ là đúng là công nghệ sẽ thay đổi cách người ta thực hành
Cuối cùng, điều quan trọng là năng lực cân bằng giữa hiệu năng, chi phí, tiến độ và chất lượng
Luôn có rất nhiều phản ứng với luận điểm “engineering đã kết thúc”,
nhưng theo tôi, trong các sản phẩm quy mô lớn thì việc viết code chỉ chiếm khoảng 10~20% tổng thể
Phần còn lại là thiết kế, thử nghiệm, phân tích, giao tiếp..., mà LLM khó thay thế được
Thậm chí việc cộng tác và điều phối còn trở nên phức tạp hơn, và nhiều khi LLM làm mọi thứ tệ hơn
Vì vậy nên xem AI là công cụ chứ không phải thứ thay thế
Họ nói rằng “cách phát triển đã tồn tại hàng chục năm nay đã kết thúc”, chứ không nói engineering đã kết thúc
Nếu viết code chỉ là 10~20%, thì điều đó có nghĩa phần “trao đổi” còn lại đã trở nên quan trọng hơn
Như lời Linus: “hãy cho tôi thấy code hoạt động đúng như chủ đích”
Viết ra vài dòng bằng LLM thì dễ, nhưng sửa đổi một cách an toàn vẫn rất khó
Nghe nói Liz Fong-Jones của Honeycomb cũng từng mắc kiểu sai lầm này
Khi các công ty bắt đầu theo dõi ROI của LLM, họ sẽ nhận ra thực tế
Hiện tại chúng ta đang ở đỉnh của hype cycle theo Gartner, và có lẽ sắp đi xuống thung lũng vỡ mộng
Nhờ Claude mà tôi refactor rất nhanh, rồi đến một lúc thì mắc kẹt hoàn toàn
Lý do là vì tôi không biết mình thực sự muốn gì
Nếu mô hình dữ liệu còn chưa rõ mà cứ bảo “viết tiếp đi”, thì kết quả sẽ cực kỳ tệ
lập trình là hoạt động ngắn hạn, còn software engineering là một quá trình dài hạn
AI có thể tăng tốc cái đầu tiên, nhưng không thể thay thế cái thứ hai
Tiền đề “có sẵn kế hoạch phát triển rõ ràng và bí quyết triển khai” không thực tế
Bản thân lập trình chính là một hành vi lập kế hoạch, và ngôn ngữ là công cụ tư duy rất tốt
Vì thế mới có sự khác biệt trong cách nhìn về LLM — có người xem ngôn ngữ là công cụ tư duy, có người xem nó chỉ là công cụ thực thi
Nhóm trước nhìn thấy giá trị của chính hành vi lập trình, còn nhóm sau thì muốn che giấu code đi
Cuối cùng đây là vấn đề lựa chọn: xây dựng mô hình khái niệm thật tốt ngay từ đầu, hay đến sau đó phải chịu địa ngục debug
Công cụ hiện nay chưa phục vụ tốt cho nhóm đầu. Khoảng cách tooling là rất lớn
Một số người đang kết hợp cả hai để làm việc theo cách mới
Ý nghĩa gốc của “Talk is cheap” là “nói thì dễ và không có giá trị”
Nhưng “Code is cheap. Show me the talk.” lại mang sắc thái kiểu còn vô giá trị hơn cả thế, nên ngay từ đầu tôi đã thấy khó chịu
Đọc bài xong thì đúng như tôi dự đoán
Tác giả không phải người mù mờ về code. Họ cũng hoạt động mã nguồn mở rất tích cực
Ý chính rất đơn giản — trước đây việc hiện thực hóa một thiết kế tốt thành code là việc tốn kém,
còn bây giờ nó rẻ hơn, nên chất lượng của thiết kế càng quan trọng hơn
“Talk is cheap, show me the code”
Thứ cốt lõi không phải code mà là mô hình trong đầu của lập trình viên
Code chỉ là sản phẩm phụ của mô hình đó, và nếu không có diễn giải của con người thì nó không có ý nghĩa
Góc nhìn này cũng ảnh hưởng rất lớn đến cách dùng LLM
Tôi khó đồng ý với câu “cách làm suốt vài chục năm qua đã kết thúc”
Cách phát triển phần mềm năm 2005, 2015 và 2025 đều khác nhau
Thay đổi lúc nào cũng tồn tại, nên tiền đề “mấy chục năm nay đều như nhau” là sai
Công cụ có tiến bộ, nhưng cách làm việc của lập trình viên vẫn khá giống nhau
thì neovim hiện tại còn mạnh hơn rất nhiều so với thời đó
Mọi người có xu hướng đánh giá thấp những tiến bộ tiệm tiến trong 30 năm qua
Khi đó, phần lớn thông tin đều phải lấy từ sách giấy hoặc reverse engineering
Câu “Talk is even cheaper, still show me the code” làm tôi thấy đúng hơn
AI hứa hẹn năng suất gấp 10 lần, nhưng tôi gần như chưa bao giờ thấy kết quả thật sự như vậy
Nhờ AI mà độ phức tạp trở nên dễ chịu hơn, nhưng viết ứng dụng React vẫn là nỗi đau
Xử lý các API không mang tính quyết định cũng vẫn rất vất vả
Dù vậy, việc tốn ít thời gian hơn cho lỗi gõ và tìm ví dụ vẫn là một điểm cộng
Nhưng vì thiếu năng lực suy luận và giới hạn kiến thức, coding vẫn còn nhàm chán
chuyển thành ký tự ANSI và đè lên terminal —
thực chất là đã triển khai một việc hoàn toàn có thể làm đơn giản bằng curses theo cách phức tạp không cần thiết
Những câu như “Code is cheap. Show me the talk.” giờ đang bị lạm dụng như mồi câu click
Bản thân bài viết không tệ, nhưng cũng chẳng có gì mới
Không chỉ doanh nghiệp, mà cả blogger và influencer cũng đang cưỡi trên làn sóng AI
Chỉ cần gắn tiêu đề kích thích lên các bài viết tích cực hay tiêu cực về AI là đủ thành xu hướng trên HN hay Reddit
Tham khảo thêm, nguồn gốc của câu này là tweet này và
trang meme này
Cuối cùng cũng có người diễn đạt rất tốt vùng trung gian thực tế giữa hai thái cực
LLM không phải thần thánh, cũng không phải thảm họa. Nó là công cụ
Ta có thể vừa phê phán việc trích xuất địa tô của các công ty như OpenAI, Google, Microsoft,
vừa tận dụng các mô hình chạy cục bộ như Qwen hay Mistral
LLM trên cloud không thể có E2EE về mặt bảo mật, nên không phù hợp với môi trường doanh nghiệp
Nhưng nhờ LLM cục bộ mà giờ đây một người cũng có thể làm việc ở cấp độ enterprise
Chỉ với một chiếc Mac Mini là tôi xử lý được truy vấn cơ sở dữ liệu, tích hợp API và tự động hóa
Nếu không phải tổ chức quy mô lớn, thì một senior generalist có thể thay cho ba người mid-level
Dĩ nhiên tôi vẫn rất bất mãn với chuyện việc làm bị thu hẹp hay vấn đề bản quyền,
nhưng LLM cục bộ đã trở thành một phần bộ công cụ cốt lõi của tôi
Đúng là một bài viết muốn cho những người đang theo "đức tin" xem.