[TL;DR Hàng Ngày] Tôi sẽ nói rõ điều mà mọi người vẫn im lặng: khi hóa đơn AI hàng tháng của một kỹ sư bắt đầu nghe như một vòng gọi vốn Series A, câu chuyện này không còn là chuyện về công cụ nữa, mà bắt đầu trông giống một thí nghiệm kinh tế. Vậy điều chúng ta thực sự đang chứng kiến là gì—hệ điều hành tiếp theo của kỹ sư phần mềm, hay một cỗ máy cực kỳ đắt đỏ để sản xuất AI chất lượng thấp quy mô công nghiệp? Có lẽ cả hai. 🤖💸 🔥 Bối cảnh: Một nghìn tỷ token được sử dụng biến thành cuộc tranh luận công khai về chi phí 📌 Các con số tiêu đề được cố ý phóng đại • Peter Steinberger, người sáng lập OpenClaw, ước tính đội của anh ấy đã chi khoảng 10 triệu USD cho chi phí token trong một tháng để thực hiện công việc AI, sau đó lập tức bổ sung: không phải toàn bộ số tiền đó đều hữu ích. • Một ví dụ khác lan truyền là hồ sơ Cursor của Lauren Tan, cho thấy khoảng 1,5 nghìn tỷ token đã được sử dụng trong 30 ngày. • Dựa trên mức chuẩn ước tính khoảng $8 mỗi 1 triệu token, Peter Piekarczyk ước tính chi phí khoảng $384.000 mỗi ngày, ~$11 triệu mỗi tháng, hoặc $132 triệu mỗi năm. • Ngay cả với mức chiết khấu doanh nghiệp 90%, ước tính vẫn rơi vào khoảng $1,1 triệu mỗi tháng, tương đương khoảng $13 triệu mỗi năm. 📌 Lý do mọi người hoảng hốt: mức sử dụng vượt xa hành vi phát triển bình thường • Dữ liệu Jellyfish từ 12.000 nhà phát triển cho thấy người dùng trung bình tiêu thụ khoảng 51 triệu token mỗi tháng. • Percentile thứ 90 là khoảng 380 triệu token mỗi tháng. • Điều này khiến mức sử dụng 1,5 nghìn tỷ token của Lauren cao gấp khoảng 29.000 lần mức trung bình, trong khi 603 tỷ token mà Steinberger từng chia sẻ trước đó vẫn cao gấp khoảng 12.000 lần. • Khi lượng token được chuyển đổi thành toán học lương, câu chuyện thay đổi nhanh chóng: đây không còn là “công cụ tăng năng suất”, mà trông giống như sự ưu tiên về máy tính. 📌 Hóa đơn thực sự phức tạp, vì không phải tất cả token đều có giá như nhau • Số lượng token theo phong cách Cursor có thể bao gồm đầu vào tiêu chuẩn, đầu ra mô hình, ghi bộ nhớ đệm và đọc bộ nhớ đệm—những thứ này có giá rất khác nhau. • Với mức giá kiểu Opus 5.5, 1 triệu token đầu vào có thể khoảng $4, đầu ra khoảng $20, và đọc bộ nhớ đệm chỉ khoảng $0,20. • Một ảnh chụp màn hình sử dụng cho thấy 73,3 tỷ token tốn khoảng $30.000 tổng cộng, ngụ ý trung bình khoảng $0,41 mỗi 1 triệu token vì lưu lượng bộ nhớ đệm chiếm ưu thế. • Áp dụng tỷ lệ pha trộn này cho 1,5 nghìn tỷ token, chi phí hàng tháng giảm xuống còn khoảng $615.000, chứ không phải $11 triệu. • Trong kịch bản tối thiểu tuyệt đối nơi mọi thứ đều được tính theo giá đọc bộ nhớ đệm, 1,5 nghìn tỷ token sẽ tốn khoảng $300.000 mỗi tháng. • Piekarczyk sau đó cũng làm dịu lại tuyên bố của mình: ngay cả khi ước tính ban đầu của anh ấy cao gấp 10 lần, chi phí hàng tháng vẫn có thể vào khoảng $100.000. 🔥 Vậy số tiền đó thực sự mua được gì? 📌 Không phải “một chatbot”, mà là toàn bộ sơ đồ tổ chức tác nhân • Steinberger mô tả phong cách làm việc này là khám phá xem phát triển phần mềm sẽ trông như thế nào khi chi phí token không còn là rào cản. • Đội 3 người của anh ấy đang chạy khoảng 100 phiên bản Codex. • Những tác nhân này xem xét PR, quét lịch sử commit để tìm lỗi bảo mật, hợp nhất các vấn đề GitHub trùng lặp, viết bản sửa lỗi, theo dõi sự suy giảm hiệu suất và thậm chí tham gia các cuộc họp để tạo PR từ cuộc thảo luận. • Lauren mô tả hệ thống của mình như một đội gồm hơn 20 tác nhân: một tác nhân trưởng văn phòng, một tác nhân quản lý sản phẩm và hơn 20 tác nhân thực thi chạy tự chủ. 📌 Điểm cốt lõi không phải là tạo ra—mà là xác minh • Lauren cho rằng điểm nghẽn trong lập trình bằng tác nhân không phải là viết mã, mà là chứng minh mã thực sự hoạt động. • Quy trình của cô khiến các tác nhân chạy mã, thu thập dấu vết CPU và ảnh chụp bộ nhớ heap, khởi chạy trình mô phỏng iOS và tương tác với ứng dụng như người dùng thực tế. • Mục tiêu là tạo thành một vòng lặp khép kín: nếu một tác nhân có thể xác minh đầu ra của chính nó, nó có thể tiếp tục lặp lại cho đến khi hoàn thành nhiệm vụ. • Nếu không thể xác minh, nó sẽ trả lại bản diff cho con người và dừng lại—nghĩa là con người trở thành phần chậm nhất của hệ thống. • Với quy mô cô tuyên bố là 4.000 PR mỗi tháng, ngay cả khi dành 5 phút để xem xét từng PR cũng sẽ tổng cộng khoảng 333 giờ—tương đương một tháng làm việc đầy đủ của một người. Vì vậy, việc xem xét thủ công không thể là lớp xác minh. 📌 Điều này thay đổi vai trò của kỹ sư • Trong mô hình này, kỹ sư bắt đầu trông ít giống một lập trình viên và nhiều hơn như một quản lý kỹ thuật cho các tác nhân. • Lauren nói thẳng: nếu bạn không thể tin tưởng đầu ra của một tác nhân, bạn sẽ không bao giờ có thể mở rộng lên một trăm. • Quy trình pstack của cô đóng gói điều này thành các bản kế hoạch có cấu trúc—chuẩn hóa hiểu biết, thiết kế, lập trình, xem xét và xác minh trên nhiều tác nhân cục bộ và đám mây. 🔥 Nhưng đây là nơi câu chuyện trở nên sắc nét: toàn bộ sự tự chủ này đòi hỏi những ràng buộc khắt khe 📌 Mã nguồn phải được xây dựng lại để thân thiện với tác nhân • GrokBot được cho là bắt đầu như phần mềm được viết nhanh với ít ràng buộc kiến trúc và ít sự đọc mã từ con người. • Điều đó khiến các tác nhân dễ dàng chọn con đường ít nỗ lực nhất: thêm nhiều mã hơn, ranh giới mờ nhạt, rủi ro hiệu suất tăng lên. • Để khắc phục điều đó, Lauren nói cô đã dùng hơn 600 PR để tái cấu trúc hệ thống thành một kiến trúc nội bộ gọi là Dune. • Các quy tắc CI trở nên cực kỳ nghiêm ngặt: cấm useEffect, cấm comment và xác minh đồ thị phụ thuộc để Electron main và renderer không bao giờ import lẫn nhau. • Nói cách khác, phần “thông minh” không chỉ là mô hình tốt hơn—mà là thiết kế lại môi trường để các tác nhân có ít cách hơn để làm việc cẩu thả. 📌 pstack có thể mạnh mẽ, nhưng cũng có thể cực kỳ không thể di chuyển • Gói của cô bao gồm 23 bản kế hoạch và hơn 20 nguyên tắc kỹ thuật. • Điều này nghe ít giống một quy trình phát triển phổ quát và nhiều hơn như một chiếc lồng hành vi được tinh chỉnh cao cho các mô hình. • Điều đó ổn—cho đến khi ai đó cố gắng sao chép dán nó vào các đội thông thường với ngân sách thông thường và cơ sở mã lỗi thời. Khi đó phép màu có thể tan biến. 🔥 Phản ứng ngược: đây là đổi mới hay chỉ là màn trình diễn máy tính của giới giàu có? 📌 Các nhà phê bình cho rằng đây là một nhà máy sản xuất AI chất lượng thấp được trang điểm như tương lai • Trên Reddit và trong cộng đồng kỹ sư, nhiều lập trình viên lập luận rằng việc hợp nhất hàng ngàn PR với chi phí token gần như vô hạn không phải là một cuộc cách mạng trong kỹ thuật phần mềm. • Quan điểm của họ: đây là việc sử dụng sức mạnh máy tính thô để tràn ngập mã nguồn với những thay đổi vi mô, trong khi bỏ qua điểm nghẽn thực sự—khả năng duy trì dài hạn. • Nói cách khác, việc tạo mã mở rộng nhanh hơn phán đoán. Và khi phán đoán bị thiếu đầu tư, nợ sẽ được chuyển giao cho người kế thừa repo. 📌 Giá trị tiếp thị có thể cao hơn giá trị kỹ thuật • Theo, người sáng lập T3, cho rằng chi phí nội bộ thực sự có thể gần với $25.000–$50.000 mỗi tháng. • Quan điểm của anh ấy đơn giản: ngay cả ở mức đó, sự tiếp cận vẫn đáng giá. Một số công ty chi $1 triệu cho sự kiện nhưng nhận được ít sự chú ý hơn một bài đăng viral từ Lauren.• Từ góc nhìn của Cursor, điều này có thể không phải là câu chuyện về kinh tế đơn vị, mà là một chiến dịch PR xuất sắc. • Lauren chính cô cũng đã thừa nhận rõ ràng sự ưu ái này: cô làm việc trong một phòng thí nghiệm AI với lượng token gần như vô hạn, nên cô không cho rằng ai cũng nên sao chép phương pháp chính xác của cô. 📌 Câu hỏi sâu xa hơn là vấn đề kinh tế, không chỉ là kỹ thuật • Nếu phát triển theo hướng agentic chỉ hoạt động trơn tru khi các vòng xác minh được tài trợ mạnh mẽ, thì sản phẩm thực sự không phải là “lập trình AI.” Mà là quyền truy cập vào việc xác minh chi phí thấp ở quy mô lớn. • Và nếu điều đó đúng, thì AgentFi trở thành khung nhìn thú vị hơn: không chỉ là những gì các tác nhân có thể làm, mà còn là ai có đủ khả năng để cho chúng hoạt động tự chủ. • Tương lai có thể không thuộc về những đội ngũ có prompt tốt nhất. Mà có thể thuộc về những đội ngũ xây dựng hệ thống động lực, hàng rào an toàn và vòng xác minh hiệu quả về vốn tốt nhất. Quan điểm của tôi? Câu chuyện này hữu ích chính vì nó khiến mọi người cảm thấy bất an. • Trường hợp tốt nhất: đây là cái nhìn sớm về một stack kỹ thuật mới, nơi các tác nhân triển khai, kiểm thử, sửa chữa và phối hợp xuyên suốt các hệ thống phần mềm. • Trường hợp tệ nhất: đây là một màn trình diễn được tài trợ bởi tính toán, nhầm lẫn giữa khối lượng đầu ra với chất lượng sản phẩm. • Khả năng cao nhất: sự thật nằm ở giữa. Phần mềm agentic có thể là có thật, nhưng nếu không có kiến trúc kỷ luật và kinh tế hợp lý, nó có thể chỉ trở thành cách nhanh hơn để tạo ra nợ kỹ thuật. Vậy đây là câu hỏi tôi muốn để lại cho bạn: Nếu một tác nhân có thể viết 4.000 PR mỗi tháng, nhưng chỉ một nhóm nhỏ ưu tú mới đủ khả năng chi trả hóa đơn xác minh, thì đó có phải là tương lai của phần mềm—hay chỉ là một bản demo của quyền lực?