Competenze del Developer nell'Era AI

Quadro delle sei competenze fondamentali che ogni sviluppatore — dipendente, in cerca di impiego, imprenditore o indie hacker — dovrebbe sviluppare per restare competitivo con l'AI, delineato da Maximilian Schwarzmüller in una slide del suo talk a CityJS Athens e approfondito nel video What I would focus on (28 ottobre 2026; vedi anche Pensare in Grande con l'AI). ¹

1. Giudizio (judgment o taste)

L'AI è in grado di implementare molto e propone continuamente idee su come realizzare una funzionalità, quale sia l'approccio migliore o cosa costruire, ma la decisione finale spetta sempre all'umano. ¹

• Sapere cosa costruire e cosa non costruire: poiché l'AI rende facile aggiungere qualsiasi funzionalità o modalità extra, la tentazione è costruire tutto; tuttavia sommare feature su feature non produce necessariamente un prodotto che dia valore agli utenti. ¹
• Requisiti, vincoli e trade-off: lo sviluppatore deve discutere idee e vincoli con l'AI, ma deve saper identificare requisiti, vincoli (constraints) e compromessi (trade-offs) prendendo la decisione finale in autonomia (make the call). ¹
• Salire sulla scala dell'astrazione: il ruolo dello sviluppatore sale di un gradino nell'astrazione (abstraction ladder) e si fonde progressivamente con quello di un product owner tecnico. ¹

2. Orchestrazione (orchestration)

Schwarzmüller abbandona il flusso basato su una o due sessioni di Claude Code o Codex seguite in micromanagement su minuscoli task isolati guardando l'agente scrivere il codice, per adottare uno o pochi orchestratori radice (root orchestrator) per progetto (una sessione di Claude Code o di Codex) incaricati di avviare e gestire altre sessioni su task relativamente grandi, la cui ampiezza evolve con l'esperienza e con il modello usato. ¹ L'orchestratore è responsabile dell'implementazione, mentre all'umano spetta definire chiaramente il task e l'esito atteso (outcome), mettere gli agenti in condizione di lavorare con efficienza, fornirgli strumenti di auto-verifica e verificare il risultato finale senza fidarsi ciecamente, iterando e rifinendo il prodotto (per l'inquadramento architetturale e operativo dell'orchestrazione multi-agente vedi Modello Fabbrica e Ruoli e Flotta di Agenti). ¹

Le decisioni di orchestrazione e progettazione poggiano su vincoli che solo lo sviluppatore e il suo team conoscono: ¹

• Vincoli di sistema e rischio di iper-complessità: progettando una nuova piattaforma di corsi con un team piccolo, il sistema deve poter scalare quasi a zero al lancio (per non pagare cifre elevate in assenza di traction) ma anche scalare rapidamente verso l'alto, rispettando requisiti di affidabilità, prestazioni e sicurezza. ¹ Cercare di costruire tutto alla perfezione anche con l'AI porta ad accumulare strati su strati di complessità, generando un "mostro" difficile da mantenere ed evolvere che rischia di non offrire l'esperienza voluta agli utenti. ¹
• Scelte a basso livello (dipendenze ed Effect): decidere quali e soprattutto quante dipendenze introdurre è cruciale a fronte degli attacchi alla supply chain. ¹ Schwarzmüller esclude l'obiettivo di zero dipendenze (che comporta altri trade-off) ma punta a un numero ridotto, motivo per cui apprezza la libreria Effect: poiché Effect ha a sua volta zero dipendenze, permette di usarla senza trascinare nel progetto molte altre librerie. ¹
• Pattern dell'orchestratore e isolamento: nella sua forma essenziale il pattern consiste nel dire a un'istanza di Claude Code che è un orchestratore, farle scrivere le regole su come avviare altri agenti e farglielo eseguire; agli agenti vanno date le regole e le skill giuste ma non troppe, lasciandoli liberi di muoversi (roam freely) in un ambiente isolato e senza accesso al database di produzione, così che non possano cancellarlo o fare danni. ¹

3. Verifica per artefatti (verification)

Per non accettare alla cieca l'output degli agenti senza diventare il collo di bottiglia del processo, la verifica si articola su due livelli (vedi anche Visibilità della Flotta e Slice Sottili e Ciclo di Feedback): ¹

1. Auto-verifica dell'agente e linting severo: gli agenti devono poter verificare da soli il proprio lavoro eseguendo i test unitari, aprendo un browser per ispezionare il sito web o il software che stanno costruendo e analizzando autonomamente i problemi; l'ambiente deve imporre un linting severo (strict linting) in cui gli agenti sono obbligati a risolvere tutti gli errori modificando il codice e non cambiando le regole di linting. ¹
2. Report e artefatti deterministici per non leggere tutto il codice: a lavoro concluso, lo sviluppatore deve ricevere un report o un artefatto generato nel modo più deterministico possibile — così da potersi fidare che non sia allucinato né ottimizzato dall'agente — composto da diagrammi, tabelle, visualizzazioni, screenshot e video del lavoro svolto. ¹ Poiché leggere tutto il codice non funzionerà più per via del volume generato e trasforma chi lo fa nel collo di bottiglia, Schwarzmüller affina costantemente i report che riceve per comprendere la struttura del codebase e giudicare se i problemi vengono risolti nel modo voluto senza leggere ogni riga. ¹

4. Ownership

Quando qualcosa va storto, la colpa è sempre dello sviluppatore umano: a nessuno — né in un contesto aziendale né ai clienti di un lavoratore autonomo — importa se a sbagliare è stata l'AI o un umano, perché al cliente interessa soltanto che il prodotto funzioni e corrisponda a quanto richiesto. ¹

Chi delega tutto agli agenti senza comprendere, saper spiegare né saper difendere le scelte fatte è destinato a perdere: lo sviluppatore non deve ridursi a un meat proxy (un semplice intermediario in carne e ossa tra chi commissiona il lavoro e l'agente), ma agire come un partner allo stesso livello o a un livello più alto, assumendosi piena responsabilità e accountability. ¹

5. Expertise orizzontale (broad expertise)

Oltre a portare a livello esperto le nuove capacità di definire requisiti, soppesare trade-off, orchestrare agenti e verificarne l'esito, cambia anche la natura della competenza tecnica richiesta: ¹

• Dal verticalismo estremo all'orizzonte ampio: essere uno specialista iper-verticale in un unico dominio non sarà più una strategia vincente per la maggior parte degli sviluppatori, a meno di essere l'esperto mondiale di quell'ambito; le nicchie continueranno a esistere, ma per i più è meno rischioso e più efficace costruire una competenza ampia (broad expertise). ¹
• Apprendimento assistito dall'AI: discutendo i concetti con ChatGPT o usando strumenti di formazione basati sull'AI è molto più semplice acquisire rapidamente una comprensione solida su più fronti — non si diventerà il miglior esperto al mondo di Docker, ma lo si capirà più a fondo di prima insieme a sviluppo front end, back end, Rust o applicazioni desktop — affiancandovi una competenza profonda su come lavorare efficientemente con gli agenti. ¹
• Adattarsi a un bersaglio mobile: poiché strumenti e pratiche cambiano di continuo (moving target), saper capire cosa sta cambiando, adattarsi ed evolvere costituisce una competenza a sé stante. ¹

6. Curiosità (curiosity)

La rapidità dell'evoluzione tecnologica genera paura e stanchezza, ma affrontarla con curiosità permette di vivere l'AI come un moltiplicatore di creatività (costruire un videogioco oggi è più accessibile che mai). ¹ Non limitarsi al minimo indispensabile sul lavoro, ma realizzare side project, spingere gli agenti al limite, provare nuovi modelli e sperimentare ambiti creativi come la generazione di modelli 3D o di workflow video con l'AI aiuta direttamente ad affinare tutte le altre competenze di orchestrazione e verifica dell'output. ¹

Vedi anche: Maximilian Schwarzmüller, Pensare in Grande con l'AI, Modello Fabbrica e Ruoli, Flotta di Agenti, Visibilità della Flotta, Slice Sottili e Ciclo di Feedback

Fonti e Riferimenti