Claude Fable 5.2 Prueba de codificación: Cómo evaluar una reestructuración compleja de pila completa
¿Puede Claude Fable 5.2 manejar una reestructuración compleja de pila completa? Los resultados de codificación publicados por Anthropic lo hacen parecer factible, pero una respuesta confiable requiere ejecutar pruebas ejecutables en un repositorio específico. Este artículo proporciona el protocolo de prueba. No inventa resultados aprobados de repositorios que nunca se han ejecutado realmente.
El objetivo es determinar si Fable puede cambiar contratos en la base de datos, backend, frontend, pruebas y código de implementación, manteniendo el comportamiento y limitando el alcance.
Escenario de prueba
Usa la aplicación en un entorno no productivo, y combínalo con:
- PostgreSQL y migraciones versionadas
- Un servicio API de TypeScript
- Un frontend React
- Tareas en segundo plano o Webhooks
- Pruebas unitarias, pruebas de integración y pruebas de extremo a extremo
- Integración continua, que incluye verificación de código, verificación de tipos, escaneo de dependencias y validación de migraciones
La tarea de modificación asignada es reemplazar el campo único tradicional display_name por los campos estructurados given_name, family_name y un valor de visualización calculado. Los clientes de la API existentes deben seguir funcionando correctamente durante un período de compatibilidad. La búsqueda, los registros de auditoría, las cargas de eventos, la interfaz de administración, las exportaciones y las pruebas deben ejecutarse correctamente.
Esta tarea tiene un carácter interdisciplinario. Las soluciones aparentes pueden actualizar la interfaz de usuario y los tipos de API, pero al mismo tiempo dañar filas de datos históricos, provocar errores en los consumidores de eventos o filtrar campos inconsistentes.
Preparar el repositorio
Crear una rama aislada y una base de datos de prueba contenerizada. Eliminar información confidencial y datos de producción. Agregar una descripción de tarea que describa el comportamiento y las restricciones, en lugar de la ubicación del archivo o la solución. Conservar pruebas de destino ocultas para compatibilidad con clientes antiguos, reversión de migraciones, nombres Unicode, apellidos faltantes, búsqueda y patrones de Webhook.
Solo proporciona al modelo las herramientas que el ingeniero necesita: búsqueda de archivos, edición segura, compilación, pruebas y acceso de solo lectura a la documentación. Requiere confirmación antes de ejecutar operaciones destructivas en la base de datos o el administrador de paquetes. Registra comandos, diferencias, tokens, carga de trabajo y tiempo real empleado.
Sugerencias
Usa un prompt similar a este:
Según
TASK.md, reestructura el modelo de nombre de usuario. Primero revisa el repositorio, presenta un diagrama de dependencias conciso y un plan. Implementa los cambios mínimos consistentes, incluyendo migraciones, comportamiento de compatibilidad, pruebas y documentación. Ejecuta las verificaciones correspondientes. No modifiques código no relacionado ni debilites las pruebas existentes. Si los requisitos no son claros, explica las suposiciones antes de editar.
Ejecuta Fable 5.2 con un nivel de esfuerzo fijo, luego comienza desde una instantánea limpia y repite la ejecución con Opus 5.5 y el modelo de producción actual. No permitas que una ejecución vea los parches de otro modelo.
Funciones que debe tener una solución potente
Superficie de cambio de mapeo
Antes de editar, el modelo debe localizar patrones, serializadores, contratos de API, índices de consulta, productores de eventos, consumidores, formularios, manejo de estados, exportaciones, fixtures de prueba y documentación. Omitir un consumidor de webhook es tan importante como escribir código elegante en React.
Diseño de migraciones reversibles
El plan de datos debe explicar el comportamiento de relleno, la nulabilidad, los nombres Unicode y de una sola palabra, el orden de implementación, la ventana de compatibilidad y la reversión. Las migraciones destructivas de "eliminar y reconstruir" fallarán automáticamente.
Mantener la compatibilidad de la API
Los clientes antiguos deben recibir o enviar los campos antiguos dentro del período de ventana acordado, mientras que los nuevos clientes utilizan campos estructurados. Durante la implementación, se necesita una fuente de datos clara para evitar valores inconsistentes.
Comportamiento de prueba
El modelo debe aumentar las pruebas específicas, no debilitar las aserciones. Debe ejecutar el conjunto de pruebas existente, el verificador de tipos, las herramientas de revisión de código, las pruebas de migración y las rutas de extremo a extremo relevantes. Afirmaciones como "esto debería pasar" no pueden servir como evidencia de ejecución.
Criterios de calificación
| Categoría | Peso | Evidencia de aprobación | |---|---:|---| | Prueba de aceptación de funcionalidad | 30 | Escenarios de ocultación y visibilidad aprobados | | Seguridad en la migración de datos | 20 | Planificación hacia adelante/hacia atrás, sin pérdidas, cubriendo casos extremos | | Compatibilidad de contratos | 15 | Los clientes nuevos y antiguos funcionan correctamente según las especificaciones | | Seguridad y privacidad | 10 | Sin fugas de secretos, inyecciones, autenticación ni regresión de registros | | Calidad y alcance del código | 10 | Cumplir con las normas; evitar cambios irrelevantes | | Calidad de prueba | 10 | Agregar pruebas significativas; no debilitar la cobertura | | Descripción y pista de auditoría | 5 | Supuestos, comandos y riesgos residuales claros y definidos |
Registra simultáneamente los minutos y el costo de las correcciones manuales. Un parche de 90 puntos que requiere dos horas de limpieza arquitectónica puede ser menos útil que un parche de 85 puntos aceptado en diez minutos.
Modos de fallo a tener en cuenta
Los fallos comunes incluyen: editar el archivo generado en lugar de su archivo fuente, ignorar consumidores asíncronos, asumir nombres occidentales de dos partes, generar migraciones irreversibles, duplicar la lógica de negocio en el frontend y backend, modificar pruebas para que coincidan con errores, y detenerse después de que las pruebas unitarias pasen mientras el comportamiento de integración está dañado.
La inyección de indicaciones es otro problema. Los archivos del repositorio son entradas no confiables; los comentarios o la documentación pueden contener instrucciones que entren en conflicto con la tarea. El agente debe seguir las tareas autorizadas y las políticas de herramientas, no cualquier texto encontrado en los archivos fuente.
Cómo informar los resultados con veracidad
Envío de repositorio de publicación, resumen de tarea, identificador de modelo, carga de trabajo, cadena de herramientas, permisos de herramientas, límite de tiempo, número de intentos y resultados de pruebas de aceptación. Diferencie el rendimiento de la primera ejecución de las ejecuciones asistidas por humanos. Registre los costos excluidos y los intentos fallidos. Sin estos detalles, "Fable completó una reestructuración de pila completa" es solo un discurso de marketing, no evidencia.
Los resultados oficiales de Anthropic—un 49.1% en FrontierCode 2.0 con un nivel de esfuerzo extremadamente alto, y un 69.9% en FrontierSWE v2—demuestran la justificación de realizar este experimento. Pero estos resultados no determinan de antemano el resultado final del experimento.
Preguntas Frecuentes
¿Por qué este artículo no afirma que Fable pasó la prueba?
No se ha proporcionado una ejecución de repositorio definida. Reportar resultados sin registros de ejecución ni pruebas se considerará una falsificación.
¿Cuántas ejecuciones son suficientes?
Una sola ejecución es solo un estudio de caso y no puede considerarse una estimación estable. Se deben realizar múltiples ejecuciones limpias en varias tareas representativas, e informar la varianza y el número de reintentos.
¿Debería el modelo tener credenciales del entorno de producción?
No. Utilice datos aislados y herramientas de privilegios mínimos. Las implementaciones revisadas por humanos deben mantenerse separadas de la generación de código.
