IA en producción (6/6): te sientes rápido y vas lento

Llevamos cinco entregas hablando de desastres ajenos. Toca la parte incómoda: la que va de ti y de mí.

Porque después de leer los siete fiascos, los permisos que nadie revocó, las copias dentro de la explosión, las respuestas plausibles y el código que funciona pero no aguanta, queda una pregunta sin responder:

Si todo esto es verdad, ¿por qué tenemos todos la sensación clarísima de ir mucho más rápido?

La aguja mide la velocidad. No mide si vas al sitio correcto. Foto: DanTD, CC BY-SA 4.0; imagen recortada y disponible bajo la misma licencia.

El experimento

METR hizo un ensayo controlado aleatorio y lo publicó en julio de 2025. El diseño es lo mejor que tiene, así que vale la pena detallarlo:

• 16 desarrolladores experimentados de proyectos de código abierto.
• 246 tareas reales, de sus propios repositorios. No acertijos, no ejercicios: issues de verdad en código que ellos ya conocían bien.
• Asignación aleatoria: a cada tarea le tocaba, por sorteo, permitir usar herramientas de IA o prohibirlas.

Es decir: gente buena, en su casa, con su código, haciendo su trabajo. Lo más parecido a la realidad que se ha medido en este asunto.

Resultado: tardaron un 19 % más con IA.

Y ahora lo interesante. Al terminar, se les preguntó cómo había ido. Su estimación: la IA les había hecho un 20 % más rápidos.

Casi cuarenta puntos entre lo que pasó y lo que percibieron. Y ojo, con el cronómetro delante: no es que lo recordaran mal a los seis meses, es que con los datos de su propio trabajo encima de la mesa, seguían creyendo lo contrario.

Por qué nos pasa esto

No es estupidez ni autoengaño interesado. Es que estamos midiendo mal por construcción, y creo que hay tres motivos.

El trabajo visible se acelera de verdad

Escribir código es la parte que ves. Y esa parte, efectivamente, va como un tiro: lo que antes eran veinte minutos de teclear ahora son treinta segundos de leer y aceptar.

La sensación es genuina. No te la estás inventando. Lo que pasa es que esa parte nunca fue la mayoría del trabajo.

El trabajo invisible se expande

Mientras tanto crece todo lo demás, que no se contabiliza porque no parece trabajo:

• Leer con atención un bloque que no has escrito tú, para entender qué hace exactamente.
• Detectar que hay un caso que no contempla.
• Reformular la petición porque la respuesta era casi.
• Descartar una solución que funcionaba pero no encajaba con el resto del sistema.
• Y la peor de todas: arreglar algo que parecía bien, que es siempre más caro que escribirlo desde cero.

Nada de eso se siente como avanzar. Se siente como fricción, como pequeñas interrupciones entre los momentos productivos. Pero es tiempo, y el cronómetro lo cuenta.

Esperar no se computa como trabajar

Y una hipótesis mía, que el estudio no mide: el hueco que pasa mientras se genera la respuesta no lo registras como esfuerzo. Es un microdescanso agradable, incluso. Repetido muchas veces al día puede acabar siendo un agujero que tu memoria no ha apuntado en ninguna parte. No sé cuánto explica del resultado; sospecho que algo.

Antes de que me acusen de panfleto

Este estudio tiene límites reales y hay que decirlos, porque si no esto sería exactamente el tipo de artículo unilateral que critico:

• Son modelos de principios de 2025. Han pasado casi dos años, que en esto es una era geológica. El propio equipo de METR cree probable que la ayuda hoy sea mayor, y de hecho ha rediseñado el experimento para volver a medirlo.
• Son 16 personas. Es un ensayo controlado bien hecho, no un censo.
• Es un perfil muy concreto: expertos trabajando sobre código que dominan. Justo el escenario donde menos aporta un asistente, porque el conocimiento ya está en la cabeza. En territorio desconocido, la historia es probablemente distinta.

Así que no, el titular no es «la IA te hace más lento». Sería tan simplista como el contrario.

El titular es este otro, y ese sí que no caduca con la siguiente versión del modelo:

Cuando una herramienta nos hace sentir rápidos, se nos da muy mal juzgar nuestra propia productividad.

Escribí hace una semana que el horizonte se nos ha quedado en «mañana». Este es el mecanismo pequeño y cotidiano de aquella inquietud: si creemos que vamos más rápido de lo que vamos, lo primero que quitamos es el tiempo de comprobar.

En ese grupo y en ese contexto la distancia entre lo medido y lo percibido fue de casi cuarenta puntos. No demuestra que a cualquiera le pase siempre y en todo trabajo, pero sí que la sensación no sirve como medida. Y ese sesgo no está en el modelo: está en nosotros, y va a seguir ahí cuando los modelos sean diez veces mejores.

Y aquí es donde se cierra la serie

Porque el sesgo de velocidad no es un capítulo más. Es uno de los mecanismos que puede contribuir a los otros cinco.

Mira otra vez las cinco entregas anteriores y pregúntate qué faltó en cada una:

• El token con permisos de más: faltó pararse a acotarlo.
• Las copias dentro del mismo volumen: faltó probar una restauración.
• La bibliografía inventada: faltó abrir las fuentes.
• La política que se inventó el bot: faltó que alguien leyera lo que se enviaba.
• La base de datos abierta al mundo: faltó mirar qué viajaba al navegador.

Cinco desastres, cinco comprobaciones omitidas. Y todas tienen algo en común: son lentas, aburridas y no producen nada visible. No puedo demostrar que fuera el sesgo de velocidad lo que las apartó en cada uno de esos casos concretos; lo que sí encaja demasiado bien es el patrón.

Ahora junta eso con una herramienta que te hace sentir un 20 % más rápido de lo que vas. ¿Qué es lo primero que se cae de la lista cuando crees que vuelas?

Exacto. Lo que no se nota.

La sensación de velocidad no es un efecto secundario simpático de la IA. Es una de las vías por las que se erosiona la verificación. Y como conté hablando de lo que pasa cuando la IA se abarata cien veces, la verificación es justo lo único que no se ha abaratado nunca, porque se paga en atención humana.

Mide lo tuyo, que es gratis

No hace falta montar un experimento. Con esto vale:

1. Elige un tipo de tarea que hagas a menudo y que tenga un final claro: «arreglar un fallo reportado», «añadir un endpoint», «montar una pantalla».
2. Apunta la hora de inicio y de fin. Diez veces. En una hoja de cálculo, sin ceremonia.
3. Anota aparte el tiempo de después: revisiones, correcciones, el fallo que apareció dos días más tarde por culpa de eso.
4. Compara con tu impresión. Ahí está toda la información que necesitas, y es tuya, no de un estudio de gente que no conoce tu código.

Y una regla de bolsillo que uso yo:

Si no sabrías explicar por qué funciona, no lo has terminado.

No es purismo. Es que el día que falle, lo vas a arreglar tú a las tres de la mañana, y ese rato lo pagas al precio de siempre.

Cierre: el taladro

Seis entregas después, la metáfora aguanta entera, y me la quedo.

La IA es el mejor taladro que se ha fabricado nunca. Rapidísimo, incansable, obediente, disponible a las tres de la mañana y capaz de redactar un parte de incidencias mejor que la mayoría de humanos que conozco. Yo lo uso todos los días y no pienso dejar de usarlo: sería como escribir sin corrector o compilar a mano.

Lo que no hace, lo que no ha hecho nunca ninguna herramienta y lo que no va a hacer esta, es saber por dónde pasa la tubería.

Eso —el plano, el criterio, la manía de comprobar, el medio segundo de miedo antes de pulsar Intro sobre algo irreversible— sigue siendo el oficio. Y resulta que, justo ahora que todo el mundo puede hacer agujeros, es cuando más vale.

No es oro todo lo que reluce. Pero es un taladro cojonudo.

Úsalo. Y mira el plano.

(Fin de la serie. Si has llegado hasta aquí y te has reconocido en alguna de las seis entregas: bienvenido, yo también. La diferencia entre un profesional y un manazas no es no equivocarse nunca. Es saber dónde puede doler.)