El prompt de auditoría: cómo hacer que Claude Fable 5 revise tu proyecto como un arquitecto senior

El 9 de junio de 2026 Anthropic publicó Claude Fable 5, su primer modelo clase Mythos disponible al público. No es una iteración menor: es el primer modelo que mantiene tareas largas, asíncronas y de varios pasos sin perderse en el camino. En SWE-Bench Pro resuelve el 80,3% de los problemas (contra 69,2% de Opus 4.8 y 58,6% de GPT-5.5), rompe el 90% en el benchmark analítico de Hex y razona al nivel de un research scientist senior. Donde modelos anteriores se quedaban cortos — auditar un repositorio entero, sostener una conversación de horas, producir un plan de acción coherente — Fable 5 termina la jugada.

Esta guía te entrega un prompt único, diseñado específicamente para aprovechar esa ventana de razonamiento. Pegado tal cual en una sesión con tu repositorio a la vista, convierte a Fable 5 en un arquitecto senior crítico y devuelve una auditoría completa: arquitectura, seguridad, costo, deuda técnica y un plan priorizado con evidencia. No es para preguntas sueltas. Es para cuando necesitas que alguien mire todo, te diga la verdad y te ordene la pelea.

Por qué este prompt funciona (y por qué uno cualquiera no)

La calidad de cualquier análisis con un modelo grande no depende del modelo: depende del contexto que le entregues y del marco mental en que lo pongas. Fable 5 tiene capacidad para razonar como un senior; no significa que lo haga por defecto si tu prompt es "revisa mi proyecto y dime qué piensas". Con esa pregunta vas a recibir lo que recibirías de cualquier modelo: observaciones genéricas, elogios amables y un par de tips de buenas prácticas.

Un prompt que sí mueve la aguja hace tres cosas que el genérico no:

• Fija un rol denso. No basta con "actúa como senior". El modelo necesita saber qué tipo de senior, qué le importa, qué desprecia y bajo qué criterio te va a evaluar. Cambia el sesgo de respuesta.
• Acota las dimensiones de análisis. Sin un orden de prioridad explícito, el modelo cubre lo que mejor sabe y omite lo que no preguntaste. Con dimensiones fijas, no puede saltarse ninguna.
• Exige evidencia y reconoce ignorancia. Si pides "ejemplos concretos con archivo y línea" y le permites decir "esto no lo pude verificar", paras la alucinación en seco. El modelo deja de inventar y empieza a reportar lo que realmente vio.

Fable 5 brilla con ese tipo de contexto rico. Le das una sesión larga, acceso a los archivos, instrucciones precisas y reglas de evidencia, y te devuelve una auditoría que cualquier consultor habría facturado en horas. Pero la calidad del input define el techo del output.

El prompt completo

Reemplaza lo que está entre [corchetes] con la información de tu proyecto. No borres ninguna sección — las cinco dimensiones, en ese orden, son lo que hace que el modelo no se salte trabajo.

Eres un arquitecto de software senior con 15 años de experiencia
construyendo y operando sistemas en producción. Has hecho due diligence
técnico de decenas de empresas y has visto fallar muchas. Tu trabajo NO
es validarme. Tu trabajo es encontrar lo que está mal, decirme la verdad
sin amortiguar, y ordenar el trabajo por impacto real en el negocio.

Voy a darte acceso a un proyecto completo. Tu tarea es una auditoría
estructurada en cinco dimensiones, en el orden exacto que listo abajo.

# CONTEXTO DEL PROYECTO

- Nombre: [NOMBRE]
- Qué hace: [DESCRIPCIÓN EN 2-3 LÍNEAS]
- Stack principal: [LENGUAJES, FRAMEWORKS, BD, INFRA]
- Estado: [PROD CON N USUARIOS / MVP / DEMO]
- Equipo: [SOLO YO / N PERSONAS]
- Mi mayor sospecha o miedo técnico hoy: [LO QUE NO TE DEJA DORMIR]
- Restricción crítica: [PRESUPUESTO, FECHA, COMPLIANCE, ETC.]

# REGLAS NO NEGOCIABLES

1. CITA EVIDENCIA. Cada afirmación debe incluir archivo y línea (ej.
 "src/api/auth.ts:42"). Sin cita, no la incluyas.
2. SÉ ESPECÍFICO. Nada de "podrías mejorar el manejo de errores".
 Sí: "En src/api/payments.ts:88, capturas el error pero no logueas
 el customerId, así que un fallo de cobro queda sin trazabilidad".
3. DI LO QUE NO SABES. Si no pudiste leer una parte, no inferiste un
 comportamiento, o te falta archivo para opinar, dilo explícito.
 No inventes. "No tengo acceso a X" es una respuesta válida.
4. PRIORIZA POR DAÑO, NO POR ELEGANCIA. Un bug que te tira producción
 un sábado vale más que un refactor "más limpio".
5. NO ME ELOGIES. No me digas "buen patrón aquí" salvo que sea
 crítico para entender una decisión más adelante.

# DIMENSIONES DE ANÁLISIS — EN ESTE ORDEN

## 1. ARQUITECTURA
Diagrama mental de cómo fluye una request representativa de punta a
punta. Qué decisiones de diseño envejecieron bien y cuáles ya son
deuda. Acoplamientos peligrosos. Inconsistencias entre módulos.
Lo que sería difícil cambiar si mañana el negocio gira.

## 2. PROBLEMAS CRÍTICOS DE SEGURIDAD
Vulnerabilidades reales y explotables, no checklist OWASP genérico.
Secrets en código, autenticación rota, autorización por confianza,
inyecciones, exposiciones de datos, dependencias con CVEs activas.
Para cada hallazgo: severidad, vector de ataque concreto, fix
mínimo viable.

## 3. COSTO Y RENDIMIENTO
Dónde se está gastando plata sin retorno (queries N+1, llamados
redundantes a APIs caras, jobs corriendo sin necesidad, infra
sobreprovisionada). Cuellos de botella reales bajo carga. Latencias
que el usuario nota. Estimación grosera del ahorro si se arregla.

## 4. DEUDA TÉCNICA
Lo que ya cuesta mantener y va a costar más cada semana que pase.
Tests faltantes en hot paths. Tipos rotos. Patrones abandonados a
medio camino. Dependencias deprecadas. Documentación contradictoria.
Distingue entre deuda aceptable y deuda que ya está cobrándose.

## 5. PLAN DE ACCIÓN PRIORIZADO
Una tabla con máximo 10 items, ordenada por impacto/esfuerzo.
Columnas: Item · Dimensión · Impacto (alto/medio/bajo) · Esfuerzo
(horas estimadas) · Archivo(s) afectado(s) · Riesgo de no hacerlo.
Marca con 🔥 los items que harías esta misma semana si fueras yo.

# QUÉ HACER ANTES DE EMPEZAR

1. Lista los archivos que tienes acceso a leer.
2. Identifica los 5 archivos críticos que vas a priorizar.
3. Dime qué te falta para hacer una auditoría completa (logs de
 producción, métricas, esquema de BD, variables de entorno, etc.).
4. Solo entonces empieza con la dimensión 1.

Empieza ahora.

Anatomía: por qué cada parte funciona

1. Rol denso, no rol decorativo. "Arquitecto senior con 15 años que ha hecho due diligence técnico" no es flair: cambia el espacio de respuestas que el modelo considera plausibles. Le dice que tu interlocutor mental es alguien que ya vio fallar empresas, no un junior buscando un compliment. Fable 5 calibra su sesgo a ese perfil.

2. Pedir crítica explícita, prohibir el elogio. Por defecto los modelos están entrenados para ser amables. Una sola línea — "tu trabajo NO es validarme" — quita el filtro del cumplido y libera la observación dura. Sin ella, perderías un 30% del valor del análisis.

3. Cinco dimensiones específicas, en orden fijo. No es decoración: es estructura. Sin la lista numerada, el modelo cubre lo que mejor sabe (típicamente arquitectura y patrones) y omite costo y deuda técnica, que son lo que más te duele en negocio. El orden importa: arquitectura abre el contexto, seguridad detiene sangrado, costo y deuda priorizan trabajo, y el plan cierra la ejecución.

4. Priorizar por daño, no por elegancia. Una sola regla evita el output más común y menos útil: la lista de refactors "más limpios" que no mueven la aguja. Cuando obligas al modelo a pensar en daño al negocio, los hallazgos se vuelven accionables y defendibles ante un fundador o un CFO.

5. Exigir evidencia y permitir ignorancia. "Archivo y línea o no lo incluyas" elimina al 90% de las alucinaciones. "Di lo que no sabes" es la otra mitad: sin esa licencia, los modelos rellenan huecos con sus propios supuestos. Con ella, te reportan honestamente qué auditaron y qué no — que es la única base seria para un plan.

Cómo usarlo paso a paso

Errores comunes que matan el resultado

• Pegar capturas de pantalla en vez de código. El modelo puede leer imágenes, pero la transcripción introduce ruido y pierde referencias cruzadas entre archivos. Para auditoría, siempre archivos reales (Claude Code) o texto plano pegado (chat web). Las screenshots dejan al modelo adivinando.

• Pedir "feedback general" o "qué opinas de mi código". Esa pregunta empuja al modelo a su zona segura: elogios + un par de tips genéricos. Si quieres una auditoría, exige el marco — las cinco dimensiones, el rol denso, las reglas de evidencia. No hay atajo.

• Quemar la sesión en preguntas pequeñas antes de la auditoría. Algunos llegan, hacen 15 preguntas cortas ("¿qué hace este archivo?"), y cuando piden la auditoría el contexto ya está saturado y diluido. Mejor: abre sesión limpia, pega el prompt preparado, deja que el modelo dirija desde el principio.

• Aceptar la auditoría sin verificar la evidencia. Aunque Fable 5 es muy preciso con citas, una de cada veinte líneas puede estar desfasada (típicamente porque el archivo cambió y el modelo apunta a una versión anterior). Cuando el plan diga "src/x.ts:42", abre y verifica antes de planificar trabajo encima. Tres minutos de validación evitan horas de fix sobre algo que ya no existe.

Lo que NO te resuelve (todavía)

• No reemplaza a un equipo de seguridad. La dimensión 2 detecta los problemas críticos visibles desde el código, pero no hace pentesting activo, no audita infra en vivo y no encuentra vulnerabilidades de configuración cloud. Para apps con datos sensibles, sigue siendo complemento de una auditoría humana, no sustituto.

• No conoce tu negocio. El plan priorizado asume que el daño técnico se traduce linealmente a daño de negocio. A veces no: un bug horrible en una feature que casi nadie usa puede ser menos urgente que un refactor mediano en el funnel de pago. Esa calibración la tienes que hacer tú al recibir la tabla.

• No vale la pena para sesiones de 5 minutos. Fable 5 tiene un costo notable (10 USD por millón de tokens de input, 50 por millón de output — el doble que Opus 4.8). Para preguntas rápidas, Sonnet 4.6 o Haiku 4.5 dan respuestas equivalentes a menor precio. Fable 5 paga su prima cuando lo usas para tareas largas y de alto valor.

• No es para código que no compartes. Si tu proyecto tiene restricciones de NDA o regulación que prohíben enviar fuente a un modelo externo, este prompt no aplica. Usa una versión auto-hosteada o una herramienta on-prem.

Si quieres que esto opere en tu negocio

El prompt resuelve la auditoría en una tarde. La parte difícil viene después: traducir el plan priorizado en sprints, asignar dueños, medir impacto y volver a pasarle el prompt cada trimestre para ver qué mejoró y qué se está pudriendo nuevo. Eso es lo que diseñamos en Infinity Pro AI: sistemas operativos donde Claude Fable 5 no es una herramienta de consulta puntual sino una capa que revisa, prioriza y ejecuta dentro de tu flujo de desarrollo. La auditoría es gratis: en 30 minutos miramos tu setup actual y te decimos qué tiene sentido automatizar primero — y qué auditoría conviene correr manual antes de delegársela a ningún modelo.