27 aprile 2026

Perché l’AI spacca i team: non è (solo) una questione tecnica, ma di identità e aspettative

La stessa tecnologia può sembrare un razzo o una bomba: dipende da come vivi il tuo ruolo di sviluppatore e da cosa pensi che il mercato pretenda da te.

In molti team affiatati l’arrivo dell’AI generativa ha creato una frattura netta: una parte la rifiuta, un’altra la vive come un superpotere. Il motivo raramente è “l’AI funziona/non funziona”: c’entrano identità professionale, ambizione, ansia da performance e aspettative di produttività. Vediamo come riconoscere il problema e ridurre la polarizzazione con pratiche concrete.

L’AI generativa ha una caratteristica curiosa: riesce a dividere anche i team più coesi.

Capita di vedere gruppi che lavorano bene insieme da anni, con processi rodati e un buon allineamento su scelte tecniche e priorità. Poi entra in scena l’AI e succede qualcosa di anomalo: una parte del team la rifiuta con forza, mentre un’altra sembra aver trovato il miglior upgrade della propria carriera. Persone che arrivano al daily con una lista infinita di cose consegnate, entusiaste, quasi euforiche.

Questo non accade perché improvvisamente alcuni sono “pro” e altri “contro” la tecnologia. La spaccatura, spesso, nasce da due percezioni opposte dello stesso fenomeno: l’AI come razzo o l’AI come bomba.

AI come razzo: moltiplicatore di ambizione

Per alcuni sviluppatori l’AI è un acceleratore reale:

  • libera tempo su compiti ripetitivi (boilerplate, refactor meccanici, test scaffolding);
  • riduce l’attrito nell’esplorare alternative (API, patterns, edge case);
  • fa sentire possibile ciò che prima era “troppo lungo” o “troppo costoso”.

Se hai un profilo orientato alla sperimentazione e alla costruzione, è naturale percepirla come un mezzo per aumentare il raggio d’azione: più iterazioni, più prototipi, più output. Non è solo velocità: è la sensazione di poter “sbloccare” lavoro che prima rimaneva nel backlog dei desideri.

AI come bomba: minaccia all’identità e al posto

Per altri l’AI non è un tool, ma un segnale di rischio.

La paura raramente è “non mi piace l’interfaccia” o “i suggerimenti sono mediocri”. È più profonda: timore di perdere valore percepito.

  • Se il codice “lo scrive” un modello, qual è il mio contributo?
  • Se l’output atteso raddoppia, riuscirò a stare al passo?
  • Se arrivano tagli, chi verrà considerato indispensabile?

In questa lettura l’AI diventa un agente che sposta le regole del gioco: alza l’asticella e rende opaco il confine tra competenza, velocità e sostituibilità. Da qui nasce l’idea di minaccia esistenziale: non al mestiere in astratto, ma alla propria identità di programmatore.

Il vero detonatore: aspettative di output

Il punto più divisivo non è l’AI in sé. È ciò che l’organizzazione (o il mercato) potrebbe fare con l’AI: pretendere di più.

Quando una parte del team mostra un output enorme, involontariamente alza la “baseline” percepita. Anche se nessuno lo chiede esplicitamente, può scattare una dinamica tossica:

  • confronto continuo tra persone;
  • ansia da prestazione;
  • paura di essere etichettati come lenti o “non aggiornati”.

E il problema esplode proprio nei team che prima funzionavano bene, perché la fiducia viene sostituita dalla competizione implicita.

Come ridurre la polarizzazione (senza fare finta che non esista)

Se vuoi che l’AI migliori davvero un team frontend, serve trattarla come cambiamento socio-tecnico, non come semplice tool.

1) Separare sperimentazione da valutazione

Dichiarare esplicitamente che l’uso dell’AI non è un criterio automatico di performance. Finché questa ambiguità resta, chi è in ansia vedrà l’AI come un’arma puntata.

2) Definire cosa significa “output”

Più righe di codice non equivalgono a più valore. Allineatevi su metriche sane:

  • difetti in produzione,
  • lead time e stabilità,
  • qualità dei test,
  • manutenibilità,
  • chiarezza delle decisioni architetturali.

Se l’unico segnale è “quante cose hai chiuso”, l’AI renderà inevitabile la frattura.

3) Normalizzare il fatto che non tutti lavorano uguale

C’è chi sfrutta l’AI per buttare giù rapidamente una prima bozza e chi preferisce ragionare più a fondo prima di scrivere. Entrambi possono essere ottimi. Il team deve fare spazio a stili diversi senza trasformarli in gerarchie morali.

4) Rendere visibile il lavoro invisibile

Con l’AI cresce il rischio che venga premiato solo ciò che “si vede”: ticket chiusi, commit numerosi. Ma spesso il valore sta in:

  • debugging difficile,
  • revisione critica di una proposta,
  • riduzione del rischio,
  • scrittura di documentazione e decision record.

Se questo lavoro sparisce dal radar, chi non usa l’AI in modo aggressivo verrà penalizzato a prescindere.

In sintesi

L’AI divide perché tocca due nervi scoperti: ambizione e sicurezza.

Per alcuni è un razzo che amplia la capacità di costruire. Per altri è una bomba che minaccia identità e stabilità, soprattutto quando l’aumento di produttività diventa un’aspettativa implicita.

Gestirla bene non significa convincere tutti a usarla allo stesso modo, ma mettere in chiaro le regole: cosa valutiamo, cosa non valutiamo, e come manteniamo sostenibile il lavoro mentre gli strumenti cambiano.