Desarrollo de Microsoft Copilot Cowork: nueve ingenieros, 1.211 solicitudes de extracción y el cuello de botella de la verificación
Microsoft afirma que nueve ingenieros fusionaron 1.211 solicitudes de extracción durante el desarrollo de Copilot Cowork el 21 de octubre, con agentes escribiendo la mayor parte del código. Una solicitud de extracción propone cambios para su revisión antes de la integración. Esta distinción importa: el titular mide los cambios fusionados, mientras que la productividad también depende de su utilidad, fiabilidad y carga de mantenimiento.
Publicado el 2 de noviembre, el relato de ingeniería describe a un equipo que está cambiando la forma en que especifica, revisa y opera el software. Su tensión central enfrenta la expansión de la capacidad de implementación con una capacidad de verificación limitada. Generar más cambios solo crea valor cuando la organización puede determinar cuáles merecen llegar a los usuarios.
La investigación sobre agentes de Anthropic y la investigación de Google sobre entrega de software ofrecen puntos de referencia útiles, sin validar de forma independiente los resultados de Microsoft. Ambas dirigen la atención hacia los sistemas que rodean a las herramientas de IA. Para los líderes de ingeniería, la presión recae en las prácticas de revisión, la arquitectura y la responsabilidad a medida que la producción de código se vuelve más fácil de ampliar.
Qué mide realmente el hito del desarrollo de Copilot Cowork
Según el relato de ingeniería de Copilot Cowork de Microsoft, el equipo de backend alcanzó ese total diario tras comenzar a trabajar en enero. Los ingenieros conservaron la responsabilidad de los requisitos y las decisiones de mayor riesgo. Las comprobaciones automatizadas y los revisores agentes examinaron los cambios. Microsoft también describe un cambio sensible en el que los revisores humanos detectaron cuatro problemas bloqueantes que los revisores agentes no detectaron.
Una solicitud de extracción fusionada registra actividad aceptada; su valor empresarial aún requiere evidencia independiente.
Una organización puede dividir una funcionalidad en muchos cambios o combinar trabajo relacionado en una entrega más grande. Ambos enfoques alteran el recuento. Ninguno establece cuánto valor para el cliente aportó el trabajo. Por lo tanto, comparar equipos solo mediante totales corre el riesgo de premiar diferencias de empaquetado en lugar de diferencias de rendimiento de ingeniería.
Los cambios más pequeños pueden facilitar la revisión porque cada propuesta plantea una cuestión más acotada. Sin embargo, un conjunto de cambios comprensibles de forma individual aún puede producir un efecto combinado inesperado. La unidad pertinente de evaluación pasa a ser a veces la versión, el flujo de trabajo del cliente o el servicio a lo largo del tiempo.
Pensemos en un asistente hipotético de programación de reuniones que lee una solicitud, verifica la disponibilidad y prepara una invitación. Cada componente puede superar sus propias pruebas mientras que el flujo de trabajo completo gestiona incorrectamente una cancelación. Contar los cambios exitosos de los componentes no captaría el problema real del cliente.
Ese ejemplo ilustra por qué el hito merece atención sin convertirse en un objetivo universal. El recuento sugiere un proceso de integración inusualmente activo. No revela una medida estandarizada de complejidad de funcionalidades, beneficio para el cliente ni esfuerzo necesario para mantener el sistema resultante.
El momento también importa. Este relato describe un modelo operativo que surge a través de un desarrollo sostenido, en lugar de una demostración breve de código generado. Los lectores deberían evaluar sus afirmaciones como un estudio de caso de producción de una empresa, con todo el contexto y las limitaciones de selección que conlleva ese formato.
En consecuencia, la ingeniería de Copilot Cowork plantea una pregunta de gestión que va más allá de la velocidad de programación: ¿qué evidencia debería justificar la aceptación de un cambio? Las distintas respuestas implican diferentes necesidades de personal. Un equipo que enfatiza los resultados de pruebas locales se organizará de forma distinta a otro que exige revisión de seguridad, evidencia operativa y comprobaciones de resultados para el cliente.
El total diario no puede responder esa pregunta para otra organización. Sí hace más difícil posponerla. Una vez que la implementación se expande, unos criterios de aceptación débiles se convierten en una restricción operativa, en lugar de una molestia ocasional.
Para los compradores, la distinción es igualmente práctica. El ritmo de desarrollo de un proveedor describe su capacidad para cambiar el producto. Un comprador aún necesita evidencia de que esos cambios mejoran los flujos de trabajo de los que dependen los empleados.
Los líderes de ingeniería se enfrentan a un problema de capacidad de verificación
Cuando se expande la capacidad de implementación, el recurso escaso pasa a ser la confianza justificada en lo que se lanza.
La confianza tiene varias fuentes: un requisito preciso, pruebas significativas, una revisión informada y evidencia del servicio en ejecución. Estas fuentes responden a preguntas distintas. Una prueba puede establecer el comportamiento esperado para determinadas entradas sin demostrar que el propio requisito sirva al cliente.
La investigación de Google sobre desarrollo de software asistido por IA ofrece una comparación más amplia. Sus hallazgos DORA de 2025 asocian la adopción de IA con un mayor rendimiento de entrega, al tiempo que enfatizan la organización circundante. La investigación describe la IA como un amplificador de las fortalezas y debilidades existentes.
Esa perspectiva respalda una interpretación cautelosa del hito de Microsoft. Un equipo con una propiedad clara y controles de lanzamiento fiables tiene dónde dirigir la capacidad adicional de implementación. En cambio, un equipo con responsabilidades sin resolver puede acumular más propuestas que nadie puede aprobar con confianza.
Por tanto, la presión recae primero en los responsables de ingeniería y los equipos de plataforma. Ellos determinan quién es propietario de los criterios de aceptación, qué cambios requieren atención especializada y cómo puede revertirse una versión. Esas decisiones se vuelven más importantes cuando las propuestas llegan más rápido.
Los especialistas en seguridad afrontan un problema relacionado de asignación. Revisar cada cambio con la misma intensidad consume atención independientemente del riesgo. Revisar solo archivos de seguridad evidentes pasa por alto comportamientos introducidos en otros lugares. La tarea difícil consiste en conectar los cambios con los permisos, los datos y las acciones de clientes a los que afectan.
Los responsables de producto también heredan más responsabilidad. Las solicitudes ambiguas se vuelven costosas cuando el software puede producirse antes de que afloren los desacuerdos. Una implementación pulida puede generar impulso en torno a un requisito mal entendido, haciendo que la corrección sea políticamente más difícil incluso cuando modificar el código sigue siendo técnicamente sencillo.
Aquí es donde las organizaciones deberían distinguir la espera de la deliberación necesaria. Parte de la demora refleja información ausente o un revisor sobrecargado. Otra demora protege una decisión irreversible. Tratar ambas como desperdicio anima a los equipos a eliminar salvaguardas simplemente porque ralentizan un panel.
Una respuesta de gestión útil consiste en examinar dónde entra la incertidumbre en el proceso. Si los revisores preguntan repetidamente qué debería hacer una funcionalidad, el requisito necesita trabajo. Si cuestionan repetidamente los efectos del despliegue, el proceso de lanzamiento necesita una mejor visibilidad.
Estos son diagnósticos organizativos, no argumentos a favor de procesos ilimitados. Cada control adicional tiene un coste. El criterio debería ser si responde a una pregunta relevante que otro control deja sin resolver.
La historia del desarrollo de Copilot Cowork expone esa disyuntiva de una forma inusualmente visible. Los líderes de ingeniería ahora deben explicar cómo ampliarán la capacidad de verificación junto con la capacidad de implementación. Comprar acceso a un agente de programación no resuelve esa decisión operativa.
Para los compradores empresariales, la pregunta correspondiente se refiere a la calidad del cambio. Los lanzamientos más rápidos se vuelven útiles cuando los empleados experimentan menos interrupciones, permisos más claros y una finalización de tareas más fiable. La frecuencia de lanzamiento por sí sola deja esos resultados sin resolver.
La migración a Rust de Copilot Cowork separa el lenguaje de la arquitectura
Microsoft informa de que la migración a Rust de Copilot Cowork redujo el tiempo de respuesta mediano del primer turno de 7,9 segundos a 2,7 segundos en una ventana de comparación. También atribuye parte de la mejora al traslado del bucle del agente, y no hace ninguna afirmación sobre el coste por turno.
Una migración puede mejorar un servicio sin demostrar que el lenguaje de programación causó cada mejora.
Un entorno de ejecución es la maquinaria de software que ejecuta el trabajo de una aplicación. Trasladar esa maquinaria entre lenguajes puede cambiar la gestión de memoria, la planificación, el despliegue y el comportamiento de inicio. Si varios elementos cambian a la vez, la medición resultante captura su efecto combinado.
La distinción importa porque los debates sobre lenguajes de programación suelen reducir un proyecto arquitectónico a una simple competición. Ese encuadre ofrece un titular claro, pero proporciona una base deficiente para la decisión de inversión de otro equipo. La pregunta pertinente se refiere a qué mecanismo aborda su propio cuello de botella.
Las garantías de concurrencia de Rust proporcionan una referencia técnica concreta. La concurrencia significa que partes separadas de un programa pueden progresar de manera independiente. Rust utiliza reglas de propiedad y comprobación de tipos para detectar muchos errores de memoria y concurrencia antes de la ejecución.
Esas garantías tienen límites. No demuestran que una respuesta contenga la información empresarial correcta, que una operación tenga permiso o que los usuarios reciban eventos en la secuencia esperada. La seguridad del lenguaje y la corrección de la aplicación solo se solapan parcialmente.
Un servicio de programación de reuniones ilustra la diferencia. Su código puede gestionar la memoria de forma segura y, aun así, seleccionar el calendario equivocado. Sus tareas pueden ejecutarse sin una condición de carrera de datos y, aun así, enviar una invitación antes de la aprobación. Una garantía a nivel de lenguaje no puede aportar una regla de producto ausente.
Por lo tanto, la evidencia de una migración necesita varias capas. Una capa se refiere al uso de recursos y al tiempo de respuesta. Otra se refiere al comportamiento bajo tráfico realista. Otra se refiere a si el reemplazo preserva obligaciones que antes eran implícitas.
Una comparación controlada idealmente mantendría estables las condiciones de carga de trabajo e infraestructura, al tiempo que documentaría los cambios sometidos a evaluación. Las migraciones de producción rara vez ofrecen una separación experimental perfecta. Esa limitación debería condicionar la atribución, en lugar de eliminar mediciones operativas útiles.
Para los desarrolladores que leen el relato de la migración a Rust de Copilot Cowork, la implicación práctica es analítica. Determinen si el problema pertinente implica planificación de ejecución, sobrecarga de inicio, comportamiento de memoria o diseño de la aplicación antes de generalizar el resultado.
Para los compradores, el lenguaje en sí suele importar menos que el resultado del servicio. Las respuestas iniciales más rápidas son valiosas, pero no demuestran una finalización más rápida de una tarea completa. Un sistema puede empezar a responder antes y, aun así, tardar más en producir un entregable correcto.
La misma distinción se aplica a la economía. Una mejora de latencia no demuestra automáticamente un menor coste operativo. El uso de infraestructura, las llamadas al modelo, los reintentos y el trabajo de soporte afectan al cálculo.
Eso convierte la migración en un estudio de caso útil sobre atribución. Muestra por qué un resultado de ingeniería debería conservar su contexto arquitectónico cuando se convierte en una afirmación pública de rendimiento.
La revisión por agentes necesita una base independiente para la confianza
Añadir revisores aumenta la confianza solo cuando sus comprobaciones proporcionan evidencia útil y suficientemente independiente.
Un agente de IA es un sistema impulsado por modelos que selecciona acciones y utiliza herramientas para alcanzar un objetivo. Un revisor de agentes puede inspeccionar un cambio propuesto, identificar inquietudes y solicitar correcciones. Su criterio sigue siendo un resultado que debe evaluarse, especialmente cuando el agente autor proporcionó gran parte de la explicación circundante.
Los patrones de flujos de trabajo de agentes de Anthropic describen sistemas que separan la generación de la evaluación. La empresa recomienda diseños simples, criterios de evaluación claros y complejidad adicional solo cuando mejora los resultados. Esto ofrece una comparación útil con el creciente papel de la revisión automatizada.
Un evaluador tiene una tarea más sencilla cuando el éxito puede observarse directamente. Un cálculo numérico puede verificarse mediante una operación independiente. Un flujo de trabajo sensible a permisos requiere otro tipo de evidencia, porque la acción correcta depende de la identidad, las políticas y el contexto.
El peligro central es el malentendido compartido. Un autor y un revisor pueden coincidir porque ambos interpretaron de la misma manera un requisito ambiguo. Su acuerdo no resuelve la ambigüedad. Un modelo o prompt distinto solo ayuda si aporta una diferencia relevante en la evidencia o el razonamiento.
Las pruebas tienen una limitación similar. Una prueba escrita junto con una implementación puede reproducir los supuestos de esta. Superarla demuestra consistencia entre esos artefactos. No necesariamente demuestra consistencia con el comportamiento previsto.
La evidencia independiente puede proceder de un contrato existente, un comportamiento observado, un requisito aprobado o un caso de fallo cuidadosamente seleccionado. La fuente adecuada depende del cambio. La distinción importante es si la evidencia puede contradecir la implementación.
Consideremos una comprobación automatizada que informa éxito pese a no recibir entradas relevantes. Su resultado se parece a una inspección satisfactoria, pero no contiene información sobre el cambio propuesto. Un símbolo visible de aprobación se vuelve engañoso cuando los usuarios no pueden saber qué examinó realmente la comprobación.
Por eso, la calidad de la revisión no puede reducirse al número de agentes asignados. Un conjunto pequeño de comprobaciones con propósitos distintos puede aportar más confianza que revisiones amplias y repetidas. El objetivo es cubrir los modos de fallo importantes sin crear un flujo ilegible de comentarios.
La participación humana también necesita una función específica. Pedir a alguien que apruebe un cambio sin tiempo ni contexto genera una supervisión nominal. Una revisión eficaz requiere una decisión clara, evidencia relevante y la autoridad para rechazar la propuesta.
Para el desarrollo con Copilot Cowork, la lección más amplia se refiere a la relación entre automatización y rendición de cuentas. Una retroalimentación automatizada más rápida puede respaldar el juicio humano, pero la organización sigue necesitando una base explícita para aceptar riesgos.
Esa base debe seguir siendo comprensible después de que los autores originales abandonen la conversación. Un registro consultable de requisitos y decisiones ayuda a los futuros revisores a reconstruir la intención. Los equipos que gestionan ese contexto pueden explorar una base de conocimiento consultable sin tratar los documentos almacenados como prueba de que el software se comporta correctamente.
La investigación sobre productividad complica el titular sobre las pull requests
El estudio de caso de Microsoft y la investigación independiente sobre productividad miden cosas diferentes, por lo que sus hallazgos no pueden sustituirse entre sí.
El experimento de productividad de desarrolladores de METR ofrece un útil contrapunto. En su estudio de principios de 2025, 16 desarrolladores experimentados de código abierto completaron 246 tareas. Permitir el uso de IA aumentó el tiempo de finalización en un 19% en ese contexto, pese a que los participantes creían que las herramientas ayudaban.
Ese resultado se refiere a desarrolladores, repositorios, tareas y herramientas concretos. No demuestra que la IA ralentice a todos los equipos de ingeniería. Tampoco puede evaluar directamente un flujo de trabajo posterior organizado en torno a muchos agentes concurrentes.
METR matizó posteriormente el panorama. Su actualización del experimento de productividad de febrero de 2026 describió problemas de selección y dificultades para medir el tiempo cuando los desarrolladores utilizaban agentes de forma concurrente. Los investigadores consideraron que los resultados más recientes no eran fiables para estimar con precisión el efecto actual.
En conjunto, estas fuentes establecen un problema de medición, no un veredicto universal. El tiempo de finalización de tareas, los cambios integrados y la utilidad percibida por los usuarios pueden evolucionar de forma distinta. Una evaluación sólida especifica qué resultado importa antes de interpretar un hallazgo.
Para un desarrollador individual, una herramienta puede reducir el trabajo desagradable sin reducir el tiempo transcurrido. Para una organización, una herramienta puede ampliar el abanico de proyectos viables sin disminuir el esfuerzo de mantenimiento. Estos beneficios merecen consideración, pero necesitan etiquetas precisas.
Un equipo también puede completar más trabajo porque elige tareas más pequeñas. Eso podría mejorar la entrega al reducir la espera y la incertidumbre. También podría inflar las métricas de actividad mientras los principales problemas de los clientes siguen sin resolverse. El recuento por sí solo no puede distinguir entre esas explicaciones.
El contrafactual también importa. Evaluar la productividad exige algún relato de lo que habría ocurrido sin la herramienta o el proceso. Una entrega exitosa demuestra que un equipo publicó algo. No demuestra de forma independiente cuánto de la aceleración es atribuible a la IA.
El relato público de Microsoft ofrece un ejemplo operativo, más que una comparación aleatorizada. Ese formato puede revelar mecanismos y modos de fallo útiles. No puede aislar cada contribución de la experiencia de los desarrolladores, la infraestructura, el apoyo organizativo y la capacidad del modelo.
La misma cautela se aplica a los competidores. La orientación arquitectónica de Anthropic explica un enfoque de diseño, mientras que la investigación de Google describe patrones más amplios. Ninguna de ellas establece qué proveedor ofrece el mejor resultado para una carga de trabajo empresarial concreta.
Para los líderes de ingeniería, la implicación es resistirse a convertir una cifra memorable en una fórmula de plantilla. Las decisiones sobre plantilla requieren evidencia sobre entrega sostenida, calidad, carga de soporte y el trabajo que queda fuera del proceso medido.
La historia también deja abierta una cuestión económica. El coste total del trabajo aceptado incluye generación, evaluación, infraestructura, atención humana y corrección tras el lanzamiento. Una mayor actividad de implementación puede coexistir con una economía mejor o peor.
Por tanto, la ingeniería de Copilot Cowork debe evaluarse como un ejemplo específico de trabajo reorganizado. Su contribución más sólida es impulsar mejores preguntas sobre la evidencia, en lugar de proporcionar una tasa de conversión universal entre ingenieros y agentes.
Tres señales facilitarán juzgar el modelo de desarrollo
La próxima evidencia útil se refiere a resultados sostenidos, verificación repetible y el coste total del trabajo aceptado.
La primera señal es un seguimiento que conecte la actividad de desarrollo con la fiabilidad en producción. En los próximos meses, la divulgación de fallos de lanzamiento, reversiones o problemas recurrentes de clientes ayudaría a los lectores a interpretar el volumen de cambios integrados.
Una mejora de la fiabilidad junto con una entrega sostenida reforzaría el argumento a favor del modelo operativo. Un aumento del trabajo de reparación lo complicaría. Cualquiera de los dos resultados aportaría más valor para la toma de decisiones que otro registro aislado de actividad.
La comparación debe utilizar definiciones coherentes. Un cambio en las prácticas de información puede hacer que un servicio parezca más saludable sin modificar su comportamiento. Los lectores deberían buscar una ventana de medición estable y una explicación clara de qué se considera un fallo.
La segunda señal es evidencia de que las prácticas de verificación se transfieren más allá del equipo original. Una evaluación documentada, una configuración de prueba reproducible o un caso de producción comparable ayudarían a distinguir un enfoque ampliamente útil de un resultado dependiente de condiciones inusuales.
La replicación no exige que otro equipo iguale el total diario. Exige demostrar que una capacidad adicional de implementación produce resultados aceptados sin desbordar la revisión y las operaciones. Es razonable que distintas cargas de trabajo generen distintos niveles de actividad.
Si otros equipos reproducen los beneficios bajo restricciones diferentes, el caso se vuelve más general. Si el éxito depende en gran medida de infraestructura especializada o experiencia concentrada, su aplicabilidad se vuelve más limitada. Aun así, sería información útil para compradores y líderes de ingeniería.
La tercera señal es un relato económico creíble. El coste por tarea de cliente completada con éxito conectaría los cambios de ingeniería con la realidad operativa del producto. También revelaría si los reintentos y el trabajo correctivo absorben las aparentes ganancias de eficiencia.
Una divulgación útil explicaría qué costes entran en el cálculo. Excluir la revisión o la infraestructura respondería a una pregunta más limitada. Incluirlas ayudaría a las organizaciones a comparar el enfoque con su proceso actual.
Estas son prioridades de observación, no compromisos anunciados de información. Microsoft no ha prometido todas las mediciones analizadas aquí. Su ausencia dejaría partes del caso sin resolver, en lugar de demostrar automáticamente un fracaso.
Para los compradores empresariales, la acción inmediata es pedir a los proveedores evidencia vinculada a un flujo de trabajo real. Elijan una tarea que los empleados realicen, definan un resultado aceptable y examinen cómo el sistema gestiona las excepciones. Mantengan la actividad de desarrollo separada del éxito del cliente.
Para los líderes de ingeniería que evalúan el desarrollo con Copilot Cowork, utilicen este hito para afinar las preguntas que sustentan sus propias decisiones de adopción. Identifiquen qué le cuesta verificar a su equipo, dónde se pierde la intención y qué resultados justifican más automatización. Comparen el trabajo aceptado durante un periodo significativo, incluido el esfuerzo necesario para corregirlo. Lean el relato de ingeniería subyacente junto con la investigación sobre productividad, porque responden a preguntas distintas. Después, examinen si su organización puede explicar por qué un cambio merece publicarse. Cuando resulta más fácil ampliar la implementación, esa explicación se convierte en una responsabilidad central de ingeniería. ¿Qué evidencia convencería a su equipo de que más código generado se ha convertido en software más fiable?
