Lời biên tập: Khi ngày càng nhiều người thảo luận "AI có thay thế lập trình viên không", thì Garry Tan - Chủ tịch YC - lại đặ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 vài tháng để viết một dự án có tên Garry's List với 540 nghìn dòng code bằng Rails và AI Agent. Sau khi hoàn thành dự án, anh lại đi đến một kết luận nghe có vẻ mâu thuẫn: 540 nghìn dòng code đó bản thân chúng không quan trọng, giá trị thực sự nằm ở GStack - một khung phát triển mới xoay quanh quy trình làm việc của AI Agent - được đúc kết trong quá trình phát triển.
Theo anh, vài năm gần đây 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 vào các bài kiểm tra, bộ kiểm tra, cơ chế thử lại, tác vụ nền và các logic điều khiển khác nhau, bao bọc mô hình bằng nhiều lớp. Cách làm này có lý do hợp lý trong thời kỳ mô hình đắt đỏ và năng lực hạn chế, nhưng khi LLM đã có thể tự chủ hoàn thành khối lượng lớn công việc, những hệ thống này lại giống như đang xây dựng một "nhà máy Foxconn" cho một công nhân siêu thông minh - dùng hàng loạt quy tắc và quy trình để kiềm chế một tác nhân thông minh vốn đã có đủ năng lực.
Khi chi phí mô hình giảm nhanh và năng lực tiếp tục được nâng cao, trọng tâm của phát triển phần mềm có lẽ đang chuyển từ "viết thêm nhiều code" sang "thiết kế thêm nhiều năng lực". Tác giả đề xuất sử dụng Markdown để xây dựng skill pack (gói kỹ năng, tức là các module năng lực có thể kiểm tra, tái sử dụng), để Agent tự động tạo ra code, hệ thống kiểm tra và đánh giá, biến các quy trình công việc phức tạp thành tài sản năng lực có thể tái đầu tư sinh lợi. Anh thậm chí còn đưa ra một ví dụ: công việc đánh giá hackathon vốn cần vài ngày để hoàn thành, giờ đây chỉ cần vài chục phút là Agent có thể làm xong.
Ở 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à về sự kết thúc của logic công nghiệp hóa phần mềm. Khi code không còn là nguồn lực khan hiếm nhất, lợi thế cạnh tranh cốt lõi của kỹ sư cũng bắt đầu chuyển dịch: So với việc viết ra nhiều code hơn, thì khả năng phán đoán đ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 có thể 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, chưa chắc đã là người viết nhiều code nhất, mà có thể là người viết ít nhất, nhưng lại giải phóng được nhiều trí tuệ nhất.
Dưới đây là nguyên văn:
Tháng 1 năm nay, tôi lại bắt đầu viết code, làm ra Garry's List. Code Rails cộng với các bài kiểm tra dùng để ràng buộc nó, tổng cộng hơn 500 nghìn 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. Thứ thực sự đáng tự hào không phải là ứng dụng này, mà là cách thức làm việc mà tôi đã mò mẫm ra trong quá trình xây dựng nó. GStack, tức là cách tôi lập trình bằng Agent, chính là mọc lê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ó số sao cao nhất trong lịch sử GitHub, chưa đầy ba tháng đã đạt được khoảng 105 nghìn sao.
Hơn 500 nghìn dòng code đó là "sản phẩm". Cách thức làm việc kia mới là "sản phẩm phụ". Và thứ thực sự quan trọng, chính là sản phẩm phụ này.
Vậy thì, về bản chất, 540 nghìn dòng code được dựng xung quanh một LLM là gì?
Nó là một nhà máy Foxconn. Một nhà máy được xây cho một công nhân AI có trí thông minh cao. Người công nhân này vốn không cần được giám sát chặt chẽ, nhưng chúng ta vẫn xây cho nó.
Vào cửa phải đi giày bọc. 6 giờ sáng phải dậy. Tập thể dục tập thể. Ngày này qua ngày khác đứng trên cùng một dây chuyền lắp ráp. Cuộc sống khó khăn đến mức 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à một cuộc sống mà bạn muốn có. Mỗi bài kiểm tra, mỗi hàng rào bảo vệ, mỗi vòng lặp thử lại, đều là một inch lồng sắt vặn lên người công nhân này. Trong khi người công nhân này vốn đã có thể hoàn thành công việc này, thậm chí còn có thể làm được cả nghìn việc mà bạn chưa từng nghĩ tới.
Con người và Agent đều có khả 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ừ những sinh mệnh tươi đẹp. Vốn dĩ chúng 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 như vậy.
Tôi đã từng xây những nhà máy như vậy. Hôm nay hầu như mọi người đều đang xây 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.
Nhà du hành thời gian
Với 539 nghìn dòng code, điều tôi thực sự chứng minh được, là tôi có thể hoàn hảo đóng giả một nhà 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 cùng thực sự được gọi là kỹ sư phần mềm, bị ném vào năm 2026, trong tay cầm công cụ hiện đại, nhưng vẫn xây dựng phần mềm theo cách duy nhất mà anh ta quen thuộc: nhiều code hơn. Mãi mãi là nhiều code hơn.
Công cụ đã thay đổi, nhưng bản năng của tôi không đổi.
Người kỹ sư năm 2013 trong xương tủy tin vào một điều: Năng lực bằng số dòng code. Niềm tin này trong vài chục năm qua vẫn đúng, cho đến hôm nay.
Nếu bạn đưa Codex hay Claude Code cho tôi, 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 đây vẫn là cùng một tấm bản đồ, chỉ là thay động cơ nhanh hơn, lao với tốc độ nhanh nhất đến một đích đến mà giờ đã sai.
Đâ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 tại. Họ nâng cấp công cụ, nhưng giữ lại mô hình tư duy năm 2013.
Cái bẫy này trông không giống bẫy, bởi vì code thực sự chạy được. Garry's List thực sự đã lên sóng. Tháng đó, tôi cảm thấy mình như đang trải qua giai đoạn năng suất cao nhất trong đờ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, nên chúng ta phải "thuần hóa" chúng
Kinh tế học cũ khoảng trước năm 2025 là: Gọi LLM rất đắt, còn code thì rẻ.
Vì vậy bạn sẽ viết code để tiết kiệm lời gọi mô hình, kiềm chế nó, thuần hóa nó, gọi nó một cách thận trọng. Kiến trúc lúc đó là: Dùng nhiều phần mềm bao bọc một số ít lời gọi mô hình quý giá.
Nhưng cả hai vế của phương trình này đã đảo ngược.
Mô hình đang trở nên rẻ, và mỗi quý lại càng rẻ hơn. Đồng thời, mô hình đủ thông minh, tỷ lệ giá trị trên chi phí đã đảo ngược. Mô hình còn có thể viết ra code dùng được.
Vì vậy bạn không cần viết code để "trông coi" mô hình nữa. Bạn có thể dùng ngôn ngữ tự nhiên nói với mô hình phải 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 sinh thành tức thời), và chúng ta đang bước vào thời đại hoàng kim của nó.
Hình thái của sản phẩm phần mềm cũng thay đổi triệt để. Ứng dụng Rails kia là 540 nghìn dòng code tôi viết và sở hữu, cùng các bài kiểm tra dùng để giám sát nó. Vật thay thế của nó, là một Agent cấu thành từ Markdown và một ít code, quy mô chỉ bằng một phần nhỏ của cái trước.
Năng lực tương đương. Dễ đọc hơn. Dễ bảo trì hơn. Cũng linh hoạt hơn nhiều. Bởi vì hành vi tồn tại trong các chỉ dẫn mà bạn có thể chỉnh sửa bằng ngôn ngữ tự nhiên, chứ không đông cứng trong logic code bạn viết vào một ngày nào đó.
Chúng ta từng viết code để trông coi một thứ, nhưng giờ đây thứ đó đã thông minh hơn những dòng code kia.
Bên trong nhà máy Foxconn: Thậm chí lưới bảo vệ cũng đã dựng xong
Nếu gần đây bạn viết code, rất có thể bạn đã vô tình xây loại nhà máy này.
Bạn có thể đi vào kho code của mình, đế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 nghìn dòng code ứng dụng, và khoảng 276 nghìn dòng bài kiểm tra dùng để giám sát nó. Ủy ban kiểm toán còn lớn hơn cả công ty.
Có những bộ làm sạch đang kiểm tra đầu vào mà mô hình vốn có thể xử lý. Có những bộ kiểm tra đang kiểm tra đầu ra mà mô hình vốn có thể phát hiện. Có những vòng lặp thử lại bao bọc lời 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 ván cược: Người công nhân này chắc chắn sẽ thất bại.
Bạn cũng đã từng đặt cược tương tự. Tất cả chúng ta đều từng.
127 tác vụ nền, trong đó 33 cái là tác vụ đị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 mà giờ thường đi làm đúng giờ.
Trong những ngày tôi xây "nhà máy Foxconn", Claude và tôi đã viết một file 1778 dòng. Tác dụng 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 từng luận điểm 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 luận điểm đơn giản sẽ trải qua một ngưỡng phân loại nhẹ trước, tránh tất cả nội dung đều đi qua quy trình đầy đủ. Nếu vòng đầu không có kết quả, thì thử lại. Rồi còn có phương án dự phòng cho phương án dự phòng.
Trong một tập "Rick và Morty", Rick tạo ra một con robot nhỏ trên bàn ăn sáng. Robot khởi động xong ngẩng đầu hỏi: Sứ mệnh của tôi là gì? Rick nói: Con phụ trách đưa bơ. Con robot đẩy đĩa bơ qua, cúi đầu nhìn đôi tay mình, nói: Trời ơi. Rồi nó ngồi đó. Con robot đó cũng có khả năng vô hạn. Nó lại được tạo ra để đưa bơ. 276 nghìn dòng bài kiểm tra 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 2023, bạn đang xây 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 giờ đây chính là chương trình
Tôi nói Markdown, không phải là prompt.
Prompt là nhất thời. Bạn nhập một câu, nhận một kết quả, rồi nó bốc hơi.
Tôi nói đến việc xây dựng. Là sự xây dựng có quản lý phiên bản, có thể kiểm tra, có thể tái sử dụng.
Markdown là lớp chỉ dẫn: ý định, kỹ năng, phán đoán, cùng hướng dẫn về cách công việc nên được hoàn thành. TypeScript thì 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ự phải do code hoàn thành: I/O, và những phần tuyệt đối không được ảo giác.
Quan trọng hơn, bạn phải kiểm tra Markdown như kiểm tra 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ì đó trước, cho đến khi nó chạy được. Sau đó tôi nói: "skillify it." Tiếp theo Agent sẽ viết ra:
Hướng dẫn kỹ năng Markdown;
Lượng code tối thiểu mà nó cần;
Bài kiểm tra đơn vị cho code;
Đánh giá LLM cho kỹ năng;
Bài kiểm tra tích hợp bao phủ cả kỹ năng và code;
Một bộ phân giải (resolver), để Agent tự động gọi kỹ năng này trong ngữ cảnh liên quan;
Và đánh giá của chính bộ phân giải đó.
Toàn bộ bộ này, chính 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, sẽ liên tục sinh lợi kép.
Thứ thực sự kỳ diệu là kiểm tra: Việc bao phủ skill, cho phép nó không bị phá vỡ trong quá trình thay đổi. Đây là điểm khác biệt giữa nó và vibe coding (viết code theo cảm giác). Vibe coding chỉ là cảm giác, còn skill pack có kiểm tra.
Chúng ta hiện mới chỉ bắt đầu mò mẫm theo thời gian thực các nguyên thủy hệ thống của kỹ thuật Agent, giống như thời kỳ CPU đầu tiên phát minh ra ngăn xếp, heap, thanh ghi và kiến trúc Von Neumann vậy.
Tôi cho rằng skill pack chính 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 dùng số dòng code để đo lường phần mềm.
Bạn thực sự có thể xây ra những thứ điên rồ
Đây không phải là một luận điểm đồ chơi.
Những việc Agent này có thể làm, đã vượt qua ứng dụng Rails hơn 500 nghìn dòng kia, và lượng code mới tăng thêm chỉ bằng một phần nhỏ của cái sau.
Một ví dụ cụ thể: Đánh giá hackathon.
Thứ Bảy hai tuần trước, chúng tôi tổ chức một hackathon GStack/GBrain, có 85 tác phẩm nộp. Tôi tải lên Google Drive chứa tất cả tác phẩm, sau đó nói: Bắt đầu.
Agent phân tích chất lượng code của mỗi kho code, 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 lô tác phẩm này.
Việc đánh giá một hackathon, vốn là mấy ngày làm việc vất vả, giờ đã trở thành việc khoảng 30 phút.
Tôi không viết code. Tôi để OpenClaw làm nhiệm vụ, tôi phụ trách hướng dẫn nó. Khi nó hoàn thành, tôi nói: skillify it.
Thế là nó trở thành một gói tarball mà bất kỳ ai cũng có thể tái sử dụng mãi mãi, có thể áp dụng trên bất kỳ bảng hackathon nào.
Giờ tôi hầu như ngày nào cũng nói "skillify". Tôi đã có hơn 350 skill pack. Hầu hết mọi nhiệm vụ tôi cần xử lý trong công việc và cuộc sống cá nhân, 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 kia, một năng lực như vậ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 cộng một chút code, do Agent xây dựng trong một buổi chiều, và mọi người đều 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à hợp nhất vào nhánh main. Giờ đây GStack có thể kiểm tra ứng dụng iOS trên máy giả lập và thiết bị thật, và tính năng hoàn chỉnh này, là do một người làm ra trong chưa đầy 8 giờ tại hackathon.
Tokenmaxxing
Ở đây có một tấm vé vào cửa, nhưng hầu như không ai muốn trả tiền: Bạn phải sẵn sàng tiêu tiền vào token.
Peter Steinberger đã làm OpenClaw, đây là harness tôi thích nhất. Anh ấy từng nói, mình sẵn sàng chi khoảng 1 triệu đô la mỗi năm vào token.
Hầu hết mọi người nghe con số này sẽ 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 vài năm mới đuổi 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 2 triệu đô la tín dụng token, dưới dạng SAFE không giới hạn (uncapped SAFE).
Khi bạn có thể chuyển hóa trí thông minh thô thành token, rồi lại chuyển hóa token thành sản phẩm thực sự có thể được người dùng sử dụng, giải quyết nhu cầu thực, và người dùng sẵn sàng trả tiền, thì một điều gì đó kỳ diệu sẽ xảy ra.
Nếu bạn là người sáng lập, bạn nên kéo khả năng này lên mức tối đa. Đây cũng là lý do tôi luôn nhấn mạnh skillify, bởi vì nó là một phương pháp thực sự mang lại kết quả tốt.
Một thời đại trước, chúng ta luôn cảm thấy gọi LLM quá đắt, phải sử dụng tiết chế. Chúng ta luôn ration, tức là phân phối chúng.
Nhưng giờ đây, chính bản năng này đang kéo chậm mọi người lại.
Nếu bạn sẵn sàng tokenmax, sẵn sàng để Agent tự do tiêu thụ token, chạy liên tục, bạn sẽ có được lợi thế tiên phong giống như thời kỳ đầu internet năm 1994, chỉ là lần này chi phí được trả bằng token.
Điều này sẽ chặn hơn 99.99% tổ chức vẫn còn tính toán chi li với một nguồn lực đang sụp đổ giá, trao lợi thế dẫn đầu cho một số ít người thực sự hiểu.
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, hôm nay bạn đã có thể vận hành theo cách mà cả thế giới năm sau bắt buộc phải áp dụng.
Bạn có thể sống năm 2026 như năm 2028. Khoản đầu tư trước này là đáng giá. Bởi vì token trị giá 100 nghìn đô la hôm nay, năm sau có thể chỉ còn 10 nghìn, năm sau nữa có thể chỉ còn 1 nghìn, đến cuối năm 2028 có lẽ 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ư vốn sáu chữ số, để khiến mình tiến vào tương lai trước hai đến ba năm, và duy trì lợi thế này trong vài năm, thì 100 người sáng lập đủ tiêu chuẩn, cả 100 người sẽ chấp nhận thương vụ này.
Thứ duy nhất cản đường, là bản năng năm 2013 đó: Nó nói với bạn rằng, gọi mô hình quá đắt, không được dùng thoải mái.
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, chứ không phải Foxconn
Nếu 540 nghìn dòng code điều khiển là đang xây một nhà máy Foxconn cho công nhân, thì giải pháp là xây mặt đối lập của nó.
Ở rìa vách đá Big Sur có một nơi tên là Esalen. Người ta đến đó để bị tháo rời, được tái tạo, buông bỏ áo giáp, rồi trở về giống với bản thân mình hơn.
Không có dây chuyền lắp ráp. 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 những thứ như vậy.
Hãy xây một nơi như YC: Nơi chúng tôi giúp bạn thành lập công ty, giải quyết vấn đề thực, tìm được product-market fit.
Xây những nơi có thể cho công nhân tự do, dù những công nhân đó là con người, hay AI.
Đây chính là toàn bộ tinh thần cốt lõi.
Làm những thứ có thể giải phóng Agent. Làm những công ty có thể để con người tự do phát huy.
Trong công việc tri thức, nhà máy là mô hình thất bại. Mục tiêu thực sự, là thiết lập các cơ cấu 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 cờ lê theo. Mô hình là động cơ, không phải toàn bộ chiếc xe. Chúng ta vẫn đang ở thời khắc Apple I, vẫn còn hàn bảng mạch.
Nó được phát hành rất thô. Bạn vẫn phải tự hoàn thiện nó.
GBrain, công cụ tìm kiếm 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ó người nói OpenClaw không an toàn. Họ không hiểu, tự do chính là lý do nó mạnh mẽ. Trước khi bạn thực sự gặp vấn đề, đừng vội vặn hàng rào an toàn lên một thứ mà bạn tin tưởng. Cây cờ lê trong tay bạn, chính là bằng chứng cho thấy nó chưa bị nhốt vào lồng.
Hệ thống kiểm soát tinh xảo, bởi vì kiểm soát cần kiểm soát triệt để, tức là nhà máy Foxconn. Hệ thống tự do thô, bởi vì nó tin rằng bạn sẽ hoàn thiện nó.
Bạn phải chọn mình thực sự đang xây loại nào. Rồi hãy nhìn lại bạn đã viết bao nhiêu code.
Rốt cuộc điều này có ý nghĩa gì
540 nghìn dòng code Rails, là bằng chứng tôi vẫn có thể chơi đến trình độ cao nhất trong trò chơi cũ.
Nhưng trình độ đó 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ư trước, thậm chí có thể trở thành kỹ sư gấp 1000 lần. Nhưng tôi làm xây nhà máy Foxconn. Code cũ. Trò chơi cũ.
Còn trò chơi mới, về cơ bản không phải chơi bằng số dòng code.
Kết quả là, những người hâm mộ đen 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 đến các bạn.
Khi bạn có thể chuyển hóa trực tiếp ý định thành hệ thống có thể chạy, có thể kiểm tra, có thể tái sử dụng, thì nút cổ chai không còn là bạn có thể xây bao nhiêu thứ, mà là bạn thực sự muốn gì, và nó có đáng xây hay không.
Nguồn lực khan hiếm trở thành sự rõ ràng, gu thẩm mỹ và năng lực phán đoán.
Người kỹ sư viết code ít nhất, thường mới là người xây dựng nhiều thứ nhất.
Tôi đã viết 540 nghìn dòng code mới học được điều này. Bạn không cần phải đi lại một lần nữa.







