P Stack: jak inżynierka Cursora pisze i wdraża kod z pomocą AI

O czym jest ten film

1. Lauren Tan — principal engineer w SpaceX, członkini zespołu technicznego Cursora, staff engineer w Mecie i osoba ze ścisłego trzonu Reacta — udostępniła otwarcie cały swój warsztat: repozytorium P Stack z przepływami pracy, umiejętnościami i zasadami pisania kodu z AI.
2. Autor rozkłada P Stack na sześć etapów cyklu wytwarzania oprogramowania: planowanie, projektowanie, budowanie, testowanie, wdrożenie i utrzymanie.
3. Etap planowania celuje w projekty „brownfield”: umiejętności how, why i teach służą poznawaniu istniejącego kodu, a figure out z show me your work rozbijają duże zadanie na mniejsze tickety i spisują decyzje do pliku.
4. Do planowania od zera autor sam by po te umiejętności nie sięgał — woli zestawy Matta Pococka lub Sue Power; przepisy Laureen Tan powstały z myślą o dużych migracjach i zmianach w działających aplikacjach.
5. Projektowanie rozstrzygane jest wielomodelowo: umiejętność architect puszczona jest przez „arenę” modeli (Opus, GPT, Grok), a interrogate ocenia nadesłane propozycje i scala je w jeden raport.
6. Budowanie to przede wszystkim TDD, obowiązkowe dobre praktyki TypeScriptu oraz cleanup diff, który wymiata typowe ślady po generatorach (zbędne komentarze, gołe try-catch, zmienne bez typu, głębokie zagnieżdżenie), dbając o niezmienione zachowanie programu.
7. Kontrowersyjna reguła „bez komentarzy”: model bywa czyta komentarz zamiast kodu, więc jeśli komentarz kłamie, agent pójdzie w ślad za komentarzem — stąd decyzja o ich usuwaniu.
8. Testowanie to trzy przepływy: pełny rytuał end-to-end (środowisko, uruchomienie, sprzątanie), rój agentów swarm oraz attack the diff — próba złamania własnych zmian z pomocą kilku modeli i bezwzględnej recenzji jakości.
9. Wdrożenie to cały pipeline wokół pull requesta: łatwa recenzja, nadzór nad scaleniem, naprawa konfliktów, zbieranie komentarzy i ratowanie CI; natomiast etap utrzymania w P Stack w ogóle nie istnieje.
10. Zasady nie trafiają do systemowego promptu (koszt tokenów przy każdej wiadomości), tylko do osobnych umiejętności z mapą wyzwalaczy; autor wybrał do przejęcia attack the premise oraz odrzucanie stanów niemożliwych w systemie typów.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Projektuj na wielu modelach naraz — arena plus sędzia

Na czym polega: W P Stack etap projektowania nie sprowadza się do pytania jednego modelu. Umiejętność architect uruchamia „arenę”, na której kilka modeli niezależnie od siebie proponuje rozwiązania, a interrogate wystawia na nie model-sędziego, który ocenia efekty i scala najlepsze elementy w jeden raport projektowy.

Jak stosować: Przy każdej poważniejszej decyzji architektonicznej rozdziel pracę: najpierw równoległe propozycje od różnych modeli, potem osobny prompt „sędziego” z jasnymi kryteriami oceny i poleceniem złożenia jednej rekomendacji. Można to ogarnąć ręcznie w kilku oknach albo zapisać jako umiejętność.

Na co uważać: Więcej modeli to wyższe koszty i dłuższy czas oczekiwania; sędzia bez konkretnych kryteriów sklei propozycje mechanicznie zamiast wybrać to, co naprawdę najlepsze.

2.Gdy AI kręci się w kółko, zaatakuj przesłankę

Na czym polega: Zasada attack the premise odpowiada na znaną każdemu pętlę: agent naprawia błąd, błąd wraca, agent poprawia, błąd znowu wraca. Zamiast kolejnej iteracji reguła każe się zatrzymać i zakwestionować założenia — czy w ogóle rozwiązujemy właściwy problem.

Jak stosować: Po dwóch–trzech nieudanych próbach z rzędu wstrzymaj poprawki i każ agentowi odpowiedzieć na pytania wprost: co założyliśmy, które założenie mogło być fałszywe, czy objaw nie jest objawem czegoś innego. Dopiero potem wracajcie do kodu.

Na co uważać: Każda „prawie udana” poprawka daje złudzenie postępu, dlatego warto z góry ustawić limit prób, po którym pętla jest przerywana.

3.Zero zbędnych komentarzy — agent ma czytać kod, nie opisy

Na czym polega: Lauren Tan celowo każe usuwać nadmiarowe komentarze, bo model bywa prowadzony tym, co napisano nad funkcją, a nie tym, co funkcja faktycznie robi. Jeśli komentarz twierdzi, że funkcja zwraca A, a kod zwraca B, agent potrafi zaufać komentarzowi.

Jak stosować: Traktuj komentarz jak podejrzany dublet kodu: jeśli powtarza to, co widać w kodzie, wytnij go. Kod powinien mówić sam za siebie, a jego zachowanie ma potwierdzać test.

Na co uważać: Nie każda uwaga w kodzie to szum — komentarze wyjaśniające nietrywialne decyzje biznesowe bywają bezcenne; warto też uzgodnić tę zasadę z konwencjami zespołu.

4.Sprzątaj diff po AI tuż przed scaleniem

Na czym polega: cleanup diff porównuje gałąź główną z bieżącą i przeczesuje zmiany pod kątem typowych ozdobników po generatorach: zbędne komentarze, gołe bloki try-catch, zmienne bez typu, zbyt głębokie zagnieżdżenie. Warunek niepodlegający dyskusji: zachowanie programu ma się nie zmienić, co potwierdzają testy, a na końcu agent oddaje krótkie, dwu- albo trzyzdaniowe podsumowanie.

Jak stosować: Wprowadź taki przegląd jako stały krok przed pull requestem — najlepiej zapisany jako umiejętność uruchamiana automatycznie na samym diffie.

Na co uważać: Refaktoryzacja bez pokrycia testami to prosta droga do regresji; tam, gdzie testów brakuje, najpierw je dopisz, a dopiero potem sprzątaj.

5.Zbuduj cały rytuał weryfikacji end-to-end, nie tylko testy

Na czym polega: create verification to nie generator samych testów, lecz przepis na całą procedurę: postawienie bazy i serwerów, uruchomienie aplikacji tak, jak robi to użytkownik, diagnoza problemów, przejście realnych ścieżek, zebranie dowodów i sprzątnięcie środowiska po sobie.

Jak stosować: Zapisz w umiejętności konkretne komendy i kolejność kroków, żeby agent sam podnosił i burzył środowisko testowe; pomaga też reguła „jedna funkcjonalność = jeden folder”, dzięki której testy nie zlewają się w jedno.

Na co uważać: Takie przepływy bywają chimeryczne — tymczasowe bazy i serwery trzeba naprawdę zrzucać po każdym przebiegu, inaczej kolejne uruchomienia dziedziczą śmieci z poprzednich.

6.Rozprosz testy na rój agentów

Na czym polega: Zamiast jednego agenta przeczesującego całość, swarm puszcza wielu agentów równolegle — każdy może działać na innym modelu i zajmować się małym wycinkiem — a wyniki trafiają do wspólnego raportu.

Jak stosować: Podziel powierzchnię testową na niezależne fragmenty i przydziel je agentom; rozważ różne modele, bo mają różne slepe punkty i wzajemnie się uzupełniają.

Na co uważać: Scalanie to słabe ogniwo — bez porządnego agregowania raport utopi cię w powtórzeniach; rój mnoży też koszty tokenów.

7.Przed scaleniem wystaw własne zmiany na atak

Na czym polega: Przepływ „attack the diff” ponownie wykorzystuje interrogate: agent zna różnicę między gałąź główną a Twoją i deleguje kilka modeli z jednym zadaniem — spróbować złamać to, co właśnie napisałeś. Dokłada do tego thermonuclear code quality review, czyli wyjątkowo surową warstwę recenzji sprawdzającą, czy kod da się jeszcze uprościć.

Jak stosować: Uczyń z tego stały rytuał przed pull requestem: adwersarze szukają dziur, ostra recenzja wymusza upraszczanie.

Na co uważać: Bezwzględna recenzja łatwo rozmienia się w drobiazgi — pilnuj, żeby priorytetem była poprawność i prostota, a nie kosmetyka.

8.Zautomatyzuj opiekę nad pull requestem

Na czym polega: Na etapie wdrożenia P Stack ma cały zestaw narzędzi: pull request pisany tak, by łatwo się go recenzowało, tryb nadzoru, który pilnuje aż zmiana naprawdę się scali, naprawę konfliktów scaleniowych, zbieranie komentarzy z recenzji i ratowanie czerwonych kontrolek CI.

Jak stosować: Jeśli agent ma dokończyć robotę za ciebie, zapisz te kroki jako umiejętności — wówczas konflikt czy nieprzechodzący pipeline nie zatrzyma pracy bez twojej interwencji.

Na co uważać: Pełna automatyzacja scalania wymaga zaufania do testów i recenzji; bez nich agent „dopchnie” zmianę, która nie powinna wejść.

9.Zasady trzymaj w umiejętnościach, nie w systemowym prompcie

Na czym polega: Wszystkie reguły w jednym systemowym prompcie to ogromny plik, który model czyta przy każdej wiadomości — płacisz tokenami za informacje, które akurat są zbędne. P Stack tnie zasady na osobne umiejętności i prowadzi mapę mówiącą, kiedy którą uruchomić, a gdy nie wiesz, którą wybrać, ratuje router (potato mode) dobierający umiejętność po opisie problemu.

Jak stosować: Wynieś zasady z promptu do osobnych plików, dopisz indeks wyzwalaczy, a niepewność rozstrzygaj przez router opisujący problem naturalnym językiem.

Na co uważać: Nadmiar umiejętności utrudnia routerowi trafne wybieranie — opisy muszą jednoznacznie mówić, do czego dany plik służy.

10.Odrzucaj stany niemożliwe już na poziomie typów

Na czym polega: W ramach zasady „co-construction safety” P Stack wymusza dyscyplinę typów: model danych ma wykluczać stany, które nie mogą zaistnieć — płatność nie może być jednocześnie opłacona i oczekująca.

Jak stosować: Przy modelowaniu domeny zapisuj stany tak, by niemożliwe kombinacje w ogóle nie przechodziły kompilacji (np. warianty zamiast niezależnych flag), i dodaj tę regułę do zasad, którymi sterujesz agenta.

Na co uważać: Przesadnie sprytny system typów bywa ciężki w utrzymaniu — agent potrzebuje prostej, opisanej konwencji, żeby nie wymyślać własnej.

Redakcyjne tłumaczenie

Bohaterka materiału i jej otwarty notatnik

Eric otwiera film kartą zawodową Lauren Tan: principal engineer w SpaceX, członkini zespołu technicznego Cursora i staff engineer w Mecie, a do tego osoba ze ścisłego trzonu zespołu Reacta. (Informacja dodatkowa: Cursor to edytor kodu z głęboką integracją AI; praca w rdzeniu Reacta oznacza miejsce w ścisłym kierownictwie jednego z największych otwartych projektów frontendowych.)

Niedawno Lauren Tan zrobiła coś, na co nawet tak doświadczeni inżynierowie rzadko się decydują: upubliczniła całość swojego warsztatu — przepływy pracy, umiejętności i zasady — w otwartym repozytorium o nazwie P Stack. Film Erica to przewodnik po tym zbiorze: co się w nim znajduje, czym różni się od omawianych wcześniej zestawów i które elementy autor sam zamierza przejąć do własnej pracy.

(Informacja dodatkowa: „umiejętności”, ang. skills, to w narzędziach takich jak Cursor gotowe pakiety instrukcji, które model doładowuje we właściwym momencie pracy. Autor kanału regularnie recenzuje takie zbiory i porównuje je ze swoim autorskim zestawem Superboard.)

Sześć etapów jednego cyklu

Na potrzeby recenzji Eric rozrysował diagram, który porządkuje cały P Stack wzdłuż sześciu etapów cyklu życia oprogramowania tworzonego z AI: planowanie, projektowanie, budowanie, testowanie, wdrożenie i utrzymanie. O samym cyklu nagrał wcześniej osobny materiał — i po kolei zabiera się za każdy etap.

Etap pierwszy: planowanie, czyli najpierw poznaj cudzy kod

Umiejętności planistyczne w P Stack powstały z myślą o projektach brownfield — takich, w których kod już istnieje. (Informacja dodatkowa: projekt brownfield to w żargonie deweloperów praca na działającej aplikacji, w odróżnieniu od greenfield, czyli budowy od zera.)

Są tu dwa przepływy. Pierwszy, „naucz się najpierw kodu”, opiera się na trzech umiejętnościach: how odpowiada na pytanie, jak kod działa, why — dlaczego działa właśnie tak, a teach łączy oba i tłumaczy kod w całości. Drugi przepływ, „zaplanuj duże zadanie”, korzysta z figure out, która rozbija zadanie albo cały projekt na mniejsze tickety, oraz show me your work, dbającej o to, by decyzje wylądowały w porządnym dokumencie markdown.

Sam autor jednak sięgnąłby po nie niechętnie. Jego zdaniem Lauren Tan nie poświęca planowaniu wiele uwagi — jej przepisy celują w ulepszanie tego, co już istnieje: wielkie migracje i duże zmiany. Jeśli budujesz samodzielnie albo od zera, Eric poleca raczej zestawy Matta Pococka lub Sue Power — to na nich polega we własnych projektach. (Informacja dodatkowa: Matt Pocock, znany popularyzator TypeScriptu, i Sue Power publikują własne otwarte zbiory umiejętności dla asystentów programistycznych, omawiane wcześniej na kanale.)

Etap drugi: projektowanie rozstrzygnięte na arenie

Zanim padnie pierwsza linijka kodu, P Stack każe „ustalić kształt kodu”. Umiejętność architect wystawia sprawę na arenę: kilka modeli i agentów — Opus, GPT, Grok, cokolwiek masz pod ręką — pracuje równolegle, każde nad własnym projektem rozwiązania. Gdy propozycje wrócą, do akcji wchodzi interrogate: model w roli sędziego ocenia nadesłane projekty i skleja z nich jeden raport projektowy.

To najciekawszy kontrast z omawianymi wcześniej zestawami, w tym z tymi Pococka. Tam cały etap opierał się na jednym modelu; tutaj każdą decyzję projektową można rozbić na wiele modeli, porównać efekty, zebrać to, co w każdym najlepsze, i dopiero wtedy ruszać dalej.

Etap trzeci: budowanie — testy najpierw, TypeScript zawsze, sprzątanie obowiązkowo

Na etapie budowania prowadzą dwa przepływy. Pierwszy to klasyczne TDD — rozwój sterowany testami — za który odpowiada umiejętność TDD, kładąca nacisk na pisanie testów przed implementacją. Eric zestawił ją z odpowiednikami od Matta Pococka i Sue Power i sporządził osobne porównanie, bo te umiejętności różnią się w zależności od sytuacji: szybka łatka buga, nowa funkcjonalność, zdyscyplinowany zespół. Odnośnik do zestawienia autor zostawia pod filmem.

Drugim filarem jest typescript best practice. Lauren Tan żyje Reaktem, a React żyje TypeSryptem — stąd osobna umiejętność, która wymusza dobre praktyki TypeScriptu przy każdym generowanym pliku.

Trzeci element to cleanup diff z wewnętrznym trybem de-slop. Najpierw porównuje gałąź główną z bieżącą, a potem przeczesuje zmiany (diff, czyli zestaw różnic między gałęziami) pod kątem typowych śladów po generatorach: zbędne komentarze, gołe bloki try-catch łapiące wyjątki, zmienne bez typu, zbyt głębokie zagnieżdżanie. Cel jest jasny: kod ma zostać czyściejszy, ale zachować dotychczasowe zachowanie — o co dbają testy — a na koniec agent ma oddać krótkie, dwu- albo trzyzdaniowe podsumowanie tego, co zrobił.

Dlaczego w kodzie nie ma komentarzy

Na osobną uwagę zasługuje pozycja „usuń zbędne komentarze”. Skąd ona się bierze? P Stack ma zasadę no comments, a jej uzasadnienie jest zaskakująco proste: model bywa leniwy wobec kodu i woli czytać komentarze. Jeśli w komentarzu napisano, że funkcja zwraca A, a w kodzie zwraca B, agent potrafi zaufać temu pierwszemu. Usunięcie komentarzy usuwa szum — agentowi zostaje samo źródło prawdy, czyli kod.

Etap czwarty: testowanie — udowodnij, że działa, a potem spróbuj to złamać

Testowanie składa się z trzech przepływów.

Pierwszy: „udowodnij, że aplikacja działa”, oparty na umiejętności create verification. Różni się od omawianej wcześniej umiejętności TDD, która odpowiada za testy jednostkowe i funkcjonalne — tutaj chodzi o testy end-to-end, obejmujące całą ścieżkę działania aplikacji. A takie testy wymagają świata: bazy danych, serwerów, sposobu, w jaki aplikację uruchamia użytkownik. Umiejętność prowadzi agenta przez całość — uruchamia aplikację, diagnozuje problemy, odtwarza realne zachowania użytkownika, zbiera dowody, a na końcu sprząta po sobie, zrzucając tymczasowe bazy i serwery, i korzysta przy tym z funkcji pomocniczych. Sedno: nie chodzi tylko o napisanie testów end-to-end, ale o zapisanie całego rytuału — w jaki sposób agent ma podnosić środowisko i jakie komendy uruchamiać. Do tego dochodzą reguły porządkowe: jedna funkcjonalność na folder (zamiast wrzucać wszystko do jednego katalogu), każdy element przechodzi własne kroki od początku do końca, a całość odsyła do głównej umiejętności nadrzędnej.

Drugi przepływ, swarm, odwraca logikę „jednego agenta na całość”. Zamiast jednej maszyny, która i uruchamia, i testuje kolejne strony, puszczasz rój: kilku agentów — jeśli chcesz, na różnych modelach — z których każdy zajmuje się małym wycinkiem, a wyniki łączą się w jeden raport.

Trzeci przepływ, „attack the diff”, wraca do znanego z etapu projektowania interrogate. Agent widzi różnice między gałąź główną a Twoją i jego zadanie polega na tym, by kilka modeli spróbowało złamać wprowadzone właśnie zmiany. Wsparciem jest thermonuclear code quality review — nazwy, jak przyznaje Eric, ktoś najwyraźniej wymyślił w wyjątkowym natchnieniu — czyli dodatkowa, wyjątkowo ostra warstwa recenzji sprawdzająca, czy kod da się jeszcze uprościć. Autor porównuje ją do omawianego wcześniej „ponytail”: tam także chodziło o dopracowanie refaktoryzacji do granic prostoty.

Etap piąty: wdrożenie, czyli pipeline wokół pull requesta

Wszystko przetestowane i gotowe do scalenia. Pierwszy krok: pull request pisany tak, by łatwo się go recenzowało. Tu każdy ma swój styl — również autorski Superboard ma własny — ale warto podejrzeć, jak porządkuje to Lauren Tan.

Następnie P Stack buduje cały pipeline opieki nad scaleniem. Tryb nadzoru („babysit”) pilnuje pull requesta, aż zmiana naprawdę się zmerguje. Umiejętność naprawy konfliktów scaleniowych wchodzi do gry, gdy ktoś z zespołu zmerguje w międzyczasie swoją zmianę i zderzy ją z twoją. Dalej zbieranie komentarzy z recenzji oraz ogarnianie nieudanych kontrolek CI w procesie CI/CD. Całość układa się w pełny, domknięty proces wdrożenia.

Etap szósty: utrzymanie — puste pole

A tu niespodzianka: P Stack nie ma nic dla etapu utrzymania — czyli zbierania zgłoszeń i zawracania ich do fazy planowania. Eric odsyła do recenzowanych na kanale umiejętności tego typu, na przykład „Super Collect” z zestawu Superboard.

Przerwa sponsorska: automatyzacja social mediów (fragment sponsorski)

Między etapem testowania a omówieniem umiejętności pomocniczych autor wstawia reklamę narzędzia Potato, które przez serwer MCP podłącza się do ChatGPT i pozwala modelowi zarządzać kontami w mediach społecznościowych. Pokazuje na własnym przykładzie: po połączeniu kont wkleja linki do filmów z YouTube, a agent sam tnie je w krótkie rolki, publikuje je i planuje kolejne na następny dzień. Potrafi też odpowiadać w komentarzach na wybrane słowa kluczowe i zbierać adresy e-mail do kampanii. Dzięki temu — twierdzi Eric — jego konto na Instagramie urosło do 7 tysięcy obserwujących w kilka miesięcy.

Umiejętności pomocnicze: router i powrót do kontekstu

Poza głównym cyklem P Stack ma warstwę umiejętności, które można uruchomić w dowolnym momencie pracy. Najciekawsza to potato mode — router: gdy nie wiesz, której umiejętności użyć, opisujesz problem, a router dobiera właściwą. Obok niej zestawy: konfiguracyjne (setup), catch-up i plain talk do odtwarzania kontekstu, pisarskie (writing) oraz służące rozwijaniu samego P Stacku. Autor chwali zwłaszcza pierwszą parę: po przeskoku między projektami wystarczy jedna komenda, żeby odświeżyć pamięć o tym, co się działo.

Zasady pocięte na umiejętności, a nie wciśnięte w system prompt

Osobny dział P Stacku to zasady. Czemu nie w systemowym prompcie? Bo to byłyby setki linijek, które model czyta przy każdej wiadomości — a więc i płaci za nie tokenami przy każdej wiadomości — nawet gdy akurat są zupełnie niepotrzebne. Dlatego P Stack tnie zasady na osobne umiejętności i prowadzi indeks mówiący, kiedy którą uruchomić.

Zasad jest mnóstwo, więc Eric wybiera te najbardziej wartościowe z perspektywy własnego zestawu Superboard. „Pisz mało” (keep it small) pokrywa się z omawianym wcześniej „ponytail”, więc odpuszcza szczegóły. Zostają dwie perełki.

Pierwsza: attack the premise. Znasz to z własnej praktyki — agent naprawia błąd, błąd wraca, agent naprawia, błąd wraca, i tak w kółko, w nieskończonej pętli poprawiania i blokowania, aż wydaje się, że maszyna w ogóle nie daje rady tego buga usunąć. Zasada każe zatrzymać maszynę i zakwestionować założenia: czy w ogóle zmierzamy we właściwym kierunku, zanim pozwolimy agentowi biec dalej. Eric zapowiada, że wdroży ją w Superboard.

Druga: „co-construction safety”, a w niej dyscyplina typów. Zmienne bywają w różnych stanach i o różnych typach, dlatego modelowanie ma odrzucać stany niemożliwe — płatność nie może być jednocześnie opłacona i oczekująca. Ta reguła również trafi do autorskiego zestawu autora. Pozostałe zasady jego zdaniem pokrywają się z tym, co Superboard już ma; zainteresowanych odsyła do osobnej strony z omówieniem.

Zakończenie

Na koniec Eric obiecuje wrzucić do opisu filmu cały diagram P Stacku, żeby każdy mógł się do niego dobrać, prosi o polubienia i zachęca do komentowania: jakie inne frameworki do pracy z AI w programowaniu warto by omówić na kanale.