Każdy nowy projekt szepcze tę samą pokusę: otwórz edytor, wybierz framework i zacznij pisać. W przypadku MaxOS, twórca

Każdy nowy projekt szepcze tę samą pokusę: otwórz edytor, wybierz framework i zacznij pisać. W przypadku MaxOS twórca Max Paardekam odczuwał to przyciąganie wyjątkowo silnie. Kilka tygodni temu projekt istniał jedynie jako rozproszone pomysły w jego notatkach. Jego pierwszym instynktem było spędzanie godzin za godzinami na pisaniu w TypeScript wewnątrz Cursor, pozwalając pamięci mięśniowej i autouzupełnianiu budować impet. Opierał się temu. Zamiast kodu aplikacji, stworzył coś rzadszego i bardziej kruchego: gotową architekturę.

Ta decyzja początkowo wydawała się stagnacją. Gdy narzędzia są gotowe, a boilerplate instaluje się w kilka sekund, przerwa na rysowanie prostokątów i strzałek może wydawać się absurdalna. Ale MaxOS nie zapowiada się na kolejny prosty wrapper Electron wokół widoku webowego. Celem jest zbudowanie czegoś, co przetrwa lata użytkowania, refaktoryzacji i rozbudowy. Systemy o takim cyklu życia wymagają czegoś głębszego niż szybki start. Potrzebują spójnego myślenia jeszcze przed pierwszym poleceniem import.

Dlaczego IDE może poczekać

Nowoczesne środowiska programistyczne zacierają granicę między planowaniem a egzekucją. Cursor i podobne edytory wspomagane przez AI umożliwiają generowanie całych komponentów na podstawie komentarza. Pętla zwrotna jest natychmiastowa, a zastrzyk dopaminy płynący z obserwowania materializującego się interfejsu użytkownika jest trudny do przebicia. Paardekam zaczął właśnie od tego założenia: że większość jego początkowej energii trafi bezpośrednio do plików TypeScript. Jednak stopniowo przekierował te dni na czystą pracę projektową.

To trudny zwrot dla każdego samodzielnego twórcy. Gdy jesteś całym swoim zespołem inżynieryjnym, każda godzina spędzona w narzędziu do diagramów lub dokumencie tekstowym wydaje się godziną skradzioną z procesu dostarczania produktu. Jednak wczesny kod to często obciążenie przebrane za postęp. Nowość działającego prototypu szybko mija, gdy każda nowa funkcja wymaga omijania założeń przyjętych już podczas pierwszego popołudnia. Wymuszając na sobie odejście od edytora, Paardekam kupił jedyny zasób, który z czasem przynosi coraz większe korzyści: klarowność.

Myślenie systemami, a nie funkcjami

Najważniejsza zmiana w ciągu tych tygodni nie miała charakteru technicznego. Była poznawcza. Architektura oprogramowania, gdy traktuje się ją poważnie, zmienia sposób zadawania pytań. Paardekam przestał podchodzić do projektu z nastawieniem na funkcje. Nie pytał już, jak dołożyć konkretną funkcjonalność. Zamiast tego zmierzył się z trudniejszym pytaniem: jaka struktura bazowa sprawi, że dodawanie każdej przyszłej możliwości będzie łatwiejsze?

To rozróżnienie ma znaczenie. Nastawienie na funkcje traktuje oprogramowanie jak listę zadań. Implementujesz wyszukiwarkę, potem powiadomienia, potem przycisk eksportu. Myślenie systemowe pyta, jak wyszukiwarka, powiadomienia i eksport mogą współdzielić ten sam model danych, tę samą szynę zdarzeń i tę samą warstwę uprawnień. Oznacza to projektowanie gramatyki aplikacji przed pisaniem jej zdań. Koszt początkowy jest wyższy. Nagrodą jest to, że przyszła praca przestaje przypominać montaż, a zaczyna przypominać kompozycję.

Jest to szczególnie krytyczne dla projektu takiego jak MaxOS, który ma na celu zintegrowanie funkcji, które normalnie znajdują się w dziesięciu różnych aplikacjach. Ścisła integracja bez myślenia systemowego staje się koszmarem kruchych mostów i niespójnych stanów. Dzięki niemu przestrzeń robocza zachowuje się jak pojedynczy organizm, a nie federacja łatań i narzędzi.

Przestrzeń robocza, a nie system operacyjny

Paardekam jasno określił granice swoich ambicji. MaxOS nie zastąpi Windowsa ani macOS. Nie aspiruje do zarządzania sterownikami, alokacją pamięci czy warstwami abstrakcji sprzętowej. Celem jest coś bardziej intymnego: przestrzeń robocza.

Większość pracowników umysłowych żyje w pofragmentowanym środowisku. Przeskakujesz z klienta poczty do kalendarza, z aplikacji do notatek do terminala, z narzędzia projektowego do platformy komunikacyjnej. Każde takie przejście wiąże się z tarciem. Kontekst ginie. Uwaga ulega rozproszeniu. System operacyjny zapewnia scenę, ale nie reżyseruje sztuki.

MaxOS zamierza ujednolicić to doświadczenie w jedno środowisko, które rozumie przebieg Twojej pracy i aktywnie pomaga Ci poruszać się szybciej. To inne wyzwanie inżynieryjne niż budowa tradycyjnego systemu operacyjnego. Wymaga głębokiej empatii wobec procesów pracy, bezwzględnego ograniczania zakresu oraz interfejsów, które adaptują się do intencji, zamiast zmuszać użytkownika do adaptacji do narzędzia. Zastąpienie przestrzeni roboczej oznacza zastąpienie nawyków, a nawyki zmieniają się tylko wtedy, gdy alternatywa przynosi ulgę, a nie stanowi kolejnej krzywej uczenia się.

Co zostało zbudowane w te ciche tygodnie

Faza architektury Paardekama zaowocowała dwoma konkretnymi rezultatami. Po pierwsze, jasnym zdefiniowaniem wizji i misji. To nie jest marketingowy bełkot. Dla samodzielnego założyciela technicznego pełni ona rolę ostatecznego strażnika zakresu projektu. Kiedy stajesz przed decyzją, czy dodać pasek boczny czatu, czy rynek wtyczek, deklaracja misji albo to zaprasza, albo to odrzuca. Po drugie, ukończył pełny plan projektu (blueprint).

Zobaczenie całego planu przedstawionego od początku do końca zmieniło psychologię projektu. Pomysły w notatnikach wydają się hipotetyczne. Plan (blueprint) wydaje się nieunikniony. Ujawnia luki, gdy ich naprawa jest jeszcze tania. Pokazuje, gdzie kryją się najtrudniejsze ryzyka. Na tym etapie precyzyjny dokument ma naprawdę większe znaczenie niż linie kodu. Kod można refaktoryzować; niejasne założenia krystalizują się w dług techniczny, którego nie rozpuści żadna nocna sesja debugowania.

Od papieru do monorepo

Po zakończeniu architektury rozpoczęła się kolejna faza. Paardekam przechodzi od dokumentów do kodu, zaczynając od inicjalizacji monorepo. Ten proces wiąże się z własnym niepokojem. Plan to obietnica. Baza kodu to dowód. Przyznał, że czuje niepokój tym, czy projekt przetrwa konfrontację z implementacją. Ta szczerość odzwierciedla zdrowy szacunek do niewiadomych, które pojawiają się dopiero wtedy, gdy teoria spotyka się z wersjami bibliotek, przypadkami brzegowymi (edge cases) i realiami zachowań międzyplatformowych.

Inicjalizacja monorepo to coś więcej niż ceremonialne git init. Ustala ona strukturę fizyczną, która będzie odzwierciedlać architekturę logiczną. To, gdzie znajdują się pakiety, jak zależą od siebie nawzajem i gdzie przebiegają granice między warstwami, będzie echem tygodni planowania. Jeśli zostanie to zrobione dobrze, pierwsza struktura folderów i potok budowania (build pipeline) będą prowadzić przyszłe wkład (contributions). Jeśli zostanie to zrobione źle, będą po cichu karać każdego programistę dotykającego projektu przez lata.

Najważniejsza lekcja

Doświadczenie Paardekama stoi w sprzeczności z kultem szybkości (velocity), który dominuje w dużej części współczesnej kultury tworzenia oprogramowania. Istnieje ogromna presja na szybkie wydawanie produktów (shipping), pokazywanie wzrostu i pozwalanie, by kod zastępował rozmowę. Ale niektóre projekty, szczególnie te mające przetrwać lata, wynagradzają cierpliwość. Dyscyplina polegająca na zdefiniowaniu wizji, rozrysowaniu planu i zaprojektowaniu systemu przed zadeklarowaniem zmiennych to stara rada, która nigdy nie przestała być aktualna.

Jeśli masz teraz pomysł i nie możesz się doczekać, by otworzyć edytor, zastanów się, czy kilka dodatkowych dni świadomego projektowania nie zaoszczędzi Ci miesięcy chaotycznego poprawiania pracy. Dopamina płynąca z działającej aplikacji przemija. Jasność dobrej architektury daje efekt procentu składanego. Zacznij od dokładnej wiedzy o tym, co budujesz i dlaczego. Pisanie kodu może poczekać.