Notatki z prezentacji Aparny Sinhy (SVP of Product, Vercel) zatytułowanej „The Velocity Advantage: How AI-Native Teams Ship Products Fast and Safe„, wygłoszonej w San Francisco. Wszystkie przemyślenia, obserwacje i wnioski w tym artykule pochodzą od prelegentki.

TL;DR:

Budowanie w AI przypomina budowanie podczas trzęsienia ziemi – najlepszy model zmienia się wielokrotnie dziennie, co wymaga elastycznej infrastruktury
Cztery filary przewagi szybkości: elastyczna infrastruktura, błyskawiczne iteracje, bezpieczeństwo jako domyślna warstwa oraz inteligentna optymalizacja kosztów
Prawdziwym testem kultury jest gotowość do „wdrażania w piątek” – ostateczny dowód zaufania do stabilności systemu
V0 demokratyzuje tworzenie aplikacji – menedżerowie produktu mogą dać programistom działający kod jako punkt wyjścia
Nigdy wcześniej nie widzieliśmy takiego głodu na AI – użytkownicy chętnie przechodzą na najnowsze technologie
Vercel Agent osiąga 70% współczynnik akceptacji dzięki „czystemu sygnałowi, a nie szumowi” – AI omija tarcie społeczne w code review
Od czerwca Vercel wypuścił 150+ funkcji, a stażyści wdrażają w ciągu 2 tygodni od dołączenia

Aparna Sinha wcześniej przez dekadę w Google skalowała Kubernetes i Google Cloud do poziomu multi-billion dollar businesses, następnie prowadziła produkty AI/ML w Capital One. Obecnie pomaga budować AI Cloud w Vercel – firmie, która niedawno pozyskała $300 milionów przy wycenie $9.3 miliarda.

Budowanie w AI to jak budowanie podczas trzęsienia ziemi

Sinha rozpoczyna od mocnej metafory. Według niej budowanie w AI przypomina budowanie podczas trzęsienia ziemi – grunt ciągle się rusza. Oznacza to, że najlepszy model może zmieniać się wielokrotnie w ciągu jednego dnia.

Większość zespołów inżynieryjnych nie jest przygotowana na taką prędkość. Ich CI/CD i workflow nie są zaprojektowane do szybkich iteracji ani testowania globalnego z wybranymi użytkownikami. Nawet w najbardziej nowoczesnych firmach programiści często budują tę infrastrukturę sami – co oznacza stromą krzywą uczenia się i niedobory talentów.

Tymczasem użytkownicy chętnie przechodzą na najnowsze technologie. Według Sinhy nigdy wcześniej nie widzieliśmy takiego głodu na AI. Ten apetyt rynku zwiększa presję na zespoły.

Ostatecznie firmy stają przed tragicznym wyborem: wypuszczają albo produkt o nieoptymalnym doświadczeniu użytkownika, albo za późno.

Cztery filary przewagi szybkości

Aby wyjść z tego impasu, organizacje muszą zbudować fundamenty oparte na czterech filarach.

1. Elastyczna i inteligentna infrastruktura

Platforma musi nie tylko automatyzować zadania, ale inteligentnie rozumieć framework aplikacji i sama dostosowywać konfigurację. Celem jest swobodne eksperymentowanie – szybkie testowanie nowych technologii i weryfikowanie, co działa dla konkretnego produktu.

2. Błyskawiczne iteracje i kultura pewności

Wymaga to szybkiego CI/CD pipeline i feature flags, które pozwalają udostępniać funkcje wybranym użytkownikom. Kluczowy jest też instant rollback – możliwość natychmiastowego cofnięcia gdy coś nie działa.

Prawdziwym testem, jak zauważa Sinha, jest kulturowa gotowość do „wdrażania w piątek” – ostateczny dowód zaufania do stabilności systemu. Zespół musi czuć się na tyle pewnie, by deployować nawet w sobotę, gdy wyjdzie nowy model.

3. Bezpieczeństwo jako domyślna warstwa

Obciążenia AI są bardzo drogie, co przyciąga złośliwe podmioty – złe boty i exploity czekają tylko na możliwość wykorzystania tych kosztownych zasobów. Dlatego bezpieczeństwo musi być wbudowane domyślnie, a nie dodawane jako dodatek na końcu.

Aplikacje muszą chronić przed najnowszymi zagrożeniami, które dynamicznie się zmieniają. Wdrożenia mogą być preview deployments udostępniane tylko wybranym użytkownikom, chronione hasłem. Na produkcji aplikacja jest chroniona przez firewall świadomy najnowszych zagrożeń.

4. Inteligentna optymalizacja kosztów

Kluczowy jest model, w którym płaci się tylko za aktywne obliczenia. Zasoby obliczeniowe skalują się w górę i w dół automatycznie. Podczas gdy obciążenia AI czekają na reasoning czy wywołania backendu, aplikacja nic nie kosztuje – w momentach, gdy czeka na odpowiedź modelu, nie powinna generować żadnych kosztów.

Dlatego firmy AI-native od OpenAI przez Zapier po Cursor i Browserbase wybierają Vercel na swoje interfejsy użytkownika. Ostatnio większe firmy – Under Armour, Meta, New York Times – również decydują się na Vercel, zwykle z inicjatywy programistów, którzy chcą przyspieszyć rozwój AI.

V0: Demokratyzacja rozwoju i nowy model współpracy

Sinha podkreśla, że nowoczesne narzędzia, takie jak V0, zmieniają nie tylko to KTO może tworzyć, ale też JAK zespoły współpracują. Menedżerowie produktu, projektanci – wszyscy mogą pisać aplikacje i uruchamiać je na tej samej infrastrukturze Vercel, zaprojektowanej dla łatwości użycia i bezpieczeństwa na skalę.

Live demo: Interfejs do porównywania modeli w kilka minut

Sinha demonstruje stworzenie aplikacji, która pozwala chatować z dwoma modelami równolegle – GPT-5 Nano i Claude 3.5 Haiku. V0 używa AI SDK – open source SDK od Vercel, który pozwala łączyć się z wieloma modelami. System szuka przykładów AI SDK, przegląda różne strony i tworzy motyw.

Gdy jest gotowe, widać wygenerowany kod, który można również edytować. Może z tego korzystać osoba znająca się na kodzie, ale nie jest to wymagane – można być kompletnym nowicjuszem. Po stworzeniu aplikacji można ją udostępnić komukolwiek – zaprosić użytkownika do przeglądania lub edycji.

W panelu programisty widać dokładnie, co się działo z wdrożeniem. Widać, że fluid compute (ekonomiczny compute) jest włączony, a cold start prevention aktywne – aplikacja wystartuje bardzo szybko. Można ponownie wdrożyć aplikację albo cofnąć do wcześniejszej wersji.

To fundamentalna zmiana. Product manager może dziś „dać programistowi działający kod jako punkt wyjścia”, co przyspiesza pracę inżynierów, bo nie zaczynają od pustego edytora. Można też – jak Sinha – eksperymentować z różnymi modelami AI i przeprowadzać ewaluacje. Vercel użył tego przy wypuszczaniu jednego z najnowszych modeli OpenAI.

Jak Vercel wypuszcza szybko: Kultura równie ważna jak narzędzia

Jako firma AI-native, Vercel nie tylko mówi o szybkim wypuszczaniu – również to praktykuje. Nawet najlepsze narzędzia nie zadziałają bez odpowiedniej kultury. Jedna z pierwszych rzeczy, które słyszysz w Vercel: możesz po prostu wypuszczać produkty.

Każdy pracownik ma możliwość wypuszczania. Od czerwca wypuścili ponad 150 funkcji. Większość pracowników, włączając stażystów, wypuszcza nową funkcję w ciągu dwóch tygodni od dołączenia.

Przy takiej prędkości pojawia się pytanie: jak zapewnić rygorystyczne testowanie, jakość i dobry gust? Sinha dzieli się trzema zasadami.

Zasada #1: Pracuj publicznie

Przykład: AI SDK – open source SDK w TypeScript z publicznym playground. Bycie open source oznacza zaangażowanie społeczności, programistów i wszystkich dostawców modeli. Jest vendor-agnostic – nie optymalizowany pod OpenAI, Anthropic czy Gemini, lecz wciąga wszystkie modele.

Latem Vercel przeprowadził znaczącą zmianę – przejście z wersji 4.x do 5.0, która była breaking change. Sposób wykonania? Praca w otwartości. Ogłosili breaking change i stworzyli nową wersję publicznie ze społecznością, która mogła dawać feedback. To poprawiło produkt oraz zaprosiło wszystkich dostawców modeli do integracji z AI SDK 5.0. Ostatecznie pozwoliło wypuścić agentic SDK, który był dużo bardziej solidny niż byłby przy pracy w zamkniętym środowisku.

Zasada #2: Iteruj ku doskonałości

Przykład: AI Gateway – komponent infrastruktury backendowej, który wspiera AI SDK. To nie jest open source, lecz produkt budowany wewnątrz Vercel. Jak więc pracować publicznie dla produktu, który nie jest open source?

Proces iteracji według Vercel:

Wszystko zaczyna się w kanale Slack – w maju zespół wystartował z ideą gateway dla AI SDK
Zespół rozwija się organicznie – ludzie przychodzą, wnoszą zastrzeżenia, dodają kod, bardzo podobnie jak w open source, ale wewnętrznie
Demo days jako celebracja – bez względu na to, co prezentujesz, wszyscy dopingują. Każdy pomysł dostaje aplauz, co bardzo zachęca i otwiera przestrzeń dla innych
Wypuszczenie jako beta z użytkownikami – gateway wyszedł w czerwcu jako rozwijający się produkt, by zobaczyć rzeczywiste użycie i otrzymać feedback
Iteracja na podstawie feedbacku – użytkownicy chcieli interfejsu, więc stworzono playground dla każdego modelu i darmowy tier ($5 kredytów)

Efektem tego podejścia jest realna prędkość. GPT-5 przyszedł do nich przed swoim wypuszczeniem, aby Vercel mógł przeprowadzić ewaluacje. Od tamtej pory przy każdym nowym modelu zwykle inkorporują go w gateway i pracują nad nim 2-3 tygodnie wcześniej. Jak mówi Sinha: „Gdy pojawia się nowy model, jesteśmy z nim na żywo w ciągu godzin, czasem minut.”

Zasada #3: Poznaj swojego klienta (i swój zespół)

Przykład: Vercel Agent – bardzo świeży projekt wypuszczony kilka tygodni temu. To narzędzie dla inżynierów do code review pull requestów. Ta zasada ma głębszy wymiar – tworząc narzędzie, zespół zdał sobie sprawę, że ludzie „czasami nie dają najostrzejszej opinii, bo nie chcą być niemili”. AI nie ma tej bariery społecznej.

Problem AI: często dostarcza „slop” – wiele narzędzi kodujących daje dużo feedbacku, ale to volume bez quality. Tarcie społeczne (chęć bycia miłym, unikanie konfrontacji) często prowadzi do powierzchownych opinii. Vercel chciał zbudować coś innego – narzędzie, które dostarcza „czysty sygnał, a nie szum”.

Jak to zrobili? Mają dużą populację programistów – około 700 w Vercel. Zbudowali i wypuścili to wewnętrznie dla każdego użytkownika. Nikt nie musiał tego używać, jednak wszyscy zaczęli. Z otrzymanym feedbackiem ulepszyli produkt tak, że teraz ma 70% współczynnik akceptacji.

To kolejna zasada produktowa: wypuść do wczesnych użytkowników i mierz. Aspekt mierzenia jest niezwykle ważny. Większość narzędzi kodujących używających AI ma 30-50% współczynnik akceptacji, gdzie 50% to naprawdę rzadkość. Ten produkt ma 70% – mniej szumu, naprawdę użyteczny agent. Gdy wyszli na zatłoczony rynek (jest mnóstwo narzędzi AI do kodowania), faktycznie znaleźli naprawdę dobre dopasowanie produkt-rynek. To zmienia cel przeglądu kodu z konsensusu społecznego na bezkompromisową optymalizację techniczną.

Checklist: Jak wypuszczać AI w tempie ewolucji modeli

✅ Infrastruktura

Masz elastyczną infrastrukturę release do szybkiego testowania nowych modeli
Twój pipeline CI/CD jest błyskawiczny
Używasz feature flags do udostępniania funkcji wybranym użytkownikom
Masz możliwość natychmiastowego cofnięcia gdy coś nie działa
Bezpieczeństwo jest wbudowane domyślnie, nie dodawane później
Twoje zasoby obliczeniowe skalują się automatycznie i płacisz tylko za faktyczne użycie

✅ Kultura organizacyjna

Każdy w zespole ma możliwość wypuszczania produktów
Macie kulturową gotowość do „wdrażania w piątek” – ostateczny test zaufania do systemu
Pracujecie publicznie (open source) lub quasi-publicznie (wewnętrzna przejrzystość w kanałach Slack)
Macie regularne demo days, gdzie każdy pomysł otrzymuje aplauz
Wypuszczacie jako beta z prawdziwymi użytkownikami, nie czekając na perfekcję
Testujecie produkty wewnętrznie przed zewnętrznym wypuszczeniem
Mierzycie kluczowe metryki (np. współczynnik akceptacji), aby wiedzieć, że poprawiacie produkt
Zapewniacie dobry gust – jakość i przemyślany design wymagają szczegółów i pracy

✅ Proces wypuszczania

Nowi członkowie zespołu (nawet stażyści) wypuszczają w ciągu 2 tygodni
Macie możliwość wdrażania w weekendy, gdy wychodzą nowe modele
Wypuszczacie małe, iteracyjne zmiany zamiast dużych wydań
Współpracujecie z dostawcami modeli 2-3 tygodnie przed ich publicznym wypuszczeniem
Jesteście dostępni w ciągu godzin (nie dni), gdy nowy model wychodzi

Podsumowanie: Zaczynaj wcześnie, bo nauka się kumuluje

Każda firma jest na krzywej z AI. Przeszliśmy od asystentów do agentów, a teraz przechodzimy do systemów autonomicznych. Infrastruktura i platforma muszą pozostawać aktualne względem zagrożeń bezpieczeństwa, ale też pozwalać szybko się poruszać.

Równie ważna jest kultura organizacyjna:

Pracuj publicznie – nawet dla produktów closed source możesz pracować przejrzyście wewnętrznie
Iteruj ku doskonałości – zacznij małe, wypuść coś, pracuj z użytkownikami, testuj wewnętrznie, miej mocne metryki
Poznaj swojego klienta (i swój zespół) – wypuszczaj coś ze smakiem i łatwe w użyciu, co wymaga wielu szczegółów i pracy

Według Sinhy najważniejsze to zacząć wcześnie. Gdy budujesz te produkty, zyskujesz więcej doświadczenia. Nauka się kumuluje – każda iteracja, każde wypuszczenie, każdy feedback sprawia, że następny produkt jest lepszy. Ta kumulująca się wiedza to właśnie przewaga firm, które działają szybko.

Bonus: Przykłady promptów do V0 z live demo

Podczas prezentacji Aparna Sinha pokazała, jak szybko można stworzyć aplikację w V0 oraz jak wykorzystać ją do ewaluacji modeli. Użyła dwóch rodzajów promptów:

Prompt 1: Generowanie interfejsu użytkownika

Chcę stworzyć przyjazną dla nowicjuszy stronę główną, gdzie mogę chatować

z dwoma modelami równolegle obok siebie i wybierać spośród tych dwóch modeli 
GPT5 Nano i Claude 3.5 Haiku.

Kiedy stosować: Do błyskawicznego prototypowania interfejsów, tworzenia narzędzi wewnętrznych lub generowania kodu startowego dla programistów.

Dlaczego ten prompt działa dobrze:

Określa poziom skomplikowania – „przyjazna dla nowicjuszy” jasno komunikuje, że interfejs ma być prosty
Definiuje główną funkcję – „chatować z dwoma modelami równolegle” precyzyjnie opisuje główną funkcjonalność
Specyfikuje konkretne wymagania – wymienia dokładnie, które modele mają być używane

Prompt 2: Testowanie i porównywanie modeli (ewaluacja)

W jednym zdaniu, jaka jest rola product managera?

Kiedy stosować: Do bezpośredniego porównywania jakości, tonu i stylu odpowiedzi różnych modeli AI w ramach stworzonej aplikacji. Można szybko ocenić, który model lepiej radzi sobie z konkretnym typem zapytań.

Kluczowa lekcja: Im bardziej konkretny jest prompt (jakie doświadczenie użytkownika, jaka funkcjonalność, jakie konkretne narzędzia), tym lepszy rezultat otrzymasz z narzędzi takich jak V0. Aparna użyła tego do przeprowadzania ewaluacji modeli przed ich publicznym wypuszczeniem – to samo narzędzie, którego użył Vercel przy testowaniu GPT-5 przed jego wydaniem.

Kluczowy insight

Więcej wdrożeń = lepsza jakość

Standardowo myślimy: Częste wdrożenia oznaczają więcej chaosu, więcej błędów i większe ryzyko. Dlatego większość firm ma zasadę „no deploy Friday” i stara się minimalizować liczbę wydań. Im mniej ruszamy w produkcji, tym bezpieczniej.

W praktyce okazuje się: Vercel wdraża w soboty, gdy wychodzą nowe modele. Wypuścili 150+ funkcji od czerwca. Każdy – nawet stażysta – może wdrażać w dwa tygodnie od dołączenia. To nie prowadzi do chaosu, lecz do lepszej jakości. Dlaczego? Każde wdrożenie jest małe, każda zmiana jest iteracyjna. Gdy masz natychmiastowe cofnięcie, ryzyko znika.

Dlaczego to jest istotne: Większość firm opóźnia wypuszczanie „dla bezpieczeństwa”. Tymczasem małe, częste zmiany z natychmiastowym cofnięciem są bezpieczniejsze niż rzadkie, duże wdrożenia. Dodatkowo – jak mówi Sinha – nauka się kumuluje. Im więcej wypuszczasz, tym więcej się uczysz, tym lepsze jest następne wypuszczenie.

Test na jutro: Następnym razem gdy planujesz duże wydanie, zamiast czekać aż wszystko będzie perfekcyjne, podziel go na 5 małych wdrożeń. Ustaw sobie możliwość natychmiastowego cofnięcia. Wypuść pierwszą małą część dzisiaj, nawet jeśli to piątek. Sprawdź czy paradoksalnie czujesz się bezpieczniej niż przy dużych, rzadkich wydaniach.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Prezentacja Aparny Sinhy miała miejsce w San Francisco.

Tag: Ci Cd Pipeline

Jak wypuszczać produkty AI w tempie ewolucji modeli: Lekcje od Vercel #EN323