L'anno scorso il mio feed LinkedIn aveva un genere. Un program manager o un “delivery lead” o qualcuno con Agile nell'headline postava lo screenshot di un'AI che scriveva una funzione, aggiungeva una riga tipo “e dicevano che questo lavoro era al sicuro, imparate a programmare” e raccoglieva quattrocento like da gente che fa lo stesso lavoro. Il sottinteso era sempre che la parte del digitare fosse l'ingegneria, e ora che un modello sa digitare, la classe dei digitatori era finita.
Penso che abbiano letto l'organigramma a testa in giù. E sono contento che lo stiano scoprendo.
Ecco la cosa che nessuno da quella parte del feed dice ad alta voce. L'AI non è granché nella parte portante del costruire, cioè decidere cosa il sistema debba fare, sapere perché gli ultimi tre tentativi sono falliti, ed essere in grado di capire quando il modello ti ha appena consegnato con sicurezza qualcosa di rotto. È invece davvero, imbarazzantemente brava nell'altra parte. Il riepilogo di stato. Le release note che nessuno legge. Il catalogo di feature che diventa obsoleto in una settimana. Il piano di test che è perlopiù una riformattazione dei criteri di accettazione. L'aggiornamento settimanale che riassume lo standup che riassumeva il thread Slack. Non è quello il lavoro con cui l'AI fa fatica. È il lavoro per cui l'AI è nata.
Quindi guarda chi sta dove. Il livello di supporto esiste, di proposito, per fare le parti che gli ingegneri non volevano fare. Tenere aggiornato il project tracker. Rincorrere la gente per gli aggiornamenti. Trasformare due frasi di un ingegnere in un paragrafo per il VP. Trasformare il paragrafo di un ingegnere in due frasi per il VP. Mantenere il doc. Condurre la riunione dove ognuno dice ciò che ha già detto per iscritto ieri. Non sto facendo il crudele. Questi compiti erano reali ed erano tediosi e qualcuno doveva farli, che è tutta la ragione per cui i ruoli sono stati finanziati. Il problema è che “produrre un riepilogo pulito di input generati da altri” è la forma esatta di ciò che un modello linguistico fa meglio, e “produrre gli input” è la parte che ancora non sa fare da solo.
Ed ecco l'asimmetria che chi postava l'obsolescenza ha saltato. Per usare bene l'AI devi essere in grado di controllarla. Devi leggere il diff e capire che è sbagliato. Devi guardare la migrazione generata e notare che non ha un rollback. Il costruttore ce l'ha già, quella capacità. È la stessa competenza che l'ha reso un costruttore. Il livello di coordinamento, invece, è stato assunto sull'esplicito presupposto che non avrebbe avuto bisogno di leggere il codice, e ora lo strumento che dovrebbe salvarlo produce un output di cui può fidarsi solo chi sa leggere il codice. Gli hanno messo in mano una motosega e il manuale è in una lingua che gli avevano detto non avrebbe mai dovuto imparare.
Un buon program manager non è una macchina sforna-aggiornamenti di stato.
Sì, lo so. Ma su ~40 che ho incontrato finora in carriera, forse 2 lo erano. 38 erano decisamente macchine sforna-aggiornamenti. Il lavoro vero, quello per cui vale la pena pagare, è il giudizio su cosa tagliare, la copertura politica quando un lancio slitta, sapere quale “domanda veloce” di un dirigente è una minaccia, e portare sei team che si odiano a impegnarsi su un'unica data. L'AI non fa niente di tutto ciò. Non sa assorbire la colpa in una stanza. Non sa decidere che la sequenza tecnicamente corretta è quella politicamente suicida. Ridurre l'intera funzione a “tiene calda la pagina Confluence” è la fantasia più vecchia del programmatore e ha sempre avuto torto sui migliori in quel ruolo. Lo so.
Il lavoro di giudizio-e-protezione non è mai stato l'intero organico. Sotto ognuno di quei program manager davvero bravi c'era uno strato di persone la cui vera giornata era la manutenzione degli artefatti, il riepilogo, il catalogo, la deck che ribadiva la deck.
La folla del “gli ingegneri sono finiti” aveva tutto al contrario, perché ha confuso chi produce valore con chi fa più rumore nel produrlo. La persona che sa distinguere una buona risposta da una sbagliata ma sicura di sé è la persona che l'AI rende più preziosa, non meno. Quella persona di solito stava costruendo. Raramente era quella che postava lo screenshot.