Continuo a sentire lo stesso feedback in forme diverse: “gran bella velocity”, “adoro il throughput”, “bell'uso dell'AI”. Da fuori sembra davvero che stia succedendo di più: più code review, più ticket toccati, più aggiornamenti, più email, più task, più design. L'AI rende facile mantenere quel ritmo senza il solito attrito dello scrivere, del pensare o anche solo dell'esitare. Ma dentro al lavoro c'è un dilemma che continua a crescere.
Il dilemma è reale e nessuno lo dice ad alta voce. L'ingegneria vera, stanare una race condition che esce solo sotto carico o capire che il bug semplice è un'assunzione sbagliata nel design, non accelera con l'AI. Ma le metriche misurano ticket toccati e
Il dilemma è reale e nessuno lo dice ad alta voce. L'ingegneria vera, stanare una race condition che esce solo sotto carico o capire che il bug semplice è un'assunzione sbagliata nel design, non accelera con l'AI.
Ma le metriche misurano ticket toccati e PR aperte, e su quelle il rumoroso ti stacca.
Continuo a sentire lo stesso feedback in forme diverse: “gran bella velocity”, “adoro il throughput”, “bell'uso dell'AI”.
Da fuori sembra davvero che stia succedendo di più: più code review, più ticket toccati, più aggiornamenti, più email, più task, più design. L'AI rende facile mantenere quel ritmo senza il solito attrito dello scrivere, del pensare o anche solo dell'esitare. Ma dentro al lavoro c'è un dilemma che continua a crescere.
C'è l'ingegneria vera: stanare una race condition che si presenta solo sotto carico, o accorgersi che un bug “semplice” è in realtà un'assunzione sbagliata nel design. O decidere di non rifattorizzare un sistema solo perché è disordinato, perché funziona ancora e il rischio non vale la pena. Quella parte non diventa più veloce con l'AI. Fai il lavoro che l'AI può fare e ti ritrovi con metriche molto più basse degli altri ingegneri? Oppure ti metti lì e prompti tutto il giorno, sforni codice e design in continuazione? Trovi soluzioni senza codice oppure usi l'AI per creare una valanga di feature, sistemi, design? Sì... non so neanch'io che fare.
Poi c'è tutto quello che ci gira attorno. L'AI rende banale generare un grosso refactor di “pulizia” che rinomina i file e rimescola i moduli così il codice sembra migliore in una PR. O tirare su una suite di test ampia che dà l'impressione di copertura senza colpire davvero i failure mode che contano. O spezzare un singolo cambiamento coerente in dieci PR più piccole così il grafico dell'attività sembra più in salute. Persino la documentazione viene tirata dentro: documenti lucidi, espansivi, che si leggono bene... ma che non vengono più letti davvero perché c'è troppo rumore in giro. Prompttiamo l'AI per generare design e poi i nostri revisori prompttano l'AI per riassumerli e revisionarli. E il management sembra adorarlo.
Il comportamento ingegneristico si adatta ai KPI che contano. Più commit incrementali, più frammenti di PR, più note tipo “l'AI mi ha aiutato a generare questo” che segnalano la partecipazione al workflow atteso. Anche quando il lavoro vero è ancora la parte lenta, il debug, il ragionamento, il dire no ai cambiamenti inutili, sempre di più deve essere avvolto in artefatti che sembrano slancio. Vogliamo tutti tenerci il posto.
La parte scomoda è che l'AI non ha solo aumentato la produttività. Ha abbassato il costo di produrre prove convincenti di produttività. E una volta che questo diventa facile, inizia a competere con la domanda più difficile, cioè se qualcosa di tutto ciò abbia davvero contato.
La copertura test gonfiata è la trappola peggiore. Numero alto sul report, zero failure mode coperti. Sembra rigore, è teatro. E chi ha scritto i test seri esce peggio nelle metriche di chi ha generato cento test inutili.
Il dilemma è reale e nessuno lo dice ad alta voce. L'ingegneria vera, stanare una race condition che esce solo sotto carico o capire che il bug semplice è un'assunzione sbagliata nel design, non accelera con l'AI.
Ma le metriche misurano ticket toccati e PR aperte, e su quelle il rumoroso ti stacca.
La PR di "pulizia" che rimescola i moduli per sembrare migliore è la scrivania da vetrina del codice: tutto in ordine, niente ci lavora davvero.
La domanda onesta è: se il tuo manager premia il volume, qual è la mossa razionale del singolo? Restare lento e profondo finendo sotto le metriche, o promptare tutto il giorno? Il sistema sta selezionando attivamente per il rumore.
I segnali falsi che l'AI rende banali:
refactor di pulizia che rinomina file e sembra lavoro
suite di test ampie che non colpiscono i failure mode veri
valanga di feature che gonfiano l'attività senza ridurre il rischio
Sembra throughput. È rumore con la sintassi giusta.