Ocho equipos, un LLM y datos reales: así fue nuestra primera kata de prompting

Las katas de código son conocidas en el mundo del desarrollo: ejercicios prácticos que te ayudan a mejorar habilidades específicas en un contexto controlado. Pero las katas de prompting son territorio relativamente inexplorado. Busca «code kata» y aparecen millones de resultados, repositorios enteros dedicados al tema, plataformas especializadas. Busca «kata prompting» en Google y encontrarás poco más que silencio. 

Esa carencia nos pareció una oportunidad perfecta. Si nadie está haciendo katas de prompting de forma estructurada, ¿por qué no ser nosotros quienes exploremos cómo se hace?  Y de paso, ¿por qué no aprovechar para nuestra jornada anual de teambuilding? Jornada en la que juntamos a gente que, además de estar asignada a diferentes proyectos, trabaja en remoto el resto del año. 

Así nació nuestra kata interna: un ejercicio práctico donde los equipos competían por crear el mejor prompt para Apogee, nuestro bot de Slack open source, usando datos reales de nuestra propia empresa. El objetivo no era solo entrenar prompting, sino descubrir qué patrones sociales escondían esos datos y, de paso, pasar un buen rato viendo qué chismes podía desenterrar cada equipo.

El reto: analizar datos de karma y mostrar el resumen más jugoso

Para este kata prompting entre equipos, partíamos del histórico de transacciones de karma en Apogee. Queríamos que los equipos se esmeraran en conseguir un resumen de datos con personalidad: que captara dinámicas de equipo, patrones curiosos, posibles chismes… 

En el fondo, queríamos ver reflejada nuestra dinámica como equipo a través de los datos. Y descubrir cosas que quizá no eran tan obvias solo mirando el canal de Slack. Para conseguirlo, los equipos tenían que entrenar su capacidad de prompting: afinar las instrucciones al LLM para que, con los datos disponibles, extrajera insights realmente interesantes.

Los datos accesibles para este ejercicio eran:

• Leaderboard actual: Ranking completo de usuarios ordenados por karma acumulado
• Leaderboard de hace una semana: La misma foto pero de 7 días atrás, para identificar cambios
• Transacciones intermedias: Todas las operaciones de karma entre ambas fechas, incluyendo el mensaje completo, quién lo envió, quién lo recibió, cuántos puntos y el timestamp

Toda esta información incluía también los mensajes que acompañaban a cada transacción: “@carlos +++ 👀 (de antemano, por guapo)”, “@elena ++ desconceptualizando MiPortal 🚀💫”, “@daniel +++ mentorización y empatía máxima ” «@fernando ++ pasión, lecciones y consejos de un desarrollador veterano allá por «2007 cuando programaba en Java»». Ese contexto textual era oro puro para crear prompts que fueran más allá de lo numérico y captaran lo humano, lo divertido, lo absurdo: los ingredientes para el salseo.

La infraestructura técnica: aplicación web + datos en vivo

Como stack ténico, dispusimos de un puñado de herramientas, para hacer la actividad lo más lean posible. Montamos una aplicación web específica en Next.js con dos páginas:

• Landing con instrucciones: Con una breve introducción sobre Apogee y en qué consistía la kata; la descripción de los datos a los que se tendría acceso y cómo enviar la solución final.
• Entorno de testing: Una interfaz donde escribir el prompt y ejecutarlo directamente contra OpenAI (GPT-4 Mini) con los datos reales. El resultado se mostraba inmediatamente debajo, permitiendo iterar rápido e ir ajustando el prompt hasta obtener el resultado deseado.

Los datos de Apogee se exponían como tools/funciones que el LLM podía invocar: obtener el ranking actual (getTodayLeaderboard()), el ranking de hace 7 días (getLastWeekLeaderboard()), y todas las transacciones entre ambas fechas (getLastWeekTransactions()).

Cada equipo levantaba la aplicación en su local, escribía su prompt, lo testeaba las veces que quisiera. Cuando estuviera satisfecho, lo enviaba como solución final.

Aquí había un detalle importante: durante la fase de desarrollo en local, los equipos trabajaban con datos antiguos, de semanas atrás. Esto era deliberado. No queríamos que vieran los datos frescos mientras preparaban sus prompts. El efecto sorpresa vendría después, cuando ejecutáramos sus prompts en vivo contra los datos de la última semana real. Ver qué descubría cada prompt sobre lo que había pasado esos últimos días en la empresa era parte de la diversión.

Los prompts finales no se envíaban por email o formulario: los commiteaban directamente al repositorio de la kata en nuestro GitHub.

El momento de la verdad: ejecutar los prompts en vivo

Cada equipo tenía su carpeta con un archivo README.md donde almacenar su prompt definitivo, su solución. Algunos equipos iteraron mucho (Orion hizo 5 ejecuciones antes de dar su prompt por bueno), otros se conformaron con 2 intentos (Escorpio). Esa metadata también era interesante: ¿quién era más perfeccionista? ¿Quién confiaba en su primera aproximación?

Para poder ver los resultados de cada equipo durante la kata con los datos más recientes, modificamos Apogee añadiendo un nuevo endpoint: /api/weekly-summary. Este endpoint:

1. Recibe como parámetro un prompt
2. Obtiene automáticamente los datos de leaderboard actual, de hace una semana, y transacciones
3. Envía el prompt a OpenAI con esos datos
4. Publica la respuesta directamente en el canal #thnx de Slack

Durante la presentación de cada equipo, nuestro compañero Kevin ejecutaba manualmente este endpoint con el prompt que habían desarrollado. Así todos podíamos ver en vivo, en el canal de Slack, qué resultado generaba cada propuesta. Eso permitía comparar enfoques y elegir el ganador de forma transparente… y que nos riéramos un rato con los insights que cada prompt era capaz de extraer de Apogee.

La idea de futuro es añadir un cron job que ejecute automáticamente este endpoint cada viernes, usando el prompt ganador, para que Apogee publique el resumen semanal sin intervención manual.

Cuando analizas los datos de tu propia empresa, te involucras en el resultado y, por supuesto, te ríes más.

MATTEO DI PAOLANTONIO
CTO de Orbitant

Métricas reales: qué aprendimos de los datos

Estos son los datos precisos que OpenAI nos proporcionó sobre la ejecución de la kata:

• 219 requests totales al modelo GPT-4 Mini
• 2,029,032 tokens procesados en total
• Coste total: $0.89
• 8 equipos participantes: Orión, Osa Mayor, Osa Menor, Casiopea, Escorpio, Leo, Tauro y Géminis

Equipos más «caros» (por tokens totales consumidos):

1. Orión – 68,794 tokens (5 ejecuciones)
2. Osa Mayor – 29,788 tokens (2 ejecuciones)
3. Escorpio – 28,516 tokens (2 ejecuciones)
4. Casiopea – 16,729 tokens (1 ejecución, pero con output masivo)
5. Géminis – 15,523 tokens (1 ejecución)

Prompts más largos (input):

1. Géminis – 15,344 tokens de input
2. Casiopea – 13,847 tokens de input
3. Escorpio/Orión – ~13,800 tokens de input

Outputs más largos:

1. Casiopea – 2,882 tokens (el más extenso de todos)
2. Osa Mayor (1ª ejecución) – 1,770 tokens
3. Osa Mayor (2ª ejecución) – 1,682 tokens

Lo más interesante no fueron los números absolutos sino los patrones:

Equipos que iteraban más (como Orión con 5 intentos) no necesariamente generaban outputs más largos, sino que refinaban el enfoque. Su coste venía de la repetición, no de la complejidad de cada resultado.

La variabilidad del output fue el mayor driver de coste. Los inputs eran relativamente consistentes (~13,000-15,000 tokens), pero los outputs variaban brutalmente desde 179 tokens (Géminis) hasta 2,882 (Casiopea). Casiopea pedía gráficas, secciones estructuradas, análisis detallado. Otros pedían un resumen de 3 párrafos con tono informal.

El contexto textual importaba más que los números. Los mejores prompts no se centraban en «quién tiene más karma» sino en analizar el lenguaje de los mensajes, los emojis recurrentes, identificar patrones de comportamiento social. Buscaban el chisme, las dinámicas implícitas, los momentos raros. Y eso es lo que hacía que el resultado fuera divertido de leer.

Por qué esto importa más allá del ejercicio

Organizar esta kata prompting entre equipos nos enseñó varias cosas:

• El prompting es una habilidad entrenable: se puede practicar de forma deliberada, iterar, mejorar. Pero casi nadie lo hace de forma estructurada —todavía—. La diferencia entre el primer intento y el quinto de Orión era notable.
• Los datos propios son los mejores para aprender. Usar información real de nuestro Slack hizo que todos estuvieran más engaged que si hubiéramos usado un dataset genérico de Kaggle. Cuando analizas datos de tu propia empresa, te involucras en el resultado —y, por supuesto, te ríes más—.
• La competición sana funciona. Ver los prompts de otros equipos generó conversaciones técnicas valiosas sobre estrategias de prompting que no habrían surgido de otra manera.
• Perfiles no técnicos pueden competir en igualdad. A diferencia de una code kata donde solo los developers tienen opciones, aquí participaron equipos mixtos: marketing, diseño, producto, desarrollo. Todos pudieron aportar.
• Del ejercicio a producción hay un paso pequeño si diseñas bien. No montamos la kata en un entorno aislado: la construimos sobre nuestra infraestructura real (Apogee) de forma que el resultado fuera directamente utilizable. 

Y, lo más importante, funciona como actividad para hacer equipo: montar grupos con gente que normalmente no trabaja junta, darle un reto técnico –pero asequible para roles no techies– y dejarles competir de forma sana es una buena fórmula para fomentar la cultura de empresa. 

Si te ha interesado este ejercicio, recuerda que todo el código está disponible en el repositorio de GitHub.