Opus 5.5 non è “un altro modello”: come cambiare approccio per ottenere risultati migliori (soprattutto nel frontend)

Negli ultimi mesi ci siamo abituati a un pattern: esce un nuovo modello, porta benchmark impressionanti, poi nella pratica oscilla tra momenti di brillantezza e improvvise “amnesie operative” (si ferma troppo presto, fa di testa sua, aggiunge cose non richieste). Con Opus 5.5 la sensazione è diversa: la varianza cala parecchio. Non significa che sia infallibile, ma cambia il modo in cui conviene lavorarci.

Questo articolo raccoglie un set di pratiche concrete per usarlo bene nello sviluppo (con un occhio di riguardo al frontend), evitando due errori tipici:

1. trattarlo come un modello da guidare passo-passo;
2. spingerlo sempre al massimo “per sicurezza”, consumando più budget senza un guadagno proporzionale.

---

1) Smetti di “tenere la mano” al modello: punta sulla consistenza

Con molti LLM il prompting diventa un esercizio di contenimento: devi ripetere vincoli, ricordare di non deviare, forzare checklist, e comunque può succedere che:

• si interrompa a metà (“ho finito” ma manca un pezzo);
• aggiunga feature non richieste;
• ristrutturi file e API per gusto personale.

Opus 5.5 tende a essere più stabile e coerente nel seguire un obiettivo dichiarato. Questo consente un cambio di strategia: invece di micro-task iperatomici, funziona bene un approccio a blocchi (plan → implementazione → verifica), purché tu sia chiaro su:

• obiettivo;
• criteri di completamento;
• controlli da eseguire.

In pratica: meno prompt “correttivi” durante l’esecuzione, più cura a monte nel definire il lavoro.

---

2) Thinking effort: “medium” come default, “high” quando serve (evita gli estremi)

Se hai a disposizione livelli di effort (low/medium/high/xhigh/max), la tentazione è tenere sempre il cursore al massimo. Ma i dati di benchmark (e l’esperienza sul campo) suggeriscono un comportamento più pragmatico:

• medium spesso è molto vicino a high come qualità;
• tra high e xhigh il miglioramento tende a essere minimo (a volte nullo, a volte addirittura peggiorativo su alcuni scenari);
• low è troppo penalizzante: il salto di qualità da low a medium è enorme;
• max costa molto di più rispetto al guadagno reale.

Regola operativa consigliata

• Parti con medium.
• Passa a high se:
  • il task è intrinsecamente difficile (migrazioni, refactor estesi, architettura);
  • stai ottenendo output corretti ma “superficiali” (manca profondità, edge case, test/validazioni).
• Usa xhigh solo in casi particolari e consapevoli (debug complesso, ragionamenti lunghi), non come impostazione predefinita.
• Evita low e max come routine.

Questo approccio ha un impatto diretto su costo/limiti d’uso e, paradossalmente, spesso anche sulla velocità complessiva: se non “sprechi” effort, puoi iterare di più.

---

3) Definisci esplicitamente quando un task è “DONE” (per evitare stop prematuri)

Anche un modello molto consistente può fermarsi quando pensa di aver concluso. Il punto è che “finito” per te e “finito” per lui non sono sempre la stessa cosa.

Cosa scrivere nel prompt (o nel piano)

Inserisci criteri di done verificabili. Per esempio:

• “Il task è completo quando: build passa, test passano, lint passa, e la UI è verificata manualmente su X breakpoint.”
• “Considera concluso solo dopo aver aggiornato: componenti, test, documentazione e changelog.”
• “Se modifichi API pubbliche, aggiorna anche gli esempi d’uso.”

Non serve entrare in modalità “romanzo”: basta una sezione Definition of Done chiara.

---

4) Costruisci un loop di auto-verifica (e rendilo eseguibile)

L’idea non è “fidarsi” dell’LLM: è metterlo nelle condizioni di verificare ciò che produce.

La baseline è:

• unit test
• lint
• typecheck

Ma nello sviluppo frontend spesso non basta. Aggiungi, quando possibile:

• integration/E2E (anche pochi test mirati)
• controllo UI reale: avvio dell’app, navigazione, verifica responsive

Prompting pratico: niente vaghezze

Non scrivere “verifica che vada tutto”. Scrivi:

• “Esegui pnpm lint, pnpm test, pnpm build e incolla l’output finale.”
• “Apri la pagina X, verifica: layout a 320px/768px/1280px, overflow, contrasto, hover/focus states.”
• “Controlla che non ci siano regressioni su: header, sidebar, modale di login.”

Se nel tuo ambiente hai strumenti per far pilotare un browser o ispezionare UI, esplicitali. Se non li hai, chiedi comunque una checklist manuale (con punti concreti).

---

5) Frontend e styling: specifica cosa non vuoi, in modo chirurgico

Quando si parla di UI, la vaghezza è un moltiplicatore di attrito. Frasi come “non usare uno stile generico” o “rendilo moderno” lasciano spazio a interpretazioni.

Funziona molto meglio definire vincoli negativi e positivi:

Esempi utili:

• “Niente gradienti viola.”
• “No eyebrow titles / micro-sottotitoli sopra gli H2.”
• “Tipografia: usa scala 14/16/20/28, interlinea 1.5, niente font decorative.”
• “Componenti: solo quelli del design system X; niente librerie aggiuntive.”
• “Accessibilità: focus visibile, contrasto minimo AA, stati hover/focus coerenti.”

Opus 5.5 tende a rispettare bene questi paletti: sfrutta questa caratteristica e scrivili nero su bianco.

---

6) Orchestrazione: incoraggialo a delegare e parallelizzare

Su task medio-grandi, il salto di produttività arriva quando il lavoro viene spezzato in sotto-attività parallele:

• analisi impatti e file coinvolti
• migrazione componente per componente
• aggiornamento test
• verifica UI
• revisione finale del diff

Se il tuo stack/strumento supporta sub-agent o sessioni multiple, dillo esplicitamente:

• “Separa in sotto-task e, dove possibile, delega analisi e refactor a sub-agent.”
• “Crea un agente per i test e uno per la UI review.”

Anche quando l’orchestrazione è “automatica”, un incoraggiamento esplicito aumenta la probabilità che venga usata bene (e presto).

---

7) Dagli lavoro complesso (sì, davvero): migrazioni e refactor lunghi sono il suo terreno

L’errore più comune è limitarsi a micro-task per paura che l’LLM deragli. Con Opus 5.5 conviene fare l’opposto, a patto di impostare bene il perimetro:

1. allineamento (obiettivo, vincoli, piano)
2. Definition of Done
3. check e auto-verifica
4. pitfall noti (es. “attenzione a SSR”, “non rompere le API”, “mantieni compatibilità con i vecchi props”)

Poi: lascia che lavori. Migrazioni di stack, refactor architetturali, conversioni TypeScript più profonde, riorganizzazioni di un design system… sono task in cui la consistenza e la resistenza su iterazioni lunghe contano più della “furbizia” occasionale.

---

Sintesi: un workflow che funziona

Se dovessi ridurlo a una checklist:

• Medium come default, High quando serve; evita Low e Max.
• Scrivi una Definition of Done misurabile.
• Pretendi un loop di verifica (comandi + controlli UI) e rendilo eseguibile.
• Sui dettagli di UI: vincoli specifici, inclusi quelli “negativi”.
• Incoraggia deleghe e parallelismo.
• Non micro-gestire: assegna task complessi con guardrail chiari.

Il risultato è un uso più “ingegneristico” del modello: meno correzioni in corsa, più affidabilità, e soprattutto più valore sui progetti reali—quelli che non finiscono in 10 minuti e non si risolvono con un singolo snippet.