In questo articolo Indice dei contenuti 2 sezioni
Il confronto diretto tra Copilot Workspace e Claude Code su uno stesso task di debugging restituisce un risultato che spiazza solo in parte, perché la distanza vera tra i due agenti non sta nella qualità del codice JavaScript prodotto, corretto in entrambi i casi, ma nel modo in cui ciascuno reagisce davanti a un’informazione mancante. È lì che le due filosofie si separano, e si vede bene osservando come viene affrontata l’ambiguità di una issue scritta senza tutti i dettagli necessari.
Due modi opposti di reagire all’incertezza
Copilot Workspace ha trattato l’ambiguità come un ostacolo da rimuovere. Ha cercato nel codebase la risposta più plausibile, l’ha adottata e ha tirato dritto, senza però dichiarare da nessuna parte l’assunzione fatta. L’output finale sembra completo, ordinato, pronto. Il problema è che poggia su una premessa che nessuno ha verificato.
Per chi usa Copilot Workspace come acceleratore su attività che già padroneggia, questo comportamento non crea particolari grattacapi. Lo sviluppatore sa già dove guardare e delega all’agente la parte meccanica del lavoro. Il discorso cambia quando la diagnosi è parte integrante del compito, perché in quel caso l’assunzione silenziosa diventa un rischio concreto.
Claude Code ha fatto l’opposto. Ha considerato l’incertezza come un segnale da comunicare, non da nascondere. Ha continuato a esplorare il codebase anche oltre il primo punto di contatto ovvio, ha individuato più cause possibili e ha chiesto le informazioni che mancavano prima di proporre qualsiasi soluzione. Il prezzo è un giro in più di interazione, nello specifico i due chiarimenti sul timezone, ma il ritorno è una diagnosi corretta e una correzione che risolve davvero il problema descritto nella issue.
Chiedersi quale dei due gestisca meglio l’ambiguità, a questo punto, è una domanda senza risposta universale. Dipende da come lo strumento viene inserito nel flusso di lavoro. Copilot Workspace nasce per un modello in cui lo sviluppatore supervisiona ogni singolo passaggio del piano prima dell’esecuzione, e in quel contesto la tendenza a fare assunzioni implicite viene compensata dalla review umana che precede ogni modifica. Claude Code è pensato invece per un’autonomia operativa maggiore, e la sua abitudine a fermarsi e chiedere riflette proprio quella libertà. Meglio una domanda in più che una modifica sbagliata propagata su dieci file.
La qualità del codice generato dai due agenti
Lasciando da parte la diagnosi e guardando solo al codice generato, il divario si assottiglia, ma non sparisce del tutto. Resta visibile in alcune aree precise.
La modifica al frontend proposta da Copilot Workspace, costruita sull’uso di startOfDay e endOfDay, era sintatticamente corretta. Mancava però qualsiasi gestione degli errori per le date non valide. E soprattutto non prendeva in considerazione lo scenario in cui l’utente seleziona solo la data iniziale senza quella finale, che nel componente già esistente era a tutti gli effetti uno stato legittimo.
Claude Code, avendo letto il codice del componente durante la sua esplorazione, quel caso limite lo aveva notato. E lo aveva gestito nella modifica al frontend, proposta in parallelo alla correzione lato backend.
Proprio sul backend la differenza si fa più netta. La modifica firmata da Claude Code risultava più completa di quella che uno sviluppatore di media esperienza avrebbe messo insieme in una prima iterazione. Il timezone trattato come parametro con un fallback previsto, per esempio, è il tipo di accortezza che di solito arriva al secondo o terzo giro di revisione, non subito.
Fonte: TecnoAndroid
