Bên trong OpenAI: một nơi làm việc AI-native đòi hỏi gì ở con người

1. Nate tới OpenAI: máy tính này là của ai?

Nate B Jones đặt ra một câu hỏi: máy tính này là máy tính của anh, hay thật ra là máy tính của Codex, còn anh chỉ có một góc nhỏ để ngồi nói chuyện với nó? Anh kể rất nhiều lúc anh dùng Wispr Flow để nói với agent, rồi có một con trỏ chạy khắp các cửa sổ, làm user acceptance testing cho thứ anh đang build, và anh thậm chí không còn biết chuyện gì đang diễn ra trong tất cả các cửa sổ của mình nữa (theo video đăng ngày 22/09/2026).

Có một câu nói về lúc ngữ cảnh liên quan tới một vai trò trở nên sẵn có. Andrew nói voice là cách hiệu quả nhất để đưa ngữ cảnh vào và để truyền đạt thông tin, nhưng đọc thì nhanh hơn nghe nhiều. Akshay kể tuần trước, một automation của anh tìm ra một lỗi khá lớn trong hồ sơ thuế của anh. Nate hỏi: "Có lợi cho anh không?" Akshay đáp: có lợi cho anh, và nó giúp anh tiết kiệm được hàng nghìn đô, một chuyện mà anh nói tự mình sẽ không bao giờ phát hiện ra. Nate thì nói anh đã đánh giá thấp tiềm năng scaling law của computer use (theo video đăng ngày 22/09/2026).

Rồi Nate nói anh được có mặt ở OpenAI hôm đó và rất hào hứng (theo video đăng ngày 22/09/2026). Anh biết rất nhiều người xem đã hỏi anh nhiều tới mức anh không đếm xuể về những gì anh có thể hỏi những người ở OpenAI. Cuộc trò chuyện này là thứ anh rất háo hức được chia sẻ, vì theo anh nó chạm vào cốt lõi của việc AI đi từ chỗ chỉ là một chatbot trong túi bạn tới chỗ làm được những việc có ý nghĩa.

Nate giới thiệu anh sẽ ngồi với Akshay và Andrew, hai người mà theo anh đều đang ở rất sâu trong bước chuyển đó, xây dựng tương lai của cách tất cả chúng ta làm việc cùng nhau (theo video đăng ngày 22/09/2026). Anh nói cuộc trò chuyện sẽ đi xa hơn phần interface. Thứ anh muốn bàn là: làm việc theo cách khác trong thời AI, ở ngay tại OpenAI, cảm giác thế nào?

Nate nói hai người không có sẵn mọi câu trả lời, nhưng cả ba sẽ cùng nói về chuyện đó trông ra sao trong thực tế, và về những bài học mà ai cũng có thể lấy để làm việc theo cách khác (theo video đăng ngày 22/09/2026). Theo anh, cuộc nói chuyện sẽ đi tới một điểm mà tất cả có thể hiểu vài xu hướng dài hạn nhìn thấy được từ bên trong toà nhà này, những xu hướng sẽ định hình việc ta nên đi đâu với sự nghiệp, với bộ kỹ năng, với mức thành thạo AI, và ta nên tập trung học gì trong sáu tháng tới một năm tới. Anh nói anh đã rất mong buổi này và không chờ nổi để người xem bắt đầu.

2. Andrew, Akshay và những use case bất ngờ của Astra

Nate nói anh rất vui được trò chuyện với Andrew và Akshay, rồi hỏi trước tiên hai người là ai và đã tới OpenAI như thế nào. Andrew nhận nói trước. Anh kể anh bắt đầu làm Codex app, mà giờ đã thành toàn bộ app desktop của OpenAI, và làm nhiều việc khác nhau ở đó. Lúc nói chuyện anh đã ở OpenAI khoảng một năm, hơn một năm một chút (theo video đăng ngày 22/09/2026).

Nate hỏi trước đó Andrew ở đâu. Andrew kể anh luôn ở trong giới startup: anh làm founder chừng tám năm, làm những thứ nhỏ, rồi có dịp kết nối với vài người ở OpenAI, và từ đó mọi thứ cất cánh (theo video đăng ngày 22/09/2026). Nate đáp như vậy là hợp lý, rồi quay sang hỏi Akshay.

Akshay kể anh đã ở OpenAI khoảng ba năm (anh nói "three-ish years"). Anh vào OpenAI để dẫn dắt team ChatGPT Enterprise, rồi chuyển qua lại khá nhiều chỗ, làm nhiều việc bên mảng consumer. Gần đây anh tập trung dẫn dắt mảng mà anh gọi là "productivity and engineering pillar", với mục tiêu đưa những agent hữu ích tới tất cả mọi người, bắt đầu bằng việc tập trung vào knowledge work và developer (theo video đăng ngày 22/09/2026).

Nate nói đó là chỗ tốt để bắt đầu. Anh hỏi: với việc ra mắt Astra, giờ Astra không còn chỉ ở bên trong các bức tường của OpenAI mà đã ra bên ngoài, ai cũng có nó; vậy hai người thấy use case nào bất ngờ nhất ngoài đời thật kể từ khi nó ra mắt? (câu hỏi của Nate trong video đăng ngày 22/09/2026)

Andrew đáp rằng chuyện bất ngờ nhất, thì chuyện fruit fly đã khá điên rồ; Nate đồng ý là chuyện đó hơi điên thật (theo video đăng ngày 22/09/2026). Nhưng thứ Andrew không ngờ sẽ bùng lên, một phần chỉ vì nó vui, là Blender: mọi người dựng mô phỏng các môi trường 3D. Anh nói đó không phải việc hữu ích nhất mà anh và đồng nghiệp ở OpenAI dùng nó để làm ở nội bộ, nhưng nhìn mọi người tạo ra những game và môi trường photorealistic mà người ta có thể đi lại bên trong thì khá kinh ngạc.

Theo Andrew (video đăng ngày 22/09/2026), mỗi model ra đời đều có những "spike", những thứ nó làm được thật tốt, và một trong các spike của Astra là 3D. Nate hỏi ở nội bộ hai người có biết 3D là một spike khi phát hành không. Akshay đáp là đã có người ở nội bộ chơi với những khả năng đó.

Anh nói tiếp, nhắc lại ý của Andrew: anh nghĩ anh và đồng nghiệp đã bất ngờ vì nó được đón nhận nhiều tới vậy (theo video đăng ngày 22/09/2026). Anh kể một người trong gia đình anh đang sửa nhà, chỉ cần đưa file PDF bản vẽ thiết kế vào Astra là nó dựng ra cả một mô hình 3D của bản sửa nhà mà bạn có thể đi xuyên qua, và theo anh là chính xác hoàn toàn. Người đó còn quyết định thay đổi vài thứ dựa trên mô hình ấy. Akshay nói việc nó đã vượt qua khoảng cách, từ một tool cho power user thành thứ mà ai cũng có thể dùng để nâng cuộc sống của mình lên, là điều rất đáng kinh ngạc.

3. Thiết kế cho knowledge work: bớt đi thì hơn, từ script tới con trỏ

Nate hỏi về những khác biệt trong thiết kế và interface: hai người đã phải nghĩ khác đi thế nào khi bắt đầu build cho cái mà anh tạm gọi là những "non-verifiable domains" trong không gian knowledge work? (câu hỏi của Nate trong video đăng ngày 22/09/2026)

Akshay đáp rằng với knowledge work, anh và đồng nghiệp ở OpenAI thật sự thấy "less is more", bớt đi thì hơn (theo video đăng ngày 22/09/2026). Càng giấu được bớt chi tiết chính xác agent đang làm gì, mà vẫn đưa ra đủ để mọi người tin rằng nó đang cho ra kết quả đúng, thì sản phẩm càng dễ tiếp cận với mọi người.

Andrew lấy khả năng computer use, mà anh gọi là thật sự state-of-the-art, làm ví dụ (theo video đăng ngày 22/09/2026). Anh nói anh và nhóm luôn làm được một mức computer use nào đó. Khi nó chỉ là một tool cho developer, nhóm có thể cho hiện ra luôn các script đang chạy để làm computer use: nếu nó sắp click quanh một app, nhóm có thể cho xem script nó đang chạy, các selector nó đang click vào, những thứ kiểu như vậy.

Khi chuyển sang phục vụ một lượng người dùng lớn hơn, theo Andrew (video đăng ngày 22/09/2026), nhóm phải build thêm. Bạn không thể cho người dùng xem script đó. Bạn phải cho họ biết nó đang dùng một app nào đó hay đang dùng trình duyệt, đặt một khung picture-in-picture nhỏ cho thấy nó đang click quanh, và thêm một con trỏ. Anh nói bên dưới thì tất cả đều là coding agent, nên nhóm thêm một con trỏ thân thiện click đi click lại và những thứ tương tự. Nhưng về bản chất, theo anh, nó rất giống nhau ở chỗ model giỏi việc gì.

4. Nate tự nhận đã sai về computer use

Nate nói computer use là một trong những lúc anh phải tự phê bình mình công khai (theo video đăng ngày 22/09/2026). Hồi 2024, 2025, nhìn vào tình trạng của computer use lúc đó, theo anh không ai làm đúng cả: nó còn chập chờn ở bản triển khai anh đã xem.

Giả thuyết của anh khi đó, theo lời anh (video đăng ngày 22/09/2026): nếu bạn dùng máy tính như một con người thì bạn sẽ giỏi dùng nó như một con người; còn nếu bạn dùng nó như một cỗ máy thì bạn sẽ cần một interface mà máy đọc được, bạn sẽ cần một MCP, bạn sẽ cần một API, bạn sẽ cần thứ gì đó để tương tác. Và anh đã đánh giá thấp tiềm năng scaling law của computer use.

Theo Nate (video đăng ngày 22/09/2026), khi computer use đủ tốt thì có một điểm bùng phát rất lớn, không cần MCP, không cần API. Giờ anh thấy mình dùng đủ loại use case bỗng nhiên nhanh và trôi chảy. Anh có thể dùng nó để lục qua một đống giấy tờ phiền phức mà anh không bao giờ truy cập được qua MCP hay API, vì nếu đó là giấy tờ của chính phủ thì bên đó sẽ không build mấy thứ đó. Chuyện đó sẽ không xảy ra. Còn giờ thì việc cứ thế xong, anh tự lo được.

Nate nói đó là một khoảnh khắc "aha" với anh, và cũng với nhiều người đang xem: computer use đã trở nên tốt tới mức đó, nhanh tới vậy (theo video đăng ngày 22/09/2026).

Andrew đáp: nó thật sự là "universal connector", một connector đa năng (theo video đăng ngày 22/09/2026). Có nhiều trường hợp MCP nhanh hơn, tiết kiệm token hơn, nhưng một thế giới mà bạn có MCP cho mọi việc mình làm thì không phải... Nate nói nốt: đó là một thế giới không tồn tại. Andrew đồng ý là Nate nói đúng.

Andrew kể một thời gian computer use với anh và nhóm là một "party trick" gây ấn tượng: nó rất trực quan, trông rất ấn tượng, nhưng để làm việc thật với nó thì khá chậm (theo video đăng ngày 22/09/2026). Giờ thì nó nhanh tới mức đôi khi nhóm không để ý là một agent chạy nền đang dùng nó: nhóm không nhận ra nó đã chuyển từ MCP sang computer use cho đúng một việc không có trong MCP. Chuyện đó cứ thế xảy ra, rồi bạn nhìn lại và thấy "ồ, thú vị thật, nó đã click quanh mà mình không hề để ý". Andrew nói chuyện đó thật điên rồ.

5. Cuộc sống bị "đúc theo hình công việc" và lời hứa "cứ mô tả vấn đề"

Nate nói chúng ta đang gặp một tình huống mà ta tự hỏi: máy tính này là máy tính của tôi, hay thật ra là máy tính của Codex và tôi chỉ có một góc để nói chuyện với nó? (theo video đăng ngày 22/09/2026) Anh nhắc lại cảnh anh dùng Wispr Flow nói với agent, con trỏ chạy khắp các cửa sổ làm user acceptance testing cho thứ anh đang build, còn anh không biết chuyện gì đang diễn ra trong các cửa sổ của mình nữa.

Từ đó Nate hỏi: khi nghĩ về knowledge work và hướng nó đang đi, hai người nghĩ thế nào về cách con người sẽ dùng máy tính so với cách ta sẽ điều khiển agent trong trải nghiệm máy tính? (câu hỏi của Nate trong video đăng ngày 22/09/2026)

Andrew đáp rằng, ở nhiều mặt, chúng ta đã mất hàng chục năm để dựng lên cả một thế giới UI máy tính, app, website, và nó phức tạp hơn nhiều so với những gì bất kỳ ai thật sự muốn để làm mọi việc (theo video đăng ngày 22/09/2026). Bạn cảm thấy điều đó trong đời sống. Anh có hai con, và việc điền các loại form... Nate chen vào: anh có ba con. Andrew nói tiếp: cuộc sống đã trở nên quá "work-shaped", bị đúc theo hình công việc, với mấy thứ này.

Theo Andrew (video đăng ngày 22/09/2026), còn tệ hơn nữa vì các tool đó thường là PDF, hoặc bạn phải gửi fax. Các phòng khám nhi vẫn dùng fax. Mọi thứ đều như vậy, phức tạp hơn nhiều so với những gì ta từng muốn.

Andrew nói có vài khía cạnh mà anh nhìn khoảnh khắc Codex, khoảnh khắc ChatGPT với computer use như một kiểu "hãy quay lại đúng việc mà công nghệ đáng lẽ phải giúp chúng ta" (theo video đăng ngày 22/09/2026): mô tả vấn đề của bạn, mô tả bạn cần giúp gì, rồi nó sẽ click quanh, tìm website, quét file PDF, gửi fax, cất mọi thứ vào đúng chỗ, để sau này trên điện thoại bạn có thể hỏi: "này, mũi vắc-xin uốn ván nhà mình tiêm hồi nào? Kéo cái form này ra và gửi cho trại hè thể thao giúp mình." Với anh, tất cả những chuyện này là để giúp đi qua mớ phức tạp đã được dựng lên suốt hàng chục năm mà kiểu như chưa bao giờ thật sự được xử lý.

Có tiếng nói tiếp: chuyện đó chưa bao giờ được xử lý, và tính trung bình thì nó còn tệ đi mỗi năm. Có tiếng nói thêm: giờ không còn phải nghĩ hai lần trước khi nhờ Codex làm việc đó nữa (theo video đăng ngày 22/09/2026).

6. Connector và plugin: bước ngoặt trong khoảng sáu tháng

Nate nói anh có cảm giác đây không chỉ là bài toán trí tuệ mà còn là bài toán integration và dữ liệu sẵn có (theo video đăng ngày 22/09/2026). Anh hỏi hai người đã nghĩ thế nào khi bước qua cây cầu đó, khi mở máy tính ra vượt khỏi computer use, với những integration email, integration Slack và các thứ khác mà OpenAI đã làm. Nhìn về phía trước, hai người coi phần integration là cơ bản đã xong vì computer use giờ đã tốt như vậy, hay vẫn muốn đầu tư rất mạnh vào đó vì có thêm năng lực khi đầu tư vào các integration sâu?

Akshay trả lời rằng trong một thời gian dài, ChatGPT đã có connector, plugin, gọi là gì cũng được, nhưng model không phải lúc nào cũng giỏi dùng chúng nhất (theo video đăng ngày 22/09/2026). Theo anh, trong khoảng sáu tháng qua, giống hệt computer use, bỗng có một điểm lật. Bỗng nhiên mọi người kiểu "trời ơi, phải bảo đảm nó truy cập được vào mọi thứ mà ai đó muốn cho nó truy cập", vì mỗi connector hay plugin thêm vào đều nhân sức mạnh của sản phẩm lên.

Akshay kể anh và nhóm tập trung rất nhiều vào latency, reliability và những thứ tương tự, để khi model dùng một connector thì (theo video đăng ngày 22/09/2026):

• A, nó truy cập được nhiều tool nhất có thể trong số những tool mà các server bên thứ ba cung cấp; nhóm phản ánh lại tất cả các tool đó (theo video đăng ngày 22/09/2026).
• B, các connector hoạt động, và hoạt động ổn định (theo video đăng ngày 22/09/2026).
• C, chúng nhanh và tiết kiệm token (theo video đăng ngày 22/09/2026).

Akshay nói anh và nhóm sẽ tiếp tục làm như vậy, nhưng ở những chỗ có thể làm một connector tốt hơn cho những sản phẩm cụ thể thì tại sao không, vì như thế là trao thêm sức mạnh cho model (theo video đăng ngày 22/09/2026).

7. Thói quen ở OpenAI: thử trong Codex hoặc ChatGPT trước đã

Nate hỏi về chuyện dogfooding ở nội bộ mà hai người vừa mô tả: hai người đã thấy hình dạng công việc bắt đầu thay đổi thế nào? Đâu là thứ mà ở nội bộ hai người coi là một thói quen để thành thạo, một thói quen học tập, hay điều gì đó đã thật sự có ích bên trong công ty, mà hai người muốn mọi người biết? (câu hỏi của Nate trong video đăng ngày 22/09/2026)

Akshay nói, ít nhất với riêng anh, mẹo cá nhân là: cứ thử đi (theo video đăng ngày 22/09/2026). Bạn tới chỗ làm, hay đang ở nhà, ở đâu cũng được, nhìn vào máy tính và có việc cần làm: "ồ, mình cần cập nhật một bài thuyết trình", hay "mình cần gửi email cho ai đó", hay cần làm gì đó. Phản xạ tự nhiên của bạn sẽ là bắt tay vào làm luôn. Điều rất quan trọng trên hành trình của anh là tự nói: "không, mình sẽ không làm thế, mình sẽ thử nó trong Codex hoặc ChatGPT".

Theo Akshay (video đăng ngày 22/09/2026), bước đầu tiên đó, đi từ chỗ tự làm mọi thứ sang chỗ bắt đầu bằng automation, là một khoảng cách lớn.

Andrew kể anh và đồng nghiệp đã dựng môi trường làm việc ở OpenAI theo kiểu rất "native" với Codex và ChatGPT, nên nhìn chung toàn bộ mọi thứ chạy được (theo video đăng ngày 22/09/2026). Nhóm vẫn dùng các tool bên thứ ba bình thường cho khá nhiều việc; không phải nhóm đã biến mọi thứ thành của mình, nhưng nhóm bảo đảm chúng được kết nối tốt.

Vì vậy, theo Andrew (video đăng ngày 22/09/2026), khi mọi người hỏi những câu như "sao mình lại làm việc này theo cách đó?" hay "làm sao kết nối tới thứ này?", câu trả lời thường là: cứ nói chuyện với nó đi, bấm nút voice, đi hỏi nó. Anh thấy rất thú vị khi bạn có thể cắt xuyên qua mớ nhiễu, Slack, Google Documents, mọi thứ mà mọi người đã làm, để có được bức tranh đầy đủ.

Andrew nói ở OpenAI giờ ai cũng dùng Codex hoặc "ChatGPT work" cho phần lớn công việc của mình, nhưng có một thời điều đó chưa đúng (theo video đăng ngày 22/09/2026). Có một giai đoạn, anh nói là khoảng nửa đầu năm nay, khi từng bộ phận một thực hiện bước chuyển lớn sang cách làm việc đó.

8. Từng bộ phận "lật": coding, legal, rồi tới finance

Theo Andrew (video đăng ngày 22/09/2026), với mỗi bộ phận, điểm lật lại hơi khác một chút. Coding hiển nhiên là bộ phận đầu tiên. Có tiếng hỏi: rồi ai thứ hai nhỉ? Có tiếng đáp: nghe nói legal theo sát ngay sau. Có tiếng nói legal lên sớm, vì có rất nhiều tài liệu.

Andrew giải thích đó là sự kết hợp giữa việc model giỏi loại việc nào vào lúc nào, và cả loại connector, quyền truy cập file mà bộ phận đó có: ngữ cảnh của bạn trông như thế nào (theo video đăng ngày 22/09/2026). Coding là dễ nhất vì mọi thứ chỉ là CLI chạy local. Bạn không cần một Git connector, bạn cần Git CLI, bạn cần GH CLI. Anh nói hồi tháng 1, tháng 12 gì đó, nhóm chưa có câu chuyện connector nào ra hồn, nhưng bạn vẫn code được với nó.

Rồi tới legal: theo Andrew (video đăng ngày 22/09/2026), legal có tài liệu Microsoft nằm local khắp nơi, và model đọc được chúng. Rồi trong nửa đầu năm, connector trở nên thật sự tốt, rồi computer use trở nên thật sự tốt. Tuỳ vào ngữ cảnh mà mỗi vai trò cần, khi đạt tới khối lượng tới hạn, nó đẩy vai trò đó qua mép.

Có tiếng chốt lại: đó là lúc ngữ cảnh liên quan tới vai trò ấy trở nên sẵn có rộng rãi ("generally available"), và một câu chen thêm: sẵn có cả về hiệu năng (theo video đăng ngày 22/09/2026). Andrew nói thật ra điều quyết định là chuyện đó, hơn là những thứ thông thường người ta hay nghĩ, như một vai trò có kỹ thuật tới đâu.

Nate nói đó là một ý rất hay (theo video đăng ngày 22/09/2026). Một trong những điều anh rút ra là: câu hỏi một vai trò có mang tính kỹ thuật hay không ngày càng ít hữu ích với anh.

Akshay kể đó là một trong những thứ rất thú vị anh thấy trong vài tuần qua (theo video đăng ngày 22/09/2026). Anh đã nói chuyện, dành thời gian với những người ở team finance và các team business. Ở vài chỗ, các team này đang bỏ Excel để tạo ra những ChatGPT site, về thực chất là các app, rồi chia sẻ chúng trong team, lặp lại theo thời gian, làm ra phiên bản mới và cập nhật cho những use case mới. Theo anh, xét về mọi mặt, những người này là developer trong mảng đó.

Akshay nói những người ấy không có nhiều tool, và điều đó làm anh hơi lo: các team này không có những tool mà anh và đồng nghiệp có để công việc dễ hơn, như Git hay version control; các team đang "YOLO" với những gì anh và nhóm cung cấp (theo video đăng ngày 22/09/2026). Vì thế còn rất nhiều thứ phải build để cuộc sống của các team ấy dễ hơn. Nhưng bản thân việc giờ các team làm được chuyện đó, theo anh, đã rất tuyệt.

9. Site như một loại artifact mới, và ai cũng có khách hàng

Nate nói chuyện site rất thú vị; anh biết OpenAI đã đầu tư rất nhiều vào mảng này trong khoảng một hai tháng qua (theo video đăng ngày 22/09/2026). Anh hỏi: nhìn vào knowledge work và nơi knowledge work diễn ra, site có giống một đòn bẩy đa dụng mới và lớn cho knowledge work không?

Akshay đáp rằng có ý tưởng về những artifact được tạo ra (theo video đăng ngày 22/09/2026). Theo anh, trong lịch sử có doc, slide, sheet, PDF và những thứ tương tự. Với AI, có thể trong tương lai sẽ có một artifact mới mang tính AI native.

Theo Akshay (video đăng ngày 22/09/2026), site làm rất tốt ở chỗ: đôi khi thứ bạn muốn diễn đạt không vừa khít với ô nào trong các ô đó. Có thể nó cần tương tác, có thể nó cần tồn tại lâu dài theo cách nào đó. Và có thể vì bạn "không rành kỹ thuật" (anh nói "quote-unquote non-technical"), bạn thậm chí không biết điều đó. Bạn biết các yêu cầu, nhưng không diễn đạt chúng theo cách một kỹ sư sẽ làm. Nhưng, như Andrew nói, bạn chỉ cần mô tả vấn đề của mình cho model và nó có thể tạo ra application đó cho bạn.

Akshay nói site lấp vào khoảng trống: bạn không bao giờ làm được việc này trong một sheet, một doc hay một bộ slide, nhưng giờ thì làm được (theo video đăng ngày 22/09/2026). Vì vậy anh nghĩ với knowledge work, nó cho phép mọi người diễn đạt phong phú hơn nhiều so với trước, và đó sẽ là một bước mở khoá rất lớn.

Nate nói trong hầu hết tình huống, hầu hết vai trò công việc, đều có một mức độ lặp lại nào đó (theo video đăng ngày 22/09/2026). Anh tò mò hai người đã thấy hành vi người dùng khác nhau tới đâu giữa người làm việc với ChatGPT work và người dùng Codex: người ta bắt đầu dùng một workflow có nhịp điệu, lặp lại nhiều hơn, so với một workflow phát triển hướng tới mục tiêu, nơi bạn chỉ cần đưa code lên production và nó phải được ship.

Có tiếng trả lời: hai kiểu này chắc chắn giống nhau hơn so với trước; trong mấy năm qua, phát triển phần mềm đã trở nên lặp lại nhiều hơn. Có tiếng đáp: "That's a fair point." (theo video đăng ngày 22/09/2026)

Andrew nói tiếp: nếu gọi đó là vòng đời phát triển sản phẩm, thì vòng đời của một tool nội bộ được build dưới dạng ChatGPT site trông rất giống best practice khi bạn đưa một thứ gì đó tới khách hàng (theo video đăng ngày 22/09/2026). Giờ ai cũng đang đưa ra thứ gì đó cho một kiểu khách hàng nào đó. Ví dụ, bộ phận HR có thể làm một site để giúp anh và đồng nghiệp xác định nhân tài, và anh cùng đồng nghiệp là khách hàng của sản phẩm mà HR duy trì. Ai cũng bắt đầu duy trì một sản phẩm chứa đựng loại chuyên môn của mình, cho một nhóm người dùng khác.

Theo Andrew (video đăng ngày 22/09/2026), trong nhiều trường hợp chu kỳ của các nhóm này nhanh hơn vì người dùng nội bộ ít hơn: các nhóm này không phải lo tương thích ngược với một tỷ người dùng ChatGPT. Đôi khi các nhóm này còn dạy cho các developer phần mềm ở OpenAI một bài học: bạn cứ thế mà lặp. Andrew thêm: tất nhiên, là vì bạn không có một tỷ người dùng. Nate nói đó cũng là một ý thú vị.

10. Nên đặt cược vào kỹ năng nào

Nate hỏi: chúng ta nên đặt cược vào điều gì về mặt kỹ năng? Nên đặt cược vào những đường xu hướng nào mà ta có thể theo dõi, tiếp tục kỳ vọng sẽ tốt lên, và đủ dễ đoán để nói rằng trong sáu tháng nữa X hay Y sẽ tốt hơn nhiều? (câu hỏi của Nate trong video đăng ngày 22/09/2026)

Akshay trả lời rằng việc tạo ra những sản phẩm công việc này, tạm gọi như vậy vì không có từ nào tốt hơn, như site, tool, tài liệu hay bất cứ thứ gì, sẽ tiếp tục cải thiện năng lực của model trong việc làm ra chúng, và trên nhiều chiều (theo video đăng ngày 22/09/2026):

• Thứ nhất là chất lượng của output (theo Akshay, video đăng ngày 22/09/2026).
• Thứ hai là khả năng hiểu ý định thật của bạn, bạn thật sự muốn nói gì (theo Akshay, video đăng ngày 22/09/2026).
• Khả năng kéo ngữ cảnh vào, trích nguồn chính xác, và những thứ tương tự (theo Akshay, video đăng ngày 22/09/2026).

Akshay nói tất cả những thứ đó sẽ tốt lên rất nhiều (theo video đăng ngày 22/09/2026). Điều đó có nghĩa là nút thắt của bạn sẽ là ý tưởng: khả năng nghĩ xem nên làm gì tiếp, để agent đưa ra một thứ gì đó, rồi, như Andrew nói, kiểm chứng xem nó có hữu ích không, với chính bạn hoặc với những người bạn làm cùng, rồi quay lại agent và lặp tiếp.

Theo Akshay (video đăng ngày 22/09/2026), kỹ năng làm việc với agent là thứ sẽ không đổi, và câu hỏi là bạn có tiếp tục giỏi lên ở đó được không. Bạn có thể giả định mỗi vòng lặp chất lượng sẽ tốt hơn, có thể chu kỳ lặp ngắn lại, và rồi bạn làm được mười việc song song trong khi trước đây chỉ làm được năm, và cứ thế.

Andrew nói mặt kia của chuyện này là làm ra mọi thứ đã trở nên dễ tới mức taste và convergence là một nút thắt khác mà anh và nhóm đôi khi gặp: có quá nhiều thứ được làm ra tại bất kỳ thời điểm nào (theo video đăng ngày 22/09/2026). Nhóm muốn ship một sản phẩm tập trung, gắn kết và mạch lạc nhất có thể để giúp mọi người giải quyết việc của họ.

Câu hỏi với Andrew, theo lời anh (video đăng ngày 22/09/2026), là: làm sao lấy cái thứ trông hay ho ở đằng kia, ba thứ này, thứ kia và thứ nọ, ghép lại với nhau, nặn nó thành một thứ có lý, mạch lạc với mọi người, có gu? Vì ngày nay bạn có thể ship bất cứ thứ gì, nhóm có thể ship mọi sản phẩm từng có. Có tiếng chen vào: làm được thì đúng, còn có nên làm không lại là câu hỏi khác. Andrew nói đó là chuyện thật sự phải có sự rõ ràng trong suy nghĩ: điều gì là thứ ta thật sự cần làm ở đây?

11. Busy work biến mất, câu hỏi dội lại chính mình

Nate nói cả hai người đều nhắc tới những kỹ năng tư duy: một người nói về sự thành thạo khi làm việc với agent, một người nói về việc ra quyết định và cách đưa ra quyết định tốt với gu tốt (theo video đăng ngày 22/09/2026).

Nate kể một điều anh đang suy ngẫm (theo video đăng ngày 22/09/2026): hồi còn ở giai đoạn đầu sự nghiệp, hiển nhiên có những việc đòi hỏi trí tuệ nghiêm túc mà anh phải làm, nhưng cũng có rất nhiều busy work, việc vặt lấp đầy cả ngày. Giờ phần lớn số đó đã biến mất: busy work là thứ anh có thể giao cho agent và nó cứ thế được làm xong.

Nhưng theo Nate (video đăng ngày 22/09/2026), điều đó có nghĩa là câu hỏi dội ngược lại chính anh: mình đang làm gì với thời gian của mình? Mình đang tận dụng tối đa agency của mình thế nào? Mình có ý tưởng để đưa cho AI thứ nó cần không? Mình đang ra những quyết định có gu, hay đang đẩy ra "slop"? Anh có cảm giác đó là câu hỏi mà tất cả chúng ta đều đang bị đặt ra.

Andrew nói có một chút khó chịu khi phải liên tục tái tạo lại bản thân hết lần này tới lần khác (theo video đăng ngày 22/09/2026). Đồng thời, anh lớn lên vừa là software engineer vừa là designer, và luôn có những thứ anh thấy trong đầu, muốn làm ra, nhưng vượt quá trình độ của anh ở phía engineering. Anh thấy phần nào được giải phóng khi có thể làm ra mọi thứ mà không cần busy work.

Có tiếng nói tiếp: bản thân busy work không có ý nghĩa gì; ý nghĩa nằm ở thứ mà bạn tạo ra (theo video đăng ngày 22/09/2026).

12. Token efficiency: lật vai orchestrator và executor

Nate hỏi hai người nghĩ thế nào về token efficiency (theo video đăng ngày 22/09/2026). Anh có cảm giác khoảng tháng 4 gì đó, "token maxing" là thứ đang thịnh, ai cũng nói về token maxing và các bảng xếp hạng token, còn giờ con lắc đã đung đưa ngược lại.

Nate kể anh đang rất vui với việc đảo ngược những giả định quen thuộc (theo video đăng ngày 22/09/2026). Giả định quen thuộc là chọn model thông minh làm orchestrator và model "kém thông minh" làm executor. Anh thì thử đảo lại: để Luna làm orchestrator ở mức extra high, và để Astra làm executor với các subagent.

Theo lời Nate (video đăng ngày 22/09/2026), thỉnh thoảng anh dùng thêm một model Astra khác để "chọc" Luna về chuyện agency và về chuyện đừng thu hẹp phạm vi thứ anh đang build, nhưng model này không nhận toàn bộ context window, nên nó không ngốn hết số token đó. Còn thread orchestration chạy rất dài thì nằm ở Luna. Anh thấy cách này tiết kiệm token cực kỳ, mà vẫn đưa anh đi được một quãng dài tới chỗ anh muốn. Anh hỏi hai người đã nghe về cách này chưa, có bất ngờ không, và có mẹo nào khác để tiết kiệm token không.

Andrew nói anh đã nghe về cách này, và nghe ngày càng nhiều khi áp lực này tăng lên (theo video đăng ngày 22/09/2026). Không phải vì trước đây mọi người không nhận ra mình nên tiết kiệm token, mà vì khi model ngày càng lớn, nó đẩy bạn phải tiết kiệm token hơn trên mỗi đơn vị đầu ra.

Theo Andrew (video đăng ngày 22/09/2026), anh và nhóm đã thấy những bước nhảy thật sự về hiệu quả ở Astra: có những trường hợp Astra hiệu quả hơn các model trước đó của nhóm tới cả một bậc độ lớn, và điều đó thật tuyệt. Phần "code mode" cho computer use còn làm nó tốt hơn nữa.

Andrew nói anh và nhóm cũng đang cố lấy một vài điều Nate vừa mô tả, kiểu "tôi có một setup multi-agent, chọn model này cho việc này, model kia cho việc kia", và đưa thêm một phần vào cách model hoạt động theo mặc định (theo video đăng ngày 22/09/2026). Nate đáp anh hiểu. Andrew nói nhóm muốn mang điều đó tới tất cả mọi người.

Akshay nói thêm rằng, như Andrew đã nhắc, anh và nhóm đã làm rất nhiều việc ở các chi tiết: bảo đảm các skill mà anh và nhóm publish là tiết kiệm token nhất cho model, bảo đảm harness và cách nó dùng computer use, với những thứ như code mode, chạy theo cách dùng ít token nhất có thể (theo video đăng ngày 22/09/2026). Đó là việc nhóm muốn tiếp tục đẩy mạnh theo thời gian.

13. Đo chi phí trên một đơn vị công việc, và bản báo cáo 9 giờ sáng

Akshay nói việc Nate để Astra lo phần thực thi không làm anh bất ngờ (theo video đăng ngày 22/09/2026). Một điều anh và nhóm thấy là: nếu chỉ đo token trên mỗi đơn vị thời gian thì đó không phải thước đo chính xác bạn nên nghĩ tới, kể cả khi bạn là một người dùng để ý chi phí, vì cái bạn thật sự muốn đo là bạn đã chi bao nhiêu để làm xong đơn vị công việc bạn muốn hoàn thành. Nate chen vào: "The outcome". Akshay đáp: "Exactly."

Theo Akshay (video đăng ngày 22/09/2026), dù Astra có thể đắt hơn nếu tính theo từng token, nó lại hiệu quả hơn nhiều. Điều anh và nhóm muốn làm là tìm cách để mọi người kiểm chứng được điều đó, như ROI, chứ không nhất thiết chỉ đo đã tiêu bao nhiêu token rồi nhân với giá.

Nate kể anh gặp những người nói: nhân viên của tôi dùng nó cho email, dùng nó như một answer engine, dùng nó để code; rồi có một khoảng ngừng dài, và bạn được kỳ vọng sẽ điền vào: "và việc tiếp theo là..." (theo video đăng ngày 22/09/2026). Anh hỏi: làm sao build một sản phẩm tập trung vào kết quả trong một thế giới mà người làm knowledge work có thể không diễn đạt rõ được kết quả họ muốn ngay từ đầu, nhưng có thể đi tới đó theo thời gian?

Andrew kể anh hay dùng nó để đi qua dữ liệu, tìm những nhóm người dùng chưa thật sự giữ chân được trên sản phẩm, hoặc chưa được onboard đủ nhanh, và để nó cho anh sự rõ ràng về những nhóm đó (theo video đăng ngày 22/09/2026). Trước đây đó là những việc mất nhiều ngày: tìm bảng dữ liệu, viết câu SQL, dựng dashboard rồi nhận ra "ồ không, câu query sai rồi, nó chẳng nói gì với mình", nên phải quay lại làm lần nữa. Còn giờ anh có thể nhận một bản báo cáo kiểu "đây là một vùng cơ hội cho chúng ta", và chia sẻ nó với team.

Theo Andrew (video đăng ngày 22/09/2026), anh và nhóm thử rất nhiều để xem có thể đẩy nó vào những mảng khác nhau thế nào, và không phải lúc nào nó cũng sẵn sàng; nhóm làm vậy nhiều để nghiên cứu xem có thể đưa gì thành sản phẩm. Anh nhận ra mọi người không có thời gian để thử nghiệm với nó như nhóm, nên nhóm phải đưa một phần vào sẵn bên trong. Ví dụ, hôm trước nhóm vừa phát hành một data plugin giúp với nhiều câu hỏi về dữ liệu kiểu này, thật sự làm gọn cách làm báo cáo và những việc tương tự.

Andrew nói đây là điều nhóm muốn thử nghiệm: nếu model biết cách trả lời bất kỳ câu hỏi nào bạn gõ vào, thì bạn không cần phải hỏi từng câu một (theo video đăng ngày 22/09/2026). Anh và nhóm nên có thể đưa cho bạn một bản báo cáo lúc 9 giờ sáng: "đây là những thứ bạn chưa hỏi. Việc của bạn là retention, và bạn chưa hỏi gì về những nhóm này, nhưng thật ra chúng là một điểm mù rất lớn của bạn." Có tiếng chen vào: những nhóm đó đang churn, và câu ấy được nhắc lại. Có tiếng nói: đó là loại việc cần làm cho đúng ở bước tiếp theo.

14. Proactivity đặt ngưỡng cao hơn, và voice như một interface

Nate nói proactivity giống như lấy bài toán ngữ cảnh rồi bơm cho nó thật to, vì khi đó bạn không chỉ phải tự tin về ngữ cảnh, mà còn phải tự tin về insight, tự tin về hướng của insight, và tự tin về chính mức độ tự tin của mình (theo video đăng ngày 22/09/2026). Như vậy khi lên tiếng nói một điều gì, bạn có thể nói: "tôi biết điều này đúng vì X, Y và Z, và vì thế tôi đề xuất hành động C". Nate nói chuyện này rất thú vị.

Andrew nói đây là mảng phải cẩn thận, nhất là với chuyện hiệu quả (theo video đăng ngày 22/09/2026). Bạn không thể chạy thứ này và cứ thế inference suốt đêm, inference cực kỳ đắt trong 12 tiếng lúc người dùng đang ngủ, rồi ngốn hết hoá đơn sử dụng của ai đó để đổi lấy ba insight tệ hại kiểu spam. Anh nói đó là điều anh và nhóm đang nghĩ rất nhiều và muốn làm cho đúng.

Có tiếng nói tiếp: chuyện token efficiency nằm ở đây, chuyện chọn model chắc chắn cũng nằm ở đây; và ngưỡng chất lượng mà ta phải đạt nhìn chung cao hơn khi người dùng chưa hỏi rõ ràng (theo video đăng ngày 22/09/2026).

Nate nói voice dĩ nhiên là một interface (theo video đăng ngày 22/09/2026). Anh hỏi: khi nghĩ về năng lực model, computer use và hướng đi của những thứ này, hai người đang chú ý tới những xu hướng nào trong thiết kế interface, khi nghĩ tới chỗ mà Codex hay công việc có thể được thể hiện trong khoảng một năm tới, những thứ mà bây giờ ta còn chưa nghĩ tới?

Akshay nói vì Nate đã nhắc tới voice, anh nghĩ đó là thứ đáng nêu ra (theo video đăng ngày 22/09/2026). Theo anh, đây là một chỗ mà những người dùng sớm đi trước mọi người khác rất xa. Khi đi quanh văn phòng, anh thấy có người để tới sáu cái mic khác nhau trên bàn, và đó là cách họ giao tiếp với Codex hoặc ChatGPT work cả ngày. Nhưng điều đó rõ ràng chưa tới được với tất cả mọi người.

Theo Akshay (video đăng ngày 22/09/2026), một phần lý do là sản phẩm cần làm tốt hơn nhiều để mọi người phát hiện ra khả năng này có tồn tại. Một phần khác là anh và nhóm cần đưa mọi người đi cùng trong việc chuyển từ gõ phím hay chạm sang nói, và cho họ thấy cách đó trôi chảy, ít ma sát hơn bao nhiêu như một interface. Anh nói nhóm còn rất nhiều việc phải làm để khiến nó có cảm giác là thứ tiếp theo: Codex hay ChatGPT đi cùng bạn mọi nơi, vì bạn có interface giọng nói này.

Akshay nói những người hiểu thì thật sự hiểu, nhưng anh và nhóm chưa làm đủ để cho mọi người thấy điều đó là khả thi (theo video đăng ngày 22/09/2026). Vì vậy, thậm chí trước cả chuyện build một interface hoàn toàn mới, theo anh voice là thứ nhóm đã có sẵn, và câu hỏi là làm sao mang nó tới tất cả mọi người.

Andrew nói mặt thú vị còn lại của voice là: voice là cách hiệu quả nhất, bỏ xa các cách khác, để đưa ngữ cảnh vào và để truyền đạt thông tin, nhưng đọc thì nhanh hơn nghe nhiều (theo video đăng ngày 22/09/2026).

15. Voice vào, hình ảnh ra; hỏi đúng câu, đúng thiết bị

Có tiếng đáp "That's right". Andrew nói vì vậy anh thấy rất thú vị khi thử kết hợp voice ở đầu vào với hình ảnh được tạo ra (generative visuals) ở đầu ra (theo video đăng ngày 22/09/2026). Anh và nhóm đã làm một chút với "visualized skill" và generative UI của OpenAI, nhưng anh không nghĩ nhóm đã làm được gì lớn ở mảng này.

Theo Andrew (video đăng ngày 22/09/2026), có rất nhiều lúc anh muốn nói vào sản phẩm này, vào model này, đưa ngữ cảnh vào với tốc độ mà anh không gõ kịp, nhưng không muốn nó nói lại với anh, mà muốn nó cho anh xem mọi thứ và hỏi anh các câu hỏi. Anh nói anh là người rất thiên về hình ảnh, nên nhóm cũng đang xem xét khá nhiều hướng như vậy.

Andrew nói còn nhiều việc phải làm ở đây (theo video đăng ngày 22/09/2026). Mức tương tác cần thiết không phải lúc nào cũng như nhau. Khi nghĩ về những thứ như token efficiency, đôi khi chỉ một câu hỏi có thể gỡ nút cho cả một lượng lớn token và cho ra kết quả tốt hơn nhiều, chỉ cần vài câu hỏi làm rõ. Anh nói bạn sẽ thấy Astra hỏi nhiều câu hơn các model trước.

Nhưng khi tác vụ kéo dài, theo Andrew (video đăng ngày 22/09/2026), cần có khả năng gửi câu hỏi tới các thiết bị khác nhau mà bạn có. Anh kể người ta nói về chuyện code ở sân chơi trong khi con mình chơi ở sân chơi; anh thì không thích ý đó lắm, anh muốn dành thời gian cho con. Nate đáp: "You want to be spending time with the kids, yeah."

Andrew nói nhưng cũng rất bực khi quay lại bàn làm việc và thấy một việc được làm theo cách không sai, nhưng một câu hỏi là đã có thể làm nó tốt hơn (theo video đăng ngày 22/09/2026). Cứ gửi cho anh câu hỏi có hoặc không trong lúc anh ra ngoài; anh sẽ trả lời nhanh và gỡ nút cho nó, giống như đôi khi ai đó nhắn bạn một tin Slack để được gỡ nút. Anh nói nhóm sẽ làm thêm ở mảng đó.

Nate nói đó là một ví dụ nữa của kiểu proactivity thông minh: học cách hỏi đúng câu (theo video đăng ngày 22/09/2026). Anh kể một pattern khác trong workflow mà anh nhận ra ở bản thân: anh ngày càng đọc nhiều các message trung gian được in ra, và anh nắn rất mạnh tay lượt chạy của agent khi thấy các message đó dần thành hình.

Theo Nate (video đăng ngày 22/09/2026), đôi khi anh trả lời trực tiếp: "không, không, không, sai rồi, làm chỗ này khác đi". Đôi khi anh lấy một bản in ra giữa chừng lượt chạy, đưa cho một agent khác và nói: "cái này mình thấy không hợp lý lắm, bạn nhìn lại bằng con mắt mới được không?". Và vì các lượt chạy đủ dài, anh có thể vòng lại và nói: "được rồi, đây là cách mình nghĩ ta nên làm tiếp".

Nate hỏi: hai người có thấy hoạt động chen vào giữa công việc của agent là một nhóm hành vi đang nổi lên trong số đông người dùng không, hay đó chỉ là anh kỳ quặc vì là power user? Kinh nghiệm của hai người thế nào? (câu hỏi của Nate trong video đăng ngày 22/09/2026)

16. Chen vào giữa một lượt chạy, và cái sai có ích

Akshay nói anh nghĩ khi phạm vi việc mà agent có thể nhận ngày càng lớn, cả về giá trị lẫn thời gian nó cần để làm, thì nhóm thật sự cần làm thật tốt trải nghiệm ngắt hoặc chen vào giữa một lượt rollout (theo video đăng ngày 22/09/2026). Không chỉ cho những trường hợp Nate vừa tả, khi agent có thể đang làm sai, mà cả khi chính người dùng sai.

Akshay kể anh đã gặp nhiều lần: anh nhờ nó làm một việc, rồi 20 phút sau anh mới thấy "khoan đã", đó hoàn toàn không phải thứ anh muốn, và anh phải quay lại sửa (theo video đăng ngày 22/09/2026). Theo anh, việc đó cần thật trôi chảy, và đó là chỗ nhóm cần đầu tư thêm. Nhưng chắc chắn đó là điều nhóm đang thấy: mọi người bắt đầu học được rằng đây là quan hệ hai chiều suốt cả quá trình, không chỉ là hỏi, đáp, hỏi, đáp. Anh nghĩ interface còn có thể làm nhiều hơn nữa để làm rõ điều đó.

Nate nói điều đó rất hợp lý (theo video đăng ngày 22/09/2026). Anh kể thêm một pattern anh nhận thấy ở bản thân, nối lại với chuyện công việc lặp lại đã bàn ở trước: một trong những cách mà anh, và những người khác anh từng nói chuyện, thật sự làm việc với AI là dùng AI gần giống như một cỗ máy tạo ý tưởng kiểu quả bóng nảy. Bạn cứ nảy qua nảy lại: "không, không phải cái đó, nhưng mình đã không nghĩ ra điều đó; không, không phải cái đó; ồ, đúng nó rồi".

Theo Nate (video đăng ngày 22/09/2026), bạn phải đi qua một loạt câu "không", và chính những câu "không" giúp làm rõ ý định của bạn. Anh không biết đã có interface nào cho việc này chưa, nhưng với anh đó là một chế độ rất khác so với chế độ "làm xong việc" khi anh đã có ý định rõ ràng, và anh cần cả hai tuỳ tình huống: một bên là "mình có hiểu mình muốn gì không?", bên kia là "được rồi, giờ làm cho xong".

Andrew kể anh vừa có một cuộc nói chuyện rất giống vậy, hình như là hôm qua, về ý tưởng ngẫu nhiên hay nhiễu (theo video đăng ngày 22/09/2026). Đó là một tham số bạn có thể chỉnh nếu đang dùng mọi núm vặn trên API. Nhưng nếu lùi ra xa và nói "tôi có kế hoạch này muốn đạt được", dù là với một model hay với cả một công ty gồm nhiều người, thì có một mức nhiễu, dao động và thử nghiệm mà bạn chấp nhận, nằm đâu đó giữa con số không và sự hỗn loạn, vì bạn biết nó thật ra giúp tối đa hoá, tối đa hoá toàn cục, để bạn không bị kẹt ở một cực đại cục bộ.

Theo Andrew (video đăng ngày 22/09/2026), đó là vì bạn có một chút khoảng chơi, kiểu "à, mấy người bên kia đang thử một thứ mới mà có khi là phí công". Anh thấy rất giống vậy với các model: anh muốn chúng làm theo chỉ dẫn, nhưng có một chút khoảng chơi, để khi nói chuyện về những thứ này, đúng là có thể mất lâu hơn một chút, tốn thêm một chút, nhưng nó đi ra ngoài được cái dải hẹp. Anh không biết chính xác điều đó trông ra sao, nhưng anh đồng ý với Nate về điểm này. Nate nói điều đó có tiếng vang với anh.

17. Từ năng suất cá nhân tới năng suất của cả team

Nate nói anh sẽ thiếu sót nếu không hỏi, vì anh được giới lãnh đạo hỏi câu này rất nhiều khi triển khai AI trong một tổ chức (theo video đăng ngày 22/09/2026). Gần như lúc nào vài tháng đầu cũng là: có nhóm A đang dùng và cực kỳ đam mê; có nhóm B cũng đang dùng, đang tìm hiểu dần; còn nhóm C thì kiểu "tôi không biết, cái này là gì?".

Theo Nate (video đăng ngày 22/09/2026), khi nói về nhóm A, những người dùng đầy đam mê, gần như lúc nào câu chuyện cũng là năng suất cá nhân, và câu tiếp theo anh bị hỏi là: còn team thì sao? Nên câu hỏi của anh: khi nghĩ về việc AI đã đẩy các bộ phận bên trong OpenAI "lật" qua trong sáu tháng qua, điều đó đã chuyển thành năng suất cấp team, hay khả năng làm được nhiều hơn ở cấp team, như thế nào?

Akshay trả lời rằng trong mọi trường hợp, đó là xác định một quy trình hay một vấn đề mà team của bạn gặp phải, có thể là lặp đi lặp lại, rồi người đó, power user hay người dùng sớm, gì cũng được, lao vào tìm cách làm nó tốt hơn với AI (theo video đăng ngày 22/09/2026).

Akshay kể những "hero case" lớn nhất mà anh và đồng nghiệp thấy là kiểu (theo video đăng ngày 22/09/2026):

• Ai đó nói: "được rồi, cứ hai tuần mình lại phải cập nhật financial model này, mình sẽ biến nó thành một ChatGPT site". Giờ người khác cũng làm được việc đó, và nó diễn đạt phong phú hơn (theo Akshay, video đăng ngày 22/09/2026).
• Hoặc: "mình sẽ tạo một automation đẩy toàn bộ bug của các cohort không giữ chân được (non-retentive) vào Slack". Giờ mọi người trong team đều có thể lấy từ đó (theo Akshay, video đăng ngày 22/09/2026).

Theo Akshay (video đăng ngày 22/09/2026), đó là đi xa hơn việc bạn tạo một output cho riêng mình, sang việc tạo ra thứ mà team bạn nhìn thấy và nhận được giá trị. Với những người lãnh đạo trong tổ chức đang hào hứng triển khai AI, anh nghĩ khi người dùng sớm được khuyến khích làm như vậy, mọi người cũng học theo, vì mọi người học bằng cách nhìn thấy: "ồ, đó là thứ mình cũng làm được". Và mọi người nhận giá trị ngay lập tức, thay vì kiểu tổ chức một buổi training hay thứ gì đó trừu tượng hơn nhiều.

Nate nói điều đó rất có lý, rồi chuyển sang câu hỏi cuối (theo video đăng ngày 22/09/2026). Anh tò mò: khi hai người dùng AI hằng ngày, thì hầu hết những người anh biết đều có một kiểu bài toán "NP-hard", một bài toán mà họ cứ ném AI vào hết lần này tới lần khác, cho tới khi cuối cùng nó vỡ ra: cuối cùng scaling law phát huy tác dụng và có thứ chạy được.

Với Nate, anh kể anh có một khoảnh khắc như vậy khi AI cuối cùng đọc được cả sáu cái lịch của anh và thật sự cho anh biết trong ngày còn trống lúc nào, chứ không phải chỉ đọc hai cái rồi đưa ra những khung giờ trống sai (theo video đăng ngày 22/09/2026). Anh hỏi: với hai người thì đó là gì? Khoảnh khắc thật sự khó ấy là gì, và AI đã vượt qua nó chưa? Hai người đã có lúc nào kiểu "ồ, cái này thật sự khó, mình chưa từng nghĩ AI sẽ làm được, mình nghĩ sẽ còn lâu, vậy mà giờ nó làm được" chưa?

18. Bài toán khó mà AI cuối cùng đã vượt qua

Andrew kể anh có một bài "ruột" mà anh làm mỗi khi có model mới (theo video đăng ngày 22/09/2026). Nó khó vì không chỉ thách thức về kỹ thuật mà còn là bài toán phối hợp: nhóm có một app cross-platform, và anh có giấc mơ rằng một ngày nào đó, với một model đủ mạnh, bạn có thể duy trì được trải nghiệm native tuyệt đối trên mọi nền tảng: trên Mac thì làm kiểu Objective-C UIKit đời cũ, trên Windows 11 thì là WinUI 3.

Theo Andrew (video đăng ngày 22/09/2026), đây là bài toán phối hợp vì nhóm đang đi nhanh tới mức không thể đưa mọi tính năng đi đều bước với nhau trên mọi nền tảng. Nếu nhóm đi với một phần mười tốc độ đó thì chuyện này đã không thành vấn đề lớn, nhưng nhóm dùng cross-platform chính là vì tốc độ. Một ngày nào đó nhóm sẽ quay lại với nó, sẽ có thể viết lại hoàn toàn mọi app bằng đúng thứ hoàn hảo cho từng nền tảng, giữ chúng đi đều bước, làm cả một bản Rust nữa, anh nói anh không biết. Anh nói nhóm chưa tới đó, nhưng đang tới gần hơn rất nhiều.

Andrew kể mỗi lần có model mới, anh lại cho viết lại Codex app: "này, thử làm nó bằng GPUI với Rust xem", rồi xem chuyện gì xảy ra; Nate nhắc lại: rồi xem chuyện gì xảy ra (theo video đăng ngày 22/09/2026). Theo Andrew, Astra đã làm ra được một bản khá tốt, nhiều bản cùng lúc. Có tiếng nói: để xem; và có tiếng đáp: hy vọng vậy ("fingers crossed").

Akshay nói anh xin kể chiều ngược lại: một thứ vừa mới được vượt qua (theo video đăng ngày 22/09/2026). Từ lâu anh đã là người dùng rất sớm của việc kết nối AI với mọi thứ trong đời mình, qua trình duyệt hoặc qua connector. Anh có một automation kiểu "làm sao để tiết kiệm tiền trong cuộc sống của mình?", chạy khoảng hai tháng, và nó chưa bao giờ tìm ra điều gì hữu ích.

Theo Akshay (video đăng ngày 22/09/2026), đó thật ra là một bài toán khá phức tạp, vì nó đi qua email của anh, đăng nhập vào nhiều thứ qua trình duyệt, có vài connector và những thứ tương tự. Có lúc nó gợi ý anh huỷ một subscription hay gì đó, nhưng chỉ vậy thôi. Rồi tuần trước, nó tìm ra một lỗi khá lớn trong hồ sơ thuế của anh. Nate hỏi: có lợi cho anh không? Akshay đáp: có lợi cho anh. Nate: "Ooh."

Akshay kể việc đó giúp anh tiết kiệm được hàng nghìn đô, và anh nghĩ đây là điều anh sẽ không bao giờ tự phát hiện ra (theo video đăng ngày 22/09/2026). Chuyện đó lẽ ra sẽ không bao giờ xảy ra, vì khối lượng phối hợp cần để tìm ra nó là rất lớn: nó phải nhớ một việc xảy ra từ nhiều năm trước và kéo nó lên, cùng mọi thứ liên quan. Với anh, điều đó khá mở mắt. Theo anh, càng đưa nhiều ngữ cảnh, các model đã tới mức vượt xa những gì anh tự làm được, nên anh cần tiếp tục đẩy theo hướng đó trong đời sống cá nhân.

Nate kể một thứ mà Astra đã vượt qua với anh và làm anh bật cười (theo video đăng ngày 22/09/2026). Vài tháng trước anh ở Seattle, Tibo vừa bay lên, anh có nói chuyện ngắn với Tibo, và lúc đó anh nói: "Tibo, làm cho tôi một model biết làm Lego đi", vì anh mê Lego và muốn dựng mô hình. Khi đó nó bị bão hoà ở số mảnh rất ít (anh nhắc tới 50 mảnh, rồi 10 mảnh vào thời điểm đó). Giờ thì anh làm được một bộ Lego 1.000 mảnh, không thành vấn đề.

Có tiếng nói: vượt sang được thế giới vật lý thì thật điên rồ (theo video đăng ngày 22/09/2026). Andrew kể anh nhớ cách đây vài đời model, khi anh làm cuốn sách đầu tiên cho các con, anh phải tự xâu chuỗi các bước với nhau:

• Bạn sẽ viết một kịch bản (theo lời Andrew về cách anh làm cách đây vài đời model, video đăng ngày 22/09/2026).
• Bạn lấy kịch bản đó và viết một prompt sinh ảnh cho từng trang (theo lời Andrew, video đăng ngày 22/09/2026).
• Bạn đưa nó vào API (theo lời Andrew, video đăng ngày 22/09/2026).

Nate nói chuyện đó cũng chưa lâu lắm. Andrew đồng ý là chưa lâu. Và giờ, theo Andrew (video đăng ngày 22/09/2026), bạn chỉ cần nói "làm cho các con tôi một cuốn sách về chính chúng", "mang đi in đi", và nó sẽ làm. Andrew nói khi mọi thứ bước vào đời thật, bạn cầm chúng trên tay. Nate nói: cảm giác khác hẳn; câu đó được nhắc lại, rồi Nate nói: đúng vậy.

Nate cảm ơn hai người đã dành thời gian hôm đó, nói anh thật sự trân trọng và buổi nói chuyện rất vui. Có tiếng đáp lại lời cảm ơn và nói cũng rất vui.