Tiêu đề gốc: Đừng xây dựng nhà máy Foxconn cho các tác nhân AI của bạn
Tác giả gốc: Garry Tan, Y Combinator
Biên dịch: Peggy

Lời biên tập: Khi ngày càng nhiều người thảo luận về việc "AI có thay thế được lập trình viên hay không", chủ tịch YC Garry Tan thực chất đang đặt ra một câu hỏi khác: Nếu AI đã có thể hoàn thành phần lớn công việc lập trình, tại sao chúng ta vẫn quản lý nó theo cách quản lý phần mềm thông thường?

Đầu năm nay, Garry Tan đã dành nhiều tháng để viết một dự án có tên Garry's List với 540.000 dòng mã bằng Rails và AI Agent. Sau khi hoàn thành dự án, ông lại đưa ra một kết luận có vẻ mâu thuẫn: 540.000 dòng mã này tự nó không quan trọng, thứ thực sự có giá trị là GStack được kết tinh trong quá trình phát triển - một framework phát triển mới được xây dựng xoay quanh quy trình làm việc của AI Agent.

Theo quan điểm của ông, trong vài năm qua, ngành công nghiệp phần mềm đã hình thành một quán tính tập thể: các nhà phát triển liên tục thêm các bài kiểm tra, bộ xác thực, cơ chế thử lại, tác vụ nền và các logic điều khiển khác, bọc mô hình trong nhiều lớp. Cách làm này có lý khi mô hình còn đắt đỏ và khả năng hạn chế, nhưng khi LLM đã có thể tự động hoàn thành nhiều công việc, các hệ thống này lại giống như đang xây dựng một "nhà máy Foxconn" cho một siêu công nhân thông minh - dùng vô số quy tắc và quy trình để ràng buộc các tác nhân vốn đã có năng lực.

Khi chi phí mô hình giảm nhanh và khả năng không ngừng tăng lên, trọng tâm phát triển phần mềm có thể đang chuyển từ "viết nhiều mã hơn" sang "thiết kế nhiều năng lực hơn". Tác giả đề xuất sử dụng Markdown để xây dựng skill pack (gói kỹ năng - các module năng lực có thể kiểm thử và tái sử dụng), cho phép Agent tự động tạo mã, kiểm thử và hệ thống đánh giá, kết tinh các quy trình làm việc phức tạp thành tài sản năng lực có thể sinh lãi kép. Ông thậm chí còn đưa ra một ví dụ: công việc đánh giá hackathon vốn mất nhiều ngày, nay chỉ cần vài chục phút là Agent có thể hoàn thành.

Ở một khía cạnh nào đó, bài viết này không bàn về lập trình, mà là sự kết thúc của logic công nghiệp hóa phần mềm. Khi mã nguồn không còn là tài nguyên khan hiếm nhất, năng lực cốt lõi của kỹ sư cũng bắt đầu dịch chuyển: thay vì viết nhiều mã hơn, việc đánh giá điều gì đáng xây dựng, cách định nghĩa vấn đề, và cách kết tinh kinh nghiệm thành năng lực tái sử dụng đang trở nên quan trọng hơn. Kết luận cuối cùng của tác giả là: kỹ sư xuất sắc nhất trong tương lai không nhất thiết là người viết nhiều mã nhất, mà có thể là người viết ít nhất, nhưng giải phóng được nhiều trí thông minh nhất.

Dưới đây là nội dung gốc:

Vào tháng 1 năm nay, tôi bắt đầu viết mã lại và tạo ra Garry's List. Mã Rails cùng với các bài kiểm tra để ràng buộc nó đã vượt quá 500.000 dòng.

Lúc đó, tôi rất tự hào về nó. Nhưng thực ra không nên như vậy. Điều thực sự đáng tự hào không phải là ứng dụng này, mà là cách làm việc tôi đã mày mò ra trong quá trình xây dựng nó. GStack, tức cách tôi sử dụng Agent để lập trình, đã phát triển trong quá trình làm Garry's List. Sau đó tôi đã mã nguồn mở nó. Giờ đây, nó đã là một trong 100 dự án mã nguồn mở có nhiều sao nhất trong lịch sử GitHub, đạt khoảng 105.000 sao trong chưa đầy ba tháng.

Hơn 500.000 dòng mã đó là "sản phẩm". Cách làm việc đó mới là "sản phẩm phụ". Và điều thực sự quan trọng chính là sản phẩm phụ này.

Vậy, 540.000 dòng mã được xây dựng xoay quanh một LLM thực chất là gì?

Đó là một nhà máy Foxconn. Một nhà máy được xây dựng cho một công nhân AI có trí tuệ cao. Người công nhân này vốn không cần bị giám sát chặt chẽ, nhưng chúng ta vẫn xây dựng nó cho anh ta.

Vào cửa phải đi dép. Dậy lúc 6 giờ sáng. Tập thể dục tập thể. Ngày qua ngày đứng trên cùng một dây chuyền sản xuất. Cuộc sống khó khăn đến nỗi mỗi tòa nhà cao tầng đều phải lắp lưới bảo vệ, bởi vì—đó không phải là cuộc sống bạn muốn. Mỗi bài kiểm tra, mỗi rào cản, mỗi vòng lặp thử lại, đều là một cái lồng siết chặt lên người công nhân này. Và người công nhân này vốn có thể hoàn thành công việc, thậm chí còn có thể làm hàng nghìn việc bạn không ngờ tới.

Con người và Agent đều có tiềm năng vô hạn, nhưng logic của nhà máy Foxconn là vắt kiệt trí tuệ và lao động từ cuộc sống tươi đẹp. Chúng vốn có thể làm những công việc này, thậm chí làm nhiều hơn gấp 1000 lần, chỉ cần chúng ta cho phép chúng làm vậy.

Tôi đã từng xây dựng những nhà máy như vậy. Hôm nay hầu như ai cũng đang xây dựng như vậy. Và bây giờ tôi muốn nói với bạn: Đừng làm như vậy nữa.

Người du hành thời gian

Điều tôi thực sự chứng minh được với 539.000 dòng mã là tôi có thể hoàn hảo giả dạng thành một người du hành thời gian.

Một kỹ sư Web 2.0 năm 2013, tức là bản thân tôi lần cuối thực sự được gọi là kỹ sư phần mềm, bị ném vào năm 2026, với các công cụ hiện đại trong tay, nhưng vẫn xây dựng phần mềm theo cách duy nhất anh ta quen thuộc: thêm nhiều mã hơn. Luôn là thêm nhiều mã hơn.

Công cụ đã thay đổi, nhưng bản năng của tôi thì không.

Các kỹ sư năm 2013 tin vào một điều sâu sắc: năng lực bằng số dòng code. Niềm tin này đã đúng trong nhiều thập kỷ, cho đến tận ngày nay.

Nếu bạn giao cho tôi Codex hoặc Claude Code, tôi có thể hoàn thành khối lượng công việc của 100 thậm chí 1000 kỹ sư. Nhưng đó vẫn là cùng một bản đồ, chỉ là thay động cơ nhanh hơn, lao với tốc độ tối đa về một điểm đến giờ đây đã sai lầm.

Đây chính xác là vị trí của hầu hết những người xây dựng AI hiện nay. Họ nâng cấp công cụ, nhưng vẫn giữ nguyên tư duy của năm 2013.

Cái bẫy này trông không giống bẫy, vì code thực sự chạy được. Garry's List cũng thực sự lên sóng. Tháng đó, tôi cảm giác như mình đã trải qua giai đoạn năng suất nhất cuộc đời.

Nhưng đó chỉ là năng suất phục vụ cho một ý tưởng đã lỗi thời.

LLM từng rất đắt, vì vậy chúng ta phải "thuần hóa" chúng

Tính đến khoảng năm 2025, nền kinh tế cũ là: gọi LLM rất đắt, còn code thì rẻ.

Vì vậy bạn viết code để tiết kiệm các lần gọi model, ràng buộc nó, thuần hóa nó, gọi nó một cách cẩn thận. Kiến trúc thời đó là: dùng nhiều phần mềm bao bọc xung quanh một vài lần gọi model quý giá.

Nhưng cả hai vế của phương trình này đều đã đảo ngược.

Model đang trở nên rẻ, và mỗi quý lại càng rẻ hơn. Đồng thời, model đủ thông minh, tỷ lệ giá trị so với chi phí đã đảo chiều. Model còn có thể viết code khả dụng.

Vì vậy bạn không còn cần viết code để "giám sát" model nữa. Bạn có thể dùng ngôn ngữ tự nhiên để bảo model làm gì, sau đó để nó chỉ viết ra lượng code tối thiểu thực sự cần thiết.

Đây chính là just-in-time software (phần mềm tạo ra tức thời), và chúng ta đang bước vào thời kỳ hoàng kim của nó.

Hình thái của sản phẩm phần mềm cũng thay đổi hoàn toàn. Ứng dụng Rails kia là 540.000 dòng code tôi đã viết và sở hữu, cùng với các bài kiểm tra để giám sát nó. Sự thay thế của nó là một Agent được tạo từ Markdown và một lượng nhỏ code, quy mô chỉ bằng một phần nhỏ so với bản cũ.

Năng lực tương đương. Dễ đọc hơn. Dễ bảo trì hơn. Và linh hoạt hơn nhiều. Bởi vì hành vi tồn tại trong các chỉ dẫn bạn có thể chỉnh sửa bằng ngôn ngữ tự nhiên, chứ không bị đóng băng trong logic code bạn viết vào một ngày nào đó.

Chúng ta từng viết code để chăm sóc một thứ, nhưng giờ đây thứ đó đã thông minh hơn cả những dòng code ấy.

Bên trong nhà máy Foxconn: Thậm chí lưới bảo vệ cũng đã được lắp đặt xong

Nếu gần đây bạn đang viết code, rất có thể bạn đã vô tình xây dựng loại nhà máy này.

Bạn có thể bước vào kho code của mình và đếm xem có bao nhiêu dòng code tồn tại chỉ vì bạn không tin tưởng mô hình có thể hoàn thành công việc của nó. Trong kho code của tôi, có khoảng 262.000 dòng code ứng dụng và khoảng 276.000 dòng test để giám sát nó. Ủy ban kiểm toán còn lớn hơn cả công ty.

Một số bộ lọc đang kiểm tra đầu vào mà mô hình lẽ ra có thể xử lý. Một số bộ xác thực đang kiểm tra đầu ra mà mô hình lẽ ra có thể phát hiện. Một số vòng lặp thử lại bao quanh các lệnh gọi mô hình, trong khi mô hình thực ra đã có thể tự phục hồi. Mỗi dòng code như vậy đều là một canh bạc: công nhân này chắc chắn sẽ thất bại.

Bạn cũng đã từng viết những canh bạc tương tự. Tất cả chúng ta đều đã từng.

127 tác vụ nền, trong đó 33 tác vụ là định kỳ. Đây không phải là năng lực, mà là đặt 33 cái đồng hồ báo thức cho một công nhân LLM hiện thường đi làm đúng giờ.

Trong những ngày tôi xây dựng "nhà máy Foxconn", Claude và tôi đã viết một file dài 1778 dòng. Mục đích duy nhất của nó là chất vấn các sự thật do mô hình đưa ra.

Nó sẽ tách rời từng tuyên bố mà mô hình đưa ra, gửi song song đến năm nguồn khác nhau để xác minh, sau đó chấm điểm. Các tuyên bố đơn giản sẽ trải qua một ngưỡng phân loại nhẹ để tránh tất cả nội dung đều phải chạy quy trình đầy đủ. Nếu không có kết quả ở vòng đầu tiên, nó sẽ thử lại. Và còn có phương án dự phòng cho phương án dự phòng.

Trong một tập của "Rick and Morty", Rick đã chế tạo một robot nhỏ trên bàn ăn sáng. Robot khởi động và ngước lên hỏi: Nhiệm vụ của tôi là gì? Rick nói: Anh chịu trách nhiệm đưa bơ. Robot đẩy đĩa bơ qua, cúi xuống nhìn đôi tay của mình và nói: Trời ơi. Và rồi nó ngồi đó. Robot đó cũng có tiềm năng vô hạn. Nó lại được tạo ra chỉ để đưa bơ. 276.000 dòng test của tôi chính là cái đĩa bơ đó.

Khi bạn xây dựng phần mềm bằng phương pháp "nhà máy Foxconn" kiểu năm 2023, bạn đang xây dựng một cái lồng. Nếu không cẩn thận, chính bạn sẽ trở thành người canh giữ nhà tù AI Agent này.

Markdown bây giờ chính là chương trình

Tôi nói Markdown, không phải là prompt.

Prompt là tạm thời. Bạn nhập một câu, nhận được một kết quả, và rồi nó biến mất.

Tôi đang nói về việc xây dựng. Là một quy trình xây dựng có quản lý phiên bản, có thể kiểm thử và tái sử dụng.

Markdown là lớp chỉ thị: ý định, kỹ năng, phán đoán, và các hướng dẫn về cách công việc nên được hoàn thành. TypeScript chỉ là một lớp logic xác định mỏng manh. Nó chỉ đảm nhận một số ít việc thực sự cần code làm: I/O, và những phần tuyệt đối không được phép ảo tưởng.

Quan trọng hơn, bạn phải kiểm thử Markdown giống như kiểm thử code.

Trong hệ thống của tôi, vòng lặp này chỉ cần một từ: skillify it.

Tôi sẽ cùng Agent làm ra một thứ gì đó cho đến khi nó hoạt động. Sau đó tôi nói: "skillify it." Agent sẽ viết ra:

Mô tả kỹ năng Markdown;

Code tối thiểu cần thiết;

Unit test cho code;

LLM eval cho kỹ năng;

Integration test bao phủ cả kỹ năng và code;

Một resolver để Agent tự động gọi kỹ năng này trong các tình huống liên quan;

Và eval cho chính resolver.

Toàn bộ những thứ này là một skill pack (gói kỹ năng). Nó là một đơn vị năng lực có thể tái sử dụng, và sẽ liên tục sinh lãi kép.

Điều thực sự kỳ diệu là kiểm thử: việc bao phủ kỹ năng cho phép nó không bị hỏng khi có thay đổi. Đây chính là điểm khác biệt giữa nó và vibe coding (viết code theo cảm tính). Vibe coding chỉ là cảm giác, còn skill pack có kiểm thử.

Chúng ta mới chỉ bắt đầu mày mò theo thời gian thực các nguyên thủy hệ thống của Agent engineering, giống như thời kỳ đầu của CPU khi phát minh ra stack, heap, register và kiến trúc Von Neumann.

Tôi cho rằng skill pack là một trong những nguyên thủy như vậy. Harness (khung thực thi) cũng là một nguyên thủy khác.

Hầu hết mọi người chưa nhận ra điều này, bởi vì họ vẫn đo lường phần mềm bằng số dòng code.

Bạn thực sự có thể xây dựng những thứ điên rồ

Đây không phải là một lập luận mang tính đồ chơi.

Agent này có thể làm được nhiều hơn ứng dụng Rails 500.000 dòng code kia, và lượng code mới thêm vào chỉ bằng một phần nhỏ của nó.

Hãy lấy một ví dụ cụ thể: chấm thi hackathon.

Hai tuần trước, vào thứ Bảy, chúng tôi tổ chức một hackathon GStack/GBrain với 85 bài dự thi. Tôi tải lên Google Drive chứa tất cả các bài dự thi và nói: bắt đầu.

Agent đã phân tích chất lượng code của từng kho lưu trữ, nghiên cứu sâu về từng thí sinh, xem và chụp ảnh màn hình từng video demo, chấm điểm giao diện, và xếp hạng 85 đội. Cuối cùng, nó cho tôi biết 5 ứng dụng đáng chú ý nhất trong số các bài dự thi này.

Chấm một hackathon, vốn là công việc vất vả kéo dài nhiều ngày, giờ đây chỉ còn khoảng 30 phút.

Tôi không viết code. Tôi để OpenClaw làm nhiệm vụ, còn tôi hướng dẫn nó. Sau khi nó hoàn thành, tôi nói: skillify it.

Và thế là nó trở thành một tarball mà bất kỳ ai cũng có thể tái sử dụng vĩnh viễn, áp dụng cho bất kỳ bảng hackathon nào.

Bây giờ tôi gần như nói "skillify" mỗi ngày. Tôi đã có hơn 350 skill pack. Hầu như tất cả các nhiệm vụ cá nhân và công việc tôi cần xử lý, giờ đây Agent của tôi đều có thể làm.

Đây là một ví dụ về sự đảo ngược.

Trước đây, một khả năng như thế này sẽ là một dự án phần mềm thực sự: cần crawler, pipeline chấm điểm, xử lý video, module nghiên cứu, hệ thống xếp hạng. Giờ đây, nó trở thành Markdown kèm một chút code, được Agent xây dựng trong một buổi chiều, và ai cũng có thể tái sử dụng.

Nhân tiện, quán quân của hackathon đó thực sự đã viết ra một đoạn code mà cuối cùng tôi đã chỉnh sửa và merge vào nhánh main. Giờ đây GStack có thể kiểm thử ứng dụng iOS trên cả trình giả lập và thiết bị thật, và tính năng hoàn chỉnh này được một người tạo ra trong chưa đầy 8 giờ tại hackathon.

Tokenmaxxing

Có một tấm vé vào cửa, nhưng hầu như không ai sẵn sàng trả tiền: bạn phải sẵn sàng chi tiền cho token.

Peter Steinberger đã tạo ra OpenClaw, harness yêu thích nhất của tôi. Anh ấy nói rằng mình sẵn sàng chi khoảng 1 triệu đô la mỗi năm cho token.

Hầu hết mọi người nghe con số này đều lùi bước. Nhưng họ không nên lùi bước, bởi vì vàng ở ngay đây: nếu bạn sẵn sàng làm điều này, bạn có thể sống ở năm 2028. Còn những người khác phải mất nhiều năm mới bắt kịp.

Đây cũng là lý do tại sao OpenAI quyết định cung cấp cho mỗi công ty YC tín dụng token trị giá 2 triệu đô la, dưới hình thức SAFE không giới hạn.

Khi bạn có thể chuyển đổi trí thông minh thô thành token, rồi biến token thành sản phẩm đầu ra thực sự có thể được người dùng sử dụng, giải quyết nhu cầu thực tế và người dùng sẵn sàng trả tiền, một điều kỳ diệu nào đó sẽ xảy ra.

Nếu bạn là nhà sáng lập, bạn nên tối đa hóa khả năng này. Đây cũng là lý do tại sao tôi luôn nhấn mạnh skillify, vì nó là một phương pháp thực sự mang lại kết quả tốt.

Trong một thời đại trước đây, chúng ta luôn nghĩ rằng việc gọi LLM quá đắt, phải sử dụng một cách tiết kiệm. Chúng ta liên tục ration, tức là phân phối chúng.

Nhưng bây giờ, chính bản năng này đang kìm hãm mọi người.

Nếu bạn sẵn sàng tokenmax, để Agent tự do tiêu thụ token và chạy liên tục, bạn có thể đạt được lợi thế đi trước tương tự như thời kỳ đầu của Internet năm 1994, chỉ khác là lần này chi phí được thanh toán bằng token.

Điều này sẽ loại bỏ hơn 99,99% tổ chức vẫn còn tính toán chi li với một nguồn tài nguyên đang giảm giá, và trao lợi thế dẫn đầu cho số ít những người thực sự hiểu rõ.

Vài chục nghìn đến vài trăm nghìn đô la một năm, thậm chí ít hơn đối với một số người, bạn có thể vận hành ngay hôm nay theo cách mà thế giới sẽ buộc phải áp dụng trong vài năm tới.

Bạn có thể sống như năm 2028 vào năm 2026. Khoản đầu tư trước này là xứng đáng. Bởi vì token trị giá 100.000 đô la hôm nay, năm sau có thể chỉ còn 10.000 đô la, năm sau nữa có thể chỉ còn 1.000 đô la, và đến cuối năm 2028 có thể chỉ còn 100 đô la.

Nếu bạn nói với bất kỳ nhà sáng lập nào trong lịch sử: bạn có thể đầu tư sáu con số vốn để đưa mình vào tương lai sớm hơn hai đến ba năm, và duy trì lợi thế này trong vài năm, thì trong số 100 nhà sáng lập đủ tiêu chuẩn, 100 người sẽ chấp nhận giao dịch này.

Thứ duy nhất cản đường, là bản năng từ năm 2013: nó bảo bạn rằng, gọi mô hình quá đắt, không thể thoải mái sử dụng.

Nhưng chúng không còn đắt nữa. Đó là kinh tế học cũ. Sự đảo ngược đã xảy ra.

Esalen, không phải Foxconn

Nếu 540.000 dòng mã điều khiển đang xây dựng một nhà máy Foxconn cho công nhân, thì giải pháp là xây dựng điều ngược lại của nó.

Ở vách đá Big Sur có một nơi gọi là Esalen. Người ta đến đó để được tháo dỡ, được tái tạo, bỏ lại bộ giáp, và trở về giống chính mình hơn.

Không có dây chuyền sản xuất. Không có quản đốc. Không có tiếng còi lúc 6 giờ sáng. Là tự do, chứ không phải kiểm soát.

Hãy xây dựng những thứ như thế.

Hãy xây dựng một nơi như YC: nơi chúng tôi giúp bạn xây dựng công ty, giải quyết vấn đề thực tế, tìm ra product-market fit.

Xây dựng những nơi giải phóng người lao động, dù họ là con người hay AI.

Đó chính là tinh thần cốt lõi.

Làm những thứ giải phóng Agent. Làm những công ty giải phóng con người.

Trong công việc tri thức, nhà máy là một mô hình thất bại. Mục tiêu thực sự là xây dựng các tổ chức giải phóng con người. Giờ đây, mục tiêu này cũng hướng đến Agent.

OpenClaw giống như một chiếc Ferrari mà bạn phải tự mang theo cờ lê. Mô hình là động cơ, không phải cả chiếc xe. Chúng ta vẫn đang ở thời khắc Apple I, vẫn đang hàn bảng mạch.

Nó được phát hành một cách thô sơ. Bạn vẫn phải tự mình hoàn thiện nó.

GBrain, công cụ truy xuất và skill pack mà tôi mã nguồn mở, vẫn chưa phải là sản phẩm hoàn chỉnh dùng ngay được.

Có người nói OpenClaw không an toàn. Họ không hiểu rằng, chính sự tự do mới là lý do nó mạnh mẽ. Trước khi bạn thực sự gặp vấn đề, đừng vội lắp rào chắn an toàn vào thứ bạn tin tưởng. Cây cờ lê trong tay bạn chính là minh chứng nó chưa bị nhốt trong lồng.

Hệ thống kiểm soát tinh vi vì kiểm soát cần sự kiểm soát tuyệt đối, tức là nhà máy Foxconn. Hệ thống tự do thô sơ vì nó tin rằng bạn sẽ hoàn thiện nó.

Bạn phải chọn xem mình đang xây dựng loại nào. Sau đó, hãy nhìn lại xem bạn đã viết bao nhiêu dòng code.

Điều này thực sự có nghĩa là gì

540.000 dòng code Rails, là cách tôi chứng minh mình vẫn có thể chơi ở đẳng cấp cao nhất trong trò chơi cũ.

Nhưng đẳng cấp đó thuộc về Web 2.0, thuộc về mười năm trước.

Tôi vẫn có thể chơi tốt như xưa, thậm chí trở thành kỹ sư 1000x. Nhưng tôi đang xây dựng nhà máy Foxconn. Code cũ. Trò chơi cũ.

Còn trò chơi mới, hoàn toàn không phải chơi bằng số dòng code.

Kết quả là, những anti-fan của tôi đã đúng. Nếu các bạn đang đọc bài viết này, những người bạn ẩn danh, tôi xin gửi lời chào.

Khi bạn có thể biến ý định trực tiếp thành một hệ thống có thể chạy, kiểm thử và tái sử dụng, thì nút thắt cổ chai không còn là bạn có thể xây dựng được bao nhiêu, mà là bạn thực sự muốn gì, và liệu nó có đáng để xây dựng hay không.

Tài nguyên khan hiếm trở thành sự rõ ràng, gu thẩm mỹ và khả năng phán đoán.

Kỹ sư viết ít code nhất, thường mới là người xây dựng nhiều nhất.

Tôi đã viết 540.000 dòng code mới học được điều này. Bạn không cần phải lặp lại con đường đó.

[Liên kết gốc]

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia