Las cuatro perspectivas de un equipo de desarrollo que trabaja con IA: personas, procesos, herramientas e indicadores

Según el informe DORA de 2025, el papel principal de la IA en un equipo de desarrollo es el de amplificador: magnifica las fortalezas y las debilidades que la organización ya tenía. Y añade que el mayor retorno de la inversión en IA no sale de las herramientas, sino de la atención al sistema organizativo que las rodea.

Si es así, la pregunta útil para un CTO no es qué asistente comprar, sino qué es lo que su equipo está amplificando. Para responderla sirve un marco que los equipos de TI llevan años usando: mirar cuatro perspectivas —personas, procesos, herramientas e indicadores— y buscar cuál frena a las demás.

La tesis de esta pieza es que con IA el marco sigue valiendo, pero las preguntas que lo llenan han cambiado, y que la herramienta, la perspectiva a la que más tiempo se dedica, es la que menos decide el resultado. Una transformación con IA puede fallar sin que el asistente tenga la culpa: a menudo es porque una de las otras tres sigue diagnosticada con las preguntas de antes.

Un marco clásico con preguntas nuevas

En un diagnóstico sin IA se pregunta por las habilidades y los planes de carrera, por la automatización, la frecuencia de despliegue y las definiciones de ready y done, por la experiencia del desarrollador y por lo que se mide. Todas esas preguntas siguen siendo legítimas. Lo que ocurre es que, cuando un agente escribe buena parte del código, cada una se desplaza.

Las cuatro filas tienen una cosa en común: la pregunta nueva ya no mira el código, mira lo que lo rodea. Quién lo pide, cómo se comprueba, qué contexto lo guía y cómo se sabe que ha servido. Vamos una a una.

Personas: quién sabe especificar y quién sabe revisar

La habilidad que escasea en un equipo con agentes no es teclear. Son dos, y casi ningún plan de formación las nombra: escribir una especificación que un agente pueda ejecutar sin adivinar y revisar código que no has escrito, con criterio para detectar lo que parece correcto y no lo es. Una prueba para esta semana: elige tres cambios entregados el último mes y pregunta, de cada uno, quién escribió lo que se le pidió al agente y quién entiende por qué el resultado es correcto. Si la respuesta es «nadie en concreto», esa perspectiva tiene un hueco.

Los planes de carrera cambian con ello. El recorrido clásico de un junior pasaba por escribir el primer borrador, equivocarse y depurar su error, y ese ejercicio es el que ahora hace el agente. Si nadie lo sustituye, el equipo produce más hoy y forma menos gente capaz de firmar el código mañana. Lo desarrollamos en desarrolladores junior con IA; la salida pasa por que el junior escriba la especificación y explique su cambio sin el asistente delante. Lo mismo vale al incorporar a alguien: si un agente resuelve la prueba técnica, lo que hay que mirar es el criterio.

Una aclaración de escala. Esta perspectiva es la del equipo de desarrollo; la adopción en toda la empresa, con sus resistencias y su cultura, tiene otra dimensión y la tratamos en personas y cultura, más allá de la formación.

Procesos: el ready es la especificación y el done es la verificación

En un equipo ágil, ready y done son las dos puertas de una tarea: cuándo está lista para empezar y cuándo está terminada. Con IA, las dos puertas cambian de contenido.

• Ready = la especificación. Una tarea está lista cuando existe una especificación con criterios de aceptación que se puedan comprobar. Es la idea de Spec-Driven Development (SDD, desarrollo guiado por especificaciones): la especificación es la fuente de verdad y el código se deriva de ella. Una historia de usuario de tres líneas bastaba para una persona que conocía el producto; no basta para un agente que no lo conoce.
• Done = la verificación, y dónde firma una persona. Una tarea está terminada cuando el resultado se ha comprobado contra la especificación y, en los puntos de riesgo, una persona ha firmado. Que los tests pasen no basta si los ha generado el propio agente desde su código. Tampoco se trata de aprobarlo todo: aprobarlo todo no es control, es un atasco.

Esto desplaza el cuello de botella. Es un razonamiento, no una medida: si el agente produce más cambios por hora, la cola ya no se forma al escribir, sino al revisar y al verificar, y un proceso de review diseñado para un autor que ya no existe se convierte en el límite. Por eso la frecuencia de despliegue, que antes dependía sobre todo de la automatización, depende ahora también de lo que cuesta verificar un cambio. Cada pieza la hemos tratado por separado: la especificación como el sitio donde se firma, el método SDD y el review que sigue esperando a un autor.

Herramientas: las reglas por encima de la herramienta

La tercera perspectiva se suele leer como «qué asistente usamos». Con agentes, la pregunta que decide es otra: dónde vive lo que el agente necesita saber. Las reglas del proyecto, los patrones, los estándares y las decisiones de arquitectura pueden estar en la cabeza de dos personas, en el historial de un chat o en ficheros versionados que el agente lee en cada tarea. Solo la tercera opción es gobernable. A eso lo llamamos Rules over Tools (las reglas por encima de la herramienta) y es la parte práctica de la ingeniería de contexto (context engineering).

El mercado va en esa dirección. AGENTS.md se define como «un README para agentes»: un lugar predecible para el contexto y las instrucciones que necesita un agente de código, y lo leen herramientas distintas. Claude Code, por su parte, carga ficheros CLAUDE.md y puede leer también el AGENTS.md de un repositorio. Cuando el conocimiento está en ficheros, cambiar de herramienta no obliga a empezar de cero, y eso es lo que hace secundaria a la herramienta. Secundaria no es irrelevante: se sigue eligiendo por seguridad, coste y encaje, pero deja de ser el sitio donde está el método.

Hay un límite que conviene conocer. La documentación de Claude Code lo dice sin rodeos: esos ficheros son contexto, no configuración que se imponga, y cuanto más específicas y concisas son las instrucciones, con más constancia las sigue el modelo. Lo que tiene que cumplirse siempre no debe vivir solo en un texto: va a una comprobación automática, a una regla del repositorio o a un gancho que bloquee la acción. Texto para orientar; comprobaciones para garantizar.

La experiencia del desarrollador, que es lo que mide esta perspectiva, tiene tres dimensiones según Noda, Storey, Forsgren y Greiler: los bucles de retroalimentación, la carga cognitiva y el estado de flujo. Con agentes, las dos primeras se vuelven concretas. Un agente sin contexto obliga a reexplicarle el proyecto en cada sesión, y eso es carga cognitiva. Un review lento es un bucle de retroalimentación largo. La pregunta de diagnóstico no es «¿están contentos con el asistente?», sino «¿qué tiene que volver a explicar cada persona cada vez, y cuánto espera por una respuesta?». Cómo se construye ese contexto está en context engineering, la disciplina que sostiene a los equipos con IA.

Indicadores: medir entrega y calidad, no actividad

«Lo que no se mide no se puede mejorar» sigue siendo cierto, con una trampa nueva: con IA, lo que es fácil medir es actividad. Líneas generadas, licencias activas, sugerencias aceptadas. Son números que suben casi solos al adoptar una herramienta y no dicen si el software llega antes ni mejor. Es el mismo problema que describimos en el ROI de Copilot y Cursor.

DORA mide la entrega con cinco métricas, en dos grupos. Las de rendimiento: tiempo de entrega de un cambio (desde el commit hasta producción), frecuencia de despliegue y tiempo de recuperación de un despliegue fallido. Las de inestabilidad: tasa de cambios fallidos y tasa de despliegues de corrección no planificados. Sirven porque se miran juntas: si la IA sube el rendimiento pero también la inestabilidad, el equipo solo está llegando más rápido a producción con más problemas. Los datos salen del repositorio y del sistema de despliegue, no de una encuesta.

La segunda razón para medir es que la percepción falla. En el ensayo aleatorizado que METR publicó en julio de 2025, 16 desarrolladores con experiencia resolvieron 246 tareas reales de repositorios que conocían bien. Con herramientas de IA tardaron un 19 % más; esperaban ir un 24 % más rápidos y, al terminar, seguían creyendo que habían ido un 20 % más rápidos. Los propios autores acotan el resultado: muestra pequeña, desarrolladores veteranos en proyectos conocidos y herramientas de principios de 2025. No prueba que la IA no sirva. Prueba que una impresión no es una medición, y que hace falta una línea base antes de empezar. Qué medir exactamente, y qué dejar de medir, lo desarrollamos en los KPIs de equipos de desarrollo con IA.

Cómo usar las cuatro perspectivas esta semana

No hace falta un proyecto para empezar. Basta una sesión de dos horas con el equipo y una entrega real del último mes:

1. Elige un cambio que llegó a producción y reconstruye su recorrido: quién lo pidió, qué especificación había, qué generó el agente y qué contexto leyó.
2. Marca dónde esperó: en la especificación, en el review, en la verificación o en un despliegue.
3. Para cada perspectiva, anota una pregunta de la tabla que el equipo no sepa responder con un dato.
4. Elige la perspectiva con más huecos y fija una métrica de entrega que revisar dentro de un mes.

Una perspectiva débil limita a las demás: de nada sirve un buen contexto si nadie sabe especificar, ni medir la entrega si el review no tiene dueño. Y si la duda es anterior —por dónde empezar con la IA en toda la empresa, no solo en el equipo de desarrollo—, la pieza que corresponde es las siete capas de madurez.

La pregunta que queda para tu equipo es la de siempre, con otra forma: ¿entregáis antes que hace un año o solo tecleáis más rápido? Si cuesta responder con un dato, ya sabes qué perspectiva revisar primero.

Preguntas frecuentes

¿Cuáles son las cuatro perspectivas de un equipo de desarrollo que trabaja con IA?

Personas, procesos, herramientas e indicadores. Son las perspectivas clásicas de diagnóstico de un equipo de TI, pero con IA cambian las preguntas: en personas, quién sabe escribir especificaciones y revisar código generado; en procesos, qué significan ready y done; en herramientas, dónde vive el contexto que lee el agente; y en indicadores, si se mide la entrega y la calidad o solo la actividad.

¿Qué significan «ready» y «done» cuando un agente escribe el código?

Ready pasa a ser una especificación con criterios de aceptación que se puedan comprobar, porque un agente no conoce el producto como una persona del equipo. Done pasa a ser que el resultado se ha verificado contra esa especificación y que, en los puntos de riesgo, una persona ha firmado. Que los tests pasen no basta si los ha generado el propio agente desde su código.

¿Qué es «Rules over Tools» y por qué importa que el contexto viva en ficheros?

Es el principio de que las reglas del proyecto, los patrones, los estándares y las decisiones de arquitectura deben vivir escritos en ficheros versionados que el agente lee en cada tarea, por encima de la herramienta concreta. Formatos como AGENTS.md los leen herramientas distintas, así que cambiar de herramienta no obliga a empezar de cero. Es la parte práctica de la ingeniería de contexto.

¿Qué indicadores sirven para saber si la IA mejora la entrega?

Los de entrega y estabilidad, no los de actividad. DORA propone cinco: tiempo de entrega de un cambio, frecuencia de despliegue, tiempo de recuperación de un despliegue fallido, tasa de cambios fallidos y tasa de despliegues de corrección no planificados. Líneas generadas, licencias activas o sugerencias aceptadas suben al adoptar la herramienta y no dicen si el software llega antes ni mejor.

¿Por qué no basta con preguntar al equipo si la IA les hace ir más rápido?

Porque la percepción falla. En el ensayo aleatorizado de METR de julio de 2025, 16 desarrolladores con experiencia tardaron un 19 % más con herramientas de IA y, al terminar, creían haber ido un 20 % más rápidos. Los autores advierten del tamaño reducido de la muestra y de que las herramientas eran de principios de 2025. La lección es medir con datos del repositorio y del despliegue, con una línea base previa.

¿Por dónde se empieza un diagnóstico de las cuatro perspectivas?

Por una entrega real del último mes. Se reconstruye su recorrido (quién la pidió, qué especificación tenía, qué generó el agente, qué contexto leyó), se marca dónde esperó y se anota, en cada perspectiva, la pregunta que el equipo no sabe responder con un dato. Se elige la perspectiva con más huecos y una métrica de entrega que revisar dentro de un mes.

Fuentes

• DORA (Google Cloud), «State of AI-assisted Software Development 2025».
• DORA, «DORA's software delivery performance metrics» (cinco métricas: rendimiento e inestabilidad).
• Abi Noda, Margaret-Anne Storey, Nicole Forsgren y Michaela Greiler, «DevEx: What Actually Drives Productivity», ACM Queue, marzo-abril de 2023 (copia en PDF alojada por una de las autoras).
• METR, «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity», 10 de julio de 2025.
• AGENTS.md, formato abierto para guiar a agentes de código.
• Documentación de Claude Code, «How Claude remembers your project».