Describes una interfaz con palabras y, en diez segundos, tienes un trozo de código React que funciona (casi) perfectamente. Si ahora podemos generar con un prompt todo lo que vemos en una web, ¿sigue teniendo sentido pagar a alguien para que lo haga? La pregunta es bastante razonable. La respuesta, como suele pasar, depende de qué entendamos exactamente por «frontend».
Llevamos un tiempo dándole vueltas al tema… ¿Ha muerto el frontend? ¿Quién se lo ha cargado? ¿Deberían los desarrolladores frontend empezar a buscarse otro oficio? ¿O sería mejor montar un chiringuito en alguna playa? Vamos a empezar por el escenario que hace que esta pregunta tenga sentido, y no por defender a capa y espada una profesión.
En 2026, todos lo sabemos, existen herramientas capaces de recibir una descripción en lenguaje natural y devolver aplicaciones que funcionan.
- v0, de Vercel, genera interfaces en React con Tailwind y shadcn/ui con una calidad que resulta difícil de distinguir de la de un desarrollador senior.
- Bolt.new, de StackBlitz, construye aplicaciones full-stack directamente en el navegador, con las dependencias instaladas y una vista previa funcionando en cuestión de minutos.
- Lovable lleva a alguien que no sabe programar desde una simple idea hasta un producto con base de datos y autenticación ya integradas. Y no estamos hablando de demos para una conferencia: son categorías de producto con un crecimiento récord y millones de usuarios (y personas que están ganando millones de dólares con ellas).
La tarea más representativa del frontend developer —convertir un diseño en código y estilos, componer componentes, gestionar estados y layouts— es precisamente lo que mejor hacen estas herramientas.
Y aquí surge una pregunta tan legítima como provocadora: si la creación de interfaces se puede automatizar, ¿se ha convertido el frontend developer en una profesión en peligro de extinción?
Merece la pena tomarse la pregunta en serio. Construyamos el argumento más sólido posible y después desmontémoslo para ver qué queda en pie. Bienvenidos al tribunal de Codemotion: el acusado es la IA y el cadáver (quizá) es el del desarrollador frontend.
La acusación: el frontend ha muerto
El mercado ya ha votado
Antes incluso de entrar en cuestiones técnicas, la acusación pone sobre la mesa la prueba más difícil de rebatir: el dinero. Lovable habría alcanzado unos 20 millones de dólares de ingresos recurrentes anuales en apenas dos meses y Bolt.new, alrededor de 40 millones en seis. No son cifras propias de una startup que vende una promesa en una presentación: hablamos, respectivamente, del crecimiento más rápido jamás visto en el software europeo y de cifras propias de una categoría ya consolidada.
El capital es un juez cínico. No apuesta por lo que queda bien en una demo de una conferencia: apuesta por lo que, a escala, genera valor real. Si inversores y usuarios están pagando estas cantidades para que un modelo escriba frontend, es porque ese frontend, para una enorme cantidad de casos de uso, es «lo suficientemente bueno» como para cumplir su función. Y «lo suficientemente bueno, ahora mismo» suele ganar a «perfecto, dentro de dos semanas».
La UI se ha convertido en una commodity
Durante veinte años, buena parte del valor de un frontend developer estaba en su capacidad para convertir un mockup en código: picar píxeles, gestionar el CSS, adaptar el diseño a distintos dispositivos y conseguir que todo funcionara en diferentes navegadores. Era un trabajo artesanal y, como todo trabajo artesanal, su valor dependía en buena medida de que no hubiera tanta gente capaz de hacerlo bien.
Esa escasez se está reduciendo. La generación mediante prompts y los flujos de design-to-code (por ejemplo, pasar de Figma al código) están haciendo «trivial» precisamente el paso que definía el trabajo del frontend. Cuando cualquiera puede crear una interfaz decente describiéndola con palabras, la competencia de «frontend puro» deja de ser una ventaja competitiva y se convierte en un botón que pulsar.
El boilerplate ERA el pan de cada día
Formularios, tablas, modales, estados de carga, gestión de errores de validación, código de conexión entre componentes… Quien trabaja en este campo sabe que una parte enorme de la jornada se va en estas tareas. No es trabajo creativo, es trabajo repetitivo, y precisamente ahí es donde los modelos de lenguaje funcionan mejor. Como son patrones que han aparecido miles de veces, los modelos saben exactamente qué hacer.
La paradoja es bastante cruel: la parte del trabajo que llenaba tantas horas es también la más fácil de automatizar. Lo que parecía ser «hacer frontend» consistía, en buena medida, en gestionar código que ya conocíamos.
La velocidad baja el listón
Hay otro efecto más sutil que no tiene tanto que ver con la calidad del resultado como con la economía de quien toma las decisiones. Para que la IA gane no necesita superar a un senior en su propio terreno: basta con que cambie el punto en el que alguien dice «esto ya está bien».
Cuando una interfaz decente cuesta diez segundos y unos pocos euros en lugar de dos jornadas de trabajo, el nivel de lo que consideramos aceptable baja al mismo tiempo que el coste. Empresas que jamás habrían destinado presupuesto a ese trabajo artesanal de píxel ahora despliegan interfaces generadas sin pensárselo demasiado, porque la pregunta ha cambiado: ya no es «¿cuánto vale la pena hacerlo bien?», sino «¿para qué pagar si con esto basta?».
El frontend developer no pierde una competición de habilidad. Simplemente se lo saltan, porque la pregunta que antes justificaba contratarlo ya no se la hace nadie.
Los problemas que ya están resueltos son los que mejor domina la IA
El ecosistema se ha consolidado alrededor de soluciones compartidas. Las librerías headless, los sistemas de diseño como shadcn/ui y los patrones de composición que ya se han convertido en estándares han transformado buena parte del frontend en un conjunto de problemas conocidos. Y los problemas conocidos son precisamente aquellos en los que un modelo entrenado con millones de repositorios se mueve con mayor seguridad.
No es casualidad que v0 sea, en la práctica, una versión basada en IA de la filosofía de shadcn/ui: genera exactamente aquello para lo que ha sido optimizado.
La presión se nota sobre todo en los perfiles junior
Hay un efecto secundario más preocupante que la simple automatización. Las tareas de entrada —maquetar, aplicar estilos, replicar un mockup, crear el formulario de la enésima página de contacto, etc.— son las primeras que empiezan a desaparecer.
Y son precisamente las tareas con las que, históricamente, un junior aprendía el oficio y justificaba su sueldo. Si el senior trabajaba en la arquitectura de una aplicación frontend, el junior se encargaba de… picar CSS.
Si el escalón de entrada se hace más pequeño, el problema no afecta solo a quienes ya están dentro: también afecta a quienes deberían entrar. Una profesión que deja de formar juniors es una profesión que, después de uno o dos ciclos, tiene un problema estructural de renovación.
Hasta aquí, la tesis. Es sólida, y quien la despache como alarmismo probablemente no la ha observado durante suficiente tiempo. Ahora, veamos el otro lado.
La defensa: el frontend está muy vivo
Generar no es decidir
El punto débil de la teoría del «asesinato del frontend» es que confunde producir código con hacer ingeniería de software. La IA genera, pero la arquitectura, la gestión del estado, el presupuesto de rendimiento, la estrategia de caché y la accesibilidad siguen siendo decisiones humanas, con consecuencias medibles y duraderas.
Un modelo puede escribir un componente de React en diez segundos. Pero no te dice si ese componente debería estar ahí, si el estado debería vivir en ese punto del árbol de componentes o si esa decisión seguirá funcionando cuando la página crezca un orden de magnitud.
Genera una respuesta plausible a una pregunta concreta; no toma decisiones de sistema. Y el frontend, en un producto real, es un sistema.
Una demo no es un producto: el «technical cliff»
Aquí la teoría se encuentra con un dato concreto. Estas herramientas suelen funcionar de maravilla durante el primer 80 % del trabajo: una demo que funciona, una interfaz que queda bien en una captura de pantalla. Es el 20 % restante el que separa un juguete de algo que realmente puedes poner en producción: casos límite, comportamiento en distintos navegadores, accesibilidad, internacionalización, tolerancia a errores y seguridad.
¿No os dice nada la proporción 80/20? Pues debería.
No es un miedo abstracto. En 2025, la vulnerabilidad CVE-2025-48757 expuso los datos de más de 170 aplicaciones de Lovable en producción: Supabase envía las tablas con Row Level Security desactivado por defecto y el generador no lo activaba. Traducido: había aplicaciones que parecían terminadas, con una interfaz cuidada y un login que funcionaba, pero cuya base de datos estaba abierta a cualquiera que supiera dónde mirar. El código generado parecía estar listo. No lo estaba.
Es el ejemplo perfecto del technical cliff: el momento en el que la magia de la generación se encuentra con la brutalidad de la infraestructura de producción. Alguien tiene que conocer el precipicio para no caer en él, y ese alguien tiene un perfil que se parece mucho al de un frontend engineer experimentado.
La responsabilidad es la ley y no se genera con un prompt
Hay un nivel en el que ese precipicio se convierte, literalmente, en un problema legal. Desde el 28 de junio de 2025, la European Accessibility Act (Directiva UE 2019/882, incorporada en Italia mediante el Decreto Legislativo 82/2022) ha convertido la accesibilidad digital en una obligación legal para gran parte de las empresas que superan el umbral de microempresa, con sanciones que pueden llegar a los 40.000 euros. Ya no es una cuestión de sensibilidad o de buenas prácticas: es cumplimiento normativo, con una autoridad que supervisa y sanciona.
Ahora, prueba a pedirle a un modelo que te genere una interfaz que cumpla con las WCAG en todos los casos límite y después pídele que responda ante el organismo regulador cuando no sea así. No funciona de esa manera.
La IA genera, pero la responsabilidad sigue siendo humana y, además, puede tener consecuencias legales. Alguien tiene que saber qué revisar, garantizar que el resultado cumple requisitos que el modelo trata como opcionales y, finalmente, poner su firma. Ese es precisamente el perfil de un frontend engineer experimentado: no alguien que desaparece, sino alguien que se convierte en el punto en el que se detiene el riesgo.
El problema del contexto
Hay un límite más profundo y más difícil de superar simplemente utilizando un modelo más grande. La IA no conoce tu codebase, las restricciones del negocio, la historia de las decisiones arquitectónicas ni el motivo por el que hace tres años elegisteis un patrón en lugar de otro. Genera dentro del vacío del prompt (o, como mucho, utilizando como contexto aquello que se le haya proporcionado).
Alguien tiene que darle ese contexto, precisamente… Y tiene que entender lo suficiente como para juzgar si el resultado tiene sentido dentro de ese contexto.
Cuanto más crece un proyecto, más peso adquiere ese trabajo de contextualización y revisión. No es casualidad que, entre quienes utilizan estas herramientas de verdad, exista cierto consenso en que, a partir de un determinado nivel de complejidad, el código generado puede ser más difícil de mantener, no menos. La velocidad inicial se acaba pagando después.
El frontend no consiste en «hacer botones»
El error conceptual de fondo es reducir el frontend a la implementación. El frontend es la capa en la que el producto se encuentra con el usuario: la coherencia del sistema de diseño, la calidad de la interacción, la accesibilidad entendida como requisito y no como algo que se añade después, la percepción del rendimiento.
Desaparece la implementación repetitiva; no desaparece la disciplina que decide qué hay que implementar y por qué.
Un modelo puede darte mil variantes de un botón. Pero no te dice cuál es la adecuada para tu usuario, tu marca o tu contexto de uso. Esa sigue siendo una competencia humana.
La estructura es tan importante para el agente como para el humano
Hay un último punto que cambia por completo la intuición inicial. Podríamos pensar que, si el código lo escribe un modelo, la organización del proyecto —el framework, las convenciones, la estructura de carpetas— cada vez importa menos.
Es justo al contrario.
La estructura que impone un framework es lo que permite a una persona razonar sobre una codebase compleja sin tener que mantenerla entera en la cabeza. Y es exactamente esa misma estructura la que permite a un agente generar código con sentido, porque le proporciona las restricciones y los patrones dentro de los que debe moverse.
Los frameworks funcionan, en otras palabras, como una capa de compresión cognitiva: convierten decisiones recurrentes en convenciones compartidas. Y esas convenciones son una ventaja tanto para quien lee como para quien genera.
Un proyecto bien estructurado no solo es más fácil de mantener para una persona; también es más «generable» para un modelo. Quien conoce un framework a fondo y sabe cómo darle forma no está perdiendo relevancia en la era de los agentes: está construyendo el terreno sobre el que los agentes trabajan mejor.
¿Os suena de algo?
La paradoja de Jevons: más código, no menos
Queda la objeción económica, esa de los ingresos récord con la que la acusación abría el caso. Y aquí la defensa juega su mejor carta, una que tiene ya un siglo y medio.
En el siglo XIX, el economista William Stanley Jevons observó que hacer más eficiente el uso del carbón no reducía su consumo. Al contrario: lo hacía crecer, porque al bajar el coste se multiplicaban sus usos. Es la paradoja que lleva su nombre y que funciona igual con el código que con el carbón.
Cuando generar una interfaz cuesta prácticamente nada, no construimos la misma cantidad de software gastando menos: construimos mucho más. Más superficies, más dashboards, más flujos, más experimentos que antes nunca habrían justificado un presupuesto.
Y cada nueva interfaz es algo que hay que decidir, revisar, mantener, hacer accesible y mantener coherente con el resto.
El mismo mercado que hoy está financiando los generadores será el que mañana se encuentre inundado de frontend que gobernar. Y necesitará más personas capaces de hacerlo, no menos.
La IA no elimina el trabajo: eleva su nivel.
El veredicto
Las dos tesis no se anulan entre sí. Describen el mismo fenómeno desde dos perspectivas diferentes y ambas tienen razón en cosas distintas.
La tesis del «asesinato» tiene razón cuando dice que cierto perfil está desapareciendo: el ejecutor, el artesano del pixel-pushing, quien obtenía su valor de la velocidad con la que escribía boilerplate. Esa ventaja competitiva se ha terminado, y fingir lo contrario es la forma más fácil de buscar consuelo.
La tesis de que «el frontend está vivo» tiene razón cuando dice que la profesión no se reduce a ese perfil. El centro de gravedad del trabajo se desplaza de escribir a juzgar: de implementar a decidir, evaluar, contextualizar y diseñar arquitecturas. Menos tiempo escribiendo código y más tiempo decidiendo si el código escrito es el adecuado.
Es exactamente ese cambio el que está haciendo emerger una figura híbrida: el product engineer. Alguien capaz de conectar diseño, producto e ingeniería y utilizar estas herramientas para probar tres direcciones de UI en el tiempo que antes necesitaba para configurar un bundler.
No es menos técnico que un frontend developer. Es técnico en un punto diferente de la cadena de valor.
Hay además un detalle que quienes defienden la tesis del «asesinato» suelen pasar por alto: estas herramientas están dejando de ser simples generadores de UI.
v0, que durante dos años fue el arquetipo del «frontend-only», desde febrero de 2026 también genera rutas API, server actions y conexiones con bases de datos.
Lo que, paradójicamente, refuerza las dos tesis: la IA automatiza una parte cada vez mayor del trabajo y, precisamente por eso, el punto de control humano —el criterio para evaluar un resultado cada vez más amplio— se vuelve más importante, no menos.
¿Qué cambia, en la práctica, para quien está leyendo esto?
Si trabajas en frontend, la pregunta útil no es «¿me van a sustituir?». La pregunta es: ¿dónde se ha desplazado el valor?
Deja de considerar una ventaja competitiva aquello que la IA puede hacer en diez segundos: escribir boilerplate, replicar un mockup o maquetar una página estática.
No porque haya dejado de ser útil, sino porque ya no es un recurso escaso.
Invierte tu tiempo allí donde la IA todavía no llega:
- El criterio arquitectónico: dónde vive el estado, cómo estructurar una aplicación para que pueda crecer y qué compromisos de rendimiento estás dispuesto a aceptar.
- La accesibilidad y los casos límite: ese 20 % que separa una demo de un producto y que los modelos tienden a pasar por alto de forma sistemática.
- El contexto de negocio: conocer el negocio, la codebase y la historia de las decisiones lo suficiente como para guiar y corregir el resultado generado.
- La revisión crítica: saber leer código generado y detectar el precipicio técnico antes de caer en él. La vulnerabilidad de Lovable no es un incidente aislado: es la forma más estable del riesgo cuando se generan aplicaciones sin alguien que sepa qué hay que revisar.
El frontend que conocías —el implementador que traducía diseños a código manualmente— sí ha muerto. Pero no lo ha matado la IA: lo ha dejado obsoleto al convertir en abundante aquello que antes era escaso.
Lo que queda en su lugar —el que decide, revisa y diseña la arquitectura de la experiencia— vale más, no menos, precisamente porque trabaja sobre una capa que ahora puede generar código de forma automática.
Es un cambio de piel. Impresiona mientras sucede y, visto desde fuera, parece el final de algo.
Pero quien cambia de piel no muere.
