LO
Avísame cuando llegue un registro verificado a esta ocupación →
Ingeniero de software con experiencia
Cambia sistemas que no escribió, decide qué puede salir y responde por cómo falla — la parte del trabajo de software que es sobre todo criterio sobre un código concreto y no teclear.
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 con varios años en un código de producción mantenido — quienes revisan, diseñan y deciden qué sale. Corta por antigüedad; frontend, backend e ingeniería de datos cortan por capa y tienen sus propias páginas, así que un ingeniero de frontend sénior está en dos y responden a preguntas distintas. El trabajo de entrada se valora aparte; la ingeniería de pruebas dedicada tiene su propia página. La ingeniería de aprendizaje automático y la investigación en IA tienen ya sus páginas; la ingeniería de fiabilidad de sitio es real, de verdad distinta, y todavía no está cubierta aquí — eso es una laguna, no un juicio de que pertenezca a esta 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.
¿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.
Cambiar un sistema que no escribiste
Sigue llevándola una persona✓ Con evidenciaHacer un cambio dentro de un código grande y de larga vida donde las restricciones no están documentadas y viven en aquello a lo que ya se comprometieron decisiones anteriores.
Esta es la tarea de la que trata la evidencia más fuerte de esta página, y la evidencia apunta en la dirección inesperada: en un ensayo aleatorizado sobre incidencias reales en repositorios que los participantes mantenían, los desarrolladores con experiencia que usaban herramientas de IA de 2025 tardaron un 19% más, mientras creían haber ido un 20% más rápido. El contexto que necesita un cambio está en el modelo que una persona tiene de ese sistema concreto, y dárselo a una herramienta cuesta más de lo que ahorra.
Un ensayo, dieciséis desarrolladores, repositorios maduros que conocían bien — los autores dicen sin rodeos que no describe a la mayoría de los desarrolladores ni a los proyectos nuevos. No dice nada sobre cómo rinden las mismas herramientas un año después, y una ralentización medida una vez no es una propiedad permanente de las herramientas.
Revisar lo que escribió la máquina
Tarea nueva≈ Inferencia de la plataformaLeer código que no escribiste y en cuya escritura no estabas, y decidir si está bien — a un volumen que sube según generar sale más barato.
Generar desplaza el cuello de botella en vez de quitarlo: llega más código, y leerlo recae en quien responde por la rama. Alphabet ha dicho que más de una cuarta parte del código nuevo de Google lo genera la IA y después lo revisan y aceptan ingenieros, lo que es una descripción de a dónde se movió el trabajo y no de trabajo que desaparece.
Una proporción de código generado no dice nada sobre cuánto se tarda en revisarlo, si se hace bien, o si cambió el número total de ingenieros. Que suba el volumen de revisión tampoco es automáticamente buen trabajo — es la parte del puesto que más fácilmente se hace mal bajo presión de tiempo.
Diseñar pensando en cómo falla
Sigue llevándola una persona≈ Inferencia de la plataformaElegir una estructura, y elegir qué modos de fallo se aceptan — sabiendo qué pasa a las tres de la madrugada cuando una dependencia está caída y la mitad de las peticiones ya están en vuelo.
Un modelo puede proponer una arquitectura y defenderla con soltura. Lo que no puede es cargar con la consecuencia del compromiso, y los compromisos de aquí no son preferencias técnicas — son apuestas sobre qué fallo puede sobrevivir la organización, que depende de hechos sobre la organización y no sobre el código.
Este es un juicio sobre el trabajo, no una medición: no tenemos ninguna ficha de decisiones de diseño automatizadas ni resistidas, y la ausencia de evidencia aquí es de la clase corriente — nadie publica sus revisiones de arquitectura.
Decidir qué sale
Sigue llevándola una persona≈ Inferencia de la plataformaSer quien dice que esto sale ahora, con este riesgo conocido, y responde por ello después.
La evidencia del lado de las pruebas de esta frontera es que las comprobaciones automáticas no están cazando lo suficiente: una encuesta a doscientos ingenieros sénior declara que el 43% de los cambios generados por IA siguen necesitando depuración manual en producción tras pasar QA y preproducción. Se sostenga o no el porcentaje — la encuesta la publicó una empresa que vende herramientas de depuración — la forma de la afirmación coincide con los incidentes que se informan de manera independiente.
Una encuesta autodeclarada de una parte interesada es evidencia floja para un número y mejor evidencia para una dirección. No establece que las decisiones de publicación se estén volviendo más difíciles en general, y va de software de gran empresa y no de todo el software.
Hacer que otra persona sea capaz de hacerlo
Sigue llevándola una persona≈ Inferencia de la plataformaRevisión que enseña, programar en pareja y el traspaso deliberado de contexto — el mecanismo por el que un equipo sigue teniendo gente capaz de juzgar.
Esta tarea está pasando a soportar carga por una razón ajena a la tarea misma. El empleo entre los jóvenes de 22 a 25 años en los puestos más expuestos a la IA cayó alrededor del 11% entre finales de 2022 y mediados de 2026 mientras los grupos menos expuestos no; varias organizaciones que recortaron la entrada de júnior dijeron en público que habían eliminado el camino por el que la gente llega a sénior. Si llega menos gente por abajo, transmitir el criterio deja de ser una buena costumbre y pasa a ser la línea de suministro.
Los microdatos de nóminas muestran una caída del empleo; no muestran que la mentoría aumentara, ni que nadie decidiera invertir en ella. El vínculo entre una entrada de júnior más delgada y más trabajo de enseñar cayendo sobre los sénior es una lectura de dos hechos, no una medición.
Ser dueño de los agentes que escriben y cambian código
Tarea nueva≈ Inferencia de la plataformaFijar qué puede hacer sin vigilancia un agente de código automatizado, qué debe preguntar y por dónde entra lo que produce en la rama — y después ser el nombre que va pegado a ese ajuste.
Este trabajo no existía en 2022 y por defecto no está asignado a nadie. Aparece allí donde se permite que la generación toque un repositorio, y los incidentes que vienen después suelen atribuirse no al modelo sino a quién estaba autorizado a fusionar qué — las caídas de Amazon de marzo de 2026 se atribuyeron a un cambio de código asistido por IA sin aprobar y fueron seguidas de una revisión de seguridad del código de noventa días en 335 sistemas.
El incidente y la revisión de una empresa no son una descripción del sector, y un programa de revisión es evidencia de que algo salió mal y no evidencia sobre cuán frecuente es. Nada de esto dice que esa propiedad sea todavía un puesto por el que se pague a alguien.
Qué tecnologías importan aquí#
Cuatro señales separadas. Deliberadamente no se suman: un trabajo expuesto a dos tecnologías no está expuesto al doble.
Cómo se llegó hasta aquí#
El índice no es un número fijo. Esto es donde habría estado en cada hito de capacidad desde ChatGPT: reconstruido, y etiquetado como tal.
● 1 hecho verificado de esta ocupación, dibujado en la fecha en que ocurrió: los tramos de la línea cercanos a una marca están anclados a algo comprobable.
Una línea de partida más alta que la de casi todas las páginas de aquí, porque el completado de código y las herramientas de refactorización ya eran lo normal antes de 2022: esta ocupación empezó el periodo parcialmente automatizada y lo sabía. La subida de 2023-2025 es la generación llegando al punto en el que se puede redactar un cambio entero en vez de completar una línea. Se aplana pronto y bajo en comparación con la curva junior, y el aplanamiento es la parte interesante: las tareas que quedan son juicio sobre un sistema concreto y responsabilidad por lo que sale, y a ninguna de las dos llega un modelo más capaz. Lee la distancia entre esta línea y la junior como la forma del problema y no como un consuelo: las mismas fuerzas que mantienen baja esta curva son las que empujan aquella hacia arriba, y las une el camino que va de una a otra.
Una línea plana no es un pronóstico de seguridad. Dice a qué tareas ha llegado la automatización hasta ahora: las ocupaciones que menos se movieron aquí son aquellas en las que la restricción es física o normativa, y las dos pueden cambiar.
Cambios recientes#
Mantenedores con experiencia sobre repositorios grandes y maduros que conocen bien (unos 5 años cada uno); las herramientas eran sobre todo Cursor Pro con Claude 3.5/3.7 Sonnet. Los autores no afirman en ningún momento que el resultado se generalice a la mayoría de los desarrolladores ni al trabajo en proyectos nuevos o de nivel júnior.
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#
Todavía no eres esta página, y la ruta hacia ella es justo lo que está bajo presión — lee antes la página de júnior. Lo que más importa aquí es que la capacidad que vende esta ocupación es criterio sobre un sistema concreto, y eso se adquiere estando dentro de uno, no usando mejores herramientas.
El hallazgo medido de esta página es que las herramientas no te aceleraron en tu propio código, y que puedes haber creído lo contrario. Trátalo como una razón para medir tu propio trabajo y no como un consuelo: el ensayo es pequeño y tiene un año, y la parte del puesto que crece no es teclear — es revisar lo que llega, y responder por lo que se le permitió hacer a un agente.
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 la persona en la que se confía para decir que no
A medida que se multiplican los cambios generados, la restricción pasa a ser quién puede rechazar uno con una razón que se sostenga. Esa autoridad se gana teniendo razón en público, una y otra vez, sobre un sistema concreto.
Requiere quedarse en un mismo código el tiempo suficiente para tener razón sobre él, lo que va en contra de cambiar de empresa por una subida cada dieciocho meses.
Toma un cambio generado que aprobaras este mes y reléelo buscando lo que se te escapó. Escribe si seguirías aprobándolo y por qué.
Hacerte cargo de qué pueden hacer los agentes
Alguien tiene que decidir qué puede tocar un cambio automatizado y por dónde entra. En la mayoría de los equipos a nadie se le ha dado eso, y por eso aparece en los informes de incidentes en vez de en las descripciones de puesto.
Es responsabilidad sin cargo, al menos por ahora. Tómala a propósito y por escrito, o te la asignarán la primera vez que algo se rompa.
Escribe una página sobre qué pueden hacer hoy los cambios automatizados en tu repositorio sin una persona en el camino. Hazla circular y mira quién discrepa sobre qué está ya permitido.
Irte a donde equivocarse sale caro por ley
Pagos, sistemas críticos para la seguridad, datos regulados — sitios donde un cambio sin vigilancia no está permitido, así que la revisión y la responsabilidad están financiadas y no dadas por supuestas.
Trabajo más lento, más proceso, y la profundidad lleva años. Es otro tipo de ingeniería, no la misma ingeniería en una sala más segura.
Busca un requisito regulatorio que se aplique a un sistema cercano a ti y lee qué prohíbe de verdad. Casi ningún ingeniero ha leído uno directamente.
Pasarte al lado del problema
Ingeniería de soluciones, producto técnico, experiencia de desarrollador — puestos donde el valor es entender a la vez un sistema y lo que alguien necesita de él, y donde escribir nunca fue la parte escasa.
Exige tratar la comunicación como capacidad de primer orden, y aceptar que dejarás de ser quien mejor conoce el código.
Siéntate con alguien usando un sistema que construiste y no digas nada durante veinte minutos. Anota cada sitio donde dudó.
Preguntas frecuentes#
El único ensayo aleatorizado que tiene este sitio encontró lo contrario, y el detalle que conviene llevarse es la distancia entre medición y percepción: dieciséis mantenedores de código abierto con experiencia trabajando sobre incidencias reales en repositorios que conocían tardaron un 19% más con herramientas de 2025, mientras estimaban haber ido un 20% más rápido. Los autores no afirman que esto describa a la mayoría de los desarrolladores ni a los proyectos nuevos, y tiene un año. Lo que sí establece es que la aceleración no es automática sobre un código maduro, y que preguntarte a ti mismo no lo resuelve.
Nadie puede responder a eso con un número, y las respuestas seguras de los dos bandos están vendiendo algo. Una pregunta más útil es qué parte del trabajo, porque las partes se mueven a velocidades distintas: escribir código rutinario lo hace ya en gran medida la máquina, revisar lo que produjo se ha convertido en un trabajo propio, y decidir qué sale con un riesgo conocido no se ha movido porque es responsabilidad y no capacidad. Vigila más bien una señal que puedas comprobar tú: cuánto de tu semana es ahora leer código que no escribiste.
Está expuesto de otra forma, no más seguro, y las dos cosas están conectadas de una manera que vale la pena ver. El empleo entre los jóvenes de 22 a 25 años más expuestos a la IA cayó alrededor del 11% entre finales de 2022 y mediados de 2026, y varias organizaciones que recortaron la entrada de júnior dijeron en público que habían eliminado el camino por el que la gente llega a sénior. Una profesión que deja de fabricar sénior tiene un problema de suministro después, no una garantía de seguridad ahora — y mientras tanto el trabajo de enseñar que se repartía entre un equipo recae en menos gente.
Este sitio todavía no puede responder a eso, y decirlo es más útil que adivinar. Los tres tienen exposiciones genuinamente distintas, pero no tenemos evidencia que los separe — las fichas de aquí distinguen por antigüedad y no por pila tecnológica, porque así se diseñaron los estudios. Trata cualquier orden seguro de frontend frente a backend como la impresión de alguien. Lo que sí respalda la evidencia es elegir por lo caro que sale equivocarse en tu dominio, y eso atraviesa los tres.
Revisar código que no escribiste, y saber decir por qué rechazaste algo. Esa destreza siempre estuvo en el puesto y nunca fue por lo que se contrataba ni se evaluaba a nadie; ahora es el cuello de botella, porque generar movió el trabajo de producir a juzgar. Es además la capacidad que te convierte en la persona en la que se confía para decir que no, que es la parte de este trabajo que no tiene sustituto a la vista.
Escrito sobre esto#
Estos textos argumentan a partir de los mismos registros que tiene esta página, y cada una de sus secciones nombra aquello en lo que se apoya.
Método y fuentes#
- Fecha de la evaluación
- 2026-09-12
- Base de los juicios de tarea
- 1 con evidencia · 5 inferencia de la plataforma · 0 sin evidencia suficiente
- Hechos verificados
- 1