Guía paso a paso para crear tus propios Gems en Gemini (con ejemplo real para programadores)

Si usas Gemini a diario para programar, escribir código o resolver dudas técnicas, seguro que en algún momento te has cansado de repetir el mismo contexto una y otra vez: "actúa como un experto en X", "responde siempre en este formato", "usa este stack de tecnologías"... Ahí es exactamente donde entran los Gems.

Los Gems son básicamente asistentes personalizados dentro de Gemini: versiones del modelo con instrucciones fijas, un tono definido y (opcionalmente) archivos de referencia, listas para usar cuando las necesites sin tener que reescribir el prompt cada vez. Es la forma que tiene Google de darte algo parecido a los "Custom GPTs" o a los proyectos de Claude, pero integrado en su propio ecosistema.

En este artículo vamos a crear, paso a paso, un Gem pensado específicamente para programadores: un "Code Reviewer" que revisa fragmentos de código, detecta errores comunes, sugiere mejoras de rendimiento y siempre responde con un formato consistente. Vamos allá.

¿Qué es exactamente un Gem?

Antes de meternos en el paso a paso, aclaremos el concepto. Un Gem es una configuración personalizada de Gemini que incluye:

• Instrucciones personalizadas: el "system prompt" que define cómo debe comportarse el modelo.
• Nombre y descripción: para identificarlo rápido entre tus otros Gems.
• Archivos de conocimiento (opcional): documentos, guías de estilo o fragmentos de código que quieras que el Gem tenga siempre presentes.

Una vez creado, el Gem queda disponible en tu barra lateral de Gemini, listo para usarse en cualquier conversación nueva.

Paso 1: Accede al creador de Gems

Entra a gemini.google.com con tu cuenta de Google. En el menú lateral izquierdo busca la sección "Gems" (en algunos idiomas puede aparecer como "Explorar Gems"). Ahí verás los Gems predefinidos de Google (como "Programador" o "Guía de aprendizaje") y un botón para crear uno nuevo.

Haz clic en "Crear un Gem" (o el ícono de "+").

Paso 2: Ponle nombre a tu Gem

Para nuestro ejemplo, vamos a llamarlo:

Code Reviewer Pro

El nombre importa más de lo que parece: cuanto más específico sea, más fácil será encontrarlo después entre varios Gems si terminas creando toda una colección (uno para debugging, otro para documentación, otro para SQL, etc.).

Paso 3: Escribe las instrucciones (el corazón del Gem)

Aquí es donde realmente se define el comportamiento. La clave está en ser concreto: qué rol cumple, qué debe evaluar, en qué formato debe responder y qué debe evitar.

Un ejemplo de instrucciones para nuestro "Code Reviewer Pro":

Eres un revisor de código senior con experiencia en desarrollo web
moderno (JavaScript, TypeScript, Python, React y Next.js).

Cuando el usuario te pase un fragmento de código, tu trabajo es:

1. Identificar errores de lógica o bugs potenciales.
2. Señalar problemas de seguridad (inyecciones, datos sin validar,
   claves expuestas, etc.).
3. Sugerir mejoras de legibilidad y buenas prácticas.
4. Proponer optimizaciones de rendimiento si aplica.

Responde siempre con esta estructura:
- ✅ Qué está bien
- ⚠️ Problemas detectados (con severidad: baja/media/alta)
- 💡 Sugerencias de mejora
- 🔧 Código corregido (solo si hay cambios relevantes)

No reescribas código que ya es correcto solo por "estilo personal".
Sé directo y evita explicaciones innecesariamente largas.

Este tipo de instrucción convierte a Gemini en una herramienta consistente: cada vez que le pegues un fragmento de código, sabrás exactamente qué formato de respuesta vas a recibir, sin tener que pedirlo cada vez.

Paso 4: Añade archivos de referencia (opcional, pero muy útil)

Si tu equipo tiene una guía de estilo propia (por ejemplo, convenciones de nombres, estructura de carpetas o reglas de linting), puedes subir ese documento al Gem. Así, cada revisión de código tendrá en cuenta no solo buenas prácticas generales, sino también las reglas específicas de tu proyecto.

Para nuestro ejemplo, podrías subir un archivo .md con algo como:

- Usar siempre const/let, nunca var.
- Componentes en PascalCase, hooks en camelCase con prefijo "use".
- Evitar lógica de negocio dentro de componentes de presentación.
- Toda función async debe manejar errores con try/catch.

Esto es especialmente útil si trabajas con "vibe coding" y quieres que el modelo revise el código generado con criterios consistentes con tu stack (en mi caso, por ejemplo, uso Next.js, Supabase y Vercel casi en todos mis proyectos, así que este tipo de reglas evita que el modelo sugiera patrones que no encajan con esa arquitectura).

Paso 5: Guarda y prueba tu Gem

Haz clic en "Guardar". Tu Gem ya aparecerá en la barra lateral. Ábrelo y prueba con un fragmento de código real. Por ejemplo:

function getUser(id) {
  const user = db.query("SELECT * FROM users WHERE id = " + id);
  return user;
}

Con las instrucciones que configuramos, el Gem debería detectar de inmediato el problema de inyección SQL, señalar la falta de manejo de errores y sugerir usar parámetros preparados en la consulta, todo en el formato fijo que definiste.

Paso 6: Itera sobre las instrucciones

La primera versión de un Gem casi nunca es la definitiva. Después de un par de usos reales, vas a notar detalles que quieres ajustar: quizás las respuestas son muy largas, o falta que evalúe también la cobertura de tests, o quieres que use un tono más informal. Vuelve a la configuración del Gem, edita las instrucciones y guarda de nuevo. No hace falta crear uno nuevo desde cero; el Gem se actualiza para todas tus conversaciones futuras.

Ideas de otros Gems útiles para programadores

Una vez que domines el proceso, este mismo flujo sirve para crear toda una "caja de herramientas" personalizada:

• Documentador técnico: convierte funciones o endpoints en documentación clara, con ejemplos de uso.
• Generador de tests: recibe una función y devuelve casos de prueba (unitarios y edge cases).
• Traductor de código: convierte snippets entre lenguajes (por ejemplo, de Python a JavaScript) manteniendo la lógica.
• Asistente de commits: recibe un diff y sugiere un mensaje de commit siguiendo Conventional Commits.

En conclusión, los Gems no son magia: son, en el fondo, prompts bien pensados guardados de forma persistente. Pero esa simple diferencia —no tener que reescribir el contexto cada vez— es la que realmente ahorra tiempo en el día a día de cualquier programador. Si trabajas con IA como parte de tu flujo habitual (ya sea para revisar código, generar documentación o depurar errores), vale la pena invertir 10 minutos en configurar un par de Gems bien definidos. La inversión se paga sola desde la primera semana de uso.

¿Ya tienes algún Gem creado? Cuéntame en los comentarios para qué lo usas, siempre es interesante ver cómo cada quien adapta estas herramientas a su propio flujo de trabajo.