Cách Oxide sử dụng LLM

• Mô hình ngôn ngữ lớn (LLM) đang thay đổi căn bản cách làm việc, và Oxide đã xác định rõ cách sử dụng chúng trong tổ chức
  • Oxide là một startup hạ tầng điện toán theo nhu cầu, xây dựng phần cứng và phần mềm tích hợp cho các trung tâm dữ liệu on-premises
• Oxide đưa ra các nguyên tắc cốt lõi khi sử dụng LLM là trách nhiệm, tính chặt chẽ, sự đồng cảm, tinh thần đồng đội và sự cân bằng với tính khẩn trương
• LLM hữu ích trong việc tóm tắt và hiểu tài liệu, review mã, gỡ lỗi, nhưng khi viết văn bản hay viết mã, phán đoán và trách nhiệm của con người là điều bắt buộc
• Với mọi đầu ra do LLM tạo ra, luôn phải duy trì cơ chế để con người rà soát và chịu trách nhiệm
• Oxide khuyến khích sử dụng LLM, nhưng với tiền đề là trách nhiệm đối với sản phẩm, khách hàng và đồng nghiệp

---

Các tiêu chuẩn giá trị khi sử dụng LLM

• Oxide đánh giá việc sử dụng LLM theo các giá trị cốt lõi của tổ chức
  • Trách nhiệm (Responsibility): LLM chỉ là công cụ, và trách nhiệm đối với kết quả hoàn toàn thuộc về con người
  • Tính chặt chẽ (Rigor): nếu dùng cẩn trọng, LLM có thể giúp mài giũa tư duy; nhưng nếu bất cẩn, nó sẽ làm giảm chất lượng tư duy
  • Sự đồng cảm (Empathy): cần nhận thức rằng cả người viết lẫn người tiếp nhận ngôn ngữ đều là con người, và phải duy trì giao tiếp lấy con người làm trung tâm
  • Tinh thần đồng đội (Teamwork): cần cẩn trọng để việc dùng LLM không làm tổn hại niềm tin giữa các đồng nghiệp, và việc công khai chuyện sử dụng không bị nhìn nhận như cách né tránh trách nhiệm
  • Tính khẩn trương (Urgency): dù có thể tăng tốc, cũng không được hy sinh các giá trị khác

Các cách sử dụng LLM khác nhau

LLMs as Readers

• LLM đặc biệt giỏi trong tóm tắt tài liệu và hỏi đáp, giúp hiểu nhanh một lượng lớn tư liệu
• Tuy nhiên, phải đảm bảo quyền riêng tư dữ liệu, và cần cấu hình để tài liệu tải lên không bị dùng cho việc huấn luyện mô hình
• Đây là công cụ hữu ích để hỗ trợ hiểu tài liệu, nhưng không được thay thế những tình huống cần tự đọc trực tiếp

LLMs as Editors

• LLM hiệu quả trong việc cải thiện cấu trúc và văn phong của tài liệu đã hoàn thiện, và đặc biệt hữu ích ở giai đoạn cuối
• Tuy nhiên, LLM có xu hướng phản hồi quá tích cực, nên có thể thiếu phân tích phản biện
• Nếu dùng ở giai đoạn viết nháp, có nguy cơ làm mất đi giọng văn riêng của người viết

LLMs as Writers

• Văn bản do LLM tạo ra thường sáo mòn hoặc để lộ rõ dấu vết của nội dung được tạo tự động
• Nội dung được tạo tự động có thể làm tổn hại tính chân thực trong tư duy và niềm tin của người đọc
• Người đọc mặc định rằng người viết đã hiểu nội dung, nhưng văn bản do LLM viết làm sụp đổ tiền đề đó
• Oxide giả định mọi thành viên đều có năng lực viết, nên không dùng LLM làm chủ thể viết
• Tuy vậy, vẫn có thể dùng ở mức hạn chế như công cụ hỗ trợ sắp xếp ý tưởng

LLMs as Code Reviewers

• LLM hữu ích trong việc phát hiện một số loại vấn đề mã cụ thể, nhưng không thể thay thế review của con người
• Vì đề xuất có thể phi logic hoặc bỏ lỡ ngữ cảnh, nên chỉ nên dùng như công cụ hỗ trợ

LLMs as Debuggers

• LLM có thể được dùng như một “rubber duck” gợi mở ý tưởng gỡ lỗi
• Khả năng giải quyết vấn đề thực tế còn hạn chế, nhưng lại hữu ích như tác nhân kích thích để nghĩ ra cách tiếp cận mới

LLMs as Programmers

• LLM có năng lực sinh mã rất mạnh, phù hợp cho việc viết mã mang tính thử nghiệm hoặc hỗ trợ
• Càng gần với mã sản phẩm, việc kiểm chứng và trách nhiệm càng quan trọng
• Mã do LLM viết phải được chính người viết tự rà soát (self-review), và bắt buộc phải kiểm tra trước khi đưa cho đồng nghiệp review
• Trong quá trình review mã, cấm xử lý bằng cách tái sinh toàn bộ, vì như vậy sẽ không thể review lặp lại
• Ngay cả khi sinh mã, vẫn phải duy trì trách nhiệm, tính chặt chẽ, sự đồng cảm và tinh thần đồng đội

Vận hành và hướng dẫn

• Các chi tiết kỹ thuật và hướng dẫn nội bộ cho việc sử dụng LLM được tổng hợp trong tài liệu nội bộ trên GitHub
• Oxide khuyến khích sử dụng LLM, nhưng với tiền đề là sử dụng có trách nhiệm
  • Ý thức trách nhiệm đối với chất lượng sản phẩm, niềm tin của khách hàng và sự hợp tác giữa đồng nghiệp được đặt lên hàng đầu

[GN⁺]

Ý kiến trên Hacker News

• Bài viết của Bryan cho thấy một góc nhìn cân bằng và thực tế
  Tôi nghĩ việc Oxide không tuyển kỹ sư junior là lý do nội dung liên quan không xuất hiện trong RFD
  Bryan là một kỹ sư đã làm việc với phần mềm và phần cứng khó trong hơn 30 năm, và có kinh nghiệm hoàn thành một “chương trình thực sự khó (OS)”
  Cách ông ấy làm việc với LLM rất khác so với một kỹ sư junior của năm 2025
  Có lẽ các junior ngày nay hầu như chưa từng code mà không có sự trợ giúp của LLM

  • Trước đây đã có thời tôi ở công ty chỉ làm mô hình cho data ingest suốt nhiều tháng
    Chán đến mức đi làm cũng thấy nặng nề, còn bây giờ có lẽ chỉ mất vài phút với LLM
    Nghĩ lại thì lượng thời gian đã đổ vào đó gần như điên rồ
  • Tôi nhớ trong buổi học web design đầu tiên, giáo viên đã dạy cả học kỳ bằng Notepad về “các nguyên lý nền tảng” của HTML, CSS, JS
    Chỉ sau đó mới giới thiệu Dreamweaver, và năng suất tăng lên gấp mười
  • Sự căng thẳng giữa “tinh thần thủ công vs tính thực dụng” của LLM rất thú vị
    Trong những lĩnh vực có kết quả rõ ràng như nghiên cứu bảo mật, LLM rất xuất sắc, nhưng lại yếu với các vấn đề đòi hỏi phán đoán tinh tế
    Vì vậy lý tưởng nhất là giao phần lặp lại và có tính hệ thống cho LLM, còn phần cần phán đoán thì để con người đảm nhiệm
  • Tôi đã lập trình hơn 20 năm, và từng có một sự kháng cự vô hình với việc dùng LLM
    Nhưng giờ tôi đã chấp nhận rằng đây là “một cách lập trình mới”, và khi nhận ra điều đó, tôi lại có cảm giác như trẻ ra
  • Tôi thấy buồn cười vì ngay sau cụm “những người nhận ra dấu vết của LLM” lại xuất hiện em-dash (—)
    Dạo này cứ dùng em-dash là dễ bị hiểu lầm là bài do AI viết, điều đó khá khó chịu

• Khi đọc RFD của Oxide, tôi đồng ý với hầu hết nội dung, nhưng không đồng ý với phần nói rằng “LLM viết code tốt ngay từ đầu”
  LLM rất hữu ích để giải quyết “hội chứng trang trắng”, nhưng tôi nghĩ code thực sự để triển khai còn cách rất xa kết quả nó tạo ra
  Đây có thể là một “ảo giác về tiến bộ”

  • Viết là biểu đạt cá nhân, còn code là công cụ giải quyết vấn đề
    LLM học từ những “lời giải tốt” xuất hiện nhiều trong dataset nên mạnh ở việc giải quyết vấn đề
    Ngược lại, biểu đạt của con người vốn dĩ cốt lõi là sự đa dạng, nên cách diễn đạt trung bình sẽ trở nên nhạt nhẽo
    Cuối cùng, LLM có thể làm hạn chế năng lực giải các vấn đề chưa có lời giải
    Tôi cho rằng lý do chất lượng code thấp là do giới hạn context window
  • Văn viết sáo mòn thì dở, nhưng code sáo mòn lại thường là tốt
  • Phản bác kiểu “hãy thử model khác” giờ khiến tôi cảm thấy giống “No True Scotsman” trong thế giới LLM
    Sinh code ở mức hàm thì ổn, nhưng giao cả một tính năng thì cấu trúc và interface thường trở nên lộn xộn
    Nếu ví với viết lách thì mức phù hợp là chỉ đưa câu đầu và câu cuối của một đoạn rồi để nó điền phần còn lại
  • Điều này giống hiện tượng ta dễ nhận ra lỗi trong tin tức về lĩnh vực mình quen thuộc, nhưng lại tin nguyên xi ở lĩnh vực mình không biết
    Lập trình viên có thể đánh giá chất lượng code, nhưng với viết lách thì không hẳn như vậy
  • Chất lượng LLM khác nhau tùy model
    Nhiều người có ấn tượng xấu vì đã dùng model cũ hoặc rẻ tiền

• Tôi nghi ngờ nhận định rằng “LLM phân biệt tốt văn bản do LLM tạo ra”
  Không rõ điều đó đã được chứng minh bằng dữ liệu hay chưa

  • Bryan của Oxide đã trực tiếp giải thích
    Quy trình tuyển dụng của công ty thiên về viết lách, nên gần đây số lượng hồ sơ do LLM soạn tăng mạnh
    Họ đã cảnh báo trong RFD 0003 và trang tuyển dụng, nhưng chuyện đó vẫn tiếp diễn
    Tập podcast cũng đề cập các trường hợp liên quan
    LLM không bắt được toàn bộ văn bản AI tạo ra, nhưng vẫn hữu ích như công cụ hỗ trợ phát hiện trong các trường hợp đáng ngờ
  • Có người đề xuất một cách phân biệt văn bản do LLM tạo: đưa một nửa văn bản vào LLM rồi cho nó dự đoán phần còn lại để so sánh xác suất n-token
    Dù chưa thử nghiệm, đây vẫn là một hướng tiếp cận thú vị
  • Vì mức độ LLM can thiệp có thể khác nhau (viết toàn bộ, tóm tắt, biên tập...), nên việc phát hiện trở nên khó khăn
    Tôi nghĩ với công nghệ hiện tại, không thể phân biệt hoàn hảo

• Khi dùng code do LLM tạo, trách nhiệm thuộc về kỹ sư
  Code mà bản thân chưa tự rà soát thì không thể đem đi review
  Quy trình của tôi như sau:

  1. nhập code liên quan → 2) mô tả mục tiêu → 3) review thiết kế → 4) sinh code → 5) test và chỉnh sửa → 6) đọc kỹ toàn bộ code và chỉnh tay
     Bước cuối là khó nhất, và về mặt cảm xúc rất dễ muốn bỏ qua
     Cách này giúp duy trì tư duy ở cấp độ kiến trúc đồng thời giảm bớt việc lặp đi lặp lại
     Nhưng LLM là phi quyết định, nên khác với công cụ có tính dự đoán như compiler
  • Thực tế, bước 6 chiếm phần lớn tổng thời gian
    Nếu code không hoạt động đúng thì còn phải sửa nhiều hơn
    Vì thế tôi không chắc LLM có thực sự tiết kiệm thời gian hay không
  • Có thể thêm một bước trước bước 4 là cho nó sinh test code trước, rồi để nó sửa từ trạng thái fail sang pass
  • Nếu thay vì chỉnh tay mà để LLM chủ động dẫn dắt mọi thay đổi, nó có thể giữ được tính nhất quán tri thức trong suốt session
  • Làm vậy lại có cảm giác làm tổn thương lòng tự trọng và cảm giác sở hữu của kỹ sư
    Rất khó đầu tư cảm xúc vào việc gọt giũa thứ code do máy tạo ra

• Thật lạ khi không thấy nhắc đến khả năng vi phạm bản quyền của code do LLM tạo ra
  Code trên GitHub có thể bị sao chép nguyên xi, và đây là vấn đề quan trọng với các công ty mã nguồn mở

  • Nếu sản phẩm do LLM tạo ra không thuộc đối tượng bản quyền, thì địa vị pháp lý của code theo giấy phép Copyleft sẽ trở nên mơ hồ
    Cần có đủ đóng góp của con người thì bản quyền mới hình thành, nhưng tiêu chuẩn đó lại không rõ ràng
  • Tôi tò mò không biết những vấn đề như vậy đã từng được đưa ra tòa chưa
  • Cũng không rõ các LLM mới nhất còn gây ra chuyện này hay không, hoặc liệu chúng có làm thế thường xuyên hơn con người không

• Tài liệu được tổ chức tốt, nhưng đoạn nói rằng “dùng LLM như công cụ hỗ trợ đọc thì không sao” lại có vẻ mâu thuẫn
  Nếu nó hoàn hảo thì chẳng khác gì bản gốc, còn nếu không hoàn hảo thì sẽ có rủi ro đọc sai
  Thực tế tôi thường thấy LLM không đọc tài liệu tử tế mà chỉ nhìn mục lục rồi suy luận
  Có nguy cơ xuất hiện một lớp phiên dịch giữa nội dung và người đọc

  • Tôi nghĩ RFD này không nói về “đọc” mà về kỳ vọng xã hội đối với “viết”
  • Nếu cho nó so sánh ba cuốn sách kỹ thuật rồi ra kết quả sai, thì đó là thất bại trong cách dùng công cụ
    Phải tự đưa toàn bộ văn bản trực tiếp vào context window
    Dù vậy, toàn bộ nội dung của ba cuốn sách có thể đã vượt quá giới hạn của LLM

• Tôi đồng cảm với nhận định rằng “văn bản do LLM tạo ra làm tổn hại cả tính chân thực của tư duy”
  Văn bản do con người trực tiếp viết có giá trị, còn thứ do LLM viết giống như bản sao bị pha loãng giá trị
  Câu nói rằng thà đọc prompt còn hơn thật sự rất ấn tượng

  • Nghệ thuật của con người thể hiện nội tâm cá nhân, còn LLM là sản phẩm của giá trị trung bình tập thể
    Những ý tưởng thú vị và độc đáo nằm ở những điểm lệch khỏi giá trị trung bình
    Tôi hiểu việc dùng LLM trong những trường hợp như dịch thuật để người không phải bản ngữ diễn đạt suy nghĩ của mình tốt hơn,
    nhưng người nhận sẽ bắt đầu nghi ngờ liệu cách diễn đạt đó có thực sự là suy nghĩ cá nhân hay không
  • Điều đó khiến tôi nhớ đến “Programming as Theory Building” của Naur
    Comment là nỗ lực diễn đạt bối cảnh mang tính lý thuyết không nằm trong code
    LLM không thể có kiểu “lý thuyết” này, nên không thể tạo ra những comment thực sự có giá trị
  • Tôi ghét “văn phong AI” đặc trưng của LLM, nhưng nhiều người lại không nhận ra điều đó
    Chẳng hạn phần lớn bài đăng trên /r/SaaS trông như do LLM viết,
    nhưng vẫn rất giỏi trong việc gợi phản ứng của người đọc bằng storytelling giàu cảm xúc
    Tôi cũng dùng LLM để viết tài liệu và benchmark
    Nó cũng hữu ích khi người không phải bản ngữ viết tài liệu kỹ thuật, nhưng chất lượng dao động rất lớn
    Rốt cuộc, trong viết lách để truyền đạt thông tin, LLM đang ngày càng trở nên hữu ích
  • Câu “tôi muốn đọc prompt” cũng là điều tôi thường nghĩ khi nhìn tiêu đề tin tức
    Điều tôi tò mò không phải là đã viết gì, mà là vì sao lại viết nó
  • LLM dự đoán tốt những câu trung bình, nhưng gần như không đoán nổi những câu sáng tạo
    Vì thế, dù suy nghĩ của tôi có thể không độc đáo, việc nó hiếm về mặt thống kê vẫn đem lại chút an ủi

• Tôi cho rằng văn bản viết bằng LLM không đáng để đọc
  Tôi thích việc Oxide đặt ra nguyên tắc cứng rắn là không dùng LLM cho các đầu ra không phải code
  Với code review cũng vậy, code được sinh ra phải do chính tác giả kiểm tra trước
  Dù còn phải xem văn hóa đó có thực sự được duy trì hay không, định hướng này vẫn là khôn ngoan

• Có nhận thức mạnh rằng LLM được huấn luyện trên dữ liệu bị chiếm dụng,
  nên tôi nghĩ lẽ ra tài liệu phải tính đến nhận thức phổ biến này
  Dù là vấn đề đạo đức hay rủi ro thương hiệu, hiện tại đây rõ ràng là một yếu tố quan trọng

  • Tôi xem tài liệu này là văn bản kỹ thuật nội bộ chứ không phải dành cho công chúng
    Mục đích của nó là đưa ra hướng dẫn kỹ thuật hơn là thể hiện lập trường đạo đức
  • Có vẻ như điều bài viết gọi là “sự sụp đổ của niềm tin” chính là cách diễn đạt khác của vấn đề đó
    Văn bản do LLM tạo ra đánh mất tính chân thực, và người đọc sẽ cảm thấy ngay cả suy nghĩ ấy cũng đã bị tự động hóa
    Rốt cuộc nó có thể làm tổn hại niềm tin giữa con người với nhau

• Câu “viết là lao động trí tuệ lớn hơn đọc” khá thú vị
  Nhưng với code thì tôi lại thấy ngược lại

  • Một bài viết tệ thì vô dụng, nhưng code tệ chỉ cần chạy được là vẫn có thể đóng Jira ticket
    Vì vậy mới có nhiều code dở hơn hẳn
    Ngược lại, code viết tốt có giá trị học hỏi rất lớn và đòi hỏi sự thấu hiểu như văn chương
  • Có người trích dẫn định luật Kernighan
    “Debug khó gấp đôi việc viết code.
    Vậy nên nếu khi viết bạn cố tỏ ra thông minh hết mức, thì việc debug sẽ trở thành bất khả thi.”
    liên kết laws-of-software.com