BrickForge: de AFOL a diseñadora, con Claude como un socio al que tengo que verificar

Llevo años armando LEGO: cientos de sets, miles de pasos y buen olfato para saber qué técnicas aguantan y cuáles no. Pero siempre he armado el diseño de otra persona. Ahora quiero diseñar mis propios modelos, y quise a Claude como socio de diseño desde el primer día.

Mi experiencia armando detectó el primer problema rápido: los modelos de lenguaje hablan con mucha seguridad de piezas LEGO que no existen. Un número de pieza creíble, un color en el que la pieza nunca se fabricó, una pieza que casi es la correcta. Cualquier AFOL detectaría algunas. Otras parecen correctas hasta que intentas comprar la pieza. Así que BrickForge dejó de tratarse de que la IA diseñe, y pasó a tratarse de montar un flujo de trabajo donde cada afirmación se verifica.

Paso uno: un catálogo que mantiene honesto a Claude

BrickForge es un proyecto de Claude conectado a un servidor MCP que construí: un catálogo LEGO sobre los datos públicos de Rebrickable. Tiene seis herramientas de solo lectura. Buscan piezas, consultan una pieza, listan colores, devuelven el inventario de un set, decodifican IDs de elemento e informan qué tan antiguos son los datos. Cada respuesta incluye su fuente y la fecha de la copia de datos.

Una de las primeras hojas de concepto nombraba tres piezas. Verificarlas tomó segundos:

• Parabrisas 2 x 10 x 3 (24607) existe en Trans-Clear, pero aparece en solo 13 sets. Es válida, pero puede ser difícil de conseguir.
• Cono 2 x 2 x 2 (3942c) viene en 42 colores. Nunca se ha fabricado en Trans-Orange.
• Placa redonda 1 x 1 (6141) en Trans-Orange es común: aparece en 659 sets.

Ese conteo de sets es una señal barata de rareza. Como constructora, sé que algunas piezas son difíciles de encontrar. Lo nuevo es tener un número antes de comprometer un diseño con esa pieza.

Lo que un catálogo no puede hacer

Un catálogo sabe qué existe, no cómo encaja. No tiene geometría, ni conexiones, ni física. Así que salí a buscar una capa de diseño, y puse a dos agentes de IA especialistas a revisar las opciones, uno enfocado en estrategia y otro en arquitectura. Cada uno tenía que etiquetar cada afirmación externa como verificada, con su fuente, o no verificada.

Encontraron problemas reales:

• Una herramienta de la comunidad que deja a Claude colocar ladrillos solo rota piezas en pasos de 90° y solo verifica conexiones a través de los studs de arriba. No puede con SNOT, del que depende cada modelo serio que he armado. Su ficha en el directorio no lo decía. El código fuente sí.
• Los términos de LEGO Ideas, en la versión revisada, restringen las propuestas hechas con ayuda de IA. Mis modelos son proyectos personales de todos modos, pero vale la pena saberlo antes de compartir un diseño.

Descartar las herramientas existentes no significaba que una capa de diseño fuera imposible. Significaba que tendría que construir una.

La pieza que faltaba: datos de conexión

Lo difícil de una herramienta de diseño LEGO es saber cómo se conectan las piezas en cualquier orientación: studs, anti-studs, studs laterales, clips, agujeros Technic. Esos datos existen en LDCad Shadow Library, un proyecto de la comunidad que agrega puntos de conexión (posición, dirección, forma) a la biblioteca de piezas LDraw.

La revisión de arquitectura los midió contra inventarios reales de sets: el 95,8% de las piezas que de verdad se usan en sets tiene datos de conexión. Ladrillos, placas, tiles, brackets y ladrillos con studs laterales están cubiertos entre 96 y 100%. Los huecos son ruedas, figuras grandes y Duplo, y una primera versión puede vivir sin ellos.

El diseño de la solución

La idea clave: Claude nunca hace cuentas 3D. Decide qué se conecta con qué ("el anti-stud de este bracket sobre el stud de esa pared"), y un servidor calcula la posición, verifica el encaje y rechaza las colisiones. Los modelos de lenguaje son buenos eligiendo. No son confiables con matrices de rotación.

• Mi PC
  • Claude Desktop (BrickForge)
  • ↓Luego: llama a las herramientas
  • MCP de capa de diseño (nuevo, local)
    • Herramientasplace_part, attach_part, open_connectors, check_model, export_ldraw
    • MotorEncaje de conectores, posición y rotación (SNOT), colisiones, piezas flotantes, estado del modelo
    • DatosGeometría LDraw + puntos de conexión LDCad
  • ↓Luego: exporta .mpd (en un solo sentido)
  • BrickLink Studio
    • El modelo maestro, estabilidad, instrucciones, renders
• ↓Luego: pregunta "¿existe esta pieza en este color?"
• Nube
  • MCP de catálogo (Rebrickable)
    • Legalidad, rareza, sets

Un intercambio típico: pido un panel de tiles montado de lado sobre una pared. Claude le pregunta al servidor qué studs laterales están libres, engancha un bracket a uno, engancha los tiles al bracket y corre una verificación: nada flotando, nada chocando. Luego exporta un archivo de subensamble que importo en Studio, donde reviso la estabilidad.

Tres decisiones que tomé a propósito:

• Un solo archivo maestro. El modelo de Studio es la fuente de verdad. Los subensambles de Claude fluyen hacia él, nunca de vuelta.
• Dos servidores, dos trabajos. El servidor local se encarga de la geometría y los modelos. El catálogo en la nube se encarga de "¿esto es LEGO de verdad?". Ninguno duplica al otro.
• Local, no en la nube. Armar un modelo implica mantener el estado a lo largo de muchos pasos, y solo la geometría de las piezas pesa unos 279 MB. Corre en mi PC, en Claude Desktop.

Cómo sabré que funciona

Nada se construye por fe. El plan tiene fases, y cada una tiene una prueba que debe pasar:

1. Primero validar el verificador, contra conexiones reales conocidas, antes de que Claude lo toque. Si no, estaría calificando a Claude con una regla que nadie ha probado.
2. Después probar a Claude en tres armados pequeños: una pared escalonada, un panel de lado y un detalle SNOT desplazado. Cinco intentos de cada uno, calificados contra referencias que armo a mano, y comparados con Claude trabajando sin las herramientas. Si las herramientas no superan esa línea base, me detengo. La capa no se está ganando su lugar.
3. Solo entonces agregar clips, bisagras, Technic y la verificación de legalidad contra el catálogo.

Lo que he aprendido hasta ahora

• Un MCP es una capa de hechos, no un diseñador. Su valor es que hace verificables las afirmaciones de la IA.
• Lee el código, no la ficha. La descripción de una herramienta dice lo que espera hacer. El código dice lo que de verdad verifica.
• "Esas herramientas no sirven" no es "no se puede hacer". Pregunta cuál es la parte difícil y luego busca los datos.
• La experiencia armando es el verdadero validador. La IA acelera el camino hacia un modelo que vale la pena probar. Mis manos siguen decidiendo si aguanta.

Lo que sigue

Fase 0: construir los datos de conexión y demostrar que el verificador funciona. Escribiré sobre si Claude pasa su prueba, incluso si no la pasa.

---

Datos: Rebrickable. Datos de conexión: LDCad Shadow Library (CC BY-SA 4.0). Geometría de piezas: LDraw.org (CC BY). LEGO® es una marca registrada del Grupo LEGO, que no patrocina ni respalda este proyecto.