Ingeniero de software con experiencia

Relato de ingeniería del propio GitHub sobre el paso de TypeScript a Rust del entorno de ejecución que hay detrás de Copilot CLI y del Copilot SDK: 832.378 líneas de Rust de producción y 468.689 líneas de pruebas unitarias en Rust, hecho principalmente por un solo desarrollador en unos pocos meses. De 2.639 mensajes escritos por la persona, el 31,0% se centró en revisión, pruebas e integración continua; el 17,4% cuestionó decisiones técnicas o de diseño, y el 15,0% insistió en que el trabajo quedara completo. De 1.130.921 llamadas a herramientas, el 61% salió de subagentes y no del hilo principal de la sesión: un reparto entre agentes, no una parte del trabajo hecho por agentes. El desarrollador se quedó con la arquitectura de destino, qué comportamiento tenía que seguir idéntico, cómo se dividía el trabajo, las disyuntivas ambiguas, el juicio sobre la evidencia, la revisión manual de las zonas de alto riesgo y las decisiones finales de fusión. También describe a un agente que aplicó una etiqueta que dejaba pasar una comprobación de esquema y que, al indagar, resultó ocultar una regresión. Un desarrollador, un proyecto, en el propio código del proveedor. Registrado como capacidad, que en este sitio nunca mueve una valoración.

Una demostración, una prueba de referencia o un artículo muestran que la tarea se puede hacer. Actualiza lo que la tecnología puede hacer, no lo que harán las empresas.

Un estándar de ingeniería que obliga a los equipos de software del Ministerio del Interior británico. Dice que los equipos seguirán respondiendo plenamente de todo el código y los resultados asistidos por IA porque las herramientas de IA no pueden sustituir el juicio, la comprensión, la propiedad ni la responsabilidad humanas sobre las decisiones, los diseños o los cambios hechos en los sistemas, que los resultados asistidos por IA deben ser revisados y aprobados por una persona antes de llegar a producción, y que los equipos deben poder afirmar la seguridad y la mantenibilidad de lo que ejecutan. El «must» tajante se aplica a la revisión; la frase sobre los diseños dice dónde recae la responsabilidad. Es el estándar publicado de un ministerio, no una medida de la práctica en otros lugares.

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 gran proyecto de compilador de código abierto, vinculante para sus colaboradores. La política dice que no deben usarse herramientas de inteligencia artificial para resolver incidencias de GitHub etiquetadas good first issue, porque esas incidencias por lo general no son urgentes y están pensadas como oportunidades de aprendizaje para nuevos colaboradores; dice que trasladar a un LLM los comentarios de los mantenedores no ayuda a nadie a crecer, y que revisar los cambios de los nuevos colaboradores forma parte de formar a la siguiente generación de colaboradores. La cláusula llegó con la primera versión de la política, incorporada el 16 de enero de 2026; las ediciones posteriores no la modificaron. Es la norma de un proyecto, no la de un empleador.

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.

Una gran distribución de Linux, vinculante para sus colaboradores y revisores. La política, cuyos MUST y MUST NOT tienen su significado normativo habitual en las especificaciones, dice que no se debe usar la inteligencia artificial como árbitro único o final al emitir un juicio sustantivo o subjetivo sobre una contribución, y que la responsabilidad final de aceptar una contribución, aunque la ejecute un sistema automatizado, recae siempre en el colaborador humano que autoriza la acción. Permite comprobaciones automatizadas para la validación técnica objetiva. Versión 1.0; la propia línea de la página indica como última revisión el 24 de octubre de 2025.

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.

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.

49.009 respuestas de 177 países, recogidas del 29 de mayo al 23 de junio de 2025, y autoseleccionadas: los participantes fueron captados por los canales propios de Stack Overflow, así que esto mide a quienes responden a Stack Overflow, no una muestra aleatoria de desarrolladores. Se registra frente a la revisión del código escrito por la máquina y no frente a escribir código, porque lo que mide es el motor del volumen y la respuesta de verificación, no quién escribe qué. Ambas mitades pertenecen aquí: el 84 % usa o piensa usar herramientas de IA (76 % un año antes) y el 51 % de los desarrolladores profesionales las usa a diario, mientras el sentimiento favorable cayó de más del 70 % en 2023 y 2024 al 60 %, más desarrolladores desconfían activamente de la exactitud de las herramientas de IA (46 %) que confían en ella (33 %), y los más experimentados muestran la tasa más baja de confianza alta, 2,6 %, frente a la más alta de desconfianza alta, 20 %. El interés en juego corta en ambos sentidos, y eso es lo bastante inusual como para decirlo: lo que los asistentes de código desplazan es el propio tráfico de Stack Overflow, de modo que el dato de adopción va contra su interés comercial mientras que la caída de confianza va a su favor. La encuesta no dice para qué se usaron las herramientas, si alguna revisión tardó más, ni qué cambió en el código que salió a producción.

Una herramienta se usa a gran escala en trabajo real y eso está medido, y quien decidió usarla fue la persona que trabaja, no quien emplea. Es más que un registro de capacidad —el trabajo es real, no una demostración— y menos que uno de despliegue, porque ningún empleador la puso en producción, ni la exigió, ni construyó un proceso alrededor. Ponderada como `cautious`: `automating` significa que la máquina puede hacer la tarea Y que hay indicios de adopción, y esto es un indicio de adopción; pero el uso puede ser una prueba, y buena parte de la medición viene de una parte con intereses, así que un registro nunca basta y dos independientes sí. Fíjate además en quién cuenta. La telemetría de un proveedor ve esto directamente y a la vez vende la herramienta, así que un registro de este tipo declara ese interés en su ámbito de aplicación; una agencia estadística que pregunta a las empresas si su personal usa IA en tareas ve el mismo canal sin ningún interés propio, y donde exista es la mejor fuente.

Un componente de un organismo (ICE) dentro de un gobierno, y declarado por ese organismo en cumplimiento de una obligación legal en vez de elegido para publicarse — que es justo lo que hace que valga la pena leer las entradas aburridas de este inventario. Entrada DHS-2758 del CSV de declaración individual. Lo que establece es la puesta en producción y las condiciones que la acompañan, no cuánto se usan las herramientas: el inventario no trae ninguna cifra de uso, ninguna plantilla y ninguna afirmación de productividad más allá de que el organismo dice que las herramientas «aumentan la productividad de los desarrolladores». Las dos cláusulas que sostienen las dos tareas enlazadas son frases separadas en palabras del propio organismo: las salidas «deben revisarse y aprobarse antes de incorporarse al código a través de los procesos existentes de control de versiones y despliegue» (la tarea de revisar), y «las herramientas no modifican directamente los sistemas de producción; todos los cambios deben pasar por los flujos estándar de revisión humana, pruebas y aprobación» (la tarea de fijar qué puede hacer un agente sin supervisión). La herramienta nombrada es una compra a un proveedor, lo cual conviene saber, aunque quien declara aquí es el organismo y no el proveedor. El mismo inventario trae una señal en sentido contrario del mismo departamento: la entrada DHS-373, «IA generativa comercial para generación de código», tiene como fase de desarrollo «Retirada». Esa fila no lleva fecha ni motivo, así que solo establece que el DHS llegó a listar ese uso y ya no lo mantiene.

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.

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.

Quedarte y reforzarte

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.

Rehacer el puesto

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.

Movimiento lateral

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.

Cambio de sector

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.

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. Una profesión que deja de formar perfiles sénior tiene un problema de suministro más adelante, no una garantía de seguridad ahora: si llegan menos personas a la base, la enseñanza que antes se repartía en un equipo recae en menos personas. Algunas comunidades de ingeniería ya protegen ese camino a propósito: LLVM prohíbe las herramientas de IA en las incidencias etiquetadas como good first issue para que quienes contribuyen por primera vez puedan aprender con ellas.

Todavía nadie puede responder a eso con evidencia, y decirlo es más útil que adivinar. Esos tres tienen exposiciones realmente distintas, pero los estudios que existen se diseñaron para comparar niveles de experiencia, no pilas tecnológicas, así que no hay nada con lo que separarlos. Toma cualquier clasificación segura de frontend frente a backend como la impresión de alguien. Lo que la evidencia sí respalda es otro criterio: elegir según lo caro que salga equivocarse en tu ámbito, y eso atraviesa los tres por igual.

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.