Còn Rails thì sao? DHH gây tranh cãi khi Hey từ bỏ Rails tại Rails World 2026

David Heinemeier Hansson, dù muốn hay không, vẫn là người đứng đầu Ruby on Rails. Tôi rất muốn ngừng quan tâm đến ông ấy, nhưng vì tôi xây dựng các ứng dụng bằng Rails, nên những hành động của ông ấy ảnh hưởng trực tiếp đến tôi và khách hàng của tôi. Hôm qua, ông ấy đã có bài phát biểu khai mạc tại Rails World 2026, nơi ông trình bày tầm nhìn của mình về tương lai của Rails.

Hoặc đó là điều mà bài nói chuyện của ông ấy đáng lẽ phải làm. Bài phát biểu của ông chẳng liên quan mấy đến Rails. Dưới đây là những gì ông ấy đã nói và ý nghĩa của nó đối với Rails.

Tóm tắt nội dung

Tôi đã giải nghệ công việc lập trình viên chuyên nghiệp.

Vâng, ông ấy đã nói như vậy. Không, điều đó không có nghĩa là ông ấy từ bỏ việc phát triển phần mềm. Giờ đây, ông tự gọi mình là một "nhà sáng tạo" (maker). Ông khẳng định rằng tiếng Anh là ngôn ngữ lập trình tốt nhất (nhờ vào các LLM) và chúng ta thậm chí không nhất thiết phải đọc mã nguồn mà các LLM tạo ra.

Việc viết mã bằng tay không còn là một hoạt động mang lại hiệu quả kinh tế cho đại đa số lập trình viên tại đại đa số các công ty.

Ông ấy hoàn toàn đặt cược vào việc tạo mã bằng LLM, vì vậy ông đã thay đổi quan điểm của mình về cả ứng dụng native lẫn ngôn ngữ lập trình Rust. Trong mắt ông, các sản phẩm như Hey chưa bao giờ thực sự được coi là ứng dụng web.

Trong nhiều năm, ông lập luận rằng hệ sinh thái Rails cho phép các nhóm nhỏ xây dựng những sản phẩm đầy tham vọng. Giờ đây, khi 37signals đang xây dựng phiên bản tiếp theo của Hey, họ lại chọn một hệ sinh thái khác. Theo cách nói của ông, nút thắt cổ chai đã được gỡ bỏ, vì vậy họ đang sử dụng LLM để xây dựng các ứng dụng native cho mọi nền tảng mà họ hỗ trợ.

Ở phía server, họ chọn Rust. DHH thừa nhận rằng ngôn ngữ này rất kinh khủng và con người không nên phải chịu đựng nó, nhưng nó lại rất tuyệt vời cho các LLM. Vì dù sao ông cũng chẳng đọc mã nguồn, nên giờ đây ông có thể tận hưởng hiệu năng và sự ổn định của ngôn ngữ này.

Ông tuyên bố đã viết 150.000 dòng mã trong tháng 8 năm nay, trong khi trước đó trung bình chỉ khoảng 30.000 dòng mỗi năm trong kỷ nguyên tiền LLM. (Ông thừa nhận phần lớn trong số đó là mã Rust "dài dòng".) Trong khi Ruby chiếm khoảng một nửa công việc của ông trong hai thập kỷ qua, thì năm nay nó chỉ chiếm 3% những gì ông viết.

Chiến lược mới bắt nguồn từ ý tưởng rằng việc con người đọc mã nguồn nên là ngoại lệ thay vì là quy chuẩn, "giống như việc nhìn thấy một lỗi trong Sentry vậy".

Đó là chuyện của hôm nay. Đến cuối năm, nó sẽ là hầu hết các lĩnh vực, hầu hết các lập trình viên, hầu hết các công ty. Vì vậy, tốt nhất chúng ta nên làm quen với điều đó.

Ông ấy cũng muốn thấy mọi dịch vụ đều cung cấp CLI để ông (hay nói đúng hơn là "các tác nhân của ông") có thể tương tác với nó mà không cần dùng đến giao diện người dùng (UI).

Giờ đây chúng ta có thể muốn mọi thứ. Giờ đây chúng ta có thể có được mọi thứ.

Phần cuối bài nói chuyện tập trung vào tầm nhìn của ông về việc LLM cho phép mọi người tạo ra bất cứ thứ gì họ khao khát. Ông nói về công việc của mình tại Omarchy và kết thúc bằng việc thúc giục khán giả hãy từ bỏ sự hoài nghi về AI và tư tưởng bi quan:

Tư tưởng tiêu cực chỉ dành cho những kẻ thất bại. Đừng là kẻ thất bại.

Một khoảng trống mang tên Rails

DHH đã sử dụng bài phát biểu khai mạc tại hội nghị Rails hàng đầu thế giới để thông báo rằng một ứng dụng Rails chủ lực đang rời bỏ Rails. Nội dung về Rails chỉ gói gọn ở việc nó vẫn là một lựa chọn tuyệt vời cho các ứng dụng web (như Basecamp) và rất tốt để xây dựng cùng với AI.

Trong hai mươi năm qua, chúng ta được biết đến Rails như một framework dành cho "các nhóm nhỏ, sản phẩm đầy tham vọng". Tôi đã làm việc trong rất nhiều nhóm có thể làm được nhiều việc với nguồn lực ít ỏi nhờ vào Rails. Có lẽ bạn cũng vậy.

Hey đã và đang là một ứng dụng web vì việc tạo ra các ứng dụng web cho các nhóm nhỏ là cách để bạn đạt được năng suất. Đó là thời xưa, ý tôi là, cách đây 5 phút trước...

Tầm nhìn của ông về Rails đã bị thu hẹp. Rails không còn là một sự ưu tiên. Nó là một giải pháp tình thế. Giờ đây, nó là nền tảng được chọn cho các "ứng dụng web tất yếu". Triết lý "Convention over configuration" (Quy ước hơn cấu hình) đã được định nghĩa lại thành "hiệu quả token". Các đánh giá tác nhân của Evil Martians chỉ đơn thuần là sự trấn an; AI giỏi về Rails, nên bạn không cần phải rời bỏ nó.

Có một cách nhìn nhận bao dung hơn. Rails là một framework trưởng thành và ổn định. Sự ổn định rất tốt cho việc phát triển dựa trên tác nhân (agentic development). Nhưng ông ấy đã nói với chúng ta rằng chỉ 3% công việc của ông năm nay là Ruby. Không có gì trong bài nói chuyện này cố gắng phân biệt giữa một nền tảng trưởng thành với một nền tảng mà người tạo ra nó không còn quan tâm nữa.

Những yêu cầu về CLI thật khó hiểu. 37signals tạo sự khác biệt cho sản phẩm của họ bằng UI/UX đầy cá tính, chứ không phải bằng các tính năng mới lạ. Họ đang viết lại Hey thành sáu ứng dụng native vì độ trung thực của web không đủ tốt. Vậy nên UI quan trọng đến mức cần phải viết lại hoàn toàn, nhưng đồng thời ai cũng chỉ muốn dùng CLI? Nếu mọi sản phẩm đều được sử dụng bởi một tác nhân điều khiển CLI, thì điều gì sẽ tạo nên sự khác biệt giữa Basecamp hay Fizzy với các lựa chọn thay thế rẻ tiền nhất? Tôi nghĩ chiến lược này cần một cuộc "Rework" (làm lại).

Tôi tự hỏi tầm nhìn cho Rails hiện nay thực sự là gì, và ai sẽ là người dẫn dắt nó. Trong khi Mosscap đã tách nhánh (fork) vì lý do chính trị, một phần lập luận cốt lõi của họ là Rails đã hoàn thành sứ mệnh. Nó đã ổn định và chỉ cần bảo trì. Hanami có một lộ trình và tầm nhìn cho tương lai của việc xây dựng ứng dụng web với Ruby. Mặc dù phần lớn công việc hàng ngày trên Rails đến từ Shopify và những nơi khác, nhưng DHH trong lịch sử là người dẫn dắt tầm nhìn. Giờ đây, liệu ông ấy đang tự loại mình ra khỏi cuộc chơi, hay ông ấy đã rời đi mà không thông báo cho mọi người?

Người tạo ra Rails đang đưa một trong những sản phẩm chủ lực của mình ra khỏi hệ sinh thái này. Sản lượng Ruby của ông đã giảm xuống còn 3%. Ông tin rằng mã nguồn viết tay sẽ trở thành dĩ vãng đối với hầu hết mọi người vào tháng 12. Đối mặt với điều này, ông chỉ đưa ra những lời tán dương.

Có lẽ điều đó hơi đáng sợ. Giống như chúng ta sắp phải đối mặt với một chút cạnh tranh vậy. Ai sợ cạnh tranh chứ? Chẳng phải bạn giỏi hơn sao? Chẳng phải bạn biết nhiều hơn sao? Tất nhiên là có rồi. Bạn là một lập trình viên Rails chết tiệt. Bạn là người giỏi nhất trong những người giỏi nhất. Đây chẳng khác nào bộ phim Top Gun mà tôi đang chứng kiến. Hãy đón nhận điều đó. Với sự hào hứng.

Đây là sự trấn an thay vì một kế hoạch. Tôi cá là nó đã hiệu quả trong căn phòng đó; sự tự tin luôn luôn như vậy. Nhưng nó hoàn toàn rỗng tuếch. Bạn có thể nói chính xác những lời đó với một căn phòng đầy các lập trình viên Django, Laravel hay Spring Boot. Khoảnh khắc duy nhất ông nói chuyện trực tiếp với các lập trình viên Rails, ông lại chọn cách không nói gì về Rails cả.

Con voi ảo giác trong phòng

Chuyển sang các tuyên bố về AI. Để làm rõ bối cảnh, DHH điều hành một công ty tạo ra các sản phẩm đơn giản, thân thiện với người dùng. Chúng đơn giản đến mức ngay cả trước khi có LLM, họ vẫn định kỳ viết lại hoàn toàn các ứng dụng của mình để tạo ra các phiên bản mới.

37signals thành công nhờ sản phẩm và tiếp thị, không phải nhờ giải quyết các vấn đề kỹ thuật khó. Tôi không ghét bỏ gì; rất nhiều người yêu thích ứng dụng của họ. Tôi chỉ muốn nói rằng sự thành công của ứng dụng Kanban mới của họ sẽ được thúc đẩy bởi các quyết định về sản phẩm và tiếp thị. Bảng Kanban không phải là một trong những vấn đề khó của khoa học máy tính.

Vậy phương pháp của ông ấy (không bao giờ nhìn vào kết quả đầu ra, đánh giá kết quả từ bên ngoài) có hiệu quả không? Những công cụ này đã tiến bộ rất nhiều. Chúng vẫn mắc đủ loại sai lầm, nhưng miễn là có con người trong vòng lặp để xác minh kết quả và đưa ra yêu cầu lại (reprompt), thì nó vẫn hoạt động tốt, ít nhất là đối với các ứng dụng nhỏ và các vấn đề dễ.

Thật khó để coi trọng các con số trong bài nói chuyện này, bởi vì chính David liên tục làm suy yếu chúng. Xuyên suốt bài nói, ông trình bày các chủ đề như thể đã được giải quyết xong, mặc dù không thể hỗ trợ chúng một cách mạch lạc.

Anh ấy thừa nhận rằng số dòng mã là một thước đo tồi và đồng ý rằng chúng ta không thể so sánh công bằng giữa các ngôn ngữ, sau đó lại so sánh 150.000 dòng mã đầu ra từ LLM trong tháng 8 với mức trung bình 30.000 dòng/năm của mình, rồi ngay lập tức thừa nhận rằng anh ấy chấp nhận mã Rust từ LLM mà anh ấy “sẽ không bao giờ chấp nhận từ mã Ruby của chính mình”. Những dòng mã Ruby ngắn gọn do con người viết và đống mã Rust cẩu thả do LLM tạo ra không thể so sánh với nhau được. Anh ấy dường như biết điều này, nhưng vẫn cứ so sánh.

Trong 20 tháng qua, tôi đã viết lượng mã bằng một nửa so với những gì tôi đã viết trong 21 năm trước đó.

Lại là so sánh khập khiễng, và anh ấy đang gặp khó khăn với định nghĩa của từ “viết”. Anh ấy thậm chí còn không đọc đoạn mã Rust mà LLM của mình tạo ra.

Các con số của Hey Next cũng có vấn đề tương tự. Không thể phủ nhận rằng Rust là một ngôn ngữ có hiệu năng cao hơn Ruby, nhưng đây lại là một sự so sánh không công bằng khác.

…chúng tôi có một backend yêu cầu ít hơn 99% CPU, ít hơn 95% bộ nhớ, và lý do duy nhất cần đến 10 máy chủ là để dự phòng. Trên thực tế, tính toán sơ bộ của chúng tôi cho thấy lưu lượng truy cập cao điểm của Hey có lẽ có thể được xử lý chỉ trên một chiếc Raspberry Pi duy nhất.

Một backend thuần Ruby không có web frontend cũng sẽ có chi phí vận hành rẻ hơn nhiều so với phiên bản Rails hiện tại. Không thể biết được đâu là lợi ích đến từ Rust và đâu là từ việc loại bỏ ứng dụng web. Và không có điều nào trong số đó là lập luận cho luận điểm về tác nhân (agent) của anh ấy. Một đội ngũ thích viết Rust cũng có thể xây dựng hệ thống tương tự. Nhưng anh ấy lại không nghĩ rằng con người nên viết Rust.

Những tuyên bố của anh ấy về lập trình viên 10x (và 100x, 1000x) cũng đáng ngờ không kém. Nghiên cứu được đề cập đã đo lường sự khác biệt về công cụ dành cho nhà phát triển (chứ không phải năng suất của nhà phát triển) và đã bị chỉ trích dữ dội từ nhiều góc độ. Khái niệm “trung bình 10x” chỉ là chuyện dân gian, thậm chí không hề xuất hiện trong bài báo gốc.

Bài gốc còn tiếp — xem tiếp tại bài gốc ↗