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 backend
Es dueño de la parte donde equivocarse sale caro y no se ve — los datos que tienen que seguir siendo coherentes, el dinero que no puede moverse dos veces, y el servicio que tiene que estar en pie a las tres de la madrugada.
Busca un invariante de tu sistema que no pueda violarse nunca, y comprueba si algo lo hace cumplir de verdad o si simplemente todo el mundo evita romperlo.
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 servicios, API y capas de datos. Corta por capa y no por antigüedad — las páginas de júnior y de experiencia cortan al revés y un ingeniero de backend sénior está en las dos. El trabajo de plataforma y de fiabilidad de sitio se solapa pero responde por otras cosas; las canalizaciones de datos tienen su propia página.
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.
Generar un endpoint no es lo mismo que decidir que debe existir, qué tiene que garantizar, o qué pasa cuando se le llama dos veces. Teclear rara vez fue la parte cara de este trabajo.
Uber informa de que una herramienta redacta ya correcciones para carreras de datos de bajo nivel en su código Go, y de que los responsables del código aceptan la mayoría y rechazan algunas que pasaban las pruebas pero eran erróneas; eso son carreras en una sola base de código, no transacciones ni orden entre servicios. Los incidentes casi nunca se atribuyen en público a código de concurrencia generado, y ese silencio no es evidencia de que no ocurra.
Google informa de que la mayor parte del código de una gran migración de identificadores lo escribió la IA, mientras que cada cambio lo revisaron y desplegaron personas; eso es un cambio de código en una empresa, no una migración de esquema en producción. La afirmación va de quién decide y responde por ello, no de quién lo teclea.
La agencia de ciberseguridad del Reino Unido aconseja escribir la lógica de autorización de una forma más cercana a lo manual, y un banco de pruebas encontró que cerca de la mitad de los backends funcionales escritos por los modelos podían explotarse; ninguno de los dos es un estudio de defectos que separe el código generado del escrito a mano dentro de la misma base de código, que es lo que lo zanjaría. Los entornos regulados ya exigen aquí la firma de una persona, y puede que sea eso, más que la dificultad, lo que está sosteniendo el trabajo.
Nada de esto mide cuánto de esto está hoy dirigido por herramientas en la práctica, y la respuesta difiere enormemente entre un equipo con presupuesto de observabilidad y uno sin él.
Esto no dice nada sobre si la carga de guardias está subiendo o bajando, que es la pregunta que de verdad importa a la mayoría de los ingenieros y la que nadie publica.
¿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 guía de la agencia nacional de ciberseguridad del Reino Unido, escrita por uno de sus arquitectos principales de seguridad, que sitúa el desarrollo asistido por IA en un espectro que va de lo totalmente generado a lo manual. Aconseja deslizarse hacia lo manual cuando se construye lógica de autenticación o autorización, se tratan datos personales sensibles, se manejan secretos, tokens o credenciales, o allí donde las consecuencias de un fallo de seguridad serían importantes. Es un consejo, no una norma vinculante, y no prohíbe usar IA para código de seguridad; no da cifras sobre cómo trabajan de verdad los desarrolladores.
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 mismo censo: 20 preguntas fijas planteadas a todos los organismos que informan por obligación legal, cada una respondida con Sí o No, con el producto citado y las licencias por tramos. Generar código con IA recibe Sí en 31 de 45, séptimo entre los 20. Lo que da valor a esta fila por encima de su recuento es la columna del producto, porque las herramientas nombradas no existían hace tres años: GitHub Copilot en Agricultura, Asuntos de Veteranos, la SEC y una docena más, Claude Code en Interior, Poolside en Seguridad Nacional y Trabajo, Codex en la Oficina de Gestión de Personal, Amazon Q Developer en Salud y Servicios Humanos. Compárese con la fila de reservas de viaje del mismo archivo, donde la mayoría de los Sí nombran SAP Concur: en aquella pregunta los organismos señalaban en buena medida una plataforma que ya tenían, y en esta no. Tres límites. Un tramo de 10.000 a 50.000 en Energía o en la Agencia de Protección Ambiental es una licencia corporativa que también responde a otras filas de este archivo, de modo que no es un recuento de personas escribiendo código con ella. Un Sí es el empleador declarando que dispone de la herramienta, no una medición de cuánto código escribe ni de cuánto de ese código se conserva. Y la pregunta dice código sin decir back-end o front-end, ni cuánto tiempo lleva en el oficio quien lo escribe; este registro se adjunta aquí porque escribir código de servicio rutinario es lo que esta tarea es, no porque el inventario lo diga.
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.
Un banco de pruebas revisado por pares de 392 tareas de backend, cada una un conjunto de endpoints que implementar a partir de una especificación, con pruebas funcionales y exploits de seguridad de extremo a extremo, entre ellos control de acceso indebido y autorización incorrecta. El mejor modelo en corrección llegó al 62%; de media, cerca de la mitad de los programas correctos que producía cada modelo podían explotarse; y el mejor modelo en código correcto y seguro llegó al 35%. Son modelos de 2025 escribiendo backends enteros a partir de una especificación, no cambios dentro de una base de código existente, y algunos autores trabajan para una empresa que construye agentes de programación con IA.
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.
Un artículo revisado por pares de ingenieros de Uber sobre una herramienta que funciona en el propio flujo de trabajo de desarrollo de Uber. A lo largo de 18 meses identificó 404 carreras de datos reproducibles en la base de código Go de Uber, produjo correcciones para 224 (el 55%), y los desarrolladores aprobaron 193 de ellas (el 86%) en la revisión de código; entre las correcciones rechazadas había algunas consideradas incorrectas pese a pasar las pruebas iniciales. Uber no vende la herramienta. Abarca carreras de datos de bajo nivel en un solo lenguaje y una sola base de código, no transacciones, idempotencia, reintentos ni orden entre servicios, y cada corrección pasó por la revisión de una persona.
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.
Ingenieros de Google describiendo su propio uso de modelos de lenguaje para grandes migraciones internas de código. En un caso de estudio, los identificadores de la base de código de Ads (más de 500 millones de líneas) tenían que pasar de 32 a 64 bits para evitar escenarios de desbordamiento a valores negativos que podían causar caídas del servicio; el 80% de las modificaciones de código de los cambios integrados fueron escritas íntegramente por IA, en la mayoría de los casos una persona tuvo que revertir al menos parte de los cambios del modelo, y los ingenieros estimaron que el tiempo total se redujo un 50%. El artículo dice que las revisiones de código y los despliegues de cambios siguen exigiendo un operador humano. Google vende los modelos que usó. Es un cambio de tipo en el código de toda una base de código, no una migración de esquema de una base de datos en producción.
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.
Una gran empresa tecnológica, con datos que ella misma declara y sin definir cómo se mide lo «generado» (autocompletado frente a funciones enteras). La cifra abarca todo el código nuevo de Google sin decir de qué tipo; este registro se asocia a esta tarea porque escribir código de servicio rutinario —manejadores, validación, llamadas entre servicios y sus pruebas— es precisamente esta tarea, no porque la declaración señale el trabajo de backend. No dice nada sobre contratación, y la revisión siguió en manos de los ingenieros.
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.
Una estimación interna de Amazon sobre la propia ingeniería de Amazon, publicada por la empresa que vende la herramienta — quien hace el trabajo, quien lo mide y quien lo vende son la misma parte, lo que se dice aquí porque no puede comprobarse desde fuera. La empresa publica además su método: el tiempo ahorrado se estimó a partir del número de dependencias Java migradas, suponiendo un día o más de tiempo de desarrollador por dependencia hecha a mano. Fíjate en qué es la migración: una subida de versión de lenguaje tiene un compilador y una batería de pruebas existente como árbitro, así que el éxito se comprueba a máquina en cada paso — la forma más favorable posible para esta clase de automatización y no un resultado general sobre el trabajo de backend. Y fíjate en qué se afirma y qué no: 4.500 años es trabajo no hecho, más de mil desarrolladores, sin que se diga en ninguna parte que alguno se fuera o que se eliminara un puesto.
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.
Un artículo revisado por pares, en su mayoría de autores de Microsoft, sobre una herramienta para ingenieros de guardia que atienden incidentes en la nube. Su componente de recogida de información de diagnóstico lleva más de cuatro años desplegado en más de 30 equipos de Microsoft; un componente de predicción de la causa raíz que usa un modelo de lenguaje, tras una fase preliminar con éxito, lo tiene desplegado activamente un equipo de gestión de incidentes desde hace varios meses. Ayuda en el diagnóstico; no decide qué revertir ni qué aceptar, y Microsoft vende los modelos implicados.
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.
Qué significa esto para ti#
La mitad visible de este trabajo — endpoints y fontanería — es la mitad expuesta, y es lo que te habrían contratado para hacer. Las partes que aguantan van de qué no puede pasar nunca, y eso se aprende estando presente cuando algo sí pasó. Acércate a un turno de guardia antes de lo que resulta cómodo.
Tu posición es más fuerte que la de la página de frontend en la tarea más expuesta, y la razón no es que el trabajo sea más difícil — es que equivocarse sale caro y no se ve, así que la responsabilidad está concentrada. Vigila el modo de fallo que eso crea: revisar cambios generados en sistemas donde un error es silencioso durante meses.
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.
Ir a donde un error sale caro
Pagos, contabilidad, identidad, cualquier cosa con un regulador — dominios donde un cambio sin vigilancia no está permitido, así que la revisión y la responsabilidad están financiadas y no dadas por supuestas.
Más lento, más proceso, y la profundidad lleva años. Es otro tipo de ingeniería, no el mismo trabajo en una sala más segura.
Busca un invariante de tu sistema que no pueda violarse nunca, y comprueba si algo lo hace cumplir de verdad o si simplemente todo el mundo evita romperlo.
Ser dueño de la frontera que los agentes pueden cruzar
Alguien tiene que decidir qué puede tocar un cambio automatizado en un servicio donde un error es silencioso. En la mayoría de los equipos a nadie se le ha dado eso, y por eso aparece en las revisiones de incidentes en vez de en las descripciones de puesto.
Responsabilidad sin cargo, por ahora. Tómala por escrito o te la asignarán la primera vez que algo se rompa.
Escribe qué puede fusionar y desplegar hoy un cambio automatizado en tu servicio sin una persona en el camino. Hazlo circular y mira a quién le sorprende.
Pasar a trabajo de datos o de plataforma
El razonamiento sobre coherencia, fallos y coste se transfiere directamente, y los dos son sitios donde el mismo criterio se aplica a una superficie más amplia.
Los dos te alejan más del producto y de la gente que lo usa, que es el coste que a algunos ingenieros les importa.
Rastrea un número de un cuadro de mando de la empresa hasta la tabla de la que sale, y cuenta por cuántas transformaciones pasó.
Preguntas frecuentes#
Las partes se mueven a velocidades distintas, así que un solo número escondería lo que necesitas. Escribir endpoints es ya en gran medida trabajo de máquina. Decidir qué no puede pasar nunca cuando llegan dos peticiones a la vez, o qué se le permite revelar a un mensaje de error, no se ha movido, porque son posiciones de las que se responde y no de teclear. Una señal que puedes comprobar: cuando algo se rompió el trimestre pasado, ¿la parte difícil fue encontrarlo o decidir qué hacer con ello?
En su tarea más visible está menos expuesto, y la razón conviene entenderla en vez de tomarla como consuelo: la corrección en backend a menudo es invisible y sale cara si falla, así que más parte del trabajo es responsabilidad. Es una diferencia estructural, no un orden de dificultad, y puede cambiar — la mitad de endpoints de este trabajo está expuesta exactamente en los mismos términos que la mitad de frontend.
Para las entrevistas, eso todavía no ha cambiado. Para el trabajo, la división honesta es que recordar un algoritmo importa menos que antes, mientras que razonar sobre fallos importa más — saber qué le hace un reintento a un sistema que ya va apurado es la misma destreza que intentan medir las preguntas de diseño de sistemas, aplicada a algo real. Apréndela de tus propios incidentes y no de una lista.
Ya puede redactar uno, y esa no es la restricción. La restricción es que alguien tiene que garantizar qué no puede hacer nunca, migrar sus datos años más tarde sin perder nada, y estar despierto cuando falle. Son posiciones de responsabilidad, y la responsabilidad no se ha abaratado — en los dominios regulados se ha vuelto más explícitamente obligatoria.
¿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, 6 se apoyan en un evento verificado y 0 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 8 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 frontend · 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