DEV Community: frontendfacile.it

TimescaleDB: quando PostgreSQL incontra le serie temporali (senza smettere di essere PostgreSQL)

frontendfacile.it — Thu, 24 Sep 2026 11:19:59 +0000

Aggregazioni pre-calcolate, gestione automatica dei chunk e query di dashboard che restano veloci anche con milioni di eventi.

Il problema reale: la dashboard non dovrebbe ricalcolare sempre tutto

Immagina due database sullo stesso laptop, entrambi con 10 milioni di record di richieste HTTP. La domanda è la stessa:

quante richieste arrivano ogni ora
qual è la loro latenza media

Nel primo caso PostgreSQL calcola la risposta leggendo (e raggruppando) gli eventi grezzi. Nel secondo caso si legge invece un riepilogo orario già pronto.

Risultato tipico:

query sugli eventi: ~1,6 secondi
query sul riepilogo: ~10 millisecondi

Le risposte coincidono. A cambiare è la quantità di lavoro: o fai aggregazione “live” su milioni di righe, oppure leggi risultati già aggregati.

A questo punto viene spontaneo dire: “Ok, allora basta salvare i riepiloghi anche in PostgreSQL”. Vero. Il punto è un altro: mantenerli aggiornati in modo affidabile e incrementale, senza dover ricalcolare l’intera storia ogni volta che arrivano nuovi dati.

È qui che entrano in gioco le continuous aggregates.

Che cos’è TimescaleDB (in pratica)

La cosa più importante da chiarire subito: TimescaleDB è PostgreSQL.

Non è un fork, non è un database “a parte”, non ti costringe a un linguaggio proprietario. È un’estensione, esattamente come accade con PostGIS (geospaziale) o pgvector (embedding).

Conseguenze pratiche molto concrete:

continui a usare SQL
continui a usare i tuoi strumenti: migration framework (Django/Rails/Prisma), pooler, pg_dump, monitoraggio
l’installazione a livello database è banale: CREATE EXTENSION ...

Un dettaglio operativo spesso sottovalutato: l’estensione va abilitata per database. Se crei un nuovo database, devi eseguire di nuovo CREATE EXTENSION lì.

Perché le serie temporali stressano Postgres (anche quando Postgres è “abbastanza”)

I workload time-series hanno alcuni tratti ricorrenti:

i record arrivano continuamente (append-heavy)
la maggior parte dei dati storici non cambia
le query filtrano quasi sempre un intervallo di tempo
dashboard e report fanno spesso le stesse aggregazioni su finestre temporali simili

Esempi classici: richieste HTTP, prezzi finanziari, sensori IoT, log applicativi, metriche di pipeline/AI agent, ecc.

PostgreSQL gestisce dataset grandi, ma con una event table che cresce senza sosta emergono costi sempre più visibili:

indici “attivi” molto grandi → più I/O e più manutenzione
cancellare dati vecchi → lavoro di cleanup (vacuum, bloat, ecc.)
dashboard che “scansiona la storia” → ricalcoli ripetuti e costosi

Postgres offre già strumenti (ad esempio partitioning), ma TimescaleDB aggiunge tre leve pensate specificamente per questo scenario:

gestione automatica dei chunk (partizionamento time-oriented gestito dal motore)
storage colonnare / compressione (in base alla configurazione)
continuous aggregates (aggregazioni incrementali mantenute nel tempo)

L’idea non è “magia”: è ingegnerizzare i pattern più comuni delle serie temporali in modo robusto e ripetibile.

Continuous aggregates: la differenza tra “calcolare” e “leggere”

La logica è semplice:

se la tua dashboard chiede “per ora” o “per giorno”, probabilmente non vuoi raggruppare ogni volta la tabella eventi
vuoi una vista/materializzazione che contenga già: conteggi, medie, min/max, ecc.

Il tema però è la manutenzione:

il primo calcolo “storico” può richiedere tempo (ed è normale)
poi serve un meccanismo affidabile per refresh incrementali man mano che arrivano nuovi record (e, in alcuni casi, quando cambi regole o dati)

TimescaleDB rende questo aggiornamento time-aware: l’obiettivo è evitare di “rifare tutto da zero” quando ti basta aggiornare solo l’ultima finestra temporale.

Risultato: query di dashboard che restano reattive anche quando la tabella eventi cresce in modo aggressivo.

Nota importante: i numeri (1,6s vs 10ms) dipendono da schema, hardware, distribuzione dei dati, filtri, ecc. Quello che conta è il meccanismo: meno lavoro a query-time.

Il dataset “tipo”: una riga per richiesta HTTP

Uno scenario estremamente comune per ragionare su time-series è una tabella che rappresenta un access log “strutturato”:

time: timestamp dell’evento (la colonna più importante)
campi “chi/cosa”: server, dominio, sessione, URL
esito: status code
performance: durata (latenza)
contesto: geografia, user agent, bytes, ecc.

La chiave: una riga per evento, potenzialmente milioni o miliardi.

Tutto quello che farai in analisi parte quasi sempre da:

1) filtrare un intervallo temporale
2) raggruppare
3) calcolare aggregati

Il “20% di SQL” che copre l’80% dell’analisi time-series

1) Date arithmetic con `interval`

Filtrare “ultime 24 ore”, “ultimi 7 giorni”, “ultimi 15 minuti” dovrebbe essere naturale. In PostgreSQL lo è:

timestamp - interval '24 hours'
timestamp - interval '7 days'

Sono valori tipizzati, non stringhe “finte”. È un dettaglio che fa la differenza nella qualità delle query e nella leggibilità.

2) `GROUP BY` per impilare eventi in “pile”

Il salto mentale utile: gli aggregati non si calcolano “per riga”, ma per gruppo.

Esempio tipico: raggruppare per status per capire quante 200/404/500 hai visto e con quale latenza media.

3) Aggregazioni condizionali con `FILTER`

Quando vuoi più contatori in una sola passata sui dati (totale, errori 5xx, not found 404, ecc.), FILTER è spesso più leggibile (e in genere più efficiente) rispetto a CASE WHEN ... ripetuti.

È anche il modo più pulito per derivare metriche come error rate senza lanciare query multiple.

4) Percentili: utilissimi, ma costosi se “esatti”

La latenza media spesso racconta una storia rassicurante. Il P95/P99 racconta quella vera per gli utenti peggiori.

In PostgreSQL, i percentili esatti richiedono ordinamento dei valori (ORDER BY all’interno dell’aggregazione). Su poche migliaia di righe è ok; su decine/centinaia di milioni può diventare un problema serio.

Qui la lezione pratica è: misura e valuta alternative approssimate quando la scala cresce.

Tipi dati che contano davvero in questi schemi

Tre scelte ricorrenti fanno la differenza nel tempo:

timestamptz: preferiscilo sempre a timestamp “senza time zone”. timestamptz rappresenta un momento assoluto e si adatta al fuso del client in output. timestamp invece è un orario “da parete”, ambiguo.
jsonb: perfetto per attributi rari/long-tail che non meritano una colonna dedicata, con possibilità di indicizzazione.
uuid: utile per identificatori robusti e distribuiti, ma ha implicazioni interessanti su indici e locality (tema che in dataset grandi emerge presto).

La skill che sblocca tutto: leggere `EXPLAIN`

Se devi portarti a casa una sola competenza “operativa” quando lavori su performance, è questa.

EXPLAIN mostra il piano previsto (senza eseguire)
EXPLAIN ANALYZE esegue e mostra cosa è successo davvero
EXPLAIN ANALYZE BUFFERS aggiunge quanta memoria/pagine sono state toccate

Quest’ultimo è sottoutilizzato, ma spesso è quello che ti dice la verità: non solo “quanto ci ha messo”, ma quanta roba ha dovuto leggere.

E soprattutto ti aiuta a distinguere:

sequential scan: legge molte righe per trovare quelle utili
index scan: salta più direttamente alle righe rilevanti

Nelle serie temporali, dove quasi tutto è filtrato per tempo, capire quando stai ancora scansionando troppo (e perché) è metà del lavoro.

Sintesi: cosa cambia davvero con TimescaleDB

Per dati time-series, il punto non è “Postgres è lento”. Il punto è che certi pattern diventano inevitabilmente costosi quando:

la tabella eventi cresce continuamente
le dashboard ricalcolano sempre gli stessi aggregati
retention e manutenzione iniziano a pesare

TimescaleDB resta dentro Postgres (stesso SQL, stessi strumenti), ma aggiunge primitive mirate: chunk management, ottimizzazioni di storage, e soprattutto continuous aggregates per trasformare query di dashboard da “calcola su milioni di righe” a “leggi un riepilogo mantenuto aggiornato”.

L’implicazione pratica è chiara: se stai costruendo osservabilità, telemetria, metriche di prodotto o qualsiasi sistema che vive di grafici per intervalli temporali, vale la pena progettare da subito pensando a pre-aggregazione time-aware e a un workflow di misurazione basato su EXPLAIN (ANALYZE, BUFFERS)—prima ancora di inseguire micro-ottimizzazioni o indici “a tentoni”.

Articolo originale: https://frontendfacile.it/blog/timescaledb-quando-postgresql-incontra-le-serie-temporali-senza-smettere-di-esse

Dal codice scritto dagli agenti alla produzione in pochi minuti: un workflow moderno con Vercel

frontendfacile.it — Thu, 24 Sep 2026 11:14:59 +0000

Branch deploy, AI SDK e un approccio “agent-first” per ridurre il tempo tra idea, prototipo e impatto reale.

L’adozione di coding agents sta cambiando la geografia del lavoro frontend (e non solo). Quando la capacità di generare codice aumenta di un ordine di grandezza, il vero rischio è spostare il collo di bottiglia altrove: review infinite, ambienti di test incoerenti, deploy lenti, prototipi che non arrivano mai nelle mani giuste.

In uno scenario “agent-first”, la domanda pratica diventa: come porto in produzione (o almeno in preview) il codice prodotto dagli agenti in minuti, mantenendo controllo e qualità? La risposta, sempre più spesso, è un workflow costruito attorno a deploy effimeri, branch preview e automazioni che rendono il ciclo “idea → verifica → rilascio” il più corto possibile.

L’obiettivo: ingegneri con più agency, non solo più codice

Quando hai agenti che sfornano feature, refactor e fix, non ti serve soltanto velocità di output. Ti serve:

Agency: ogni ingegnere deve poter spingere un’iniziativa fino all’impatto, senza dipendere da mille passaggi intermedi.
Affidabilità: l’aumento della velocità non deve tradursi in instabilità.
Consegna rapida: il deploy deve essere parte del flusso, non un evento.

Questa impostazione cambia anche il modo in cui si pensano le applicazioni interne: se i team usano agenti per costruire automazioni e strumenti, serve una piattaforma che renda il shipping banale e ripetibile.

Perché i branch deployments diventano il centro del workflow

Il punto di svolta, per molti team, è spostare la prototipazione su branch deployments.

In pratica, ogni branch diventa un ambiente di esecuzione autonomo, con un URL condivisibile. Questo abilita tre cose fondamentali:

Prototipazione immediata: una feature generata da un agente può essere provata subito, senza “integrazioni obbligate” nel trunk.
Feedback mirato: chi deve validare (PM, designer, stakeholder interni) non legge PR, prova direttamente l’interfaccia.
Iterazione rapida: si riduce l’attrito nel passare dal “quasi pronto” al “pronto davvero”.

Quando l’obiettivo è arrivare dal 80–90% al 99–100% di qualità percepita, la differenza la fa spesso la capacità di iterare su dettagli, edge case e UX: avere preview affidabili accelera proprio quel tratto finale.

Deploy come infrastruttura per l’adozione degli agenti

Un punto interessante dei workflow moderni è che gli agenti non sono solo “generatori di feature”. Possono diventare anche:

manutentori guidati, che propongono fix contestuali
refactor assistant, che migliorano leggibilità e coerenza
strumenti di automazione interna, capaci di eliminare lavori ripetitivi

Ma tutto questo vale solo se il percorso per mettere online quel codice è lineare. Se ogni deploy richiede passaggi manuali, permessi, sincronizzazioni e rituali, la produttività guadagnata con gli agenti evapora.

Vercel, in questo tipo di architettura, viene spesso scelta proprio perché rende il deploy un’operazione “di default”: push → build → preview → validazione.

Incidenti e produzione: quando gli agenti entrano nel loop operativo

C’è un altro fronte, meno discusso ma molto concreto: l’operatività.

Quando un sistema di alert segnala un problema in produzione, la parte costosa non è solo il fix, ma il context switching:

capire cosa è successo
raccogliere log e segnali
formulare ipotesi
identificare la regressione
proporre remediation

Qui entra in gioco un pattern emergente: usare uno swarm di agenti per il triage e la remediation, orchestrati tramite un SDK dedicato (come il Vercel AI SDK). L’idea è far lavorare più agenti in parallelo su:

raccolta e sintesi dei segnali
analisi della causa probabile
proposta di patch o mitigazione
preparazione di output utili per l’ingegnere che approva e rilascia

Il risultato atteso è una riduzione netta del Mean Time To Resolution (MTTR): non perché “gli agenti risolvono tutto da soli”, ma perché riducono drasticamente il tempo necessario a orientarsi e convergere su un intervento.

Implicazioni pratiche per team frontend

Se stai progettando un workflow simile, questi sono i punti che contano davvero:

Preview per ogni branch come standard: deve essere immediato condividere una build funzionante.
Validazione rapida del valore: il deploy non serve solo a “rilasciare”, ma a capire se un’idea merita di diventare prodotto.
Automazioni interne come primo cittadino: strumenti e micro-app interne devono poter essere create e iterate con la stessa facilità del prodotto principale.
Operazioni assistite: integrare agenti nel flusso incidentale (triage/remediation) riduce il costo cognitivo dell’on-call.

Sintesi: la velocità non è scrivere codice, è spedirlo bene

Con i coding agents, la produzione di codice non è più la risorsa scarsa. Lo diventano deploy, validazione e iterazione. Un setup basato su Vercel — con branch deployments e integrazione di agenti anche nei flussi operativi — sposta il focus su ciò che conta: trasformare output “quasi pronti” in soluzioni affidabili, provabili e distribuibili in tempi molto brevi.

L’implicazione più interessante è organizzativa prima che tecnica: quando il deploy è semplice e la preview è immediata, ogni ingegnere può davvero lavorare con un livello di autonomia e impatto superiore, senza sacrificare controllo e qualità.

Articolo originale: https://frontendfacile.it/blog/dal-codice-scritto-dagli-agenti-alla-produzione-in-pochi-minuti-un-workflow-mode

33 ore, 8 milioni e una lezione scomoda: cosa insegna il “quasi-ribaltone” in Automattic

frontendfacile.it — Thu, 24 Sep 2026 11:09:58 +0000

Governance, controllo del voto e infrastrutture critiche: quando WordPress non è solo un CMS, ma un pezzo di economia del web.

Automattic è una di quelle aziende che, per chi lavora nel frontend, spesso resta sullo sfondo: la incontri indirettamente attraverso WordPress.com, WooCommerce, Tumblr, o più banalmente perché WordPress alimenta ancora una fetta enorme del web. Proprio per questo, quando succede qualcosa ai suoi vertici non è solo gossip da tech industry: è un segnale su come potere, governance e infrastruttura possano intrecciarsi in modi poco rassicuranti.

Nelle ultime settimane l’azienda ha vissuto un episodio surreale per velocità e costo: un tentativo di sostituire il fondatore alla guida, concluso in poco più di un giorno con il ritorno del fondatore stesso e una conseguenza immediata — oltre 8 milioni di dollari in buonuscite dovute a due dirigenti rimossi dopo appena 33 ore.

Al di là dei dettagli, la storia è utile perché porta a galla tre temi che impattano chiunque costruisca prodotti sul web: (1) cosa significa davvero “il board conta più del CEO”, (2) quanto può valere il controllo del voto, (3) perché possedere un’infrastruttura critica cambia il peso di ogni decisione.

1) Il board può “licenziare” un CEO… ma non sempre può cambiarne il destino

In moltissime aziende tech la regola implicita è semplice: il board of directors sta sopra al CEO. Se il CEO prende decisioni ritenute dannose (strategie legali aggressive, gestione reputazionale disastrosa, scelte che deprimono la valutazione), il board ha leve per intervenire.

Nel caso Automattic, il board ha effettivamente provato a rimuovere il fondatore dalla carica di CEO, promuovendo il CFO al ruolo di CEO e presentando pubblicamente il passaggio come ordinato e condiviso.

Fin qui, scenario “da manuale”. Il punto è che il manuale cambia completamente quando la struttura dei voti è sbilanciata.

2) Se controlli la maggioranza del voto, un “cambio di CEO” può durare quanto un deploy annullato

Il dettaglio che trasforma una crisi in un boomerang è questo: il fondatore detiene una quota enorme del potere di voto (si parla dell’84%). In pratica, anche se il board vota la rimozione, chi controlla il voto può:

sostituire i membri del board;
nominare un board allineato;
farsi reintegrare rapidamente.

È esattamente il tipo di architettura di governance che rende possibile un rientro “lampo”. E qui c’è una lezione che va oltre Automattic:

nelle aziende con voto concentrato, gli organi di controllo possono essere reali solo finché il controllore principale lo accetta.

Per chi lavora nel prodotto, questo ha una conseguenza pratica: la stabilità decisionale non dipende solo da processi e organigrammi, ma dalla distribuzione del potere contrattuale.

3) Quando in 33 ore si firmano buonuscite: gli incentivi contano più delle intenzioni

La parte economicamente più significativa dell’episodio è anche la più istruttiva: durante la finestra in cui due dirigenti hanno gestito l’azienda, sarebbero stati preparati accordi di uscita che prevedevano condizioni estremamente favorevoli in caso di licenziamento (stipendio annuale, copertura sanitaria, vesting immediato delle azioni).

Risultato: al ritorno del fondatore e al conseguente licenziamento dei due dirigenti, l’azienda si ritrova con un conto da oltre 8 milioni.

Non è solo una cifra impressionante: è un promemoria su come, nelle crisi, gli incentivi e le tutele contrattuali diventino una variabile di primo livello. Quando i ruoli cambiano rapidamente, chi ha il tempo (e l’autorità temporanea) di firmare cose, spesso lo fa.

Per un team tecnico questo si traduce in un punto molto concreto: nelle fasi di instabilità al vertice, la probabilità di decisioni irreversibili (contratti, policy, licenze, accessi, deleghe) sale.

4) Open source, controllo operativo e “punto singolo di influenza”

C’è poi un livello ancora più delicato: l’ecosistema WordPress non è solo un prodotto, è una rete di distribuzione.

Quando parliamo di update, plugin e temi, la dipendenza non è astratta: migliaia di installazioni “tirano” componenti e aggiornamenti da snodi centrali. Se una parte di questa infrastruttura critica è legata a decisioni e proprietà personali, il rischio non è teorico.

Questa tensione (open source vs controllo operativo) esiste da anni in tanti progetti: puoi avere codice aperto e comunità attiva, ma se:

la governance è fortemente centralizzata;
le leve operative (accessi, canali, infrastrutture, domini) sono in poche mani;

…allora il sistema è tecnicamente aperto, ma politicamente fragile.

Per chi sviluppa prodotti su WordPress (o su qualunque piattaforma/marketplace), la domanda pratica è sempre la stessa:

quanto è sostituibile la dipendenza?
esiste un piano B per aggiornamenti, distribuzione, continuità operativa?

Implicazioni pratiche per chi fa frontend e lavora con WordPress (o con piattaforme simili)

Non serve fare doomscrolling sulla governance per trarne valore. Basta trasformare l’episodio in checklist operative:

Riduci il lock-in della supply chain: dove possibile, pipeline di deploy e aggiornamenti sotto controllo del team (mirror, policy di pinning, staging robusto).
Gestisci aggiornamenti come change management: niente auto-update “ciechi” su produzione senza canary/staging, soprattutto per plugin critici.
Traccia dipendenze e criticità: sapere quali plugin sono “core business” e chi li mantiene è risk management, non paranoia.
Piano di emergenza: backup reali, procedure di rollback testate, alternative documentate.

Sintesi: il costo reale non sono gli 8 milioni

L’episodio colpisce per la cifra e per la rapidità — 33 ore possono bastare per bruciare milioni — ma la lezione più utile è un’altra: la tecnologia non vive in un vuoto.

Governance, controllo del voto e proprietà delle infrastrutture determinano quanto un ecosistema sia prevedibile. E per chi costruisce interfacce, ecommerce, contenuti e prodotti sopra piattaforme dominanti, prevedibilità significa una cosa sola: rischio misurabile.

Quando quel rischio cambia improvvisamente, non lo risolvi con un nuovo framework: lo risolvi con architettura, processi e un minimo di strategia di indipendenza.

Articolo originale: https://frontendfacile.it/blog/33-ore-8-milioni-e-una-lezione-scomoda-cosa-insegna-il-quasi-ribaltone-in-automa

Swipe to remove sul web moderno: un’implementazione fluida con Scroll Snap, Intersection Observer e Web Animations

frontendfacile.it — Wed, 23 Sep 2026 10:53:39 +0000

Come costruire un gesto “swipe per rimuovere” stabile, performante e cross‑browser senza finire in codice fragile e animazioni a scatti.

Costruire un gesto di swipe per rimuovere (tipico delle app mobile) in un’interfaccia web è uno di quei compiti che sembrano semplici finché non ci sbatti contro: gestione del touch, soglie, inertia, conflitti con lo scroll, animazioni che “saltano” e mille edge case.

Un approccio più solido consiste nel smettere di “simulare” la fisica a mano e appoggiarsi il più possibile a primitive native della piattaforma. Una combinazione particolarmente efficace è:

CSS Scroll Snap: per rendere naturale il gesto di trascinamento e l’aggancio a posizioni predefinite.
Intersection Observer: per capire in modo affidabile quando l’utente ha “superato la soglia” di rimozione.
Web Animations API: per animare in modo fluido la rimozione (collasso, fade, slide out) senza layout thrashing.

Di seguito un modello mentale e una struttura che puoi adattare a liste, inbox, carrelli, notifiche.

1) Il pattern: uno “snap” tra stato normale e stato rimuovi

L’idea è costruire ogni riga come un piccolo contenitore scrollabile orizzontalmente con due “pagine”:

Stato normale: la card/item principale.
Stato azione: area a destra (o sinistra) che rappresenta l’azione di rimozione.

Con scroll-snap l’utente trascina, il browser gestisce inerzia e decelerazione, e l’item “aggancia” in modo prevedibile.

Struttura HTML indicativa

<li class="row">
  <div class="swipe">
    <div class="pane pane--content">
      <!-- contenuto dell’item -->
      <h3>Messaggio</h3>
      <p>Anteprima...</p>
    </div>

    <button class="pane pane--remove" type="button" aria-label="Rimuovi">
      Rimuovi
    </button>
  </div>
</li>

CSS: scroll-snap “a pagine”

.row {
  list-style: none;
}

.swipe {
  display: grid;
  grid-auto-flow: column;
  grid-auto-columns: 100%;

  overflow-x: auto;
  overscroll-behavior-x: contain;
  scroll-snap-type: x mandatory;
  -webkit-overflow-scrolling: touch;
  scrollbar-width: none;
}

.swipe::-webkit-scrollbar { display: none; }

.pane {
  scroll-snap-align: start;
}

.pane--remove {
  display: grid;
  place-items: center;
  background: #d92c2c;
  color: white;
  border: 0;
}

Con questa base ottieni già una gesture utilizzabile: trascinamento orizzontale, snapping e un’area “Rimuovi” raggiungibile.

2) La soglia di rimozione con Intersection Observer

Il passo successivo è determinare quando considerare l’azione “confermata”. Puoi farlo in due modi tipici:

Swipe fino allo snap dell’area remove → rimuovi automaticamente.
Swipe parziale → mostra l’azione e richiedi un tap su “Rimuovi”.

Per evitare calcoli manuali basati su scrollLeft e dimensioni (fragili con font, zoom, RTL, layout responsive), puoi usare un sentinel osservato.

Esempio: inserisci un piccolo elemento “marker” all’inizio della seconda pagina (remove) e osserva quando entra sufficientemente in view.

<div class="pane pane--remove">
  <span class="sentinel" aria-hidden="true"></span>
  Rimuovi
</div>

.sentinel {
  width: 1px;
  height: 1px;
}

const swipeEls = document.querySelectorAll('.swipe');

swipeEls.forEach((swipeEl) => {
  const sentinel = swipeEl.querySelector('.pane--remove .sentinel');
  if (!sentinel) return;

  const io = new IntersectionObserver(
    (entries) => {
      for (const entry of entries) {
        // entry.isIntersecting + threshold gestiscono la “soglia”
        if (entry.isIntersecting && entry.intersectionRatio >= 0.6) {
          swipeEl.dispatchEvent(new CustomEvent('swipe:readyToRemove', { bubbles: true }));
        }
      }
    },
    {
      root: swipeEl,
      threshold: [0.6],
    }
  );

  io.observe(sentinel);
});

Questa soluzione è robusta perché:

non dipende da frame-by-frame JS durante il drag;
delega al browser la parte complessa (scroll + inertia);
rende semplice cambiare la soglia (es. 0.5, 0.7) senza rifare matematica.

3) Rimozione fluida con Web Animations API (senza reflow a raffica)

Quando decidi di rimuovere l’item, l’effetto “giusto” non è solo farlo sparire, ma:

dare feedback (fade/slide);
collassare lo spazio nella lista in modo elegante.

Una sequenza comune:

anima l’opacità e un leggero translate;
poi anima l’altezza da offsetHeight a 0.

document.addEventListener('swipe:readyToRemove', async (e) => {
  const swipeEl = e.target.closest('.swipe');
  const row = e.target.closest('.row');
  if (!row || !swipeEl) return;

  // evita doppi trigger
  if (row.dataset.removing === 'true') return;
  row.dataset.removing = 'true';

  // 1) feedback visivo
  await row.animate(
    [
      { opacity: 1, transform: 'translateX(0px)' },
      { opacity: 0, transform: 'translateX(-8px)' }
    ],
    { duration: 160, easing: 'ease-out', fill: 'forwards' }
  ).finished;

  // 2) collasso
  const h = row.offsetHeight;
  row.style.height = `${h}px`;
  row.style.overflow = 'clip';

  await row.animate(
    [ { height: `${h}px` }, { height: '0px' } ],
    { duration: 180, easing: 'ease-in', fill: 'forwards' }
  ).finished;

  row.remove();
});

Nota: per accessibilità e controllo, spesso conviene non rimuovere automaticamente al primo superamento soglia, ma richiedere conferma (tap su bottone) o offrire undo. Il pattern sopra è un buon “motore” su cui costruire queste scelte di UX.

4) Compatibilità e fallback: cosa fare quando manca una feature

Le primitive citate sono in gran parte ben supportate. Dove tipicamente sorgono problemi:

comportamenti specifici legati allo scroll (es. particolari proprietà CSS meno diffuse);
differenze di feeling tra browser su inerzia e snapping.

Strategia pratica:

Progressive enhancement: se scroll-snap-type non è disponibile, mantieni un’interazione base (tap su “Rimuovi”).
Feature detection in CSS e JS:
- CSS: @supports (scroll-snap-type: x mandatory) { ... }
- JS: controlli su API ('IntersectionObserver' in window, 'animate' in Element.prototype)
Alternative semplici: se manca Web Animations, passa a transizioni CSS; se manca Intersection Observer, degrada a controllo scrollLeft su scrollend (o un debounce su scroll).

L’obiettivo non è inseguire la perfezione identica ovunque, ma garantire:

gesto naturale dove supportato;
comportamento coerente (niente stati bloccati);
fallback funzionale.

Sintesi: meno “gesture logic”, più piattaforma

Uno swipe-to-remove ben fatto non nasce da decine di listener touch e calcoli per-frame. La via moderna è comporre primitive native:

Scroll Snap per rendere lo swipe prevedibile e fisico “gratis”;
Intersection Observer per decidere soglie e stati in modo affidabile;
Web Animations per una rimozione fluida senza scatti.

Il risultato è un’interazione più stabile, più semplice da mantenere e più facile da far evolvere (undo, multi-azioni, layout diversi) senza trasformare ogni lista in un mini motore di gesture.

Articolo originale: https://frontendfacile.it/blog/swipe-to-remove-sul-web-moderno-un-implementazione-fluida-con-scroll-snap-inters

Opus 5.5 alza l’asticella (e abbassa i costi): cosa cambia davvero per chi sviluppa

frontendfacile.it — Wed, 23 Sep 2026 10:48:38 +0000

Prestazioni da top di gamma, prezzo in caduta e nuovi meccanismi di rate limit: l’effetto pratico su coding, UI e workflow creativi.

Negli ultimi mesi ci siamo abituati a un pattern abbastanza stabile: ogni salto di qualità nei modelli “premium” tende a portarsi dietro un conto più salato, rate limit più stretti o compromessi sull’accessibilità. Opus 5.5 rompe questo schema in modo piuttosto netto: prestazioni che lo collocano nella fascia alta (in pratica comparabile ai migliori modelli cloud “da produzione”) e costi inferiori rispetto alla generazione precedente.

Al di là dell’hype, la domanda utile per chi fa frontend è: che cosa abilita davvero, nel lavoro quotidiano? E cosa cambia nell’equilibrio tra “modello migliore” e “modello sostenibile” quando si lavora a colpi di prompt, refactor e iterazioni UI.

1) Non è solo “scrive codice”: è densità di prodotto in meno tempo

Uno dei segnali più interessanti non è il singolo snippet perfetto, ma la capacità di generare artefatti completi: esperienze interattive, prototipi giocabili, animazioni su canvas, UI con logica e stato coerenti.

In questa ondata di esempi si vede un pattern chiaro:

Single-file app non banali (anche corpose) che includono rendering, input, stato di gioco, audio/animazioni e loop di aggiornamento.
Canvas/animazioni con output “pulito”: timing, easing, gestione delle dimensioni, ridisegno efficiente.
Prototipi che sembrano “da team”, non da demo: controlli, fisica, camera, assets/texture, un minimo di architettura.

Per chi sviluppa frontend, questo si traduce in una cosa concreta: aumenta la complessità massima del prototipo che riesci a esplorare prima di decidere (o prima di coinvolgere il resto del team). Meno tempo speso a “dimostrare che si può fare”, più tempo su UX, vincoli e scelte.

Implicazione pratica

Se fino a ieri usavi il modello top solo per task ad alto valore (refactor difficili, debug di edge case, architetture), ora diventa realistico usarlo anche per:

prototipi interattivi di feature (micro-frontend, configuratori, editor);
playground canvas/WebGL e data-viz;
scaffolding di design system + esempi reali di utilizzo.

2) Benchmark: utili, ma conta “la resa” su task agentici

I benchmark restano una fotografia imperfetta. Però un punto emerge: Opus 5.5 risulta molto competitivo su task agentici e coding-oriented (quelli dove il modello deve pianificare, iterare, correggersi).

Per un frontend engineer questa è la differenza tra:

un modello che “indovina” la prima risposta e poi si perde,
e un modello che tiene il contesto, fa troubleshooting con metodo e converge.

Non è glamour, ma è ciò che incide sul tempo totale quando gli chiedi:

di riparare una regressione CSS introdotta da una refactor;
di analizzare un bug di stato in un componente complesso;
di migrare una codebase (router, store, test) senza rompere tutto.

3) Il punto vero: il prezzo cambia le abitudini

La parte più “di prodotto” di questo rilascio è la riduzione di costo. Se un modello arriva a livelli molto alti e contemporaneamente costa sensibilmente meno da eseguire, succedono almeno tre cose:

Lo usi più spesso, anche per task intermedi (non solo per “salvataggi in extremis”).
Aumenti il numero di iterazioni: più prompt, più alternative, più tentativi A/B su implementazioni.
Lo metti in pipeline: linters “intelligenti”, generatori di test, review assistita, refactor programmati.

Per il frontend moderno (dove il costo nascosto è l’iterazione continua), questo è enorme: il modello smette di essere “un consulente costoso” e diventa una parte della toolchain.

4) Accesso e velocità: quando la UX del modello diventa una feature

Oltre al costo per token, contano i limiti d’uso e la prevedibilità.

Due segnali interessanti:

Aumento dei limiti orari sui piani in abbonamento.
Introduzione di un concetto di reset “bancabile” del rate limit: in pratica, la possibilità di conservare un reset e usarlo quando serve (utile nei picchi: release, incident, refactor massivi).

Per un team, questa è una differenza concreta: invece di “sperare” che il modello sia disponibile quando ti serve, inizi a gestire l’uso in modo più razionale (quasi come si fa con i budget di CI).

5) E Fable? Più che una guerra, un riequilibrio

Quando un nuovo modello arriva “allo stesso livello” del riferimento più amato per coding, la domanda non è solo “chi è migliore”, ma:

chi è migliore per euro speso;
chi regge meglio il carico di lavoro reale (contesti lunghi, codebase sporche, vincoli di prodotto);
chi si integra meglio nei flussi quotidiani.

Se Opus 5.5 mantiene davvero questa combinazione di qualità e costo, l’effetto più probabile è un riposizionamento:

Fable resta un riferimento per certe nicchie e per chi ha già pipeline ottimizzate su quel modello.
Opus 5.5 diventa la scelta “default” per molti team che vogliono qualità alta ma sostenibile.

In altre parole: non è detto che uno “uccida” l’altro. È più realistico che cambi la percentuale d’uso, soprattutto nelle attività dove oggi si risparmia per non sforare costi.

6) Una nota sul tema “pacing” e frontiera

C’è un tema di coerenza di mercato: da un lato si parla di “rallentare la corsa” (pacing), dall’altro escono modelli più capaci e più economici.

A livello pratico, per chi costruisce prodotti, la conseguenza è semplice: la “frontiera” diventa meno un concetto astratto e più una linea di accesso:

modelli utilizzabili con guardrail e policy;
modelli più “sensibili” con accessi ristretti o capacità limitate.

Per noi sviluppatori, il tema etico e di governance resta importante, ma il segnale industriale è chiaro: la competizione si sta spostando sul rapporto qualità/prezzo e sull’esperienza d’uso, non solo sulla potenza pura.

Sintesi: cosa fare adesso, da frontend

Se lavori su UI complesse, prototipi interattivi, data-viz o tool interni, Opus 5.5 è il tipo di rilascio che cambia le abitudini perché riduce il “costo dell’iterazione”.

L’implicazione pratica è questa: ha senso trattarlo come un upgrade “di qualità” e “di budget”, e rivedere i tuoi workflow di conseguenza.

Usa i modelli top non solo per risolvere bug difficili, ma per aumentare il throughput (più varianti, più esperimenti).
Sposta nel modello task ripetitivi ma time-consuming (test, refactor guidati, migrazioni incrementali).
Valuta la toolchain con un criterio nuovo: quanto mi costa una settimana di iterazioni, non solo “quanto costa una singola risposta”.

Articolo originale: https://frontendfacile.it/blog/opus-5-5-alza-l-asticella-e-abbassa-i-costi-cosa-cambia-davvero-per-chi-sviluppa

Sviluppare software nel 2026: più codice, meno “mani”, nuove regole di affidabilità

frontendfacile.it — Tue, 22 Sep 2026 11:34:51 +0000

Gli agenti aumentano la produttività individuale, ma senza ripensare delivery e governance il risultato è solo più rumore (e più costi).

Negli ultimi 18–24 mesi lo sviluppo software ha iniziato a somigliare meno a una catena di montaggio fatta di persone e più a un sistema operativo fatto di agenti. Il cambio di passo non è solo “scrivo più velocemente”: è un cambio di scala. La quantità di codice prodotta può crescere di ordini di grandezza, e questo mette in crisi i meccanismi tradizionali con cui abbiamo governato qualità, sicurezza e delivery negli ultimi dieci anni.

In questo scenario, molte convinzioni “da manuale” iniziano a scricchiolare: la code review come collo di bottiglia virtuoso, l’onboarding dei junior tramite task semplici, la crescita della capacità tramite hiring e offshore. Funzionavano quando il costo principale era scrivere codice. Ora il costo sta diventando capire, verificare e rendere affidabile ciò che viene prodotto.

1) La produttività individuale esplode, quella organizzativa no

Con agenti e tool AI, il singolo sviluppatore (o il singolo team piccolo) può passare dall’idea al prototipo in minuti o ore. In una startup snella questo si traduce spesso in shipping reale: meno coordinamento, meno dipendenze, meno cerimonie.

Nelle aziende grandi, però, lo stesso incremento non si materializza automaticamente a livello di “azienda”:

si acquistano licenze e si consumano token;
tante persone usano AI “a lato” del lavoro;
ma metriche di output (time-to-market, qualità, costi operativi, throughput end-to-end) migliorano poco o in modo non lineare.

Il punto non è lo strumento: è il processo. Senza trasformare il modo in cui il lavoro attraversa l’SDLC, il risultato è spesso un backlog che scorre più velocemente… verso nuovi colli di bottiglia (review, compliance, QA, incidenti, debito tecnico).

2) Dalla “capacity” al “value”: cambia l’aspettativa sul delivery

Fino a poco tempo fa, molte organizzazioni compravano capacità: più persone, a costo medio più basso, per consegnare funzionalità.

Oggi la conversazione si sta spostando su due richieste molto più dure:

più valore allo stesso costo, oppure
lo stesso valore con meno persone.

Questo genera una pressione immediata su team interni e fornitori: non basta “essere pieni”, serve dimostrare che la pipeline produce outcome misurabili. In parallelo cresce un effetto collaterale: la paura di restare indietro rispetto ai competitor porta a sperimentazioni rapide e spesso poco strutturate, con adozioni di AI non dichiarate o non standardizzate.

3) Code review tradizionale: non regge l’esplosione del codice

Quando il volume di modifiche passa da “migliaia di righe a settimana” a “centinaia di migliaia”, la code review manuale perde il suo ruolo storico. Non perché sia inutile in assoluto, ma perché diventa matematicamente impossibile mantenere lo stesso livello di attenzione umana su tutto.

In più, la review umana è variabile: chiunque abbia lavorato in team grandi ha visto pull request enormi chiuse con un “LGTM” frettoloso. Con l’aumento della velocità, quel comportamento non è un’eccezione: rischia di diventare la norma.

La direzione che sta emergendo: “reliability realms”

Un approccio pragmatico è trattare i sistemi in modo diverso in base alla criticità:

core critico: cambi piccoli, revisione accurata, presenza umana più forte;
sistemi meno critici: progressiva autonomia degli agenti per valutazione, review e deploy.

Questo è interessante perché sposta la domanda da “chi approva la PR?” a “quale livello di garanzia mi serve qui, e come lo ottengo?”—un cambio mentale molto più sano per architetture moderne.

4) Se gli agenti scrivono codice, il lavoro umano si sposta su orchestrazione e governance

Quando “scrivere” non è più il collo di bottiglia, la competenza distintiva diventa:

definire specifiche verificabili (non solo desideri);
progettare guardrail (sicurezza, policy, compliance);
costruire processi agent-led che producano artefatti affidabili: test, prove, tracciabilità, rollback, osservabilità;
scegliere dove l’autonomia è accettabile e dove no.

In pratica, il team non “perde” lavoro: lo cambia. E chi guida engineering deve abituarsi a gestire sistemi che non si stancano, non vanno in ferie, non negoziano priorità—ma che possono amplificare errori e ambiguità con la stessa velocità con cui amplificano output.

5) Junior developer e apprendistato: il problema non è assumere, è creare compiti reali

C’è un segnale chiaro: i task “da junior” (pulizia, CRUD ripetitivo, pezzi marginali) sono esattamente quelli che gli agenti assorbono meglio. Questo crea un vuoto di apprendistato: meno occasioni di “imparare facendo” su lavoro produttivo.

Due conseguenze pratiche:

le aziende che vogliono formare junior devono investire: non possono più contare sul fatto che il junior sia produttivo dal giorno 1 su compiti semplici a margine del delivery.
si alza l’asticella dell’“agency”: viene premiato chi sa prendere in carico un problema end-to-end, fare domande giuste, guidare l’esecuzione con strumenti e agenti, e rendere il risultato verificabile.

Questa non è una “fine dei junior”, ma un cambiamento del loro percorso: meno manovalanza, più responsabilità guidata.

6) Selezione naturale tra senior: non basta esperienza, serve moltiplicare valore

In un mondo agentico, il senior non è prezioso solo perché “sa fare”, ma perché:

sa creare contesto e vincoli corretti;
sa costruire sistemi di verifica;
sa ridurre rischio e aumentare affidabilità mentre la velocità aumenta;
sa trasformare produttività individuale in produttività di squadra e di organizzazione.

È qui che si separano “anni di esperienza” da “capacità di moltiplicare output con qualità”.

Sintesi operativa: cosa fare in un team frontend oggi

Tratta la code review come una risorsa scarsa: riservala alle parti critiche e sposta il resto su test, policy e automazioni.
Definisci livelli di criticità (reliability realms) per componenti, servizi e pipeline: non tutto merita lo stesso rigore umano.
Riprogetta l’SDLC attorno agli agenti: specifiche, verifiche, tracciabilità e osservabilità devono essere “first-class”.
Per i junior, crea percorsi di valore: task piccoli sì, ma agganciati a risultati misurabili e con guardrail; altrimenti l’apprendistato si spegne.

La direzione è chiara: la velocità di scrittura del codice non sarà più il vantaggio competitivo. Lo sarà la capacità di trasformare quell’abbondanza in software affidabile, sicuro e sostenibile—senza far collassare processi, persone e qualità lungo la strada.

Articolo originale: https://frontendfacile.it/blog/sviluppare-software-nel-2026-piu-codice-meno-mani-nuove-regole-di-affidabilita

Progettare prodotti “AI‑native” per un’intelligenza che cresce: meno guardrail, più accesso al root

frontendfacile.it — Tue, 22 Sep 2026 11:29:50 +0000

Quando i modelli migliorano, le regole a mano diventano debito tecnico. Tre principi per costruire interfacce e architetture che scalano con l’intelligenza.

Negli ultimi due anni abbiamo visto uno schema ricorrente nei prodotti AI‑native: appena l’output del modello “non è abbastanza”, la reazione istintiva è costruire strati di controllo. Validazioni, post‑processing, SDK semplificati, workflow rigidi. Il risultato, spesso, è un prodotto che sembra più affidabile nel breve periodo.

Poi arriva un nuovo modello, molto più capace.

E succede una cosa scomoda: quello che avevamo codificato come intelligenza di dominio diventa improvvisamente rumore. A volte addirittura un vincolo che impedisce al prodotto di beneficiare del salto di qualità del modello.

Questa dinamica non è un incidente: è un pattern prevedibile.

Il problema: i guardrail “vincono” oggi e perdono domani

All’inizio, quando il modello sbaglia spesso, i guardrail sono tentatori perché:

riducono gli errori più frequenti (UI rotte, API sbagliate, asset mancanti);
rendono l’esperienza più uniforme;
permettono di “vendere affidabilità” senza addestrare modelli.

Esempi tipici (soprattutto in prodotti che generano codice o UI):

lint custom per intercettare pattern errati e rimandare feedback al modello;
post‑processing per correggere automaticamente risorse inesistenti (icone, font, nomi di componenti);
SDK semplificati per far usare feature complesse (streaming, URL corretti, tool AI) evitando gli errori più comuni;
workflow a binari (pubblicazione store, deploy, release) ridotti a una macro‑procedura.

Nel breve periodo funziona. Ma nel medio periodo emergono due effetti:

1) Ogni regola a mano invecchia: il modello impara a fare meglio proprio quell’area e i guardrail diventano ridondanti.

2) Le regole a mano diventano un tetto: quando il modello sblocca nuove capacità (nuovi framework, nuove API, nuovi paradigmi), quei limiti impediscono al prodotto di “salire di livello”.

La “bitter lesson” applicata al product design

C’è un principio che torna ciclicamente nell’AI: i metodi che scalano con compute e apprendimento tendono a superare nel tempo le soluzioni basate su conoscenza codificata a mano.

Tradotto per chi progetta prodotti:

aggiungere regole e middleware sembra intelligente all’inizio;
ma spesso blocca la crescita quando la base (il modello) fa un salto;
e psicologicamente è difficile accettare che “compute + modello” batta il nostro design accurato.

Se stai costruendo un prodotto AI‑native, la domanda non è “come rendo il modello affidabile oggi?”, ma:

Come progetto un sistema che diventa migliore automaticamente quando il modello migliora?

Un cambio di mentalità: non inseguire affidabilità, rimuovi limiti

La reliability è importante, ma c’è una provocazione utile: molta affidabilità arriva gratis aspettando il prossimo modello.

Se il tuo vantaggio competitivo è “abbiamo messo guardrail attorno a un modello generalista”, stai giocando una partita fragile: al primo salto generazionale rischi che il modello nudo superi il tuo prodotto.

L’alternativa è spostare l’ottimizzazione su un’altra dimensione:

ridurre i colli di bottiglia del prodotto;
dare accesso a capability più profonde;
togliere i soffitti artificiali che impediscono al modello di esprimersi.

In pratica: se il tuo prodotto limita framework, piattaforme, primitive di sistema o strumenti “veri” (cloud, deploy, simulatori, gateway), stai limitando l’intelligenza che vorresti vendere.

Tre regole di design per “growing intelligence”

Di seguito tre principi pratici che funzionano come bussola quando progetti agenti e prodotti che devono scalare con modelli sempre più capaci.

1) Smetti di inseguire la reliability come obiettivo primario

Non significa ignorare la qualità, ma non costruire la tua strategia sul correggere il modello.

Chiediti:

sto aggiungendo questo strato perché è indispensabile al prodotto… o perché il modello oggi sbaglia?
se domani il modello fosse 10× migliore, questo layer sarebbe ancora utile o diventerebbe un freno?

I guardrail “anti‑errore” spesso sono debito tecnico mascherato da UX.

2) Fissa un obiettivo enorme (e usalo come test di progetto)

Un obiettivo grande è uno strumento diagnostico: mette in luce dove il tuo prodotto impone limiti inutili.

Esempio di framing:

se costruisci un tool per creare app: “si può costruire un Uber completo?” (più piattaforme, più ruoli, backend vero, scalabilità);
se costruisci un editor video AI: “un regista esperto può ottenere un risultato da studio?” (togliendo dal gioco la “scusa” che l’utente non sappia cosa vuole).

Nota interessante: usare un utente “super‑competente” come riferimento aiuta a isolare il problema. Se anche l’utente sa perfettamente cosa vuole, dove si rompe il prodotto? Quella rottura è quasi sempre un limite architetturale o di design.

Con questo test emergono scelte che all’inizio sembravano ragionevoli (supportare solo una piattaforma, un solo tipo di progetto, un backend “semplice”) ma che impediscono la crescita.

3) Dai all’AI accesso al “root” (alle primitive, non ai middleware)

Questa è la regola più potente e, spesso, la più contro‑intuitiva.

Quando incapsuli tutto in livelli intermedi (SDK “friendly”, wrapper, workflow chiusi), stai dicendo:

“il mondo vero è troppo complesso, lo nascondo dietro un’interfaccia fissa”.

Ma un modello che cresce diventa sempre più bravo a gestire complessità. Quindi la strategia più scalabile è:

esporre primitive stabili (le azioni fondamentali),
e lasciare che l’AI componga le strategie sopra di esse.

Tre applicazioni concrete:

1) Gateway invece di SDK proprietari

Se oggi costruisci un SDK per gestire provider e feature AI, domani quel lavoro invecchia. Esporre un gateway (o una proxy layer minimale) e limitarsi a metering, policy e billing riduce manutenzione e rende il prodotto “future‑proof” rispetto a nuovi modelli.

2) Workflow scomposti in azioni

Pubblicare su uno store, fare release, gestire compliance: non è una funzione unica, è una sequenza piena di edge case. Invece di codificare un flow rigido, conviene esporre le azioni atomiche (upload, signing, metadata, review checks, ecc.) e lasciare che l’AI decida ordine e strategia.

3) Rimozione dei middle layer che limitano capability

Ogni “ponte” tecnologico (framework, runtime, compatibilità) può diventare un tappo. Se per ottenere feature reali serve scendere a livello nativo, l’AI deve poterlo fare senza essere bloccata da un’astrazione pensata per un modello meno capace.

Implicazioni pratiche per chi fa frontend (e prodotti)

Questi principi non sono solo infrastruttura: cambiano anche il modo in cui progetti l’esperienza.

UI come console di capability: meno wizard che impongono un percorso unico, più strumenti componibili (azioni, risorse, permessi, stato).
Osservabilità al posto di regole: se non rincorri reliability via guardrail, ti serve telemetria eccellente (errori, costi, latenza, tentativi, rollback) per capire dove intervenire.
Permessi e sicurezza come design core: dare accesso al “root” significa anche progettare sandbox, policy, rate limit, scope delle credenziali. È qui che il prodotto crea valore reale.

Sintesi: progettare per l’intelligenza che cresce

Se l’intelligenza sottostante migliora continuamente, il prodotto deve essere un amplificatore, non una gabbia.

I guardrail possono essere utili come stampelle temporanee, ma diventano rapidamente debito.
Un obiettivo grande rivela i limiti nascosti del design.
L’accesso alle primitive (root) rende il sistema più adattivo e “compatibile con il futuro”, perché sposta la complessità dove può evolvere: nel modello e nella sua capacità di pianificare.

La conseguenza pratica è chiara: costruire prodotti AI‑native oggi significa progettare meno regole e più possibilità, con un’architettura che non abbia paura dei prossimi salti di modello, ma che li trasformi automaticamente in valore per gli utenti.

Articolo originale: https://frontendfacile.it/blog/progettare-prodotti-ai-native-per-un-intelligenza-che-cresce-meno-guardrail-piu-

Oltre i componenti: come cambia la UI quando la genera un modello (e non solo il dev)

frontendfacile.it — Tue, 22 Sep 2026 11:24:49 +0000

Dallo SPA “a props” alla UI dichiarativa e fino alle interfacce davvero generative: vantaggi, limiti e un’idea più concreta del futuro.

Negli ultimi anni abbiamo visto un’accelerazione brutale: prima il flusso era “copio-incolla un componente React, lo aggiusto, ripeto”; poi siamo passati a modelli capaci di generare schermate complete con interazioni sensate e attenzione all’accessibilità. A quel punto la domanda non è più se un modello sappia costruire UI, ma come vogliamo che lo faccia — e quali garanzie servono per portare quel risultato in un prodotto reale.

Il tema interessante, oggi, non è soltanto dove vive l’interfaccia (dentro un agente “super-app”, dentro il tuo prodotto, dentro un client che integra servizi esterni). È soprattutto come viene generata: con componenti predefiniti? con una descrizione strutturata? oppure con markup e logica creati sul momento?

Qui sotto trovi i tre approcci principali che stanno emergendo, con i relativi trade-off.

1) UI a componenti statici: tool call → props → render

È la versione più vicina al frontend tradizionale.

L’agente invoca un tool (o un endpoint)
Il tool ritorna dati/parametri
Il client assembla e renderizza componenti già esistenti

In pratica è uno schema simile a quello che abbiamo sempre usato: qualcuno “a monte” prepara dati e il client li monta su UI nota. Anche quando la fonte è un agente, il rendering resta vincolato a un catalogo di componenti che hai già nel prodotto.

Pro

Affidabilità alta: UI deterministica
Accessibilità e design system sotto controllo
Debug più semplice: lo spazio di variabilità è nei dati

Contro

Flessibilità bassa: l’agente può solo “colorare dentro le righe”
Personalizzazione limitata alle varianti previste

È un buon punto di partenza, ma non risolve il desiderio di UI davvero dinamiche.

2) UI dichiarativa: l’agente scrive JSON, il client compone

Qui l’agente non decide quale componente chiamare, ma costruisce una descrizione dell’interfaccia (spesso JSON): layout, gerarchie, contenuti, parametri. Poi un renderer traduce quella descrizione in componenti reali.

Il dettaglio importante: anche qui i componenti restano predefiniti (quindi coerenti con design system e accessibilità), ma l’agente guadagna molta più libertà nel combinare struttura e contenuto.

Questo modello è parente stretto di ciò che viene spesso chiamato server-driven UI: la “pagina” non è hardcoded nel client, ma arriva come struttura dati che il client sa interpretare.

Pro

Ottimo equilibrio: creatività controllata
Stabilità: catalogo componenti governato dal team
Personalizzazione spinta senza rigenerare l’app

Contro

Sei comunque vincolato al catalogo: ciò che non esiste non può apparire
Serve progettare bene:
- schema/versioning
- fallback
- validazione
- mapping tra JSON e componenti

Se oggi dovessi scegliere un approccio “da produzione” per UI guidate da agenti, questo è spesso quello più sensato: dinamico, ma con guardrail.

3) UI pienamente generativa: il modello produce markup (e talvolta logica)

All’estremo opposto c’è l’approccio più “wow”: il modello genera direttamente HTML/CSS (e spesso anche JS) per presentare dati e flussi.

È molto utile quando l’obiettivo è consumare informazioni in modo visuale (dashboard al volo, report, spiegazioni interattive, prototipi). L’interfaccia diventa quasi “usa e getta”: viene generata per quella specifica richiesta, poi si passa oltre.

Pro

Libertà totale: non sei limitato a un catalogo
Velocità di iterazione altissima
Ottimo per visualizzazioni ad-hoc e prototipi

Contro (quelli che contano davvero)

Costo: generare UI “da zero” continuamente può essere caro
Incoerenza: senza vincoli, ogni render può variare (layout, pattern, stile)
Familiarità: gli utenti vogliono ritrovare le cose dove se le aspettano
Sicurezza: se generi ed esegui codice (JS), devi sandboxare e limitare in modo serio

Questo approccio non è “sbagliato”, ma è difficile da rendere un’interfaccia di prodotto stabile. Brilla in contesti dove l’output è temporaneo o dove la UI è un artifact che serve soprattutto a capire, esplorare, decidere.

Il punto: la UI non è solo output, è collaborazione

C’è un aspetto che spesso viene sottovalutato: la UI generata non dovrebbe essere soltanto una pagina mostrata all’utente, ma uno spazio di lavoro condiviso tra umano e agente.

Quando puoi:

spostare elementi
annotare
modificare un diagramma
fare “aggiustamenti” manuali
e poi chiedere all’agente di adattarsi a quelle modifiche

…non stai più “guardando” una UI. Stai co-progettando con un sistema.

Questa idea sposta il focus dal “render perfetto” alla ciclicità dell’interazione: il valore arriva quando l’interfaccia diventa un canvas dove l’agente e la persona iterano insieme.

Implicazione pratica per chi fa frontend oggi

Se stai costruendo UI con agenti (o prevedi di farlo), la decisione cruciale non è “componenti sì o no”, ma quali vincoli vuoi imporre e dove.

Se ti serve solidità di prodotto: UI dichiarativa + catalogo componenti è la base più pragmatica.
Se ti serve esplorazione veloce: UI generativa è potente, ma trattala come artifact, non come superficie primaria.
Se vuoi il salto di qualità: investi in collaborazione (stato condiviso, editing, feedback loop), non solo in generazione.

Sintesi

La “fine dell’era dei componenti” non significa buttare via componenti e design system. Significa riconoscere che, con i modelli, la UI può diventare una funzione del contesto: generata, adattata e negoziata in tempo reale. Il futuro credibile non è una UI che cambia casualmente a ogni prompt, ma un sistema che bilancia creatività e controllo — e che rende la collaborazione uomo-agente la nuova interazione primaria.

Articolo originale: https://frontendfacile.it/blog/oltre-i-componenti-come-cambia-la-ui-quando-la-genera-un-modello-e-non-solo-il-d

Modelli “System 1”: decisioni in millisecondi per agenti, UI e automazioni (anche in locale)

frontendfacile.it — Tue, 22 Sep 2026 11:19:49 +0000

Dalle LLM conversazionali ai modelli di classificazione a scelte finite: più veloci, più economici e spesso più affidabili quando serve decidere, non scrivere.

Nel frontend siamo abituati a ragionare in termini di eventi → stato → decisione → azione. È un ciclo semplice, ripetibile, e soprattutto misurabile. Una buona parte dell’AI “da prodotto”, però, si è infilata negli ultimi anni in un paradigma diverso: quello delle LLM che generano testo e “ragionano” a lungo.

Sta emergendo una famiglia di modelli progettata con un’idea quasi opposta: niente testo libero, niente divagazioni. Solo decisioni rapide su un insieme finito di scelte. Risultato: latenza bassissima, costi ridotti e un comportamento spesso più controllabile quando l’obiettivo non è scrivere, ma scegliere cosa fare.

System 1 vs System 2, ma in ottica prodotto

La distinzione torna utile perché descrive bene due modi di progettare l’esperienza:

System 2: più lento, deliberativo, “ragionante”. Perfetto per spiegare, scrivere, sintetizzare, fare tutoring, produrre contenuti.
System 1: veloce, istintivo, orientato alla scelta. Perfetto per classificare, selezionare un’azione, decidere tra opzioni predefinite.

Nel prodotto questo si traduce in una regola pratica:

Se il tuo flusso richiede una decisione ripetibile (click, next step, routing, label, intent), un modello “System 1” è spesso più adatto di una LLM generalista.

Cosa sono davvero questi modelli: classificazione con output strutturato

Questi modelli non “rispondono” come un chat. Lavorano tipicamente con due ingredienti:

States: lo stato corrente (testo, contesto, snapshot, metadati) in forma strutturata.
Questions: domande/decisioni definite come schema, ciascuna con:
- tipo di risposta (boolean, scelta tra classi, score)
- criteri espliciti per guidare la decisione

Il punto interessante per noi: l’output è quasi sempre JSON, con scelta finale e spesso probabilità/confidenza. Questo apre subito una porta importante: osservabilità.

Perché l’output strutturato è un game changer

Nel frontend e nelle automazioni, testo libero significa edge case continui:

parsing fragile
ambiguità
impossibilità di validare a compile-time

Con output strutturato:

validi con Zod/TypeScript
logghi le decisioni come eventi
fai fallback quando la confidenza è bassa
costruisci UI deterministiche (badge, warning, “serve conferma”)

Latenza: perché 30 ms cambiano l’UX

Quando una decisione arriva in ~30–40 ms, il modello smette di essere un “servizio remoto che aspetti” e diventa parte del loop interattivo.

È la differenza tra:

assistente (ti risponde dopo un po’)
controllore (decide mentre tu agisci)

Per un agente che controlla una UI (browser, app desktop, web app), questa latenza è cruciale: consente catene di micro-decisioni rapide, tipo:

identifica il campo giusto
decide se è già valorizzato
sceglie l’azione (click / type / open menu)
verifica lo stato successivo

…ripetendo decine di volte al secondo senza far “sentire” il pensiero.

Browser agents e frontend: la combinazione naturale

Nel mondo degli agenti browser, il problema non è scrivere testo. È:

capire cosa c’è nella pagina
scegliere dove cliccare
verificare quando fermarsi

Un modello a scelte finite si presta perfettamente a questo pattern:

“Qual è il prossimo step?” → {open_tab, fill_form, click_search, stop}
“Questo elenco contiene opzioni coerenti con la richiesta?” → {yes/no + confidence}
“Quale elemento della pagina corrisponde al target?” → {selector A/B/C}

In pratica, è un “policy model” leggero: dato uno stato, decide un’azione.

Esecuzione in locale: perché interessa davvero

L’altra implicazione enorme è che alcuni di questi modelli esistono anche in versione open weights e girano sulla macchina dell’utente (es. laptop Apple Silicon) con prestazioni sorprendenti.

Per un team frontend/prodotto questo sblocca scenari prima scomodi:

privacy: dati che non escono dal dispositivo (email, pagine interne, strumenti aziendali)
costo: automazioni continue senza bruciare budget a ogni iterazione
resilienza: meno dipendenza da rate limit e disponibilità di servizi esterni

Non è “solo” ideologia open source: è una scelta architetturale.

Come si progetta una decisione robusta (pattern pratico)

Il trucco non è chiedere “cosa ne pensi?”, ma definire bene stato, opzioni e criteri.

1) State minimale ma informativo

Inserisci solo ciò che serve per decidere:

testo (email, snippet pagina)
contesto (da dove arriva, obiettivo)
vincoli (cosa è consentito/non consentito)

2) Classi esplicite e finite

Esempio: classificare un’email per dipartimento.

Classi: billing | technical | sales | other

Più le classi sono:

mutuamente esclusive
ben definite

…più il modello performa.

3) Criteri (la parte che molti saltano)

I criteri sono “regole del gioco”. Anche una semplice booleana diventa affidabile quando definisci:

quando è true
quando è false
cosa fare in caso di ambiguità

In ottica UI, i criteri sono l’equivalente di una spec: riducono interpretazioni creative.

4) Gestione confidenza

Non trattare la scelta come “verità”, ma come segnale:

confidence > 0.9 → automatico
0.7–0.9 → automatico ma log + retry
< 0.7 → fallback (chiedi conferma, passa a un modello più potente, oppure esci)

Questo è esattamente il modo in cui progettiamo UI robuste con input incerti.

Quando NON usarli

Non sono una bacchetta magica:

se ti serve spiegazione, creatività o contenuto lungo → meglio System 2
se il task richiede ragionamento multi-step complesso → meglio un modello deliberativo (o un orchestratore)
se le classi sono mal definite o cambiano spesso → rischi instabilità e drift

L’approccio vincente spesso è ibrido:

System 2 per pianificare (pochi step)
System 1 per eseguire micro-decisioni rapide e ripetute

Implicazione pratica per chi fa frontend

Questi modelli rendono più realistico costruire:

agenti UI che non bloccano l’esperienza
automazioni “sempre attive” a costo quasi nullo
feature AI con contratti di output (JSON) che si integrano bene con TypeScript

Sintesi

I modelli “System 1” spostano l’AI dal regno del testo libero a quello delle decisioni strutturate: meno magia, più ingegneria. Per il frontend è una buona notizia, perché il nostro lavoro migliora quando l’output è validabile, misurabile e integrabile nel loop stato→azione.

La direzione è chiara: più agenti, più automazioni, più controlli locali. E quando la latenza scende a poche decine di millisecondi, l’AI smette di essere un pannello laterale e diventa parte della UI.

Articolo originale: https://frontendfacile.it/blog/modelli-system-1-decisioni-in-millisecondi-per-agenti-ui-e-automazioni-anche-in-

Jev e l’idea radicale: togliere il linguaggio ai “LLM” per avere decisioni veloci, economiche e tipizzate

frontendfacile.it — Tue, 22 Sep 2026 11:14:48 +0000

Dalla generazione di testo ai modelli “System 1”: output a schema garantito, costi minimi e un nuovo modo di integrare l’AI nelle app frontend.

Negli ultimi anni abbiamo imparato a convivere con un paradosso: i modelli generativi sono potentissimi, ma spesso sono sproporzionati rispetto al problema che dobbiamo risolvere in un’app.

Se ti serve una decisione secca — sì/no, una scelta tra opzioni, un punteggio — chiamare un modello “chat” significa pagare (in latenza e in token) un motore progettato per parlare bene, argomentare, essere utile e… riempire il silenzio. E nel prodotto questo si traduce in tre problemi ricorrenti:

Verbosity: output lunghi quando servirebbe una singola parola.
Fragilità dell’output: parsing di testo libero, JSON “quasi valido”, edge case infiniti.
Costo e latenza: soprattutto quando la decisione è in hot path (moderazione live, UI reattive, realtime).

Jev nasce esattamente come risposta a questo: non un modello che parla, ma un modello che decide.

L’idea: eliminare il linguaggio dall’interfaccia

Il punto non è che “l’AI non usa più token” (li usa), ma che non ti restituisce linguaggio naturale come prodotto finale. L’interfaccia è pensata per ottenere uno di pochi tipi di output, sempre nello stesso formato.

In pratica, la query non è una richiesta “aperta”, ma una domanda fortemente tipizzata, con un risultato che deve rispettare una delle tre forme:

choice: una scelta tra opzioni predefinite
score: un valore numerico (punteggio)
null: un esito booleano/di gating (pass/fail)

La promessa è ambiziosa: schema matching garantito, niente JSON rotto, niente “spiegoni” inutili, niente output che richiede parsing creativo. Per chi costruisce front-end e prodotti, questo cambia la qualità dell’integrazione: l’AI diventa un componente che si comporta più come una funzione pura che come una chat.

“Type-safe AI”: perché interessa davvero a chi sviluppa UI

Se fai frontend moderno, sai che “type safety” non è una mania estetica: è un modo per ridurre i bug e rendere l’evoluzione del codice meno rischiosa.

Traslato sull’AI, vuol dire:

Contratto di output stabile: l’app sa esattamente cosa aspettarsi.
Meno glue code: meno validazioni, meno fallback, meno regex.
UI più affidabile: se l’AI alimenta componenti (badge, status, gating, ranking), vuoi output prevedibile.

Un esempio tipico è la moderazione: invece di chiedere “è consentito?” e ricevere un paragrafo, chiedi una decisione null che blocca/consente. Oppure un choice per assegnare una categoria tra poche (es. safe | suspicious | block).

System 1 vs System 2: decisioni rapide, non ragionamenti lunghi

Il framing “System 1” (alla Kahneman) è utile perché chiarisce lo scopo:

System 1: veloce, istintivo, cheap → perfetto per decisioni frequenti e leggere.
System 2: lento, deliberativo, costoso → utile quando devi spiegare, ragionare, pianificare.

Nel prodotto spesso hai bisogno del primo tipo molto più spesso del secondo.

Pensa a:

classificare un input utente in tempo reale
scegliere la prossima azione di un NPC
decidere se mostrare un contenuto, bloccarlo o metterlo in review
assegnare priorità a elementi in una lista

Sono tutte cose che non richiedono un saggio, ma un verdetto.

Output tipizzato ≠ output corretto

Qui è importante non confondere robustezza del formato con verità del contenuto.

Avere uno schema garantito significa:

niente allucinazioni nella struttura (niente campi inventati, niente formati imprevedibili)

Ma non significa:

zero errori nel merito (può classificare male)

In più, il comportamento può rimanere non deterministico: stessa domanda, stesso contesto, risposta diversa in run diversi. Questo è normale in molti modelli probabilistici e va gestito a livello di prodotto.

La leva utile: confidenza calibrata

Un aspetto interessante è l’idea di restituire sempre un numero di confidenza calibrata.

La confidenza “da chat” spesso è cosmetica: il modello suona sicuro perché gli esseri umani preferiscono risposte sicure. Qui invece l’obiettivo è che un “60%” significhi davvero: in media, quando dico 60%, ho ragione circa 60 volte su 100.

Per un prodotto è oro, perché abilita pattern come:

soglie (es. accetta solo se confidenza > 0.85)
fallback (se confidenza bassa, passa a un modello più costoso, o a revisione umana)
UX adattiva (mostra “verificato” solo sopra una certa soglia)

Casi d’uso che diventano più pratici (anche nel frontend)

Se prendi sul serio un motore decisionale economico e veloce, si sbloccano integrazioni che prima evitavi per costo/latency:

Moderazione e policy enforcement in linea (prima del submit o al momento della pubblicazione).
Filtri intelligenti in UI (ranking, sorting, dedupe) guidati da score.
Routing di richieste: decidere quale pipeline usare (cheap vs premium).
Realtime: giochi, simulazioni, strumenti interattivi (decisioni per frame/tick o quasi).

Nel frontend, la differenza è che puoi trattare l’AI come un servizio che risponde con un tipo semplice, integrabile in stato e componenti senza dover “domare” testo libero.

Il punto controverso: quanto è nuovo rispetto ai classifier zero-shot?

L’idea di usare modelli per classificazione zero-shot non è nuova: da anni si estraggono probabilità su etichette/candidati e si sceglie l’opzione migliore.

Il salto (se confermato) sta più nell’insieme di scelte di prodotto e training:

interfaccia tipizzata (choice/score/null)
promessa di schema invariabile
confidenza calibrata come feature di prima classe
ottimizzazione aggressiva su costi e latenza

È anche il motivo per cui stanno comparendo implementazioni alternative che riproducono un’interfaccia simile leggendo le probabilità delle opzioni da modelli esistenti, in un singolo forward pass. Per chi sviluppa, questa dinamica è interessante perché suggerisce che il pattern potrebbe diffondersi anche oltre un singolo fornitore.

Implicazione pratica: progettare l’AI come “componente tipizzato”

Se costruisci prodotti web, la lezione più utile non è il nome del modello, ma il cambio di mentalità:

Quando ti serve generazione, usa un generatore.
Quando ti serve decisione, progetta un contratto tipizzato e chiedi solo quello.

In concreto:

Definisci poche opzioni chiare (choice) invece di domande aperte.
Introduci un punteggio (score) quando serve ranking, non spiegazioni.
Usa null/boolean per gating e policy.
Progetta soglie di confidenza e fallback fin dall’inizio.

Sintesi

Il futuro “pratico” dell’AI nelle app non passa solo da modelli sempre più bravi a parlare, ma da modelli e interfacce pensate per rispondere in modo controllabile. Tipi, schemi e confidenza calibrata portano l’AI più vicino a ciò che il software ha sempre preteso: contratti affidabili. E quando il contratto è chiaro, l’integrazione smette di essere una demo e diventa davvero prodotto.

Articolo originale: https://frontendfacile.it/blog/jev-e-l-idea-radicale-togliere-il-linguaggio-ai-llm-per-avere-decisioni-veloci-e

Harness engineering: come sono evoluti i “trucchi” che fanno funzionare davvero gli agenti

frontendfacile.it — Tue, 22 Sep 2026 11:09:48 +0000

Dal prompt singolo ai grafi di lavoro, fino a sistemi che ottimizzano se stessi: una mappa pratica delle idee che stanno ridisegnando l’infrastruttura tra modello e mondo.

Costruire agenti AI non significa “scrivere un prompt migliore”. Significa progettare un harness: tutto ciò che si frappone tra il mondo reale (utenti, file, API, database, UI, policy) e il modello (inferenzia, genera token, chiama strumenti). L’harness è l’ingegneria che rende l’AI operativa: affidabile, veloce, controllabile, integrabile.

Negli ultimi anni abbiamo visto una progressione chiara: ogni volta che il solo testo non bastava, abbiamo aggiunto struttura attorno al modello. E ogni volta che quella struttura diventava troppo complessa, abbiamo trovato un modo per farla “mangiare” al modello, oppure per delegare al modello la sua stessa ottimizzazione.

Qui metto in fila i passaggi più utili da capire — non come cronologia da museo, ma come cassetta degli attrezzi per chi costruisce prodotti agentici.

Cos’è un harness (in pratica)

Un harness è tutto ciò che sta tra “il mondo” e “il modello”:

prompt di sistema e istruzioni
esempi few-shot / template
orchestrazione (catene, loop, grafi)
tool calling, sandbox, permessi
parser, validatori, schemi
memoria (short/long-term), retrieval
policy, guardrail, auditing
telemetria, metriche, valutazioni
persino parti del decoding e dell’inference pipeline, quando vengono usate per vincolare l’output

Se un agente in produzione “automatta mezza azienda”, non è magia: è harness engineering fatto bene.

1) Dal few-shot alla “programmazione” via prompt

All’inizio i modelli non “seguivano istruzioni”: completavano testo. Il primo hack funzionale è stato rendere l’output desiderato il più probabile possibile.

Few-shot: esempi come priming

Mettere esempi prima del task serve a impostare lo stato latente: il modello riconosce pattern e li continua.

Zero-shot: istruzione diretta

A un certo punto si è capito che, spesso, un’istruzione ben scritta può portare a uno stato interno simile agli esempi. Nasce l’idea di prompt programming: non solo “chiedere”, ma progettare un input per ottenere una distribuzione di output più utile.

Implicazione pratica: prima di introdurre tool e framework, verifica se il comportamento desiderato è ottenibile con una sola variazione di framing. È la leva a costo più basso.

2) Catene: quando un prompt non basta

Quando il lavoro diventa composto (ricerca → sintesi → trasformazione → verifica), un singolo passaggio degrada.

La risposta è stata spezzare il compito in più prompt: le chains. Non è solo “più chiamate”, è progettare passaggi con output intermedi che riducono ambiguità e aumentano controllabilità.

Implicazione pratica: catene = debuggabilità. Se non riesci a spiegare perché un agente fallisce, spesso è perché stai chiedendo troppo in un passo solo.

3) Loop: ReAct e il lavoro con side effect

Con l’arrivo degli agenti “che fanno cose”, il testo non è più innocuo: produce azioni che cambiano lo stato del mondo.

Il pattern base diventa un loop:

osservazione (stato, output tool)
ragionamento (piano/decisione)
azione (tool call)
nuova osservazione

Questo è il cuore di gran parte degli agenti moderni: l’harness non genera solo testo, ma gestisce un ciclo di interazione con l’ambiente.

Implicazione pratica: se un agente è instabile, spesso non è “colpa del modello”, ma di un loop progettato male: osservazioni incomplete, azioni troppo potenti, mancanza di controlli o di criteri di stop.

4) Aumentare le dimensioni: dall’albero al “best path”

Dopo catene e loop, la naturale estensione è esplorare più alternative.

Tree of Thoughts (e varianti)

Invece di un’unica traiettoria, si generano più rami, si valuta e si sceglie.

Pro: più probabilità di trovare una soluzione corretta
Contro: costi di inference più alti (token, tool calls, tempo)

Implicazione pratica: utile quando il costo dell’errore è alto (migrazioni, refactor complessi, query delicate), meno quando serve latenza bassa.

5) Output affidabile: dal “premio in JSON” ai vincoli nel decoding

Molti team hanno provato a ottenere JSON valido promettendo ricompense testuali o minacciando retry. Funziona… finché non funziona.

Un salto di qualità arriva quando sposti l’affidabilità dalle parole alle regole:

parsing strutturato
schema validation
grammar-constrained decoding: il decoder ammette solo token compatibili con una grammatica

Qui l’inference pipeline diventa parte del harness: non “speri” nel formato, lo imponi.

Implicazione pratica: se l’output alimenta sistemi downstream (UI, DB, workflow), vincolare il decoding è spesso più efficace di qualsiasi prompt.

6) Prompt che ottimizzano prompt: hill climbing sul linguaggio

Un’altra svolta è usare i modelli per esplorare lo spazio dei prompt e migliorare una metrica.

L’idea è semplice:

definisci un obiettivo misurabile
generi varianti di prompt
valuti
tieni i migliori e iteri

Sembra banale, ma cambia la mentalità: non cerchi “il prompt giusto”, costruisci una procedura di ottimizzazione.

Implicazione pratica: appena hai una metrica affidabile (accuracy, pass rate, human rating, cost/latency), ha senso trasformare il prompting in un ciclo sperimentale ripetibile.

7) Sampling massivo e selezione: qualità via quantità

Un pattern sempre più comune: generare molte soluzioni e selezionare le migliori.

ripeti la generazione N volte
valuti con rubriche, test, esecuzione, self-check
scegli la traiettoria migliore

È un modo pragmatico per ottenere qualità senza aspettare “il modello perfetto”. Ed è anche un ponte verso sistemi che migliorano col tempo, perché le traiettorie migliori diventano dati preziosi.

Implicazione pratica: per codegen, l’accoppiata “molte candidate + test automatici” spesso batte qualunque prompt sofisticato.

8) Oltre la context window: spezzare il lavoro su più finestre

Quando i task superano i limiti del contesto, smetti di comprimere tutto in un prompt.

La strategia efficace è distribuire:

segmenti di lavoro in finestre separate
contesti “freschi” per ciascun segmento
consolidamento finale

In pratica: invece di forzare il modello in condizioni peggiori di quelle per cui è ottimizzato, lo riporti in una zona “nativa”.

Implicazione pratica: per analisi di codebase grandi, è spesso meglio pianificare una pipeline di chunking + subtask + merge, anziché aumentare il contesto e sperare.

9) Il modello “mangia” il harness: agenti che si costruiscono gli strumenti

Un cambio di paradigma: invece di progettare un harness enorme, parti minimale e lasci che il modello lo estenda.

Esempio tipico:

pochi tool fondamentali (es. eseguire comandi, leggere/scrivere file)
il modello decide come combinare, creare wrapper, definire routine

Qui sfrutti un fatto scomodo ma vero: i modelli hanno assorbito moltissima conoscenza su tool, pattern di orchestrazione e “come ci si aspetta che funzioni un agente”, perché questi pattern compaiono ovunque nei dati.

Implicazione pratica: riduci configurazione manuale e boilerplate, ma aumenta la necessità di policy, permessi, sandbox e osservabilità. Un agente che si auto-estende è potente e pericoloso se non lo contieni.

10) Prestazioni: eseguire codice mentre i token arrivano

Quando l’AI diventa commodity, la latenza diventa intollerabile: nessuno aspetta decine di secondi per il primo risultato.

Un hack interessante è speculative tool execution:

il modello inizia a generare una chiamata a tool / funzione
appena è sintatticamente valida, la esegui subito
quando il modello termina, hai già risultati pronti da reiniettare

Invece di aspettare token, sfrutti che l’esecuzione di funzioni può essere più veloce e parallelizzabile.

Implicazione pratica: se la tua UX soffre sul “time-to-first-useful-result”, valuta strategie speculative soprattutto su tool deterministicamente sicuri (letture, calcoli, query con limiti rigidi).

Tre traiettorie per capire cosa sta succedendo (e cosa progettare)

Guardando questi hack, emergono tre direzioni ricorrenti.

A) La forma del lavoro: testo → catena → loop → albero → grafo

La prossima forma naturale non è “più catene”, ma grafi di lavoro:

fan-out / fan-in
parallelismo
join e barriere
branch condizionali
retry mirati
dipendenze esplicite tra risultati intermedi

Un grafo può contenere catene e loop come casi particolari, ma offre un modello mentale più adatto al lavoro reale.

B) Il modello assorbe il harness

Sempre più spesso:

servono meno istruzioni fisse
servono più contratti (schema, policy, vincoli)
il modello può proporre (o scegliere) la strategia di esecuzione

In altre parole: meno “prompt lunghi”, più “sistemi che valutano e vincolano”.

C) La scala cresce: da una call a una “città di esperti”

Sampling, sub-agent, parallelismo, grafi: la tendenza è amplificare la capacità tramite molte istanze coordinate, non solo tramite un modello più grande.

Cosa significa per chi costruisce prodotti (frontend e non solo)

Se stai integrando agenti in strumenti reali (IDE, ticketing, Slack/Teams, dashboard interne), le implicazioni pratiche sono abbastanza nette:

Tratta il prompting come UI/UX del ragionamento, ma non come unica leva.
Metti struttura dove serve affidabilità: schema, parsing, vincoli nel decoding.
Preferisci grafi a catene monolitiche quando il task ha dipendenze e parallelismo.
Progetta metriche e telemetria: senza segnali chiari, non ottimizzi nulla; “hill climbing” richiede feedback.
Contieni la potenza: sandbox, permessi, rate limit, audit. Più l’agente è autonomo, più l’harness deve essere robusto.

Sintesi finale

L’harness engineering è l’arte di trasformare un generatore di testo in un sistema che lavora: osserva, decide, agisce, verifica e migliora. La storia recente mostra un pattern ripetibile: quando un approccio si satura (prompt), aggiungiamo struttura (catene/loop/grafi), poi rendiamo quella struttura ottimizzabile (hill climb), e infine deleghiamo parte della progettazione al modello stesso — mantenendo però vincoli e metriche sempre più rigorosi.

Se c’è una regola pratica che vale oggi: meno fiducia cieca nell’output, più ingegneria attorno al processo. È lì che gli agenti diventano prodotti.

Articolo originale: https://frontendfacile.it/blog/harness-engineering-come-sono-evoluti-i-trucchi-che-fanno-funzionare-davvero-gli

Agentic engineering in un contesto bancario: disciplina, repo come fonte di verità e “review del piano”

frontendfacile.it — Tue, 22 Sep 2026 11:04:47 +0000

Come progettare un flusso di lavoro che sfrutti gli agenti senza perdere controllo, qualità e tracciabilità (soprattutto quando audit e compliance non sono opzionali).

Costruire prodotti digitali in ambito fintech è un esercizio di equilibrio: da una parte la necessità di muoversi velocemente, dall’altra l’obbligo di spiegare e documentare perché una funzionalità esiste, come è stata progettata e chi se ne assume la responsabilità.

Quando aggiungi agenti AI al mix, la tentazione è trattarli come un acceleratore di codice. Ma se il tuo dominio è regolato (banking, assicurazioni, healthcare), l’acceleratore da solo non basta: serve un sistema operativo del prodotto che mantenga disciplina, auditabilità e qualità.

Di seguito raccolgo un modello pratico per rendere l’agentic engineering “adatto alla produzione” senza trasformarlo in caos: repo come fonte di verità, specifiche e piani in chiaro, e un’idea semplice ma potente—non rendere deterministico l’agente, rendi disciplinato il processo.

Determinismo vs disciplina: l’obiettivo non è “controllare l’AI”, è controllare il flusso

Nella vita reale neanche gli esseri umani sono davvero deterministici: due persone che implementano la stessa feature difficilmente produrranno lo stesso identico codice. Il punto, quindi, non è pretendere output identici, ma costruire un processo affidabile.

“Affidabile” in questo contesto significa:

specifiche chiare e verificabili
decisioni tracciate
cambiamenti piccoli e revisionabili
controlli automatici e manuali nei punti giusti

Se il processo è solido, l’agente diventa un moltiplicatore. Se il processo è fragile, l’agente amplifica solo l’entropia.

Il problema classico: BRD giganteschi e responsabilità diffuse

Molte organizzazioni partono da un flusso simile:

esiste un problema di business
viene prodotto un documento (spesso enorme)
qualcuno lo “traduce” in requisiti di prodotto
i team ingegneristici devono dedurre acceptance criteria, edge case e implementazione
si rilascia, si corregge, si reitera

Questo ciclo funziona finché la complessità è gestibile. In un dominio regolato, però, si aggiunge un vincolo duro: devi poter ricostruire le decisioni. Non solo cosa hai fatto, ma perché lo hai fatto in quel modo.

Spostare il baricentro: il repository come “single source of truth”

Un passaggio chiave è decidere dove vive la verità operativa.

Documentazione e strumenti rimangono utili (wiki, tool di design, issue tracker), ma per rendere davvero produttivi team e agenti serve un punto centrale, versionato e vicino al codice.

Scelta pragmatica:

le specifiche e i piani di implementazione vivono nel repository
possono essere issue strutturate o file Markdown (ADR, RFC, spec)
ogni decisione rilevante rimane collegata a commit, PR e release

In un contesto di audit, questo cambia le regole del gioco: quando arriva una domanda scomoda (“perché questa logica calcola X così?”), hai una catena di evidenze più corta e più robusta.

Ruoli più fluidi, ma responsabilità più chiare

Un effetto collaterale interessante dell’adozione di agenti è che “i confini” tra funzioni tendono ad ammorbidirsi.

Product resta owner del problema: persona, obiettivo, vincoli, priorità.
Design resta owner della soluzione UX/UI, ma può aprire il processo: far sperimentare altri membri del team sui flussi, dentro un design system.
Engineering non è solo esecuzione: deve garantire confini, invarianti, architettura, qualità operativa.

Gli agenti aiutano a generare varianti, scenari, edge case, alternative. Ma la proprietà del risultato deve restare umana.

Qui vale una regola semplice:

Gusto, accountability e ownership restano sul lato umano.

Il resto—boilerplate, typing, refactoring ripetitivo—si può delegare con più serenità.

“Review del piano” invece di “review del mega-PR”

Uno dei punti più concreti è cambiare cosa si revisiona.

In ambienti dove la review è obbligatoria (e spesso lo è), il rischio è finire con PR ingestibili: decine di file, migliaia di righe, scarsa comprensione, alta probabilità di errori.

Un approccio più sostenibile è:

Specifiche approvate (incluse le funzioni di controllo: compliance, risk, security quando serve)
Piano di implementazione dettagliato, grande quanto basta per essere utile
Task piccoli, abbastanza granulari da essere:
- prodotti dall’agente
- revisionati da umani e/o agenti
- testati e rilasciati in modo incrementale

Il risultato è una review che valuta prima la traiettoria (piano), poi l’esecuzione (task). E questa è una differenza enorme quando vuoi velocità senza perdere governance.

Dove mettere gli umani: security, privacy e confini del rischio

Se vuoi usare agenti in produzione, la domanda “dove metto l’intervento umano?” deve avere una risposta esplicita.

Una divisione efficace è:

Agenti su parti a basso rischio e ad alto volume (es. wiring, UI ripetitiva, mapping, refactor meccanici)
Umani su:
- GDPR e trattamento dati
- security e compliance
- remediation da penetration test
- autorizzazioni, token, sessioni, confini di trust

Non perché l’agente “non sia capace”, ma perché in quei punti la responsabilità è indelegabile e la dimostrazione di controllo deve essere semplice.

Un modello a strati per ridurre il rischio (senza fermare la delivery)

Invece di discutere in modo astratto se “l’AI è sicura”, conviene strutturare una pipeline di verifiche. Un esempio realistico:

Spec umana (con vincoli e acceptance criteria)
Static checks e test (lint, typecheck, unit test)
Dynamic checks (integrazione, end-to-end, security test/DAST)
Review dell’agente (per coerenza e regressioni evidenti)
Review umana mirata (punti critici)
Release management con gate finale

Questo non è “burocrazia”: è una forma di risk budgeting. Automatizzi tutto ciò che può essere automatizzato, e conservi energie umane dove hanno impatto.

Seniority dopo gli agenti: non è (più) “sapere il framework a memoria”

L’arrivo degli agenti mette pressione su una definizione di seniority troppo legata al dettaglio sintattico.

Se il tuo valore è “conosco React Native a memoria”, il giorno in cui l’agente scrive quel codice meglio e più in fretta, ti senti spiazzato.

Ma la seniority vera inizia dove l’agente fatica:

ragionare per invarianti e confini
fare system design e threat modeling
capire perché una scelta è giusta per quel dominio
orchestrare il lavoro (umani + agenti)
alzare la qualità del team: mentoring, review, cultura operativa

In pratica: meno “abilità di digitazione”, più capacità di guidare sistemi.

Il rischio reale: la “cognitive surrender”

Il nemico non è l’AI. È la resa cognitiva: copiare/incollare output senza validazione, perché “sembra giusto”.

Questo atteggiamento esisteva già (ricette trovate online, snippet non compresi), ma gli agenti lo rendono più pericoloso perché l’output è più convincente.

L’antidoto è culturale e processuale:

chiedere sempre prove (test, metriche, reasoning, trade-off)
rendere obbligatorio il collegamento tra spec → piano → task → PR
misurare la qualità (defect rate, lead time, rollback) invece di misurare “righe prodotte”

Sintesi: agenti sì, ma dentro un sistema che regge

Un’adozione efficace dell’agentic engineering non parte dal prompt perfetto: parte dal modello operativo.

Se vuoi portare questo approccio nel tuo team già da domani, l’implicazione pratica è chiara:

sposta specifiche e piani nel repository
rendi piccole le unità di cambiamento
revisiona il piano prima del codice
automatizza i controlli, ma mantieni umani sui punti di rischio
ridefinisci la seniority come capacità di design, governance e responsabilità

Gli agenti possono aumentare la velocità. La disciplina aumenta l’affidabilità. In un prodotto reale—e soprattutto in un dominio regolato—servono entrambe.

Articolo originale: https://frontendfacile.it/blog/agentic-engineering-in-un-contesto-bancario-disciplina-repo-come-fonte-di-verita

DEV Community: frontendfacile.it

TimescaleDB: quando PostgreSQL incontra le serie temporali (senza smettere di essere PostgreSQL)

Il problema reale: la dashboard non dovrebbe ricalcolare sempre tutto

Che cos’è TimescaleDB (in pratica)

Perché le serie temporali stressano Postgres (anche quando Postgres è “abbastanza”)

Continuous aggregates: la differenza tra “calcolare” e “leggere”

Il dataset “tipo”: una riga per richiesta HTTP

Il “20% di SQL” che copre l’80% dell’analisi time-series

1) Date arithmetic con interval

2) GROUP BY per impilare eventi in “pile”

3) Aggregazioni condizionali con FILTER

4) Percentili: utilissimi, ma costosi se “esatti”

Tipi dati che contano davvero in questi schemi

La skill che sblocca tutto: leggere EXPLAIN

Sintesi: cosa cambia davvero con TimescaleDB

Dal codice scritto dagli agenti alla produzione in pochi minuti: un workflow moderno con Vercel

L’obiettivo: ingegneri con più agency, non solo più codice

Perché i branch deployments diventano il centro del workflow

Deploy come infrastruttura per l’adozione degli agenti

Incidenti e produzione: quando gli agenti entrano nel loop operativo

Implicazioni pratiche per team frontend

Sintesi: la velocità non è scrivere codice, è spedirlo bene

33 ore, 8 milioni e una lezione scomoda: cosa insegna il “quasi-ribaltone” in Automattic

1) Il board può “licenziare” un CEO… ma non sempre può cambiarne il destino

2) Se controlli la maggioranza del voto, un “cambio di CEO” può durare quanto un deploy annullato

3) Quando in 33 ore si firmano buonuscite: gli incentivi contano più delle intenzioni

4) Open source, controllo operativo e “punto singolo di influenza”

Implicazioni pratiche per chi fa frontend e lavora con WordPress (o con piattaforme simili)

Sintesi: il costo reale non sono gli 8 milioni

Swipe to remove sul web moderno: un’implementazione fluida con Scroll Snap, Intersection Observer e Web Animations

1) Il pattern: uno “snap” tra stato normale e stato rimuovi

Struttura HTML indicativa

CSS: scroll-snap “a pagine”

2) La soglia di rimozione con Intersection Observer

3) Rimozione fluida con Web Animations API (senza reflow a raffica)

4) Compatibilità e fallback: cosa fare quando manca una feature

Sintesi: meno “gesture logic”, più piattaforma

Opus 5.5 alza l’asticella (e abbassa i costi): cosa cambia davvero per chi sviluppa

1) Non è solo “scrive codice”: è densità di prodotto in meno tempo

Implicazione pratica

2) Benchmark: utili, ma conta “la resa” su task agentici

3) Il punto vero: il prezzo cambia le abitudini

4) Accesso e velocità: quando la UX del modello diventa una feature

5) E Fable? Più che una guerra, un riequilibrio

6) Una nota sul tema “pacing” e frontiera

Sintesi: cosa fare adesso, da frontend

Sviluppare software nel 2026: più codice, meno “mani”, nuove regole di affidabilità

1) La produttività individuale esplode, quella organizzativa no

2) Dalla “capacity” al “value”: cambia l’aspettativa sul delivery

3) Code review tradizionale: non regge l’esplosione del codice

La direzione che sta emergendo: “reliability realms”

4) Se gli agenti scrivono codice, il lavoro umano si sposta su orchestrazione e governance

5) Junior developer e apprendistato: il problema non è assumere, è creare compiti reali

6) Selezione naturale tra senior: non basta esperienza, serve moltiplicare valore

Sintesi operativa: cosa fare in un team frontend oggi

Progettare prodotti “AI‑native” per un’intelligenza che cresce: meno guardrail, più accesso al root

Il problema: i guardrail “vincono” oggi e perdono domani

La “bitter lesson” applicata al product design

Un cambio di mentalità: non inseguire affidabilità, rimuovi limiti

Tre regole di design per “growing intelligence”

1) Smetti di inseguire la reliability come obiettivo primario

2) Fissa un obiettivo enorme (e usalo come test di progetto)

3) Dai all’AI accesso al “root” (alle primitive, non ai middleware)

Implicazioni pratiche per chi fa frontend (e prodotti)

Sintesi: progettare per l’intelligenza che cresce

Oltre i componenti: come cambia la UI quando la genera un modello (e non solo il dev)

1) UI a componenti statici: tool call → props → render

Pro

Contro

2) UI dichiarativa: l’agente scrive JSON, il client compone

Pro

Contro

3) UI pienamente generativa: il modello produce markup (e talvolta logica)

Pro

Contro (quelli che contano davvero)

Il punto: la UI non è solo output, è collaborazione

Implicazione pratica per chi fa frontend oggi

Sintesi

Modelli “System 1”: decisioni in millisecondi per agenti, UI e automazioni (anche in locale)

System 1 vs System 2, ma in ottica prodotto

1) Date arithmetic con `interval`

2) `GROUP BY` per impilare eventi in “pile”

3) Aggregazioni condizionali con `FILTER`

La skill che sblocca tutto: leggere `EXPLAIN`