El mes pasado Matt, el CEO de Automattic, lanzó lo que llamamos «radical speed month«. Las reglas eran simples: encuentra alguien con quien trabajar, elige una métrica, y céntrate en moverla. Eliminamos las reuniones recurrentes y todas las dinámicas de trabajo que teníamos.
Para mí eso significó algo que raramente puedo hacer: diseñar y desplegar a producción (hacer deploy) yo misma. Tres semanas después, y con mucho tira y afloja, puedo decir que la IA ha cambiado mi proceso de diseño.
Esto es lo que he aprendido.
Figma primero, siempre
El proyecto que escogimos tenía como objetivo mejorar el flujo de onboarding de WordPress.com para dispositivos móviles. Revisamos cada pantalla, hicimos capturas con varios dispositivos físicos, identificamos puntos de fricción y definimos el enfoque. Decidimos que nos íbamos a centrar en tres áreas: Dominios, la página de planes de hosting, y el checkout.
Lo hicimos todo en Figma, antes siquiera de abrir la terminal (yo utilizo iTerm2) o Claude.
Al principio pensé que continuaba diseñando «a la vieja usanza», que debería empezar con Claude directamente. De hecho lo intenté en algún momento, pero lo que pasó era predecible: acabamos trabajando en una iteración sobre otra iteración, y como yo no sabía donde iba, Claude tampoco 🙄
Figma sigue formando parte de mi proceso de diseño. Es mi brújula, porque contiene «la fuente de la verdad», el diseño al que puedo volver cuando me pierdo o la IA me confunde.
Puedo compartirlo con Claude cuando necesita contexto visual, y me permite comparar muy fácilmente lo que hay en producción con la idea que tenía.
Sin eso, la IA me arrastra hacia donde ella «quiere» ir.
Sin reglas explícitas, Claude pierde el tiempo (y tú también)
Soy diseñadora, y aunque creo que me desenvuelvo suficientemente bien en temas técnicos, no tengo ni de lejos el conocimiento de alguien que se dedica exclusivamente al desarrollo.
Después de perder mucho tiempo en iteraciones infinitas, acabé por definir ciertas reglas con Claude (reglas que cumple cuando quiere, pero eso es otro tema).
- Nunca hagas commit de nada. Le prohíbo explícitamente que haga commits y cree pull requests sin que antes yo revise manual y visualmente todos los cambios.
- Arranca siempre el entorno local para que pueda ver los cambios en el navegador fácilmente.
- Sigue los principios del repositorio y usa MCPs. Claude tiene tendencia a hacer sobreingeniería y reinventar la rueda. En un repositorio tan grande como Calypso, es más fácil que busque cómo se ha resuelto eso en otro caso que rehacerlo todo de nuevo. Lo bueno es que tenemos MCPs que contienen todo el contexto de la empresa y del proyecto, y eso también ayuda.
- No asumas nada. Si tienes dudas, pregunta. Prefiero que Claude me fría a preguntas a que asuma cosas y nos desviemos del objetivo.
- ELI5 (explain me like I’m five) cuando lo necesite. Le pido que me explique qué está haciendo de la forma más fácil y menos técnica posible.
Esta última regla es la más importante y quizás también la más contraintuitiva. Teóricamente, con inteligencia artificial puedo hacer cosas que antes requerían un desarrollador… pero eso no significa que las entienda, no nos engañemos. Y si no las entiendo, no puedo saber si vamos en la dirección correcta.
El «ELI5» no es una señal de ignorancia. Es asumir que no lo sé todo y que tengo un criterio: necesito suficiente contexto para evaluar si la solución tiene sentido antes de aceptarla, no quiero trabajar con el modo automático a ciegas. Es, en el fondo, lo mismo que en cualquier ciclo de feedback: no puedes validar lo que no entiendes. Y ante la duda, siempre consulto con alguien del equipo de desarrollo.
La IA «sobrecomplicará» los problemas simples
Durante el proyecto introdujimos un bug visual mientras arreglábamos otro (cosas que pasan). El segundo bug era simple: sin querer habíamos cambiado el tamaño de la tipografía, su color y los márgenes. En teoría es CSS básico.
Claude estuvo más de 30 minutos (y no sé cuántos tokens) buscando contexto. Y entonces empezó a trabajar en lo que parecía una rearquitectura completa de la página.
La solución real eran pocas líneas de CSS y mover un par de clases.
Prueba y error. Todo el rato.
Todo esto pasa porque la IA no tiene tu criterio. No distingue entre «esto requiere refactorizar» y «esto requiere tocar dos propiedades». Busca contexto, encuentra patrones relacionados, y suele optimizar más allá del problema real.
He aprendido a detectar la señal de alerta: cuando Claude lleva más de diez minutos buscando contexto para algo que tú podrías describir en una frase, es mejor parar. En este caso concreto tuve que reiniciar la terminal dos veces porque Claude se quedaba enganchado en querer rehacer el flujo entero. Al final aprendí que era mejor si le compartía los dos PRs causantes, el contexto del proyecto, y lo que quería lograr.
Puedes hacer cosas que nunca imaginaste. Eso no significa que las entiendas.
Este mes hice PRs en un repositorio con miles de archivos, en un stack que no domino, y usando conceptos y herramientas que hace un año me habrían parecido inaccesibles. Eso está pasando, y me encanta.
Pero es una trampa. Cuanto más capaz te vuelves gracias a la IA, más importante es tener criterio. Porque el sistema no tiene forma de saber cuándo está yendo demasiado lejos, eso lo tienes que saber tú.
El criterio no se improvisa, no me aparece si cierro los ojos. Viene de años de trabajo, de observar, de no aceptar lo que hace la IA sin pensarlo, de entender qué hace que una interfaz funcione, de haber visto suficientes patrones como para reconocer cuando algo está mal aunque no puedas explicarlo técnicamente todavía.
La IA amplifica tu capacidad, pero también amplifica tus puntos ciegos. Por eso el criterio importa más que nunca (y no precisamente porque la IA vaya a reemplazarnos).
Sigues necesitando humanos
Mis PRs no se mergean solos, siempre los revisa un desarrollador antes de que lleguen a producción.
Y esto no es un cuello de botella, sino una garantía. No porque no confíe en mi trabajo, sino porque los ojos de alguien que conoce el stack de verdad detectan cosas que ni Claude ni yo vemos. Y porque no soy desarrolladora 🙂
La IA ha comprimido muchísimo el loop entre diseño y producción de una forma que antes me parecía imposible. Lo que está claro es que todavía seguimos necesitando tener humanos en el flujo 🙂
Y esto está bien, porque el objetivo no debería ser eliminar a diseñadores (con Claude Design) y desarrolladores del proceso.
Apuntes finales
Tres semanas diseñando y haciendo deploy con la ayuda de Claude me han enseñado más sobre cómo usar estas herramientas que cualquier artículo que haya leído.
Lo más importante fue entender que la IA es tan buena como el criterio que traes a la conversación. Si sabes lo que quieres, te lleva allí más rápido de lo que creías posible. Si no lo sabes, te lleva a algún sitio, pero probablemente no sea el correcto.
Por mi parte, sigue siendo muy claro: Figma primero, para pensar, definir, discutir y ver. Luego IA, pero con criterio.
