Show HN: screenshot-to-code - convierte capturas de pantalla en código HTML limpio usando GPT Vision (herramienta OSS)
(github.com/abi)- Es una herramienta que usa IA para convertir capturas de pantalla, mockups, diseños de Figma y grabaciones de pantalla en código limpio y funcional
- Los stacks compatibles son HTML + Tailwind, HTML + CSS, React + Tailwind, Vue + Tailwind, Bootstrap e Ionic + Tailwind
- También admite una función para recibir grabaciones de pantalla que muestran el funcionamiento de un sitio web y convertirlas en prototipos funcionales
- Los modelos de IA predeterminados son Gemini 3 Flash Preview, Gemini 3.1 Pro Preview, GPT-5.5, GPT-5.4 Mini, Claude Opus 4.6 y Claude Opus 4.8; para generación de imágenes usa z-image-turbo basado en Replicate
- Para ejecutarlo localmente se requieren claves de API y configurar backend y frontend, y la estructura de la app es un frontend con React/Vite y un backend con FastAPI
- Se necesita al menos una clave de proveedor de modelos entre OpenAI, Anthropic o Gemini
- Gemini extrae logos e imágenes reales de las capturas de pantalla y es necesario para el modo de video
- Replicate habilita edición de imágenes, eliminación de fondo y generación de imágenes basada en Replicate
- Si agregas más claves, el sistema elige automáticamente combinaciones de modelos más potentes según cada variante; si solo hay una clave, usa únicamente los modelos de ese proveedor
- La función opcional de screenshot preview renderiza la página generada en un navegador headless para verificarla visualmente después de instalar Chromium; si Chromium no está disponible, esa herramienta se omite
- Admite ejecución en desarrollo local, uso de la app alojada y ejecución con Docker; al ejecutarse con Docker, la app corre en
http://localhost:5173
1 comentarios
Opiniones de Hacker News
Esto realmente parece magia, y no sé dónde ubicarlo dentro de mi modelo mental de cómo funciona la computación.
Entendía que decir que las redes neuronales son aproximadores universales de funciones significa que modelan conjuntos de funciones que mapean entradas a salidas de un dominio específico; ejemplos como MNIST me resultan conceptualmente aceptables.
Pero aquí me pregunto si el entrenamiento general de GPT implementa un mapeo de valores desde intensidades de píxeles hacia tokens de texto HTML+Tailwind, y el resultado de que el navegador interprete y renderice esos tokens termina aproximándose a la imagen de entrada.
Si es así, GPT estaría modelando no solo la conversión píxeles→HTML/CSS, sino también la forma en que un navegador renderiza HTML/CSS. Puedo aceptar que exista ese mapeo, pero me sorprende que GPT lo haya derivado mientras además escribe sobre muchísimos otros temas.
En términos más prácticos, también me pregunto si este tipo de herramienta puede verse como un compilador de diagramas, y si más adelante podría formar parte de un pipeline de build que reciba artefactos como los de Sketch/Figma y emita HTML/CSS/JS.
Un espacio latente es un espacio n-dimensional donde las ideas y conceptos se ubican más cerca cuanto más parecidos son entre sí, y esa disposición se crea a partir de los datos de entrenamiento durante el entrenamiento; por lo tanto, el proceso de entrenamiento es, en sí mismo, el proceso de crear el espacio latente.
Imagina una grilla 2D donde “house” y “mansion” están cerca, mientras que “growling” está en una esquina completamente distinta. Un espacio latente como el de GPT-4 es similar, pero con cientos o miles de dimensiones, y esa diferencia de escala permite ordenar de forma útil una enorme cantidad de conocimiento.
Volviendo a la lectura de imágenes, en los datos de entrenamiento había imágenes de páginas web y su código correspondiente, y ese código le indicó al proceso de entrenamiento dónde colocar esos pares código-imagen. Las etiquetas y los pies de imagen también ayudan a ubicar las imágenes en el espacio latente, igual que el texto.
Entonces, si le das a GPT-4 una imagen nueva de un sitio web y le pides el HTML correspondiente, puede colocar esa imagen en el espacio latente y recuperar el HTML correspondiente que está cerca.
Pero no dice nada sobre la posibilidad de entrenarla ni sobre la estructura necesaria, y esa estructura requerida podría ser irrealmente grande.
El algoritmo de entrenamiento usado, la retropropagación mediante descenso de gradiente estocástico, no es un aprendiz universal, ni garantiza encontrar el mínimo global.
Parece que la dirección es saltarse el paso de Sketch/Figma e ir directo a un prototipo ejecutable.
La perspectiva de “puede ajustar cualquier función” es correcta, pero no te dice si realmente puede hacerlo con recursos finitos, así que por sí sola no me parece muy útil.
Lo sorprendente ahora no es el aproximador universal que existe desde hace tiempo, sino que aproxima tan bien conceptos abstractos, y la respuesta está en la escala de los datos.
Existe la idea de que la compresión es inteligencia, y estos modelos pueden verse como buenos compresores. Durante el entrenamiento, los pesos tienen un tamaño fijo y son mucho más pequeños que los datos que intentan ajustar; si el objetivo es reconstruir el original, es decir, predecir el siguiente token, no hay otra forma que comprimir muy bien los datos.
Cuanto más inteligente es, mejor predice y comprime; y si se lo obliga a comprimir, en la práctica se lo obliga a adquirir inteligencia. Es parecido a prepararse para un examen: puedes memorizar respuestas, pero si hay miles de preguntas y no puedes memorizarlas, lo mejor es aprender la materia y derivar las respuestas durante el examen.
Esta dualidad compresión/inteligencia es polémica para quienes niegan la capacidad de generalización de los LLM, pero es mi modelo mental actual y todavía no lo he refutado.
Si aceptas esta perspectiva, las capacidades multimodales se vuelven más bien un problema de ingeniería. No sé exactamente cómo es GPT-4V por dentro, pero podemos inferirlo a partir de investigaciones multimodales públicas.
Si tienes pares de una imagen y el texto que la describe, tokenizas/embebes la imagen igual que el texto. Como en ViT (Visual Transformer), puedes convertir la imagen en características visuales por parches y formar una secuencia larga.
Si le das ese embedding a un LLM preentrenado y lo obligas a predecir el texto descriptivo de la imagen, no le queda otra que obtener una comprensión general de la imagen a partir del embedding de la imagen.
Una vez que puede entender la información de una imagen dada y expresarla en lenguaje natural, basta con hacer instruction tuning para que use esa comprensión.
Los modelos generativos de imágenes como Stable Diffusion funcionan de forma parecida: entrenan modelos contrastivos como CLIP para acercar embeddings de imagen y embeddings de texto del mismo concepto, y usan esa información dual para controlar la dirección de la generación.
Lo sorprendente es que ya tenga capacidades de esta escala, y que pueda obtener más capacidades solo con más cómputo. Si la pérdida final actual de GPT-4 fuera 1, es muy probable que sea mucho más capaz cuando de alguna forma se pueda bajarla a 0.1.
Sobre la segunda pregunta, parece ir en esa dirección, y probablemente ya sea posible.
La clave está aquí: https://github.com/abi/screenshot-to-code/blob/main/backend/...
El prompt le indica que actúe como un experto en Tailwind para el usuario y que, viendo la captura, cree una app de una sola página con Tailwind, HTML y JS.
Incluye instrucciones como igualar con precisión el color de fondo, el color del texto, el tamaño de fuente, el padding, el margen, los bordes, etc.; usar tal cual el texto de la captura; “escribe todo el código”; respetar la cantidad de elementos repetidos; no omitir nada con comentarios; usar imágenes de placehold.co y poner una descripción detallada en el alt.
Dice que se puede usar Tailwind desde
https://cdn.tailwindcss.com, Google Fonts y Font Awesome, y que devuelva todo el código solo dentro de las etiquetas, sin usar fences de código Markdown.Personalmente, no creo que el prompting defensivo sea el camino a seguir, pero que esto funcione es realmente impresionante. Se siente como si algo que soñaba de adolescente ahora fuera posible con relativamente poco esfuerzo.
siguen instrucciones de forma inestable, generan bugs y se arreglan gritándole a la máquina.
Si veo una vez más “este es un desafío complejo”, creo que voy a hartarme de verdad. A veces es mejor un modelo menos “flojo”, aunque solo tenga 60% de rendimiento. Para que use el 40% restante de su capacidad hace falta más ingeniería de prompts, y eso se siente menos como una limitación técnica y más como una degradación intencional.
Aun así, sigue siendo una exigencia difícil para los competidores, así que por ahora gana OpenAI.
Claro que sigue siendo increíblemente genial y útil, así que si aparece competencia que realmente lo logre en vez de solo quejarse, los próximos años van a ponerse interesantes.
Sería bueno agregar “hacer esto bien es muy importante para mi carrera”.
No lo encuentro ahora, pero según algún video de investigación en YouTube, eso mejoró de forma notable la calidad de salida en varias tareas.
Según el estudio, los prompts con lenguaje emocional produjeron, en general, una mejora de rendimiento del 8% en tareas como “convertir una oración a lenguaje formal” o “encontrar características comunes de los objetos dados”.
Ahora no sé cómo pensar qué debería construir.
No es para nada una crítica a este proyecto, y agradezco que el código sea abierto, pero ahora hay toda una familia de problemas que parecen bastante fáciles de resolver, y eso da la sensación de “¿para qué hacerlo?”.
Creo que hay que recalibrar el planteamiento de los problemas, tanto en qué vale la pena resolver como en cómo resolverlo.
Si una herramienta así puede producir “código suficientemente bueno” que solo necesite un poco de pulido, es un gran ahorro de tiempo.
Si simplemente entrega código desordenado, es menos útil.
Los tecnólogos tienden a obsesionarse demasiado con las herramientas que usan. No sé cuántos proyectos vacíos y completamente ordinarios de “hello world” he visto exhibidos solo porque forzaron la unión de Framework A con Toolkit B; es realmente aburrido.
La razón por la que la tecnología basada en LLM es desafiante en este contexto es que obliga a repensar las posibilidades mismas. Si la herramienta es de propósito general, crear una simple demo no tiene mucho sentido.
Lo sorprendente, por supuesto, es que esto funcione con un modelo de propósito general, pero generar datos de aprendizaje supervisado para esta tarea parece bastante fácil.
Generar HTML → renderizarlo y tomar una captura → usar esos datos al revés para entrenar.
En la página de GitHub dice que planean ofrecer una versión hospedada a través de Pico, y me da curiosidad por qué eligieron Pico.
Acabo de conocer Pico por esa página, y parece que Pico solo paga el 30% de los ingresos. Es la mitad del 60% típico de las tiendas de apps y, según entiendo, solo se paga cuando usuarios gratuitos prueban una app y luego se registran; si la usan usuarios que ya estaban en la plataforma, no se paga.
Las condiciones parecen mucho peores que las de las plataformas tradicionales y la base de usuarios también parece más pequeña, así que me da curiosidad el motivo de la elección.
Además, Pico es una plataforma general para crear apps web. La parte del 30% de ingresos aplica solo a afiliados, no a pagos dentro de la app. Pico todavía no soporta pagos dentro de la app.
No entiendo bien el punto. Si se trata de copiar un sitio web existente, no sé por qué no usar Httrack.
El sitio web original siempre se va a parecer más, y te ahorras el costo de la API de GPT. Donde esta técnica brilla es al pasar de un boceto a un sitio web.
Me encantó la forma en que muestra de inmediato la demo del sitio web generado mientras se está creando, usando un iframe con
srcdoc.Simple y elegante.
Si ignoramos los detalles de implementación de la “IA”, esto genera HTML en un sentido parecido a convertir una imagen ráster en un SVG que se ve pésimo al ampliarlo y hace que el renderizador dibuje líneas y rellenos innecesarios.
Es decir, el resultado no parece lo suficientemente limpio como para pasárselo a un desarrollador web. Probablemente el desarrollador tendría que reescribir casi todo, salvo la estructura superior más obvia, para la cual de entrada no hace falta una herramienta avanzada y un plugin de snippets en un editor de texto lo haría mejor.
Gran parte del desarrollo web ni siquiera es visible. La accesibilidad es metadatos que no se pueden obtener de una captura de pantalla, y el CSS responsivo requeriría un video que incluya todos los comportamientos, animaciones, etc., sin omitir nada.
JavaScript parece casi imposible de determinar con cualquier cantidad de reconocimiento de imágenes.
¿No sería mejor simplemente copiar el HTML real directamente desde las herramientas de desarrollador?
Creo que acelerará mucho la creación de sitios de phishing.