Saltar al contenido principal
onext technology
IA 23 octubre 2026 - 7 min de lectura

Los agentes de código no se adoptan por decreto, se contagian: lo que dice el despliegue de Microsoft para tu equipo de desarrollo

Si el uso de los agentes de código se extiende entre compañeros, lo que se contagia es la forma de usarlos. Sin un método común, también los malos hábitos. Por eso conviene empezar por un equipo concreto que trabaje a la vista.

Bernat López
Fundador y CEO de onext
Dos desarrolladores de espaldas ante un portátil con código en una oficina con luz azul: uno sentado, el otro inclinado señalándole la pantalla, como ocurre cuando un compañero enseña a otro a usar un agente de código

Una empresa compra licencias de agentes de código para todo el equipo de ingeniería y espera que el uso se extienda por sí solo. A veces es lo que pasa. La pregunta que casi nadie se hace es qué se extiende exactamente.

La tesis de esta pieza: si el uso de los agentes de código viaja entre compañeros, con él viaja la forma de usarlos de cada uno. Sin un método común, también se contagian los malos hábitos. Por eso conviene empezar por un equipo concreto que trabaje a la vista, con especificaciones y criterios compartidos, y no por licencias para todos. Del estudio es que el primer uso se extendió sobre todo entre compañeros; que con él viaje la forma de usarlo, y lo demás, es una conclusión de onext.

Qué encontró Microsoft en su despliegue

Emerson Murphy-Hill, Jenna Butler y Alexandra Savelieva publicaron en julio de 2026 un estudio sobre el despliegue de dos agentes de línea de comandos, Claude Code y GitHub Copilot CLI, entre decenas de miles de ingenieros de Microsoft en la primera mitad de 2026. Se puede leer en arXiv.

Encuentran dos cosas que importan aquí. La primera: «el primer uso se extendió principalmente por las redes sociales». La segunda: quienes adoptaron los agentes fusionaron aproximadamente un 24 % más de pull requests de las que habrían fusionado sin ellos, y el efecto se mantuvo durante los cuatro meses que cubre el estudio. De ahí sacan una recomendación: las organizaciones deberían tratar el uso visible entre compañeros como parte central de la estrategia de despliegue.

Límite Es un único estudio, publicado como preprint en arXiv, sin que conste revisión por pares, sobre una sola empresa. Mide las pull requests fusionadas como indicador de producción, y los propios autores advierten de que una pull request fusionada no equivale al valor que entrega. Por eso el 24 % no se presenta aquí como una ganancia de productividad.

Lo que ya se sabía de cómo se descubren las herramientas

El hallazgo encaja con un trabajo anterior del primer autor. En 2015, Murphy-Hill y otros estudiaron cómo descubren herramientas nuevas quienes desarrollan software: entrevistaron a 18 programadores de la industria y siguieron con un diario a 76 usuarios en sus puestos de trabajo (Computer Supported Cooperative Work, 24(5)). Concluyeron que aprender una herramienta de un compañero funciona cuando ocurre, pero ocurre poco, aproximadamente una vez cada pocos meses, y que mejoraría si la gente hablara de sus herramientas de forma más abierta y concisa.

Las dos piezas dicen lo mismo desde ángulos distintos: el boca a boca entre compañeros es un canal real de adopción, pero depende de que el uso se vea y se explique.

Lo que viaja con la herramienta

Aquí termina lo que dicen los estudios y empieza lo que pensamos en onext. Un compañero que enseña cómo usa un agente no enseña solo el comando: enseña cómo pide los cambios, cómo comprueba el resultado, cuánto revisa y cuándo se fía. Eso es lo que otros copian. Si cada persona trabaja a su manera, lo que circula es un conjunto de maneras, con sus aciertos y con sus atajos.

Clave

Cuando el uso se extiende por contagio, la herramienta es lo de menos. Lo que se contagia es el método de quien da el ejemplo, sea bueno o no.

La diferencia entre las dos maneras de empezar, en una tabla:

Pregunta Licencias para todos Un equipo concreto, a la vista
Qué se contagia La manera de trabajar de cada persona Una manera de trabajar acordada y escrita
Qué ven los demás equipos Resultados sueltos y difíciles de comparar Un ejemplo que se puede leer y copiar
Cómo se corrige un mal hábito Persona a persona, cuando se descubre En el método del equipo, para todos a la vez
Qué se puede medir Uso de la herramienta Entrega y calidad de un equipo concreto

Lectura propia de onext a partir del estudio de Microsoft (2026) y de la capacidad de DORA sobre una postura clara de IA (2025)

Por dónde empezar

No hace falta frenar a nadie que ya use agentes por su cuenta. Se trata de que el ejemplo que se vea sea el que quieres que se copie:

  1. Elige un equipo. Uno con trabajo real ya planificado y con alguien que quiera enseñar cómo trabaja.
  2. Deja por escrito cómo trabaja. Cómo se especifica un cambio, qué criterios de aceptación lo cierran y qué contexto del código recibe el agente. En el desarrollo guiado por especificaciones (Spec-Driven Development, SDD), primero se escribe qué tiene que cumplir el código y después se construye; está explicado en qué es SDD y cómo mantiene el código controlado. El contexto compartido, en Claude Code en equipos: el contexto, no el control y en instrucciones compartidas y curadas. Una base de partida, en las plantillas de SDD gratis.
  3. Hazlo visible. Que el resto de ingeniería pueda ver las especificaciones, las revisiones y las decisiones, no solo el resultado. Es el mecanismo que describe el estudio, pero con un método detrás.
  4. Mide entrega y calidad, no uso. Cuánto tarda un cambio en llegar a producción, cuántos fallan después y cuánto retrabajo hay. Qué medir está en los KPI de un equipo de desarrollo con IA, y por qué pedir antes una tesis de valor, en la tesis de valor de la IA para el presupuesto de TI.

Hay una condición previa que DORA, el programa de investigación de Google Cloud sobre entrega de software, pone como una de las siete capacidades de su modelo para la IA: que la posición de la organización sobre las herramientas de IA sea clara y esté bien comunicada. Incluye qué se espera, qué se puede probar y qué herramientas se permiten. DORA aclara que no mide el contenido de la política, solo que se entienda (Storer y DeBellis, 2025). Sin eso, el contagio ocurre igual, pero sin una norma que lo oriente.

Y antes de repartir el acceso, conviene tener la red que detecta los errores: antes del agente, la red.

Antes de repartir licencias

Si estás desplegando agentes de código y quieres decidir con alguien de fuera qué equipo va primero, qué tiene que dejar escrito y cómo se va a ver si funciona, hablemos. La conversación empieza por un equipo concreto, no por el número de licencias.

Preguntas frecuentes

¿Cómo se extiende el uso de los agentes de código dentro de un equipo?

Según el estudio del despliegue de Microsoft en 2026, el primer uso se extendió sobre todo por las redes sociales, y los autores recomiendan tratar el uso visible entre compañeros como parte central de la estrategia de despliegue. Es un único estudio, sobre una empresa concreta.

¿Qué mide el estudio de Microsoft y qué no?

Mide quién adopta y mantiene el uso de dos agentes de línea de comandos (Claude Code y GitHub Copilot CLI) a principios de 2026, y si aumenta su producción. Usa las pull requests fusionadas como indicador de producción y, como señalan los autores, eso no equivale al valor entregado. Es un preprint de arXiv, sin que conste revisión por pares.

¿Significa el 24 % que los equipos son un 24 % más productivos?

No. El estudio dice que quienes adoptaron los agentes fusionaron aproximadamente un 24 % más de pull requests de las que habrían fusionado sin ellos, con el efecto sostenido durante cuatro meses. Una pull request fusionada no equivale a valor entregado, y los propios autores lo señalan.

¿Por qué empezar por un equipo y no dar licencias a todos?

Es una conclusión de onext, no del estudio. Si el uso se contagia entre compañeros, con él se contagia la forma de usarlo. Un equipo que trabaja con especificaciones y criterios compartidos, y que lo hace a la vista, es el ejemplo que conviene que se copie. Con licencias para todos, el ejemplo es el de cada cual.

¿Qué tiene que tener escrito el equipo que va primero?

Cómo se especifica un cambio, cuáles son los criterios de aceptación, qué contexto del código se le da al agente y quién decide dónde hay riesgo. No hace falta un manual largo: hace falta que otro equipo pueda leerlo y copiarlo.

¿Qué es una postura clara sobre IA según DORA?

Es una de las siete capacidades del modelo de DORA para la IA: que la posición de la organización sobre las herramientas de IA sea clara y esté bien comunicada (qué se espera, qué se puede probar y qué herramientas se permiten). DORA aclara que no mide el contenido de la política, solo que sea clara y se conozca.

Fuentes

Bernat López
Escrito por
Bernat López
Fundador y CEO de onext

Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.

LinkedIn →

¿Qué equipo va primero?

Hablamos del equipo antes que de las licencias.

Ver cómo trabajamos

Lo que construimos se queda en tu equipo.