La risposta di Copilot Workspace

In un team di prodotto che funziona, le issue non arrivano scritte in pseudocodice con i casi limite già identificati. Arrivano come descrizioni funzionali, spesso vaghe, con screenshot allegati, riproduzioni parziali del bug e aspettative implicite che lo sviluppatore deve ricavare dal contesto.

È il lavoro quotidiano di chiunque abbia mai operato in un team misto tecnico-prodotto. Rappresenta una delle frizioni più costose in termini di tempo: il back-and-forth tra chi ha scoperto il problema e chi deve risolverlo.

La domanda interessante, nel contesto degli agenti AI per lo sviluppo, non è se GitHub Copilot Workspace e Claude Code riescono a implementare un requisito tecnico ben specificato. Su quello abbiamo già dati sufficienti per dire che entrambi gli strumenti si comportano ragionevolmente bene. La domanda è cosa succede quando il requisito è ambiguo, scritto da qualcuno che non conosce il codebase, con dettagli mancanti che uno sviluppatore esperto colmerebbe con l'esperienza e un agente deve gestire in qualche modo.

Per questo confronto ho usato una issue reale, anonimizzata, proveniente da un progetto React con backend Node.js. L'ho assegnata a Copilot Workspace e a Claude Code nelle stesse condizioni, senza modifiche e senza prompt aggiuntivi oltre al testo della issue stessa.

La issue: testo originale senza modifiche

Il filtro date nel report esportazioni non funziona bene
Aperta da marta.bianchi · Product Manager · 3 giorni fa · Label: bug

Ciao, ho notato un problema con la pagina dei report. Quando uso il filtro per le date e scelgo un intervallo tipo "dal 1 novembre al 30 novembre", nell'export Excel che scarico ci sono anche record di ottobre e qualche volta anche di dicembre.

Ho fatto la prova più volte e non è sempre uguale. A volte vengono fuori solo i record giusti, a volte no. Sembra peggio quando ci sono tanti dati.

Ho allegato due screenshot: uno in cui il filtro funziona e uno in cui vengono fuori record sbagliati. I dati nell'export sono ordinati per data ma alcune date sembrano fuori posto.

È urgente perché il cliente usa questi export per la fatturazione mensile e ha già trovato errori nel report di ottobre.

È una issue tipica: descrive un comportamento osservato, non una causa. Contiene informazioni utili perché sappiamo che il comportamento è non deterministico, peggiora con grandi volumi, riguarda sia l'interfaccia che l'export. Non dice però nulla sull'implementazione, su dove vive il codice del filtro, su come vengono gestite le date internamente. Per un developer esperto, "a volte vengono fuori record sbagliati" e "peggio quando ci sono tanti dati" sono segnali che puntano verso un problema di timezone, di paginazione o di gestione dell'offset nelle query. Si tratta però inferenze, non fatti.

Come ha risposto Copilot Workspace

Copilot Workspace ha letto la issue e ha prodotto quasi immediatamente un piano di implementazione strutturato in passi, con le modifiche ai file proposte in anticipo rispetto all'esecuzione. Il piano era visivamente ordinato e dava l'impressione di una analisi sistematica. Il problema è emerso guardando nel dettaglio cosa aveva deciso di fare.

Copilot Workspace aveva identificato come causa principale un problema nel componente React del date picker. Ha poi trovato nel codebase un componente DateRangePicker e proposto di modificare come venivano passate le date al componente padre.

"Ho identificato il problema nel componente DateRangePicker. Le date vengono passate senza normalizzazione, il che può causare inclusione di record adiacenti all'intervallo selezionato. Ho proposto di usare startOfDay e endOfDay da date-fns per garantire che l'intervallo sia sempre inclusivo dei giorni selezionati."

Ecco le modifiche proposte:

// PRIMA — DateRangePicker.jsx
const handleDateChange = (dates) => {
  const [start, end] = dates;
  onDateChange({ start, end });
};
// DOPO — modifica proposta da Copilot Workspace
const handleDateChange = (dates) => {
  const [start, end] = dates;
  onDateChange({
    start: start ? startOfDay(start) : null,
    end: end ? endOfDay(end) : null,
  });
};

La modifica non è sbagliata in senso assoluto. Normalizzare le date all'inizio e alla fine del giorno è una pratica corretta quando si gestiscono intervalli. Ma è una risposta a una causa ipotetica che Copilot Workspace aveva assunto senza verificarla. Il vero problema, che emerge guardando il codice del backend nel repository, era altrove: la query di export usava un confronto diretto su un campo timestamp with time zone di PostgreSQL senza tenere conto che i timestamp erano salvati in UTC mentre il frontend passava date nel timezone locale dell'utente.

Il componente React non era il colpevole.

Copilot Workspace non aveva cercato il codice del backend che generava l'export. Non aveva aperto il file della query. Aveva trovato il componente più ovviamente correlato al termine "filtro date" e aveva proposto una modifica lì, senza esplorare la catena completa dal componente React alla query SQL.