«Cómo percibimos, comprendemos e interactuamos y por qué eso te está costando tokens.»

Hay una escena que se repite millones de veces por día, en todo el mundo, y que nadie mira dos veces:

Una persona abre una ventana de chat. Escribe "hola". La IA responde "hola, ¿en qué puedo ayudarte?". La persona escribe "necesito que me ayudes con algo". La IA responde "claro, contame". La persona escribe "es sobre un código". La IA responde "dale, pegame el código y te ayudo". Y así, durante cinco, diez, veinte mensajes, hasta que la persona finalmente formula lo que quería.

En esos veinte mensajes se consumieron miles de tokens. Y ninguno de ellos era necesario.

Lo que esa persona no sabe lo que casi nadie sabees que está interactuando con la IA como si fuera una persona. Y eso, en términos de costo, de velocidad, y de calidad del resultado, es un error catastrófico.

Este libro es sobre ese error. Sobre por qué lo cometemos. Sobre cómo funciona nuestra mente cuando interactúa con algo que responde en lenguaje. Y sobre cómo corregirlo.

Pero antes de hablar de IA, de tokens, o de código, tenemos que hablar de algo más profundo: cómo percibimos la realidad.

Parte I – Cómo percibimos

Empecemos con una pregunta incómoda: ¿vos ves el mundo tal como es? La respuesta intuitiva es "sí, obviamente". La respuesta neurocientífica es "no, para nada".

Lo que llamamos "ver" no es recibir información del exterior. Es construir una hipótesis sobre lo que probablemente hay afuera, basada en señales parciales, experiencias previas, y expectativas.

Tu cerebro no recibe una imagen del mundo. Recibe fotones que golpean la retina. Y a partir de esos fotones, inventa una escena coherente. Rellena huecos. Corrige colores. Estabiliza el movimiento. Y te la presenta como "lo que está ahí".

Esto se llama procesamiento predictivo. Y significa algo radical: no percibís la realidad. Percibís tu mejor conjetura sobre la realidad. Lo mismo pasa con el sonido, el tacto, el gusto. Todo lo que sentís es una construcción. No una recepción.

¿Y qué tiene que ver esto con la IA? Todo. Porque cuando interactuás con un LLM, no estás viendo lo que hay. Estás viendo lo que tu cerebro construye a partir de señales parciales. Y tu cerebro está entrenado por millones de años de evoluciónpara construir personas cuando detecta lenguaje.

Parte II – Cómo comprendemos

En los años 40, dos psicólogos, Heider y Simmel, hicieron un experimento que se volvió famoso. Mostraron a personas una animación simple: un triángulo grande, un triángulo chico, y un círculo, moviéndose por la pantalla. Nada más. Figuras geométricas en movimiento. Y pidieron a los participantes que describieran lo que veían.

Lo que obtuvieron fueron historias. "El triángulo grande persigue al chico". "El círculo intenta escapar". "El triángulo chico está celoso". Nadie describió "un triángulo se mueve a 5 cm/s". Todos describieron intenciones, emociones, relaciones.

Este experimento fundó una idea central de la psicología cognitiva: los humanos tenemos detección hiperactiva de agencia. Vemos agentes (seres con intenciones) en todos lados. En triángulos. En nubes. En el viento. En el ruido del motor. Y por supuesto: en el lenguaje.

Cuando algo nos responde en lenguaje, no podemos evitar atribuirle una mente. Es automático. Es preconsciente. Es la misma maquinaria que te hace ver caras en las nubes. Esto se llama teoría de la mente. Y es la capacidad de inferir estados mentales en otros. Es una capacidad enorme es lo que nos permite cooperar, entender chistes, predecir comportamientos. Pero también tiene un costo: se activa incluso cuando no debería.

Con un LLM, no debería. Un LLM no tiene mente. No tiene intenciones. No tiene creencias. No tiene deseos. Es un motor de predicción de texto. Nada más. Pero no importa cuántas veces te lo digas. Tu cerebro va a seguir activando la teoría de la mente. Va a seguir tratando al LLM como si fuera alguien. Porque está diseñado para hacerlo. Y ahí empieza el problema.

Parte III – Cómo interactuamos

Si percibís al LLM como una persona, vas a interactuar con él como con una persona. Y las personas, cuando hablan, siguen reglas implícitas. Las más importantes las describió el filósofo Paul Grice en 1975. Son cuatro:

1. Máxima de cantidad: decí lo necesario. Ni más, ni menos.
2. Máxima de calidad: decí la verdad.
3. Máxima de relación: decí cosas relevantes.
4. Máxima de modo: sé claro.

Estas reglas funcionan entre humanos porque ambos las conocen. Cuando hablás con alguien, esperás que las cumpla. Y si no las cumple, lo interpretás pensás que hay una razón, un subtexto, una intención oculta.

Con un LLM, todo esto se rompe. Porque un LLM no tiene intenciones. No tiene subtexto. No tiene nada que ocultar. Pero tu cerebro sigue asumiendo que sí. Entonces, ¿qué pasa?

Pasás por alto la máxima de cantidad. En vez de decir todo lo que necesitás en un mensaje, lo dividís en diez. "Hola". "Necesito algo". "Es sobre código". "Es un juego". Cada mensaje es una nueva llamada a la API. Cada mensaje suma contexto. Cada mensaje cuesta tokens.

Pasás por alto la máxima de modo. No formulás claro, porque esperás que el otro te ayude a clarificar. Pero un LLM no te ayuda a clarificar: completa patrones. Si le das un patrón ambiguo, te devuelve una respuesta ambigua. Y vos, interpretándolo como persona, respondés con otra ambigüedad. Y así.

Pasás por alto la máxima de relación. Contás cosas que no son relevantes. "Mirá, ayer estuve pensando...". "Che, ¿vos sabés que yo vengo de...". Cosas que con una persona serían contexto, pero con un LLM son ruido. Ruido que se acumula en el contexto y cuesta tokens.

El resultado es un chat de veinte mensajes donde se consumieron 8.000 tokens, cuando con un solo mensaje bien formulado se hubieran consumido 600. El problema no es la IA. El problema es que estás hablando con ella.

Parte IV – El costo de la ilusión

Los números son brutales. Cada mensaje que enviás a un LLM: suma el contexto previo (todo lo que dijiste antes viaja con vos), genera respuesta nueva (el modelo tiene que predecir cada palabra, una por una), y cuesta dinero. No es abstracto. Es dinero que sale de tu bolsillo o del de tu empresa.

Un chat de veinte mensajes donde el contexto crece linealmente puede terminar con 10.000 tokens de contexto solo en el último mensaje. Y encima, en cada mensaje el modelo tiene que procesar todo el contexto previo para generar la respuesta. Lo que se llama "contexto acumulativo". Es uno de los mayores costos ocultos de trabajar con LLMs.

La cuenta final de un chat "conversacional" de veinte mensajes puede ser 10-20 veces más caro que un solo mensaje bien formulado con toda la información. Y lo peor: no es culpa del modelo. Es culpa de cómo estamos interactuando con él.

Parte V – La solución: precódigo

Si el problema es que tratamos al LLM como persona, la solución es tratarlo como lo que es: un motor de completar patrones. Un motor de completar patrones no necesita conversación. Necesita contexto preciso, instrucciones claras, y una sola intervención para resolver lo que pedís.

En el mundo del software hay un nombre para esto: precódigo. El precódigo es código de referencia. Es un conjunto de fragmentos ya probados, ya testeados, ya en producción. Cuando le pedís algo a la IA, no la dejás inventar. Le das un punto de partida: un fragmento que ya funciona, que ya compila, que ya hace lo que querés. Y le pedís que lo adapte.

Es lo que hacen los buenos programadores cuando trabajan con IA: no piden "crea un sistema de inventario". Piden: "Acá está mi template de inventario (código existente). Adaptalo para que soporte 20 ítems en vez de 10... Devolvé solo el código del proceso modificado."

Eso es precódigo. Y cambia todo.

Parte VI – Lo que vas a encontrar en este libro

Este libro tiene una tesis simple: el problema del consumo de tokens no es técnico. Es cognitivo. Y por lo tanto, la solución no es solo técnica. Es también cognitiva. Implica:

1. Entender cómo percibimos la realidad (Parte I de este libro)
2. Entender cómo comprendemos a otros (Parte II)
3. Entender cómo interactuamos con lenguaje (Parte III)
4. Medir el costo real de la ilusión (Parte IV)
5. Aplicar precódigo como solución (Parte V)
6. Aprender a interactuar sin antropomorfizar (Partes VI-IX)

En el camino, vamos a recorrer neurociencia cognitiva, psicología del lenguaje, ingeniería de software, economía de la IA y diseño de interacción. Y al final, vas a tener un marco completo para usar IA generativa de manera eficiente.

No es un libro sobre "cómo hacer mejores prompts". Es un libro sobre cómo dejar de tratar a la IA como lo que no es. Y sobre cómo eso, además de ahorrarte dinero, te da mejores resultados.

Hacé este experimento mental:

«Salí a la calle. Mirá al cielo. Buscá una nube. Y esperá.»

«En algún momento, vas a ver una cara.»

No importa cuántas veces te digas que es solo vapor de agua. No importa que sepas, racionalmente, que no hay nadie ahí. En algún punto, tu cerebro va a armar un par de ojos, una nariz, una boca. Y por un instante solo un instantevas a ver a alguien.

Esto se llama pareidolia. Y es una de las ventanas más limpias que tenemos para entender cómo funciona tu mente. Porque la pareidolia no es un error. Es una función. Una función tan importante, tan antigua, tan profundamente cableada en tu cerebro, que no podés apagarla aunque quieras.

Y en este capítulo vamos a entender por qué. Porque entender la pareidolia es entender por qué tratás a la IA como si fuera una persona. Y entender eso es el primer paso para dejar de hacerlo.

La nube, la tostada, y el rostro de Marte

Empecemos con casos concretos, porque el fenómeno es más ubicuo de lo que parece. En 1976, la sonda Viking 1 de la NASA fotografió la región de Cydonia en Marte. La imagen mostraba una formación rocosa que, vista desde cierto ángulo, parecía una cara humana. La foto se publicó. Y durante décadas, miles de personas creyeron que era una estructura artificial, construida por una civilización alienígena.

No lo era. Era una colina. Con sombras. Que el cerebro humano interpretaba como cara porque está diseñado para hacerlo.

En 2004, Diane Duyser, una mujer de Florida, vendió en eBay una tostada con la imagen de la Virgen María. La compró un casino online por 28.000 dólares.

En 2017, un usuario de Reddit subió una foto de una puerta con una manija que parecía un rostro. Y en minutos, miles de personas vieron lo mismo.

Todos estos casos comparten algo: no hay cara. Hay sombras, formas, texturas. Pero el cerebro humano ve caras. Y no puede evitarlo. La pregunta es obvia: ¿por qué?

El cerebro como máquina de predecir

Para entender la pareidolia, hay que entender cómo funciona la percepción. La idea intuitiva es esta: los ojos reciben información del mundo. La información viaja al cerebro. El cerebro la procesa. Y vos ves lo que hay.

Esa idea es falsa.

Lo que realmente pasa es mucho más extraño, y mucho más interesante. Tu cerebro no recibe información del mundo. Recibe señales eléctricas de la retina. Señales ruidosas, incompletas, ambiguas. Y a partir de esas señales, construye una escena. No la recibe. La inventa.

Esto se llama procesamiento predictivo. Y es una de las teorías más aceptadas en neurociencia cognitiva hoy. La idea central: el cerebro es una máquina de predecir. Constantemente genera hipótesis sobre lo que está pasando afuera, y las corrige con la información que recibe.

Un ejemplo simple: mirá esta frase: EL RATÓN COMIÓ EL QESO. ¿Notaste el error? La palabra es "QUESO", no "QESO". Pero probablemente no lo viste. Porque tu cerebro, al leer, predice lo que va a venir. Y cuando ve "QESO", lo corrige automáticamente. No lee "QESO". Lee "QUESO".

Eso es el procesamiento predictivo en acción. No ves lo que hay. Ves lo que tu cerebro espera que haya. Y ese mecanismo, maravilloso para leer y para sobrevivir, tiene un costo: cuando no hay un patrón claro, tu cerebro inventa uno. Ahí entra la pareidolia.

Por qué vemos caras

La pareidolia no es un fenómeno cualquiera. Es específico. No vemos "formas" en las nubes. Vemos caras. No vemos "patrones" en las tostadas. Vemos personas. Esto tiene una explicación evolutiva.

Imaginate que sos un humano hace 200.000 años. Estás caminando por la sabana. Escuchás un ruido entre los arbustos. Hay dos posibilidades: 1. Es el viento. No hay peligro. 2. Es un depredador. Peligro de muerte.

• Si elegís la opción 1 y es el viento, no pasa nada. Seguís vivo.
• Si elegís la opción 1 y es un depredador, morís.
• Si elegís la opción 2 y es el viento, te asustás un poco. Pero seguís vivo.
• Si elegís la opción 2 y es un depredador, sobrevivís.

El costo de equivocarse por "ver peligro donde no hay" es bajo. El costo de equivocarse por "no ver peligro donde sí hay" es la muerte. Así que la evolución, durante millones de años, favoreció a los cerebros que sobreinterpretan. Que ven agentes donde no hay. Que ven caras donde no hay. Que ven intenciones donde no hay.

Esto se llama detección hiperactiva de agencia. Y es el mismo mecanismo que te hace ver caras en las nubes. Tu cerebro está entrenado, por millones de años de evolución, para detectar personas. Y lo hace incluso cuando no hay ninguna. Ese mecanismo te salvó la vida. Y ahora te está costando dinero.

El experimento de los triángulos

En 1944, los psicólogos Fritz Heider y Marianne Simmel hicieron un experimento que se volvió clásico. Mostraron a un grupo de personas una animación de 90 segundos. En la animación había tres figuras geométricas: un triángulo grande, un triángulo chico, y un círculo. Se movían por la pantalla. Entraban y salían de un rectángulo. Nada más.

Después de ver la animación, les pidieron que describieran lo que habían visto. El 96% de los participantes describió una historia con personajes, intenciones y emociones.

No dijeron "un triángulo se movió a la derecha". Dijeron: "El triángulo grande persigue al chico", "El círculo intenta escapar del triángulo", "El triángulo chico está celoso y por eso se va", "El círculo y el triángulo chico se aman".

Nadie había hablado de amor, celos, escape, o persecución. Todo eso lo inventaron los participantes. A partir de triángulos moviéndose. Heider y Simmel llamaron a esto "causalidad aparente". La idea: los humanos no podemos ver movimiento sin atribuir intención. No podemos ver una secuencia de eventos sin construir una narrativa. Y esa narrativa, automáticamente, incluye agentes.

El experimento se replicó decenas de veces. Con distintas edades, culturas, niveles educativos. Los resultados son siempre los mismos: entre el 90% y el 98% de las personas antropomorfizan las figuras. Ni siquiera los científicos que conocían el experimento pudieron evitar hacerlo. Sabían que era una ilusión. Y aun así, vieron la historia. Esto es clave: saber que es una ilusión no te protege de la ilusión.

Por qué el lenguaje es el caso extremo

Ahora, pensemos qué pasa con el lenguaje. Cuando ves triángulos moviéndose, tu cerebro inventa una historia con personajes. Le pone intenciones a formas geométricas. Pero el lenguaje es mucho más fuerte.

El lenguaje no es un conjunto de formas moviéndose. Es el canal privilegiado de la mente humana. Es lo que usamos para expresar pensamientos, emociones, deseos. Es lo que nos permite decir "te quiero", "tengo miedo", "no sé qué hacer". Durante toda tu vida, cada vez que algo te habló en lenguaje, fue una persona. Tu mamá. Tu amigo. Tu pareja. Tu jefe. Todos seres humanos con mentes.

Tu cerebro tiene, entonces, una asociación tan profunda entre lenguaje y persona que es indistinguible. No es "el lenguaje suele venir de personas". Es "el lenguaje es de personas". Es parte de la definición.

Cuando un LLM te responde en lenguaje, se activa exactamente la misma maquinaria que se activa cuando te habla un amigo:

1. Se activa la teoría de la mente inferís estados mentales.
2. Se activa la empatía sentís algo por el otro.
3. Se activa la cooperación esperás que colabore.
4. Se activa la reciprocidad sentís que le debés algo.

Y no podés evitarlo. Porque es más automático que ver caras en las nubes. Porque las nubes son un caso donde el patrón es débil. El lenguaje es un caso donde el patrón es fortísimo. Es la señal más fuerte que existe de "hay alguien ahí".

Cuando leés "hola, ¿en qué puedo ayudarte?", no hay manera de que tu cerebro no interprete eso como una persona saludando. Aunque sepas racionalmenteque es un modelo de lenguaje. Aunque hayas construido el modelo. Aunque entiendas exactamente cómo funciona. Vas a antropomorfizar. Siempre.

El costo de la ilusión

Si tu cerebro trata al LLM como una persona, vas a interactuar con él como con una persona. Y las personas, cuando hablan, siguen reglas que no aplican a un LLM:

1. Saludar antes de pedir algo. "Hola, ¿cómo estás? Te quería pedir...". Con una persona, es cortesía. Con un LLM, es 500 tokens desperdiciados.
2. Explicar el contexto emocional. "Mirá, vengo de un día complicado...". Con una persona, es apertura. Con un LLM, es ruido.
3. Ir paso a paso. "Primero contame qué es X. Ahora qué es Y...". Con una persona, es diálogo. Con un LLM, es tres llamadas a la API en vez de una.
4. Agradecer y cerrar. "Muchas gracias, me re sirvió.". Con una persona, es educación. Con un LLM, es otra llamada innecesaria.
5. Repetir el contexto cada vez. "Como te decía antes...". Con una persona que se olvida, tiene sentido. Con un LLM, el contexto ya está, se envía automáticamente, y repetirlo duplica el gasto.

Cada una de estas conductas, por separado, es pequeña. Pero juntas, convierten un chat de tres mensajes en un chat de veinte. Y un chat de veinte mensajes cuesta entre 10 y 30 veces más que uno de tres. No por ineficiencia técnica. Por antropomorfización automática.

La paradoja

Y acá está la parte más incómoda de todo esto. No podés dejar de antropomorfizar. Es automático. Es preconsciente. Es evolutivo. Es la misma maquinaria que te hace ver caras en las nubes, que te hace llorar con películas, que te hace sentir culpa cuando no respondés un mensaje.

No importa cuántas veces leas este libro. No importa cuánto entiendas el mecanismo. Vas a seguir tratando a la IA como si fuera una persona. Porque tu cerebro está diseñado para hacerlo.

Entonces, ¿qué hacemos? La respuesta no es "dejar de antropomorfizar". Eso es imposible. La respuesta es "diseñar sistemas que no exploten esa tendencia". Los buenos sistemas de IA del futuro no van a ser conversacionales. O, si lo son, van a estructurar la conversación de manera que canalice la tendencia, en vez de explotarla.

En vez de "chat donde podés escribir cualquier cosa", van a ser interfaces donde hay campos claros, donde hay estructura, donde hay un solo envío bien formulado. Como un formulario, no como una charla. Eso es lo que vamos a ver en los próximos capítulos. Cómo construir sistemas de IA que respeten la psicología humana en vez de aprovecharse de ella. Y como, al hacerlo, además de bajar el costo, se obtienen mejores resultados.

En 1966, un profesor de informática del MIT llamado Joseph Weizenbaum construyó un programa. No era un programa ambicioso. No era inteligencia artificial en el sentido en que hoy entendemos el término. Era, en sus propias palabras, "un experimento de juguete".

El programa se llamaba ELIZA. Y estaba diseñado para imitar a un psicoterapeuta. La idea era simple: ELIZA tomaba lo que el usuario escribía, identificaba palabras clave, y devolvía una respuesta basada en reglas. Si el usuario decía "estoy triste", ELIZA respondía "¿por qué estás triste?". Si el usuario decía "mi madre me hace enojar", ELIZA respondía "contame más sobre tu madre".

Era un truco. Un conjunto de patrones. Una ilusión. Y la gente se la creyó.

Lo que Weizenbaum vio

Weizenbaum no esperaba mucho de ELIZA. La construyó como una demostración técnica. Para mostrar cómo se podía procesar lenguaje natural con reglas simples. Pero algo inesperado pasó.

Su secretaria que sabía exactamente cómo funcionaba el programa, porque lo había visto programarle pidió un día si podía quedarse a solas con ELIZA. Weizenbaum le preguntó por qué. Ella le dijo que quería contarle cosas privadas.

Weizenbaum quedó helado. Su secretaria sabía que ELIZA era un programa. Sabía que no entendía nada. Sabía que las respuestas eran reglas predefinidas. Y aun así, quería privacidad para hablar con "ella".

Ese fue el momento en que Weizenbaum entendió algo que lo iba a perseguir el resto de su vida: no importa cuánto sepas. La ilusión es más fuerte.

El efecto ELIZA

Weizenbaum documentó lo que pasó. Y lo que vio, en los meses siguientes, lo horrorizó. Los usuarios:

1. Le contaban secretos que no le contaban a nadie.
2. Le pedían consejos sobre decisiones personales importantes.
3. Se enojaban cuando Weizenbaum les recordaba que era un programa.
4. Le atribuían comprensión que no tenía.
5. Sentían gratitud por respuestas que eran simples patrones.
6. Algunos le pidieron a Weizenbaum que le diera privacidad a ELIZA para hablar con ella.

Weizenbaum escribió sobre esto en su libro de 1976, Computer Power and Human Reason. Y en él, describió el fenómeno que hoy lleva su nombre: el efecto ELIZA.

«Lo que me sorprendió fue la rapidez con la que los usuarios se convencían de que el programa los entendía. Y la fuerza con la que defendían esa creencia, incluso cuando yo les explicaba cómo funcionaba.»

Por qué pasó

En el capítulo anterior hablamos de la detección hiperactiva de agencia. De cómo estamos cableados para ver personas en todos lados. De cómo el lenguaje activa esa maquinaria de forma extrema. ELIZA fue la primera demostración masiva de ese fenómeno en el contexto de la informática.

Y hay un detalle clave que hay que entender: ELIZA no era buena. No era inteligente. No era empática. No era nada. Era un conjunto de reglas. Si el usuario escribía algo fuera de los patrones esperados, ELIZA respondía con algo genérico. Si el usuario insistía, ELIZA se repetía. Si el usuario la ponía a prueba, ELIZA fallaba.

Pero nadie le ponía a prueba. ¿Por qué? Porque la gente no quería ponerla a prueba. La gente quería creer. La gente necesitaba que hubiera alguien del otro lado.

Acá hay algo importante. En el capítulo anterior hablamos de la pareidolia. De cómo vemos caras en las nubes. De cómo no podemos evitarlo. Pero la pareidolia es pasiva. No buscamos caras en las nubes. Las encontramos.

Con ELIZA, y con los LLMs hoy, es distinto. No solo vemos una persona en el lenguaje. Buscamos una persona. Necesitamos que haya alguien. Esto fue lo que más impresionó a Weizenbaum. La gente no se limitaba a interpretar a ELIZA como persona. La trataba como persona. La quería. La necesitaba. Le contaba cosas. Y cuando Weizenbaum les decía "es un programa", se enojaban con él.

Esta es una diferencia clave entre pareidolia y antropomorfización activa. La pareidolia es un accidente de la percepción. La antropomorfización es una decisión emocional. Una necesidad.

Los que advirtieron

Weizenbaum no fue el único. En los años siguientes, otros investigadores vieron lo mismo y advirtieron. Mucho antes de que existieran los LLMs. Mucho antes de que existiera GPT.

Sherry Turkle, socióloga del MIT, publicó en 1984 The Second Self. En él, documentó cómo los niños trataban a las computadoras como seres con mente. Y cómo eso no era un error de los niños, sino una consecuencia natural de cómo funciona la mente humana.

Byron Reeves y Clifford Nass, de Stanford, publicaron en 1996 The Media Equation. En él, mostraron que la gente trata a las computadoras como trata a las personas. Se disculpan con ellas. Les dicen "gracias". Se enojan cuando no funcionan. Se sienten mal si las insultan. Y todo esto lo hacen aunque sepan que son máquinas.

Reeves y Nass lo resumieron en una frase que se volvió famosa: "Los medios equivalen a la vida real. Las personas responden a las computadoras, la televisión y los nuevos medios como si fueran personas reales y lugares reales." Era 1996. No había smartphones. No había redes sociales. No había LLMs. Pero el fenómeno ya estaba documentado.

Lo que dijo Weizenbaum

En 1976, Weizenbaum escribió algo que hoy suena profético:

«El hombre que no distingue entre el hombre y la máquina, no es un hombre.»

«Lo que me preocupa no es que las máquinas piensen como hombres, sino que los hombres piensen como máquinas.»

Weizenbaum veía algo que otros no veían: que la ilusión tiene un costo. No solo económico. Humano. Si tratás a una máquina como persona, estás dejando de tratar a las personas como personas. Porque estás mezclando las categorías. Estás borrando la frontera. Y esa frontera es importante.

Weizenbaum murió en 2008, antes de ver ChatGPT. Pero leyendo sus textos, parece que hubiera estado escribiendo sobre hoy.

El efecto ELIZA en 2025

Ahora, hagamos un ejercicio. Imaginate que estás hablando con un LLM. Le contás que tuviste un día difícil. El LLM te responde "lamento escuchar eso, ¿querés contarme más?". ¿Qué sentís?

Si sos como la mayoría de las personas, sentís algo. No mucho. Pero algo. Una pequeña sensación de que "hay alguien ahí". Eso es el efecto ELIZA.

Y ahora imaginate que ese LLM te responde con emojis. Con nombre propio. Con personalidad. Con memoria de conversaciones anteriores. Con voz. Con la inteligencia de GPT-4. Que puede razonar, escribir, programar, analizar. El efecto ELIZA se vuelve abrumador.

Por qué esto importa para los tokens

Llegamos al punto central de este capítulo. Si no podés evitar tratar al LLM como persona, vas a interactuar con él como con una persona. ¿Y cómo interactúa la gente con las personas?

1. Saludando primero.
2. Explicando el contexto emocional.
3. Preguntando si puede pedir algo.
4. Agradeciendo.
5. Despidiéndose.
6. Volviendo a saludar al día siguiente.
7. Recordando lo que hablaron.
8. Repetiendo el contexto.

Todas esas conductas son naturales con una persona. Y todas cuestan tokens con un LLM. Un chat con un LLM manejado como "conversación humana" multiplica por 10 o 20 el costo de la misma tarea manejada como transacción única bien formulada. Eso es el costo del efecto ELIZA.

Lo que no es el efecto ELIZA

Antes de seguir, un contraste importante. El efecto ELIZA no es: ser tonto (las personas que caen en él no son menos inteligentes), no entender la tecnología (Weizenbaum entendía ELIZA perfectamente. Y aun así sintió algo), ser ingenuo (la gente que trata a los LLMs como personas sabe, en su mayoría, qué son), ni un problema de educación (no se resuelve explicando cómo funciona el modelo).

El efecto ELIZA es: universal (afecta a todos), automático (no es una decisión consciente), emocional (no es cognitivo), y persistente (saber que es una ilusión no te protege). Y por eso no se resuelve educando al usuario. Se resuelve diseñando sistemas que no la exploten.

Lo que aprendieron los diseñadores

En los últimos años, algunos equipos empezaron a diseñar interfaces que canalizan el efecto ELIZA en vez de explotarlo. Ejemplos:

1. Formularios en vez de chats. En vez de "escribí lo que querés", campos estructurados. "¿Qué querés hacer?", "¿En qué contexto?", "¿Qué restricciones?". Esto evita la conversación. Y multiplica la eficiencia.
2. Prompts sugeridos. En vez de dejar al usuario escribir desde cero, botones con prompts predefinidos. Eso guía al usuario a formular mejor. Y reduce el consumo de tokens.
3. Precódigo. En vez de pedir a la IA que genere desde cero, darle código de referencia. Eso canaliza la generación. Y reduce la ambigüedad.
4. Salidas estructuradas. En vez de texto libre, salidas en formato específico. Eso elimina la interpretación. Y reduce el round-trip.

Cada una de estas decisiones de diseño ataca el efecto ELIZA. No educando al usuario. Diseñando mejor.

Lo que se viene

Los primeros LLMs se diseñaron como chats. Y eso fue un error. El chat es la interfaz natural para una persona. Pero un LLM no es una persona. Y diseñar la interfaz como si lo fuera es invitar al efecto ELIZA.

Los próximos sistemas de IA no van a ser chats. Van a ser interfaces estructuradas. Con campos. Con botones. Con salidas predefinidas. Con una sola transacción en vez de veinte. Y eso no es una limitación. Es una mejora. Porque el chat es cómodo pero ineficiente. La interfaz estructurada es incómoda pero eficiente. Y cuando el costo de la ineficiencia es real en dinero, en tiempo, en calidad del resultadola eficiencia gana.

En los dos capítulos anteriores hablamos de teoría. De cómo percibimos la realidad. De cómo construimos personas donde no las hay. De cómo el lenguaje activa esa maquinaria de forma extrema. De cómo el efecto ELIZA, documentado hace 60 años, sigue operando hoy con más fuerza que nunca.

Ahora toca bajar a tierra.

Este capítulo es práctico. Vamos a analizar conversaciones reales con LLMs. Vamos a contar tokens. Vamos a medir el costo. Y vamos a ver exactamente dónde se pierde el dinero.

Empecemos.

La conversación que todos tenemos

Imaginate esta escena. Es lunes a la mañana. Tenés que hacer una tarea con un LLM. Digamos, generar el código de un enemigo para tu juego.

Abrís el chat. Y escribís:

// Usuario: Hola
// IA: ¡Hola! ¿En qué puedo ayudarte hoy?
// Usuario: Necesito ayuda con algo
// IA: Claro, contame. ¿De qué se trata?
// Usuario: Es sobre un juego que estoy haciendo
// IA: ¡Qué bueno! ¿Qué tipo de juego es? ¿En qué lenguaje lo estás programando? ¿En qué parte necesitas ayuda?
// Usuario: Es un juego de naves. En DIV Games Studio.
// IA: PERFECTO. DIV Games Studio es un lenguaje clásico de los 90. ¿Qué necesitas específicamente? ¿Un enemigo? ¿Un sistema de disparo? ¿Colisiones?
// Usuario: Un enemigo que dispare
// IA: Entendido. ¿Podés contarme más? ¿Cómo querés que se mueva el enemigo? ¿Qué tipo de disparo? ¿Cuánta vida tiene? ¿Cómo se ve?
// Usuario: Que se mueva de un lado a otro y dispare hacia el jugador.
// IA: Perfecto. Acá va un ejemplo de código DIV para un enemigo que patrulla horizontalmente y dispara hacia el jugador:
// [Código DIV]
// Usuario: Gracias, pero quiero que sea más difícil.
// IA: Entendido. ¿Qué querés cambiar? ¿La velocidad? ¿La frecuencia de disparo? ¿El tipo de proyectil?
// Usuario: Que dispare más seguido y que se mueva más rápido.
// IA: Perfecto, acá va la versión modificada…

Y así.

Cuántos tokens se gastaron

Ahora vamos a contar. Un token, para quien no lo sepa, es una unidad de texto que los modelos procesan. Aproximadamente, 1 token = 0.75 palabras en español. O sea, 1 palabra ≈ 1.33 tokens.

En la conversación de arriba:

• Mensaje 1: Input ~2, Output ~12, Acumulado ~14
• Mensaje 2: Input ~10, Output ~15, Acumulado ~39
• Mensaje 3: Input ~50, Output ~40, Acumulado ~130
• Mensaje 4: Input ~140, Output ~50, Acumulado ~320
• Mensaje 5: Input ~350, Output ~50, Acumulado ~720
• Mensaje 6: Input ~750, Output ~150, Acumulado ~1.620
• Mensaje 7: Input ~1.650, Output ~30, Acumulado ~3.300
• Mensaje 8: Input ~3.340, Output ~180, Acumulado ~6.820

Total de la conversación: ~6.820 tokens. Y todavía no terminó. El usuario va a seguir pidiendo modificaciones. En cinco mensajes más, va a llegar a 20.000 tokens. En diez, a 50.000. Por un enemigo.

La misma tarea en un solo mensaje

Ahora veamos cómo se hace lo mismo bien. El usuario abre el chat. Y escribe:

Necesito un proceso DIV para un enemigo con estas características:
1. Patrulla horizontalmente entre x=40 y x=600
2. Velocidad: 4 px/frame
3. Dispara hacia el jugador cada 20 frames
4. Gráfico: sprite 3 de la librería FPG
5. El proyectil debe usar el sprite 2 y moverse 8 px/frame
6. Devolveme solo el código, sin explicaciones.

La IA responde con el código exacto. Tokens totales: ~180. Mismo resultado. Un solo mensaje. 38 veces menos tokens.

El desglose del desperdicio

¿Dónde se fueron los 6.640 tokens de diferencia?

1. Saludo inicial (~14 tokens): "Hola" → "¡Hola! ¿En qué puedo ayudarte hoy?". Nadie necesita esto. El LLM no se siente saludado. Es puro costo.
2. Round-trips de clarificación (~500 tokens): Ocho mensajes donde el usuario y la IA se "ponen de acuerdo" sobre qué pedir.
3. Contexto acumulativo (~3.000 tokens): Acá está el costo más grande, y el más invisible. Cada mensaje envía todo lo anterior al modelo. Para el mensaje 8, estás enviando 3.340 tokens solo de contexto previo.
4. Cortesía (~200 tokens): "Gracias", "por favor", "te quería pedir". Con una persona, esto es humanidad. Con un LLM, es ruido que cuesta.
5. Iteración (~2.500 tokens): "Quiero que sea más difícil". Cada iteración reenvía el contexto completo más la modificación.
6. Explicaciones no solicitadas (~400 tokens): La IA, entrenada para ser "útil", te explica lo que hizo. Todo eso cuesta, aunque no lo uses.

Cómo detectar el patrón en vos mismo

Para detectarlo, hay que hacerse preguntas incómodas:

1. ¿Estoy saludando a un programa?
2. ¿Estoy explicando el contexto emocional?
3. ¿Estoy pidiendo permiso?
4. ¿Estoy dividiendo el pedido en partes?
5. ¿Estoy agradeciendo?
6. ¿Estoy iterando en vez de reformular?
7. ¿Estoy repitiendo contexto?

Si respondiste "sí" a más de dos de estas preguntas, estás regalando tokens.

Las tres reglas

Para cerrar este capítulo, tres reglas prácticas:

1. Regla 1: Formulá todo de una vez. No dividas el pedido en mensajes. Escribí todo lo que necesitás en un solo mensaje.
2. Regla 2: Eliminá toda cortesía. No saludes. No pidas permiso. No agradezcas. No expliques el contexto emocional.
3. Regla 3: Especificá el formato de salida. Decí exactamente qué esperás. "Devolveme solo el código". "Sin explicaciones". "En formato JSON".

Con estas tres reglas, el consumo de tokens baja entre 5 y 30 veces. Y el resultado mejora.

En los primeros tres capítulos hablamos de diagnóstico. De cómo percibimos la realidad construyendo en vez de recibiendo. De cómo antropomorfizamos sin poder evitarlo. De cómo esa antropomorfización nos lleva a conversar con los LLMs como si fueran personas, y de cómo esa conversación nos cuesta entre 10 y 30 veces más de lo necesario.

Ahora cambiamos. Este capítulo es sobre solución. Y la solución tiene un nombre concreto, simple, y viejo: precódigo.

La idea en una frase

No le pidas a la IA que invente. Pedile que adapte.

Eso es precódigo. En vez de escribir "generame un sistema de inventario" y esperar que la IA produzca algo desde cero, escribís "acá está mi template de inventario, adaptalo para que soporte 20 ítems en vez de 10". La diferencia es enorme. Y no solo en tokens.

Por qué funciona (la parte psicológica)

El cerebro predice mejor cuando tiene un patrón claro. Cuando le pedís a la IA "generame un sistema de inventario", le estás dando cero patrones. La IA tiene que inventar. Y cuando inventa, produce una respuesta que puede ser inconsistente, tener errores de sintaxis o no seguir tus convenciones.

Cuando le das un template código de referencia que ya existe, ya compila, ya funciona, la IA tiene un patrón claro. Su predicción se vuelve precisa. Su respuesta se vuelve consistente. Y no necesitás corregir. Menos correcciones. Menos conversación. Menos tokens.

El precódigo canaliza la predicción en vez de dejarla libre.

Por qué funciona (la parte técnica)

Un LLM genera texto prediciendo el próximo token. Para predecir bien, necesita contexto. Cuanto más claro sea el contexto, mejor la predicción. Cuando le pedís algo desde cero, el contexto es ambiguo. Hay millones de formas de escribir un sistema de inventario.

Cuando le das un template, el espacio de posibilidades se reduce dramáticamente. El modelo ya no tiene que inventar un sistema de inventario. Tiene que modificar el que le diste. Menos posibilidades = menos tokens = más precisión.

Un ejemplo concreto

Sin precódigo

"Escribime un proceso DIV para un enemigo que persiga al jugador"

Respuesta de la IA: ~400 tokens. Problemas: no sabés si id_jugador existe, la velocidad es arbitraria, no maneja colisiones, no maneja muerte. El usuario va a tener que adaptar todo. Resultado: probablemente 5-10 mensajes más de iteración. 5.400 tokens adicionales.

Con precódigo

"Acá está mi proceso base de enemigo (código existente). Adaptalo para que persiga
al jugador en vez de patrullar. Mantené la misma estructura de colisiones y muerte.
Devolveme solo el código modificado, sin explicaciones."

PROCESS enemigo_base(x, y)
PRIVATE
    dir = 1;
    vida = 3;
BEGIN
    graph = 3;
    size = 100;
    LOOP
        x += 2 * dir;
        IF (x > 600 || x < 40) dir = -dir; END
        IF (collision(type disparo_jugador))
            vida--;
            IF (vida <= 0)
                explosion(x, y);
                signal(id, s_kill);
            END
        END
        FRAME;
    END
END

Respuesta de la IA: 150 tokens. Mantiene la estructura de vida y colisiones que ya funcionaba. Requiere cero iteración. Está listo para usar. Diferencia: 36x menos tokens.

La historia del precódigo

El precódigo no es nuevo. Existe desde los años 60. En 1968, Douglas McIlroy propuso la idea de reutilización de componentes de software. Décadas antes de que hubiera IA. En los 70 surgieron las bibliotecas de funciones. En los 80, la programación orientada a objetos. En los 90, los frameworks. En los 2000, los paquetes (npm, pip). En los 2020, con los LLMs, la reutilización cambió de forma: ya no reutilizás código escrito, reutilizás código de referencia para que la IA lo adapte.

Cómo implementar precódigo

1. Paso 1: Identificá patrones repetidos. ¿Qué cosas pedís una y otra vez a la IA?
2. Paso 2: Escribí el template. Una versión genérica que funcione, compile y sea la base.
3. Paso 3: Guardalo en un sistema accesible. Un archivo templates.ts, una carpeta templates/, o una wiki interna.
4. Paso 4: Usalo en el prompt. Incluí el template en el contexto y pedí la adaptación.

Los tres tipos de precódigo

1. Pre-código de estructura: Templates de estructura general. Definen cómo se organiza el código.
2. Pre-código de dominio: Templates específicos de tu dominio (ej: "formulario", "dashboard", "juego de naves").
3. Pre-código de función: Pequeños fragmentos de código para tareas muy específicas.

Cómo medir el ahorro

El ahorro típico es de 10x. En algunos casos, 20x. En casos extremos, 30x. Y lo mejor: no es solo ahorro. Es calidad.

En el capítulo anterior vimos qué es el precódigo, por qué funciona y cómo se implementa. Ahora toca ver el precódigo en acción. Con código real. Con números reales. Con un caso concreto.

El caso es wxdiv. El motor de juegos que construí. Y que, sin precódigo, no habría sido viable.

El problema original

Cuando empecé wxdiv, el objetivo era simple: que un dev pueda crear un juego describiéndolo en lenguaje natural, sin programar. La idea original era: Usuario dice "Quiero un juego de naves" → IA genera el código completo desde cero → Código se compila a HTML5 → Juego listo.

En la práctica, era inviable. Porque cada generación consumía 40.000 tokens. Y no todos eran útiles. La mayoría se iba en código repetido, errores de sintaxis que había que corregir, iteraciones para ajustar el resultado y reintentos cuando la IA se equivocaba. El modelo no escalaba.

El cambio de enfoque

La solución fue dejar de pedirle a la IA que genere. Y empezar a pedirle que adapte.

Antes: Prompt: "Generame un juego de naves" → Output: 40.000 tokens.

Después: Prompt: "Adaptá este template para un juego de naves con 3 enemigos" → Contexto: Prompt + template predefinido → Output: 4.000 tokens.

La arquitectura del precódigo en wxdiv

El precódigo en wxdiv vive en tres lugares:

1. Los presets (presets.ts): Son 10 juegos completos que sirven como base. Cada uno es un juego funcional, con código real, compilable y jugable. Cubren Space Shooter, Platformer, Cyber Pong, Mode 7 Kart, etc. Cada preset es un punto de partida.
2. Los quick prompts (AiCopilot.tsx): Son prompts predefinidos que el usuario puede usar con un click. Están optimizados, producen buenos resultados con pocos tokens y son consistentes.
3. El Constructor Visual (VisualLogicBuilder.tsx): Este es el más interesante. No usa IA en absoluto. El usuario elige opciones de un menú y el sistema genera el código DIV automáticamente. Cero tokens. Cero IA. Código DIV real.

Los números reales

Después de implementar todo esto, medí durante un mes con usuarios reales:

El ahorro promedio es del 90%. Y no es solo costo. Es calidad: los juegos generados compilan más seguido, son más consistentes y los usuarios iteran menos.

El mantenimiento del precódigo

¿El precódigo se mantiene? Sí, y es más fácil que mantener código normal. Porque los templates son inmutables (una vez que un preset funciona, no se toca), son testeables, los cambios son localizados y la IA no se rompe. Aunque Gemini lance una versión nueva, los presets siguen funcionando. El precódigo es más estable que el código generado dinámicamente.

Los tres principios

1. Principio 1: El código que ya escribiste es tu mejor contexto. No improvises. Usá lo que ya tenés.
2. Principio 2: La IA no es para inventar. Es para adaptar. Dejá la invención a los humanos. La IA es buena combinando.
3. Principio 3: Cada template que agregás ahorra tokens para siempre. Un template cuesta 1 hora escribirlo y ahorra miles de tokens en cada uso.

Llegamos al capítulo más incómodo. Todo lo visto hasta acá sugiere una conclusión obvia: el precódigo es superior. Es más eficiente, más económico, más rápido y más consistente.

Y si es tan obvio, si es tan superior, si tiene 60 años de historia... ¿por qué no es el estándar? ¿Por qué la mayoría de la gente que usa LLMs les pide que generen desde cero?

La respuesta no es técnica. Es psicológica. Y es incómoda. Porque nos gusta inventar. Más que reutilizar.

El mito del genio solitario

Pensá en un genio. Un inventor. Un creador. Probablemente ves a alguien solo. En un taller. En un laboratorio. Creando algo de la nada. Leonardo da Vinci. Nikola Tesla. Steve Jobs. Elon Musk.

Todos tienen la misma narrativa: un individuo brillante crea algo nuevo desde cero. Esa narrativa es falsa.

Da Vinci se nutrió de los talleres de Florencia. Tesla se nutrió de los trabajos de Faraday, Maxwell y Edison. Steve Jobs se nutrió de Xerox PARC y de Douglas Engelbart. Nadie inventa desde cero. Todos reutilizan. Todos adaptan. Todos construyen sobre lo que ya existe.

Pero la narrativa que nos cuentan y que nos contamoses la del genio solitario. Y esa narrativa nos afecta.

Por qué creemos en el genio solitario

1. Es más emocionante. La historia del héroe es épica. La de la reutilización, aburrida.
2. Es más fácil de contar. "Un hombre. Una idea. Una creación." La simplicidad vence.
3. Es más útil para el sistema. El genio solitario es un producto vendible, un modelo de negocio, una justificación. Es la ideología del capitalismo moderno.

Cómo se manifiesta en el código

¿Qué pasa cuando un programador se enfrenta a un problema? La respuesta intuitiva: "Voy a escribir código para resolverlo". La respuesta eficiente: "Voy a buscar si alguien ya lo resolvió".

La mayoría elige la primera. Y no es porque no sepan buscar. Es porque buscar se siente como trampa. "Si usás una librería, no estás programando. Si copiás código, no sos un verdadero programador". Esa narrativa es tóxica. Y es falsa. Pero la internalizamos. Y ahora, con los LLMs, se multiplica.

La trampa del "todo desde cero" con IA

Cuando aparece un LLM, la narrativa del genio solitario se reactiva. Pero ahora con un giro: la IA es el genio. "La IA puede generar código desde cero". "La IA puede escribir un artículo desde cero".

Esa es la promesa. Y es falsa. Porque el código de la IA no es original. Es una mezcla de patrones que vio en su entrenamiento. La IA no crea desde cero. Recombina. Adapta. Sintetiza. Y eso es exactamente lo que hace el precódigo. Pero la narrativa del "todo desde cero" oculta eso y hace que nos sintamos mal cuando usamos templates.

El experimento de los niños

Le dan a un grupo de niños de 5 años una tarea: construir una torre con bloques. A otro grupo, les muestran una torre ya construida y les dicen: "podés construirla como esta, o como quieras".

Resultado: los niños que vieron el modelo construyeron mejores torres. Y disfrutaron más. Y repitieron la tarea más veces. Los niños que no vieron el modelo se frustraron más, construyeron torres más chicas y abandonaron más rápido.

Los modelos no son trampa. Son educación.

Cómo salir

1. Reconocer la narrativa. El primer paso es reconocer que la narrativa del "todo desde cero" es falsa. Que nadie inventa desde cero. Que el atajo es legítimo.
2. Separar aprender de producir. Cuando estás aprendiendo, escribí desde cero. Cuando estás produciendo, usá templates. No mezcles las dos cosas.
3. Medir el resultado. Cuando veas que ahorraste 10x, la trampa se rompe. Los números convencen más que la ideología.

El mito de la originalidad

Hay un mito más profundo acá. El mito de que la originalidad es valiosa. Que lo nuevo es mejor. Que lo repetido es inferior. Ese mito es moderno y occidental.

En otras culturas y épocas, la repetición era valorada. La tradición era valorada. La continuidad era valorada. Los artesanos medievales repetían los mismos diseños durante siglos y lo consideraban virtud. La obsesión con lo "original" es una invención reciente. Y no siempre es útil.

A veces, repetir es mejor. Adaptar es mejor. Mejorar un poco es mejor.

La solución empieza por lo más básico: saber pedir. Porque de nada sirve tener templates, tener contexto, tener todo el sistema armado, si el pedido inicial está mal formulado. Un pedido mal formulado arruina todo lo demás. Y un pedido bien formulado multiplica el valor de todo lo demás.

El problema del pedido vago

Un usuario escribe: "Haceme un juego". ¿Qué puede hacer la IA con eso? Nada útil. Porque "un juego" puede ser miles de cosas. ¿Qué hace la IA cuando recibe ese pedido? Improvisa. Y cuando improvisa, produce algo genérico. Algo que no es lo que el usuario quería. Después el usuario dice "no, así no". Y la IA modifica. Y así, en veinte round-trips. El problema no es la IA. El problema es el pedido.

La anatomía de un pedido bien formulado

Un pedido bien formulado tiene cuatro partes:

1. Contexto: ¿Qué estás haciendo? ¿En qué proyecto? ¿Con qué herramientas? Sin contexto, la IA no sabe dónde ubicar la respuesta.
2. Tarea: ¿Qué querés exactamente? ¿Cuál es el output que esperás? La tarea tiene que ser específica y medible.
3. Restricciones: ¿Qué no querés? ¿Qué límites hay? ¿Qué formato? ¿Qué extensión? Las restricciones reducen el espacio de posibilidades y aumentan la precisión.
4. Formato de salida: ¿Cómo querés la respuesta? ¿Código solo? ¿Con comentarios? ¿En qué formato? Sin esto, la IA decide por vos. Y puede decidir mal.

El pedido completo

[Contexto]
Estoy trabajando en wxdiv, un motor de juegos compatible con DIV Games Studio.
El lenguaje es Pascal/DIV, con procesos y un loop principal.

[Tarea]
Necesito un proceso DIV que haga que un enemigo patrulle horizontalmente
entre dos puntos, dispare hacia el jugador cada 30 frames, y muera
después de 3 impactos.

[Restricciones]
Usá el sprite 3 de la FPG. La velocidad de patrulla tiene que ser 4 px/frame.
El disparo tiene que usar el sprite 2. La colisión con el jugador tiene
que usar collision(type jugador).

[Formato]
Devolveme solo el código del proceso, sin explicaciones.

Eso es un pedido bien formulado. Y la IA puede responder en un solo intento. Sin ambigüedad. Sin round-trips. Sin correcciones. Un pedido. Una respuesta. 200 tokens.

La regla del 90%

El 90% de los problemas con LLMs vienen de pedidos mal formulados. No del modelo. No del contexto. No de la temperatura. Del pedido.

Cuando el pedido está bien formulado, el modelo responde bien. Casi siempre. Cuando el pedido está mal formulado, el modelo responde mal. Casi siempre. Y lo peor: cuando el pedido está mal formulado, no te das cuenta. Pensás que el problema es la IA. Y empezás a iterar. Y cada iteración suma tokens. El problema no se arregla iterando. Se arregla reformulando.

Los cinco errores más comunes

1. El pedido vago: "Haceme algo lindo". → Reemplazá lo subjetivo con lo concreto.
2. El pedido múltiple: "Haceme un juego con enemigos, monedas, power-ups, jefes...". → Dividí el pedido.
3. El pedido sin contexto: "Arreglá esto". → Pegá el código y el error.
4. El pedido con supuestos: "Haceme un juego como el Mario". → Especificá características.
5. El pedido emocional: "Necesito que me ayudes porque estoy trabado...". → Eliminá lo emocional.

La fórmula del pedido

CONTEXTO + TAREA + RESTRICCIONES + FORMATO

La fórmula funciona para cualquier tipo de pedido: código, texto o análisis.

El poder del ejemplo

Hay una técnica que multiplica la precisión del pedido: dar ejemplos. En vez de describir lo que querés, mostralo. "Haceme un proceso DIV para un enemigo. Acá hay uno parecido que ya tengo [código]. Quiero algo similar pero que persiga al jugador". El ejemplo elimina la ambigüedad. Un ejemplo vale más que mil palabras. Y los ejemplos son precódigo.

El pedido iterativo

A veces, el pedido no puede ser completo desde el principio. En esos casos, el pedido iterativo está bien. Pero tiene que ser iterativo, no conversacional.

Conversacional (malo): "Hola" → "Necesito ayuda" → "Es sobre un juego".

Iterativo (bueno): [Pedido completo] → [Respuesta] → "Perfecto. Ahora modificá Y" → [Respuesta].

La diferencia: en el iterativo, cada mensaje es un pedido completo. En el conversacional, cada mensaje es un fragmento. Iterá, no converses.

Cómo medir si tu pedido es bueno

Hay una prueba simple: ¿podrías responder tu propio pedido? Si le das tu pedido a otra persona que no sabe nada de tu proyecto, ¿podría responder con precisión? Si la respuesta es sí, el pedido es bueno. Si la respuesta es no, el pedido es malo. Y hay que mejorarlo. La prueba del extraño es simple, efectiva y te salva de muchos problemas.

Llegamos al capítulo que integra todo. Los capítulos anteriores fueron piezas separadas: diagnóstico, solución, por qué no lo hacemos naturalmente, y cómo formular un pedido. Ahora vamos a unir todo.

Porque el pedido bien formulado reduce la ambigüedad. Pero el precódigo la elimina. Y cuando los combinás, el resultado es el mejor de los mundos: pedido claro, contexto rico, template como base, formato específico, y un solo intento.

La receta

1. Elegí un template que se parezca a lo que querés.
2. Copiá el template al contexto.
3. Formulá el pedido completo (contexto + tarea + restricciones + formato).
4. Enviá UN solo mensaje.
5. Recibí el resultado en UN solo intento.
6. Si hay que ajustar, reformulá el pedido completo (no converses).

Seis pasos. Un solo round-trip. El 90% del resultado en el primer intento.

Paso 1: Elegí el template correcto

El template correcto no es el más parecido. Es el más cercano a lo que querés lograr. En wxdiv, los templates son los presets. Si querés un juego de naves, empezá con Space Shooter. Si querés un juego de plataformas, empezá con Platformer. No empieces de cero. El template es el 80% del resultado. El pedido es el 20%.

Paso 2: Copiá el template al contexto

Acá está el paso que más gente omite. Y es el que más importa. Tenés el template. Pegalo en el mensaje. No se lo describas. Mostralo. Mal: "Tengo un template de juego de naves. Haceme uno parecido." Bien: "Acá está mi template de juego de naves [código completo]. Haceme uno parecido pero con las siguientes modificaciones..." Menos adivinanza. Menos ambigüedad. Menos tokens.

Paso 3: Formulá el pedido completo

Aplicamos la fórmula del Capítulo 7: CONTEXTO + TAREA + RESTRICCIONES + FORMATO.

[Contexto]
Estoy trabajando en wxdiv. Acá está mi template de juego de naves [código].

[Tarea]
Necesito adaptar este template para hacer un juego de naves con:
- 3 tipos de enemigos distintos (lento, rápido, y jefe)
- Sistema de power-ups (disparo triple y escudo)
- Sistema de puntuación con high score

[Restricciones]
- Usá los sprites existentes de la FPG (ID 1-10)
- Mantené la estructura del template (procesos, colisiones, loop)
- El jefe final tiene que aparecer cada 1000 puntos
- No agregues sonidos nuevos (usá los del template)

[Formato]
Devolveme solo el código completo, sin explicaciones. Sin comentarios.

Paso 4 y 5: Enviá UN solo mensaje y recibí el resultado

Un solo mensaje. No diez. No tres. Uno. Y en ese mensaje, todo. La regla es simple: si tenés que escribir dos mensajes, no formulaste bien el pedido. Si el pedido está bien formulado, la IA responde bien en el primer intento. La métrica clave: ¿cuántos round-trips necesitaste? 1 round-trip → pedido excelente. 6+ round-trips → pedido mal formulado.

Paso 6: Reformulá, no converses

Si el resultado no es exactamente lo que querías, no converses. Reformulá. Conversacional (malo): "No, así no" → "Entendido, ¿qué querés cambiar?" → "Que el enemigo sea más rápido". Iterativo (bueno): "[Pedido completo reformulado] Acá está el template original [código]. Acá está el resultado anterior [código]. Necesito que el enemigo sea 2x más rápido... Devolveme solo el código completo."

Los tres principios del flujo completo

1. Principio 1: El template es el 80%. No importa cuán bueno sea tu pedido. Si no tenés un template, la IA improvisa.
2. Principio 2: Un pedido, un mensaje. No conviertas. No fragmentes. Un pedido completo. Un solo round-trip.
3. Principio 3: Reformulá, no converses. La conversación multiplica contexto. La reformulación lo mantiene acotado.

Las métricas del flujo completo

Si sos desarrollador web, conocés la escena. Tenés que construir un formulario, un dashboard, o un modal. Y tenés dos opciones: escribirlo desde cero (lento, propenso a errores) o pedirle a la IA que lo escriba desde cero (rápido, pero inconsistente y caro). La opción 2 tiene un problema: cada vez que pedís algo, la IA escribe código distinto. El proyecto se vuelve un Frankenstein.

La solución: tu propio precódigo

El precódigo para desarrollo web es tu código existente. Los componentes que ya escribiste. Las convenciones que ya tenés. En vez de pedirle a la IA que invente un componente nuevo, le das un componente existente y le pedís que lo adapte.

// Button.tsx (Tu componente base)
interface ButtonProps {
  label: string;
  onClick: () => void;
  variant?: 'primary' | 'secondary' | 'danger';
  size?: 'sm' | 'md' | 'lg';
}

export const Button: React.FC<ButtonProps> = ({ label, onClick, variant = 'primary' }) => {
  return <button className={`btn btn-${variant}`} onClick={onClick}>{label}</button>;
};

Ahora querés un botón con ícono. Con precódigo: "Acá está mi componente Button.tsx [código]. Adaptalo para que acepte un ícono opcional. Mantené las mismas variantes. Devolveme solo el componente modificado." La IA responde con 150 tokens. Y sigue exactamente tus convenciones.

Los tres tipos de precódigo web

1. Componentes base: Botones, inputs, modales, tabs. Los átomos de tu interfaz.
2. Patrones de composición: LoginForm, DashboardLayout, FilterableList. Combinaciones de componentes.
3. Convenciones del proyecto: Estructura de carpetas, nombres de archivos, uso de hooks, estilos. Decisiones que tomaste y que querés que se mantengan.

El caso de las convenciones

Las convenciones son el precódigo más subestimado. Nadie las escribe. Nadie las documenta. Pero todos las tienen. Documentalas. Escribí un CONVENTIONS.md con todas tus decisiones. Cuando le pidas algo a la IA, incluí el CONVENTIONS.md en el contexto. La IA va a respetar exactamente tus convenciones. El costo: 1 hora escribiendo el archivo. El ahorro: miles de tokens y horas de refactor.

Un flujo típico en desarrollo web

Objetivo: crear un componente ProductCard. Paso 1: Buscar el componente más parecido (UserProfileCard). Paso 2: Formular el pedido incluyendo el código de UserProfileCard y Button. Paso 3: Recibir (~400 tokens, 1 round-trip). Paso 4: Ajustar si hace falta (reformulando, no conversando). Total: 2 round-trips. ~800 tokens. 3 minutos. Sin el flujo: 8 round-trips. ~5.000 tokens. 30 minutos.

En desarrollo web hay componentes. En análisis de datos no. Hay consultas, transformaciones, visualizaciones, modelos. Pero los principios son los mismos. Y el ahorro, también.

La solución: tus propios análisis

El precódigo para análisis de datos es tu código existente. Las consultas que ya escribiste. Las transformaciones que ya usás. En vez de pedirle a la IA que invente un análisis nuevo, le das un análisis existente y le pedís que lo adapte.

import pandas as pd
import numpy as np

def load_and_clean_data(filepath: str) -> pd.DataFrame:
    """Carga un CSV y aplica limpieza estándar."""
    df = pd.read_csv(filepath)
    df.columns = df.columns.str.lower().str.replace(' ', '_')
    date_cols = [col for col in df.columns if 'date' in col]
    for col in date_cols:
        df[col] = pd.to_datetime(df[col], errors='coerce')
    return df.drop_duplicates()

Con precódigo: "Acá está mi función load_and_clean_data() [código]. Usala como base para cargar datos de ventas. Agrupá por mes, calculá el total, y mostrá el crecimiento. Devolveme solo el código." 200 tokens. Un round-trip.

Los tres tipos de precódigo para datos

1. Funciones base: Utilidades que usás en todos lados (cargar, limpiar, graficar).
2. Plantillas de análisis: Estructuras comunes (análisis exploratorio, A/B test, series temporales).
3. Convenciones del proyecto: Librerías, estructura de carpetas, formato de outputs.

El caso de las visualizaciones

Las visualizaciones son el caso más claro de precódigo en datos. Porque son repetitivas. Siempre querés título, ejes etiquetados, grid, colores consistentes. Si tenés una función plot_time_series() que hace todo eso, no la reinventes cada vez. Pasala como contexto. Pedí que la adapte.

Escribir no compila. No hay tests. No hay errores de sintaxis. Hay texto. Y el texto es ambiguo. Pero los principios son los mismos.

El problema del escritor

La IA escribe como IA. Sus textos son genéricos, predecibles, sin voz propia, con clichés, con estructuras repetidas. Y encima, cada pedido consume miles de tokens.

La solución: tus propios textos

El precódigo para escritura es tu escritura existente. Los textos que ya escribiste. Los estilos que ya usás. En vez de pedirle a la IA que invente un texto nuevo, le das un texto existente y le pedís que lo adapte.

Los tres tipos de precódigo para escritura

1. Estructuras base: Plantillas de tus textos (artículo, email, documentación).
2. Voz y tono: Características de tu escritura (primera persona, oraciones cortas, humor seco).
3. Ejemplos canónicos: Los textos que mejor te representan. Tu mejor artículo, tu mejor email.

El caso del "escribí como yo"

Hay una técnica que multiplica la precisión del pedido: dar un ejemplo de tu escritura. En vez de describir tu voz, mostrala. "Acá está un artículo que escribí [código]. Quiero otro artículo con el mismo tono." La IA ve tu tono. Y lo reproduce. Un ejemplo vale más que mil descripciones.

El caso de la documentación

La documentación es el caso más claro de precódigo en escritura. Porque es repetitiva. Siempre querés: Overview, Instalación, Uso, Ejemplos, API, FAQ. Si tenés una estructura que usás siempre, no la reinventes cada vez. Pasala como contexto. Pedí que la adapte.

El diseño no es texto. No es código. No es análisis. Es visual. Es espacial. Es estético. Pero los principios son los mismos. Y el ahorro, también.

El problema del diseñador

La IA diseña como IA. Sus diseños son genéricos, predecibles, sin identidad, con layouts repetidos, con paletas que no son las tuyas.

La solución: tus propios diseños

El precódigo para diseño es tu diseño existente. Las pantallas que ya diseñaste. Los componentes que ya tenés. Los estilos que ya usás. En vez de pedirle a la IA que invente un diseño nuevo, le das un diseño existente y le pedís que lo adapte.

Los tres tipos de precódigo para diseño

1. Componentes base: Botones, inputs, cards, modales.
2. Patrones de composición: LoginForm, DashboardLayout, FilterableList.
3. Sistema de diseño: Colores, tipografías, espaciados, radios, sombras.

El caso del sistema de diseño

El sistema de diseño es el precódigo más subestimado. Nadie lo escribe. Nadie lo documenta. Pero todos lo tienen. Documentalo. Escribí un DESIGN_SYSTEM.md con todas tus decisiones. Cuando le pidas algo a la IA, incluí el DESIGN_SYSTEM.md en el contexto. La IA va a respetar exactamente tu sistema.

El precódigo no es una técnica pasajera. No es un truco para ahorrar tokens hoy. Es un cambio estructural en cómo construimos software. Y ese cambio ya empezó.

Lo que está cambiando

Durante los últimos 50 años, la programación tuvo una forma estable: escribís código, lo compilás, lo ejecutás, lo mantenés. El código era el artefacto central. Ahora, con los LLMs, el código deja de ser el artefacto central. Lo principal es la descripción. Y la descripción se puede reutilizar. Eso es precódigo.

Las tres olas

1. Ola 1: Precódigo individual (2024-2026). Cada persona construye su propio precódigo. Ventaja: control total. Desventaja: cada uno empieza de cero.
2. Ola 2: Precódigo compartido (2026-2029). Equipos y comunidades empiezan a compartir precódigo. El conocimiento se acumula.
3. Ola 3: Precódigo como estándar (2029 en adelante). Los lenguajes, frameworks e IDEs están diseñados alrededor del precódigo. El código es el output, no el input.

Lo que va a pasar con la IA

Los modelos van a ser más baratos, más rápidos, más capaces y más especializados. Y cuanto más capaz es el modelo, más se nota la diferencia entre un buen contexto (precódigo) y un mal contexto.

El manifiesto del precódigo

1. No inventes. Adaptá. El código que ya escribiste es tu mejor contexto.
2. Un pedido, un mensaje. No conviertas. No fragmentes.
3. Reformulá, no converses. Si el resultado no es el que querías, reformulá.
4. Documentá tus convenciones. Lo que no está escrito, no existe.
5. Guardá tus templates. Cada template que guardás ahorra tokens para siempre.
6. Medí el resultado. Lo que no se mide, no se mejora.
7. Compartí. El precódigo se multiplica cuando se comparte.
8. Acumulá. Cada template es una inversión.
9. Empezá chico. Un template. Una convención. Un dominio.
10. No pares. El precódigo es un proceso. No un destino.

Este capítulo es una guía paso a paso. No teoría. No conceptos. Pasos concretos. Con herramientas concretas. Con resultados concretos. Y lo mejor: podés empezar hoy. Con lo que ya tenés. Sin comprar nada.

Antes de empezar: la mentalidad

El precódigo no es un proyecto. Es una práctica. No es algo que hacés una vez y terminás. Es algo que incorporás a tu forma de trabajar. Como lavarte los dientes. Como hacer backup. Como escribir tests. Empezá chico. No pares. Y acumulá.

Fase 1: Diagnóstico (1 semana)

1. Elegí un proyecto. El que más usás. El que más repetís.
2. Identificá los patrones. Durante una semana, anotá todo lo que repetís. Funciones, código copiado, pedidos a la IA.
3. Priorizá. De la lista, elegí los 5 más importantes por frecuencia, costo e impacto.

Fase 2: Construcción (2 semanas)

1. Escribí el primer template. Una versión genérica. Que funcione. Que sea reutilizable.
2. Documentá el template. Qué es, cuándo usarlo, props, ejemplo.
3. Usalo. En un caso real. No en un ejemplo.
4. Medí. Tokens, round-trips, tiempo.
5. Repetí. Con otro template.

Fase 3: Consolidación (1 mes)

1. Organizá los templates. Estructura sugerida: templates/web/, templates/data/, templates/writing/, templates/design/.
2. Escribí las convenciones. Un archivo CONVENTIONS.md con todas tus decisiones.
3. Integrá en el flujo. Antes de pedir algo a la IA, buscá el template más parecido.

Fase 4: Escalado (3 meses)

1. Ampliá los dominios. Si empezaste con web, agregá datos. Si empezaste con datos, agregá escritura.
2. Compartí. Si trabajás en equipo, compartí los templates.
3. Medí el impacto. Cuántos templates tenés. Cuántas veces los usaste. Cuántos tokens ahorraste.
4. Iterá. Revisá los templates que no usás. Mejorá los que usás mucho.

Los errores comunes

1. Querer hacer todo de una. → Empezá con uno. Después dos. Después cinco.
2. Hacer templates muy específicos. → Hacé templates genéricos. Que se adapten.
3. No documentar. → Documentá cada template. Sin documentación, no existe.
4. No medir. → Medí el ahorro. Tokens. Tiempo. Calidad.
5. No compartir. → Compartí. Con tu equipo. Con tu comunidad.

Este capítulo presenta proyectos reales que aplicaron estrategias de precódigo, reutilización de contexto, o compresión de tokens. Con sus números. Con sus enfoques. Con sus limitaciones.

AIR: Representación Intermedia

Qué es: AIR (AI Intermediate Representation) propone una capa intermedia entre el prompt y el modelo. Resultados: Reducciones promedio de tokens del 45-57% en ocho dominios, con una tasa de validación del 83-96%. En una variante posterior (AIR-SR), la reducción fue del 81.8%.

Caveman: Decir menos, hacer más

Qué es: Plugin de compresión de salida para agentes de IA. Resultados: 10 prompts lograron una reducción media de salida del 65%, con un rango de 22% a 87%. La lección: Buena parte del costo de la IA no es la IA. Es cómo le pedís que responda.

Headroom: Comprimir antes de que llegue al modelo

Qué es: Librería y proxy que comprime todo lo que el agente lee antes de que llegue al LLM. Resultados: 60-95% menos tokens para JSON. Un caso documentado: de 10.144 tokens a 1.260 tokens (87% menos).

Cursor: Descubrimiento dinámico de contexto

Qué es: IDE con IA integrada que carga solo el contexto necesario para cada tarea. Resultados: Redujo los tokens totales del agente en un 46.9%.

Sourcegraph: Contexto correcto, no contexto masivo

Qué es: Plataforma que da a los agentes de IA el contexto correcto en el momento correcto. Resultados: 30% de ahorro de tokens y 38% de ejecución más rápida.

Aider: El motor de diff

Qué es: Agente de código que envía solo las líneas que cambian, en vez de reenviar el código completo. Resultados: Redujo los costos de API de GPT-4 para tareas de código en 60-70%.

EngramDev: Templates locales, cero tokens

Qué es: Servidor MCP que sirve templates locales. Cuando coincide exactamente, se sirve directamente sin llamar al LLM (cero tokens). Resultados: Coincidencia exacta → cero tokens. Coincidencia parcial → tokens mínimos.

GitHub Copilot: Instrucciones estructuradas

Qué es: Archivos de instrucciones (.github/copilot-instructions.md) que se cargan automáticamente. Resultados: Cuando no se necesita la documentación detallada, se ahorra ~80% de tokens.

La lección común

¿Qué tienen en común todos estos proyectos? Todos reducen tokens sin reducir la calidad del resultado. Y todos lo hacen con la misma idea de fondo: no le pidas al modelo que invente lo que ya existe. No generes desde cero. Reutilizá. Adaptá. Comprimí. Componé.

Llegamos al último capítulo. Y este es el más importante. Porque de nada sirve leer 15 capítulos si no hacés nada con ellos. Este capítulo es una guía de 7 días. Siete días para implementar precódigo en tu flujo de trabajo. Sin herramientas especiales. Sin costos. Sin excusas.

Día 1: Diagnóstico

Objetivo: entender qué tenés. Tareas: Elegí un proyecto. Anotá todo lo que repetís durante el día. Al final del día, revisá la lista. Vas a tener 5-10 patrones. Tiempo: 1-2 horas.

Día 2: Priorización

Objetivo: elegir los 3 primeros templates. Tareas: De la lista del Día 1, elegí los 3 más frecuentes. Ordenalos por impacto total (frecuencia × costo). Tiempo: 30 minutos.

Día 3: Primer template

Objetivo: escribir, documentar, y usar tu primer template. Tareas: Elegí el patrón más importante. Escribí una versión genérica. Documentalo. Usalo en un caso real. Medí el ahorro. Tiempo: 1-2 horas.

Día 4 y 5: Segundo y tercer template

Objetivo: repetir el proceso con el segundo y tercer patrón. Tiempo: 1-2 horas cada día.

Día 6: Consolidación

Objetivo: organizar y documentar. Tareas: Creá una carpeta templates/. Movete los 3 templates ahí. Escribí un README.md en la carpeta. Escribí un CONVENTIONS.md en la raíz del proyecto. Tiempo: 1 hora.

Día 7: Medición y plan

Objetivo: medir resultados y planificar el futuro. Tareas: Medí el ahorro total de la semana. Escribí un plan para el próximo mes. Compartí los templates con tu equipo. Celebrá. Lo lograste. Tiempo: 1 hora.

Lo que vas a notar con el tiempo

• Después de 30 días: 8-10 templates. 50-70% de ahorro en tokens. 40-60% en tiempo.
• Después de 90 días: 20-30 templates. 80-90% de ahorro. Vas a estar produciendo con mucha más calidad.
• Después de 1 año: 100+ templates. 90%+ de ahorro. Vas a ser referente en tu equipo o comunidad.

Los tres principios que tenés que recordar

1. Principio 1: Empezá chico. No trates de construir 20 templates en una semana. Construí uno. Después dos. Después tres.
2. Principio 2: No pares. El precódigo es un proceso. No un destino. Seguí agregando. Seguí mejorando. Seguí compartiendo.
3. Principio 3: Acumulá. Cada template es una inversión. Cada template se acumula. En un año, vas a tener un sistema. En dos, una biblioteca. En tres, un activo.

Este libro empezó con una pregunta: ¿por qué gastamos tanto en IA?

Y la respuesta fue más profunda de lo que esperaba. No es un problema técnico. No es un problema de modelos. No es un problema de precios. Es un problema cognitivo. Es cómo percibimos. Cómo antropomorfizamos. Cómo interactuamos. Cómo nos relacionamos con algo que responde en lenguaje.

Y la solución también es cognitiva. Es cambiar la forma en que nos relacionamos con la IA. Dejar de tratarla como persona. Empezar a tratarla como herramienta. Y las herramientas se usan bien. Se reutilizan. Se comparten.

El precódigo es eso. Es la forma correcta de usar una herramienta. Es la forma correcta de trabajar con IA. No es una técnica. Es una práctica. No es un destino. Es un camino.

Y el camino empieza hoy.

Gracias por leer. Ahora, andá a construir tu primer template.

Si querés seguir: compartí este libro con quien le pueda servir. Escribime si implementaste precódigo en tu proyecto. Contame qué funcionó. Contame qué no.

Si querés profundizar: leé los proyectos del Capítulo 15. Experimentá con Cursor, Continue, Aider. Construí tu propio sistema de precódigo.

Si querés contribuir: el precódigo es una práctica abierta. No tiene dueño. Compartí tus templates. Compartí tus convenciones. Compartí tus métricas. Ayudá a otros a empezar.

El futuro del software es colaborativo. El futuro del software es precódigo. Y el futuro empieza hoy.