El 33% de los empleados consultados por Workday dice que corregir resultados de inteligencia artificial consume al menos la mitad del tiempo que había ahorrado con ella. La revisión humana puede absorber una parte del beneficio de automatizar tareas.
La encuesta, realizada en agosto de 2026 entre 5,944 empleados de distintos países, también encontró que el 57% considera que debe comprobar cuidadosamente las respuestas antes de confiar en ellas. Son experiencias declaradas en un sondeo de un proveedor de software empresarial, no una medición directa de horas trabajadas.
El "impuesto de verificación" nombra el tiempo que requiere comprobar si una respuesta de IA es correcta y utilizable. Generar el resultado deja pendiente ese trabajo de revisión.
La carga de revisión puede pasar a otro empleado
Un análisis de DORA, el programa de investigación de Google Cloud, publicado el 10 de marzo de 2026 examinó 1,110 respuestas abiertas de ingenieros de Google del tercer trimestre de 2025. Los participantes describieron ventajas al generar código junto con trabajo adicional de auditoría.
Los testimonios describen un traslado de carga: el desarrollador produce cambios más rápido y el revisor recibe más código que comprobar. Ambas tareas pertenecen al mismo proceso.
El análisis cualitativo identifica dificultades, sin estimar una pérdida de tiempo aplicable a todos los sectores.
La mejora se reduce antes de publicar software
El documento de trabajo de Mert Demirer, Leon Musolff y Liyuan Yang, revisado el 6 de septiembre de 2026, estudia más de 500,000 desarrolladores de GitHub mediante comparaciones de trayectorias de adopción con grupos emparejados.
Para agentes interactivos, que editan código junto al desarrollador, la tabla 6 estima aumentos del 957.5% en líneas modificadas, del 153.2% en cambios guardados o commits y del 19.8% en versiones publicadas. Corresponden a las semanas 21 a 30 desde la adopción, respecto de la actividad previa.
La comparación distingue tres resultados del mismo proceso de desarrollo:
| Indicador semanal | Aumento estimado |
|---|---|
| Líneas de código modificadas | 957.5% |
| Commits | 153.2% |
| Versiones publicadas | 19.8% |
Es un estudio observacional preliminar. Los autores interpretan la reducción como compatible con cuellos de botella humanos; las versiones publicadas también aumentan.
El ahorro declarado y el resultado final miden cosas distintas
Leídas en conjunto, las fuentes permiten distinguir dónde aparece el costo y cómo se observa. Workday pregunta por tiempo que los empleados creen haber ganado y después gastado en correcciones. Google recoge relatos sobre revisión. El estudio de GitHub mide actividad y publicaciones de software.
Por eso, el 33% de Workday cuenta personas que reportan perder al menos la mitad de su ahorro; no es el porcentaje de tiempo perdido por toda la muestra. Tampoco un aumento de líneas de código equivale al mismo aumento de productividad empresarial o ingresos. Confundir esos indicadores puede inflar la expectativa de retorno.
DORA recomienda evaluar el flujo completo, incluido el tiempo de revisión y los fallos en producción, y trabajar con cambios pequeños que puedan comprobarse.
Para valorar el retorno de una herramienta, la diferencia relevante está entre terminar una primera versión y tener un resultado utilizable. Contar solo el primer momento deja fuera el trabajo que todavía debe realizar el equipo.
