Imagina esta escena: una diseñadora trabaja en un prototipo generado en código real que usa fuentes de datos. No es programadora, pero puede producir vistas consistentes con el Design System, sostener los principios de experiencia del producto y mostrar una idea con suficiente fidelidad para discutirla con negocio y desarrollo.
O esta otra: un líder de diseño define un flujo para validar si ciertas vistas cumplen con el Design System. El equipo y PM pueden correr un skill /valida-diseño que revisa reglas visuales, uso de tokens, accesibilidad y alineación con definiciones de usuario obtenidas en investigación.
Ambas escenas siguen siendo diseño. No porque la IA “diseñe sola”, sino porque amplía el tipo de materiales sobre los que diseño puede trabajar. Ya no hablamos sólo de pantallas estáticas, sino de prototipos, reglas, criterios, documentación, datos, evidencia y herramientas propias.
Sin embargo, cuando escuchamos hablar de Codex o Claude Code, lo más probable es que pensemos en programación.
Tiene sentido. Son herramientas que nacieron o se hicieron visibles dentro del trabajo de desarrollo: leer y explicar un repo, modificar archivos, ejecutar comandos, revisar errores, generar cambios, crear código, abrir un pull request o sostener una tarea larga con contexto técnico.
Pero quedarnos en esa idea, agentes como herramientas de desarrollo, deja fuera una parte importante del problema.
Muchas tareas de diseño ya no ocurren sólo dentro de una pantalla de Figma ni sólo dentro de una conversación con ChatGPT o Claude. Cada vez más, el trabajo se reparte entre sistemas de diseño, research, criterios de UX, prototipos tempranos, herramientas visuales asistidas por IA, código de prueba, notas de decisión y materiales que cambian mientras el equipo piensa.
Tampoco se trata de que diseñadores y diseñadoras deban convertirse en programadores.
La pregunta es qué posibilidades aparecen para diseño cuando podemos dirigir herramientas capaces de leer contexto, operar sobre archivos, modificar artefactos y sostener un flujo de trabajo más largo que una conversación.
Ahí Codex y Claude Code se vuelven interesantes.
No porque conviertan al diseñador en developer o porque todo prototipo tenga que terminar en código. Tampoco porque la solución sea mover el proceso de diseño a la terminal.
De hecho, no me refiero necesariamente a las versiones CLI (de terminal de comandos) de estas herramientas. También importa lo que está ocurriendo en versiones de escritorio, entornos con GUI y herramientas más cercanas al trabajo visual.
Lo interesante es otra cosa: permiten pensar una forma distinta de trabajar con IA, menos centrada en pedir respuestas y más centrada en diseñar condiciones de trabajo.
La diferencia no está en el prompt, sino en el entorno de trabajo
Durante mucho tiempo, la forma más común de usar IA en diseño fue conversacional.
Abrir un chat. Explicar el contexto. Pedir alternativas. Copiar una respuesta. Ajustar. Volver a explicar. Pedir una revisión. Recuperar manualmente lo que ya se había dicho.
Ese modo sigue siendo útil para pensar rápido, explorar una idea, probar una formulación o desbloquear una tarea.
El problema aparece cuando el trabajo deja de ser una consulta puntual y empieza a parecerse a un proceso.
Un equipo no sólo quiere “ideas para mejorar onboarding”. Quiere comparar alternativas, revisar consistencia con criterios de UX, mantener decisiones tomadas, generar un prototipo temprano, detectar problemas de accesibilidad, ajustar copy funcional, documentar supuestos y conservar evidencia de research para la siguiente iteración.
En ese punto, la conversación deja de alcanzar por sí sola.
Empiezan a importar cosas que en un chat suelen quedar frágiles: qué contexto está disponible, qué reglas aplican, qué materiales puede tocar la IA, cuándo debe pedir permiso y cómo se revisa lo que produce.
Codex y Claude Code importan porque obligan a mirar esa capa. No trabajan sólo con una instrucción suelta. Trabajan con un espacio: archivos, carpetas, reglas, memoria, documentos y artefactos.
Ese espacio puede ser un repo. Pero también puede ser una carpeta de prototipos, documentación de un producto, un set de notas de research, una librería de criterios, una colección de prompts convertidos en skills o un proyecto híbrido donde diseño, contenido y desarrollo se cruzan.
La pregunta de diseño es qué condiciones necesita ese espacio para que un agente pueda aportar sin desordenar el trabajo.
Para diseño, el primer caso fuerte es el prototipo temprano
El uso más obvio de Codex y Claude Code es producir o modificar código. Pero para diseño, el caso más interesante no siempre es “programar una aplicación”. Muchas veces es construir prototipos tempranos con suficiente estructura para pensar mejor.
Un prototipo temprano no tiene que ser producción, perfecto ni representativo de todo el sistema. Puede servir para probar una hipótesis de interacción, explorar un flujo, comparar estados, simular una experiencia o descubrir decisiones que quedan ocultas cuando todo vive en un documento.
Ahí una herramienta agéntica puede ayudar de varias formas.
Puede convertir un brief en una primera superficie interactiva, generar variantes de un flujo, incorporar estados vacíos o errores que suelen quedar fuera de la maqueta inicial, transformar criterios de UX en una pauta de revisión o documentar los supuestos que quedaron embebidos en el prototipo.
Lo importante no es que el agente “diseñe solo”, sino que pueda sostener trabajo operativo alrededor del diseño, siempre que el diseñador haya definido el marco.
Herramientas como Claude Design u Open Design apuntan precisamente a ese punto de encuentro: espacios donde el artefacto visual, el prototipo y la asistencia del modelo empiezan a convivir. En ese escenario, Codex y Claude Code no son necesariamente el destino final del trabajo, pero sí ayudan a entender una capacidad nueva: diseñar flujos donde modelos y herramientas operan sobre materiales concretos.
El valor no está en reemplazar Figma, el research o la crítica de diseño. Está en conectar mejor esas piezas.
El problema no es que el agente pueda actuar. Es bajo qué reglas actúa
Cuando una herramienta puede modificar archivos, ejecutar pasos o sostener tareas largas, aparece una ventaja evidente: puede avanzar más.
Pero también aparece un riesgo: puede avanzar mal.
Ese riesgo es muy visible en proyectos de diseño y conocimiento, como un curso, un artículo o un reporte. Un agente afinado para entornos de desarrollo tiende a hacer lo que ese entorno premia: ejecutar, editar, normalizar, completar, reorganizar, dejar todo “limpio”. Si puede modificar algo, muchas veces asume que debe hacerlo.
En diseño, esa inercia es riesgosa.
Hay momentos donde ejecutar rápido ayuda. Pero hay otros donde el trabajo correcto es leer, comparar, hacer una pregunta, conservar una ambigüedad o no cerrar todavía una decisión. A veces conviene no tocar una nota, no convertir una exploración en plan operativo o no reescribir una formulación que tenía textura.
Por eso, trabajar con agentes en diseño no empieza por darles más autonomía: empieza por diseñar sus límites.
Qué pueden leer. Qué pueden cambiar. Qué deben preguntar. Qué tipo de salida deben dejar. Qué decisiones son reversibles. Qué criterios son persistentes. Qué parte del trabajo exige revisión humana. Qué diferencia hay entre un proyecto de código, un proyecto híbrido y un proyecto de conocimiento.
Ése es el rol del scaffolding: dar una estructura común de trabajo sin convertirla en receta universal ni en burocracia.
Un setup posible: documentos como contratos de colaboración
En mi propio trabajo empecé a consolidar un setup para proyectos con agentes. Tiene archivos con nombres poco glamorosos: AGENTS.md, MEMORY.md, PLAN.md, HANDOFF.md, UX.md, DESIGN.md, FRONTEND.md, SOURCES.md.
Una versión simplificada de esa estructura se ve así:
proyecto/
├── AGENTS.md reglas estables para agentes
├── MEMORY.md decisiones y aprendizajes persistentes
├── PLAN.md tareas vivas en repos o workspaces
├── HANDOFF.md continuidad entre agentes en proyectos de conocimiento
├── UX.md comportamiento, flujos, estados y copy funcional
├── DESIGN.md sistema visual, marca, tokens y assets
├── FRONTEND.md implementación, componentes, rutas y QA
└── SOURCES.md fuentes y grounding cuando hace falta
Visto desde fuera, puede parecer documentación técnica. Pero la función más interesante no es técnica. Es colaborativa.
Uso más de un agente para distintas tareas y voy combinando disponibilidad de tokens, capacidades y estilos de trabajo. Codex me responde bien en tareas operativas, pero también en ideación y pensamiento. Claude Code me sirve mucho para arquitectura, desarrollo de ideas y revisión del trabajo de otros agentes. OpenCode con GLM entra en tareas operativas, planificación y continuidad. En algunos proyectos participan todos en momentos distintos.
Cuando eso pasa, no basta con confiar en que cada agente “entienda el contexto”. Hay que dejar contratos mínimos para que sepan cómo trabajar.
Cada archivo responde una pregunta distinta sobre cómo debe actuar un agente dentro de un proyecto.
AGENTS.md define las reglas estables: qué leer al comenzar, qué no hacer sin permiso, cómo coordinarse con otros agentes, qué jerarquía documental respetar, qué límites no debe cruzar.
MEMORY.md guarda aprendizajes persistentes: decisiones, invariantes y criterios que deberían informar acciones futuras. No es un diario ni un resumen infinito. Es memoria operativa: aquello que cambia cómo conviene actuar la próxima vez.
PLAN.md sirve cuando el proyecto vive en un repo o workspace donde hay tareas asignables a agentes. Ahí funciona como tablero vivo: qué está pendiente, qué está bloqueado, qué se validó y qué queda para otro agente.
HANDOFF.md cumple otra función en proyectos de conocimiento. Si el proyecto vive en Obsidian, por ejemplo, no quiero saturar el índice con cada paso operativo. El índice debe orientar el proyecto. El handoff debe permitir continuidad.
UX.md, DESIGN.md y FRONTEND.md separan tres preguntas que suelen mezclarse: cómo se comporta la experiencia, cómo se ve y cómo se implementa.
Esa separación importa mucho en diseño.
Porque si todo vive en una sola instrucción, el agente mezcla niveles. Puede tratar una decisión visual como si fuera comportamiento, resolver un problema de UX con una preferencia estética o modificar una interfaz sin entender qué parte era contrato de experiencia, sistema visual o restricción técnica.
Los documentos no existen para ordenar el proyecto por deporte. Existen para que el agente no confunda el tipo de decisión que está tomando.
No todos los proyectos necesitan la misma forma de trabajo
Una de las decisiones más importantes de este setup es separar tipos de proyecto.
Un repo de código no se trabaja igual que un proyecto de conocimiento. Un proyecto híbrido no se trabaja igual que una carpeta de research. Un prototipo temprano no exige el mismo nivel de estabilidad que un producto en producción. Una nota de curso no debería tratarse como un archivo de aplicación.
Esto parece obvio, pero los agentes suelen borrar esa diferencia si no se les explicita.
En un repo, tiene sentido que el agente lea archivos, proponga cambios, ejecute tests, revise errores, actualice un plan y deje un commit. Ahí la acción es parte natural del trabajo.
En un proyecto de conocimiento, como un curso, un framework o una investigación, la lógica debería ser distinta. Ahí muchas veces el valor está en pensar antes de ordenar: comparar antes de escribir, proponer antes de mover, preguntar antes de reorganizar y conservar matices antes de cerrar una estructura prematura.
En un proyecto híbrido, el problema se vuelve más interesante. Puede existir un repo donde se implementa una herramienta y una contraparte en Obsidian donde vive la investigación, la planificación, las decisiones largas y la documentación del proceso. Si el agente no entiende esa división, termina poniendo planificación conceptual en el repo o tareas ejecutables en una nota que debía servir para pensar.
Esto también aplica a diseño.
Si estoy trabajando en un prototipo temprano, quiero que el agente pueda tocar artefactos exploratorios, pero no quiero que trate cada cambio como una decisión final de producto. Si estoy trabajando en un sistema de diseño, quiero consistencia y trazabilidad. Si estoy trabajando en research, quiero evidencia y cuidado con la interpretación. Si estoy trabajando en contenido o documentación, quiero preservar voz, contexto y decisiones editoriales.
El tipo de proyecto define qué significa ayudar bien.
El criterio de diseño se vuelve infraestructura
Hay una frase que resume buena parte de este cambio: los agentes hacen visible el criterio que antes quedaba implícito.
Cuando una persona diseñadora trabaja sola o en equipo, muchas decisiones viven en conversaciones, experiencia acumulada, intuiciones compartidas, referencias, comentarios de revisión y memoria informal. Eso puede funcionar mientras el contexto está fresco y las mismas personas están presentes.
Pero un agente no comparte esa historia de manera natural.
Si el criterio no está escrito, el agente lo inventa, lo aproxima o lo reemplaza por patrones genéricos.
Por eso trabajar con agentes obliga a una operación que diseño ya conoce, pero a veces posterga: explicitar criterios.
¿Qué cuenta como una buena variante? ¿Qué estados debe contemplar un flujo? ¿Qué tono debe tener el copy funcional? ¿Qué decisiones visuales pertenecen a marca y cuáles son sólo composición local? ¿Qué hallazgos de research son evidencia y cuáles son interpretación? ¿Qué debe pasar cuando la información no alcanza? ¿Cuándo una recomendación necesita revisión humana?
Estas preguntas no son accesorias. Son parte del diseño del sistema de trabajo.
Cuando están explicitadas, Codex o Claude Code pueden ayudar a aplicarlas, revisarlas, tensionarlas y convertirlas en acciones. Cuando no lo están, el agente produce algo que puede parecer correcto, pero que no necesariamente responde al criterio del equipo.
En ese sentido, los documentos del setup no son documentación para después. Son parte del material de diseño.
Una regla pequeña que muestra el problema completo
Un ejemplo mínimo: la inercia ASCII.
Si has trabajado con herramientas de desarrollo, asumes que son entornos donde lo ASCII parece más seguro: nombres sin tildes, textos sin eñes, rutas simplificadas, convenciones pensadas para evitar problemas técnicos.
Eso puede tener sentido en ciertos archivos o comandos. Pero cuando el trabajo es documentación en español, notas de conocimiento, piezas editoriales o materiales de curso, esa inercia deja de ser una precaución técnica y se convierte en pérdida de calidad.
Si el agente omite tildes en palabras como “diseño”, “acción” o “documentación” por reflejo, no está cometiendo sólo un error ortográfico. Está trasladando una norma de un entorno técnico a un contexto cultural y editorial donde no corresponde.
La solución no es dramática. Basta con una regla explícita: “en documentación en español, especialmente en proyectos de conocimiento, no usar ASCII por inercia; conservar tildes, eñes y puntuación correcta”.
Pero el ejemplo muestra algo más grande.
Los agentes heredan hábitos del entorno en el que operan: si el proyecto no declara qué importa, el agente optimiza para señales equivocadas.
Eso vale para la ortografía, pero también para la experiencia de usuario, el tono de una marca, la evidencia de research, la fidelidad visual de un prototipo o la forma correcta de dejar una decisión abierta.
Qué puede hacer un equipo de diseño con esto
La aplicación práctica no es “crear muchos archivos Markdown”. Esa es una solución puntual y poco sostenible.
La aplicación práctica es diseñar mejores condiciones para que un agente participe en trabajos concretos de diseño.
Un equipo puede usar un agente para explorar variantes de un flujo de onboarding, pero darle un UX.md con principios de comportamiento, estados obligatorios y criterios de error. Puede pedirle que genere un prototipo temprano y exigir que documente qué supuestos tomó. Puede usarlo para revisar una interfaz con evidencia por hallazgo, separando usabilidad, accesibilidad, lenguaje y consistencia visual. También puede trabajar con research, pero pidiéndole que distinga dato, interpretación e implicancia.
Sobre esa base, el equipo puede crear skills más específicos: uno para revisar voz y tono, otro para detectar problemas de accesibilidad, otro para transformar entrevistas en patrones, otro para comparar una pantalla contra un sistema de diseño o preparar un handoff de producto.
Después puede coordinar esos skills en un flujo.
No para que el agente tenga la última palabra, sino para que el equipo llegue mejor preparado a decidir. Y ese matiz es clave.
El valor no está en sacar al diseñador del proceso: está en sacar fricción operativa del camino para que el diseñador pueda concentrarse en criterio, interpretación y decisión.
Codex y Claude Code como herramientas de diseño indirecto
Quizá la forma más útil de pensarlo es esta: Codex y Claude Code no son herramientas de diseño en el sentido tradicional, pero pueden funcionar como herramientas de diseño indirecto.
No reemplazan una herramienta visual. No sustituyen una conversación con usuarios. No entienden por sí mismas la estrategia del producto. No garantizan buen gusto, pertinencia ni impacto.
Pero pueden ayudar a construir el andamiaje alrededor del trabajo de diseño.
Pueden preparar prototipos, sostener documentación viva, convertir criterios en evaluadores, recorrer archivos, detectar inconsistencias, producir versiones exploratorias, dejar rastros de decisiones y operar con memoria local del proyecto.
Y, sobre todo, obligan a hacer una pregunta necesaria:
¿Mi proceso de diseño está suficientemente definido como para que alguien más pueda seguirlo sin que yo lo explique todo de nuevo?
Si la respuesta es no, el problema no es del agente.
El agente sólo está mostrando que una parte del criterio todavía vive de manera tácita.
Esto no reemplaza el oficio de diseño. Lo exige más
Hay una tentación frecuente cuando aparece una herramienta nueva: imaginar que la herramienta reduce la necesidad de criterio.
Con agentes ocurre lo contrario.
Mientras más capacidad de acción tiene una herramienta, más importante se vuelve definir qué no debería hacer. Mientras más archivos puede tocar, más necesario es saber qué debe preservar. Mientras más rápido puede producir variantes, más importante es tener criterios para evaluarlas. Mientras más fácil es generar prototipos, más urgente es distinguir exploración, validación y decisión.
Trabajar con Codex y Claude Code en diseño no elimina el oficio. Por el contrario, lo vuelve más explícito.
Eso puede exigir más trabajo al comienzo: escribir reglas, nombrar supuestos, separar tipos de decisiones, definir límites y aceptar que parte del trabajo que antes parecía intuición también puede describirse como criterio operativo.
Pero cuando el criterio se vuelve explícito, deja de depender sólo de la memoria de una persona. Puede compartirse, revisarse, discutirse, probarse y convertirse en una herramienta.
Ahí está el cambio de fondo.
No en usar agentes para hacer más de lo mismo más rápido.
Se trata de aprender a diseñar sistemas de trabajo donde humanos, modelos y herramientas colaboran sin confundir sus responsabilidades.
Qué trabajamos en Agentes y Skills para Diseño
Este es uno de los temas que atraviesa el curso Agentes y Skills para Diseño.
No como tutorial de Codex o Claude Code. Tampoco como promesa de que todo diseñador debe trabajar en una terminal o que todo se resuelve en estas herramientas.
El curso parte de una pregunta más amplia: cómo puede un diseñador construir sus propias herramientas de IA para resolver problemas reales de su proceso.
Eso incluye instrucciones persistentes, skills, agentes, patrones multiagente y flujos conectados. Pero el centro no es la herramienta. El centro es el diseño del sistema de trabajo: qué tarea vale la pena sistematizar, qué criterio debe quedar explícito, qué materiales necesita el agente, qué límites debe respetar, qué salida ayuda a decidir y qué parte debe seguir en manos humanas.
Codex y Claude Code son parte de ese mapa porque muestran una capacidad que ya no pertenece sólo al desarrollo: trabajar con IA sobre un entorno completo, no sólo dentro de una conversación.
Para diseño, eso abre un campo amplio: prototipos tempranos, herramientas propias, evaluadores, documentación viva, research asistido, revisión de interfaces, auditorías de experiencia, handoffs más claros y skills que capturan criterio del equipo.
Pero todo eso requiere una condición previa: dejar de pensar la IA como una respuesta suelta y empezar a diseñar el espacio donde trabaja.
Ése es el salto importante.
No pasar de diseñador a programador.
Pasar de usuario de herramientas a diseñador de condiciones de trabajo.
