Acotar, especificar y auditar: los nuevos roles humanos en el desarrollo de software con IA

En el artículo sobre deuda de verificación mostramos que, con IA, un equipo genera software más rápido de lo que puede verificarlo: entre enero de 2024 y septiembre de 2026, los pull requests integrados al mes en GitHub crecieron 5.6 veces y los aprobados por otra persona, solo 2.6. La consecuencia para las personas es directa: si el cuello de botella ya no es escribir código sino validarlo, el trabajo humano tiene que moverse a donde está el cuello de botella.

Este artículo propone cómo. La tesis: el rol humano deja de ser el de revisor universal de código y pasa a tres funciones: acotar, especificar y auditar. Para cada una describimos qué hace, con qué herramientas, qué entrega y cómo se mide. Después comparamos cómo se veía un equipo de producto en 2023 con cómo debería verse hoy, y revisamos qué dicen los datos sobre la reducción real de personas, incluidos los que contradicen la tesis.

Una aclaración antes de empezar: «dejar de revisar código» no significa dejar de leerlo. Significa dejar de revisarlo todo, línea por línea, como control principal. La revisión humana completa sigue siendo obligatoria donde fallar cuesta caro: pagos, autenticación, datos personales, seguridad.

Por qué tiene que cambiar el rol

El modelo DVI del artículo anterior describe la deuda de verificación con una ecuación:

donde G son los cambios generados por día, α las horas para verificar cada uno, V la capacidad de verificación y δ la tasa a la que la deuda pendiente se encarece. A eso se suma p_c, la probabilidad de que el código y sus pruebas compartan el mismo error, y C_i, el costo de que un fallo llegue a producción.

Hasta hace poco, la hora de una persona programadora se gastaba sobre todo en G: escribir código. Hoy G lo producen agentes a un costo marginal casi nulo, y añadir más G sin mover lo demás solo agranda la deuda. La hora humana rinde más en los otros términos:

Ninguna de las cuatro es nueva. Lo nuevo es la proporción: antes eran la parte menor del trabajo de un equipo y ahora son casi todo.

Lo que está medido y lo que no

Antes de proponer roles y tamaños de equipo, conviene separar lo que los datos sostienen de lo que es interpretación.

Tres lecturas que se sostienen con esa evidencia:

1. La reducción existe, pero entra por la puerta de la contratación. Se contrata menos gente que empieza, no se despide más gente con experiencia.
2. Generar más rápido no garantiza entregar más. METR y DORA coinciden en que la ganancia de productividad no es automática; depende de cómo se organiza el trabajo alrededor de la IA.
3. Lo que se demanda es criterio. Las vacantes que vuelven son senior y de IA: personas que pueden decidir qué construir y juzgar si lo construido es correcto.

Los tres roles

1. Acotar: decidir qué se construye, dónde puede actuar la IA y qué tan grave es fallar

Quien acota define los límites dentro de los cuales trabaja la IA. Es el rol que heredan la gestión de producto y el liderazgo técnico, y en equipos chicos lo puede cubrir una sola persona.

Funciones

• Formular el problema y lo que queda fuera de alcance, antes de pedir una línea de código.
• Clasificar el riesgo de cada cambio (bajo, medio, alto, crítico) y decidir qué controles exige cada nivel.
• Fijar el presupuesto de cambios por ciclo: cuánto trabajo en curso cabe sin rebasar la capacidad de verificación del equipo.
• Trazar los límites del sistema: módulos, contratos entre ellos y qué puede tocar un agente sin permiso adicional.
• Reservar capacidad para pagar deuda vieja, al menos al ritmo al que se encarece.

Herramientas: registros de decisiones de arquitectura (ADR), contratos versionados (OpenAPI, JSON Schema, AsyncAPI), mapas de dominio, matrices de riesgo, límites de trabajo en curso, permisos y hooks que restringen lo que un agente puede ejecutar o editar.

Entrega: alcance escrito, clasificación de riesgo por cambio, decisiones registradas y límites técnicos aplicados por máquina, no por buena voluntad.

Cómo se mide: proporción de cambios con riesgo clasificado, cambios que salen de los límites acordados y relación entre lo generado y lo verificado (ρ̂ del artículo anterior).

2. Especificar: decir con precisión qué significa «correcto»

Quien especifica convierte una necesidad en algo que una máquina puede comprobar. Es el rol que heredan el análisis de negocio y buena parte de la programación: ya no se escribe la implementación, se escribe lo que la implementación debe cumplir.

Funciones

• Escribir historias de usuario con criterios de aceptación verificables.
• Traducir esos criterios a pruebas antes del código, y congelarlas para que el agente no las pueda editar para hacerlas pasar.
• Definir propiedades e invariantes: lo que debe ser cierto para cualquier entrada, no solo para los ejemplos.
• Mantener los contratos entre componentes y los casos límite del dominio.
• Partir el trabajo en cambios pequeños, porque verificar un cambio chico cuesta mucho menos.

Herramientas: plantillas de historia de usuario, Gherkin o EARS para requisitos, pruebas de aceptación, pruebas basadas en propiedades (Hypothesis, fast-check, jqwik), pruebas de contrato (Pact), sistemas de tipos estrictos y, en el núcleo crítico, especificación formal (TLA+, Alloy, Dafny).

Entrega: una especificación ejecutable: pruebas en rojo que describen el comportamiento esperado antes de que exista el código.

Cómo se mide: proporción de cambios con pruebas previas, tamaño medio de PR, y cuántos defectos escapan por una especificación ambigua o incompleta.

3. Auditar: comprobar de forma independiente que lo construido es lo especificado

Quien audita no revisa todo: decide qué revisar, cómo y con qué intensidad, según el riesgo. Es el rol que heredan las pruebas de calidad (QA) y la revisión de código, con un cambio de fondo: su valor está en ser independiente de quien generó el código, incluido el modelo de IA.

Funciones

• Revisar línea por línea los cambios de riesgo alto y crítico.
• Auditar por muestreo el resto: elegir al azar una fracción de los cambios de riesgo bajo y medio y revisarlos a fondo, para estimar cuántos defectos se están escapando.
• Medir la calidad de las pruebas, no solo su cobertura: cuántos errores sembrados sobreviven (pruebas de mutación).
• Usar verificadores que no compartan sesgo con el generador: otro modelo, otra persona, análisis estático, pruebas escritas desde la especificación.
• Construir el modelo de amenazas de las funciones con datos personales, dinero o entradas externas, con una prueba por amenaza.
• Detectar la aprobación sin revisión: aprobaciones demasiado rápidas para el tamaño del cambio.

Herramientas: pruebas de mutación (Stryker, PIT, mutmut), análisis estático y de seguridad (Semgrep, CodeQL), escáneres de secretos y dependencias, un modelo de IA distinto al que generó para pre-revisar, guías de revisión por riesgo, STRIDE para amenazas y estadística básica de muestreo.

Entrega: un dictamen por cambio de riesgo alto, y una estimación periódica de la tasa de defectos que escapan en el resto.

Cómo se mide: tasa de mutantes que sobreviven, defectos encontrados en producción frente a los encontrados antes, y tasa de cambios fallidos (DORA).

Los roles que se mantienen

• Operar (plataforma, SRE): despliegue gradual, feature flags, reversión automática, observabilidad. Baja C_i: no reduce la deuda, pero vuelve tolerable un fallo que escapa. Suele compartirse entre varios equipos.
• Diseñar (UX): la IA produce interfaces rápido, pero decidir qué necesita una persona usuaria sigue siendo trabajo de investigación. También suele compartirse.

De dónde viene cada rol

Capacidades que hay que desarrollar

Lo que pierde valor relativo: memorizar sintaxis, escribir código repetitivo, la velocidad de tecleo y conocer de memoria la API de cada biblioteca. Lo que no pierde valor: entender cómo funciona el software por dentro. Sin esa base no hay auditoría posible.

Cómo se ve un equipo: 2023 frente a hoy

Tomamos un equipo de producto típico de 2023, del tamaño que la industria suele usar para un producto web con aplicación y API: diez personas, cuatro de ellas dedicadas a escribir código.

Con la lógica de este artículo, el mismo producto hoy necesitaría unas seis personas equivalentes:

Cómo leer esta comparación:

1. Es una composición ilustrativa, no una medición. No existe hoy un estudio que mida el tamaño de los equipos de producto antes y después de la IA. Los datos de la sección anterior miden empleo y vacantes, no equipos.
2. La reducción sale de escribir código, no de verificar. La capacidad de verificación se mantiene o crece. Recortar ahí, con más código entrando, es exactamente lo que hace crecer la deuda.
3. El número depende del riesgo. Con el mismo razonamiento, un producto interno de riesgo bajo podría funcionar con tres personas, y un sistema de pagos o de salud quizá con las mismas diez que antes: el ahorro en programación se reinvierte en verificación.
4. Depende de qué haga la empresa con la productividad. Si la usa para construir más productos en lugar de recortar, el empleo total puede no bajar, aunque cada equipo sea más chico. Los propios autores del estudio de Stanford advierten que más productividad puede subir o bajar el empleo según cuánto crezca la demanda.

Lo que puede salir mal

Esta reorganización tiene costos y riesgos que conviene decir antes que nadie:

1. Se rompe la cantera. Si se contrata menos gente que empieza, como muestran los datos de Stanford, ¿de dónde saldrán las personas con criterio para auditar dentro de diez años? Nadie aprende a juzgar código sin haberlo escrito y roto antes. Un equipo que piensa a largo plazo necesita formar personas, aunque hoy le salga más caro.
2. Equipos más chicos, más concentración de conocimiento. Con seis personas, la salida de una pesa más. Las decisiones registradas y los contratos explícitos dejan de ser burocracia y se vuelven la memoria del equipo.
3. Auditar resultados de una máquina cansa y adormece. Cuando el sistema casi siempre acierta, la atención baja y se aprueba sin mirar. El artículo anterior ya encontró la señal: en su muestra, los PRs firmados por Claude Code reciben 4.8 veces menos revisiones por cada 1,000 líneas.
4. La productividad no está garantizada. METR midió un 19% más de tiempo con IA en personas expertas; DORA, menos estabilidad. Recortar personas suponiendo una ganancia que el equipo todavía no tiene es acumular deuda por adelantado.
5. El contexto regulado cambia la cuenta. En sectores con auditorías externas, la evidencia de revisión humana es un requisito, no una opción de eficiencia.

Cómo hacer la transición

1. Medir antes de recortar. Calcular cuántos cambios se integran por cada uno revisado, y estimar la deuda con la calculadora del artículo anterior.
2. Clasificar el riesgo de cada parte del sistema y escribir qué controles exige cada nivel.
3. Instituir pruebas antes del código, congeladas para que el agente no las edite.
4. Reconvertir QA en ingeniería de verificación: mutación, muestreo e independencia, en vez de ejecución manual.
5. Mover a quienes programaban hacia especificación y auditoría, según su perfil, con formación explícita en las capacidades de la tabla anterior.
6. Reservar capacidad para pagar deuda, al menos al ritmo al que se encarece.
7. Mantener un programa de entrada: personas que empiezan auditando bajo supervisión y escribiendo especificaciones, para que exista criterio dentro de cinco años.

Lo que este artículo no afirma

• No afirma que el código ya no haya que leerlo. Afirma que leerlo todo deja de ser el control principal, y que se lee donde importa.
• No afirma que la IA ya haya reducido el empleo en software de forma generalizada. La evidencia disponible muestra menos contratación de gente joven y vacantes por debajo de 2020, con causas que todavía se discuten.
• No afirma que seis sea el número correcto para todo equipo. Es una ilustración para un producto de riesgo medio; el tamaño adecuado sale del riesgo y de la capacidad de verificación.
• No afirma que las personas sobren. Afirma que su trabajo cambia de lugar, y que ese lugar exige más criterio, no menos.

Fuentes

• Brynjolfsson, Chandar y Chen, Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence, Stanford Digital Economy Lab, versión de agosto de 2026.
• Indeed Hiring Lab, datos de vacantes de desarrollo de software en EE. UU., julio de 2026.
• Becker, Rush, Barnes y Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR (2025).
• Peng, Kalliamvakou, Cihon y Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot (2023).
• DORA, Accelerate State of DevOps Report (2024) y State of AI-assisted Software Development (2025).
• U.S. Bureau of Labor Statistics, Occupational Outlook Handbook: Software Developers, Quality Assurance Analysts, and Testers, proyecciones 2024-2034.
• Dixi-Project, Deuda de verificación en el desarrollo con IA (2026): datos de GitHub y modelo DVI.