El erizo y el zorro que fueron a promptear

Una fábula sobre prompts, engineering y dos animales viejísimos.

1. Érase una vez

Érase una vez, hace unos veintiséis siglos, un poeta griego llamado Arquíloco que escribió una línea casi sin querer. Una línea corta. De esas que parecen no decir nada y luego, con los años, lo dicen todo:

«El zorro sabe muchas cosas, pero el erizo sabe una cosa grande.»

Arquíloco no sabía lo que había hecho. Pasaron veinticinco siglos. Llegó Isaiah Berlin, en 1953, tomó la frase y la convirtió en un ensayo célebre sobre Tolstói: hay pensadores erizo y pensadores zorro. Hay quien apuesta toda su vida a una sola idea enorme, y hay quien colecciona ideas pequeñas y se mueve entre ellas como entre matorrales.

Y aquí estamos, en 2025, hablando de inteligencia artificial. Y resulta que el viejo bicho del erizo y el viejo bicho del zorro han vuelto. Esta vez vienen disfrazados. Uno se hace llamar prompt. El otro se hace llamar prompt engineering.

Las cosas cambian poco en 2500 años. Solo los disfraces.

2. El erizo

El erizo no se mueve mucho. No le hace falta.

El erizo, cuando se topa con un modelo de lenguaje, escribe una línea. A veces dos. A veces una sola palabra colocada en el sitio exacto. Y el modelo, que estaba dando vueltas como un perro buscando dónde echarse, de pronto entiende. Responde lo que tenía que responder. La conversación se ordena.

Eso es un prompt. Eso, en su forma más pura, es lo que podríamos llamar un erizo de código: una línea que lo cambia todo. No hay pipeline, no hay arquitectura, no hay infraestructura. Hay una persona, una caja de texto, y una intuición sobre cómo pedir.

El erizo sabe una cosa grande: que el lenguaje, bien afilado, basta.

El erizo escribe «actúa como si fueras un editor escéptico» y el texto cambia de tono. Escribe «explícalo como si yo tuviera diez años» y la respuesta se vuelve transparente. Escribe «primero piensa paso a paso» y de repente el modelo deja de improvisar. Tres frases. Tres mundos distintos.

Hay quien dice que esto no es una habilidad. Que cualquiera puede hacerlo. Que basta con escribir lo que uno quiere. Y es cierto a medias, como casi todo lo que se dice con seguridad. Porque escribir lo que uno quiere es exactamente lo que casi nadie sabe hacer.

El erizo calla. Escribe la línea. Y se va.

3. El zorro

El zorro, en cambio, no escribe una línea. El zorro construye un sistema.

El zorro mira el problema y ve cinco capas: está el modelo (¿cuál?, ¿con qué temperatura?), está el contexto (¿de dónde sacamos los documentos relevantes?, ¿cómo los recortamos?), está la cadena (¿una llamada o varias?, ¿en qué orden?), está la evaluación (¿cómo sabemos si funciona?, ¿qué pasa cuando falla?) y está el coste (¿cuánto vale cada respuesta?, ¿se puede hacer más barato?).

El zorro habla de RAG, de embeddings, de chunking, de fallbacks. El zorro sabe que el prompt es una pieza. Importante, sí. Pero una pieza entre muchas.

Donde el erizo ve una conversación, el zorro ve una tubería. Donde el erizo escribe «responde en formato JSON», el zorro escribe un validador que, si el JSON viene mal, reintenta con un prompt distinto, registra el error, alerta al equipo y sigue. El erizo se queda en la frase. El zorro construye la red de seguridad debajo de la frase.

Esto es prompt engineering en su forma adulta. No es escribir bien una instrucción. Es diseñar todo el aparato alrededor de la instrucción para que, cuando el modelo se equivoque —y se va a equivocar—, el sistema entero no se caiga.

Cuando algo falla —y algo falla siempre—, el zorro no reescribe el prompt a ciegas. Primero pregunta: ¿falla en qué casos? ¿En todos, o solo cuando el usuario escribe en mayúsculas, o cuando el documento tiene más de tres mil tokens, o cuando aparece una fecha ambigua? El zorro abre los logs. Mira veinte ejemplos. Encuentra el patrón. A veces el patrón es que el modelo confunde dos campos parecidos. A veces es que el contexto recuperado por el RAG no contiene la respuesta y el modelo, educado, se la inventa. El zorro no culpa al modelo. El zorro busca la grieta.

Y para no buscarla siempre a oscuras, el zorro construye un eval set. Cincuenta casos. Cien. Doscientos. Casos fáciles, casos difíciles, casos tramposos, casos que ya rompieron el sistema una vez y a los que ahora se vigila como a un reincidente. Cada vez que alguien toca el prompt —una coma, una palabra, un ejemplo nuevo—, el eval set se ejecuta entero. Y aparece un número. Un número incómodo, casi siempre, porque mejorar un caso suele empeorar otro.

El zorro mide. Mide precisión, mide latencia, mide coste por mil llamadas, mide cuántas veces el modelo devuelve algo parseable y cuántas devuelve un párrafo improvisado donde debería haber un JSON. Para lo que no se puede medir con una regla —el tono, la claridad, la utilidad—, el zorro pone a otro modelo a juzgar, con su propia rúbrica, y luego audita al juez. Sí: el zorro hasta evalúa al evaluador.

Y cuando el modelo base se actualiza —porque se actualiza, sin avisar, y un martes cualquiera el prompt que funcionaba el lunes empieza a comportarse raro—, el zorro tiene listo su regression test. Pasa el eval set. Compara. Detecta las cinco respuestas que ahora están peor. Ajusta. Vuelve a pasar. El erizo, en ese martes, está mirando la pantalla sin entender qué pasó. El zorro ya sabe qué pasó, por qué pasó, y cuánto va a costar arreglarlo.

El zorro mira alrededor. Siempre mira alrededor.

4. La fricción

Y aquí empieza el conflicto. Porque las empresas, casi todas, quieren contratar al erizo.

Lo dicen así, con estas palabras o parecidas: «Necesitamos a alguien que sepa hacer prompts. Que nos dé el prompt mágico para resumir reuniones. Para escribir correos. Para clasificar tickets.» Y ofrecen un sueldo. A veces alto. A veces casi cómico, porque la idea que tienen del oficio es la idea del erizo: una línea, una solución, listo.

Lo que necesitan, sin embargo, es al zorro.

Porque el prompt mágico no existe. O existe durante tres semanas, hasta que el modelo se actualiza, o hasta que aparece un caso límite que nadie había previsto, o hasta que el volumen de uso multiplica los costes y de pronto la línea bonita que funcionaba en el demo se vuelve insostenible en producción. Entonces hace falta el zorro. Hace falta alguien que sepa por qué el modelo se desvía, qué cambiar, qué medir, qué dejar igual.

Pero el zorro es más caro. Tarda más en explicar lo que hace. Su trabajo se ve menos. El erizo enseña una línea de texto y todos aplauden. El zorro enseña un diagrama con quince cajas y nadie entiende nada.

Así que las empresas contratan al erizo, esperan resultados de zorro, y cuando no llegan, concluyen que «esto del prompting está sobrevalorado». Hay incluso ensayos enteros sobre este desencanto. Y otros, del mismo autor, defendiendo lo contrario seis meses después. Ya sabes de qué hablo: el campo está tan vivo que cambia de opinión sobre sí mismo cada dos estaciones.

Hay quien dice, en los pasillos del oficio, que prompt engineer como puesto de trabajo quizá ni siquiera sobreviva la década. Que es un oficio de transición. Que los modelos entienden cada vez mejor lo que uno quiere y hacen falta menos artesanía para arrancarles una buena respuesta. Dentro de unos años nadie contratará a un «ingeniero de prompts» igual que hoy nadie contrata a un «ingeniero de búsquedas en Google». Puede que tengan razón, en la parte que les toca.

Pero el zorro, que ha visto pasar lenguajes, frameworks y modas, sonríe un poco al oírlo. Porque el zorro también sabe que el erizo envejece. Sabe que la línea mágica de hoy es el comando olvidado de mañana. Lo que casi nunca envejece es saber medir, saber depurar, saber diseñar el sistema alrededor de la pieza que falla. Si el oficio cambia de nombre en cinco años, el zorro cambiará de tarjeta de visita y seguirá haciendo, en el fondo, lo mismo de siempre: mirar alrededor.

La fricción es vieja. El que sabe una cosa grande siempre parece más vendible que el que sabe moverse entre muchas. Y luego, cuando hay que mover algo de verdad, falta el zorro.

5. Lo que Berlin no dijo

Berlin escribió su ensayo sobre Tolstói. Y la tesis era esta: Tolstói era un zorro que se creía erizo. Sabía mil cosas, veía mil matices, pero se moría por encontrar una sola gran ley de la historia. Y por eso, dice Berlin, vivió en tensión consigo mismo toda su vida.

Décadas después, un investigador llamado Philip Tetlock pasó veinte años estudiando a expertos que hacían predicciones políticas. Quería saber quién acierta más: ¿el que apuesta a una idea grande o el que combina varias pequeñas? La respuesta, resumida sin matices, fue: ganan los zorros. Los erizos aciertan menos. Pero los erizos, ojo, salen más en televisión. Convencen más. Su narrativa es más limpia.

Berlin no dijo —porque no podía decirlo, no era su tema— algo que la práctica del prompting nos enseña con bastante claridad: el oficio bueno suele ser mestizo.

Quien trabaja con modelos de lenguaje todos los días termina siendo erizo por naturaleza y zorro por necesidad. Erizo en el momento de escribir la línea: ahí hay que ser preciso, frontal, casi poético. Zorro en todo lo demás: en pensar el sistema, en medir, en prever el fallo, en negociar con el equipo de producto, en explicar al cliente por qué el modelo a veces miente.

El que solo es erizo se queda atrapado en demos bonitas que no escalan. El que solo es zorro construye sistemas elegantes que generan respuestas mediocres porque nadie se molestó en pulir las instrucciones. Hace falta el mestizaje.

Y aquí viene lo interesante: el mestizaje no es promedio. No es ser medio erizo y medio zorro. Es saber cuándo ser uno y cuándo ser el otro. Es tener, dentro, dos animales que se turnan.

El erizo aparece a las tres de la mañana, cuando uno lleva dos horas intentando que el modelo haga algo y de pronto, en un destello, encuentra la palabra. La palabra que faltaba. Y todo encaja.

El zorro aparece al día siguiente, cuando hay que explicar al equipo por qué esa palabra funciona, en qué casos podría fallar, qué métricas vamos a poner para detectarlo, y cómo encaja en el sistema completo.

Sin el erizo, no hay magia. Sin el zorro, la magia no dura.

6. Moralina

Toda fábula necesita su moralina. Aquí va la nuestra.

Los oficios nuevos siempre empiezan con la misma discusión, y siempre la discusión es estéril: ¿esto es una habilidad real o no lo es? ¿se aprende o se nace? ¿es magia o es ingeniería? Y mientras la discusión se desarrolla en conferencias y en blogs, hay gente trabajando que ya descubrió, sin teorizar mucho, que la pregunta está mal planteada.

El prompt y el engineering no son dos profesiones distintas peleándose por el mismo nombre. Son dos animales que viven en la misma persona. Uno escribe la línea. El otro construye el mundo alrededor de la línea. Si separas a los dos, mueren los dos.

Arquíloco escribió que el zorro sabe muchas cosas y el erizo una sola grande. Lo que no escribió —quizá porque era poeta y los poetas dejan los cabos sueltos a propósito— es lo que pasa cuando los dos viven juntos.

Pasa esto: que la línea mínima, el erizo de código, solo brilla cuando hay un sistema entero que la sostiene. Y que el sistema entero solo sirve para algo cuando, en su corazón, hay una línea bien escrita. Lo demás es ruido: ofertas de trabajo confusas, debates en internet, conferencias con título de moda.

Aquí ya me entiendes.

El erizo calla. El zorro mira alrededor. Y el prompt engineer, ese animal nuevo de nombre incómodo, hace las dos cosas a la vez.

Berlin, I. (1953/2013). The Hedgehog and the Fox. Princeton University Press. Arquíloco, fragmento 201 West.