Nunca había empezado por el wireframe. Dejé que Claude Code orquestara todo.
Probé tres herramientas de IA para wireframes, encontré que solo una tenía escritura real, y terminé descubriendo que el verdadero resultado no era cuál tool ganaba, sino que Claude Code podía sostener todo el flujo: wireframe, diseño, código y revisión de UX en un viewport real.
El plan
Llevo años trabajando en distintas capas de una aplicación: empecé en backend, después full stack, después devops, y en cada fase terminé metiéndome un poco más en el pedazo que seguía, hasta llegar a construir dev tools para mi propio equipo. Lo único que nunca hice fue arrancar un proyecto desde el wireframe. La única vez fue en la universidad.
Con más experiencia encima, quería vivir esa parte del proceso de verdad: los retos reales de partir de una hoja en blanco, no de un backend ya definido. Así que antes de tocar código investigué apps, herramientas, MCPs, agentes, skills y hasta filosofías de diseño distintas. Arranqué instalando el skill oficial frontend-design de Anthropic para Claude Code, y de ahí seguí probando.
Lo que venía posponiendo era justamente esto: decidir de verdad qué herramienta para wireframes/diseño usar, en vez de leer comparativas y quedarme con la primera que sonara bien. Y hay un motivo extra para resolverlo ahora, no solo curiosidad: en paralelo estoy armando trabajo freelance (mockups de cliente, iteración rápida de UI) donde esa decisión también importa. Probar las herramientas yo mismo, con Claude Code como el que las opera, y ver cuál sobrevive el primer intento real.
Mi portfolio iba a ser el conejillo de indias. Wireframes primero, después diseño hi-fi, después código. Todo orquestado desde la misma sesión de Claude Code, sin salir a copiar y pegar entre herramientas a mano.
Antes de escribir una línea de código, probé tres herramientas de IA para wireframes. Solo una tenía escritura real.
Paso 0: elegir referencias antes de tocar una herramienta
Antes de abrir cualquier tool, elegí 4 portfolios reales y anoté exactamente qué me gustaba de cada uno, no "inspiración" en general:
- Leland Jansen: el hero, cómo arma las páginas de detalle de cada proyecto, y la sección About con espacio para hobbies, no solo lo profesional.
- Tom Weightman: la sección Notes, solo texto, sin necesidad de multimedia para que una idea funcione.
- Tamal Sen: diseño con carácter, la sección Professional Experience, y un cierre de contacto con recomendaciones de terceros.
- Irene Alvarado: el grid de Work con GIFs en vez de fotos estáticas, y un About limpio.
Esto terminó siendo el ancla real del proyecto. Sin una referencia concreta, cualquier herramienta de IA para diseño tiende al mismo output genérico, sin importar cuál elijas después.
Intento 1: Balsamiq. El README miente
Empecé por Balsamiq porque tiene MCP server (balsamiq-bmpr-mcp) y el nombre ya lo conocía de otros trabajos. El README decía npm install -g balsamiq-bmpr-mcp. Corrí eso y:
npm error 404 Not Found - GET https://registry.npmjs.org/balsamiq-bmpr-mcp
El paquete nunca se publicó a npm, pese a estar documentado como la forma de instalar. Cloné el repo a mano y lo compilé. Ahí vino el segundo golpe: el servidor es solo lectura. Expone tools para leer archivos .bmpr ya creados, no para generar ni editar nada. El wireframe hay que armarlo primero en Balsamiq Cloud o Desktop, a mano, y el MCP solo le da a Claude ojos sobre el resultado.
Es decir: ni instalación documentada correctamente, ni escritura. Descartado en quince minutos.
Si alguien lo llegó a instalar como dice el README, contame cómo. Con gusto lo reintento.
Intento 2: Whimsical. "Contactá a soporte"
Whimsical tiene un MCP oficial que corre a través de su app de escritorio. Fui a la documentación (whimsical.com/learn/integrations/mcp) buscando el comando de instalación y me encontré con esto: no dice qué sistemas operativos soporta la app, y para configurar el MCP la doc dice literal "reach out to our support team".
Sin ruta self-service, sin confirmación de que corre en Linux. No iba a esperar un ticket de soporte para probar una herramienta que ni siquiera sabía si iba a levantar en mi máquina. Descartado sin instalar nada.
Intento 3: Penpot. Ahí sí
Penpot tiene MCP server oficial (@penpot/mcp), dos modos de conexión (local con npx @penpot/mcp@stable + plugin cargado en el browser, o remoto contra Penpot Cloud con un token), y expone tools reales de escritura: execute_code corre JS contra el Plugin API completo. Ahí sí pude construir.
El servidor no corre un LLM propio, ojo, eso lo confirmé viendo el log de arranque. Es puente de datos hacia el cliente MCP que ya tenía corriendo (Claude Code). El razonamiento de diseño lo hacía yo, con Claude Code operando el plugin.
# pensando en voz alta:Acá está lo que más me sorprendió de todo el ejercicio: no esperaba que la integración vía MCP fuera tan simple. Pasar una idea que tenía en la cabeza a algo que ya podía ver en pantalla, real, editable, fue mucho más directo de lo que pensé después de años sin tocar esta parte del proceso.
Construir los tres wireframes (Home, About, Writing) vía execute_code no fue sin fricción:
penpot.createText()no acepta creación vacía seguida de asignar.charactersdespués, aunque la doc del tool lo sugiere así. Hay que pasarle el string en la creación misma o tiraValue not valid. Code: :createText.alignItemsusa vocabulario propio de Penpot ('start','end'), no el de CSS flexbox ('flex-start'tira error).- El auto-sizing de un board con flex layout, después de remover shapes hijos, no se refleja de inmediato. Exporté una captura justo después de sacar una sección y salió con un hueco enorme donde el board todavía no había recalculado su altura. Hubo que esperar un par de segundos antes de confiar en los bounds.
Los tres wireframes finales en Penpot (Home, About, Writing)
Grabación del proceso de armado en Penpot
Tres herramientas, un paquete roto, un soporte inexistente, un ganador. Recién ahí arrancó la parte de código.
De wireframe a diseño real: Kombai
Con los wireframes de Home aprobados, pasé a Kombai Code para la exploración hi-fi y la generación de código de la página Home: Astro + Tailwind v4 + TS, tema "Terminal Elegance" (dark, estilo VS Code).
Recorrido del tema Terminal Elegance elegido para Home
About y Writing las armé a mano, replicando el mismo sistema de diseño que generó Kombai para Home, pero explorando un tema distinto: "Stark Monolith" (light, acento rojo). Antes de decidir, comparé tres variantes lado a lado: la actual (light + rojo), una versión dark, y una versión light + cyan.
About - comparación de temas
Writing - comparación de temas
Writing con el tema light + rojo final, scroll completo
Terminé quedándome con dual-theme: Home dark, About/Writing light + rojo. Para que un navbar compartido entre páginas dark y light cambiara de paleta sin duplicar componentes ni pasar props de tema, usé el patrón de Tailwind v4 de mapear utility classes a custom properties CSS (--color-editor-bg: var(--editor-bg) en @theme inline) y una clase wrapper (.light-section) que remapea esas properties. La cascada de CSS custom properties resuelve el valor final en runtime, por elemento del DOM. Ningún componente necesita saber en qué tema está parado.
Claude Code no solo escribió el código. También encontró los bugs
Acá está el punto real del post, más que Penpot vs Kombai: Claude Code fue el mismo actor en todo el flujo. Operó el MCP de Penpot para los wireframes, tomó el código que salió de Kombai para Home, escribió a mano About y Writing matcheando ese sistema, y después hizo la revisión de UX que normalmente haría yo a ojo en el browser.
Probando en 2560px (ultra-wide, mi monitor real) aparecieron problemas que en una laptop de 1440px no se veían:
Home y About a 2560px, antes del fix
El diagnóstico: navegación rota fuera de Home (los links de EditorTabs solo funcionaban desde la home), texto mono en 10-11px ilegible a esa resolución, contenedores topeados en un ancho que dejaba media pantalla vacía en monitores anchos, CTA del hero con fill transparente que casi no se distinguía del fondo, y el hero creciendo en altura vacía a medida que crecía el viewport en vez de toparse.
El fix: EditorTabs corregido para funcionar desde cualquier página, texto mono subido a 12-14px con peso medium, contenedores ensanchados a 2xl:max-w-[1800px], CTA con fill sólido cyan y copy cambiado de "start a project" (enmarcado como freelancer) a "View work", y el hero con altura mínima topeada en breakpoint 2xl para que dejara de crecer con el viewport.
Lo que me llevo
El veredicto no fue un tool contra el otro, fue una cadena: Penpot no compitió con Kombai, lo alimentó. El wireframe que armé en Penpot lo llevé como referencia y contexto directo a Kombai, y de ahí salió el código real de Home. Para esa segunda parte, diseño a código, Kombai ganó sola: fue la que produjo algo usable con pocos ajustes.
# pensando en voz alta:Eso lo esperaba. Lo que no esperaba era que el hallazgo real no fuera "Penpot gana" ni "Kombai gana", sino confirmar que Claude Code puede sostener el flujo completo, de wireframe a revisión de UX en un viewport real, sin que yo tenga que ser el pegamento entre herramientas.
Para el trabajo freelance que viene, me quedo con las dos, no con una sola: Penpot para explorar layout a mano y dejar esa exploración como contexto, Kombai para llevarlo a código real. Lo que importa no es cuál herramienta de mockup es "mejor" en abstracto, sino cuál se deja operar de punta a punta por el mismo orquestador que después escribe y revisa el código.