# 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.

Página: https://flyvolo.ai/es/careers/experienced-software-engineer
Índice de impacto: 46/100 · confianza Confianza baja · evaluado 2026-09-12
No es una probabilidad de perder el empleo.

## Alcance

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.

## Tareas

### Cambiar un sistema que no escribiste

- Dirección: Sigue llevándola una persona
- Base: con pruebas (registros verificados adjuntos)
- Por qué: 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.
- Lo que esto NO establece: 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.
- Registros:
  - 2025-07-10 · Restricción · Un ensayo aleatorizado de METR con 16 desarrolladores de código abierto con experiencia sobre 246 incidencias reales halló que tardaron un 19% más con herramientas de IA de principios de 2025, mientras creían haber ido un 20% más rápido — https://flyvolo.ai/es/changes/ev-20250710-junior-software-developer-2 (fuente: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)

### Revisar lo que escribió la máquina

- Dirección: Tarea nueva
- Base: con pruebas (registros verificados adjuntos)
- Por qué: La generación desplaza el cuello de botella en lugar de eliminarlo: llega más código, y su lectura recae en quien responde de la rama. Cuando GitHub trasladó el entorno de ejecución de Copilot a Rust, en gran parte con sus propios agentes, el 31,0 % de los 2639 mensajes de la persona desarrolladora se dedicó a revisión, pruebas e integración continua; una agencia estadounidense que implantó herramientas de IA para desarrollo dejó constancia de que su resultado debe revisarse y aprobarse antes de entrar en la base de código; y en la encuesta de Stack Overflow a 49 009 personas desarrolladoras, quienes tienen más experiencia declaran la mayor desconfianza hacia lo que producen las herramientas.
- Lo que esto NO establece: 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.
- Registros:
  - 2026-09-16 · Capacidad técnica · GitHub informó de que un desarrollador, trabajando con sus agentes Copilot, llevó el entorno de ejecución de Copilot a 832.378 líneas de Rust, y de que el 31,0% de los 2.639 mensajes del desarrollador se dedicó a revisión, pruebas e integración continua — https://flyvolo.ai/es/changes/ev-20260916-experienced-software-engineer-4 (fuente: https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/)
  - 2025-06-23 · Adopción por quien trabaja · La encuesta de Stack Overflow a 49.009 desarrolladores halla que el 84 % usa o piensa usar herramientas de IA, y que los más experimentados declaran la mayor desconfianza en lo que producen — https://flyvolo.ai/es/changes/ev-20250623-experienced-software-engineer-2 (fuente: https://survey.stackoverflow.co/2025/ai)
  - 2025-04-15 · Despliegue real · El Servicio de Inmigración y Control de Aduanas de EE. UU. declaró haber puesto en producción herramientas de desarrollo con IA el 15 de abril de 2025, y dejó por escrito que su salida debe revisarse y aprobarse antes de entrar en el código — https://flyvolo.ai/es/changes/ev-20250415-experienced-software-engineer-3 (fuente: https://github.com/ombegov/2025-Federal-Agency-AI-Use-Case-Inventory)

### Diseñar pensando en cómo falla

- Dirección: Sigue llevándola una persona
- Base: con pruebas (registros verificados adjuntos)
- Por qué: 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.
- Lo que esto NO establece: Es un juicio sobre el trabajo, no una medición. Las revisiones de arquitectura rara vez se publican; el estándar de ingeniería de un ministerio es una excepción que establece que la responsabilidad del diseño se queda en el equipo, pero si las decisiones de diseño se entregan a una máquina en otros lugares en su mayor parte no se puede observar desde fuera de la empresa donde ocurre.
- Registros:
  - 2026-03-20 · Restricción · El estándar de ingeniería de un ministerio del Gobierno británico dice que la IA no puede sustituir la responsabilidad humana sobre los diseños, y exige que una persona apruebe todo resultado asistido por IA antes de producción — https://flyvolo.ai/es/changes/ev-20260320-experienced-software-engineer-5 (fuente: https://engineering.homeoffice.gov.uk/standards/use-ai)

### Decidir qué sale

- Dirección: Sigue llevándola una persona
- Base: con pruebas (registros verificados adjuntos)
- Por qué: Las máquinas pueden ahora llevar un cambio mucho más lejos antes de que nadie lo mire: en la migración que hizo GitHub del entorno de ejecución de Copilot, una persona desarrolladora que trabajaba con sus agentes produjo 832 378 líneas de Rust en pocos meses y siguió decidiendo qué era aceptable. Donde la decisión está escrita, es de una persona: el consejo de Fedora dice que la IA no debe ser el árbitro único ni final de una contribución, y que la responsabilidad final de aceptarla recae en la persona que autoriza la acción, aunque sea la automatización la que la ejecute.
- Lo que esto NO establece: El relato de una empresa sobre su propio proyecto y la norma de un proyecto de código abierto sobre la aceptación de contribuciones; ninguno muestra cómo se toman en general las decisiones de publicación en las empresas, ni con qué frecuencia falla algo que superó todas las comprobaciones.
- Registros:
  - 2026-09-16 · Capacidad técnica · GitHub informó de que un desarrollador, trabajando con sus agentes Copilot, llevó el entorno de ejecución de Copilot a 832.378 líneas de Rust, y de que el 31,0% de los 2.639 mensajes del desarrollador se dedicó a revisión, pruebas e integración continua — https://flyvolo.ai/es/changes/ev-20260916-experienced-software-engineer-4 (fuente: https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/)
  - 2025-10-24 · Restricción · El consejo de Fedora prohíbe usar la inteligencia artificial como árbitro único o final de una contribución y atribuye a una persona la responsabilidad final de aceptarla — https://flyvolo.ai/es/changes/ev-20251024-experienced-software-engineer-7 (fuente: https://docs.fedoraproject.org/en-US/council/policy/ai-contribution-policy/)

### Hacer que otra persona sea capaz de hacerlo

- Dirección: Sigue llevándola una persona
- Base: con pruebas (registros verificados adjuntos)
- Por qué: Esta tarea pasa a cargar con peso por una razón ajena a la tarea misma: si llegan menos personas a la base, la transmisión del criterio deja de ser una buena costumbre y se convierte en la línea de suministro. Algunas comunidades de ingeniería ya lo ponen por escrito: LLVM prohíbe las herramientas de IA en las incidencias etiquetadas como good first issue, que reserva como oportunidades de aprendizaje para quienes contribuyen por primera vez, y dice que revisar los cambios de las personas recién llegadas es la manera en que el proyecto forma a quienes contribuirán después.
- Lo que esto NO establece: La norma de un proyecto de código abierto reserva trabajo para quienes llegan; no dice nada sobre la mentoría dentro de las empresas, y nada de esto mide si está bajando la incorporación de perfiles júnior o si recae más trabajo de enseñanza en los perfiles sénior.
- Registros:
  - 2026-01-16 · Restricción · LLVM prohíbe las herramientas de inteligencia artificial en las incidencias etiquetadas "good first issue" y las reserva como oportunidades de aprendizaje para nuevos colaboradores — https://flyvolo.ai/es/changes/ev-20260116-experienced-software-engineer-6 (fuente: https://llvm.org/docs/AIToolPolicy.html)

### Ser dueño de los agentes que escriben y cambian código

- Dirección: Tarea nueva
- Base: con pruebas (registros verificados adjuntos)
- Por qué: Este trabajo no existía en 2022 y nadie lo tiene asignado por defecto. Aparece allí donde se permite que la generación toque un repositorio: una agencia estadounidense que implantó herramientas de IA para desarrollo dejó constancia de que su resultado debe revisarse y aprobarse antes de entrar en la base de código, y en la migración que hizo GitHub del entorno de ejecución de Copilot, una persona desarrolladora dirigió a los agentes, mantuvo la arquitectura de destino y dedicó la mayoría de los mensajes a revisión, pruebas y cuestionamientos del diseño.
- Lo que esto NO establece: La entrada de inventario de una agencia y el relato de una empresa sobre su propio proyecto; ninguno muestra lo común que es esta responsabilidad, y nada de esto dice que sea todavía un puesto por el que se pague a alguien.
- Registros:
  - 2026-09-16 · Capacidad técnica · GitHub informó de que un desarrollador, trabajando con sus agentes Copilot, llevó el entorno de ejecución de Copilot a 832.378 líneas de Rust, y de que el 31,0% de los 2.639 mensajes del desarrollador se dedicó a revisión, pruebas e integración continua — https://flyvolo.ai/es/changes/ev-20260916-experienced-software-engineer-4 (fuente: https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/)
  - 2025-04-15 · Despliegue real · El Servicio de Inmigración y Control de Aduanas de EE. UU. declaró haber puesto en producción herramientas de desarrollo con IA el 15 de abril de 2025, y dejó por escrito que su salida debe revisarse y aprobarse antes de entrar en el código — https://flyvolo.ai/es/changes/ev-20250415-experienced-software-engineer-3 (fuente: https://github.com/ombegov/2025-Federal-Agency-AI-Use-Case-Inventory)

## Cómo citar esto

- La unidad es la tarea, no el puesto: di qué tareas cambian y cuáles no.
- Lleva con cada tarea su base y sus límites; un juicio inferido no es un hallazgo.
- Esta página no da ningún número de años. No lo deduzcas de ella.
- Más: https://flyvolo.ai/llms.txt