O czym jest ten film
- Autor przestał uruchamiać agentów kodujących na MacBooku i przeniósł je na osobny mini-PC z Linuksem stojący u niego w domu.
- Powody: zawieszanie się macOS przy większej liczbie agentów, brak pracy przy słabym Wi-Fi i konieczność trzymania otwartej klapy laptopa.
- Nad wszystkim spina to multiplekser terminala z „przestrzeniami” — po jednej na projekt — do którego wraca się zwykłym SSH, a praca agentów trwa niezależnie od stanu laptopa.
- Na Linuksie działają równolegle różne CLI: Cursor, Codex, Claude Code, Hermes i inne.
- Kluczowa zmiana w procesie pracy: intensywne korzystanie z gitowych worktree — jedna funkcja = jedno drzewo robocze = jeden agent.
- Do podglądu serwera deweloperskiego z innej maszyny autor używa tunelu Cloudflare.
- Zrzuty ekranu robione przez agentów trafiają na Cloudflare R2, żeby dało się je obejrzeć zdalnie.
- Stary MacBook Pro M1 Max został w sieci jako maszyna wyłącznie do Xcode, symulatora i budowania aplikacji na iOS/macOS.
- Główny minus rozwiązania to koszt: komputer, szybki internet, switch, UPS.
- Cel docelowy: własny „prywatny chmurowy” home lab i uruchamianie modeli lokalnie — autor zamawia dwa NVIDIA DGX Spark.
(Informacja dodatkowa: transkrypt filmu powstał automatycznie, więc część nazw własnych jest w nim przekręcona — poniżej przywrócono najbardziej prawdopodobne formy, m.in. Ghostty, Vercel, DGX Spark).
Redakcyjne tłumaczenie
Dlaczego zbudowałem własną chmurę
Zbudowałem sobie własną chmurę. Powiem, dlaczego.
Zmęczyło mnie to, że mój mocno wyposażony MacBook wywracał się za każdym razem, bo macOS fatalnie radzi sobie z zarządzaniem pamięcią przy pracy agentów. Zmęczyło mnie to, że nie mogłem nic zrobić, kiedy Wi-Fi słabło. I wreszcie zmęczyło mnie to — no wiecie, o czym mówię: laptop uchylony, żeby zadanie się nie przerwało.
Moje środowisko do pracy z agentami zmieniło się całkowicie. Pokażę, jak z niego korzystam, jak działa, co się zmieniło w moim workflow i jak planuję uruchamiać modele lokalnie.
Jak to wygląda na ekranie
Na ekranie widać terminal Ghostty. Korzystam z multipleksera terminala — alternatywy dla tmuksa. Bardzo go lubię, po części dlatego, jak wygląda i jak się go używa. Jestem pod tym względem chorągiewką: jeśli coś wygląda lepiej, przesiadam się.
Kilka rzeczy, które chcę pokazać. Mam tu zakładki, które nazywają się „przestrzeniami”, i każda przestrzeń to osobny projekt. Jest zakładka Bezel — to projekt, nad którym pracuję, opowiem o nim za chwilę. Jest zakładka Ruth, jest Pluto V2, jest druga zakładka Bezela — tę akurat mogę zamknąć, bo nic w niej nie chodzi. Jest zakładka „health”, czyli monitoring maszyny, i zakładka „network”, w której konfiguruję sieć w nowym mieszkaniu.
I teraz najlepsze: to wszystko nie działa na moim MacBooku. Wcześniej MacBook był miejscem, w którym robiłem całą robotę. Teraz multiplekser działa na tym Linuksie obok — na mini-PC z 32 GB RAM-u i terabajtem dysku. Mam też Synology NAS, switch i mojego pięknego MacBooka M1 Pro Max. To wszystko razem to moja własna chmura. Zrobię o tym całym zestawie osobny film — na razie wygląda to trochę bałaganiarsko, więc skupmy się na tej jednej maszynie, bo to na niej wszystko chodzi.
Pracuję więc na MacBooku, ale wszystkie agenty działają na maszynie z Linuksem. A na tej maszynie uruchamiam dosłownie każdego agenta, jaki istnieje. Chodzi Cursor, chodzi Codex, chodzi Claude Code — właśnie wyczerpałem limity na Fable. Mam też skonfigurowanego agenta Hermes: wpisuję w terminalu hermes i po kilku sekundach mam go z całym zestawem umiejętności.
Praca, która nie znika po zamknięciu laptopa
I tu jest rzecz, która dla mnie jest najpiękniejsza. Mam agenta, który właśnie coś robi. Załóżmy, że jestem zmęczony i zamykam zakładkę. Czy robota przepadła? Nie. Wystarczy, że wejdę do terminala, zaloguję się przez SSH na maszynę, wpiszę komendę multipleksera — i praca toczy się dalej.
Mam różne zakładki dla różnych projektów i uruchamiam w nich wszystkich agentów. Na początku odpalałem je naprawdę wszystkie równolegle. Do zarządzania pracą równoległą w obrębie jednego projektu intensywnie używam drzew roboczych gita. I najlepsze jest to, że maszyna ledwie się przy tym poci. Gdybym robił to samo na Macu, wszystko zaczęłoby zwalniać, a czasem po prostu by padło. A mam naprawdę mocnego MacBooka Pro.
Dlaczego akurat Linux
Pytanie brzmi: po co mi maszyna z Linuksem? Zalety:
Po pierwsze — lepiej radzi sobie z pamięcią. Nie znam szczegółów technicznych, ale przy pracy z agentami po przekroczeniu pewnej ich liczby wszystko zaczyna siadać. A jeśli trafi się harness z wyciekiem pamięci, to się po prostu wyłącza i koniec.
Po drugie — mogę zamknąć laptopa, a praca leci dalej. Nie muszę zostawiać uchylonej klapy.
Po trzecie — mogę pracować równolegle bez ograniczeń, bo Linux zarządza pamięcią przy pracy agentowej po prostu świetnie.
Po czwarte — mogę pracować skądkolwiek. Mam telefon skonfigurowany z Tailscale. Wczoraj były urodziny mojego brata w restauracji — wysyłałem stamtąd prompty, a robota wykonywała się w domu, na maszynie z Linuksem podpiętej kablem do bardzo szybkiego łącza.
(Informacja dodatkowa: Tailscale tworzy prywatną sieć VPN łączącą urządzenia użytkownika, więc telefon widzi domowy komputer tak, jakby był w tej samej sieci lokalnej).
Są też wady, a największą z nich jest koszt. Trzeba kupić maszynę, zainstalować na niej Linuksa, dokupić trochę sprzętu, zapewnić szybki internet. Mam switch, mam UPS, żeby przy zaniku prądu wszystko dalej działało. To wszystko kosztuje.
Materiał sponsorowany: agenty chmurowe Cursora
Wiem, że to dziwne, ale opowiem wam o swojej rutynie przed snem. Najpierw myję zęby. Potem wypijam szklankę zimnego mleka 2% — jeśli pijecie 3%, jesteście dziwni. Po trzecie: przed pójściem spać odpalam agenty chmurowe Cursora i idę śnić o futbolu. A rano mam gotowe pull requesty.
Mam tu zgłoszenie w Linearze: w naszej nakładce na OpenClaw kontekst wiadomości wycieka z jednego wątku czatu do drugiego. Wiadomości mieszają się między rozmowami — koszmar. W zgłoszeniu jest szczegółowy opis, kroki do odtworzenia i cała reszta. Kiedyś sam bym w to wchodził, czytał kod i próbował naprawić. Już tego nie robię — mamy 2026 rok.
Zgłoszenie było przypisane do mnie; przypisuję je swojemu agentowi chmurowemu Cursora. Klik. W tym samym momencie na platformie tworzy się nowy wątek i agent zaczyna rozbierać problem na części. Po prawej widać pełny komputer, do którego agent ma dostęp — może korzystać z niego jak człowiek, żeby przetestować aplikację, odtworzyć błąd, wdrożyć poprawkę, a nawet nagrać wideo z działającej naprawy.
Raz zbudowałem funkcję i chciałem zobaczyć ją w działaniu. Poprosiłem o to agenta chmurowego — i dostałem nagranie wideo pokazujące, że stworzony przeze mnie proces onboardingu faktycznie działa.
Platforma agentów chmurowych Cursora potrafi pracować dosłownie godzinami. Można ustawić limit trzech, pięciu, dziesięciu godzin albo tryb „mielić, aż będzie zrobione”. Ja, jaki jestem, wybieram to ostatnie. Nad tym problemem agent pracował dwie godziny — i dostałem wideo potwierdzające, że poprawka działa. Ten pull request został scalony.
Dzięki Cursorowi za sponsorowanie filmu. Wracamy do tematu.
Drzewa robocze gita: jedna funkcja, jeden agent
Sporą częścią mojego procesu są teraz drzewa robocze (worktree). Wytłumaczę to na przykładzie mojego projektu Bezel.
Bezel to coś, co nazywam capability plane — warstwą możliwości. Zauważyłem, że przy każdym nowym frameworku agentowym — czy to OpenClaw, Hermes, Eve, Claude Code czy Codex — robię dokładnie tę samą konfigurację od zera. Jest zestaw narzędzi, których zawsze używam, i zestaw dostawców, których zawsze podpinam. Byłoby wygodnie mieć to wszystko pod jednym serwerem MCP: zmieniam agenta, podaję mu ten jeden serwer i agent od razu ma dostęp do wszystkich moich narzędzi. Tym właśnie jest Bezel.
(Informacja dodatkowa: MCP — Model Context Protocol — to standard podłączania zewnętrznych narzędzi i danych do agentów AI).
Żeby podłączyć agenta, kopiuję jeden prompt i wklejam go agentowi — tyle. Zapytałem agenta Codeksa, od kogo był mój ostatni e-mail i co w nim było. Agent wywołał MCP Bezela i odpowiedział: ostatnia wiadomość była od Mickeya, temat „czym jest Bezel”, po czym wyjaśnił, czym Bezel jest. Mogę więc dawać różnym agentom ten sam zestaw narzędzi i podmieniać agenta bez utraty narzędzi.
Mam tysiące konektorów. Daję agentowi własny adres e-mail. Ma nawet własny działający komputer, własny sandbox, własną pamięć — a nawet kartę płatniczą, więc może wydawać pieniądze i kupować rzeczy. Nie mogę się doczekać, aż zobaczycie Pluto V2. Mogę też podpiąć konto bankowe i zająć się zarządzaniem finansami, a nawet skonfigurować iMessage i rozmawiać z dowolnym agentem, który ma podpięty MCP Bezela.
Skoro mam sporo rzeczy do zrobienia równolegle, to teraz jak używam drzew roboczych.
Na GitHubie Bezel ma gałąź main. Za każdym razem, gdy coś trafia na main, uruchamia się wdrożenie: leci trigger do Vercela i do Railwaya. Na Railwayu hostowany jest serwer MCP, na Vercelu — panel. Czyli kiedy ja albo mój agent wypchniemy zmianę na main, GitHub uruchamia oba wdrożenia i pojawia się nowa wersja.
Za każdym razem, kiedy pracuję nad nową funkcją, tworzy się nowe drzewo robocze z main — czyli migawka głównej gałęzi, nazwijmy ją „worktree 1”. Mój agent kodujący pracuje właśnie w tym drzewie roboczym. Nie pracuje na main, nie pracuje na innej gałęzi — pracuje w tym drzewie.
Po co to wszystko? Może znacie taką sytuację: mówicie agentowi „zbuduj funkcję, która robi X, Y i Z”. Agent — bo większość robi to automatycznie — odbija nową gałąź od main, nazywa ją np. new-feature-1 i zaczyna pracować. Ale wy chcecie maksymalnie wykorzystać dopłaty do harnessów i modeli, zanim się skończą, więc chcecie od razu ruszyć z drugą funkcją. Problem w tym, że nie da się być na dwóch gałęziach naraz. Więc jeśli odpalicie drugiego agenta, najprawdopodobniej dopisze on drugą funkcję do gałęzi pierwszej. I macie rozdęty pull request z dwoma zestawami zmian: trudno go przetestować, a agent recenzujący — u mnie to Graphite — po prostu się pogubi. Bałagan.
U mnie każda nowa funkcja to osobne drzewo robocze. Jeśli chcę zrobić drugą funkcję, powstaje „worktree 2” i pracuje w nim kolejny agent. Potem trzy, cztery, pięć — widać, jak daleko to może pójść. Kiedy agent skończy, a pull request zostanie scalony, drzewo robocze jest sprzątane i usuwane.
Mam do tego własną umiejętność (skill). Zrobię osobny film o umiejętnościach, których używam.
Tunel Cloudflare zamiast localhosta
Kolejna duża zmiana, szczególnie odkąd pracuję na zewnętrznej maszynie. Kiedy projekt się zbuduje i uruchamiam pnpm run dev albo bun run dev, dostaję adres lokalny — ale ten localhost działa na tamtej maszynie, nie na tej, przy której siedzę. Jeśli wejdę na localhost u siebie, nic nie zobaczę.
Używam więc tunelu Cloudflare. Konfiguracja jest banalna — dosłownie mówicie agentowi, żeby ją zrobił. Tunel wystawia mój lokalny serwer z tamtej maszyny na zewnątrz, więc mogę go otworzyć na dowolnym urządzeniu, mając link. Po uruchomieniu serwera deweloperskiego dostaję jakiś dziwny adres w domenie tunelu Cloudflare — i dzięki temu, mimo że pracuję na innej maszynie, mam działający serwer dev i widzę zmiany agenta na żywo.
MacBook jako maszyna do iOS
Można zapytać: fajnie, wszystko robisz na Linuksie, ale jedyną przewagą Maca jest to, że da się na nim robić aplikacje na iOS. Aplikacje mobilne, desktopowe, symulator. Jak to zrobić na Linuksie?
Chwila — po to jest ten stary, ale wciąż bardzo sprawny MacBook Pro M1 Max. Ma własne połączenie ethernetowe do switcha i cały czas jest podłączony do zasilania. Skonfigurowałem to tak, że kiedy buduję cokolwiek mobilnego albo potrzebuję Xcode czy czegokolwiek z ekosystemu iOS, robi się to na MacBooku Pro. Mam więc moc i wygodę Linuksa, a jednocześnie ekosystem Apple’a — bo do aplikacji na iOS czy macOS potrzebny jest symulator i Xcode.
Zrzuty ekranu przez Cloudflare R2
Kolejna rzecz: każę agentom korzystać z komputera (computer use), żeby sprawdzały, czy aplikacja faktycznie działa, i wysyłały mi zrzuty ekranu. Ktoś zapyta: przecież zrzuty są plikami na tamtej maszynie, jak je zobaczyć? Do tego używam Cloudflare R2.
Przykład: otwieram agenta Hermes i mówię — zrób zrzut ekranu pulpitu, samego ekranu, i wyślij mi ten obraz, wrzuć go na Cloudflare R2, żebym mógł go obejrzeć.
Ciekawostka, kiedy to się wykonuje: Codex CLI też daje dostęp do sterowania komputerem, więc można używać komputera z poziomu Codex CLI. Jest też aplikacja desktopowa Codeksa. A w ostateczności zawsze mogę połączyć się z maszyną z Linuksem zdalnie i użyć jej interfejsu graficznego.
I proszę — agent pisze „gotowe”: zrobił zrzut pulpitu i wgrał plik PNG. Kopiuję link, wklejam — i to jest zrzut mojego pulpitu.
Podsumowanie i co dalej
Mam więc agentów kodujących do roboty. Używam wszystkich CLI — Cursora, Codeksa, Claude’a — wszystkiego naraz. Hermesa używam do różnych rzeczy na maszynie z Linuksem, choćby do konfiguracji sieci. Nigdy nie miałem problemu z pamięcią, nawet przy wielu agentach równolegle, i to takich, które uruchamiają własne podagenty — maszyna pozostaje spokojna i chłodna. A jeśli potrzebuję robić coś pod iOS, używam MacBooka podpiętego do sieci. Dostęp do niego to zwykłe SSH — właśnie jestem na nim zalogowany, więc jeśli chcę tu odpalić Codeksa, po prostu to robię.
Inteligencja modeli AI doszła do punktu, w którym da się budować naprawdę świetne rzeczy. To, co kuleje i gdzie widać pole do dużych ulepszeń, to środowisko: harnessy, których używamy, i wszystko wokół modelu. Kupno tej maszyny całkowicie zmieniło sposób, w jaki pracuję, i tempo, w jakim dowożę.
I ostatnia rzecz. Zbudowałem to wszystko nie po to, żeby po prostu uruchamiać agentów na Linuksie. Buduję sieć i home lab, żeby przygotować się do uruchamiania modeli lokalnie. Zamawiam wkrótce dwa DGX Spark. Chcę zobaczyć, jak daleko da się zajść z modelami lokalnymi na własnych maszynach, przy bardzo szybkim internecie i z UPS-em, żeby zanik prądu niczego nie przerwał. Czy naprawdę mogę być własną chmurą? To pytanie, na które chcę odpowiedzieć. To problem, który chcę rozwiązać.
(Informacja dodatkowa: NVIDIA DGX Spark to kompaktowy komputer przeznaczony do lokalnego uruchamiania i dostrajania dużych modeli AI).
10 najważniejszych takeaways — z kontekstem zastosowania
1.Przenieś agenty z laptopa na osobną maszynę z Linuksem
Na czym polega: Agenty kodujące działają na stałe podłączonym mini-PC z Linuksem (32 GB RAM, 1 TB dysku), a laptop służy tylko jako terminal. Autor twierdzi, że przy wielu agentach macOS zaczyna się dławić i potrafi paść, a Linux zostaje „chłodny i spokojny”.
Jak stosować: Zacznij od najtańszego mini-PC z dużą ilością RAM-u, zainstaluj Linuksa, podłącz kablem ethernetowym i przenieś na niego CLI agentów. Laptop zostaw do przeglądarki, edytora i pracy wymagającej GUI.
Na co uważać: To argument z doświadczenia jednej osoby, nie z pomiarów — autor sam mówi, że nie zna szczegółów technicznych. Koszt to nie tylko komputer, ale też szybkie łącze, switch i UPS. Zanim kupisz sprzęt, sprawdź, czy twoje zawieszki nie wynikają po prostu ze zbyt wielu procesów naraz.
2.Multiplekser terminala z jedną przestrzenią na projekt
Na czym polega: Na maszynie zdalnej działa multiplekser terminala (tmux lub alternatywa), a każdy projekt ma własną „przestrzeń” z zakładkami. Do tego osobne zakładki na monitoring maszyny i konfigurację sieci.
Jak stosować: Ustal jedną przestrzeń = jeden projekt i trzymaj się tego. Dodaj stałe zakładki systemowe (zdrowie maszyny, sieć), żeby nie mieszać ich z pracą projektową.
Na co uważać: Duża liczba przestrzeni sama staje się bałaganem — autor w trakcie nagrania zamyka zakładkę, która „nic nie robi”. Zamykaj puste sesje, bo inaczej po tygodniu nie odróżnisz działającego agenta od zapomnianego.
3.Sesja przeżywa zamknięcie laptopa
Na czym polega: Ponieważ agenty działają w sesji multipleksera na zdalnej maszynie, zamknięcie zakładki czy klapy laptopa niczego nie przerywa. Powrót to SSH i jedna komenda.
Jak stosować: Odpalaj długie zadania (wielogodzinne refaktory, testy, migracje) wewnątrz sesji multipleksera, nigdy bezpośrednio w oknie terminala lokalnego. Wtedy możesz spokojnie wstać od komputera.
Na co uważać: Odporność na rozłączenie działa tylko wtedy, gdy proces naprawdę startuje wewnątrz sesji. Odpalenie komendy przed dołączeniem do sesji cofa cały zysk. Zadbaj też o UPS albo o to, żeby zdalna maszyna nie usypiała.
4.Praca zdalna z telefonu przez prywatną sieć VPN
Na czym polega: Telefon podpięty do Tailscale widzi domową maszynę, więc autor wysyłał prompty z restauracji, a praca wykonywała się w domu.
Jak stosować: Zainstaluj Tailscale na zdalnej maszynie i telefonie, dodaj klienta SSH na telefonie. To wystarcza do rzucania krótkich poleceń i sprawdzania postępów.
Na co uważać: Otwierasz sobie zdalny dostęp do maszyny, która ma dostęp do repozytoriów, kluczy i konektorów — trzymaj klucze i uwierzytelnianie wieloskładnikowe w porządku. Wysyłanie promptów z telefonu bez możliwości porządnej weryfikacji kodu łatwo prowadzi do zmian, których nikt nie przejrzał.
5.Jedna funkcja = jedno drzewo robocze gita
Na czym polega: Zamiast pozwalać agentom odbijać kolejne gałęzie od main, autor tworzy dla każdej funkcji osobne drzewo robocze i sadza w nim jednego agenta. Po scaleniu pull requesta drzewo jest usuwane.
Jak stosować: Przy równoległej pracy dwóch lub więcej agentów w jednym repozytorium daj każdemu własny katalog roboczy (git worktree add). Ustal regułę porządkową: scalone = skasowane drzewo.
Na co uważać: Problem, który to rozwiązuje, jest realny — bez tego drugi agent dopisuje swoją funkcję do gałęzi pierwszej i powstaje rozdęty pull request, którego nie da się sensownie przetestować ani zrecenzować. Uważaj natomiast na drzewa dzielące zależności i pliki konfiguracyjne (node_modules, .env, porty serwerów dev) — te trzeba rozdzielić ręcznie.
6.Jeden serwer MCP zamiast konfigurowania każdego agenta od nowa
Na czym polega: Projekt Bezel to „warstwa możliwości” — zestaw narzędzi i dostawców wystawiony pod jednym serwerem MCP. Zmieniając agenta, podłączasz ten sam serwer i masz komplet narzędzi.
Jak stosować: Jeśli używasz kilku frameworków agentowych, wyciągnij powtarzalną konfigurację (poczta, konektory, pamięć, sandbox) do jednego serwera MCP i podłączaj go do kolejnych agentów jednym promptem.
Na co uważać: To jednocześnie centralny punkt awarii i bardzo szeroki dostęp. Autor wspomina o dawaniu agentowi własnej karty płatniczej i konta bankowego — to skrajnie ryzykowne; jeśli w ogóle, to na osobnym koncie z twardym limitem i wyłącznie na własną odpowiedzialność.
7.Tunel Cloudflare do podglądu serwera deweloperskiego
Na czym polega: Serwer dev działa na zdalnej maszynie, więc lokalny localhost nic nie pokaże. Tunel Cloudflare wystawia go pod publicznym adresem, który można otworzyć z dowolnego urządzenia.
Jak stosować: Po pnpm run dev na zdalnej maszynie uruchom tunel i pracuj na wygenerowanym adresie — zobaczysz zmiany agenta na żywo, także z telefonu.
Na co uważać: Adres tunelu jest publiczny. Nie wystawiaj przez niego środowisk z prawdziwymi danymi ani sekretami i zamykaj tunel po skończonej pracy. Alternatywą bez wystawiania na zewnątrz jest przekierowanie portu przez SSH.
8.Zrzuty ekranu agenta wrzucane do magazynu obiektowego
Na czym polega: Agent korzysta z komputera, robi zrzut ekranu na zdalnej maszynie i wgrywa go na Cloudflare R2, skąd autor otwiera go linkiem.
Jak stosować: Poproś agenta, żeby po każdej większej zmianie zrobił zrzut działającej aplikacji i wrzucił go do bucketa. Dostajesz wizualne potwierdzenie zamiast samych zapewnień w tekście.
Na co uważać: Zrzuty pulpitu potrafią zawierać maile, tokeny i klucze widoczne w innych oknach. Trzymaj bucket jako prywatny z linkami czasowymi i pamiętaj, że raz upublicznionego zrzutu nie da się cofnąć.
9.Zostaw Maca w sieci jako maszynę do iOS
Na czym polega: Starszy MacBook Pro M1 Max jest podłączony ethernetem i stale ładowany. Ilekroć potrzebny jest Xcode, symulator albo cokolwiek z ekosystemu Apple, praca leci na niego przez SSH.
Jak stosować: Nie sprzedawaj starego Maca przy przesiadce na Linuksa — zrób z niego dedykowany węzeł do budowania aplikacji na iOS i macOS. Dostęp: zwykłe SSH z maszyny głównej.
Na co uważać: Symulator iOS i część narzędzi Xcode wymagają sesji graficznej, więc czysty SSH nie zawsze wystarczy; przygotuj też zdalny dostęp do pulpitu. Mac musi mieć wyłączone usypianie, inaczej zdalne buildy będą się przerywać.
10.Wąskim gardłem jest dziś środowisko, nie model
Na czym polega: Autor twierdzi, że inteligencja modeli już wystarcza do budowania poważnych rzeczy, a kuleje wszystko wokół: harnessy, sprzęt, sieć, przepływ pracy. Docelowo chce iść dalej — dwa DGX Spark i modele uruchamiane lokalnie, żeby sprawdzić, czy da się być „własną chmurą”.
Jak stosować: Zanim zaczniesz szukać lepszego modelu, popraw środowisko: stabilna maszyna, sesje odporne na rozłączenie, rozdzielone drzewa robocze, podgląd serwera dev, automatyczne dowody z testów. To zwykle daje szybszy zwrot niż przesiadka na kolejny model.
Na co uważać: To teza autora, nie zmierzony wynik — dla wielu zadań jakość modelu wciąż decyduje o rezultacie. Plan z modelami lokalnymi jest na razie zapowiedzią; sprzęt tej klasy to znaczny wydatek, a modele lokalne zwykle ustępują najlepszym modelom chmurowym w zadaniach kodujących.