Normalmente me incomoda el hábito común de intentar encontrar análogos del viejo mundo para fenómenos del nuevo mundo. Así que ten paciencia conmigo mientras cometo exactamente ese pecado: permíteme exponer el argumento de por qué al prompting deberíamos llamarlo diseño de prompts y compararlo con el diseño web.

Veo el prompting como comunicarme con una persona con tiempo limitado. Aunque las técnicas específicas de LLM son sin duda útiles (sobre todo chain-of-thought), he descubierto que una de las mejores formas de mejorar el rendimiento es simplemente tener instrucciones extremadamente claras y de alta calidad, de forma similar a cómo la claridad y la concisión ayudan a los humanos reales a entender mejor también.

Prompting-como-comunicación-clara hace que el prompting suene como escribir. Sin embargo, la mayor parte del prompting que hago es paramétrico: tengo varias variables de entrada y necesito adaptar mi prompt dinámicamente a ellas.

Por lo tanto, prompting-como-comunicación-clara-con-entrada-dinámica se siente como la caracterización más precisa.

¿En qué otro campo se trata de comunicar con claridad a partir de entrada dinámica? En el diseño web.

Enumeremos todas las similitudes. Tanto el prompting como el diseño web:

1. requieren claridad y tienen la comunicación como objetivo principal;

2. necesitan responder a contenido dinámico, a diferencia de la escritura o la maquetación de una revista; y

3. necesitan adaptar su contenido a diferentes tamaños: tamaños de pantalla en el diseño web, ventanas de contexto en el prompting.

Por mi experiencia tanto haciendo prompting como diseño web, también he descubierto que tengo preferencias de desarrollador similares en ambas áreas:

1. Mirar el prompt real es súper importante, al igual que mirar el sitio web renderizado es súper importante. No puedo diseñar un sitio web si tengo que simular el proceso de renderizado de HTML y CSS en mi mente. Del mismo modo, es realmente difícil escribir prompts buenos y claros sin ver la salida renderizada de un prompt con todas las variables de entrada rellenadas.

2. Por ejemplo, el prompt "Hi ${username} ${message}" puede parecer razonable, hasta que lo renderizas y te das cuenta de que el nombre de usuario se confunde con el mensaje.

3. Los componentes componibles son útiles tanto en prompting como en diseño web.

4. Declarativo es mejor que imperativo en ambos casos. Es realmente difícil cambiar un sitio web donde todos los elementos HTML se crean con llamadas a document.createElement. De manera similar, leer y cambiar un prompt que consiste en una larga secuencia de str += "..." se vuelve fácilmente inmanejable.

5. En ambos, a veces quiero lograr la “perfección de píxel”. Cuando hago prompting con modelos menos capaces (GPT-3.5 y peores), quiero asegurarme de no tener saltos de línea innecesarios ni otros tipos de formato imperfecto, y cuando diseño un sitio web, a veces cada píxel importa.

Para agentes de LLM, es posible llevar la analogía aún más lejos: el prompting de agentes puede verse como construir un sitio web interactivo para los agentes, donde pueden “hacer clic en botones” llamando a funciones, y donde el prompt se vuelve a renderizar en respuesta a una llamada de función, igual que un sitio web se vuelve a renderizar en respuesta a un clic de botón.

Por supuesto, hay diferencias entre el diseño de prompts y el diseño web:

1. El prompting trata solo con texto (¡por ahora!).

2. La caché es diferente: para los agentes en particular, quieres asegurarte de que tus nuevos renderizados sean baratos cambiando solo las partes posteriores del prompt. Hay un paralelismo rebuscado aquí con la web (quieres optimizar la caché de tu sitio), pero creo que en el fondo es un desafío bastante diferente.

Aun así, las similitudes me han convencido de que al prompting deberíamos llamarlo diseño de prompts, no prompt engineering. Escribir un prompt se siente exactamente como diseñar un sitio web, y por lo tanto debería nombrarse de la misma manera también.

La perspectiva de diseño de prompts me inspiró a crear Priompt, una librería de diseño de prompts basada en JSX, similar a React.

#Priompt v0.1: una primera aproximación a una biblioteca de diseño de prompts

Priompt es un primer intento de crear una biblioteca de diseño de prompts inspirada en los principios del diseño web moderno. Lo estamos usando internamente en Cursor y nos gusta mucho.

Creo que probablemente no sea del todo correcto en todas sus abstracciones, pero al menos estoy convencido de que JSX es una forma mucho más ergonómica de escribir prompts que las plantillas de cadenas de texto. Incluso el simple hecho de poder comentar fácilmente partes de tu prompt hace que el ciclo de iteración sea mucho más rápido.

Priompt también incluye un sitio web de vista previa (armado muy apresuradamente), donde puedes previsualizar tu prompt con datos reales. Al desarrollar tu aplicación, puedes registrar las props serializadas que recibe un componente en cada solicitud. Luego, cuando veas un comportamiento inesperado, puedes ir a la vista previa de Priompt, mirar el prompt exacto y cambiar el código fuente para que el prompt se actualice con las mismas props que la solicitud real. Hemos descubierto que esto facilita iterar sobre los prompts.

Si lo pruebas, ¡por favor cuéntame qué piensas! Me encantaría ver más ideas en la misma línea, o simplemente que me digan que estoy completamente equivocado y que el diseño de prompts es una tontería :).

#Salvedades

Los modelos cambian rápido, y las técnicas de prompting también tienen que hacerlo. Dicho esto, creo que hay algunas salvedades respecto a la caracterización del diseño de prompts:

1. Los diseños pixel-perfect no son importantes para GPT-4, y probablemente quedarán obsoletos para GPT-4.5 o modelos mejores.

2. La restricción de la ventana de contexto puede desaparecer, si extrapolamos la tendencia reciente de modelos con contexto largo. Aunque no estoy convencido de esto.

3. OpenAI parece avanzar hacia ofrecer cada vez menos control sobre el prompt a los desarrolladores; es posible que en un año ya no exista algo llamado prompt, y que la llamada a la API simplemente nos pida los datos en bruto más una instrucción. Esta tendencia hacia menos control comenzó con el formato de chat y ha continuado con la llamada a funciones anunciada recientemente.

4. Es posible que el caché sea uno de los aspectos más importantes del prompting, en cuyo caso empieza a sonar un poco más a ingeniería que a diseño.

5. Quizá el diseño de prompts sea demasiado de bajo nivel y deba delegarse a un framework o compilador de más alto nivel (por ejemplo, langchain). Creo que esto puede ser cierto, pero dado lo rápido que cambian los LLM, personalmente prefiero estar lo más cerca posible del modelo en bruto.

#Nota final obligatoria

...porque me encantaría trabajar contigo: En Cursor, estamos creando Cursor, un editor de código con prioridad en la IA. Si te entusiasma el diseño de prompts, los LLM para programar o crear productos extraordinarios, escríbeme a arvid@cursor.com. Somos 5 personas en San Francisco, todo el equipo es excepcional y buscamos a unas cuantas personas excepcionales más — desarrolladores y diseñadores — para que se unan a nosotros a construir el futuro de la programación.