Claude Fable 5.2 Test di codifica: come valutare un complesso refactoring full-stack

Claude Fable 5.2 è in grado di gestire un complesso refactoring full-stack? I risultati di codifica pubblicati da Anthropic lo fanno sembrare fattibile, ma una risposta credibile richiede l'esecuzione di test funzionanti su un repository specifico. Questo articolo fornisce il protocollo di test. Non inventa risultati di superamento da repository mai effettivamente eseguiti.

L'obiettivo è determinare se Fable è in grado di modificare i contratti nel database, backend, frontend, test e codice di distribuzione, mantenendo al contempo il comportamento e limitando l'ambito.

Scenario di test

Utilizza applicazioni in ambiente non di produzione, in combinazione con:

• PostgreSQL e migrazioni con versionamento
• Un servizio API TypeScript
• Un frontend React
• Attività in background o Webhook
• Test unitari, test di integrazione e test end-to-end
• Integrazione continua, che include controllo del codice, controllo dei tipi, scansione delle dipendenze e verifica della migrazione

Il compito di modifica assegnato è sostituire il tradizionale campo singolo display_name con i campi strutturati given_name, family_name e un valore di visualizzazione calcolato. I client API esistenti devono continuare a funzionare correttamente durante un periodo di compatibilità. Ricerche, log di audit, payload di eventi, interfaccia di amministrazione, esportazioni e test devono funzionare correttamente.

Questo compito ha una natura interdisciplinare. Le soluzioni apparenti potrebbero aggiornare l'interfaccia utente e i tipi di API, ma allo stesso tempo danneggiare le righe di dati storici, causare errori nei consumatori di eventi o esporre campi incoerenti.

Preparazione del repository

Crea un ramo isolato e un database di test containerizzato. Rimuovi le informazioni riservate e i dati di produzione. Aggiungi una descrizione del compito che descriva il comportamento e i vincoli, non la posizione dei file o la soluzione. Mantieni i test mirati nascosti per la compatibilità con i client precedenti, il rollback delle migrazioni, i nomi Unicode, i cognomi mancanti, la ricerca e i pattern dei webhook.

Fornisci al modello solo gli strumenti necessari all'ingegnere: ricerca file, modifica sicura, compilazione, test e accesso in sola lettura ai documenti. Richiedi conferma prima di eseguire operazioni distruttive sul database o sul gestore di pacchetti. Registra comandi, differenze, token, carico di lavoro e tempo effettivo impiegato.

Suggerimenti

Usa un prompt simile a questo:

Ristrutturare il modello del nome utente secondo TASK.md. Prima controllare il repository, presentare un diagramma delle dipendenze conciso e un piano. Implementare modifiche minime e coerenti, incluse migrazioni, comportamento di compatibilità, test e documentazione. Eseguire i controlli pertinenti. Non modificare codice non correlato né indebolire i test esistenti. Se i requisiti non sono chiari, chiarire le ipotesi prima di modificare.

Esegui Fable 5.2 a un livello di sforzo fisso, poi parti da uno snapshot pulito e ripeti l'esecuzione con Opus 5.5 e il modello di produzione corrente. Non permettere a un'esecuzione di vedere le patch di un altro modello.

Funzionalità che una soluzione potente dovrebbe avere

Mappatura della superficie di modifica

Prima di modificare, il modello dovrebbe individuare pattern, serializzatori, contratti API, indici di query, produttori e consumatori di eventi, moduli, gestione dello stato, esportazioni, fixture di test e documentazione. Trascurare un consumatore di webhook è importante quanto scrivere codice React elegante.

Progettazione di migrazioni reversibili

Il piano dati dovrebbe specificare il comportamento di backfill, la nullabilità, i nomi Unicode e a parola singola, l'ordine di distribuzione, la finestra di compatibilità e il rollback. Le migrazioni distruttive "elimina e ricostruisci" falliranno automaticamente.

Mantenere la compatibilità delle API

I clienti vecchi devono ricevere o inviare i vecchi campi entro la finestra concordata, mentre i nuovi clienti utilizzano campi strutturati. Durante l'implementazione è necessaria una fonte dati chiara per evitare valori incoerenti.

Prova del comportamento

Il modello dovrebbe aggiungere test mirati, anziché indebolire le asserzioni. Deve eseguire la suite di test esistente, il type checker, gli strumenti di linting, i test di migrazione e i percorsi end-to-end correlati. Affermazioni come "questo dovrebbe funzionare" non possono essere considerate prove di esecuzione.

Criteri di valutazione

| Categoria | Peso | Prove di superamento | |---|---:|---| | Test di accettazione funzionale | 30 | Scenari di visibilità e occultamento superati | | Sicurezza della migrazione dei dati | 20 | Piano forward/backward, senza perdite, copertura dei casi limite | | Compatibilità del contratto | 15 | I client nuovi e vecchi funzionano correttamente secondo le specifiche | | Sicurezza e Privacy | 10 | Nessuna fuga di segreti, iniezione, regressione dell'autenticazione o della registrazione | | Qualità del codice e ambito | 10 | Rispettare le norme; evitare modifiche irrilevanti | | Qualità del test | 10 | Aggiungere test significativi; non ridurre la copertura | | Descrizione e audit trail | 5 | Ipotesi, comandi e rischi residui chiaramente definiti |

Registra anche i minuti e i costi delle correzioni manuali. Una patch da 90 punti che richiede due ore di pulizia dell'architettura potrebbe essere meno utile di una patch da 85 punti accettata in dieci minuti.

Modalità di guasto da tenere d'occhio

I fallimenti comuni includono: modificare il file generato invece del file sorgente, ignorare i consumatori asincroni, assumere nomi occidentali in due parti, generare migrazioni irreversibili, duplicare la logica di business nel frontend e nel backend, modificare i test per farli corrispondere a errori, e fermarsi dopo che i test unitari passano mentre il comportamento di integrazione è danneggiato.

L'iniezione di prompt è un altro problema. I file del repository sono input non affidabili; commenti o documenti possono contenere istruzioni in conflitto con il compito. L'agente deve seguire le strategie di compito e strumento autorizzate, non testi arbitrari trovati nei file sorgente.

Come riportare onestamente i risultati

Pubblicazione dei commit del repository, riepilogo delle attività, identificatore del modello, carico di lavoro, toolchain, permessi degli strumenti, limiti di tempo, numero di tentativi e risultati dei test di accettazione. Distinguere le prestazioni del primo avvio da quelle con assistenza umana. Registrare i costi esclusi e i tentativi falliti. Senza questi dettagli, "Fable ha completato un refactoring full-stack" è solo marketing, non una prova.

I risultati ufficiali di Anthropic—49,1% su FrontierCode 2.0 con uno sforzo estremamente elevato e 69,9% su FrontierSWE v2—giustificano la conduzione di questo esperimento. Tuttavia, questi risultati non possono predeterminare l'esito finale dell'esperimento.

Domande frequenti

Perché questo articolo non afferma che Fable ha superato il test?

Non è stato fornito un repository definito per l'esecuzione. Riportare risultati senza log di esecuzione e test sarà considerato una falsificazione.

Quante esecuzioni sono sufficienti?

Una singola esecuzione è solo un caso studio e non può essere considerata una stima stabile. Si dovrebbero effettuare più esecuzioni pulite su più compiti rappresentativi, riportando la varianza e il numero di tentativi.

Il modello dovrebbe possedere credenziali per l'ambiente di produzione?

No. Utilizzare dati isolati e strumenti con privilegi minimi. Le revisioni manuali dovrebbero rimanere separate dalla generazione del codice.