Il ROI dello sviluppo web agentico: come Claude Code cambia l'economia dell'e-commerce

Ogni team e-commerce con cui ho lavorato ha da qualche parte lo stesso documento. Una lista di funzionalità evidentemente utili per il business, ordinate più o meno in base a quanto qualcuno ci crede, con forse due di queste pianificate per il trimestre.

La lista non è corta per mancanza di idee. È corta per aritmetica. Una funzionalità richiede un certo numero di giornate di sviluppo, le giornate costano, e così la maggior parte della lista resta in attesa.

Negli ultimi due anni è cambiato proprio quel secondo numero. E non di poco.

Cosa significa davvero "agentico" in questo contesto

Molti team hanno già provato il completamento automatico del codice tramite AI, quello che suggerisce la riga successiva mentre si scrive. È davvero utile per velocizzare la digitazione. Non incide sul budget, perché la digitazione non è mai stata la parte costosa.

Claude Code funziona in modo diverso. È uno strumento agentico, che in pratica significa che accede all'intero codebase e agisce invece di suggerire. Se si descrive un bug, individua la causa nel codice e applica una correzione. Se si descrive una funzionalità, pianifica l'approccio, modifica tutti i file necessari, esegue la suite di test, corregge eventuali errori e restituisce un branch per la revisione.

Si può eseguire dal terminale, da un'estensione nativa per VS Code o plugin JetBrains, da un'app desktop o dal browser. Funziona anche senza interfaccia in CI tramite la modalità print (claude -p), un aspetto più rilevante di quanto sembri — ci torneremo.

Un esempio concreto: da quindici giorni a due

Le percentuali di produttività non aiutano ad approvare un budget, quindi ecco un caso specifico e piuttosto comune: un modulo "Acquistati insieme di frequente" nella pagina prodotto, con prezzo bundle automatico, logica che tiene conto dello stock e aggiunta al carrello con un clic.

Niente di complicato. La maggior parte degli store lo desidera. Molti non lo hanno, per motivi noti.

Il metodo tradizionale — circa 15 giorni lavorativi

• Giorni 1–2 · Analisi. Qualcuno legge il codice esistente di catalogo, carrello e prezzi per capire come interagiscono varianti, imposte e sconti.
• Giorni 3–4 · Specifica. Specifica tecnica, decisioni sul modello dati, passaggio al design, stima.
• Giorni 5–9 · Backend. Query di raccomandazione, nuovo endpoint, regole di prezzo bundle e interazione con le promozioni esistenti.
• Giorni 10–12 · Frontend. Componente, stati responsive, gestione caricamento ed errori, integrazione con il carrello.
• Giorno 13 · Test. Di solito la prima cosa che si taglia se la stima sfora.
• Giorno 14 · QA e bugfix. Varianti esaurite, multi-valuta, prezzi comprensivi di imposte.
• Giorno 15 · Deploy. Monitoraggio e documentazione.

Due o tre persone coinvolte in tre settimane di calendario. Ai normali costi orari, sia in agenzia che in azienda, questa è una funzionalità da cinque cifre, ed è esattamente il motivo per cui resta ancora in lista.

La stessa cosa con un agente — circa 2 giorni.

Primo giorno, mattina. Qualcuno scrive una specifica completa: regole di business, logiche di prezzo, casi limite rilevanti. Claude Code legge il codice e propone un piano — quali file intende modificare, come si integra con la logica del carrello esistente, dove individua i rischi. Si corregge il piano prima che venga scritto codice. Questi novanta minuti sono la fase a maggior valore dell’intero progetto, ed è tutta valutazione umana.

Primo giorno, pomeriggio. Il lavoro procede in parallelo. Claude Code offre diversi strumenti integrati: subagent che gestiscono task specifici e riportano l’esito, agent view per gestire sessioni in background, workflow dinamici per attività più ampie e worktree che assegnano a ogni sessione una propria checkout git, così il lavoro parallelo non entra in conflitto sugli stessi file. Esiste anche una modalità sperimentale agent teams con lista task condivisa, disabilitata di default e da considerare ancora in fase iniziale.

Un flusso di lavoro sull’endpoint e la logica di prezzo, uno sul componente frontend, uno sui test. L’analisi, che manualmente richiedeva due giorni, ha impiegato circa venti minuti, perché l’agente ha letto il codice invece di doverlo imparare.

Secondo giorno, mattina. Revisione. Qui si concentra ora il tempo dell’ingegnere senior: verifica della logica di prezzo rispetto alle regole reali di promozione, controllo di cosa accade se un articolo del bundle esaurisce durante la sessione, verifica del trattamento fiscale. Le correzioni vengono restituite in pochi minuti.

Secondo giorno, pomeriggio. QA, staging, deploy. Test e documentazione sono già presenti, perché produrli ha richiesto un costo quasi nullo.

Dove sono finiti i tredici giorni

Vale la pena analizzarlo, perché spiega tutto il cambiamento:

• Archeologia del codice. Un agente legge il codice molto più velocemente di una persona.
• Boilerplate — endpoint, strutture di base, gestione dello stato, errori.
• Scrittura dei test, ora così economica da non essere più opzionale.
• Documentazione, che diventa un sottoprodotto invece che un’attività a sé.
• La fase di debugging, dato che l’agente esegue i test e corregge i propri errori prima che altri vedano la branch.

E cosa non si è compresso: decidere cosa sviluppare, definire le regole e revisionare il risultato. Queste fasi restano umane. E rappresentano ora una quota molto maggiore del lavoro.

Non è solo un esercizio teorico

Rakuten — che gestisce oltre 70 attività tra e-commerce, viaggi, fintech e comunicazione — ha pubblicato i propri dati insieme ad Anthropic.

Time to market

24 giorni → 5

Riduzione

79%

Scrittura autonoma del codice

7 ore continuative

Precisione del codice

99.9%

Il dato delle sette ore si riferisce a un progetto complesso di refactoring open source gestito dall’inizio alla fine, con il 99,9% di precisione nelle modifiche al codice. Quindi, la riduzione da 15 a 2 giorni mostrata sopra è già realtà su progetti di ampia portata.

Altri risultati pubblicati sono più contenuti, dato rilevante. L’agenzia Boldare ha riportato un aumento della velocità di sprint fino al 31% in un trimestre, con l’AI coinvolta in circa il 75–85% del nuovo codice e dei test. HubSpot ha ridotto la risoluzione di problemi tecnici complessi da tre-cinque giorni a meno di un’ora, e ha usato Claude Code per accelerare una migrazione frontend durante un rebranding che altrimenti avrebbe richiesto mesi. HubSpot precisa che questi dati derivano da analisi interne su implementazioni selezionate e sono da considerarsi illustrativi.

Il volume è il punto, non il risparmio

Ecco l’aspetto che spesso sfugge nelle discussioni sui costi.

Prenda uno sviluppatore che lavora su funzionalità di questa dimensione. A quindici giorni ciascuna ne consegnerà circa sedici all’anno. Con una media di tre giorni per funzionalità — alcune più rapide, altre meno — il numero si avvicina a ottanta.

Legga questi dati come rapporto, non come previsione di capacità. Nessuno sviluppatore dedica 240 giorni l’anno solo a nuove funzionalità: ci sono manutenzione, incidenti, riunioni, ferie. Entrambe le righe sono sovrastimate dalla stessa ipotesi, quindi il rapporto tra loro resta valido anche se nessun numero reggerebbe su una sprint board reale. E ottanta funzionalità l’anno sono più di quante la maggior parte dei team possa revisionare in modo adeguato, un vincolo su cui tornerò.

Nessun cambiamento nell'organico. Il budget resta invariato. Cambia solo il numero di tentativi a disposizione.

Questo è rilevante perché l’ottimizzazione della conversione è, in sostanza, un problema di ricerca. Nessuno sa in anticipo quale modifica farà davvero la differenza. Lo si scopre solo mettendo in produzione e misurando; il team che può permettersi più tentativi trova la soluzione migliore prima.

Consideri cosa può improvvisamente permettersi di sviluppare un negozio:

• Notifiche di riassortimento per ogni variante non disponibile
• Un configuratore di bundle o un modulo "completa il look"
• Gestione autonoma di resi e cambi, riducendo i ticket al supporto
• Guide alle taglie con dati reali di vestibilità, che in genere abbassano la frequenza di reso
• Dati strutturati su tutto il catalogo per risultati di ricerca più ricchi
• Una wishlist che invia email in caso di ribasso prezzo
• Ottimizzazione della velocità delle pagine sui template che ne hanno più bisogno
• Miglioramenti al checkout ospite e recupero carrelli abbandonati con segmentazione corretta
• Strumenti interni per la gestione dei prezzi, così i merchandiser non devono più aprire ticket per modificare le regole

Presi singolarmente sono piccoli interventi, ciascuno con un impatto frazionario. Insieme, nell’arco di un anno, si sommano — ed è proprio la somma che la vecchia struttura dei costi impediva. Se ogni attività richiede quindici giorni, quella lista occupa più anni di roadmap. Se ne bastano tre, si parla di pochi trimestri.

Vale la pena rifletterci: un concorrente che esegue quattro esperimenti a trimestre contro i suoi dodici non è tre volte più lento. Impara tre volte più lentamente, e questo divario non si colma con nuove assunzioni.

Tre aspetti oltre la pura velocità

Il contesto architetturale non va perso con le persone

Quando un ingegnere esperto lascia, la perdita più costosa è spesso il contesto, non il codice — cioè il motivo per cui certe scelte sono state fatte. Claude Code aiuta con un file CLAUDE.md nella root del progetto, dove annotare decisioni architetturali, librerie preferite, convenzioni e standard di sicurezza. Ogni sessione lo consulta, così il codice generato segue le regole interne invece di schemi generici.

È un modo concreto per rendere persistente il giudizio di un senior. Riduce anche i tempi di onboarding, perché chi entra può interrogare direttamente la base di codice invece di passare settimane a ricostruire le intenzioni.

Gestisce la complessità lato server, non solo le interfacce

Scetticismo comprensibile da parte di molti CTO: va bene per il rendering dei componenti, ma le parti che tolgono il sonno? In realtà, l’agente è più utile proprio lì, dove leggere codice non familiare costa di più. Mappare regole di instradamento ordini multi-regione. Preparare una coda di background per gestire un import massivo di catalogo. Capire perché una promozione si somma in modo errato su tre servizi diversi. Sono problemi di contesto, non solo di scrittura.

Lavoro che procede senza supervisione diretta

Poiché funziona in modalità headless con claude -p, può essere integrato in GitHub Actions o in qualsiasi pipeline CI e collegato agli eventi già presenti: ad esempio, all’apertura di una pull request per garantire una prima revisione automatica, oppure quando una build fallisce, così l’errore viene già analizzato prima che qualcuno riceva l’alert. Oltre a questo: audit settimanali di dipendenze e sicurezza, sincronizzazione della documentazione dopo i merge. Le routine pianificate girano in cloud, indipendentemente dal fatto che il portatile di qualcuno sia acceso.

Si tratta di una categoria di attività che prima richiedeva una persona dedicata o, più spesso, restava scoperta.

Cosa pianificare con realismo

Tre fattori determinano se otterrà i risultati descritti sopra o solo un test poco soddisfacente.

La revisione diventa il vincolo. La generazione si è fatta economica; la revisione no. Un pattern ricorrente è un forte aumento di produttività nelle prime settimane, seguito da un calo quando il codice viene rilasciato più velocemente di quanto il team riesca a revisionarlo, costringendo a rifare le stesse funzionalità. Se aumenta l’output senza intervenire sul processo di revisione, si sposta il collo di bottiglia invece di eliminarlo. Rafforzi i gate CI e la revisione automatica prima che il volume cresca, non dopo — abbiamo documentato la policy di code review che adottiamo per i cambiamenti generati dall’agente e gli standard di sicurezza da cercare nel PHP generato.

L’adozione superficiale non dura. I team che definiscono come lavorano — mantenendo un CLAUDE.md, pianificando prima di scrivere codice, regole chiare su cosa può modificare l’agente senza supervisione — mantengono i benefici. Dove si lascia tutto all’iniziativa dei singoli, si vede un picco seguito da un lento ritorno alla situazione iniziale. È un cambiamento di processo, non solo l’acquisto di uno strumento.

La qualità delle specifiche diventa il limite. Quella consegna in due giorni è possibile solo perché qualcuno ha scritto una buona specifica. Istruzioni vaghe portano a risultati sbagliati, ma prodotti con sicurezza. La competenza scarsa si sta spostando dalla scrittura del codice alla capacità di definire con precisione cosa serve, e questo va considerato sia nelle assunzioni sia nella crescita interna.

Dove la porta questa situazione

Il modo utile di inquadrare la questione internamente non è «possiamo spendere meno per la stessa roadmap». È che una roadmap che prima avrebbe giudicato irrealistica ora merita una valutazione concreta dei costi.

Entrambe le letture sono legittime. La seconda, però, è quella che di solito si riflette nei ricavi.

Valutare i costi di una roadmap che prima sembrava irrealistica?

Questo è il nostro approccio. Se ha un backlog bloccato dai numeri, possiamo indicare quali parti sono ora raggiungibili con i nuovi parametri — per noi è sviluppo AI e ML e sviluppo e-commerce; la pagina servizi AI applicata copre il resto di ciò che gestiamo in produzione. Ci contatti.