O deseño é o código

Como a lóxica dos autómatas celulares reconfigurará os sistemas de deseño axénticos, e por que o futuro do desenvolvemento web quizais xa estea escrito en regras simples

Hai unha transformación profunda en marcha na encrucillada entre os sistemas de deseño, a intelixencia artificial e a teoría da computación. É un cambio tan de fondo que pon en cuestión o que significa «deseño» na era dos axentes autónomos.

Durante décadas tratamos o deseño e o código como disciplinas separadas: o deseño como territorio da creatividade humana e do criterio estético, e o código como a tradución mecánica desas ideas a unha forma executable. Pero a medida que os axentes de IA montan interfaces de usuario de xeito autónomo, consomen os sistemas de deseño como infraestrutura lexible por máquinas e xeran código a partir de tokens semánticos, achegámonos a un punto de converxencia que lembra unha idea moito máis antiga da teoría da computación.

Que idea? O deseño é o código.

Non é só unha frase con gancho. É recoñecer que quizais nos dirixamos cara a un mundo no que os sistemas de deseño funcionan como autómatas celulares: regras simples das que xorden comportamentos complexos e emerxentes. Un mundo no que a distinción entre «deseñar» algo e «programalo» se esvaece por completo. Onde os axentes autónomos non só usan os sistemas de deseño, senón que son sistemas de deseño en acción.

Esta entrada do blog explora as conexións profundas entre os autómatas celulares, o comportamento emerxente e o futuro dos sistemas de deseño axénticos. Seguiremos o rastro dos fundamentos teóricos, desde as máquinas autorreplicantes de von Neumann ata os enxames de axentes de IA de hoxe.

Veremos como Drupal e as plataformas CMS modernas están integrando a IA mediante módulos como Schema.org Blueprints e Drupal AI. E pensaremos no que todo isto significa para deseñadores, desenvolvedores e o futuro da creación de produtos dixitais.

Os autómatas celulares e a lóxica da emerxencia

A beleza das regras simples

En 1970, o matemático John Conway presentou o Xogo da vida, un «xogo sen xogadores» que chegaría a ser un dos sistemas máis estudados da teoría da computación. As regras son dunha sinxeleza abraiante:

1. Toda célula viva con menos de dous veciños vivos morre (subpoboación)
2. Toda célula viva con dous ou tres veciños vivos sobrevive
3. Toda célula viva con máis de tres veciños vivos morre (superpoboación)
4. Toda célula morta con exactamente tres veciños vivos volve á vida (reprodución)

Destas catro regras, expresadas nun puñado de condicións binarias, xorde un universo asombroso de complexidade. Os planeadores (gliders) cruzan redes infinitas. Os osciladores laten con ritmos perpetuos. Os canóns lanzan fluxos de patróns polo espazo celular. E, o máis notable, está demostrado que o Xogo da vida é Turing-completo: todo o que se pode calcular algorítmicamente pódese, en principio, calcular dentro da sinxela cuadrícula de Conway.

Figura 1: A canón de planadores de Gosper no Xogo da vida de Conway. Este patrón produce un fluxo continuo de planadores e amosa como unhas regras sinxelas poden xerar unha complexidade infinita que se perpetúa a si mesma.

Esta é a primeira lección dos autómatas celulares: a complexidade non é un requisito para un comportamento complexo. Unhas regras sinxelas, aplicadas de forma constante sobre un substrato, poden dar lugar a patróns e comportamentos que ninguén programou de maneira explícita.

Os Loops de Langton e a autorreplicación

En 1984, Christopher Langton levou este principio máis lonxe cos seus loops autorreplicantes, un autómata celular que demostraba principios reais de vida artificial. Mentres que o Xogo da vida de Conway amosa complexidade emerxente, os Loops de Langton amosan unha reprodución.

emerxente. Cada loop componse dun bordo cíclico que encerra un «xenoma» codificado nos estados das celas. Ese xenoma flúe de forma continua arredor do loop e sae por un brazo construtor, que levanta un loop filla ao longo de 151 pasos de tempo. Cando remata, a filla sepárase da nai e ambas seguen replicándose.

Figura 2: O Loop de Langton na súa configuración inicial. A información xenética circula polo loop e dirixe a construción dos loops filla a través do brazo que se estende.

«Se unha máquina que se reproduce a si mesma é posible dentro dun autómata celular, entón a propia vida podería estar ao alcance das máquinas.»

- Christopher Langton, «Studying Artificial Life with Cellular Automata» (1986)

As implicacións son profundas. Os Loops de Langton demostran que a autorreplicación non precisa a complexidade das células biolóxicas nin as capacidades de construción universal do deseño orixinal de von Neumann. Só require:

• Un conxunto de regras sinxelas e locais
• Un mecanismo para codificar instrucións
• Un proceso polo cal se executan esas instrucións

As regras son o organismo. O deseño é o código.

En 1999, Hiroki Sayama presentou os evoloops, variantes que incorporan a disolubilidade estrutural e as interaccións fenotípicas, o que permite mutacións espontáneas e dinámicas evolutivas. Estes loops evolucionan a través de colisións físicas directas durante a replicación, o que leva a variacións do xenotipo, a unha maior diversidade morfolóxica e ao crecemento da complexidade ao longo das xeracións. A diferenza da replicación fixa de Langton, os evoloops amosan mutacións herdables sen intervención externa.

A Regra 110 e a computación universal

A exploración de Stephen Wolfram dos autómatas celulares elementais culminou nun descubrimento sorprendente: a Regra 110, unha das só 256 regras posibles para o tipo máis simple de autómata celular unidimensional, é capaz de realizar computación universal.

A regra 110 pódese especificar por completo indicando o resultado de cada unha das oito combinacións posibles dunha cela e as súas dúas veciñas. E, así e todo, esta regra tan trivialmente sinxela —oito decisións binarias— é quen de simular unha máquina de Turing universal.

Figura 3: autómata celular da regra 110. Malia a súa definición sinxela, a regra 110 presenta un comportamento de clase 4 —patróns complexos que non son nin totalmente estables nin totalmente caóticos— e demostrouse que é Turing completa.

"Non fai falta nada que se pareza a unha CPU de ordenador completa para facer computación universal. Só fai falta esta pequena regra."

- Stephen Wolfram, "A New Kind of Science"

En 2004, Matthew Cook publicou unha demostración de que a regra 110, cun determinado patrón de fondo que se repite, é Turing completa. A demostración amosa que a regra 110 pode emular sistemas de etiquetas cíclicas, que á súa vez poden emular calquera máquina de Turing. Entre os 88 autómatas celulares elementais únicos posibles, a regra 110 é a única da que se demostrou directamente a completude de Turing.

O Principio de Equivalencia Computacional que propuxo Wolfram suxire algo aínda máis radical: os sistemas que superan un limiar mínimo de complexidade son, en esencia, equivalentes nas súas capacidades computacionais. Un cerebro humano, un sistema meteorolóxico e a regra 110 son, nun sentido profundo, computacionalmente equivalentes.

A metacela 0E0P: a verdadeira autorreplicación

En outubro de 2018, Adam P. Goucher completou a construción da metacela 0E0P —un patrón do Xogo da vida de Conway capaz de autorreplicarse de verdade. A diferenza das metacelas anteriores, que precisaban copias preexistentes preto, a metacela 0E0P pode construír copias de si mesma desde cero, incluída a súa propia cinta de instrucións.

Este logro representa un fito na vida artificial: un sistema que pode propagarse a través dun substrato computacional empregando só regras locais. O 23 de novembro de 2013, Dave Greene construíu o primeiro replicador do Xogo da vida que crea unha copia completa de si mesmo, incluída a cinta de instrucións, demostrando que mesmo o sinxelo autómata de dous estados de Conway pode soportar unha autorreprodución sen límites.

Os sistemas de deseño como substratos computacionais

Do deseño atómico ao deseño axéntico

A metodoloxía de deseño atómico (Atomic Design) de Brad Frost, presentada en 2013, revolucionou a forma de pensar os sistemas de deseño. Ao dividir as interfaces en átomos (elementos básicos como botóns e campos de entrada), moléculas (combinacións sinxelas), organismos (seccións complexas da interface), modelos (estruturas de páxina) e páxinas (implementacións finais), o Atomic Design achegou unha estrutura xerárquica para xestionar a complexidade.

Pero velaquí o máis notable, visto en retrospectiva: o Atomic Design xa encarnaba os principios dos autómatas celulares sen os recoñecer de maneira explícita.

«Cando o sistema de deseño é aburrido, libera a deseñadores e desenvolvedores para facer cousas novas, para resolver problemas novos. O sistema de deseño carga co peso do aburrido, para que deseñadores e desenvolvedores non teñan que facelo.»

- Josh Clark, «The Most Exciting Design Systems Are Boring»

En febreiro de 2023, Brad Frost escribiu sobre «Design Systems in the Time of AI»:

«A IA é unha consumidora natural dos sistemas de deseño... O certo é que gran parte do traballo con compoñentes dun sistema de deseño é realmente mecánico e previsible. Xa usamos ferramentas como PlopJS para xerar de golpe o código base dun compoñente que encaixa coa forma do resto da biblioteca. Benvida sexa a axuda da IA para xerarme moitas das cousas base máis habituais.»

- Brad Frost

A natureza mecánica e previsible dos sistemas de deseño é precisamente o que os fai axeitados para un funcionamento ao estilo dos autómatas celulares. Cando as regras son claras, locais e aplicadas de maneira consistente, os axentes poden operar de forma autónoma, igual que as células do Xogo da vida de Conway non necesitan un controlador central para producir planeadores e osciladores.

O imperativo da lectura por máquinas

A iniciativa Storybook MCP (Model Context Protocol) representa unha evolución fundamental nesta dirección. Anunciada a finais de 2025, Storybook MCP ofrece aos axentes de programación con IA metadatos de compoñentes lexibles por máquinas a partir de configuracións de Storybook xa existentes.

A clave está en que os axentes non necesitan código en bruto nin documentación visual. Necesitan:

• Manifestos de compoñentes: Metadatos estruturados de cada compoñente: as súas props, variantes, vínculos con tokens de deseño e exemplos de uso
• Nomenclatura semántica: Tokens cargados de intención, como action.primary.confirm que transmiten significado aos axentes, non só valores
• Bucles de validación: A capacidade de executar probas, ver os fallos e autocorrixirse

«Storybook MCP axuda aos axentes a seguir os teus patróns e a pasar as túas probas. Dótaos de dúas cousas que nunca tiveron: metadatos de compoñentes lexibles por máquinas e un bucle iterativo para curar por si mesmos os seus erros.»

- Equipo de Storybook

Storybook MCP inclúe un bucle de corrección autónoma. Permite que os axentes executen as probas dos teus compoñentes (de interacción e de accesibilidade), vexan o que falla e arranxen os seus propios erros. Só cómpre que unha persoa desenvolvedora intervéña cando as probas pasan. Fóra o coidado constante dos prompts.

Esta é precisamente a arquitectura dun autómata celular aplicada ao deseño: regras locais (as especificacións dos compoñentes), interaccións entre veciñas (os patróns de composición) e actualizacións iterativas (a validación e a autocorrección).

O meu manifesto de compoñente como xenoma

A comparación cos Bucles de Langton resulta aínda máis acaída cando pensamos en como funcionan os manifestos de compoñentes. No sistema de Langton, o «xenoma» codificado nas células que circulan contén as instrucións para construír un novo bucle. Nun sistema de deseño lexible por máquinas, o manifesto do compoñente contén as instrucións para montar interfaces.

Un manifesto de compoñente podería especificar:

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

Este manifesto é, á vez, unha especificación de deseño e código executable; ou, mellor dito, as instrucións a partir das cales se pode xerar código executable. O axente que consome este manifesto non precisa entender a estética nin a experiencia de usuario no sentido humano. Precisa seguir as regras, combinar os elementos segundo as súas restricións e producir resultados válidos.

Estou de acordo con Brad Frost en usar un formato yaml.

Os compoñentes de Drupal usan o formato yaml. Algo así como

$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

O deseño é o código.

• Variantes
• Tokens
• Props

• Restricións (poderiamos engadilas aos compoñentes)

• Regras dos slots (o que se pode colocar noutros slots, ou o que se permite colocar no meu slot)

• Regras

• Exemplos 

• Animacións  ( Permitido ou recomendado usar )

Despois observa e experimenta co comportamento.

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

Os design tokens como variables de contorno

Os design tokens son outra peza fundamental do crebacabezas. Nos autómatas celulares, as células reaccionan ao seu contorno inmediato: o estado das células veciñas. Nos sistemas de deseño, os compoñentes reaccionan aos design tokens: os valores contextuais que determinan o seu aspecto e o seu comportamento.

As arquitecturas de tokens modernas empregan varias capas:

• Tokens base: Valores en bruto como color.blue.500: #3B82F6
• Tokens semánticos: Referencias guiadas pola intención como color.action.primary: color.blue.500
• Tokens de compoñente: Aplicacións acotadas como button.background.primary: color.action.primary

Cando un axente xera un compoñente Button, non necesita saber que "primary" significa azul. Só precisa facer referencia a button.background.primary e confiar en que o sistema de tokens o resolverá co valor correcto. O contorno (a capa de tokens) contén a información; o compoñente (a célula) só ten que reaccionar a ela.

Ferramentas como Tokens Studio evolucionaron para tratar os design tokens como grafos computacionais con resolvedores: nodos que toman decisións semánticas sobre que tokens base usar segundo o contexto. Así os design tokens deixan de ser valores estáticos e pasan a ser sistemas dinámicos baseados en regras.

O ecosistema de Drupal e a integración da IA

A integración da IA nos sistemas de xestión de contidos é un laboratorio perfecto para explorar os principios de «o deseño é o código». CMS como Drupal xa encarnan os conceptos centrais: tipos de contido estruturados, definicións de campos, relacións e regras de composición.

Nunca pensei que poderiamos dicir algo así. Para min isto era o último grito.

 O equipo informático definitivo que poderiamos ter. Algúns desenvolvedores que parecen saídos do futuro de Star Trek, falándolle ao computador para que programe por eles.

Experiencia de axente (AX) e o novo usuario

Deseñar para máquinas

A principios de 2025, Mathias Biilmann, CEO de Netlify, presentou o concepto de «Agent Experience» (AX), unha nova disciplina centrada en como interactúan os axentes de IA cos produtos e as plataformas.

O cambio é fundamental. Durante décadas, a UX (User Experience) optimizouse para a cognición, a percepción e o comportamento humanos. A DX (Developer Experience) optimizouse para as persoas desenvolvedoras que constrúen software. A AX recoñece que os axentes se están converténdose nos usuarios principais dos sistemas dixitais, e teñen necesidades totalmente distintas:

• Non lles importa a estética visual: só datos estruturados e analizables
• Non navegan por interfaces: chaman a APIs e consomen manifestos
• Non len a documentación como as persoas: precisan contexto lexible por máquinas
• Non fan xuízos subxectivos: seguen regras e restricións

«Os axentes de IA non son persoas: non lles importa o tamaño dun botón, a lexibilidade da tipografía, a fermosa paleta de cores do teu sitio web nin as animacións chamativas da túa aplicación. Entón, que «lles importa» aos axentes de IA? É unha pregunta que hoxe non ten unha resposta concreta, pero que será cada vez máis importante nos próximos anos.»

- Investigación sobre AX

A resposta: regras claras, comportamentos previsibles, datos ben estruturados e circuítos de retroalimentación que lles permitan verificar e corrixir as súas accións.

O reto da dobre interface

Deseñar para a AX significa construír dúas interfaces á vez:

1. Interface de humano a axente: Onde as persoas supervisan, aproban, editan e orientan o comportamento dos axentes: a capa de «control de misión». Pensa en paneis de control e colas de aprobación, non en formularios e botóns.
2. Interface de axente a sistema: Onde os axentes interactúan con APIs, bases de datos e ferramentas: a capa «operativa». Debe ser robusta, estar ben documentada e estar optimizada para a eficiencia das máquinas.

Isto reflicte a arquitectura dos autómatas celulares, onde conviven dúas perspectivas distintas:

• A perspectiva local: cada cela (axente) segue regras sinxelas baseadas nas súas veciñas máis próximas
• A perspectiva global: xorden patróns complexos que só se ven a gran escala

«O deseño da experiencia de axente (AX) debe traducirse nunha gran usabilidade para os axentes e dos axentes. Por tanto, unha gran AX leva a unha gran experiencia de usuario (UX). Se o axente de IA se atopa cun proceso roto, un protocolo roto ou ata cunha redacción inconsistente entre sistemas, non pode realizar esa tarefa. Esa é unha mala experiencia para o axente que, á súa vez, leva a unha mala experiencia para o cliente ou o empregado.»

- Kat Holmes, directora de Experiencia (Chief Experience Officer), Salesforce

Da UX á AX: a evolución do deseño dixital

Estigmergia e comunicación indirecta

Un dos conceptos máis potentes da intelixencia de enxame é a estigmergia: a coordinación indirecta mediante rastros no ambiente. As formigas non se comunican directamente sobre onde hai comida; deixan rastros de feromonas que as demais seguen. O ambiente convértese nun medio de comunicación.

Nos sistemas de deseño axénticos, a estigmergia toma a forma de:

• Bibliotecas de compoñentes compartidas: os axentes «ven» que compoñentes existen e como se usaron
• Tokens de deseño: valores semánticos que codifican as decisións de deseño como feitos do ambiente
• Documentación de patróns: exemplos de uso que funcionan como rastros de feromonas para os axentes futuros
• Conxuntos de probas: regras de validación que acoutan o espazo de saídas válidas
• Historial de Git: un rexistro de decisións pasadas ao que os axentes poden recorrer

Cando un axente xera unha interface de usuario usando un compoñente, deixa rastros: no código, na documentación, nos patróns que establece. Os axentes futuros que se atopen con tarefas semellantes verán a súa conduta influída por eses rastros, o que crea unha forma de intelixencia colectiva que ningún axente individual posúe.

Patróns de deseño axénticos

Andrew Ng e outros identificaron catro patróns clave para os sistemas de IA axénticos:

1. Reflexión: a IA avalía a súa propia saída e mellóraa de forma iterativa
2. Uso de ferramentas: a IA interactúa con ferramentas, APIs e sistemas externos
3. Planificación:A IA divide as tarefas complexas en subtarefas e execútaas de forma secuencial
4. Multiagente: Varios axentes especializados colaboran en tarefas complexas

Estes patróns correspóndense directamente cos conceptos dos autómatas celulares:

O deseño é o código: unha lectura máis profunda

Que significa de verdade «o deseño é o código»

Cando dicimos «o deseño é o código», estamos afirmando varias cousas á vez:

1. Equivalencia semántica

As decisións de deseño, cando se codifican como se debe, volvense executables. Un token de deseño non é só un valor: é unha instrución. A especificación dun compoñente non é só documentación: é un programa. Cando os axentes consomen estes artefactos, están executando o deseño tanto como o están implementando.

2. Capacidade xerativa

Do mesmo xeito que a Regra 110 pode calcular todo o que é calculable, un sistema de deseño suficientemente completo pode xerar calquera interface válida. O sistema contén o potencial de todas as súas expresións válidas. O que xurde depende só das condicións iniciais (os requisitos) e das regras (as restricións).

3. Complexidade emerxente

As interfaces máis sofisticadas non se deseñan de arriba abaixo; xorden da aplicación coherente de regras sinxelas. Un botón ben deseñado, usado con coherencia, produce unha linguaxe visual cohesionada sen que ninguén planifique esa coherencia de maneira explícita.

4. Irredutibilidade computacional

Algúns resultados de deseño non se poden predicir sen executar de verdade o sistema. Non podes saber como será unha interface montada por un axente sen deixar que o axente a monte. Este é o principio de irredutibilidade computacional de Wolfram aplicado ao deseño.

5. Automodificación

Coma os evoloops, que mutan durante a replicación, os sistemas de deseño preparados para axentes poden evolucionar co uso. Os compoñentes xerados polos axentes pasan a formar parte da biblioteca que consumirán os axentes futuros. O sistema aprende, adáptase e medra.

A metáfora dos autómatas celulares, ampliada

Máis alá da metáfora: unha converxencia real

Pero isto non é só unha metáfora. A converxencia é real e está a suceder agora mesmo:

• Storybook MCP converte as bibliotecas de compoñentes en instrucións lexibles por máquina que os axentes executan
• Model Context Protocol estandariza o modo en que os axentes acceden ás ferramentas e ao contexto, e crea un substrato universal para as operacións axénticas
• As arquitecturas multiagente reparten o traballo entre axentes especializados (arquitecto, programador, revisor) que interactúan segundo protocolos, coma celas con funcións diferenciadas
• Bucles de autocuraciónPermiten que os axentes executen probas, detecten erros e iteren: os mesmos mecanismos de retroalimentación que usan os autómatas celulares para evolucionar cara a configuracións estables
• Schema.org Blueprints fan que as estruturas de contido sexan lexibles por máquinas e semanticamente significativas
• Drupal AI achegan a infraestrutura para que os axentes de IA creen, modifiquen e xestionen contido de forma autónoma

Non entendemos «o deseño é o código» como unha postura filosófica. Estámolo construíndo como infraestrutura técnica.

Implicacións e camiño por diante

Para deseñadores

O papel do deseñador está pasando de «creador de rectángulos» a «definidor de regras». Como observou Brad Frost:

«Os deseñadores e desenvolvedores que entenden o seu traballo como crear rectángulos teñen moito de que preocuparse. Pero os que entenden o seu traballo como resolver problemas —e, de paso, teñen que crear ou manexar algúns rectángulos para resolvelos— teñen menos que temer.»

- Brad Frost

No futuro dos axentes, os deseñadores:

• Definirán tokens semánticos e as súas relacións
• Establecerán restricións de composición e patróns
• Crearán regras de validación que os axentes deberán cumprir
• Coidarán e farán evolucionar as regras que gobernan a emerxencia
• Deseñarán os mecanismos de retroalimentación que permiten a autocorrección
• Daranlle forma ás «funcións de aptitude» que determinan que resultados son aceptables

Isto é deseño nun nivel de abstracción máis alto: deseñar as regras que producen deseños, e non os deseños mesmos. Como definir as regras dun autómata celular en lugar de debuxar cada cela por separado.

Para desenvolvedores

Os desenvolvedores pasan a ser arquitectos de sistemas de axentes. Como describe Anthropic:

«O ámbito do desenvolvemento de software demostrou un potencial notable para as funcións baseadas en LLM, con capacidades que evolucionaron desde a autocompletación de código ata a resolución autónoma de problemas.»

Os desenvolvedores terán que:

• Crear interfaces lexibles por máquinas entre axentes e sistemas
• Deseñar bucles de retroalimentación e mecanismos de validación
• Construír o andamiaxe dentro do cal ocorre o comportamento emerxente
• Manter a supervisión humana como árbitro final
• Definir os protocolos mediante os cales se comunican os axentes
• Implementar o «código de unión» que conecta os distintos sistemas de axentes

Para o desenvolvemento web e as plataformas CMS

A integración da IA en plataformas como Drupal apunta a un futuro no que:

• Os modelos de contido serán consumibles polos axentes grazas a estándares como Schema.org
• Os fluxos editoriais contarán coa axuda de axentes con redacción, moderación e optimización impulsadas pola IA
• A busca evoluciona da coincidencia de palabras clave á comprensión semántica mediante embeddings e bases de datos vectoriais
• A personalización faise autónoma con axentes que aprenden as preferencias das persoas usuarias e adaptan o contido en tempo real
• O desenvolvemento acelérase mentres os axentes xeran compoñentes, probas e documentación

A aposta do ecosistema de Drupal pola IA —a través de módulos como Drupal AI, Drupal Canvas, Schema.org Blueprints e a integración de provedores de IA— demostra que este futuro xa se está construíndo.

Para organizacións

A vantaxe competitiva será das organizacións cuxos sistemas de deseño estean máis «preparados para axentes». Os sistemas preparados para axentes teñen:

• Cobertura completa dos estados e variantes dos compoñentes
• Nomenclatura semántica que transmite a intención
• Documentación e contexto lexibles por máquinas
• Infraestrutura de validación e probas
• Restricións claras que delimitan o espazo de saídas válidas
• APIs deseñadas para o consumo por parte dos axentes (AX-first)
• Arquitecturas de contido baseadas primeiro en Schema.org

Para o futuro dos produtos dixitais

O estado final é algo así como unha ecoloxía dixital: incontables axentes que operan segundo regras locais e producen interfaces emerxentes que ningún deseñador nin desenvolvedor planificou, pero que dalgún xeito resultan coherentes porque as regras de fondo son sólidas.

Isto non é tan inverosímil como soa. É xusto así como funcionan os sistemas biolóxicos, como medran as cidades, como funcionan os mercados. A pregunta non é se chegaremos a este estado, senón como transitaremos ata el.

Conclusión: o código está vivo

John von Neumann, o polímata que inventou os autómatas celulares, movíase por unha pregunta fundamental: cal é a complexidade mínima necesaria para a autorreprodución? A súa resposta, o construtor universal de von Neumann, demostrou que a autorreplicación non precisa de maquinaria biolóxica. Só precisa de regras que codifiquen a súa propia aplicación.

Setenta anos despois, descubrimos que o mesmo principio vale para os sistemas de deseño. O requisito mínimo para a xeración autónoma de interfaces non é a intelixencia xeral artificial nin a creatividade a nivel humano. É un conxunto de regras completo, coherente e lexible por máquinas que os axentes poidan executar.

Cando os Langton's Loops se replican por unha grella celular, non dicimos que os lazos estean "deseñando" lazos novos. A replicación é simplemente o que producen as regras. Con todo, o resultado, colonias en expansión constante de patróns autosemellantes, é innegablemente xerativo, creativo nalgún sentido funcional.

Cando os axentes de IA montan interfaces a partir de compoñentes do sistema de deseño, seguindo tokens semánticos e restricións de composición, fan algo semellante. A "creatividade" non reside nos axentes, senón nas regras que executan: regras que deseñaron persoas, pero que agora funcionan de maneira autónoma.

Estamos no limiar dunha nova era da creación dixital. Os axentes xa están aquí. Os protocolos están collendo forma. Os sistemas de deseño están a converterse en substratos para a vida artificial.

O deseño é o código.
E o código está a cobrar vida.

Artigos e proxectos clave

• 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

Recursos de Drupal AI

• Drupal AI

• Schema.org Blueprints Module

   

Recursos sobre autómatas celulares

• Conway's Game of Life Lexicon - Preto de 1500 figuras
• 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

Exploración de ideas na intersección entre a teoría computacional, os sistemas de deseño, a intelixencia artificial e o desenvolvemento web.

 As opinións expresadas son exploracións especulativas de tendencias emerxentes, non predicións de futuros seguros.

Vexo que estamos a crear axentes de IA que traballan nun bucle e interactúan con outros axentes de IA noutros bucles adicionais.

O deseño é o código cando o sistema funciona nun bucle, como un bucle de vida, dentro dun lenzo e dun conxunto de regras escollidos.