Linus Torvalds dùng Claude Code: chuyện thật sau 8 bản vá

Chào mừng bạn đến với Fx Studio. Bài này đọc kỹ 8 bản vá Linus Torvalds làm cùng Claude Code: AI làm phần nào, Linus giữ phần nào, con số đẹp tới đâu, và vì sao chữ ký cuối cùng vẫn là của người.

Giữa tháng 10/2026, tin Linus Torvalds dùng Claude Code để làm bản vá cho nhân Linux lan khắp các nhóm lập trình. Người từng nói AI là “90% marketing” giờ ngồi làm việc cùng một AI coding agent, nghe là thấy hấp dẫn rồi. Tui cũng làm một video ngắn về chuyện này, và khi viết kịch bản thì vấp ngay một điều: bản nháp đầu tiên có ba chỗ nói quá so với nguồn. Nên bài này đi chậm lại, đọc thẳng commit trong git của kernel và các thư trên danh sách thư Linux Kernel Mailing List (LKML), để xem chuyện thật là gì.

Tóm ý: Linus làm một nhánh thử nghiệm gồm 8 bản vá cho đường đọc page cache, và ghi rõ code, chương trình test, phần rà soát cùng bản nháp mô tả đều làm với Claude Code “dưới sự chỉ đạo của tôi”. Con số đo được rất đẹp nhưng chỉ trên một laptop. Người khác soi vào thì tìm ra lỗi, và nhánh này chưa được merge. Bài học không nằm ở chỗ “Linus dùng AI”, mà nằm ở cách ông dùng: tự đặt bài toán, tự đo, ghi rõ AI làm gì, đem ra cho người khác soi, và tự ký tên.

Chuyện gì đã xảy ra

Vài mốc chính, theo thứ tự thời gian:

• 7–10/10/2026: Linus tạo nhánh noref-filemap-read-with-llm trong cây kernel của ông trên git.kernel.org. Nhánh có 8 bản vá, cộng một commit rỗng ở trên cùng đóng vai thư giới thiệu (cover letter). Tổng cộng sửa 14 file, phần lớn trong mm/.
• 9/10/2026: tại Open Source Summit Europe ở Prague, trong buổi trò chuyện với Dirk Hohndel, Linus nói ông giờ “thật sự thích dùng AI” (ngày này lấy từ hai nguồn tin thứ cấp, tui chưa đối chiếu được với lịch chính thức).
• 13/10/2026: Linus gửi thư “Improve page refcount scalability” lên LKML, kèm bản mới hơn là nhánh rcu-free-v3. Cùng ngày, các kỹ sư khác vào soi và tìm ra lỗi.
• 13/10/2026: Linus nhờ Kiryl Shutsemau tiếp quản cả loạt bản vá, vì ông sắp nghỉ phép rồi phải lo merge window. Kiryl nhận.

Tới ngày 17/10/2026, cả hai nhánh chưa nằm trong nhánh master của Linux, và không có thông báo nào về phiên bản kernel sẽ nhận chúng.

Còn một chi tiết về động cơ, nằm ngay trong thư LKML của Linus: Maintainers Summit năm nay có một chủ đề lớn là dùng LLM trong phát triển kernel, nên ông quyết định thử giải một bài toán khó thật bằng LLM.

“So for the kernel maintainer summit this year, where one of the big topics was going to be LLM use in kernel development, I decided that hey, I will try to actually solve this thing using an LLM”
(Maintainers Summit năm nay có một chủ đề lớn là dùng LLM trong phát triển kernel, nên tui quyết định thử thật sự giải bài toán này bằng một LLM.)

Nghĩa là đây là một thí nghiệm có chủ đích, chọn một bài toán nhiều người đã thử mà chưa xong. Linus còn làm một loạt bản vá thứ hai, “bình thường hơn nhiều”, để phòng khi thí nghiệm này không thành.

8 bản vá giải bài toán gì

Phần này hơi kỹ thuật, nhưng hiểu được nó thì mới thấy vì sao con số phía sau đáng chú ý.

Khi một chương trình đọc file, kernel thường lấy dữ liệu từ page cache, tức vùng nhớ giữ sẵn nội dung file. Mỗi lần đọc, kernel làm ba việc:

• tăng một bộ đếm tham chiếu (refcount) trên trang nhớ, để trang đó không bị giải phóng giữa chừng;
• chép dữ liệu cho chương trình;
• giảm bộ đếm đó xuống.

Một luồng đọc thì không sao. Nhưng khi nhiều luồng cùng đọc một file nhỏ, tất cả cùng ghi vào một bộ đếm, và các nhân CPU phải giành nhau đúng dòng cache chứa nó. Commit chính của Linus tả đúng chỗ đau: mỗi lần đọc phải ghi vào dòng cache của trang hai lần.

Ý tưởng của loạt bản vá là bỏ hẳn bộ đếm ở đường đọc nhanh. Thay vào đó, trang nhớ bị gỡ khỏi page cache sẽ chỉ được trả về bộ cấp phát sau một khoảng chờ của cơ chế RCU (Read-Copy-Update), tức là sau khi mọi luồng đang đọc dở đã xong. Luồng đọc không cần giữ tham chiếu nữa, chép thẳng dữ liệu sang bộ đệm của chương trình. Chữ “noref” trong tên nhánh nghĩa là vậy: đọc mà không cần tham chiếu.

Linus Torvalds dùng Claude Code như thế nào

Đây là phần nhiều bài báo và cả bản nháp kịch bản đầu tiên của tui nói lệch. Câu gốc nằm ở mục “Tools” trong commit giới thiệu của nhánh:

“The code, the test programs, the review behind the list above and the first draft of this text were done with an LLM coding assistant (Claude Code) under my direction. The measurements were run on my machine.”
(Code, các chương trình test, phần rà soát đứng sau danh sách ở trên và bản nháp đầu tiên của đoạn văn này được làm với một trợ lý lập trình LLM (Claude Code) dưới sự chỉ đạo của tôi. Các phép đo chạy trên máy của tôi.)

Đọc kỹ thì thấy hai điều trái với cách kể phổ biến.

Một: AI không chỉ “rà soát hộ”.

• Bản nháp kịch bản của tui ban đầu viết rằng Linus chỉ dùng AI như một cộng sự rà soát, không để nó viết code. Câu gốc nói ngược lại: code cũng làm với Claude Code.
• Phần AI làm gồm cả bốn thứ: code, chương trình test, phần rà soát, và bản nháp mô tả.

Hai: phần của Linus không nằm ở gõ phím.

• Ông chọn bài toán, chỉ đạo hướng giải, chạy phép đo trên máy của mình, đưa ra cho cộng đồng soi, và ký tên chịu trách nhiệm.
• Mỗi bản vá trong 8 bản đều có hai dòng cuối: Assisted-by: LLM (có AI tham gia) và Signed-off-by: Linus Torvalds (người chịu trách nhiệm).

Linus cũng nhận xét nhẹ về chất lượng văn bản AI viết trong thư LKML: commit message “dài dòng hơn một chút so với khi tui tự viết mà không dùng công cụ, nhưng có khi như vậy lại tốt hơn”.

Có một điều nên nói rõ để khỏi suy rộng: Linus không còn là người viết nhiều code kernel. Trong buổi nói ở Prague, ông tự nhận: “I don’t do a lot of kernel programming. I’m a maintainer.” (Tui không lập trình kernel nhiều. Tui là maintainer.) Không có nguồn nào nói ông dùng AI hằng ngày, hay đưa AI vào quy trình rà soát kernel thường lệ. Đây là một thí nghiệm, một nhánh, một bài toán.

Con số đẹp, điều kiện hẹp

Linus ghi điều kiện đo ngay trên đầu bảng số, và đó là phần đáng đọc nhất:

“My laptop only, ext4, mitigations off, CONFIG_HARDENED_USERCOPY off. The laptop throttles on temperature, so compare cost per read, not reads per second.”
(Chỉ trên laptop của tôi, ext4, tắt các biện pháp giảm thiểu lỗ hổng CPU, tắt CONFIG_HARDENED_USERCOPY. Laptop bị hạ xung vì nhiệt, nên hãy so chi phí mỗi lần đọc, đừng so số lần đọc mỗi giây.)

Máy đo là laptop Intel Core i7-8565U (4 nhân, 8 luồng). Bài test: đọc 16 byte ở đầu một file chỉ dài một trang, mỗi luồng một file descriptor.

Linus tóm lại: với 8 luồng, “three times the reads, for a quarter of the cycles” (gấp ba số lần đọc, với một phần tư số chu kỳ). Một luồng thì gần như không đổi, đúng như mong đợi, vì bài toán chỉ nằm ở chỗ nhiều luồng tranh nhau.

Có hai chỗ hay bị đọc lệch:

• Chưa đo trên máy lớn. Linus viết thẳng “nothing bigger has been measured” (chưa đo trên máy nào lớn hơn). Ông đoán máy nhiều CPU sẽ được lợi hơn, nhưng đó là dự đoán.
• Con số “gấp 23 lần” là của bài test nhân tạo. Ở bản rcu-free-v3, Linus thấy hiệu năng tăng 23 lần trên máy Ryzen Threadripper, nhưng ông nói ngay đó là một trường hợp “very artificial” (rất nhân tạo): đọc đi đọc lại cùng một phần nhỏ của trang trong vòng lặp trên mọi CPU, nên “any real life impact will be much much less” (tác động ngoài đời thật sẽ nhỏ hơn rất, rất nhiều).

Người viết bản vá tự ghi giới hạn của con số mình đưa ra. Riêng chi tiết này đã đáng học.

Người khác soi vào và tìm ra lỗi

Phần này ít được nhắc, nhưng tui thấy nó quan trọng nhất.

Linus gửi thư lên LKML ngày 13/10. Ngay trong ngày:

• Kiryl Shutsemau tìm ra một race condition trong hàm filemap_read_rcu_batch(): nếu trang nhớ bị thay bằng trang mới rồi kích thước file tăng lên đúng lúc đó, luồng đọc có thể đọc ra “data that never got written there” (dữ liệu chưa từng được ghi vào đó). Kiryl cũng là người trước đó tìm ra một workload làm bản đầu tiên giữ quá nhiều bộ nhớ chờ giải phóng tới mức hệ thống phải giết tiến trình vì hết RAM, và chính điều này dẫn tới bản rcu-free-v3.
• Matthew Wilcox, người lo phần lớn mã folio của kernel, viết: “Obviously the numbers are compelling” (Rõ ràng con số rất thuyết phục), rồi nói ngay ông không thích cờ PG_rcu_free mới, và đề xuất một cách khác.

Linus trả lời góp ý, rồi nhờ Kiryl tiếp quản cả loạt vì ông sắp nghỉ phép và phải lo merge window. Kiryl đồng ý.

Nếu chỉ đọc tít “Linus dùng AI viết kernel”, mình dễ nghĩ AI đã làm xong một việc khó. Câu chuyện thật thì khác: AI giúp một người rất giỏi đi nhanh tới một lời giải đáng thử, rồi những người giỏi khác soi ra chỗ sai trong vòng vài giờ. Lưới an toàn vẫn là con người và quy trình review công khai của kernel.

Chữ ký vẫn là của người

Kernel Linux có luật riêng cho đóng góp có AI tham gia, viết trong Documentation/process/coding-assistants.rst. Câu quan trọng nhất:

“AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO).”
(AI agent KHÔNG ĐƯỢC thêm dòng Signed-off-by. Chỉ con người mới có thể chứng nhận Developer Certificate of Origin (DCO) về mặt pháp lý.)

Người gửi bản vá phải tự rà soát toàn bộ code AI sinh ra và chịu toàn bộ trách nhiệm về đóng góp đó. Một tài liệu khác, generated-content.rst, nói gọn hơn: người gửi phải hiểu và bảo vệ được mọi thứ mình gửi lên.

Dòng Assisted-by cũng đang được bàn lại. Ngày 9/10/2026, Sasha Levin gửi bản vá đề xuất bỏ các nhắc tới tag này khỏi tài liệu. Bản v2 (13/10) ghi rằng khoảng 10% trong 18.533 commit (không tính merge) của Linux 7.3 tới -rc7 có tag Assisted-by, và tại Maintainers Summit có “strong, though not unanimous, consensus” (đồng thuận mạnh, dù không tuyệt đối) để bỏ nó. Tới 17/10, bản vá này chưa được merge, nên chưa thể nói Linux đã bỏ tag. Còn luật về Signed-off-by thì không ai đề xuất đổi.

Trong cùng chuỗi thảo luận, có người đề xuất bắt buộc commit message phải tự tay viết. Linus phản đối kiểu luật “không được dùng AI cho việc X”, và nói những người ông nể là “not the ones that shy away from using new and interesting tools” (không phải những người né tránh công cụ mới và thú vị). Ông bảo vệ quyền dùng công cụ, nhưng không bảo vệ việc đẩy trách nhiệm sang công cụ.

Từ “90% marketing” tới “thích dùng AI”

Tháng 10/2024, cũng ở Open Source Summit Europe (lần đó ở Vienna), Linus nói AI lúc ấy là “90% marketing và 10% thực tế”. Hai năm sau, ở Prague, ông nói: “I used to think it was just not very good — but now I’m at the point where I actually really like using AI.” (Tui từng nghĩ nó chưa tốt lắm, nhưng giờ tui tới mức thật sự thích dùng AI.)

Đổi ý là chuyện thật, nhưng đọc hết buổi nói thì thấy ông đổi ý có điều kiện:

• Dùng như công cụ: “I think AI is a wonderful tool if you use it correctly and treat it as a tool” (AI là công cụ tuyệt vời nếu dùng đúng cách và coi nó là công cụ).
• Dùng cho chỗ mình yếu: ông lấy ví dụ dùng AI làm giao diện cho dự án pedal guitar của mình, “the things that I’m bad at” (những thứ tui làm dở).
• Cẩn thận với việc thật: “you need to be very careful using AI when you’re doing something real and important” (cần rất cẩn thận khi dùng AI cho việc thật và quan trọng).
• Nhìn thấy cái giá: bản vá do AI hỗ trợ tìm lỗi đang làm code base tốt lên, nhưng “it is also stressing maintainers out to the point that it’s a problem” (nó cũng làm các maintainer căng thẳng tới mức thành vấn đề).

Theo ZDNet, khoảng ba phần tư buổi thảo luận ở Maintainers Summit hôm trước xoay quanh việc làm cho chuyện sinh và review bản vá AI bớt căng thẳng. Tức là ngay trong nhóm người hào hứng nhất, câu hỏi chính đã chuyển từ “có nên dùng không” sang “review sao cho xuể”. Chuyện code rẻ đi thì điểm nghẽn dời sang khâu review, tui đã viết kỹ hơn ở bài Code rẻ đi thì điểm nghẽn dời về đâu?.

Đọc tin này sao cho khỏi lệch

Từ một commit tới một kịch bản video lan truyền, câu chuyện phình ra qua từng lớp. Tui ghi lại đúng những gì đã xảy ra với chính bản nháp của mình:

Vài câu nghe rất hợp lý mà không có nguồn nào đỡ:

• “Linus dùng AI hằng ngày” / “AI đã vào quy trình rà soát kernel”: không có nguồn. Đây là một thí nghiệm, chuẩn bị cho Maintainers Summit.
• “Linus chỉ dùng AI để rà soát, không cho viết code”: ngược với câu gốc của ông.
• “Bản vá đã vào kernel” hay “sẽ vào bản 7.4”: chưa merge, không có phiên bản đích.
• “Nhanh gấp 23 lần”: chỉ đúng với một bài test mà chính Linus gọi là rất nhân tạo.
• “Linux đã bỏ tag Assisted-by”: mới có đồng thuận và một bản vá đề xuất, chưa merge.

Cách tui dùng để tránh các câu trên khá đơn giản: tìm tới câu gốc (commit, thư LKML, tài liệu trong cây kernel), đọc điều kiện đo đi kèm mỗi con số, và tách sự kiện ra khỏi diễn giải.

Mang về team mình được gì

Đây là phần diễn giải của tui, không phải lời của Linus. Nhìn vào cách ông làm, tui rút ra năm thói quen mà team nào dùng AI coding agent cũng áp được ngay:

1. Tự chọn bài toán và hướng giải. AI làm phần lớn việc gõ, nhưng câu hỏi “giải cái gì, theo hướng nào” vẫn do người đặt.
2. Tự đo, và ghi điều kiện đo. Con số không kèm điều kiện thì chưa nên đưa vào PR hay báo cáo.
3. Ghi rõ AI đã làm phần nào. Một đoạn như mục “Tools” của Linus giúp người review biết phải soi chỗ nào kỹ hơn.
4. Đưa ra cho người khác soi. Lỗi race trong loạt bản vá này do người khác tìm ra, không phải do AI tự rà.
5. Người ký là người chịu trách nhiệm. Ký tên dưới code AI viết nghĩa là mình hiểu và bảo vệ được nó.

Chỗ bài này có thể sai

• Ngày nói ở Prague (9/10) dựa trên hai nguồn tin thứ cấp, chưa khớp với lịch chính thức của sự kiện.
• Câu “90% marketing” năm 2024 tui đọc qua bài tường thuật, chưa xem video phỏng vấn gốc.
• Tình trạng merge và tag Assisted-by tính tới ngày 17/10/2026. Kernel thay đổi nhanh; đọc bài muộn thì nên kiểm lại.
• Năm thói quen ở mục trên là suy luận của tui từ một ca duy nhất, không phải kết luận nghiên cứu.

Tạm Kết

Tin “Linus Torvalds dùng AI” dễ đọc thành một trong hai câu chuyện: hoặc AI đã đủ giỏi để viết kernel, hoặc người giỏi nhất cũng đã đầu hàng công cụ. Đọc tới commit thì thấy câu chuyện thứ ba, bình thường hơn mà đáng học hơn.

Một người rất hiểu bài toán dùng Claude Code để đi nhanh hơn. Ông ghi rõ AI làm gì, tự đo trên máy mình, ghi luôn giới hạn của con số. Rồi ông đưa ra cho cộng đồng soi, và cộng đồng tìm ra lỗi trong ngày. Bản vá chưa vào kernel. Chữ ký dưới mỗi bản vá vẫn là tên một con người.

AI viết bản vá, nhưng người vẫn ký tên. Phần ký tên đó mới là phần khó, và nó không tự nhỏ lại khi AI viết code nhanh hơn.

Nguồn

• Linus Torvalds, nhánh noref-filemap-read-with-llm (commit giới thiệu 4c0f3697118e, các commit 7–10/10/2026) và nhánh rcu-free-v3 — git.kernel.org/torvalds/linux
• Linus Torvalds, “Improve page refcount scalability”, LKML 13/10/2026 — lkml.iu.edu
• Kiryl Shutsemau, race trong filemap_read_rcu_batch(), LKML 13/10/2026 — lkml.iu.edu
• Matthew Wilcox, góp ý về PG_rcu_free, LKML 13/10/2026 — lkml.iu.edu
• Linus Torvalds nhờ Kiryl tiếp quản — lkml.iu.edu; Kiryl nhận — lkml.iu.edu
• Linus Torvalds về luật “không dùng AI cho X”, LKML — lkml.iu.edu
• Linux kernel, Documentation/process/coding-assistants.rst — GitHub mirror
• Sasha Levin, “[PATCH] docs: remove Assisted-by references” (9/10/2026) — lkml.iu.edu; bản v2 (13/10/2026) — lkml.iu.edu
• Steven J. Vaughan-Nichols, ZDNet, buổi nói của Linus Torvalds tại Open Source Summit Europe 2026, Prague — zdnet.com
• Computerworld, “Linus Torvalds has started using AI to develop the Linux kernel” (14/10/2026) — computerworld.com
• Câu “90% marketing” (Open Source Summit Europe 2024, Vienna) — Boing Boing

Cảm ơn bạn đã đọc bài viết này!

Written by chuotfx

Hãy ngồi xuống, uống miếng bánh và ăn miếng trà. Chúng ta cùng nhau đàm đạo về đời, về code nhóe!