💻 computer science

To Copilot and Beyond: 22 AI Systems Developers Want Built

Este artículo presenta los resultados de una encuesta a 860 desarrolladores de Microsoft que identificaron 22 sistemas de IA deseados, revelando la necesidad de herramientas que asuman tareas de ensamblaje mientras respetan la identidad profesional mediante un concepto de "delegación acotada" que prioriza la calidad, la procedencia y los límites de autoridad.

Autores originales: Rudrajit Choudhuri, Christian Bird, Carmen Badea, Anita Sarma

Publicado 2026-04-10

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Rudrajit Choudhuri, Christian Bird, Carmen Badea, Anita Sarma

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que eres un chef en una cocina muy ocupada. Durante años, la gente pensaba que tu trabajo consistía principalmente en cortar verduras y mezclar ingredientes (escribir código). Por eso, la tecnología de Inteligencia Artificial (IA) se centró en crear robots que hicieran exactamente eso: cortar y mezclar súper rápido.

Pero, según este estudio, hay un problema: cortar verduras solo ocupa el 10% de tu día. El resto del tiempo (el 90%) lo pasas limpiando la cocina, organizando los pedidos, explicando el menú a los clientes, asegurándote de que la comida no esté envenenada y gestionando las quejas.

Los investigadores (de la Universidad Estatal de Oregón y Microsoft) preguntaron a 860 "chefs" (desarrolladores de software) qué querían que hiciera la IA. La respuesta fue sorprendente: no quieren que la IA cocine por ellos; quieren que la IA haga el trabajo sucio alrededor de la cocina.

Aquí tienes los hallazgos clave explicados de forma sencilla:

1. El Problema: "Más comida, menos control"

La IA actual es muy buena escribiendo código rápido. Es como un robot que corta verduras a la velocidad de la luz. Pero esto ha creado un caos:

Hay demasiada comida (código) que nadie entiende bien.
Los revisores (los inspectores de calidad) están agotados porque tienen que revisar montañas de platos que el robot preparó, sin saber si están seguros.
La documentación (las recetas) se queda obsoleta porque el robot cambia los ingredientes más rápido de lo que alguien puede anotarlos.

2. La Solución: 22 "Ayudantes" Específicos

En lugar de un robot que "hace todo", los desarrolladores quieren 22 herramientas específicas que actúen como asistentes de confianza. Aquí están las más importantes, con analogías:

El "Arquitecto de Planes" (No el Decisor): Imagina que tienes que organizar una fiesta. Quieres que la IA te diga: "Oye, si invitas a 50 personas, necesitarás 3 mesas y 2 baños". Pero tú decides si invitas a 50 o a 100. La IA no debe tomar la decisión final, solo preparar las opciones.
El "Detective de Errores" (No el Juez): Cuando algo sale mal en el sistema, la IA debe reunir todas las pistas (registros, errores, cambios recientes) y decirte: "Aquí tienes la evidencia, parece que el problema fue este cambio". Pero tú eres quien decide si el culpable es ese cambio o no. La IA no puede "arrestar" al código sin tu permiso.
El "Traductor de Requisitos" (No el Mentiroso): Si un cliente pide algo confuso, la IA puede ayudar a redactar el correo para que se entienda, pero nunca debe inventar detalles que no existen. Si falta información, debe decir: "No sé esto, pregúntale al cliente", en lugar de alucinar una respuesta falsa.
El "Guardián de Seguridad" (No el Hacker): La IA puede revisar si hay puertas abiertas en el sistema, pero nunca debe tener permiso para cerrarlas o cambiarlas por sí sola. Debe avisarte y esperar a que tú le des el visto bueno.

3. La Regla de Oro: "Delegación Limitada"

Los investigadores llamaron a esto "Delegación Limitada".
Es como tener un perro muy inteligente en casa.

Lo que quieres que haga: Que busque la pelota, que vigile la puerta, que traiga el periódico. (El trabajo de ensamblaje, la logística, la búsqueda de información).
Lo que NUNCA quieres que haga: Que decida qué ropa usar, que firme los cheques del banco o que cuide a los niños. (El juicio profesional, la responsabilidad final, la creatividad profunda).

Los desarrolladores sienten que su "identidad profesional" está en tomar las decisiones difíciles. Si la IA hace todo el trabajo creativo y de juicio, ellos se sienten como si ya no fueran necesarios. Quieren que la IA sea el ayudante, no el jefe.

4. Las 4 Reglas de Seguridad (Los "Guardarraíles")

Para que los desarrolladores confíen en estas herramientas, la IA debe cumplir cuatro reglas estrictas:

Saber sus límites: Si la IA no está segura, debe decir "No sé" y detenerse, no inventar una respuesta.
Mostrar sus fuentes: Si dice algo, debe poder decirte "Lo leí en este documento" o "Lo vi en este código". Nada de magia negra.
No tener llaves maestras: La IA no debe tener permiso para borrar cosas o cambiar configuraciones críticas sin que un humano lo apruebe primero.
Proteger la privacidad: No debe tocar datos sensibles de clientes sin permiso.

En Resumen

El mensaje del estudio es claro: La IA no debe ser un reemplazo, sino un amplificador.

Los desarrolladores quieren usar la IA para eliminar el trabajo aburrido y repetitivo (como limpiar la cocina o organizar los ingredientes), para que ellos puedan concentrarse en lo que realmente importa: crear, decidir y asegurar la calidad.

Si la IA intenta hacer el trabajo de "chef" (tomar decisiones creativas y de responsabilidad), los desarrolladores la rechazarán. Pero si la IA se queda en su papel de "ayudante de cocina" (hacer el trabajo pesado y preparar el terreno), entonces será una herramienta increíblemente valiosa.

La lección final: El valor de la IA no está en cuánto trabajo puede hacer, sino en dónde decide detenerse para dejar que el humano tome el control.

Resumen Técnico: Hacia Copilot y Más Allá: 22 Sistemas de IA que los Desarrolladores Quieren Construir

1. El Problema: El Desequilibrio en el Ciclo de Vida del Desarrollo

El artículo identifica una desconexión crítica en la actual herramienta de IA para ingeniería de software. Mientras que la mayoría de la inversión en IA se centra en la generación de código (que representa solo aproximadamente el 10% del tiempo laboral de un desarrollador), el resto de la jornada se dedica a tareas de verificación, depuración, cumplimiento normativo, revisión y gestión de incidentes.

Esta asimetría está creando un "problema de desplazamiento a la derecha" (right-shift problem):

La generación de código asistida por IA acelera la producción, pero expande la carga de trabajo en las etapas lentas y complejas de verificación y mantenimiento.
Los desarrolladores se enfrentan a un volumen creciente de código con procedencia limitada, lo que genera fatiga, agotamiento (burnout) y una acumulación de "deuda técnica inducida por IA".
Existe una necesidad urgente de herramientas que no solo generen código, sino que integren señales de calidad y verificación más temprano en el flujo de trabajo, antes de que el código llegue a producción.

2. Metodología

El estudio se basa en un análisis cualitativo riguroso de los datos obtenidos de una encuesta a gran escala realizada a 860 desarrolladores de Microsoft.

Fuente de Datos: Encuesta aprobada por el IRB (julio de 2025) que capturó las evaluaciones cognitivas de los desarrolladores sobre su trabajo diario y sus prioridades de IA Responsable (RAI).
Análisis de Respuestas Abiertas: Se analizaron las respuestas a dos preguntas clave por categoría de tarea:
1. Oportunidad: ¿Dónde quieres que la IA juegue el papel más grande?
2. Restricción: ¿Qué aspectos no quieres que la IA maneje y por qué?
Pipeline de Análisis "Human-in-the-Loop" (HITL):
- Se utilizó un enfoque de council basado en múltiples modelos (Human-in-the-loop, multi-model council-based thematic analysis).
- Descubrimiento Independiente: Tres modelos de IA de vanguardia (GPT-5.2, Gemini 3.1 Pro, Claude Opus 4.6) de proveedores distintos analizaron las respuestas por separado para identificar temas, reduciendo los sesgos específicos de cada modelo.
- Reconciliación y Validación Humana: Los temas propuestos por las máquinas fueron reconciliados y luego revisados exhaustivamente por dos investigadores humanos. Se validó la fidelidad, el anclaje en los datos y la distinción entre temas.
- Codificación Sistemática: Los tres modelos codificaron las respuestas contra un código aprobado, proporcionando una justificación (cadena de pensamiento) antes de asignar etiquetas.
- Fiabilidad: Se calculó la fiabilidad inter-evaluador (Krippendorff's $\alpha$ ), obteniendo un promedio de 0.94, lo que indica una alta consistencia.

3. Contribuciones Clave

El principal aporte del trabajo es la identificación y descripción de 22 sistemas de IA específicos que los desarrolladores desean ver construidos. Estos sistemas se organizan en cinco categorías de tareas de desarrollo de software:

Desarrollo (Development): Enfocados en la gestión de deuda técnica y el contexto del repositorio.
Diseño y Planificación (Design & Planning): Enfocados en la traducción de requisitos a tareas y la exploración de alternativas arquitectónicas.
Gestión de Calidad y Riesgo (Quality & Risk): Enfocados en pruebas, revisiones de código y seguridad.
Infraestructura y Operaciones (Infrastructure & Ops): Enfocados en la triaje de alertas, configuración de CI/CD y mantenimiento.
Meta-trabajo (Meta-Work): Enfocados en documentación, incorporación de nuevos empleados y comunicación con partes interesadas.

Para cada uno de los 22 sistemas, el artículo detalla:

El problema específico que resuelve.
Las dificultades técnicas para construirlo (ej. comprensión del contexto, calibración de confianza).
Las restricciones y guardarraíles que los desarrolladores exigen.

4. Resultados Principales y Hallazgos

A. Los 22 Sistemas Solicitados (Ejemplos Destacados)

Los desarrolladores no piden "más código", sino herramientas de asistencia y verificación:

Generador de PRs delimitado para deuda técnica: Que realice refactorizaciones pequeñas y seguras, deteniéndose ante lógica de negocio compleja.
Puerta de calidad incrustada: Detección de errores y pruebas en tiempo real durante la escritura del código, no después.
Banco de trabajo de causa raíz (Trace-to-diff): Que assemble logs y trazas para incidentes en producción, sugiriendo hipótesis con niveles de confianza explícitos.
Gráfico de contexto del repositorio: Para entender cómo un cambio afecta a todo el sistema, no solo al archivo local.
Asistente de revisión de PRs consciente del contexto: Que identifique riesgos específicos del repositorio, no solo comentarios genéricos.
Compilador de evidencia de cumplimiento: Que traduzca políticas de seguridad en pasos accionables y recopile evidencia sin manejar datos sensibles.
Entrenador de incorporación contextualizado: Que cree rutas de aprendizaje personalizadas basadas en el repositorio real, sin reemplazar la mentoría humana.

B. El Patrón de "Delegación Acotada" (Bounded Delegation)

El hallazgo conceptual más importante es el concepto de "Delegación Acotada".

Los desarrolladores quieren que la IA absorba el trabajo de ensamblaje (logística, búsqueda de información, generación de borradores, mantenimiento de documentación).
Sin embargo, rechazan firmemente que la IA asuma el trabajo de oficio (craft): la toma de decisiones finales, la responsabilidad profesional, la arquitectura crítica y la comunicación sensible.
Esta frontera no se basa en la incapacidad actual de la IA, sino en la identidad profesional y la necesidad de mantener la agencia y la responsabilidad.

C. Cuatro Guardarraíles Transversales

Para que cualquier sistema sea aceptable, los desarrolladores exigen cuatro condiciones estrictas:

Delimitación explícita de la autoridad: El sistema debe operar dentro de límites declarados y detenerse cuando se requiere juicio humano.
Procedencia (Provenance): Todas las salidas deben poder rastrearse a sus fuentes originales.
Señalización de incertidumbre: El sistema debe comunicar explícitamente cuándo falta evidencia o cuando su confianza es baja, en lugar de alucinar con seguridad.
Acceso de privilegio mínimo: Restricción estricta sobre el manejo de datos sensibles y la capacidad de escribir en producción sin supervisión humana.

5. Significado e Implicaciones

Para la Práctica (Diseño de Herramientas)

Cambio de enfoque: El valor de la IA no debe medirse por cuánto código puede escribir, sino por dónde y cómo se detiene. Las herramientas deben diseñarse para proteger la agencia humana.
Desplazamiento a la izquierda (Left-shifting): La verificación de calidad debe integrarse en el momento de la autoría (antes del commit), no después. Esto es crucial para contrarrestar la sobrecarga de revisión generada por la IA.
Diseño de sistemas: Los futuros sistemas de IA para ingeniería de software deben priorizar la transparencia, la trazabilidad y la capacidad de intervención humana sobre la autonomía total.

Para la Investigación

Metodología: El estudio demuestra la viabilidad de utilizar modelos de IA generativa en pipelines de análisis cualitativo a gran escala, siempre que se mantenga la autoridad interpretativa humana y se utilice la diversidad de modelos como mecanismo de validación convergente.
Nuevas direcciones: Abre la puerta a investigar cómo calibrar estas restricciones (guardarraíles) para diferentes contextos y niveles de criticidad, evitando tanto la falta de control como la sobrecarga burocrática que lleva a los usuarios a ignorar las herramientas.

Conclusión

El artículo concluye que la próxima generación de herramientas de IA para ingeniería de software no debe centrarse en reemplazar al desarrollador, sino en aumentar sus capacidades asumiendo la carga logística y de ensamblaje, mientras se preserva estrictamente la responsabilidad humana sobre el juicio, la arquitectura y la calidad. La frontera entre lo que la IA hace y lo que el humano hace es un requisito de diseño fundamental, no una limitación temporal.