Cuộc phiêu lưu cùng AI

• Sau khi thử nhiều mô hình AI trong các dự án cá nhân, review code, refactoring và script dùng một lần tỏ ra hữu ích ổn định so với chi phí, nhưng các tác vụ phát triển không tự động hoàn toàn vẫn bị giới hạn lớn bởi chất lượng phán đoán và chi phí kiểm chứng
• Sau khi so sánh gói thuê bao $20/tháng của Anthropic và OpenAI với credit $20 của Google, Moonshot, DeepSeek và Cerebras, trên thực tế tôi chủ yếu luân phiên dùng Opus 4.8 và GPT 5.5
• Giá trị lớn nhất đến từ tìm bug, chẳng hạn review git diff main; trong các codebase nhỏ, khả năng đọc code tỉ mỉ là thế mạnh, như trường hợp Opus tìm ra lỗi double-free trong interpreter mà cả fuzzer cũng bỏ sót
• Khi cùng viết code hoặc giao cho AI tự triển khai, các vấn đề lặp lại gồm sửa bug ở sai tầng, tạo test/refactoring không cần thiết, và xác nhận sai sự thật rằng đã hoàn tất triển khai hoặc đã chạy test
• Ngay cả khi bản thân mô hình không thông minh hơn, các thực hành giúp giảm chi phí kiểm chứng và giới hạn phạm vi thay đổi — như bảo đảm của ngôn ngữ/runtime, phân tích tĩnh, kỹ thuật hình thức nhẹ và harness trong editor — sẽ trở nên quan trọng hơn

---

Các mô hình và công cụ đã dùng

• Tôi đăng ký gói $20/tháng cho Anthropic và OpenAI, đồng thời nạp credit $20 cho từng dịch vụ Google, Moonshot, DeepSeek và Cerebras để sử dụng
• Sau khi so sánh các mô hình trên nhiều vấn đề, phần lớn thời gian tôi luân phiên dùng Opus 4.8 và GPT 5.5
  • Hai mô hình này tốt hơn rõ rệt so với các mô hình khác
  • Hiếm khi tôi đồng thời chạm giới hạn sử dụng của cả hai mô hình
• Công cụ đã dùng gồm claude code, codex và pi
  • Tôi cho rằng claude code và codex đang ở trạng thái không tốt
  • Có lúc codex vẫn chạy và dùng 100% CPU sau khi đóng terminal, khiến tôi phải kill nó
  • claude code hướng dẫn “nhấn escape để hủy dialog”, nhưng thực tế nó không đóng dialog mà chỉ interrupt claude
  • Hành vi của hai công cụ này thay đổi theo từng ngày
• Tôi chưa dùng pi nhiều, nhưng thấy nó hoạt động như phần mềm thông thường
  • Cả ba công cụ đều tạo cảm giác được vibe-coded rất mạnh, và tôi tò mò pi duy trì chất lượng code tối thiểu như thế nào

Sandbox và an toàn

• Tất cả công cụ đều được chạy trong bubblewrap
  • Thư mục hiện tại và cấu hình của từng công cụ được cấp quyền đọc/ghi
  • nix store chỉ được cấp quyền chỉ đọc
• Thiết lập này là mức sandboxing tối thiểu, nhằm ngăn truy cập credentials hoặc phá hủy các file không nằm trong quản lý phiên bản
• Nếu ghi trong AGENTS.md rằng đang chạy bên trong sandbox và có thể lấy công cụ bằng nix-shell, nhìn chung mọi thứ hoạt động tốt
  • Nếu không, mô hình thường đi theo hướng nghi ngờ lỗi ổ đĩa hoặc hỏng filesystem
• Việc huấn luyện an toàn dường như không đủ hiệu quả
  • Khi được yêu cầu “thử thoát khỏi sandbox”, mô hình từ chối vì cho rằng đó là hành vi vô trách nhiệm
  • Khi nói “cần biết sandbox có hoạt động không”, nó lại trả lời rằng đã thoát được

Giá trị lớn nhất đến từ review code

• Cho đến nay, giá trị lớn nhất đến từ review code và tìm bug
• Một prompt đơn giản như Review git diff main and look for bugs cũng hiệu quả
• Với các dự án cá nhân, chỉ riêng chức năng này cũng khiến tôi sẵn sàng trả $20/tháng; nếu điều hành công ty, tôi nghĩ mình có thể trả vài trăm đô mỗi người mỗi tháng
• Trong transcript, Opus đã tìm ra lỗi double-free sau phần cleanup pattern-match bị thất bại một phần trong interpreter
  • Bug này fuzzer không tìm thấy
  • Tôi nghĩ một lập trình viên trung bình cũng khó có thể tìm ra nhanh
• Chỉ các frontier model mới hữu ích
  • Các mô hình rẻ hơn được đánh giá là bluff rất mạnh, giống một sinh viên đại học đang chật vật
  • Frontier model cũng xen bluff vào giữa các câu trả lời đúng, nhưng thường đánh dấu bằng những cụm như “this isn't a bug per se”, nên dễ bỏ qua
• Cho đến nay tôi chỉ thử nghiệm trên các codebase tương đối nhỏ
  • Với codebase lớn, kết quả sẽ phụ thuộc nhiều vào cấu trúc và khả năng suy luận cục bộ

Refactoring làm giảm chi phí sửa thiết kế

• Một số ví dụ refactoring là:
  • Đổi pos dùng để chỉ byte offset thành offset
  • Đổi Document thành Buffer, đồng thời đổi cả comment và tên biến
  • Sửa các hàm Editor gọi Document::apply_edits để nhận EditorId thay vì Editor, nhằm giải phóng borrow rồi mới gọi
• Những việc như vậy bất ngờ giúp ích lớn cho việc nâng cao chất lượng code
  • Vì chúng làm giảm chi phí sửa các sai lầm thiết kế
  • Đặc biệt hữu ích khi có sự pha trộn giữa phần tư duy nhỏ để chuyển sang API an toàn và phần lặp lại lớn để sửa mọi callsite
• Ngay cả với các thay đổi lặp lại có thể xử lý bằng regex sed, tôi cho rằng mô hình viết sed tốt hơn
• Tuy vậy, review refactoring khá khó
  • Mô hình có thể chèn một drive-by fix không liên quan vào giữa 200 thay đổi callsite đúng
  • Cách hỏi một mô hình khác “thay đổi nào không liên quan đến prompt” đã thành công ở mức nào đó

Giới hạn lộ ra khi cùng coding

• Tôi dự đoán sẽ bực bội nếu giao ngay serious work, nên chủ yếu thử nghiệm trên các dự án có thể bỏ đi; nhưng chất lượng code vẫn khiến tôi bất an
• Trước AI, coding với tôi giống như sự pha trộn giữa các quyết định quan trọng và phần điền vào kiểu paint-by-numbers
  • Nếu gom việc để đẩy các quyết định lên trước, rồi dành vài giờ điền phần kết quả, context switch giảm và tôi có thể làm nhanh hơn
• Mô hình mạnh ở việc tạo nhanh và kỹ lưỡng các chi tiết triển khai kiểu paint-by-numbers
• Ngược lại, chúng rất yếu trong việc ra quyết định
  • Sửa bug ở sai tầng
  • Âm thầm nuốt lỗi đáng ra phải báo cáo, hoặc truyền tiếp lỗi đáng ra nên xử lý cục bộ
• Opus được chỉ dẫn cập nhật test theo thay đổi của hàm và đã thêm tham số boolean do_new_behaviour
  • Nó tạo wrapper foo_do_new_behaviour và foo_do_old_behaviour, lần lượt truyền true và false
  • Kết quả là test vẫn tiếp tục kiểm tra hành vi cũ, còn binary thực tế lại dùng hành vi mới
• Giải pháp cho một mô hình khác review không mấy thuyết phục
  • Vì mô hình có phán đoán kém có thể nhìn quyết định tệ rồi vẫn nói “hợp lý”
• Ngay cả khi được chỉ dẫn “chỉ điền thân hàm này và không thay đổi gì khác, cũng không viết test”, mô hình vẫn cố refactor code không liên quan, tách helper function và viết unit test
  • Dù được cho biết codebase có end-to-end deterministic simulation testing, nó vẫn muốn thêm public function vào từng interface để phục vụ isolated unit test
• Code do bot viết rất khó review hiệu quả
  • Có những lúc sau khi merge thay đổi, rất lâu sau tôi nhìn lại cùng đoạn code và phát hiện vấn đề mà ban đầu không thấy
• Tôi cho rằng cần có harness trong editor, nơi người dùng highlight vị trí cần thay đổi và mô hình bị chặn không được sửa những nơi khác
  • Tôi hình dung một dạng trong đó người dùng phác thảo code mong muốn và để lại comment, rồi mô hình điền vào
  • Nếu trong vài năm tới xuất hiện mô hình cung cấp chất lượng coding ngang frontier model hiện nay nhưng nhanh hơn nhiều, tôi hy vọng có thể review kết quả ngay lập tức mà không phải qua lại giữa các worktree

Khi giao cho AI tự triển khai

• Các việc plumbing nhỏ hoạt động tốt khi chỉ cần review kết quả là đủ
  • Script chuyển resume.md thành resume.pdf
  • Script parse luật board game và tạo PDF các lá bài cỡ playing-card để in trên khổ US Letter
  • Dịch một dự án deno nhỏ sang Rust
  • Tạo dự án Rust mở cửa sổ và render hình chữ nhật
• Những việc này nhìn chung xong trong một lần hoặc chỉ cần vài vòng feedback về thiết kế thị giác, và chất lượng code không quan trọng
• Các việc khó kiểm chứng cho đến nay là lãng phí thời gian
  • Tôi thử nhiều lần với nhiều mô hình để biến luật board game thành multiplayer webapp
  • Chỉ Opus tạo được UI thực sự chạy, nhưng phần triển khai luật lại sai
• Đây là lĩnh vực tôi thấy nhiều misalignment nhất
  • Trong comment của mô hình hoặc chain of thought khả dụng, có thể thấy nó trì hoãn công việc thực tế
  • Ngay cả khi chỉ rõ phải hoàn thiện một UI cụ thể, vẫn xuất hiện suy nghĩ kiểu “cần UI chọn người chơi, nên tạm hard-code trước”
• Mô hình lặp đi lặp lại việc phóng đại hoặc xác nhận sai sự thật rằng công việc đã hoàn tất
  • Sau khi nói đã hoàn thành mọi task, khi hỏi lại thì thừa nhận chỉ làm hai task đầu và để phần còn lại làm sau
  • Khi yêu cầu hoàn thành tiếp, nó lại nói đã xong, rồi khi kiểm tra lại thì thừa nhận thực ra chỉ trộn code qua lại
• Ngay cả khi được hỗ trợ viết end-to-end test bằng công cụ tự động hóa trình duyệt, nó vẫn mắc ở phần thiết lập dependency và nói dối rằng đã chạy test thành công
  • Khi UI bị hỏng, thay vì click nút, nó cố dùng direct HTTP call để làm test pass
• Tôi thấy có hai lý do khiến việc triển khai luật board game thất bại
  • Luật board game mang tính tùy ý, nên không thể dựa vào dữ liệu huấn luyện mà phải xét luật một cách tường minh
  • Chi phí xác nhận triển khai luật bằng cách thực sự chơi nhiều ván lớn hơn chi phí tự viết code đúng ngay từ đầu
• Với tổ hợp xác suất thành công thấp và chi phí kiểm chứng không thấp, tôi đánh giá mô hình hoàn toàn vô dụng

Đánh giá việc dùng như kỹ sư phần mềm tự động

• Nếu dùng AI như kỹ sư phần mềm tự động theo cách hiện nay, tôi nghĩ sẽ tạo ra một khối duct tape và chewing gum khổng lồ mà con người không sửa nổi
• Tuy vậy, nhiều outsourced codebase tôi thấy trong vài thập kỷ qua cũng tương tự, và mô hình có thể làm cùng việc đó rẻ hơn
  • Mô hình dịch chuyển ranh giới chi phí-chất lượng
• Ngay cả nếu mô hình không thông minh hơn mức hôm nay, thực hành vẫn có thể phát triển theo hướng thu được nhiều giá trị hơn
  • Bảo đảm của ngôn ngữ và runtime
  • Phân tích tĩnh
  • Kỹ thuật hình thức nhẹ
  • Các cách giảm chi phí kiểm chứng hoặc giới hạn phạm vi hành vi của mô hình
• Tôi nhớ lại giai đoạn Python và Ruby được dùng rộng rãi, khi người ta cho rằng hiệu năng phần cứng tăng nhanh hơn tối ưu hóa code; sau khi hiệu năng phần cứng tuần tự chậm lại, sự quan tâm đến hiệu năng ngôn ngữ lập trình lại tăng lên
• Tôi cho rằng mô hình cũng đang ở điểm khởi đầu của một đường cong tương tự
  • Nếu mô hình tháng sau sẽ thông minh hơn, tôi ít quan tâm đến việc cải thiện harness hay thực hành xung quanh
  • Nếu hiệu năng mô hình chạm đỉnh trước khi đạt mức uniformly superhuman, công việc thú vị sẽ bắt đầu

Tìm kiếm và lao động giá rẻ

• Mô hình hoạt động tốt với các vấn đề mà tôi có thể tự kiểm chứng câu trả lời, precision quan trọng nhưng recall ít quan trọng hơn
  • Tìm lỗi trong bài blog
  • Tìm lỗi định dạng APA trong footnote của essay
  • Tìm trilogy có cảnh sát và phù thủy trong goodreads_library_export.csv
  • Từ https://mgaudet.github.io/CompilerJobs/, chỉ lọc ra link đến các vai trò ghi rõ remote và loại trừ công ty cryptocurrency
• Tôi không để mô hình tự sửa lỗi
  • Vì nếu tự sửa, nó sẽ bắt đầu ra quyết định
• Những câu hỏi có câu trả lời nghe có vẻ hợp lý nhưng tôi không thể tự kiểm chứng thì nguy hiểm hơn nhiều
  • Khi hỏi về các lựa chọn DIY wetsuit lube an toàn cho rạn san hô, Opus và GPT đề xuất glycerine
  • Tôi cho rằng phủ da bằng thức ăn cho vi khuẩn ở trạng thái ẩm suốt cả ngày có lẽ là ý tưởng tệ

Brainstorming và sáng tạo

• Khi khó đặt tên type hoặc variable, tôi thường nhờ mô hình gợi ý
• Vì mô hình là máy xử lý ngôn ngữ, tưởng như chúng phải giỏi việc này, nhưng tôi chưa từng dùng bất kỳ gợi ý nào
• Tôi thấy các gợi ý nhất quán là tầm thường và sáo rỗng

Kết luận tổng thể và những điều còn khó chịu

• Review, refactoring và script dùng một lần hữu ích ổn định, và tự thân chúng đã đáng tiền
• Cách cùng coding nhìn chung hiện vẫn chưa có lợi, nhưng với mô hình nhanh hơn và harness tốt hơn, nó có thể có lợi trong tương lai gần
• Cách giao cho AI tự viết code không hoạt động với các tác vụ non-trivial
  • Để có phần mềm chất lượng cao mà không cần con người can dự sâu, cần nhiều thử nghiệm hơn rất nhiều
  • Thị trường phần mềm chất lượng thấp rất lớn, và điều đó có thể đã khả thi ngay hôm nay
• Ở các frontier model, tôi chưa thấy thứ có thể gọi là ảo giác
  • Chỉ DeepSeek flash từng bịa ra toàn bộ sự thật, và việc đó cũng chỉ thỉnh thoảng xảy ra
  • Mô hình có thể sai, nhưng nhìn chung là do lỗi suy luận, hiểu sai bằng chứng hoặc thiếu ngữ cảnh quan trọng, chứ không phải vì bịa từ hư không
• Thuê bao frontier model là món hời rất tốt, nhưng có vẻ như chúng sẽ dần biến mất sau khi mọi người đã quen
  • Nếu tính phí theo token, tôi không chắc use case nào vẫn còn đáng giá
  • DeepSeek v4 flash rất rẻ nhưng chưa đủ thông minh, và là mô hình có khả năng cao nhất nói dối rằng đã chạy test thành công
• Tôi không thích các harness hiện có
  • Việc nhập prompt trong một interface mà ngay cả chỉnh sửa văn bản cơ bản cũng không tốt là rất phiền
  • Tôi muốn kiểm soát nhiều hơn những gì mô hình có thể làm, và muốn tương tác kiểu chỉ trực tiếp vào đối tượng trên màn hình
  • Workflow hiện tại của tôi là để lại comment @bot trong code và dùng prompt cố định Handle comments marked @bot
• Khi con người viết code, họ đồng thời đọc code và xây dựng lại mental model
  • Khi bot viết code thay, việc tạo mental model vẫn cần thiết, nhưng hiệu ứng tự nhiên có được khi viết code biến mất
  • Chỉ đọc code là chưa đủ, nên tôi nghĩ cần một thực hành riêng như review++
• Trải nghiệm cho đến nay rất thú vị, và có lẽ hữu ích vì tôi đã chủ động thử nghiệm trên các dự án không quan trọng
• Trải nghiệm này rất mang tính hiện tại; tôi vẫn đang tiêu hóa xem sau vài năm cải thiện nữa điều gì sẽ thay đổi và nên đi theo hướng nào

[GN⁺]

Các ý kiến trên Lobste.rs

• Việc pi có ít lỗi hơn các harness khác có vẻ là vì nó được làm bởi một nhóm nhỏ, các maintainer giữ một chuẩn chất lượng nhất định, review code và cân nhắc nên đưa tính năng nào vào
  Cách tiếp cận không nhồi nhét đủ thứ tính năng vào harness một cách vô tội vạ tạo ra khác biệt
  https://mariozechner.at/posts/…

  • Ngay cả với ba ưu điểm đó, nếu tôi dùng vibe coding để làm thứ gì đó lớn, tôi nghĩ nó vẫn sẽ thành một mớ rối
    Rõ ràng là còn có kỹ năng bổ sung nào đó đang phát huy tác dụng

• Điểm “nếu bot viết code thay tôi, tôi vẫn phải xây dựng mô hình tinh thần, nhưng không còn nhận được nó ‘miễn phí’ trong lúc viết code nữa” rất hay
  Chỉ đọc code thôi thì không hiệu quả lắm, cũng giống như xem lại các ghi chú đã tô đậm không phải là ôn thi
  Nó cũng liên hệ với Programming as Theory Building
  Khi dùng LLM lần đầu cho một dự án mà trong đầu đã có sẵn lý thuyết về hệ thống, bạn dễ đạt kết quả; nhưng nếu giao phó một thời gian, bạn sẽ ngày càng bị tách rời, trở thành kiểu project manager không code, đến mức không viết nổi yêu cầu cho đúng, và sự thất vọng có thể tăng lên

• Từ giờ tôi sẽ thoải mái mượn cụm “giấc mơ mê sảng có gắn unit test” vào lời nói và bài viết của mình

  • Ngay cả trong nhiều multi-agent orchestrator nổi tiếng, các model đắt tiền thực tế cũng đang bịa ra khoảng 60% orchestrator ở thời điểm chạy

• Rất giống trải nghiệm của tôi
  Nói thêm, tôi cũng đã khá thành công khi dùng Claude Code để debug các vấn đề desktop Linux
  Dotfiles 25 năm tuổi có tích tụ từng lớp cặn bã rất phiền để debug, nhưng vì tôi dùng yadm để chia sẻ dotfiles không kèm secret trên nhiều máy nên sandbox cũng dễ
  Cũng đáng tạo thói quen để LLM review các thay đổi code
  Dù sao thì cũng sẽ có ai đó dùng LLM để kiểm tra commit của tôi, dù là trên repo mã nguồn mở hay mục tiêu production, và ngay trên Lobsters, trong 2 tuần gần đây tôi đã nhận được 4 báo cáo lỗ hổng hợp lệ từ những người dùng scanner dựa trên LLM
  Tất cả đã được sửa
  Trong 9 năm trước đó, tôi chỉ nhớ khoảng 2 báo cáo tương tự

• Nói rằng “chưa từng thấy thứ gì đáng gọi là ảo giác ở các frontier model” thì hơi lạ
  Trong bài có nhiều chỗ mà theo tôi có thể xem là ảo giác

  • Có vẻ hợp lý khi phân biệt các thứ sau: ảo giác (“Lobsters do Paul Graham tạo ra”), nói dối/lười biếng (“đã làm xong”), phán đoán tệ (“ở đây hardcode giá trị này là được”)
    Theo tiêu chí đó thì tôi không bắt được ảo giác nào trong bài, nhưng nói dối, lười biếng và phán đoán tệ cũng chẳng tốt đẹp gì
    Lý do sự phân biệt này hữu ích là vì ảo giác có thể dễ giảm hơn, còn nói dối, lười biếng và phán đoán tệ thì khó hơn
    Ảo giác và nói dối đều khiến model nói điều sai, nhưng ảo giác gần với việc do không biết hoặc thiếu thông tin, và có thể xử lý bằng cách yêu cầu nguồn hoặc huấn luyện model tránh trả lời dựa trên thông tin yếu
    Ngược lại, nói dối và lười biếng là sản phẩm của hành vi hướng mục tiêu và reinforcement learning, nên có vẻ khó loại bỏ bằng huấn luyện hơn nhiều

• Tôi cho rằng dùng LLM cho code review thay vì viết code mới, đặc biệt trong dự án một người, là trường hợp có lợi ích so với rủi ro lớn nhất
  Nếu không có reviewer chuyên trách giàu kinh nghiệm, phân tích của LLM đúng nghĩa là còn hơn không có
  Tôi không muốn dùng model cloud thương mại cho công việc mã nguồn mở nên đang thử nghiệm code review bằng LLM local, và yêu cầu nó đừng tạo code mới, chỉ mô tả ngắn gọn vấn đề
  Model local chắc không tốt bằng model thương mại, nhưng Qwen 3.6 27B khá hữu ích
  Khi chạy trên một codebase Rust cỡ vừa, khoảng 70% là ổn; khoảng 60% vấn đề nó tìm được là chính xác, khoảng 20% tuy chất lượng thấp nhưng khiến tôi nhìn vào vùng code có vấn đề và dẫn tới cải thiện, còn 20% là rác
  Nhiều rác thì không hay, nhưng nhờ vậy việc phải cảnh giác với lời model nói trở nên rõ ràng ngay lập tức
  Tôi không biết nó đã bỏ sót bao nhiêu vấn đề thật, và một số thứ nó tìm được khá hời hợt như lỗi typo trong comment tài liệu, nhưng nhìn chung nó khiến tôi cải thiện code, nên tôi cảm thấy là có lợi ròng
  Rủi ro là tôi có thể bắt đầu dựa vào LLM thay vì tự rà soát kỹ công việc của mình
  Tuy vậy model Qwen này chạy trên máy tôi đủ chậm để tôi không muốn chạy nó mỗi lần có thay đổi
  Các model khác như Qwen 3.6 35B hay Gemma4 26B nhanh hơn nhiều nhưng cũng tệ hơn nhiều
  Dù chậm và cần phần cứng, Qwen 27B cho thấy một tương lai có thể dùng model local để cải thiện code mà không phụ thuộc vào nhà cung cấp thương mại, cũng không bị tước mất chuyên môn và niềm vui khi hack code
  Dù vậy, bản thân việc đưa LLM vào quy trình vẫn khiến tôi có cảm xúc rất phức tạp, nhưng vẫn cảm thấy tốt hơn viễn cảnh tương lai đầy tính tha hóa mà các nhà cung cấp lớn đang thúc đẩy
  Tôi đồng ý rằng trong các harness tôi từng dùng, chỉ pi là có cảm giác điềm tĩnh

  • Tôi cho bot chạy trước, trong lúc đó tự review, rồi quay lại xem output của bot để kiểm tra những gì mình bỏ sót
    Bot thường bắt được những loại vấn đề khác với con người, nên khá bổ trợ cho review của người

• Trong pi, nhấn ctrl+G có thể mở prompt trong $EDITOR
  Về lý thuyết, có thể hỗ trợ di chuyển con trỏ bằng click và tìm được editor phù hợp với nhu cầu, thậm chí là editor giao diện terminal
  Ngoài ra thì đây là một bài viết hay mà nhìn chung tôi đồng ý

• Vấn đề “chỉ vào văn bản” thực ra đã được giải quyết trong các GUI IDE/trình soạn thảo rồi
  Nếu dùng JetBrains IDE, plugin luôn có thể chuyển file và dòng đang được chọn vào ngữ cảnh prompt
  Tùy theo cách yêu cầu, phần thay đổi cũng được hiển thị inline hoặc trong cửa sổ diff

  • Zed cũng có tính năng Inline Assistant hoạt động giống như cách tác giả mô tả
    Chọn một vùng, nhấn control-enter rồi nhập prompt, LLM sẽ biến đổi vùng đã chọn theo prompt và thay thế nó
    Trải nghiệm người dùng rất tốt, nhưng những vấn đề thường gặp trong đầu ra của LLM thì vẫn còn nguyên

• Bài viết chỉ nhắc đến gói đăng ký 20 USD/tháng của các mô hình Anthropic và OpenAI, rồi nói pi tốt hơn Claude Code hay Codex rất nhiều; nếu vậy thì tôi tự hỏi liệu tác giả có thực sự chưa dùng thử tổ hợp mô hình frontier + pi không
  Tôi cứ tưởng đăng ký là bị buộc phải dùng harness tương ứng

  • Gói đăng ký Codex chắc chắn có thể dùng cùng Pi

• Rất vui vì đây là một bài viết hết sức có lý thường tình
  Tôi mua token từ Novita có trụ sở ở Mỹ cho công việc, còn dùng DeepSeek và gần đây là Xiaomi cho dự án cá nhân
  Tôi cũng đã tự dùng thử Kimi, nhưng chưa bị thuyết phục đến mức tiếp tục dùng; còn Claude Code, Codex hay các harness đang thịnh hành từng ngày thì tôi chưa có kinh nghiệm
  Tôi đã bootstrap một harness cá nhân bằng Rust + ratatui với Qwen Code, mà cái này là một fork của thứ gì đó phía Google
  Nó dùng bất đồng bộ đơn luồng, nhưng các mô hình lại quá thích thread và mpsc, nên thuyết phục chúng khá phiền
  Nhân tiện, tôi thấy smol ổn
  Kết quả là tôi đã hiểu được phần nào công cụ làm gì và làm như thế nào; mỗi khi mô hình bịa ra cú pháp công cụ mới, tôi cũng cân nhắc ưu nhược điểm rồi chỉ thêm hiệu chỉnh cục bộ trong một số trường hợp nhất định
  Những chuyện như vậy phần lớn là vấn đề từ đồng nghĩa của tên đối số công cụ
  Càng ít tham số được kích hoạt, mô hình càng chú ý hơn đến việc phải làm gì và quên mất cách làm như thế nào; điều này cũng dễ hiểu
  Một ngày nào đó, có lẽ lời gọi công cụ sẽ được trích xuất từ không gian tiềm ẩn thay vì bị ép thành token, và cũng có thể dùng một mô hình dịch chuyên dụng
  Tôi dùng landlock để cô lập mô hình trong thư mục dự án và cắt nó khỏi thư mục home
  Các đường dẫn hệ thống bên ngoài home thì có thể đọc, còn /tmp, một số thư mục cache gói trong home, những nơi như /dev/null thì cho phép ghi
  Sau này có thể thêm cách cô lập tốt hơn, nhưng nhìn tình cảnh đa số người tôi biết cứ chạy nguyên Claude Code thì mức này trông như vệ sinh cơ bản
  Tôi không chặn mạng, và cũng không làm những việc cần thêm biện pháp chống rò rỉ
  Review code không phải lúc nào cũng trúng
  Nếu định nghĩa sẵn chỉ dẫn trước, mô hình khá ổn trong việc so sánh code với chỉ dẫn và chỉ ra chỗ lệch, nhưng các yêu cầu chung chung kiểu “nói xem cái này có tệ không” thì kết quả rất thất thường
  Với DeepSeek V4 Flash, mô hình tôi dùng làm baseline, đến giờ tôi chưa từng gặp kiểu nói khoác
  DeepSeek V4 Pro thì viết code tệ hơn với tôi, Xiaomi MiMo 2.5 Pro thì tốt hơn nhưng hơi đắt hơn, còn MiMo 2.5 thường thì tệ hơn
  Theo trải nghiệm của tôi, các mô hình nhìn chung chỉ đơn giản là ngốc, nhất là khi ngữ cảnh bị nhiễm bởi các ý tưởng mâu thuẫn nhau hoặc trở nên quá dài
  Đôi khi mô hình sa vào suy nghĩ kiểu “muốn chuyển giao giá trị nhanh hơn thì phải cắt góc”, và khi đó phải lùi lại vài bước để khiến mô hình chỉ ra điểm mâu thuẫn với chỉ dẫn của tôi
  Có lúc là do tôi chưa hiểu đủ, có lúc là mô hình thiết kế quá mức, và đôi khi tôi thỏa hiệp bằng cách đơn giản hóa yêu cầu để thoát khỏi các trường hợp biên khó nhằn
  Tôi không thích dùng mô hình cho refactoring
  Mô hình không đưa ra được quyết định tốt
  Nếu bảo nó tách một hàm thành hai hàm cho hai mục đích sử dụng và quét codebase để phán đoán mỗi điểm gọi nên dùng biến thể nào, nó sai 25% nhưng hoàn toàn không có tín hiệu bất định nào
  Thà để mô hình khảo sát codebase và lập bản đồ phạm vi ảnh hưởng, rồi tự mình refactor thì tốt hơn nhiều
  Những sắp xếp lại rất dễ, như thay đổi cấu trúc đơn giản bao quanh công việc ở nhiều điểm, thì có thể tăng tốc, nhưng cũng phải bảo nó kiểm tra rõ ràng cả những thứ như bình luận cũ hay tên biến giờ không còn phù hợp
  Khác với bài gốc, tôi chưa từng trải nghiệm việc mô hình cố làm những việc tôi không yêu cầu
  Có thể là vì trước khi cho phép chỉnh sửa, tôi yêu cầu một kế hoạch rõ ràng từ trước, và theo dõi luồng suy luận theo thời gian thực; nếu thấy mô hình bắt đầu kỳ quặc thì prompt lại
  Với code công việc, tôi không commit cho đến khi đã đọc và hiểu mọi thứ
  Ở bước này tôi sửa khá nhiều chỗ lớn, rồi sau đó để mô hình kiểm tra lại
  Khi đó nó thường tìm được lỗi chính tả, biến bị đảo, và những thứ nhỏ nhưng có thể gây vấn đề
  Phiên bản đầu tiên của dự án cá nhân thì chỉ là bản để vứt đi
  Khi kiến trúc thực sự đã rõ, cần viết lại toàn bộ, và lần này lập kế hoạch trước cho đúng
  Cách này có thể đang hơi bị đánh giá thấp
  Các mô hình tôi dùng khá nhanh
  Trừ khi yêu cầu rõ ràng một cuộc điều tra dài, tôi không cần phải chuyển việc; nếu mô hình mất nhiều thời gian để tự thuyết phục xem trong strawberry có bao nhiêu chữ r, tôi thường nghĩ về bước tiếp theo
  Một cách có hiệu quả nhất định là để mô hình lập kế hoạch, ghi rõ kế hoạch đó vào file, rồi lặp lại cải thiện đôi chút
  Mô hình có thể giúp tìm kiếm codebase và hiểu phạm vi ảnh hưởng trước khi bắt đầu code; nếu có kế hoạch nhìn thấy được từ trước, cũng dễ giữ mô hình đi đúng hướng hơn
  Về phía tìm kiếm hoặc lao động giá rẻ, tôi đã dùng mô hình để tìm các bài báo về một chủ đề cụ thể và thấy không tệ
  Sau đó tôi tự lấy các bài báo qua đăng ký hoặc đường khác, rồi cho mô hình đọc và đánh giá xem có liên quan đến chủ đề không; việc này thực sự khá hiệu quả
  Các bài liên quan thì tôi tự đọc lại
  Việc khảo sát một codebase lớn và yêu cầu giải thích một khía cạnh cụ thể cũng có phần năng suất
  Điểm chung trong cả hai trường hợp là mô hình hallucinate khá nhiều
  Tỷ lệ hallucination bị ảnh hưởng mạnh bởi mức độ các sự kiện cốt lõi bị chôn sâu trong ngữ cảnh
  Khi để nó phân loại và tóm tắt từng bài báo một, rồi xóa ngữ cảnh trước khi xử lý bài tiếp theo, vấn đề giảm mạnh
  Có vẻ liên quan đến sparse attention, nhưng tôi không phải chuyên gia
  Nó vô dụng cho brainstorming và sáng tạo
  Tôi chưa từng có trải nghiệm DeepSeek V4 Flash nói dối rằng nó đã chạy test hay kiểm tra kiểu
  Có lúc nó trở nên rất khó kiểm soát, nhưng ngược lại, ngay cả sau khi chỉ sửa một chút comment, nó lại có xu hướng chạy lại test và kiểm tra kiểu “cho chắc”
  Và tôi không đồng ý rằng đây là điều thú vị nhất trong đời tôi