LO
Avísame cuando llegue un registro verificado a esta ocupación → · Marca cuáles de estas tareas son tuyas (VOLO Pro, gratis) → · Para un equipo o una promoción de graduados →
Desarrollador frontend
Construye la superficie que la gente toca de verdad — y se queda con las partes que una pantalla generada no sobrevive: dispositivos reales, redes reales, y la exigencia legal de que funcione para todo el mundo.
Toma una pantalla de tu producto y lista todos los estados en los que puede estar. Después comprueba cuántos de ellos existen de verdad en el código.
Esto no es una probabilidad de perder el empleo. Combina qué parte de la carga de tareas del puesto está expuesta a la automatización con hasta dónde ha llegado realmente la adopción: sirve para comparar ocupaciones sobre una base constante, y para nada más.
Escrito para ingenieros que construyen interfaces web y de aplicación. Corta por capa y no por antigüedad — las páginas de software júnior y con experiencia cortan al revés, y un ingeniero de frontend sénior está en las dos. El diseño en sí es una ocupación aparte; el móvil nativo y los videojuegos divergen.
Qué está cambiando de verdad#
La unidad de análisis es la tarea, no el nombre del puesto. Un puesto no se sustituye: se le mueve la mezcla de tareas.
Cada casilla es una tarea. Su tamaño es cuánto pesa en el trabajo; su color, hacia dónde va la tarea. Haz clic en una casilla para ver qué no establece ese juicio.
Una pantalla que se renderiza no es una pantalla que sale a producción. No dice nada sobre si el resultado es mantenible, si encaja con un sistema de diseño existente, o cómo se comporta en los estados que nadie dibujó — vacío, cargando, error, media lista.
Es un juicio sobre dónde se sitúa el trabajo, no una medición de él. Los equipos no cuentan qué parte de su código frontend es manejo de casos límite, así que no hay cifra con la que contrastarlo, y el equilibrio cambia enormemente entre una página de marketing y una pantalla de negociación.
Un estándar gubernamental exige estas pruebas en sus propios servicios; nada de esto dice cuántas horas llevan en otros sitios ni si los equipos las hacen siquiera — buena parte del trabajo de frontend que se publica nunca recibe esta atención, y que las herramientas existan no significa que se hayan ejecutado.
La actuación de un regulador ha enumerado las barreras que quedaban en sitios que confiaban en una capa automática superpuesta, sin nombrar esos sitios; lo que acabaría de zanjarlo es una actuación sancionadora que nombre una interfaz concreta y qué tenía de mal. Los requisitos difieren según el mercado y según si el producto va dirigido al consumidor.
Que esto sea un puesto o una tarea añadida depende enteramente del tamaño del equipo, y cuántos equipos le dedican a alguien de forma deliberada no lo cuenta nadie.
Que aparezca trabajo nuevo no es lo mismo que plantilla nueva: esto se está absorbiendo dentro de los puestos existentes, y nada de esto dice que se contratara a nadie para hacerlo.
¿Es este tu trabajo? Dilo y esta página se estrecha a tu parte de él.
El nombre de un puesto es un paquete de tareas compradas juntas, y no hay dos personas con el mismo paquete. No se envía nada a ninguna parte: se queda en este navegador.
Cambios recientes#
Una norma federal de EE. UU. que obliga a los gobiernos estatales y locales en virtud del título II de la Ley de Estadounidenses con Discapacidades. La norma de 2024 exige que su contenido web y sus aplicaciones móviles cumplan WCAG 2.1 AA; esta norma final provisional, en vigor desde el 20 de abril de 2026, amplía el plazo de cumplimiento hasta el 26 de abril de 2027 para las entidades con una población de 50.000 habitantes o más, y hasta el 26 de abril de 2028 para las más pequeñas y los distritos especiales. En su razonamiento, el Departamento dice que la tecnología avanzada, como la IA generativa, todavía no automatiza de forma fiable la corrección de contenido inaccesible a escala, y que cuanto menos puedan apoyarse las entidades públicas en la tecnología para hacer accesible el contenido, más tendrán que apoyarse en cambio en el trabajo manual. Eso es el razonamiento del Departamento, no un requisito con fuerza normativa, y trata de corregir contenido existente, no de construir interfaces nuevas; la norma obliga a los gobiernos, no a las empresas privadas.
Un fallo, una marcha atrás, una regulación o un coste están frenando la adopción. Puede bajar una evaluación o ensanchar su incertidumbre.
El documento establece la medición, no su efecto. Figma declara que introdujo créditos de IA en todos los asientos durante 2025 y que empezó a aplicar los límites en marzo de 2026, vendiendo complementos mensuales o uso de pago por consumo por encima de ellos; el documento indica el mes, no el día. No da ninguna cifra de uso de Figma Make ni de Dev Mode. Solo dice que, una vez que empezó a aplicar los límites, recibió más solicitudes de soporte, hubo cierto descontento público y algunos clientes redujeron su uso, sin medir cuánto. Figma vende esos asientos, así que tiene interés en cómo se presenta un cambio de precios, pero el hecho que aquí se registra —que generar una interfaz a partir de un diseño ahora consume créditos medidos en lugar de estar incluido en el asiento— consta en un documento donde exagerar acarrea responsabilidad. No dice nada sobre herramientas de otros proveedores ni sobre canalizaciones internas.
Un fallo, una marcha atrás, una regulación o un coste están frenando la adopción. Puede bajar una evaluación o ensanchar su incertidumbre.
El estándar del Gobierno central británico para construir servicios digitales públicos. Si un servicio usa IA, debe dejar claro a los usuarios cómo puede afectar eso a sus datos y al resultado o la información que reciben; si usa un chatbot basado en IA, debe asegurarse de que los usuarios entienden que las respuestas no vienen de un ser humano y pueden no ser exactas, y de que saben cómo contactar con una persona. La página dice además que los servicios deben estar preparados para dejar de usar la IA si hace falta. Obliga a los equipos de servicios del Gobierno central británico, no a las empresas privadas, y fija lo que la interfaz debe comunicar, no cómo la construye ningún equipo.
Un fallo, una marcha atrás, una regulación o un coste están frenando la adopción. Puede bajar una evaluación o ensanchar su incertidumbre.
La demanda del regulador estadounidense de protección del consumidor contra una empresa que vendía un widget basado en IA que, según decía, hacía que cualquier sitio web cumpliera las Pautas de Accesibilidad para el Contenido Web, resuelta con una orden definitiva que exige un pago de 1 millón de dólares y prohíbe hacer esas afirmaciones sin pruebas. La demanda afirma que, según expertos en accesibilidad, ninguna herramienta automática de pruebas puede determinar por sí sola si un sitio web cumple las normas de accesibilidad y que hacen falta pruebas manuales hechas por personas, y enumera barreras que seguían presentes en sitios que usaban el producto: indicadores de foco ausentes, trampas de teclado en formularios y menús, texto alternativo ausente o inexacto, encabezados incorrectos. Es un caso de publicidad engañosa resuelto por acuerdo, la frase de los expertos cita a expertos externos, y los sitios afectados no se nombran.
Un fallo, una marcha atrás, una regulación o un coste están frenando la adopción. Puede bajar una evaluación o ensanchar su incertidumbre.
El propio código de una empresa, publicado por esa empresa, con la estimación de la migración manual (un año y medio de tiempo de ingeniería) dada por la misma empresa y no comprobable desde fuera. Lo que hace el resultado reproducible es el mecanismo, que la publicación describe entero: la migración es una máquina de estados en la que cada paso tiene un árbitro automático — jest, eslint y tsc dicen pasa o falla — así que el modelo podía reintentar sin nadie mirando, y la primera tanda resolvió el 75% de los ficheros en cuatro horas. La cola que quedó es el número más útil: tras cuatro días de ajustes, el 97%; muchos de los ficheros de la cola se habían reintentado entre 50 y 100 veces, y el último 3% se terminó a mano. La publicación es además explícita en que el factor principal fue seleccionar los ficheros relacionados correctos para meterlos en la instrucción — que creció a entre 40.000 y 100.000 tokens arrastrando hasta 50 ficheros — y no la redacción de la instrucción. No informa de ningún cambio de plantilla, de contratación ni de puestos, y tampoco lo afirma.
Una empresa lo ha puesto en producción. Puede mover la línea de base, ponderado por la escala y por cuánto se parece ese entorno al tuyo.
El estándar del Gobierno central británico para construir servicios digitales públicos. Todos los servicios del Gobierno deben seguir la mejora progresiva — funcionar primero con HTML y añadir después CSS y JavaScript — aunque una parte del servicio necesite JavaScript. Para que JavaScript funcione en todos los navegadores, la página enumera la detección de funcionalidades, los polyfills y la transpilación, el uso de pruebas automáticas o linters, y hacer pruebas manuales periódicas, incluidas pruebas con dispositivos más antiguos o menos potentes. Obliga a los equipos de servicios del Gobierno central británico; es un estándar sobre cómo debe hacerse el trabajo, no una medición de qué parte de él está automatizada.
Un fallo, una marcha atrás, una regulación o un coste están frenando la adopción. Puede bajar una evaluación o ensanchar su incertidumbre.
Qué significa esto para ti#
La tarea para la que antes te habrían contratado primero — convertir un diseño en una pantalla — es la más expuesta de aquí. Eso conviene saberlo antes de pasar un año volviéndote rápido en ella. Las partes que aguantan son los estados que nadie dibujó y la exigencia de que funcione para todo el mundo, y ninguna de las dos se aprende construyendo páginas de portafolio.
Tu palanca se movió de producir pantallas a restringirlas: el sistema de diseño, los estados, el presupuesto de rendimiento, la obligación de accesibilidad. Es trabajo menos visible y más difícil de enseñar en un portafolio, lo que es un problema real la próxima vez que cambies de empleo — empieza a llevar un registro de qué rechazaste y por qué.
Tus opciones#
Cuatro direcciones, cada una con sus restricciones reales y con una cosa que puedes probar esta semana. Seguir como estás es una opción legítima; solo tiene que ser una opción elegida.
Ser dueño de la capa de restricciones
Cuando las pantallas salen baratas, lo escaso es la persona que mantiene coherente un producto — la biblioteca de componentes, los estados, el presupuesto de rendimiento.
Es trabajo poco visible que se da fácilmente por supuesto, y necesita un equipo lo bastante grande como para que la coherencia importe.
Toma una pantalla de tu producto y lista todos los estados en los que puede estar. Después comprueba cuántos de ellos existen de verdad en el código.
Ser quien puede demostrar que es accesible
Esto se está moviendo de buena práctica a obligación en varios mercados, y una obligación necesita a una persona con nombre que pueda demostrar el cumplimiento en vez de afirmarlo.
Requiere aprender a probar con tecnología de apoyo en vez de con un verificador, cosa que la mayoría de los ingenieros nunca ha hecho.
Enciende un lector de pantalla y completa un flujo de tu propio producto sin mirar la pantalla. Anota dónde te atascaste.
Acercarte a la decisión de producto
Los ingenieros de frontend ven lo que hace la gente de verdad más directamente que casi nadie, y esa observación es la materia prima del trabajo de producto.
Exige renunciar a ser quien mejor conoce el código, y aprender a discutir con números en vez de con gusto.
Busca una funcionalidad que construyeras y que nadie use, y ve a averiguar por qué. La respuesta casi nunca es la que el equipo suponía.
Preguntas frecuentes#
Ningún número aquí sería honesto, y la pregunta se hace mejor tarea a tarea. Producir una pantalla a partir de un diseño lo hace ya en gran medida la máquina; decidir qué hace la pantalla cuando faltan los datos, no, ni tampoco responder de si funciona para alguien que usa un lector de pantalla. Una señal que puedes comprobar tú: cuánto de tu último mes fue teclear marcado frente a decidir comportamiento. Si fue sobre todo lo primero, la exposición es real y el movimiento es hacia lo segundo.
En su tarea más visible, sí, y la razón es mecánica y no un juicio sobre dificultad: la entrada es visual, la salida es texto, lo correcto se comprueba mirando, y los datos de entrenamiento son la web pública. Pero la mayor parte de un código de frontend real no es esa tarea — son los estados que nadie dibujó, los dispositivos en los que nadie probó, y las restricciones que mantienen coherente un producto que crece. Estar expuesto en la mitad visible no es estar expuesto en el trabajo.
La amplitud no es automáticamente protección, y ese es el encuadre que conviene soltar. Dos exposiciones superficiales son más fáciles de sustituir que una profunda; lo que protege es ser la persona en la que se confía para juzgar, y el criterio es específico de un dominio. Si cruzas, cruza por una razón — los estados y el modelo de datos están de verdad conectados, y entender los dos te hace mejor en la frontera, que es donde vive la mayoría de los fallos.
Se sigue pidiendo, y es una señal cada vez más débil por la misma razón que la primera tarea de esta página: quien lo revisa sabe ahora cuánto cuesta producir una pantalla bonita. Lo que no se ha debilitado es la evidencia de criterio — un componente que quitaste y por qué, un estado que manejaste y que nadie especificó, un presupuesto de rendimiento que sostuviste bajo presión. Eso es más difícil de reunir y mucho más difícil de generar.
¿Estudiando para esto?
Estas carreras llevan hasta aquí. Sus páginas desglosan cuáles de sus competencias se transfieren y qué les suele faltar a quienes se gradúan.
En qué se apoyan estos juicios#
De los 6 juicios de tarea de esta página, 5 se apoyan en un evento verificado y 1 son inferencia de la plataforma, cada uno etiquetado donde aparece. Detrás hay 2 dimensiones tecnológicas, una trayectoria reconstruida desde que los modelos de lenguaje llegaron al público y 6 eventos verificados.
Ver qué tecnologías, cómo llegó hasta aquí y el método →
Dónde se sitúa en la clasificación oficial: habilidades, conocimientos y trabajos afines →
Otros puestos de la misma función#
Una empresa divide su trabajo en funciones antes de dividirlo en puestos. Estos están en Tecnología y datos junto a este — un hecho sobre los organigramas, no un juicio de que se parezcan ni de que cambien en la misma dirección.
Desarrollador de software júnior · Ingeniero de software con experiencia · Desarrollador backend · Ingeniero de datos · Ingeniero de aprendizaje automático · Investigador de IA · Tester de software / ingeniero de QA · Analista de datos · Científico de datos · Estadístico · Economista · Analista de negocio · Responsable de sistemas de negocio · Técnico de soporte informático / mesa de ayuda · Analista de seguridad (SOC) · Ingeniero de DevOps / ingeniero de plataforma / SRE · Ingeniero de redes · Redactor técnico / ingeniero de documentación · Redactor de solicitudes de subvención / técnico de subvenciones