sviluppo

Claude, e sei subito sviluppatore

di Gianluca Simonini ·
Claude, e sei subito sviluppatore

Claude, e sei subito sviluppatore

C'era un'epoca in cui bastava uno slogan. Compra questo, e sei subito qualcun altro. Bevi quel caffè e sei già un uomo di mondo, indossa quelle scarpe e corri come un campione. Funzionava perché vendeva una scorciatoia: il risultato senza il percorso.

Oggi quello slogan lo scrivo in un terminale. Apro Claude Code, descrivo cosa mi serve, e in qualche minuto ho codice che gira. Non un prototipo da buttare: codice strutturato, con i suoi test, la sua gestione degli errori, la sua documentazione. Un'attività che ieri richiedeva una giornata oggi ne richiede mezz'ora. E sei subito sviluppatore.

La parte entusiasmante è vera, e va detta senza ipocrisie. La distanza tra l'idea e la cosa che funziona si è accorciata in modo che chi fa questo mestiere da trent'anni fatica a metabolizzare. Lo scaffolding di un'app, l'integrazione con un web service, lo script che normalizza tremila righe sporche, il refactoring di un modulo legacy: tutto il lavoro che era attrito puro — necessario ma privo di valore intellettuale — semplicemente evapora. Quello che resta è il pensiero: cosa voglio costruire, e perché. Non è poco. È quasi tutto.

La storia che abbiamo già visto

Solo che questa storia, in parte, l'ho già vissuta. Era la metà degli anni Novanta e Microsoft mise un database relazionale dentro Office. Si chiamava Access, e fu una piccola rivoluzione silenziosa. Improvvisamente non servivano più un analista, un DBA e tre mesi di progetto per avere un gestionale: bastava il responsabile di magazzino con un pomeriggio libero e un po' di pazienza. Maschere, query, report, tutto con il mouse. La produttività in azienda esplose. Reparti interi cominciarono a risolversi i problemi da soli, senza aspettare l'IT.

E poi, qualche anno dopo, arrivò il conto.

Perché tutti quei file .mdb non erano scomparsi. Si erano moltiplicati. Stavano sui desktop, sulle cartelle condivise, su floppy dimenticati in un cassetto. Erano diventati critici per il business — la fatturazione girava lì dentro, le commesse, le anagrafiche clienti — ma nessuno sapeva chi li avesse scritti, come, con quali regole. Erano scatole nere che funzionavano finché funzionavano. L'IT li scopriva sempre nello stesso momento: quando si rompevano. Senza documentazione, senza un proprietario, senza nessuno in grado di metterci mano. La velocità di ieri era diventata il debito tecnico di oggi.

Il rovescio della velocità

Ecco il punto che lo slogan non racconta mai. La scorciatoia ti dà il risultato, ma ti toglie il percorso — e il percorso era anche il luogo dove imparavi a governare quel risultato.

Quando il codice lo scrivi tu, riga per riga, lo conosci. Sai dove sono i compromessi, sai cosa hai lasciato indietro, sai dove guardare quando alle due di notte qualcosa si rompe. Quando il codice te lo genera un'intelligenza artificiale in trenta secondi, hai un artefatto che funziona ma che non hai costruito. La domanda non è più "so scriverlo?", ma "so cosa ho appena accettato?".

E qui i nodi vengono al pettine in fretta. Il codice si accumula a una velocità che la nostra capacità di revisione non regge. Si introducono dipendenze che nessuno ha valutato. Si replicano pattern senza capire se siano quelli giusti per quel contesto. Si delega all'AI non solo la scrittura, ma — di soppiatto — anche le decisioni architetturali, che sono la cosa che meno si dovrebbe delegare. E soprattutto si genera, di nuovo, shadow IT: applicazioni nate fuori da ogni governance, che diventano critiche prima ancora che qualcuno se ne accorga. Gli .mdb del 2026 sono repository pieni di codice che nessuno ha davvero letto.

La velocità, da sola, non è una virtù. È un moltiplicatore. Moltiplica la disciplina di chi ne ha, e moltiplica il disordine di chi non ne ha. Lo strumento amplifica te: se porti metodo, ne esce metodo accelerato; se porti improvvisazione, ne esce caos su scala industriale.

Dove sta la differenza

Non è un invito alla prudenza luddista — sarebbe ridicolo, e tra l'altro non ci credo. Claude Code è uno degli strumenti più potenti che abbia avuto in mano in trent'anni di carriera, e chi non lo usa oggi parte già svantaggiato. Il punto è un altro: la differenza non la fa più saper produrre. Quello, in larga parte, è risolto. La differenza la fa saper governare ciò che produci.

Cosa entra in produzione e con quali criteri. Chi ne è il proprietario. Come viene documentato, testato, manutenuto. Quali decisioni restano umane perché toccano il rischio, la sicurezza, il dato. Tutto ciò che negli anni Novanta nessuno fece con gli Access — e di cui pagammo le conseguenze per un decennio.

Lo slogan diceva: e sei subito sviluppatore. È vero. Il mestiere però non era mai stato scrivere il codice. Era decidere quale codice meritava di esistere, e prendersene la responsabilità. Quella parte, per fortuna, non te la genera nessuno.


Ti contattiamo noi?

Se vuoi capire come ERPNext può risolvere le sfide raccontate in questo articolo, prenota una demo dedicata.

Altri articoli