¿Cómo saber quién está pensando?

Ahora mismo, en tu equipo, hay al menos un ingeniero que entrega trabajo que no sabría reproducir en una pizarra.

El código compila. Los tests pasan. La PR está impecable. Pero el razonamiento nunca fue suyo, y no lo sabe. Desde dentro, tomar prestado un pensamiento se siente exactamente igual que tener uno.

Lo descubrirás la próxima vez que alguien haga la pregunta de la caché. El diagrama de arquitectura está en pantalla, el diseño se ve limpio y un ingeniero staff se inclina hacia delante:

Explícame por qué descartaste aquí una caché write-through. ¿Qué pasa cuando se reinicia este nodo concreto bajo carga?

La pausa que sigue debería ser una pausa de recuperación: el ingeniero rebuscando en su propio modelo mental la restricción que había considerado, la alternativa que había sopesado, el efecto de segundo orden que tenía en la cabeza cuando tomó la decisión.

Hoy, la pausa es un vacío.

La fricción sostenía la estructura

Esto no es una elegía por los viejos tiempos de rebuscar en Stack Overflow.

La IA es un multiplicador fantástico. Es un revisor incansable de medianoche que leerá tu diseño a la 1 de la madrugada sin quejarse. Es un sparring que mantiene un contraargumento el tiempo suficiente para que montes una defensa de verdad. Te dice lo que habías pasado por alto. Los ingenieros que la usan bien son, con cualquier medida honesta, más agudos que hace dos años. Yo la uso. Tú la usas. Este post sería un fraude si fingiera lo contrario.

Pero hemos cometido un error de categoría sin enterarnos. Asumimos que la fricción de la ingeniería de software era solo un límite de velocidad. No lo era.

La fricción no solo nos frenaba. Sostenía la estructura. Era un mapa topográfico en tiempo real que te decía dónde vivían los problemas difíciles. Optimizamos la fricción y, sin querer, borramos el mapa.

Cuando un problema era difícil de verdad, pasabas tres horas mirando una pared, sudando delante de una pizarra y cuestionándote la carrera. La fricción era una brújula. La misma fricción que hacía el trabajo insoportable era la que te obligaba a construir el modelo en la cabeza: la semántica del write-through, los modos de fallo, la ventana de lectura tras escritura. Lo tenías todo en el cráneo hasta que podías defender el diseño sin el documento abierto.

El modelo alucina en doce segundos un documento de arquitectura perfectamente formateado y de sintaxis deliciosa. No hay fricción. Hay un chute de dopamina y una mentira. Tienes la respuesta. No tienes el músculo.

El eje roto

Una organización de ingeniería es un problema de muestreo. No puedes vigilar cada pulsación de tecla, así que lees los artefactos e infieres la cognición. Pull requests, documentos de diseño, postmortems, alguna revisión de incidente. Esos son los instrumentos de muestreo. Las evaluaciones de desempeño, la calibración, los listones de promoción y los procesos de contratación descansan en la suposición de que el artefacto y la cognición salen del mismo sitio.

La IA partió el eje que unía esas dos ruedas.

Ahora el resultado es función de tres variables (el ingeniero, el modelo y el prompt) y los artefactos te hablan de las tres, mezcladas, sin forma de separar la señal. Una PR pulida es compatible con un ingeniero reflexivo, con uno que no lo es o con una pestaña que alguien dejó abierta en el tren. El artefacto sigue llegando a tiempo. Solo que ya no lleva la señal para la que lo leías.

Esto importa sobre todo con los ingenieros a los que quieres hacer crecer. Un senior que produce salida fluida con IA está, en el peor de los casos, apalancado. El músculo ya está construido y el modelo solo lleva el teclado. Un junior que produce lo mismo lo produce sin haber construido nunca el músculo que el trabajo debía construirle. Entrega la caché write-through sin haber modelado qué pasa cuando el nodo se cae. Entrega la réplica de lectura para analítica sin haberse sentado nunca con la ventana de consistencia. El artefacto está bien. La intuición arquitectónica que debía crecer debajo nunca apareció.

La paradoja de METR

Aquí hay un número que debería estar mirando a la cara a los líderes de ingeniería. METR hizo un estudio riguroso en 2025. Desarrolladores con experiencia que usaban asistencia de IA completaron las tareas un 19 % más despacio que sin ella, mientras creían ir un 20 % más rápido.¹ Los juniors en código que no conocen, en el trabajo aparte de McKinsey, van al revés: entre un 26 y un 39 % más rápido.²

El gradiente va al revés de lo que cabe en un organigrama. ¿Por qué los juniors parecen ingenieros 10x mientras los seniors parecen estancados?

Los seniors no lo hacen peor con IA. El trabajo en el que la IA ayuda no es el que ellos hacían. Su cuello de botella nunca fue teclear, sino decidir qué teclear. Los juniors parecen rápidos porque su cuello de botella era teclear, y ahora teclear es gratis. La función de producción no solo ha mejorado, se ha reubicado. Se ha ido del artefacto por completo. Los juniors producen salida de aspecto senior. No están construyendo, por ninguna señal medible, criterio senior.

Los juniors cierran tickets tan rápido que el tablero de Jira parece una tragaperras soltando premios. El dashboard dice que son un 39 % más rápidos. El dashboard está encantado. El dashboard, eso sí, no tiene que mantener la máquina de estados que se acaban de inventar.

Tres cosas que fallan dentro de tu cabeza

Tres mecanismos psicológicos se activan a la vez cuando lees salida fluida de una IA y la llamas pensamiento propio. Están documentados, tienen décadas y no han envejecido.

La ilusión de fluidez. La gente juzga lo bien que entiende algo por lo fácil que le viene a la mente.³ La salida de una IA es facilísima. Pulida, segura, estructurada justo al nivel que puedes absorber. Leerla produce la cálida sensación de entender sin hacer el trabajo que suele producir esa sensación.

La calidez de entender es el bug.

La señal de esfuerzo perdida. Durante casi toda tu carrera, esto me costó era un indicador útil de estoy haciendo cognición de verdad. La fricción hacía la calibración por ti. Con el modelo en el bucle, la cognición se delega pero el indicador no se recalibra. Entregas la cosa, te resultó fácil, das por hecho que era sencilla, cuando quizá significa que no pensaste.

La deriva de autoría. La investigación sobre monitorización de la fuente tiene cuarenta años. La gente no distingue de forma fiable las ideas que generó de las que le soplaron.⁴ Para el jueves, la deriva ya es completa. El ingeniero mira un bloque de 400 líneas de regex que “hizo en pareja” con el modelo y piensa de verdad: Ah, sí, me acuerdo de cuando elaboré con esmero ese lookbehind negativo. No lo hiciste. Le pediste a la caja del prompt que hiciera desaparecer los caracteres malos y aceptaste el primer fragmento que no lanzó un error.

La pregunta de la caché cae justo aquí. El ingeniero escribió la capa write-through con un modelo en el bucle. Le resultó fácil. El código compila. Los tests pasan. Pero nunca se detuvo a pensar qué pasa con la escritura en vuelo cuando el nodo se cae. Nunca pensó qué ve la base de datos cuando la caché vuelve en estampida, ni qué devuelve la ruta de lectura durante el calentamiento. No tiene un modelo mental del que recuperar nada cuando se lo preguntan. El código no tiene nada malo. En la cabeza del ingeniero no hay nada.

La introspección ha dejado de funcionar

El efecto combinado es lo que debería quitarte el sueño.

El ingeniero que ha pasado de ampliar a sustituir no miente cuando dice que lo pensó bien. Se sintió fluido. El trabajo le pareció fácil, como le parece fácil el trabajo que se entiende bien. Recuerda el razonamiento como suyo.

El informe introspectivo no es fiable. El artefacto no es fiable.

Lo que queda es lo que sabe hacer, en frío, cuando se lo pides.

El escepticismo no es desconfiar de la IA

El escepticismo, aquí, no es desconfiar de la IA. Es desconfiar de la señal de fluidez. Es la disciplina de separar puedo leer esto y siento que lo entiendo de puedo producir esto de la nada mañana por la mañana. Antes eran más o menos lo mismo. Ya no.

Este es el movimiento que tiene que ocurrir primero, en la cabeza del propio ingeniero, antes de que ningún manager pueda hacer nada útil con él. Si el ingeniero no puede aplicárselo a sí mismo, ningún proceso de revisión lo salvará.

Cómo se ve el escepticismo aplicado a ti mismo

• Reproducción en frío. Cierra el portátil. Ve a la pizarra. Reproduce el diseño de memoria, con las alternativas que descartaste. La pausa antes de empezar es el dato.
• Autocuestionamiento adversarial. Elige la suposición con la que estés menos cómodo e intenta romperla sin volver a lanzar el prompt. Si tu primer gesto es abrir el chat, ya tienes la respuesta.
• La prueba del 10x. ¿Qué cambiaría si la suposición de carga se multiplicara por 10? Si tu respuesta es se lo preguntaría al modelo, el diseño es del modelo, no tuyo.

Y luego está la versión de la pregunta de la caché que te haces tú, en tu cabeza, sentado en tu cocina a altas horas de la noche:

Explícame por qué descarté aquí una cola de mensajes. Espera. ¿La descarté? ¿O el modelo simplemente no la mencionó? Espera, ¿soy yo el modelo?

Una vez a la semana, apunta las decisiones que tomaste en tres columnas: tuyas, del modelo y no sé separarlas. La tercera es la interesante. No debería ser la más grande.

La versión del manager

El trabajo del engineering manager ya no es seguir la velocidad. Es sondear la profundidad.

La revisión por conversación es el instrumento que falta. El dato que la organización necesita de verdad (tres momentos por trimestre en los que este ingeniero defendió una decisión no trivial ante preguntas en directo) no está en el calendario de nadie, ni en ninguna plantilla de evaluación, ni en ningún dashboard. Solo existe en la sala, y solo si a alguien en la sala se le ocurrió preguntar.

El intercambio que hay que escuchar:

“Explícame por qué elegiste esta estrategia concreta de indexado de la base de datos.”

Silencio.

“Vale, explícame qué es un índice.”

Un silencio más largo.

Si un ingeniero no puede defender el diseño con el portátil cerrado, no lo escribió.

Contratar ha cambiado

La tercera superficie donde esto aterriza es la contratación, y es donde las consecuencias llegan más rápido.

Doy por hecho que todos los candidatos usan IA. El CV es estupendo, la prueba para casa está limpia y nada de eso es ya una señal. He dejado de sondear la perfección de la sintaxis o la capacidad de depurar: el modelo hace ambas cosas, y el candidato sabe que yo lo sé.

Lo que sondeo ahora es la toma de decisiones por delante del modelo. El candidato que, al pedirle que diseñe algo, dice “necesito esto, pero sé que pasará aquello, y si el tráfico se duplica esto se cae por aquí, así que en realidad haría lo otro” es el candidato que ha construido el músculo. El candidato que reproduce un diseño limpio pero no sabe decirme qué se rompe a 10x es el candidato al que el modelo llevó en brazos durante la prueba.

Lo otro que sondeo es la parte del sistema que el modelo no ve. El clúster que escala horizontalmente detrás del servicio. La caché que vive en el repo de otro equipo. El consumidor aguas abajo que se tragará en silencio un evento malformado durante seis semanas antes de avisar a alguien. El modelo es brillante dentro del código que tiene delante. Está ciego al sistema que lo rodea. Igual que el candidato que solo ha trabajado en pareja con el modelo.

No hay vuelta de hoja: usarán IA. La entrevista ya no va de si pueden producir una función. Va de si pueden sostener el sistema en la cabeza.

El problema de los tres años

Si el sistema no lo ve, no lo puede evaluar. Si no lo puede evaluar, no puede promocionar por ello. Si no puede promocionar por ello, deja de seleccionarlo.

Así que promocionaremos por velocidad. Formaremos una generación entera de ingenieros staff que pueden entregar cualquier cosa y no defienden nada. Los burndown charts serán preciosos. Los burndown charts serán lo único que no esté ahora mismo en llamas.

Los ingenieros senior capaces de defender un diseño bajo interrogatorio no se habrán ido: nunca llegaron a contratarlos. Sus sucesores se ven igual en el dashboard. Solo que no saben responder a la pregunta.

Aplícalo a este post

Vas asintiendo. El argumento te suena bien. La lógica ha encajado.

Pero recuerda el bug: la calidez no es prueba de que el argumento sea correcto.

Este post nació en desacuerdo con AI should elevate your thinking, not replace it, de Koshy John, que defiende la versión de virtud personal de este argumento. Tiene casi toda la razón. Partes de este ensayo se las di a pensar a un modelo. Algunas frases llegaron demasiado fáciles. Hay frases aquí que, si me preguntaran en frío mañana, me costaría reproducir con la misma forma.

¿Soy un genio por articular esto, o simplemente le di a Regenerar hasta que el robot sonó lo bastante cínico?

Mañana por la mañana, cierra el portátil e intenta reproducir esta tesis de memoria. Repasa las tres variables que partieron el eje. Repasa la diferencia entre el argumento de Koshy John y este.

Si no puedes, no lo pensaste. Solo lo leíste.

La caché, eso sí

Dentro de tres años, nuestros dashboards de ingeniería estarán enteramente en verde. La velocidad estará por las nubes. La organización parecerá impecable sobre el papel.

La caché, eso sí, estará en llamas.

---

Footnotes

1. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 2025. ↩

2. McKinsey, Unleashing developer productivity with generative AI, 2023. Reports task-completion gains for less-experienced developers in roughly the 26–39% range, depending on the task type. ↩

3. See Rozenblit, L. & Keil, F., The misunderstood limits of folk science: an illusion of explanatory depth, Cognitive Science, 2002. The fluency-as-proxy-for-understanding effect is robust across decades of work. ↩

4. Johnson, M. K., Hashtroudi, S. & Lindsay, D. S., Source monitoring, Psychological Bulletin, 1993. The foundational synthesis; the result has been replicated and extended into human/AI co-authorship contexts in recent years. ↩