Rediseñando WPML con Claude Code — y lo que estoy aprendiendo sobre la construcción con IA

Soy el fundador de OnTheGoSystems. Esta semana he estado rediseñando personalmente la interfaz de usuario de administración de WPML, nuestro producto más grande. No gestionando el proyecto. No revisando el trabajo de otra persona. Sentado con Claude Code y haciendo el trabajo de diseño real yo mismo.

Dos razones.

Primero, una administración más limpia e intuitiva es lo principal que nuestros clientes nos piden que arreglemos. Durante años nos han dicho que WPML tiene demasiadas pantallas, que los ajustes están repartidos en áreas no relacionadas, que las funciones importantes son difíciles de encontrar. Cuando algo es tan importante para los clientes, quiero liderarlo con mis propias manos, no desde la distancia.

Segundo, quería aprender de primera mano cómo es hoy en día construir un producto real con IA. No lo que muestran las demostraciones. No lo que afirman los líderes de opinión. Trabajo de producto real, en una base de código que los clientes reales verán, con todo el desorden que ello conlleva. Prefiero descubrir lo que funciona haciendo el trabajo yo mismo que que alguien me lo informe.

Lo que encontré me sorprendió en ambos sentidos. Algunas cosas que esperaba que fueran fáciles resultaron ser difíciles, particularmente mantener la IA alineada con la realidad cuando se sentía tentada a inventar características que sonaban plausibles pero que no estaban en nuestro producto. Otras cosas que esperaba que fueran difíciles resultaron ser casi triviales, como producir trece archivos HTML consistentes para una nueva sección en menos de una hora, cada uno con JavaScript funcional para alternar estados e indexación de búsqueda, y cada uno de ellos utilizable como referencia de diseño para el equipo que implementa el producto real.

La velocidad, sinceramente, fue la sorpresa menor. La mayor fue cuánto importa el método. Si el método es correcto, se obtienen resultados compuestos: mejor producción, más rápido, con la documentación lista para entregar. Si se hace mal, solo se llega a la mediocridad más rápido.

Lo que sigue es el método completo que utilicé: las indicaciones que funcionaron, los errores que cometí, las rondas de revisión que detectaron características fabricadas por la IA antes de que pudieran lanzarse. Está escrito principalmente para desarrolladores de OTGS que quieran ejecutar proyectos como este ellos mismos, pero cualquiera que construya interfaces de usuario con IA hoy en día probablemente pueda sacar algo de él.

La única regla que hace que esto funcione

Planifique en texto antes de producir código.

Claude Code construirá HTML con gusto en el momento en que se lo pida. También construirá el HTML incorrecto, de forma educada, rápida y en grandes cantidades. Cada vez que se ahorra tiempo omitiendo una ronda de planificación, se paga el doble en reelaboración, y la reelaboración es más difícil que la planificación original porque ahora hay código que no se quiere desechar.

Cada rama exitosa en la sesión de WPML tuvo la misma forma:

1. Amir planteó un problema o una intención.
2. Claude hizo preguntas aclaratorias.
3. Amir respondió concisamente.
4. Claude propuso un plan en texto.
5. Amir confirmó o editó el plan.
6. Solo entonces Claude construyó.

Cada vez que esa forma se rompía, retrocedíamos. Si no recuerda nada más de esta guía, recuerde los seis pasos anteriores.

Las ocho fases de una sesión

1. Enfoque el problema, no la solución

Comience con el problema que siente el usuario, no con la pantalla que desea cambiar.

Mal inicio:

“Añadir una nueva página de ajustes para la facturación de la traducción con IA.”

Buen inicio (cómo empezó realmente la sesión de WPML):

“Los usuarios informan que WPML resulta abrumador y poco intuitivo debido a:

• Demasiadas pantallas diferentes relacionadas con la traducción.
• Ajustes distribuidos en múltiples áreas, a veces no relacionadas.
• Opciones prominentes pero de baja prioridad que distraen de los flujos de trabajo de traducción principales.
• Secciones relacionadas distribuidas en diferentes pantallas sin dependencias claras o rutas de navegación.
• Falta de enlaces cruzados entre funcionalidades relacionadas…”

La segunda versión le da a Claude un alcance sobre el que razonar. Conoce el problema del usuario, puede detectar otras cosas que contribuyen a ese problema y puede oponerse si la solución propuesta no aborda la causa raíz. La primera versión reduce a Claude a un mecanógrafo.

En la sesión de WPML, el planteamiento del problema llevó directamente a decisiones que Claude no podría haber tomado solo: que Pagos y Mantenimiento era una pantalla de más, que los Paquetes no deberían estar en el nivel superior, que el registro de Comunicación estaba en el menú equivocado, que el Glosario no era ni un ajuste ni un elemento de facturación. Nada de eso se habría logrado si se hubiera empezado con “rediseñar Ajustes”.

2. Reúna su material antes de que comience la sesión

Ponga todo lo que la IA necesita en el directorio de trabajo antes de solicitarlo:

• Capturas de pantalla de la interfaz de usuario actual. Cada pantalla que pueda tocar. En la sesión de WPML vivían en Current/ — WPML settings.jpg, debug-main.jpg, td-invoices.jpg, td-translators.jpg, etc. Una decena de JPG que cubrían todo el alcance.
• Un instructions.txt que expone el problema, el alcance y la expectativa de salida. Consulte ../instructions.txt para ver el real; observe cómo creció a lo largo de tres pasadas (--- 1 ---, --- 2 ---, --- 3 ---) a medida que se añadía un nuevo alcance, en lugar de reescribirse cada vez.
• Cualquier diseño preexistente en una carpeta already-updated/. La sesión de WPML comenzó con un ai-translation.html con estilo que Claude utilizó como plantilla visual para todo lo demás producido en la sesión: la configuración de Tailwind, la clase de tarjeta, el patrón de enlace de retroceso, la animación flash para los saltos de ancla. Ese único archivo ahorró unos 30 minutos de decisiones del sistema visual.
• Enlaces externos que desea que Claude consulte. Para la Solución de problemas, la página de requisitos mínimos de WPML (wpml.org/home/minimum-requirements/) impulsó el diseño del panel de advertencias.

Claude funciona mejor cuando puede ver la fuente de la verdad. Las capturas de pantalla le permiten verificar las afirmaciones con la realidad. Los enlaces externos le permiten investigar a través de subagentes (ver fase 8) sin molestarle para obtener información de fondo.

3. Termine cada resumen con “hágame preguntas, no asuma”

Esta es la frase de mayor impacto en la guía. Cada conjunto de instrucciones en la sesión de WPML terminaba con alguna versión de:

“Antes de empezar el diseño, revise todo, cree una lista de preguntas y pregúnteme. No asuma.”

Sin ella, Claude asume por defecto actuar directamente sobre su resumen. Con ella, Claude dedica un turno a mapear lo que no sabe y le pregunta. Ese turno ahorra horas.

Cuando Claude le devuelva preguntas, respóndalas de forma concisa. No debe párrafos. De la sesión de WPML:

P: “Etiqueta del menú: ¿mantener como ‘Pago por traducción con IA’? (suena un poco torpe)”
R: “Facturación de traducción con IA”

P: “Estructura de la página: ¿una página larga con secciones o subpáginas?”
R: “Subpáginas, siguiendo una estructura similar a cómo construyó la página de Ajustes. Necesitaremos planificar antes de que implemente.”

Las respuestas de una línea están bien. Las frases completas están bien. Los párrafos completos suelen ser una señal de que está haciendo el trabajo de Claude por él.

4. Realice rondas de preguntas antes de cualquier implementación

La sección de Facturación de la sesión de WPML pasó por dos rondas completas de preguntas antes de que se escribiera una sola línea de HTML.

Ronda 1 — 8 preguntas que cubren: etiqueta del menú, estructura de la página, variaciones de estado, el contador redundante de sitios conectados, ubicación del Glosario, ubicación de Quién puede usar, alcance de la facturación, manejo de acciones solo para el propietario.

Ronda 2 — 7 preguntas más específicas: resumen vs. índice, la CTA “Cansado de asignar créditos”, contenido de informes de uso, UX de transferencia de créditos, campos de estado activo de Pago por uso, estado prepago activo, alcance solo para el propietario.

Solo después de ambas rondas Claude propuso el plan de archivos. Solo después de que se confirmó el plan de archivos se escribió el HTML. Tiempo total de planificación transcurrido: quizás quince minutos de ida y vuelta. Archivos totales producidos: cinco, todos correctos a la primera.

El patrón opuesto es comprometerse con la salida después de una ronda, y luego regenerar cada archivo dos o tres veces porque las restricciones no se revelaron completamente. Ese camino parece más rápido hasta la tercera hora.

5. Designe explícitamente las funcionalidades solo para maquetas

Las maquetas a menudo necesitan mostrar múltiples estados de la misma pantalla: vacía vs. poblada, segura vs. advertencia, plan activo vs. plan inactivo. Dos patrones en esta sesión funcionaron bien:

El conmutador de estado de facturación. La página de inicio de Facturación tiene un control Preview state: No plan | PAYG active en la parte superior derecha. Al hacer clic en cualquiera de ellos, el panel de resumen cambia entre los dos estados: sin plan muestra ambas tarjetas de adquisición, activo de Pago por uso muestra el panel único “Su plan de Pago por uso” con los detalles de la tarjeta. Etiquetado como “Estado de vista previa:” para que los revisores entiendan que esto es una funcionalidad de maqueta, no una interfaz de usuario de producto.

El conmutador de advertencias de Solución de problemas. Preview state: Has warnings | All OK muestra u oculta el panel amarillo de requisitos mínimos. Mismo etiquetado, misma razón.

Sin estos, se enviarían dos archivos HTML separados para cada pantalla con una transición de estado. Con ellos, un archivo demuestra toda la superficie de diseño. Los revisores ven más, más rápido.

En la actualización del ticket de YT, señálelos explícitamente:

“Hay un conmutador en la parte superior: ‘Estado de vista previa: Sin plan / Pago por uso activo’. Úselo para ver ambos estados. Por supuesto, esto es solo parte de la maqueta y no para la interfaz de usuario real.”

La cláusula en cursiva es importante. De lo contrario, un desarrollador preguntará por qué el producto tiene un conmutador de estado.

6. Realice una ronda de revisión comparando las maquetas con la fuente

Una vez que todo esté construido, antes de comprometerse con la entrega, realice una ronda de revisión. En esta sesión fue una única indicación:

“Todo parece bien. Haga una ronda de revisión:

1. Verifique en detalle las capturas de pantalla de entrada para asegurarse de que no ha añadido cosas que WPML no tiene y no ha eliminado cosas que deberían estar allí.
2. Verifique que las explicaciones de texto para cada página y cada función sean lo suficientemente descriptivas para que los clientes entiendan qué hace ‘esto’, para qué sirve y qué esperar.”

Claude reexaminó cada captura de pantalla, la comparó con cada archivo producido y devolvió un informe estructurado. De la revisión de Solución de problemas de WPML:

• Faltan en mi diseño — cinco herramientas presentes en la interfaz de usuario actual que no se habían portado: “Eliminar comentarios que no coinciden con el idioma del contenido”, “Mensajes y notificaciones / Eliminar todos los mensajes y notificaciones”, “Corregir código wpml_language en la configuración de WPML”, “Restablecer ATE / Restablecer registro de depuración” y la tabla de registro del instalador en la página de Soporte del instalador.
• Cosas que añadí que no existen — la maqueta de Verificación del sistema mostraba 4 servidores de conectividad; el producto actual solo verifica 2. Enumeraba 4 bibliotecas PHP; el actual muestra 2.
• Explicaciones que necesitan ser más precisas — el registro de Comunicación no explicaba cómo se ve el éxito/fracaso; la gestión de Paquetes no mencionaba que los paquetes se crean automáticamente por otros plugins; la vinculación de tipos de contenido no explicaba el efecto visible de cambiar una asignación.

Cada elemento se podía solucionar en un solo turno de seguimiento. Ninguno se habría detectado sin la indicación de revisión. La IA tiene una ventaja aquí que usted no tiene: puede volver a leer cada página y cada captura de pantalla simultáneamente en un solo turno.

Hágalo siempre. No lo trate como opcional.

7. Escriba la entrega al desarrollador en paralelo, no al final

La actualización del ticket de YT en la sesión de WPML pasó por varias iteraciones durante la sesión, refinándose a medida que evolucionaba el diseño, no se ensambló en pánico al final. Cuando PostHog fue renombrado a “Seguimiento e informes de uso”, la actualización del ticket lo reflejó en el mismo turno.

Una buena actualización de ticket para una entrega de rediseño de interfaz de usuario tiene:

1. Un resumen de un párrafo de lo que está cambiando.
2. Puntos clave de alto nivel — qué se mueve, qué se elimina, qué se añade.
3. Una tabla de detalles por área — nombre de la página, qué cambió, por qué. Omita los aspectos estéticos cuando toda la sección haya sido reestilizada, es ruido.
4. Una tabla de mapa de migración para cualquier cosa que cruce menús de administración. Utilice rutas exactas de la interfaz de usuario actual: WPML → Translation Dashboard → Payments & Maintenance → Advanced Translation Editor → Overview → Who can use Automatic Translation? — no resúmenes, no paráfrasis.
5. Elementos abiertos — lo que aún necesita la aportación del equipo receptor.
6. Menciones @ de las personas específicas que necesitan revisar áreas específicas.

La actualización real del ticket de WPML tiene unas 2.500 palabras y cubre tres menús de nivel superior (Ajustes / Facturación de traducción con IA / Solución de problemas). Es más larga que la mayoría de los tickets porque la superficie de cambio es grande; no tema la extensión cuando el cambio es complejo, pero sea disciplinado sobre lo que pertenece a la tabla (rutas y destinos) frente a lo que pertenece a la prosa (principios y razonamiento).

Cuando quiera que Claude actualice el ticket a medida que evoluciona el diseño, un mensaje estructurado funciona mejor:

“Necesito que actualice mi mensaje que explica los cambios realizados.

1. Debe tener una nueva sección sobre [X].
2. Explique por qué hemos [hecho Y].
3. Incluya una tabla con los detalles del cambio. Omita los aspectos estéticos porque todo en esta sección tiene una nueva apariencia.
4. Actualice las instrucciones actuales, ya que ahora ha movido algunos controles a [Z].”

Específico, estructurado y le dice a Claude qué conservar y qué cambiar.

8. Utilice subagentes para la investigación externa

Cuando Claude necesite información de fuera del directorio de trabajo (documentación del proveedor, publicaciones de blog, requisitos mínimos), delegue en un subagente. No la busque y pegue manualmente.

La indicación que inició la investigación de Solución de problemas de WPML:

“Investigue las características de solución de problemas/depuración del plugin WPML en wpml.org (el sitio de documentación oficial) y devuelva un resumen conciso de lo que hace cada característica y cómo el equipo de Soporte de WPML suele instruir a los usuarios para que la utilicen. […] Por favor, busque la documentación de cada uno de los siguientes y dígame:

• Qué hace la herramienta (1-2 frases)
• Quién la usa: autoservicio del usuario final o solo bajo instrucción del Soporte
• ¿Es destructiva/riesgosa? (restablece datos, borra caché, etc.)
• Cualquier confusión de usuario conocida que la documentación señale.”

Ese subagente devolvió un resumen estructurado con enlaces a la fuente que dieron forma directamente a la organización de tres niveles (seguro / registros / solo para soporte) del rediseño de Solución de problemas. Sin él, habríamos adivinado quién usa qué, o habríamos interrumpido el flujo para leer la documentación nosotros mismos.

Cuando delegue en un subagente, dígale:

• Lo que intenta lograr (para que pueda juzgar casos extremos, no solo seguir instrucciones).
• Exactamente qué formato desea de vuelta (¿tabla? ¿viñetas? ¿una frase cada uno?).
• Un presupuesto de palabras o tiempo. De lo contrario, devolverá un ensayo.

Principios críticos de UX que surgieron del trabajo

El método es lo principal. Pero algunos principios se repitieron con la suficiente frecuencia como para que valga la pena conocerlos de antemano; le ahorrarán una o dos rondas de preguntas.

Organizar por riesgo, no por tema

La página actual de Solución de problemas de WPML es un desplazamiento gigante de unas 25 herramientas, mezclando “Borrar caché” con “Restablecer WPML por completo” con el mismo peso visual. Los clientes no pueden saber qué es seguro. Los asistentes no pueden señalar una URL.

El rediseño clasifica cada herramienta en uno de tres niveles con insignias de colores:

• Seguro de ejecutar usted mismo (verde) — soluciones de autoservicio que los clientes pueden probar sin ayuda.
• Registros — solo lectura (información azul) — diagnósticos que nunca cambian nada.
• Avanzado — solo cuando el Soporte de WPML se lo pida (rojo, más un párrafo explicativo a nivel de grupo) — herramientas que pueden perder datos o romper un sitio si se usan incorrectamente.

Si se encuentra rediseñando una página técnica densa, pregunte “¿cuál es el radio de acción de cada herramienta?” antes de preguntar “¿a qué tema pertenece cada herramienta?”

Cada herramienta responde a tres preguntas

Para que una herramienta funcione como autoservicio, su texto debe decirle al usuario:

1. Qué hace.
2. Cuándo es útil.
3. Qué esperar después.

La herramienta “Corregir post_parent en traducciones” de WPML pasó del conciso “Corrige las relaciones padre de las entradas traducidas” del producto actual a:

“Vuelve a vincular las páginas secundarias traducidas (o cualquier contenido jerárquico) a la versión traducida de su padre, en lugar de apuntar al padre en el idioma original. Útil después de migraciones o importaciones masivas.”

La misma herramienta, 3 veces más útil porque el usuario ahora sabe cuándo recurrir a ella.

Controles de seguridad graduados

No todas las acciones destructivas necesitan el mismo patrón de confirmación. La sesión de WPML terminó con tres niveles:

• Acción segura → un botón.
• Acción de riesgo medio → una casilla de verificación “Entiendo” activa el botón; un párrafo rojo encima explica el riesgo específico.
• Acción nuclear (Restablecer WPML por completo) → la casilla de verificación Y una frase RESET WPML escrita deben ser correctas.

Diferentes niveles de riesgo, diferente fricción.

Enlace cruzado, no duplicar

Cuando una herramienta se superpone con un ajuste, enlace en lugar de poseer. La página Solución de problemas → Informes de uso enlaza a Ajustes → Traducción con IA → “Quién puede usar la Traducción automática” en lugar de volver a implementar ese control. Una fuente de verdad, un lugar para mantener, una experiencia consistente.

Renombrar para clientes

Los nombres internos de proveedores o acrónimos no deben aparecer en el texto dirigido al cliente. En esta sesión:

• “Integración de PostHog” → “Seguimiento e informes de uso” (los clientes no saben qué es PostHog).
• “ATE” como etiqueta de interfaz de usuario → “Editor de traducción avanzado” (ATE se mantiene como abreviatura interna solo en los comentarios de YT).
• “Créditos” → “Palabras” (cambio de modelo de precios, pero la lección de UX se generaliza: no exponga los detalles internos del proveedor o la facturación como sustantivos orientados al usuario).

La búsqueda supera a la navegación para superficies densas

El índice de Ajustes de WPML tiene 16 secciones; la página de Solución de problemas tiene unas 25 herramientas. Esperar que un usuario escanee y encuentre la correcta no es realista. Una búsqueda destacada y con alcance con indexación de subelementos —para que al escribir “fantasma” se salte directamente al ancla de la herramienta de entradas fantasma— resuelve la capacidad de descubrimiento mejor que cualquier limpieza de navegación.

La sección de Facturación fue diferente: 4 subpáginas, todas con etiquetas en lenguaje sencillo. Inicialmente añadimos la búsqueda, luego la eliminamos después de evaluar la densidad real. El principio:

Si una página tiene ≤6 elementos de nivel superior con etiquetas en lenguaje sencillo, no añada búsqueda. Si tiene >10 elementos técnicos, la búsqueda casi siempre vale la pena.

Advertencias proactivas sobre ajustes pasivos

Si su sitio no cumple un requisito conocido, informe al usuario en la parte superior de la página; no espere a que lo descubra al fallar. La página de inicio de Solución de problemas ejecuta todas las comprobaciones de la lista de requisitos mínimos de WPML y muestra los fallos en un panel amarillo encima de la búsqueda. Cuando todo pasa, el panel se oculta por completo.

Patrones de indicaciones que funcionaron

Estas son las frases exactas que mantuvieron la sesión de WPML en marcha. Robe las.

Forzar rondas de preguntas

“Antes de continuar, revise todo y pídame aclaraciones. No haga suposiciones.”

“Si le quedan preguntas, pregunte.”

“Compile el material y hágame preguntas antes de producir el resultado.”

Impulsar la revisión

“Haga una ronda de revisión:

1. Verifique en detalle las capturas de pantalla de entrada para asegurarse de que no ha añadido cosas que WPML no tiene y no ha eliminado cosas que deberían estar allí.
2. Verifique que las explicaciones de texto para cada página y cada función sean lo suficientemente descriptivas para que los clientes entiendan qué hace ‘esto’, para qué sirve y qué esperar.”

Evaluar antes de actuar

“En realidad, veo que la funcionalidad de búsqueda para la sección de facturación no es necesaria. Evalúe y dígame si hay necesidad, basándose en el contenido de las subpáginas.”

Pedir a Claude que evalúe antes de implementar es la forma de evitar tener que deshacer algo tres ediciones más tarde. En la sesión de WPML, esta indicación llevó a que la búsqueda se eliminara limpiamente de Facturación en un solo paso, en lugar de implementarse a medias y luego eliminarse.

Detectar ambigüedades

“Verifique la consistencia y los conflictos. Produzca una versión actualizada libre de conflictos y ambigüedades. Antes de hacerlo, hágame preguntas para que no necesite asumir o inventar.”

Cuando se le preguntó esto, Claude devolvió una lista estructurada de contradicciones en un borrador de actualización de ticket (“los elementos listados como eliminados también se listan como movidos, ¿cuál es?”, “’ATE’ es ambiguo: ¿Editor de traducción avanzado o Motor de traducción automática?”). Cada una se resolvió en una sola respuesta. Sin esta indicación, esas contradicciones se habrían enviado.

Renombres y movimientos dirigidos

“Renombre ‘X’ a ‘Y’ en todos los archivos de solución de problemas.”

“Mueva el bloque amarillo de requisitos mínimos para que esté encima de la búsqueda en troubleshooting.html.”

Quirúrgico. Específico. Siempre funciona, siempre que el cambio sea realmente mecánico. Para cualquier cosa que requiera juicio, vuelva al patrón de planificación.

Errores a evitar

• Saltarse la planificación para “ahorrar tiempo”. Cada ronda de planificación omitida cuesta más reelaboración de la que ahorró.
• Aceptar características que no ha verificado que existan. Claude inicialmente añadió 4 servidores de conectividad a la Verificación del sistema; el producto solo tiene 2. Detectado en la revisión. Usted es responsable de la verificación de cordura; no confíe en la plausibilidad como un sustituto de la precisión.
• Desviación de nombres. Una vez que se toma una decisión (“ATE” es solo interno; la interfaz de usuario del cliente dice “Editor de traducción avanzado”), aplíquela en todas partes. La desviación entre los archivos de maquetas y los tickets causa confusión al desarrollador. Pida a Claude que propague los renombres; no lo haga manualmente.
• Controles solo para maquetas sin etiquetar. Los conmutadores de vista previa son excelentes para las revisiones. Sin una etiqueta de “Estado de vista previa:”, se leen como interfaz de usuario del producto.
• Olvidar la consistencia entre documentos. Cuando se renombra una característica, el HTML, el índice de búsqueda, el nombre de archivo, cada href y el ticket de YT deben actualizarse. Dígale a Claude que propague; no lo persiga archivo por archivo.
• Dejar la documentación de entrega para el final. Escriba el ticket a medida que avanza. Cuando el diseño se estabilice, el ticket estará listo.
• Dejar que la IA decida lo que importa. Claude es excelente en la ejecución; es mediocre en juicios que dependen del contexto institucional. La decisión de “no necesitamos búsqueda aquí” en Facturación fue de Amir, no de Claude, y fue correcta. No abdique las decisiones editoriales a la herramienta.

Un esquema de sesión de ejemplo

Si ha leído hasta aquí, aquí tiene el flujo de trabajo completo condensado:

1. Enmarcar — plantee el problema del usuario, enumere las pantallas/áreas dentro del alcance, adjunte capturas de pantalla.
2. Resumen — escriba un instructions.txt que termine con “revise todo, hágame preguntas, no asuma”.
3. Ronda de preguntas 1 — deje que Claude haga 5-10 preguntas. Respóndalas concisamente.
4. Plan — Claude propone una estructura general. Usted confirma o ajusta.
5. Ronda de preguntas 2 — preguntas restantes más detalladas (normalmente sobre variaciones de estado, casos extremos, confirmaciones).
6. Subplan — lista de archivos y esquema por archivo.
7. Construir — Claude escribe los archivos. Verifique cada uno a medida que llega.
8. Revisar — comparación con las capturas de pantalla de origen; encuentre elementos faltantes/añadidos; refine el texto.
9. Consolidar — redacte la actualización del ticket de YT e itérela junto con el diseño.
10. Entrega — envíe al repositorio, grabe un breve video explicativo, @mencione al equipo receptor.

Presupuesto para los pasos 3-5 y el paso 8; el resto es principalmente ejecución.

Cierre

La lección más importante de la sesión de WPML es que Claude Code no es un diseñador; es un constructor disciplinado que puede ejecutar un plan bien especificado a una velocidad inusual. Su valor en el ciclo es el juicio, no la escritura. Déle a Claude el problema, exija que haga preguntas, insista en un plan en texto, revise el resultado con la fuente de la verdad y prepare la entrega a medida que avanza.

Si hace eso, la velocidad que obtendrá no es una mejora de 2x sobre el trabajo manual de UX. Es más bien un orden de magnitud, y la calidad del resultado es mayor, porque la disciplina de revisión está integrada en el flujo de trabajo en lugar de ser algo que tendría que recordar hacer.

Esta actualización de diseño se incluirá en WPML 4.10. Al igual que el diseño impulsado por IA, implementaremos esta enorme actualización desplegando agentes de IA para que trabajen de forma autónoma, como un equipo. Si está interesado en una vista previa, aquí tiene un vídeo rápido: