Projekt jest kodem

Jak logika automatów komórkowych przekształci agentowe systemy projektowe i dlaczego przyszłość tworzenia stron internetowych może być już zapisana w prostych regułach

Na styku systemów projektowych, sztucznej inteligencji i teorii obliczeń dokonuje się głęboka przemiana. Jest tak fundamentalna, że zmusza nas do przemyślenia na nowo, co właściwie znaczy „projektowanie” w epoce autonomicznych agentów.

Przez dziesięciolecia traktowaliśmy projekt i kod jako dwie osobne dziedziny: projekt jako sferę ludzkiej kreatywności i oceny estetycznej, kod jako mechaniczne przełożenie tych pomysłów na postać wykonywalną. Ale gdy agenci AI coraz częściej samodzielnie składają interfejsy użytkownika, korzystają z systemów projektowych jak z infrastruktury czytelnej dla maszyn i generują kod na podstawie tokenów semantycznych, zbliżamy się do punktu zbieżności, który odbija znacznie starszą ideę z teorii obliczeń.

Jaką ideę? Projekt jest kodem.

To nie jest tylko chwytliwe hasło. To uznanie, że zmierzamy ku światu, w którym systemy projektowe działają jak automaty komórkowe: proste reguły dają początek złożonym, emergentnym zachowaniom. Gdzie granica między „projektowaniem” a „programowaniem” znika zupełnie. Gdzie autonomiczni agenci nie tylko korzystają z systemów projektowych, ale są systemami projektowymi w działaniu.

Ten wpis na blogu bada głębokie związki między automatami komórkowymi, zachowaniami emergentnymi i przyszłością agentowych systemów projektowych. Prześledzimy fundamenty teoretyczne od samoreplikujących się maszyn von Neumanna aż po dzisiejsze roje agentów AI.

Przyjrzymy się, jak Drupal i nowoczesne platformy CMS integrują AI za pomocą modułów takich jak Schema.org Blueprints i Drupal AI. I zastanowimy się, co to wszystko oznacza dla projektantów, programistów i przyszłości tworzenia produktów cyfrowych.

Automaty komórkowe i logika emergencji

Piękno prostych reguł

W 1970 roku matematyk John Conway przedstawił Grę w życie, czyli „grę zerowego gracza”, która stała się jednym z najczęściej badanych systemów w teorii obliczeń. Reguły są zdumiewająco proste:

1. Każda żywa komórka z mniej niż dwoma żywymi sąsiadami umiera (niedoludnienie)
2. Każda żywa komórka z dwoma lub trzema żywymi sąsiadami przeżywa
3. Każda żywa komórka z więcej niż trzema żywymi sąsiadami umiera (przeludnienie)
4. Każda martwa komórka z dokładnie trzema żywymi sąsiadami ożywa (rozmnażanie)

Z tych czterech reguł, wyrażonych w garstce warunków binarnych, wyłania się zdumiewający wszechświat złożoności. Szybowce przemierzają nieskończone siatki. Oscylatory pulsują w nieustannym rytmie. Działa wystrzeliwują strumienie wzorów w przestrzeń komórkową. A co najbardziej niezwykłe, udowodniono, że Gra w życie jest zupełna w sensie Turinga: wszystko, co da się obliczyć algorytmicznie, można w zasadzie obliczyć na prostej siatce Conwaya.

Rysunek 1: Działo szybowcowe Gospera w Grze w życie Conwaya. Ten wzór wytwarza nieprzerwany strumień szybowców – pokazuje, jak proste reguły potrafią dać nieskończoną, samopodtrzymującą się złożoność.

Oto pierwsza lekcja automatów komórkowych: złożoność nie jest warunkiem złożonego zachowania. Proste reguły, stosowane konsekwentnie na całym podłożu, mogą wywołać wzory i zachowania, których nikt wprost nie zaprogramował.

Pętle Langtona i samoreplikacja

W 1984 roku Christopher Langton poszedł o krok dalej ze swoimi samoreplikującymi się pętlami – automatem komórkowym, który ukazał prawdziwe zasady sztucznego życia. Gra w życie Conwaya pokazuje emergentną złożoność, natomiast pętle Langtona pokazują emergentną reprodukcję.

Każda pętla składa się z cyklicznej granicy, wewnątrz której znajduje się „genom” zapisany w stanach komórek. Genom ten krąży nieustannie wokół pętli i wypływa wzdłuż ramienia konstrukcyjnego, które w ciągu 151 kroków czasowych buduje pętlę potomną. Gdy jest gotowa, potomek oddziela się od rodzica i obie pętle replikują się dalej.

Rysunek 2: Pętla Langtona w konfiguracji początkowej. Informacja genetyczna krąży w pętli i kieruje budową pętli potomnych za pomocą wysuwającego się ramienia.

„Jeśli samoreprodukująca się maszyna jest możliwa w automacie komórkowym, to samo życie może być osiągalne dla maszyn.”

– Christopher Langton, „Studying Artificial Life with Cellular Automata” (1986)

Wnioski są doniosłe. Pętle Langtona dowodzą, że samoreplikacja nie wymaga złożoności komórek biologicznych ani uniwersalnych zdolności konstrukcyjnych z pierwotnego projektu von Neumanna. Potrzeba do niej tylko:

• zestawu prostych, lokalnych reguł
• mechanizmu kodowania instrukcji
• procesu, w którym te instrukcje są wykonywane

Reguły są organizmem. Projekt jest kodem.

W 1999 roku Hiroki Sayama przedstawił evoloopy – warianty uwzględniające strukturalną rozpuszczalność i interakcje fenotypowe, co umożliwia spontaniczne mutacje i dynamikę ewolucyjną. Pętle te ewoluują dzięki bezpośrednim zderzeniom podczas replikacji, co prowadzi do zmienności genotypów, większej różnorodności morfologicznej i wzrostu złożoności z pokolenia na pokolenie. W odróżnieniu od stałej replikacji Langtona, evoloopy wykazują dziedziczne mutacje bez żadnej ingerencji z zewnątrz.

Reguła 110 i obliczenia uniwersalne

Badania Stephena Wolframa nad elementarnymi automatami komórkowymi doprowadziły do zaskakującego odkrycia: Reguła 110 – jedna z zaledwie 256 możliwych reguł dla najprostszego rodzaju jednowymiarowego automatu komórkowego – jest zdolna do obliczeń uniwersalnych.

Reguła 110 może zostać w pełni określona przez podanie wyniku dla każdej z ośmiu możliwych kombinacji komórki i jej dwóch sąsiadów. A jednak ta banalnie prosta reguła – osiem binarnych decyzji – potrafi symulować uniwersalną maszynę Turinga.

Rysunek 3: Automat komórkowy Reguła 110. Mimo prostej definicji Reguła 110 wykazuje zachowanie klasy 4 – złożone wzory, które nie są ani całkowicie stabilne, ani całkowicie chaotyczne – i udowodniono, że jest zupełna w sensie Turinga.

„Do obliczeń uniwersalnych nie potrzeba niczego, co przypominałoby cały procesor komputera. Wystarczy ta jedna mała reguła.”

– Stephen Wolfram, „A New Kind of Science”

W 2004 roku Matthew Cook opublikował dowód, że Reguła 110 z określonym powtarzalnym wzorem tła jest zupełna w sensie Turinga. Dowód pokazuje, że Reguła 110 potrafi emulować cykliczne systemy znaczników (cyclic tag systems), które z kolei mogą emulować dowolną maszynę Turinga. Spośród 88 możliwych unikalnych elementarnych automatów komórkowych Reguła 110 jest jedyną, dla której zupełność w sensie Turinga została udowodniona bezpośrednio.

Zasada równoważności obliczeniowej, którą zaproponował Wolfram, sugeruje coś jeszcze bardziej radykalnego: systemy przekraczające minimalny próg złożoności są w istocie równoważne pod względem swoich możliwości obliczeniowych. Ludzki mózg, układ pogodowy i Reguła 110 są, w pewnym głębokim sensie, obliczeniowo równoważne.

Metakomórka 0E0P: prawdziwa samoreplikacja

W październiku 2018 roku Adam P. Goucher ukończył budowę metakomórki 0E0P – wzoru w Grze w życie Conwaya zdolnego do prawdziwej samoreplikacji. W przeciwieństwie do wcześniejszych metakomórek, które wymagały istniejących już w pobliżu kopii, metakomórka 0E0P potrafi zbudować własne kopie od zera, łącznie z własną taśmą instrukcji.

To osiągnięcie jest kamieniem milowym w dziedzinie sztucznego życia: system, który potrafi się rozprzestrzeniać w podłożu obliczeniowym, korzystając wyłącznie z reguł lokalnych. 23 listopada 2013 roku Dave Greene zbudował w Grze w życie pierwszy replikator, który tworzy pełną kopię samego siebie, łącznie z taśmą instrukcji – co pokazuje, że nawet prosty, dwustanowy automat Conwaya może podtrzymywać nieograniczoną samoreprodukcję.

Systemy projektowe jako podłoże obliczeniowe

Od Atomic Design do projektowania agentowego

Metodologia Atomic Design Brada Frosta, wprowadzona w 2013 roku, zrewolucjonizowała nasze myślenie o systemach projektowych. Dzieląc interfejsy na atomy (podstawowe elementy, takie jak przyciski i pola wprowadzania), cząsteczki (proste kombinacje), organizmy (złożone sekcje interfejsu), szablony (układy stron) i strony (ostateczne realizacje), Atomic Design dał hierarchiczną strukturę do zarządzania złożonością.

Ale z perspektywy czasu warto zauważyć coś niezwykłego: Atomic Design już ucieleśniał zasady automatów komórkowych, choć nie nazywał ich wprost.

„Kiedy system projektowy jest nudny, uwalnia projektantów i programistów do tworzenia nowych rzeczy i rozwiązywania nowych problemów. System projektowy bierze na siebie ciężar nudy, żeby projektanci i programiści nie musieli."

– Josh Clark, „The Most Exciting Design Systems Are Boring"

W lutym 2023 roku Brad Frost napisał o „Design Systems in the Time of AI":

„AI jest naturalnym odbiorcą systemu projektowego... Faktem jest, że duża część pracy nad komponentami w systemie projektowym jest naprawdę mechaniczna i przewidywalna. Używamy już narzędzi takich jak PlopJS, by wygenerować szkielet komponentu pasujący do kształtu reszty biblioteki. Chętnie przyjmę pomoc AI w tworzeniu wielu typowych, szablonowych elementów."

– Brad Frost

Mechaniczny i przewidywalny charakter systemów projektowych sprawia, że doskonale nadają się one do działania w stylu automatów komórkowych. Gdy reguły są jasne, lokalne i stosowane konsekwentnie, agenci mogą działać autonomicznie – tak jak komórki w Grze w życie Conwaya nie potrzebują centralnego kontrolera, by powstawały szybowce i oscylatory.

Imperatyw czytelności maszynowej

Inicjatywa Storybook MCP (Model Context Protocol) to krytyczny krok ewolucji w tym kierunku. Ogłoszony pod koniec 2025 roku Storybook MCP dostarcza agentom kodującym AI czytelne maszynowo metadane komponentów z istniejących konfiguracji Storybooka.

Kluczowy wniosek jest taki, że agenci nie potrzebują surowego kodu ani dokumentacji wizualnej. Potrzebują:

• Manifestów komponentów: Ustrukturyzowanych metadanych o każdym komponencie – jego właściwościach (props), wariantach, powiązaniach z tokenami projektowymi i przykładach użycia
• Semantycznego nazewnictwa: Tokenów bogatych w intencje, takich jak action.primary.confirm, które przekazują agentom znaczenie, a nie tylko wartości
• Pętli walidacji: Możliwości uruchamiania testów, sprawdzania błędów i samodzielnego ich poprawiania

„Storybook MCP pomaga agentom przestrzegać Twoich wzorców i przechodzić Twoje testy. Daje im dwie rzeczy, których nigdy wcześniej nie mieli: czytelne maszynowo metadane komponentów oraz iteracyjną pętlę do samonaprawiania błędów."

- Zespół Storybooka

Storybook MCP zawiera autonomiczną pętlę korekty. Pozwala agentom uruchamiać testy komponentów (interakcji i dostępności), sprawdzać, co zawodzi, i naprawiać własne błędy. Programista musi wkroczyć dopiero po przejściu testów. Koniec z niańczeniem promptów.

To dokładnie architektura automatu komórkowego zastosowana w projektowaniu: reguły lokalne (specyfikacje komponentów), interakcje z sąsiadami (wzorce kompozycji) i iteracyjne aktualizacje (walidacja i samokorekta).

Mój manifest komponentu jako genom

Porównanie do pętli Langtona staje się jeszcze trafniejsze, gdy przyjrzymy się temu, jak działają manifesty komponentów. W systemie Langtona „genom" zakodowany w krążących komórkach zawiera instrukcje budowy nowej pętli. W systemie projektowym czytelnym maszynowo manifest komponentu zawiera instrukcje składania interfejsów.

Manifest komponentu może określać:

{
  "name": "Button",
  "variants": ["primary", "secondary", "destructive"],
  "sizes": ["sm", "md", "lg"],
  "props": {
    "label": "string",
    "disabled": "boolean",
    "onClick": "function"
  },
  "tokens": {
    "background": "color.action.primary",
    "borderRadius": "radius.md",
    "padding": "space.3"
  },
  "constraints": [
    "Must have accessible contrast ratio",
    "Label required for non-icon buttons",
    "Minimum touch target 44x44px"
  ],
  "examples": [
    { "variant": "primary", "label": "Submit", "size": "md" },
    { "variant": "destructive", "label": "Delete", "size": "sm" }
  ]
}

Ten manifest jest jednocześnie specyfikacją projektową i wykonywalnym kodem — a raczej instrukcjami, z których można wygenerować wykonywalny kod. Agent korzystający z tego manifestu nie musi rozumieć estetyki ani doświadczenia użytkownika w ludzkim sensie. Ma przestrzegać reguł, łączyć elementy zgodnie z ich ograniczeniami i tworzyć poprawne wyniki.

Zgadzam się z Bradem Frostem co do formatu YAML.

Komponenty Drupala korzystają z formatu YAML. Coś w rodzaju

$schema: https://git.drupalcode.org/project/drupal/-/raw/HEAD/core/assets/schemas/v1/metadata.schema.json
name: Button
status: experimental
description: Use Bootstrap custom button styles for actions in forms, dialogs, and more with support for multiple sizes, states, and more.
props:
  type: object
  properties:
    html_tag:
      type: string
      title: The HTML tag to use for the button (button | a). Defaults to `button`.
      default: button
      enum:
        - button
        - a
    url:
      type: string
      title: URL Link
      description: URL link for the button when the HTML tag is an anchor link.
      $ref: "ui-patterns://url"
    color:
      type: string
      title: Color
      description: Bootstrap includes several predefined button styles, each serving its own semantic purpose, with a few extras thrown in for more control.
      default: ''
      enum:
        - ''
        - primary
        - secondary
        - success
        - danger
        - warning
        - info
        - dark
        - light
        - link
    outline:
      type: boolean
      title: Outline
      description: In need of a button, but not the hefty background colors they bring? Replace the default modifier classes with the .btn-outline-* ones to remove all background images and colors on any button.
      default: false
    size:
      type: string
      title: Size
      description: Bootstrap button size
      default: ''
      enum:
        - ''
        - btn-sm
        - btn-lg
    disabled:
      type: boolean
      title: Disabled
      description: Disabled button
      default: false
    button_utility_classes:
      type: array
      title: Utility Classes
      default: []
      items:
        type: 'string'
      description: An array of utility classes that can be used to add extra Bootstrap utility classes or custom classes to this component.
    attributes:
      type: object
      title: Attributes
      description: HTML attributes for the containing element.
      $ref: 'ui-patterns://attributes'
slots:
  content:
    type: string
    title: Content
    description: The content for the button
    minLength: 1
    examples:
      - Press
      - Submit now
      - Save
      - Login
      - Read more

Projekt jest kodem.

• Warianty
• Tokeny
• Właściwości (props)

• Ograniczenia (moglibyśmy dodać je do komponentów)

• Reguły slotów (co można umieścić w innych slotach albo co wolno umieścić w moim slocie)

• Reguły

• Przykłady 

• Animacje  ( dozwolone lub zalecane do użycia )

Potem obserwuj zachowanie i eksperymentuj.

jak w https://storybook.demo.varbase.vardot.com/?path=/story/atoms-button--primary 

Tokeny projektowe jako zmienne środowiskowe

Tokeny projektowe to kolejny kluczowy element układanki. W automatach komórkowych komórki reagują na swoje najbliższe otoczenie — stany sąsiednich komórek. W systemach projektowych komponenty reagują na tokeny projektowe — wartości kontekstowe, które określają ich wygląd i zachowanie.

Nowoczesne architektury tokenów składają się z wielu warstw:

• Tokeny bazowe: Surowe wartości, takie jak color.blue.500: #3B82F6
• Tokeny semantyczne: Odwołania oparte na intencji, takie jak color.action.primary: color.blue.500
• Tokeny komponentów: Zastosowania ograniczone do zakresu, takie jak button.background.primary: color.action.primary

Gdy agent generuje komponent Button, nie musi wiedzieć, że „primary” oznacza niebieski. Wystarczy, że odwoła się do button.background.primary i zaufa, że system tokenów rozwiąże to do właściwej wartości. Środowisko (warstwa tokenów) zawiera informacje, a komponent (komórka) musi tylko na nie zareagować.

Narzędzia takie jak Tokens Studio ewoluowały tak, by traktować tokeny projektowe jako grafy obliczeniowe z resolverami — węzłami, które podejmują semantyczne decyzje, których tokenów bazowych użyć w danym kontekście. Dzięki temu tokeny projektowe przestają być statycznymi wartościami, a stają się dynamicznym systemem opartym na regułach.

Ekosystem Drupala i integracja z AI

Integracja AI z systemami zarządzania treścią to idealne laboratorium do badania zasady „projekt jest kodem”. Systemy CMS, takie jak Drupal, już teraz realizują podstawowe założenia: ustrukturyzowane typy treści, definicje pól, relacje i reguły kompozycji.

Nigdy nie sądziłem, że usłyszymy coś takiego. Dla mnie to było szczytem możliwości.

 Najlepszy komputer, jaki moglibyśmy mieć. Programiści jakby z przyszłości Star Treka, którzy mówią do komputera, by programował za nich.

Doświadczenie agenta (AX) i nowy użytkownik

Projektowanie dla maszyn

Na początku 2025 roku Mathias Biilmann, dyrektor generalny Netlify, przedstawił koncepcję „Agent Experience” (AX) — nowej dyscypliny skupionej na tym, jak agenci AI wchodzą w interakcje z produktami i platformami.

Ta zmiana jest fundamentalna. Przez dziesięciolecia UX (User Experience) optymalizowało pod kątem ludzkiego poznania, percepcji i zachowania. DX (Developer Experience) optymalizowało pod kątem programistów budujących oprogramowanie. AX uznaje, że agenci stają się głównymi użytkownikami systemów cyfrowych — a mają zupełnie inne potrzeby:

• Nie dbają o estetykę wizualną— liczą się tylko ustrukturyzowane dane, które można przetworzyć
• Nie poruszają się po interfejsach— wywołują API i korzystają z manifestów
• Nie czytają dokumentacji jak ludzie— potrzebują kontekstu czytelnego dla maszyn
• Nie wydają subiektywnych sądów— przestrzegają reguł i ograniczeń

„Agenci AI to nie ludzie: nie obchodzi ich rozmiar przycisku, czytelność typografii, piękna paleta kolorów na Twojej stronie ani efektowne animacje w Twojej aplikacji. Czym więc „przejmują się” agenci AI? To pytanie, na które dziś nie ma konkretnej odpowiedzi, ale w nadchodzących latach będzie ono coraz ważniejsze.”

- Badania nad AX

Odpowiedź: jasne reguły, przewidywalne zachowania, dobrze ustrukturyzowane dane i pętle sprzężenia zwrotnego, które pozwalają agentom weryfikować i korygować własne działania.

Wyzwanie podwójnego interfejsu

Projektowanie dla AX oznacza budowanie jednocześnie dwóch interfejsów:

1. Interfejs człowiek–agent: Tu ludzie nadzorują, zatwierdzają, edytują i kierują zachowaniem agentów – to warstwa „centrum dowodzenia”. Pomyśl o panelach i kolejkach zatwierdzeń, a nie o formularzach i przyciskach.
2. Interfejs agent–system: Tu agenci komunikują się z API, bazami danych i narzędziami – to warstwa „operacyjna”. Musi być solidna, dobrze udokumentowana i zoptymalizowana pod kątem wydajności maszyn.

Odzwierciedla to architekturę automatów komórkowych, w których współistnieją dwie odrębne perspektywy:

• Perspektywa lokalna: Każda komórka (agent) kieruje się prostymi regułami opartymi na swoich najbliższych sąsiadach
• Perspektywa globalna: Pojawiają się złożone wzorce, widoczne dopiero w dużej skali

„Projektowanie doświadczenia agenta (AX) powinno zapewniać świetną użyteczność dla agentów i ich samych. Dlatego świetne AX prowadzi do świetnego doświadczenia użytkownika (UX). Jeśli agent AI napotka zepsuty proces, protokół, a nawet niespójne nazewnictwo w różnych systemach, nie jest w stanie wykonać zadania. To złe doświadczenie dla agenta, które z kolei prowadzi do złego doświadczenia klienta lub pracownika.”

- Kat Holmes, Chief Experience Officer, Salesforce

Od UX do AX: ewolucja projektowania cyfrowego

Stygmergia i komunikacja pośrednia

Jedną z najpotężniejszych koncepcji z inteligencji roju jest stygmergia – pośrednia koordynacja poprzez ślady w środowisku. Mrówki nie przekazują sobie bezpośrednio informacji o miejscu znalezienia pożywienia; zostawiają szlaki feromonowe, za którymi podążają inne mrówki. Środowisko staje się medium komunikacji.

W agentowych systemach projektowych stygmergia przybiera formę:

• Wspólnych bibliotek komponentów: Agenci „widzą”, jakie komponenty istnieją i jak były używane
• Tokenów projektowych: Wartości semantyczne, które kodują decyzje projektowe jako fakty środowiskowe
• Dokumentacji wzorców: Przykłady użycia, które służą jako szlaki feromonowe dla przyszłych agentów
• Zestawów testów: Reguły walidacji, które ograniczają przestrzeń poprawnych wyników
• Historii Git: Zapisu dawnych decyzji, do którego agenci mogą się odwoływać

Gdy agent generuje interfejs z użyciem komponentu, zostawia ślady – w bazie kodu, w dokumentacji, we wzorcach, które ustanawia. Kolejni agenci, napotykając podobne zadania, ulegną wpływowi tych śladów, tworząc rodzaj zbiorowej inteligencji, której nie posiada żaden pojedynczy agent.

Wzorce projektowe agentów

Andrew Ng i inni wskazali cztery kluczowe wzorce dla agentowych systemów AI:

1. Refleksja: AI ocenia własne wyniki i iteracyjnie je ulepsza
2. Korzystanie z narzędzi: AI współpracuje z zewnętrznymi narzędziami, API i systemami
3. Planowanie:Sztuczna inteligencja rozbija złożone zadania na podzadania i wykonuje je po kolei
4. Wiele agentów: Kilku wyspecjalizowanych agentów współpracuje przy złożonych zadaniach

Te wzorce odpowiadają wprost pojęciom z automatów komórkowych:

Projekt jest kodem – głębsza lektura

Co naprawdę znaczy „projekt jest kodem”

Mówiąc „projekt jest kodem”, stawiamy jednocześnie kilka tez:

1. Równoważność semantyczna

Decyzje projektowe, odpowiednio zakodowane, stają się wykonywalne. Token projektowy to nie tylko wartość, lecz instrukcja. Specyfikacja komponentu to nie tylko dokumentacja, lecz program. Gdy agenci korzystają z tych artefaktów, projekt wykonują w tym samym stopniu, w jakim go implementują.

2. Zdolność generatywna

Tak jak Reguła 110 potrafi obliczyć wszystko, co daje się obliczyć, tak dostatecznie kompletny system projektowy potrafi wygenerować każdy poprawny interfejs. System zawiera w sobie potencjał wszystkich swoich poprawnych wyrażeń. To, co z niego wyłoni się, zależy wyłącznie od warunków początkowych (wymagań) i reguł (ograniczeń).

3. Złożoność emergentna

Najbardziej wyrafinowane interfejsy nie powstają odgórnie – wyłaniają się ze spójnego stosowania prostych reguł. Dobrze zaprojektowany przycisk, używany konsekwentnie, tworzy spójny język wizualny, choć nikt nie planował tej spójności wprost.

4. Nieredukowalność obliczeniowa

Niektórych skutków projektowania nie da się przewidzieć bez faktycznego uruchomienia systemu. Nie dowiesz się, jak będzie wyglądał interfejs złożony przez agenta, dopóki nie pozwolisz mu go złożyć. To zasada nieredukowalności obliczeniowej Wolframa zastosowana do projektowania.

5. Automodyfikacja

Podobnie jak evoloopy, które mutują podczas replikacji, systemy projektowe gotowe dla agentów mogą ewoluować w trakcie użytkowania. Komponenty wygenerowane przez agentów stają się częścią biblioteki, z której będą korzystać kolejni agenci. System uczy się, dostosowuje i rośnie.

Rozszerzona metafora automatu komórkowego

Poza metaforą: realna konwergencja

Ale to nie tylko metafora. Ta konwergencja jest realna i dzieje się teraz:

• Storybook MCP zamienia biblioteki komponentów w instrukcje czytelne dla maszyn, które agenci wykonują
• Model Context Protocol ujednolica sposób, w jaki agenci uzyskują dostęp do narzędzi i kontekstu, tworząc uniwersalne podłoże dla operacji agentowych
• Architektury wieloagentowe dzielą pracę między wyspecjalizowanych agentów (architekta, programistę, recenzenta), którzy współdziałają według protokołów – jak komórki o zróżnicowanych funkcjach
• Pętle samonaprawczeZezwalają agentom uruchamiać testy, wykrywać błędy i iterować - tymi samymi mechanizmami sprzężenia zwrotnego, dzięki którym automaty komórkowe wykształcają stabilne konfiguracje
• Schema.org Blueprints sprawiają, że struktury treści są czytelne dla maszyn i mają znaczenie semantyczne
• Drupal AI zapewnia infrastrukturę, dzięki której agenci AI mogą samodzielnie tworzyć treści, modyfikować je i zarządzać nimi

Nie traktujemy zasady „projekt jest kodem” jako stanowiska filozoficznego. Budujemy ją jako infrastrukturę techniczną.

Konsekwencje i droga przed nami

Dla projektantów

Rola projektanta zmienia się z „twórcy prostokątów” w „definiującego reguły”. Jak zauważył Brad Frost:

„Projektanci i programiści, którzy postrzegają swoją pracę jako tworzenie prostokątów, mają powody do niepokoju. Ale ci, którzy widzą w niej rozwiązywanie problemów - a prostokąty tworzą i obsługują przy okazji, bo bez tego się nie da - mają mniej powodów do obaw.”

- Brad Frost

W agentowej przyszłości projektanci będą:

• Definiować tokeny semantyczne i relacje między nimi
• Ustalać ograniczenia kompozycji i wzorce
• Tworzyć reguły walidacji, które agenci muszą spełniać
• Pielęgnować i rozwijać reguły, które rządzą emergencją
• Projektować mechanizmy sprzężenia zwrotnego, które umożliwiają samokorektę
• Kształtować „funkcje przystosowania”, które decydują o tym, jakie wyniki są akceptowalne

To projektowanie na wyższym poziomie abstrakcji - projektowanie reguł, które tworzą projekty, a nie samych projektów. Trochę jak ustalanie reguł automatu komórkowego zamiast rysowania każdej komórki z osobna.

Dla programistów

Programiści stają się architektami systemów agentowych. Jak opisuje to Anthropic:

„Obszar tworzenia oprogramowania pokazał ogromny potencjał funkcji opartych na LLM, a ich możliwości rozwinęły się od uzupełniania kodu do samodzielnego rozwiązywania problemów.”

Programiści będą musieli:

• Tworzyć czytelne dla maszyn interfejsy między agentami a systemami
• Projektować pętle sprzężenia zwrotnego i mechanizmy walidacji
• Budować rusztowanie, w obrębie którego pojawia się zachowanie emergentne
• Zachować nadzór człowieka jako ostatecznego arbitra
• Definiować protokoły, za pomocą których agenci się komunikują
• Wdrażać „kod łączący”, który spina różne systemy agentowe

Dla tworzenia stron internetowych i platform CMS

Włączanie AI do platform takich jak Drupal wskazuje przyszłość, w której:

• Modele treści stają się zrozumiałe dla agentów dzięki standardom takim jak Schema.org
• Procesy redakcyjne są wspierane przez agentów dzięki tworzeniu szkiców, moderacji i optymalizacji opartych na AI
• Wyszukiwanie ewoluuje od dopasowywania słów kluczowych do rozumienia semantycznego dzięki osadzeniom (embeddings) i wektorowym bazom danych
• Personalizacja staje się autonomiczna - agenci uczą się preferencji użytkowników i dostosowują treści w czasie rzeczywistym
• Rozwój przyspiesza bo agenci generują komponenty, testy i dokumentację

To, że ekosystem Drupala sięga po AI - przez moduły takie jak Drupal AI, Drupal Canvas, Schema.org Blueprints i integrację z dostawcami AI - pokazuje, że ta przyszłość już powstaje.

Dla organizacji

Przewagę konkurencyjną zdobędą organizacje, których systemy projektowe są najlepiej „gotowe na agentów”. Systemy gotowe na agentów mają:

• Pełne pokrycie stanów i wariantów komponentów
• Semantyczne nazewnictwo, które oddaje intencję
• Dokumentację i kontekst czytelne dla maszyn
• Infrastrukturę walidacji i testowania
• Jasne ograniczenia wyznaczające granice przestrzeni poprawnych wyników
• API zaprojektowane z myślą o korzystaniu przez agentów (AX-first)
• Architektury treści oparte na Schema.org od podstaw

Dla przyszłości produktów cyfrowych

Stan docelowy przypomina cyfrową ekologię: niezliczeni agenci działający według lokalnych reguł i tworzący emergentne interfejsy, których nie zaplanował żaden projektant ani programista, a które mimo to jakoś tworzą spójną całość, bo reguły leżące u ich podstaw są trafne.

To nie brzmi aż tak nieprawdopodobnie, jak się wydaje. Dokładnie tak działają systemy biologiczne, rosną miasta i funkcjonują rynki. Pytanie nie brzmi, czy dojdziemy do tego stanu, lecz jak przejdziemy przez okres przejściowy.

Wniosek: kod żyje

John von Neumann, erudyta, który wynalazł automaty komórkowe, kierował się jednym zasadniczym pytaniem: Jaka jest minimalna złożoność potrzebna do samoreprodukcji? Jego odpowiedź, czyli uniwersalny konstruktor von Neumanna, pokazała, że samoreplikacja nie wymaga biologicznej maszynerii. Wystarczą reguły, które zawierają w sobie zapis własnego zastosowania.

Siedemdziesiąt lat później odkrywamy, że ta sama zasada dotyczy systemów projektowych. Minimum potrzebne do autonomicznego generowania interfejsu to nie sztuczna inteligencja ogólna ani kreatywność na ludzkim poziomie. To kompletny, spójny i czytelny dla maszyn zestaw reguł, który agenci mogą wykonywać.

Gdy pętle Langtona replikują się na komórkowej siatce, nie mówimy, że pętle „projektują” nowe pętle. Replikacja jest po prostu tym, co wytwarzają reguły. A jednak wynik, czyli stale rosnące kolonie samopodobnych wzorów, jest niezaprzeczalnie generatywny i w pewnym funkcjonalnym sensie twórczy.

Kiedy agenci AI składają interfejsy z komponentów systemu projektowego, kierując się semantycznymi tokenami i ograniczeniami kompozycji, robią coś podobnego. „Kreatywność” nie tkwi w agentach, lecz w regułach, które wykonują. Reguły zaprojektowali ludzie, ale teraz działają one samodzielnie.

Stoimy na progu nowej ery w tworzeniu cyfrowym. Agenci już tu są. Protokoły dopiero się kształtują. Systemy projektowe stają się podłożem dla sztucznego życia.

Projekt to kod.
A kod ożywa.

Kluczowe artykuły i projekty

• Design Systems in the Time of AI – Brad Frost
• Storybook MCP Sneak Peek – Storybook
• Introducing AX: Why Agent Experience Matters – Mathias Biilmann
• Building Effective Agents – Anthropic

Zasoby o Drupal AI

• Drupal AI

• Moduł Schema.org Blueprints

   

Zasoby o automatach komórkowych

• Conway's Game of Life Lexicon – około 1500 figur
• A Working Turing Machine in Game of Life
• Langton's Loops – Wikipedia
• Rule Sets for Cellular Automata
• A New Kind of Science Online – Stephen Wolfram
• Cellular Automata – Nature of Code

Zbadane idee leżące na styku teorii obliczeń, systemów projektowych, sztucznej inteligencji i tworzenia stron internetowych.

 Przedstawione poglądy są spekulatywnymi rozważaniami o wyłaniających się trendach, a nie przewidywaniami pewnej przyszłości.

Widzę, że tworzymy agentów AI, którzy działają w pętli i wchodzą w interakcje z innymi agentami AI w kolejnych pętlach.

Projekt jest kodem, gdy system działa w pętli, jak pętla życia w wybranym kanwie i zestawie reguł.