Il full-stack¹ esiste. E in molti contesti non si ferma nemmeno al software.

Ieri mi è passato sulla timeline un post che mi ha colpito. L’autore racconta di aver cambiato idea: per anni ha sostenuto che il full-stack non esiste, che chi si definisce tale stia semplicemente mentendo sulla profondità delle proprie competenze. Poi è arrivata l’AI, e con essa una rivalutazione: il trasversale possiede il contesto, la visione d’insieme, la capacità di cucire pezzi che vivono in mondi diversi. Lo specialista, invece, si ritrova affiancato da uno strumento che il suo dominio lo conosce spesso meglio di lui.

È una tesi stimolante, e coglie qualcosa di reale. Ma parte da un presupposto che vale la pena esaminare più da vicino: che il full-stack fosse, fino a ieri, una bugia.

La confusione tra profondità e ampiezza

Il problema con l’affermazione il full-stack non esiste è che mescola due concetti distinti: la profondità di competenza e l’ampiezza operativa.
Nessuno ha mai sostenuto seriamente che una singola persona possa avere la stessa padronanza tecnica di uno specialista in ogni dominio che tocca. Sarebbe una pretesa assurda. Ma tra “esperto assoluto di tutto” e “competenza operativa su tutto il ciclo di un progetto” c’è uno spazio enorme, ed è esattamente in quello spazio che vive il profilo full-stack nel senso più utile del termine.

Da sistemista, ho visto quotidianamente i danni che produce la mancanza di visione trasversale. Lo sviluppatore che scrive codice elegante ma non capisce le implicazioni infrastrutturali delle proprie scelte. Il DBA che ottimizza le query senza sapere come vengono generate dall’applicazione. Il frontend che non ha idea di cosa succede dall’altra parte della chiamata HTTP. Sono tutte ottimizzazioni locali che, prese insieme, peggiorano il risultato globale.
Il sistema non è la somma delle sue parti ottimizzate separatamente.

Il full-stack, in questo senso, non è mai stato una bugia. È stato, semmai, un’etichetta abusata da chi la usava per gonfiare un curriculum senza avere i fondamentali. Ma la categoria in sé è reale, concreta e operativamente necessaria.

L’AI sposta l’equilibrio, ma non nel modo che sembra

Il post originale sostiene che l’AI ha ribaltato i ruoli: prima vinceva lo specialista, ora vince il trasversale. È una lettura suggestiva, ma semplifica troppo.

Quello che l’AI fa davvero è ridurre il costo di accesso all’informazione verticale. Documentazione tecnica, pattern di codice, best practice di dominio: tutto questo diventa più accessibile.
Ma qui c’è un punto fondamentale: l’AI riduce il valore dell’informazione rara, non quello dell’esperienza rara.

E questo cambia molto il quadro.
Lo specialista non è prezioso perché conosce una documentazione che gli altri non hanno letto. È prezioso perché ha accumulato anni di esperienza, errori, casi limite, problemi reali, intuizioni costruite sul campo. Quel patrimonio non viene automaticamente trasferito in un prompt.
Allo stesso tempo, il vantaggio di chi ha una visione trasversale aumenta, perché diventa più facile muoversi tra domini diversi senza dover investire mesi o anni per acquisire le basi operative di ciascuno.
Ma il giudizio rimane umano.

Capire se una risposta del modello è corretta, accorgersi quando è plausibile ma sbagliata, sapere quale domanda porre e perché, richiede competenza tecnica reale, non soltanto visione d’insieme.
Un generalista senza nessuna profondità propria non saprebbe nemmeno formulare la domanda giusta, né riconoscere quando il modello sta prendendo un abbaglio in un dominio che non gli appartiene.

La vista d’insieme senza alcuna profondità verticale è cieca tanto quanto la profondità senza vista d’insieme.
L’AI amplifica il valore di chi possiede entrambe, non di chi possiede soltanto una delle due.

Quando il “full” arriva fino all’hardware

C’è però un aspetto del dibattito che quasi sempre manca, probabilmente perché chi lo conduce opera in un mondo in cui tutto comincia e finisce nel software.
In certi contesti – sistemi embedded, prototipazione, automazione industriale, elettronica applicata, IoT non banale – lo stack non termina al livello del sistema operativo o del framework.

Scende fino al silicio.

Ho lavorato a progetti in cui non bastava conoscere il software, il sistema operativo, la rete e l’architettura applicativa. Bisognava anche progettare l’hardware su cui tutto questo girava: scegliere i componenti, disegnare lo schema elettrico, capire le caratteristiche di pilotaggio di un attuatore, tenere conto dei vincoli termici, meccanici e di consumo.
Interfacciarsi con sensori che comunicano su bus seriali non standardizzati. Scrivere firmware che rispetti vincoli real-time imposti dalla fisica del sistema. Diagnosticare problemi che possono nascere da una pista su un PCB, da un alimentatore sottodimensionato o da una temporizzazione errata.

In questi contesti, il “full-stack” non è una metafora.
È una descrizione letterale di uno stack che comprende livelli che nel dibattito mainstream spesso non vengono nemmeno nominati.
E qui emerge una differenza fondamentale rispetto al software puro: la realtà fisica non negozia.

Puoi convincere un modello linguistico che il codice sia corretto. Non puoi convincere un motore passo-passo a girare se la corrente di pilotaggio è sbagliata.
Puoi ottenere una spiegazione plausibile da un’AI. Non puoi ottenere che un sensore restituisca dati sensati se hai sbagliato il progetto dell’interfaccia elettrica.

Nei sistemi che interagiscono con il mondo fisico, la realtà è il bug tracker definitivo.
Per questo la visione trasversale non è un optional: è la precondizione necessaria affinché qualsiasi cosa funzioni.

Il generalista competente, non il jolly tuttofare

Tornando al punto di partenza: il full-stack esiste, ed esiste da molto prima dell’AI.
Quello che l’AI ha fatto è renderlo più visibile e più prezioso in contesti in cui prima veniva sottovalutato.

Ma c’è una distinzione che vale la pena fare con precisione.
Il profilo utile non è quello del jolly tuttofare, capace di un po’ di tutto ma padrone di niente.
È quello del generalista competente: qualcuno che conosce abbastanza bene molti domini – non per sentito dire, ma per averci messo le mani – da poter dialogare con tutti, individuare i problemi sistemici, prendere decisioni informate e, soprattutto, sapere quando fermarsi e coinvolgere chi ne sa più di lui su un aspetto specifico.

La vera discriminante non è tra specialista e full-stack.
È tra chi comprende il sistema nel suo insieme e chi comprende solo il suo pezzo di puzzle.

L’AI rende più facile attraversare i confini tra i domini. Ma qualcuno deve ancora sapere dove sono quei confini, perché esistono e cosa succede quando li attraversi.
È questo, oggi come ieri, il vero valore del full-stack.

L’AI non ha creato questa figura. Ha semplicemente reso più evidente quanto fosse già importante.

 

---

1) Full-stack: termine usato in ambito software per indicare uno sviluppatore o un tecnico in grado di lavorare su tutti i livelli di un sistema: dalla parte visibile all’utente (frontend) alla logica applicativa (backend), fino all’infrastruttura su cui tutto gira. In senso più ampio, indica chiunque abbia competenza operativa sull’intero ciclo di un progetto tecnologico, senza limitarsi a un singolo strato o componente.

Nella foto del titolo: Modem AFSK a filtri attivi (LM3900N Norton + XR-2206), che ho progettato e costruito intorno alla metà degli anni ’80, e rilasciato come hardware aperto prima che il termine “open hardware” esistesse. Un esempio concreto di stack completo: dallo schema elettrico al firmware, fino al software di comunicazione.