- En lugar de redactar documentos de especificación y hacer mockups en Figma, el flujo de trabajo de diseño cambió a crear directamente funciones prototipo que realmente funcionan a partir de las ideas tal como están en la cabeza
- Antes era escéptico con los LLM como Copilot, Cursor y Gemini, pero tras unirse a Jane Street sintió que el apoyo de la IA es indispensable
- Claude permite iterar gratis y sin límites, así que aunque cambie de opinión 50 veces, hace posibles mejoras detalladas como ajustar el botón Submit, atajos de teclado y textos sin quejarse
- Los diseñadores también pueden crear por sí mismos una prueba de concepto (POC) funcional como lo haría un ingeniero, para que otras personas la prueben y la evalúen directamente
- Al concentrar todo el esfuerzo en el entregable real, se eliminan tareas intermedias accesorias y esto lleva a un nuevo modelo de colaboración
Del escepticismo hacia los LLM al cambio
- Durante mucho tiempo fue escéptico con los LLM y se decepcionaba cada vez que los usaba
- El año pasado intentó usar Copilot y Cursor para modificar un juego que había creado, pero ninguno de los dos logró generar cambios que funcionaran
- En su trabajo anterior usó Gemini para crear el esquema de un brief de producto y wireframes, pero terminó descartándolo todo
- Todas las áreas en las que había probado LLM eran cosas que ya hacía bien, y el resultado era peor que hacerlo directamente
- Después de unirse a Jane Street el verano pasado, se dio cuenta de que el apoyo de la IA era indispensable
- Porque había muchas áreas nuevas en las que aún no dominaba, como OCaml y Bonsai
- La mayor sorpresa fue que cambió incluso su flujo de trabajo de diseño, que era el área en la que mejor se desempeñaba
Flujo de trabajo centrado en prototipos
- En vez de documentos de especificación, mockups en Figma, propuestas escritas y revisiones de implementación con desarrolladores, construye directamente funciones prototipo que realizan exactamente la funcionalidad deseada
-
Flujo de trabajo real
- Escribe el problema y la propuesta en texto
- Abre el editor y ejecuta el build, el servidor y Claude, usando esa descripción escrita como prompt
- Hace que primero funcione la base para demostrar la viabilidad
- Itera todo lo que haga falta
- Hace push de los cambios al entorno de desarrollo y recopila opiniones de usuarios
- Envía una feature (el equivalente al pull request en esa empresa) con la apariencia y el comportamiento previstos
- Un prototipo dentro del codebase real resultó mejor que los mockups o la documentación en casi todos los aspectos
Caso del prototipo de entrada JSQL
- Recientemente creó un prototipo que agrega prompting con LLM a la entrada de JSQL
- JSQL es un dialecto interno de SQL usado en herramientas dirigidas a distintos usuarios
- Realmente funcionó, y lo usó, probó y convivió con él durante varios días
- Claude permite iterar gratis y sin límites, así que no le importa si uno cambia de opinión por quincuagésima vez o pide pequeños ajustes
- Refinar el botón Submit, agregar atajos de teclado, ajustar textos, modificar prompts y añadir mensajes de confirmación generativos
- Son mejoras que en su trabajo anterior habrían requerido días o semanas de ida y vuelta entre ingeniería y diseño, o quizá nunca habrían ocurrido
- Todo el esfuerzo se invierte en mejorar el entregable real, y no en trabajo accesorio como crear componentes en Figma o dar formato a documentos
Cómo se consolidó este flujo de trabajo
- Llegar a esta forma de trabajo tomó tiempo
- Al principio, tras incorporarse, solo usaba IA para tareas pequeñas como corregir defectos menores de UX
- Para ideas más grandes seguía usando Figma y documentos, y si intentaba hacerlo con Claude, fallaba
- En los últimos dos meses, las ocasiones en que recurre a Figma han disminuido drásticamente
- Gracias a una combinación de mejoras del modelo, mayor habilidad personal y una mejor elección del alcance, la IA empezó a funcionar también en trabajos grandes
- Además de los prompts de JSQL, hizo muchos prototipos para cambios orientados al usuario, al modelo de datos y a librerías, algunos de ellos con diffs de más de 2000 líneas
- Diseña en Figma y luego implementa prototipos interactivos, o en algunas apps nuevas omite Figma por completo y desde el inicio itera el diseño visual con Claude
El poder que esto da a los diseñadores
- Un ingeniero puede crear directamente una prueba de concepto funcional cuando tiene una idea, pero un diseñador normalmente tiene que convencer a otras personas
- Una idea como el "prompting directo con LLM dentro de la entrada de JSQL" puede no tener clara ni siquiera su viabilidad al inicio, así que pedirle a otra persona que haga un prototipo podría ser una pérdida de tiempo
- También podría ser una propuesta que no cubra claramente una necesidad del usuario
- Cuando la idea se implementa realmente con Claude, para los demás es mucho más fácil evaluarla probándola directamente
El reto en la forma de revisar
- La desventaja es que el revisor recibe una función ya terminada
- Surge la duda de si terminará revisando solo el código, sin posibilidad de opinar sobre la funcionalidad
- Es parecido a cuando en diseño se recibe un wireframe detallado hecho por PM y te piden simplemente "hacer que se vea bien"
- La propuesta debe ser lo más clara y completa posible, pero también quiere que sus colegas de ingeniería iteren junto con él en el espacio de diseño como si fuera un mockup en Figma
-
Solución actual
- Optó por mirar la feature de otra manera y escribir una guía breve en la descripción
- El prototipo es un documento vivo de propuesta, el código es desechable, y el rol del revisor es dar feedback sobre diseño y experiencia de usuario
- Al final, el revisor toma la idea y la implementa en una feature aparte, usando el prototipo como referencia pero asumiendo directamente la propiedad del código de producción
- Todavía sigue explorando qué resulta razonable y qué se siente bien
Preocupaciones y una tensión conocida
- Existe el temor de que diseñar con Claude saque al autor de un pensamiento flexible y creativo y lo deje atrapado en un pensamiento iterativo limitado a lo que cree que Claude puede construir
- Eso puede estar bien para herramientas maduras con cambios incrementales, pero al trabajar en algo nuevo podría hacer que se pierdan ideas
- Es una tensión conocida y se conecta con el debate de 2011 sobre si los diseñadores deberían escribir código
- Los críticos sostenían que, una vez que uno empieza a programar, se vuelve más difícil hacer cambios grandes en las ideas
- Sin embargo, como siempre le gustó tanto crear sitios web como programar, siguió escribiendo código
- A medida que frameworks frontend como React se volvieron comunes y el desarrollo se hizo más complejo, eligió especializarse
- Sus proyectos personales siguen hechos con React y eso le ayuda a comunicarse con desarrolladores
- La mayor parte de su tiempo laboral se iba a Figma y a documentos
- Si se hubiera unido a Jane Street antes de los LLM, probablemente habría quedado mucho más atrapado en Figma
- Tenía algo de experiencia con JavaScript, pero OCaml y Bonsai eran completamente nuevos, así que la contribución técnica se habría sentido fuera de su alcance
- En cambio, volvió a construir el entregable real, y siente que regresar a ese medio es emocionante y le da una libertad mucho mayor para probar cualquier cosa
1 comentarios
Comentarios de Hacker News
En el lado de negocio ya suelen traer los requisitos en forma de una solución que ellos mismos idearon, y normalmente es algo tipo máquina de Rube Goldberg, así que hay que hacer ingeniería inversa en la conversación para llegar al requisito real
En adelante, probablemente traerán una solución ya “lista” y “funcionando”, y estarán menos abiertos a hablar de diseño y arquitectura de forma integral
Seguramente será algo como: “Pero si ya se puede hacer así. Casi está listo, ¿por qué hace falta X semanas-persona?”
La desventaja es que el lado de negocio no entiende por qué no se puede desplegar esa app tal cual a producción
Va a aumentar la presión de “podemos ir más rápido con AI”, y al final parece que dependerá de una dinámica organizacional sana
La ventaja es que la idea está mucho más validada que un boceto en una servilleta
Claude probablemente ya preguntó por casos límite y decisiones de diseño, y es muy posible que en algún punto le hayan dicho explícitamente “no te preocupes por eso, asúmelo” o “después de usarlo unas veces, esta interacción no convence, cámbiala”
Ahora mismo la presión de “qué problema hay, solo súbelo a producción” es fuerte, tonta y desmoralizante, así que se acerca más a una pérdida neta, pero cuando se estabilice podría volverse una ganancia neta para proyectos futuros
Esos ajustes menores son cosas como que el layout se rompe si el navegador no mide exactamente 1920px de ancho, que los filtros y el ordenamiento a veces no funcionan bien, o que después de cierta acción el nuevo valor no se actualiza correctamente en la app
Sin importar el problema, el lado de negocio cree que ya hizo el 95%, así que asume de antemano que “un desarrollador con experiencia lo arreglará rápido”
La gente se acostumbra al resultado que ya tiene y luego le cuesta más aceptar los cambios en una nueva mezcla profesional
Hay PM, CSM y TAM que sí tienen el criterio para traducir el problema del cliente en funcionalidades de producto usables, pero si se saltan la definición del problema y hacen que otra organización funcional construya la solución, normalmente termina siendo un desastre que desperdicia muchísimo esfuerzo de ingeniería y otros recursos
Si alguien llega ya con una solución, corres el riesgo de pasarte meses construyendo software operable para descubrir después que al cliente no le gusta, que no resuelve el problema o que creó uno nuevo
No donde trabajo ahora, sino en un lugar donde estuve antes, y lo subieron a producción tal cual con pérdida de datos y problemas de seguridad
Según entiendo, Jane Street es inversionista de Anthropic, así que hay que tener eso en cuenta
También está el hecho de que en julio de 2025 la SEBI, el regulador bursátil de India, afirmó que Jane Street manipuló el mercado usando varias entidades y le prohibió el acceso al mercado
Supongo que una gran máquina de hacer dinero necesita muchos dashboards
Aquí el diseñador parece estar tomando un enfoque equivocado, como si hubiera caído en una especie de envidia de ingeniería y quisiera que el prototipo fuera lo más profundo y realista posible
Pero esa no es la parte más importante del trabajo de diseño
Lo más importante es que se construya lo correcto
Preguntas como “¿por qué hace falta una caja de entrada JSQL? ¿qué es lo que realmente se quiere? ¿qué otras formas hay?” muchas veces se resuelven mejor con bocetos en papel, reuniones, observación y discusión
Es mejor eso que cerrarse demasiado rápido a un diseño específico y terminar discutiendo si el botón va a la izquierda o a la derecha, o cómo debe comportarse en detalle el LLM
Aunque claro, también podría ser exactamente eso lo que quieren que pensemos
A veces se nota esto
Los LLM actualmente no ven más allá de la iteración presente, así que tengo que pensar fuera del marco y decir “¿y si lo vemos desde este ángulo?” para que de pronto aparezca una forma nueva de diseño
A veces incluso hay que hacer un diagrama de flujo para que el LLM pueda ver más allá de la etapa en la que va
Cuando dice “Claude me dio iteración gratis e ilimitada, sin molestarse aunque cambiara de opinión por quincuagésima vez o pidiera un ajuste pequeño”, ¿significa que no paga Claude?
Los estudios de diseño pequeños también suelen funcionar parecido, y muchas veces no cobran por hora como los desarrolladores
Respondí honestamente que soy realmente malo para diseño y que también tengo problemas para extrapolar sistemas de diseño
Me cuesta muchísimo llegar a un punto que se vea aceptable, y en el proceso casi siempre termino empeorándolo
La diseñadora que me entrevistaba se lo tomó como algo personal y se me fue encima
Ya me había pasado antes algo parecido
A los diseñadores no les gustaban las preguntas constantes sobre cómo debía verse algo, y querían una entrega tipo “te lo paso una vez y listo”
Incluso en agencias de marketing y publicidad tuve que pelear constantemente para que me dieran muestras de cómo debían verse cosas que no estaban en la especificación de diseño
No digo que yo tuviera razón, pero para mí es un gran talón de Aquiles
Así que cuando oigo “gratis, iteración ilimitada, sin molestarse”, antes que el dinero pienso en tiempo y paciencia
Bolt, que uso para hacer prototipos, no se enoja
Tal vez no produzca el mejor diseño posible, pero es muchísimo mejor que lo que yo podría hacer, y al final se le puede dar a un diseñador de verdad para que lo mejore
Hasta entonces, no tengo que preocuparme por hacer enojar a nadie
He estado usando Claude Design para frontend
La apariencia y la sensación del resultado son suficientemente buenas, pero los diseños suelen verse parecidos y en general siguen patrones trillados de la web moderna
Me pregunto si alguien ha logrado hacer intentos creativos no convencionales con esto
Hasta ahora le he dedicado unas 3 semanas y todavía no está terminado, pero se entiende la idea
Así como en la última década existió el boilerplate de SaaS, también existe un boilerplate de LLM entrenado con internet
Aun así, si le metes suficiente mano, sigue siendo posible hacer cualquier cosa
Me parece interesante que si le das requisitos, los sigue, y si no le das dirección, toma decisiones seguras
Si vas a evaluar la estética del output y la experiencia de usuario y el contenido, pero casi no das prompts sobre la parte estética, solo vas a recibir valores seguros por defecto
Hace bien diseños con esa sensación de copia de bootstrap/tailwind, pero hay que empujarlo conscientemente en esa parte
En páginas web simples, empecé a poner el estilo visual como único foco de las iteraciones iniciales
Basta con indicarle específicamente que no se vea estándar y darle ejemplos del estilo de sitios web que quieres
Si peleas un poco con eso, se siente algo más creativo, pero requiere trabajo de prompt
Me lo recomendaron diseñadores muy respetados y con mucha experiencia, y ellos ahora hacen prototipos casi por completo en Claude y, si les gusta, luego lo pulen en Figma
Desde el inicio, si pides una UI genérica sin un prompt de estilo detallado, es obvio que va a salir un diseño genérico
La ventaja aquí es que los diseñadores aprendan a programar
Siempre me pareció raro que un diseñador moldeara software sin saber cómo se construye el software
Para que conste, yo también soy diseñador
Pero diseñar en código es un enfoque de la tecnología primero
Si el objetivo del diseño es dar forma a un resultado de acuerdo con objetivos humanos, también se puede argumentar que es mejor no empezar desde las reglas estrictas del código
No por lo bonito del resultado, sino porque para empujar el pensamiento hacia adelante sigue siendo difícil ganarle al papel y lápiz
Ahora que prácticamente ya se puede programar con la voz, estoy volviendo otra vez al vibe coding y a crear productos, y se siente increíble
Mi jefe todavía está tratando de entender esta nueva situación, pero parece que la vieja separación de roles ya empezó a morir
Creo que estar en la intersección es el mejor lugar ahora mismo
Siento que toda mi vida me preparó para este momento
Para un diseñador, probablemente se parezca a Figma, pero viendo el resultado y corrigiéndolo con lenguaje en vez de con un editor visual
Mi esposa trabaja como product manager en una FAANG, y su equipo depende muchísimo de usar AI para vibe codear piezas de software que antes habrían hecho con algo como Word o Excel
No aprenden a programar ni miran el código ni por un segundo
El enfoque de “el prototipo es un documento de propuesta vivo, el código se puede desechar y el trabajo del revisor es dar feedback sobre el diseño y la experiencia de usuario
Al final, el revisor toma la idea y la implementa como una funcionalidad aparte, usando el prototipo como referencia, pero siendo dueño directo del código de producción” resuelve un problema que yo tenía en todos los POC
Es una forma realmente buena de trabajar
Cuando estás tratando un problema específico de un producto específico, es fácil llamarlo un “documento de propuesta”
Pero aun así muchísimos diseñadores siguen usando Figma para definir y mantener sistemas de diseño a lo largo de productos y plataformas enteras, y en esos casos Figma es la fuente de verdad
En mi equipo también trabajamos así, y yo soy ingeniero frontend, pero honestamente extraño muchísimo la forma anterior
Como las especificaciones escritas fueron reemplazadas por prototipos funcionales, ahora existe una carga cognitiva extra: tengo que leer el código y decidir cuál es el cambio intencional y qué ruido hay que desechar
Me pasan un PR generado y tengo que decidir si hago los cambios necesarios sobre eso o si lo rehago desde cero, y en ambos casos hay fricción
A veces se generaron un montón de cambios no intencionales, yo dediqué tiempo a reimplementarlos, y después más tarde llega el “ah, perdón, eso no era algo que queríamos cambiar”
Entiendo que esto da más autonomía, pero también le quitó parte del disfrute que sentía en mi trabajo y lo convirtió en un dolor de cabeza
Diseño y producto hacen vibe design/vibe coding de funcionalidades o experiencias con Claude, arman prototipos rápido y los llevan frente a clientes para recibir feedback con el mínimo tiempo de ingeniería posible
Eso está buenísimo
Pero puede sorprender que, en conjunto, no haya ayudado mucho a lanzar más rápido
Creo que la razón es que en el proceso se perdió pensamiento
Una parte nada menor del razonamiento ahora está tercerizada al modelo de lenguaje
Tapa los huecos del prompt y rellena con alucinaciones los comportamientos no especificados
Antes uno se detenía con cosas como “esto no termina de encajar”, “¿cómo comunico esta idea?”, “¿qué pasa en este caso?”, pero ahora eso desapareció y esos detalles se empujan para después, cuando ya está construido
Claro que podemos mejorar el proceso y revisar cómo aprovechar mejor esta nueva técnica, pero no sé si de verdad sea mejor que antes
Está quedando obsoleta
Ahora la gente de backend también hace frontend
Esa es la confusión
¿Te pones a mirar el ensamblador generado por el compilador? No
Entonces, ¿por qué estás mirando este código?
Lo que hicimos fue subir el nivel de abstracción
Yo también uso mucho el mismo enfoque
Incluso antes de la IA lo hacía así, de forma manual
Primero me sentaba con el usuario con solo pluma y papel, y después armaba rápido un POC o demo de frontend, dejaba que el usuario lo probara y luego lo ajustaba hasta que funcionara como quería
Para mí, hacer en código un demo rápido de frontend, no con calidad de producción, muchas veces ya era más rápido que crear interacciones precisas en Figma
Como permitía una interacción completa, podía detectar muchos más casos límite del lado de la experiencia de usuario
Ahora, gracias a Claude Code, hacer prototipos desechables se volvió más rápido, pero no es una diferencia enorme
Como el 80% del tiempo total se va en hablar con el usuario y pensar cómo debería funcionar, Claude más o menos reduce a la mitad el 20% restante frente a cuando lo construyo rápido yo mismo
La primera versión sale más rápido, pero iterar es más lento cuando no lo has entendido por completo
Edwin, qué gusto ver que publicaste esto
Recuerdo que participamos juntos en un hackatón por ahí de 2012/2013
La capacidad de llegar más rápido a un prototipo funcional da muchísimo impulso, incluso si existe la tentación de publicar tal cual una idea todavía incompleta
El diseño y los requisitos de experiencia de usuario se benefician enormemente cuando puedes ir más allá del storyboard y el wireframe, y tocar y experimentar el flujo real