- Thử nghiệm xây dựng một máy chủ web hoàn toàn không có logic ứng dụng, để LLM xử lý mọi yêu cầu
- Máy chủ chỉ đơn giản nhận HTTP request rồi hỏi LLM “cần làm gì?”, còn lại để LLM tự thực hiện
- Máy chủ chỉ dùng ba công cụ: database, webResponse, updateMemory để thực hiện chức năng CRUD
- LLM tự đảm nhiệm thiết kế schema SQL, tạo HTML·JSON, phản ánh phản hồi để hiện thực một ứng dụng quản lý liên hệ cơ bản
- Tốc độ phản hồi là 30~60 giây, chi phí cao hơn 100~1000 lần so với web app truyền thống, đồng thời tồn tại vấn đề về tính nhất quán UI và khả năng ghi nhớ
- Dù vậy, thử nghiệm vẫn cho thấy khả năng xây dựng một ứng dụng CRUD hoàn chỉnh hoạt động không cần code, gợi ý rằng bản thân code có thể chỉ là một khái niệm mang tính quá độ
Bối cảnh
- Bắt đầu từ một ý tưởng kiểu Shower Thought rằng “đến một lúc nào đó chúng ta sẽ không còn cần phải viết code nữa”
- Trong tương lai, LLM có thể xử lý đầu vào theo thời gian thực và xuất video 120fps, mở ra khả năng điện toán thuần dựa trên ý định, không còn app hay code
- Ngoài đời thực, điều này vẫn còn thuộc lĩnh vực khoa học viễn tưởng, nhưng tác giả quyết định dành một cuối tuần để tự kiểm chứng “công nghệ hiện tại có thể đi đến đâu”
- Giả thuyết của thử nghiệm được đặt ra với kỳ vọng sẽ thất bại
- Trong bối cảnh phần lớn AI đều tập trung vào hướng tạo code (ví dụ: Claude Code, Cursor, Copilot...),
dự án này được tạo ra để kiểm chứng một góc nhìn khác: “nếu bỏ qua hoàn toàn bước sinh code thì sao?”
- Kết quả là một máy chủ HTTP không hề có route, controller hay business logic, nơi mọi request đều được chuyển cho LLM với câu hỏi “cần làm gì?”
- Mục tiêu của thử nghiệm là chứng minh “tương lai đó thực sự còn xa đến mức nào”
Tổng quan dự án
- nokode là một thử nghiệm xây dựng “máy chủ web không có logic ứng dụng”, nhằm kiểm tra cấu trúc nơi mọi request đều được LLM xử lý
- Máy chủ chỉ đơn giản nhận HTTP request rồi hỏi LLM “cần làm gì?”, còn lại để LLM tự thực hiện
- Mục tiêu là xác minh liệu LLM có thể trực tiếp thực thi logic ứng dụng mà không cần sinh code hay không
- Đối tượng thử nghiệm là một ứng dụng quản lý liên hệ (contact manager), bao gồm các chức năng CRUD cơ bản (thêm, xem, sửa, xóa)
Cấu trúc hệ thống
- Backend chỉ gồm 3 công cụ
- database: thực thi SQL trong SQLite, LLM tự thiết kế schema
- webResponse: tạo phản hồi ở định dạng phù hợp như HTML, JavaScript, JSON
- updateMemory: lưu phản hồi người dùng dưới dạng Markdown để tham chiếu ở các request sau
- Ví dụ, request tới
/contacts sẽ tạo trang HTML, còn request tới /api/contacts sẽ tạo phản hồi JSON
- Mỗi trang đều có widget phản hồi, cho phép áp dụng ngay các yêu cầu như “hãy làm nút lớn hơn”, “hãy đổi sang giao diện tối”
Kết quả thử nghiệm
- Về mặt chức năng, thử nghiệm đã hoạt động thành công
- Gửi form, lưu dữ liệu, hiển thị UI, phản hồi API đều hoạt động bình thường
- Ngay cả khi không có ví dụ, LLM vẫn tạo được schema cơ sở dữ liệu phù hợp, SQL an toàn, API kiểu REST, bố cục responsive, kiểm tra form, xử lý lỗi
- Vấn đề hiệu năng
- Mỗi request mất 30~60 giây, chậm hơn 300~6000 lần so với web app thông thường (10~100ms)
- Mỗi request tốn $0.01~0.05, tức đắt hơn 100~1000 lần
- Có tình trạng màu sắc và bố cục UI không đồng nhất, không nhớ được trạng thái trước đó, và nếu sinh SQL sai thì lỗi phát sinh ngay lập tức
- Những nỗ lực tối ưu prompt như “⚡ THINK QUICKLY” thậm chí còn làm chậm hơn
Kết luận và hàm ý
- LLM thực sự có khả năng trực tiếp thực thi logic ứng dụng
- Vấn đề nằm ở các giới hạn hiệu năng như tốc độ, chi phí, tính nhất quán, độ tin cậy
- Tuy nhiên, các giới hạn này thuộc về bài toán cải thiện định lượng hơn là vấn đề định tính
- Tốc độ suy luận tăng khoảng 10 lần mỗi năm
- Chi phí đang có xu hướng giảm
- Khả năng mở rộng độ dài ngữ cảnh có thể cải thiện trí nhớ
- Tỷ lệ lỗi đang có xu hướng giảm
- Kết quả là, “kỷ nguyên AI viết code” có thể còn xa hơn “kỷ nguyên AI trực tiếp thực thi”
- Hiện tại phần còn lại chỉ là code ở cấp độ hạ tầng như cấu hình HTTP, định nghĩa công cụ, kết nối DB,
và về dài hạn, điều này gợi mở khả năng chuyển sang “một nền điện toán chỉ còn ý định và thực thi”
Cách chạy
- Chạy
npm install, sau đó cấu hình nhà cung cấp LLM và API key trong file .env
- Chạy
npm start rồi truy cập http://localhost:3001 (request đầu tiên mất 30~60 giây)
- Có thể sửa
prompt.md để thay đổi loại ứng dụng hoặc chức năng
- Có thể thử nhiều route như
/game, /dashboard, /api/stats
- Nhập phản hồi như “make this purple”, “add a search box” để áp dụng ngay
- Chi phí mỗi request vào khoảng $0.001~0.05 tùy theo model
- Phát hành theo giấy phép MIT
2 bình luận
Vấn đề là điện toán sẽ trở nên nhanh và rẻ đến mức nào.
Nếu trong tương lai, một máy chủ trung bình nhanh hơn hiện tại 100.000 lần mà chi phí vận hành hay chi phí triển khai vẫn giữ nguyên, thì cách đó cũng có thể là hợp lý.
Cũng như khi điện toán trở nên rẻ hơn, chúng ta đã chuyển từ mã máy sang C, rồi từ C sang Node.js hay Python, có lẽ trong tương lai sẽ chuyển sang LLM.
Nhiều thứ sẽ thay đổi, và theo cách riêng thì có vẻ khá thú vị. Cũng sẽ xuất hiện nhiều cơ hội nữa.
Ý kiến Hacker News
Tôi cũng đã nghĩ theo hướng tương tự
Tôi lần đầu nghĩ đến chuyện này khi ChatGPT 3.5 xuất hiện
Một ngày nào đó AI có thể thay thế chương trình hoàn toàn, nhưng cốt lõi thực sự là tìm ra mức trừu tượng hóa (abstraction) phù hợp
Ví dụ, cũng như việc chuyển từ CVS sang Git đã mở ra thời đại microservices, một lớp trừu tượng tốt có thể thay đổi bản chất vấn đề
Để LLM tự khám phá ra những lớp trừu tượng như vậy, nó sẽ phải học thông qua tương tác lâu dài với thế giới thực
Nếu bổ sung công cụ để LLM có thể trực tiếp chỉnh sửa các file mã, tôi nghĩ tốc độ phản hồi và tính nhất quán sẽ được cải thiện đáng kể
Khi đó mã sẽ đóng vai trò như một dạng bộ nhớ lưu trữ (memory)
Gửi trực tiếp yêu cầu HTTP đến LLM thì giống như cache miss, và cũng có thể duy trì một cơ chế phản hồi để kích hoạt cập nhật mã
Vẫn còn nhiều chỗ để tối ưu, nhưng thực tế thì cách viết mã truyền thống có lẽ vẫn hiệu quả hơn
Nghe giống câu hỏi “nếu hành vi phi định tính (non-deterministic) là có thể, thì tại sao lại nhất thiết phải mang tính quyết định?”
Nhưng có lẽ đa số mọi người sẽ không muốn một webapp hoạt động khác nhau mỗi lần dùng
Mã mang tính quyết định có giới hạn khi xử lý các vấn đề phức tạp, và một cách tiếp cận linh hoạt như con người có thể phù hợp hơn
Nhưng trong tương lai, LLM sẽ có khả năng đầu ra và lưu trữ phong phú hơn
Ví dụ, LLM có thể tự tạo liên kết để khi nhấp vào thì nội bộ sẽ truy vấn lại, hoặc vận hành bằng cách quản lý một cơ sở dữ liệu tạm thời
Trải nghiệm người dùng vẫn liên tục thay đổi do cập nhật tự động, A/B testing, thay đổi UX, v.v.
Điều thú vị là cách tiếp cận này hoạt động chỉ với context window, không cần công cụ riêng
Vào tháng 7/2025 tôi đã làm một POC
Thử nghiệm này cho thấy rất rõ “khái niệm mã boilerplate sẽ thay đổi như thế nào”
Nếu chạy nhiều instance cùng lúc trong sandbox và cung cấp kết quả có hiệu suất tốt nhất qua đánh giá nội bộ, thì nó sẽ trở thành một dạng meta reinforcement learning
Tuy nhiên, việc chuyển ý định của người dùng thành đầu ra mang tính quyết định là rất khó, còn ứng dụng truyền thống thì lại thiếu linh hoạt
Cuối cùng, điểm mấu chốt là làm sao triển khai đánh giá ý định (intent evaluation) một cách ổn định
Bản thân việc tạo ra một phương pháp đánh giá tốt cũng phức tạp chẳng kém gì xây dựng mô hình AI
Xử lý yêu cầu theo cách truyền thống hiệu quả về chi phí hơn rất nhiều so với dùng trực tiếp LLM
Ước tính để sinh ra 10 token bằng một mô hình 7 tỷ tham số cần hơn 100 GFLOPs
Rất lãng phí điện năng
Nếu từng làm trong enterprise IT thì sẽ thấy sự kém hiệu quả của con người cũng không hề nhỏ
Thực tế là ngay cả sự kém hiệu quả cũng có thể trở thành xu hướng
Biết đâu chỉ cần đưa LLM lên port 443 rồi bảo “mày là máy chủ HTTPS đồng thời là máy chủ ứng dụng” là xong ;)
Có nhất thiết phải cần webapp không? Chẳng phải chỉ cần trò chuyện với máy tính bằng giọng nói là được sao?
“Cho tôi xem ảnh chụp trong kỳ nghỉ năm ngoái, xóa mây đi rồi gửi cho bạn tôi”
“Đặt bộ đếm giờ tập luyện, bỏ jumping jack đi”
“Tạo cho tôi một nhịp techno kiểu Detroit”
“Tìm cho tôi người hẹn hò tối nay, tôi thích tóc đen”
Tôi hình dung ra một thế giới nơi mọi thứ đều được xử lý bằng lời nói như vậy
Cuối cùng nhân loại có lẽ sẽ chia thành những người chấp nhận nó và những người từ chối nó
Ngay cả hiện tượng đĩa vinyl hồi sinh cũng đã cho thấy dấu hiệu đó
Ngay cả giữa con người với nhau, nhiều khi văn bản vẫn được ưa thích hơn
Nó làm được cả việc cần làm, mua sắm lẫn quản lý lịch trình, và được tùy biến hoàn toàn theo nhu cầu của tôi
Các tác vụ phức tạp có thể được diễn đạt đầy đủ bằng giọng nói, nhưng với những việc đơn giản lặp đi lặp lại thì UI hiệu quả hơn
Ví dụ, khi nói “mua cho tôi một cái quần”, nếu phải chọn một món trong 30 kết quả thì cuối cùng vẫn cần giao diện trực quan
Tôi cũng đã đưa một PoC tương tự lên GitHub
Ban đầu nó dùng một “design model” chậm để tạo theme ứng dụng và schema DB, sau đó dùng model nhanh hơn để xử lý phản hồi
Tôi đã thử dùng PostREST để đưa logic vào DB, nhưng thường xuyên gặp lỗi tạo schema thất bại hoặc sinh truy vấn sai
Tôi dùng thư viện CSS để giữ tính nhất quán cho UI, đồng thời cho nó nhớ trang trước đó
Cách tiếp cận này có thể được dùng như một App Bench để đánh giá liệu LLM có thể tạo ra một ứng dụng hoàn chỉnh chỉ trong một lần hay không