Your Roadmap Is Why You're Losing to AI-Native Teams.

O czym jest ten film

1. „Sekretnym składnikiem” firm typu Anthropic czy OpenAI, które wdrażają co tydzień, nie jest samo AI — to kultura i sposób organizacji pracy.
2. Nowe zadanie operatora: przenosić powtarzalne interakcje międzyludzkie do kodu i trwałych dokumentów, na których mogą działać agenci.
3. Autor przedstawia 15 „przykazań” — spójny system zmiany organizacyjnej, którego nie da się wdrażać wybiórczo.
4. Analogia z fotografią cyfrową: AI zbiło koszt kolejnego szkicu, prototypu czy analizy do zera, więc decyzje nie zniknęły — stały się łatwiejsze do unikania.
5. Klaster „radykalny”: produkt nie robi roadmap ani nie steruje czasem inżynierii, ale za to codziennie siedzi w kodzie i pracuje ramię w ramię z inżynierią.
6. Klaster „pisania”: brak spotkań dłuższych niż godzina, dokumentacja jako kod, obsesja na punkcie klarowności intencji — bo dokumenty czytają teraz agenci.
7. Klaster „behawioralny”: jak sprawić, by tempo AI było znośne dla ludzi — elastyczność, zakładanie dobrych intencji, budowanie w zespole, uczenie się nawzajem.
8. Design rozszerza się na terminal, SDK i doświadczenia agentowe — projektant tylko od ekranów projektuje dziś „lobby, gdy reszta budynku powstaje bez niego”.
9. Dwa sposoby na zepsucie całości: adopcja częściowa oraz brak zmiany kultury i oczekiwań.
10. Kluczowa myśl: znajdź punkt największej dźwigni i przenieś tam rzadki zasób — ludzki osąd i smak.

Redakcyjne tłumaczenie

Dlaczego nagrałem ten film

Nie mogłem go nie nagrać. Mamy przed sobą tyle bólu, gdy próbujemy dostosować się do AI. Dostaję mnóstwo pytań w stylu: „Nate, dlaczego mój biznes rusza się tak wolno, a Anthropic potrafi wydawać coś praktycznie co tydzień?”. Odpowiedź jest stosunkowo prosta. Nagrałem ten film, żeby wyjaśnić, dlaczego firmy takie jak Anthropic, OpenAI i małe startupy z Doliny Krzemowej potrafią wdrażać tak szybko — i dlaczego niemal wszyscy inni nie potrafią używać AI w ten sposób. Jaki jest ich sekretny składnik? Podpowiedź: to nie jest samo AI.

W tym filmie poznasz 15 „zasad drogowych”, których używam, pomagając zespołom wejść w takie szybkie tempo wdrożeń.

Nowa rola operatora: przenosić koordynację do kodu

Uważam, że operatorzy mają w erze AI nowe zadanie: przenosić coraz więcej powtarzalnych interakcji międzyludzkich firmy w stronę kodu. Zmieniają miejsce, w którym „żyje” firma. Robią to na różne sposoby.

Decyzje, które kiedyś rozpływały się w spotkaniach, stają się dokumentami — takimi, do których ludzie mogą wracać, ale przede wszystkim takimi, na których mogą działać agenci. I to jest wskazówka. Menedżerowie produktu, którzy kiedyś kierowali inżynierami przez system zgłoszeń, dziś wrzucają rzeczy do terminala i pracują z inżynierami bezpośrednio tam. Recenzje stają się ewaluacjami (evalami). Powtarzane przypomnienia stają się systemami, na których agenci mogą działać, które mogą budować i z czasem ulepszać. Design wchodzi do kodu, do SDK — w sposób, w jaki nigdy nie działo się to w latach 2010.

Nie twierdzę, że każda interakcja międzyludzka przenosi się do oprogramowania. Zaufanie zostaje ludzkie. Smak zostaje ludzki. Ale wiele powtarzalnych elementów koordynacji, na których opieramy prowadzenie biznesu, można przenieść w stronę kodu, żeby przyspieszyć wykonanie za pomocą agentów. Jeśli każdą decyzję musi na nowo wyjaśniać jakiś człowiek, to ludzie stają się wąskim gardłem biznesu. I to jest właśnie czynnik odróżniający firmy takie jak Anthropic czy OpenAI, które wdrażają szybko, od całej reszty.

Dlatego napisałem 15 przykazań, które mają prowadzić zmianę organizacyjną w stronę takiej przyszłości z AI. To naprawdę przykazania — bawiłem się tym, pisałem językiem „nie będziesz…”. Chcę je omówić, bo razem tworzą system, którym możemy przesuwać organizację ku szybszemu tempu wdrożeń — ku światu, w którym wszyscy potrafimy poruszać się tak szybko, jak pozwalają na to narzędzia AI.

Każde z tych 15 przykazań istnieje, bo AI zmieniło pracę leżącą pod nim. Część wyprowadza koordynację ze spotkań do trwałych systemów. Część przybliża osąd produktowy do samego budowania. Część chroni czas, który stał się cenniejszy dzięki szybkiemu wykonaniu. Reszta chroni relacje międzyludzkie, które pozwalają firmie działać w tym tempie przy wysokim zaufaniu. Wszystkie mają jedną intencję: znaleźć punkt największej dźwigni — dla biznesu i dla ludzi w nim — a potem przenieść rzadki ludzki osąd właśnie tam.

Analogia z fotografią cyfrową

Najłatwiejsza analogia to fotografia cyfrowa. Kiedy klisza kosztowała, a pamiętam te czasy, rodzina robiła na wakacjach 24 albo 48 zdjęć. Ktoś wybierał kadr, ktoś czekał, aż wszyscy spojrzą w obiektyw. Cena kliszy i złożoność jej wywoływania dawały pewną dyscyplinę w tym, ile zdjęć powstawało.

Fotografia cyfrowa całkowicie usunęła tę barierę ceny. Dziś możesz mieć 40 000 zdjęć, sześć wersji dokładnie tego samego zachodu słońca i żadnego pojęcia, gdzie w tej stercie zniknęły urodziny twojego dziecka. To samo AI zrobiło z całą pracą. Koszt kolejnego szkicu, kolejnego prototypu, kolejnej analizy, kolejnego kawałka kodu spada do zera. Dawna rzadkość wymuszała wybory — i wiele naszych organizacji jest zaprojektowanych tak, by te wybory wymuszać. Ale gdy rzadkość zniknęła, wybory nie stały się mniej ważne. Stały się po prostu łatwiejsze do unikania.

Firma mocno oparta na AI musi więc odpowiedzieć na dwa pytania, żeby udźwignąć ten wolumen. Po pierwsze: co możemy teraz zrobić? Po drugie: na co nie chcemy poświęcać czasu, nawet jeśli jest to niemal darmowe? Dojście do tych 15 przykazań pomaga odpowiedzieć na oba.

Przykazanie 1: Nie spowalniaj inżynierii — idź szybko

Wiem, że brzmi to jak hasło każdego startupu z Doliny Krzemowej, więc doprecyzuję. Szybkość to nie proszenie ludzi, by więcej pracowali z AI tylko po to, by pracować z AI. Szybkość to przyspieszanie pętli uczenia się. A pętle uczenia napędza to, co potrafimy pokazać klientom — co z kolei zależy od kodu, który potrafimy złożyć.

Stary proces rozciągał dystans między kolejnymi zakładami, bo każda zmiana pochłaniała rzadką moc inżynierską, a do czasu jej wdrożenia pierwotne pytanie mogło się już zmienić. Byłem tym menedżerem produktu, który coś wypuścił, gdy pierwotne pytanie było już nieaktualne. AI usunęło tak wiele kosztu kolejki, że sama kolejka przestała być istotna. Możemy skupić czas na pytaniu: skoro mamy tak ogromną prędkość inżynieryjną, którą chronimy, jak budować ambitnie, by dostarczać klientom nadzwyczajną wartość?

Przykazanie pierwsze wystawia każdą inną regułę na próbę. Czy to spotkanie skraca drogę od dowodu do lepszego produktu? Czy skraca pętlę uczenia? Jeśli nie — zlikwiduj je. Czy ten dokument niesie decyzję? Jeśli nie — usuń go. Czy to zatwierdzenie faktycznie wyłapuje ryzyko, czy to tylko papierologia? Czy to przekazanie pracy poprawia doświadczenie klienta? Jeśli nie umiemy nazwać zadania, które wykonujemy procesem wokół inżynierii, to prawdopodobnie ten proces spowalnia.

Drugą rzeczą rzadką jest dystrybucja. Zbudowanie czegoś, czego nikt nie widzi, wciąż jest warte zero — tak samo jak 10 lat temu. Tanie wykonanie podnosi wartość decyzji o tym, co zasługuje na istnienie, i o dostarczeniu pożytecznej rzeczy przed właściwą osobę.

Klaster najbardziej prowokacyjny: koniec z roadmapami

Ułożę te reguły w klastry. Zacznijmy od najbardziej prowokacyjnego.

• Przykazanie 3: Produkt nie tworzy roadmap.
• Przykazanie 5: Produkt nie kontroluje ani nie steruje czasem inżynierii.

Gdybym się na tym zatrzymał, nie miałbym radykalnego nowego systemu operacyjnego budowania firm — miałbym tylko dobry sposób na produkowanie chaosu. Ale żyjemy w innym świecie. AI sprowadziło koszt budowania do zera. Zespół potrafi teraz pokazać klientowi działającą wersję, zanim dawne spotkanie roadmapowe znalazłoby wolną godzinę w kalendarzach wszystkich uczestników. I nie żartuję. Z narzędziami takimi jak 5.6 Ultra, jak Fable 5, z systemem wieloagentowym takim jak Ringer, o którym mówiłem w tym tygodniu, możesz mieć gotowy produkt, zanim za dwa dni odbędzie się to spotkanie.

(Informacja dodatkowa: „5.6 Ultra”, „Fable 5” i „Ringer” to nazwy narzędzi AI przywoływane przez autora jako przykłady bardzo szybkiego budowania; traktuj je jako ilustrację tempa, nie rekomendację konkretnych produktów.)

Ale to nie usuwa potrzeby osądu produktowego. Usuwa jedynie potrzebę, by produkt trzymał się z dala od kodu. Dlatego przykazanie 4 idzie w parze z 3 i 5:

• Przykazanie 4: Produkt codziennie siedzi w terminalu. Tak czy inaczej wejdziesz w kod.
• Przykazanie 6: Produkt siada z inżynierią i codziennie z nią pracuje („jamuje”).

Bierzesz na siebie, jako PM, obowiązek siedzenia w pracy, dotykania materii, przyprowadzania klienta i podejmowania decyzji, gdy rzecz staje się realna. Wejście PM-a w kod, wspólne dłubanie produktu z inżynierią wokół artefaktu tworzonego dla klienta — to właśnie pozwala robić dobre myślenie produktowe bez spowalniania całego pociągu.

Chcę coś wyjaśnić. Podstawowe pytania, na które te kompetencje muszą odpowiadać, się nie zmieniają. Inżynieria wciąż musi odpowiedzieć: czy ten kod działa i czy będzie działał dalej? To wysoka poprzeczka, a wiele zespołów używa AI, by się pod nią prześlizgnąć. Produkt wciąż musi odpowiedzieć: czy to powinno istnieć i czy ktokolwiek dostatecznie mocno chce tego używać? Ten sam terminal, może wspólny kod — inne pytania.

Dlatego liczy się przykazanie 13: zachowuj się, jakby liczyło się tylko jedno — głęboko pomocne i zachwycające doświadczenie klienta. Wykonujesz tę pracę koordynacyjną, którą kiedyś robił cały proces roadmapowy.

Przykazanie 12 rozszerza powierzchnię produktową dla designu. Design jest w kodzie. Terminal to przestrzeń projektowa. SDK to przestrzeń projektowa. UI też. Gdy płatność się nie udaje, a komunikat mówi klientowi dokładnie, co robić dalej — ktoś zaprojektował ten scenariusz awaryjny. Gdy agent dochodzi do granicy uprawnień i — tak, projektujemy już dla agentów — wyjaśnia, czego potrzebuje, zamiast po cichu zawieść, ktoś zaprojektował to agentowe doświadczenie. Projektant, który projektuje wyłącznie ekrany, projektuje dziś lobby, podczas gdy reszta budynku powstaje bez niego. Nie chcemy być w tej sytuacji, bo potrzebujemy pytań, które zadaje design, na całej długości naszych systemów technicznych. Nie widzę świata, w którym nie korzystamy z designu — widzę świat, w którym design jest „przeciążony pracą”, bo powstało tak wiele powierzchni wymagających dobrego projektowania.

Te reguły tworzą jeden system. Jeśli usuwasz roadmapy, musisz mieć system zastępujący odległą koordynację codziennym kontaktem, jasną odpowiedzialnością i doświadczeniem klienta na tyle konkretnym, że da się je ocenić — i to wszystko w czasie rzeczywistym.

Klaster pisania: dokument jako kod

• Przykazanie 2: Żadnych spotkań dłuższych niż godzina. Jeśli to wymusza dokumentację — o to właśnie chodzi. Chcemy priorytetyzować dokumentację, bo coraz częściej mamy agentów, którzy potrzebują informacji zwrotnej o tym, co omawiamy na spotkaniach. Pisanie jest mechanizmem wymuszającym pracę dla agentów.

To prowadzi do przykazania 11: dokumentacja jako kod. Mam to na myśli dosłowniej, niż miałbym jeszcze rok temu. Agenci czytają dokumenty i na ich podstawie decydują, co zrobić. Dokument może dostarczyć standardu, hierarchii źródeł, uprawnień, ścieżki eskalacji, definicji ukończenia. Jeśli masz niejednoznaczne dokumenty, rozsiewasz chaos w całym systemie. Musisz mieć obsesję na punkcie tego, by twoje dokumenty były jasne. Inaczej po prostu spychasz chaos w dół strumienia. I to jest właśnie ryzyko „AI slopu” — bylejakości generowanej przez AI.

(Informacja dodatkowa: „AI slop” to potoczne określenie masowo generowanych, mało wartościowych treści AI.)

Nie obchodzi mnie, czy w dokumencie napiszesz „masz absolutną rację”. Obchodzi mnie, czy wiesz, co się w nim znajduje, i czy rozumiesz, co chcesz nim osiągnąć. Tak często, gdy ludzie siadają do pisania, brakuje im tej jasności — i wychodzi „slop”, bo nie ma ludzkiej klarowności. Nie ma dla tego substytutu.

Dyscypliny pisania nauczyłem się w Amazonie, na długo przed obecną falą agentów. Musieliśmy wszystko pisać ręcznie jak troglodyci. Kiedyś doszedłem do 57 wersji sześciostronicowej narracji. W produkcie mieliśmy kulturę uczenia się pisania od siebie nawzajem. Jadaliśmy razem lunche i przeglądaliśmy dokumenty, bo to pomagało ulepszać własne, uczyło krytykować cudze i lepiej zadawać pytania. To budowało silniejszą kulturę dokumentów, która nie powinna zaginąć. Nie musimy wszyscy przyjmować dokładnie standardów Amazona, ale wszyscy musimy tak samo dbać o pisanie w erze agentów. Musimy traktować klarowność intencji, którą komunikujemy w piśmie, z taką rygorystycznością.

I tu dochodzimy do przykazania 7: zabijaj comiesięczne spotkania. Chcemy audytować swoje regularne zobowiązania czasowe i przeznaczać więcej czasu na budowanie, bo to niesamowity moment, by budować. Mamy ogromną dźwignię, jeśli mamy ambicję i spójność (alignment). A jeśli się zastanawiasz — tak, zbudowałem do tego narzędzie, które pomaga audytować spotkania, bo to sprawa dla mnie osobista. Chcę, żebyśmy dobrze wykorzystywali czas. Link znajdziesz poniżej.

To jest klaster pisania: jakość, na jakiej musimy pisać, nasze zobowiązania czasowe, sposób spędzania czasu na spotkaniach oraz to, co przenosimy do pisma, by ten czas oszczędzić. Wszystko to sprowadza się do intencji. Czy komunikujemy intencję jasno na spotkaniach? Czy komunikujemy ją jasno w piśmie?

Klaster behawioralny: żeby tempo AI było znośne dla ludzi

Trzeci klaster jest dla nas, ludzi. Chodzi o to, by tempo AI dało się przeżyć w ludzkich kulturach i zespołach — bo to duża zmiana.

• Przykazanie 8: Zachowuj elastyczność w dostarczaniu wartości — jak woda opływająca kamień. Umiejętność adaptacji. Wiem, że znasz to z książek biznesowych, ale w erze AI ma to znaczenie, bo więcej komunikujemy i piszemy. Byliśmy przyzwyczajeni do rozmów twarzą w twarz; teraz spotkania osobiste są cenniejsze, ale pisanie musi wejść na wyższy poziom, a my mamy zakładać dobre intencje. Nie ma powodu — niezależnie od stanowiska — by narzekać czy jęczeć. Wszyscy mamy dostęp do niesamowitej ilości inteligencji i narzędzi do budowania rozwiązań. Powinniśmy być w stanie albo bezpośrednio naprawić problem, który nas martwi, albo zaproponować kompletną naprawę.

• Przykazanie 14: Buduj z zespołem. Nie budujesz sam. To trochę kontrowersyjne — wiem, że istnieją całe startupy oparte na wizji jednoosobowej firmy wartej miliard dolarów. Ja wierzę, że trwałe biznesy buduje się zespołami. Mogą być mniejsze niż kiedyś, bo mały, dobrze skoordynowany zespół potrafi zrobić bardzo wiele, ale świetne małe zespoły budują niesamowite rzeczy — razem. Wspólne budowanie pozwala wychwytywać nawzajem błędy, doprecyzowywać intencję dla AI i skuteczniej budować dla klientów. Znajdź społeczność. Nie musi być moja — czyjaś inna jest równie dobra, ale znajdź jakąś. Tania indywidualna produkcja to nie to samo, co stworzenie czegoś, czego ludzie chcą. Jedna osoba i jeden agent mogą wyprodukować ogrom materiału, ale wciąż potrzebują nas wszystkich, by dojść do smaku, wiedzy dziedzinowej, kontaktu z klientem, marki i odwagi, by powiedzieć, że coś nie działa.

Jest jeszcze jedno przykazanie z tego klastra — przykazanie uczenia (teaching commandment). Chodzi o pomaganie tym, którzy nie idą tak szybko, i uczenie się od tych, którzy idą szybciej. Tak wszyscy razem przyspieszamy. To prawda w organizacjach, a jeśli nie masz organizacji lub chcesz uczyć się od innych — to prawda także w internetowych społecznościach.

Dwa sposoby, by to wszystko zepsuć

Zanim skończę: są dwa częste sposoby, by zrujnować całą tę koncepcję.

Pierwszy to adopcja częściowa. Jeśli weźmiesz tylko regułę „bez roadmap”, ale nie wprowadzisz PM-ów do kodu, produkujesz jedynie chaos. Wiele firm spoza Doliny nie zdaje sobie sprawy, że ten proces trzeba przejść w całości naraz, inaczej się nie uda. Będzie boleśnie, ale łatwiej się dostosować, jeśli od razu wyłożysz cały zestaw oczekiwań. Dostać 15 reguł naraz może przytłoczyć — „o rany, to za dużo”. Dzielę się nimi wszystkimi naraz, bo zespoły, które faktycznie przyspieszają tempo, nie odgryzają tego kawałek po kawałku. Traktują to jako połączony system, w którym muszą się zmienić ludzie, klarowność intencji wokół pisania i sposób wchodzenia w kod.

Drugi tryb porażki to właśnie branie tylko fragmentu: „Wiesz co, Nate, masz rację, powinniśmy lepiej ograniczać spotkania”. To cię nie zaprowadzi tam, gdzie chcesz dojść. Trzeba spojrzeć na cały system jako sposób budowania ludzkiej infrastruktury, która przyspiesza przesuwanie firmy ku rzeczywistości skupionej na kodzie i agentach. Przenosisz coraz więcej firmy do kodu, żeby agenci mogli na nim działać — po to, by uzyskać wyższą jakość i szybsze wyniki.

Duża część tego, dlaczego OpenAI i Anthropic wdrażają szybciej, leży w tym, że mają taką kulturę: uczą jej, zaszczepiają ją i pod nią rekrutują. Wzmacniają ją w miarę wzrostu, więc się rozpędza. Każdy, kogo zatrudniają w Anthropic, oczekuje już takiej szybkości — a to o wiele łatwiejsze niż wchodzenie do firmy, gdzie wszyscy oczekiwali wydań kwartalnych, i próba ich rozpędzenia. To ogromna zmiana kultury i to jest część tego, co się dzieje. Dlatego wciąż powtarzam: trzeba przeprowadzić całą tę rozmowę i być gotowym, by ruszyć naprzód z całym biznesem.

Jeśli chcesz zgłębić temat, mam poświęcony mu cały artykuł na Substacku, jest też narzędzie kalendarzowe, które zbudowałem, a także towarzyszący przewodnik, który możesz przepuścić przez swojego agenta, by zbudować kompletny proces zarządzania zmianą dla twojej firmy czy zespołu, w dowolnej skali. Ten film to punkt wyjścia — ma cię skłonić do myślenia o tym, czego naprawdę wymaga transformacja w erze AI. Cała dyskusja o tym rusza w poniedziałek.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Przewaga AI-native firm to kultura, nie samo narzędzie

Na czym polega: Anthropic i OpenAI wdrażają szybko nie dlatego, że mają lepsze AI, lecz dlatego, że przebudowały kulturę i organizację pracy pod tempo, które AI umożliwia.

Jak stosować: Zanim kupisz kolejne narzędzie, zdiagnozuj, gdzie ludzie i procesy są wąskim gardłem między dowodem a wdrożeniem. Zainwestuj w zmianę nawyków, oczekiwań i rekrutacji, nie tylko w licencje.

Na co uważać: Nie myl aktywności z prędkością. „Więcej pracy z AI” bez skrócenia pętli uczenia to tylko iluzja postępu.

2.Przenoś powtarzalną koordynację do kodu i dokumentów

Na czym polega: Decyzje ze spotkań, przypomnienia i recenzje mają stawać się trwałymi dokumentami i systemami, na których mogą działać agenci — a nie ulotnymi ustaleniami w głowach ludzi.

Jak stosować: Wskaż 3–5 powtarzalnych interakcji (statusy, zatwierdzenia, onboarding) i zamień je na zapisany standard z jasną ścieżką eskalacji i definicją ukończenia.

Na co uważać: Zaufanie, smak i osąd zostają ludzkie — nie próbuj kodyfikować wszystkiego. Przenoś powtarzalne, zostawiaj wartościujące.

3.Traktuj przykazania jako jeden system, nie bufet

Na czym polega: 15 reguł działa tylko razem; wdrożenie jednej (np. „bez roadmap”) bez pozostałych produkuje chaos.

Jak stosować: Zaplanuj zmianę jako spójny pakiet i zakomunikuj cały zestaw oczekiwań naraz, nawet jeśli wdrażasz etapami.

Na co uważać: Adopcja częściowa to najczęstszy tryb porażki. Jeśli nie masz mandatu na całościową zmianę, poczekaj, aż go zdobędziesz, zamiast wyrywać pojedyncze reguły.

4.Wpuść produkt do terminala, zamiast dawać mu roadmapy

Na czym polega: Skoro koszt zbudowania działającej wersji spadł niemal do zera, PM ma podejmować decyzje przy powstającym artefakcie, a nie sterować inżynierią przez tickety i roadmapy.

Jak stosować: Ustaw codzienny wspólny czas produktu z inżynierią w kodzie („jam”). PM przynosi klienta i decyzje, gdy rzecz staje się realna.

Na co uważać: To nie znaczy, że PM przejmuje sterowanie czasem inżynierii — chodzi o wspólną pracę nad artefaktem, bez spowalniania inżynierii.

5.Skróć pętlę uczenia się jako główny cel prędkości

Na czym polega: Prędkość mierzy się tym, jak szybko dowód od klienta przekłada się na lepszy produkt, a nie liczbą wypuszczonych rzeczy.

Jak stosować: Każde spotkanie, dokument i zatwierdzenie oceniaj pytaniem: „Czy to skraca drogę od dowodu do lepszego produktu?”. Jeśli nie — usuń.

Na co uważać: Szybkie budowanie bez dystrybucji jest warte zero. Równolegle pytaj, co zasługuje na istnienie i jak trafi do właściwej osoby.

6.Dokument jako kod — obsesja na punkcie klarowności intencji

Na czym polega: Agenci czytają dokumenty i na ich podstawie działają, więc niejednoznaczny dokument rozsiewa chaos w całym systemie.

Jak stosować: Pisz dokumenty z jasnym standardem, hierarchią źródeł, uprawnieniami i definicją ukończenia. Zanim napiszesz, sam wiedz, co chcesz osiągnąć.

Na co uważać: „AI slop” bierze się z braku ludzkiej klarowności, nie z braku narzędzi. Żadne AI nie zastąpi tego, że rozumiesz, co jest w twoim dokumencie i po co.

7.Audytuj czas: krótsze spotkania, mniej cyklicznych rytuałów

Na czym polega: Spotkania powyżej godziny są zakazane, a comiesięczne rytuały warto zabijać, by przenieść czas do budowania — i wymusić dokumentację.

Jak stosować: Przejrzyj kalendarz, usuń spotkania niedostarczające decyzji, a to, co trzeba, zapisuj, by agenci i ludzie mogli z tego korzystać później.

Na co uważać: Ograniczanie spotkań w oderwaniu od reszty systemu to tylko cięcie kosztów. Uwolniony czas ma trafić do budowania i pisania, nie do kolejnych kanałów komunikacji.

8.Rozszerz design na terminal, SDK i doświadczenia agentowe

Na czym polega: Projektowanie to już nie tylko ekrany — to komunikaty błędów, scenariusze awaryjne i granice uprawnień agentów.

Jak stosować: Włączaj projektantów w projektowanie zachowań systemu i agentów, nie tylko UI. Pytaj, co się dzieje, gdy coś zawodzi lub agent napotyka granicę.

Na co uważać: Projektant ograniczony do ekranów „projektuje lobby, gdy reszta budynku powstaje bez niego” — to strata najcenniejszych pytań, jakie zadaje design.

9.Buduj w zespole i w społeczności

Na czym polega: Tania indywidualna produkcja nie równa się tworzeniu czegoś, czego ludzie chcą; smak, wiedza dziedzinowa i odwaga do powiedzenia „to nie działa” powstają w zespole.

Jak stosować: Utrzymuj małe, dobrze skoordynowane zespoły, które wzajemnie wychwytują błędy i doprecyzowują intencję dla AI. Dołącz do jakiejś społeczności praktyków.

Na co uważać: Nie daj się uwieść mitowi jednoosobowej firmy za miliard dolarów. Jeden człowiek z agentem wyprodukuje dużo materiału, ale rzadko coś trwałego.

10.Zakładaj dobre intencje i naprawiaj, zamiast narzekać

Na czym polega: Skoro każdy ma dostęp do potężnej inteligencji i narzędzi, od każdego — niezależnie od stanowiska — oczekuje się propozycji kompletnej naprawy zamiast narzekania.

Jak stosować: Gdy widzisz problem, przynieś gotowe rozwiązanie albo pełną propozycję. Pomagaj wolniejszym i ucz się od szybszych — tak przyspiesza cały zespół.

Na co uważać: Więcej komunikacji przenosi się do pisma, więc łatwiej o nieporozumienia. Świadomie podnoś jakość pisania i traktuj spotkania twarzą w twarz jako cenniejszy, rzadszy zasób.