Showing posts with label Andrej Karpathy. Show all posts
Showing posts with label Andrej Karpathy. Show all posts

5.05.2026

Andrej Karpathy: Từ Vibe Coding Đến Kỹ Thuật Tác Nhân — Bản Ghi Chép Đầy Đủ

Sự kiện: AI Ascent 2026, do Sequoia Capital tổ chức

Khách mời: Andrej Karpathy — đồng sáng lập OpenAI, cựu Giám Đốc Trí Tuệ Nhân Tạo tại Tesla, sáng lập Eureka Labs

Người phỏng vấn: Stephanie Zhan, Cộng Tác Viên tại Sequoia Capital

Năm: 2026

Giới Thiệu

STEPHANIE ZHAN: Chúng tôi vô cùng vui mừng được đón tiếp vị khách đặc biệt đầu tiên. Ông đã giúp xây dựng trí tuệ nhân tạo hiện đại, rồi giải thích nó, và đôi khi đặt tên lại cho nó. Thực ra ông đã đồng sáng lập OpenAI, ngay tại văn phòng này. Ông là người đã làm cho hệ thống Autopilot của Tesla hoạt động được từ thuở ban đầu, và ông có một tài năng hiếm có: biến những bước chuyển mình kỹ thuật phức tạp nhất thành điều vừa dễ hiểu vừa tất yếu.

Tất cả các bạn đều biết ông qua thuật ngữ "vibe coding" mà ông đặt ra năm ngoái, nhưng chỉ trong vài tháng gần đây, ông đã nói một điều còn đáng kinh ngạc hơn: rằng ông chưa bao giờ cảm thấy mình bị bỏ lại phía sau như một lập trình viên đến vậy. Đó là điểm khởi đầu của chúng ta hôm nay. Cảm ơn ông Andrej đã có mặt.

Cảm Giác Bị Tụt Hậu Như Một Lập Trình Viên

ANDREJ KARPATHY: Vâng. Xin chào. Rất vui được có mặt ở đây để mở đầu.

STEPHANIE: Được rồi. Vậy thì, chỉ vài tháng trước, ông đã nói rằng ông chưa bao giờ cảm thấy mình bị tụt hậu như một lập trình viên đến vậy. Thật đáng ngạc nhiên khi nghe điều này từ chính ông. Ông có thể giúp chúng tôi hiểu rõ hơn không? Cảm giác đó là phấn khích hay bất an?

ANDREJ: Vừa phấn khích vừa bất an. Trước hết, cũng như nhiều người trong số các bạn, tôi đã dùng các công cụ tác nhân — những thứ như Claude Code và các công cụ tương tự — trong một thời gian, có lẽ hơn một năm nay kể từ khi chúng ra đời. Chúng rất giỏi với từng đoạn code. Đôi khi chúng sai và bạn phải sửa, nhưng nhìn chung cũng khá hữu ích. Rồi thì tháng Mười Hai năm ngoái là một bước ngoặt rõ ràng. Tôi đang nghỉ phép nên có nhiều thời gian hơn. Tôi nghĩ nhiều người cũng có trải nghiệm tương tự. Tôi bắt đầu nhận ra rằng với các mô hình mới nhất, các đoạn code cứ ra đúng hoài. Rồi tôi tiếp tục yêu cầu thêm và nó vẫn cứ đúng. Rồi tôi không còn nhớ lần cuối mình phải sửa nó là khi nào. Và rồi tôi ngày càng tin tưởng hệ thống hơn, và thế là tôi "vibe coding" rồi.

(tiếng cười)

Đó thực sự là một bước chuyển rất rõ ràng. Tôi đã cố gắng nhấn mạnh điều này trên Twitter — hay X — vì tôi nghĩ nhiều người trải nghiệm AI năm ngoái như một thứ gì đó gần với ChatGPT. Nhưng đến tháng Mười Hai, bạn thực sự phải nhìn lại, vì mọi thứ đã thay đổi cơ bản — đặc biệt là về quy trình làm việc tác nhân liên mạch, thứ đã thực sự bắt đầu hoạt động được. Chính nhận thức đó đã khiến tôi lao vào cái hố thỏ này của vô số dự án cá nhân. Thư mục dự án phụ của tôi đầy ắp với đủ thứ ngẫu nhiên, và tôi cứ vibe coding suốt. Vậy đó, chuyện đó xảy ra vào tháng Mười Hai, và tôi đã theo dõi những hệ lụy của nó từ đó đến nay.

Giải Thích Software 3.0

STEPHANIE: Ông đã nói rất nhiều về ý tưởng LLM như một máy tính mới — không chỉ là phần mềm tốt hơn, mà là một mô thức tính toán hoàn toàn mới. Software 1.0 là các quy tắc tường minh, software 2.0 là các trọng số được học, software 3.0 là thứ này. Nếu điều đó thực sự đúng, thì một nhóm phát triển sẽ xây dựng khác đi thế nào vào ngày họ thực sự tin vào điều này?

ANDREJ: Đúng vậy. Software 1.0, tôi viết code. Software 2.0, tôi thực ra lập trình bằng cách tạo ra các bộ dữ liệu và huấn luyện mạng thần kinh — vậy nên lập trình ở đây có nghĩa là sắp xếp dữ liệu và có thể một số mục tiêu cùng kiến trúc mạng thần kinh. Rồi điều đã xảy ra là: về cơ bản, nếu bạn huấn luyện một trong những mô hình GPT hay LLM này trên một tập hợp nhiệm vụ đủ lớn — ngầm định, vì khi huấn luyện trên internet bạn phải xử lý đồng thời tất cả mọi thứ trong bộ dữ liệu — những mô hình này thực ra trở thành một loại máy tính có thể lập trình được theo nghĩa nào đó. Vậy software 3.0 về cơ bản là: lập trình của bạn bây giờ chuyển thành viết prompt, và những gì trong cửa sổ ngữ cảnh là đòn bẩy của bạn đối với bộ thông dịch là LLM, thứ đang diễn giải ngữ cảnh của bạn và thực hiện tính toán trong không gian thông tin số. Đó là bước chuyển đó. Và tôi nghĩ có một vài ví dụ thực sự đã làm tôi hiểu ra điều này.

Tác Nhân Như Một Bộ Cài Đặt

ANDREJ: Ví dụ, khi Claude Code ra đời — khi bạn muốn cài đặt nó, thông thường bạn sẽ mong đợi đó là một bash script, một shell script. Bạn chạy shell script để cài đặt Claude Code. Nhưng vấn đề là, để nhắm tới nhiều nền tảng và nhiều loại máy tính khác nhau, những shell script này thường phình to ra và trở nên cực kỳ phức tạp. Và bạn vẫn mắc kẹt trong vũ trụ software 1.0 của việc muốn viết code. Thực ra, cài đặt Claude Code là một đoạn văn bản mà bạn copy-paste và đưa cho tác nhân của mình. Về cơ bản đó là một kỹ năng nhỏ — bạn copy-paste đoạn này và đưa cho tác nhân, và nó sẽ cài đặt Claude Code. Lý do điều này mạnh mẽ hơn nhiều là vì bạn đang làm việc trong mô thức software 3.0, nơi bạn không cần phải liệt kê từng chi tiết cụ thể của việc cài đặt đó. Tác nhân có trí thông minh riêng của mình, nó gói gọn mọi thứ, làm theo hướng dẫn, xem xét môi trường và máy tính của bạn, thực hiện các hành động thông minh để mọi thứ hoạt động, gỡ lỗi trong vòng lặp — và nó mạnh mẽ hơn rất nhiều. Đây là một cách suy nghĩ rất khác: đoạn văn bản nào để copy-paste cho tác nhân? Đó chính là mô thức lập trình bây giờ.

MenuGen So Với Các Prompt Thô

ANDREJ: Thêm một ví dụ khác còn cực đoan hơn, đó là khi tôi đang xây dựng MenuGen. MenuGen là ý tưởng khi bạn đến nhà hàng, họ đưa cho bạn một thực đơn, thường không có hình ảnh. Vậy nên tôi không biết nhiều món là gì — thường khoảng ba mươi phần trăm các món tôi không biết, đôi khi năm mươi phần trăm. Vậy nên tôi muốn chụp ảnh thực đơn nhà hàng và nhận được hình ảnh những món đó có thể trông như thế nào theo nghĩa chung. Tôi đã vibe-code ứng dụng này, thứ về cơ bản cho phép bạn tải ảnh lên và xử lý tất cả những thứ đó. Nó chạy trên Vercel, hiển thị lại thực đơn, cho bạn xem tất cả các món, và sử dụng trình tạo hình ảnh để OCR tất cả các tiêu đề khác nhau, lấy hình ảnh của chúng, và hiển thị cho bạn. Rồi tôi thấy phiên bản software 3.0 của điều này, và nó thổi bay tâm trí tôi. Nó chỉ đơn giản là: chụp ảnh, đưa cho Gemini, và nói "Hãy dùng Nana Banana để phủ các món ăn lên thực đơn." Và Nana Banana trả lại một hình ảnh chính xác là tấm ảnh thực đơn tôi đã chụp, nhưng nó đã đặt vào các pixel những hình ảnh được render của các món trong thực đơn. Điều này thổi bay tâm trí tôi, vì toàn bộ MenuGen của tôi là thừa. Nó đang hoạt động trong mô thức cũ — ứng dụng đó không nên tồn tại. Và mô thức software 3.0 thô hơn nhiều: mạng thần kinh của bạn đang làm ngày càng nhiều công việc, prompt hay ngữ cảnh của bạn chỉ là hình ảnh, đầu ra là một hình ảnh, và không cần bất kỳ ứng dụng nào ở giữa.

Vậy nên tôi nghĩ mọi người phải tái định khung mọi thứ — không làm việc trong mô thức hiện tại của những gì đã tồn tại và chỉ coi đó là tăng tốc độ. Thực ra là những thứ mới đang có mặt bây giờ. Và điều đó cũng là ví dụ của việc làm việc với tư duy cũ, bởi vì không chỉ là lập trình trở nên nhanh hơn. Đây là xử lý thông tin tổng quát hơn, nay có thể tự động hóa. Vậy nên nó không chỉ là về code. Code trước đây hoạt động trên dữ liệu có cấu trúc. Nhưng ví dụ, với dự án LLM knowledge bases của tôi — về cơ bản bạn dùng LLM để tạo wiki cho tổ chức hoặc cho bản thân — đây thậm chí không phải là một chương trình. Đây không phải là thứ có thể tồn tại trước đây, vì không có code nào sẽ tạo ra một knowledge base từ một loạt sự kiện. Nhưng bây giờ bạn chỉ cần lấy những tài liệu này và về cơ bản biên dịch lại chúng theo cách khác, sắp xếp lại chúng, và tạo ra thứ gì đó mới và thú vị. Đây là những thứ mới không thể thực hiện được trước đây. Tôi cứ cố gắng quay lại câu hỏi đó: không chỉ là những gì chúng ta có thể làm nhưng nhanh hơn, mà là những cơ hội mới nào — những thứ không thể thực hiện được trước đây? Và tôi gần như nghĩ điều đó còn thú vị hơn.

Điều Gì Sẽ Hiển Nhiên Vào Năm 2026

STEPHANIE: Tôi rất thích sự tiến triển và tương phản của MenuGen mà ông đã trình bày. Nếu ông nhìn xa hơn — điều tương đương năm 2026 là gì của việc xây dựng trang web trong những năm 90, xây dựng ứng dụng di động trong những năm 2010, xây dựng SaaS trong kỷ nguyên cloud trước? Điều gì sẽ trông hoàn toàn hiển nhiên khi nhìn lại mà hiện tại vẫn còn chủ yếu chưa được xây dựng?

ANDREJ: Vâng, đi theo ví dụ MenuGen, rất nhiều code này không nên tồn tại — chỉ là một mạng thần kinh đang làm hầu hết công việc. Tôi nghĩ sự ngoại suy trông rất kỳ lạ vì bạn có thể tưởng tượng những máy tính hoàn toàn thần kinh theo một nghĩa nào đó. Bạn đưa video hoặc âm thanh thô vào cơ bản là một mạng thần kinh, và nó sử dụng diffusion để render một giao diện người dùng độc đáo cho thời điểm đó. Và tôi cảm thấy như trong những ngày đầu của máy tính, mọi người hơi bối rối về việc liệu máy tính sẽ trông như máy tính bỏ túi hay như mạng thần kinh — trong những năm 50 và 60 của thế kỷ trước, không rõ ràng hướng nào sẽ thắng. Và tất nhiên chúng ta đã đi theo con đường máy tính bỏ túi và kết thúc bằng máy tính cổ điển. Và rồi mạng thần kinh đang chạy ảo hóa trên máy tính hiện có. Nhưng bạn có thể tưởng tượng rằng nhiều điều trong số này sẽ đảo ngược, và mạng thần kinh trở thành tiến trình chủ còn CPU trở thành đồng xử lý. Bạn có thể tưởng tượng điều gì đó thực sự kỳ lạ và xa lạ, nơi mạng thần kinh đang làm hầu hết công việc nặng nhọc, sử dụng công cụ như một thứ phụ lục lịch sử cho một số nhiệm vụ xác định, nhưng những gì thực sự điều hành mọi thứ là các mạng thần kinh này. Nhưng tôi nghĩ chúng ta sẽ đến đó từng bước một. Và sự tiến triển đó, thật ra vẫn còn chưa biết.

(tiếng cười)

Tính Kiểm Chứng Và Trí Tuệ Lởm Chởm

STEPHANIE: Tôi muốn nói một chút về khái niệm có thể kiểm chứng được — thực tế là AI sẽ tự động hóa nhanh hơn và dễ dàng hơn trong các lĩnh vực mà đầu ra có thể được kiểm chứng. Nếu khung đó đúng, công việc nào sắp chuyển động nhanh hơn mọi người nhận ra? Và những nghề nghiệp nào mọi người nghĩ là an toàn nhưng thực ra có tính kiểm chứng cao?

ANDREJ: Vâng. Vậy nên tôi đã dành một chút thời gian viết về tính kiểm chứng. Về cơ bản, máy tính truyền thống có thể dễ dàng tự động hóa những gì bạn có thể chỉ định trong code. Và vòng LLM mới nhất này có thể dễ dàng tự động hóa những gì bạn có thể kiểm chứng — theo một nghĩa nào đó — bởi vì cách thức hoạt động của nó là khi các phòng thí nghiệm hàng đầu huấn luyện những LLM này, đây là những môi trường học tăng cường khổng lồ. Vậy nên chúng được cho phần thưởng kiểm chứng, và vì cách các mô hình này được huấn luyện, chúng cuối cùng về cơ bản tiến bộ và tạo ra những thực thể lởm chởm này, thực sự đạt đỉnh năng lực trong các lĩnh vực có thể kiểm chứng như toán học và code và các lĩnh vực lân cận — và hơi đình trệ, hơi thô ở những lĩnh vực không nằm trong không gian đó.

Vậy nên tôi nghĩ lý do tôi viết về tính kiểm chứng là tôi đang cố gắng hiểu tại sao những thứ này lại lởm chởm đến vậy. Và một phần liên quan đến cách các phòng thí nghiệm huấn luyện các mô hình, nhưng tôi nghĩ một phần cũng liên quan đến sự tập trung của các phòng thí nghiệm và những gì họ đưa vào phân phối dữ liệu. Bởi vì một số thứ có giá trị hơn đáng kể trong nền kinh tế và cuối cùng tạo ra nhiều môi trường hơn vì các phòng thí nghiệm muốn làm việc trong những bối cảnh đó. Code là một ví dụ tốt về điều đó. Có lẽ còn rất nhiều môi trường có thể kiểm chứng khác mà họ có thể nghĩ đến nhưng chưa được đưa vào vì chúng không hữu ích lắm để phát triển năng lực xung quanh.

Nhưng tôi nghĩ bí ẩn lớn đối với tôi là — ví dụ yêu thích một thời là: "strawberry" có bao nhiêu chữ cái? Và các mô hình đã nổi tiếng trả lời sai điều này. Đó là một ví dụ về tính lởm chởm. Các mô hình bây giờ đã vá lỗi đó. Nhưng câu mới là: Tôi muốn đến tiệm rửa xe cách đây 50 mét — tôi nên lái xe hay đi bộ? Và các mô hình hàng đầu ngày nay sẽ nói với bạn là đi bộ vì nó quá gần. Làm sao có thể như vậy khi Opus 4.7 hàng đầu có thể đồng thời tái cấu trúc một codebase 100.000 dòng hoặc tìm các lỗ hổng zero-day, mà lại nói với tôi là đi bộ đến tiệm rửa xe? Điều này thật điên rồ.

(tiếng cười)

Và trong phạm vi mà các mô hình này vẫn còn lởm chởm, đó là chỉ dấu rằng thứ nhất, có thể có gì đó hơi sai, hoặc thứ hai, bạn cần thực sự tham gia vào một chút — bạn cần đối xử với chúng như công cụ và theo dõi những gì chúng đang làm. Vậy nên toàn bộ bài viết của tôi về tính kiểm chứng, tóm lại, chỉ đơn giản là cố gắng hiểu tại sao những thứ này lại lởm chởm. Có mô hình nào không? Và tôi nghĩ đó là sự kết hợp nào đó của "có thể kiểm chứng" cộng với "phòng thí nghiệm quan tâm."

Thêm một giai thoại nữa mang tính chỉ dẫn: từ GPT-3.5 đến GPT-4, mọi người nhận thấy cờ vua cải thiện rất nhiều. Nhiều người nghĩ đó chỉ là sự tiến bộ năng lực bình thường thôi. Nhưng thực ra, tôi nghĩ — đây là thông tin công khai, tôi thấy trên internet — một lượng dữ liệu cờ vua rất lớn đã được đưa vào tập huấn luyện trước. Và chỉ vì nó nằm trong phân phối dữ liệu, mô hình đã cải thiện nhiều hơn nhiều so với mặc định. Vậy nên ai đó tại OpenAI đã quyết định thêm dữ liệu này, và bây giờ bạn có một năng lực đã đạt đỉnh nhiều hơn. Và đó là lý do tôi nhấn mạnh khía cạnh này: chúng ta đang hơi bị chi phối bởi bất cứ điều gì các phòng thí nghiệm đang làm, bất cứ điều gì họ đưa vào. Và bạn phải khám phá thứ họ cho bạn mà không có hướng dẫn sử dụng. Nó hoạt động trong một số bối cảnh, nhưng có thể không trong những bối cảnh khác. Nếu bạn ở trong các mạch đã là một phần của học tăng cường, bạn bay. Nếu bạn ở trong các mạch nằm ngoài phân phối dữ liệu, bạn sẽ vật lộn. Và nếu bạn không ở trong những mạch đó, thì bạn thực sự phải xem xét tinh chỉnh và làm một số công việc của riêng mình, vì LLM không nhất thiết sẽ cho bạn điều đó ngay từ đầu.

Lời Khuyên Cho Nhà Sáng Lập Và Tự Động Hóa

STEPHANIE: Tôi muốn nói đến khái niệm trí tuệ lởm chởm một chút nữa. Nếu bạn là một nhà sáng lập ngày nay đang nghĩ đến việc xây dựng một công ty — bạn đang cố gắng giải quyết một vấn đề mà bạn nghĩ là có thể thực hiện được, điều gì đó trong một lĩnh vực có thể kiểm chứng — nhưng bạn nhìn xung quanh và nghĩ, "Ôi trời ơi, các phòng thí nghiệm đã thực sự bắt đầu đạt vận tốc thoát trong những lĩnh vực rõ ràng nhất: toán học, code, và những thứ khác." Lời khuyên của ông cho các nhà sáng lập trong khán giả là gì?

ANDREJ: Vậy nên tôi nghĩ điều đó có thể quay lại câu hỏi trước. Tính kiểm chứng làm cho một thứ gì đó có thể thực hiện trong mô thức hiện tại vì bạn có thể ném một lượng học tăng cường khổng lồ vào nó. Vậy nên có thể một cách để nhìn nhận là điều này vẫn đúng ngay cả khi các phòng thí nghiệm không tập trung trực tiếp vào nó. Nếu bạn ở trong một môi trường có thể kiểm chứng nơi bạn có thể tạo ra những môi trường RL hay ví dụ, điều đó thực sự thiết lập cho bạn để tiềm năng thực hiện tinh chỉnh của riêng mình, và bạn có thể hưởng lợi từ điều đó. Nhưng đó là công nghệ về cơ bản chỉ hoạt động — bạn có thể kéo một đòn bẩy nếu bạn có một lượng lớn các bộ dữ liệu đa dạng và môi trường RL. Tôi không muốn nói quá rõ câu trả lời, nhưng có một số ví dụ về điều này mà tôi nghĩ rất có giá trị.

STEPHANIE: Mặt khác, điều gì ông nghĩ vẫn chỉ có vẻ có thể tự động hóa từ xa?

ANDREJ: Tôi nghĩ cuối cùng hầu hết mọi thứ đều có thể được làm cho kiểm chứng được ở một mức độ nào đó — một số thứ dễ hơn những thứ khác. Bởi vì ngay cả với những thứ như viết lách, bạn có thể tưởng tượng có một hội đồng các thẩm phán LLM và có thể nhận được điều gì đó hợp lý từ cách tiếp cận đó. Vậy nên vấn đề là cái gì dễ hay khó. Cuối cùng tôi nghĩ...

Tất cả mọi thứ.

(tiếng cười)

Tất cả mọi thứ đều có thể tự động hóa.

Từ Vibe Coding Đến Kỹ Thuật Tác Nhân

STEPHANIE: Tuyệt vời. Vậy thì năm ngoái ông đã đặt ra thuật ngữ "vibe coding", và hôm nay chúng ta đang ở trong một thế giới có vẻ nghiêm túc hơn một chút — kỹ thuật tác nhân. Ông nghĩ sự khác biệt giữa hai điều là gì, và ông thực sự sẽ gọi những gì chúng ta đang ở hôm nay là gì?

ANDREJ: Vâng. Vậy nên tôi sẽ nói rằng vibe coding là về việc nâng cao nền tảng cho tất cả mọi người về những gì họ có thể làm trong phần mềm. Nền tảng nâng lên, mọi người đều có thể vibe-code bất cứ thứ gì — và điều đó thật tuyệt vời, đáng kinh ngạc. Nhưng sau đó tôi sẽ nói rằng kỹ thuật tác nhân là về việc bảo tồn thanh chất lượng của những gì đã tồn tại trước đây trong phần mềm chuyên nghiệp. Bạn không được phép đưa ra các lỗ hổng do vibe coding. Bạn vẫn chịu trách nhiệm về phần mềm của mình, giống như trước — nhưng bạn có thể đi nhanh hơn không? Và câu trả lời là: bạn có thể. Nhưng làm thế nào để làm điều đó đúng cách? Vậy nên với tôi, kỹ thuật tác nhân — tôi gọi nó như vậy vì tôi nghĩ nó là một loại ngành kỹ thuật. Bạn có những tác nhân này, là những thực thể lởm chởm. Chúng hơi không đáng tin cậy, hơi ngẫu nhiên, nhưng chúng cực kỳ mạnh mẽ. Câu hỏi là: làm thế nào để bạn phối hợp chúng để đi nhanh hơn mà không hy sinh thanh chất lượng? Và làm điều đó tốt và đúng đắn là lĩnh vực của kỹ thuật tác nhân. Vậy nên tôi coi chúng là khác nhau — một cái là về nâng cao nền tảng, và cái kia là về ngoại suy lên cao. Và những gì tôi thấy là có một trần rất cao về năng lực kỹ thuật tác nhân. Người ta từng nói về kỹ sư 10x. Tôi nghĩ điều này được khuếch đại nhiều hơn — 10x không phải là tốc độ tăng bạn đạt được. Dường như với tôi rằng những người giỏi điều này đạt đỉnh nhiều hơn 10x.

STEPHANIE: Tôi thực sự thích cách đóng khung đó. Khi Sam Altman đến AI Ascent năm ngoái, một điều đáng nhớ ông ấy nói là người ở các thế hệ khác nhau sử dụng ChatGPT khác nhau. Vậy nếu bạn ở tuổi 30, bạn dùng nó như thứ thay thế tìm kiếm Google. Nhưng nếu bạn ở tuổi thiếu niên, ChatGPT là cửa ngõ của bạn vào internet. Điều song song ở đây trong lập trình hôm nay là gì? Nếu chúng ta quan sát hai người code bằng Claude Code hoặc Codex — một người bạn coi là tầm thường với nó, và một người bạn coi là hoàn toàn AI-native — bạn sẽ mô tả sự khác biệt như thế nào?

ANDREJ: Ý tôi là, tôi nghĩ đó chỉ là cố gắng tận dụng tối đa các công cụ có sẵn, sử dụng tất cả các tính năng của chúng, đầu tư vào cài đặt của bạn. Giống như trước đây, các kỹ sư đã quen với việc tận dụng tối đa các công cụ họ sử dụng — dù là Vim hay VS Code, hay bây giờ là Claude Code hay Codex. Vậy nên chỉ là đầu tư vào cài đặt của bạn và sử dụng nhiều công cụ có sẵn.

Tôi nghĩ một suy nghĩ liên quan là nhiều người có thể đang tuyển dụng cho điều này ngay bây giờ, vì họ muốn tuyển dụng các kỹ sư tác nhân mạnh. Những gì tôi thấy là hầu hết mọi người vẫn chưa tái cấu trúc quy trình tuyển dụng của họ cho năng lực kỹ thuật tác nhân. Nếu bạn đang đưa ra các câu đố để giải, đây vẫn là mô thức cũ. Tôi sẽ nói rằng tuyển dụng cho điều này phải trông như: cho tôi một dự án thực sự lớn và xem ai đó triển khai nó. Chẳng hạn, viết một Twitter clone — cho tác nhân — và sau đó làm cho nó thực sự tốt, thực sự an toàn. Rồi có một số tác nhân mô phỏng hoạt động trên Twitter clone này. Và rồi tôi sẽ dùng 10 Codex agents để cố phá vỡ trang web bạn đã triển khai. Họ sẽ cố phá vỡ nó, và họ không nên có thể làm được. Có lẽ nó trông như vậy, đúng không? Quan sát mọi người trong bối cảnh đó, xây dựng các dự án lớn hơn, sử dụng công cụ — đó có thể là những gì tôi sẽ xem xét.

STEPHANIE: Và khi các tác nhân làm nhiều hơn, kỹ năng con người nào bạn nghĩ trở nên có giá trị hơn, không phải ít hơn?

ANDREJ: Vâng, đó là câu hỏi hay. Ngay bây giờ, câu trả lời là các tác nhân giống như những thực thể thực tập sinh. Đáng chú ý — bạn về cơ bản vẫn phải chịu trách nhiệm về thẩm mỹ, phán đoán, thị hiếu, và một chút giám sát. Có lẽ một trong những ví dụ yêu thích của tôi về sự kỳ lạ của tác nhân là với MenuGen: bạn đăng ký bằng tài khoản Google, nhưng bạn mua credits bằng tài khoản Stripe. Cả hai đều có địa chỉ email. Và tác nhân của tôi thực sự đã cố — khi bạn mua credits, nó gán chúng bằng cách dùng địa chỉ email từ Stripe để khớp với tài khoản Google. Như là, không có user ID cố định mà nó cố gắng khớp; nó đang cố gắng khớp địa chỉ email. Nhưng bạn có thể dùng địa chỉ email khác cho Stripe và Google của mình, và về cơ bản nó sẽ không liên kết được các khoản tiền. Và đây là loại điều tác nhân vẫn còn mắc lỗi — tại sao bạn lại dùng địa chỉ email để cố gắng tương quan chéo các khoản tiền? Chúng có thể là tùy ý. Bạn có thể dùng email khác nhau. Đây là điều thực sự kỳ lạ cần làm.

Vậy nên tôi nghĩ mọi người phải chịu trách nhiệm về đặc tả, kế hoạch. Và tôi thực sự không thích "plan mode" — ý tôi là, rõ ràng nó rất hữu ích, nhưng tôi nghĩ có điều gì đó tổng quát hơn ở đây nơi bạn phải làm việc với tác nhân của mình để thiết kế một đặc tả rất chi tiết. Có thể đó về cơ bản là các tài liệu — để tác nhân viết chúng, và bạn chịu trách nhiệm về việc giám sát và các danh mục cấp cao nhất, nhưng các tác nhân đang làm nhiều công việc bên dưới. Và vì vậy bạn không quan tâm đến một số chi tiết. Ví dụ, với arrays hay tensors trong mạng thần kinh — có rất nhiều chi tiết giữa PyTorch và NumPy và tất cả các chi tiết API nhỏ khác nhau, như với pandas và vân vân. Và tôi đã quên những thứ như "keepdims" hay "keep_dim", hay đó là "dim" hay "axis", hay "reshape" hay "permute" hay "transpose" — tôi không nhớ những thứ này nữa, vì bạn không cần. Đây là loại chi tiết được xử lý bởi thực tập sinh, vì chúng có khả năng nhớ rất tốt. Nhưng bạn vẫn phải biết, ví dụ, rằng có một tensor bên dưới, có một view bên dưới, và bạn có thể thao tác view của cùng một storage hay bạn có thể có storage khác nhau — điều đó kém hiệu quả hơn — và vì vậy bạn vẫn phải hiểu những gì thứ này đang làm ở mức cơ bản, để bạn không sao chép bộ nhớ xung quanh một cách không cần thiết. Nhưng các chi tiết của API bây giờ được chuyển giao. Vậy nên bạn đang chịu trách nhiệm về thị hiếu, kỹ thuật, thiết kế — đảm bảo nó có ý nghĩa, yêu cầu đúng thứ, nói "những thứ này phải là ID người dùng độc đáo mà chúng ta sẽ gắn mọi thứ vào đó." Bạn đang làm thiết kế và định hướng, và các tác nhân đang điền vào chỗ trống. Đó là nơi chúng ta đang ở hiện tại.

STEPHANIE: Bạn có nghĩ có khả năng rằng thị hiếu và phán đoán này sẽ quan trọng ít đi theo thời gian không, hay trần sẽ cứ tiếp tục nâng lên?

ANDREJ: Vâng, đó là câu hỏi hay. Ý tôi là, tôi hy vọng nó cải thiện. Tôi nghĩ có lẽ lý do nó không cải thiện ngay bây giờ là, một lần nữa, nó không phải là một phần của học tăng cường. Có lẽ không có chi phí hay phần thưởng thẩm mỹ, hay nó không đủ tốt, hay điều gì đó như vậy. Và tôi nghĩ khi bạn thực sự nhìn vào code, đôi khi tôi có một cơn hoảng loạn nhỏ vì nó không phải là code siêu tuyệt vời nhất thiết luôn luôn — nó rất cồng kềnh, có rất nhiều copy-paste, có những abstractions lạ kỳ giòn. Nó hoạt động, nhưng nó thực sự xấu. Và tôi hy vọng điều này có thể cải thiện trong các mô hình tương lai.

Một ví dụ hay cũng là dự án microGPT, nơi tôi đang cố gắng đơn giản hóa việc huấn luyện LLM để đơn giản nhất có thể. Các mô hình ghét điều này. Chúng không thể làm được. Tôi cứ cố gắng nhắc nhở LLM "đơn giản hóa thêm, đơn giản hóa thêm", và nó chỉ không thể. Bạn cảm thấy như mình đang ở ngoài các mạch học tăng cường. Nó cảm thấy như nhổ răng — không phải tốc độ ánh sáng. Vậy nên tôi nghĩ mọi người vẫn còn chịu trách nhiệm về điều này. Nhưng tôi nghĩ không có gì cơ bản ngăn nó cải thiện. Các phòng thí nghiệm chỉ chưa làm điều đó.

STEPHANIE: Vâng. Vậy nên tôi muốn quay lại ý tưởng về các hình thức trí tuệ lởm chởm này. Ông đã viết một chút về điều này trong một bài khá gây tranh luận về động vật so với ma — ý tưởng rằng chúng ta không xây dựng động vật, chúng ta đang triệu hồi ma. Đây là những hình thức trí tuệ lởm chởm được định hình bởi dữ liệu và hàm phần thưởng, nhưng không bởi động lực nội tại, niềm vui, sự tò mò, hay sự trao quyền — những thứ xuất hiện qua tiến hóa. Tại sao cách đóng khung đó quan trọng, và nó thực sự thay đổi cách bạn xây dựng, triển khai, đánh giá, hay thậm chí tin tưởng chúng như thế nào?

ANDREJ: Vâng. Vậy nên tôi nghĩ lý do tôi viết về điều này là tôi đang cố gắng hiểu những thứ này là gì. Bởi vì nếu bạn có một mô hình tốt về những gì chúng là — hay không phải là — thì bạn sẽ có năng lực hơn trong việc sử dụng chúng. Và tôi không chắc liệu nó có thực sự có sức mạnh thực tiễn không.

(tiếng cười)

Tôi nghĩ đó là một chút triết học. Nhưng tôi nghĩ đó chỉ là chấp nhận thực tế rằng những thứ này không phải là trí tuệ động vật. Như là, nếu bạn quát tháo chúng, chúng không hoạt động tốt hơn hay tệ hơn — không có tác động gì. Và tất cả chỉ là loại các mạch mô phỏng thống kê nơi chất nền là huấn luyện trước — vậy nên thống kê — và rồi học tăng cường được gắn vào trên đó, thứ tăng cường các phần phụ. Và có lẽ đó chỉ là tư duy — về những gì tôi đang tiếp cận, hay những gì có khả năng hoạt động hay không hoạt động, hay cách để sửa đổi nó. Nhưng tôi thực sự không có "đây là năm kết quả rõ ràng về cách làm cho hệ thống của bạn tốt hơn." Đó chỉ là trạng thái nghi ngờ, và khám phá dần dần theo thời gian.

Tác Nhân Khắp Nơi Và Việc Học Hỏi

STEPHANIE: Đó là điểm khởi đầu. Được rồi, vậy nên ông đang rất sâu trong làm việc với các tác nhân không chỉ trò chuyện — chúng có quyền thực sự, chúng có ngữ cảnh cục bộ, chúng thực sự thực hiện hành động thay mặt bạn. Thế giới sẽ như thế nào khi tất cả chúng ta bắt đầu sống trong thế giới đó?

ANDREJ: Vâng. Tôi nghĩ nhiều người ở đây phấn khích về môi trường native tác nhân này trông như thế nào — và mọi thứ phải được viết lại. Mọi thứ vẫn về cơ bản được viết cho con người và phải được làm lại. Tôi vẫn dùng, hầu hết thời gian, khi tôi dùng các framework hay thư viện hay những thứ như vậy, các tài liệu về cơ bản được viết cho con người. Đây là điều tôi phàn nàn yêu thích nhất. Tại sao mọi người vẫn còn nói với tôi phải làm gì? Như là, tôi không muốn làm bất cứ điều gì. Đoạn văn bản nào để copy-paste cho tác nhân của tôi?

(tiếng cười)

Vậy nên, mỗi khi tôi được nói "hãy đến URL này" hay điều gì đó như vậy, nó chỉ là — ugh.

(tiếng cười)

Vậy nên mọi người đang phấn khích về cách chúng ta phân tách khối lượng công việc cần xảy ra thành về cơ bản các cảm biến trên thế giới, các cơ cấu trên thế giới. Làm thế nào để chúng ta làm cho nó native tác nhân? Về cơ bản mô tả mọi thứ cho tác nhân trước, và rồi có nhiều tự động hóa xung quanh các cấu trúc dữ liệu rất dễ đọc với LLMs. Vậy nên tôi hy vọng có nhiều cơ sở hạ tầng agent-first ở ngoài kia. Và cho MenuGen — nổi tiếng, khi tôi viết bài blog về MenuGen — rất nhiều rắc rối không phải là viết code cho MenuGen. Đó là triển khai nó trên Vercel, vì tôi phải làm việc với tất cả các dịch vụ khác nhau này, kết nối chúng, đi đến cài đặt và menu của chúng, cấu hình DNS của tôi — và nó thật phiền phức. Đó là ví dụ tốt về điều gì đó tôi hy vọng có thể thay đổi: tôi đưa một prompt cho LLM, "xây dựng MenuGen," và rồi không cần chạm vào bất cứ thứ gì, và nó được triển khai trên internet. Tôi nghĩ đó sẽ là thử nghiệm tốt về việc liệu cơ sở hạ tầng của chúng ta có ngày càng trở nên native tác nhân hơn không.

Và rồi cuối cùng, tôi nghĩ chúng ta đang hướng tới một thế giới nơi có đại diện tác nhân cho mọi người và tổ chức — tác nhân của tôi sẽ nói chuyện với tác nhân của bạn để tìm ra một số chi tiết cuộc họp của chúng ta hay những thứ như vậy.

(tiếng cười)

Tôi nghĩ đó là đại khái hướng mọi thứ đang đi. Nhưng vâng, tôi nghĩ mọi người ở đây đều hứng khởi về điều đó.

STEPHANIE: Tôi thực sự thích hình ảnh ẩn dụ về cảm biến và cơ cấu. Tôi thực sự chưa nghĩ đến điều đó trước đây.

ANDREJ: Đúng không?

STEPHANIE: Được rồi, tôi nghĩ chúng ta phải kết thúc với một câu hỏi về giáo dục. Bởi vì ông có lẽ là một trong những người giỏi nhất thế giới trong việc làm cho các khái niệm kỹ thuật phức tạp trở nên đơn giản, và ông đang suy nghĩ sâu sắc về cách chúng ta thiết kế giáo dục xung quanh nó. Điều gì vẫn còn đáng học sâu khi trí tuệ trở nên rẻ, khi chúng ta bước vào kỷ nguyên tiếp theo của AI?

ANDREJ: Vâng. Có một tweet đã thổi bay tâm trí tôi gần đây, và tôi cứ nghĩ về nó mỗi ngày. Nó đại khái là: "Bạn có thể thuê ngoài việc suy nghĩ của mình, nhưng bạn không thể thuê ngoài việc hiểu của mình." Và tôi nghĩ điều đó được nói rất hay. Bởi vì tôi vẫn là một phần của hệ thống, và thông tin vẫn phải đi vào não của tôi. Và tôi cảm thấy như mình đang trở thành một nút cổ chai — chỉ về mặt biết những gì chúng ta đang cố gắng xây dựng, tại sao nó đáng làm, làm thế nào để định hướng các tác nhân của mình, và vân vân. Vậy nên tôi vẫn nghĩ rằng có điều gì đó phải định hướng việc suy nghĩ và xử lý, và điều đó vẫn bị ràng buộc về cơ bản bởi sự hiểu biết. Và đây là một lý do tôi cũng rất hứng thú về LLM knowledge bases — vì tôi cảm thấy đó là cách để tôi xử lý thông tin. Và bất cứ khi nào tôi thấy một góc chiếu khác lên thông tin, tôi luôn cảm thấy như mình có được cái nhìn sâu sắc hơn. Đó thực sự chỉ là nhiều prompts để tôi tạo ra dữ liệu tổng hợp trên một số dữ liệu cố định. Tôi thực sự thích nó — bất cứ khi nào tôi đọc một bài báo, tôi có wiki của mình được xây dựng từ những bài báo này, và tôi thích hỏi câu hỏi về mọi thứ. Và tôi nghĩ cuối cùng đây là những công cụ để tăng cường sự hiểu biết. Và điều này vẫn là một loại nút cổ chai, vì bạn không thể là một đạo diễn tốt nếu các LLM chắc chắn không xuất sắc trong việc hiểu — bạn vẫn là người độc đáo chịu trách nhiệm về điều đó. Vậy nên vâng, tôi nghĩ các công cụ theo hướng đó đang cực kỳ thú vị và hứng khởi.

STEPHANIE: Tôi phấn khích được quay lại đây trong vài năm tới và xem liệu chúng ta có bị tự động hóa hoàn toàn ra khỏi vòng lặp hay không và các tác nhân thực sự đảm nhận cả sự hiểu biết. Cảm ơn ông rất nhiều khi tham gia cùng chúng tôi, Andrej. Chúng tôi thực sự trân trọng điều đó.

(tiếng vỗ tay)

Nguồn bản ghi chép: AI Ascent 2026, do Sequoia Capital tổ chức. Đã được chỉnh sửa để dễ đọc từ bản ghi âm giọng nói gốc.

Labels: , ,

Andrej Karpathy: From Vibe Coding to Agentic Engineering

Karpathy explains why he's never felt more behind as a programmer, why agentic engineering is a more serious discipline than vibe coding, and why we should think of LLMs not as animals but as ghosts.

From AI Ascent 2026, hosted by Sequoia Capital.
Guest: Andrej Karpathy — co-founder of OpenAI, former Head of A.I. at Tesla, founder of Eureka Labs.
Interviewer: Stephanie Zhan, Partner at Sequoia Capital.
Published: 2026

Table of Contents

Introduction

STEPHANIE ZHAN: We are so excited for our very first special guest. He has helped build modern A.I., then explain modern A.I., and then occasionally rename modern A.I. He actually helped co-found OpenAI, right inside of this office. He was the one who got Autopilot working at Tesla back in the day, and he has a rare gift of making the most complex technical shifts feel both accessible and inevitable.

You all know him for having coined the term "vibe coding" last year, but just in the last few months he said something even more startling: that he's never felt more behind as a programmer. That's where we're starting today. Thank you, Andrej, for joining us.

I. Feeling Behind as a Coder

ANDREJ KARPATHY: Yeah. Hello. Excited to be here and to kick us off.

STEPHANIE: Okay. So just a couple of months ago, you said that you've never felt more behind as a programmer. That's startling to hear from you of all people. Can you help us unpack that? Was that feeling exhilarating or unsettling?

ANDREJ: Yeah, a mixture of both for sure. Well, first of all, I guess, like many of you, I've been using agentic tools — things like Claude Code, adjacent tools — for a while, maybe over the last year as they came out. And they were very good at, you know, chunks of code. Sometimes they would mess up and you'd have to edit them, and it was kind of helpful. Then I would say December was this clear inflection point. I was on a break, so I had a bit more time. I think many other people experienced something similar. I started to notice that with the latest models, the chunks just came out fine. And then I kept asking for more and it just came out fine. And then I couldn't remember the last time I'd corrected it. And then I just trusted the system more and more, and then I was vibe coding.

[laughter]

ANDREJ: And so it was kind of a — I do think it was a very stark transition. I think a lot of people... I tried to stress this on Twitter, or X, because I think a lot of people experienced A.I. last year as a ChatGPT-adjacent thing. But you really had to look again, as of December, because things changed fundamentally — especially on this agentic, coherent workflow, which really started to actually work. And so yeah, it was just that realization that had me go down this whole rabbit hole of just, you know, infinity side projects. My side projects folder is extremely full with lots of random things, and I'm just vibe coding all the time. So yeah, that kind of happened in December, I would say, and I've been looking at the repercussions of that ever since.

II. Software 3.0 Explained

STEPHANIE: You've talked a lot about this idea of LLMs as a new computer — that it isn't just better software, it's a whole new computing paradigm. Software 1.0 was explicit rules, software 2.0 was learned weights, software 3.0 is this. If that's actually true, what does a team build differently the day they actually believe this?

ANDREJ: Right. So, yeah, exactly. Software 1.0, I'm writing code. Software 2.0, I'm actually programming by creating data sets and training neural networks — so the programming is kind of like arranging data sets and maybe some objectives and neural network architectures. And then what happened is that basically, if you train one of these GPT models or LLMs on a sufficiently large set of tasks — implicitly, because by training on the internet you have to multitask all the things that are in the data set — these actually become kind of like a programmable computer in a certain sense. So software 3.0 is kind of about, you know, your programming now turns to prompting, and what's in the context window is your lever over the interpreter that is the LLM, which is kind of interpreting your context and performing computation in the digital information space. So I guess, yeah, that's kind of the transition. And I think there are a few examples that really drove it home for me.

III. Agents as the Installer

ANDREJ: For example, when Claude Code came out — when you want to install it, you would expect that normally this would be a bash script, a shell script. So you'd run the shell script to install Claude Code. But the thing is, in order to target lots of different platforms and lots of different types of computers, these shell scripts usually balloon up and become extremely complex. But you're still stuck in a software 1.0 universe of wanting to write the code. And actually, the Claude Code installation is a copy-paste of a bunch of text that you're supposed to give to your agent. So basically it's a little skill — you copy-paste this and give it to your agent, and it will install Claude Code. And the reason this is a lot more powerful is that you're now working in the software 3.0 paradigm, where you don't have to precisely spell out all the individual details of that setup. The agent has its own intelligence, it packages it up, it follows the instructions, looks at your environment and your computer, performs intelligent actions to make things work, debugs things in the loop — and it's just so much more powerful. So I think that's a very different kind of way of thinking about it: what is the piece of text to copy-paste to your agent? That's the programming paradigm now.

ANDREJ: One more example that comes to mind, that is even more extreme, is when I was building MenuGen. So MenuGen is this idea where you come to a restaurant, they give you a menu, there are no pictures usually. So I don't know what a lot of these things are — usually around thirty percent of items I have no idea what they are, sometimes fifty percent. So I wanted to take a photo of the restaurant menu and get pictures of what those dishes might look like in a generic sense. And so I built — I vibe-coded this app — that basically lets you upload a photo and does all this stuff. It runs on Vercel, rerenders the menu, gives you all the items, and uses an image generator to basically OCR all the different titles, get pictures of them, and show it to you. And then I saw the software 3.0 version of this, which blew my mind. It's literally just: take your photo, give it to Gemini, and say, "Use Nana Banana to overlay the dishes onto the menu." And Nana Banana returned an image that is exactly the picture of the menu that I took, but it actually put into the pixels rendered images of the different dishes in the menu. And this blew my mind, because all of my MenuGen is spurious. It's working in the old paradigm — that app shouldn't exist. And the software 3.0 paradigm is a lot more raw: your neural network is doing more and more of the work, your prompt or context is just the image, the output is an image, and there's no need to have any of the app in between.

ANDREJ: So I think people have to kind of reframe things — not to work in the existing paradigm of what things existed and just think of it as a speed-up of what already exists. It's actually that new things are available now. And going back to your programming question — that's also an example of working in the old mindset, because it's not just about programming becoming faster. This is more general information processing that is now automatable. So it's not even just about code. Previous code worked over structured data, right? But for example, with my LLM knowledge bases project — basically, you get LLMs to create wikis for your organization or for yourself personally — this is not even a program. This is not something that could have existed before, because there was no code that would create a knowledge base from a bunch of facts. But now you can just take these documents and basically recompile them in a different way, reorder them, and create something that is new and interesting as a reframing of the data. And so these are new things that weren't possible. I keep trying to get back to that question: not only what can we do that already existed but faster, but what are the new opportunities — things that couldn't be possible before? And I almost think that's even more exciting.

V. What's Obvious by 2026

STEPHANIE: I love the MenuGen progression and dichotomy that you laid out. I'm sure many folks here followed your own progression in programming from last October to early January and February of this year. If you extrapolate further — what is the 2026 equivalent of building websites in the '90s, building mobile apps in the 2010s, building SaaS in the last cloud era? What will look completely obvious in hindsight that is still mostly unbuilt today?

ANDREJ: Well, going with the example of MenuGen, a lot of this code shouldn't exist — it's just a neural network doing most of the work. I do think the extrapolation looks very weird because you could basically imagine... you could imagine completely neural computers in a certain sense. You feed raw video or audio into basically what's a neural net, and it uses diffusion to render a UI that is kind of unique for that moment. And I kind of feel like in the early days of computing, people were a little bit confused as to whether computers would look like calculators or whether computers would look like neural nets — in the '50s and '60s it was not really obvious which way it would go. And of course we went down the calculator path and ended up building classical computing. And then neural nets are currently running virtualized on existing computers. But you could imagine — I think — that a lot of this will flip, and that the neural net becomes kind of the host process and the CPUs become kind of the co-processor. So we saw the diagram of how intelligence compute for neural networks is going to take over and become the dominant spend of flops. You could imagine something really weird and foreign, where neural nets are doing most of the heavy lifting, using tool use as a kind of historical appendage for some deterministic tasks, but what's really running the show is these neural nets. You can imagine something extremely foreign as the extrapolation, but I think we're going to get there sort of piece by piece. And that progression is TBD, I would say.

[laughter]

VI. Verifiability and Jagged Skills

STEPHANIE: I'd like to talk a little bit about this concept of verifiability — the fact that A.I. will automate faster and more easily in domains where the output can be verified. If that framework is right, what work is about to move much faster than people realize? And what professions do people think are safe but are actually highly verifiable?

ANDREJ: Yes. So I spent some time writing about verifiability. Basically, traditional computers can easily automate what you can specify in code. And this latest round of LLMs can easily automate what you can verify — in a certain sense — because the way this works is that when frontier labs are training these LLMs, these are giant reinforcement learning environments. So they are given verification rewards, and because of the way these models are trained, they end up basically progressing and creating these jagged entities that really peak in capability in verifiable domains like math and code and adjacent areas — and kind of stagnate and are a little rough around the edges when things are not in that space.

So I think the reason I wrote about verifiability is that I'm trying to understand why these things are so jagged. And some of it has to do with how the labs train the models, but I think some of it also has to do with the focus of the labs and what they happen to put into the data distribution. Because some things are significantly more valuable in the economy and end up creating more environments because the labs wanted to work in those settings. Code is a good example of that. There are probably lots of verifiable environments they could think of that didn't make it into the mix because they're just not that useful to have capability around.

But I think the big mystery for me is — the favorite example for a while was: how many letters are in "strawberry"? And the models would famously get this wrong. That's an example of jaggedness. The models now patch that, I think. But the new one is: I want to go to a car wash to wash my car and it's 50 meters away — should I drive or should I walk? And state-of-the-art models today will tell you to walk because it's so close. How is it possible that state-of-the-art Opus 4.7 will simultaneously refactor a 100,000-line codebase or find zero-day vulnerabilities, and yet tells me to walk to this car wash? This is insane.

[laughter]

And to whatever extent these models remain jagged, it's an indication that, number one, maybe something is slightly off, or number two, you need to actually be in the loop a little bit — you need to treat them as tools and stay in touch with what they're doing. So all of my writing about verifiability, long story short, is just trying to understand why these things are jagged. Is there any pattern to it? And I think it's some kind of combination of "verifiable" plus "labs care."

The Chess Data Anecdote

Maybe one more anecdote that is instructive: from GPT-3.5 to GPT-4, people noticed that chess improved a lot. A lot of people thought, "Oh well, it's just a progression of capabilities." But actually, I think — this is public information, I saw it on the internet — a huge amount of chess data made it into the pre-training set. And just because it's in the data distribution, the model improved a lot more than it would by default. So someone at OpenAI decided to add this data, and now you have a capability that just peaked a lot more. And so that's why I'm stressing this dimension of it: we are slightly at the mercy of whatever the labs are doing, whatever they happen to put into the mix. And you have to explore this thing they give you that has no manual. It works in certain settings, but maybe not in others. And you have to kind of explore it a little bit. If you're in the circuits that were part of the reinforcement learning, you fly. If you're in the circuits that are out of the data distribution, you're going to struggle, and you have to figure out which circuits you're in for your application. And if you're not in those circuits, then you really have to look at fine-tuning and doing some of your own work, because it's not necessarily going to come out of the LLM out of the box.

VII. Founder Advice and Automation

STEPHANIE: I'd love to come back to the concept of jagged intelligence in a little bit. If you are a founder today thinking about building a company — you're trying to solve a problem that you think is tractable, something in a domain that is verifiable — but you look around and think, "Oh my gosh, the labs have really started getting to escape velocity in the ones that seem most obvious: math, coding, and others." What would your advice be to the founders in the audience?

ANDREJ: So I think maybe that comes back to the previous question. Verifiability makes something tractable in the current paradigm because you can throw a huge amount of reinforcement learning at it. So maybe one way to see it is that this remains true even if the labs are not focusing on it directly. If you are in a verifiable setting where you could create these RL environments or examples, that actually sets you up to potentially do your own fine-tuning, and you might benefit from that. But that is fundamentally technology that just works — you can pull a lever if you have a huge amount of diverse data sets and RL environments. You can use your favorite fine-tuning framework and pull the lever and get something that actually works pretty well. So I don't know exactly what the examples of this might be. But I do think there are some very valuable reinforcement learning environments that people could think of that are not part of the mix. Yeah, I don't want to give away the answer, but there is one domain that I think is very — oh, okay. Sorry, I don't mean to vague-post on stage, but there are some examples of this.

STEPHANIE: On the flip side, what do you think still feels automatable only from a distance?

ANDREJ: I do think that ultimately almost everything can be made verifiable to some extent — some things easier than others. Because even for things like writing, you can imagine having a council of LLM judges and probably get something reasonable out of that kind of approach. So it's more about what's easy or hard. I do think that ultimately...

Everything.

[laughter]

Everything is automatable.

VIII. From Vibe Coding to Agentic Engineering

STEPHANIE: Amazing. Okay. So last year you coined the term "vibe coding," and today we're in a world that feels a little bit more serious — more agentic engineering. What do you think is the difference between the two, and what would you actually call what we're in today?

ANDREJ: Yeah. So I would say vibe coding is about raising the floor for everyone in terms of what they can do in software. The floor rises, everyone can vibe-code anything — and that's amazing, incredible. But then I would say agentic engineering is about preserving the quality bar of what existed before in professional software. You're not allowed to introduce vulnerabilities due to vibe coding. You're still responsible for your software, just as before — but can you go faster? And the spoiler is: you can. But how do you do that properly? So to me, agentic engineering — I call it that because I do think it's kind of an engineering discipline. You have these agents, which are these spiky entities. They're a bit fallible, a little stochastic, but they are extremely powerful. The question is: how do you coordinate them to go faster without sacrificing your quality bar? And doing that well and correctly is the realm of agentic engineering. So I kind of see them as different — one is about raising the floor, and the other is about extrapolating upward. And what I'm seeing is that there is a very high ceiling on agentic engineering capability. People used to talk about the 10x engineer. I think this is magnified a lot more — 10x is not the speed-up you gain. It does seem to me like people who are very good at this peak a lot more than 10x, from my perspective right now.

What A.I.-Native Coding Actually Looks Like

STEPHANIE: I really like that framing. One thing — when Sam Altman came to AI Ascent last year, one memorable thing he said was that people of different generations use ChatGPT differently. So if you're in your 30s, you use it as a Google search replacement. But if you're in your teens, ChatGPT is your gateway to the internet. What is the parallel here in coding today? If we were to watch two people code using Claude Code or Codex — one you'd consider mediocre at it, and one you would consider fully A.I.-native — how would you describe the difference?

ANDREJ: [clears throat] I mean, I think it's just trying to get the most out of the tools that are available, utilizing all of their features, investing in your own setup. Just like previously, engineers were used to basically getting the most out of the tools they use — whether it's Vim or VS Code, or now it's Claude Code or Codex or so on. So just investing in your setup and utilizing a lot of the tools that are available to you. And I think it kind of looks like that.

I do think a related thought is that a lot of people are maybe hiring for this right now, because they want to hire strong agentic engineers. What I'm seeing is that most people have still not refactored their hiring process for agentic engineering capability. Like, if you're giving out puzzles to solve, this is still the old paradigm. I would say that hiring for this has to look like: give me a really big project and see someone implement it. Let's say, write a Twitter clone — for agents — and then make it really good, make it really secure. Then have some agents simulate some activity on this Twitter clone. And then I'm going to use 10 Codex agents to try to break the website that you deployed. They're going to try to basically break it, and they should not be able to break it. Maybe it looks like that, right? Watching people in that setting, building bigger projects, utilizing the tooling — that's maybe what I would look at, for the most part.

The Intern Problem — Taste, Judgment, and Oversight

STEPHANIE: And as agents do more, what human skill do you think becomes more valuable, not less?

ANDREJ: So, yeah, it's a good question. Right now, the answer is that the agents are kind of like these intern entities. It's remarkable — you basically still have to be in charge of the aesthetics, the judgment, the taste, and a little bit of oversight. Maybe one of my favorite examples of the weirdness of agents is with MenuGen: you sign up with a Google account, but you purchase credits using a Stripe account. Both of them have email addresses. And my agent actually tried to — when you purchase credits, it assigned them using the email address from Stripe to the Google account. Like, there wasn't a persistent user ID that it was trying to match up; it was trying to match up email addresses. But you could use a different email address for your Stripe and your Google, and it basically would not associate the funds. And so this is the kind of thing that agents still make mistakes about — like, why would you use email addresses to try to cross-correlate the funds? They can be arbitrary. You can use different emails. This is such a weird thing to do.

So I think people have to be in charge of the spec, the plan. And I actually don't even like "plan mode" — I mean, obviously it's very useful, but I think there's something more general here where you have to work with your agent to design a spec that is very detailed. Maybe it's basically the docs — get the agents to write them, and you're in charge of the oversight and the top-level categories, but the agents are doing a lot of the work under the hood. And so you're not caring about some of the details. As an example, with arrays or tensors in neural networks — there's a ton of details between PyTorch and NumPy and all the different little API details with pandas and so on. And I've already forgotten things like keepdims versus keep_dim, or whether it's dim or axis, or reshape or permute or transpose — I don't remember this stuff anymore, because you don't have to. This is the kind of detail that's handled by the intern, because they have very good recall. But you still have to know, for example, that there's an underlying tensor, there's an underlying view, and you can manipulate the view of the same storage or you can have different storage — which would be less efficient — and so you still have to understand what this stuff is doing at a fundamental level, so that you're not copying memory around unnecessarily. But the details of the APIs are now handed off. So you're in charge of the taste, the engineering, the design — making sure it makes sense, asking for the right things, saying "these have to be unique user IDs that we're going to tie everything to." You're doing the design and direction, and the agents are doing the fill-in-the-blanks. That's currently kind of where we are, and I think that's what everyone is seeing.

Animals vs. Ghosts — What Kind of Thing Is an LLM?

STEPHANIE: Do you think there's a chance that this taste and judgment matters less over time, or will the ceiling just keep rising?

ANDREJ: Yeah, it's a good question. I mean, I'm hoping that it improves. I think probably the reason it doesn't improve right now is, again, it's not part of the RL. There's probably no aesthetics cost or reward, or it's not good enough, or something like that. And I do think that when you actually look at the code, sometimes I get a little bit of a heart attack because it's not like super amazing code necessarily all the time — it's very bloated, there's a lot of copy-paste, there are awkward abstractions that are brittle. It works, but it's just really gross. And I do hope that this can improve in future models.

A good example also is this microGPT project, where I was trying to simplify LLM training to be as simple as possible. The models hate this. They can't do it. I kept trying to prompt an LLM to "simplify more, simplify more," and it just can't. You feel like you're outside of the RL circuits. It feels like you're pulling teeth — it's not light-speed. So I do think that people still remain in charge of this. But I do think that there's nothing fundamental preventing it from improving. It's just that the labs haven't done it yet, almost.

STEPHANIE: Yeah. So I'd love to come back to this idea of jagged forms of intelligence. You wrote a little bit about this in a very thought-provoking piece around animals versus ghosts — the idea that we're not building animals, we are summoning ghosts. These are jagged forms of intelligence shaped by data and reward functions, but not by intrinsic motivation, fun, curiosity, or empowerment — things that came about via evolution. Why does that framing matter, and what does it actually change about how you build, deploy, evaluate, or even trust them?

ANDREJ: Yeah. So I think the reason I wrote about this is that I'm trying to wrap my head around what these things are. Because if you have a good model of what they are — or are not — then you're going to be more competent at using them. And I do think that... I'm not sure if it actually has real practical power.

[laughter]

I think it's a little bit of philosophizing. But I do think it's just coming to terms with the fact that these things are not animal intelligences. Like, if you yell at them, they're not going to work better or worse — it doesn't have any impact. And it's all just kind of like statistical simulation circuits where the substrate is pre-training — so statistics — and then RL is bolted on top, which kind of increases the appendages. And maybe it's just a mindset — of what I'm coming into, or what's likely to work or not likely to work, or how to modify it. But I don't actually have "here are the five obvious outcomes of how to make your system better." It's more just being suspicious of it, and figuring things out over time.

IX. Agents Everywhere and Learning

STEPHANIE: That's where it starts. Okay, so you are so deep in working with agents that don't just chat — they have real permissions, they have local context, they actually take action on your behalf. What does the world look like when we all start to live in that world?

ANDREJ: Yeah. I think a lot of people here are excited about what this agent-native environment looks like — and everything has to be rewritten. Everything is still fundamentally written for humans and has to be reworked. I still use, most of the time, when I use different frameworks or libraries or things like that, docs that are fundamentally written for humans. This is my favorite pet peeve. Why are people still telling me what to do? Like, I don't want to do anything. What is the thing I should copy-paste to my agent?

[laughter]

So it's just — every time I'm told, you know, "go to this URL" or something like that, it's just like — ugh.

[laughter]

So everyone is excited about how do we decompose the workloads that need to happen into fundamentally sensors over the world, actuators over the world. How do we make it agent-native? Basically describe things to agents first, and then have a lot of automation around data structures that are very legible to LLMs. So I'm hoping that there's a lot of agent-first infrastructure out there. And for MenuGen — famously, when I wrote the blog post about MenuGen — a lot of the trouble was not even writing the code for MenuGen. It was deploying it on Vercel, because I had to work with all these different services, string them up, go to their settings and menus, configure my DNS — and it was just so annoying. That's a good example of something I would hope could change: I give a prompt to an LLM, "build MenuGen," and then don't have to touch anything, and it's deployed on the internet. I think that would be a good test of whether our infrastructure is becoming more and more agent-native.

And then ultimately, I do think we're going towards a world where there's agent representation for people and for organizations — I'll have my agent talk to your agent to figure out some of the details of our meetings or things like that.

[laughter]

I do think that's roughly where things are going. But yeah, I think everyone here is excited about that.

What Still Remains Worth Learning Deeply

STEPHANIE: I really like the visual analogy of sensors and actuators. I actually hadn't thought of that. That's super interesting.

ANDREJ: Right?

STEPHANIE: Okay, I think we have to end on a question about education. Because you are probably one of the very best in the world at making complex technical concepts simple, and you are deeply thoughtful about how we design education around it. What still remains worth learning deeply when intelligence gets cheap, as we move into the next era of A.I.?

ANDREJ: Yeah. There was a tweet that blew my mind recently, and I keep thinking about it every other day. It was something along the lines of: "You can outsource your thinking, but you can't outsource your understanding." And I think that's really nicely put. Because I'm still part of the system, and information still has to make it into my brain. And I feel like I'm becoming a bottleneck — just in terms of knowing what we're trying to build, why it's worth doing, how to direct my agents, and so on. So I do still think that something has to direct the thinking and the processing, and that's still kind of fundamentally constrained by understanding. And this is one reason I was also very excited about LLM knowledge bases — because I feel like that's a way for me to process information. And any time I see a different projection onto information, I always feel like I gain insight. It's really just a lot of prompts for me to do synthetic data generation over some fixed data. I really enjoy it — whenever I read an article, I have my wiki being built up from these articles, and I love asking questions about things. And I think that ultimately these are tools to enhance understanding. And this is still kind of a bottleneck, because you can't be a good director if the LLMs certainly don't excel at understanding — you are still uniquely in charge of that. So yeah, I think tools to that effect are incredibly interesting and exciting.

STEPHANIE: I'm excited to be back here in a couple of years and to see if we've been fully automated out of the loop and they actually take care of understanding as well. Thank you so much for joining us, Andrej. We really appreciate it.

[applause]

Transcript source: AI Ascent 2026, hosted by Sequoia Capital. Edited for readability from the original speech-to-text recording.

Labels: , ,

3.28.2026

Andrej Karpathy Thật Ra Đang Nói Gì — Hướng Dẫn Về Tương Lai AI Cho Người Bình Thường

 

Author: Claude AI, under the supervision, prompting and editing by HocTro

Andrej Karpathy là một trong những tiếng nói quan trọng nhất trong lĩnh vực trí tuệ nhân tạo. Ông là đồng sáng lập OpenAI, từng dẫn dắt nhóm AI xe tự lái tại Tesla, và hiện đang là nhà nghiên cứu độc lập. Trong một lần xuất hiện trên podcast No Priors gần đây, ông đã chia sẻ tầm nhìn của mình về hướng đi của AI — và đó là một tầm nhìn đầy kịch tính. Nhưng phần lớn những gì ông nói được gói trong thuật ngữ kỹ thuật và ngôn ngữ nội bộ. Bài viết này sẽ giải thích từng điểm chính, nói rõ ý nghĩa thực sự của chúng, và tại sao chúng quan trọng với những người không phải kỹ sư hay nhà nghiên cứu AI.

Mục Lục

Tóm Tắt

Cuộc trò chuyện của Andrej Karpathy trải dài qua nhiều chủ đề, và phần lớn nghe như chuyện khoa học viễn tưởng — nhưng không phải vậy. Đó là mô tả về những gì đang xảy ra ngay lúc này. Đây là phiên bản nói thẳng nói thật về những điểm chính của ông: Công cụ AI hỗ trợ lập trình đã thay đổi mạnh mẽ vào khoảng tháng 12 năm 2025, đến mức các kỹ sư giỏi nhất ngừng tự viết code và chuyển sang quản lý AI như quản lý nhân viên. Karpathy xây dựng một trợ lý AI cho ngôi nhà của mình — điều khiển đèn, nhạc, máy lạnh, hồ bơi, và camera an ninh — tất cả chỉ qua tin nhắn. Ông cho rằng phần lớn các app trên điện thoại rồi sẽ bị thay thế bởi một trợ lý AI duy nhất nói chuyện với mọi thiết bị thay bạn. Ông thiết lập một AI tự cải thiện các AI khác qua đêm trong khi ông ngủ, và nó tìm ra những tối ưu hóa mà ông bỏ sót sau hai mươi năm kinh nghiệm. Ông nghĩ AI sẽ thay đổi công việc văn phòng nhanh hơn nhiều so với công việc chân tay, vì di chuyển thông tin dễ hơn di chuyển vật thể vô cùng. Ông thận trọng lạc quan về việc làm — phần mềm rẻ hơn trong lịch sử đồng nghĩa với nhiều việc làm hơn, chứ không phải ít hơn. Ông tin giáo dục sẽ chuyển đổi từ giáo viên giảng bài cho học sinh sang giáo viên lập trình gia sư AI. Và ông rời các lab AI lớn vì muốn nói thẳng về những gì đang diễn ra mà không bị áp lực từ công ty. Thông điệp tổng thể: cuộc cách mạng AI không phải đang tới — nó đã ở đây rồi, đang diễn ra nhanh hơn hầu hết mọi người nhận ra, và những người có vị thế tốt nhất là những ai học cách làm việc cùng AI thay vì cạnh tranh với nó.

"AI Psychosis" Là Gì? — Khoảnh Khắc Mọi Thứ Thay Đổi

Karpathy nói ông đang ở trong trạng thái "AI psychosis kéo dài liên tục." Nghe có vẻ đáng lo, nhưng thực ra ý ông đơn giản hơn: ông bị ngợp bởi tốc độ thay đổi quá nhanh và lo lắng về việc theo kịp. Từ "psychosis" ở đây chỉ là cách nói cường điệu — ông không mất kết nối với thực tại, mà là không còn có thể vẽ bản đồ toàn bộ thực tại vì có quá nhiều lãnh thổ mới mở ra cùng lúc.

Chuyện gì xảy ra vào tháng 12 năm 2025: Trước tháng đó, Karpathy tự viết phần lớn code của mình — khoảng 80% bằng tay, AI chỉ hỗ trợ 20%. Rồi có gì đó thay đổi trong các model AI (nhiều khả năng là thế hệ mới của các coding agent từ Anthropic, OpenAI, và các công ty khác). Gần như chỉ qua một đêm, AI trở nên đủ giỏi để Karpathy lật ngược hoàn toàn: giờ ông gần như không tự viết một dòng code nào. Ông nói chuyện với các trợ lý AI, mô tả điều mình muốn, và chúng tự xây dựng.

Tại sao điều này quan trọng với bạn: Hãy hình dung như bước nhảy từ viết thư tay sang dùng email. Máy đánh chữ đầu tiên còn thô sơ — bạn vẫn phải tự gõ hầu hết mọi thứ, máy chỉ giúp định dạng. Rồi email xuất hiện và không ai còn viết thư tay nữa. Karpathy đang mô tả bước chuyển kiểu đó, nhưng áp dụng cho toàn bộ ngành phát triển phần mềm. Những người tạo ra app, website, hệ thống ngân hàng cho bạn — cách họ làm việc đã thay đổi hoàn toàn chỉ trong vài tuần. Phần lớn người ngoài ngành công nghệ chưa nhận ra điều này.

Yếu tố lo lắng: Karpathy theo dõi các lập trình viên khác trên mạng xã hội phát hiện ra kỹ thuật mới và cảm thấy thật sự bồn chồn vì sợ tụt hậu. Nếu một trong những chuyên gia AI hàng đầu thế giới còn cảm thấy vậy, điều đó nói lên rất nhiều về tốc độ thay đổi. Vùng lãnh thổ của những điều có thể làm được đang mở rộng nhanh hơn bất kỳ ai có thể khám phá.

II. Coding Agent Là Gì? — Tại Sao Lập Trình Viên Ngừng Gõ Phím

Để hiểu phần còn lại của cuộc trò chuyện, bạn cần hiểu "coding agent" là gì. Nó không phải tự động hoàn chỉnh câu. Không phải AI gợi ý từ tiếp theo khi bạn gõ. Một coding agent giống như có một nhân viên mới có thể làm theo hướng dẫn phức tạp hơn. Bạn mô tả tính năng muốn làm — ví dụ "thêm bảng biểu vào app vẽ này" — và agent tự đi làm trong hai mươi phút hay một tiếng, tự đọc code hiện có, tự hiểu cách chúng kết nối, viết hàng trăm dòng code mới, tự kiểm tra, tự sửa lỗi, rồi quay lại với kết quả hoạt động được.

Cách làm việc của Peter Steinberg: Karpathy mô tả một lập trình viên tên Peter Steinberg đã trở nên nổi tiếng trong cộng đồng lập trình AI. Steinberg ngồi trước màn hình với nhiều AI agent chạy đồng thời, mỗi agent đang làm một việc khác nhau. Anh ta giao cho agent một tính năng cần xây dựng, agent hai một tính năng khác, agent ba một việc nghiên cứu, agent bốn một việc lập kế hoạch. Mỗi việc mất khoảng hai mươi phút. Steinberg đi qua lại giữa chúng như người quản lý trong văn phòng, xem xét kết quả và giao việc mới. Anh ta không viết code — anh ta điều phối.

Nghĩa là gì nói theo cách bình thường: Công việc của kỹ sư phần mềm đang chuyển từ "người gõ lệnh bằng ngôn ngữ lập trình" sang "người quản lý các nhân viên AI." Kỹ năng không còn là gõ nhanh hay nhớ cú pháp. Kỹ năng là khả năng chia nhỏ vấn đề lớn thành từng phần, giải thích từng phần rõ ràng, và xem xét kết quả. Nó giống quản lý dự án hơn là đánh máy.

Kinh tế token: Karpathy đưa ra một khái niệm xuất hiện xuyên suốt cuộc trò chuyện: token. Trong AI, một "token" gần giống một từ hoặc một phần của từ. Khi bạn dùng AI, bạn đang tiêu token — gửi token vào (hướng dẫn của bạn) và nhận token về (câu trả lời của AI). Karpathy nói thước đo năng suất mới là "lưu lượng token" — bao nhiêu token bạn có thể huy động làm việc cho bạn mỗi giờ. Ông so sánh với thế giới nghiên cứu vật lý ngày xưa, nơi năng suất được đo bằng số GPU (chip đồ họa chuyên dụng) đang chạy thử nghiệm cho bạn. Nếu GPU rảnh, bạn đang lãng phí. Giờ thì nếu AI agent rảnh, bạn đang lãng phí.

Tại sao căng thẳng: Điều này tạo ra một kiểu lo lắng công việc mới. Nếu bạn có thể luôn luôn khởi động thêm một AI agent và giao thêm việc, thì mỗi khoảnh khắc không làm vậy là bạn đang bỏ phí công suất. Karpathy thẳng thắn nói ông cảm thấy bồn chồn khi có dung lượng đăng ký chưa dùng. Đó là nỗi lo của người lao động tri thức khi nhìn máy móc ngồi không trong nhà máy. Điểm khác là "máy móc" ở đây là model AI và "nhà máy" là cái laptop của bạn.

III. "Claw" Là Gì? — Dobby Và Cuộc Cách Mạng Nhà Thông Minh

Karpathy dùng từ "claw" (đôi khi là "claude," ám chỉ AI của Anthropic, đôi khi là thuật ngữ chung cho hệ thống agent tự động) để mô tả thứ gì đó bền bỉ hơn coding agent. Một claw là AI chạy liên tục trong nền, có bộ nhớ riêng, môi trường riêng, và làm việc thay bạn ngay cả khi bạn không theo dõi. Hãy nghĩ coding agent như người bạn thuê cho một việc cụ thể; còn claw thì giống trợ lý sống cùng nhà.

Câu chuyện về Dobby, từng bước một: Karpathy xây dựng một hệ thống AI mà ông đặt tên là "Dobby the Elf" (theo nhân vật trong Harry Potter). Đây là chuyện đã xảy ra:

Ông nói với AI: "Tôi nghĩ tôi có loa Sonos. Bạn có thể tìm không?" AI quét mạng nội bộ trong nhà — cùng mạng WiFi với điện thoại và máy tính của ông — và tìm thấy hệ thống Sonos. Nó phát hiện loa không có mật khẩu bảo vệ (điều thường thấy với thiết bị nhà thông minh trên mạng nội bộ). Sau đó nó tự tìm kiếm trên internet để tìm cách điều khiển loa qua giao diện lập trình của chúng. Chỉ qua ba lần nhắn tin, nhạc đã phát trong phòng làm việc của ông.

AI lặp lại điều này cho hệ thống đèn, máy lạnh và sưởi, rèm cửa, hồ bơi và bồn tắm nước nóng, và camera an ninh. Về bảo mật, nó thiết lập một hệ thống: camera theo dõi phía trước nhà, khi phát hiện chuyển động, video được gửi cho một AI riêng có khả năng hiểu hình ảnh. AI đó nhắn tin cho Karpathy qua WhatsApp: "Xe giao hàng FedEx vừa đỗ trước nhà."

Trước khi có Dobby: Karpathy dùng sáu app khác nhau để điều khiển các hệ thống này — một cho Sonos, một cho đèn, một cho điều hòa, v.v. Mỗi app có giao diện riêng, tài khoản riêng, cách dùng riêng. Sau khi có Dobby, ông dùng không app nào. Ông chỉ nhắn tin cho Dobby qua WhatsApp và nói những thứ như "sleepy time" (tắt hết đèn) hay "bật hồ bơi."

Tại sao điều này quan trọng với bạn: Hiện tại, thiết lập thứ gì đó như Dobby đòi hỏi kỹ năng kỹ thuật. Bạn cần biết về mạng, API, và cách ra lệnh cho AI. Nhưng điểm mấu chốt của Karpathy — và đây là điều quan trọng — là tình trạng này chỉ tạm thời. Trong một hoặc hai năm nữa, ông tin bất kỳ ai cũng có thể làm điều này mà không cần kiến thức kỹ thuật. AI sẽ xử lý toàn bộ sự phức tạp. Bạn chỉ cần nói muốn gì và nó sẽ xảy ra.

IV. Cái Chết Của App — Tại Sao Điện Thoại Bạn Có Thể Đơn Giản Hơn

Ví dụ về Dobby dẫn Karpathy đến một lập luận lớn hơn: hầu hết các app trên điện thoại bạn thật ra không nên tồn tại như những ứng dụng độc lập.

Lập luận nói thẳng: Hãy nghĩ về tất cả app bạn đang có. App ngân hàng. App theo dõi sức khỏe. App điều nhiệt nhà thông minh. App nhạc. App an ninh nhà. Mỗi cái được xây bởi một công ty khác nhau, với thiết kế riêng, giao diện riêng, cách hoạt động riêng. Bạn phải học từng cái riêng biệt. Phải liên tục chuyển qua lại giữa chúng. Và chúng không thể nói chuyện với nhau tốt lắm.

Tầm nhìn của Karpathy là tất cả những thứ này chỉ nên là các dịch vụ nền — thứ dân kỹ thuật gọi là "API" (Application Programming Interface), về cơ bản là các kết nối hậu trường cho phép máy tính nói chuyện với nhau. Trợ lý AI của bạn sẽ nói chuyện với tất cả chúng thay mặt bạn. Muốn kiểm tra số dư ngân hàng, điều chỉnh nhiệt độ, và mở nhạc? Cứ nói, AI sẽ gọi đúng dịch vụ cần thiết. Không app, không giao diện, không cần học.

Khách hàng giờ là ai? Đây là điểm khiêu khích nhất của Karpathy trong phần này: khách hàng không còn là con người nữa. Khách hàng là AI agent. Các công ty không nên thiết kế giao diện cho người dùng bấm — mà nên thiết kế API rõ ràng, được ghi chép tốt cho AI agent gọi. Con người chỉ cần nói chuyện với agent. Agent nói chuyện với mọi thứ còn lại.

Phản bác và câu trả lời của Karpathy: Có người lập luận điều này không thực tế vì người bình thường không học lập trình AI riêng cho mình. Karpathy đồng ý — hiện tại. Nhưng ông xem đây là trạng thái tạm thời. Thứ gì giờ đòi hỏi kỹ năng kỹ thuật sẽ trở nên cực kỳ dễ dàng trong một hoặc hai năm nữa, khi model AI cải thiện và công cụ trở nên phổ biến hơn. Phần mềm bạn cần sẽ trở thành "nhất thời" — được tạo ra ngay lập tức cho tình huống cụ thể của bạn, dùng xong rồi bỏ. Bạn sẽ không cài app nữa; bạn chỉ nêu ý định.

Ví dụ thực tế: Hãy nhớ hồi xưa bạn phải tự cấu hình TV, đầu DVD, hộp cáp, và hệ thống âm thanh — mỗi thứ có remote riêng. Rồi remote đa năng ra đời và gộp giao diện lại. Rồi TV thông minh loại bỏ hầu hết thiết bị riêng lẻ. Rồi trợ lý giọng nói cho phép bạn chỉ cần nói "mở phim". Mỗi bước loại bỏ sự phức tạp. Karpathy đang mô tả bước tiếp theo, nơi trợ lý giọng nói không chỉ điều khiển TV — mà điều khiển mọi thứ trong cuộc sống kỹ thuật số của bạn, và đủ thông minh để tự xử lý các chi tiết.

V. Tự Nghiên Cứu — Chuyện Gì Xảy Ra Khi AI Tự Cải Thiện Chính Mình

Đây có lẽ là phần quan trọng nhất — và đáng lo ngại nhất — của cuộc trò chuyện. Karpathy mô tả một hệ thống AI không chỉ làm việc cho con người, mà còn tự cải thiện mà không cần con người can thiệp.

"Auto research" thực ra nghĩa là gì: Karpathy có một dự án nơi ông huấn luyện các model AI nhỏ (cứ nghĩ chúng như phiên bản đơn giản hóa của ChatGPT). Huấn luyện một model AI đòi hỏi điều chỉnh hàng nghìn tham số — hãy hình dung như các nút vặn trên bàn mixer. Mỗi nút điều khiển một khía cạnh của quá trình học. Vặn đúng các nút này là một nghệ thuật mà nhà nghiên cứu phải mất nhiều năm để có cảm giác. Karpathy đã làm điều này hai mươi năm.

Ông thiết lập một hệ thống AI tự động điều chỉnh các nút này, chạy thử nghiệm, kiểm tra model có tốt hơn hay xấu hơn, rồi điều chỉnh tiếp. Ông để nó chạy qua đêm — hoàn toàn không cần giám sát — và nó tìm ra những cải thiện mà ông bỏ sót. Cụ thể, nó phát hiện một số tham số ít được chú ý (nếu muốn biết thuật ngữ: "weight decay on value embeddings" và "Adam betas") chưa được điều chỉnh tối ưu, và chúng tương tác với nhau theo cách khó nhìn thấy đối với con người. Hai mươi năm kinh nghiệm chuyên gia, và hệ thống tự động vẫn tìm ra cải tiến chỉ trong một đêm.

Tại sao điều này quan trọng: Đây là minh chứng nhỏ về thứ các lab AI lớn đang đua nhau hướng tới: tự cải thiện đệ quy. Đó là thuật ngữ kỹ thuật cho AI tự làm mình thông minh hơn, rồi lại tự làm thông minh hơn nữa, cứ thế tiếp. Nghe như khoa học viễn tưởng thì không phải — nó đang xảy ra ngay bây giờ ở quy mô nhỏ, và Karpathy đang mô tả từ kinh nghiệm trực tiếp.

Điều kiện then chốt — tiến độ có thể đo lường được: Tự nghiên cứu hoạt động được vì huấn luyện model AI có mục tiêu rõ ràng, đo lường được. Bạn có thể nói với hệ thống: "Làm cho con số này giảm" (gọi là "loss" trong học máy — con số đo mức độ sai của các dự đoán của model). Hệ thống thử nhiều thứ, kiểm tra con số có giảm không, và giữ lại những gì có tác dụng. Giống như có nhân viên làm việc suốt đêm mà hiệu suất được đánh giá hoàn toàn dựa trên một con số trên dashboard. Không mơ hồ, không chính trị nội bộ, không đánh giá chủ quan.

Karpathy chỉ ra rằng khả năng đo lường này là giới hạn quan trọng. Tự nghiên cứu hoạt động tốt cho bất cứ thứ gì có chỉ số rõ ràng — làm code chạy nhanh hơn, giảm lỗi, tối ưu tham số. Nhưng không hoạt động cho những thứ khó đo — sáng tạo, sắc thái, phán đoán, biết khi nào nên hỏi thay vì tự tìm hiểu. Đây là chủ đề xuyên suốt cuộc trò chuyện: AI vượt trội con người trong những lĩnh vực có thể kiểm chứng, và tầm thường ở mọi nơi khác.

Mở rộng quy mô: Karpathy mô tả cách các lab AI lớn — OpenAI, Anthropic, Google DeepMind — về cơ bản đang làm điều này ở quy mô khổng lồ. Họ có các cụm hàng chục nghìn chip chuyên dụng chạy thử nghiệm. Điểm đến hợp lý là làm cho các thử nghiệm này hoàn toàn tự động: một hệ thống AI tự tạo ra giả thuyết (có thể bằng cách đọc bài nghiên cứu), tự kiểm tra trên model nhỏ, giữ lại những gì có tác dụng, và suy ra kết quả cho model lớn hơn. Các nhà nghiên cứu con người sẽ đóng góp ý tưởng vào hàng đợi, nhưng họ sẽ không còn là người chạy thử nghiệm hay đánh giá kết quả nữa. Hệ thống sẽ chạy 24/7, với tốc độ và mức độ kỹ lưỡng mà không nhóm con người nào có thể sánh kịp.

Điều này có nghĩa gì với bạn: Đây là phần khiến bạn phải dừng lại suy nghĩ. Nếu AI có thể cải thiện AI, và các cải thiện cộng dồn lại, thì tốc độ tiến bộ của AI không còn bị giới hạn bởi tốc độ làm việc của nhà nghiên cứu con người nữa. Nó bị giới hạn bởi lượng sức mạnh tính toán có sẵn và mức độ thiết kế tốt của các hệ thống tự động. Karpathy đang mô tả một thế giới mà tiến độ tăng không theo đường thẳng mà theo hàm mũ — AI tồn tại sáu tháng nữa có thể tốt hơn đáng kể so với hiện tại, không phải vì con người có đột phá, mà vì AI tự cải thiện chính nó.

VI. Nghiên Cứu AI Theo Kiểu Cộng Đồng — Mô Hình Wikipedia Cho Trí Tuệ

Karpathy lấy ý tưởng tự nghiên cứu và đẩy thêm một bước: nếu bất kỳ ai trên internet cũng có thể góp phần cải thiện AI, không chỉ riêng người tại các lab lớn thì sao?

So sánh với SETI@home và Folding@home: Đầu những năm 2000, có các dự án cho phép người bình thường hiến tặng sức mạnh tính toán nhàn rỗi của máy tính cho nghiên cứu khoa học. SETI@home dùng để tìm kiếm tín hiệu ngoài Trái Đất. Folding@home dùng để nghiên cứu cách protein gấp lại (quan trọng cho việc hiểu bệnh tật). Bạn cài một chương trình nhỏ, và mỗi khi máy tính rảnh, nó sẽ xử lý một phần nhỏ của vấn đề khoa học lớn hơn.

Karpathy hình dung điều gì đó tương tự cho nghiên cứu AI. Ý tưởng cơ bản là: cải thiện model AI đòi hỏi thử rất nhiều thứ (10,000 ý tưởng có thể chỉ cho ra một cái có tác dụng), nhưng xác minh một cải thiện cụ thể có tác dụng hay không thì tương đối đơn giản (bạn chỉ cần chạy kiểm tra). Sự bất cân xứng này — khó khám phá, dễ xác minh — chính là thuộc tính làm cho Bitcoin mining hoạt động. Nhiều máy tính làm rất nhiều công việc để tìm block hợp lệ, nhưng ai cũng có thể xác minh kết quả trong vài giây.

Cách nó sẽ hoạt động trong thực tế: Mọi người hoặc tổ chức trên thế giới sẽ đóng góp sức mạnh tính toán cho một dự án nghiên cứu chung. Máy tính của họ sẽ thử các sửa đổi khác nhau cho code huấn luyện của model AI. Khi máy tính của ai đó tìm ra cải tiến, nó gửi lên. Hệ thống trung tâm xác minh cải tiến đó có thật không (bằng cách chạy huấn luyện và kiểm tra kết quả) và thêm vào codebase chung. Người đóng góp được ghi nhận trên bảng xếp hạng; tập thể có một model AI tốt hơn.

Vấn đề tin tưởng: Có một thách thức rõ ràng: nếu người lạ trên internet gửi code cho bạn chạy, đó là cơn ác mộng bảo mật. Ai đó có thể gửi code độc hại để đánh cắp dữ liệu hay phá hoại dự án. Karpathy thừa nhận điều này và nói thiết kế hệ thống cần xử lý người đóng góp không đáng tin — cách ly các bài gửi của họ, xác minh kết quả độc lập, và xây dựng các biện pháp bảo mật tương tự hệ thống blockchain. Khó, nhưng là loại vấn đề đã có giải pháp.

Tại sao điều này quan trọng với bạn: Hãy tưởng tượng bạn quan tâm đến nghiên cứu ung thư. Thay vì quyên tiền cho viện nghiên cứu và hy vọng họ dùng đúng, bạn có thể mua sức mạnh tính toán và đóng góp trực tiếp vào đàn AI tập trung vào ung thư. Đóng góp của bạn sẽ được đo lường và có thể xác minh. AI sẽ chạy thử nghiệm quanh đồng hồ, và sức mạnh tính toán của bạn sẽ là một phần của bộ não tập thể đang giải quyết vấn đề. Đây không phải giấc mơ xa vời — các mảnh kỹ thuật đã tồn tại hôm nay. Thứ còn thiếu là cơ sở hạ tầng điều phối.

Sức mạnh tính toán như đồng tiền mới: Karpathy và các người dẫn chương trình ngắn gọn khám phá một ý tưởng khiêu khích: liệu sức mạnh tính toán (đo bằng FLOPS — phép tính dấu phẩy động mỗi giây) có thể trở nên quan trọng hơn tiền không? Hiện tại, thật sự khó mua sức mạnh tính toán dù bạn có tiền mặt — có thiếu hụt vật lý về chip chuyên dụng mà AI cần. Trong một thế giới mà AI là động lực chính tạo ra giá trị, kiểm soát sức mạnh tính toán có thể quan trọng hơn kiểm soát đô la. Karpathy không hoàn toàn cam kết với ý tưởng này, nhưng ông thấy nó đủ thú vị để khám phá.

VII. Tại Sao AI Vừa Xuất Sắc Vừa Ngớ Ngẩn Cùng Lúc

Đây là một trong những phần dễ đồng cảm nhất của cuộc trò chuyện, vì ai đã dùng ChatGPT hay công cụ tương tự đều từng trải nghiệm điều này: AI viết một bài luận xuất sắc nhưng không đếm được số chữ "r" trong từ "strawberry." Nó giải bài toán ở trình độ đại học nhưng kể cùng một câu chuyện cười tẻ nhạt mãi không đổi.

Điều Karpathy gọi là "jaggedness" — sự tham sai: Hãy hình dung một học sinh đạt điểm bách phân vị thứ 99 ở phần toán trong kỳ thi SAT nhưng chỉ thứ 10 ở phần đọc hiểu. Ở con người, loại chênh lệch cực đoan như vậy rất hiếm — các năng lực thường có tương quan với nhau. Nếu bạn đủ thông minh để là lập trình viên đẳng cấp thế giới, có lẽ bạn cũng kể được một câu chuyện cười tử tế. Model AI không hoạt động theo cách đó. Chúng có thể vừa đẳng cấp thế giới trong một lĩnh vực, vừa ở trình độ mẫu giáo trong lĩnh vực khác.

Bài kiểm tra câu chuyện cười: Karpathy chỉ ra rằng nếu bạn hỏi model AI tiên tiến nhất thế giới kể chuyện cười, bạn sẽ nhận được câu chuyện cười y hệt ba hoặc bốn năm trước: "Tại sao các nhà khoa học không tin nguyên tử? Vì chúng đã bịa đặt nên mọi thứ." Dù hàng nghìn tỷ đô la đầu tư và những bước nhảy vọt khổng lồ về năng lực, câu chuyện cười không hề tốt hơn. Thậm chí không thay đổi. Hỏi cùng AI đó xây dựng một tính năng phần mềm phức tạp và nó sẽ làm việc nhiều giờ và cho ra sản phẩm phi thường. Nhưng kể chuyện cười? Vẫn câu đó. Mãi mãi.

Tại sao điều này xảy ra — giải thích về reinforcement learning: Các lab AI cải thiện model thông qua quá trình gọi là học tăng cường. Nói đơn giản, họ đưa cho AI một nhiệm vụ, kiểm tra nó làm có đúng không, và thưởng cho câu trả lời đúng. Điều này hoạt động cực kỳ tốt cho các nhiệm vụ mà "đúng" và "sai" rõ ràng: Code có chạy không? Toán có đúng không? Kiểm tra có qua không? AI ngày càng giỏi hơn ở những nhiệm vụ này vì vòng phản hồi chặt chẽ và không mơ hồ.

Nhưng với những thứ mà "tốt" và "xấu" mang tính chủ quan — hài hước, phong cách, nhận thức xã hội, biết khi nào nên hỏi câu hỏi — không có tín hiệu phản hồi rõ ràng. Chưa ai tìm ra cách cho AI một "điểm hài hước" có thể đo lường để cải thiện câu chuyện cười một cách đáng tin. Vì vậy những khả năng mềm này không cải thiện với tốc độ tương tự những khả năng cứng, có thể xác minh. Model trở nên giỏi hơn đáng kể về lập trình trong khi khiếu hài hước vẫn đóng băng năm 2021.

Điều Karpathy gọi là "on rails" vs. "off rails": Khi AI làm việc trong lĩnh vực được huấn luyện — lập trình, toán, phân tích — cảm giác như bạn đang kết nối với siêu trí tuệ. Mọi thứ diễn ra với tốc độ và chất lượng phi thường. Nhưng khi bước ra ngoài những lĩnh vực đó — yêu cầu viết sáng tạo với giọng văn thật sự, yêu cầu sắc thái xã hội, yêu cầu thứ gì đó thật sự mới lạ — AI "lan man." Nó cho ra sản phẩm nhạt nhẽo, chung chung. Bạn đã lạc ra khỏi đường ray vào vùng hoang mạc chưa được tối ưu.

Tại sao điều này quan trọng với bạn: Đây là điều cốt lõi để hiểu AI có thể và không thể làm gì cho bạn ngay hôm nay. Nếu công việc của bạn liên quan đến nhiệm vụ có câu trả lời đúng sai rõ ràng — phân tích dữ liệu, viết code, tóm tắt tài liệu, công thức bảng tính — AI đã cực kỳ hữu ích và đang ngày càng tốt hơn. Nếu công việc của bạn liên quan đến phán đoán, thẩm mỹ, sắc thái giao tiếp con người, sáng tạo độc đáo, hoặc biết câu hỏi nào cần hỏi — AI tầm thường ở mức tốt nhất, và có thể không cải thiện nhanh như các tiêu đề báo gợi ý. Khoảng cách giữa hai loại này là "sự tham sai" mà Karpathy đang mô tả, và giải thích tại sao cùng một AI có thể vừa như thiên tài vừa như người ngốc trong cùng một cuộc trò chuyện.

Hàm ý khó chịu: Một số nhà nghiên cứu hy vọng rằng làm AI giỏi code hơn sẽ tự động làm nó giỏi mọi thứ hơn — rằng trí tuệ là trí tuệ, và cải thiện một lĩnh vực sẽ kéo tất cả lên. Karpathy không tin điều này đang xảy ra. Ông thấy các cải thiện ở lại trong làn đường của chúng. Code tốt hơn; câu chuyện cười vẫn vậy. Điều này có nghĩa chúng ta không nên kỳ vọng AI trở nên xuất sắc đồng đều chỉ vì nó xuất sắc ở nhiệm vụ cụ thể. Sự tham sai có thể là đặc điểm vĩnh viễn, không phải lỗi tạm thời.

VIII. Có Nên Có Nhiều AI Chuyên Biệt Cho Từng Công Việc Không?

Dựa trên vấn đề tham sai, Karpathy đặt câu hỏi tự nhiên: thay vì cố xây một AI giỏi mọi thứ, có nên xây nhiều AI mỗi cái thật giỏi một việc không?

Cách tiếp cận hiện tại — một model cai trị tất cả: Hiện nay, các công ty như OpenAI, Anthropic, và Google đang xây dựng thứ mà Karpathy gọi là "monoculture" — một model AI khổng lồ duy nhất được cho là xử lý mọi thứ. Cần thơ? Cùng model đó. Cần phân tích tài chính? Cùng model đó. Cần debug code? Cùng model đó. Logic là một model mạnh duy nhất dễ triển khai, bảo trì, và cải thiện hơn. Nhưng kết quả là vấn đề tham sai: model giỏi một số thứ và tầm thường ở thứ khác, và người dùng không bao giờ biết họ sẽ gặp phiên bản nào.

Lựa chọn thay thế — chuyên biệt hóa: Karpathy mượn thuật ngữ từ sinh học: speciation — sự phân nhánh loài. Trong tự nhiên, động vật tiến hóa ra nhiều loại não khác nhau cho những môi trường khác nhau. Đại bàng có khả năng xử lý thị giác phi thường. Cá heo có hệ thống định vị âm thanh tinh vi. Con người có trung tâm ngôn ngữ và lý luận phát triển quá mức. Không con nào giỏi mọi thứ; mỗi con đặc biệt xuất sắc ở những gì môi trường của nó đòi hỏi.

Karpathy gợi ý AI nên đi theo con đường tương tự. Thay vì một model biết mọi thứ, bạn có thể có các model nhỏ hơn, chuyên biệt, chia sẻ một "lõi nhận thức chung" (lý luận cơ bản và hiểu ngôn ngữ) nhưng được chuyên biệt hóa sâu trong các lĩnh vực cụ thể. Model cho nhà toán học làm việc trong hệ thống chứng minh hình thức. Model cho bác sĩ phân tích hình ảnh y tế. Model cho luật sư xem xét hợp đồng. Mỗi cái sẽ nhanh hơn, rẻ hơn, và tốt hơn ở nhiệm vụ cụ thể của nó so với model tổng quát khổng lồ.

Tại sao điều này chưa xảy ra: Có hai lý do chính. Thứ nhất, các lab AI không biết trước người dùng sẽ hỏi về gì. Vì cùng một model phục vụ hàng triệu người dùng với nhu cầu hoàn toàn khác nhau, nó phải là người đa năng. Thứ hai, khoa học tùy chỉnh model AI vẫn còn non nớt. Khi bạn cố làm model giỏi hơn ở một thứ, thường vô tình làm nó kém hơn ở thứ khác. Giống như học sinh học quá tập trung cho kỳ thi toán đến mức quên hết lịch sử. Đến khi vấn đề này được giải quyết, xây dựng model chuyên biệt đáng tin cậy khó hơn nghe.

Điều này có nghĩa gì với bạn: Trong tương lai gần, bạn vẫn sẽ tương tác với model AI đa năng — các ChatGPT và Claude của thế giới. Nhưng trong vài năm tới, hãy kỳ vọng thấy nhiều công cụ AI chuyên biệt hơn xuất hiện cho các ngành và nhiệm vụ cụ thể. Bác sĩ của bạn có thể dùng AI y tế giỏi chẩn đoán hơn model tổng quát nhiều. Kế toán của bạn có thể dùng AI tài chính hiểu luật thuế ở tầng sâu hơn. Các model đa năng sẽ không biến mất, nhưng chúng sẽ được bổ sung bởi các chuyên gia — giống như bác sĩ đa khoa trong y tế được bổ sung bởi tim mạch, thần kinh, và ung thư học.

IX. Open Source Vs. Big Tech — Ai Nên Kiểm Soát AI?

Đây là một trong những chủ đề mang tính chính trị nhất trong AI, và Karpathy — người đã làm việc bên trong các lab lớn nhất và giờ hoạt động độc lập — có quan điểm tinh tế.

"Open source" trong AI nghĩa là gì: Khi một công ty như Meta phát hành model AI dưới dạng "open source," họ cho phép bất kỳ ai tải về, kiểm tra, sửa đổi, và sử dụng. Bạn có thể chạy nó trên máy tính của mình mà không phải trả tiền cho công ty. Ngược lại là "closed source," nơi các công ty như OpenAI hay Anthropic giữ model sau rào chắn đăng ký — bạn có thể dùng, nhưng không thể xem cách chúng hoạt động hay tự chạy chúng.

Tình trạng hiện tại: Các model AI mạnh nhất là closed — chúng thuộc về một số ít công ty. Nhưng các model open source đang bắt kịp nhanh chóng. Karpathy nói khoảng cách từng là khoảng 18 tháng; giờ còn khoảng sáu đến tám tháng. Các công ty Trung Quốc và nhóm nghiên cứu toàn cầu đã phát hành các model mở gần với tiên phong hơn hầu hết mọi người kỳ vọng.

Quan điểm của Karpathy — Linux cho AI: Ông vẽ ra so sánh với cuộc chiến hệ điều hành. Windows và macOS là sản phẩm thương mại đóng. Linux là open source — và nó chạy trên khoảng 60% máy tính thế giới (hầu hết web server, điện thoại Android, và hạ tầng đám mây đều dùng Linux). Linux thành công vì ngành thực sự cần một nền tảng chung mà không công ty đơn lẻ nào kiểm soát. Karpathy tin AI cần điều tương tự.

Điểm khác biệt là chi phí. Viết phần mềm cho Linux đòi hỏi tài năng nhưng không cần phần cứng đắt tiền. Huấn luyện model AI lớn đòi hỏi chip tính toán chuyên dụng trị giá hàng triệu đô. Điều này làm cho open source AI khó cạnh tranh ở đỉnh tuyệt đối. Nhưng Karpathy lập luận rằng cho đại đa số trường hợp sử dụng hàng ngày, các model open source đã đủ tốt. Và thứ là tiên phong hôm nay sẽ là open source trong sáu đến mười hai tháng. Đó là băng chuyền: các lab lớn đẩy ranh giới, open source theo sau, và tổng năng lực có sẵn cho mọi người cứ tăng lên mãi.

Tại sao điều này quan trọng — nguy cơ tập trung hóa: Karpathy trở nên cá nhân hơn ở đây. Ông là người gốc Slovak-Canada, và ông nhắc đến lịch sử Đông Âu để giải thích sự ngờ vực của mình với tập trung hóa. Khi quyền lực được tập trung vào ít tay — dù là chính phủ hay tập đoàn — những điều xấu thường xảy ra. Ông không muốn AI mạnh nhất thế giới chỉ tồn tại sau cánh cửa đóng của hai hoặc ba công ty. Ông muốn nhiều lab hơn, nhiều quan điểm hơn, nhiều người hơn trong phòng khi đưa ra các quyết định quan trọng. Trong học máy, ông lưu ý, các ensemble (kết hợp nhiều model) luôn vượt trội bất kỳ model đơn lẻ nào. Nguyên tắc tương tự, ông lập luận, áp dụng cho các tổ chức.

Điều này có nghĩa gì với bạn: Cuộc tranh luận này có thể trừu tượng, nhưng nó có hậu quả thực với cuộc sống bạn. Nếu AI bị kiểm soát bởi vài công ty, các công ty đó quyết định AI có thể và không thể làm gì, ai được tiếp cận, và chi phí bao nhiêu. Nếu có các lựa chọn open source mạnh mẽ, bạn có lựa chọn — và mọi lập trình viên xây dựng công cụ bạn dùng cũng vậy. Karpathy về cơ bản lập luận rằng sự cân bằng hiện tại (lab lớn ở tiên phong, open source gần theo sau) là lành mạnh, và chúng ta nên nỗ lực duy trì nó.

X. Còn Công Việc Của Tôi Thì Sao? — Câu Trả Lời Thật Sự

Đây là câu hỏi mọi người muốn được trả lời, và Karpathy thật lòng đáng khen ngợi về cả sự lạc quan lẫn sự không chắc chắn của ông.

Khung tư duy then chốt — kỹ thuật số vs. vật lý: Karpathy chia nền kinh tế thành hai loại. Công việc "kỹ thuật số" là bất cứ thứ gì bạn có thể làm từ máy tính ở nhà — kỹ thuật phần mềm, phân tích tài chính, thiết kế đồ họa, viết lách, nhập liệu, nghiên cứu pháp lý, hỗ trợ khách hàng. Công việc "vật lý" đòi hỏi cơ thể bạn phải ở đâu đó — điều dưỡng, xây dựng, thợ ống nước, cảnh sát, phẫu thuật, nhà hàng.

AI hiện tại là thực thể kỹ thuật số. Nó thao túng thông tin — văn bản, code, số, hình ảnh — với tốc độ phi thường. Nó không có thân xác. Di chuyển bit thông tin gần như miễn phí và tức thì; di chuyển vật thể vật lý đòi hỏi năng lượng, thời gian, và kỹ thuật. Karpathy ước tính thao túng bit dễ hơn thao túng nguyên tử khoảng "một triệu lần." Vì vậy sự gián đoạn sẽ đánh vào công việc kỹ thuật số trước và mạnh nhất. Công việc vật lý cũng sẽ thay đổi, nhưng chậm hơn nhiều.

Sẽ có ít việc làm hơn không? — Nghịch lý Jevons: Câu trả lời của Karpathy dựa trên nguyên tắc kinh tế 150 tuổi gọi là nghịch lý Jevons. Vào những năm 1860, nhà kinh tế học William Stanley Jevons quan sát rằng khi động cơ hơi nước trở nên hiệu quả hơn về nhiên liệu, tiêu thụ than không giảm — mà tăng. Động cơ rẻ hơn đến mức người ta dùng chúng cho những việc trước đây quá đắt. Nhu cầu mở rộng nhanh hơn hiệu quả giảm.

Ví dụ hiện đại Karpathy dùng là ATM và nhân viên ngân hàng. Khi ATM được giới thiệu, người ta lo nhân viên ngân hàng sẽ bị thay thế. Điều thực sự xảy ra là ATM làm cho mỗi chi nhánh ngân hàng rẻ hơn nhiều để vận hành (bạn cần ít nhân viên hơn mỗi chi nhánh). Vì chi nhánh rẻ hơn, các ngân hàng mở thêm nhiều chi nhánh hơn. Tổng số việc làm nhân viên ngân hàng thực tế tăng trong nhiều thập kỷ sau khi ATM được giới thiệu.

Karpathy lập luận cùng động lực áp dụng cho phần mềm. Phần mềm cực kỳ mạnh mẽ, nhưng trong lịch sử, sản xuất nó đắt tiền. Chỉ các công ty lớn mới đủ khả năng xây phần mềm tùy chỉnh cho nhu cầu cụ thể. Nếu AI làm phần mềm rẻ hơn 10 hay 100 lần, nhu cầu phần mềm sẽ không giảm cùng hệ số — nó sẽ bùng nổ. Các doanh nghiệp nhỏ trước đây không đủ tiền phần mềm tùy chỉnh sẽ đột nhiên có thể tiếp cận. Cá nhân sẽ có phần mềm cá nhân hóa theo nhu cầu cụ thể. Tổng lượng phần mềm trên thế giới sẽ tăng mạnh, và cùng với đó, nhu cầu về người có thể chỉ đạo và quản lý việc tạo phần mềm do AI hỗ trợ.

Sự không chắc chắn thật sự: Karpathy không giả vờ biết điều này diễn ra thế nào về lâu dài. Ông lưu ý rằng các nhà nghiên cứu tại các lab AI lớn đang tự làm mình mất việc, và nhiều người trong số họ cảm thấy sự lo lắng tương tự ông mô tả. Ông nói với đồng nghiệp tại OpenAI: "Nếu chúng ta thành công ở điều này, tất cả chúng ta đều mất việc." Tương lai dài hạn thật sự không chắc chắn, và Karpathy nói dự báo đúng là việc của các nhà kinh tế, không phải kỹ sư.

Lời khuyên thực tế: Lời khuyên ngầm của Karpathy là: các công cụ cực kỳ mới và cực kỳ mạnh mẽ. Điều đầu tiên cần làm là học chúng. Đừng bác bỏ AI hay sợ hãi — hãy xem nó như những gì nó đang là, một công cụ trao quyền. Công việc là tập hợp các nhiệm vụ, và một số nhiệm vụ đó giờ có thể làm nhanh hơn nhiều. Những người học dùng các công cụ này hiệu quả sẽ năng suất hơn, có giá trị hơn, và khó thay thế hơn.

XI. Robot Đang Tới, Nhưng Không Nhanh Như Bạn Nghĩ

Nếu AI sắp biến đổi mọi công việc kỹ thuật số, còn công việc vật lý thì sao? Robot có thay thế thợ ống nước, y tá, và thợ xây không? Câu trả lời của Karpathy được định hình bởi thời gian ông dẫn chương trình xe tự lái của Tesla, và thận trọng hơn bạn có thể kỳ vọng.

Bài học từ xe tự lái: Karpathy dẫn nhóm AI tại Tesla đang cố làm xe tự lái. Ông chứng kiến hàng chục startup xe tự lái ra đời một thập kỷ trước, đầy vốn mạo hiểm và sự lạc quan. Hầu hết thất bại. Công nghệ đòi hỏi đầu tư vốn khổng lồ, nhiều năm phát triển, và sức chịu đựng với thế giới vật lý bừa bộn, khó lường. Xe tự lái vẫn chưa hoàn toàn được giải quyết, dù hàng tỷ đô la và một thập kỷ nỗ lực.

Ông kỳ vọng robot tổng quát — robot hình người, robot kho hàng, trợ lý trong nhà — sẽ theo quỹ đạo tương tự. Sẽ có tiến bộ, nhưng chậm hơn, tốn kém hơn, và khó khăn hơn cuộc cách mạng kỹ thuật số đang xảy ra ngay bây giờ. Lý do là cơ bản: di chuyển vật thể vật lý vốn khó hơn di chuyển thông tin. Bạn có thể copy một file trong mili giây. Di chuyển một cái hộp qua phòng đòi hỏi động cơ, cảm biến, điện năng, và xử lý nghìn biến số khó lường (sàn ướt, con mèo đang ngồi đó, hộp nặng hơn dự kiến).

Ba giai đoạn phát triển: Karpathy mô tả tương lai trong ba giai đoạn:

Giai đoạn 1 (đang xảy ra): Viết lại mạnh mẽ thế giới kỹ thuật số. Mọi thứ tồn tại dưới dạng thông tin số — tài liệu, code, dữ liệu, quy trình — được tối ưu hóa, tổ chức lại, và cải tiến bởi AI với tốc độ đáng kinh ngạc.

Giai đoạn 2 (sắp tới): Các công ty xuất hiện ở giao giữa kỹ thuật số và vật lý. Đây là "cảm biến và cơ cấu chấp hành" — các công ty đưa dữ liệu thế giới thực vào AI (camera, thiết bị phòng thí nghiệm, thiết bị giám sát môi trường) hoặc thực thi lệnh của AI trong thế giới vật lý (robot, phòng thí nghiệm tự động, logistics).

Giai đoạn 3 (xa hơn): Tự chủ hoàn toàn trong thế giới vật lý — robot có thể làm các nhiệm vụ vật lý phức tạp một cách đáng tin cậy và kinh tế. Đây là thị trường lớn nhất, nhưng đến sau cùng.

Điều này có nghĩa gì với bạn: Nếu công việc của bạn chủ yếu là vật lý — bạn làm việc bằng tay, cần hiện diện thực tế, công việc liên quan thế giới thực khó lường — bạn có nhiều thời gian hơn trước khi AI thay đổi công việc hàng ngày. Không phải vì công việc vật lý kém quan trọng, mà vì nó khó tự động hóa hơn. Nếu công việc của bạn chủ yếu là kỹ thuật số — bạn làm việc trên máy tính, xử lý thông tin — những thay đổi đã ở đây rồi.

XII. Tương Lai Của Trường Học — AI Làm Gia Sư Riêng

Gần cuối cuộc trò chuyện, Karpathy nói về một dự án tên MicroGPT và điều nó tiết lộ về tương lai giáo dục.

MicroGPT là gì: Karpathy đã dành hơn một thập kỷ cố gắng chắt lọc khái niệm huấn luyện model AI xuống dạng đơn giản nhất tuyệt đối. MicroGPT là nỗ lực mới nhất: toàn bộ thuật toán — tải dữ liệu, xây mạng nơ-ron, huấn luyện, và tối ưu hóa — được thể hiện chỉ trong 200 dòng code Python đơn giản. Mọi thứ ngoài 200 dòng đó, trong hệ thống AI thật, chỉ để làm nó chạy nhanh hơn. Nếu bạn không quan tâm tốc độ và chỉ muốn hiểu thuật toán, 200 dòng là tất cả những gì bạn cần.

Sự chuyển dịch trong giáo dục: Trong quá khứ, bản năng của Karpathy sẽ là làm một video giải thích dài đi qua code. Ông nổi tiếng với chính xác loại nội dung giáo dục này (các video YouTube về mạng nơ-ron của ông có hàng triệu lượt xem). Nhưng ông nhận ra điều gì đó: code quá đơn giản đến mức bất kỳ ai cũng có thể nhờ trợ lý AI của họ giải thích. Và trợ lý AI sẽ giải thích tốt hơn ông — không phải vì nó hiểu nhiều hơn, mà vì nó có thể tùy chỉnh giải thích cho từng cá nhân. Nếu bạn học bằng hình ảnh, nó có thể vẽ sơ đồ. Nếu bạn đã biết tính toán, nó có thể dùng ký hiệu toán học. Nếu bạn hoàn toàn mới bắt đầu, nó có thể bắt đầu từ cơ bản nhất. Không giáo viên con người nào có thể làm điều này cho mọi học sinh đồng thời.

Vai trò mới của giáo viên: Karpathy mô tả một sự chuyển dịch căn bản. Thay vì giải thích mọi thứ cho người, giáo viên nên giải thích mọi thứ cho agent. Nếu agent hiểu tài liệu, agent có thể giải thích nó cho bất kỳ ai. Vai trò của giáo viên trở thành thiết kế chương trình học — tạo ra thứ Karpathy gọi là "skill," về cơ bản là bộ hướng dẫn cho AI về con đường tiến triển cần dẫn dắt học sinh qua — và đóng góp những "bit ít ỏi" của sự thấu hiểu thật sự mà AI không tự tạo ra được.

Điều này có nghĩa gì với bạn: Nếu bạn là học sinh, tương lai có vẻ như có gia sư riêng luôn có mặt, kiên nhẫn vô hạn, và thích nghi hoàn hảo với phong cách học của bạn. Nếu bạn là giáo viên, vai trò của bạn đang tiến hóa từ "người truyền đạt thông tin" sang "người thiết kế trải nghiệm học và đóng góp những hiểu biết AI không thể." Nếu bạn là phụ huynh, các công cụ giáo dục cho con bạn sẽ tốt hơn nhiều so với những gì bạn có — nhưng các yếu tố con người trong giáo dục (động lực, hướng dẫn, phát triển xã hội) sẽ trở nên quan trọng hơn, không phải ít hơn, chính xác vì phần truyền đạt thông tin đang được tự động hóa.

XIII. Tại Sao Karpathy Rời Bỏ Big Tech — Và Điều Đó Nói Lên Điều Gì

Cuộc trò chuyện kết thúc với một ghi chú rất cá nhân. Karpathy từng làm tại OpenAI và Tesla — hai tổ chức AI có hậu quả nhất trong lịch sử. Tại sao ông rời đi, và tại sao ông không quay lại?

Lập luận về độc lập: Bên trong một lab AI lớn, bạn không được tự do. Có những thứ bạn không thể nói công khai — không phải vì ai cấm một cách rõ ràng, mà vì áp lực là có thật. Đồng nghiệp của bạn liếc nhìn. Cuộc trò chuyện trở nên ngượng ngùng. Tổ chức có câu chuyện muốn chiếu, và các tuyên bố công khai của bạn ngầm phải hỗ trợ nó. Karpathy nói ông cảm thấy "gắn liền với nhân loại" hơn khi ở ngoài các lab vì ông không bị ràng buộc bởi các động cơ tài chính đến từ việc là một phần của tổ chức kiếm lợi từ việc làm AI mạnh hơn.

Đây là nan đề mà OpenAI ban đầu được thành lập để giải quyết: nếu AI sắp thay đổi thế giới một cách mạnh mẽ, những người xây dựng nó không nên là cùng những người kiếm lợi từ nó. Karpathy không tuyên bố vấn đề này đã được giải quyết — ông nói "nan đề vẫn chưa được giải quyết hoàn toàn."

Chi phí của việc ở ngoài: Độc lập có nhược điểm thực: các lab tiên phong là mờ đục. Họ đang làm gì tiếp theo, và nếu bạn không ở trong đó, hiểu biết của bạn về tương lai không tránh khỏi bị lệch. Bạn không biết các hệ thống thực sự hoạt động thế nào bên dưới. Bạn không có cảm giác đáng tin cậy về hướng đi. Karpathy thừa nhận điều này khiến ông lo lắng.

Giải pháp đề xuất của ông mang tính thực dụng: vào ra luân phiên. Dành thời gian bên trong một lab tiên phong, đóng góp công việc thực sự, giữ kết nối với trạng thái nghệ thuật thực tế. Rồi bước ra ngoài, lấy lại sự độc lập, nói thẳng, đóng góp cho hệ sinh thái. Đừng vĩnh viễn gắn mình với bất kỳ tổ chức đơn lẻ nào, vì khi cổ phần trở nên thực sự cao, là nhân viên nghĩa là bạn không thực sự kiểm soát tổ chức làm gì.

Điều này có nghĩa gì với bạn: Lựa chọn nghề nghiệp của Karpathy phản ánh sức căng rộng hơn trong AI. Công nghệ đang được xây dựng bởi một số ít công ty với quyền lực khổng lồ và tính minh bạch hạn chế. Những người bên trong các công ty đó thông minh, nhưng họ không phải là các tác nhân tự do — họ không phải lúc nào cũng có thể nói với công chúng những gì họ biết hay nghĩ. Lựa chọn của Karpathy hoạt động độc lập, với cái giá là hơi tụt hậu so với tiên phong, là cách ông duy trì khả năng nói thật. Đó là sự đánh đổi mà ngày càng nhiều nhà nghiên cứu AI có thể phải đối mặt khi cổ phần ngày càng cao hơn.

Kết Luận

Nếu bạn đọc đến đây, đây là điều Andrej Karpathy thật ra đang nói, gỡ bỏ hết thuật ngữ:

Công cụ đã thay đổi. Vào khoảng tháng 12 năm 2025, các trợ lý AI lập trình đã đủ tốt đến mức các lập trình viên hàng đầu ngừng tự viết code. Giờ họ quản lý các nhân viên AI thay thế. Đây giống như bước chuyển từ viết thư tay sang dùng email — cùng công việc được hoàn thành, nhưng phương pháp hoàn toàn khác.

Các app của bạn sắp biến mất. Tương lai không phải năm mươi app trên điện thoại; mà là một trợ lý AI nói chuyện với tất cả chúng từ hậu trường. Bạn chỉ cần nói muốn gì.

AI đang cải thiện AI. Karpathy thiết lập một AI tối ưu các AI khác qua đêm. Nó tìm ra những cải tiến ông bỏ sót sau hai mươi năm kinh nghiệm. Các lab lớn đang làm điều này ở quy mô khổng lồ. Tốc độ cải thiện AI sắp không còn bị giới hạn bởi tốc độ làm việc của nhà nghiên cứu con người.

AI vừa xuất sắc vừa mù quáng cùng lúc. Nó có thể xây phần mềm phức tạp nhưng không thể kể một câu chuyện cười mới. Nó có thể giải bài toán trình độ sau đại học nhưng không biết khi nào nên hỏi câu hỏi làm rõ. Sự không đồng đều này có tính cấu trúc, không phải tạm thời.

Công việc kỹ thuật số thay đổi trước. Nếu bạn làm việc trên máy tính, những thay đổi đã ở đây rồi. Nếu bạn làm việc bằng tay, bạn có nhiều thời gian hơn — nhưng những thay đổi đang tới cho công việc vật lý cũng vậy, chỉ chậm hơn.

Nhiều phần mềm hơn, không phải ít hơn. Phần mềm rẻ hơn trong lịch sử đồng nghĩa với nhu cầu nhiều hơn, không phải ít hơn. Cùng quy luật đó có khả năng giữ nguyên với việc tạo phần mềm do AI hỗ trợ.

Giáo dục chuyển đổi. Giáo viên sẽ chuyển từ giải thích mọi thứ cho người sang thiết kế chương trình học cho gia sư AI. Gia sư AI sẽ kiên nhẫn hơn, thích nghi hơn, và cuối cùng hiểu biết hơn bất kỳ giáo viên con người nào — nhưng nó sẽ cần nội dung do con người tạo ra để dạy từ đó.

Những người phụ trách cũng đang lo lắng. Karpathy, một trong những nhà nghiên cứu AI thành công nhất còn sống, mô tả bản thân đang trong trạng thái "AI psychosis." Ông cảm thấy sự lo lắng tương tự như mọi người về việc theo kịp. Điểm khác là ông lo lắng về việc đứng ở tiên phong; bạn có thể lo lắng về việc bị bỏ lại phía sau. Dù thế nào, lãnh thổ này mới với tất cả mọi người.

Phải làm gì bây giờ: Học các công cụ. Đừng sợ chúng và đừng bác bỏ chúng. Tập trung vào những thứ AI không thể làm — phán đoán, sáng tạo, công việc vật lý, trí tuệ cảm xúc, đặt ra những câu hỏi đúng. Mọi thứ AI có thể làm, nó sẽ sớm làm tốt hơn bạn. Chiến lược thua duy nhất là đứng yên.

Bài phân tích này dựa trên lần xuất hiện của Andrej Karpathy trên podcast No Priors. Mọi ý tưởng và nhận định đều được gán cho Karpathy và người dẫn chương trình như được thể hiện trong cuộc trò chuyện gốc. Các giải thích và ví dụ so sánh được thêm vào để giúp dễ hiểu hơn.

Labels: , ,
Subscribe to: Posts (Atom)