Khi ai cũng có thể build phần mềm

1. Mở đầu: make something agents want

Video mở bằng vài câu của Paul Copplestone: anh thật sự háo hức về những gì tương lai có thể mang lại cho rất nhiều người. Điều anh rất thích ở Supabase là anh thấy rất nhiều người khởi nghiệp nhờ nền tảng này. Anh chắc rằng mọi người trên thế giới có quyền dùng AI sẽ trở thành một kiểu builder nào đó: bạn có thể build bất cứ thứ gì, tùy biến nó, muốn chỉnh một app hay một UI thì không còn phải phụ thuộc vào người khác. Và anh nói anh khá phấn khích về năm 2027 (theo Paul, video đăng ngày 30/10/2026).

Đây là một tập Lightcone, podcast của Y Combinator. Một host chào mừng khán giả trở lại và giới thiệu khách mời: Paul Copplestone, co-founder và CEO của Supabase, backend Postgres mã nguồn mở mà theo lời host đã trở thành database mặc định bên trong những công cụ như Claude Code và Codex. Host nói Supabase hiện có 13 triệu người dùng và đang tạo ra hơn một triệu database mỗi tuần (theo video đăng ngày 30/10/2026; mô tả video cũng ghi 13 triệu người dùng và hơn 50 triệu database đang được quản lý). Paul cảm ơn vì được mời.

Garry Tan mở câu hỏi đầu tiên. Ai cũng biết YC phát cho founder một chiếc áo thun ngay ngày đầu tiên, trên đó in "make something people want". Nhưng theo Garry, càng ngày cả nhóm càng nhận ra câu đó đang thành "make something agents want", và công ty của Paul là ví dụ tiêu biểu cho điều đó: khoảng 70% hoạt động mới trên Supabase đến từ agent. Anh hỏi: điều đó có điên rồ không (theo Garry, video đăng ngày 30/10/2026)?

2. Tăng trưởng và doanh thu gấp bốn

Paul đáp: đúng là điên thật. Anh nói riêng trong năm nay, nhìn vào các con số, điểm uốn (inflection) là một cú chuyển dịch rất lớn về phía agent (theo Paul, video đăng ngày 30/10/2026).

Harj Taggar muốn khán giả hình dung Supabase đã lớn tới mức nào, vì theo anh nó khá khó tin. Anh hỏi Paul quan tâm tới những con số nào, cùng thời điểm năm ngoái công ty ở đâu, và bây giờ ở đâu (video đăng ngày 30/10/2026).

Paul trả lời. Supabase hiện có 13 triệu lượt đăng ký (signup). Khoảng 12 tháng trước, có lẽ con số đó vào khoảng ba triệu. Năm nay doanh thu sẽ tăng gấp bốn. Hiện có khoảng một triệu database được tạo ra mỗi tuần, và anh xác nhận là hơn một triệu. Còn số database đang được quản lý (under management) thì đang tiến gần 50 triệu, trong khi cùng thời điểm năm ngoái là 8 triệu. Theo anh, đó là một điểm uốn cực lớn (các con số theo lời Paul, video đăng ngày 30/10/2026).

Được hỏi điều gì đang thúc đẩy đà đó, Paul đưa ra hai lý do. Thứ nhất, software engineer đang build rất hăng (anh nói "building with abandon"). Thứ hai, theo anh có rất nhiều builder mới đang xuất hiện: việc trước đây là của người có nền tảng software engineering thì nay người không phải kỹ sư cũng có thể thật sự build được thứ gì đó trên Supabase (theo Paul, video đăng ngày 30/10/2026).

3. Ba chương của Supabase, open source và agent

Garry nhận xét đây là một cú chuyển rất lớn, rồi hỏi Supabase đã thật sự làm gì để tạo điều kiện hoặc khuyến khích sự chuyển dịch đó. Software engineer rõ ràng vẫn sẽ tiếp tục chọn Supabase, nhưng làm sao để agent tìm đến ngay từ đầu (video đăng ngày 30/10/2026)?

Paul nói Supabase phần lớn đã trải qua ba chương. Công ty bắt đầu là một công ty dashboard, sau đó thành một công ty API, và bây giờ rất rõ là một công ty code first. Anh và nhóm cố gắng có đúng những phương thức (modality) mà agent thật sự muốn dùng để build, và đó là code first: phần lớn thời gian agent muốn dùng CLI. Điều thứ hai là được các LLM chọn làm lựa chọn mặc định. Theo anh, Supabase hưởng lợi rất lớn từ thời điểm: đúng lúc công ty bắt đầu trở thành lựa chọn mặc định cho database (theo Paul, video đăng ngày 30/10/2026).

Một host hỏi tiếp: việc là mã nguồn mở đóng vai trò lớn cỡ nào, vì agent rất thích những thứ open source (video đăng ngày 30/10/2026)?

Paul nói khó biết được nếu khác đi thì sẽ ra sao (counterfactual), nhưng anh nghĩ nó mang tính quyết định. Mọi thứ Supabase làm đều open source, và có vẻ điều đó đã mang lại lợi ích rất lớn. Anh và nhóm làm theo một cách rất "open source": cố hỗ trợ các công cụ đã có, không chỉ công cụ của Supabase. Anh kể Supabase hỗ trợ một công cụ rất nổi tiếng trong hệ sinh thái Postgres và giúp bảo trì nó. Nhờ vậy Supabase lan ra nhiều nhóm người dùng khác nhau (theo Paul, video đăng ngày 30/10/2026).

Garry đoán agent thật sự thích open source vì khi có gì hỏng, nó có thể đọc thẳng source code. Có tiếng đáp "Yeah". Garry nói thêm anh để ý thấy agent rất thích cảm giác mạnh mẽ, và chúng mê dữ liệu; không có gì bực mình hơn việc đâm vào một bức tường, không biết chuyện gì đang xảy ra và không sửa được (theo Garry, video đăng ngày 30/10/2026).

Paul nghĩ điều này còn ngày càng quan trọng hơn, vì bây giờ bảo mật quan trọng như vậy, nhiều doanh nghiệp lớn (enterprise) sẽ muốn kiểm tra source code để biết nó an toàn. Nếu code của bạn là closed source thì có lẽ họ sẽ không muốn chọn bạn làm nhà cung cấp (theo Paul, video đăng ngày 30/10/2026).

4. "Builder" khác gì developer truyền thống

Một host hỏi: developer có còn là người dùng cốt lõi mà Supabase nhắm tới không, và Paul nghĩ về chuyện đó thế nào bây giờ, năm 2026 (video đăng ngày 30/10/2026)?

Paul nói thế giới đang đi về phía, ít nhất là những gì anh thấy năm nay, những người anh gọi là builder. Builder đang xuất hiện, và số người xuất hiện nhiều tới mức điên rồ. Điều kỳ lạ của năm nay: thông thường, khi đầu phễu (top of funnel) tăng tốc như của Supabase, khi signup tăng tốc, bạn sẽ thấy nhiều con số khác bắt đầu giảm, như activation và conversion. Nhưng năm nay tất cả đều đi lên và sang phải, điều mà anh thấy hơi khó tin, chỉ vì các model đang giỏi build tới vậy. Anh và nhóm bắt đầu thấy những người vốn không có nền tảng software engineering cũng đến và build được (theo Paul, video đăng ngày 30/10/2026).

Garry nói đó chính là chỗ phân biệt: builder theo nghĩa là họ có thể không thật sự là software engineer. Họ có thể chỉ là một người cần build một thứ, và họ cứ thế mở Claude Code ra. Rồi hóa ra file chỉ đưa bạn đi được tới một mức nào đó (theo Garry, video đăng ngày 30/10/2026).

Paul đồng ý. Theo anh, nhóm người này có cả đống ý tưởng dồn nén mà trước đây họ không bao giờ thuyết phục được một software engineer giúp build. Bây giờ họ không phải thuyết phục ai cả, và họ đang tuôn ra đủ loại ý tưởng. Software engineer vẫn chiếm một phần rất lớn, nhưng tốc độ tăng của nhóm builder khá lớn. Anh cũng nói anh không biết trần của chuyện này ở đâu. Anh nhớ các nhà đầu tư đầu tiên của Supabase từng nói: kiểu PLG (product-led growth) sẽ chạm trần ở một mức doanh thu nào đó, và công ty sẽ phải bắt đầu chuyển sang phân khúc khác của thị trường. Đến giờ có vẻ không có trần nào cả, và anh không thấy nó dừng ở đâu (theo Paul, video đăng ngày 30/10/2026).

Một host nói điều đó về cơ bản là đúng hai năm trước, hoặc một năm trước, nhưng chắc chắn không đúng trong năm nay (video đăng ngày 30/10/2026).

Harj kể anh vừa nói chuyện với một người hôm cuối tuần vừa rồi, đúng kiểu builder: một người làm fintech vừa exit công ty với giá hơn một tỷ đô. Người này luôn ở gần sản phẩm, học toán hồi đại học, có thể ghép vài script Ruby, nhưng lúc nào cũng cần một kỹ sư để build phần mềm. Giờ thì trong các dự án phụ, anh ta tự build đồ của mình. Anh ta có toàn bộ kiến thức về cách build một công ty fintech, nên có thể build những thứ khá tinh vi chỉ cho tài chính cá nhân của mình, như bảng cân đối (balance sheet) và phần mềm theo dõi, biết cách tích hợp với ngân hàng và tự viết mọi tích hợp từ đầu. Theo Harj, đó là loại phần mềm mà ngay cả hai năm trước cũng sẽ không bao giờ được build (theo Harj, video đăng ngày 30/10/2026).

Paul nói đây cũng là kiểu builder hoàn hảo. Developer như anh có những ý tưởng rất hướng về developer, những thứ anh muốn build. Nhưng có rất nhiều chuyên gia trong lĩnh vực (domain expert) biết chính xác các ngách: "đây là vấn đề chưa ai giải trong ngách của tôi". Giờ họ có thể đào thẳng vào những ngách đó mà không phải thuyết phục ai khác tham gia. Rồi anh hỏi lại các host: anh nghĩ các anh từng nói về chuyện này ở YC, chân dung founder đang thay đổi, kể cả với những người được nhận vào mỗi batch (theo Paul, video đăng ngày 30/10/2026)?

Garry trả lời: nếu nhìn vào giai đoạn khoảng 2022 đến 2025, đã có một chuyển dịch thật sự trong suy nghĩ: AI đang tới, và bỗng nhiên software engineering trở thành cốt lõi, bạn cần một technical co-founder bằng mọi giá. Theo anh, đó là một ý tưởng cực lớn nổi lên ở YC trong giai đoạn đó. Nó vốn luôn đúng phần nào, nhưng khi đó YC nhấn mạnh gấp đôi. Rồi trong năm vừa qua, YC lại nói: thật ra, builder. YC bắt đầu thấy những người mà, theo Garry, việc khó hơn nhiều là biết build cái gì. Còn khả năng build thì giờ ai cũng có thể có sẵn trong tay, và điều đó thật sự rất hay. Anh bảo thử hình dung tất cả những thứ lẽ ra không bao giờ được build, đúng như Paul vừa nói: "chúng tôi biết người ta sẽ mua thứ này, chúng tôi biết có vấn đề ở đây", nhưng ở phần rìa, những người đó không thuyết phục được một kỹ sư làm cho họ (theo Garry, video đăng ngày 30/10/2026).

5. Ứng dụng cá nhân: chiếc taxi ở Brazil và "control tower" của Harj

Jared Friedman hỏi Paul có ví dụ nào về app người ta build trên Supabase, có khi chỉ cho riêng mình, thuộc loại trước đây sẽ không bao giờ được build không (video đăng ngày 30/10/2026).

Paul kể một ví dụ khá hay ở hội nghị của Supabase. Sau hội nghị, một người đàn ông từ Brazil đến gặp anh: người đó đã build cả một app taxi từ điện thoại của mình, kiểu một Uber thu nhỏ cho thị trường địa phương. Bản thân người đó là tài xế taxi. Paul nói anh không thật sự biết vì sao người đó build nó, nhưng việc người đó build được nó, và đến gặp anh với lòng biết ơn rất lớn vì làm được điều này, khiến anh thấy hay. Người đó khoảng 50 tuổi gì đó, nhưng có năng lượng của một thiếu niên bỗng dưng được build. Theo Paul, giờ có rất nhiều bất định quanh câu hỏi tương lai của công việc sẽ ra sao, nhưng trong nhóm builder này có một niềm háo hức về tương lai, và đó là điều anh thật sự yêu ở Supabase: một nơi mà những người đang bất định tìm thấy bộ kỹ năng này và những cơ hội này, trong khi trước đó họ chỉ là công nhân lao động chân tay (blue-collar), kiểu chân dung đó (theo Paul, video đăng ngày 30/10/2026).

Một host quay sang Harj: dạo này anh đang tự build phần mềm cá nhân, anh kể xem đang "nấu" gì. Harj đáp "Yeah" (video đăng ngày 30/10/2026).

Harj nói nó chỉ là đồ "n of 1" (dành cho một người), nhưng nó lớn dần lên từ việc anh nghiện OpenClaw. Khoảng sáu tháng trước, giờ anh thấy ngại khi nhắc lại, anh từng nói sẽ không còn UI nào nữa, tất cả chỉ là chat qua OpenClaw của anh. Anh cũng từng quyết tâm rất lâu không dùng database, chỉ muốn mọi thứ nằm trong Markdown. Nhưng hóa ra tới một lúc database trở nên hữu ích và bạn thật sự cần UI. Vậy là mấy tuần gần đây, đặc biệt là vậy, anh build thứ đó. Anh gọi nó là "control tower": mỗi mảng đời sống của anh có một UI. Có một UI để phân loại (triage) toàn bộ email nên anh không cần đọc hộp thư; có phần tài chính theo dõi chi tiêu; có phần sức khỏe theo dõi cân nặng và các buổi tập; mọi thứ ở một chỗ (theo Harj, video đăng ngày 30/10/2026).

Điều kỳ diệu, theo Harj, đôi khi là một ý nghĩ khó tin: phần tài chính trong một app của riêng anh, anh nghĩ, ít nhất đã ngang tính năng (feature parity) với Mint hay Monarch và những thứ tương tự, mà có mặt còn tốt hơn, vì nó có thể dùng ngữ cảnh rất cá nhân. Nó có thể tìm ra một giao dịch là gì bằng cách tra tên trong GBrain của anh để biết người đó là ai, rồi phân loại cho đúng. Trước đây đó là cả một công ty, nhiều startup chỉ làm tài chính cá nhân, còn bây giờ bạn có thể tự build cho mình, không cần nó chạy cho ai khác hay cần ý kiến của ai khác. Nó chỉ là thứ của riêng anh, và điều đó thật tuyệt (theo Harj, video đăng ngày 30/10/2026).

Paul nói Supabase thấy rất nhiều trường hợp như vậy, nhất là tài chính và sức khỏe, về cơ bản là hai mảng mà người ta muốn có dữ liệu của riêng mình. Anh và nhóm thấy nhiều người làm thế, và đồng bộ mọi thiết bị vào một database duy nhất là một kỹ năng kỳ diệu; bạn có thể prompt để nó tìm ra các tương quan (correlation) xuyên suốt (theo Paul, video đăng ngày 30/10/2026).

Harj nói chính các tương quan đó mới là thứ thật sự đáng giá. Lấy lại ví dụ sức khỏe: toàn bộ dữ liệu nằm trong database Supabase của anh, nhưng nó cũng có quyền truy cập lịch của anh. Nên nó biết những chuyện như: cân nặng của anh gần đây tăng, nhưng anh đang đi công tác, nên không sao, tuần sau anh cứ quay lại nhịp cũ. Nó có kiểu ngữ cảnh rất có giá trị như vậy (theo Harj, video đăng ngày 30/10/2026).

6. Database cá nhân và quyền sở hữu dữ liệu

Paul kể anh cũng nhận ra, khi bắt đầu dùng personal agent, anh hơi lo xa (paranoid) rằng mình đang dồn mọi routine và CRM vào trong một agent duy nhất. Nên giờ anh đang từ từ tách nó ra một chỗ riêng, để nếu muốn gắn các agent khác lên trên thì anh biết mình có thể dùng bất kỳ agent nào. Theo anh, CRM là một mảng khác thật sự quan trọng (theo Paul, video đăng ngày 30/10/2026).

Một host nói đó là lý do Supabase có giá trị như vậy: thứ đáng giá thật ra là nơi giữ bản ghi gốc (store of record), là database. Bạn muốn sở hữu database của riêng mình rồi build mọi application hay agent lên trên, thay vì để tất cả nằm trong database của người khác (video đăng ngày 30/10/2026).

Một host nói đó là một ý tưởng hoàn toàn mới lạ nếu nghĩ về lịch sử database: trước đây thế giới chỉ có một số lượng tương đối nhỏ những database rất lớn, do các công ty lớn vận hành. Anh nhớ khi Supabase mới bắt đầu, công ty có ý tưởng là phải làm cho việc tạo database thật dễ với tất cả mọi người, và lúc đó điều này gần như vô lý: tại sao lại có nhiều người muốn làm vậy, vì nếu không viết được code thì bạn làm được gì với một database? Mà số người thật sự viết được code và build được một CRM cá nhân như thế không nhiều; trước AI, việc đó là quá nhiều công sức với hầu hết mọi người (video đăng ngày 30/10/2026).

Harj kể thêm một ví dụ nơi Supabase thật sự có giá trị với anh: một mảng khác trong control tower chỉ là chỗ upload file. Nghe rất đơn giản, nhưng anh có thể forward bất kỳ file nào qua email hoặc thả vào UI này, rồi agent của anh tìm ra file đó là gì, nó liên quan gì tới cuộc sống của anh và cần làm gì với nó. Tất cả được lưu trên Supabase. Nói chung, Supabase rốt cuộc sẽ chứa mọi dữ liệu về cuộc sống của anh ở một chỗ. Một năm trước anh sẽ không bao giờ nghĩ mình muốn có một database cá nhân, vì khi đó nó chẳng có nghĩa gì, nhưng giờ anh thấy đó thật ra là thứ có giá trị nhất (theo Harj, video đăng ngày 30/10/2026).

Một host nói thêm rằng Supabase có một thứ "files" tương thích S3 và mọi thứ của anh nằm trong đó. Có tiếng đáp "Oh really? Nice." Host này nói đó là mặc định trong GBrain. Có tiếng nói "Great, thank you." (video đăng ngày 30/10/2026).

7. Scale tới hàng tỷ database

Jared hỏi Paul: đây có phải tương lai, khi về cơ bản mọi người trên thế giới, không chỉ mọi developer mà mọi người, sẽ có một database Supabase chứa những thứ về cuộc sống của họ, sức khỏe, tài chính, các mối quan hệ (video đăng ngày 30/10/2026)?

Paul nói anh rất muốn vậy. Anh chắc rằng mọi người trên thế giới có quyền dùng AI sẽ trở thành một kiểu builder nào đó: bạn có thể build bất cứ thứ gì, tùy biến nó, muốn chỉnh một app hay một UI thì không phải phụ thuộc vào ai. Tất nhiên, anh và nhóm coi Supabase là một công ty "index" (một chỉ báo): khi vào YC, Supabase chỉ tập trung vào các công ty YC, muốn giành mọi khách hàng YC, vì biết mình phải có mặt từ ngày đầu tiên khi doanh nghiệp bắt đầu. Sứ mệnh không đổi, chỉ có độ mở (aperture) đã tăng lên đáng kể. Giờ khi có thêm nhiều builder, anh và nhóm biết phải phục vụ họ, và đó thật ra là một bài toán hoàn toàn khác, nhưng là một bài toán thú vị (theo Paul, video đăng ngày 30/10/2026).

Một host hỏi lại: "đáng kể" nghĩa là kiểu gấp 10 triệu lần (video đăng ngày 30/10/2026)?

Paul nói: hiện Supabase tạo một triệu database mỗi tuần. Nhưng nếu làm phép tính đơn giản, lấy ví dụ ChatGPT, anh nghĩ họ nói có 1,2 tỷ người dùng hoạt động hằng tuần (weekly active user). Giả sử tất cả họ đều muốn launch một thứ gì đó mỗi tháng, đó là 1,2 tỷ database mỗi tháng. Đó là quy mô Supabase đang hướng tới, và cần những kiến trúc để có thể phục vụ quy mô đó, điều chưa từng phải xảy ra trong thế giới database (theo Paul, video đăng ngày 30/10/2026; con số ChatGPT là như anh nhớ).

Một host hỏi: có làm được việc đó với Postgres không, hay Supabase sẽ phải tự build database engine riêng để scale tới một tỷ database mới mỗi tuần (video đăng ngày 30/10/2026)?

Paul nói nếu Supabase đàm phán được tốt hơn với AWS thì có lẽ làm được; nhưng hóa ra lúc này ai cũng muốn có máy tính. Và thật ra anh không chắc nhiều workload này cần tới một chiếc Ferrari như vậy. Supabase vừa thực hiện một thương vụ mua lại: Turso. Turso có một kiến trúc tương thích với Postgres, và thật ra cũng tương thích với SQLite. Anh nghĩ SQLite là một database phi thường. Vậy nên Supabase sẽ cung cấp một tier mà anh gọi là Supabase Spark, về cơ bản dành cho những workload lúc mới bắt đầu. Ý tưởng vẫn vậy: bạn bắt đầu với cùng một trải nghiệm và có thể scale lên tới hàng petabyte. Tagline của Supabase là "prototype to petabytes". Theo anh, công ty phải bảo đảm phục vụ được tất cả mọi người, và nếu họ scale lên và doanh nghiệp tiếp tục lớn, Supabase bảo đảm họ có trải nghiệm tốt (theo Paul, video đăng ngày 30/10/2026). Bài đăng trên blog Supabase ngày 02/10/2026 ghi Supabase đang mua lại Turso, và rằng Supabase sẽ tiếp tục build quanh Postgres trong khi Turso tiếp tục làm SQLite (đọc ngày 03/11/2026).

Harj nói đó là điều anh tò mò: một công ty phần mềm kinh điển bắt đầu với các startup giai đoạn đầu, như trong một batch YC, rồi luôn để một mắt nhìn về enterprise. Theo anh, nhất là với một công ty database trước thời AI, lối nghĩ thông thường là bạn muốn thành Oracle, nên phải tới enterprise càng nhanh càng tốt vì tiền nằm ở đó, và bạn bắt đầu build các tính năng enterprise. Việc nghiêng về SQLite thì như đi theo hướng ngược lại. Anh hỏi Paul nghĩ thế nào, có phải đang nhìn cả hai phía không (video đăng ngày 30/10/2026)?

Paul nói Supabase đang phải làm cả hai, và điều đó cực kỳ khó. Về cơ bản công ty có hai sản phẩm phục vụ hai đầu: Multigres scale lên tới hàng petabyte, còn Turso scale xuống cho những workload kiểu prototype và SQLite. Làm điều này ở tốc độ tăng trưởng như vậy, trong khi phải tuyển thêm người, ngay cả với AI, đang và đã là một thách thức thật sự, nhưng là một thách thức vui (theo Paul, video đăng ngày 30/10/2026). Trang Multigres tự mô tả là một kiến trúc Postgres scale theo chiều ngang (đọc ngày 03/11/2026).

8. AI adoption bên trong Supabase

Garry nhắc tới một cuộc khảo sát (poll) Supabase làm gần đây: từ 10% số kỹ sư viết 80% code của mình bằng coding agent, con số đó gần đây đã lên tới 60% chỉ trong vòng sáu tháng. Anh hỏi: chuyện đó xảy ra thế nào, đang có gì diễn ra, và từ đây nó sẽ đi đâu (con số theo lời Garry, video đăng ngày 30/10/2026)?

Paul nói Supabase không có chính sách AI nội bộ. Công ty để mọi người làm điều họ muốn và cho họ quyền dùng bất kỳ công cụ nào họ muốn. Anh nghĩ bây giờ đơn giản là họ đã bị thuyết phục rằng model có thể làm việc tốt hơn nhiều và nhiều hơn nhiều, nên mức adoption tăng điên rồ. Những thứ họ build nội bộ không chỉ là đồ "vibe-coded", mà khá nặng. Và khi Supabase chuyển sang thế giới code do AI viết, lượng testing và các công cụ testing được áp dụng đã khá hữu ích để bảo đảm mọi người thật sự biết kết quả cuối sẽ tốt (theo Paul, video đăng ngày 30/10/2026).

Garry nói YC cũng thấy điều đó trong các startup YC, như Blacksmith, Depot, Ubicloud: tất cả đều đang lên vì ai cũng làm CI (theo Garry, video đăng ngày 30/10/2026).

Một host nói thêm: số lượng test người ta có giờ tăng vọt, rồi tới Greptile cho khâu review; thấy điều đó thật sự khá ấn tượng. Người đó hỏi tiếp, câu hỏi bỏ dở giữa chừng: có phải chỉ là model giờ đã đủ tốt, và người ta dành đủ thời gian để thấy "à, thật ra cái này khá tốt" (video đăng ngày 30/10/2026)?

Paul nói người ta cần được thuyết phục, nhất là kỹ sư. Đầu năm có thể họ chưa nghĩ nó tốt lắm. Model đã tốt lên, nhưng họ cũng bắt đầu thấy: "à, thật ra mình có thể làm được những điều tuyệt vời với các model này". Anh nhắc tới những chuyện quanh Navier-Stokes, những thứ thuyết phục thị trường rằng đúng là có thể mở ra vùng đất mới. Theo anh, đó là thế giới đang hướng tới, và giờ mọi người đã tin rằng mọi thứ sẽ đi theo hướng này (theo Paul, video đăng ngày 30/10/2026).

9. Ba kỷ nguyên và những công ty đi trước: Parse, Firebase, Mongo

Một host tóm lại: Paul đã đưa Supabase qua ba kỷ nguyên. Đầu tiên là một công ty dashboard, build trong 100 ngày ở YC; rồi công ty API; và giờ là khoảnh khắc "make something agents want". Trong mỗi kỷ nguyên, có một hai điều nào nổi bật kiểu "à, chính điều đó đã làm nên chúng tôi lúc ấy" không (video đăng ngày 30/10/2026)?

Paul nói những cú chuyển đó đã xảy ra như sau. Với cái đầu tiên, đúng như host vừa nói, tại sao một công ty database lại tồn tại: khi vào YC, Supabase có vẻ là một ý tưởng rất ngược đời (contrarian) vào thời điểm đó. Anh và nhóm thấy dùng database khó tới mức nào, ngay cả với developer. Vậy nên hướng dashboard first là: build một UI trông giống Airtable chạy trên Postgres, vì anh cũng rất thích Airtable và nghĩ sẽ hay nếu phía sau nó chỉ là một database Postgres. Cái đó đến từ việc thấy ngay cả software engineer cũng chật vật (theo Paul, video đăng ngày 30/10/2026).

Cú chuyển sang API, theo Paul, đến từ một bên đang tích hợp với Supabase và nói: "chúng tôi muốn launch rất nhiều database, chúng tôi cần một API để làm tất cả việc này". Đó là khoảng năm 2021. Và hóa ra đó đúng là bước đi phù hợp cho năm 2024, khi những cái tên như Bolt, Lovable và nhiều bên khác bắt đầu build trên Supabase (theo Paul, video đăng ngày 30/10/2026).

Rồi năm nay, anh thấy thật ra chẳng ai tới dashboard nữa. Không ai vào dashboard nữa. Vậy agent sẽ build thế nào? Anh gửi một bản product memo cho team, nói rằng Supabase phải code first, phải chuyển sang code first. Nếu một thứ có trên dashboard thì về cơ bản nó phải chạy song song, ăn khớp hoàn toàn (lockstep) trong code, về cơ bản là infrastructure as code. Anh và nhóm đã kiến trúc lại phần lớn CLI và nhiều thứ khác để chạy được trong sandbox, bằng code (theo Paul, video đăng ngày 30/10/2026).

Một host hỏi, có thể là lùi quá xa, nhưng Supabase có từng lấy cảm hứng từ Parse, một công ty YC khác, không (video đăng ngày 30/10/2026)?

Paul nói có: Parse và Firebase, anh thích cả hai công ty đó. Anh thấy buồn cười về những làn sóng này: họ làm backend, Firebase được Google mua, Parse được Meta mua. Nhưng theo anh, theo một nghĩa nào đó, họ đã mở đường cho Supabase đến sau và có một doanh nghiệp database đàng hoàng. Vì năm 2014, không dùng RDS cho database của mình là điều vô lý. Rồi họ xuất hiện, Mongo xuất hiện, Mongo bắt đầu chuyển sang Atlas, và nhiều công ty database cho thấy bạn không cần chỉ dùng một trong ba hyperscaler, bạn thật sự có thể có một công ty database đàng hoàng. Thời điểm đó mang tính quyết định với Supabase (theo Paul, video đăng ngày 30/10/2026).

Một host nói Parse giờ phần nào bị quên, nhưng đó là một sản phẩm build rất tốt. Họ ra mắt đúng lúc anh lần đầu build app iPhone, và chuyển sang một RESTful API gọn gàng như vậy thật dễ chịu (video đăng ngày 30/10/2026).

Paul nói những cú chuyển này luôn đi kèm các điểm uốn. Khi đó có hai chuyện xảy ra trên thị trường: không hiểu sao MongoDB thuyết phục được mọi người rằng NoSQL là một cách tuyệt vời để lưu dữ liệu; và thứ hai là mobile. Anh nói Supabase may mắn cũng có được vài làn sóng như vậy, và giờ đang ở ngay giữa tâm của một làn sóng (theo Paul, video đăng ngày 30/10/2026).

10. Heroku, AWS, mô hình kinh doanh của Stripe và khách hàng cá nhân

Harj nói đây là điều anh muốn hỏi lúc trước về cách nghĩ về enterprise từ sớm. Nếu lùi xa hơn, Heroku là bên đầu tiên theo kiểu: cứ bắt đầu với developer experience tốt nhất rồi scale lên. Nhưng theo anh, scale lên cùng khách hàng thật ra có thể khá khó, và anh nghĩ Heroku đã không bắc được cây cầu đó: làm sao giữ người ta ở lại khi app lớn hơn và cần hiệu năng cao hơn, vân vân. Trong lịch sử, công ty nào cũng phải giải bài toán đó. Anh biết Supabase đang nhìn về hướng ấy, nhưng có thể Supabase không phải làm, nếu thị trường chỉ riêng phần "từ 0 đến 10" cứ mở rộng với tốc độ này thì nó sẽ khổng lồ (theo Harj, video đăng ngày 30/10/2026).

Paul đáp rằng có thể Supabase không bắt buộc phải làm, nhưng chắc chắn sẽ làm. Anh dành lời khen cho Heroku: theo anh họ đã làm Postgres phổ biến. Nhưng khi đó Postgres còn khá non trẻ và vẫn còn một số giới hạn khi scale, nên Supabase đã phải bọc Postgres trong những công cụ cho phép nó scale vô hạn (theo Paul, video đăng ngày 30/10/2026).

Harj nói có lẽ phép so sánh đúng hơn cho Supabase là AWS, bên đã giành được khách hàng từ sớm và scale theo họ. Anh hỏi bài học là gì, Paul nghĩ thế nào về việc bảo đảm có thể scale vô hạn (video đăng ngày 30/10/2026)?

Paul nói bài học là thế này. Anh có nghe một con số thống kê, có thể anh nhớ sai nên cần kiểm chứng lại: khoảng 40% doanh thu của AWS đến từ những startup bắt đầu trên AWS rồi scale lên. Đó là nhóm mà Supabase muốn. Anh và nhóm biết thuyết phục người ta di chuyển từ nhà cung cấp database này sang nhà cung cấp khác gần như là không thể. Nên Supabase chỉ muốn có mặt từ ngày đầu tiên, bảo đảm họ có trải nghiệm tốt, rồi bảo đảm họ thật sự không muốn rời đi (theo Paul, video đăng ngày 30/10/2026; con số 40% là như anh nghe và tự nói cần kiểm chứng).

Một host nói đó là mô hình kinh doanh giống Stripe, về cơ bản là mô hình kinh doanh tốt nhất trên đời nếu bạn làm được: có được họ từ ngày đầu, rồi scale vô hạn cùng những công ty tăng trưởng nhanh nhất thế giới (video đăng ngày 30/10/2026).

Paul đồng ý: bạn làm điều đó suốt một thế hệ và trở thành một doanh nghiệp thế hệ (generational business), về cơ bản là vậy. Nhưng với Supabase thì khó, vì "ngày đầu tiên" trông thế nào đang thay đổi rất nhanh. Trước đây, ngày đầu tiên với anh luôn là khách hàng YC. Còn bây giờ ngày đầu tiên đang thành: ai cũng là builder; họ sẽ dùng gì, các phương thức là gì, họ sẽ chọn database thế nào? Theo anh, đó là những câu hỏi khó (theo Paul, video đăng ngày 30/10/2026).

Jared nói đây là một phân khúc khách hàng khác. Khi Supabase mới bắt đầu, không hề có một thị trường database cho cá nhân; ý tưởng một công ty database là doanh nghiệp bán thẳng cho người tiêu dùng (direct-to-consumer) nghe như một lỗi cú pháp (syntax error). Paul đáp "Yes". Jared nói tiếp: nhưng giờ Supabase thật sự có hai phân khúc, các công ty giai đoạn đầu với mô hình kinh doanh mạnh kiểu Stripe, và việc bán thẳng cho người tiêu dùng, hoặc có lẽ cho agent của họ. Paul đáp "Yes, yes, yes". Jared nói những use case đó có lẽ sẽ không scale như startup, nhưng họ có thể tiếp tục dùng Supabase cho suốt phần đời còn lại, vì Supabase đang chạy app quản lý tài chính cá nhân của họ, hay công ty taxi của họ, hay thứ gì đó tương tự (theo Jared, video đăng ngày 30/10/2026).

Paul nói khi cuộc sống của họ lớn lên và họ tích lũy thông tin, đó về cơ bản là một chỉ số cho tăng trưởng của chính Supabase: họ lưu nhiều hơn, người ta thu thập nhiều dữ liệu hơn, và thị trường prosumer này về bản chất là một yếu tố tăng trưởng tốt cho Supabase (theo Paul, video đăng ngày 30/10/2026).

11. Build cho personal agent và dogfooding

Một host hỏi: Paul có nhìn thế giới personal agent qua lăng kính đó không? Coding agent muốn Supabase thì đã rõ. Nhưng nếu giai đoạn tiếp theo là ai cũng có database cá nhân, Supabase có cần làm gì để personal agent nói chuyện với nó dễ dàng không, hay về cơ bản là giống nhau (video đăng ngày 30/10/2026)?

Paul nói giờ anh rất lạc quan (bullish) về personal agent, sau một tuần trợ lý điều hành (EA) của anh đi vắng và anh học được chính xác chúng làm được gì. Và giờ anh như bị ám ảnh với ý tưởng build cho personal agent. Đúng là anh từng nói với công ty rằng Supabase là code first, đang build cho con người làm việc theo kiểu code first, nhưng thật ra là đang build cho agent: những con người đó chẳng bao lâu nữa sẽ không thật sự tương tác trực tiếp (theo Paul, video đăng ngày 30/10/2026).

Cách anh đang build: anh dùng một agent mà anh nói chuyện qua điện thoại. Anh ngồi trong một cuộc gọi với nó suốt, trò chuyện và nói "bạn sửa giúp mấy chỗ này được không". Heuristic của anh để chắc mình đang build, hay dogfooding, cho đúng là anh không nhìn code, và không bao giờ cho phép mình kiểm tra kiến trúc, trừ khi muốn kiểm tra nó có đang build đúng không. Còn khi thay đổi gì, anh chỉ muốn nói chuyện với nó và xem nó thay đổi được gì (theo Paul, video đăng ngày 30/10/2026).

Có tiếng xen vào: "One of us." (video đăng ngày 30/10/2026)

Paul nói nó cũng điên rồ: nó đang làm những thứ phi thường, cảm giác như bước ra từ một bộ phim khoa học viễn tưởng của hai năm trước. Giờ anh có rất nhiều khoảnh khắc thấy choáng ngợp; nếu cho ai đó xem điều này sáu tháng trước, họ sẽ nghĩ là không thể (theo Paul, video đăng ngày 30/10/2026).

Jared kể anh có mặt ở hội nghị Supabase Select của Paul vài tuần trước, và nói thêm đó là một hội nghị rất hay. Anh nảy ra một ý nghĩ khá điên: ngồi đó nghe Paul nói về đủ tính năng mới Supabase ra mắt, anh nghĩ nếu mình build app trên Supabase, có lẽ mình còn chẳng buồn tự hiểu hết các tính năng hay ho đó. Anh muốn gửi agent của mình tới Supabase Select để nghe hết tính năng mới và tự tìm cách tích hợp chúng vào codebase (theo Jared, video đăng ngày 30/10/2026).

Paul hưởng ứng: thật là "wild", một hội nghị ảo thực thụ. "We should do that", một hội nghị chỉ dành cho agent. Mọi người góp vào: một hội nghị cho agent, chúng đều có mặt live, có thể nói chuyện với nhau, trao đổi mẹo, ngay tại chỗ. Có tiếng nói có thể bắc cầu: "airdrop" các file markdown cho mọi người, nhưng phải có mặt trong khán phòng mới nhận được. Một host đặt tên: "the artifactory". Paul nói anh khá thích cái tên đó (video đăng ngày 30/10/2026).

12. Thiết kế agent-first: error message và eval

Garry nhắc lại chuyện đã nói trước buổi quay: có một loạt thứ Supabase đang làm khiến agent thích Supabase hơn, như error message. Insight then chốt là gì, và còn những thứ nào khác Supabase đang làm, một mặt thì hiển nhiên, mặt khác lại chưa ai làm (video đăng ngày 30/10/2026)?

Paul nói về error message: tối qua anh có mặt ở một sự kiện và ngạc nhiên vì điều này không hiển nhiên với mọi người. Supabase đã đào rất sâu vào error message. Bạn lấy một use case, như "tôi muốn build một application". Thông thường, error message cho developer chỉ là kiểu "500", một thứ cơ bản, và bạn chỉ biết là có vấn đề. Nhưng giờ bạn muốn agent tự khắc phục. Nên bên trong error message, bạn nói thẳng cho chúng cách sửa lỗi này, hoặc bảo chúng đi đọc docs nào để sửa. Phần lớn việc này chỉ là chọn use case của bạn rồi lặp đi lặp lại các vòng cải thiện error message của chính mình, để bạn có thể "one shot" về cơ bản bất cứ thứ gì bạn muốn (theo Paul, video đăng ngày 30/10/2026).

Garry nói hợp lý: nếu bạn được một agent dùng, agent sẽ gặp error message. Trước đây con người phải đi Google lỗi đó và làm đủ thứ, còn ở đây bạn có thể nói luôn: "bạn đang hết inode, nên có lẽ bạn nên làm thế này" (theo Garry, video đăng ngày 30/10/2026).

Paul nói có hai giai đoạn để chiếm được agent. Thứ nhất là được model chọn. Thứ hai là khi chúng bị kẹt, bạn không muốn chúng chuyển sang bên khác. Chắc chắn chúng sẽ bị kẹt ở một lúc nào đó, và bạn chỉ muốn đưa cho chúng công cụ để tự khắc phục. Nên thật ra không phức tạp lắm: theo anh chúng giờ đủ thông minh để tự tìm ra nhiều thứ, nhưng bạn phải thiết kế lại nhiều thứ trước đây chỉ dành cho con người và developer để dành cho agent (theo Paul, video đăng ngày 30/10/2026).

Jared hỏi Supabase có test sản phẩm cho agent không: có cho agent thử dùng Supabase rồi báo lại mọi chỗ chúng gặp khó không (video đăng ngày 30/10/2026)?

Paul nói có, với tất cả các model khác nhau. Supabase có một website eval để xem model nào đang build tốt nhất, và có bộ eval nội bộ riêng. Công ty cũng eval xem model nào tốt nhất riêng với Postgres, điều anh nghĩ là thú vị cho cả ngành, và build skill quanh đó để các model áp dụng và thật sự phát triển với Postgres. Nên có rất nhiều testing. Thật ra, giờ phần lớn công sức engineering của Supabase đang dồn vào việc test các use case cụ thể hơn là vào việc build: anh và nhóm muốn nghĩ cho kỹ xem người ta đang build thế nào và build các bộ test quanh đó (theo Paul, video đăng ngày 30/10/2026).

13. Garry kể chuyện xây GBrain trên Supabase

Jared hỏi Garry: khi build GBrain, anh build nó trên Supabase. Anh kể xem anh quyết định build trên Supabase thế nào, và làm người dùng thì cảm giác ra sao (video đăng ngày 30/10/2026)?

Garry nói GBrain là bản chưng cất từ một loạt thứ anh đã viết. Đầu tiên anh làm Garry's List, một kiểu tòa soạn agentic (agentic newsroom). Anh phải dựng về cơ bản một hệ thống nghiên cứu cho RAG, cho chính sách và các bài báo khoa học: nó đọc mọi bài báo về một chủ đề rồi cố tổng hợp lại. Sau đó anh lấy phần đó và chưng cất thành phần retrieval mã nguồn mở cho OpenClaw (theo Garry, video đăng ngày 30/10/2026).

Lý do là thế này. Anh đã viết nó bằng Rails, và nó giống một nhà máy Foxconn cho agent: anh coi mỗi lần gọi LLM là cực kỳ đắt và cực kỳ nguy hiểm. Rồi khi thấy OpenClaw, nó giống như Esalen: một cách rất khác để làm việc với AI, kiểu "à, AI thông minh, nó không cố làm hại bạn, nên cứ để nó làm việc, cứ đưa cho nó dữ liệu và năng lực". Anh nhận ra một triệu token thật ra là một bộ nhớ làm việc (working memory) đáng kinh ngạc. Hầu hết con người chỉ giữ được khoảng bảy cộng trừ hai thứ trong đầu, trong khi một triệu token về cơ bản là ba cuốn Harry Potter. Nhưng ngay cả thế vẫn hơi giới hạn với agent: giữ đúng ba cuốn Harry Potter cần thiết trong context ở một thời điểm là một thách thức thật sự (theo Garry, video đăng ngày 30/10/2026).

Nên anh thấy có một thứ ở giữa, cho "bộ não công ty" (company brain) hoặc cho đồ cá nhân của anh. Anh có nửa triệu file markdown về mọi cuộc trao đổi anh từng có, nên thứ này thật sự có ngữ cảnh về anh và mọi điều anh quan tâm. Nhưng ở bất kỳ thời điểm nào, agent có thể chỉ cần khoảng hai trang. Đó là một bài toán retrieval. Ở mức đó, anh nghĩ khoảng 30, 40 gigabyte, bạn cần pgvector, bạn cần Postgres, và bạn có thể làm graph database rất dễ trong SQL. GBrain chính là vậy: RAG retrieval cộng với một graph database tạo cấu trúc từ dữ liệu phi cấu trúc, kiểu dynamic schema, hơi giống Palantir mà anh nhớ ngày xưa (theo Garry, video đăng ngày 30/10/2026).

Toàn bộ ý tưởng, theo Garry, là agent mạnh hơn nhiều khi có thứ trung gian này: agent chỉ cần nói "đây là thứ tôi đang tìm", nó sẽ duyệt graph, làm toàn bộ vector search rồi quay lại với "đây là một bản báo cáo, hãy nạp cái này vào context". Đó là GBrain. Còn Supabase thì rất đơn giản: anh cần Postgres được host, và cần nó phục vụ một kho dữ liệu cỡ 50 hay 100 hay 300 gigabyte thật nhanh. Và nó chạy rất tốt, auto scaling chạy rất ổn (theo Garry, video đăng ngày 30/10/2026). Repo GBrain trên GitHub tự mô tả là "Garry's Opinionated OpenClaw/Hermes Agent Brain" (đọc ngày 03/11/2026).

Giờ điều buồn cười nhất, theo Garry, là với browser use: anh dùng một trình duyệt phụ cho browser use, và OpenClaw có thể vào Supabase, dùng database hay các API mới mà Paul và nhóm làm, rồi tự quản lý; nó có thể tự quản lý chính nó (demo theo lời Garry, video đăng ngày 30/10/2026).

Có tiếng hỏi Garry: anh có phải prompt để nó tìm ra cấu trúc dữ liệu, như graph hay RAG, hay gì đó không (video đăng ngày 30/10/2026)?

Garry nói điều buồn cười là anh nhớ mình vào Claude Code và chỉ nói: dùng Exa, tải về và phân tách (diarize) mọi bài nghiên cứu về AI mà nó tìm được. Hôm nay anh có thể dùng thứ như Alpha Signal, nhưng ý là: đi tìm mọi bài nghiên cứu về RAG, graph database, text retrieval, rồi tóm tắt cho use case của anh, là làm sao giúp một agent tiếp cận được những thứ này. Sau khi nó làm xong, nó nói: "ok, đây là cách chúng ta sẽ làm" (theo Garry, video đăng ngày 30/10/2026).

Theo lời Garry, đó là yêu cầu anh đưa cho Claude Code:

use Exa and download and diarize every paper you can find in AI research

14. Dynamic retrieval và vòng lặp eval tự cải thiện

Paul kể hôm trước anh dự một bữa tối về tương lai của database. Một ý tưởng ở đó là về bản chất database là một cơ chế retrieval cho dữ liệu: bạn đặt index để chúng tìm trên dữ liệu theo một số định dạng, như graph hay RAG. Một ý tưởng rất thú vị là đặt một agent chạy vòng lặp để tạo ra cấu trúc dữ liệu hoàn hảo cho việc tìm kiếm: nếu bạn tìm trên tập dữ liệu này chừng ấy lần và mỗi lần mất 10 giây, sao không để một agent chạy vòng lặp tạo ra một loại index mới, hoặc tìm index tốt nhất để trả về kết quả trong dưới một giây (theo Paul, video đăng ngày 30/10/2026). Có tiếng đáp "Oh yeah" trong lúc anh kể.

Garry nói dynamic retrieval rõ ràng sẽ xảy ra ngay khi bạn có code gen thật sự, thật sự thông minh. Hiện tại anh dùng nó cho OpenClaw: anh dùng instance production, rồi từ các trace đó anh trích ra một tập dữ liệu eval. Anh có một repo riêng tên là GBrain evals, với 40 nhóm (category) khác nhau: các kiểu retrieval cụ thể, hiệu quả retrieval, hiệu quả chi phí, latency (theo Garry, video đăng ngày 30/10/2026).

Điều hay ở eval, theo Garry, là bạn có thể bảo agent chạy vòng lặp: cứ auto research và lặp, thứ gì cải thiện chỉ số trên bộ eval này thì ship vào master, bật mặc định; thứ gì đã thử mà không hiệu quả thì viết một file markdown giải thích vì sao nó nghĩ thứ đó không hiệu quả, rồi cất vào GBrain evals (theo Garry, video đăng ngày 30/10/2026).

Anh dùng một công cụ có khái niệm "captain", theo anh hơi giống các bot Grok: bạn chỉ cần đưa cho nó một ngữ cảnh. Anh có một captain luôn chạy với nhiệm vụ nghĩ ra các category mới, và một captain khác luôn chạy, đi qua mọi category trong eval, auto research, và mỗi ngày cố tìm cách cải thiện điểm trên bộ eval nội bộ. Nó chạy liên tục. Garry gọi đó là một phiên bản rất, rất sơ khai của RSI (recursive self-improvement) cho một use case cụ thể. Nhưng nếu đi lên một tầng trừu tượng, bạn có thể làm điều đó không chỉ cho use case của anh, là OpenClaw, mà cho use case retrieval của bất kỳ ai; thứ duy nhất thay đổi là use case, các trace và tập dữ liệu (theo Garry, video đăng ngày 30/10/2026).

Có tiếng nói với Garry: rõ ràng anh hiểu về eval, và anh có thể cải thiện phần mềm của mình vì anh bọc framework này quanh nó. Rồi hỏi: trong tương lai, builder có phải thật sự biết về những thứ kiểu này không (video đăng ngày 30/10/2026)?

15. Tương lai của coding

Garry nói có thể không. Thành thật mà nói, anh cảm thấy mọi thứ còn quá sớm: anh chỉ đang mày mò, anh thích làm việc này dưới dạng open source, và anh hy vọng ai đó nhìn vào và nói "à, mình áp dụng được cái này". Theo anh, mọi người đúng là đang nghĩ ra những primitive về cách dùng những thứ này ngay lúc này. Anh nhớ đầu năm đọc về software factory của Steve Yegge và những thứ tương tự mà không hoàn toàn hiểu ra được; giờ anh cảm thấy mình đã chắp vá được một thứ chạy được, ít nhất là với anh (theo Garry, video đăng ngày 30/10/2026).

Jared nhắc lại khi Boris Cherny ngồi ở đây, tầm nhìn của Boris về tương lai của coding giống như bạn chỉ nói chuyện với Claude như với một người bạn, không phải biết về eval hay mấy thứ đó, và Claude tự tìm ra cách build thứ bạn đang có trong đầu (theo Jared, video đăng ngày 30/10/2026).

Paul kể anh có tên miền openusd.dev. Có một định dạng file tên là OpenUSD, và anh hay sưu tầm tên miền. Rồi bỗng nhiên Stripe, Visa và nhiều bên khác công bố OpenUSD, nên anh nghĩ phải đem tên miền này ra dùng, nhưng anh chưa bao giờ có thời gian. Vậy là anh trò chuyện với agent của mình, và nó phát triển một trang developer với hệ sinh thái và đủ thứ. Anh trò chuyện với nó trên máy tính, rồi khi kết thúc ngày, anh gọi nó trên điện thoại lúc chuẩn bị đi ngủ; anh nói nghe thì đáng ngờ, nhưng anh hứa là chỉ đang kiểm tra và code cùng nó (theo Paul, video đăng ngày 30/10/2026).

Anh nói với nó rằng anh không thích kiến trúc thông tin ở chỗ hệ sinh thái liên kết với các use case, bảo nó đưa vài gợi ý. Nó đưa. Anh nói "ok, triển khai đi". Rồi 20 giây sau nó nói "ok, xong rồi, anh refresh lại nhé". Anh refresh trang, nội dung viết rất tốt, mọi thứ liên kết với nhau, và nó đã nối luôn các phần kiểu SEO. Anh không hề làm những việc kinh điển mà lẽ ra phải làm, chỉ trò chuyện với nó, và theo anh đó thật sự là một trong những khoảnh khắc anh thoáng thấy tương lai (demo theo lời Paul, video đăng ngày 30/10/2026).

Một host nói Paul làm được vậy vì anh biết mình muốn build gì. Paul đáp đó chính là vấn đề: rõ ràng anh có nền tảng engineering nên ít nhiều biết cách prompt. Nhưng anh đang cố không nói gì, cố không hướng nó về phía GitHub hay thứ gì tương tự, anh đang cố code như một người bình thường ("normie"), hay như một người sẽ làm vào năm sau. Mục đích là để dogfood Supabase và biết được liệu một năm nữa agent có trải nghiệm tốt với Supabase không (theo Paul, video đăng ngày 30/10/2026).

Garry nói thấy buồn cười khi Boris bảo "tôi chỉ muốn nó làm tự động". Chắc chắn, một khi thứ đó đã vào phân phối dữ liệu (distribution), nghĩa đen là model đã có nó trong weights, nó làm được. Nhưng trước đó nó cần chút markdown hay gì đó; thậm chí không cần nhiều prompt, chỉ một lượng prompt rất nhỏ là nó làm được (theo Garry, video đăng ngày 30/10/2026).

Garry nói mọi người đang bước vào một khoảnh khắc rất lạ của xã hội: có vẻ RSI thật sự đã ở đây, và khoảnh khắc đi từ 20% tới 80% của nghiên cứu AI đang diễn ra ngay trong các vòng lặp này, bên trong Claude Code hay Codex hay ở đâu đó. Đồng thời, xã hội không thật sự có đủ những người như Paul, biết build cái gì và biết hỏi nó thế nào. Nên giống như lực không thể cản gặp vật không thể dời. Năng lực của các model đang tăng theo hình parabol, còn số người biết cách thật sự tạo tác động lên xã hội bằng nó thì gần như không đổi (theo Garry, video đăng ngày 30/10/2026).

16. Thêm nhiều người khởi nghiệp, và lời khuyên cuối

Paul thêm: và muốn thấy háo hức với nó, theo anh đó là điều còn lại. Anh nghĩ nhiều người đang trở nên lo sợ, nhưng anh thật sự háo hức về những gì tương lai có thể mang lại cho rất nhiều người. Nhiều startup trước đây của anh tập trung vào công nhân lao động chân tay, những người mà anh bọc công nghệ quanh họ, những người đã phải làm việc rất nhiều trong đời. Điều anh rất thích ở Supabase là anh thấy rất nhiều người khởi nghiệp nhờ nền tảng này, nên anh có thể thấy một tương lai nơi sẽ có nhiều người khởi nghiệp hơn rất nhiều, và đó thật ra là một lối sống khá trọn vẹn với nhiều người. Anh khá phấn khích về năm 2027: miễn là giữ được nhịp này và tránh được vài sự kiện điên rồ, đó sẽ là một chuyến đi vui với nhiều người (theo Paul, video đăng ngày 30/10/2026).

Garry nói YC đang thấy một khoảnh khắc mà founder vertical SaaS gặp khó khi gọi Series A. Khi bạn còn dưới quy mô (subscale), ở khoảng 5 đến 10 triệu đô ARR, mức mà trong lịch sử là rất nhiều ARR, chắc chắn có Series A ngay cả chín hay mười hai tháng trước, thì hôm nay người ta lại không mặn mà lắm. Theo anh, với horizontal và đầu tư AI thì có vẻ hoàn toàn bật đèn xanh, nhưng người làm vertical SaaS đang thật sự chật vật. Nhưng điều này cũng xảy ra đúng vào lúc bạn có thể đạt 10 đến 15 triệu, thường là 25, 30 triệu, 50 triệu với chỉ 10 hay 15 người, và khi đó bạn rất có lãi (theo Garry, video đăng ngày 30/10/2026).

Paul làm phép tính: nếu bạn có 15 người, 2 triệu đô ARR mỗi người, với biên lợi nhuận 50%, thì mỗi người kiếm được một triệu đô một năm. Theo anh, đó là một kết quả tuyệt vời với rất nhiều người (phép tính theo lời Paul, video đăng ngày 30/10/2026).

Garry nói đồng thời YC làm rất nhiều buổi office hours với những người đã chạm tới thành công (anh dùng hình ảnh "brass ring") rồi lại buồn vì không gọi được Series A. Nhiều buổi office hours của anh chỉ là nói: có lẽ bạn sẽ nhìn lại chuyện này như một điều may mắn, vì bạn không cần tiền. Từng có thời bạn phải gọi khoảng 100 triệu đô để đạt khoảng 30 triệu đô doanh thu mỗi năm, vì phải tuyển hết chừng ấy người, còn bây giờ thì không cần (theo Garry, video đăng ngày 30/10/2026).

Paul nói trong giới startup có một chuyện có thật là "huy hiệu". Với anh cũng vậy: lúc đầu, gọi được vốn cảm giác như mình đang đạt được điều gì đó lớn lao. Nhưng giờ, trong đầu anh, việc thật sự không cần gọi vốn mới là đạt được điều lớn lao. Nên anh hơi ghen tị với những công ty đang đi tới được điểm đó (theo Paul, video đăng ngày 30/10/2026).

Garry nói đây là một thế giới thay đổi liên tục, nhưng trong mọi công ty, Supabase thật sự đã cưỡi được trên mọi làn sóng. Anh hỏi Paul có suy nghĩ gì cho những người đang cố làm theo những gì Paul đã làm (video đăng ngày 30/10/2026).

Paul nói một điều giúp anh ngủ ngon là hiệu ứng Lindy: database đã tồn tại 50 năm, anh nghĩ chúng sẽ còn tồn tại thêm 50 năm nữa, và đây là thứ mà dù AI đi tới đâu, anh khá chắc vẫn sẽ có database. Rút ra từ đó điều bạn muốn: bạn phải chọn những lĩnh vực (category) rất bền. Và nếu bạn đặt cược cả đời mình, về cơ bản là điều anh đang làm, hãy chọn lĩnh vực mà bạn thấy đáng để đầu tư (theo Paul, video đăng ngày 30/10/2026).

Điều thứ hai, theo Paul, là mọi thứ đang thay đổi rất nhanh. Supabase không cố có mọi câu trả lời, mà chỉ cố bảo đảm luôn thích nghi nhanh nhất. Anh đã đánh giá, hay đã quan sát, rất nhiều dev tool yêu thích của mình: chúng bắt đầu với tập trung vào developer, rồi luôn đi lên, trở nên rất "corporate", trì trệ nhiều và mất đi tình yêu đó. Từ góc nhìn của anh, những công ty như Stripe có một người, kiểu một founder, thật sự quan tâm gần như chỉ vào việc tập trung vào những cách build mới. Nên nếu bạn build cho làn sóng tiếp theo, bạn luôn phải để một mắt vào tương lai, vào thứ gì đến tiếp theo, mà giờ là một khung thời gian rất ngắn. Mọi thứ đi rất nhanh, nhưng hãy thật linh hoạt và bảo đảm team có năng lực dư để chuyển hướng thật nhanh. Đó là điều Supabase đang tập trung cho năm tới (theo Paul, video đăng ngày 30/10/2026).

Một host hỏi tiếp: có bài học cụ thể nào không? Supabase đã có điểm uốn vibe coding ban đầu, rồi điểm uốn Opus 4.8, và code gen nói chung. Khi làn sóng tiếp theo, hy vọng là thêm nhiều điểm uốn nữa, ập tới, Paul sẽ làm gì khác để chuẩn bị tốt hơn (video đăng ngày 30/10/2026)?

Paul nói trước hết, từ góc nhìn của Supabase, dogfooding là một trong những điều quan trọng nhất: anh luôn thử những công cụ đó cùng sản phẩm của Supabase để biết khoảng trống ở đâu, và không có feedback nào tốt hơn việc chính bạn bị kẹt trên công cụ của mình. Thứ hai là năng lực dư: Supabase cố hợp tác với những bên chủ chốt trong lĩnh vực, và lối chơi hệ sinh thái (ecosystem play) này rất hữu ích vì họ cho feedback về thứ họ đang build. Công ty cũng cố để lại chút năng lực dư trong team, điều cũng rất khó, để khi họ có ý tưởng thì Supabase có thể thử (theo Paul, video đăng ngày 30/10/2026).

Không nhiều canh bạc thật sự thắng, theo Paul, ngay cả khi có vẻ như hai bên đang hợp tác làm một thứ mới hay ho. Thật ra không ai biết trước. Chúng có thể nghe hay, anh và nhóm thử, rồi chúng thất bại. Nhưng những cái thành công thì rốt cuộc nghĩa là hai bên cùng cưỡi một làn sóng tuyệt vời (theo Paul, video đăng ngày 30/10/2026).

Một host khép lại: đó là một nốt kết rất hay. Anh cảm ơn Paul rất nhiều và hẹn gặp lại mọi người lần sau.