O czym jest ten film
- Rozmowa Davida Ondreja z Alexem Liebermanem (współzałożyciel Morning Brew i 10X) oraz Danem, dyrektorem inżynierii w 10X.
- Jak wprowadzić dużą, wolno poruszającą się firmę w tryb „AI native” — i dlaczego trzeba spotkać ją tam, gdzie faktycznie jest.
- Rozróżnienie na AI „single player” i „multiplayer” jako pierwszy framework, który 10X daje klientom.
- Dlaczego większość problemów z AI w korporacjach okazuje się w rzeczywistości problemami z danymi.
- Koncepcja „kontekstu jako kodu” i „meta harness” — repozytorium markdownów ważniejsze niż repozytorium kodu.
- Pokaz wewnętrznego CLI 10X: artefakty (epiki, specyfikacje, konwencje), tryb dla człowieka i dla agenta, hook startowy jako „życzliwy prompt injection”.
- Walidator procesu — „linter dla całego SDLC”, wykrywający rozjazd między deklarowanym a wyliczonym statusem prac.
- Szczegółowy opis „maszyny do treści” Alexa: wybór twórcy, oracle skanujący wewnętrzne źródła, panel prowadzących wywiad, rada redaktorów, silnik repurposingu i plik lekcji.
- Spór o to, czy inżynierowie będą jeszcze czytać i pisać kod — i dlaczego fundamenty inżynierskie mogą mieć większe znaczenie niż kiedykolwiek.
- Dlaczego w świecie po AI zostają w zasadzie trzy fosy: ludzie, zaufana dystrybucja i unikalna wiedza wewnętrzna.
Redakcyjne tłumaczenie
David: Alex, Dan — mam pytanie. Jak wziąć starą, wolno poruszającą się firmę i uczynić ją AI native?
Alex: Odpowiedź jest w gruncie rzeczy taka sama jak na pytanie: „jak sprawić, by ktokolwiek, kto ma już swój bagaż kontekstu, zaczął robić coś inaczej?”. Trzeba wyjść naprzeciw firmie tam, gdzie ona naprawdę jest — gdzie są jej systemy, gdzie są jej ludzie, na jakim etapie transformacji AI się znajduje.
Gdyby dziś, w 2026 roku, projektować od zera biznes doradczy dla firm z Fortune 2000, musiałby to być partner full stack. Historycznie największe firmy konsultingowe na świecie robiły jedną rzecz. Dostawały opis problemu. Grupa konsultantów z menedżerem przez kilka miesięcy pracowała nad rozwiązaniem w formie prezentacji. Potem spotkanie z klientem, wręczenie stupięćdziesięciostronicowej talii slajdów — i „trzymajcie się, na razie”. A klient zostawał sam z koniecznością rozwiązania problemu.
Nasze zdanie jest takie, że w świecie po AI trzeba dotknąć każdego ogniwa łańcucha wartości w transformacji firmy. Opracować strategię. Wykonać całą pracę nieinżynierską wokół zarządzania zmianą i wszystko to, co musi się wydarzyć obok technologii, żeby technologia w ogóle miała wartość. A potem faktycznie wejść do firmy w modelu forward deployed.
(Informacja dodatkowa: forward deployed engineer to inżynier oddelegowany do pracy bezpośrednio u klienta, wewnątrz jego zespołów — model spopularyzowany przez Palantir).
Wracając do pytania: jest sporo firm z Fortune 500, w których pierwszą rzeczą, jaką robimy, jest dosłownie wzięcie zarządu albo kadry kierowniczej i nauczenie ich obsługi Claude Code czy Claude Cowork. A inne przychodzą do nas i mówią: „chcemy zbudować agentów back office do fakturowania, należności, zobowiązań, HR”. Wtedy wychodzimy naprzeciw im w tym miejscu. Chodzi o to, jak zredukować tarcie tak blisko zera, jak to po ludzku możliwe.
Co odróżnia dobrego konsultanta AI
David: Rozumiem. To jest chyba jedna z największych różnic między przeciętnym konsultantem, który coś ci daje i musisz sam sobie z tym poradzić, a świetnym, który pomaga wdrożyć. Co jeszcze? Bo wielu ludzi chce być konsultantami AI — dużo osób próbowało zakładać takie firmy.
Alex: Powiedziałbym tak: ani Arman, mój współzałożyciel i wspólnik zarządzający, ani ja nie marzyliśmy o byciu konsultantami. Żaden z nas nie jest konsultantem. Naszą prawdziwą wizją dla 10X jest zbudowanie współczesnych Bell Labs — i to z różnych powodów.
Zorientowałem się w pewnym momencie, że jeśli nie jestem w domu z żoną i córką, to musi być tego warte. A „warte” znaczy dla mnie: rozwiązywanie naprawdę trudnych problemów na granicy technologii, z najmądrzejszymi i najbardziej zdeterminowanymi ludźmi, z jakimi kiedykolwiek pracowałem.
Arman jeszcze w liceum albo na studiach przeczytał książkę The Innovators. Wyjątkowa rzecz. Opowiada historię informatyki dosłownie od Charlesa Babbage’a i Ady Lovelace aż po AI. Mówi o łuku innowacji i o tym, jakie surowce sprawiały, że ośrodki innowacji odnosiły sukces — czy to Bell Labs z tranzystorem, czy DARPA z internetem, czy Xerox PARC.
(Informacja dodatkowa: The Innovators Waltera Isaacsona, wydana w 2014 roku).
Krótka odpowiedź brzmi: przez cały czas chodziło o genialnych ludzi, którym daje się bardzo dużo autonomii, ale też kierunek, dystrybucję i zasoby. Powiedzieliśmy sobie więc: skoro chcemy mieć wszystkie te pięć składników, a nie mamy ochoty od startu zbierać setek milionów dolarów finansowania — jak to zrobić? I odpowiedź, całkiem elegancko, zaczyna wyglądać tak: pomagać największym firmom świata rozwiązywać ich najtrudniejsze problemy z pomocą AI.
Rozwiązując te problemy, dowiadujemy się od korporacji, jakie są ich największe wyzwania. Płacą nam za to, więc biznes generuje gotówkę. Pomagając przedsiębiorstwom znaleźć się po właściwej stronie historii, zdobywamy wszystkie surowce potrzebne do zbudowania laboratorium AI stosowanego, w którym inkubujemy jedne z najbardziej doniosłych technologii świata po AI.
Rola forward deployed engineera
Alex: Jedną z najciekawszych ról, jakie można dziś mieć jako inżynier, jest właśnie ta rola inżyniera AI stosowanego pracującego u klienta. Przyspieszasz rozwiązywanie bardzo trudnych, szytych na miarę problemów korporacji, które wcześniej mogły liczyć wyłącznie na rozwiązania uniwersalne. Teraz można wejść, znaleźć najbardziej pokręcone problemy w firmie i rozwiązać wiele z nich w krótkim czasie.
Jeżeli uda ci się skrócić czas do momentu magii na wczesnym etapie współpracy i pokazać zarządowi albo innemu decydentowi, jaką dźwignię ich zespoły mogą uzyskać dzięki AI, uruchamia się kaskada — wszyscy inni w organizacji też chcą się załapać, a my możemy budować dla nich coraz więcej.
David: Czyli w zasadzie innowacja jako usługa.
Alex: Dokładnie tak.
David: Konsulting to chyba za słabe słowo.
Alex: Zgadzam się i myślę, że to działa na naszą korzyść. Bo niestety najlepsze talenty techniczne nigdy nie trafiały do konsultingu. Jeden sposób sprzedaży konsultingu wygląda tak: wchodzisz do firmy, opowiadają ci o problemie, odpowiedzią zwykle jest zwalnianie ludzi, wręczasz talię slajdów, wychodzisz, nigdy nie widzisz owoców swojej pracy i idziesz do następnego klienta.
Ale można też ustawić to inaczej: oto ogromna firma z chaotycznymi, złożonymi i naprawdę ważnymi wyzwaniami. Nie ma odpowiedzi i potrzebuje zespołu A, który dostarczy jej innowację jako usługę — nie samą innowację, ale innowację i wdrożenie, czyli realny zwrot z inwestycji i wzrost napędzany dostarczanymi wnioskami.
Fajne jest też to, że nie musisz robić tego z jedną firmą w nieskończoność. Nuda i spłaszczenie rozwoju u inżynierów w każdej organizacji często biorą się właśnie stąd, że pracujesz nad jednym bardzo konkretnym wyzwaniem przez bardzo długi czas. Konsulting z definicji daje różnorodność pracy.
David: No i ADHD jest zaspokojone, a ty wciąż pracujesz w tej samej firmie. Nie musisz zmieniać pracodawcy, a masz różne wyzwania.
Alex: Dokładnie.
Single player i multiplayer AI
Alex: Jest kilka pytań, które klienci zadają nam regularnie. Jedno z nich brzmi: jak w ogóle myśleć o tym, gdzie w naszym biznesie jest przestrzeń dla AI? Mniej więcej w połowie przypadków dzwoni ktoś z zarządu i mówi: „Słuchajcie, jestem w grupie na czacie z kolegami z innych zarządów, wszyscy opowiadają, jakie fajne rzeczy robią z AI, mam FOMO i nie wiem, co powinniśmy zrobić, ale potrzebujemy AI. Pomożecie?”.
Jednym z pierwszych frameworków, jakie dajemy, jest rozróżnienie na AI single player i multiplayer. Single player to sytuacja, w której mówię: „David, do tej pory wpisywałeś zapytanie w Google i dostawałeś odpowiedź. Postawię przed tobą GPT albo Claude’a. Zadaj to samo pytanie i zobacz, co sądzisz o odpowiedzi”. Zero zmiany zachowania. Po prostu to robisz. I to jest wartościowe.
W kontekście korporacji wygląda to tak — i zwykle jest to pierwszy krok w transformacji — że firma podpisuje z jednym z laboratoriów dużą umowę na tokeny. Z OpenAI albo z Anthropikiem: „zobowiązujemy się do wydania pięciu, dziesięciu milionów dolarów na tokeny, tylko musimy mieć pewność, że mamy bezpieczne instancje Codeksa i GPT albo Claude Code i Cowork”. Pierwszy krok single playera to dosłownie postawienie przed ludźmi mocy modelu na poziomie state of the art, a potem, w idealnym świecie, nauczenie ich, jak faktycznie tego używać w codziennej pracy.
To jest naprawdę wartościowe i twierdzę, że większość firm właśnie tam powinna zacząć. Ale to jest single player — ludzie uzyskują dźwignię wyłącznie dla własnej pracy, nie ma efektu kumulacji.
Multiplayer AI to podejście, w którym patrzysz na horyzontalne technologie albo procesy w firmie i przez ich wymyślenie na nowo tworzysz dźwignię nie dla jednej osoby, lecz dla całej firmy albo całej funkcji. To może być zbudowanie agenta sprzedażowego albo SDR-owego, który każdemu handlowcowi zwraca czas dotąd tracony na logistykę i drobiazgi zamiast na rozmowy z klientami.
(Informacja dodatkowa: SDR — sales development representative, handlowiec odpowiedzialny za wstępną kwalifikację leadów).
Albo — i mówimy to bez przerwy — większość klientów przychodzi do nas z problemem AI, który okazuje się problemem z danymi. Robimy dla nich jakąś formę inżynierii danych, bo nie są nawet blisko gotowości danych pozwalającej zbudować cokolwiek agentowego na wierzchu. To kolejny przykład multiplayer AI: jeśli to zrobisz dobrze, dźwignia dla całej organizacji jest ogromna.
Nasze podejście jest takie, że w 10X robimy jedno i drugie, ale wykładniczą korzyść — i zarazem najtrudniejszą, najboleśniejszą i najbardziej chaotyczną robotę, przy której możemy najbardziej pomóc — daje strona multiplayer.
Repozytoria markdownów jako pamięć zespołu
David: Podzielę się tipem z naszej dużo mniejszej firmy. Każdy pracuje w innym repozytorium GitHuba — mamy jedno do rekrutacji, jedno do współprac z markami, jedno do filmów na YouTube. Zamiast czatować w webowej aplikacji Claude’a czy ChatuGPT, wszystkich zmuszam do rozmowy w Codeksie i Claudzie oraz do zapisywania efektów w plikach markdown w tych repozytoriach. Dzięki temu każdy inny może odpalić własnego Claude’a z Fable i nawet jeśli to nie jest jego obszar biznesu, ma od razu wszystkie umiejętności specyficzne dla projektu, wszystkie pliki markdown, cały kontekst.
To kompletna zmiana zasad gry, bo ludzie, którzy pół roku temu nie byli techniczni i nie używali AI tak, jak mogli, teraz to robią. Dzielenie się skillami jest naprawdę magiczne — ktoś, kto w danym obszarze nie pracuje, czuje, że da radę, bo jego Fable czyta te pliki i podaje mu brief. To jest forma multiplayera.
Kontekst jako kod
Alex: Zdecydowanie. Dodam jedną rzecz — dokładnie tak Dan i zespół inżynieryjny 10X myślą o całym naszym SDLC. To idea kontekstu jako kodu.
(Informacja dodatkowa: SDLC, software development life cycle — cykl życia wytwarzania oprogramowania).
Ciekawe jest to, że inżynierowie od dawna myśleli o sobie jako o ludziach zorganizowanych i metodycznych w tym, jak strukturyzują pliki i informacje przy budowie oprogramowania. W tradycyjnej pracy umysłowej tak nie jest. Pod wieloma względami nietechniczni pracownicy wiedzy dopiero nadrabiają zaległości i dochodzą do tego, jak inżynierowie zawsze podchodzili do rusztowania własnej pracy. A w inżynierii w 10X po prostu wynosimy to na kolejny poziom — jesteśmy jeszcze staranniejsi i bardziej nakazowi w tym, jaki kontekst dostarczamy agentom kodującym.
Dan: Myślę o tym jako o nowym rodzaju problemu. Wcześniej rozwiązywało się problem koordynacji między ludźmi a ludźmi. Dlatego rozwój zwinny sprowadzał się do mnóstwa ceremonii: codzienne spotkania, omawianie pracy, retrospektywy na koniec każdego tygodnia — zapychasz kalendarz maksymalną liczbą spotkań, żeby przekazać jak najwięcej informacji.
Teraz to jest problem koordynacji między ludźmi, innymi ludźmi i agentami jako trzecią stroną. Tyle że agenci są w roli głównego bohatera — to oni faktycznie wykonują robotę na ziemi. Dlatego bycie kulturą pisaną jest ważniejsze niż kiedykolwiek: gromadzenie tych wszystkich markdownów sprawia, że i ludzie mogą się dogadać co do tego, nad czym pracują w różnych projektach, i agenci mogą zostać błyskawicznie zbriefowani.
A w 10X doprowadzamy to do skrajności. Jeśli pomyśleć od pierwszych zasad, jak przeprojektowałbyś SDLC pod agentów — agenci utrzymują spójność w obrębie znacznie większej ilości informacji naraz, niż kiedykolwiek potrafili ludzie. Można więc tworzyć większe i bardziej złożone plany, które rozpisują więcej architektury i więcej planów, znacznie dalej w przód, niż było to możliwe wcześniej w tych ludzko-ludzkich ceremoniach zwinnych.
Mamy więc bardzo konkretne struktury i typy artefaktów markdown, które piszemy do każdego projektu, tak żeby agenci mogli je łatwo walidować. Traktujemy kontekst jak kod — agenci potrafią natychmiast wyciągnąć właściwy kontekst we właściwym momencie i utrzymywać całość w synchronizacji, jako nową formę maszyny do oprogramowania.
David: Z każdym kolejnym projektem trzymam w repozytorium coraz więcej rzeczy. Mam dosłownie /docs/marketing. Mam plik z feedbackiem od użytkowników — każda uwaga ląduje tam, w markdownie. Mam /docs/external, gdzie trafiają wszystkie wdrożenia i rzeczy zewnętrzne wobec kodu, bo kto wie, kiedy agent będzie tego potrzebował. Może pojawi się problem z hostingiem frontendu, a agent, wiedząc, jak to jest skonfigurowane i jakie są zmienne, znajdzie brakujący wpis środowiskowy.
Potrzebujemy na to nowego słowa, bo to już nie jest baza kodu. Kiedyś był tam sam kod, a teraz to jest raczej baza kontekstu.
Alex: Powinniśmy nazwać to czymś w rodzaju „meta harness”.
David: Meta harness. Dobrze.
(Informacja dodatkowa: harness w żargonie agentowym to cała obudowa wokół modelu — narzędzia, instrukcje i pętla wykonania. „Meta harness” oznacza tu warstwę wyżej: repozytorium kontekstu sterujące pracą agentów).
Alex: Tak to nazwaliśmy wewnętrznie w 10X. A co właściwie chcemy osiągnąć? Agenci kodujący oferują prędkość, która wcześniej była nieosiągalna, ale im dłużej trwa zadanie, tym większe ryzyko entropii i odejścia od planu. Pytanie brzmi: jak zminimalizować entropię i rozjazd, jednocześnie optymalizując pod prędkość, która jest siłą tej technologii?
Fosy w świecie po AI
David: Chcę też pogadać o waszej maszynie do treści, bo to jeden z najbardziej unikalnych systemów. Myślę, że coraz więcej firm będzie tak robić — treści tworzy nie tylko założyciel i człowiek od marketingu, ale więcej osób.
Alex: To ci na pewno zabrzmi znajomo, bo masz nogę w obu światach — budujesz oprogramowanie, ale sam widziałeś siłę treści.
Zacznę od jednej z naszych najwyższego rzędu tez w 10X: w świecie po AI liczba pozostałych fos w biznesie się kurczy. Co jest dziś fosą? Do pewnego stopnia efekty sieciowe. Do pewnego stopnia dane. Do pewnego stopnia ludzie — i twierdzę, że ludzie są fosą bardziej niż kiedykolwiek, bo AI jest jak lustro z krzywego zwierciadła: sprawia, że inteligentni ludzie o wysokiej sprawczości wyglądają naprawdę dobrze, a głupich ludzi o niskiej sprawczości sprawia, że wyglądają gorzej.
I twierdzę, że zaufana dystrybucja jest fosą bardziej niż kiedykolwiek. Budujesz oprogramowanie i prawdopodobnie są dosłownie miliony innych inżynierów, którzy zbudują to samo dość szybko. Co więc zarobi ci pieniądze od odbiorców? To, że masz ludzi, którzy ci ufają, a to zaufanie zamienia się w pieniądze na koncie.
Dlatego zawsze uważaliśmy, że budujemy firmę medialną na wierzchu 10X. Będzie ona połączeniem treści markowych — newslettery, głęboka publicystyka, techniczna i nietechniczna — oraz treści opartych na talentach, gdzie dosłownie zatrudniamy Davidów, zanim staną się duzi. Chcemy mieć takich osób w firmie dziesiątki. Ale chcemy też zamienić naszych pracowników w twórców.
Zadałem sobie pytanie: jak zamienić inżynierów albo strategów w 10X w twórców treści? Zaczynając od treści tekstowych, bo o wiele łatwiej dziś wykorzystać do nich AI niż do wideo i multimediów. To samo dotyczy mnie — nie mam całego dnia na tworzenie treści, a byłem pierwszym i najlepszym kanałem marketingowym 10X, więc musiałem utrzymać produkcję.
Idea maszyny do treści była taka: jak zbudować system, który umożliwia obfitość treści, pozwala osobom na pełnych etatach tworzyć nawet przy trzydziestu minutach dziennie, a jednocześnie nie jest armatą strzelającą AI-owym szlamem. Taki był prompt.
Maszyna do treści — warstwa procesu i warstwa osobista
Alex: Maszyna do treści ma warstwę procesu i warstwę osobistą. Warstwa procesu to wszystko, co żyje w gicie dla mojego zespołu — pipeline, czyli wszystkie kroki, przez które przechodzi maszyna, taka linia montażowa od „potrzebuję pomysłu, o czym stworzyć treść” do gotowego materiału opublikowanego na X, LinkedInie albo innej platformie.
Warstwa osobista to pliki, które żyją na twoim komputerze: skodyfikowany zapis twojego głosu, lekcje o treściach, których udzieliłeś maszynie w przeszłości, i inne ważne informacje o tobie, które sprawiają, że maszyna produkuje coś reprezentatywnego dla ciebie.
Podzielę się jedną dużą myślą o tym, jak stworzyć system AI produkujący treści, które nie są szlamem — w czasach, gdy modele wciąż piszą dość słabo. To znaczy: piszą dobrze, ale zawsze zalatuje od tego AI.
David: Te same schematy.
Alex: Dokładnie. Widziałem, jak ludzie tworzą skille — Peter Yang zrobił taki „no AI slop”, który wyłapuje wszystkie znaki rozpoznawcze. Ale przy każdej zmianie modeli pojawią się nowe znaki i to będzie ciągła zabawa w kotka i myszkę.
Moim zdaniem gwarancję, że to nie będzie szlam — niezależnie od tego, jak dobre będą modele — daje coś innego: AI pomaga we wszystkim poza tym, do czego potrzebny jest człowiek. A człowiek jest najbardziej potrzebny — nie tylko w procesie tworzenia treści, szczerze mówiąc w większości procesów, także przy budowie oprogramowania — na pierwszej i ostatniej mili.
David: Tak, ja to nazywam źródłem. Nagrałem o tym shorta: numer jeden różnica między treścią AI, która jest śmieciem, a treścią AI, która ma wartość, to czy źródło jest ludzkie.
Alex: Dokładnie.
Rozpisanie procesu krok po kroku
Alex: Zbudowałem tę maszynę tak, że dosłownie narysowałem na kartce każdy pojedynczy krok procesu tworzenia treści. Krok pierwszy: muszę wymyślić pomysł. Krok drugi: wymyśliłem pomysł. Krok trzeci: badam pomysł. Krok czwarty: wyrzucam z siebie wszystkie myśli. Krok piąty: zamieniam to w spójny szkic. Krok szósty: redaguję ten szkic. Krok siódmy: jestem wkurzony, uważam, że szkic nie jest tak dobry, jak powinien, więc piszę go od nowa. Krok ósmy: kończę szkic. Krok dziewiąty: publikuję.
Rozpisałem to i powiedziałem sobie: przebudujmy ten proces tak, żeby był AI first, i zostawmy człowieka tam, gdzie człowiek jest potrzebny. Moim zdaniem człowiek zawsze musi wybrać pomysł, o którym chce tworzyć treść. I musi dostarczyć własne słowa na temat tego pomysłu.
Gdybym miał zapytać: „David, co sądzisz o Kimi K3?”, to żeby naprawdę powstał z tego dobry materiał, chciałbym przeprowadzić z tobą trzydziestominutowy wywiad po tym, jak zrobisz research nad modelem i nad tym, jakie eleganckie rozwiązania problemów z pamięcią przynosi. Przez trzydzieści minut podajesz mi swoje przemyślenia. Te przemyślenia stają się transkryptem, czyli plikiem markdown, na którym operuje cała maszyna.
Celem maszyny jest dać ci pomysły do wyboru, a potem wziąć twoje słowa i ich nie zmieniać — tylko zadbać, żeby płynęły, żeby przejścia były dobre i żebyś miał redaktora, który sprawdza to, co powiedziałeś, i dodaje kontekst tam, gdzie nie podałeś go w pierwotnych myślach, albo robi inne poprawki.
Jak działa maszyna, krok po kroku
Alex: Proces wygląda tak.
Najpierw wybór twórcy, bo z maszyny korzystają wszyscy nasi pracownicy w 10X. Wybierasz, kim jesteś, co ładuje pliki specyficzne dla ciebie: twój głos i twoje lekcje o treściach.
Potem uruchamia się coś, co nazywamy oracle. Skanuje twoje ostatnie siedem dni na Slacku, w Notionie, Gmailu, Linearze i gicie, i poluje na piki. Pik to pytanie: ile jest tu punktu widzenia, ile potencjału na historię, ile intensywności emocjonalnej, ile lekcji albo frameworka, ile głębi.
Poza wyciąganiem pomysłów ze źródeł wewnętrznych w firmie oracle pobiera też ze źródeł zewnętrznych. Używam do tego /last-30-days, czyli skilla Matta Van Horna. Robi się przemiał społecznościowy po Reddicie, X, YouTubie, Hacker Newsie i tak dalej, wokół tematów, o których chcesz stworzyć pomysł.
To produkuje listę mniej więcej piętnastu pomysłów. Wszystkie trafiają do bazy w Notionie, która tworzy się przy pierwszym uruchomieniu maszyny — nazywa się „skarbiec”. Jeśli wybieram jeden pomysł, pozostałe czternaście niekoniecznie jest złych, po prostu nie chcę ich teraz użyć. Lądują w bazie.
Załóżmy, że wybieram pomysł wokół Kimi K3. Nie jestem głęboko techniczny, ale chcę mieć na ten temat perspektywę. Mogę uruchomić pośredni krok researchu, w którym maszyna analizuje oryginalny artykuł naukowy, a także mówi mi, jakie są bieżące wydarzenia, co już mówi się na rynku, jakie są kontrariańskie ujęcia i jakie są otwarte pytania, na które tylko ja, Alex Lieberman, mogę odpowiedzieć.
Kiedy mam już swoje przemyślenia, przepytuje mnie panel prowadzących wywiad. To prawdopodobnie najważniejszy krok w całej maszynie. Zamiast sytuacji, w której Alex musi przeprowadzić wywiad z Davidem, bo człowiek musi przepytać człowieka, mam sześć person: Tim Ferriss, Joe Rogan, Larry King, Howard Stern, Michael Barbaro i Barbara Walters — każda jako osobny skill. Ich sposób zadawania pytań jest skodyfikowany w sześciu oddzielnych skillach.
(Informacja dodatkowa: to znani amerykańscy prowadzący wywiady i podcasty, każdy o wyrazistym, rozpoznawalnym stylu pytania).
Zadają mi pytania po jednym. Zmuszają mnie do konkretu. Za każdym razem, gdy odpowiadam mgliście, naciskają. Ciągnie się to jakieś dwadzieścia minut. Pytają tekstem w Claude Code, a ja odpowiadam dyktowaniem. To zamienia się w pełny plik markdown z transkryptem, kluczowymi historiami, głównymi wnioskami, które podałem, i cytowalnymi momentami.
Następnie mówię, w jakim formacie ma to być napisane: post na LinkedIn, wątek na X, długi post, playbook, promocja podcastu i tak dalej. Maszyna znajduje odpowiedni skill, czyli moją skodyfikowaną wersję tego, jak pisałem posty na LinkedIn w przeszłości, które z nich radziły sobie najlepiej i jaki miały format. Bierze surowy plik markdown i dopracowuje go pod kątem płynności, nie zmieniając moich słów, do tego formatu.
Potem mam radę pisarzy, a właściwie radę redaktorów. Ta sama idea co panel wywiadu, ale do redakcji: Morgan Housel, Tim Urban, Sean Puri, Greg Isenberg, David Perell i wykrywacz szlamu. Przechodzą przez tekst i oceniają go. Jeśli dostanie poniżej dziewięciu na dziesięć, wchodzi w pętlę poprawek. Jeśli powyżej dziewięciu — gotowe.
Dostaję materiał i mogę go przepuścić przez silnik repurposingu. Powiedzmy, że kończę długi tekst o Kimi K3 — dlaczego jest ważny, co ludzie powinni wiedzieć. Silnik zamienia go w dziesięć pochodnych materiałów, ale każdy przechodzi przez ten sam proces: pobiera skill z moim sposobem tworzenia artykułu na X, moim sposobem pisania na LinkedIn, tworzy tekst i znów puszcza go przez radę redaktorów.
Na końcu jest część dystrybucyjna. Dostaję tag UTM dla każdego materiału, mogę publikować automatycznie z maszyny i monitorować wyniki. Chodzi o to, żeby dzięki monitorowaniu wyników maszyna w przyszłości pisała lepiej — bo wie, co należy do najlepszych publikacji.
Ostatni element: na koniec każdej sesji przekazuję opinię, co maszyna zrobiła dobrze przy tworzeniu materiału, a ona zamienia to w plik lekcji. Za każdym razem, gdy w przyszłości pisze tekst, sprawdza content-lessons.md, żeby nie popełnić tego samego błędu ponownie.
Ile przykładów potrzeba, żeby wytrenować głos
David: Ile przykładów zwykle potrzebujesz — tych ludzkich artykułów, postów na LinkedInie — żeby poczuć, że jest dobrze?
Alex: Nie znam dokładnej odpowiedzi, bo jestem szczególnym przypadkiem: mam mnóstwo wcześniejszych treści. Trzysta pięćdziesiąt odcinków podcastu, jakieś dziesięć tysięcy postów w mediach społecznościowych. Na pewno nie potrzeba aż tyle.
Powiedzmy, że Dan chce postawić maszynę do treści i nigdy nie publikował na X ani LinkedInie. Ma trzy drogi, żeby wytrenować swój głos.
Pierwsza: maszyna przeprowadzi z nim wywiad głosowy, żeby wydobyć jego głos, i zamieni ten wywiad w plik głosu.
Druga: może wrzucić cokolwiek, co pokazuje jego głos — dawne SMS-y, wysłane maile, wiadomości ze Slacka. To zamienia się w plik głosu.
Trzecia, którą ludziom polecam: zacznij po prostu ode mnie jako persony. Dosłownie użyj moich plików głosu, a z czasem, w miarę jak będziesz dawał feedback, to naturalnie przekształci się w to, czym twój głos ma się różnić od mojego. Ale przynajmniej masz głos, z którym czujesz się komfortowo.
Dan, jakie masz doświadczenia z maszyną do treści?
Dan: Świetne. Fajnie jest zacząć od głosu Alexa, bo wytrenował swoją maszynę na ogromnej historii tego, co w mediach społecznościowych działa, a co nie. A potem w całej firmie ludzie po prostu dyktują swoje przemyślenia o najnowszym modelu albo trendzie w inżynierii agentowej i to się tłumaczy na materiał, który wychodzi na zewnątrz. Odkąd Alex wdrożył maszynę wewnętrznie, widzimy ogromny wzrost liczby osób w 10X, które faktycznie publikują. Spodziewam się, że to będzie dalej rosło.
Tarcie i zachęty
Alex: Dwie dodatkowe myśli. Generalnie bardzo trudno jest skłonić do tworzenia treści ludzi, których praca na pełen etat nie polega na tworzeniu treści. Moim zdaniem trzeba zmniejszyć tarcie i dać zachętę. Maszyna do treści była zmniejszaniem tarcia. Możemy zmniejszyć je jeszcze bardziej.
Wyobrażam sobie, że twórcy na pełny etat, których będziemy zatrudniać, częściowo działają jako producenci dla naszego zespołu: nagrywają rozmowy i wrzucają je do maszyny. Albo — za kilka godzin rozmawiamy o kawałku wewnętrznej własności intelektualnej, którą właśnie budujemy w 10X. Jeśli całe to spotkanie zostanie nagrane, możemy podpiąć maszynę pod hook, żeby przy każdej nowej transkrypcji spotkania w Notionie automatycznie tworzyła materiał.
Druga rzecz to zachęta — żeby przejść od zimnego startu, w którym nikt nie tworzy treści, do zbudowania nawyku. Zrobiliśmy konkurs, w którym w ciągu miesiąca rozdaliśmy pięć tysięcy dolarów za tworzenie treści. Rozgrywaliśmy różne gry: nie chodziło tylko o to, czyj materiał zebrał najwięcej wyświetleń, ale też czyj najlepiej wyedukował odbiorców w danym temacie albo czyj najlepiej opowiedział światu historię realnej pracy, którą wykonujemy dla klienta. Trzeba robić jedno i drugie: zachęty i obniżanie tarcia.
David: Jedna praktyczna rzecz, którą robimy: gdy mamy spotkanie na Google Meet, jest tam notatnik, wszystko jest automatycznie zaciągane przez Composio CLI. Te transkrypcje — jeśli już coś omawiacie, czy to bardziej doświadczone osoby w zespole, czy ktoś szkolący nową osobę — to są okazje na treści. Potem możesz kazać modelowi frontierowemu, na przykład Fable, przeanalizować: te rzeczy są prywatne, superprywatne, nigdy ich nie udostępniaj, ale o tych dziesięciu mógłbyś zrobić tweety. To kolejny sposób redukcji tarcia — bo tę rozmowę i tak byś odbył, tylko zwykle nie zdajesz sobie sprawy, że rozmowy wewnętrzne to najlepsze treści.
Tak jak powiedziałeś: jeśli spada model taki jak Kimi K3 — co o nim sądzisz, czy naprawdę będziemy go używać, czy używa go konkurencja? To trochę jak gadanie w szatni, tylko firmowe, gdzie ludzie dzielą się gorącymi opiniami. Ale wyciągnąć telefon i napisać tweeta — to już nie brzmi tak dobrze.
Alex: Dokładnie. Robimy to na razie z tekstem, ale widzimy dużo możliwości w wideo. Jeden z naszych inżynierów w 10X, CJ, jest od dawna fanem treści Theo i chciałby prowadzić własny stream o pięciu największych tematach w AI i inżynierii z własną perspektywą. Problem w tym, że AI nie jest teraz dobre w montażu wideo, więc albo musisz mieć zasoby wewnętrzne, albo wybrać format, w którym w ogóle nie trzeba montować. Ale to będzie kolejny krok: jak budować przepływy pracy pomagające we wszystkich mediach, nie tylko w tekście.
Czy inżynierowie będą jeszcze czytać kod
David: Wspomniałeś Matta Van Horna. Miałeś z nim niezły wywiad i powiedziałeś coś, co jest zresztą świetnym haczykiem: że jeden z najbardziej produktywnych inżynierów, jakich znasz, nie umie czytać kodu. Zauważyłem ten sam wzorzec — ludzie, o których myślałbyś, że będą szaleńczo produktywni z AI, bo mają piętnaście lat doświadczenia w świetnych firmach, byli w rzeczywistości bardzo powolni w adopcji. Opowiedz więcej o tym wzorcu, że ludzie, którzy nie umieją czytać kodu, są zwykle skuteczniejsi z agentami.
Alex: Po pierwsze — czy uważasz, że ludzie powinni jeszcze czytać kod? To była bardzo gorąca teza Matta. Nie jest inżynierem, ale mówił to jako uogólnienie. Chciałbym zrobić kolejny odcinek z debatą, bo wiem, że znajdą się ludzie po drugiej stronie. On twierdził, że już wkrótce nikt, łącznie ze wszystkimi inżynierami, nie będzie czytał ani pisał kodu. Zgadzasz się z nim czy nie?
Dan: Zdecydowanie zgadzam się z tym, że ilość kodu, jaką czytasz, spada w czasie. Ale to, co outsourcujesz, to myślenie i przetwarzanie całego tego kodu — nie da się outsourcować rozumienia. Żeby dobrze ustrukturyzować plany, bazę kodu i wszystko inne, wciąż uważam — i z czasem jestem coraz mocniej przekonany — że ogromne znaczenie ma to, jak głęboko siedzisz w fundamentach inżynierii.
Jeśli weźmiesz inżyniera, który ma naprawdę złe nawyki i przed erą AI nie był fantastycznym programistą, a teraz mocno oprze się na AI, to te złe nawyki zostaną wzmocnione stukrotnie. Natomiast ktoś, kto jest słabszym inżynierem, ale bardziej zorganizowanym, bardziej dbającym o strukturę, potrafiącym lepiej rozłożyć pracę w czasie i po prostu lepiej pracującym z agentami, może osiągnąć lepsze rezultaty niż ta pierwsza osoba ze stukrotnie ujemnym wynikiem. Ale najlepszy scenariusz to ktoś, kto głęboko rozumie cały stos inżynierski i potrafi wycisnąć z AI maksimum.
Setup inżynierii agentowej w 10X
David: Możecie podzielić się swoim setupem inżynierii agentowej?
Dan: Jasne. Tytułem wstępu — mówiliśmy już o meta harnessie i o idei konstruowania pakietu kontekstu jako kodu dla każdego projektu i każdego zlecenia. Najważniejsze jest tu zdefiniowanie wszystkich zestawów artefaktów, które agent będzie pisał albo które będziemy wymieniać między ludźmi a agentami, zdefiniowanie struktury tych rzeczy, a potem możliwość walidowania i łatwego pobierania z nich, tak żeby agent mógł się sam korygować.
David: Czyli główny wzorzec z tego, co mówisz, brzmi tak, że myślenie architekta jest o wiele ważniejsze niż konkretne „zbuduj tę funkcję” albo nauka składni.
Dan: Tak, uważam, że to prawda.
Jesteśmy w przestrzeni roboczej, w której zwykle oddzielamy repozytoria kodu od tego, co nazywamy repozytorium zarządzania projektem — tam znajdują się wszystkie artefakty. Plik, na który teraz patrzymy, to jeden z typów artefaktów: artefakt konwencji, z prefiksem con. Ma metadane na górze, żeby agent mógł sparsować wszystkie te artefakty i je odnaleźć. A dalej jest indeks wszystkich pozostałych konwencji, jakie mamy w repozytorium.
To jest dokładnie ten rodzaj rzeczy, który trzyma agenta na szynach i sprawia, że stosuje wszystkie naprawdę dobre wzorce kodowania. Dlatego uważam za bardzo ważne, żebyś wiedział, co robisz w kwestii inżynierii i dobrych wzorców, kiedy budujesz te pliki konwencji. Ale jeśli zbudujesz je dobrze i masz system walidacji względem konwencji, możesz o wiele mniej martwić się o jakość kodu, bo wiesz, że wszędzie są przestrzegane.
Uruchomię kilka komend, żeby pokazać CLI, którym zarządzamy artefaktami. Jesteśmy w przestrzeni roboczej 10x-process. Wpisuję 10x context i wybieram tryb operatora, czyli dla człowieka — ale zaprojektowaliśmy to CLI tak, żeby było zwrócone i do agenta, i do człowieka. Od razu widać rodzaj informacji, który agent może natychmiast pobrać. Raportuje, jakie artefakty istnieją. Mamy sześć epików — to jeden z naszych typów artefaktów, definiujący, co budujemy i jakie są kamienie milowe. I dwadzieścia specyfikacji, czyli znacznie bardziej szczegółowych dokumentów technicznych o dokładnej architekturze i o tym, ticket po tickecie, jak zbudujemy daną rzecz. Widać też trzydzieści pięć dokumentów, w tym te dokumenty konwencji. Raportuje również, na jakiej wersji CLI jesteśmy.
Mamy też wszystkie te współdzielone skille, którymi dzielimy się w zespole. Pozwalamy ludziom tworzyć własne kanały skilli, a kiedy skill jest wystarczająco dobry albo jest centralny dla procesu, trafia do gałęzi głównej. Po wpisaniu 10x skills status widać, że mamy skille odpowiadające każdemu naszemu artefaktowi. Więc kiedy tworzysz jeden z tych ustrukturyzowanych artefaktów, agent dokładnie zna jego strukturę i wie, jak zbudować go poprawnie.
Jeśli zrobimy 10x context z trybem dla agenta, wypisze o wiele bardziej szczegółowe informacje i wyliczy każdy pojedynczy artefakt. Agent wie więc dokładnie, gdzie znaleźć wszystkie informacje o epikach, architekturze, poszczególnych konwencjach, oraz log wszystkiego, co ostatnio wydarzyło się w repozytorium. Agent zawsze zapisuje do tego loga po wykonaniu jakiejkolwiek istotnej pracy.
I mamy to wszystko podpięte pod hook startowy. Każda sesja agenta, jaką ktokolwiek w 10X uruchamia, dostaje — nazwijmy to życzliwym prompt injection — pakiet kontekstu, który mówi agentowi wszystko o jego przestrzeni roboczej i o każdym artefakcie, do jakiego ma dostęp.
(Informacja dodatkowa: hook startowy w Claude Code to skrypt uruchamiany automatycznie na początku sesji, którego wyjście trafia do kontekstu agenta).
Dlaczego repozytorium kontekstu jest cenniejsze niż kod
David: Mam mnóstwo notatek. Zauważyłem oddzielne repozytoria. Chciałem was zapytać, czy to prawda, że z czasem repozytorium kontekstu staje się cenniejsze niż repozytorium kodu.
Dan: Zdecydowanie tak uważam. Odsetek czasu, który spędzasz na inżynierowaniu markdownu, powinien być wyższy niż odsetek czasu, który spędzasz na faktycznym wykonywaniu kodu. Mogę spędzić cztery godziny, budując naprawdę dobre plany i dokumenty architektoniczne oraz konfigurując całe to repozytorium zarządzania projektem, a potem po prostu powiedzieć /go /10x-process /execute-project-spec, odstawić komputer w kąt, iść spać i obudzić się dokładnie z tym, co zaplanowałem.
Piękne w tym systemie jest to, że wszystkie tickety zostały przesunięte do właściwych kolumn w Linearze, wszystko zostało odpowiednio zapisane z powrotem do repozytorium i masz pełny ślad tego, co agent zrobił. Zdecydowanie uważam więc, że informacja, meta harness i cały markdown są o wiele ważniejsze niż kod.
David: Zgadzasz się, Alex?
Alex: Całkowicie. Patrząc z najwyższego poziomu, jako osoba nietechniczna: wartość polega na tym, że istnieje zestaw norm i zwyczajów, które trzymają agenta na szynach. A cały problem, z którym ludzie się mierzą przy budowie oprogramowania, to pamięć albo kontekst między sesjami. To życzliwe prompt injection, o którym mówi Dan, jest naszym rozwiązaniem, które gwarantuje, że dokładnie właściwa informacja pojawia się dokładnie we właściwym momencie, bez luk, dzięki czemu agenci mogą pracować nad długimi zadaniami.
David: Moje pytanie szło jeszcze głębiej. Wyobraź sobie, że ktoś włamał się do twojego systemu i mógł ukraść tylko jedno repozytorium. Mój kod jest w porządku, ale i tak jest już pisany przez agentów — nie obchodzi mnie to, każdy mógłby go odtworzyć. Ale cała reszta, kluczowe wnioski biznesowe…
Alex: Tak — proces, pomysły, wiedza o klientach, strategie marketingowe.
David: …to są rzeczy, które wciąż cenię, bo są ludzkie.
Alex: Ogólnie — Dan, ciekaw jestem twojego zdania — pomyśl o tym jak o zwykłych rynkach ekonomicznych, w kategoriach podaży i popytu. Największy popyt będzie tam, gdzie jest najmniejsza podaż. A kodu jest więcej niż kiedykolwiek. Znacznie rzadszy jest unikalny proces, zwyczaje biznesowe albo wewnętrzna wiedza, która generuje alfę. Rzecz jasna więc to będzie w długim terminie cenniejsze.
Dan: Zdecydowanie się zgadzam. Spojrzałbym na to też przez taką soczewkę: gdybyś miał odtworzyć czyjś produkt metodą inżynierii wstecznej, wolałbyś dostać całą jego bazę kodu czy repozytorium zarządzania projektem? Po pierwsze, baza kodu staje się dla agenta naprawdę trudna do strawienia, nawet jeśli jest ostatecznym źródłem prawdy o tym, co dziś istnieje w projekcie. Jest pozbawiona całego znaczenia i struktury — dlaczego ta funkcja istnieje i jak wiąże się ze wszystkim innym, poza bezpośrednimi powiązaniami w kodzie.
Myślę więc, że z repozytorium zarządzania projektem mógłbyś odtworzyć produkt, a nawet zbudować lepszy, bo zawiera całą intencję, konwencje, architekturę i sposób, w jaki prowadzisz system. To kompletne wywrócenie do góry nogami tego, jak dawniej wyglądała inżynieria.
Walidator — linter dla całego procesu
Alex: Powiem jeszcze jedną rzecz, która może cię zainteresować, David. W miarę jak poznawałem nasz proces, zawsze fascynowało mnie to pytanie: jak uczynić coraz więcej rzeczy poza czystym kodem weryfikowalnymi? Ten cały krok walidatora jest naprawdę ciekawym kawałkiem tej układanki.
Dan: Uruchomię 10x validate i zobaczmy, co dostanę. Od razu znajdujemy ostrzeżenia — przechodzi przez wszystkie artefakty w repozytorium zarządzania projektem. Jest tam bardzo długi zestaw reguł zgodny z naszymi standardami tego, jak lubimy pisać oprogramowanie, i ze wszystkimi krokami procesu od wymagań klienta albo problemu do rozwiązania aż po zmergowany PR czy wypuszczony produkt.
W tym konkretnym przykładzie status checkpointu w specyfikacji projektu jest oznaczony jako „rozjechany”. To znaczy, że status zadeklarowany przez autora — „ukończony” — nie zgadza się ze statusem wyliczonym, czyli „w recenzji”. Status wyliczony jest obliczany na podstawie ustalonych przez nas reguł. W tym przypadku może to znaczyć, że specyfikacja projektu twierdzi, że jest ukończona, ale zawiera tickety, które nie są jeszcze ukończone albo są w recenzji. A nie da się rozstrzygnąć projektu jako ukończonego, jeśli nie wszystkie tickety są ukończone.
Można sobie to ekstrapolować i przemnożyć — mamy setki takich reguł. To coś w rodzaju lintowania twojego SDLC, całego procesu inżynierskiego, a nie tylko lintowania kodu. Wykorzystuje to również pewną własność agentów: agent potrafi korzystać z CLI, więc może stale ustalać, co jest najważniejszą rzeczą do zrobienia w następnej kolejności, co się rozjechało i jak to naprawić. Powstaje bardzo przyjemna, samodoskonaląca się pętla.
Agenci, którzy rozliczają ludzi
David: Uważam, że jest ogromna alfa w tym, żeby agenci rozliczali ludzi. Jeśli mówisz: to są długoterminowe priorytety firmy, to są największe projekty na ten tydzień — a potem ktoś rozprasza się jakimś fajnym pomysłem z Twittera, agent może powiedzieć: „słuchaj, tego nie ma w mapie drogowej, to nie jest w pierwszej piątce priorytetów, dlaczego nad tym pracujesz?”.
Ludzie muszą znacznie swobodniej oddawać agentom rzeczy, w których agenci są świetni. Bo z każdą generacją modeli agenci są lepsi od ludzi w coraz większej liczbie rzeczy. Wszyscy już rozumieją trawienie dużej ilości treści — możesz wziąć całą książkę, dziesięć książek, i przeczytać je natychmiast. Ale konsekwencja, przewidywalność — w tym ludzie są naprawdę słabi. Ludzie są dość losowi. Są kreatywni, lubią przeskakiwać z zadania na zadanie. Agenci będą, jak sądzę, coraz częściej używani do tego, żeby nas rozliczać.
U mnie mam wiele skilli w stylu: zbuduj samodzielnie tyle, ile się da, a gdy coś cię zablokuje po mojej stronie, poprowadź mnie krok po kroku. Dosłownie wysyłam agentowi zrzuty ekranu, a on pomaga mi ustawić coś w Supabase — normalnie zajęłoby mi to znacznie dłużej, agent napisałby kawałek kodu, potem zablokowałbym go ja. Powiedz więcej o budowaniu nie tylko dla ludzi, ale i dla agentów, bo wspomniałeś o tym wcześniej i myślę, że w tę stronę zmierza świat.
Budowanie oprogramowania dla agentów
Dan: Trzeba dziś myśleć naprawdę kreatywnie o tym, jak powinno się pisać oprogramowanie. Wszystko, czego kiedykolwiek nauczyłeś się o budowaniu oprogramowania, jest w pewnym sensie wywrócone do góry nogami.
Często słyszę takie negatywne ujęcie: agent jest ułomny w kodowaniu albo w pracy z bazą kodu, bo każda sesja zaczyna się od zerowej wiedzy o bazie kodu, trzeba budować mu kontekst, więc tylko człowiek może utrzymać spójność między wieloma sesjami. Ale jeśli spojrzeć z perspektywy rzeczy, o których mówiłeś — konsekwencja, struktura — i zapytać, jak wykorzystać wszystkie przewagi agentów i po prostu rozwiązać te braki, wychodzi bardzo ciekawy wynik.
Robimy więc tak, że traktujemy każdą sesję tak, jakby agent miał zaczynać jako starszy inżynier w projekcie. Powinien od razu wiedzieć, co się dzieje.
David: Czyli hook.
Dan: Tak, hook. A potem, jeśli użyjemy skilla 10x-process, agent wie, co robić. Wystarczy, że powiem „nad czym powinienem pracować dalej”, i od razu widać, że uruchamia ten hook z całym kontekstem, który widziałeś wcześniej, a potem używa komend 10x-process i wciąga dokładnie te rzeczy, nad którymi trzeba pracować w następnej kolejności. Może też wciągnąć architekturę.
Bardzo naturalnie rozwiązuje to problem tego, że agent nie wie, co robi, kiedy zaczynasz świeżą sesję. Teraz nie tylko wie, co robi, ale też trzyma się skrajnie konsekwentnego procesu opartego na regułach. Możemy więc podnieść poziom także ludziom pracującym w ten sposób.
David: Otworzyliście coś z tego jako open source?
Dan: To otwarta dyskusja, które części otworzymy, a które nie. Może w najbliższej przyszłości coś takiego zrobimy.
David: Zastanowiłbym się. Nie musicie zaczynać od wszystkiego — kiedy wypuściłem swoje repozytorium ze skillami, szybko stało się moim najpopularniejszym repozytorium na GitHubie, a są dużo popularniejsze repozytoria ze skillami niż moje. To bardzo dobra strategia na rozruch.
Dan: Zdecydowanie.
David: Dzięki za wasz czas. Gdzie ludzie mają szukać?
Alex: Jeśli ktoś chce dowiedzieć się więcej o tym, co robimy w 10X — 10x.co. Rekrutujemy mnóstwo ludzi: dobrych inżynierów, strategów AI, twórców full stack, 10x.co/careers. A jeśli chcesz po prostu śledzić treści, które publikujemy, obserwuj mnie na X, @businessbarista — bo nie tylko tworzę treści, ale też wzmacniam wszystko, co publikują Dan, CJ i inni ludzie w firmie. Zobaczysz u mnie wszystko, w tym to, co nazywamy „WWE dla nerdów”.
David: Świetnie. Wrzucę wszystkie linki pod filmem. Jeszcze raz dzięki za czas i miłego dnia.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Rozdziel repozytorium kodu od repozytorium kontekstu
Na czym polega: 10X trzyma kod osobno, a osobno „repozytorium zarządzania projektem” z artefaktami markdown: epikami, specyfikacjami technicznymi i konwencjami. To repozytorium jest w ich ocenie cenniejsze niż kod, bo zawiera intencję, architekturę i sposób prowadzenia systemu.
Jak stosować: Wydziel katalog albo osobne repozytorium na dokumenty procesu. Nadaj artefaktom typy i prefiksy (np. con- dla konwencji), dodaj metadane na górze pliku, żeby agent mógł je parsować, i utrzymuj indeks.
Na co uważać: Dwa repozytoria to dwa miejsca, które mogą się rozjechać z rzeczywistością. Bez mechanizmu synchronizacji dokumenty kontekstu szybko stają się kłamstwem, na którym agent buduje błędne plany.
2.Przesuń czas z wykonywania kodu na inżynierowanie markdownu
Na czym polega: Dan mówi wprost, że odsetek czasu spędzany na projektowaniu planów i dokumentów architektonicznych powinien być wyższy niż odsetek czasu na wykonanie kodu. Cztery godziny dobrego planu pozwalają odpalić wykonanie i wrócić do gotowego rezultatu.
Jak stosować: Zanim wydasz agentowi polecenie budowy, rozpisz specyfikację ticket po tickecie i zdefiniuj architekturę. Traktuj to jak właściwą pracę inżynierską, a nie jak biurokrację przed pracą.
Na co uważać: To działa tylko wtedy, gdy naprawdę wiesz, co robisz technicznie. Plan napisany przez kogoś bez fundamentów zamienia się w bardzo dobrze udokumentowany zły projekt, wykonany szybko i konsekwentnie.
3.Wstrzykuj kontekst hookiem startowym, nie promptem
Na czym polega: Każda sesja agenta w 10X zaczyna się od hooka, który dostarcza pakiet kontekstu o przestrzeni roboczej i dostępnych artefaktach — „życzliwy prompt injection”. Agent startuje jak starszy inżynier znający projekt, a nie od zera.
Jak stosować: Zamiast liczyć, że ktoś wklei kontekst, podepnij skrypt startowy zwracający stan projektu: jakie artefakty istnieją, gdzie ich szukać, co ostatnio się wydarzyło. Zadbaj, żeby agent zapisywał do loga po każdej istotnej pracy.
Na co uważać: Pakiet kontekstu zjada okno kontekstowe na starcie każdej sesji. Trzymaj go jako indeks i wskaźniki, nie jako pełną treść dokumentów.
4.Zbuduj CLI zwrócone jednocześnie do człowieka i do agenta
Na czym polega: 10x context ma tryb operatora dla człowieka i osobny, znacznie bardziej szczegółowy tryb dla agenta. Ten sam interfejs obsługuje obie strony, a agent może z niego korzystać samodzielnie.
Jak stosować: Kiedy budujesz narzędzie procesowe, od razu przewidź drugi tryb wyjścia — gęstszy, ustrukturyzowany, z pełnymi ścieżkami. Agent, który może odpytać system, nie musi zgadywać.
Na co uważać: Rozbudowane CLI to kolejny kawałek kodu do utrzymania. Jeśli zespół jest mały, zacznij od kilku komend, których faktycznie używasz codziennie.
5.Walidator procesu, czyli linter dla całego SDLC
Na czym polega: 10x validate przechodzi przez artefakty i porównuje status zadeklarowany przez autora ze statusem wyliczonym z reguł. Rozjazd — na przykład „ukończone” przy nieukończonych ticketach — jest raportowany jako ostrzeżenie. Reguł są setki.
Jak stosować: Zacznij od kilku reguł spójności, które da się wyliczyć mechanicznie z twoich dokumentów, i uruchamiaj je w pętli razem z agentem. Agent może sam pytać walidator, co się rozjechało, i to naprawiać.
Na co uważać: Setki reguł to setki możliwych fałszywych alarmów. Jeśli walidator hałasuje, ludzie i agenci nauczą się ignorować jego wyjście — dokładnie jak przy zbyt gadatliwym linterze.
6.Rozróżniaj AI single player i multiplayer
Na czym polega: Single player to dostarczenie ludziom modelu do indywidualnej pracy — wartościowe, ale bez efektu kumulacji. Multiplayer to przeprojektowanie horyzontalnego procesu, które tworzy dźwignię dla całej funkcji albo firmy.
Jak stosować: Zacznij od single playera — to właściwy pierwszy krok dla większości organizacji. Ale planując inwestycje, szukaj procesów horyzontalnych, gdzie jedno usprawnienie mnoży się przez liczbę osób.
Na co uważać: Alex ostrzega, że większość problemów „AI” okazuje się w praktyce problemami z danymi. Zanim obiecasz agenta multiplayer, sprawdź, czy dane w ogóle są gotowe.
7.Człowiek na pierwszej i ostatniej mili
Na czym polega: Gwarancją, że treść nie będzie AI-owym szlamem, nie jest polowanie na charakterystyczne zwroty modeli — te zmieniają się z każdą generacją. Gwarancją jest to, że człowiek dostarcza źródło (pomysł i własne słowa) oraz zamyka rzecz na końcu.
Jak stosować: Rozpisz swój proces krok po kroku na kartce, a potem zaznacz, w których krokach człowiek jest niezastąpiony. Resztę oddaj AI. Zasada dotyczy nie tylko treści — Alex mówi to samo o budowaniu oprogramowania.
Na co uważać: „Człowiek na pierwszej mili” musi znaczyć realny wkład, a nie zatwierdzenie tematu jednym kliknięciem. Jeśli materiał źródłowy jest pusty, żadna warstwa redakcyjna tego nie uratuje.
8.Panel prowadzących wywiad jako sposób wydobycia własnych myśli
Na czym polega: Sześć person prowadzących wywiady, skodyfikowanych jako osobne skille, przez dwadzieścia minut zadaje pytania po jednym i naciska przy każdej mglistej odpowiedzi. Odpowiedzi dyktowane głosem stają się plikiem markdown z transkryptem, historiami, wnioskami i cytatami.
Jak stosować: Zamiast prosić model o napisanie tekstu, poproś, żeby cię przepytał. Wymuś jedno pytanie naraz i wyraźnie poinstruuj, żeby dopytywał przy ogólnikach. Dyktowanie jest szybsze niż pisanie i brzmi bardziej jak ty.
Na co uważać: Persony realnych osób to stylistyczne uproszczenie działające wewnętrznie; do materiałów publicznych lepiej opisać styl pytania niż podpierać się cudzym nazwiskiem.
9.Rada redaktorów z progiem i pętlą poprawek
Na czym polega: Po napisaniu materiał ocenia sześć redaktorskich person plus „wykrywacz szlamu”. Poniżej dziewięciu na dziesięć tekst wraca do pętli poprawek, powyżej — jest gotowy. Repurposing przechodzi przez ten sam obieg.
Jak stosować: Ustaw twardy próg jakości i pętlę, zamiast czytać wyjście modelu i machać ręką. Dorzuć plik lekcji — po każdej sesji zapisuj feedback, a każde kolejne pisanie niech go sprawdza.
Na co uważać: Ocena modelu na własnym tekście bywa zawyżona i zbieżna — pętla może kręcić się aż do „dziewiątki”, która nadal jest mierna. Kalibruj próg na materiałach, których jakość znasz.
10.Fosą jest to, czego nie da się skopiować: ludzie, zaufanie i wiedza wewnętrzna
Na czym polega: Kodu jest więcej niż kiedykolwiek, więc jego wartość spada. Rośnie wartość unikalnego procesu, zwyczajów biznesowych i wewnętrznej wiedzy, a także zaufanej dystrybucji. AI działa jak krzywe zwierciadło: wzmacnia ludzi o wysokiej sprawczości i obnaża tych o niskiej.
Jak stosować: Pytaj o priorytety: co byś stracił, gdyby wyciekło jedno repozytorium? Inwestuj w to, co odpowiada na to pytanie — w proces, wiedzę o klientach i we własną dystrybucję, a nie w kod, który każdy może odtworzyć.
Na co uważać: Ta sama logika działa przeciw tobie. Skoro repozytorium kontekstu pozwala odtworzyć produkt lepiej niż baza kodu, to właśnie ono jest teraz najbardziej wrażliwym zasobem — i tak trzeba je zabezpieczać.