Ho dato a Claude un'app e gli ho chiesto di comportarsi come quattro diversi sviluppatori senior: ecco cosa è successo.

Online, soprattutto su X, abbondano le affermazioni che promettono di rendere i chatbot più efficaci. Quando mi sono imbattuto per la prima volta in una serie di affermazioni di David Max , un esperto di formazione sull'IA , ero scettico, ed è proprio questo che mi ha spinto a metterle alla prova. Queste affermazioni promettono di trasformare Claude in qualsiasi cosa, da un debugger esperto a un esperto di performance. Ecco cosa è successo quando ho deciso di indagare. Se siete interessati ad altre affermazioni efficaci, potete dare un'occhiata a " 7 affermazioni efficaci per Claude 4 per sviluppare le vostre idee e aumentare la vostra produttività".

Visualizza il mio strumento di monitoraggio delle spese domestiche su Claude

Avevo già creato un sistema di monitoraggio delle spese generico con segnaposto per le singole voci utilizzando ChatGPT Work, quindi l'ho usato e poi ho chiesto a Claude di rivedere l'applicazione per quattro volte. Ogni volta, gli ho assegnato un diverso ruolo ingegneristico principale: ingegnere full-stack, ingegnere di debug, ingegnere frontend e ingegnere delle prestazioni.

Il risultato è stato molto più rivelatore del semplice chiedere a Claude di "migliorare l'app". Ogni personaggio si è concentrato su una serie diversa di problemi, e a volte ha persino portato alla luce criticità che il precedente "sviluppatore" aveva trascurato. Ecco cosa è successo e le affermazioni che hanno fatto.

1. L'applicazione è stata sviluppata dall'ingegnere Full-Stack senior.

Tutto è iniziato con la richiesta di Claude di creare un'app interattiva per tenere traccia delle spese domestiche, utilizzabile da chiunque. Per saperne di più sulle capacità di Claude nello sviluppo di app, leggi " Ho creato 3 app in pochi minuti usando Claude e Gemini: ma una di queste ha una funzione nascosta ".

La sfida: creare un tracker interattivo delle spese domestiche che chiunque possa utilizzare per registrare e comprendere le proprie uscite. Dovrebbe includere la possibilità di aggiungere ed eliminare spese, assegnare categorie, filtrare le transazioni, calcolare la spesa totale e visualizzare una ripartizione grafica delle categorie.

Immagina di essere un ingegnere full-stack senior che sviluppa un MVP (Minimum Viable Product) ben rifinito per una startup. Prima di scrivere qualsiasi riga di codice, fornisci una breve descrizione dell'architettura, della struttura dei dati e del flusso utente. Quindi, crea l'applicazione come artefatto cloud.

Assicurati che sia reattivo e facile da usare, ma non perdere tempo a rivedere, eseguire il debug o migliorare il codice finale. Delegherò questi compiti ad altri sviluppatori.

Claude ha creato un'app React sorprendentemente ben rifinita. Includeva transazioni di esempio, totali di spesa, classifiche per categoria, funzionalità di ricerca e filtro e la possibilità di ordinare le transazioni per data. Inoltre, salvava le modifiche in modo che rimanessero disponibili anche dopo aver riaperto l'app.

A prima vista, sembrava molto più simile a un prodotto finito che a un prototipo incompleto. In alto c'erano delle schede statistiche, un modulo spese ben strutturato e delle barre colorate che mostravano quanto era stato speso in ciascuna categoria.

2. L'ingegnere senior addetto al debug ha riscontrato alcuni problemi.

Dopodiché, ho chiesto a Claude di ignorare l'apparenza e di esaminare il proprio lavoro come ingegnere di debug, preparando un'applicazione per il lancio.

La richiesta: ora, comportatevi come il capo debugger che ha ereditato questa applicazione prima del suo rilascio pubblico.

Esamina attentamente l'applicazione e il codice esistente senza alterarne la funzionalità o il design visivo. Testa i principali flussi utente e individua errori funzionali, gestione non corretta degli input, rischi di perdita di dati, calcoli errati, problemi di persistenza e casi limite.

Prima di modificare il codice, forniscimi un breve rapporto di debug che includa ciò che hai testato, ogni problema riscontrato, la causa principale di ciascun problema, la gravità di ciascun problema e la soluzione che raccomandi.

Successivamente, eseguite le riparazioni e verificate che le caratteristiche originali siano ancora funzionanti. Non ridisegnate la facciata, non intraprendete un'ampia ristrutturazione architettonica e non apportate modifiche puramente estetiche.

Il processo di debug ha portato alla luce numerosi problemi reali.

Ad esempio, il campo di input originale non era formattato correttamente. Cliccando sul pulsante "Salva transazione" il risultato era corretto, ma premendo il tasto Invio poteva non esserlo. Claude ha risolto il problema convertendo la sezione in un formato valido con un pulsante di invio.

Ha inoltre scoperto che gli utenti potevano cancellare la cronologia e salvare una transazione con informazioni sulla data non valide. Claude ha aggiunto la convalida della data, ha rafforzato i controlli per gli importi non validi e ha corretto un calcolo che faceva apparire "Alloggio" come la categoria più grande anche quando il tracker era vuoto.

Era ancora possibile eliminare definitivamente le transazioni con un solo clic. Gli errori di archiviazione rimanevano nascosti nella console per sviluppatori, il che significava che gli utenti potevano credere che le loro informazioni fossero state salvate quando in realtà non lo erano. Inoltre, Claude non aveva implementato test automatici per confermare che le sue correzioni funzionassero.

3. L'esperto ingegnere front-end ha notato un'applicazione completamente diversa.

Nel terzo round, ho chiesto a Claude di considerare il sistema di monitoraggio delle spese come un ingegnere front-end specializzato in design responsivo e accessibilità.

La richiesta: Agisci ora come un esperto ingegnere front-end specializzato in applicazioni consumer accessibili e reattive.

Rivedi il tuo attuale strumento di monitoraggio delle spese dal punto di vista di chi lo utilizza su un telefono, una tastiera o una tecnologia assistiva. Mantieni la funzionalità e l'identità visiva complessiva, ma migliorane l'usabilità e l'accessibilità.

Prima di modificare il codice, effettuate una breve analisi che includa il comportamento e la reattività del telefono cellulare, la navigazione da tastiera, l'usabilità dei moduli, l'accessibilità per i lettori di schermo, il contrasto dei colori, gli stati di caricamento e di errore, le azioni distruttive e i controlli che possono generare confusione.

Implementate quindi i miglioramenti. Assicuratevi che ogni campo di input e controllo interattivo abbia un nome accessibile, che gli stati di focus siano chiaramente visibili, che i messaggi di verifica possano essere annunciati da un lettore di schermo e che i dettagli di spesa trasmettano informazioni senza affidarsi esclusivamente a barre colorate.

Questa è stata la revisione più completa dell'esperimento.

Claude ha notato che l'app rimuoveva il bordo naturale attorno ai campi di input selezionati senza fornirne uno sostitutivo. Di conseguenza, chi navigava con la tastiera avrebbe avuto difficoltà a visualizzare il campo attivo.

È stato inoltre riscontrato che le etichette visive non erano collegate correttamente ai rispettivi campi di input, che il campo di ricerca si basava esclusivamente sul testo segnaposto e che gli errori di convalida non erano configurati per essere segnalati dai lettori di schermo.

Claude ha ripristinato gli indicatori di messa a fuoco visiva, ha collegato le etichette ai controlli dei moduli, ha aggiunto descrizioni per gli screen reader e ha aumentato il contrasto di molti elementi di testo grigio chiaro. Ha inoltre reso la barra di ricerca più flessibile sugli schermi piccoli e ha aggiunto etichette più descrittive per i pulsanti che contengono solo icone.

La cosa più importante è che questo personaggio ha scoperto un problema di cancellazione che il debugger aveva trascurato. Claude ha sostituito il pulsante di cancellazione con un solo clic con un processo di conferma in due fasi che richiede agli utenti di eliminare o conservare la transazione.

Non tutte le affermazioni erano perfette. Claude ha descritto 44 x 44 pixel come la dimensione minima dell'area di interazione tattile, ma ha ingrandito il pulsante principale di eliminazione solo fino a 36 x 36 pixel. Questo soddisfa il requisito più piccolo delle WCAG 2.2 AA, ma non la raccomandazione di 44 pixel da lui menzionata.

Tuttavia, il cambiamento di ruolo di Claude ha chiaramente modificato la sua prospettiva. Il debugger verificava se l'applicazione funzionava, mentre lo sviluppatore front-end esaminava se una persona reale potesse utilizzarla comodamente. Questo esperimento dimostra come un singolo requisito possa influenzare significativamente i risultati di Claude.

4. L'ingegnere delle prestazioni ha riconosciuto che l'applicazione non necessitava di molto aiuto.

Infine, ho chiesto a Claude di configurare un sistema di monitoraggio delle spese in grado di gestire almeno 10,000 transazioni.

La richiesta: Ora, in qualità di ingegnere senior delle prestazioni, prepara questo strumento di monitoraggio delle spese a gestire migliaia di transazioni.

Analizzare l'implementazione attuale per individuare rendering non necessari, calcoli ridondanti, ordinamento o filtraggio inefficienti, colli di bottiglia nello storage, crescita della memoria e interazioni che potrebbero rallentare con l'aumentare delle dimensioni dei dati.

Non dare per scontato che ci sia un problema di prestazioni. Crea un metodo realistico per testare l'applicazione con almeno 10,000 transazioni e stabilisci un valore di riferimento per le operazioni critiche.

Implementa quindi solo i miglioramenti giustificati dall'analisi. Mantieni l'aspetto dell'app, i miglioramenti all'accessibilità e il comportamento attuale. Non dichiarare un miglioramento della velocità se non lo hai misurato o definito chiaramente come un miglioramento previsto.

Claude ha scoperto un collo di bottiglia particolarmente significativo. L'applicazione creava un nuovo oggetto di formato valuta ogni volta che visualizzava un importo. Con 10,000 righe, Claude ha misurato che questo processo richiedeva 349 millisecondi. Riutilizzando un singolo formattatore, il tempo si è ridotto a 5.2 millisecondi, un miglioramento che, secondo i calcoli di Claude, è stato di ben 67 volte.

Claude ha inoltre aggiunto una funzionalità di "virtualizzazione delle tabelle", il che significa che il browser visualizzerà solo le transazioni attualmente visibili sullo schermo, anziché migliaia di righe contemporaneamente. Gli aggiornamenti di ricerca e archiviazione sono stati ritardati di una frazione di secondo per evitare costose ripetizioni dopo ogni pressione di un tasto o modifica rapida.

Claude ha persino aggiunto dei pulsanti in grado di generare 1,000, 10,000 o 50,000 transazioni di esempio per i test di stress.

Ma la parte più interessante del rapporto era l'ammissione di Claude che la maggior parte di questi miglioramenti non erano necessari per lo scopo previsto dell'applicazione.

Una famiglia tipica potrebbe aggiungere tra le 30 e le 50 transazioni al mese. Anche dieci anni dopo, Claude concluse che l'applicazione originale avrebbe probabilmente gestito i dati risultanti senza problemi significativi. A parte la memorizzazione nella cache del formattatore di valuta, la maggior parte dei miglioramenti si rivelò utile solo perché avevo richiesto specificamente il supporto per migliaia di transazioni.

Questa moderazione (o autocontrollo) è sembrata più "matura" e "professionale" rispetto al semplice apportare modifiche per il gusto di poterlo fare.

La mia conclusione finale

Ho trovato queste affermazioni estremamente efficaci, poiché ognuna ha messo chiaramente in luce i punti di forza e di debolezza di Claude. Ogni ruolo ha offerto una prospettiva di valutazione unica, che ho trovato molto utile e che sicuramente applicherò nelle mie future recensioni di altre app e siti web.

Mentre l'ingegnere addetto al debug ha individuato comportamenti errati, l'ingegnere front-end ha riscontrato problemi di accessibilità e usabilità. L'ingegnere delle prestazioni, d'altro canto, ha valutato le implicazioni dell'aumento del volume dei dati e ha riconosciuto quando l'ottimizzazione non era necessaria.

L'esperienza ha anche dimostrato perché utilizzare un'unica richiesta generica come "Rendi questo pronto per la produzione" potrebbe non essere l'approccio migliore. Una singola revisione potrebbe trascurare questioni importanti, anche se la richiesta sembra esaustiva. Suddividere il lavoro in fasi mirate ha ridotto il numero di priorità da affrontare per Claude e ha reso più facile la valutazione dei risultati.

Tenete presente i limiti di utilizzo del cloud. La prossima volta, potrei provare a combinare i suggerimenti per evitare di raggiungere il limite massimo consentito.

---

---