00:00:00Hay una capa en el antiguo proceso de creación que ya no existe.
00:00:03Y la mayoría de los equipos no han descubierto con qué reemplazarla, así que siguen
00:00:06ejecutando el proceso anterior por pura inercia.
00:00:08Esta semana, Jenny Wen publicó una entrevista en el podcast de Lenny.
00:00:11Ella es la jefa de diseño de Claude en Anthropic y, antes de eso, fue directora de diseño
00:00:16en Figma.
00:00:17En el episodio, habló sobre cómo el proceso de diseño ha muerto y qué es lo que realmente lo está
00:00:21reemplazando.
00:00:22Así que vamos a desglosar qué cambió, por qué, y luego recorreremos el proceso exacto
00:00:26que lo sustituyó.
00:00:27Para entender qué lo reemplazó, hay que entender por qué existía.
00:00:31Con el proceso antiguo, primero se definían los requisitos; luego, un diseñador los llevaba a
00:00:35Figma y creaba una maqueta de cómo se suponía que debía verse la aplicación.
00:00:38Ese archivo de Figma era el documento de entrega entre lo que alguien quería y lo que se construía.
00:00:43Un ingeniero de front-end luego convertía ese archivo en código.
00:00:46Mientras tanto, el ingeniero de back-end construía en paralelo, porque se definía una especificación
00:00:51de API por adelantado, así ambos lados avanzaban al mismo tiempo y todo conectaba al final.
00:00:55Jenny describe esto como un proceso que los diseñadores trataban como un ritual.
00:00:58Este era el estándar en toda la industria.
00:01:00La mayoría de las personas que explican por qué está cambiando pasan por alto la razón por la que existía.
00:01:05Simon Willison, un desarrollador que escribe uno de los blogs técnicos más leídos del
00:01:09sector, resumió la charla de Jenny en Berlín en enero y añadió la idea que su charla implica
00:01:14pero no dice directamente.
00:01:16Construir con IA reduce significativamente el coste de construir algo equivocado.
00:01:19Antes de la IA, una dirección errónea significaba meses de tiempo de ingeniería desperdiciado.
00:01:23Un pequeño error en el front-end suponía 10 veces más trabajo durante la implementación.
00:01:27Así que los equipos justificaban cada paso.
00:01:28La investigación, los perfiles de usuario, los viajes del usuario, los esquemas, el documento técnico.
00:01:33Todo ello era una protección contra la construcción de algo incorrecto a gran escala.
00:01:36Entonces, ¿qué cambió realmente en el proceso?
00:01:38Primero cambió la velocidad de la ingeniería.
00:01:40Y cambió más rápido de lo que la mayoría de la gente pudo procesar.
00:01:42Jenny dijo que hace unos años, el 60 o 70 % de su tiempo como diseñadora se dedicaba a maquetar y prototipar.
00:01:48Ahora es del 30 al 40 %.
00:01:49No es que ella decidiera trabajar de forma diferente.
00:01:51Los ingenieros a su alrededor empezaron a lanzar múltiples agentes en paralelo y, de repente, el
00:01:55cuello de botella ya no era la ingeniería.
00:01:58La ingeniería cambió primero y el diseño se vio obligado a seguirla.
00:02:00Los plazos de visión también cambiaron.
00:02:02El diseño solía producir visiones de 2 a 5 años.
00:02:04Ahora la tecnología avanza tan rápido que un horizonte de 3 a 6 meses es el alcance realista.
00:02:09Y no es necesariamente una presentación de diapositivas.
00:02:11Es un prototipo que orienta a la gente en una dirección.
00:02:13Lo mismo ocurrió con el paso de la traducción.
00:02:15Cuando un agente puede tomar un documento de requisitos y construir una interfaz funcional, no hay
00:02:19capa de traducción.
00:02:20El agente escribe el código.
00:02:22No hay un archivo de Figma que traducir porque nunca llega a haber un archivo de Figma.
00:02:25Además, si disfrutas de nuestro contenido, considera pulsar el botón de “hype” porque nos ayuda
00:02:29a crear más contenido como este y a llegar a más personas.
00:02:33Cuando recibimos trabajos de clientes, este es el cambio exacto que hemos tenido que hacer.
00:02:36Ahora bien, el proceso de diseño cambió, pero la parte que no cambió son los requisitos.
00:02:40Unos malos requisitos arruinan toda la construcción.
00:02:42Y la mayoría de los equipos saltan directamente a la especificación técnica.
00:02:44Ese es el orden incorrecto.
00:02:45Cuando construyes un prototipo, no necesitas una infraestructura técnica ni una especificación de API.
00:02:48Necesitas saber lo suficiente para construir algo que se vea y se sienta como el producto real
00:02:52para poder mostrárselo a alguien y obtener un sí o un no.
00:02:56Así que, antes de tocar el prototipo, empieza con los actores.
00:02:58Un actor es una persona que interactúa con el sistema.
00:03:01Una persona específica con un objetivo específico.
00:03:03Pero quién lo usa determina lo que el sistema debe hacer.
00:03:06Si tienes a alguien que envía contenido y a alguien que lo aprueba, esas son dos
00:03:10interfaces distintas con dos pantallas de inicio diferentes.
00:03:12Luego observa dónde se dividen las vistas.
00:03:13En la mayoría de los productos, en algún punto, dos actores diferentes entran en la misma URL y ven
00:03:18cosas completamente diferentes.
00:03:19Un administrador ve un panel de gestión.
00:03:21Un usuario normal ve su tablero personal.
00:03:22Lo último son las restricciones.
00:03:24No le digas al agente qué herramientas usar.
00:03:26Dile lo que no puede hacer y lo que no puede costar.
00:03:28Esto también facilitará mucho las decisiones técnicas más adelante.
00:03:32Ahora implementamos todas esas reglas específicas en este “prompt” para crear el PRD, que básicamente
00:03:37te entrevista, actúa como tu entrevistador de PRD, y te hace preguntas según las reglas,
00:03:42planteándote un montón de cuestiones diferentes.
00:03:44Y al final, terminas con un archivo Markdown de PRD, que se utilizará en las etapas
00:03:48posteriores del proceso.
00:03:49Ese archivo PRD es la base sobre la que se construye todo lo demás.
00:03:52Así que el siguiente paso es convertirlo en la estructura para el front-end.
00:03:55Para esto, usamos este “prompt” de capa, que esencialmente le dice al agente que mire el PRD, que de nuevo
00:04:00no es un PRD completo con todos los requisitos técnicos, y produzca dos cosas.
00:04:04Le pide que produzca las páginas y los modales que acompañarán a tu prototipo y
00:04:08luego los flujos de usuario.
00:04:09Obviamente, las páginas y los modales son importantes para la estructura, de modo que todo lo que el agente
00:04:14necesite implementar en el front-end esté planeado de antemano.
00:04:17Hemos insistido en hablar sobre planificar antes de actuar y por qué es tan importante para
00:04:21el agente y la ventana de contexto, así que no hace falta profundizar en eso.
00:04:24Pero con los flujos de usuario, es importante definir las acciones de cada actor.
00:04:28Como ya nos enfocamos en los actores mismos y no en las funciones, también es
00:04:32importante definir los flujos para que el agente pueda implementar los estados de interacción
00:04:36adecuados y la navegación correcta para el prototipo completo de la interfaz.
00:04:40Así que terminamos con dos archivos donde el “architecture.md” contiene las páginas, los modales y los flujos
00:04:45que discutimos.
00:04:46Después de eso, le pedimos que instale una aplicación Next.js porque esa es la tecnología que
00:04:50usamos normalmente, Next.js con Supabase.
00:04:53Y esto es lo que realmente creó.
00:04:55En general, el diseño se ve genial, pero hay una razón específica para ello.
00:04:58Además, no se mencionó antes, pero el proyecto era una plataforma comunitaria con canales,
00:05:03productos y cursos.
00:05:04Hay dos actores, básicamente el miembro y también el creador, donde el creador
00:05:08tiene todas las funcionalidades administrativas como crear un canal, añadir un producto
00:05:12o subir un curso, así como consultar diferentes estadísticas.
00:05:15En nuestra opinión, para ser el primer prototipo que se ha hecho, el diseño se ve muy bien.
00:05:19Pero la experiencia de usuario (UX) no es tan buena porque normalmente no queremos un tablero así.
00:05:23Y este es precisamente el punto.
00:05:24Ese tipo de corrección solía costar días, aquí cuesta minutos.
00:05:27Porque la IA puede hacer estas modificaciones de forma muy, muy rápida.
00:05:30Y como aquí no hay back-end, tampoco tiene que lidiar con todo ese trabajo extra,
00:05:34es solo el prototipo del front-end.
00:05:36Ahora bien, normalmente la IA no crea sitios web e interfaces con tan buen aspecto.
00:05:40Y la razón por la que esto se ve bien es porque usamos esta habilidad general de front-end
00:05:44que Anthropic ofreció en uno de sus blogs.
00:05:46Recomendamos encarecidamente usar esto antes de implementar la interfaz de usuario.
00:05:50Guárdalo como un comando rápido o una habilidad para que tu agente pueda usarlo.
00:05:53Si trabajas para un cliente, solo tienes que mostrarle este prototipo, que es
00:05:57totalmente funcional en términos de características con datos ficticios, porque todavía
00:06:01no va a gestionar una base de datos.
00:06:02Puedes mostrárselo al cliente, obtener su aprobación y, si no, hacer los cambios y luego
00:06:06continuar con el resto de la construcción.
00:06:08Estas listas de tareas son una de las razones por las que ahora podemos pedirle a estos agentes que hagan
00:06:12prototipos plenamente funcionales.
00:06:14Es gracias a estas listas de tareas, a la persistencia de las mismas y a que todo
00:06:17está estructurado.
00:06:18Por eso crear ese archivo “architecture.md” era tan importante, porque permite al
00:06:23agente construir una lista de tareas optimizada para que no tenga alucinaciones.
00:06:28Después de eso pasamos a la implementación del back-end.
00:06:30Normalmente hay dos cosas que podrías hacer.
00:06:32Podrías mantener Next.js, dejar el front-end separado en Next.js e implementar el
00:06:36back-end como un servicio de Python independiente.
00:06:39Pero eso depende del tipo de aplicación con la que estés trabajando.
00:06:42Para la mayoría de los proyectos que ustedes construirán, Next.js será suficiente.
00:06:46Necesitas un back-end de Python separado específicamente cuando requieres librerías extensas
00:06:50que no están disponibles en Next.js o si necesitas una orquestación seria de tareas en segundo plano
00:06:55para optimizar tu sitio o sus funciones.
00:06:57En ese caso, podrías necesitar un back-end independiente.
00:06:59De lo contrario, el back-end de Next.js es prácticamente todo lo que vas a necesitar.
00:07:03Antes de tocar el back-end, necesitamos saber qué es lo que el front-end necesita de él.
00:07:07Así que hicimos que el agente mirara el código del front-end, el PRD y el archivo de arquitectura y escribiera
00:07:11una especificación de API.
00:07:12Después de eso, le pedimos que usara los tres documentos para crear el esquema completo de Supabase porque
00:07:17estamos usando Supabase más Next.js como front-end.
00:07:20Básicamente, necesita crear los esquemas que albergarán los datos de la aplicación.
00:07:25Normalmente, si le preguntas a tu agente, te dirá que vayas tú mismo, consigas tus claves de API
00:07:28de la base de datos y pegues manualmente consultas SQL para crear las tablas.
00:07:33Pero en lugar de eso, deberías usar el MCP de Supabase.
00:07:36Intenta usar siempre un MCP para cualquier servicio con el que trabajes porque automatiza
00:07:40muchas cosas.
00:07:41Por ejemplo, aquí ni siquiera tuvimos que mirar los proyectos.
00:07:43Creó automáticamente el proyecto, ejecutó las consultas para el esquema y realizó automáticamente
00:07:48las migraciones.
00:07:49Así que básicamente no tuvimos que hacer nada.
00:07:51Una vez configurada la base de datos, vas a conectar el front-end a ella.
00:07:55Nuevamente, hay una distinción clara aquí.
00:07:57No tienes que conectar el back-end a la base de datos porque ya está integrado en
00:08:00el front-end.
00:08:01El front-end habla directamente con la base de datos, lo que hace que la integración y la complejidad
00:08:06general sean mucho menores.
00:08:07Ahora bien, nos hemos asociado con Warp para este vídeo y hace poco lanzaron OZ, que
00:08:11es una plataforma de orquestación para diferentes agentes en la nube.
00:08:14Estos agentes en la nube son útiles para tareas que solo quieres delegar y sabes que
00:08:19el agente podrá completar por su cuenta.
00:08:21Así que hasta ahora, el agente había conectado el front-end a la base de datos y la aplicación ya
00:08:26estaba funcionando según eso.
00:08:27Pero para añadir cosas como procesamiento de pagos, nuevas notificaciones, limitación de tasa o analíticas
00:08:32en el sitio, necesitamos una capa de API de back-end dedicada para poder integrar todo eso.
00:08:37Para ello, creamos un entorno usando OZ y ejecutamos un agente en la nube, al que pedimos que construyera
00:08:41esa capa de back-end dedicada.
00:08:43Y después de unos 15 minutos, terminó la tarea y todo el sistema estaba listo.
00:08:47Para que esto fuera funcional y empezar a aceptar usuarios, lo único que faltaba
00:08:51era la autenticación de Google, la integración de Stripe y algunos pequeños detalles que debíamos corregir.
00:08:56Ahora habéis visto el proceso completo y los “prompts” han aparecido ahí mismo en pantalla.
00:09:00Pero si queréis todos estos “prompts” como un flujo de trabajo paso a paso que podáis seguir para vuestros
00:09:04propios proyectos, los estamos publicando en AI Labs Pro.
00:09:06Para quienes no lo sepan, es nuestra comunidad donde obtenéis plantillas listas para usar que podéis
00:09:10conectar directamente a vuestros proyectos, tanto para este vídeo como para todos los anteriores.
00:09:14Si valoráis lo que hacemos y queréis apoyar al canal, esta es la mejor manera
00:09:18de hacerlo.
00:09:19El enlace está en la descripción.
00:09:20Con esto llegamos al final de este vídeo.
00:09:22Si queréis apoyar al canal y ayudarnos a seguir haciendo vídeos como este, podéis hacerlo
00:09:26usando el botón de “Súper gracias” de abajo.
00:09:28Como siempre, gracias por vernos y os veré en el próximo.