Ingeniería de prompts para DevOps: la checklist C.L.E.A.R. y una biblioteca de prompts

La ingeniería de prompts suena a palabra de moda hasta la primera vez que una pregunta mal planteada te cuesta una hora. Cuando la IA forma parte del trabajo diario con la infraestructura, un prompt vago recibe una respuesta igual de vaga. A veces, además, equivocada, y en DevOps equivocada puede significar un pipeline roto o un comando kubectl destructivo.

La solución es tratar los prompts como código: versionarlos, probarlos y reutilizarlos. Veamos cómo funciona con ejemplos sacados del trabajo de operaciones de todos los días.

Por qué importa a la gente de operaciones

Nadie le pide poesía al modelo. Las peticiones típicas son de este estilo:

• averiguar por qué falla un plan de Terraform
• escribir un script de bash que no se cargue producción
• reducir 10.000 líneas de logs a diez viñetas
• descifrar un mensaje de error críptico de Kubernetes
• generar un YAML que pase la validación

Lo de «basura entra, basura sale» vale para los prompts igual que para los datos. Escribir uno bueno es hoy una habilidad tan básica como saber usar grep o awk.

El error que comete casi todo el mundo

El prompt habitual es algo como «Arregla mi error de Terraform». La respuesta llega genérica e inútil, y no debería sorprender a nadie, porque el modelo no sabe:

• qué proveedor de nube hay detrás (AWS, GCP o Azure)
• qué dice exactamente el mensaje de error
• qué versión de Terraform se está usando
• qué se ha probado ya

Sin contexto no hay respuesta útil. De verdad, así de sencillo.

Una checklist que cabe en la cabeza: C.L.E.A.R.

Cinco puntos cubren casi cualquier buen prompt.

C de Context, el contexto. Describe el entorno, por ejemplo un clúster EKS de producción en AWS.

L de Limitations, las limitaciones. Indica las restricciones, como un pod con estado que no se puede reiniciar.

E de Expected output, el resultado esperado. Di qué forma debe tener la respuesta, por ejemplo un arreglo de una línea en lugar de reescribirlo todo.

A de Actual error or data, el error o los datos reales. Pega el log o el texto del error tal cual.

R de Role, el rol. Pide al modelo que responda como un SRE sénior haciendo una revisión.

Cada uno de los cinco merece un vistazo más detenido.

1. Contexto

Versión floja: «¿Por qué se cae mi pod?»

Versión mejor: un pod de Node.js en GKE funcionó sin problemas durante tres meses y entró en crash loop justo después de un cambio en un ConfigMap el día anterior.

Ahora el modelo conoce la plataforma, el tipo de aplicación y el desencadenante probable. La diferencia de calidad entre esos dos prompts es enorme.

2. Limitaciones

Un modelo no puede adivinar tus restricciones. Hay que decirlas claramente, por ejemplo: propón un arreglo, pero el nodo principal de la base de datos no se puede reiniciar en horario laboral.

Si no lo dices, lo más probable es que aparezca en la respuesta un despreocupado «simplemente reinícialo». En producción, eso tiene de todo menos de despreocupado.

3. Resultado esperado

Especifica el formato que quieres. Solo con este hábito te ahorras muchas idas y venidas. Algunas peticiones de formato útiles:

• solo el comando de bash, sin comentarios
• responde en forma de tabla
• el bloque YAML y nada más
• la versión corta, pensada para alguien que está depurando a las dos de la madrugada

4. Error o datos reales

Este es el punto que más se salta la gente. Pega lo que hay de verdad.

Versión floja: «Me falla el pipeline de CI».

Versión buena: la salida exacta del fallo del job.

El código de salida 137 suele significar que el proceso se mató por quedarse sin memoria. El modelo solo puede detectarlo si tiene delante el error real.

5. Rol

El rol cambia tanto el tono como la profundidad de la respuesta. Compara pedir una respuesta de un SRE sénior con diez años de experiencia en Kubernetes con pedir una explicación para principiantes. La pregunta es la misma, pero las respuestas cambian mucho, y cualquiera de las dos puede ser justo lo que hace falta según el día.

Prompts que merecen un sitio en el archivo de snippets

Algunos prompts vale la pena guardarlos en cuanto funcionan.

Depuración de Terraform. Pide el rol de un ingeniero DevOps sénior, pega el error del plan, indica el proveedor (AWS) y la versión de Terraform (1.7), y solicita la causa raíz en una línea seguida del arreglo.

Scripts de automatización seguros. Pide un script de bash que elimine las imágenes de Docker con más de siete días. Exige que el modo dry-run venga activado por defecto y prohíbe borrar nada sin confirmación.

Resúmenes de logs. Pasa los logs de Nginx y pide los cinco códigos de error más frecuentes, los endpoints con más tráfico y cualquier patrón de IP sospechoso, todo en menos de 100 palabras.

Postmortems de incidentes. Entrega las notas en bruto del incidente y pide un documento limpio con las secciones Summary, Timeline, Root Cause y Action Items.

Hábitos que salen caros

Hay varios patrones que dan malos resultados una y otra vez:

• meter cinco problemas sin relación en una sola pregunta
• omitir el stack tecnológico, aunque Terraform, CloudFormation y Pulumi den respuestas muy distintas
• dar por buena la primera respuesta sin preguntar «por qué» al menos una vez
• olvidar mencionar que el entorno es de producción cuando lo es
• pegar la salida del modelo directamente en producción sin revisarla

Este último hábito merece su propia etiqueta de advertencia. La IA es el copiloto; el piloto sigue siendo una persona.

Mantener una biblioteca de prompts

Los equipos ya tienen bibliotecas de scripts y runbooks, y una biblioteca de prompts encaja perfectamente a su lado. Una estructura sencilla:

/prompts
  ├── terraform-debug.md
  ├── log-summary.md
  ├── incident-postmortem.md
  ├── yaml-validator.md
  └── cost-report-summary.md

Cada archivo contiene la plantilla reutilizable, campos de relleno como [ERROR], [STACK] y [ENV], y una nota breve sobre cuándo usarla. Así, escribir prompts deja de ser teclear al azar y pasa a ser elegir la herramienta adecuada, igual que coger el script correcto de una carpeta.

Flojo frente a bueno, uno al lado del otro

Fallo de CI

• Flojo: «El CI está roto, ayuda»
• Bueno: «GitHub Actions falla en el paso docker build con código de salida 137, probablemente por falta de memoria. Sugiere cómo ajustar la memoria del runner».

Problema de Kubernetes

• Flojo: «El pod se cae todo el rato»
• Bueno: «Un pod de Node.js en GKE está en crash loop desde el cambio de ConfigMap de ayer. Los logs muestran OOMKilled. Sugiere un ajuste de los límites de recursos».

Petición de script

• Flojo: «Escribe un script de limpieza»
• Bueno: «Escribe un script de bash que borre las imágenes de Docker con más de siete días, incluya un flag de dry-run y nunca borre nada automáticamente».

Por dónde empezar

La ingeniería de prompts no es magia. Es la misma precisión que exige un buen ticket o un runbook claro. Empieza poco a poco, guarda los prompts que funcionan y reutilízalos. Trátalos como código, porque a estas alturas prácticamente lo son.