"Creo que voy a tener que ir a acostarme un rato."

• Impresiones tras probar la demo de Make Real de TLDraw
• Una herramienta que usa IA para convertir dibujos en software funcional
  • Convierte imágenes vectoriales a HTML/TailWind CSS y Javascript usando GPT-4V de OpenAI

[GN⁺]

Opiniones de Hacker News

• Soy Steve, de tldraw. Perdón, esto es un proyecto de juguete con patrones de seguridad pésimos. Si quieren ejecutarlo localmente o ver el código fuente, está aquí: https://github.com/tldraw/draw-a-ui
  Pueden ver otros ejemplos en https://twitter.com/tldraw. Puedo responder preguntas sobre tldraw o sobre este proyecto. No es algo que vaya a quitarle el trabajo a alguien, pero es muy divertido para jugar, y hay un ejemplo más complejo aquí: https://twitter.com/tldraw/status/1725083976392437894

  • Deberían lanzarlo ya mismo. Esto es de verdad un producto brillante, podrían cobrar US$5 al mes y hacer que los usuarios traigan su propia clave de OpenAI.
    También tengo un servidor de licencias que acabo de publicar con licencia MIT. Está escrito en Elixir y ejecuta https://go.robocoder.app. Si necesitan ayuda con la configuración, pueden contactarme: https://github.com/emcmanus/robocoder-server/
  • Steve, ¿a dónde mando el dinero? Bromas aparte, es algo bastante convincente. Tal vez sea un juguete, pero todos se están divirtiendo así.
  • Gran proyecto y felicidades por el lanzamiento. Probé poner mi clave de OpenAI y me dio el error "you exceeded your current quota, check billing". Me preguntaba si con una suscripción OpenAI Pro de US$20 al mes alcanza, o si se necesitan permisos adicionales.
    Encontré la respuesta en el README de GitHub. Dice: “Para usar tu propia clave de API, necesitas acceso a usage tier 1; puedes revisar tu tier actual y cómo subirlo en la configuración de OpenAI”.
  • Ese ejemplo del diagrama de flujo es realmente el punto clave, y creo que en herramientas como esta debería tratarse como un concepto de primera clase. Empieza a ofrecer agarraderas que permiten crear algo útil, no solo un juguete.
  • El último ejemplo es interesante, y sorprende que se pueda dar feedback de esa manera. Me pregunto qué recibe realmente como entrada cuando seleccionas juntos la app generada y el texto. ¿Recibe el código generado antes junto con el texto nuevo?

• El prompt del sistema que está en el repositorio es este:

  You are an expert tailwind developer. A user will provide you with a  
  low-fidelity wireframe of an application and you will return  
  a single html file that uses tailwind to create the website.  
  They may also provide you with the html of a previous design that they want you to iterate from.  
  Carry out any changes they request from you.  
  In the wireframe, the previous design's html will appear as a white rectangle.  
  Use creative license to make the application more fleshed out.  
  if you need to insert an image, use a colored fill rectangle as a placeholder. Respond only with the html file.  
  

  No estoy muy seguro de por qué se menciona "creative license" aquí. En cada generación, el prompt del usuario es el siguiente:

  [IMAGE_LINK]  
  Turn this into a single html file using tailwind.  
  

  https://github.com/tldraw/draw-a-ui/blob/8a889bf36afc06fbb0c...
  Parece lo bastante simple como para hacerlo correr “en privado” tomando una captura de un canvas común de tldraw y pasándola a la API junto con este prompt.

  • "creative license" en inglés común significa no preocuparse demasiado por las restricciones y hacer lo que parezca mejor. No parece tener relación con una licencia de software.

• Probé meter un mockup de una pregunta de entrevista de Facebook. Tenía dos listas de checkboxes y dos botones para mover los elementos marcados de un lado al otro, y lo resolvió bien: https://gist.github.com/milesrichardson/2a2f77d4bfb19c3b28dc...

  • No tenía idea de que toList.appendChild(item.closest('li')); moviera el elemento. Todos los días se aprende algo.
  • Lo probé con un lector de pantalla y, al presionar el botón, no se anuncia nada. Eso es un problema. Debería decir algo como “Checkbox B moved to the left”.
    Sin ningún anuncio, el usuario no puede saber si realmente pasó algo al presionar el botón. Página de prueba: https://output.jsbin.com/jixoqur/quiet

• Estas demos recientes muestran lo impresionante que ha sido el avance reciente del machine learning/IA, pero al mismo tiempo también muestran cuántos millones de desarrolladores en todo el mundo siguen reimplementando una y otra vez trabajo repetitivo y poco original.
  La mayoría de las pantallas de UI se pueden describir con precisión en uno o dos párrafos, así que no sorprende que puedan representarse con bastante detalle dentro de un vector de embedding relativamente pequeño.

  • Estoy de acuerdo con la dirección general, pero también es importante señalar que la mayoría de estas demos son casos cuidadosamente seleccionados. Si uno solo ve demos virales en redes sociales, puede terminar creyendo que la IA está mucho más adelantada de lo que realmente está en tareas complejas.
    Los perfiles no técnicos que no han usado IA de forma intensiva en trabajo real son especialmente vulnerables a esto. Quienes la viven en la práctica suelen verla con más matices. Es tremendamente útil, pero también comete muchos errores, y para obtener resultados de nivel producción hay que ajustarla con cuidado. Incluso como optimista de la IA, creo que el valor es real y las demos impresionantes muestran hacia dónde vamos, pero todavía tomará tiempo que el resultado promedio alcance las expectativas infladas.
  • Muchas formas de expresar ideas de software también son muy ineficientes. La parte realmente interesante, es decir, la entropía, es muy pequeña.
    En esta demo son literalmente dos sliders que ajustan dos propiedades de CSS, así que la especificación de la UI no contiene mucha información. Con un lenguaje adecuado para especificar UI, habría sido código de tres líneas. La dificultad viene de tener que manejar todo el boilerplate de una UI web.
  • Esto expresa muy bien por qué me incomodaba el hype de IA B2C montado sobre cientos de demos tipo “Hello World”. La vibra era como “¡Dios mío, la programación está muerta!”.
    Lo raro es que en HN, cuando se habla de plataformas no-code tradicionales, todos detectan fácilmente sus límites de escalabilidad y mantenimiento, pero cuando se les agrega IA, de pronto parece que esos problemas se resolvieron y ya no hay que preocuparse por el espagueti que escupe una caja negra.
  • Esto solo revela lo absurdo que es nuestro stack de software. Todo funciona bajo la lógica de “quizá quieras personalizar esto y aquello, y también otros 300 detalles inútiles”.
    Lo que en realidad queríamos era separar funcionalidad y presentación. Casualmente, la web de HTML puro de 1996 era exactamente eso. Algo salió terriblemente mal de una forma inimaginablemente absurda, y nadie mejoró nada. En su lugar, nos quedamos con sombras y flexbox internos.
  • Que se reimplemente una y otra vez trabajo repetitivo y poco original no es un problema exclusivo de los desarrolladores. Desde captura de datos hasta contabilidad y trabajo creativo, esto aplica a la mayor parte del trabajo de oficina.
    Una parte considerable del trabajo de oficina consiste en repetir las mismas tareas una y otra vez, y en muchas empresas distintas hay personas repitiendo trabajos que en esencia son los mismos.

• Esto parece una herramienta para hacer que los diseñadores de UI, o quizá los product owners, parezcan inteligentes y competentes. Pero el trabajo real seguirá yendo a los programadores, como ahora.
  El diseñador de UI podrá entregar una “demo”, pero ¿cómo se conectará esa funcionalidad básica con el resto de la app? No lo hará.

  • Seguro terminará en conversaciones agradables y productivas del tipo: “¡Pero si ahí ya está funcionando! ¿Por qué tardan tanto en meterlo en la app? ¿No pueden simplemente descargarlo?”.
    Desde antes de GPT ya existía el argumento de que los prototipos o mockups muy tempranos deberían verse visualmente tan poco terminados como corresponde al nivel de funcionalidad interna. Los prototipos bonitos y aparentemente “funcionales” pero solo de UI generan expectativas poco realistas aunque se expliquen claramente, y aumentan la probabilidad de la proto-ducción, donde el prototipo termina convirtiéndose tal cual en producción.
  • No me gusta que los diseñadores muestren en Figma una UI que parece producto terminado. Para los ejecutivos se ve como un producto completo, y eso mete expectativas poco realistas en un proceso de diseño de UI que debería ser iterativo.
    He visto varios proyectos donde, por las restricciones de un diseño de Figma aprobado por algún ejecutivo, se les terminó imponiendo a los ingenieros un diseño de sistema pésimo. Claro que esas organizaciones tienen problemas más grandes, pero los mockups de alta fidelidad fáciles de hacer empeoraron este problema más que los wireframes.
  • El método es simple. Dale un nuevo prompt a GPT-4: "Thanks. Please connect it to the rest of this code:"
    Si quieres que lo haga mejor, agrega también "it's very important for my career".

• Los desarrolladores que hacen demos para agrandar y rotar cajas están a punto de quedarse sin trabajo.

  • Solo los que ni siquiera pueden alinear sliders.

• Mientras hablábamos con un cliente sobre cómo integrar nuestro software con el suyo, el cliente nos envió una captura de pantalla de su formulario principal.
  Metí esa captura en ChatGPT y le dije: “hazme un formulario de React con Bootstrap que se vea así”. Después de algunos ajustes, conecté mi software, y unas horas más tarde el cliente quedó sorprendido al ver una prueba de concepto integrada tan rápido. Cuando tengo problemas de layout con CSS en desarrollo web, suelo subir una captura a ChatGPT y preguntarle cómo resolverlos; la demo del tuit se ve bastante parecida.

  • Crear una página de formulario básica siempre fue algo simple. Lo sorprendente es que, después de unos 25 años de desarrollo web, sigamos creando nuevos frameworks web y haciéndolo más complicado de lo necesario.
    Han seguido apareciendo frameworks excelentes para casos de uso sofisticados, pero excesivos para tareas comunes y básicas. Hubo algunas excepciones, pero a la mayoría de los desarrolladores web no les gustan. Tampoco se ven muy impresionantes en el currículum y, siendo honestos, ¿quién quiere pasarse toda la carrera haciendo formularios web?
  • La primera vez, el cliente quedará impresionado por la velocidad. La segunda vez, esperará esa velocidad. La tercera vez, cuando los requisitos hayan crecido más allá de lo que ChatGPT puede manejar, se enojará porque el calendario explotó.
  • Si hablaste con el cliente por email o chat, también puedes imaginar que el cliente le está preguntando a ChatGPT cuál es la mejor forma de comunicarte sus requisitos.
    Al final son tortugas sobre tortugas :+)
  • Pero quizá el cliente no quería que expusieras sus datos a ChatGPT.
  • Subir capturas de problemas de layout de CSS a ChatGPT para corregirlos es una idea ingeniosa que no se me había ocurrido. Normalmente manejo suficiente CSS como para arreglarlo en las herramientas de desarrollador y pasar los estilos al código, pero vale la pena recordarlo.
    Para programar, he usado ChatGPT más para procesar datos rápidamente con pipes de línea de comandos o scripts de Bash que para código. Si le das la salida de un comando y le pides Bash para formatear, agrupar, ordenar o extraer lo que quieres, se vuelven fáciles cosas que antes quizá no habría hecho, como depurar o comprobar hipótesis. Podría hacerlo manualmente, pero sería lento y para recordar opciones y argumentos tendría que buscar o leer páginas man. Para código uso principalmente GH Copilot.

• Pueden llamarme escéptico, pero no creo en el futuro de las soluciones no-code. Hay que alinear botones en resoluciones de dispositivos pequeños, dejar márgenes para que se vea bien en otros idiomas, y siempre siguen apareciendo otros requisitos.
  Como mucho, servirá para crear apps más rápido con un lenguaje más abstracto. Eso funciona para cosas extremadamente básicas y comunes, como el ta-te-ti, pero no encaja con trabajos originales.

  • El gran problema del no-code basado en LLM es que la salida es no determinista, así que al final solo se puede poner bajo control de versiones el resultado en sí.
    Imaginen a decenas de personas que saben apenas un poco de tecnología haciendo bocetos y presionando “hazlo de verdad” para agregar funciones. Cada una genera cientos de líneas de código. Al final del día, alguien tiene que entender ese resultado, y como la salida es no determinista, eso es lo único que nos queda.
  • Es parecido al autotune. Los artesanos que saben cantar afinados seguirán creando cosas interesantes.
    Al mismo tiempo, nuevas personas que no aprendieron, o no quisieron aprender, a cantar afinadas crearán géneros musicales completamente nuevos y pop masivo con mucho menos esfuerzo. Los artesanos también lo usarán ocasionalmente para reforzar algunos flujos de trabajo, pulir el acabado y acelerar.
  • Muchas de estas demos no parecen intentar impulsar un enfoque no-code puro, sino más bien mostrar que se pueden crear casi al instante wireframes funcionales.
    Creo que herramientas como Canva y Figma van a incorporar estas funciones con fuerza y mejorar mucho los wireframes y demos de alta fidelidad.
  • Mi intuición inicial era la misma. La personalización y la integración serán una pesadilla total. Pero para prototipado es excelente.
  • O bien los LLM/IA se vuelven perfectos, o empezaremos a usar código y frameworks que sean mucho más fáciles de usar para los LLM/IA.

• Squarespace, Wix y otros ya se quedaron con la parte baja del mercado; si no, lo habría hecho el outsourcing en India.
  Esto es una evolución natural del mismo concepto. Si fuera product manager de un creador de sitios web, me lanzaría de inmediato a integrar este tipo de builder con IA. Nunca funcionará para tareas de negocio complejas y apenas definidas, pero sí podría crear bien algo como una calculadora de costos para un negocio de fotografía.

  • La mayoría de las pymes todavía no tienen app ni sitio web, o si lo tienen, muchas veces no sirve de mucho. Hay muchísimo espacio para mercados de nicho y buenas herramientas.
  • Parece útil como herramienta para crear demos interactivas y prototipos que permitan iterar ideas rápidamente. Puede mantener corto el ciclo de feedback con los clientes y reducir malentendidos. Por ejemplo, Figma podría implementar algo así.
  • No entiendo por qué creen que solo sirve para tareas triviales. Eso roza la negación.
    El software de flujos de trabajo para procesos de negocio es bastante popular. Hay muchas apps en las que la gente hace cosas similares con drag and drop o editores interactivos de widgets, y pueden manejar formularios complejos, relaciones padre-hijo y transiciones de estado. Con algo como GPT Vision, se podría saltar el drag and drop de widgets y usar herramientas de dibujo más libres o bocetos hechos a mano. El ejemplo más popular hoy probablemente sea Notion, y desde mucho antes ya existían ejemplos más complejos.

• Ahora me siento viejo. Hace décadas, con VB o Delphi se podía hacer casi lo mismo a una velocidad parecida. Solo que, en vez de que la herramienta infiriera a partir de los nombres de las etiquetas, el resultado era un poco más determinista.
  Ya teníamos cosas así, pero olvidamos que se podían hacer sin meter todo en el navegador ni usar la enorme computación de los modelos de IA generativa. Me siento como un viejo gritándole a una nube.

  • Pienso algo parecido. Dicho de forma un poco más provocadora: cuando la gente muestra cómo convierte Figma a HTML con IA, digo: “¿han oído hablar de Dreamweaver?”.
    Claro, el código de Dreamweaver era feo y casi inutilizable, y el código generado por IA a veces no está tan mal. Aun así, creo que ya habíamos llegado bastante cerca de donde estamos hoy.
  • Esto no es un problema del navegador, sino de qué tan opinativo en su diseño es el framework.
    VB era una herramienta muy opinativa y solo creaba interfaces estilo Windows nativo. No se trataba de replicar en VB, píxel por píxel, cualquier mockup arbitrario traído por un diseñador, con un look and feel totalmente personalizado. Hoy la mayoría de las GUI de productos son parte de la marca. Para bien o para mal, todas las empresas quieren un look and feel y comportamientos de UI distintivos. Por eso las herramientas para construirlas tienen que ser mucho más complejas. En el navegador se puede recrear VB, y de hecho mucha gente ha hecho cosas parecidas, pero no se usa mucho para desarrollo de productos porque las empresas no quieren interfaces aburridas y genéricas.
  • Entiendo la idea, pero solo aplica a los ejemplos más simples. Esta herramienta puede hacer varias cosas. Si miran más ese hilo, también implementa ta-te-ti.
    Básicamente funciona enviando una captura de pantalla de un diagrama a GPT-4 y diciéndole “implementa esto”.
  • Hace mucho, en el pabellón de gráficos de Comdex, había un sistema operativo novedoso que se presentaba como el siguiente paso. Un nerd enorme arrastraba cosas de aquí para allá con el mouse, “demostrando” que no hacía falta ser programador para crear una aplicación.
    Diez años después, apareció por uno o dos años algo llamado Visix Vibe que ofrecía lo mismo para Java, que entonces era un lenguaje relativamente nuevo. Cada tantos años, más o menos cada 4 o 5 o cada 10, alguien quiere hacer desaparecer toda la complejidad. Pero al final terminan construyendo un sistema operativo.
  • Con los principales toolkits de UI nativa todavía se puede ver esto. Puede que no sea tan rápido como RAD, pero te dan “gratis” un montón de elementos e interacciones que en la web requieren JavaScript personalizado y normalmente inestable.
    Y de hecho funcionan bien, interactúan con el resto del toolkit de la forma esperada, y la internacionalización y la accesibilidad también funcionan de manera consistente. No hay razón para que HTML no pueda hacer mucho más de forma nativa, y eso ahorraría cada año una enorme cantidad de horas de desarrollo y frustración de usuarios. Pero simplemente no se hace.