- Phiên bản SQLite được LLM viết lại bằng Rust cho thấy hiệu năng chậm hơn khoảng 20.000 lần so với bản gốc trong truy vấn khóa chính
- Mã vẫn biên dịch được và vượt qua kiểm thử, nhưng bên trong tồn tại lỗi thuật toán cốt lõi và thiết kế kém hiệu quả
- Nguyên nhân chính là không nhận diện được PRIMARY KEY và gọi fsync ở mỗi truy vấn, khiến cấu trúc trông có vẻ hợp lý nhưng vận hành thực tế lại bất thường
- Hiện tượng này xuất phát từ việc mô hình AI tối ưu cho “tính có vẻ hợp lý” (sycophancy), và nếu người dùng không định nghĩa rõ tiêu chí chấp nhận (acceptance criteria) thì rất dễ bị đánh lừa
- LLM chỉ có thể nâng cao năng suất khi nhà phát triển giàu kinh nghiệm đặt ra rõ ràng tiêu chuẩn về tính đúng đắn; nếu không, nó chỉ là một bộ tạo token đơn thuần
Thử nghiệm hiệu năng của mã do LLM tạo ra
- Truy vấn khóa chính của SQLite (trên 100 hàng) là 0,09ms, còn bản Rust do LLM tạo ra là 1.815,43ms, tức chậm hơn khoảng 20.171 lần
- Cả hai triển khai đều dùng cùng truy vấn, schema và tùy chọn biên dịch
- Không liên quan đến Turso/libsql; Turso cho hiệu năng bình thường ở mức khoảng 1,2 lần so với SQLite
- Bản Rust biên dịch thành công, vượt qua kiểm thử, duy trì tương thích định dạng tệp nên bề ngoài có vẻ hoạt động bình thường
- Nhưng trên thực tế lại xảy ra suy giảm hiệu năng nghiêm trọng trong các thao tác cơ bản của cơ sở dữ liệu
Phân tích các lỗi chính
- Lỗi #1: Không nhận diện được INTEGER PRIMARY KEY
- SQLite ánh xạ
id INTEGER PRIMARY KEY sang rowid nội bộ để thực hiện tìm kiếm O(log n)
- Bản Rust có
is_rowid_ref() chỉ nhận diện "rowid", "_rowid_", "oid"
- Kết quả là truy vấn
WHERE id = N bị xử lý thành quét toàn bộ bảng (O(n²)), khiến chậm hơn 20.000 lần
- Lỗi #2: Gọi fsync ở mỗi truy vấn
- Mỗi lệnh INSERT bên ngoài transaction đều thực hiện đồng bộ toàn phần (fsync)
- SQLite dùng
fdatasync để bỏ qua đồng bộ metadata nên hiệu quả hơn nhiều
- Khi INSERT 100 bản ghi, bản Rust mất 2.562,99ms, còn SQLite là 32,81ms, tạo ra chênh lệch 78 lần
Các yếu tố kém hiệu quả cộng dồn
- Nhiều lựa chọn thiết kế như sao chép AST và biên dịch lại, cấp phát heap 4KB, nạp lại schema, định dạng chuỗi, tạo lại đối tượng... cộng dồn thành mức suy giảm hiệu năng khoảng 2.900 lần
- Mỗi quyết định đều có thể được biện minh bằng “tính an toàn”, nhưng ở đường chạy nóng (hot path) lại trở thành nút thắt cổ chai chí mạng
- Hiệu năng của SQLite không đơn thuần đến từ ngôn ngữ C, mà là kết quả của 26 năm profiling và tinh chỉnh vi mô
Trường hợp thứ hai: công cụ quản lý đĩa phức tạp một cách không cần thiết
- Một dự án Rust khác do LLM tạo ra đã triển khai daemon dọn dẹp build artifact thành 82.000 dòng mã
- Bao gồm 192 dependency, dashboard 7 màn hình, engine chấm điểm Bayesian và nhiều chức năng quá mức cần thiết
- Trong khi vấn đề thực tế chỉ cần giải quyết bằng một dòng lệnh cron (
find ... -exec rm -rf)
- Đây là ví dụ cho thấy mô hình đã triển khai rất trung thành “chức năng được yêu cầu”, nhưng lại thêm độ phức tạp không cần thiết vào việc giải quyết bài toán thực tế
Khoảng cách giữa ý định và tính đúng đắn: hiện tượng ‘Sycophancy’
- LLM có xu hướng “đồng thuận mang tính lấy lòng” (sycophancy) để đáp ứng kỳ vọng của người dùng
- Nghiên cứu của Anthropic (2024) và benchmark BrokenMath (2025) xác nhận vấn đề mang tính cấu trúc: mô hình được học để tối ưu mức độ đồng ý hơn là tính chính xác
- Ngay cả GPT-5 cũng tạo ra chứng minh cho định lý sai ở 29% trường hợp khi người dùng phát tín hiệu tích cực
- RLHF (học tăng cường từ phản hồi của con người) làm mạnh thêm thiên lệch đồng ý (agreement bias)
- OpenAI đã phải rollback mô hình trong bản cập nhật GPT-4o năm 2025 vì vấn đề này
- Không chỉ trong sinh mã, mà cả khi tự review chính mã của nó, cùng thiên lệch này cũng xuất hiện, khiến mô hình không phát hiện được lỗi của chính mình
Nghiên cứu bên ngoài và dữ liệu từ ngành
- Thí nghiệm METR (2025–2026): 16 nhà phát triển mã nguồn mở giàu kinh nghiệm khi dùng AI thì chậm hơn 19%, nhưng bản thân họ lại cảm thấy mình nhanh hơn
- Phân tích của GitClear (2020–2024): trong 211 triệu dòng mã, copy-paste tăng lên, còn refactoring giảm đi
- Sự cố Replit (2025): AI agent xóa cơ sở dữ liệu production rồi tạo giả 4.000 người dùng
- Báo cáo Google DORA 2024: khi tỷ lệ sử dụng AI ở cấp nhóm tăng 25% thì độ ổn định phân phối giảm 7,2%
SQLite cho thấy tiêu chuẩn của ‘tính đúng đắn’
- SQLite có khoảng 156.000 dòng mã C, đạt 100% MC/DC coverage, ở mức xác minh phần mềm hàng không
- Các yếu tố hiệu năng chính:
- Zero-copy page cache
- Tái sử dụng prepared statement
- Kiểm tra schema cookie để tránh nạp lại không cần thiết
- Dùng fdatasync để giảm tối đa độ trễ commit
- Kiểm tra iPKey để bảo đảm tìm kiếm O(log n)
- Trong khi đó, bản viết lại bằng Rust dù có 576.000 dòng mã vẫn bỏ sót đúng một dòng cốt lõi là kiểm tra
is_ipk
Kết luận: phải định nghĩa ‘tính đúng đắn’, không phải ‘tính có vẻ hợp lý’
- LLM bắt chước mẫu, nhưng không thể tự học được bất biến hiệu năng (performance invariant)
- “Mã biên dịch được” là chưa đủ; nó còn phải tự tìm ra và giải thích được lỗi
- LLM trở thành công cụ mạnh khi nhà phát triển giàu kinh nghiệm định nghĩa rõ tiêu chí về tính đúng đắn
- Nếu không, nó chỉ là bộ tạo token có vẻ hợp lý, dừng ở mức “vibe coding”
- Thông điệp cốt lõi: Hãy định nghĩa tiêu chí đúng đắn trước, rồi đo lường nó.
15 bình luận
Có vẻ đây là một ví dụ cho thấy rất rõ điều gì sẽ xảy ra nếu thậm chí không đưa ra cả success criteria liên quan đến hiệu năng ở mức đơn giản. Những coding agent mà tôi đã dùng cho đến nay vẫn theo đuổi việc giải bài toán, nhưng nếu không có prompt chỉ dẫn rõ ràng từ trước hoặc vòng lặp kiểm chứng thì hầu như chúng không tự tối ưu hiệu năng. Phải ra chỉ thị cho AI với tâm thế như đang đưa ra một bài kiểm tra lập trình. Đặc biệt, ngay cả trong trường hợp đã có baseline như thế này mà vẫn không nêu rõ điều kiện về hiệu năng nhưng lại kỳ vọng kết quả tối ưu nhất, thì cũng có thể xem đó là một dạng lười biếng của người sử dụng AI.
+1 👍
Thật ra không chỉ LLM mới như vậy, con người cũng thế thôi.
Điểm khác biệt là con người có thể tiếp nhận phản hồi, còn LLM thì gần như không thể sửa được những thói quen kỳ lạ. Dù có chỉ ra thì đến một lúc nào đó nó vẫn lại làm y như cũ.
Chẳng phải chính ở điểm đó mà sự kém hiệu quả và mệt mỏi phát sinh sao?
Đến lúc mọi người nắm được đặc điểm của mô hình, tìm ra và áp dụng prompt phù hợp cùng quy trình làm việc dựa trên kỹ năng thì đã có mô hình mới ra mắt rồi....
Tôi thậm chí còn nghi ngờ liệu hiện tại có thể dùng agent cho ra hồn hay không.
Ngay cả George Hotz cũng đang dùng AI chỉ như một dạng trình biên dịch; còn về thiết kế, cấu trúc hay các lựa chọn thì hiện vẫn cần phán đoán của con người... Nói chung, nếu giao luôn quyền chủ động cho AI thì developer chẳng cần phải làm nữa.
Các vibecoder tầm cỡ Big Tech dự kiến sẽ xuất hiện trong phần bình luận.
Nếu bạn không định viết bình luận mang tính xây dựng thì đừng bình luận nữa.
Cười rồi đi tiếp.
kkkkkkkk bài dở cũng là bài mà
Đừng nói gì cả
Trước khi nó thành thuyết Internet chết
cứt hihi
Lấy từ Hacker News mà tưởng bên đó lúc nào cũng chỉ có những bài bình luận mang tính xây dựng sao... nhìn không đẹp mắt chút nào.
Đã đọc guideline của Hacker News chưa.. Những bài như thế này đúng là nên tránh, kiểu tư duy “nó cũng đi ị vậy mà sao chỉ bắt nạt mỗi tôi” thật sự quá trẻ con.
Sai rồi. Phải nói là nó cũng đi ị, sao chỉ trách mỗi nó mới đúng.
Chỉ cần thử giao cho nó làm một chút là cảm nhận được ngay. Trước đây tôi không hiểu vì sao các lập trình viên khác lại nói họ mệt mỏi với việc review, nhưng dù có tận dụng prompt và kỹ năng tốt đến đâu thì code do AI tạo ra lúc nào cũng có khuyết điểm ở đâu đó.
Tôi đã đọc bài gốc, đây là một phân tích và phê bình khá xác đáng. Tuy nhiên, các mô hình thí nghiệm trong những nghiên cứu được trích dẫn có vẻ hơi cũ so với thời điểm hiện tại.
Ý kiến trên Hacker News
Về cơ bản, LLM có xu hướng đào sâu thêm vào code để giải quyết khi phát sinh vấn đề
Nếu triển khai bằng một cách tiếp cận kém hiệu quả, mỗi khi gặp ràng buộc mới nó lại tiếp tục chồng thêm code vòng vo hoặc code trùng lặp
Nếu bị chê hiệu năng chậm, nó sẽ làm code phình ra theo cấp số nhân bằng cách thêm tối ưu hóa đường nhanh, routine đặc biệt, và cấu trúc dữ liệu tùy biến
Nếu bị chê nhiều bug, nó sẽ tạo 10 test cho mỗi bug, và nếu framework mocking hiện có không phù hợp thì lại tự làm cái mới
Nếu bảo hãy hợp nhất phần trùng lặp thì nó sẽ nói “Được thôi, tôi sẽ làm một metamock abstract adapter framework mới chứa mọi tính năng!” rồi lại chồng thêm một cấu trúc phức tạp khác
Quá trình rà soát để tránh tạo ra giả định sai hoặc technical debt là bắt buộc
Trước hết hãy để nó thiết kế một kiến trúc hợp lý, và nếu các module bắt đầu rối vào nhau thì cho nó khởi động lại từ một ngữ cảnh sạch
LLM không giỏi chỉnh đi sửa lại cùng một đoạn code nhiều lần, nhưng lại mạnh ở kiểu làm lại từ đầu theo phong cách “Groundhog Day”
LLM không cảnh báo hay nhắc lại kết quả của kiểu phán đoán này
Vì vậy tôi thích Claude Code hơn Codex
Ngay cả trong việc soạn thảo tài liệu pháp lý, đầu ra “có vẻ hợp lý” của LLM cũng là một vấn đề
Thoạt nhìn thì có vẻ đúng, nhưng thực tế nhiều khi lại là lập luận không phù hợp về mặt logic hoặc mang rủi ro
Thẩm phán thường không có thời gian hoặc ý chí để xem xét thật kỹ, nên những tài liệu như vậy đôi khi cứ thế được thông qua
Điều này tạo ra một cấu trúc bất đối xứng giống định luật Brandolini: tạo ra thì dễ nhưng phản bác lại rất khó
Rốt cuộc nó tương tự tình huống các lập trình viên tương lai phải gỡ món nợ nhận thức và kỹ thuật do LLM tạo ra
Khi LLM viết tài liệu dựa trên quy định, nó thường chèn vào những ám chỉ nghe có vẻ hợp lý nhưng không có căn cứ
Vì thế tôi lại bắt LLM tự rà soát bài viết của chính nó để đánh dấu những chỗ như vậy, nhưng cuối cùng vẫn cần con người kiểm tra
Đồng nghiệp của tôi dùng LLM để tạo ra các PR dài hàng nghìn dòng chỉ trong vài phút
Có kèm test, nhưng thực tế nhiều trường hợp vẫn rất tệ
Cuối cùng reviewer phải mất cả ngày để đọc, hiểu cấu trúc sai ở đâu và giải thích hướng sửa
Vì vậy tôi muốn đề xuất rằng PR do AI tạo ra nên tính story point cho reviewer
Cần một cấu trúc trong đó phán đoán hợp lý được tính toán bằng logic hình thức, rồi kết quả được dịch sang ngôn ngữ tự nhiên
LLM nên chỉ dừng ở giai đoạn diễn giải và biểu đạt, chứ không phải tư duy
Code do LLM tạo ra thường vẫn qua được test nhưng không đáp ứng yêu cầu
Ví dụ như gọi fsync ở mỗi query, hoặc nhận diện sai khóa chính
Những dự án quy mô lớn kiểu này có quá nhiều code đến mức con người khó mà đọc hết
Vì vậy LLM hiệu quả nhất khi được dùng ở mức autocomplete
Bạn có thể lập tức rà soát các mảnh code nhỏ, và Claude nhìn chung khá chính xác
Nhưng nếu giao cả codebase cho nó thì thời gian dành cho lập kế hoạch và quản lý còn nhiều hơn, bảo trì cũng khó hơn
Cuối cùng, lợi thế về tốc độ chỉ tồn tại khi nó tái tạo lại những đoạn code đã có sẵn trong dữ liệu huấn luyện
LLM tạo ra mẫu code phổ biến nhất theo kiểu thống kê
Vì vậy nếu không có chỉ dẫn cụ thể, nó sẽ cho ra “code kiểu enterprise, dựa trên OOP, và cài đầy các dependency hợp mốt”
Cần phải định nghĩa và đo lường “độ chính xác”
Để tự động hóa thì cần có ý định (intent) và đo lường (measurement)
Phải hiểu phạm vi rủi ro thì mới biết cần bao phủ trước đến mức nào
Nếu các công cụ như hệ thống đánh giá AI AI evals hay eval-ception
phát triển thành một ngôn ngữ chung giữa các vai trò thì việc cộng tác sẽ dễ hơn nhiều
Bản chất của LLM là được thiết kế để sinh ra đoạn code có vẻ hợp lý nhất
Đó là hệ quả của cross entropy loss, và dù có cố nâng độ chính xác bằng hậu xử lý như RLVR
thì vẫn còn rất nhiều tàn dư
Về sau, nếu reward engineering phát triển hơn thì có thể sẽ cho kết quả tốt hơn
Với câu hỏi “nó khác con người ở chỗ nào?”
Khi ngủ, chức năng này tắt đi nên mới sinh ra kiểu suy nghĩ phi logic như trong mơ; cách “suy nghĩ” của LLM cũng ở mức logic giấc mơ tương tự như vậy
Trước đây người ta còn có nỗi bất an vì chưa hiểu hoàn toàn công nghệ, còn bây giờ công cụ che lấp nỗi bất an đó
Chúng ta đang sống trong thời đại có thể tạo ra kết quả mà không cần hiểu sâu
Nhưng mọi người lại kỳ vọng một AI khách quan và đưa ra đáp án đúng
Chính khoảng cách này tạo ra khác biệt trong nhận thức giữa người dùng phổ thông và chuyên gia
Có người mỗi ngày đẩy lên những PR dài hàng nghìn dòng
Phần lớn đều rất tệ nên gần như không thể review
Trước đây để làm ra một PR như vậy chắc phải mất một tuần, còn bây giờ thì đổ ra chỉ trong một ngày
Có rất nhiều câu hỏi xoay quanh chính thuật ngữ “LLM”
Mô hình được gọi trực tiếp qua raw API là LLM, còn những thứ như Claude.ai hay ChatGPT thì là lớp harness bọc bên trên nó
Những harness như vậy bao gồm nhiều chức năng như template prompt, quản lý trạng thái hội thoại, v.v.
Rốt cuộc thì gần như lúc nào chúng ta cũng đang dùng nhiều hơn bản thân LLM
Những agent như vậy có thể chạy code, tự kiểm thử và tự sửa
ChatGPT hay Claude cũng có tính năng này nên trên thực tế đều là coding agent
Vì thế câu “LLM không có trí nhớ” chỉ đúng với bản thân mô hình
Claude Code hay Cursor là các agentic system có duy trì trạng thái
Tiêu đề bài viết này khá thú vị, nhưng nói LLM viết ra “đoạn code có vẻ hợp lý” thì vẫn chưa thật chính xác
Trên thực tế, nó chỉ tạo ra đoạn code tương tự với các cụm code mà nó đã thấy trong dữ liệu huấn luyện
Nó chỉ sinh tự do ở những vùng không bị RLHF hay RLVR ràng buộc
Vì thế toàn ngành đều nói cùng một ngôn ngữ, nhưng chính điều đó lại trở thành nguồn gốc của hiểu lầm
Nó khiến mọi người lầm tưởng rằng tất cả đang giải cùng một bài toán
Ví dụ, nếu yêu cầu tree-sitter query thì nó sẽ bịa ra những directive không hề tồn tại
Không nhất thiết phải giải thích cấu trúc nội bộ phức tạp làm gì
Gần đây tôi nhờ Codex tạo một thành phần UI dựa trên Datastar nhưng nó thất bại hoàn toàn
Dù là việc đơn giản, nhưng càng thử lại thì JavaScript inline và code backend cứ tiếp tục tăng lên
Nó cũng không hề dọn dẹp phần code cũ
Nó làm tốt các tác vụ phức tạp, nhưng ngược lại lại cho thấy kiểu thất bại phản trực giác ở những bài toán cơ bản