Suunnittelu on koodia

Kuinka soluautomaattien logiikka muokkaa agenttipohjaisia suunnittelujärjestelmiä – ja miksi verkkokehityksen tulevaisuus saattaa olla jo kirjoitettu yksinkertaisiin sääntöihin

Suunnittelujärjestelmien, tekoälyn ja laskennan teorian risteyksessä tapahtuu syvällinen muutos. Se on niin perustavanlaatuinen, että se haastaa käsityksemme siitä, mitä "suunnittelu" edes tarkoittaa autonomisten agenttien aikakaudella.

Vuosikymmenten ajan olemme pitäneet suunnittelua ja koodia erillisinä aloina: suunnittelu on ollut ihmisen luovuuden ja esteettisen arvostelukyvyn aluetta, koodi taas näiden ideoiden mekaanista kääntämistä suoritettavaan muotoon. Mutta kun tekoälyagentit kokoavat käyttöliittymiä yhä itsenäisemmin, käyttävät suunnittelujärjestelmiä koneluettavana infrastruktuurina ja tuottavat koodia semanttisista tokeneista, lähestymme käännekohtaa, joka kaikuu paljon vanhemmasta laskennan teorian ajatuksesta.

Mikä ajatus? Suunnittelu on koodia.

Tämä ei ole pelkkä tarttuva lause. Se on havainto siitä, että olemme ehkä matkalla kohti maailmaa, jossa suunnittelujärjestelmät toimivat kuin soluautomaatit: yksinkertaiset säännöt synnyttävät monimutkaista, emergenttiä käyttäytymistä. Maailmaa, jossa ero jonkin "suunnittelemisen" ja sen "ohjelmoinnin" välillä katoaa kokonaan. Jossa autonomiset agentit eivät vain käytä suunnittelujärjestelmiä vaan ovat suunnittelujärjestelmiä toiminnassa.

Tässä blogikirjoituksessa tarkastellaan soluautomaattien, emergentin käyttäytymisen ja agenttipohjaisten suunnittelujärjestelmien tulevaisuuden syviä yhteyksiä. Seuraamme teoreettisia perusteita von Neumannin itseään kopioivista koneista nykypäivän tekoälyagenttien parviin.

Tarkastelemme, miten Drupal ja nykyaikaiset sisällönhallintajärjestelmät yhdistävät tekoälyä moduulien, kuten Schema.org Blueprintsin ja Drupal AI:n, avulla. Ja pohdimme, mitä tämä kaikki merkitsee suunnittelijoille, kehittäjille ja digitaalisten tuotteiden luomisen tulevaisuudelle.

Soluautomaatit ja emergenssin logiikka

Yksinkertaisten sääntöjen kauneus

Vuonna 1970 matemaatikko John Conway esitteli Game of Life -pelin – "nollan pelaajan pelin", josta tuli yksi laskennan teorian tutkituimmista järjestelmistä. Säännöt ovat henkeäsalpaavan yksinkertaisia:

1. Jokainen elävä solu, jolla on alle kaksi elävää naapuria, kuolee (alipopulaatio)
2. Jokainen elävä solu, jolla on kaksi tai kolme elävää naapuria, selviää
3. Jokainen elävä solu, jolla on yli kolme elävää naapuria, kuolee (ylipopulaatio)
4. Jokainen kuollut solu, jolla on täsmälleen kolme elävää naapuria, heräävät eloon (lisääntyminen)

Näistä neljästä säännöstä – jotka voi ilmaista kourallisella binäärisiä ehtoja – syntyy hämmästyttävän monimutkainen maailmankaikkeus. Liitäjät (gliders) kulkevat äärettömillä ruudukoilla. Oskillaattorit sykkivät ikuisissa rytmeissä. Tykit ampuvat kuviovirtoja solujen avaruuteen. Ja ennen kaikkea: Game of Life on todistettu Turing-täydelliseksi: kaikki, mitä voidaan laskea algoritmisesti, voidaan periaatteessa laskea myös Conwayn yksinkertaisessa ruudukossa.

Kuvio 1: Gosperin purjelentokone-tykki Conwayn Game of Life -pelissä. Tämä kuvio tuottaa jatkuvan virran purjelentokoneita (glider) – ja osoittaa, kuinka yksinkertaisista säännöistä voi syntyä päättymätöntä, itseään ylläpitävää monimutkaisuutta.

Tämä on soluautomaattien ensimmäinen oppitunti: monimutkainen käyttäytyminen ei vaadi monimutkaisuutta. Yksinkertaiset säännöt, joita sovelletaan johdonmukaisesti koko alustaan, voivat synnyttää kuvioita ja ilmiöitä, joita kukaan ei ole erikseen ohjelmoinut.

Langtonin silmukat ja itsensä kopioiminen

Vuonna 1984 Christopher Langton vei tämän periaatteen pidemmälle itseään kopioivilla silmukoillaan – soluautomaatilla, joka havainnollisti aidon tekoälyelämän (artificial life) periaatteita. Siinä missä Conwayn Game of Life näyttää emergentin monimutkaisuuden, Langtonin silmukat näyttävät emergentin lisääntymisen.

. Jokainen silmukka koostuu kehämäisestä reunasta, jonka sisällä on solujen tiloihin koodattu ”genomi”. Tämä genomi kiertää jatkuvasti silmukkaa ja virtaa ulos rakennusvartta pitkin, joka rakentaa tytärsilmukan 151 aikaaskeleessa. Kun tytär on valmis, se irtoaa emostaan, ja molemmat jatkavat lisääntymistä.

Kuvio 2: Langtonin silmukka alkutilassaan. Geneettinen informaatio kiertää silmukassa ja ohjaa tytärsilmukoiden rakentamista ulottuvan varren kautta.

”Jos itseään kopioiva kone on mahdollinen soluautomaatin sisällä, myös elämä itse saattaa olla koneilla saavutettavissa.”

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

Seuraukset ovat syvällisiä. Langtonin silmukat osoittavat, ettei itsensä kopioiminen vaadi biologisten solujen monimutkaisuutta eikä von Neumannin alkuperäisen mallin yleistä rakennuskykyä. Se vaatii vain:

• Joukon yksinkertaisia, paikallisia sääntöjä
• Mekanismin ohjeiden koodaamiseen
• Prosessin, jolla nuo ohjeet suoritetaan

Säännöt ovat organismi. Suunnitelma on koodi.

Vuonna 1999 Hiroki Sayama esitteli evoloopit (evoloops) – muunnelmat, joissa on rakenteellinen hajoavuus ja fenotyyppien välistä vuorovaikutusta, mikä mahdollistaa spontaanit mutaatiot ja evolutiivisen dynamiikan. Nämä silmukat kehittyvät suorien fyysisten törmäysten kautta kopioitumisen aikana, mikä johtaa genotyypin muunnelmiin, kasvavaan muotojen moninaisuuteen ja monimutkaisuuden kasvuun sukupolvesta toiseen. Toisin kuin Langtonin kiinteä kopiointi, evoloopit osoittavat periytyviä mutaatioita ilman ulkoista väliintuloa.

Sääntö 110 ja universaali laskenta

Stephen Wolframin tutkimukset alkeellisista soluautomaateista huipentuivat hätkähdyttävään löytöön: Sääntö 110, yksi vain 256 mahdollisesta säännöstä yksinkertaisimmalle yksiulotteiselle soluautomaattityypille, kykenee universaaliin laskentaan.

Sääntö 110 voidaan määritellä täydellisesti kertomalla lopputulos kullekin kahdeksalle mahdolliselle yhdistelmälle, jotka solu ja sen kaksi naapuria voivat muodostaa. Silti tämä mitättömän yksinkertainen sääntö, kahdeksan binääripäätöstä, pystyy simuloimaan universaalin Turingin koneen.

Kuva 3: Sääntö 110 -soluautomaatti. Yksinkertaisesta määritelmästään huolimatta sääntö 110 käyttäytyy luokan 4 tavoin: se tuottaa monimutkaisia kuvioita, jotka eivät ole täysin vakaita eivätkä täysin kaoottisia. Sen on myös todistettu olevan Turing-täydellinen.

”Universaaliin laskentaan ei tarvita mitään kokonaisen tietokoneen suorittimen kaltaista. Tarvitaan vain tämä pieni sääntö.”

- Stephen Wolfram, ”A New Kind of Science”

Vuonna 2004 Matthew Cook julkaisi todistuksen, jonka mukaan sääntö 110 on Turing-täydellinen, kun sen taustalla on tietty toistuva kuvio. Todistus osoittaa, että sääntö 110 pystyy emuloimaan syklisiä tagijärjestelmiä (cyclic tag systems), jotka puolestaan pystyvät emuloimaan mitä tahansa Turingin konetta. Kaikista 88 mahdollisesta ainutlaatuisesta alkeissoluautomaatista sääntö 110 on ainoa, jonka Turing-täydellisyys on todistettu suoraan.

Wolframin esittämä laskennallisen ekvivalenssin periaate vie ajatuksen vielä radikaalimpaan suuntaan: järjestelmät, jotka ylittävät tietyn monimutkaisuuden vähimmäiskynnyksen, ovat laskennallisilta kyvyiltään pohjimmiltaan samanarvoisia. Ihmisaivot, sääjärjestelmä ja sääntö 110 ovat jollakin syvällä tasolla laskennallisesti ekvivalentteja.

0E0P-metasolu: aito itsensä kopioiminen

Lokakuussa 2018 Adam P. Goucher sai valmiiksi 0E0P-metasolun – Conwayn Elämän pelin (Game of Life) kuvion, joka kykenee aitoon itsensä kopioimiseen. Toisin kuin aiemmat metasolut, jotka tarvitsivat valmiita kopioita lähelleen, 0E0P-metasolu pystyy rakentamaan itsestään kopioita tyhjästä, myös oman ohjenauhansa.

Saavutus on virstanpylväs keinotekoisen elämän tutkimuksessa: järjestelmä, joka voi levittää itseään laskennallisessa alustassa pelkästään paikallisten sääntöjen avulla. Jo 23. marraskuuta 2013 Dave Greene rakensi Elämän peliin ensimmäisen replikaattorin, joka luo itsestään täydellisen kopion ohjenauha mukaan lukien. Se osoitti, että jopa Conwayn yksinkertainen kaksitilainen automaatti kykenee rajoittamattomaan itsensä toistamiseen.

Suunnittelujärjestelmät laskennallisina alustoina

Atomic Designista agenttiseen suunnitteluun

Brad Frostin vuonna 2013 esittelemä Atomic Design -menetelmä mullisti tavan, jolla ajattelemme suunnittelujärjestelmiä. Se jakaa käyttöliittymät atomeihin (perusosat kuten painikkeet ja syöttökentät), molekyyleihin (yksinkertaiset yhdistelmät), organismeihin (monimutkaiset käyttöliittymän osiot), malleihin (sivupohjat) ja sivuihin (lopulliset toteutukset), ja antoi näin monimutkaisuuden hallintaan hierarkkisen rakenteen.

Mutta jälkikäteen katsottuna huomionarvoista on tämä: Atomic Design sisälsi jo soluautomaattien periaatteet ilman, että niitä tunnistettiin erikseen.

"Kun design system on tylsä, se vapauttaa suunnittelijat ja kehittäjät tekemään uutta ja ratkaisemaan uusia ongelmia. Design system kantaa tylsyyden taakan, jotta suunnittelijoiden ja kehittäjien ei tarvitse."

- Josh Clark, "The Most Exciting Design Systems Are Boring"

Helmikuussa 2023 Brad Frost kirjoitti aiheesta "Design Systems in the Time of AI":

"Tekoäly on luonteva design systemin käyttäjä... Tosiasia on, että suuri osa design systemin komponenttityöstä on todella mekaanista ja ennustettavaa. Käytämme jo työkaluja kuten PlopJS, joilla luodaan komponentin runko, joka vastaa muun kirjaston muotoa. Otan mielelläni vastaan tekoälyn apua monien tavanomaisten runkotiedostojen tuottamisessa."

- Brad Frost

Design systemien mekaaninen ja ennustettava luonne tekee niistä juuri sopivia soluautomaattityyliseen toimintaan. Kun säännöt ovat selkeät, paikalliset ja johdonmukaisesti sovellettuja, agentit voivat toimia itsenäisesti – aivan kuten Conwayn Game of Lifen solut eivät tarvitse keskitettyä ohjainta tuottaakseen liitimiä ja oskillaattoreita.

Koneluettavuuden välttämättömyys

Storybook MCP (Model Context Protocol) -aloite on merkittävä kehitysaskel tähän suuntaan. Loppuvuodesta 2025 julkistettu Storybook MCP tarjoaa tekoälyn koodausagenteille koneluettavaa komponenttien metadataa olemassa olevista Storybook-asennuksista.

Keskeinen oivallus on, etteivät agentit tarvitse raakaa koodia tai visuaalista dokumentaatiota. Ne tarvitsevat:

• Komponenttimanifestit: Jäsenneltyä metadataa jokaisesta komponentista – sen propseista, variaatioista, design token -sidoksista ja käyttöesimerkeistä
• Semanttinen nimeäminen: Merkitystä kantavia tokeneita, kuten action.primary.confirm, jotka välittävät agenteille merkityksen, eivät pelkkiä arvoja
• Validointisilmukat: Kyky ajaa testejä, nähdä virheet ja korjata itse itseään

"Storybook MCP auttaa agentteja noudattamaan malleja ja läpäisemään testit. Se antaa agenteille kaksi asiaa, joita niillä ei ole ennen ollut: koneluettavaa komponenttien metadataa ja iteratiivisen silmukan virheiden itsekorjaamiseen."

- Storybook-tiimi

Storybook MCP sisältää autonomisen korjaussilmukan. Sen avulla agentit voivat ajaa komponenttitestit (interaktio- ja saavutettavuustestit), nähdä mikä epäonnistuu ja korjata omat virheensä. Kehittäjän tarvitsee astua mukaan vasta, kun testit menevät läpi. Ei enää kehotteiden lastenvahtina toimimista.

Tämä on juuri soluautomaatin arkkitehtuuri sovellettuna suunnitteluun: paikalliset säännöt (komponenttien määrittelyt), naapurivuorovaikutukset (koostamismallit) ja iteratiiviset päivitykset (validointi ja itsekorjaus).

Komponenttimanifesti genomina

Vertaus Langtonin silmukoihin käy vielä osuvammaksi, kun tarkastelemme komponenttimanifestien toimintaa. Langtonin järjestelmässä kiertävissä soluissa koodattu "genomi" sisältää ohjeet uuden silmukan rakentamiseen. Koneluettavassa design systemissä komponenttimanifesti sisältää ohjeet käyttöliittymien kokoamiseen.

Komponenttimanifesti voisi määritellä:

{
  "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" }
  ]
}

Tämä manifesti on yhtä aikaa suunnittelumäärittely ja suoritettavaa koodia – tai tarkemmin sanottuna ohjeet, joista suoritettavaa koodia voidaan tuottaa. Manifestia käyttävän agentin ei tarvitse ymmärtää estetiikkaa tai käyttökokemusta ihmisen tavoin. Sen täytyy noudattaa sääntöjä, yhdistellä elementtejä niiden rajoitteiden mukaisesti ja tuottaa kelvollisia tuloksia.

Olen Brad Frostin kanssa samaa mieltä siitä, että käytössä pitäisi olla yaml-muoto.

Drupalin komponentit käyttävät yaml-muotoa. Jotakin tällaista

$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

Suunnittelu on koodia.

• Variantit
• Tokenit
• Propsit

• Rajoitteet (voisimme lisätä komponentteihin)

• Slottien säännöt (mitä muihin slotteihin saa sijoittaa tai mitä omaan slottiini saa sijoittaa)

• Säännöt

• Esimerkit 

• Animaatiot  ( Sallittu tai ohjeistettu käytettäväksi )

Sen jälkeen voit katsella ja kokeilla toimintaa.

kuten täällä: https://storybook.demo.varbase.vardot.com/?path=/story/atoms-button--primary 

Design tokenit ympäristömuuttujina

Design tokenit ovat toinen ratkaisevan tärkeä pala palapelissä. Soluautomaateissa solut reagoivat välittömään ympäristöönsä – naapurisolujen tiloihin. Design-järjestelmissä komponentit reagoivat design tokeneihin – kontekstuaalisiin arvoihin, jotka määräävät niiden ulkoasun ja käyttäytymisen.

Nykyaikaiset token-arkkitehtuurit koostuvat useista kerroksista:

• Ydintokenit: Raaka-arvot, kuten color.blue.500: #3B82F6
• Semanttiset tokenit: Käyttötarkoitukseen perustuvat viittaukset, kuten color.action.primary: color.blue.500
• Komponenttitokenit: Rajatut sovellukset, kuten button.background.primary: color.action.primary

Kun agentti luo Button-komponentin, sen ei tarvitse tietää, että "primary" tarkoittaa sinistä. Sen tarvitsee vain viitata tokeniin button.background.primary ja luottaa siihen, että token-järjestelmä ratkaisee oikean arvon. Ympäristö (token-kerros) sisältää tiedon; komponentin (solun) tarvitsee vain reagoida siihen.

Työkalut, kuten Tokens Studio, ovat kehittyneet käsittelemään design tokeneita laskennallisina graafeina, joissa on resolverit – solmut, jotka tekevät semanttisia päätöksiä siitä, mitä perustokeneita kontekstin perusteella käytetään. Tämä muuttaa design tokenit staattisista arvoista dynaamisiksi, sääntöpohjaisiksi järjestelmiksi.

Drupal-ekosysteemi ja tekoälyn integrointi

Tekoälyn integroiminen sisällönhallintajärjestelmiin on täydellinen laboratorio "suunnittelu on koodia" -periaatteiden tutkimiseen. Drupalin kaltaiset CMS-järjestelmät sisältävät jo ydinkäsitteet: jäsennellyt sisältötyypit, kenttämäärittelyt, suhteet ja koostamisen säännöt.

En koskaan uskonut, että voisimme sanoa jotain tällaista. Minulle tämä oli alan huippua.

 Ylivertainen tietokonekokoonpano, josta voisimme vain haaveilla. Kehittäjiä, jotka voisivat olla peräisin tulevaisuuden Star Trekistä ja puhuisivat tietokoneelle, jotta se ohjelmoi heidän puolestaan.

Agenttikokemus (AX) ja uusi käyttäjä

Suunnittelua koneille

Alkuvuodesta 2025 Netlifyn toimitusjohtaja Mathias Biilmann esitteli käsitteen "Agent Experience" (AX) eli uuden osa-alueen, joka keskittyy siihen, miten tekoälyagentit toimivat tuotteiden ja alustojen kanssa.

Muutos on perustavanlaatuinen. Vuosikymmenten ajan UX (käyttökokemus) optimoitiin ihmisen kognitiota, havaitsemista ja käyttäytymistä varten. DX (kehittäjäkokemus) optimoitiin ohjelmistoja rakentaville ihmiskehittäjille. AX tunnustaa, että agenteista on tulossa digitaalisten järjestelmien ensisijaisia käyttäjiä – ja niillä on täysin erilaiset tarpeet:

• Niitä ei kiinnosta visuaalinen estetiikka – vain jäsennelty, jäsennettävä data
• Ne eivät selaa käyttöliittymiä – ne kutsuvat rajapintoja ja hyödyntävät manifesteja
• Ne eivät lue dokumentaatiota kuten ihmiset – ne tarvitsevat koneluettavaa kontekstia
• Ne eivät tee subjektiivisia arvioita – ne noudattavat sääntöjä ja rajoitteita

"AI-agentteja eivät ole ihmisiä: niitä ei kiinnosta painikkeen koko, typografian luettavuus, verkkosivustosi kaunis värimaailma tai sovelluksesi näyttävät animaatiot. Mistä AI-agentit sitten 'välittävät'? Tähän kysymykseen ei tänään ole konkreettista vastausta, mutta siitä tulee tärkeämpi ja tärkeämpi tulevina vuosina."

- AX-tutkimus

Vastaus: selkeät säännöt, ennustettava käytös, hyvin jäsennelty data ja palautesilmukat, joiden avulla agentit voivat tarkistaa ja korjata toimintansa.

Kaksoisrajapinnan haaste

AX:n suunnittelu tarkoittaa kahden rajapinnan rakentamista samanaikaisesti:

1. Ihmisen ja agentin välinen rajapinta: Tässä ihmiset valvovat, hyväksyvät, muokkaavat ja ohjaavat agentin toimintaa – se on "komentokeskuksen" kerros. Ajattele kojetauluja ja hyväksyntäjonoja, ei lomakkeita ja painikkeita.
2. Agentin ja järjestelmän välinen rajapinta: Tässä agentit käyttävät rajapintoja (API), tietokantoja ja työkaluja – se on "operatiivinen" kerros. Sen on oltava vankka, hyvin dokumentoitu ja optimoitu koneiden tehokkuutta varten.

Tämä heijastaa soluautomaattien arkkitehtuuria, jossa kaksi erilaista näkökulmaa elää rinnakkain:

• Paikallinen näkökulma: Jokainen solu (agentti) noudattaa yksinkertaisia sääntöjä välittömien naapureidensa perusteella
• Globaali näkökulma: Syntyy monimutkaisia kuvioita, jotka näkyvät vain suuressa mittakaavassa

"Agenttikokemuksen suunnittelun (AX) tulisi tuottaa erinomainen käytettävyys agenteille ja agenttien kannalta. Siksi erinomainen AX johtaa erinomaiseen käyttäjäkokemukseen (UX). Jos tekoälyagentti kohtaa rikkinäisen prosessin, protokollan tai edes epäjohdonmukaista sanastoa järjestelmien välillä, se ei pysty suorittamaan tehtävää. Se on huono kokemus agentille, mikä puolestaan johtaa huonoon asiakas- tai työntekijäkokemukseen."

- Kat Holmes, Chief Experience Officer, Salesforce

UX:stä AX:ään: digitaalisen suunnittelun evoluutio

Stigmergia ja epäsuora viestintä

Yksi parviälyn tehokkaimmista käsitteistä on stigmergia – epäsuora koordinaatio ympäristöön jäävien jälkien kautta. Muurahaiset eivät kerro toisilleen suoraan ruoan sijainnista; ne jättävät feromonijälkiä, joita muut muurahaiset seuraavat. Ympäristöstä tulee viestintäväline.

Agenttipohjaisissa suunnittelujärjestelmissä stigmergia näyttäytyy seuraavasti:

• Jaetut komponenttikirjastot: Agentit "näkevät", mitä komponentteja on olemassa ja miten niitä on käytetty
• Design-tokenit: Semanttisia arvoja, jotka koodaavat suunnittelupäätökset ympäristön tosiasioiksi
• Mallidokumentaatio: Käyttöesimerkit, jotka toimivat feromonijälkinä tuleville agenteille
• Testisarjat: Validointisäännöt, jotka rajaavat sallittujen tulosten joukkoa
• Git-historia: Tallenne aiemmista päätöksistä, joihin agentit voivat viitata

Kun agentti luo käyttöliittymän komponentin avulla, se jättää jälkiä – koodikantaan, dokumentaatioon ja luomiinsa malleihin. Tulevat agentit, jotka kohtaavat samanlaisia tehtäviä, ovat näiden jälkien vaikutuksen alaisia, ja syntyy kollektiivisen älykkyyden muoto, jota yksikään yksittäinen agentti ei omaa.

Agenttipohjaiset suunnittelumallit

Andrew Ng ja muut ovat tunnistaneet neljä keskeistä mallia agenttipohjaisille tekoälyjärjestelmille:

1. Reflektio: Tekoäly arvioi omaa tuotostaan ja parantaa sitä iteratiivisesti
2. Työkalujen käyttö: Tekoäly on vuorovaikutuksessa ulkoisten työkalujen, rajapintojen ja järjestelmien kanssa
3. Suunnittelu:Tekoäly pilkkoo monimutkaiset tehtävät osatehtäviksi ja suorittaa ne peräkkäin
4. Moniagenttimalli: Useat erikoistuneet agentit tekevät yhteistyötä monimutkaisten tehtävien parissa

Nämä mallit vastaavat suoraan soluautomaattien käsitteitä:

Suunnittelu on koodia – syvempi tulkinta

Mitä "suunnittelu on koodia" todella tarkoittaa

Kun sanomme, että "suunnittelu on koodia", esitämme samanaikaisesti useita väitteitä:

1. Semanttinen vastaavuus

Suunnittelupäätöksistä tulee suoritettavia, kun ne koodataan oikein. Design token ei ole pelkkä arvo vaan ohje. Komponenttimäärittely ei ole pelkkää dokumentaatiota vaan ohjelma. Kun agentit käyttävät näitä artefakteja, ne suorittavat suunnittelun siinä missä toteuttavat sitä.

2. Generatiivinen kyvykkyys

Kuten Rule 110 pystyy laskemaan kaiken laskettavissa olevan, riittävän kattava design system voi tuottaa minkä tahansa kelvollisen käyttöliittymän. Järjestelmä sisältää potentiaalin kaikkiin kelvollisiin ilmenemismuotoihinsa. Se, mitä syntyy, riippuu vain alkuehdoista (vaatimukset) ja säännöistä (rajoitteet).

3. Emergentti monimutkaisuus

Kehittyneimpiä käyttöliittymiä ei suunnitella ylhäältä alas, vaan ne syntyvät yksinkertaisten sääntöjen johdonmukaisesta soveltamisesta. Hyvin suunniteltu painike tuottaa johdonmukaisesti käytettynä eheän visuaalisen kielen, vaikka kukaan ei olisi erikseen suunnitellut tuota eheyttä.

4. Laskennallinen palautumattomuus

Joitakin suunnittelun lopputuloksia ei voi ennustaa ilman, että järjestelmä todella ajetaan. Et voi tietää, miltä agentin kokoama käyttöliittymä näyttää, ennen kuin annat agentin koota sen. Tämä on Wolframin laskennallisen palautumattomuuden periaate sovellettuna suunnitteluun.

5. Itsensä muokkaaminen

Kuten replikaation aikana mutatoituvat evoloopit, agenttivalmiit design systemit voivat kehittyä käytön myötä. Agenttien luomista komponenteista tulee osa kirjastoa, jota tulevat agentit hyödyntävät. Järjestelmä oppii, mukautuu ja kasvaa.

Soluautomaattimetafora laajennettuna

Metaforaa pidemmälle: todellinen konvergenssi

Mutta kyse ei ole pelkästä metaforasta. Konvergenssi on todellista ja tapahtuu juuri nyt:

• Storybook MCP muuttaa komponenttikirjastot koneluettaviksi ohjeiksi, joita agentit suorittavat
• Model Context Protocol standardoi tavan, jolla agentit käyttävät työkaluja ja kontekstia, ja luo yleisen alustan agenttiselle toiminnalle
• Moniagenttiarkkitehtuurit jakavat työt erikoistuneiden agenttien (arkkitehti, koodaaja, katselmoija) kesken, ja nämä toimivat protokollien mukaan kuin eriytyneet solut
• Itseään korjaavat silmukat– antavat agenttien ajaa testejä, havaita virheitä ja iteroida: samat palautemekanismit, joita soluautomaatit käyttävät kehittääkseen vakaita konfiguraatioita
• Schema.org Blueprints tekevät sisällön rakenteista koneluettavia ja semanttisesti merkityksellisiä
• Drupal AI tarjoaa infrastruktuurin, jonka avulla tekoälyagentit voivat luoda, muokata ja hallita sisältöä itsenäisesti

Emme lähesty ajatusta "suunnittelu on koodia" filosofisena kannanottona. Rakennamme sitä tekniseksi infrastruktuuriksi.

Vaikutukset ja tie eteenpäin

Suunnittelijoille

Suunnittelijan rooli muuttuu "suorakulmioiden piirtäjästä" "sääntöjen määrittelijäksi". Kuten Brad Frost totesi:

"Suunnittelijoilla ja kehittäjillä, jotka pitävät työtään suorakulmioiden luomisena, on paljon syytä huoleen. Mutta suunnittelijoilla ja kehittäjillä, jotka pitävät työtään ongelmien ratkaisemisena – ja joutuvat sivutuotteena luomaan tai käsittelemään suorakulmioita ratkaistakseen ne – on vähemmän pelättävää."

– Brad Frost

Agenttien aikana suunnittelijat tulevat:

• Määrittelemään semanttiset tokenit ja niiden väliset suhteet
• Asettamaan koostamisen rajoitteet ja mallit
• Luomaan validointisääntöjä, jotka agenttien on täytettävä
• Ylläpitämään ja kehittämään sääntöjä, jotka ohjaavat emergenssiä
• Suunnittelemaan palautemekanismit, jotka mahdollistavat itsekorjauksen
• Muotoilemaan "kelpoisuusfunktiot", jotka ratkaisevat, mitkä tulokset kelpaavat

Tämä on suunnittelua korkeammalla abstraktiotasolla: suunnitellaan suunnitelmia tuottavia sääntöjä itse suunnitelmien sijaan. Kuin määrittelisi soluautomaatin säännöt sen sijaan, että piirtäisi jokaisen solun erikseen.

Kehittäjille

Kehittäjistä tulee agenttijärjestelmien arkkitehteja. Kuten Anthropic kuvaa:

"Ohjelmistokehityksen alalla kielimallien ominaisuuksilla on osoittautunut olevan huomattavaa potentiaalia, ja kyvyt ovat kehittyneet koodin täydennyksestä itsenäiseen ongelmanratkaisuun."

Kehittäjien on:

• Luotava koneluettavat rajapinnat agenttien ja järjestelmien välille
• Suunniteltava palautesilmukat ja validointimekanismit
• Rakennettava tukirakenteet, joiden puitteissa emergentti käyttäytyminen syntyy
• Pidettävä ihmisen valvonta viimeisenä ratkaisijana
• Määriteltävä protokollat, joilla agentit kommunikoivat
• Toteutettava "liimakoodi", joka yhdistää eri agenttijärjestelmät

Verkkokehitykselle ja CMS-alustoille

Tekoälyn integroituminen Drupalin kaltaisiin alustoihin viittaa tulevaisuuteen, jossa:

• Sisältömallit muuttuvat agenttien hyödynnettäviksi Schema.org-kaltaisten standardien ansiosta
• Toimitukselliset työnkulut muuttuvat agenttiavusteisiksi tekoälyavusteisen luonnostelun, moderoinnin ja optimoinnin avulla
• Haku kehittyy avainsanojen täsmäytyksestä semanttiseen ymmärtämiseen upotusten ja vektoritietokantojen avulla
• Personointi muuttuu itsenäiseksi kun agentit oppivat käyttäjien mieltymykset ja mukauttavat sisältöä reaaliajassa
• Kehitys nopeutuu kun agentit generoivat komponentteja, testejä ja dokumentaatiota

Drupal-ekosysteemin tapa omaksua tekoäly – moduulien kuten Drupal AI, Drupal Canvas, Schema.org Blueprints ja tekoälypalveluntarjoajien integraation kautta – osoittaa, että tätä tulevaisuutta rakennetaan jo nyt.

Organisaatioille

Kilpailuetu on organisaatioilla, joiden design-järjestelmät ovat kaikkein "agenttivalmiimpia". Agenttivalmiita järjestelmiä leimaavat:

• Komponenttien tilojen ja varianttien kattava kuvaus
• Semanttinen nimeäminen, joka välittää tarkoituksen
• Koneluettava dokumentaatio ja konteksti
• Validointi- ja testausinfrastruktuuri
• Selkeät rajoitteet, jotka rajaavat sallittujen tulosten joukon
• Agenttien käyttöön suunnitellut rajapinnat (AX-first)
• Schema.org-lähtöiset sisältöarkkitehtuurit

Digitaalisten tuotteiden tulevaisuuden puolesta

Lopputulos on jotain digitaalisen ekologian kaltaista: lukemattomia agentteja, jotka toimivat paikallisten sääntöjen mukaan ja tuottavat esiin nousevia käyttöliittymiä, joita yksikään suunnittelija tai kehittäjä ei ole suunnitellut, mutta jotka silti jollain tavalla pysyvät koossa, koska taustalla olevat säännöt ovat kunnossa.

Tämä ei ole niin kaukaa haettua kuin miltä kuulostaa. Juuri näin biologiset järjestelmät toimivat, näin kaupungit kasvavat ja markkinat pyörivät. Kysymys ei ole siitä, päädymmekö tähän tilaan, vaan siitä, miten selviämme siirtymästä.

Johtopäätös: koodi elää

John von Neumann, cellular automata -solukkoautomaattien keksinyt universaalinero, lähti liikkeelle perustavanlaatuisesta kysymyksestä: Kuinka pieni monimutkaisuus riittää itsensä kopioimiseen? Hänen vastauksensa, von Neumannin universaali konstruktori, osoitti, ettei itsensä monistaminen vaadi biologista koneistoa. Se vaatii vain sääntöjä, jotka koodaavat oman soveltamisensa.

Seitsemänkymmentä vuotta myöhemmin huomaamme saman periaatteen pätevän suunnittelujärjestelmiin. Itsenäisen käyttöliittymien luomisen vähimmäisvaatimus ei ole yleinen tekoäly eikä ihmistason luovuus. Se on täydellinen, johdonmukainen ja koneluettava sääntöjoukko, jota agentit voivat suorittaa.

Kun Langtonin silmukat (Langton's Loops) monistuvat solukossa, emme sano silmukoiden "suunnittelevan" uusia silmukoita. Monistuminen on yksinkertaisesti se, mitä säännöt tuottavat. Silti lopputulos, yhä laajenevat itsensä kaltaisten kuvioiden yhdyskunnat, on kiistatta generatiivinen ja jollain toiminnallisella tavalla luova.

Kun tekoälyagentit kokoavat käyttöliittymiä suunnittelujärjestelmän komponenteista semanttisia tokeneita ja koostamisen rajoitteita noudattaen, ne tekevät jotain samankaltaista. "Luovuus" ei ole agenteissa vaan sääntöjen suorittamisessa: säännöt ovat ihmisten suunnittelemia, mutta ne toimivat nyt itsenäisesti.

Olemme uuden digitaalisen luomisen aikakauden kynnyksellä. Agentit ovat jo täällä. Protokollat ovat muotoutumassa. Suunnittelujärjestelmistä on tulossa keinotekoisen elämän alustoja.

Suunnittelu on koodia.
Ja koodi herää eloon.

Keskeiset artikkelit ja projektit

• 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

Drupal AI -resurssit

• Drupal AI

• Schema.org Blueprints Module

   

Solukkoautomaattien resurssit

• Conway's Game of Life Lexicon – noin 1500 kuviota
• 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

Tutkin ideoita laskennallisen teorian, suunnittelujärjestelmien, tekoälyn ja verkkokehityksen leikkauspisteessä.

 Esitetyt näkemykset ovat spekulatiivisia pohdintoja nousevista suuntauksista, eivät ennusteita varmoista tulevaisuuksista.

Näen, että luomme tekoälyagentteja, jotka toimivat silmukassa ja ovat vuorovaikutuksessa muiden tekoälyagenttien kanssa omissa silmukoissaan.

Suunnittelu on koodia, kun järjestelmä toimii silmukassa, kuin elämänkaari valitulla kankaalla ja sääntöjoukon sisällä.