I was “just” a CMS developer.
Then came AI

Jestem programistą i robiłem CMS-y.

Poświęciłem im sporą część ostatnich dwudziestu lat. CMS często oznaczał WordPressa, a WordPress oznaczał strony internetowe. To zrozumiałe skojarzenie, ale opowiada tylko o części tej pracy.

Tytuł, zdjęcie i przycisk „Publikuj” mogą być wszystkim, co widać. Za nimi mogą kryć się redakcje, tłumaczenia, uprawnienia, integracje i lata treści, które muszą przetrwać kolejną aktualizację. Najwięcej nauczyłem się właśnie przy rozwiązywaniu tych problemów.

Dziś AI pozwala znacznie większej liczbie osób stworzyć aplikację, system do zarządzania firmą, a nawet własny CMS. To mnie cieszy. I rozpoznaję w tych projektach wiele problemów, nad którymi pracowaliśmy przez lata.

Im łatwiej generować oprogramowanie, tym bardziej przydaje się wiedza o tym, co musi ono potrafić w dłuższej perspektywie. O tym doświadczeniu chcę opowiedzieć.

Oprogramowanie zaczyna się od ludzi, którzy go używają

Ktoś otwierający CMS zwykle chce skończyć pracę: opublikować artykuł, zaktualizować katalog, zorganizować wydarzenie. Nasz model danych musi odpowiadać tej pracy. Pole wymagane może mieć pełny sens w bazie, a jednocześnie być niemożliwe do wypełnienia na etapie szkicu. Prędzej czy później ktoś wpisze „do ustalenia” i ograniczenie pogorszy jakość danych.

To lekcja produktowa, która od razu staje się architekturą: odróżniać szkic od treści gotowej do publikacji, pytać o informacje we właściwym momencie, umożliwiać zrozumienie błędu i wyjście z niego.

W oprogramowaniu biznesowym kupujący i użytkownik to często różne osoby. Pracownik może latami korzystać z niewygodnego interfejsu. W produktach konsumenckich, które łatwiej porzucić, ta sama niewygoda może kosztować klienta. Wiele CMS-ów jest pomiędzy: to narzędzia pracy dla osób o bardzo różnych umiejętnościach, przyzwyczajeniach i cierpliwości. Dobra szkoła łączenia struktury z użytecznością.

W dzisiejszych aplikacjach widać znajomy wzorzec. CRM, system obsługi nieruchomości, panel administracyjny: filtruję informacje, wybieram widok, wykonuję działanie. Zapytanie, widok, akcja. Tabela, kalendarz i kanban mogą być trzema sposobami pracy z tymi samymi danymi.

Ta gramatyka ma też korzenie w bazach danych i systemach biznesowych. CMS-y długo ćwiczyły ją z osobami, które musiały używać jej codziennie, nie znając kluczy obcych. Dziś AI pozwala wygenerować widok dla jednego zadania, choćby na dziesięć minut. Pod spodem znaczenie danych i zasady ich modyfikacji muszą pozostać rozpoznawalne.

Anatomia CMS-a

Weźmy Directusa, bo pracuję z nim i mogę obejrzeć go z bliska. „Baza danych z API i panelem” to opis równie trafny jak nazwanie zwierzęcia czymś ze skórą i narządami. Żeby zrozumieć, co kupujemy, wykorzystujemy ponownie lub zamierzamy odtworzyć z AI, trzeba rozdzielić jego odpowiedzialności.

Zaczynam od zewnątrz. Skórą jest Data Studio: formularze, widoki i pulpity pozwalają korzystać z systemu. Ukrycie pola w formularzu nie chroni go jednak na serwerze. Szkieletem jest model danych: tabele i relacje SQL wraz z metadanymi, którymi Directus opisuje pola, interfejsy i konfigurację. To my ustalamy znaczenie „klienta”, „projektu” i „zatwierdzone”. Potem otwieramy królika.

Kluczowe jest rozróżnienie między tym, co potrafi Directus, a decyzjami należącymi do nas. Dostarcza kolekcje, relacje, uprawnienia, wersje i automatyzacje. Ustalenie, kto zatwierdza wydatek, kiedy szkic nadaje się do publikacji i jak rozpoznać tego samego klienta w dwóch systemach, wymaga modelu naszej pracy. Produkt daje narzędzia do jego wyrażenia; za poprawność modelu odpowiadamy my.

Prześledźmy konkretną zmianę: redaktor zmienia cenę produktu. Data Studio zbiera wartość; API otrzymuje żądanie; usługi wykonują je w kontekście użytkownika i jego uprawnień. Baza egzekwuje własne ograniczenia. Historia zachowuje zmianę, jeśli ją skonfigurowano. Flow może uruchomić aktualizację zewnętrznego katalogu. To różne odpowiedzialności: jeśli ostatnia usługa nie odpowiada, zapisana cena może odbiegać od wyświetlanej gdzie indziej. Potrzebna jest reguła naprawy i sposób zauważenia problemu.

Granice mają znaczenie również przy rozszerzaniu platformy. Dokumentacja usług każe uważać na kontekst autoryzacji, nazywany accountability: jego pominięcie może nadać usłudze uprawnienia administratora.³ A ukrycie pola w Data Studio nie zastępuje polityki dostępu do danych.⁴ Wartość platformy zależy też od poszanowania jej granic.

Poza zwierzęciem pozostają utrzymanie i eksploatacja: baza i magazyn plików, sekrety, sprawdzone kopie zapasowe, monitoring, aktualizacje i zgodność klientów. Część można zlecić usłudze zarządzanej, ale trzeba wiedzieć, kto za nią odpowiada. Migracja schematu czy odtworzenie rewizji rozwiązuje część problemu, nie zastępuje pełnego planu odtwarzania.

Wybór licencji również przypomina o koszcie całości. Directus stosuje dziś MSCL, licencję source-available: kod można przeglądać, a użycie zależy od obowiązujących warunków.⁵ Rozważając alternatywę, trzeba uwzględnić długoterminowy koszt odpowiedzialności, które zamierzamy przejąć.

Użyteczność także poza przeglądarką

Ta sama staranność powinna dotyczyć pracy przez kod, skrypty i automatyzacje. Developer experience, czyli DevEx, to kolejna forma użyteczności: jasna dokumentacja, jawne typy, przewidywalne polecenia, zrozumiałe błędy. Pozwala działać precyzyjnie i powtarzać operacje, wiedząc, czego oczekiwać.

W Directusie przybiera to konkretne formy. SDK JavaScript i TypeScript udostępnia komponowalnego klienta API, uwierzytelniania i funkcji czasu rzeczywistego, z obsługą typów własnego schematu.⁶ CLI do synchronizacji środowisk pozwala eksportować schemat i konfigurację, przeglądać różnice i stosować je w zgodnych instancjach, także w pipeline.⁷ Serwer MCP przez Model Context Protocol udostępnia dane i operacje asystentom AI, respektując uprawnienia tożsamości, z którą się łączą.⁸

To daje konkretną swobodę: korzystać z panelu, napisać integrację, uruchomić polecenie albo pracować z własnym agentem we własnym środowisku. Można wybrać sposób interakcji i spotkać ten sam model danych oraz uprawnienia wymagane przez poszczególne operacje. AI trafia do systemu, który ma już strukturę i zasady.

Dla mnie „ładne i wygodne” obejmuje też oprogramowanie, które człowiek może orkiestrować, również przez swojego agenta. Mogę złożyć przepływ pracy, delegować etapy, sprawdzić wynik i zareagować. Automatyzacja staje się sposobem zwiększania kontroli nad pracą. Dopracowane DevEx umożliwia to już dziś.

„To tylko galeria zdjęć”

Zwykła prośba: główne zdjęcie artykułu ma stać się uporządkowaną galerią. Dodajemy do formularza kilka miniaturek z przeciąganiem. Zapowiada się spokojne popołudnie.

Model zmienia się jednak z jednego odwołania w relację z wieloma obrazami i kolejnością. Istniejące artykuły muszą zachować swoje zdjęcia. API i szablony muszą rozumieć nową strukturę. Uprawnienia powinny pozwalać redaktorom zarządzać także relacją, bez niepożądanego dostępu do plików. Tymczasem redaktorzy nadal pracują.

Możemy działać etapami: dodać relację, zamienić istniejące odwołania w pierwsze zdjęcie każdej galerii, dostosować odczyty i usunąć stare pole. W okresie przejściowym trzeba też obsłużyć nowe zapisy: jeśli ktoś zmieni stare zdjęcie po pierwszej migracji, zmiana musi trafić do galerii. Zgodne wdrożenie uwzględnia również to, co wydarzy się w jego trakcie.

Schemat, dane, pliki i kod muszą współpracować na każdym etapie zmiany. Mogą ewoluować w różnych momentach, jeśli istnieje ścieżka zachowująca zgodność.

Dlatego przenoszenie schematu z developmentu na produkcję i przenoszenie treści to odrębne operacje.⁹ Dlatego powrót do wczorajszego kodu może pozostawić niedziałający system, jeśli po drodze przekształcono dane. I dlatego sama kopia bazy może nie wystarczyć: jeżeli wskazuje usunięte zdjęcia, odzyskaliśmy odwołania do czegoś, co nie istnieje.

Od galerii doszliśmy do odtwarzania po awarii. Trzeba wiedzieć, które pliki zachować, jakie wersje kodu otworzą dane i jak wznowić integracje bez ponawiania wykonanych działań. Wysłany e-mail czy operacja w zewnętrznej usłudze nie cofają się razem z bazą.

Tu wchodzi warsztat zbudowany wokół CMS-a: infrastruktura, pipeline’y CI/CD, obserwowalność, próby odtwarzania. Pozwala wdrażać we właściwej kolejności, odróżnić zły zakres uprawnień od niedziałającej usługi i sprawdzić, ile pracy może przepaść podczas incydentu. Są też ludzie: kto zatwierdza zmianę, kto interweniuje, kto wie, skąd wzięła się ta dziwna reguła.

W welance nasza chmura i procesy wokół niej są częścią tego zbiorowego doświadczenia. Kto zajmował się złożonymi CMS-ami, często wnosi cały sposób pracy, znacznie trudniejszy do zauważenia niż ekran.

AI może też pomagać pisać migracje, testy i procedury odtwarzania. Doświadczenie podpowiada, o które poprosić i czy próby naprawdę dowodzą tego, na czym nam zależy. Prototyp pokazuje, że coś może działać; dalsza praca określa warunki, w których będzie działać nadal.

C oznacza content, czyli treść

Dotąd mówiłem o artykułach i zdjęciach. Treścią może być też wymaganie, nieruchomość, dostępność, decyzja albo relacja projektu z osobą. Ta otwartość zawsze interesowała mnie w CMS-ach.

Odpowiednio elastyczny system może stać się podstawą zarządzania nieruchomościami, CRM-a lub części ERP. Już pozwala opisywać encje, łączyć je, nadawać dostęp i budować interfejsy. Dochodzi wiedza domenowa: rezerwacja musi zapobiegać kolizjom nawet przy dwóch równoczesnych żądaniach; decyzja księgowa niesie ograniczenia, których artykuł nie ma.

CMS interesuje mnie właśnie jako przestrzeń dla tych możliwości. Wiele systemów biznesowych porządkuje informacje i pozwala właściwym osobom na nich działać. Z AI dochodzi nowy uczestnik, zdolny czytać, proponować i wykonywać operacje. Jakość struktury staje się jeszcze ważniejsza.

Gdy pamięć staje się operacyjna

Wspólna pamięć staje się operacyjna, kiedy możemy prześledzić dane do ich źródła, decyzje do ich powodów, a działania do zasad, które na nie pozwalają.

Wiedza jest racjonalna w takim stopniu, w jakim możemy ją odtworzyć i zweryfikować. Zarejestrowana transakcja, szacunek i wniosek modelu muszą pozostać rozróżnialne. Reguły obliczeń i powiązania powinny dać się sprawdzić. Dzięki temu różni ludzie, z różnymi agentami, mogą pracować na tych samych faktach i dyskutować ich interpretacje.

Widzę tu związek z LLM Wiki zaproponowaną przez Andreja Karpathy’ego: model czyta źródła i utrzymuje trwałą wiedzę dzięki syntezom i połączeniom aktualizowanym w czasie.¹¹ W CMS-ie możemy przypisać tę wiedzę do projektów, odpowiedzialności i stanów: które wymaganie zatwierdzono, kto może je zmienić, które zadanie od niego zależy.

Źródłem może być dokument, nagranie lub zdjęcie. Narzędzia interpretujące muszą zachować pochodzenie, aby człowiek mógł sprawdzić i poprawić syntezę. Model może się zmienić; dane, decyzje i relacje powinny móc zostać. W tym sensie system staje się częścią inteligencji firmy.

Przejście do działania wymaga precyzyjnych uprawnień. Odczyt wymagania nie daje automatycznie prawa do zmiany projektu ani wysłania czegoś klientowi. Każdy konektor musi sprawdzić żądaną akcję i użyć odpowiednich danych dostępu do zewnętrznej usługi. MCP daje wspólny sposób łączenia narzędzi; odwzorowanie uprawnień między systemami trzeba zaprojektować. Także synteza poufnych dokumentów musi respektować te granice.¹²

Tę ewolucję mam na myśli, mówiąc o AI Management System, czyli AI MS: systemie biznesowym, w którym ludzie i agenci pracują na tej samej pamięci operacyjnej. Każdy działa po swojemu, a reguły, odpowiedzialności i historia zmian pozostają weryfikowalne. To robocza nazwa kierunku, który wydaje mi się obiecujący.

To CMS może być elementem do usunięcia

Najpoważniejszy zarzut wobec mojej tezy brzmi: AI może zwiększyć znaczenie danych i reguł, a zmniejszyć potrzebę CMS-a, który je łączy. Odpowiedzialności z tablicy anatomicznej można złożyć inaczej. Opisane umiejętności należą do inżynierii oprogramowania. To, że nauczyłem się ich przy CMS-ach, nie dowodzi, że CMS wciąż jest najlepszym wyborem.

Gdy budowanie wyspecjalizowanych narzędzi tanieje, zmienia się korzyść z dostosowania do platformy ogólnego przeznaczenia. Mała aplikacja wokół własnej pracy może być lepsza od CMS-a pełnego rozszerzeń. SDK, CLI i MCP wspierają też tę alternatywę: czynią produkty dostępnymi i komponowalnymi, nie nadając im koniecznie centralnej roli.

Wspólny model też kosztuje. Projekt dla planującego pracę i zlecenie dla wystawiającego fakturę mogą mieć inne granice. Domain-driven design zajmuje się właśnie tą wielością, wyznaczając granice modeli i jawnie opisując relacje.¹³ Wtłoczenie ich w jedną strukturę może stworzyć kruche tłumaczenia, nieaktualne kopie i punkt, przez który przechodzi każda zmiana.

Rozsądna alternatywa pozostawia systemy nadrzędne w ich domenach i łączy je jawnymi kontraktami. Agent koordynuje operacje; usługi egzekwują własne reguły. CMS zostaje tam, gdzie potrzebują go redaktorzy, albo całkiem znika z tego przepływu. Muszę brać to pod uwagę także po to, by w przyszłości nie widzieć przede wszystkim najlepiej znanego mi narzędzia.

Dla mnie CMS zasługuje na to miejsce, gdy wspólne relacje, uprawnienia i procesy redakcyjne stanowią znaczną część pracy. Jeśli wymusza dublowanie reguł niezawodnych gdzie indziej i ciągłe synchronizacje, przewaga może zniknąć. Praktyczny test to wyobrazić sobie jego usunięcie: co musiałbym odbudować, jakie integracje zniknęłyby i o ile trudniej byłoby zrozumieć lub naprawić błąd? Najlepszy wybór zmniejsza całkowitą pracę, zachowując potrzebne gwarancje.

Narzędzia, których chciałbym używać jutro

Ta perspektywa wpływa na mój wybór narzędzi. Interesuje mnie Railway, gdzie usługi i środowiska są widocznymi częściami projektu. Lovable zaczyna od tworzenia aplikacji i oferuje też zarządzany backend z bazą, uwierzytelnianiem i magazynem plików.¹⁴ To różne sposoby udostępnienia systemu, który pod spodem nadal ma zależności.

Wolę platformy, które czynią te zależności zrozumiałymi i pomagają nimi zarządzać. Tworzenie przez rozmowę widzę jako jedną z możliwości szerszej platformy wspierającej oprogramowanie również po pierwszym wdrożeniu.

Chciałbym poprosić „zamień to zdjęcie w galerię” i zobaczyć, które dane się zmienią, co stanie się z istniejącymi, jakie usługi wezmą udział i gdzie potrzebna będzie zgoda. Chcę też wiedzieć, jak się wycofać, gdy coś zawiedzie. Rysowanie komponentów na płótnie to dobry początek; wartość leży w zarządzaniu zmianą, która przez nie przechodzi.

Stąd może narodzić się następny CMS albo może wyrosnąć z narzędzi już używanych. Zależy mi, by człowiek wybierał własny interfejs i agenta, nadal pracując na wspólnej podstawie. Różnicę zrobi prowadzenie zmiany od intencji zamawiającego do konsekwencji dla systemu.

Niech żyje CMS

W świecie CMS-ów też wiele pracy wykonuje się bezrefleksyjnie: zainstalować motyw, dołożyć kolejne wtyczki i oddać projekt, nie zastanawiając się, jak system sobie poradzi. Samo doświadczenie z CMS-ami nie świadczy o staranności ani kompetencji. Łatwy start może zachęcać zarówno do ciekawości, jak i do lenistwa.

Patrząc na to, co dziś budujemy z AI, dostrzegam przede wszystkim coś, co zawsze było oczywiste: dobre oprogramowanie to dobre oprogramowanie. Poznaje się je po tym, jak pomaga użytkownikom i jak radzi sobie z upływem czasu i ze zmianami. Nazwy, skróty i modna w danym momencie technologia same w sobie mówią niewiele.

Osobom budującym dziś własny system biznesowy z AI zostawiłbym cztery pytania, które sam nadal bym sobie zadawał:

• Które reguły muszą pozostać prawdziwe podczas zmian systemu?
• Kto może działać, na jakich danych i z jakimi skutkami?
• Co rzeczywiście próbowaliśmy odtworzyć po błędzie?
• Co będą wiedzieć ci, którzy przyjdą po nas?

To przy CMS-ach nauczyłem się zadawać te pytania. Zabieram tę wiedzę ze sobą, również wtedy, gdy pomaga mi wybrać inną architekturę.

CMS is dead. Long live the CMS.