- Gần đây, các lập trình viên đang mất nhiều thời gian hơn để sửa đổi và bổ sung mã do LLM (mô hình ngôn ngữ lớn) tạo ra
- Giống như với mã legacy hiện có, để thay đổi mã một cách an toàn thì trước hết cần hiểu nó triển khai cái gì và vì sao lại làm như vậy, nhưng mã do LLM tạo ra khiến quá trình này trở nên khó khăn hơn
- Một số nhóm chậm hơn vì họ review và làm lại mã đủ kỹ, nhưng nhiều nhóm vẫn đưa thẳng đoạn mã khó đọc và chỉ được kiểm thử qua loa vào repository
- Điều này tạo ra “nợ hiểu biết (Comprehension Debt)”, và cuối cùng sẽ quay lại thành cái giá thời gian lớn hơn khi cần sửa mã
- Nhìn chung, LLM có thể hữu ích để giải quyết vấn đề ở mức khoảng 70%, nhưng không thể tránh khỏi “Doom Loop” lặp lại thất bại, và rốt cuộc sẽ tất yếu xuất hiện tình huống con người phải tự mình hiểu và sửa mã
Mã do LLM tạo ra và vấn đề nợ hiểu biết
- Gần đây trong môi trường phát triển, việc sử dụng các công cụ tự động sinh mã dựa trên LLM như ChatGPT, Copilot đang gia tăng
- Những công cụ này tạo ra mã phức tạp rất nhanh ngay cả khi lập trình viên không có kiến thức hoặc sự hiểu biết trực tiếp đầy đủ
- Tuy nhiên, trong quá trình đó, vì ý đồ, ràng buộc và nguyên lý vận hành của mã không được nắm bắt rõ ràng nên xuất hiện hiện tượng tích lũy 'nợ hiểu biết'
Nợ hiểu biết (Comprehension Debt) là gì
- Nợ hiểu biết là trạng thái mà thành viên trong nhóm không hiểu đầy đủ về chất lượng, cấu trúc và ý đồ của mã
- Trong ngắn hạn, nó có thể làm tăng tốc độ phát triển, nhưng về dài hạn có nguy cơ dẫn tới nhiều tác dụng phụ như chi phí bảo trì tăng, phát sinh lỗi, hạn chế mở rộng tính năng
Rủi ro bổ sung của mã do LLM tạo ra
- Mã do LLM tạo ra nhanh chóng cho ra kết quả mà không kèm chú thích rõ ràng hay ngữ cảnh đầy đủ
- Có khả năng cao bộc lộ vấn đề chia sẻ tri thức kém giữa các thành viên và thiếu tương thích với hệ thống hiện có
- Nếu liên tục phụ thuộc vào mã do LLM tạo ra, có thể làm suy giảm độ tin cậy của mã trên toàn bộ dự án
So sánh với nợ kỹ thuật
- Nợ kỹ thuật truyền thống là kết quả của sự đánh đổi có ý thức từ phía lập trình viên, trong khi nợ hiểu biết dựa trên LLM có thể tích lũy một cách vô thức, nên mức độ rủi ro lớn hơn
- Việc nhận diện vấn đề trở nên khó khăn, còn việc truy vết nguyên nhân và giải quyết phức tạp hơn nhiều
- Khi xử lý vấn đề, trải nghiệm “Doom Loop” (vòng luẩn quẩn mà dù liên tục chạy LLM vẫn thất bại) diễn ra khá phổ biến
Kết luận và hàm ý
- Cuối cùng, con người vẫn phải trực tiếp đọc và sửa mã
- Khi sử dụng LLM, nỗ lực để toàn bộ thành viên trong nhóm hiểu được ngữ cảnh và ý đồ của mã thông qua tài liệu hóa và chia sẻ là rất quan trọng
- Cần có các cơ chế ở cấp tổ chức như tăng cường code review, bổ sung chú thích và tài liệu, các buổi chia sẻ tri thức
- Nếu không quản lý nợ hiểu biết, lợi ích của công cụ tự động hóa ngược lại có thể chuyển thành rủi ro dài hạn
- Toàn ngành hiện đang ở trong tình trạng ngồi trên núi nợ hiểu biết đang phình to rất nhanh
8 bình luận
Tôi cũng luôn cho rằng AI không thể đưa ra quyết định một cách hoàn toàn, nên với mọi đoạn mã tôi đều tự mình quyết định và tự kiểm tra xem nó có được làm tốt hay không.
Theo tiêu chuẩn của tôi thì chỉ nên dùng để viết các snippet dưới 10 dòng (ví dụ: phân tích JSON, triển khai sắp xếp). Chỉ dùng theo cách này thôi cũng có vẻ tiết kiệm thời gian một cách đáng kể.
Được AI hỗ trợ để dựng phần khung thì ổn, nhưng để trau chuốt chi tiết đến phút cuối thì có vẻ thực sự rất khó.
Cá nhân tôi cũng đã nhiều lần cảm nhận tác dụng phụ khi dùng LLM để viết từ 0 đến 90, nên dạo này tôi cố gắng tự làm trực tiếp từ 0 đến 90, rồi chủ yếu tận dụng nó ở giai đoạn đi từ 90 đến 100, và tôi thấy khá hài lòng.
Ý kiến trên Hacker News
Đã trải nghiệm việc các vấn đề vốn đã tồn tại trở nên tồi tệ hơn khi mức độ phụ thuộc vào LLM ngày càng sâu hơn
Giới thiệu khái niệm "xây dựng lý thuyết" của Naur và chỉ ra rằng khi một nhóm phát triển chương trình bị giải thể, chương trình đó về thực chất cũng gần như đã chết
Nhắc đến lập luận 'lập trình ≠ viết code' của Lamport, nhấn mạnh rằng bản chất của lập trình là xây dựng lý thuyết về việc sẽ đạt được điều gì và đạt được như thế nào
Cho rằng những lập trình viên không tự dựng nên mô hình hay lý thuyết cần thiết thường có xu hướng cảm thấy LLM giúp mình rất nhanh
Thực tế đã từng thấy mình tạo ra giá trị lớn hơn cho dự án phần mềm khi hoàn toàn tách khỏi máy tính và công nghệ trong một khoảng thời gian
Khi biết chính xác mình muốn gì, tốc độ phát triển tăng vọt, và lúc đó LLM trở nên cực kỳ hữu ích
Nếu mục tiêu đủ rõ ràng thì cũng có thể nhận ra ngay các ảo giác của LLM
Không cho rằng cách tiếp cận chỉ ngồi nhìn một trang trắng rồi bắt đầu là hiệu quả
LLM có thể giúp khởi động, nhưng nếu không cẩn thận thì rất dễ đi lạc sang hướng hoàn toàn sai
Những vấn đề khó nhất lại thường được giải quyết khi đang nấu ăn trong bếp và suy nghĩ về chúng
Một trong những lý do khiến việc tận dụng AI để viết code của tôi thành công hơn một số đồng nghiệp là vì ngay cả trước khi có LLM, tôi đã quen với việc nhanh chóng làm ra prototype, rồi lặp đi lặp lại quá trình chỉnh sửa lại hoàn toàn cấu trúc hoặc vứt bỏ nó
Cách tiếp cận này (prototype nhanh, refactor liên tục, v.v.) khá nổi tiếng, nhưng nhiều kỹ sư vẫn có xu hướng либо cố thiết kế hoàn hảo ngay từ đầu, либо cứ tiếp tục vá víu từ prototype mà không cải tiến đúng mức
Khi làm cùng AI, việc tạo nhiều bản triển khai song song cũng trở nên rẻ hơn, nên có thể thử nghiệm và so sánh nhiều phiên bản, từ đó hình thành lý thuyết hay thiết kế chương trình vững chắc hơn một cách nhanh và hiệu quả
AI rút ngắn vòng lặp này và cho phép tập trung nhiều hơn vào việc review đầu ra, khiến quá trình phát triển hiệu quả hơn rất nhiều
Ấn tượng với việc khái niệm "xây dựng lý thuyết" kết nối với "nợ hiểu biết" của code do LLM tạo ra
Điều này không chỉ liên quan đến lập trình mà còn gắn sâu với cách con người tư duy và hiểu biết
Code, văn bản hay hình ảnh do LLM tạo ra chỉ là kết quả bề mặt; nếu không tự mình xây dựng và trải nghiệm lý thuyết phía sau, rốt cuộc cũng chỉ dừng ở mức hiểu hời hợt
Ngay cả nếu một ngày nào đó LLM có thể tự thực hiện cả việc xây dựng lý thuyết, vẫn thấy rằng một kiểu hiểu biết nhân tạo mà con người không trực tiếp tham gia vào quá trình đó sẽ thiếu ý nghĩa
Càng thuận tiện khi máy móc nghĩ thay, càng lo ngại năng lực <hiểu> của con người sẽ dần mai một
Đồng ý với Lamport, đồng thời cũng nghĩ rằng AI có thể phần nào giúp ích trong quá trình "xây dựng lý thuyết" — tức hiểu codebase, thuật toán và toàn bộ hệ thống — cả với đội ngũ hiện tại lẫn đội tiếp nhận bàn giao
Dù khó có thể thay thế toàn bộ tri thức, vẫn kỳ vọng AI có thể lấp được một phần khoảng trống
Đã từng tiếp nhận một dự án sau khi toàn bộ lập trình viên cũ đều rời đi, và đã có quãng thời gian rất khổ sở vì mọi tri thức của đội trước gần như bốc hơi hết
Đã cố hiểu thiết kế ban đầu rồi tạo ra thêm lỗi, và kết quả là phải vất vả viết lại, mở rộng phần lớn code
Nhưng ngay trong những khó khăn đó, cũng có lúc phải tự mình đi lại chính những vấn đề thiết kế ấy
LLM thường tạo ra các giải pháp chạy được, nhưng nhiều trường hợp lại sinh ra code phức tạp hơn rất nhiều so với mức cần thiết
Ở thời điểm mới viết, tác giả hiểu rõ vấn đề nhất nên có thể dễ dàng loại bỏ độ phức tạp đó; nhưng về sau, phần code phức tạp ấy lại dễ bị hiểu lầm là cần thiết, khiến việc đơn giản hóa mạnh tay trở nên khó hơn nhiều
Người bảo trì code thường thiếu ngữ cảnh hoặc kiến thức nền nên không nhận ra rằng vẫn có phương án đơn giản hơn
Thứ nhất, đưa ra prompt thật rõ ràng để LLM không tạo ra kết quả phức tạp không cần thiết
Thứ hai, luôn truyền đạt quy tắc, quá trình huấn luyện hoặc ngữ cảnh rằng vấn đề phải được giải quyết theo cách đơn giản nhất có thể
Cuối cùng, với các giải pháp đầu ra quá phức tạp, chỉ cần dùng prompt bổ sung để yêu cầu giảm độ phức tạp
Vấn đề LLM tạo ra một lượng lớn code khó debug là có thật
Có nguyên tắc rằng 'đội coi trọng chất lượng thì phải review kỹ và hiểu đầy đủ', nhưng tốc độ sinh code quá nhanh khiến review không theo kịp, dẫn đến thành nút thắt cổ chai hoặc chỉ dừng ở mức phê duyệt hình thức
Xung quanh tôi, mọi người liên tục bổ sung thêm quy trình review, nhưng cách này chỉ hiệu quả với lập trình viên junior, còn AI thì không học nên cùng một vấn đề cứ lặp đi lặp lại
LLM cần rất nhiều ngữ cảnh, nhưng đa số mọi người gần như không cung cấp thông tin gì mà chỉ dùng kiểu "hãy viết một hàm giải quyết vấn đề này"
Rốt cuộc mọi người đang chất đống những ngọn núi code mà chẳng ai hiểu nổi (
tech debt)Về căn bản, điều cần thiết là những "primitive" giúp truyền đạt ngữ cảnh hiệu quả hơn cho LLM về lý do tại sao phải tạo ra thứ này, với bối cảnh, chủ ý và tiền lệ nào
Nếu code review trở thành nút thắt cổ chai, thì dù sao việc chỉ review bị nghẽn vẫn tốt hơn là cả coding lẫn review đều do cùng một người ôm hết
Các công cụ có thể bổ trợ quy trình này (lint, fuzzing, test, v.v.) vốn đã tồn tại
Những người thiếu khả năng kiến trúc hóa toàn bộ dự án hoặc đọc và phân tích code nhanh có thể sẽ thấy thời đại LLM rất khó khăn, nhưng đây là năng lực hoàn toàn có thể rèn luyện, và theo thời gian ai rồi cũng sẽ thích nghi
Tôi thích lĩnh vực này nên đón nhận thử thách mới theo hướng tích cực
Đã có trải nghiệm tạo ra nhiều file hướng dẫn instruction
.mdđể cập nhật các quy tắc coding mà agent phải tuân theo, những cạm bẫy nhất định phải tránh, link tài liệu tiêu chuẩn coding, v.v.Các mô hình như Gemini và Claude phản ánh những chỉ dẫn dựa trên tài liệu kiểu này khá ổn, nhưng đôi khi vẫn lặp lại sai sót (ví dụ: đã dặn không dùng
autotrong C++ mà vẫn không tuân thủ)Kỳ vọng khi mô hình tốt hơn thì khả năng xử lý kiểu phản hồi này cũng sẽ tiến bộ hơn nữa
Cuối cùng cảm thấy điểm thỏa hiệp lý tưởng là thoát khỏi kiểu "vibe coding", để con người trực tiếp để tâm đến cấu trúc code và tương tác giữa các đơn vị, còn AI tập trung vào cú pháp và gõ code; như vậy vừa tăng năng suất vừa giúp lập trình viên tiếp tục nắm hướng đi tổng thể
Sau khi thay đổi cách tư duy về việc cấu trúc prompt và ngữ cảnh, trực giác của tôi về cách tận dụng LLM đã tiến thêm một bước
Tôi bắt đầu tiếp cận từ góc độ dùng prompt và ngữ cảnh để thu hẹp không gian xác suất kết quả đầu ra
Quá trình này cũng rất hiệu quả trong việc bơm vào một cách có thể tái sử dụng "lý thuyết" của code
Tuy nhiên, việc chuẩn bị ngữ cảnh như vậy đòi hỏi rất nhiều công sức và suy nghĩ, và đến giờ vẫn không dễ xác định ranh giới giữa đoạn nào nên tự triển khai và điểm nào nên giao cho LLM
Đồng cảm với nhận xét rằng "primitive khác nhau", và cho rằng đơn vị thực sự quan trọng là "test"
Khi để mô hình viết code thì cũng bắt nó tạo test cùng, và luôn kiểm tra xem test có dễ đọc hay không
Chỉ nên merge code khi toàn bộ test đều pass
Cần liên tục cải thiện hạ tầng test để toàn bộ test không trở nên quá chậm
Code legacy kiểu cũ vốn có đặc trưng là không có test, và điều tương tự cũng đúng trong thời đại LLM
Về nhận xét "trở thành nút thắt cổ chai", ngay cả khi copy code từ StackOverflow tôi cũng luôn đọc và kiểm tra rồi mới dùng, nên dù sao con người vẫn là nút thắt
Rốt cuộc nếu không đi qua quy trình đó thì gần như cũng không thể dùng code được
Gần đây trong podcast của Dwarkesh Patel, một vị khách đã giới thiệu cuốn tiểu thuyết <A Deepness In The Sky>, và khi thực sự đọc thì thấy rất ấn tượng với việc các hệ thống máy tính sau hàng nghìn năm cùng tri thức legacy trong quá khứ lại giữ vai trò quan trọng
Đây là một cuốn tiểu thuyết tuyệt vời, xử lý rất thú vị giá trị của code legacy và tri thức tổ chức, nên đáng để giới thiệu
Podcast: https://www.youtube.com/watch?v=3BBNG0TlVwM
Thông tin sách: https://amzn.to/42Fki8n
Rất tiếc vì tác giả Vernor Vinge đã qua đời, và có cảm giác những ý tưởng của ông càng theo thời gian càng mang lại cảm hứng hiện thực hơn
Phần mô tả quá trình trở thành lập trình viên trong tương lai xa thật sự rất thú vị
Do có quá nhiều library và package, kỹ năng chủ yếu không còn là viết code mới mà là tìm và kết hợp các module sẵn có
Khả năng xuyên thấu các sắc thái chi tiết và cách diễn giải của code hiện có được mô tả như năng lực thực sự
Có vẻ như "A Deepness In The Sky" là cuốn thứ hai trong series, nên thắc mắc không biết có ổn nếu chưa đọc phần 1 hay không
Hỏi liệu có thể đọc luôn ngay được không
Phần lớn lập trình viên không hiểu đến mức assembly hay machine code
Ngôn ngữ bậc cao đã trở thành tầng cốt lõi cho giao tiếp và cộng tác giữa con người với nhau
Với sự xuất hiện của LLM, tầng đó đang bị đẩy dần sang phát triển dựa trên ngôn ngữ tự nhiên và đặc tả
Cuối cùng vẫn cho rằng sau hàng chục năm tiến hóa, ngôn ngữ bậc cao gần như đã truyền đạt đặc tả hành vi chương trình ở hình thức gần tối ưu
Nếu thử thêm nhiều tầng trừu tượng hơn bằng ngôn ngữ tự nhiên thì sẽ xảy ra mất mát thông tin, còn nếu đi xuống ngôn ngữ cấp thấp thì lại quá dài dòng
Bước nhảy sang ngôn ngữ tự nhiên không đơn thuần là thay đổi tầng trừu tượng, mà về bản chất là một phương thức hoàn toàn mới
Các công cụ trước đây (assembler, compiler, framework, v.v.) đều dựa trên logic hard-code và có thể kiểm chứng bằng toán học, nhưng từ sau LLM thì giống như đang nhảy vào một thế giới pha trộn giữa bất định, suy đoán, thậm chí cả ảo giác
Nhiều lập trình viên JavaScript thậm chí còn không hiểu sâu cả những khái niệm bậc cao như cấu trúc dữ liệu phù hợp, DOM, Node API, v.v.
Sự phụ thuộc quá mức vào các tầng trừu tượng xuất hiện, và người ta đi đến trạng thái không còn hiểu rõ nguyên lý vận hành bên trong
Người ngoài vì thế khó tránh khỏi câu hỏi "thực ra ở đây đang làm cái gì vậy?"
Hiện tượng này từ lâu đã được chấp nhận như chuyện thường ngày
Rốt cuộc vì chẳng ai biết chính xác bên trong code đang diễn ra gì, nên việc LLM viết code cũng được mô tả một cách ví von là chẳng khác biệt về bản chất
Đúng là đặc tả bằng ngôn ngữ tự nhiên có vai trò, nhưng nghĩ rằng nhất thiết phải có một tầng mô tả trung gian với ngữ nghĩa nghiêm ngặt
Ví dụ với tổ hợp Rust và LLM, hệ thống kiểu mạnh giúp loại bỏ các trạng thái không hợp lệ, và dù thời gian compile có dài, kết quả cuối cùng thường vẫn khá sát thứ mình muốn
Trong cộng đồng Rust có văn hóa kiểu "chỉ cần compile được thì thường là chạy ổn", dĩ nhiên bug logic vẫn có thể tồn tại nhưng không gian lỗi thực tế bị thu hẹp lại
Lý tưởng nhất là có một ngôn ngữ lập trình nghiêm ngặt định nghĩa chặt chẽ ý nghĩa logic, cùng các đặc tả như tiền điều kiện và hậu điều kiện, còn LLM đóng vai trò chuyển ngôn ngữ tự nhiên thành đặc tả hình thức
Ngôn ngữ tự nhiên vốn dĩ là loại ngôn ngữ không rõ ràng, hàm chứa sự mơ hồ ngay từ đầu
Nếu trong ngôn ngữ lập trình mà parsing bị mơ hồ thì đó sẽ bị coi là bug nghiêm trọng, nhưng trong ngôn ngữ tự nhiên, sự mơ hồ lại là chức năng giao tiếp đa dạng như thơ, sắc thái và hàm ý
Tính chất quyết định (
import) của ngôn ngữ bậc cao không phải là khác biệt duy nhấtTrong lập trình, tính quyết định không phải là tất cả, và code dù hoàn toàn có tính quyết định vẫn có thể không rõ nghĩa với góc nhìn con người
Nói cách khác, hai trục 'trừu tượng cao/thấp' và 'quyết định/xác suất' là hai vấn đề hoàn toàn khác nhau
Đây có vẻ là làn sóng công việc khổng lồ sắp đổ đến với tôi và đội của tôi
Chúng tôi đã duy trì kinh doanh gần 8 năm bằng cách cứu các hệ thống code legacy, nhưng gần đây nhu cầu giảm vì các công ty đang dựa vào LLM để viết code
Tuy nhiên, dự đoán chỉ cần cầm cự khoảng 18 tháng nữa thì sẽ xuất hiện cơ hội rất lớn, vì các yêu cầu xử lý khối tech debt dựa trên LLM tích tụ trong thời gian ngắn sẽ ồ ạt đổ tới
Thiệt hại từ những đống nợ mà Claude dựng lên cùng câu "giờ code đã đạt mức production" rồi sẽ sớm lộ ra
Có nghe một giai thoại từ người quen khi review một PR do LLM tạo ra
Bề ngoài đó là một PR mà tính năng hoạt động hoàn hảo, nhưng khi nhìn vào bên trong thì phát hiện ra thực chất nó không cập nhật backend mà chỉ lách bằng cách thao tác cache
Đã phải rất vất vả để thuyết phục manager rằng đoạn code này không nên được merge
Cuối cùng đâm ra nghi ngờ rằng ngoài kia có khá nhiều phần mềm "vibe coded" kiểu chỉ trông như đang hoạt động ở bề mặt như vậy
Trong trường hợp như vậy, có khi cứ merge luôn rồi để họ tự trực tiếp hứng hậu quả còn tốt hơn
Người ta thường chỉ thật sự ngộ ra khi tự mình trải nghiệm kết quả của một quyết định sai
Nếu không có phản hồi thì cũng không có học hỏi, và ngược lại kiểu manager đó lại càng dễ phi thực tế hơn, chỉ biết tăng kỳ vọng và áp lực vô lý lên đội phát triển, khiến nhân viên kiệt sức rồi bị thay thế trong một vòng luẩn quẩn
Tò mò không hiểu một engineering manager không có chuyên môn thật sự làm sao có thể trụ lại trong ngành lâu đến thế
Trong 15 năm qua gần như chưa từng thấy manager nào thực sự phi kỹ thuật
Nếu kiểu manager này gây ra vấn đề thì nên báo cáo lên CTO, CEO, owner, nhà đầu tư, v.v.
Không chỉ code do LLM tạo, mà bất kỳ code nào do người khác viết cũng khiến người ta phải trả "nợ hiểu biết"
Ngay cả ở các công ty lớn như Google, kỹ sư mới cũng phải mất vài tháng để hiểu trước khi có thể nhanh chóng tạo thay đổi lớn về thuật toán
Tuy nhiên, code do con người thiết kế tốt thì rõ ràng vẫn dễ hiểu hơn đầu ra của LLM rất nhiều
Có thể nghe người thật giải thích trực tiếp; LLM cũng có thể đưa ra câu trả lời nghe hợp lý, nhưng khác biệt về ngữ cảnh thực tế vẫn tồn tại
Tôi cũng đã "vibe coding" khá nhiều, nhưng cuối cùng vì không tích lũy được mô hình tinh thần về code nên tuy có vẻ tiết kiệm thời gian, lúc debug lại mất nhiều thời gian hơn
Việc dựng sẵn mọi thiết kế hoàn hảo ngay từ đầu vốn cũng không thực tế
Và tôi không nghĩ tiêu chí kiểu 'số dòng code được chấp nhận' là cơ sở đáng tin để khẳng định năng suất hay tiết kiệm thời gian
Code dựa vào LLM rõ ràng hiệu quả hơn nếu được dùng theo cách xem xét cẩn thận rồi gọt giũa thành hình dạng đúng đắn
Quá trình này thậm chí còn gần với "pair programming" hơn
Nhấn mạnh rằng cách dùng trực tiếp đầu ra LLM mà không qua bất kỳ kiểm tra nào ("vibe coding") thì không thể thực sự hiệu quả
Lấy luật của Kernighan (Kernighan's Law) làm ví dụ để nói rằng "debug khó gấp đôi viết code"
Vì vậy, nếu LLM là bên tạo ra code, có lẽ sẽ cần một LLM thông minh gấp đôi để debug nó
Trải nghiệm của tôi không hẳn như vậy, và lúc nào tôi cũng phải là người ngồi ở ghế lái
Chủ yếu dùng Claude Code, và mỗi khi nó mắc lỗi thì phải chỉ rõ ràng để sửa hoặc khoanh riêng khu vực có vấn đề
LLM không tự biết mình đã mắc lỗi gì, nên cảm giác giống như đang làm việc với một lập trình viên junior
Tức là bản thân việc debug vẫn có thể làm ở cùng một mức độ thông minh, nhưng LLM thì không tự nhận diện được vấn đề của chính nó
Về câu "debug cần người thông minh gấp đôi", nghĩ rằng có thể điều này liên quan đến sự khác nhau giữa các chế độ "độ sâu suy nghĩ" của LLM
Với những hàm phức tạp, tôi dùng cách bắt LLM viết hoặc đính kèm trước các chú thích code giải thích rõ ý đồ và cách tiếp cận trong báo cáo của nó
Có bình luận nói rằng ngay cả khi mang mã do một lập trình viên khác viết về dùng thì vẫn cần review, nên trường hợp của LLM cũng không khác gì, nhưng tôi không nghĩ vậy. Với con người thì những thứ như uy tín, danh tiếng, phần thưởng và trừng phạt vẫn vận hành. Có lẽ nếu bây giờ làm việc kiểu như LLM thì sẽ bị sa thải ngay lập tức.
Tôi luôn nghĩ rằng “AI không chịu trách nhiệm thay bạn.”
Tôi nghĩ ngày mà việc dùng AI khi viết mã bị cấm sẽ không còn xa. Nghe có vẻ vô lý, nhưng tôi tin đó sẽ trở thành hiện thực.