O czym jest ten film
- Rozmowa z Antem Wilsonem, współzałożycielem i dyrektorem technicznym Supabase — platformy open source, którą prowadził — wg słów prowadzącego — od zera do wyceny ponad 10 mld dolarów.
- Liczba spersonalizowanych narzędzi powstających w firmach eksplodowała: z trzech–czterech rocznie do setek — i to dopiero początek.
- Agenci AI to dziś „inżynierowie najwyższej klasy”: sami wybierają narzędzia, kierując się niezawodnością, bezpieczeństwem i dostępem do kodu — dlatego preferują open source.
- Supabase prowadzi własne ewaluacje dla agentów; dostawcy modeli wykorzystują je do poprawy tego, jak modele pracują z ich narzędziami.
- Ceny muszą się zmienić: idea „bazy danych na prompt” zamiast dwóch hojnych darmowych projektów; zapowiedź Supabase Light i Multigress — nieskończenie skalowalnego Postgresa.
- Panele administracyjne tracą znaczenie: przyszłością jest headless — pełna funkcjonalność przez API, MCP i wiersz poleceń.
- Bezpieczeństwo: otwarty kod jako tarcza w erze agentów pentestujących wszystko; prosty rytuał — poproś model o podstawowy test bezpieczeństwa przed każdym wdrożeniem.
- Firma wartą miliardy prowadzi się w pełni zdalnie, w 64 krajach; rekrutacja z grona contributorów open source i kultura „najpierw na piśmie” daje agentom gotowy kontekst.
- Rady dla założycieli: iteruj komunikat produktu tak samo mocno jak sam produkt (kluczowe okazało się hasło „open source’owa alternatywa dla Firebase”) i rozmawiaj z użytkownikami twarzą w twarz.
- Strategia w czasach AI to zakłady jak w pokerze (przykład: wejście w vibe coding), nie plany pięcioletnie — a skala adopcji narzędzi AI wciąż jest znikoma, więc okazji nigdy nie było więcej.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Buduj pod agentów tak, jak pod najlepszych inżynierów
Na czym polega: Agenci wybierają i używają narzędzi według kryteriów ścisłej czołówki inżynierów: niezawodność, bezpieczeństwo, wydajność, dostęp przez API i CLI. To, co dobre dla deweloperów, okazało się dobre dla agentów.
Jak stosować: Zrób audyt produktu pod kątem „czy każdą funkcję panelu da się wykonać programistycznie”. W inwestycjach najpierw stabilność i bezpieczeństwo, dopiero potem marketing i warstwa wizualna.
Na co uważać: Łatwo zoptymalizować to, co widać (interfejs), zamiast fundamentów — agentowi interfejs graficzny jest w zasadzie zbędny.
2.Iteruj komunikat produktu tak samo jak produkt
Na czym polega: Supabase było niezrozumiałe jako „baza Postgres w czasie rzeczywistym”. Dopiero hasło „open source’owa alternatywa dla Firebase” sprawiło, że odbiorcy mówili: „oczywiste, chcę tego spróbować”.
Jak stosować: Testuj kolejne sformułowania na pierwszych dziesięciu użytkownikach; zmieniaj komunikat, aż reakcją będzie „no jasne”. Umieść swój produkt wobec czegoś znanego (alternatywa dla X), a nie w kategoriach technologii.
Na co uważać: Język inżynierów opisujących budowę produktu rzadko trafia do odbiorcy — komunikat ma odpowiadać na pytanie „czyje jaki problem rozwiązuję”.
3.Kopia zawsze coś gubi — przewagę budujesz na głębi
Na czym polega: Według Wilsona każdy, kto replikuje czyjś produkt, skopiuje 99 rzeczy i przeoczy tę jedną, która faktycznie decyduje o jakości — i zwykle kopiuje też błędy. Fosą jest głębokie rozumienie problemu, dogfooding i realne rozmowy z klientami.
Jak stosować: Korzystaj z własnego produktu na serio, prowadź stałe rozmowy z użytkownikami i dokumentuj decyzje — to z tego rodzi się wartość, której nie da się przenieść.
Na co uważać: Pojawienie się naśladowców to nie powód do paniki; często umacnia kategorię. Nie odpowiadaj kopiowaniem ich rozwiązań.
4.Obserwuj pierwsze użycie — nic tego nie zastąpi
Na czym polega: Założyciele dopracowują zaawansowane funkcje, tymczasem nowy użytkownik nie może znaleźć przycisku. Sesja z kimś, kto widzi produkt pierwszy raz, ujawnia banalne, ale krytyczne problemy.
Jak stosować: Regularnie umawiaj krótkie rozmowy wideo z nowymi użytkownikami, milcz i patrz, poproś o komentowanie na głos. Rozmowa twarzą w twarz daje szczery obraz, którego ankiety nie dadzą.
Na co uważać: Na wczesnym etapie nie deleguj zbierania feedbacku do agentów — stracisz niuanse i szczerość; automatyzacja ma sens później.
5.Zbuduj ewaluacje swojego produktu pod agentów
Na czym polega: Supabase mierzy nie tylko to, że agent wybiera ich narzędzie, ale czy potem faktycznie odnosi w nim sukces. Dostawcy modeli używają tych ewaluacji, by poprawić pracę modeli z Supabase — a to zwraca się lepszym produktem.
Jak stosować: Przygotuj zestaw typowych zadań „od wyboru narzędzia do sprawnego użycia”, mierz wyniki przy każdym nowym modelu i udostępniaj je twórcom modeli.
Na co uważać: Ewaluacje wymagają utrzymania przy każdej zmianie API; mierz efekty końcowe, a nie samą popularność czy kliknięcia.
6.Otwarty kod jako strategia bezpieczeństwa
Na czym polega: Skoro agentów będzie próbowało się włamać wszędzie, otwarty kod oznacza więcej oczu — luki wyłapuje się znacznie wcześniej. Błędy są „płytkie”, gdy kod czyta wiele osób (i maszyn).
Jak stosować: Rozważ otwarcie kluczowych komponentów, a przynajmniej udostępnij kod do audytu wybranym partnerom; otwarta architektura ułatwia też agentom bezpieczne korzystanie z produktu.
Na co uważać: Open source nie zwalnia z utrzymania — wyścig zbrojeń w cyberbezpieczeństwie trwa nadal, tylko szybciej.
7.Minimalny rytuał bezpieczeństwa przed każdym wdrożeniem
Na czym polega: Najczęstszy błąd początkujących to wypuszczanie kodu na produkcję bez żadnego testu bezpieczeństwa. Prośba do modelu o podstawowy pentest łapie najłatwiejsze do wykorzystania luki — lepiej, niż zrobiłby to samodzielnie większość pojedynczych twórców.
Jak stosować: Przed release’em zapytaj model: „wymyśl dziesięć sposobów, jakimi ktoś mógłby to złamać, i sprawdź, czy jesteśmy chronieni”. Zamień to w stałą regułę uruchamianą przy każdym scaleniu do głównej gałęzi i wdrożeniu.
Na co uważać: Niektóre modele odmawiają, tłumacząc się brakiem uprawnień — wtedy użyj innego. To kosztuje tokeny, ale wypuszczenie dziury na produkcję kosztuje więcej.
8.Dawaj agentom bezpieczny dostęp do danych
Na czym polega: Zamiast wpuścić agenta na produkcyjną bazę z prawem zapisu: replika tylko do odczytu do analiz oraz osobna baza przypisana do gałęzi w Gicie do prac rozwojowych — agent może wtedy robić co chce, nie ruszając produkcji.
Jak stosować: Do analiz danych wystaw read replicę; do eksperymentów stawiaj odizolowane środowisko na gałąź. Dopiero przy zaufaniu rozszerzaj uprawnienia.
Na co uważać: Replika może być opóźniona względem produkcji, a środowisko testowe nie powinno zawierać danych wrażliwych „dla wygody”.
9.Headless first — panel przestaje być obowiązkowy
Na czym polega: Użytkownicy coraz częściej w ogóle nie wchodzą do paneli — proszą agenta o dane i wykresy. W Supabase wszystko, co da się zrobić w panelu, musi być dostępne przez API, serwer MCP i CLI. Nową firmę infrastrukturalną Wilson dziś kusiłoby budować w ogóle bez panelu.
Jak stosować: Przy każdej nowej funkcji kolejność: API, potem interfejs. Dokumentację trzymaj w markdownie i wystawiaj przez MCP, żeby agent znalazł wszystko sam.
Na co uważać: Nie każdy odbiorca jest gotowy na brak interfejsu (spore firmy wciąż chcą klikania), a bez panelu trudniej budować widoczność w wyszukiwarkach — decyzję warto uzależnić od grupy docelowej.
10.Kultura „najpierw na piśmie” to infrastruktura dla agentów
Na czym polega: W Supabase wszystko idzie do Slacka, Notion i Lineara, a rekrutacja z contributorów open source wstępnie weryfikuje umiejętność pracy asynchronicznej. Po latach ta pisemna historia stała się skarbem: agenci przeszukują cały kontekst, który w firmie spotkań by wyparował.
Jak stosować: Decyzje i ustalenia zapisuj, minimalizuj spotkania, oceniaj kandydatów po udokumentowanej pracy zdalnej (pull requesty, issues), nie po obecności na rozmowach.
Na co uważać: Nie każdy dobrze znosi brak bezpośredniego kontaktu — mów o tym wprost już w rekrutacji, bo „lubię pracować zdalnie” po pandemii mówi niemal każdy.
Redakcyjne tłumaczenie
(Informacja dodatkowa: rozmówcą jest Ant Wilson, współzałożyciel i dyrektor techniczny Supabase — automatyczna transkrypcja zniekształciła jego imię, podobnie jak nazwisko drugiego współzałożyciela, Paula Copplestone’a. W tekście mówcy oznaczeni są jako David — David Ondrej, prowadzący — oraz Ant.)
Zapowiedź
Ant: Trudność polegała na czym innym, niż się wydaje: mieliśmy świetny produkt, ale ogromne znaczenie ma to, jak o nim opowiadasz. Dopiero kiedy zmieniliśmy hasło na „open source’owa alternatywa dla Firebase”, ludzie mówili: „aha, oczywiście — chcę tego spróbować, tego potrzebuję, żeby prowadzić startup”. Każdy, kto próbuje to skopiować, dostaje zawsze niepełną replikę. Skopiuje dziewięćdziesiąt dziewięć rzeczy, a przeoczy tę jedną iskrę, która faktycznie decyduje, że twoja firma czy produkt jest naprawdę dobra.
Agenci to dziś inżynierowie oprogramowania najwyższej klasy. Obrona i atak rosną w zawrotnym tempie. Mieliśmy okres — chyba z pół roku — kiedy modele „maksymalizowały spinacze”: wyłączały RLS, żeby coś jak najszybciej zaczęło działać. Teraz poprawiają się w oszałamiającym tempie. A gdy kod jest otwarty, każdy może mu się przyjrzeć. Dziś, kiedy agenci będą próbować włamywać się do systemów, otwarty kod pozwala wyłapać wiele problemów znacznie wcześniej.
Przyszłość oprogramowania: setki spersonalizowanych narzędzi zamiast trzech
David: Ant, poprowadziłeś Supabase od zera do wyceny ponad dziesięciu miliardów dolarów. Jak widzisz przyszłość oprogramowania?
Ant: Już teraz widzimy dużą zmianę w stronę oprogramowania szytego na miarę. Liczba nowych projektów powstających wewnątrz firm — Supabase jest tu dobrym przykładem — po prostu eksplodowała. Każdy ma dziś własne narzędzia pod swój konkretny przypadek, pod zespół, pod wydzieloną komórkę organizacyjną. Kiedyś takie wewnętrzne narzędzie dało się wypuścić może trzy, cztery razy w roku — dziś to dosłownie setki. To się będzie kontynuować i miejmy nadzieję, że większość tego powstanie jako open source. My jesteśmy w pełni otwartą spółką i liczymy, że cała branża pójdzie w tę stronę — co dodatkowo oznacza komponenty wielokrotnego użytku.
Czy wszystko będzie open source?
David: Właśnie to miało być moje następne pytanie: czy wszystko będzie open source? Bo gdy modele będą wystarczająco mocne, będą w stanie przeklikać się przez cudzy software, zrozumieć, jak działa, i zbudować replikę w dziewięćdziesięciu procentach. Poza tym wybór fundamentu stanie się jawnym elementem decyzji: opcja A jest zamknięta, opcja B jest otwarta — mogę na niej uruchomić agentów i sprawdzić kwestie bezpieczeństwa. Jak myślisz?
Ant: Oby tak było. I jak powiedziałeś: agenci będą prawdopodobnie wybierać wersję otwartą zamiast zamkniętej, dokładnie tak, jak zawsze robili to deweloperzy. Jeśli dwa narzędzia robią to samo, a w jednym mogę przeczytać kod, wybiorę je bez wahania. Szczerze mówiąc, na tym zresztą częściowo stoi sukces Supabase: wszystko, co robimy, jest w pełni otwarte. Zawsze jednak będą siły, które z jakiegoś powodu nie chcą dzielić się kodem — i to jest całkowicie w porządku. Trzymam kciuki, żeby równowaga przesunęła się bardziej w stronę otwartości niż dziś.
David: A skoro o budowaniu własnego oprogramowania mowa — widzę dwie skrajne narracje. Jedni mówią: każdy sobie zbuduje własny kalendarz, zastąpi wszystko, SaaS umarł. Drudzy: bez zrozumienia niuansów, utrzymania i wiedzy domenowej się nie obejdzie. Gdzie jesteś?
Ant: Utrzymanie to zdecydowanie najważniejszy argument drugiej strony. Mam nadzieję, że nie stanie się tak, że wytwarzanie i utrzymanie oprogramowania będzie na stałe pochłaniać tak dużo tokenów jak dziś. Dlatego uważam, że jeśli wszystkie komponenty będą otwarte, agent nie będzie musiał za każdym razem pisać kodu od zera — po prostu poskłada gotowe, wielokrotnego użytku klocki. Dopóki tak się dzieje, cena nie musi być zaporowa i trend się utrzyma. Centralny SaaS istniał zawsze z jednego powodu: taniej było zapłacić komuś za uniwersalny kawałek software’u niż napisać własny. Jeśli sprawy potoczą się dalej w tę stronę, oprogramowanie spersonalizowane powinno robić się coraz tańsze.
Sekcja sponsorowana: CodeRabbit
(Informacja dodatkowa: poniższy fragment to czytany przez prowadzącego materiał reklamowy sponsora odcinka.)
David: Spójrzcie na ten wykres. Liczba krytycznych luk bezpieczeństwa rośnie wykładniczo — a to dane gigantów takich jak Adobe, Apple czy Google. Wyobraźcie sobie, ile dziur ma oprogramowanie pisane przez nas — zwłaszcza gdy uruchamiamy mnóstwo agentów AI. Dokładnie ten problem rozwiązuje CodeRabbit. Wyobraźcie sobie: agent kodujący otwiera pull request. Wszystkie testy przechodzą, wszystko wygląda dobrze, a CodeRabbit flaguje lukę — każdy zalogowany użytkownik może czytać dane wszystkich pozostałych. I nie pisze jedynie „to może być złe”. Pokazuje dokładną ścieżkę, którą obrałby atakujący — od publicznego punktu wejścia aż po podatną linię kodu — i mówi, jak prosty byłby taki atak. Jedno kliknięcie i CodeRabbit otwiera pull request z poprawką; wystarczy go scalić. Ale to wszystko dotyczy nowego kodu. A co z tym, który już wypuściliście? Dlatego jest DeepScan. DeepScan wysyła agentów AI przez całą bazę kodu. Śledzi, jak dane przepływają przez pliki i usługi — dokładnie tak, jak zrobiłby to napastnik — a potem weryfikuje każde pojedyncze znalezisko, zanim w ogóle trafi do waszych oczu. Nie dostajecie zatem ściany fałszywych alarmów. Pokrywany jest też kod, którego nie napisaliście: podatne pakiety open source, inwentarz wszystkich zależności oraz wycieknięte klucze API. Wszystko to w jednym panelu bezpieczeństwa. Nvidia, BMW, Clerk i Bun korzystają z CodeRabbit — wy też powinniście. Wypróbujcie czternaście dni za darmo, bez podawania karty. Pierwszy link pod filmem.
Jak budować produkty przyjazne agentom
David: A decyzje będą przecież podejmować agenci, nie ludzie. Jak zrobić oprogramowanie dobre dla agentów? Zawsze wystawiać API, zawsze mieć linię poleceń?
Ant: W pewnym sensie zawsze wkładaliśmy mnóstwo pracy w to, żeby nasz produkt był świetny dla deweloperów. I okazało się, że to, co świetne dla deweloperów, jest świetne dla agentów — bo agenci to dziś inżynierowie najwyższej klasy. Przez pierwsze lata bardzo pilnowaliśmy niezawodności, bezpieczeństwa i wydajności, tak aby wybitny inżynier wybrał właśnie nas. Ta praca w niczym się nie zmarnowała: agenci podejmują dziś decyzje w zasadzie według tych samych kryteriów.
Agenci jako kupujący: najlepszy produkt wygrywa
David: Widzisz więc, że decyzje zakupowe stają się bardziej świadome? Kiedyś dobrym działem sprzedaży i marketingem dało się sprzedać wiele rzeczy, a teraz agent mówi: „ moment — może te skarpetki nie muszą kosztować siedemdziesięciu dolarów, może znajdą się za dwadzieścia”? Jak to zmienia rynek, skoro każdy konsument i każda mała czy średnia firma ma dziś więcej wiedzy — dzięki asystentom albo agentom przy kodowaniu — i nie pozwoli sobie na zły zakup? Co to oznacza dla budujących biznesy?
Ant: Dokładnie to samo dotyczy infrastruktury i oprogramowania: miejmy nadzieję, że teraz po prostu wygrywać będą najlepsze produkty. Widzimy już stare taktyki SEO stosowane wobec agentów, żeby skłonić je do wypróbowania narzędzia. Ale my włożyliśmy dużo pracy w ewaluacje Supabase — tak, aby po tym, jak agent wybierze nas, faktycznie odniósł sukces w użyciu. Mierzymy te wyniki. Wielu dostawców modeli korzysta dziś z naszych ewaluacji, żeby poprawić zdolność modeli do pracy z Supabase, a to pomaga nam z kolei robić lepszy produkt, nastawiony konkretnie na agentów. Jeśli wszystko pójdzie tak jak dotąd, marketingowy szum powinien odgrywać mniejszą rolę niż kiedyś.
David: Czyli w równaniu sprzedaż–marketing–produkt waga produktu będzie rosła.
Ant: Oby.
Ceny: baza danych na prompt
David: A płatności? Wszyscy się zastanawiają: kredyty, rozliczenie za użycie, subskrypcje? Czy to, że coraz więcej zakupów robią agenci, radykalnie zmieni sposób wyceny?
Ant: Myślę, że tak — i już to u siebie widzimy. Nasze podejście do cen, gdy celowaliśmy w deweloperów, było takie: dwa projekty za darmo, bardzo hojne, żeby można było prowadzić cały biznes na Supabase bez płacenia. Dało się zajść bardzo daleko: baza działa całą dobę, można obsłużyć sporo klientów, zanim w ogóle trzeba zapłacić. Ale dziś agenci chcą — w praktyce — osobnej bazy danych na prompt, bo chcą przeprowadzać mnóstwo małych testów. Musimy się do tego dostosować i mamy zapowiedzi na wydarzeniu Supabase Select, które adresują właśnie ten problem.
Warsztat dyrektora technicznego: chmura, Claude i powrót do kodowania
David: A ty osobiście, jako CTO — ile czasu spędzasz jeszcze przy budowaniu? Jak wygląda twój zestaw narzędzi do kodowania z AI?
Ant: Co zaskakujące — więcej. Dzięki dużym modelom językowym mogę dziś budować więcej niż wcześniej. Przez kilka lat musiałem się skupiać na budowaniu firmy, w tym na zatrudnianiu ludzi, którzy piszą oprogramowanie lepiej ode mnie. Teraz mogę tworzyć wewnętrzne narzędzia — takie, których według mnie firmie brakowało — i wypuszczać je na produkcję w jeden weekend. To naprawdę przyjemne wrócić do budowania.
David: Konkretnie? Codex, Claude Code? Agenci lokalnie czy w chmurze? Wejdź w szczegóły.
Ant: Jestem wielkim zwolennikiem podejścia cloud-first, zawsze byłem. To zresztą jedna z motywacji do stworzenia Supabase — inspirował nas Firebase od Google’a, który od początku był rozwiązaniem chmurowym. Bardzo produktywne okazało mi się używanie Claude’a ze środowiskami chmurowymi. Ale jak każdy — gdy u Claude’a skończą mi się limity tokenów — przeskakuję do OpenAI i Codexa i pracuję dalej, aż limity się odnowią. Kręcę się więc między narzędziami. No i oczywiście na backendzie wszędzie używam Supabase, co jest ważne, bo budujemy na własnym produkcie — to tzw. dogfooding. Dbamy o to, żeby każdy nowy pracownik sam coś w nim zbudował. To jeden z głównych sposobów szybkiej iteracji.
David: Wspomniałeś, że Claude to twój ulubiony — czyli pewnie Opus 5?
Ant: Na ten moment tak. I jest taka zabawna rzecz, którą na X robią chyba wszyscy: gdy wychodzi nowy model, pierwszą rzeczą, jaką się buduje, jest gra. Bardzo lubię tworzyć gry 3D właśnie jako test możliwości modelu. Nie mam jeszcze odwagi pokazywać swoich projektów na Twitterze, ale chyba powinienem zacząć.
Czego brakuje do powszechnych agentów w chmurze
David: Wiele osób wciąż pracuje wyłącznie lokalnie, na laptopie. Czego brakuje do szerokiego przyjęcia agentów chmurowych? Może kwestii poświadczeń? Pewności, co agent właśnie robi? A może tego, o czym mówiłeś — możliwości użycia dowolnego modelu i dowolnego harnessa? Bo ludzie płacą dziś dwieście, a teraz pięćset dolarów za subskrypcje u OpenAI czy Anthropic i chcą wykorzystać te zasoby.
(Informacja dodatkowa: harness, czyli narzędzie-otoczka, w którym agent wykonuje zadania — na przykład Claude Code czy Codex.)
Ant: Szczerze? To kwestia preferencji. Zawsze istniało to przeciąganie liny między klientem a serwerem, między pracą lokalną a chmurową. Ja po prostu kocham pracę w chmurze — nie chcę tracić czasu na konfigurowanie lokalnego środowiska. Chcę mieć możliwość przejścia na nowy laptop i kontynuowania pracy jak gdyby nic się nie stało. Uważam, że dostawcy modeli są najlepsi na świecie w dostarczaniu samych modeli, ale w środowiskach chmurowych jest pewna luka, którą mogą wypełnić inne firmy. Znam kilka, które już to robią. Nie oczekuję, że producenci modeli muszą być też najlepsi w tej infrastrukturze — radzą sobie dobrze, ale na rynku jest mnóstwo miejsca dla specjalistów i na pewno się pojawią.
Materiał własny twórcy: Cloud Room
(Informacja dodatkowa: poniższy fragment to promocja własnego produktu prowadzącego, wstawiona w montażu po nagraniu rozmowy.)
David: Przy okazji: ten wywiad nagraliśmy tydzień przed premierą Cloud Room. Czego Ant nie wiedział — rozwiązaliśmy dokładnie problem, który właśnie opisał. W Cloud Room można uruchomić dowolnego agenta jako agenta chmurowego: Claude Code, Codex, Pi, Hermes czy jakikolwiek inny harness. Używacie ulubionych modeli, ulubionych narzędzi i swoich dotychczasowych subskrypcji — wszystko w jednym przejrzystym interfejsie. Możecie też użyć agenta chmurowego lokalnie jako worktree. Wybieracie harness i model — to pierwsza aplikacja na świecie, która pozwala uruchamiać dowolne harnessy i dowolne modele jako agenty chmurowe. Wydajemy ją przy tym w pełni jako open source, więc możecie zajrzeć w architekturę. Oferuję teraz osobiste rozmowy wdrożeniowe dla każdego, kto dołączy na planie pro albo ultra. Wejdźcie na cloudroom.dev — to drugi link pod filmem — w zakładkę z cenami. Dostaniecie wdrożenie przeprowadzone przeze mnie albo przez kogoś z zespołu: pomożemy ustawić Cloud Room, przejdziemy przez wszystkie funkcje i upewnimy się, że narzędzie działa dla was i waszych celów. Na planie pro dostajecie ponad tysiąc agentów chmurowych miesięcznie i ponad trzysta godzin obliczeń. Każdy agent działa w odizolowanym środowisku — każdy dostaje własny komputer w chmurze, pełną maszynę z Linuksem. Do tego kanał na Slacku, gdzie rozmawiacie ze mną bezpośrednio i zgłaszacie uwagi na bieżąco.
Ewaluacje: od mema z Williem Smithem do poziomu powyżej ludzkiego
David: Wspomniałeś o ewaluacjach wewnętrznych. Jak to wygląda, gdy wychodzi nowy agent? Nie wchodź w szczegóły, ale na co patrzycie? Niezawodność? Bezpieczny kod? To, żeby nie zaśmiecał plików bezużytecznymi komentarzami?
Ant: Świetny przykład to mem z Williem Smithem jedzącym spaghetti — dużo o tym myślę w takich kategoriach.
(Informacja dodatkowa: mem z 2023 roku, oparty na filmie wygenerowanym przez wczesną wersję AI, w którym Will Smith niedorzecznie zjada spaghetti — symbol żenująco słabej jakości pierwszych generacji; tu metafora dojrzewania modeli.)
Gdy modele dopiero się pojawiły, zaczynały używać Supabase i wyprawiały szalone rzeczy. Mamy usługę przechowywania plików — Supabase Storage — a modele z jakiegoś powodu próbowały upychać dane obrazów bezpośrednio do bazy Postgresa. Mieliśmy ten okres, chyba z pół roku, kiedy „maksymalizowały spinacze” — wyłączały RLS, żeby coś szybko ruszyło.
(Informacja dodatkowa: RLS, czyli Row Level Security — mechanizm Postgresa ograniczający dostęp do poszczególnych wierszy tabeli na poziomie bazy danych; jego wyłączenie otwiera dane każdemu. „Maksymalizator spinaczy” to z kolei myślowy eksperyment o AI realizującym cel dosłownie, po drodze niszcząc wszystko inne — tu: modele idące na skróty.)
Na szczęście to za nami. Jesteśmy teraz na dojrzałym końcu tego mema — agenci radzą sobie z Supabase chyba lepiej niż ludzie. Musimy tylko dbać, żeby używali wszystkich komponentów we właściwy sposób i pisali kod bezpieczny, stabilny i wydajny. I szczerze — w ostatnim miesiącu poprawiają się w zawrotnym tempie. Wspomniałeś o Opusie 5.5 — to jest po prostu nieporównywalnie lepsze od wszystkiego, co było choćby trzy, cztery miesiące temu.
Jak bezpiecznie wpuścić agenta do bazy danych
David: Skoro agenci sięgają po bazy danych — ludzie obawiają się dawania im dostępu do produkcji, do odczytu i zapisu. Jak krok po kroku zbudować sobie komfort, żeby pozwolić agentowi choćby na czytanie danych?
Ant: Mądrze zrobiony jest u nas mechanizm replik: obok głównej, produkcyjnej bazy, do której można czytać i pisać, stawiasz tzw. read replicę — węzeł, z którego da się wyłącznie czytać. To dobry sposób na dostęp dla agenta, jeśli chcesz wykonać analizę danych: nie musisz się martwić, że agent wywali wszystkie tabele albo coś namiesza w wierszach. Równolegle zawsze głosiliśmy klasyczny układ deweloperski: jeśli pracujesz na gałęzi w Gicie, rozgałęzienie w Supabase daje ci osobną bazę dedykowaną właśnie tej gałęzi. Wtedy nie ma znaczenia, czy agent odjeżdża z pomysłami — dane produkcyjne pozostają nietknięte.
Jak działa firma warta dziesięć miliardów
David: Pytanie bardzo ogólne: co jest potrzebne, by zbudować firmę wartą dziesięć miliardów dolarów? Czym to się różni od etapu miliona, dziesięciu milionów, stu milionów? Co się dzieje na tej skali?
Ant: To naprawdę szalone. I zabawne: ponieważ Supabase jest w pełni zdalne, codzienność niewiele różni się od czasów, gdy było nas dwadzieścia osób. Nadal pracuję z domu, rano otwieram laptopa. Jest więcej ludzi na Slacku, ktoś dołącza praktycznie co tydzień — ale kiedy siadam do pracy, sama praca wygląda niemal tak samo. Zmieniło się to, że przez ostatnie lata pracuję z bardziej doświadczonymi dyrektorami. Dbamy jednak, by wszyscy oni byli ludźmi technicznymi i bardzo głęboko rozumieli produkt. W ten sposób to znowu po prostu praca z ludźmi wybitnymi w swoim fachu — z domowego biura. Nie mamy wielkiej siedziby jak Nvidia czy Google, gdzie widzi się wszystkich na żywo. Szczerze mówiąc — nie czuję wielkiej różnicy.
David: A na poziomie produktu? To ciągły proces, czy raczej „przed dopasowaniem do rynku” i „po”? Jak mają o tym myśleć ludzie z ambicją budowania dużej firmy?
Ant: Pod pewnymi względami mieliśmy szczęście, bo bardzo wcześnie zobaczyliśmy sygnały dopasowania produktu do rynku. Gdy mój współzałożyciel Paul Copplestone pierwszy raz powiedział mi, co chce zrobić, brzmiało to tak: Firebase od Google’a to świetna baza, ale jest własnościowa, ma ograniczenia skalowania i — właśnie dlatego, że jest zamknięta — nie mam możliwości wejść i naprawić czegoś samodzielnie; trzeba czekać, aż zrobi to ktoś inny. On chciał zbudować to na Postgresie, w pełni otwartej bazie, i wszystkie komponenty oddać każdemu jako open source. To brzmiało jak coś, co zawsze powinno istnieć na świecie. Nawet mnie aż to porwało — wiedziałem, że gdy tylko pokażemy to pierwszym dziesięciu deweloperom, oni też pomyślą: „no jasne, to oczywistość, takie coś powinno istnieć”. Trudność była gdzie indziej: mieliśmy świetny produkt, ale kluczowe jest, jak o nim opowiadasz. Na począteku mówiliśmy ludziom: mamy świetną rzecz — bazę Postgresa w czasie rzeczywistym. Ludzie nie bardzo wiedzieli, o co chodzi. Dopiero zmiana hasła na „open source’ową alternatywę dla Firebase” sprawiła, że mówili: „aha, jasne — chcę tego spróbować, tego potrzebuję do prowadzenia startupu”. Tak, potrzebujesz świetnego produktu — ale zachęcam każdego: iteruj to, jak komunikujesz, co robisz, aż staniesz się bardzo precyzyjny i bardzo dobry w tym przekazie.
Szybkość czy jakość? Rozmawiaj z użytkownikami
David: W tej erze każdy buduje szybciej. Jak balansować między dopracowaniem rzeczy naprawdę dobrej a szybkim wypuszczeniem?
Ant: Zabawne — dziś szybciej niż kiedykolwiek możesz zbudować niewłaściwą rzecz. Znam też kuszenie, żeby dodawać funkcje i jeszcze funkcje przed pokazaniem czegokolwiek użytkownikom; tak łatwo zamknąć się w tej bańce. Dlatego dziś bardziej niż kiedykolwiek trzeba jak najszybciej pokazać produkt prawdziwym użytkownikom. I nie licz na to, że „zbuduję sobie agentów do zbierania opinii”. To ważne później — ale na początku musisz rozmawiać z ludźmi używającymi twojego produktu twarzą w twarz albo przynajmniej na wideorozmowie, bo tylko tak poznasz szczeryą prawdę o tym, czy budujesz właściwą rzecz.
David: Zwłaszcza gdy patrzysz, jak ktoś używa twojego oprogramowania po raz pierwszy. Deweloperzy i założyciele często popełniają błąd: dopracowują zaawansowane funkcje, a strona główna myli, ludzie nie mogą znaleźć przycisku. Wystarczy jedna rozmowa wideo z osobą, która widzi produkt pierwszy raz, żeby powiedzieć: „ojej, przecież oczywiste — ten przycisk powinien być dużo większy, a ten krok można wywalić”.
Ant: Dokładnie. Sam musiałem się tego nauczyć: naprawdę nic nie zastąpi rozmowy z klientem. Choć to rada stara jak świat, wciąż jest najlepsza.
David: Ważniejsza niż kiedykolwiek.
Zaufanie wielkich korporacji
David: Jak zdobywacie zaufanie większych firm? Ostatnio się przekonałem, że w firmach z listy Fortune 100 nawet coś takiego jak Cloudflare uchodzi za ryzykowne — idą tylko z AWS, GCP albo Azure. Jak o tym myślicie?
Ant: Na szczęście w Fortune 500 jest segment bardziej „chmurowo nastawiony”, otwartych na próbowanie nowych rzeczy — i widać, że te firmy iterują znacznie szybciej niż konkurencja. Z czasem ciężkie giganci w zasadzie nie będą mieli wyboru i będą musieli przyjąć wiele z tych nowych narzędzi. A druga ciekawa rzecz, o której już częściowo mówiliśmy: tak jak ja mam teraz więcej czasu na budowanie jako osoba na szczeblu zarządu, tak samo w wielkich firmach chief product officerowie i CTO-owie, którzy przez dziesięć lat niczego nie budowali, dzwonią do mnie: „Zacząłem używać Lovable i Supabase — i nagle wypuszczam mnóstwo rzeczy wewnętrznie”. Dajemy tym ludziom narzędzia, więc zmiana zaczyna zachodzić też odgórnie. My w Supabase zawsze stawialiśmy na adopcję oddolną w dużych organizacjach: deweloperzy pokochali budowanie z nami i sami wprowadzali nasze narzędzie do zespołów. Teraz, dzięki AI, widzimy ten proces również od góry. To naprawdę ekscytujący moment, by przedsiębiorstwa zaczynały stosować te narzędzia.
Wszystkie role zbiegają się w rolę buildera
David: Czy widzisz, że role w firmie zbiegają się w jedną — buildera? Kiedyś: projektant, product manager, programista. A dziś każdy z nich potrafi zrobić resztę?
Ant: Widzimy to i u siebie. Oczywiście nadal mamy specjalistów od bardzo niszowych fragmentów oprogramowania czy designu i te umiejętności są bardzo cenne. Ale coraz częściej nasi inżynierowie-designerzy wypuszczają rzeczy na produkcję samodzielnie, bez przekazywania pracy dalej przez ścianę do kogoś innego.
Czy warto być technicznym? Lęk przed lokalnym maksimum
David: A samo bycie technicznym? Dwa lata temu pytanie brzmiało: „czy uczyć się programować?”. Zadam je inaczej: czy ludzie powinni dążyć do bycia bardziej technicznymi — rozumieć projektowanie systemów, informatykę? Czy to delegujemy agentowi, bo następna generacja modeli będzie wszystko umiała?
Ant: Uważam, że te umiejętności wciąż są ważne. Moja obawa związana z agentami robiącymi wszystko jest taka: mam nadzieję, że nie ustali się przekonanie, że istnieje tylko jeden sposób budowania oprogramowania. Zawsze było przeciąganie liny między różnymi podejściami — metodą kaskadową czy zwinnością, sprintami, test-driven development, programowaniem w parach… Mam nadzieję, że nadal będzie wiele różnych poglądów na to, jak powstaje oprogramowanie. Inaczej boję się, że wpadniemy w jakieś lokalne maksimum: wszystkie modele będą robić to jednym sposobem, a my przegapimy inne drogi do postępu.
Cyberbezpieczeństwo: atak i obrona przyspieszają
David: A cyberbezpieczeństwo — w świecie, gdzie agenci mogą testować odporność twojego i cudzego oprogramowania? Powstaje więcej kodu niż kiedykolwiek. Tworzenie nowego ekscituje, ale poświęcenie tyle samo czasu na testy bezpieczeństwa — już niekoniecznie. Jak o tym myślisz, zwłaszcza z modelami gotowymi zrobić niemal wszystko?
Ant: Obrona i atak rozwijają się w szalonym tempie. I właśnie tu widzę świetny argument za otwartym kodem, bo zawsze było prawdą, że gdy kod jest jawny, każdy może mu się przyjrzeć — a błędy są bardzo płytkie, gdy czyta go wiele osób. Dziś, skoro agenci będą próbować się wciskać do systemów, otwarty kod pozwala wyłapać mnóstwo problemów znacznie wcześniej. To moim zdaniem dobra strategia. Trzeba jednak po prostu nadążać: w cyberbezpieczeństwie zawsze była to zabawa w kotka i myszkę — i tak zostanie, tylko w przyspieszonym tempie.
Najczęstsze błędy bezpieczeństwa nowych builderów
David: A najczęstsze błędy ludzi, którzy dopiero zaczynają budować? Wspomniałeś o brakującym RLS — co jeszcze?
Ant: Zasadniczo jedno: nieproszenie agenta o podstawowe testy bezpieczeństwa przed wypuszczeniem na produkcję. To prosty krok, a modele radzą sobie z tym znacznie lepiej, niż zrobiłbym to ja sam na własną rękę. Oczywiście w Supabase mamy duży, wybitny zespół security, ale jeśli budujesz w pojedynkę — po prostu poproś model: „zrób mi podstawowy test bezpieczeństwa”. Zdarzało się, że model się wycofywał i mówił: „nie mam uprawnień” — ale nawet starsze generacje świetnie wyłapują najłatwiejsze do wykorzystania luki.
David: Czyli: przed wydaniem posiedzieć trzydzieści minut z najlepszym modelem i zapytać, jak ktoś mógłby zaatakować projekt tego typu?
Ant: Dokładnie. Powiedz: „wymyśl dziesięć sposobów, jakimi ktoś mógłby to zepsuć, i zweryfikuj, że jesteśmy przed nimi chronieni”. A potem może zapisz regułę: „za każdym razem, gdy scalamy do głównej gałęzi i wypychamy na produkcję — wykonaj ten podstawowy test”. Tak, kosztuje to sporo tokenów. Ale warto — zdecydowanie lepiej niż wypuszczać oprogramowanie z dziurami.
Dlaczego Supabase jest w pełni zdalne
David: Dlaczego właściwie pełna zdalność?
Ant: Zawsze tego chcieliśmy. Przez pierwsze lata kariery pracowałem w biurach i nigdy nie mogłem pojąć, dlaczego mam tracić kilka godzin dziennie na dojazdy, skoro ten czas można przeznaczyć na coś produkcyjniejszego. Do tego dochodzi zaleta: możemy znaleźć najlepszą osobę na świecie do konkretnego zadania. Nie ma znaczenia, czy jest w San Francisco, w Peru czy w Brunei — jeśli jest w czymś wybitna, może u nas pracować. I nikt nie marnuje czasu na dojazdy. Jestem w tej sprawie bardzo zapatrzony: praca z biura to moim zdaniem zła droga.
Rekrutacja z open source i kultura pisemna
David: Zatrudniliście wielu najlepszych współtwórców open source. Jak ważne jest „podkupowanie” najlepszych contributorów dla projektu, który chce stać się firmą?
Ant: Najważniejszy aspekt to znajdowanie ludzi świetnie pracujących asynchronicznie. Deweloperzy open source nie potrzebują bezpośredniego kontaktu, nie chcą skakać na szybkie rozmowy ani mieć regularnych spotkań — chcą wejść na GitHuba, przeczytać issues, dać swoją opinię i iść dalej. W firmie takiej jak nasza — mamy dziś ludzi w sześćdziesięciu czterech krajach, pełne pokrycie globu — nie możesz czekać, aż ktoś będzie dostępny na callu, żeby wypuścić kolejną rzecz. Zatrudnianie z open source daje ludzi wstępnie zweryfikowanych pod kątem takiego stylu pracy. Druga rzecz, z której bardzo skorzystaliśmy: zawsze stawialiśmy na piśmienność — wszystko idzie do Slacka, Notion albo Lineara. A teraz, gdy mamy agentów świetnie przeszukujących całą tę historię, cały kontekst pozostaje dostępny. Gdybyśmy ostatnie pięć lat pracowali głównie na żywo, mnóstwo tych rozmów i wiedzy wyparowałoby w nicość.
David: Ale jak dobieracie ludzi, którzy faktycznie będą produktywni na zdalnie? Po pandemii wielu ludzi brało dwa etaty naraz, gotowało obiad, opiekowało się dzieckiem… Skąd pewność, że wyniki będą jak na miejscu?
Ant: Trzeba być z ludźmi szczerym: jeśli nie jesteś osobą, która kocha brak bezpośredniego kontaktu, jeśli nie lubisz, gdy zostawia się cię samemu sobie — i potrafisz przy tym być bardzo produktywny — to w Supabase będziesz mieć fatalnie. Po COVID wielu kandydatów mówiło: „tak, pracuję zdalnie, uwielbiam”. Potem dołączali i — ponieważ u nas nie ma ani wielu spotkań, ani obecności na żywo — po kilku miesiącach mówili: „mam bardzo ciężko, nie wiem, czy to firma dla mnie”. Szczerość już na etapie rekrutacji okazała się dobrym filtrem. A poza tym, jak wspominałem, open source daje nam możliwość współpracy z ludźmi, zanim dołączą: mogą nam udowodnić, że będą wybitni i samodzielnie zmotywowani, że nie musimy ich rozpalać i pytać, co zrobią w tym tygodniu. Kochają to, co robią, i po prostu będą budować, dopóki zadanie nie będzie skończone.
David: Czy AI zmieniło to, kogo zatrudniacie?
Ant: Powiedziałbym tak: najlepsi ludzie w Supabase — ci, których można nazwać inżynierami 10x, dowożący wielokrotnie więcej niż przeciętni — dostają teraz dzięki narzędziom AI jeszcze większą dźwignię. Jeśli będziemy nadal zatrudniać właśnie ten typ osoby, to z reguły są to również ci, którzy świetnie programują razem z AI. Jestem bardzo ciekaw nowego pokolenia absolwentów. Mam nadzieję, że idea ludzi „rodzonych z AI” jest prawdziwa — ale musimy to zobaczyć. Bo ci nasi „dziesięciokrotni” są typowo w sześciu, siedmiu, ośmiu roku kariery. Bardzo bym się cieszył, gdyby dziś absolwenci informatyki też mogli dostać taką dźwignię. Będzie fajnie na to patrzeć.
Czym jest dziś fosa
David: Skoro każdy może zbudować cokolwiek szybciej niż kiedykolwiek — czym jest dziś fosa dla firmy software’owej? Efekty sieciowe? Co was chroni?
Ant: To, o czym już rozmawialiśmy: rozmowy z użytkownikami i ludzka więź. Wiele osób chce zautomatyzować absolutnie wszystko. A kluczem jest umiejętność wskazania, które elementy biznesu i sposobu budowania produktu nadal powinny przelatywać przez twoją głowę i którym poświęcasz czas myślenia. Jeśli to zrobisz dobrze, budujesz rzeczy trudniejsze do skopiowania. Od pierwszego roku, gdy zyskaliśmy trakcję, mnóstwo ludzi nas kopiuje. Widać to po tym, że kopiują również błędy — zabawny widok na rynku. Powstało sporo firm wokół Postgresa i szczerze mówiąc: kochamy to, bo to więcej osób budujących lepsze narzędzia dla całego ekosystemu — a to czyni nas, naszych użytkowników i użytkowników naszych użytkowników skuteczniejszymi. Ale im mocniej oprzesz się pokusie kopiowania cudzych sukcesów i im bardziej pomyślisz, gdzie naprawdę możesz dowieźć wartość — a to przychodzi z prawdziwych rozmów z prawdziwymi klientami — tym lepiej. Nie mogę przesadnie podkreślić, jak to jest ważne.
David: Czyli: rozumieć problem głębiej niż ktokolwiek inny, schodzić do detali, używać własnego produktu na co dzień i autentycznie obchodzić cię ten problem.
Ant: Dokładnie. I każdy, kto próbuje to odwzorować, zawsze dostaje niepełną replikę. Skopiuje dziewięćdziesiąt dziewięć rzeczy, a przegapi jeden samorodek, który faktycznie czyni twoją firmę lub produkt naprawdę dobrym.
Zakłady zamiast planów pięcioletnich
David: Skoro agenci przejmują coraz więcej zadań — czy cała branża wiedzy w software zredukuje się do dwóch kategorii: inferencji i hostingu, a resztę będzie dało się rozwiązać tokenami? Agent potrzebuje tylko własnej bazy i własnego komputera.
Ant: Może. Staram się nie spędzać zbyt wiele czasu na spekulacjach, w co świat się zredukuje. Skupiam się na byciu najlepszym w tym, co robimy — zawsze. I nadal prawdą jest, że najważniejsza jest obsesja na punkcie klienta. Zabawne, że z współzałożycielem mamy dwa nieco różne podejścia. On jest bardziej wizjonerem: patrzy w przyszłość i myśli, na ile sposobów zmieni się świat i gdzie musimy wtedy stanąć. Ja jestem bardziej od strony: „jakie pięć rzeczy najprawdopodobniej zabije nas w przyszłym tygodniu i jak się przed nimi zabezpieczyć”.
David: Trochę jak Steve Jobs i Steve Wozniak?
Ant: Może — choć porównywanie się do tych ludzi to lekkie nadymanie się. Paul ma zdecydowanie mocne poglądy na temat tego, dokąd zmierza świat. Ja muszę tylko upewnić się, że nie wysadzimy firmy w powietrze w najbliższych kilku tygodniach.
David: To zresztą miało być moje kolejne pytanie: przy tak szybkich zmianach da się w ogóle planować na pięć lat, na trzy? Czy tylko kwartał, może pół roku?
Ant: Zdecydowanie. Przeżyliśmy to dosłownie dwa lata temu, gdy pojawiły się pierwsze platformy do vibe codingu: nasz nowy ruch u samego wejścia do lejka eksplodował, ale nie było jasne, czy ten nowy typ użytkownika w ogóle skonwertuje, zapłaci, czy to się utrzyma — czy ci ludzie naprawdę będą w stanie budować produkty, które sami zmonetyzują. Musieliśmy postawić zakład: czy przychylamy się temu przez najbliższych osiemnaście miesięcy? I cieszymy się, że tak — okazało się, że to była znacząca zmiana w sposobie powstawania oprogramowania. Modele na początku były trochę słabe, ale nie było żadnego fragmentu cyklu życia oprogramowania, w którym nie widzielibyśmy szybkiej poprawy — bardzo szybko pokazały się postępy w bezpieczeństwie, testowaniu, niezawodności. Cieszymy się, że postawiliśmy ten zakład. Ale masz rację: takie chwile zdarzają się okazjonalnie i trzeba — jak w pokerze — zdecydować: sześćdziesiąt procent żetonów tu, czterdzieści tam, i mieć nadzieję, że te sześćdziesiąt się zwróci.
Co ogranicza kolejny skok
David: A jakie są dziś wąskie gardła kolejnego dziesięciokrotnego wzrostu? Ambicją jest przecież zostanie „open source’owym Oracle’em”.
Ant: Gdybyś zapytał mnie o to przed erą vibe codingu — jak dziesięciokrotnie zwiększyć napływ nowych użytkowników — powiedziałbym, że oszalałeś. Byliśmy już bardzo znani wśród deweloperów webowych na całym świecie. A mimo to wciąż jest bardzo wcześnie. Grupa ludzi faktycznie używających tych narzędzi do budowania prawdziwego oprogramowania na produkcję to wciąż mały odsetek populacji. Kiedy reszta świata zorientuje się, jak łatwe to się robi, zobaczymy kolejny skok adopcji wszystkich narzędzi deweloperskich.
David: Łatwo siedzieć na Twitterze, patrzeć, jak wszyscy coś budują, i czuć, że się odpada. A potem wyjść na ulicę: ludzie spróbowali ChatGPT dwa lata temu i myślą, że nadal tak to wygląda. Odsetek osób z płatną subskrypcją do kodowania to ułamek ułamka. Dobrze, że mówisz, jak wcześnie jesteśmy — bo w bańce AI ludzie powtarzają, że nie zostało nic do zbudowania, że po wszystkim. A patrząc z szerszej perspektywy — okazji nigdy nie było więcej niż teraz.
Ant: Zdecydowanie tak.
Y Combinator: pięć prób i sześćdziesiąt procent batcha
David: Aplikowaliście do Y Combinator chyba pięć razy, zanim was przyjęto. Co myślisz o YC dziś? Aplikowałbyś, startując teraz nową firmę?
Ant: Najpierw sprostowanie: ja aplikowałem pięć razy. Mój współzałożyciel dostał się za pierwszym razem — wtedy, gdy aplikowaliśmy razem. Więc chyba jemu mam za co dziękować. Ludzie zadają to pytanie co roku, przy każdym powiększającym się batchu: czy YC wciąż daje tę samą wartość? Moim zdaniem daje więcej niż kiedykolwiek — przez społeczność, do której zyskujesz dostęp. Prawdziwy powód, dla którego chcieliśmy się dostać, był taki: trafiasz do grupy ludzi, którzy z samej definicji chętnie sięgają po nowości. Jeśli budujesz coś takiego jak Supabase, to najlepsze możliwe miejsce, by ludzie wypróbowali twój software. To nadal prawda — w ostatnim batchu YC, o ile wiem, sześćdziesiąt procent firm buduje na Supabase.
David: Nieźle.
Ant: Wkładamy dużo pracy, by tę liczbę podnosić. To świetny powód, by aplikować do YC przy czymkolwiek związanym z narzędziami dla deweloperów: ci ludzie znacznie chętniej wypróbują nasze nowości, a my dostajemy feedback błyskawicznie. Poza tym sami w YC działają — Garry Tan osobiście buduje narzędzia AI. Nie zobaczysz tego u każdego funduszu.
Supabase Light: zbuduj w piętnaście minut, skaluj do milionów
David: Opowiedz o Supabase Light. Po co to powstaje? Jakie trendy w rodzajach oprogramowania, które agenci lubią, to odzwierciedla?
Ant: Wspominałem, że nasz stary model cenowy dawał dwa duże darmowe projekty do dowolnego użytku. Model się zmienił: każdy prompt może — i powinien — być osobną bazą danych. Chcieliśmy więc oddać znacznie więcej darmowych projektów, żeby ludzie przetestowali znacznie więcej pomysłów. A ważne jest to, że gdy projekt zaczyna rosnąć, w tle migrujemy cię na prawdziwą, dedykowaną instancję Postgresa — bez żadnego przestoju. Nasze hasło brzmiało kiedyś: „zbuduj w weekend, skaluj do milionów”. Tyle że to już nie jest weekend — to piętnaście minut. A skalowanie do milionów, gdy ktoś naprawdę trafi w potrzebę, odbywa się w tydzień. Nasz model to teraz: rozwiąż problem „zbuduj w piętnaście minut” z Supabase Light, potem migruj ludzi na dzisiejsze, pełne Supabase, a gdy trzeba skalować do milionów i dalej — mamy Multigress, w założeniu nieskończenie skalowalny Postgres. Zrobione poprawnie, nie powinieneś nawet zauważyć, że backend przeszedł przez te trzy etapy. Budowanie dla jednego użytkownika powinno wyglądać tak samo jak dla milionów czy miliardów.
Czy trzeba jeszcze rozumieć infrastrukturę?
David: A jak ludzie mają dziś rozumieć wydajność bazy? Wiedzieć, że czegoś nie ma w bazie, co powinno być? Czego się uczyć — architektury kodu, projektowania systemów? Składni języka już nie, bo agent potrafi zrefaktoryzować cały kod. Choć pewnie każdy powinien choć wiedzieć, że jest na Postgresie…
Ant: Prawdziwa odpowiedź jest taka: jeśli budujesz z tymi agentowymi narzędziami, nie powinieneś musieć się tym przejmować. Ewolucja infrastruktury w ostatnich dziesięciu, piętnastu latach polegała na tym, że dostawcy chmur brali na siebie coraz większą część stosu. Gdy pojawiło się AWS, rewolucyjne było już to, że można wejść na stronę i postawić usługi. Potem zobaczyliśmy firmy takie jak Vercel: „nie chcę nawet wchodzić na stronę i zarządzać tym, jak te usługi do siebie pasują — chcę wszystko z wiersza poleceń, nie muszę wiedzieć, jak serwery są połączone, zrób to za mnie”. To trwa nadal — dziś wielu ludzi budujących przez vibe coding nie interesuje się szczegółami w stylu „na jakim jestem serwerze” albo „czy pewne indeksy w bazie istnieją”. Powinieneś móc oddać to agentowi i dostawcy infrastruktury — oni to niech prowadzą.
David: Czyli przesuwacie tarcie tak, żeby człowiek i jego agent budowali dobrze bez zastanawiania się nad indeksami. Dobre praktyki siedzą w umiejętnościach agenta, a człowiek mu ufa.
Ant: Dokładnie. A tempo postępu z ostatnich osiemnastu miesięcy na pewno się utrzyma. Nie ma takiej wysoce wyspecjalizowanej umiejętności, w której agent nie zrobiłby lepiej niż ja.
Headless zamiast paneli
David: A dla firm, które już mają swoje oprogramowanie — jakie triki sprawiają, że agenci łatwiej go użyją? Mówiliśmy o dokumentacji w markdownie…
Ant: Główna rzecz jest trochę smutna: włożyliśmy tak wiele pracy przez pierwsze pięć lat w nasz panel. Chcieliśmy, żeby to było najlepsze możliwe doświadczenie — i myślę, że wyszło przyzwoicie. A teraz ludzie nie chcą do tego panelu wchodzić. Chcą po prostu poprosić agenta o dane i ich wizualizację — wszystko przez interfejs agenta. Więc „bycie headless” to najprostsza pierwsza odpowiedź: wszystko, co da się zrobić w panelu Supabase, powinno dać się zrobić przez API, przez serwer MCP, przez wiersz poleceń — bez żadnej różnicy w możliwościach.
(Informacja dodatkowa: MCP, czyli Model Context Protocol — otwarty standard łączenia modeli z zewnętrznymi narzędziami i danymi.)
Gdybym dziś zakładał nową firmę infrastrukturalną, kusiłoby mnie, żeby w ogóle nie robić panelu — i sprawdzić, jak daleko zajdę, dając agentom narzędzia do zrobienia wszystkiego i wizualizowania tego w ich własnym interfejsie.
David: Widzimy to: produkty takie jak Instant nie mają nawet własnego interfejsu — rozmawiasz z agentem i agent to robi. Kiedyś uważaliśmy, że warto mieć widoczność w wyszukiwarkach; czasy się zmieniły. Ludzie nie chcą uczyć się kolejnego panelu i rozkładu przycisków. Po prostu: „powiedz mi, gdzie jest sekcja kluczy API, gdzie uwierzytelnianie” — i agent albo wskaże kierunek i da link, albo sam przeklika i ustawi.
Ant: Szalone czasy.
Gdzie jest „następny Bitcoin”?
David: Jakie okazje mamy przed sobą? Słynnie przeczytałeś white paper Bitcoina w 2012 roku i żałujesz, że nie wszedłeś głębiej — jak zresztą każdy. Co jest dzisiejszym odpowiednikiem?
Ant: Gdybym wiedział, jaka jest następna okazja skali Bitcoina, byłbym bardzo bogaty. Nie będę udawał, że to wiem. Myślę, że — jak rozmawialiśmy — samo bycie w branży, budowanie, praktyka, wypróbowywanie wszystkiego i trzymanie się na froncie stawia cię w bardzo dobrej pozycji na cokolwiek, co nadejdzie. I nie zamartwiaj się, że to ty musisz być osobą z wielkim olśnieniem co do zmiany świata. Nauczyliśmy się w ostatnich latach, że nikt nie był w stanie przewidzieć sytuacji, w której się znaleźliśmy. Może Sam Altman i Dario Amodei mieli jakieś przeczucie, że świat zmieni się właśnie w ten sposób. Ale po prostu: bądź na froncie, buduj dalej, a znajdziesz się w bardzo dobrej pozycji.
David: Czyli zrobić wszystko, żeby zostawać na ostrzu, mieć otwarty umysł i komfort w szybko zmieniającym się otoczeniu — i patrzeć, dokąd to zmierza.
Ant: Zdecydowanie. Nie będę czynił wielkich deklaracji o tym, jak świat będzie działał za dziesięć lat — bo moim zdaniem nikt tego nie wie.
David: No to możemy kończyć. Dziękuję bardzo.
Ant: Dzięki, stary. Świetna rozmowa.