- Các công cụ lập trình dựa trên AI như LLM đã chiếm vị trí thiết yếu trong thực tế phát triển phần mềm
- Nhiều người quen vẫn tin rằng AI chỉ là một trào lưu nhất thời, nhưng tác giả nhấn mạnh rằng trong lĩnh vực phát triển thì đã đến lúc phải thay đổi cách nghĩ
- Tác nhân lập trình tự động hóa các công việc lặp đi lặp lại và nhàm chán, giúp lập trình viên tập trung hơn vào những việc có ý nghĩa hơn
- Dù còn tranh cãi về chất lượng, quyền sở hữu, hỗ trợ công cụ của mã do AI tạo ra, phần lớn cũng chỉ lặp lại những vấn đề vốn đã có trong môi trường phát triển hiện nay
- Thái độ thụ động trước việc áp dụng LLM là không phù hợp, và điều đó cho thấy những thay đổi công nghệ còn quan trọng hơn đang ở phía trước
Mở đầu: AI, lập trình và sự hoài nghi
- Gần đây, các lãnh đạo công ty công nghệ có xu hướng ép buộc việc đưa công cụ LLM vào sử dụng, nhưng đây là một chiến lược sai lầm
- Trong số những lập trình viên thông minh quanh tác giả, có người xem AI như một trào lưu chóng tàn kiểu NFT và không coi trọng nó
- Tuy nhiên trên thực tế, việc triển khai LLM đã tạo ra thay đổi lớn trong lĩnh vực phát triển
- Bài viết tập trung vào ý nghĩa của LLM trong phát triển phần mềm, và không bàn sang các lĩnh vực khác như nghệ thuật, âm nhạc hay viết lách
Tác nhân LLM và cách sử dụng hiện đại
Cập nhật mặt bằng: LLM trước đây so với tác nhân hiện tại
- Khác với giai đoạn 6 tháng đến 2 năm trước khi chỉ dùng ChatGPT hay Copilot một cách đơn giản, hiện nay môi trường tác nhân LLM đã tiến hóa đang lan rộng
- Lập trình viên ngày nay để tác nhân tự do khám phá và chỉnh sửa codebase, từ đó tự động hóa việc tạo file, biên dịch, kiểm thử và lặp lại quy trình
- Hỗ trợ cung cấp cây mã nguồn và mã từ nguồn bên ngoài, trích xuất thông tin bằng công cụ Unix, tương tác với Git và chạy nhiều công cụ phát triển khác nhau
- Bản thân logic thao tác mã thực tế chỉ là mã hệ thống đơn giản
- Việc copy-paste mã từ ChatGPT như trước đây đồng nghĩa với chưa thật sự trải nghiệm sự thay đổi mang tính bản chất
Tác động tích cực của LLM
- Phần lớn mã lặp đơn giản xuất hiện trong hầu hết các dự án đều có thể được LLM tạo ra dễ dàng
- LLM giỏi thu thập thông tin mà không cần tra cứu hay mở tài liệu liên tục, và không bị giảm hiệu quả do mệt mỏi tích lũy
- Khi lý do khiến việc bắt đầu phát triển một tính năng trở nên khó khăn là rào cản tiếp cận ngôn ngữ hay môi trường mới, LLM có thể giảm nhẹ điều đó đáng kể
- Những việc phiền toái trong phát triển như refactor mã kiểm thử phục vụ bảo trì hay xử lý phụ thuộc đều có thể giao cho LLM
- Lập trình viên có thể dồn nhiều năng lượng hơn vào những phần quan trọng và mang tính sáng tạo
Phản biện lập luận “không hiểu được mã do LLM tạo ra”
- Việc đọc kỹ và chỉnh sửa cho đúng style đối với mã được merge vào team là điều hiển nhiên
- Mã do LLM tạo ra mang tính dự đoán được theo nghĩa “thuật toán”, nên có thể hiểu và rà soát kết quả đầu ra
- Nếu không đủ khả năng review lặp đi lặp lại, thì cũng có khả năng cao là bạn sẽ không xử lý nổi cả những đoạn mã lộn xộn do con người viết
Góc nhìn về “vấn đề ảo giác (hallucination) của AI”
- Tác nhân LLM còn thực hiện lint mã, biên dịch và kiểm thử, qua đó sửa lại thông tin sai và đảm bảo độ tin cậy
- Vấn đề ảo giác trong phần lớn môi trường đã được giải quyết ở mức đáng kể
- Để sử dụng hiệu quả, điều cần thiết không phải là giám sát quá chi li mà là tin tưởng vào quy trình tự động hóa
Chỉ trích “mã AI có trình độ thấp”
- Chi phí dịch vụ LLM rẻ hơn lương thực tập sinh (ví dụ: Cursor.ai $20/tháng)
- Lập trình viên senior có vai trò nâng năng suất của thực tập sinh năng lực yếu hoặc của mã do LLM tạo ra
- Khả năng tận dụng tác nhân lập trình, tooling và thiết kế prompt cũng là một lĩnh vực tay nghề kỹ thuật mới
- Có sự lẫn lộn về chuyện “ai nên đảm nhận phần việc nào”, nhưng về bản chất lập trình viên vẫn chịu trách nhiệm về định hướng, kiểm chứng và phán đoán
Tranh cãi “AI làm việc kém trong Rust”
- Giới hạn tương thích với ngôn ngữ hay công cụ cụ thể là bài toán của từng hệ sinh thái
- Với những ngôn ngữ thân thiện với LLM như Go, mức độ tận dụng AI là rất cao
- Vấn đề hợp với Rust không có nghĩa là giới hạn chung của toàn bộ LLM, mà cần chiến lược phù hợp theo từng ngôn ngữ
Tinh thần thủ công (Craft) và lập trình thực chiến
- Mục tiêu của phát triển phần mềm là giải quyết vấn đề thực tế một cách thực dụng
- Việc bám chấp không cần thiết vào chất lượng mã là một kiểu "yak-shaving", và gây kém hiệu quả trong công việc thực tế
- Những việc lặp lại và phiền toái nên giao cho LLM, còn lập trình viên cần tập trung năng lực vào khoảng tạo ra giá trị
Chấp nhận sự tầm thường (“mediocrity”) của mã AI
- Phần lớn mã không cần phải quá xuất sắc mà thực tế vẫn không có vấn đề gì
- Những phần quan trọng thì nâng chất lượng lên, còn những phần không quan trọng thì nên biến việc tiết kiệm chi phí nhờ LLM thành lợi thế
- Mã do LLM tạo ra an toàn hơn ở các phần lặp lại, còn trong lĩnh vực thuật toán thì có thể tiếp cận rộng hơn con người
Ý kiến về quan điểm “vẫn còn xa mới đến AGI (trí tuệ nhân tạo tổng quát)”
- Tác giả không mấy quan tâm đến tranh cãi AGI, và cho rằng chỉ cần nó hoạt động ngoài thực tế là đủ
- Hiệu năng thực tế và mức tăng năng suất mới là tiêu chí phán đoán ở thời điểm hiện tại
Tranh cãi về thay thế việc làm
- Giống như việc phổ biến mã nguồn mở, LLM cũng là công nghệ có thể làm thay đổi hoặc xóa bỏ một số nghề nghiệp
- Kỹ sư phần mềm cũng phải nhận thức rằng mình, giống như các ngành khác, là đối tượng của tự động hóa
- Cuối cùng điều đó sẽ có lợi hay có hại thì chưa rõ, nhưng bản thân sự thay đổi là điều không thể tránh khỏi
Vấn đề đạo văn/bản quyền
- AI đang trở thành mối đe dọa lớn với giới nghệ thuật thị giác
- Trên thực tế, LLM có thể tạo ra hàng loạt kết quả đạt chất lượng công nghiệp
- Các lập trình viên phần mềm khó có thể lấy vấn đề đạo văn ra để chỉ trích
- Từ trước tới nay, lập trình viên vốn không quá nhạy cảm với bản quyền, và thường thiên về chia sẻ và tái sản xuất hơn là bảo vệ sở hữu trí tuệ
- Tranh cãi về việc tái sử dụng một phần mã về cơ bản chỉ là một kiểu ngụy biện đặc thù
Cách tận dụng LLM mới nhất và tốc độ thay đổi
- Nhờ dùng tác nhân bất đồng bộ dựa trên LLM và xử lý công việc song song, năng suất đã tăng mạnh
- Ngay cả những lập trình viên xuất sắc cũng dùng LLM để review và bổ sung mã, đồng thời trải nghiệm hiệu quả thực tế trong một môi trường không tĩnh
- Các khu vực liên quan đến độ tin cậy như quyền truy cập hạ tầng quan trọng vẫn cần được xử lý cẩn trọng
Kết luận: thay đổi công nghệ và vượt qua sự hoài nghi
- Khác với các nhà hoài nghi AI truyền thống, tác giả vẫn giữ góc nhìn thận trọng nhưng đồng thời cảm nhận rõ sự thay đổi ngoài thực tế
- Đây là lúc các lập trình viên phần mềm cần thoát khỏi những phản biện cũ kỹ và chấp nhận sự thay đổi thực tế
- LLM và lập trình dựa trên AI được dự đoán sẽ dẫn đến thay đổi tận gốc cấu trúc ngành, giống như điện thoại thông minh hay Internet từng làm
4 bình luận
Khi viết một script đơn giản để dùng một lần thì rõ ràng là hữu ích. Tiết kiệm được rất nhiều thời gian
Cũng hữu ích trong những trường hợp cần giải quyết nhưng không thể đầu tư quá nhiều thời gian. Tuy vậy, hiện tại nhìn chung vẫn hữu ích nhưng chưa thể thay thế hoàn toàn con người. Không biết sau này sẽ phát triển đến mức nào, nhưng lúc này với vai trò trợ lý thì ở mức tạm ổn để dùng.
Dù là người tin tưởng AI hay người hoài nghi AI, cứ cực đoan là tôi lại muốn tránh xa.
Mỗi lần nhìn thấy người ta cứ gào lên rằng "điểm kỳ dị sắp đến" là lại thấy thật mệt mỏi.
Ý kiến trên Hacker News
Nếu bạn đã thử viết code bằng LLM 6 tháng trước và thất bại, điều đó chỉ cho thấy cách bạn làm khác với đa số lập trình viên đang nghiêm túc tận dụng LLM. Tuy vậy, tôi vẫn luôn hoài nghi trước những tiếng nói cho rằng công nghệ này mang tính cách mạng. Cách đây 6 tháng cũng đã có luận điệu rằng nếu không dùng LLM mới nhất thì bạn đang dùng đồ lỗi thời, và là do bạn chưa biết dùng đúng cách; nhưng giờ thì ai cũng ngầm thừa nhận các LLM đời trước thực ra không tốt. Cảm giác như hiện tượng “cậu bé AI đến rồi” cứ lặp đi lặp lại với toàn lời bào chữa. Lần này cũng lại nói năng suất công việc tăng vọt, nhưng tôi nghi ngờ không biết dựa vào đâu để tin rằng tuyên bố lần này là thật. Tôi dự đoán 6 tháng nữa người ta lại bảo các sản phẩm LLM hiện nay vốn cũng chẳng ra gì.
Đồ thị hàm mũ ở mọi thời điểm trông đều khá giống nhau. Máy tính trong nhiều năm đã cải thiện cực nhanh qua từng năm, không phải vì chiếc máy bạn vừa mua là đồ bỏ đi mà vì công nghệ thực sự đã tiến bộ rất nhanh. Một góc nhìn khác là chính cảm giác mệt mỏi vì mọi thứ cứ liên tục tốt lên mà bạn đang cảm thấy lại là kết quả của một bước tiến thật sự mang tính đột phá.
Nếu cứ mỗi 6 tháng từ lúc 0 tuổi đến 30 tuổi bạn nhờ một con người giúp đỡ, thì đến lúc nào bạn mới thực sự trầm trồ? Tùy người và tùy tác vụ mà thời điểm kinh ngạc sẽ khác nhau, nhưng theo thời gian ngày càng nhiều người sẽ phải thán phục năng lực đó. Sự tiến bộ của LLM cũng nhanh như đang nhìn một đứa trẻ lớn lên. Trước đây tôi cũng không dùng LLM, nhưng từ o3 và Gemini 2.5 Pro thì tôi dùng thường xuyên. Nếu bạn đã trực tiếp thử các model mới nhất mà vẫn chưa thấy kinh ngạc, tôi tin trong vòng 3 năm nữa bạn nhất định sẽ phải trầm trồ.
tptacek không hề đưa ra kiểu khẳng định này 6 tháng trước. LLM dần dần cải thiện theo thời gian, và thỉnh thoảng còn tạo ra đột phá ở cả những thứ trước đó hoàn toàn không chạy được. Sáu tháng gần đây là thời điểm “viết code dựa trên agent” bắt đầu thực sự hoạt động. Tư duy kiểu “cứ 6 tháng lại bảo tốt hơn nên tôi sẽ không xem nghiêm túc” có thể làm suy giảm khả năng đánh giá công nghệ đúng đắn.
Có ý kiến cho rằng bản chất vấn đề nằm ở “điểm bẻ”. Có người chỉ đơn giản dán code vào ChatGPT rồi không hài lòng, trong khi người khác dùng agent nhìn thấy toàn bộ ngữ cảnh code và đạt hiệu quả vượt trội hơn nhiều. Cuối cùng điều quan trọng không chỉ là một LLM cụ thể mà còn là khác biệt trong quy trình làm việc.
Tôi thích lập luận của Thomas, nhưng tôi nghĩ trong đó vẫn có một sai lầm cốt lõi mà người ta thường mắc phải. Lập trình viên giỏi muốn dùng LLM tốt thì phải tích lũy kinh nghiệm lâu dài, và bản thân Thomas cũng đạt được chuyên môn đó theo thời gian. Nhưng có lẽ anh ấy thuộc thế hệ cuối cùng trưởng thành mà không có hỗ trợ LLM. Bây giờ một người mới ra trường sẽ làm sao để vượt khỏi kiểu “vibe coding” và xây dựng năng lực thật sự? Trước đây người ta trưởng thành bằng cách tự tay làm, còn bây giờ có nguy cơ giao toàn bộ việc thiết kế và lắp ráp cho robot, rồi chẳng học được công cụ hay vật liệu thực sự vận hành ra sao. Thậm chí mức chịu lực của mái nhà cũng chỉ còn hiểu bằng “cảm giác” mà thôi.
Có ý kiến cho rằng ưu điểm của agent AI chỉ thực sự lộ rõ khi chuyên gia có thể đọc, hiểu và tích hợp code do LLM tạo ra vào codebase. Nhưng nếu ai cũng lập trình bằng AI, thì làm sao đào tạo được những “editor” thực thụ có thể đọc code ngày càng phức tạp, nhận diện rủi ro, biết cần test ở đâu và như thế nào, và vẽ được toàn bộ cấu trúc codebase trong đầu? Những kỹ năng hiện cần cho editor đều là thứ phải tự viết code trong thời gian dài mới hình thành. Nếu người mới thuê ngoài luôn cả tư duy thì họ không có cơ hội phát triển các năng lực đó. Vì vậy cũng có nỗi lo không biết thế hệ lành nghề sau này sẽ đến từ đâu. Ở góc độ một giảng viên, tôi thấy chua chát vì bài tập và đồ án giờ đã trở thành thứ có thể qua được bằng LLM mà chẳng cần suy nghĩ gì. Có lẽ cần một cách mới để phát triển năng lực, nhưng tôi vẫn chưa nghĩ ra; và tôi không rõ trong thế giới này người mới sẽ trưởng thành thành chuyên gia ra sao.
Có phản biện rằng nếu ai cũng chỉ dùng máy tính cầm tay thì còn học toán thế nào. Cần cho học sinh luyện tập bằng tay đầy đủ và nắm được bản chất trước, rồi mới đưa LLM vào như một chiếc máy tính cầm tay.
Có người chia sẻ rằng điều này gợi nhớ tới truyện ngắn "Profession" của Isaac Asimov. Hầu hết mọi người được máy tính truyền thẳng năng lực và nghề nghiệp, nhờ đó làm việc giỏi nhưng hoàn toàn không phát triển được đổi mới hay sáng tạo. Ngược lại, chỉ một số ít không phù hợp với công nghệ ấy mới thật sự học hỏi và trở thành nhóm duy nhất có thể thúc đẩy thế giới nghệ thuật.
Theo trải nghiệm của tôi, LLM giống một lập trình viên pair hơn, và với người mới thì gần như một kỹ sư senior. Nó không chỉ viết code mà còn giải thích rất tốt nguyên lý và quy trình, nên làm gia sư cũng xuất sắc. Với senior, nó mang lại nhiều lợi ích như review code, brainstorming ý tưởng, xử lý boilerplate. Ở góc độ chuyên gia, bạn có thể tự tập trung vào 10% công việc khó nhất và giao phần việc đơn giản còn lại cho LLM để tiết kiệm thời gian. Nếu người mới chỉ chép code mà không có hứng thú hay tò mò thì đó là vấn đề của chính họ; còn với người chủ động muốn học, LLM là một tài nguyên học tập thuộc hàng tốt nhất. Xét ở điểm đó thì đây là thời đại thuận lợi nhất cho người mới.
Cả thread này giống như đang thể hiện đúng các giai đoạn tâm lý kinh điển kiểu “không có vấn đề gì cả – à có đấy, nhưng chẳng to tát – ồ đúng là có thật, thôi thích nghi vậy”. Có cảm giác như nó đã chạm vào một trong những vấn đề cốt lõi thật sự.
Tôi cũng đồng ý rằng nếu người mới phụ thuộc hoàn toàn tư duy vào LLM thì năng lực khó mà phát triển. Nhưng bản thân tôi luôn học được cái mới qua LLM. Tôi đưa ra các bài toán về API mà mình chỉ hiểu mơ hồ rồi đọc kết quả để nắm khái niệm, và thường xuyên chỉnh sửa, refactor lại code. Mấy hôm trước tôi còn tò mò về cách signal hoạt động nội bộ nên nhờ LLM tạo ví dụ rồi cùng phân tích. Chỉ cần có sự tò mò thì nó có thể là một người gia sư đáng kinh ngạc. Junior không nên mặc định chỉ “coding theo vibe”, mà cần chủ động học. Nếu không thì đó là trách nhiệm của họ; và trong một thực tế đã không thể đảo ngược này, chỉ cần còn tò mò thì vẫn có rất nhiều con đường để phát triển.
Gần đây tôi thực sự đã thử những thứ như agent Claude 4 trên nhiều trường hợp khác nhau: codebase C lớn (tính năng mới, sửa bug), dự án Rust nhỏ, frontend nhỏ, frontend mới có tài liệu API cơ bản, v.v. Trong mọi trường hợp đều thất bại hoàn toàn. Nó lấy diff sai, truyền đối số sai cho công cụ, ngay cả chức năng cơ bản cũng thất bại, còn tự tiện refactor sai hàng trăm dòng, để lại các refactor dở dang khiến codebase thành mớ hỗn độn. Với các framework JS nhiều dữ liệu như Svelte hay solidJS thì kết quả cũng kém. Tôi thật sự không hiểu điểm mạnh thực tế của các agent mà người ta ca ngợi là gì; cảm giác giống thổi phồng marketing hơn.
Có ý kiến hỏi cách viết prompt. Thường nếu tách một tính năng thành các tác vụ nhỏ và chi tiết hơn rồi giao cho LLM thì nó hoạt động tốt hơn rất nhiều. Các việc riêng lẻ trong khoảng 10~200 dòng thường làm ổn, còn vượt quá mức đó thì liên tiếp phát sinh việc nối tiếp và thất vọng. Mức hiện tại là sự tự chủ của một thực tập sinh thông minh nhưng chưa có kinh nghiệm. Những phần như thiết kế tổng thể hay lập kế hoạch khó vẫn phải do con người làm.
Giả thuyết rằng những người quảng bá agent thực ra cũng chỉ tạo ra spaghetti code, nhưng họ không quan tâm vì cảm thấy năng suất của mình tăng lên. Không mấy ai công khai các ca thành công thực tế một cách cụ thể kèm công cụ và phương pháp; trong khi lẽ ra AI cũng có thể tự tài liệu hóa chuyện đó nhưng rồi cũng chẳng thấy.
Nhiều bài viết về agent trông như bài quảng bá. Thị trường AI có quá nhiều tiền đổ vào, lại nhớ tới các chiến dịch marketing trước đây nên tôi càng khó tin hơn. Tôi đã trực tiếp dùng thử đủ loại sản phẩm agent nhưng cải thiện thực chất là rất ít. HN vốn có nhiều người bi quan sợ AI, nên khi tranh cãi nhiều thì lại hình thành không khí rằng vấn đề là do người dùng. Có người còn nói “phải tiêu AI đến 1000 USD mới trải nghiệm đúng được”, nghe rất mùi quảng cáo.
Nếu giới hạn thay đổi mà LLM được phép thực hiện vào các đoạn code nhỏ, một file đơn lẻ, hay đơn vị dưới 50 dòng thì việc quản lý sẽ dễ hơn.
Là người học lập trình từ thập niên 90, chỉ riêng việc giờ đây có thể đưa cho máy tính đầu vào mơ hồ, không rõ ràng mà vẫn nhận được kết quả có ý nghĩa đã là điều kỳ diệu. Một thế giới nơi chỉ với mức mơ hồ kiểu con người mà vẫn nhận được đầu ra rõ ràng và hữu dụng khiến tôi có cảm giác như khoa học viễn tưởng.
Ngược lại, nhiều khi ngay cả khi bạn đưa đầu vào cực kỳ rõ ràng thì máy tính vẫn diễn giải nó theo hướng mơ hồ hơn, thành một bài toán dễ hơn cho nó giải.
Tôi lại thấy chính sự mơ hồ của LLM khiến nó hấp dẫn cho mục đích đối thoại với tài liệu. Không cần phải đổi từ khóa tìm kiếm nhiều lần để mò ra thông tin mong muốn nữa, nên nhìn chung tiết kiệm rất nhiều thời gian.
Đây thật sự là một thời đại đáng kinh ngạc; tôi vẫn thấy sửng sốt trước tính hiện thực của nó khoảng 1~2 lần mỗi tuần.
Tôi từng là fan của Star Trek: The Next Generation, và từng rất thích tưởng tượng về khác biệt giữa máy tính trên tàu Enterprise và Data. Máy tính của Enterprise có thể sắp xếp tri thức, tóm tắt, thực thi tác vụ, khá giống AI ngày nay; còn Data được xây dựng như một robot có kỹ năng cá nhân. Việc Data có giới hạn trong các lĩnh vực cảm xúc con người như hài hước hay nghệ thuật cũng khá giống AI art hiện nay. Tôi còn nhớ cả những chi tiết và diễn tiến tinh tế ở giai đoạn đầu của phim.
Tôi bước vào ngành này vì thích việc đưa chỉ thị rõ ràng cho máy móc để nhận đúng thứ mình muốn. Dijkstra từ lâu đã nhấn mạnh sự mơ hồ của ngôn ngữ con người và tầm quan trọng của “ngôn ngữ hình thức” được tạo ra để vượt qua điều đó. Thế mà rốt cuộc đến năm 2025, chúng ta lại bước vào thời đại phải tranh cãi với máy tính và chỉnh lại câu chữ bằng “prompt engineering/vibe coding”. Cũng xin gợi ý đáng đọc: EWD667: The Humble Programmer
Tôi tự hỏi những người nói về năng lực vô hạn của AI tạo sinh có thể đưa ra bằng chứng thực tế hay không. Nếu GAI hay agent thật sự mạnh như vậy, thì lẽ ra có thể chứng minh bằng việc chỉ dùng AI lập công ty và sản xuất lượng code hoàn thiện khổng lồ trong thời gian ngắn. Nhưng thực tế chẳng có dấu hiệu như thế. Đến giờ công dụng hữu ích nhất vẫn chỉ là tạo văn bản và hình ảnh đủ để con người tưởng là có ý nghĩa. Theo trải nghiệm của các startup đã áp dụng vào công việc thực tế, thỉnh thoảng nó chỉ hữu dụng ở mức khám phá API hay tìm thông tin cho tiện. Nhìn tổng thể thì thời gian lãng phí lại nhiều hơn. Giờ đã đến lúc thay vì chỉ nói AI “tốt”, người ta phải trực tiếp cho thấy kết quả do AI tự tạo ra.
Có lẽ hai bên đang nhìn từ các góc khác nhau. Từ trước đến nay luôn tồn tại một ngưỡng giữa những thay đổi khả thi trong thực tế (việc nào đáng làm so với công sức bỏ ra) và những việc bị bỏ trong backlog. Công cụ AI làm giảm chi phí ngưỡng đó, nên nhiều việc hơn trở nên đáng thử. Vì vậy phe nói “năng suất tăng gấp 5” nhấn mạnh rằng lượng code thực sự được xử lý đã tăng lên, còn phe hoài nghi thì cho rằng giá trị cốt lõi với doanh nghiệp không thay đổi nhiều. Có thể tham khảo thêm nghịch lý năng suất AI.
Có người hỏi cụ thể bạn muốn thấy loại bằng chứng nào. Bạn muốn chứng minh năng lực vô hạn, hay chỉ muốn chứng minh tính hữu dụng thực tế? Hầu như ai cũng thừa nhận không có chuyện vạn năng tuyệt đối; cái hữu ích nằm ở chỗ người hiểu đúng giới hạn và điểm mạnh của nó biết cách tận dụng. Họ còn đưa ra lịch sử commit gần đây của cloudflare/workers-oauth-provider làm ví dụ, và hỏi rằng ít nhất bạn có thể đồng ý là nó “hữu ích phần nào” hay không.
Mọi người thực ra đã tự dùng code do LLM tạo ra rồi. Có người chia sẻ rằng các PR sử dụng LLM đã đi vào production nhiều tháng nay. Nếu bạn vẫn chưa tìm ra hiệu quả, có thể là vì bạn chưa học được cách tận dụng nó đúng cách.
Khi nhìn những người quảng bá rằng LLM chẳng hiệu quả mấy, tôi có cảm giác như đang chứng kiến marketing vận hành. Những công ty trước đây tôi từng tin tưởng giờ cũng nghiêng hẳn sang quảng bá AI nên thấy khá thất vọng. Nếu thực sự có lợi ích thì cứ trực tiếp dùng thử đi, đại loại là bầu không khí như vậy.
Ví như “người bán cuốc trong cơn sốt vàng”. Thay vì tự chứng minh hiệu quả của công cụ, cấu trúc marketing lại chỉ cố thuyết phục mọi người rằng ngoài kia có mỏ vàng.
Có sự chỉ trích đối với thái độ phớt lờ vấn đề giấy phép code trên Github. Có lập trình viên nói kiểu “đừng bận tâm bản quyền”, nhưng việc mặc định rằng mọi lập trình viên đều là tội phạm thường xuyên xâm phạm bản quyền là một sự khái quát hóa sai. Nhiều người trong chúng tôi, bao gồm cả tôi, không liên quan gì tới việc sao chép lậu quy mô lớn; ngược lại còn cố gắng bảo vệ tinh thần copyleft và mã nguồn mở. Tôi có thể xem SciHub là một lợi ích công, nhưng đồng thời vẫn cho rằng copyleft mà từng nhà phát triển chủ ý lựa chọn cần được tôn trọng. Bản quyền không phải thứ có thể chia đơn giản thành phe ủng hộ hay phản đối. Chính việc phớt lờ sự đa dạng và bối cảnh đó, rồi vơ đũa cả nắm hoặc biện minh cho việc xem nhẹ giấy phép, mới là một thái độ trí tuệ lười biếng.
Lập trình viên thường không hiểu rõ luật, đặc biệt là kiểu common law của Mỹ. Truyền thống pháp luật được viết ra với giả định rằng con người sẽ diễn giải nó một cách hợp lý trong thời gian dài; dù công cụ AI có được thiết kế để phân tán hoặc né tránh trách nhiệm thì cuối cùng pháp luật vẫn sẽ tìm ra người phải chịu trách nhiệm và trừng phạt. Thực tế sau khi cơn sốt AI qua đi có lẽ sẽ là: 1) doanh nghiệp và nhà nước tìm cách phân tán trách nhiệm, 2) xảy ra các sự cố tác dụng phụ như tai nạn xe cộ, thuật toán phân biệt đối xử, rò rỉ dữ liệu, 3) tòa án quy trách nhiệm cho con người và áp phạt hoặc xử lý, 4) các doanh nghiệp khác thấy rủi ro nên bắt đầu hạn chế AI. Trong dòng chảy đó, công cụ AI sẽ chỉ có thể tồn tại trong phạm vi mà trách nhiệm của con người còn bao trùm được.
Tôi đã làm nhà phát triển phần mềm tự do hơn 25 năm và rất yêu thích nhiều loại giấy phép khác nhau. Vợ/chồng tôi là đạo diễn và nghệ sĩ thị giác, nhưng riêng với nội dung liên quan AI thì tôi hoàn toàn không đụng tới và xem đó là rác. Tôi nói rõ là mình không muốn tiếp xúc với nó.
Một thử thách như Konwinski Prize, trao 1 triệu USD nếu LLM mã nguồn mở giải quyết được hơn 90% novel Github issue, khá thú vị. Xem cuộc thi Konwinski Prize. Hiện tại ngay cả model tốt nhất cũng chỉ đạt 0.09 chứ chưa phải 0.9, nên còn rất xa mới dùng được trong thực chiến. Dù mã nguồn mở có thể chỉ kém thương mại đôi chút, việc LLM tự lập trình độc lập vẫn gần như chưa thể. Nó tạo ra rất nhiều rác, nhưng vẫn có ích vì nhu cầu đánh giá và quản lý.
Dù AI có thay bạn làm phần code boilerplate lặp đi lặp lại, thì giờ lại phải lặp đi lặp lại việc review thứ code AI nhàm chán đó; thành ra công việc còn kém vui hơn, thời gian bỏ ra cũng tương tự mà mức độ hiểu lại thấp hơn.
Những người ủng hộ phát triển bằng AI có vẻ rốt cuộc thích review code hơn là viết code. Có thể chỉ là sở thích cá nhân, nhưng bản thân điều đó đã khiến tôi thấy khổ sở.
Nói chính xác thì review một lượng lớn code thường vẫn mất ít thời gian hơn tự viết, nhất là khi code đã pass test. Hơn nữa test code cũng có thể để LLM sinh ra, nên gánh nặng còn giảm thêm.
Claude, Gemini và các công cụ tương tự nhanh hơn nhiều so với việc tôi tự code, và kể cả sau khi xem lại hơn hai lần thì vẫn tốn ít thời gian hơn tự viết.
Trước đây ta viết code cho những việc lặp đi lặp lại kiểu “xén lông yak”, còn bây giờ thì phải ngồi review một màn cạo “yak” qua loa, hời hợt.
Nhìn tổng thể, năng lượng phát thải và lượng carbon lớn hơn là điều khó tránh.
Có đoạn bàn về dịch máy và nhận dạng giọng nói. Từ góc độ một người gần như khiếm thính, tôi dùng công nghệ này suốt cả ngày. Trước đây không thể xem phim truyền hình thập niên 80 mà không có phụ đề, nhưng giờ dùng các LLM như Whisper để lấy phụ đề từ video, và tôi cảm nhận đó là một phép màu biến điều từng chỉ dám tưởng tượng thành hiện thực.
SOTA mới nhất về nhận dạng giọng nói và dịch thuật vẫn đang do các model chuyên dụng cho từng nhiệm vụ dẫn đầu, nhưng khoảng cách đang thu hẹp rất nhanh, trong khi LLM làm được nhiều loại việc hơn nhiều. Có thể xem ví dụ ở bảng xếp hạng nhận dạng giọng nói; LLM đang mở ra khả năng rất rộng.
Suốt nhiều năm tôi đã thử nhiều hệ nhận dạng giọng nói khác nhau như Dragon; tất cả đều gây kinh ngạc nhưng bất tiện khi dùng thực tế. Phải đến khi kết hợp Whisper với LLM thì mới là lần đầu mang lại ích lợi thực sự. Dù vẫn chưa hoàn hảo, lượng phải tự sửa đã giảm xuống còn khoảng một phần mười, đến mức ghi chú cá nhân thì giờ tôi gần như không kiểm tra lại nữa.
Hiện giờ tôi vẫn sẽ không chỉ dựa vào dịch LLM cho các công việc rủi ro cao thật sự, chẳng hạn hợp đồng lao động ở nước ngoài hay lời khai với cảnh sát. Trước đây chuyển giọng nói thành văn bản vốn đã tồn tại; tôi cảm nhận được tiến bộ công nghệ, nhưng nó vẫn chỉ phù hợp với sử dụng thường ngày và rủi ro thấp, còn để dùng như trong tiểu thuyết khoa học viễn tưởng cho các cuộc đàm phán liên hành tinh thì vẫn còn rất xa.
Tôi cũng cảm thấy những tiến bộ gần đây đúng là đang hiện thực hóa các lời hứa từng thấy trong thể loại khoa học viễn tưởng thời thơ ấu. Mấy ngày trước ở một thành phố xa lạ, tôi chụp ảnh menu nhà hàng, trích xuất chữ viết tay tiếng Trung, dịch ngay sang tiếng Anh rồi còn học cách phát âm món mình muốn để gọi. Tôi tin chắc chuyện đó cách đây 2 năm vẫn chưa thể làm được.
Tôi nghĩ dịch thuật chính là lĩnh vực hoàn hảo cho LLM. LLM có thể phản ánh từ khái niệm xã hội, bối cảnh văn hóa, văn hóa đại chúng cho tới các tham chiếu hiếm, và còn tạo ra nhiều bản dịch phù hợp cho các ngôn ngữ cũng như bối cảnh văn hóa khác nhau. Tôi tin rằng nó đã vượt xa dịch thuật truyền thống từ lâu rồi.