Nota del editor: Claude Fable 5 se lanzó el 9 de junio de 2026, y Anthropic lo posiciona como un modelo de nivel Mythos especializado en tareas de ingeniería de software de larga duración y con características de seguridad más robustas.

Tras el lanzamiento del nuevo modelo, los desarrolladores pronto comenzaron a explorar su uso en escenarios de ingeniería reales: este prompt de auditoría de repositorios compartido por @meta_alchemist es un caso típico. Hace que Fable 5 no solo genere código, sino que actúe como un responsable técnico senior, examinando sistemáticamente un repositorio de código en cuatro fases: primero analizando la estructura del proyecto y la pila tecnológica, luego revisando problemas de arquitectura, seguridad, pruebas, rendimiento, dependencias y documentación basándose en archivos reales con números de línea, después refinando estrategias de mejora y desglosándolas en hitos de tareas con prioridad y estimación de esfuerzo. Algunos usuarios ya lo han utilizado para limpiar deuda técnica, descubrir vulnerabilidades de seguridad y problemas de eficiencia pasados por alto por modelos anteriores, mientras que otros han encontrado problemas tempranos como inestabilidad del entorno sandbox.

En general, el lanzamiento de Fable 5 no es solo una actualización de capacidades del modelo, sino que también impulsa aún más la transición de la IA de "asistente para escribir código" a "colaborador en auditorías de ingeniería y mejora de proyectos".

A continuación, el texto original:

¿Ya estás usando Claude Fable 5?

Una de las primeras cosas que deberías hacer es usarlo para mejorar tu proyecto principal, haciendo que optimice significativamente todo el trabajo que has estado realizando.

Ejecuta el siguiente "Prompt de Auditoría y Mejora de Proyecto" (puedes copiarlo y pegarlo directamente) en cada repositorio de código que sea importante para ti:

Auditoría de Repositorio de Código y Plan de Mejora

Eres un ingeniero de software de nivel mundial, con experiencia de ingeniero jefe y experto en auditoría técnica. Tu tarea es analizar en profundidad este repositorio de código, proporcionar un informe de auditoría honesto y ofrecer un plan de mejora ejecutable y priorizado. Sigue estrictamente las siguientes cuatro fases en orden, sin saltarte pasos.

Todos los juicios deben basarse en evidencia real de archivos: cita rutas de archivo y números de línea. Si algo no se puede verificar, indícalo claramente en lugar de suponerlo.

Fase 1 / Descubrimiento y Organización: Primero leer, luego juzgar

Antes de llegar a cualquier conclusión, explora sistemáticamente todo el repositorio de código:

· Organiza la estructura de directorios, identifica el tipo de proyecto, los lenguajes y frameworks utilizados, así como el objetivo de ejecución.

· Identifica los archivos de entrada, los módulos centrales y los principales flujos de datos y control del sistema.

· Lee el manifiesto del paquete (package manifest), el archivo de bloqueo (lockfile), la configuración de construcción, la configuración de CI, los archivos de configuración/entorno y toda la documentación, incluyendo README, CONTRIBUTING, ADR, etc.

· Determina el propósito de este proyecto: su objetivo, usuarios previstos y el nivel de madurez que parece tener actualmente: ¿es un prototipo, una herramienta interna, un servicio en producción o una librería?

· Registra las convenciones ya adoptadas por el proyecto, incluyendo estilos de nomenclatura, límites de módulos, patrones de manejo de errores, estilos de pruebas, etc., para que las recomendaciones posteriores se ajusten a la cultura de ingeniería existente, en lugar de oponerse a ella.

Salida de esta fase: un "Mapa del Repositorio" conciso, que incluya el propósito del proyecto, la pila tecnológica, un esquema arquitectónico, directorios clave con una breve descripción y cualquier aspecto que te haya sorprendido.

Fase 2 / Auditoría: Basada en evidencia, con nivel de gravedad

Realiza una auditoría en cada una de las siguientes dimensiones.

Para cada hallazgo, registra:

a) Qué encontraste

b) Dónde lo encontraste, en formato: archivo:número_de_línea

c) Por qué es importante, es decir, las consecuencias concretas, no principios abstractos

d) Nivel de gravedad: Critical / High / Medium / Low

Arquitectura y Diseño

Límites de módulos, acoplamiento/cohesión, dependencias cíclicas, fugas de abstracción, objetos/archivos "dios" (God objects/files), violaciones de capas, cuellos de botella de escalabilidad.

Calidad del Código

Código duplicado, código obsoleto, puntos calientes de complejidad, incluyendo las funciones más largas y las con más ramificaciones; patrones inconsistentes; brechas en el manejo de errores, por ejemplo, excepciones silenciadas o casos límite faltantes; vulnerabilidades de seguridad de tipos.

Seguridad

Claves o credenciales codificadas (hardcoded), riesgos de inyección, deserialización insegura, falta de validación de entradas, debilidades de autenticación/autorización, dependencias obsoletas con CVE conocidas, configuraciones excesivamente permisivas.

Pruebas

Brechas en la cobertura de pruebas, especialmente en la lógica de negocio central; calidad de las pruebas, es decir, si verifican comportamiento o solo que se ejecutan; tipos de pruebas faltantes, incluyendo unitarias, de integración y end-to-end (e2e); patrones de pruebas frágiles (flaky); código difícil de probar.

Rendimiento

Consultas N+1, asignaciones o copias innecesarias, llamadas bloqueantes en rutas asíncronas, falta de caché o índices, problemas de crecimiento sin límite, como memoria, archivos, colas.

Dependencias

Dependencias obsoletas, sin mantenimiento, duplicadas o pesadas innecesarias; riesgos de licencia; estado de mantenimiento del archivo de bloqueo (lockfile).

Experiencia de Desarrollo y Operaciones

Costo de construcción/inicio, brechas en CI/CD, falta de verificaciones obligatorias de linting/formato, calidad de logs y observabilidad, reporte de errores, ruta de despliegue.

Documentación

Precisión del README, ruta de inicio (onboarding), comportamientos clave no documentados, documentación desactualizada que contradice al código.

Reglas de esta fase

Es mejor dar 15 hallazgos de alta confianza que 50 hallazgos especulativos.

Distinguir entre hechos y juicios. Por ejemplo:

· Hecho: "Esta función no maneja errores: src/api/client.ts:142"

· Juicio: "Los límites de responsabilidad de este módulo parecen poco claros"

E indica claramente cuál es cuál.

También enumera los aspectos que este repositorio hace bien. Las fortalezas también son importantes, ya que determinan qué cosas se deben conservar.

Salida de esta fase: un "Informe de Auditoría". Agrupa por dimensión, ordena por nivel de gravedad e incluye una sección de Fortalezas. No olvides señalar los problemas más graves y que requieren mayor prioridad.

Fase 3 / Estrategia de Mejora

Sintetiza los resultados de la auditoría en un conjunto de estrategias:

· Identifica de 3 a 5 temas que expliquen la mayoría de los problemas, por ejemplo: "No hay límites forzados entre capas", "El manejo de errores es demasiado ad-hoc".

· Para cada tema, propón un estado objetivo y los principios detrás de él.

· Explica claramente las compensaciones (trade-offs): qué problemas sugieres no arreglar por ahora, y por qué, por ejemplo, desproporción entre inversión y beneficio, alto riesgo, nivel de madurez del proyecto que aún no lo requiere.

· Define qué significa "terminado": proporciona señales medibles, como "El CI fallará por errores de linting", "Cobertura de pruebas en módulos centrales ≥ 80%", "Problemas de nivel Critical eliminados".

Fase 4 / Plan Detallado de Tareas

Transforma la estrategia en un plan de ejecución:

Divide el trabajo en tareas independientes. Cada tarea debe incluir:

· Título y una breve descripción de la tarea

· Archivos/áreas afectadas

· Criterios de aceptación, es decir, cómo verificar que está completada

· Estimación de esfuerzo: S = menos de 2 horas, M = medio día, L = 1–2 días, XL = necesita desglose adicional

· Riesgo inherente del cambio, es decir, si podría romper la funcionalidad existente

· Dependencias con otras tareas

Ordena las tareas por hitos:

Hito 0

Red de seguridad: Elementos que deben completarse antes de cualquier refactorización segura, por ejemplo, pruebas en rutas críticas, puertas de CI, copias de seguridad.

Hito 1

Correcciones críticas: Problemas de seguridad y de corrección (correctness).

Hito 2

Mejoras de alto impacto (high leverage): Cambios que harán que todo el trabajo posterior sea más fácil.

Hito 3

Calidad y pulido: Elementos restantes de prioridad media-baja que valga la pena abordar.

Destaca por separado los "quick wins" (victorias rápidas), es decir, tareas de alto impacto, esfuerzo S, que se pueden completar de inmediato.

Para las tres primeras tareas, incluye un breve esquema de implementación, con el método, pasos clave y posibles dificultades.

Formato de entrega final

Genera un documento único que contenga las siguientes secciones:

Resumen Ejecutivo (Executive Summary): Máximo 10 frases. Asigna una puntuación de salud general de A a F y justifícala; enumera las 3 principales amenazas (risks) y las 3 principales oportunidades.

Mapa del Repositorio

Informe de Auditoría

Estrategia de Mejora

Plan de Tareas: Incluye hitos, tabla de tareas y quick wins

Preguntas Abiertas: Enumera información que requiere una decisión humana, como la intención del producto, módulos que podrían eliminarse, objetivos de rendimiento, etc.

Restricciones

Durante esta auditoría, no modifiques ningún código. Solo analiza.

No rellenes el informe. Si una dimensión está saludable, explícalo en una frase y continúa.

Calibra las recomendaciones según la madurez del proyecto. No recomiendes infraestructura de nivel empresarial a un prototipo de fin de semana a menos que el objetivo del propietario del proyecto realmente lo requiera.

Analiza las necesidades reales del proyecto y proporciona sugerencias de la manera más efectiva.

Si el repositorio de código es grande, prioriza el análisis en profundidad del 20% más central del código, es decir, la parte que realiza el 80% del trabajo, e indica qué áreas solo fueron revisadas de manera superficial.