{
  "version": "1.0",
  "title": "La Bàn",
  "language": "vi",
  "home_page_url": "https://laban.cc",
  "next_cursor": null,
  "items": [
    {
      "id": "industrial-phan-1-dot-token-tiet-kiem-thoi-gian",
      "url": "https://laban.cc/posts/industrial-phan-1-dot-token-tiet-kiem-thoi-gian",
      "markdown_url": "https://laban.cc/posts/industrial-phan-1-dot-token-tiet-kiem-thoi-gian.md",
      "title": "Industrial (Phần 1): Đốt token, tiết kiệm thời gian",
      "summary": "Guillermo Rauch, Blake Scholl và Max Hodak bàn về nhà máy phần mềm, kỹ sư 1000x, và vì sao đừng đếm token. Bản chuyển ngữ tiếng Việt của tập Naval Podcast “Industrial”, phần 1/4.",
      "date_published": "2026-10-25T00:20:38.790Z",
      "date_modified": "2026-10-25T00:20:38.790Z",
      "source": {
        "title": "Industrial — Naval Podcast (Guillermo Rauch, Blake Scholl, Max Hodak)",
        "url": "https://nav.al/industrial"
      },
      "content_markdown": "Bản chuyển ngữ tiếng Việt thực hiện cho La Bàn, từ bản ghi tập podcast Industrial trên nav.al. Bài gốc gồm bốn phần; đây là phần một. Nguồn: https://nav.al/industrial\n\n## Phần 1: Đốt token, tiết kiệm thời gian\n\nNivi: Chào mừng các bạn. Các bạn đang nghe Naval Podcast, nguồn tri thức mới đáng tin cậy. Hôm nay chúng tôi thử một cách làm mới. Tôi có ba nhà sáng lập ở tuyến đầu — ba người đàn ông đẹp trai, thật ra là vậy — và một người đàn ông đẹp trai thứ tư, Naval.\n\nĐể tôi giới thiệu từng người. Guillermo “the G” Rauch. Anh đang xây Vercel thành đám mây AI cho thế giới agent và cho bất cứ thứ gì đến sau đó. Blake Scholl. Anh đang xây Boom Supersonic — máy bay siêu thanh, trong nhà máy của chính mình, và cả động cơ phản lực. Và Max Hodak từ Science. Anh đang xây một giao diện não lai sinh học, nuôi tế bào thần kinh sống trên silicon để khôi phục các giác quan như thị giác — và về lâu dài là khám phá những vùng mới của não, những giác quan mới.\n\nCả ba người này đều không lắp sản phẩm của mình từ các linh kiện mua sẵn. Họ tự xây nhà máy. Và chúng tôi không quan tâm bằng việc họ đang xây chính xác cái gì; chúng tôi quan tâm họ đang học được gì về cách xây. Tri thức mới họ đang tạo ra là gì? Lợi thế riêng của họ là gì? Họ đang phát hiện ra nguyên tắc nào mà những người sáng lập khác có thể học? Và ngay lúc này họ đang cố tìm ra điều gì?\n\nNaval, anh có phản hồi gì trước khi tôi chuyển sang Guillermo không?\n\nNaval: Cứ vui vẻ thôi.\n\nNivi: Mọi người cứ tự nhiên vào chuyện.\n\n## Nhà máy phần mềm AI\n\nGuillermo Rauch: Tôi không nhớ chính xác câu mình từng nói, nhưng tôi bị ám ảnh bởi ý tưởng về nhà máy phần mềm. Trước đây, công việc của kỹ sư là đến chỗ làm và giao thẳng đầu ra; cả công ty chỉ hỏi một câu: người A giao đầu ra B giỏi đến đâu?\n\nGiờ thì cách tôi đánh giá một kỹ sư đã khác: bạn có đang tạo ra nhà máy sản xuất ra các đầu ra từ B đến Z với hiệu suất nhân lên không? Đó là thay đổi rất lớn. Trước đây người ta tin — và điều đó từng gây tranh cãi — rằng tồn tại kỹ sư 10x. Giờ rõ ràng có kỹ sư 100x hoặc 1000x, và thế giới chưa điều chỉnh kịp với điều đó.\n\nNaval: Tôi từng bị ném đá trên Twitter vì nói có kỹ sư 10x, bởi nó đụng vào triết lý bình đẳng rằng mọi người đều như nhau. Nhưng thực tế, khi bạn hoạt động trong lĩnh vực ý tưởng, trong không gian trí tuệ và kỹ thuật số, khoảng cách không phải 10x — mà là 100x hoặc 1000x, và nó luôn là như vậy.\n\nSatoshi. Notch. Người phát minh ra JavaScript, những Brendan Eich. John Carmack. Đó là những lập trình viên 1000x. Chưa kể đến chuyện, nếu bạn chọn đúng việc để làm thay vì việc sai, khoảng cách là vô hạn. Và người đó không nhất thiết phải là lập trình viên giỏi hơn, chỉ cần có phán đoán tốt hơn về việc nên làm gì ngay từ đầu. Giờ điều này bớt gây tranh cãi vì đòn bẩy của AI.\n\nGuillermo: Cái gây tranh cãi bây giờ là bảng xếp hạng token. Người ta vẫn hơi bối rối: “Tôi có cả đống kỹ sư 100x đây. Nhìn lượng token tôi phải trả kìa.” Tôi tò mò không biết các anh có thấy điều tương tự không — các anh đo lợi tức đầu tư thế nào?\n\nBlake Scholl: Nó giống cách người ta từng đo số dòng code. Lượng token tiêu thụ và số dòng code là hai mô hình đo lường giống nhau ở chỗ đều không trực tiếp.\n\nMax Hodak: Quan sát của tôi là Claude hay ChatGPT cơ bản giỏi ngang bạn trong một lĩnh vực. Nếu bạn là lập trình viên rất giỏi, những công cụ này rất mạnh. Nếu bạn là lập trình viên mới, bạn sẽ thấy nó giống một lập trình viên mới. Những phản hồi bạn đưa cho chúng, dù lẻ tẻ, có vẻ cực kỳ quan trọng — những cập nhật nhỏ đó dường như quyết định hoàn toàn chất lượng đầu ra bạn nhận được.\n\nGuillermo: Có một kiểu hỗ trợ mới tôi đang làm. Bạn đến gặp tôi, bạn không lấy được đầu ra tốt từ model, và tôi nói cho bạn biết nên đặt prompt thế nào. Chất lượng của lần nhắc lại (reprompt) cực kỳ quan trọng.\n\nMax: Nói rõ ra, tôi nghĩ điều này sẽ bớt quan trọng theo thời gian. Khi model thông minh hơn nhiều, bạn sẽ đưa vào ít hơn và nhận ra nhiều hơn. Nhưng ở giai đoạn này, nó thật sự phản chiếu phán đoán mà người dùng mang theo.\n\n## Đốt token, tiết kiệm thời gian\n\nNaval: Tôi kiểu như chống lại việc học hết các mẹo và thủ thuật. “Dùng Ralph Wiggum. Dùng OpenClaw. Dùng Hermes. Dùng cái prompt engine này. Dùng bộ khung này. Cắm mảnh này vào. Luôn dùng chế độ plan.” Tôi bỏ qua hết. Tôi giả định model sẽ giỏi lên nhanh hơn tốc độ tôi học cách dùng nó. Nó sẽ học cách dùng tôi nhanh hơn tôi học cách dùng nó. Nên tôi cứ dùng chúng một cách thô bạo.\n\nTôi bực mình với chúng và thấy mình ngày càng gõ ít thông tin hơn, làm ít việc hơn, vì tôi giả định mình có thể dùng sức mạnh để vượt qua. Tôi ném Codex, Claude và Gemini vào cùng một vấn đề hết lần này đến lần khác và cứ đốt token để tiết kiệm thời gian. Dù các model này có vẻ đắt đến đâu, chúng vẫn rẻ hơn nhiều so với một con người. Nên tôi sẽ nói thế này: cứ đốt token, tiết kiệm thời gian. Đừng nhìn token như đầu vào hay đầu ra. Chỉ nhìn thời gian của bạn và nhìn kết quả cuối cùng.\n\nKể cả khi chúng viết code chất lượng thấp — mà tôi biết trong nhiều trường hợp là vậy — khi đến lúc tôi muốn đưa lên production, tôi chỉ ném thêm token vào. “Đọc lại đi, xem xét đi, viết lại đi.” Chúng sẽ giỏi lên qua từng thế hệ. Tôi không thấy điều này nhất thiết dừng lại. Chừng nào còn những lĩnh vực kiểm chứng được và những bài toán đã có lời giải, chúng sẽ giải những bài toán đó. Còn ở lĩnh vực chưa có lời giải — có thể bạn là Terence Tao, ở tận biên giới của sáng tạo — thì bạn cần làm việc cộng tác và cẩn trọng, gần gũi với model. Nhưng tôi không ở đẳng cấp đó trong kỹ thuật phần mềm.\n\n## Model chỉ dẫn con người\n\nNaval: Guillermo, có lẽ anh là kỹ sư phần mềm cực đoan nhất trong nhóm. Anh thấy các model này thế nào khi đẩy chúng đến giới hạn năng lực?\n\nGuillermo: Có một việc xảy ra gần đây đúng với điều anh đang nói. Trước đây bạn đưa prompt cho model, nó chạy theo kiểu dự đoán token tiếp theo và lao đi với ý tưởng của bạn. Giờ model đã làm được kiểu lập kế hoạch trực giác — dù bạn không hề yêu cầu nó lập kế hoạch — nó quay lại và nói: “Này, việc anh muốn có ba hướng, đây là bộ đánh đổi.”\n\nĐó là khoảnh khắc người ta trên X đồng loạt nói: “Giờ chúng ta có model kỹ sư trình độ tiến sĩ.” Các model đã tốt nghiệp. Chúng từng là kỹ sư mới vào nghề. Giờ chúng là kỹ sư chính, vì chúng quay lại với bạn bằng một bộ đánh đổi. Dĩ nhiên đôi khi chúng nói bừa, rất buồn cười — nó bảo “việc này mất ba tuần” và “chừng này token”. Dự đoán của nó rất tệ. Nhưng tôi tôn trọng model hơn nhiều, như một người ngang hàng mà tôi trao đổi trí tuệ qua lại.\n\nVẫn còn nhiều khoảng trống. Nếu bạn là kỹ sư hay kiến trúc sư thật sự giỏi, bạn vẫn vắt được nhiều nước hơn. Nên câu hỏi Max đặt ra — nếu bạn là người mới, bạn có nhận lại một người mới?\n\nRõ ràng là không, vì người mới nhận được kiến thức về code cao hơn mức họ có thể tự viết. Nhưng một kiến trúc sư giàu kinh nghiệm có nhận được 10x trong khi kỹ sư mới chỉ nhận 2x? Đó là điều tôi đang cố tìm hiểu.\n\nMax: Có những quyết định kiến trúc. Tôi đang thấy điều này với vài kỹ sư phần mềm mới trong đội — bước tiến tiếp theo trong sự nghiệp của họ là gì? Đó là chuyển từ viết phần thực thi cho một tính năng sang chọn công nghệ. Chọn Postgres hay một cơ sở dữ liệu khác. Chọn ZeroMQ hay một hệ thống hàng đợi khác. Model có thể gợi ý, nhưng vấn đề là — bạn nhìn và nói: “Không, không, tôi muốn dùng cái kia.” Đó là kiểu phản hồi nhỏ thật sự quan trọng, và là kiểu đầu ra bạn nhận được ở thời điểm này.\n\nNaval: Đó là gu và phán đoán, đúng không? Dù vậy — bạn có thể hỏi model “nên dùng cái nào và vì sao”, và chúng biết mọi thứ. Chúng sẽ đưa cho bạn một ma trận đánh đổi rất tốt.\n\nGuillermo: Đó là thay đổi mới xảy ra gần đây. Bạn nói: “Này, đưa dữ liệu telemetry có số chiều cực cao này vào Postgres.” Và nó đáp: “Không, không anh bạn. Người ta không đưa loại dữ liệu đó vào Postgres. Nên xem xét ClickHouse hoặc Athena hoặc gì đó.” Điều này xảy ra với tôi nhiều lần. Rất ấn tượng.\n\nĐiều tôi vẫn đang vật lộn là — rõ ràng con người vẫn đang hoàn thiện model. Đến lúc nào thì ngược lại? Con người bắt đầu nhận chỉ dẫn: “Đi lấy cho tôi cái API key này, vì chỉ bạn làm được.” Hoặc “Lấy cho tôi chừng này vốn cho đợt đầu tư tiếp theo.” Bạn cứ chờ xem. Rõ ràng chúng ta chưa tới đó.\n\nNaval: Đó chỉ là dị tật tạm thời. Chẳng mấy chốc mọi công ty SaaS hay nhà cung cấp hosting tốt sẽ có CLI và API để model dùng trực tiếp. Thậm chí không nhất thiết cần API. Chừng nào còn là văn bản, dựa trên Unix — agent có thể tự hack API của chính nó. Còn phần tiền — bạn nhét token crypto, đưa Bitcoin vào, đưa bất cứ thứ gì, và model đi trả tiền cho những gì nó cần. Người ta đang làm việc này.\n\n## Phần mềm thuần đã chết chưa?\n\nNaval: Điều tôi đang suy nghĩ là — phần mềm thuần đã chết chưa? Kỹ thuật phần mềm thuần có phải là thứ lỗi thời? Nó giống như nói tiếng Anh. Model giờ nói tiếng Anh. Trước đây chúng ta phải học code để giao tiếp với chúng. Giờ model nói tiếng Anh — tiếng Anh mơ hồ, lộn xộn, như con người — và chúng hiểu mọi thứ. Vậy hào bảo vệ của nhà sáng lập nằm ở đâu? Phần cứng? Đó là lợi thế lớn.\n\nTrước đây bạn phải xây phần cứng, và rất khó để xây một công ty phần mềm song song. Patrick Collison nói: “Phần mềm là nghệ thuật, và rất khó thuê nghệ sĩ.” Giờ, là nhà sáng lập phần cứng — tuyệt, bạn có thể có phần mềm rất tốt được phát triển khá nhanh.\n\nNếu bạn tạo ra model, có lẽ đó là kỹ thuật phần mềm mới — huấn luyện, tinh chỉnh, huấn luyện sau, fine-tuning. Nhưng kỹ thuật phần mềm cổ điển — nó đã chết chưa? Phần mềm thuần có đáng đầu tư? Phần mềm thuần có phải là thứ bạn có thể tổ chức một công ty và một đội quanh nó, rồi cố tạo ra đòn bẩy?\n\nGuillermo: Các anh có thấy — có một bài trên X của Mitchell Hashimoto tên là “Nền kinh tế khối lắp ghép”. Lập luận của anh ấy là thứ hữu ích nhất cho agent lúc này là những khối lắp ghép tái sử dụng thật mạnh. Như ví dụ của Max: bạn không mong con bot của mình phát minh lại hạ tầng hàng đợi mỗi lần nó cần gửi email. Nó cần mang đúng khối lắp ghép, đúng kích cỡ cho việc đó — “Với việc này thì BullMQ.”\n\nTôi phản đối ý muốn agent phát minh lại toàn bộ vũ trụ từ những nguyên lý đầu tiên theo cách không tương thích với phần còn lại của xã hội và nền văn minh. Nó gần như phát minh lại đường cao tốc, luật, chính sách — chỉ cho riêng bạn. Kể cả khi có tiềm năng tối ưu thêm, vẫn có giá trị hợp tác ở quy mô lớn khi nói “cả hai chúng ta đang dựa vào Postgres 13.2”.\n\nNhóm phần mềm hạ tầng và các khối lắp ghép mà agent sẽ dùng — dĩ nhiên tôi thiên vị, vì đây là thứ chúng tôi đang xây — cực kỳ có giá trị. Tôi không thấy agent phát minh lại tất cả những thứ đó trong thời gian tới.\n\nMột ẩn dụ khác tôi hay dùng: bất cứ thứ gì đã được tạo ra mà model có thể tái sử dụng đều giống như một bộ nhớ đệm token. Bạn không muốn đốt một nghìn tỷ token để tái tạo lại thứ đã tồn tại. Luôn có một điểm khởi đầu để model rẽ nhánh. Nó sẽ thay đổi mọi thứ khá sâu sắc.\n\nNaval: Vậy chúng giống như thư viện và phụ thuộc, nhưng dành cho model.\n\nGuillermo: Đúng — đặc biệt là cho agent.\n\n## Không còn bị kẹt nữa\n\nMax: Quay lại câu hỏi của Naval — tôi học lập trình khi còn rất nhỏ. Suốt tuổi thiếu niên và hai mươi, tôi bị cuốn vào và code như hai mươi tiếng liền. Rất vui. Tôi biết đủ thứ về các ngôn ngữ lập trình khác nhau.\n\nĐã khá lâu tôi không viết một dòng code nào. Một phần vì công việc của tôi đã khác. Nhưng cũng vì — từ tháng Mười hai, tôi đã xây một lượng phần mềm khổng lồ mà giờ tôi dùng hằng ngày. Tất cả những dự án tôi hằng mơ mộng nhiều năm, giờ tôi đang dùng — do chính tôi xây. Tôi không viết dòng nào trong đó. Và tôi không thể tưởng tượng việc quay lại tự viết code bằng tay. Tôi khó thấy nó là một phần của tương lai.\n\nGuillermo: Điều thật tuyệt là bạn hiểu các mảnh ghép khớp với nhau thế nào. Bất cứ ai hiểu API là gì, dữ liệu chảy thế nào, đầu vào và đầu ra, hiệu năng — vì bạn phải định hướng model quanh câu “đây là mức kỳ vọng tôi có với thao tác này”. Điều đó luôn hữu ích hơn việc viết code, vô cùng. Một lãnh đạo kỹ thuật giỏi xưa nay vẫn “vibe coding” qua con người trên Slack hoặc trong các buổi một-một — bạn truyền ý chí, ý định, kinh nghiệm của mình và để người khác chạy với nó. Giờ chúng ta làm điều tương tự, nhưng với agent. Đó là lý do bạn thành công với nó. Tôi không chắc ai cũng thấy mức thành công như vậy.\n\nNaval: Tôi đi từ chỗ hai mươi năm không viết code đến chỗ code liên tục — qua agent. Xây rất nhiều phần mềm. Hoá ra chỉ cần hiểu các nguyên lý cơ bản của kỹ thuật phần mềm và thuật toán là đi được một quãng dài. Lý do tôi dừng code là tôi không có thời gian tìm hiểu ngôn ngữ mới nhất, kiến trúc mới nhất, các mảnh hạ tầng để cắm vào. Vercel làm việc đó dễ hơn nhiều, nhưng kể cả vậy — chỉ để bắt đầu đã là một cực hình. Cắm các mảnh vào nhau, lắp hạ tầng, thật sự rất khó chịu.\n\nMax: Điều thật sự thay đổi là — trước đây bạn có thể xây rất nhiều, phần lớn suôn sẻ, nhưng rồi bạn đụng một thứ ngẫu nhiên và có thể mất vô hạn thời gian để gỡ lỗi một chi tiết hẹp. Giờ, với agent, bạn không còn bị kẹt nữa. Điều đó khá kỳ diệu. Chúng tìm ra cách đúng khá nhanh. Trước đây — tôi nhớ khi những người bạn khác thử học lập trình, kiểu như: “Không, nó vốn dĩ gây ức chế. Đó là một phần của cuộc chơi. Đó là cách bạn học.”\n\nVà điều đó giờ không còn đúng nữa.",
      "ai_assisted": true
    },
    {
      "id": "ai-nguon-mo-doc-so-sao-the-nao-cho-dung",
      "url": "https://laban.cc/posts/ai-nguon-mo-doc-so-sao-the-nao-cho-dung",
      "markdown_url": "https://laban.cc/posts/ai-nguon-mo-doc-so-sao-the-nao-cho-dung.md",
      "title": "AI nguồn mở: đọc số sao thế nào cho đúng",
      "summary": "59 dự án trong một lần chụp GitHub. Ba dự án đáng đọc kỹ, ba cái tên có con số không khớp, và cách phân biệt dự án thật với sao được đẩy.",
      "date_published": "2026-10-24T02:29:27.190Z",
      "date_modified": "2026-10-24T02:29:57.696Z",
      "source": {
        "title": "Good AI List (tham khảo ý tưởng)",
        "url": "https://goodailist.com"
      },
      "content_markdown": "Mỗi tuần GitHub sinh ra hàng trăm dự án AI mới. Phần lớn sẽ lặng lẽ dừng ở commit thứ mười. Một số ít thì thật sự thay đổi cách người ta làm việc. Vấn đề là bảng xếp hạng theo sao không phân biệt được hai loại đó — nó chỉ đo sự chú ý, mà sự chú ý thì mua được, đẩy được và thường đến từ một cái tên lớn chứ không từ chất lượng.\n\nBài này là một lần đọc số liệu, không phải một danh sách để lưu. Tôi lấy 59 dự án từ hai chủ đề llm và ai-agents, giới hạn trong các repo tạo ra trong 120 ngày gần nhất, rồi tự hỏi với từng cái: nó giải quyết việc gì, ai đang bảo trì, và con số nào trong hồ sơ của nó không khớp với phần còn lại.\n\n## Ảnh chụp này được lấy thế nào\n\nDữ liệu chụp lúc 01:14 UTC ngày 24 tháng 10 năm 2026, qua GitHub Search API và trang Trending. Mọi con số dưới đây lấy nguyên từ lần chụp đó, không suy diễn, không làm tròn cho đẹp. Đây là lần chụp đầu tiên nên chưa có mức tăng theo ngày hay theo tuần — nghĩa là bài này không nói được cái gì đang tăng nhanh, chỉ nói được cái gì đang đứng ở đâu.\n\n## Sao không đo chất lượng, nhưng ba chỉ số khác thì có\n\nTỷ lệ fork trên sao là chỉ số bị bỏ qua nhiều nhất. Một dự án có người dùng thật sẽ có người fork để sửa, để thử, để nhúng vào việc riêng. Tỷ lệ dưới 3% trên một repo nghìn sao gần như luôn là dấu hiệu của sao được đẩy, chứ không phải của một công cụ đang được dùng.\n\nSố issue mở nói lên nhịp vận hành. Quá ít trên repo lớn thường là issue bị tắt hoặc chuyển sang kênh kín. Quá nhiều thì là dự án đang chuyển động nhanh đến mức API còn đổi — dùng được để học, chưa nên đặt cược kiến trúc.\n\nGiấy phép là thứ quyết định bạn có được dùng nó trong sản phẩm hay không. NOASSERTION, none, hoặc các giấy phép tự chế đều là rủi ro pháp lý, không phải chi tiết hành chính.\n\n## deepseek-harness: plugin không phải là tính năng, mà là kiến trúc\n\nRepo của chính DeepSeek đạt 259.459 sao và 31.330 fork, tỷ lệ 12,1%, giấy phép MIT, viết bằng TypeScript. Nó được tạo ngày 13 tháng 8 năm 2026 — chưa đầy ba tháng — và có commit trong ngày 23 tháng 10.\n\nÝ tưởng trung tâm rất rõ: mọi năng lực của agent là một plugin cắm rút được, kể cả những thứ thường bị viết cứng trong lõi. Nếu đúng như mô tả, đây là câu trả lời cho vấn đề làm agent runtime nào cũng gặp: mỗi lần thêm công cụ lại phải sửa lõi, và lõi càng sửa nhiều càng khó nâng cấp.\n\nĐiều đáng nghi là 0 issue mở trên một repo 259.459 sao. Không có dự án thật nào vận hành sạch đến vậy ở quy mô đó. Nhiều khả năng issue bị đóng tự động hoặc chuyển sang kênh khác. Cũng nên nhớ 259.459 sao trong ba tháng là con số cực đoan, và một phần lớn đến từ việc tên DeepSeek đã có sẵn. Sao ở đây đo mức quan tâm, không đo độ chín.\n\n## NVIDIA/OpenShell: đúng chỗ đau nhất của agent tự trị\n\n18.810 sao, 1.886 fork (10,0%), Apache-2.0, viết bằng Rust, tạo từ tháng 2 năm 2026, commit trong ngày 24 tháng 10. Đây là dự án duy nhất trong nhóm dẫn đầu có lịch sử đủ dài để nói về độ bền.\n\nNó giải quyết câu hỏi mà mọi đội đưa agent lên production đều phải trả lời: agent này được chạm vào những gì. Chạy agent trong môi trường cô lập thay vì tin vào mã do model sinh ra là hướng đúng, và việc NVIDIA làm bằng Rust cho thấy họ nhắm vào tầng hạ tầng chứ không phải bản demo.\n\nNhưng 574 issue mở là con số lớn. Dự án đang thay đổi nhanh, API có thể còn đổi, và nhãn an toàn là tự công bố — chưa có kiểm định độc lập nào về việc cách ly mạnh đến đâu. Dùng để học kiến trúc thì tốt; dùng làm hàng rào bảo mật duy nhất thì chưa.\n\n## open-connector: phần việc nhàm nhất trong mọi agent\n\n6.082 sao, 572 fork (9,4%), Apache-2.0, TypeScript, tạo tháng 6, commit ngày 23 tháng 10, và chỉ 9 issue mở.\n\nNó là cổng xác thực mã nguồn mở nối hàng nghìn dịch vụ SaaS với agent, qua SDK, CLI, MCP, HTTP và OpenAPI. Vấn đề nó giải quyết nghe rất ít hào nhoáng: OAuth, refresh token, phân quyền cho từng dịch vụ. Nhưng đó chính là chỗ mọi dự án agent đều mắc kẹt, vì tự viết lại hàng nghìn luồng xác thực là bất khả thi.\n\nTỷ lệ issue thấp ở đây có thể là dấu hiệu tốt, vì phạm vi hẹp và đã ổn định. Cần cảnh giác ở chỗ khác: một cổng giữ token của nhiều dịch vụ là mục tiêu hấp dẫn. Con số hơn một nghìn năm trăm nhà cung cấp là tự công bố, chưa ai đối chiếu độc lập. Nếu dùng, hãy tự host và tự đọc luồng lưu token trước.\n\n## Ba cái tên mà con số không khớp\n\nFolkbench/folkbench có 3.011 sao nhưng chỉ 14 fork — 0,5%. Giấy phép NOASSERTION, tức không xác định được. Repo tạo ngày 2 tháng 10, tức mới ba tuần. Không có cách nào một dự án ba tuần tuổi có ba nghìn người dùng thật sự fork.\n\nAhmadHassan-BTed/AutoSwarm-Shadow-Adapter còn rõ hơn: 3.010 sao, 2 fork (0,1%). Con số này gần như không thể là tăng trưởng tự nhiên.\n\nTrường hợp thứ ba không phải chuyện sao mà là chuyện rủi ro: Ebony-Vinyl/dsh-our-free-model quảng cáo dùng model frontier miễn phí không giới hạn, không cần API key. Kiểu dịch vụ này gần như chắc chắn vi phạm điều khoản của nhà cung cấp model, và không có gì bảo đảm về dữ liệu bạn gửi qua đó. Không nên dùng trong môi trường thật, dù số sao là bao nhiêu.\n\n## Danh sách theo dõi, chưa đủ chín để giới thiệu\n\nlexmount/moli — trình duyệt headless cho agent, Rust, Apache-2.0, 20.320 sao nhưng chỉ 545 fork (2,7%) và 447 issue mở. Sao tăng nhanh hơn mức cộng đồng thực sự dùng. Đáng xem, chưa đáng đặt cược.\n\ntigerless-labs/agent-memory — bộ nhớ dài hạn cho agent, lấy Markdown làm nguồn sự thật, MIT, 4.556 sao, 200 fork (4,4%). Hướng đúng vì không cần API key và không khoá dữ liệu vào một dịch vụ, nhưng tổ chức còn mới.\n\nzvec-ai/zvec-grep — tìm kiếm local-first cho workspace, Rust, 4.160 sao, 248 fork (6,0%). Cạnh tranh trực diện với một dự án đã có hơn mười bốn nghìn sao; xem ai giữ được nhịp trong hai tháng tới.\n\nsynthetic-sciences/openscience — workbench AI cho nghiên cứu khoa học, 4.243 sao, 533 fork (12,6%), tỷ lệ fork tốt nhất trong nhóm này. Cần thêm bằng chứng về kết quả tái lập được trước khi tin vào các tuyên bố về nghiên cứu.\n\n## Cách đọc bài này, và giới hạn của nó\n\nKhông có mã nguồn nào được tải về hay chạy thử. Mọi nhận định về kiến trúc đều dựa trên mô tả chính thức của dự án, và đó là điểm yếu cố hữu của mọi bài đánh giá dựa trên metadata: người viết mô tả luôn là người lạc quan nhất về sản phẩm của mình.\n\nBài này cũng chưa nói được cái gì đang tăng, vì mới có một lần chụp. Từ tuần sau, khi đã có mốc so sánh, phần đáng đọc nhất sẽ là chỗ số liệu bẻ lại nhận định ở đây. Một dự án tôi khen hôm nay mà ba tuần nữa không có commit nào thì đó mới là thông tin.\n\nCách dùng thực tế nhất: đừng chọn theo thứ hạng. Chọn theo câu hỏi. Việc gì trong tuần của bạn đang làm bằng tay và có thể giao cho một trong những dự án này? Nếu không trả lời được, danh sách hay đến mấy cũng chỉ là để đọc cho vui.\n\nBảng dữ liệu đầy đủ 59 dự án, có cột tỷ lệ fork và license: xem trang dữ liệu.",
      "ai_assisted": true
    },
    {
      "id": "ban-bang-bang-chung",
      "url": "https://laban.cc/posts/ban-bang-bang-chung",
      "markdown_url": "https://laban.cc/posts/ban-bang-bang-chung.md",
      "title": "Bán bằng bằng chứng",
      "summary": "Giúp người đọc hiểu sản phẩm AI làm được việc gì, cần đầu vào nào và còn phần nào phải duyệt. Viết lời hứa vừa với bằng chứng và thử bằng một ca khó.",
      "date_published": "2026-10-22T12:44:38.217Z",
      "date_modified": "2026-10-22T16:14:49.272Z",
      "source": {
        "title": "Sell the Truth",
        "url": "https://nav.al/sell"
      },
      "content_markdown": "Một trang giới thiệu có thể khiến sản phẩm trông rất giỏi mà người đọc vẫn chưa biết mình nên dùng nó vào việc gì. Những câu như làm việc nhanh hơn, tiết kiệm thời gian hay tự động hóa mọi thứ đều dễ đồng ý. Chúng cũng dễ tạo ra những kỳ vọng rất khác nhau.\n\nNgười đang cân nhắc một công cụ cần hình dung được một tình huống sử dụng: mình đưa vào điều gì, nhận lại điều gì và còn phải làm phần nào. Viết rõ các chi tiết ấy là một cách tôn trọng khả năng tự đánh giá của họ.\n\n## Uy tín bắt đầu từ điều có thể giải thích\n\nTrong “Sell the Truth”, đăng ngày 11/05/2026 trên nav.al, Naval đặt sự đáng tin và trung thực ở trung tâm của việc thuyết phục. Ông nhấn mạnh hiểu điều người đối diện muốn, giải thích rõ điều mình tin và chấp nhận khi đề nghị không phù hợp. Bài này phát triển một ứng dụng riêng cho cách giới thiệu sản phẩm AI; ví dụ và quy trình bên dưới do La Bàn xây dựng.\n\nMột lời giới thiệu tốt cần giữ mối liên hệ giữa điều sản phẩm làm được và điều người đọc hiểu rằng nó làm được. Khoảng cách giữa hai thứ ấy càng lớn, công việc giải thích, hỗ trợ và sửa kỳ vọng về sau càng nặng.\n\nMột minh họa cụ thể có thể giúp thu hẹp khoảng cách. Nhưng nó chỉ có ích khi phản ánh một điều kiện sử dụng được nói rõ. Một bản trình diễn được chuẩn bị đẹp chưa tự chứng minh rằng mọi dữ liệu thật đều sẽ tạo ra kết quả tương tự.\n\n## Chọn một lời hứa đủ hẹp để kiểm tra\n\nHãy xét một sản phẩm giả định giúp người bán hàng soạn bản nháp trả lời các câu hỏi thường gặp. Một lời giới thiệu rộng có thể nói công cụ sẽ tự động chăm sóc khách hàng. Người đọc có thể hiểu rằng nó tiếp nhận yêu cầu, kiểm tra trạng thái đơn, quyết định phương án và gửi câu trả lời mà không cần người xem lại.\n\nNếu sản phẩm thực tế chỉ gợi ý nội dung từ một tập thông tin được cung cấp, lời giới thiệu cần nói được đúng phần việc ấy. Chẳng hạn: tạo bản nháp trả lời dựa trên tài liệu của cửa hàng, kèm đoạn nguồn để người bán kiểm tra trước khi gửi.\n\nLời hứa hẹp hơn giúp xác định ai phù hợp. Người cần giảm thời gian viết những câu trả lời lặp lại có thể quan tâm. Người cần một hệ thống tự xử lý toàn bộ đơn hàng sẽ biết mình phải tìm hiểu thêm hoặc chọn một cách khác.\n\nĐây cũng là bước kiểm tra thiết kế. Nếu nhóm chưa thể viết một lời hứa cụ thể mà không dùng nhiều từ bao trùm, có thể bản thân phạm vi sản phẩm còn chưa được hiểu thống nhất.\n\n## Cho thấy cả đầu vào lẫn phần việc còn lại\n\nMột bản trình diễn nên bắt đầu từ dữ liệu mà người dùng có thể nhận ra. Trong ví dụ trên, có thể dùng một chính sách giao hàng giả định và một câu hỏi về việc đổi địa chỉ. Hiển thị câu hỏi, tài liệu được tham chiếu, bản nháp tạo ra và phần người bán cần xác nhận.\n\nNếu câu trả lời phụ thuộc vào trạng thái đơn hàng mà công cụ chưa được kết nối, cần thể hiện điểm thiếu đó. Một bản nháp có chỗ yêu cầu người dùng kiểm tra thông tin thực tế sẽ giúp họ hiểu rõ giới hạn hơn một câu trả lời trôi chảy nhưng tự điền phần chưa biết.\n\nCũng nên nói đến bước chuẩn bị. Người mua cần nhập tài liệu bằng cách nào? Khi chính sách đổi, họ cập nhật ở đâu? Ai xem lại kết quả trước khi dùng? Những bước này ảnh hưởng trực tiếp đến việc công cụ có phù hợp với nhịp vận hành của họ hay không.\n\nĐầu ra chỉ là một phần của trải nghiệm. Một công cụ tạo bản nháp trong vài giây nhưng cần dữ liệu được chuẩn bị thủ công cả buổi có thể vẫn hữu ích, nhưng giá trị ấy cần được hiểu trong toàn bộ quy trình.\n\n## Bằng chứng mạnh đến đâu thì kết luận đến đó\n\nMột ví dụ minh họa cho thấy sản phẩm có thể hoạt động trong tình huống đã chọn. Một bộ tình huống đa dạng giúp hiểu thêm phạm vi và lỗi. Một đợt sử dụng thực tế mới có thể cung cấp dữ liệu về hành vi, công sức và những điều phát sinh trong môi trường của người dùng.\n\nBa mức ấy trả lời ba nhóm câu hỏi khác nhau. Nếu mới có ví dụ, có thể mô tả rõ ví dụ đó. Nếu chưa đo thời gian trước và sau trên những công việc tương đương, một con số phần trăm tiết kiệm sẽ tạo ra mức chắc chắn vượt quá bằng chứng đang có.\n\nVới một phép đo, cần biết đã tính cả thời gian chuẩn bị và kiểm tra chưa, ai thực hiện, những trường hợp thất bại có bị bỏ ra ngoài không. Các chi tiết ấy không nhất thiết phải chiếm hết trang giới thiệu, nhưng người đọc cần có cách tìm hiểu căn cứ của một tuyên bố quan trọng.\n\nMột kết luận vừa với bằng chứng thường bền hơn khi sản phẩm được đưa vào sử dụng. Nó cũng giúp đội ngũ biết cần đo điều gì tiếp theo, thay vì liên tục nghĩ thêm những câu gây ấn tượng.\n\n## Một ca khó có thể làm bản trình diễn đáng tin hơn\n\nVới công cụ trả lời khách hàng giả định, hãy thêm một câu hỏi mà tài liệu chưa có thông tin. Cho thấy công cụ xử lý khoảng trống ấy ra sao và người dùng cần làm gì tiếp. Nếu phiên bản hiện tại chưa xử lý tốt, nói rõ đó là giới hạn đang được xem xét.\n\nMột ca khó không nên được chọn chỉ để trình diễn một lỗi dễ sửa. Nó cần đại diện cho tình huống người sử dụng thật có thể gặp: dữ liệu cũ, hai nguồn mâu thuẫn, một yêu cầu nằm ngoài quy trình thường ngày. Cách sản phẩm bộc lộ giới hạn là một phần của chất lượng sử dụng.\n\nNgười đọc có thể từ đó tự nhận ra mức giám sát cần thiết. Đồng thời, nhóm xây dựng cũng có một cuộc trò chuyện cụ thể hơn với họ: loại trường hợp nào đáng ưu tiên, mức kiểm tra nào chấp nhận được và công việc nào chưa nên giao cho công cụ.\n\n## Thử xem người đọc đang hiểu lời hứa nào\n\nSau khi viết lại trang giới thiệu, nhờ một người thuộc nhóm sử dụng dự kiến đọc nó mà chưa được bạn giải thích miệng. Sau đó hỏi họ sản phẩm giúp xử lý việc gì, cần chuẩn bị gì và lúc nào vẫn cần người can thiệp.\n\nNếu câu trả lời khác với khả năng thực tế, đó là một vấn đề cần sửa trong nội dung hoặc trong thiết kế sản phẩm. Chẳng hạn, từ tự động ở đầu trang có thể lấn át một ghi chú nhỏ về việc duyệt bản nháp ở phía dưới. Thêm nhiều chữ chưa chắc giúp; có thể cần thay đúng một lời hứa gây hiểu nhầm.\n\nNhững câu người đọc hỏi lại cũng có giá trị. Chúng cho biết thông tin nào ảnh hưởng đến quyết định của họ mà trang chưa trả lời. Một câu hỏi về việc cập nhật tài liệu có thể quan trọng hơn thêm một ảnh giao diện đẹp.\n\n## Sẵn sàng nói rõ khi chưa phù hợp\n\nMột sản phẩm có thể được làm tốt và vẫn chưa phù hợp với một hoàn cảnh cụ thể. Người dùng có thể cần tích hợp mà công cụ chưa hỗ trợ, mức chính xác chưa đạt hoặc cách triển khai mà nhóm chưa thể duy trì. Nói rõ điều ấy giúp cả hai bên hiểu lựa chọn trước mặt.\n\nĐiều cần giữ là sự nhất quán giữa trang giới thiệu, cuộc trao đổi trước khi dùng và trải nghiệm sau đó. Nếu mỗi nơi kể một câu chuyện khác nhau, sự tin tưởng sẽ phải được xây lại trong từng lần hỗ trợ.\n\nBạn có thể bắt đầu bằng một lần rà lại trang hiện tại: chọn lời hứa quan trọng nhất, viết căn cứ đang có bên cạnh và hỏi người đọc sẽ hiểu đến đâu. Nếu khoảng cách còn lớn, thu hẹp lời hứa hoặc làm thêm công việc để có bằng chứng. Đó là một bước thực tế để sản phẩm được lựa chọn vì đúng việc nó phục vụ.",
      "ai_assisted": true
    },
    {
      "id": "nguoi-it-tieu-chuan-ro",
      "url": "https://laban.cc/posts/nguoi-it-tieu-chuan-ro",
      "markdown_url": "https://laban.cc/posts/nguoi-it-tieu-chuan-ro.md",
      "title": "Người ít, tiêu chuẩn rõ",
      "summary": "Khi agent tạo đầu ra nhanh hơn, cộng sự càng cần rõ ai quyết định, ai kiểm tra và điều gì được xem là đủ tốt. Một cách phối hợp cho nhóm nhỏ.",
      "date_published": "2026-10-22T12:44:38.207Z",
      "date_modified": "2026-10-22T16:14:49.254Z",
      "source": {
        "title": "Curate People",
        "url": "https://nav.al/curate-people"
      },
      "content_markdown": "Hai người có thể làm việc với nhiều agent mà vẫn liên tục chờ nhau. Bản nháp đã có, thiết kế đã xong, mã đã chạy, nhưng một câu hỏi quan trọng chưa được trả lời: ai quyết định thứ này đã đủ tốt để đưa ra sử dụng?\n\nKhi công cụ tạo đầu ra nhanh hơn, những điểm mơ hồ trong phối hợp có thể hiện ra rõ hơn. Một nhóm nhỏ cần hiểu mình cùng chịu trách nhiệm cho kết quả nào, khác nhau ở quyền quyết định nào và sẽ làm gì khi không đồng ý với nhau.\n\n## Con người vẫn định hình cách công việc được làm\n\nTrong “Curate People” trên nav.al, ngày 07/11/2025, Naval xem những người đầu tiên là yếu tố quan trọng định hình công ty. Ông đề cao năng lực, động lực, sự chính trực và cái tôi thấp trong cộng tác. Nguồn bàn về tuyển dụng và văn hóa; bài này phát triển một góc hẹp hơn: cách các cộng sự làm rõ tiêu chuẩn và trách nhiệm trong dự án nhỏ có dùng AI.\n\nCó nhiều đầu ra hơn chưa giải quyết được việc nên chọn đầu ra nào. Một agent có thể giúp liệt kê phương án, viết bản nháp hoặc chỉ ra sự không nhất quán. Cộng sự vẫn cần hiểu hoàn cảnh của nhau và thỏa thuận ai đưa ra lựa chọn cuối cùng khi các tiêu chí xung đột.\n\nMột người muốn giao nhanh để nhận phản hồi. Người kia muốn sửa thêm vì đã hứa một mức chất lượng với người dùng. Cả hai có thể đang bảo vệ một điều hợp lý. Nếu chỉ nhìn số việc hoàn tất, ta sẽ bỏ lỡ bất đồng thật đang nằm dưới lịch công việc.\n\n## Phân biệt vai trò với trách nhiệm cụ thể\n\nNhững tên gọi như phụ trách sản phẩm, phụ trách kỹ thuật hay vận hành thường quá rộng đối với một tình huống đang xảy ra. Chúng chưa trả lời ai được đổi phạm vi, ai xác nhận dữ kiện và ai cần có mặt nếu người dùng gặp vấn đề.\n\nXét một nhóm hai người làm một trang thông tin cho cộng đồng địa phương. Một người hiểu nhu cầu người đọc, người còn lại xây website cùng agent. Khi có thay đổi về thời gian một hoạt động, người làm kỹ thuật có thể cập nhật rất nhanh. Nhưng tốc độ cập nhật không thay thế được việc xác nhận thông tin từ người có trách nhiệm về hoạt động.\n\nTrong tình huống giả định ấy, nhóm có thể thỏa thuận: người phụ trách nội dung xác nhận dữ kiện và cho phép công khai; người phụ trách kỹ thuật bảo đảm bản cập nhật hiển thị đúng, liên kết mở được và có cách khôi phục. Một việc đã rõ hơn khi mỗi người biết phần nào mình có thể tự làm và phần nào cần chờ xác nhận.\n\n## Viết tiêu chuẩn để hai người có thể cùng kiểm tra\n\n“Làm cho tốt” là một mong muốn, chưa phải tiêu chuẩn dùng chung. Với trang thông tin trên, hai người có thể cần thống nhất thế nào là đủ thông tin: tên hoạt động, địa điểm, thời gian, người liên hệ và mốc xác nhận gần nhất. Phần hiển thị cần dễ đọc trên điện thoại và thể hiện rõ khi nội dung đã thay đổi.\n\nMột tiêu chuẩn hữu ích phải gắn với mục đích. Nếu phần lớn người đọc cần tìm đường đến địa điểm, một ảnh trang trí đẹp chưa bù được địa chỉ không rõ. Nếu người vận hành cần tự cập nhật mỗi tuần, một giao diện chỉ người xây hiểu sẽ tạo thêm sự phụ thuộc.\n\nTiêu chuẩn cũng cần có thứ tự ưu tiên. Khi thời gian hạn chế, thông tin đúng và đường dẫn hoạt động có thể quan trọng hơn một hiệu ứng mới. Viết thứ tự ấy trước giúp việc chọn bớt phạm vi bớt mang tính cá nhân.\n\nĐây không phải một hợp đồng cứng khiến nhóm hết linh hoạt. Nó là một điểm tựa để hai người nhận ra khi nào mình đang nói về cùng một chất lượng và khi nào cần thương lượng lại.\n\n## Đánh giá cộng tác qua một việc đủ nhỏ và đủ thật\n\nMột cuộc trao đổi dễ chịu chưa cho biết cách hai người sẽ phối hợp khi có đầu vào thiếu, thời gian gấp hoặc một lỗi cần nhận trách nhiệm. Một phần việc nhỏ, có phạm vi được cả hai chấp nhận, tạo cơ hội quan sát những điều ấy mà chưa buộc dự án gánh một cam kết quá rộng.\n\nTrong ví dụ, hai người có thể cùng hoàn tất một lần cập nhật thông tin từ đầu đến cuối. Ai hỏi lại khi dữ kiện thiếu? Ai ghi rõ điều đã thay đổi? Khi phát hiện lỗi, họ cùng tìm nguyên nhân hay chỉ tìm cách chứng minh phần việc của mình đã đúng?\n\nCần xem cả hoàn cảnh thay vì vội gắn nhãn một con người từ một lần làm việc. Người nhận yêu cầu mơ hồ, thiếu thời gian hoặc không có quyền tiếp cận dữ liệu sẽ khó tạo đầu ra như mong muốn. Một thử nghiệm cộng tác tốt cũng kiểm tra chất lượng của cách giao việc và hỗ trợ lẫn nhau.\n\nĐiều đáng tìm là khả năng trao đổi về công việc một cách cụ thể: đây là điều đã hiểu, đây là phần còn thiếu, đây là căn cứ cho lựa chọn hiện tại và đây là lúc cần nhờ người khác cùng xem.\n\n## Dùng agent để chuẩn bị cho bất đồng\n\nKhi hai cộng sự không đồng ý về một phương án, agent có thể giúp viết lại các lựa chọn và hệ quả cần xem xét. Nó có thể nhắc nhóm liệt kê giả định hoặc tìm những chỗ hai người đang dùng cùng một từ với nghĩa khác nhau.\n\nTuy nhiên, việc nhờ agent đứng về một phía thường chỉ làm cuộc trao đổi có thêm một bản lập luận trau chuốt. Giá trị hơn là yêu cầu nó trình bày mạnh nhất cả hai phương án, chỉ ra dữ kiện đang thiếu và đề xuất một phép thử nhỏ có thể phân biệt chúng.\n\nChẳng hạn, nếu một người muốn thêm chatbot còn người kia muốn giữ trang tra cứu đơn giản, nhóm có thể quan sát người đọc tìm ba thông tin bằng bản hiện tại. Kết quả thử không quyết định thay nhóm, nhưng giúp bất đồng bám vào một hành vi có thể nhìn thấy.\n\n## Ghi lại quyết định, kể cả điều làm mình đổi ý\n\nMột ghi chép quyết định ngắn có thể gồm vấn đề đang giải quyết, phương án được chọn, lý do, người quyết định và dấu hiệu khiến nhóm cần xem lại. Nó đặc biệt hữu ích khi dự án có nhiều phần việc được giao cho agent, vì lịch sử các lần yêu cầu sửa thường rất dài.\n\nKhi một phương án không còn phù hợp, nhóm sẽ biết mình đang cập nhật vì có thông tin mới hay vì đã quên lý do cũ. Điều này giúp tránh những vòng tranh luận quay lại từ đầu mỗi khi có một công cụ mới hoặc một người mới tham gia.\n\nGhi lại cả phần chưa chắc cũng làm cho việc nhận lỗi bớt nặng. Quyết định từng hợp lý với thông tin có lúc đó vẫn có thể cần thay đổi. Sự chính trực trong cộng tác thể hiện ở việc làm rõ sự thay đổi ấy và cùng xử lý hậu quả, thay vì sửa lại câu chuyện như thể mình luôn biết trước.\n\n## Một nhóm nhỏ đáng tin trông như thế nào?\n\nCó thể bắt đầu bằng những điều quan sát được: mọi người biết ai cần tham gia quyết định; đầu ra có người kiểm tra; thông tin chưa chắc được nói rõ; một lỗi có đường xử lý; và bất đồng có thể được bàn bằng căn cứ cụ thể.\n\nCác thỏa thuận ấy không làm biến mất khác biệt về tính cách hoặc năng lực. Chúng giúp những khác biệt trở nên dễ hiểu hơn trong công việc. Nhóm cũng biết lúc nào cần thêm hiểu biết từ bên ngoài, thay vì buộc một trong hai người đóng vai chuyên gia cho mọi vấn đề.\n\nKhi agent giúp tạo ra nhiều hơn, giá trị của cộng sự có thể càng nằm ở khả năng cùng chọn điều đáng làm và chịu trách nhiệm đến cùng. Người ít vẫn cần một cách phối hợp đủ rõ để mỗi người có thể tin vào phần việc của người còn lại.",
      "ai_assisted": true
    },
    {
      "id": "hoc-agent-bang-mot-viec-that",
      "url": "https://laban.cc/posts/hoc-agent-bang-mot-viec-that",
      "markdown_url": "https://laban.cc/posts/hoc-agent-bang-mot-viec-that.md",
      "title": "Học agent bằng một việc thật",
      "summary": "Một dự án nhỏ chỉ giúp ta học khi có phản hồi rõ. Chọn đầu ra kiểm chứng được, xây bộ câu hỏi và tìm đúng lớp gây lỗi trước khi đổi công cụ.",
      "date_published": "2026-10-22T12:44:38.196Z",
      "date_modified": "2026-10-22T16:14:49.236Z",
      "source": {
        "title": "A Motorcycle for the Mind",
        "url": "https://nav.al/ai"
      },
      "content_markdown": "Bạn có thể dành nhiều buổi đọc về agent mà vẫn thấy khó bắt đầu một việc cụ thể. Thuật ngữ đã quen, tên công cụ đã nhớ, nhưng khi gặp một đầu vào lộn xộn hoặc một kết quả sai, bạn chưa biết nên sửa phần nào.\n\nĐó không nhất thiết là dấu hiệu học chưa đủ. Có thể điều đang thiếu là một vòng phản hồi: đặt ra một đầu ra, thử tạo nó, nhìn chỗ sai và thay đổi cách làm. Một dự án đủ nhỏ để đi hết vòng ấy có thể giúp kiến thức tìm được chỗ đứng trong công việc.\n\n## Học qua việc làm cần có phản hồi\n\nTrong “A Motorcycle for the Mind”, đăng ngày 19/02/2026 trên nav.al, Naval nhấn mạnh việc xây dựng và tiếp xúc với phản hồi thực tế. Cuộc trò chuyện cũng bàn về cách coding agent chuyển mô tả cùng phản hồi thành ứng dụng. Từ điểm gợi mở này, La Bàn phát triển một cách học qua dự án nhỏ; tình huống và quy trình dưới đây là phân tích riêng.\n\nTự tay làm một việc chưa bảo đảm sẽ học được nhiều. Nếu không kiểm tra kết quả hoặc không biết tiêu chí đúng, bạn có thể lặp lại cùng một sai lầm trong nhiều dự án. Giá trị của thực hành nằm ở việc nhìn ra khoảng cách giữa điều mình nghĩ sẽ xảy ra và điều đã thực sự xảy ra.\n\nVì thế, một bài tập tốt cần có đầu ra đủ rõ để đánh giá, dữ liệu đủ gần để bạn kiểm chứng và phạm vi đủ nhỏ để sửa thêm một vòng. Một vấn đề quá lớn dễ khiến thất bại trở thành một cảm giác chung chung: mọi thứ đều khó và không biết bắt đầu điều chỉnh từ đâu.\n\n## Chọn một việc có thể nhìn thấy điểm kết thúc\n\nHãy xét một tình huống giả định: bạn có một tập ghi chú công khai dùng để hướng dẫn thành viên mới trong một nhóm cộng đồng. Mọi người thường hỏi lại các câu về lịch sinh hoạt, cách đăng ký và nơi tìm tài liệu. Bạn muốn thử một trang tra cứu nhỏ.\n\nMục tiêu có thể là giúp người mới tìm được thông tin trong đúng tập ghi chú ấy, có đường dẫn về đoạn gốc và thấy rõ khi dữ liệu chưa đủ. Mục tiêu này nhỏ hơn việc tạo một trợ lý biết mọi thứ về hoạt động của nhóm. Nó cũng cho bạn một tập kết quả có thể kiểm tra trực tiếp.\n\nVòng đầu chỉ cần một cách nhập câu hỏi và một cách trình bày kết quả. Đăng nhập, cá nhân hóa, giọng nói và thiết kế nhiều màn hình có thể chờ. Khi những phần ấy xuất hiện quá sớm, thời gian làm đẹp sản phẩm dễ lấn át thời gian tìm hiểu xem công cụ có trả lời đúng hay không.\n\n## Viết bộ câu hỏi trước khi xem bản trình diễn\n\nChuẩn bị một nhóm câu hỏi mà ghi chú có câu trả lời rõ. Tiếp đó là những câu chắc chắn chưa có dữ liệu. Cuối cùng là các câu mơ hồ: cùng một tên hoạt động nhưng ở hai thời điểm, hoặc một câu cần hỏi thêm người dùng mới biết họ muốn gì.\n\nChẳng hạn, tài liệu chỉ ghi lịch buổi tháng trước. Một câu hỏi về buổi sắp tới cần được nhận diện là thiếu thông tin mới, thay vì dùng lại ngày cũ với giọng chắc chắn. Với câu hỏi có câu trả lời, đường dẫn nguồn phải thực sự dẫn tới phần hỗ trợ cho kết luận.\n\nViết các trường hợp này trước giúp bạn đánh giá bản đầu bằng cùng một tiêu chuẩn. Nếu chỉ nghĩ ra câu hỏi sau khi thấy giao diện đẹp, ta dễ chọn những câu mà công cụ đang trả lời tốt và bỏ qua phần còn yếu.\n\nBộ câu hỏi không cần lớn. Nó cần đại diện cho những kiểu sử dụng khác nhau. Mỗi khi có một lỗi đáng nhớ, thêm trường hợp ấy vào bộ kiểm tra để lần chỉnh sau còn nhìn thấy nó.\n\n## Đọc một lỗi theo từng lớp\n\nGiả sử công cụ trả lời sai địa điểm sinh hoạt. Có nhiều nguyên nhân có thể tạo ra cùng một biểu hiện. Ghi chú đầu vào có thể đã cũ. Công cụ có thể lấy nhầm tài liệu. Nó có thể tìm đúng đoạn nhưng diễn giải sai. Hoặc giao diện hiển thị kết quả từ câu hỏi trước đó.\n\nMỗi nguyên nhân cần một cách sửa khác nhau. Dữ liệu cũ cần được cập nhật hoặc gắn mốc thời gian. Lấy nhầm tài liệu cần xem lại cách tìm kiếm và lựa chọn nguồn. Diễn giải sai cần xem cách đặt câu hỏi, ngữ cảnh và tiêu chí trả lời. Lỗi giao diện cần được kiểm tra như một lỗi phần mềm.\n\nGọi tất cả những tình huống ấy là mô hình chưa đủ thông minh sẽ khiến bạn khó học. Tương tự, cứ thêm chỉ dẫn dài hơn vào lời nhắc có thể làm quy trình nặng lên mà không chạm vào chỗ hỏng.\n\nMột thói quen hữu ích là lưu lại đầu vào, kết quả nhận được, kết quả mong đợi và căn cứ để biết kết quả mong đợi là đúng. Bốn phần đó biến một lời than phiền thành một trường hợp có thể cùng agent điều tra.\n\n## Thay một điều rồi chạy lại cả bộ\n\nSau khi có vài lỗi, ta thường muốn sửa cùng lúc mọi thứ: đổi mô hình, viết lại lời nhắc, thêm dữ liệu và thay giao diện. Nếu kết quả tốt hơn, bạn sẽ khó biết thay đổi nào tạo ra khác biệt. Nếu kém đi, việc tìm đường quay lại cũng khó hơn.\n\nTrong giai đoạn học, hãy chọn một giả thuyết. Ví dụ: công cụ đang nhầm vì tài liệu không có ngày cập nhật rõ ràng. Bổ sung ngày vào dữ liệu mẫu, giữ các yếu tố khác tương đối ổn định rồi chạy lại bộ câu hỏi. Quan sát cả câu từng sai và câu từng đúng.\n\nKết quả cũng có thể bác bỏ giả thuyết của bạn. Việc thêm ngày không giúp công cụ chọn đúng nguồn là thông tin có ích: cần tìm một nguyên nhân khác. Học qua thực hành đòi hỏi sẵn sàng từ bỏ lời giải thích đầu tiên của chính mình.\n\n## Nhờ một người dùng mà không đứng cạnh chỉ đường\n\nNgười xây hiểu sẵn công cụ nên rất giỏi tránh những chỗ nó gây khó. Một người mới sẽ hỏi bằng từ khác, dán một đoạn dài hơn hoặc bỏ qua hướng dẫn mà bạn nghĩ rất rõ. Những hành vi ấy giúp kiểm tra cách mình đã hình dung người dùng.\n\nVới bản thử trong ví dụ, có thể nhờ một thành viên tự tìm ba thông tin. Quan sát lúc họ dừng, quay lại hoặc hỏi thêm. Họ không biết phải nhập gì? Không hiểu phần nguồn dẫn? Hay thấy câu trả lời đúng nhưng chưa biết bước tiếp theo?\n\nÝ kiến “trông đẹp” hoặc “có vẻ hữu ích” chưa cho nhiều hướng sửa. Một hành vi cụ thể như liên tục mở tài liệu gốc vì không tin phần trả lời cho biết rõ hơn điều cần kiểm tra. Đồng thời, bạn có thể nhận ra trang tìm kiếm đơn giản đã phục vụ đủ nhu cầu, chưa cần một cuộc trò chuyện nhiều bước.\n\n## Mang điều đã học sang việc tiếp theo\n\nKhi kết thúc một vòng, đừng chỉ lưu đường dẫn sản phẩm. Ghi lại điều gì làm kết quả tốt hơn, điều gì đã thử mà không giúp và bạn biết được giới hạn nào của dữ liệu hoặc cách kiểm tra.\n\nMột dự án nhỏ có thể dạy rằng thông tin cần mốc thời gian, rằng câu trả lời nên đi cùng nguồn hoặc rằng điều kiện thiếu dữ liệu phải được thể hiện rõ. Những bài học đó có thể tiếp tục hữu ích khi công cụ, mô hình và giao diện đã thay đổi.\n\nBạn chưa cần chọn một lộ trình học hoàn hảo. Chỉ cần một việc đủ gần để kiểm chứng, một vòng đủ ngắn để hoàn tất và sự kiên nhẫn nhìn thẳng vào chỗ kết quả chưa đúng. Đó là nơi việc học bắt đầu bám vào thực tế.",
      "ai_assisted": true
    },
    {
      "id": "xay-cong-cu-cho-chinh-minh",
      "url": "https://laban.cc/posts/xay-cong-cu-cho-chinh-minh",
      "markdown_url": "https://laban.cc/posts/xay-cong-cu-cho-chinh-minh.md",
      "title": "Xây công cụ cho chính mình",
      "summary": "Từ một bất tiện cụ thể đến một công cụ đáng giữ lại: mô tả tình huống sử dụng, thử trong công việc thật và tính cả quyền rời đi lẫn công sức chăm sóc.",
      "date_published": "2026-10-22T12:44:38.184Z",
      "date_modified": "2026-10-22T16:14:49.217Z",
      "source": {
        "title": "A Return to Code",
        "url": "https://nav.al/code"
      },
      "content_markdown": "Một ý tưởng ứng dụng thường bắt đầu từ một lần thấy bất tiện: tìm mãi không ra ghi chú cũ, quên lý do đã chọn một phương án, hay phải nhập lại cùng một thông tin. Khi việc tạo phần mềm dễ tiếp cận hơn, khoảng cách từ sự bất tiện đến một giao diện chạy được có thể rất ngắn.\n\nKhoảng cách từ giao diện ấy đến một thói quen sử dụng bền vững lại là câu chuyện khác. Bạn có thể thích cảm giác xây dựng hơn chính công cụ vừa xây. Nhận ra sự khác nhau đó sẽ giúp dự án cá nhân giữ được giá trị sau buổi hứng khởi đầu tiên.\n\n## Nhu cầu riêng xứng đáng được mô tả cho rõ\n\nTrong “A Return to Code” trên nav.al, ngày 28/04/2026, Naval kể về việc trở lại lập trình với coding agent và tạo ứng dụng cho nhu cầu của mình. Ông phân biệt công cụ tùy biến cá nhân với những sản phẩm phổ thông được chăm chút cho nhiều người dùng. Từ điểm gợi mở ấy, La Bàn bàn về cách xác định, thử và duy trì một công cụ nhỏ; các tình huống dưới đây là minh họa độc lập.\n\nLợi thế khi xây cho mình là được tiếp xúc trực tiếp với vấn đề. Bạn biết thời điểm nó xuất hiện, cách mình đang xoay xở và mức khó chịu đủ để muốn thay đổi. Nhưng sự gần gũi cũng tạo ra một điểm mù: những điều bạn làm theo thói quen thường không được nói ra khi mô tả sản phẩm.\n\nMột yêu cầu như “làm ứng dụng ghi chú tốt hơn” chưa giúp chọn thiết kế. Một mô tả như “trước buổi trao đổi với khách, tôi cần tìm lại quyết định gần nhất và lý do đã đưa ra” cho thấy cả thời điểm, thông tin cần có và kết quả mong muốn.\n\n## Đi theo một tình huống, đừng bắt đầu từ danh sách tính năng\n\nHãy hình dung một người làm dự án tự do thường đồng thời trao đổi với vài khách hàng. Họ có ghi chú trong nhiều cuộc trò chuyện, nhưng mỗi lần quay lại một dự án lại phải nhớ vì sao trước đó đã bỏ một phương án. Đây là tình huống giả định để làm rõ cách thiết kế.\n\nMột công cụ dành cho tình huống ấy có thể bắt đầu bằng ba trường: quyết định, lý do và lúc nào cần xem lại. Luồng sử dụng là mở dự án, đọc quyết định gần nhất rồi ghi một thay đổi nếu có. Danh bạ, lịch họp, quản lý hợp đồng và mạng xã hội chưa giúp giải quyết chỗ vướng đang được mô tả.\n\nPhạm vi nhỏ không chỉ giúp xây nhanh. Nó làm cho thất bại dễ đọc hơn. Nếu người dùng vẫn không mở công cụ trước cuộc họp, ta có thể hỏi liệu thông tin không đủ hữu ích, thao tác nhập quá nặng hay công cụ xuất hiện sai thời điểm. Với một sản phẩm chứa quá nhiều chức năng, tín hiệu ấy dễ bị che khuất.\n\n## Biến lời nhắc thành một cuộc trao đổi về thiết kế\n\nKhi nhờ agent triển khai, hãy đưa tình huống và ví dụ trước hình thức giao diện. Một bản mô tả có thể nói: người dùng cần xem quyết định mới nhất của một dự án trong một màn hình; mỗi quyết định lưu lý do, ngày ghi và dấu hiệu khiến nó cần được xem lại; dữ liệu mẫu gồm một quyết định đã đổi và một quyết định vẫn còn hiệu lực.\n\nTiếp đó, yêu cầu agent chỉ ra những câu hỏi chưa được trả lời. Có cần lịch sử chỉnh sửa? Một quyết định có thể gắn với nhiều dự án không? Có thực sự cần đồng bộ giữa thiết bị hay giai đoạn đầu chỉ sử dụng ở một nơi? Các câu trả lời sẽ ảnh hưởng đến mức phức tạp cần gánh.\n\nĐây là lúc nên nói rõ điều sẽ chưa làm. Một nguyên mẫu cá nhân có thể chưa cần tài khoản, phân quyền nhiều người hoặc bảng điều khiển tổng hợp. Việc giữ phạm vi là một quyết định sản phẩm, không phải một thiếu sót cần được sửa bằng cách thêm tính năng ngay.\n\n## Thử trong đúng lúc công cụ đáng lẽ phải hữu ích\n\nDùng thử ngay sau khi xây thường cho cảm giác tốt, vì mọi chi tiết còn ở trong trí nhớ. Bài kiểm tra có ý nghĩa hơn xuất hiện vài ngày sau, khi bạn đang bận và vấn đề thật quay lại. Bạn có tự nhớ đến công cụ không? Mở nó có nhanh hơn cách đang làm không? Đọc lại thông tin có giúp quyết định rõ hơn không?\n\nTrong ví dụ trên, hãy dùng công cụ trước vài cuộc trao đổi thật. Ghi lại những lần bạn bỏ qua nó, thay vì chỉ đếm những bản ghi đã tạo. Nếu người dùng vẫn tìm trong lịch sử tin nhắn, có thể công cụ đang thiếu một chi tiết quan trọng hoặc phải đi qua quá nhiều bước để mở.\n\nMỗi vòng chỉ cần sửa điểm cản trở lớn nhất. Thêm biểu đồ không giải quyết được một ô nhập liệu khó dùng. Thay màu sắc không bù được việc dữ liệu bị mất khi đóng cửa sổ. Quan sát một lần vấp cụ thể thường cho hướng sửa rõ hơn một buổi tự nghĩ thêm tính năng.\n\n## Quyền rời đi cũng là một phần của thiết kế\n\nMột công cụ cá nhân sẽ giữ những dữ liệu ngày càng có giá trị với người sử dụng. Vì thế, khả năng lấy dữ liệu ra cần được nghĩ đến sớm. Nếu tuần sau muốn đổi công cụ, bạn có thể mang theo các quyết định và lý do của mình dưới một định dạng đọc được không?\n\nBản thử cũng nên giúp phân biệt dữ liệu đã lưu với dữ liệu chỉ đang hiển thị. Có thể kiểm tra bằng thông tin mẫu: tạo một bản ghi, đóng ứng dụng, mở lại, sửa và xuất ra tệp. Một giao diện thuyết phục chưa nói được điều gì về độ bền của dữ liệu bên dưới.\n\nVới thông tin của khách hàng hoặc người khác, hãy chọn cách lưu và công cụ phù hợp với thỏa thuận sử dụng dữ liệu của mình. Một bản thử bằng dữ liệu giả thường đã đủ để kiểm tra luồng chính, trước khi quyết định có nên đưa thông tin thật vào hay không.\n\n## Tự xây, dùng sản phẩm có sẵn hay tiếp tục với ghi chú?\n\nTự xây hợp lý khi nhu cầu có một nét riêng quan trọng mà cách hiện tại phục vụ kém. Một sản phẩm có sẵn có thể phù hợp hơn nếu nó đã làm tốt việc cốt lõi và bạn cần sự ổn định, đồng bộ hoặc khả năng cộng tác mà mình chưa muốn duy trì.\n\nCòn nếu vấn đề chỉ xuất hiện hiếm và một biểu mẫu ghi chú đã giải quyết được, việc dùng biểu mẫu ấy có thể là lựa chọn nhẹ nhất. Số dòng mã đã tạo ra không làm cho ứng dụng trở nên cần thiết hơn.\n\nCũng nên tính phần chăm sóc về sau. Khi có lỗi, bạn có đủ hiểu để mô tả lại và kiểm tra cách sửa không? Khi một thư viện thay đổi, ai sẽ dành thời gian cập nhật? Nếu bỏ dự án một tháng, bạn có thể quay lại từ một hướng dẫn ngắn không? Những câu hỏi ấy thuộc về sản phẩm ngay từ đầu.\n\n## Một tiêu chuẩn nhỏ để giữ hoặc dừng\n\nTrước khi bắt đầu, viết một điều sẽ khiến bạn giữ công cụ sau một tuần. Chẳng hạn: trước mỗi cuộc họp, tìm được quyết định cần nhớ mà không phải lục lại nhiều nơi. Đây là một hành vi có thể quan sát, gần với vấn đề ban đầu.\n\nCuối tuần, xem lại những lần dùng, những lần bỏ qua và công sức cần để giữ dữ liệu cập nhật. Nếu công cụ chưa giúp ích, bạn có thể thu nhỏ, đổi cách tiếp cận hoặc dừng. Dừng một nguyên mẫu không cần thiết giúp giữ thời gian cho một vấn đề đáng làm hơn.\n\nCông cụ tốt cho chính mình thường không bắt đầu bằng tham vọng phục vụ mọi người. Nó bắt đầu từ việc hiểu thật rõ một khoảnh khắc trong ngày, rồi làm cho khoảnh khắc ấy bớt vướng víu.",
      "ai_assisted": true
    },
    {
      "id": "bien-quy-trinh-thanh-cong-cu",
      "url": "https://laban.cc/posts/bien-quy-trinh-thanh-cong-cu",
      "markdown_url": "https://laban.cc/posts/bien-quy-trinh-thanh-cong-cu.md",
      "title": "Biến quy trình thành công cụ",
      "summary": "Một bảng tính chứa cả dữ liệu lẫn quy tắc ngầm. Làm rõ trạng thái, ngoại lệ và cách kiểm tra trước khi nhờ agent biến công việc lặp lại thành công cụ.",
      "date_published": "2026-10-22T12:44:38.172Z",
      "date_modified": "2026-10-22T16:14:49.198Z",
      "source": {
        "title": "Vibe Coding Hardware",
        "url": "https://nav.al/hardware"
      },
      "content_markdown": "Có những bảng tính chỉ một người trong nhóm thực sự hiểu. Công thức nhìn thấy được, nhưng lý do đằng sau chúng nằm trong trí nhớ: cột này được sửa sau giờ chốt đơn, dòng kia giữ lại vì khách có thể đổi ý, con số cuối cùng phải kiểm tra thêm trong một cuộc trò chuyện.\n\nNhờ agent biến bảng ấy thành ứng dụng có vẻ là một bước tiến rõ ràng. Tuy nhiên, nếu những quy ước ngầm chưa được làm sáng tỏ, phần mềm mới chỉ giúp thực hiện sự mơ hồ nhanh hơn. Việc đầu tiên đáng làm thường là tìm ra quy trình thật đang vận hành bên dưới các ô dữ liệu.\n\n## Công cụ bắt đầu từ hiểu biết về công việc\n\nTrong “Vibe Coding Hardware”, đăng ngày 28/05/2026 trên nav.al, Blake Scholl kể về việc đưa những luồng kỹ thuật vốn nằm trong bảng tính vào phần mềm có thể lặp lại. Ông mô tả vai trò phối hợp giữa người xây kiến trúc phần mềm và chuyên gia lĩnh vực. Bài này lấy quan sát ấy làm điểm khởi hành để phân tích một quy trình nhỏ trong bối cảnh Việt Nam, với tình huống hoàn toàn giả định.\n\nPhần có thể mang theo không nằm ở quy mô của công ty trong câu chuyện. Nó nằm ở câu hỏi: người hiểu nghiệp vụ đang biết điều gì mà công cụ hiện tại chưa thể hiện được? Một quy tắc được diễn đạt rõ có thể trở thành điều kiện kiểm tra. Một ngoại lệ được nhận diện có thể trở thành bước dừng đúng lúc.\n\nHiểu biết ấy khác với khả năng sử dụng một phần mềm thành thạo. Bạn có thể rất nhanh trong việc sửa bảng tính nhưng chưa từng phải giải thích vì sao một trường hợp được xử lý khác đi. Quá trình tạo công cụ sẽ buộc những phân biệt đó xuất hiện.\n\n## Vẽ một đơn hàng đi qua hệ thống\n\nGiả sử một cửa hàng nhỏ nhận đơn từ tin nhắn, ghi sản phẩm vào bảng tính và đối chiếu khoản chuyển bằng tệp tải về. Mỗi tối, một người ghép ba nguồn ấy để biết đơn nào có thể giao. Mục tiêu ban đầu có thể chỉ là tạo danh sách những đơn đủ thông tin để kiểm tra lần cuối.\n\nHãy đi theo một đơn từ lúc xuất hiện đến lúc hoàn tất. Ai tạo mã đơn? Khi nào số tiền được coi là đúng? Một khách chuyển cho hai đơn thì ghi nhận thế nào? Nếu tiền đã đến nhưng khách đổi sản phẩm, trạng thái nào cần được giữ lại? Những câu hỏi này giúp phân biệt dữ liệu, quyết định và hành động.\n\nDữ liệu là điều đã ghi nhận: nội dung đơn, số tiền, thời điểm. Quyết định là cách diễn giải dữ liệu: khoản này có thuộc về đơn kia không? Hành động là việc tiếp theo: đưa đơn vào danh sách chuẩn bị hàng. Tách ba lớp giúp công cụ hỗ trợ kiểm tra mà chưa phải tự thực hiện mọi hành động sau đó.\n\nMột sơ đồ chỉ có “nhận đơn → thu tiền → giao hàng” thường chưa đủ. Các bước chờ và các đường quay lại mới cho thấy công việc thực sự khó ở đâu.\n\n## Đặt tên cho trạng thái thay vì sửa tay kết quả\n\nTrong bảng tính, người dùng có thể đổi một ô từ chưa xử lý sang xong. Trong công cụ, chữ xong cần có nghĩa cụ thể. Đã tìm thấy khoản chuyển? Đã được một người xác nhận? Hay đã giao hàng? Nếu cả ba cùng dùng một nhãn, người tiếp quản sẽ khó biết cần làm gì.\n\nCó thể bắt đầu với những trạng thái ít nhưng rõ: thiếu thông tin, chờ đối chiếu, có đề xuất khớp và đã được xác nhận. Đây chỉ là ví dụ cho tình huống giả định, không phải bộ trạng thái áp dụng cho mọi cửa hàng. Điều quan trọng là mỗi lần chuyển trạng thái có một căn cứ và một người hoặc quy trình chịu trách nhiệm.\n\nMột khoản tiền khớp về số lượng chưa chắc đã khớp về danh tính. Hai đơn cùng giá trị có thể xuất hiện trong một ngày. Khi thiếu căn cứ, kết quả hữu ích là đưa cả hai vào danh sách cần xem lại, kèm lý do chưa thể chọn. Tự tin sai dễ gây nhiều việc sửa hơn một lời báo chưa đủ thông tin.\n\n## Viết ngoại lệ trước khi yêu cầu agent triển khai\n\nNgười làm nghiệp vụ thường nhớ những ca khó đã từng gặp. Đó là một tài sản tốt để thiết kế công cụ. Thay vì chỉ mô tả trường hợp thuận lợi, hãy tạo dữ liệu mẫu cho từng ngoại lệ: mã đơn bị thiếu, cùng một dòng xuất hiện hai lần, khoản tiền bị tách thành hai lần chuyển, khách đổi yêu cầu sau khi đã xác nhận.\n\nVới mỗi ca, viết đầu ra mong đợi và giải thích ngắn vì sao. Chẳng hạn, hai dòng trùng mã giao dịch phải được đánh dấu để kiểm tra, không được cộng thành hai khoản riêng. Nếu công cụ chạy lại cùng một tệp, nó cần cho kết quả nhất quán thay vì tạo thêm những bản ghi tương đương.\n\nBộ ví dụ này có hai chức năng. Nó giúp agent hiểu quy tắc và giúp người dùng kiểm tra phiên bản mới. Khi thay một điều kiện, bạn sẽ biết những trường hợp trước đây làm đúng còn được giữ lại hay không.\n\n## Chọn một đoạn nhỏ có thể quay lại cách cũ\n\nMột bản thử đầu tiên có thể chỉ nhận hai tệp dữ liệu giả và xuất ra tệp đối chiếu mới. Nó chưa cần gửi tin nhắn cho khách, ghi đè dữ liệu gốc hoặc thay toàn bộ hệ thống bán hàng. Phạm vi nhỏ giúp thấy rõ phần nào đúng và giảm số nơi phải tìm khi có lỗi.\n\nNgười vận hành vẫn làm theo quy trình cũ trong giai đoạn so sánh. Mỗi chênh lệch giữa hai cách là một câu hỏi cần giải thích. Công cụ sai quy tắc, dữ liệu đầu vào bị thiếu, hay chính cách làm cũ đang dựa vào một thông tin chưa được ghi lại?\n\nChỉ khi hiểu được các chênh lệch ấy mới có cơ sở để mở rộng. Một lần đối chiếu trùng khớp chưa cho biết công cụ có xử lý được ngày có hoàn tiền, đổi đơn hoặc nhập trùng dữ liệu hay không.\n\n## Chi phí nằm cả ở tháng sau\n\nMột công cụ nhỏ vẫn cần người giữ gìn. Tệp đầu vào có thể đổi tên cột. Người trong nhóm có thể sử dụng một ký hiệu mới. Máy chạy công cụ có thể được thay. Nếu không ai biết cách nhận diện và xử lý những thay đổi ấy, thời gian tiết kiệm hôm nay có thể trở thành sự phụ thuộc khó chịu sau này.\n\nVì thế, bản bàn giao nên nói được công cụ nhận dữ liệu gì, tạo ra gì, báo lỗi ở đâu và cách quay lại quy trình thủ công. Quy tắc cần được ghi cạnh ví dụ, thay vì chỉ nằm trong một đoạn trao đổi với agent mà người tiếp quản không tìm thấy.\n\nCũng có lúc một biểu mẫu thống nhất hoặc vài quy ước đặt mã đã giải quyết đủ vấn đề. Làm rõ công việc rồi nhận ra chưa cần viết phần mềm vẫn là một kết quả có ích. Quy trình tốt phục vụ người vận hành; họ không có nghĩa vụ duy trì thêm một ứng dụng chỉ vì đã xây được nó.\n\n## Một cách bắt đầu vào sáng mai\n\nChọn một thao tác phải lặp lại trong tuần. Quan sát một lần làm thật và ghi các quyết định mà người thực hiện phải đưa ra. Lấy dữ liệu giả, viết một trường hợp bình thường và vài ngoại lệ có ý nghĩa, rồi nhờ agent tạo đúng một bước hỗ trợ.\n\nKhi dùng thử, hãy giữ câu hỏi này ở trước mặt: một người khác có thể giải thích vì sao công cụ tạo ra kết quả ấy không? Nếu câu trả lời chưa rõ, việc cần làm tiếp theo có thể là viết lại quy tắc. Phần mềm trở nên đáng tin hơn khi hiểu biết về công việc đã có một nơi rõ ràng để tồn tại.",
      "ai_assisted": true
    },
    {
      "id": "do-ket-qua-dung-dem-token",
      "url": "https://laban.cc/posts/do-ket-qua-dung-dem-token",
      "markdown_url": "https://laban.cc/posts/do-ket-qua-dung-dem-token.md",
      "title": "Đo kết quả, đừng đếm token",
      "summary": "Đánh giá agent bằng tổng công sức đến lúc có kết quả dùng được: thời gian giao việc, kiểm tra, sửa lỗi và chi phí duy trì một quy trình có thể lặp lại.",
      "date_published": "2026-10-22T12:44:38.151Z",
      "date_modified": "2026-10-22T16:14:49.177Z",
      "source": {
        "title": "Waste Tokens, Save Time",
        "url": "https://nav.al/tokens"
      },
      "content_markdown": "Một buổi tối làm việc với agent có thể trông rất hiệu quả: cửa sổ liên tục chạy, tệp mới xuất hiện, bản báo cáo ngày càng dài. Nhưng đến lúc đóng máy, bạn vẫn chưa dám dùng kết quả. Bạn đang mua được năng suất, hay chỉ đang có thêm một thứ cần kiểm tra?\n\nCâu hỏi ấy quan trọng hơn việc hôm nay đã dùng bao nhiêu token. Người làm một mình thường thiếu cả thời gian lẫn sự tập trung. Một công cụ đáng giá cần trả lại cho họ một phần của hai thứ đó, đồng thời tạo ra kết quả đủ tốt để đi vào công việc thật.\n\n## Từ một quan sát của Naval đến câu hỏi của người sử dụng\n\nTrong cuộc trò chuyện “Waste Tokens, Save Time” trên nav.al, ngày 27/05/2026, Naval đề nghị nhìn vào thời gian và đầu ra cuối cùng khi đánh giá việc dùng AI. Các khách mời cũng chất vấn việc lấy mức tiêu thụ token làm thước đo năng suất. Đó là điểm xuất phát của bài này; khung đo lường và các tình huống dưới đây là phân tích độc lập của La Bàn.\n\nĐặt câu hỏi về đầu ra sẽ đưa ta đến một phân biệt hữu ích: hoạt động của máy và tiến bộ của công việc. Máy có thể đang làm nhiều việc, nhưng tiến bộ chỉ xuất hiện khi một trở ngại cụ thể được giải quyết. Với một bản hướng dẫn, đó có thể là người mới thực hiện được quy trình. Với một lần sửa lỗi, đó là tình huống từng hỏng nay chạy đúng và những chức năng liên quan vẫn sử dụng được.\n\nVì thế, trước khi chọn mô hình hoặc so chi phí, ta cần gọi tên thứ sẽ được nghiệm thu. “Viết lại tài liệu” còn quá rộng. “Một đồng nghiệp chưa biết dự án có thể cài đặt và chạy ví dụ bằng tài liệu này” đã gần với một kết quả có thể kiểm tra.\n\n## Đếm cả phần việc quay trở lại với bạn\n\nChi phí dễ nhìn nhất nằm trên hóa đơn công cụ. Phần khó nhìn hơn nằm trong lịch của người dùng: chuẩn bị ngữ cảnh, chờ, giải thích lại, tìm lỗi và khôi phục những thứ bị sửa nhầm. Một đầu ra rẻ có thể kéo theo một vòng kiểm tra dài. Một đầu ra tốn nhiều tài nguyên hơn có thể đáng giá nếu rút ngắn được vòng ấy.\n\nCó thể bắt đầu bằng ba con số riêng biệt. Thứ nhất là thời gian bạn trực tiếp làm việc: giao việc, theo dõi, đọc và sửa. Thứ hai là thời gian từ khi bắt đầu đến lúc có kết quả dùng được. Thứ ba là chi phí công cụ. Giữ chúng riêng giúp tránh đánh đồng mười phút máy chạy nền với mười phút bạn phải nhìn màn hình.\n\nMột agent chạy lâu nhưng để bạn làm việc khác có thể giảm công sức trực tiếp mà không giúp hoàn tất sớm hơn. Ngược lại, một agent trả lời rất nhanh có thể làm bạn ngắt việc liên tục. Đâu là phương án tốt hơn còn tùy điểm nghẽn: bạn cần giao hàng đúng giờ hay cần lấy lại một buổi tập trung?\n\n## Một phép so sánh giả định, làm đến nơi đến chốn\n\nGiả sử một người vận hành blog cần chuẩn bị bản tổng hợp thay đổi hằng tuần. Làm thủ công mất 45 phút: đọc ghi chú, đối chiếu liên kết và viết lại phần hướng dẫn. Đây là tình huống minh họa, không phải số liệu đo từ một doanh nghiệp.\n\nVới quy trình dùng agent thứ nhất, người đó mất 8 phút chuẩn bị dữ liệu, 6 phút giải thích trong quá trình chạy, 12 phút kiểm tra và 4 phút sửa. Tổng công sức trực tiếp là 30 phút. Máy chạy nền thêm 10 phút, nên thời gian hoàn tất theo đồng hồ có thể là 40 phút nếu các bước diễn ra nối tiếp. Lợi ích ở đây là 15 phút công sức và 5 phút hoàn tất sớm hơn.\n\nVới quy trình thứ hai, thao tác giao việc chỉ mất 2 phút, nhưng đọc lại mất 25 phút và sửa mất 30 phút. Tổng công sức là 57 phút, còn chưa tính thời gian máy chạy. Một lời nhắc rất ngắn chưa tạo ra một quy trình hiệu quả. Phần việc bị đẩy sang cuối vẫn là công việc.\n\nSo sánh này cũng chưa tính chi phí xây quy trình ban đầu. Nếu cần hai giờ chuẩn bị bộ dữ liệu và biểu mẫu, lợi ích 15 phút mỗi lần cần nhiều lần sử dụng mới bù được công sức thiết lập. Một việc chỉ làm một lần có thể không đáng tự động hóa sâu đến vậy.\n\n## Chất lượng là điều kiện, không phải phần thưởng thêm\n\nHai phương án chỉ so được với nhau khi đạt cùng một chuẩn tối thiểu. Bản tổng hợp thiếu một thay đổi quan trọng không tương đương với bản đầy đủ, dù hoàn thành nhanh gấp đôi. Đo thời gian mà bỏ qua chất lượng sẽ tạo động lực làm ra những kết quả dễ hoàn tất nhưng khó sử dụng.\n\nMột cách thực tế là xác định điều kiện đạt trước khi chạy. Chẳng hạn: mỗi thay đổi phải có nguồn đối chiếu; các liên kết còn mở được; hướng dẫn chỉ chứa bước đã kiểm tra; những điểm chưa chắc được đánh dấu. Người kiểm tra có thể quyết định đạt hay chưa đạt mà không cần dựa vào cảm giác văn bản trông chuyên nghiệp.\n\nVới công việc có hậu quả lớn khi sai, điều kiện ấy cần nghiêm hơn và phần duyệt của người có trách nhiệm vẫn phải tồn tại. Tăng mức sử dụng mô hình không tự động giải quyết được vấn đề thiếu dữ liệu, thiếu tiêu chí hoặc thiếu người đủ hiểu để đánh giá.\n\n## Khi việc đo lường bắt đầu làm lệch mục tiêu\n\nMột chỉ số thường trở nên nguy hiểm khi được dùng như mục tiêu duy nhất. Thưởng cho số tác vụ hoàn tất có thể khiến người ta chia nhỏ những việc dễ. Thưởng cho thời gian tiết kiệm tự báo cáo có thể khiến mốc thủ công bị ước lượng quá cao. Thưởng cho lượng token có thể biến tiêu thụ tài nguyên thành một biểu hiện của sự chăm chỉ.\n\nTa cũng dễ đánh giá quá cao một lần chạy đẹp. Một quy trình phục vụ mỗi tuần cần được xem qua nhiều loại đầu vào: tuần có ít thay đổi, tuần có dữ liệu thiếu, tuần tên sản phẩm bị viết không thống nhất. Ghi lại cả lần thất bại giúp biết phạm vi nào agent làm tốt và lúc nào cần quay về cách thủ công.\n\nĐiều nên tối ưu là một vòng công việc có thể lặp lại. Một kết quả ngoạn mục nhưng không giải thích được cách kiểm tra có thể kém hữu ích hơn một quy trình bình thường mà người khác tiếp quản được.\n\n## Một trang ghi chép cho lần thử tiếp theo\n\nChọn một việc bạn đã làm đủ quen để biết đầu ra đúng trông như thế nào. Ghi cách làm hiện tại, thời gian thực tế của một lần và tiêu chí nghiệm thu. Sau đó thử agent trên cùng phạm vi, với giới hạn rõ về thời gian và chi phí mà bạn chấp nhận cho lần thử.\n\nTrong lúc làm, ghi các phút cần can thiệp và nguyên nhân. Cuối buổi, phân loại phần sửa: thiếu ngữ cảnh, sai dữ kiện, sai định dạng hay hiểu sai mục tiêu. Mỗi nhóm dẫn đến một thay đổi khác nhau. Thêm một câu vào lời nhắc có thể sửa định dạng; dữ liệu nguồn thiếu thì cần được bổ sung từ nơi khác.\n\nSau vài vòng, hãy hỏi một câu đơn giản: công việc này đã nhẹ đi ở chỗ nào, và phần nặng có chuyển sang một người khác hay một thời điểm khác không? Câu trả lời cụ thể sẽ giúp bạn chọn bước tiếp theo tốt hơn một con số tiêu thụ token đứng riêng lẻ.",
      "ai_assisted": true
    }
  ]
}