# Industrial (Phần 1): Đốt token, tiết kiệm thời gian

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.

URL: https://laban.cc/posts/industrial-phan-1-dot-token-tiet-kiem-thoi-gian
Biên soạn: La Bàn Editorial (AI-assisted)
Nguồn: Industrial — Naval Podcast (Guillermo Rauch, Blake Scholl, Max Hodak) — https://nav.al/industrial

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

## Phần 1: Đốt token, tiết kiệm thời gian

Nivi: 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.

Để 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.

Cả 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ì?

Naval, anh có phản hồi gì trước khi tôi chuyển sang Guillermo không?

Naval: Cứ vui vẻ thôi.

Nivi: Mọi người cứ tự nhiên vào chuyện.

## Nhà máy phần mềm AI

Guillermo 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?

Giờ 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 đó.

Naval: 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.

Satoshi. 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.

Guillermo: 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?

Blake 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.

Max 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.

Guillermo: 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.

Max: 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.

## Đốt token, tiết kiệm thời gian

Naval: 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.

Tô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.

Kể 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.

## Model chỉ dẫn con người

Naval: 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?

Guillermo: 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.”

Đó 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.

Vẫ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?

Rõ 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.

Max: 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.

Naval: Đó 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.

Guillermo: Đó 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.

Đ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 đó.

Naval: Đó 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.

## Phần mềm thuần đã chết chưa?

Naval: Đ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.

Trướ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ế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?

Guillermo: 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.”

Tô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”.

Nhó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.

Mộ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.

Naval: Vậy chúng giống như thư viện và phụ thuộc, nhưng dành cho model.

Guillermo: Đúng — đặc biệt là cho agent.

## Không còn bị kẹt nữa

Max: 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.

Đã 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.

Guillermo: Đ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.

Naval: 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.

Max: Đ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.”

Và điều đó giờ không còn đúng nữa.

---
Phân tích độc lập của La Bàn, biên soạn cùng AI. Các tình huống và khung thực hành do La Bàn phát triển; bài không phải bản dịch toàn văn hay phát ngôn chính thức của tác giả nguồn.