Escribo más que nunca desde que uso IA. Y no es un error.

La paradoja detrás del co-pensamiento con modelos de lenguaje: por qué la promesa de ‘escribir menos’ resultó ser exactamente al revés.

por Camilo — Julio 4 2026 · LinkedIn

---

Son las once de la noche y llevo cuarenta minutos escribiendo. No estoy redactando un informe desde cero: estoy conversando con un modelo de lenguaje sobre la arquitectura de un proyecto personal. Y en algún momento, sin buscarlo, me doy cuenta de algo raro: llevo más texto tipeado esta noche que en una sesión equivalente de hace tres años, cuando escribía todo yo, sin ayuda de nadie.

Eso no debería pasar. Si la promesa de la inteligencia artificial generativa es “hacer más con menos esfuerzo”, la lógica dice que debería estar escribiendo menos, no más. Delegar, no multiplicar. Pero ahí estaba yo, con las manos cansadas, después de haber leído y reescrito el mismo párrafo cinco veces distinto.

Empecé a prestarle atención a ese patrón. No solo en mí — en cómo trabajan los equipos de ingeniería con los que interactúo día a día en la nube, en cómo se arman prompts, en cuánto tiempo se pasa leyendo lo que el modelo devuelve antes de aceptarlo. Y la conclusión a la que llegué, después de meses de observación (y después, más recientemente, de leer con más rigor la literatura académica sobre el tema), fue esta: la IA generativa no reduce el volumen de lectoescritura del profesional experto. Lo aumenta. Y hay una razón concreta para que esto pase.

El fin de la parálisis, el comienzo de otra cosa

Durante años, una de las barreras iniciales más frecuentes en cualquier tarea de creación —escribir código, un documento, un diseño— fue arrancar. La hoja en blanco. El cursor parpadeando. Ese “File → New Project” que todo developer conoce, con la carpeta vacía mirándote de vuelta. Ese momento en el que todavía no existe nada y cualquier primera línea se siente insuficiente.

La IA generativa mata ese problema de un golpe. Le pedís un borrador, y en segundos tenés algo con qué trabajar. No hace falta que sea bueno. Alcanza con que exista. Y ahí es donde empieza a pasar algo interesante: en lugar de invertir tu energía en generar la primera versión, la invertís en mejorarla. Es la misma lógica del desarrollo ágil de software — sacar un MVP imperfecto y iterar sobre él — aplicada a la escritura. “Hacé algo, después hacelo mejor” no es una frase que inventó la industria del software, pero la industria del software la convirtió en método.

El problema es que “mejorarla” no es una tarea liviana. Es, de hecho, donde se concentra casi todo el trabajo real.

De autor a director de orquesta

Cuando trabajás con un modelo de lenguaje en una tarea de cierta complejidad —no “traducime esto”, sino “ayudame a pensar la arquitectura de este sistema”— tu rol cambia de forma silenciosa. Dejás de ser quien escribe línea por línea y pasás a ser quien dirige: quien decide qué se descarta, qué se profundiza, qué restricción hay que agregar para que la siguiente versión se acerque más a lo que tenés en la cabeza.

Ese cambio de rol no te hace escribir menos. Te hace escribir distinto. Tipeás menos texto de destino —el output final— pero tipeás muchísimo más en el proceso: instrucciones, correcciones, matices, restricciones que vas afinando turno a turno. El texto que antes se te ocurría directamente en la redacción ahora tenés que traducirlo primero en instrucciones para otro. Y traducir tu propio pensamiento en instrucciones precisas es, muchas veces, más difícil que escribirlo directamente.

El costo real: leer con desconfianza

Hay una segunda razón, todavía más importante, para este aumento de volumen: no podés simplemente copiar y pegar lo que te devuelve un modelo de lenguaje. Los modelos tienen sesgos conocidos, tienden a converger hacia respuestas “promedio” y, en ciertos contextos, directamente te dicen lo que creen que querés escuchar antes que lo que es más correcto. Aceptar un output sin revisarlo es, para cualquier profesional que se tome en serio su trabajo, no-negociable.

Entonces leés. Contrastás con lo que ya sabés. Buscás el contraejemplo que el modelo no consideró. Corregís lo que está mal, lo que suena bien pero no es preciso, lo que es genérico cuando tu problema es específico. Ese trabajo de lectura crítica —que yo llamo, para mí mismo, el modo “editor hiperactivo”— consume mucho más tiempo y mucho más texto que la redacción original que reemplaza.

Y acá conviene ser honesto con algo, porque cualquiera que siga de cerca la conversación sobre IA y cognición se lo va a preguntar de inmediato: ¿esto no contradice la investigación del MIT Media Lab que documentó “deuda cognitiva” en usuarios de modelos de lenguaje, con menor actividad cerebral y menor sentido de autoría sobre lo escrito? No necesariamente. Ese estudio midió compromiso neuronal durante la escritura — cuánta actividad distribuida hay en el cerebro mientras se redacta. Lo que yo describo acá es otra cosa: volumen de texto procesado a lo largo de toda la tarea. Ambas cosas pueden ser ciertas a la vez. Es perfectamente posible generar y evaluar más texto, en más turnos, mientras el patrón de actividad cerebral durante cada tramo individual de escritura sea distinto al de escribir desde cero. No es una contradicción; son dos mediciones de ángulos distintos del mismo fenómeno, y ninguna de las dos cierra la discusión — el propio estudio del MIT tiene objeciones metodológicas serias todavía sin resolver dentro de la comunidad académica.

Lo que esto significa

Si te reconocés en esto —si sentís que “deberías” estar escribiendo menos y en cambio terminás tipeando más que antes— no es que estés usando mal la herramienta. Es la naturaleza del trabajo que cambió. El esfuerzo se corrió: antes estaba en generar, ahora está en dirigir y en evaluar. Y dirigir y evaluar bien, cuando el problema es complejo, requiere más texto, no menos.

Esto es apenas la primera pieza de algo más grande que estuve investigando en los últimos meses: qué pasa cuando tratamos de resolver esta “sobrecarga” con atajos como el dictado por voz, o escuchando las respuestas de la IA en vez de leerlas. Spoiler: tampoco funciona, y en las próximas entregas de esta serie voy a contar por qué.

Si te interesa el desarrollo completo —con las fuentes académicas, la auditoría de citas, y hasta mis propias notas desordenadas del proceso de investigación, tal como quedaron— está todo publicado sin editar en mi repositorio: investigación completa en GitHub. Fue un ejercicio personal para entrenar el músculo de pensar un problema a fondo, no un paper para publicar — así que tomalo, cuestionalo, o usalo como quieras.