Senior nell’era degli agenti AI: meno tastiera, più giudizio 🧭

C’è una scena che si ripete in tanti team: qualcuno apre il proprio editor, scrive due righe di prompt, e nel giro di pochi minuti compare una feature intera con test, refactor e pure una spiegazione ordinata. A quel punto arriva la domanda scomoda: se la produzione di codice costa sempre meno, che senso ha parlare ancora di seniority?

La risposta breve è che la seniority non sparisce: cambia baricentro. La risposta lunga è questo articolo.

Quando il codice diventa abbondante, la risorsa scarsa torna a essere il giudizio.

Da cosa misuravamo il valore prima (e perché oggi non basta) 📉

Per anni abbiamo confuso la competenza con la velocità di scrittura. Memoria delle API, scorciatoie da tastiera, capacità di produrre molto in poco tempo. Poi sono arrivati Stack Overflow, i code snippet, Copilot, e adesso agenti capaci di orchestrare task interi.

Se la metrica resta “quante righe produci”, il risultato è paradossale: chiunque sembra bravissimo, almeno in superficie. Ma il software non vive in superficie. Vive nei dettagli noiosi: vincoli di sicurezza, latenza sotto carico, fallback quando il servizio esterno cade il venerdì sera, coerenza con una codebase già complessa.

È qui che la vecchia metrica si rompe e con lei l’illusione che la seniority fosse solo una questione di muscoli sulla tastiera.

Produzione vs giudizio: il nuovo confine reale ⚖️

Gli agenti AI hanno reso economica la produzione: codice, test di base, documentazione iniziale, refactor meccanici. Ottimo. Era la parte ripetitiva del lavoro, quella dove il margine creativo era spesso vicino allo zero.

Quello che non hanno reso economico è il giudizio: decidere cosa costruire, cosa non costruire, quali trade-off accettare, quali rischi assumersi e quali no.

In altre parole, oggi il valore si sposta da “scrivo in fretta” a “decido bene sotto vincoli”.

L’AI può proporti dieci soluzioni corrette. L’esperienza serve a scegliere quella giusta per il tuo contesto, non per il benchmark di qualcuno su internet.

Se ti interessa questo cambio di prospettiva, è lo stesso filo conduttore di Context engineering e di Pensiero critico assistito: il punto non è ottenere output, ma aumentare qualità decisionale.

Perché uno junior può sembrare senior (e perché non è una cattiva notizia) 🪞

Con gli strumenti giusti, una persona poco esperta oggi può consegnare molto più di ieri. Ed è una buona notizia: abbassa la barriera d’ingresso, accelera l’apprendimento, rende i team più produttivi.

Il rischio sta nel confondere fluidità operativa con maturità tecnica. Se un output funziona al primo giro, non significa che regga in produzione, che sia manutenibile, che non introduca lock-in, che rispetti i vincoli normativi, o che sia coerente con l’architettura esistente.

La differenza reale non è tra chi usa o non usa l’AI. È tra chi si fida ciecamente e chi verifica con metodo.

Un esempio concreto: due soluzioni entrambe “pulite” per introdurre retry su un endpoint critico. Quella che vince in demo magari è la più elegante. Quella che vince dopo sei mesi è quella con idempotenza robusta, osservabilità decente e impatto prevedibile sui costi operativi.

Il vero lavoro senior: progettare il contesto, non solo il codice 🧩

La frase “prompt engineering” ha fatto il suo tempo se la intendiamo come arte del comando perfetto. Nei sistemi reali serve qualcosa di più solido: context engineering.

Significa costruire il terreno su cui gli agenti lavorano:

• repository strutturato e leggibile;
• ADR sintetiche e aggiornate;
• contratti API chiari;
• convenzioni di qualità esplicite;
• vincoli non funzionali verificabili;
• confini architetturali che impediscano scorciatoie costose.

Quando questo contesto esiste, l’AI accelera davvero. Quando manca, accelera anche gli errori.

Per approfondire la parte più operativa del tema, la base resta Prompt engineering insieme ai pattern di Domain-driven design, perché senza modello di dominio qualsiasi automazione diventa rumore ben formattato.

Da sviluppatore esperto a direttore tecnico di agenti 🤖

Una buona metafora è questa: il lavoro senior somiglia sempre meno a “scrivere tutto” e sempre più a dirigere una squadra mista, fatta da persone e agenti.

Il ruolo cambia in modo molto concreto:

• definire il problema prima della soluzione;
• esplicitare vincoli e criteri di successo;
• assegnare task a umani e agenti in modo sensato;
• validare output e impatti sistemici;
• trasformare lezioni apprese in standard condivisi.

Sembra meno “eroico”, perché c’è meno culto della riga brillante e più disciplina progettuale. Ma è proprio questa disciplina che riduce il debito tecnico e protegge la velocità nel tempo.

In fondo è lo stesso movimento raccontato in Unknowns-driven development: non vince chi finge certezza, vince chi gestisce bene l’incertezza.

Le competenze che aumentano (mentre la sintassi scende di prezzo) 📚

Non tutte le skill crescono allo stesso modo. Alcune diventano più preziose, altre diventano commodity.

Aumentano di valore:

• domain modeling e chiarezza concettuale;
• system design e lettura dei trade-off;
• sicurezza, compliance e gestione del rischio;
• comunicazione tecnica (scrivere decisioni comprensibili);
• code review orientata all’affidabilità;
• pensiero critico e capacità di falsificare ipotesi.

Diminuiscono di valore relativo:

• memorizzazione ossessiva di sintassi;
• produzione di boilerplate;
• implementazioni ripetitive senza contesto.

Attenzione: “diminuisce” non significa “non serve”. Significa che non basta più per distinguersi.

Carriera tecnica: la scala cambia forma, non direzione 🧭

Molti immaginano l’AI come una scorciatoia per saltare livelli. In pratica funziona diversamente: comprime i tempi sulle attività meccaniche, ma rende più visibile la qualità del ragionamento.

Una traiettoria plausibile oggi assomiglia a questa:

Junior → Mid → Senior → AI-enabled senior → Architect / Staff

Non è una gerarchia morale. È una progressione di responsabilità: dalla consegna locale alla coerenza sistemica.

E sì, questo avvicina il profilo senior all’architettura. Non perché debba “fare il manager”, ma perché deve prendere decisioni che sopravvivano alla prossima release e, idealmente, anche alla prossima moda.

Conclusione pratica: meno ansia da output, più rigore sulle decisioni ✅

L’AI non rende meno importante l’esperienza. Rende meno importante scrivere ogni singola riga a mano. E questa, se ci pensi, è una liberazione: possiamo investire energia dove conta davvero.

Se vuoi una regola semplice da applicare già da domani, prova questa: prima di accettare un output AI, chiediti quali vincoli stai assumendo, quale failure mode stai ignorando e quale test può smentire la tua idea in fretta.

È un gesto piccolo, ma sposta la professione nella direzione giusta: meno spettacolo, più responsabilità. Meno magia percepita, più qualità verificabile.

E in un’epoca piena di agenti velocissimi, la competenza che resta rara è ancora la stessa: prendere decisioni tecniche sane quando il contesto è ambiguo.