Il secondo schermo

Ho studiato tanto per specializzarmi nel frontend, poi quel giorno ho scritto il mio primo prompt con un agent della prima ora. Una sfilza di componenti si è materializzata davanti a me in qualche secondo. Quello è stato il momento in cui sono rimasto a occhi spalancati davanti allo schermo. «Ah.»

Mi viene in mente quanto ho sgomitato per riuscire a convincere le persone che fossi in grado di fare frontend. La mia carriera non è iniziata con il frontend, bensì con l'opposto. Al tempo non mi piaceva un granché, perché i task erano noiosi, per contro, trovavo il frontend interessantissimo. Avevo un doppio schermo: mentre il preistorico progetto .NET si compilava, sull'altro c'era, a tutto schermo, Maximilian Schwarzmüller che mi spiegava React.

In consulenza, se hai la fortuna di puntare i piedi e non farti licenziare, puoi rivivere una seconda vita facendo ciò che più ti piace; oppure muori, finendo a tappare il buco di turno.
Puntai i piedi.

Ora quel mondo, che a fatica mi sono guadagnato, sembra essere cambiato drasticamente.

A distanza di tempo, sui social che leggo avidamente per tenermi al passo, il discorso non verte più sulle solite guerre di religione tra framework, ma su quale provider usare: Anthropic, OpenAI, Cursor. Questi sono i discorsi di adesso.

Inizialmente ho pensato che fosse l'hype del momento, una bolla destinata a scoppiare, ma poi ho visto le cose cambiare davvero.

Prolifiche e autorevoli figure del web, che mi hanno alfabetizzato e scolarizzato, un tempo assai verticali sul proprio stack, improvvisamente diventano "AI Engineer" (per citarne un paio: Matt Pocock, Kent C. Dodds…).

"Frontend Masters", celebre servizio di corsi prettamente frontend, oggi ha cambiato nome in "Masters.dev".

«Che cavolo sta succedendo?»

Forse Matt e Kent hanno capito che non serve più imparare a scrivere bene TypeScript e React se c'è una skill pronta per ogni evenienza; e forse il marketing di "Masters.dev" ha capito che l'etichetta commerciale di "frontend developer" puro si sta diluendo, e che sviluppatori nel panico come me avrebbero preferito corsi su come usare l'IA piuttosto che su un nuovo framework JS.

Il mondo multipolare di frontend e backend, che negli ultimi anni aveva già iniziato a mescolarsi con l'arrivo di framework e meta-framework fullstack, oggi sembra destinato a non esistere più.

Del resto il frontend non è più solo HTML, CSS e JavaScript, e non lo è da tempo, da quando sono arrivati proprio questi framework. E così ci siamo adattati e abbiamo silenziosamente accettato che non facciamo più solo quelle cose lì.

Se essere fullstack era un plus, in questo preciso momento storico sembra un requisito indispensabile.

E se sui social tecnici si parlava di IA a tutto spiano, su LinkedIn un founder qualunque ha detto che, con quattro prompt a Claude, ha sostituito 13 SaaS.

È naturale che dichiarazioni di questo tipo suonino minacciose se fai questo mestiere: sembra che la società abbia capito che lo sviluppo software adesso è alla portata di tutti. Ma oggi in tanti gioiscono con una demo in mano, credendo di aver creato un nuovo SaaS.

Non c'è quindi da stupirsi degli effetti di questo clima sulla psiche degli sviluppatori che leggono queste dichiarazioni. E così gli sviluppatori si schierano: da un lato c'è la FOMO, dall'altro il luddismo.

Se i primi controllano i social tech a intervalli regolari, sperando di non essere rimasti indietro sulle cose da studiare, i secondi, i luddisti, non ne vogliono proprio sapere.

L'introduzione dell'IA non è sempre accolta con entusiasmo. Conosco una cerchia di sviluppatori che osteggia questo nuovo modo di lavorare: "Perché usare questi strumenti, se poi ci porteranno al licenziamento?", pensano.

Alcuni sviluppatori fanno questo mestiere perché per loro il coding è un esercizio di stile, bello e alienante. Per alcuni è proprio un modo di evadere, come può esserlo fare un cruciverba o un sudoku: un gioco di logica che li mette a confronto con se stessi. Se chiedete a un developer malato di coding di abbandonare ciò che ama fare più di ogni altra cosa, è probabile che non accetti di buon grado questo cambiamento.

Non biasimo nessuno dei due: ci sono giorni in cui mi sento dell'una o dell'altra parte, e giorni in cui vorrei solo sparire in qualche campo da coltivare, vivere di sussistenza e non dovermi preoccupare che ogni nuovo modello mi ricordi che stiamo vivendo una nuova rivoluzione industriale, e che l'intelligenza non è più un'esclusiva umana.

Finora, però, ho parlato di developer in generale e non di frontend developer. I frontend developer reduci dal macero della consulenza, che per anni hanno fatto bug fixing di orrende interfacce, oggi si trovano in una condizione svantaggiata, a loro modo di vedere. Il frontend, se non viene gestito correttamente, è storicamente caratterizzato da una grande anarchia architetturale: i design pattern, ma anche i più rudimentali concetti di programmazione a oggetti, funzionale, passano in secondo piano. Quindi immaginate di fare dieci anni di bug fixing in consulenza, su una bella commessa per qualche cliente fintech: dopo questi dieci anni, in cosa si è formato esattamente questo sviluppatore? In React? In jQuery? Quanto saranno davvero utili queste verticalizzazioni nei progetti di oggi, sviluppati interamente con l'IA?

Però c'è qualcosa che manca sia a chi festeggia con una demo in mano sia a chi teme di essere sostituito: la consapevolezza.

Scrivere software oggi è semplice; capire cosa si è scritto, no.

Il non-sviluppatore ha in mano un codice che funziona (perché l'unico modo che ha di verificarlo è vedere che fa quello che deve fare: visto e piaciuto!) e non ha alcun modo di sapere se, ad esempio, tratta i dati dei suoi utenti in modo sicuro. Non lo scopre finché non è troppo tardi e, quando lo scopre, non sa da dove ricominciare.

È questa la competenza che non si genera con un prompt: non la capacità di scrivere codice, ma quella di sapere cosa chiedere e riconoscere quando la risposta è sbagliata.

Quest'anno il codice che scrivo a mano si è ridotto drasticamente. Quando ho iniziato a delegare flussi più grandi all'agent, il mio focus si è spostato: non guardo più a come ha scritto una funzione o risolto una promise, ma a ciò che può avere un impatto concreto. Non sono stati rari i casi in cui un codice che "pareva un quadro da appendere" nascondeva un singolo, microscopico errore capace di causare giganteschi memory leak in produzione.

Mi è successo di recente, l'agent aveva sviluppato un plugin seguendo le mie istruzioni: c’era un Map fuori dalla funzione di un plugin, destinato a crescere all'infinito. L'ho notato al volo, perché mi sembrava fuori posto; guardandola meglio in review, ho trovato l'errore.

Come avrebbe fatto una persona non tecnica a trovare l'errore?

Nel mio percorso ho avuto la sfortuna di partecipare ad alcuni progetti fallimentari (sempre in consulenza) all'interno di team disfunzionali: ho visto i sorci verdi. Sono certo che tantissimi sviluppatori si siano formati così, annaspando giorno dopo giorno, anno dopo anno, in un codice inestricabile, fino a perderci la ragione.

Ed è per questo che oggi, quando sviluppo un nuovo software con l'IA, so quali sono le cose da non fare, quali confini non superare e quali strategie adottare per non ritrovarmi alla fine con un codice da incubo.

Tutto questo è certamente una novità, e le novità sono foriere di instabilità.

Ma anziché diventare preistorico come quel progetto .NET, faccio una cosa: mi siedo, mi metto comodo e accendo il secondo schermo. Chissà se anche stavolta Maximilian mi svolterà la carriera.