Il meglio di entrambi i mondi sviluppatori umani e collaboratori AI

Il meglio dello sviluppo collaborativo tra umani e AI

Immagine dell'autore utilizzando Midjourney

Come l’IA generativa influenzerà le squadre di ingegneria dei prodotti – Parte 6 | Postscript

Questa è l’ultima parte di una serie di sei parti che indaga come gli strumenti di produttività dell’IA generativa rivolti agli sviluppatori, come Github Copilot, ChatGPT e Amazon CodeWhisperer, potrebbero influenzare la struttura di intere squadre di ingegneria dei prodotti.

In questa parte finale consideriamo molte delle complessità che abbiamo lasciato da parte nei precedenti articoli, il valore insostituibile degli ingegneri umani nell’era dell’IA e ti lasciamo con un appello alle azioni per i leader di riflettere, adattarsi e innovare.

“In precedenza su…”

Siamo stati in un lungo viaggio attraverso questa serie e penso che valga la pena fare un breve riassunto di ciò che abbiamo trattato nei cinque articoli precedenti, in modo da poter introdurre tutto ciò che non abbiamo ancora affrontato:

Nella Parte 1 abbiamo visto evidenze che gli strumenti di codifica dell’IA generativa come Copilot e ChatGPT hanno il potenziale per migliorare significativamente la produttività delle persone in ruoli tecnici, come ingegneri e scienziati dei dati. Questi strumenti cambiano il lavoro che gli sviluppatori devono fare automatizzando attività noiose, ripetitive e che richiedono molto tempo. In teoria, rimuovono gli aspetti del lavoro degli sviluppatori che non apprezzano e rendono il loro lavoro prezioso più rapido e facile.

Nella Parte 2 abbiamo considerato che un aumento dell’automazione delle attività degli sviluppatori e una maggiore produttività degli sviluppatori potrebbero portare a un cambiamento significativo nel rapporto tra ingegneri e responsabili prodotto nelle squadre di prodotto; dove le squadre hanno storicamente avuto circa cinque ingegneri per ogni responsabile prodotto, con gli strumenti di IA generativa, questo rapporto potrebbe avvicinarsi a 1:1.

Nella Parte 3 abbiamo esaminato come gli assistenti di codifica dell’IA generativa non abbiano solo la capacità di assistere con operazioni di base come il refactoring del codice o la scrittura di test. Abbiamo esplorato come un impatto a lungo termine potrebbe portare gli strumenti di IA a ristrutturare il codice legacy, inclusa la creazione di test e documentazione, e semplificare anche alcune strutture di squadra, come lo sviluppo di app mobili, che spesso sono state create non per differenziazione del flusso di valore, ma semplicemente perché le competenze tecniche erano diverse. Abbiamo anche considerato l’impatto possibile sui giovani ingegneri e il loro sviluppo professionale.

Nella Parte 4 abbiamo considerato come questo cambiamento potrebbe consentire alle aziende di ridurre drasticamente l’organico degli ingegneri per la stessa produzione, aumentare rapidamente la produzione con lo stesso budget o una combinazione di entrambi. Abbiamo iniziato a modellare come una scelta tra investimenti nella crescita, mantenimento del budget o riduzione dei costi potrebbe influenzare l’organico degli ingegneri e dei prodotti.

Nella Parte 5 abbiamo indagato come questi vantaggi possano influenzare diversi tipi di aziende in modi diversi. Le nuove startup dovrebbero iniziare subito a utilizzare i nuovi strumenti il più velocemente possibile. Le grandi aziende, che potenzialmente hanno il maggiore impulso finanziario per trasformare le strutture delle squadre, avranno difficoltà ad adattarsi a causa dell’inerzia culturale, ma dovrebbero essere incoraggiate a iniziare oggi a sperimentare con gli strumenti e a prendere decisioni strategiche su come adottarli. Abbiamo anche visto come le aziende di outsourcing “bodyshopping” siano le più colpite negativamente, poiché i clienti cercano di preservare i dipendenti interni e risparmiare costi altrove.

Tutto ciò di cui abbiamo discusso finora si è incentrato sulla discussione dell’ipotesi, “La squadra di ingegneria dei prodotti di prossima generazione avrà probabilmente molti meno ingegneri”, ma penso sia giusto dire che ci siamo fermati a un punto molto lontano dall’aver provato o confutato tale ipotesi.

“Sì, ma…”

Ora, vorrei affrontare molte delle sfide stimolanti che ho ricevuto nelle conversazioni su questo argomento negli ultimi mesi, oltre ad affrontare il fatto che ho fatto un sacco di ipotesi nell’ambito della mia ipotesi originale.

Ho lasciato molti possibili contro-argomenti senza risposta, non perché non mi abbiano preoccupato, ma perché c’è troppa incertezza e ancora troppo lavoro da fare nell’esperimentare con questi strumenti e vedere come realmente assistono le squadre.

Ecco una lunga lista di molte critiche e domande senza risposta:

Stai affidando molto agli strumenti di IA per scrivere codice di qualità. Non possono essere così bravi come gli esseri umani.

Lo ammetto, sono impressionato dalla qualità degli strumenti, ma non sto cercando di dimostrare che devono essere altrettanto bravi degli sviluppatori eccellenti. Ho deliberatamente evitato di modellare uno scenario senza competenze tecniche, perché dalla mia esperienza nell’utilizzo degli strumenti hanno comunque bisogno di molta supervisione e guida. Supervisione per assicurarsi che non stiano facendo nulla di stupido o pericoloso (come scrivere chiavi API nel codice sorgente) e guida per garantire che stiano facendo la cosa giusta (usando il linguaggio corretto, il framework o il pattern di progettazione corretto).

Ho la sensazione che questi strumenti di intelligenza artificiale debbano essere il McDonald’s dell’ingegneria del software; mentre andare in un ottimo ristorante non di catena con personale eccezionale può essere un’esperienza trascendentale, non è sempre possibile. McDonald’s è universalmente pulito, economico, sano (inteso come non infestato da batteri) e, soprattutto, coerente. Come ha detto un mio caro amico italiano di fronte a una grande catena di consegna di pizza, “Non ti uccide”. In un certo senso, questo è il livello che stiamo cercando di raggiungere con gli strumenti di intelligenza artificiale.

Ma non penso nemmeno che questa sia la fine della storia. Gli strumenti che vediamo oggi sono lontani dalla qualità che avranno fra un anno. Anche mentre ho modificato l’articolo originale in questa serie, c’erano notizie ogni giorno su ulteriori miglioramenti; UC Berkeley introduce un modello che scrive chiamate API migliori di GPT4. Microsoft annuncia ‘dilated attention’, che consente ai modelli di scalare a miliardi di token con LongNet. StackOverflow annuncia OverflowAI con promesse di risposte ancora più sarcastiche alle domande stupide (scusate, intendo, migliori e più utili ricerche).

Anche se siete scettici sulla capacità degli strumenti odierni, temo che sarebbe miope ignorare il potenziale delle capacità che sono susceptibili di sviluppare.

[Modifica: Anche nella settimana circa da quando ho scritto questo articolo per la prima volta, Stack Overflow ha annunciato OverflowAI, Github ha annunciato strumenti aggiuntivi per prevenire problemi di proprietà intellettuale e StabilityAI ha annunciato un LLM focalizzato sulla codifica. Il mercato si muove a un ritmo sorprendente]

Gli strumenti di intelligenza artificiale avranno problemi di proprietà intellettuale. E problemi di sicurezza. E se smettono di funzionare, non potremo più lavorare

Sì, tutto questo è possibile.

Ma non è la prima volta che lavoriamo su problemi come questo, e abbiamo già modi per mitigarli. Molte delle aziende con cui parlo sono paralizzate per la preoccupazione che le loro segrete aziendali verranno utilizzate per addestrare ulteriormente l’LLM. Sebbene ciò possa essere vero per le sottoscrizioni gratuite e individuali, consiglio vivamente a voi, cari lettori, di fare le vostre ricerche sui grandi fornitori per comprendere esattamente quale sia il rischio e cosa stanno facendo i fornitori per affrontare questa preoccupazione molto ragionevole. Date un’occhiata alle FAQ dei grandi player per vedere se c’è una risposta sufficientemente valida per il vostro caso d’uso e profilo di rischio: OpenAI, Github Copilot, AWS CodeWhisperer (Google Duet è ancora in versione beta chiusa e i documenti sulla sicurezza dei dati non erano disponibili).

È lo stesso caso per la sicurezza e la protezione dei dati. La maggior parte di voi che leggete oggi è già dipendente dalla sicurezza di Github, Microsoft o AWS. Probabilmente archiviate il vostro codice su Github o le vostre app o dati su Azure, GCP o Amazon. Chiedetevi perché siete disposti ad accettare il rischio per un fornitore di hypercloud, ma non per uno strumento di programmazione. Il rischio di utilizzare ChatGPT è non trascurabile, con una fuga di dati segnalata a maggio, notizie di potenziali jailbreak segnalate questa settimana e una perdita persistente di dati da parte di utenti interni segnalata dal fornitore di sicurezza cloud, Netskope. Come con qualsiasi altra tecnologia, potete scegliere di vietarla semplicemente dalla vostra organizzazione, ma le persone, come la natura, trovano sempre una strada. Per affrontare correttamente i problemi di sicurezza, è necessario educare gli utenti e fornire alternative sicure e facili da usare. Se OpenAI non è all’altezza del compito, forse uno degli altri fornitori lo è.

Un’altra preoccupazione è l’esposizione involontaria al rischio di proprietà intellettuale; ad esempio, quando il modello è stato (accidentalmente?) addestrato su materiale che è chiuso e lo strumento espone la vostra organizzazione al rischio di violare la legge (e comporta rischi per rimediare alla vostra violazione) semplicemente utilizzando lo strumento. Ecco la brutta notizia – se pensate che questo sia un nuovo rischio, dovreste probabilmente dare un’occhiata più da vicino all’utilizzo di Open Source nella vostra organizzazione. Molte aziende sono molto lontane dalla corretta gestione e comprensione dei rischi delle loro “Software Bill of Materials” (SBOM), l’elenco delle dipendenze chiuse e open source del loro software. Dovreste assolutamente preoccuparvi del rischio che uno di questi strumenti possa accidentalmente mettervi in violazione dei diritti di proprietà intellettuale di qualcun altro, ma dovreste estendere i controlli che già usate per il software open source e il grande pulsante di copia e incolla dei vostri sviluppatori.

Questi rischi sono vostri, e se siete seri nel voler esplorare le opportunità che questi strumenti possono offrire, dovreste anche leggere la documentazione e parlare con i fornitori delle misure che stanno adottando per proteggervi da questo rischio. Assicuratevi di fare i vostri compiti. Il rapporto sulla privacy di Common Sense per Copilot lo ha valutato al 63%, abbastanza basso da guadagnare un avvertimento “ambra” (ha ottenuto punteggi particolarmente bassi su “Scuola” e “Consenso genitoriale” che lo hanno abbassato).

Questo dovrebbe sempre far parte del tuo processo di approvvigionamento in ogni caso. Dovresti sempre prendere in considerazione ogni strumento che stai per mettere vicino al codice di produzione o ai dati da una prospettiva di rischio, e spetta a te decidere il tuo appetito per il rischio e come mitigarlo.

Come nota più positiva, penso che le recenti annunci di Salesforce siano un buon indicatore della direzione che questi strumenti prenderanno. Una gran parte della promozione di Salesforce per l’AI Day si è concentrata su ciò che chiamano ‘Einstein Trust Layer’, che sembra essere un involucro genuinamente impressionante per diversi modelli LLM che va molto lontano nel garantire l’accesso e proteggere le informazioni sia dei clienti che dell’azienda (seriamente, guarda questo video, anche se non riguarda il codice).

Abbiamo appena visto sette grandi aziende tecnologiche (Amazon, Anthropic, Google, Inflection, Meta, Microsoft e OpenAI) aderire ai volontari impegni di ‘AI responsabile’ che include il watermarking dell’output. È ragionevole presumere che i maggiori attori di questo mercato, molti dei quali già aziende di cui ci fidiamo con grandi quantità dei nostri dati e infrastrutture, rilasceranno involucri simili di fiducia e sicurezza che risponderanno a molte domande in sospeso su proprietà intellettuale, sicurezza, privacy e la propensione dei LLM a essere un po’ tossici e ad avere una relazione discutibile con la verità.

Qualcuno dovrà comunque progettare la soluzione globale.

Vedi anche:

  • Qualcuno dovrà gestire tutti i dati e i flussi di dati
  • Qualcuno dovrà gestire le sovrapposizioni tra le applicazioni
  • Qualcuno dovrà proteggere i prodotti
  • Qualcuno dovrà monitorare e rispondere ai problemi
  • Qualcuno dovrà gestire le dipendenze e le interazioni tra i team e i prodotti

Sì, hai ragione. Ci sono ancora moltissimi compiti da svolgere che non riguardano solo la scrittura del codice.

È fantastico!

Significa che avremo ancora bisogno di persone per un po’ di tempo e ci mostra anche dove dovremmo fornire formazione per i nostri ingegneri. Ma dovremmo anche aspettarci che gli strumenti, l’automazione e il codice di migliore qualità, testato meglio, avranno un impatto positivo su questa lista di problemi. Con una maggiore documentazione, meno codice “intelligente”, interfacce più pulite, una migliore spiegabilità e una migliore copertura dei test, potremmo vedere meno sfide di questo tipo comunque.

Ma la maggior parte del tempo di un ingegnere non viene effettivamente trascorsa nella scrittura del codice perché ci dicono di andare a riunioni stupide

Sì, è vero. L’AI non risolverà tutti i problemi, ma se sei un ingegnere che passa più tempo in riunioni che a scrivere codice, il problema non è la tua produttività, ma il modo in cui è gestita la tua organizzazione.

Forse un giorno l’AI risolverà questo problema per te, ma nel breve termine è possibile che organizzazioni più piccole, snelle e automatizzate non abbiano bisogno di così tante riunioni.

Onestamente, per la maggior parte delle organizzazioni il modo migliore per migliorare la produttività degli sviluppatori è fare un lavoro migliore di prioritizzazione del lavoro, dire no a risultati di basso valore e dare più tempo alle squadre per concentrarsi sulla consegna di prodotti di alta qualità. Ma, se non possiamo avere questo, forse possiamo avere invece assistenti di codifica AI.

Potremmo sostituire i product manager con l’AI invece?

Ah, questa è una bella domanda.

Una delle sorprendenti osservazioni che ho già ricevuto per questi articoli è stata: “è davvero interessante, ma nella mia azienda non abbiamo neanche lontanamente abbastanza supporto per i prodotti”. Sembra che stessi mostrando un bias inconscio con il mio rapporto 5:1 tra ingegneri, e molti team tecnici stavano già lottando enormemente perché i loro rapporti non erano solo molto più alti di quello (diciamo 10:1 o più), ma anche perché la competenza del prodotto non era sufficientemente valorizzata all’interno dell’organizzazione. Alcune aziende sembrano ancora pensare che gli ingegneri scrivano il codice e i product manager siano un lusso costoso.

Penso che ottenere requisiti dai clienti sia davvero importante. Penso anche che gestire un processo di prioritizzazione commerciale efficace e facile da capire sia molto difficile. Ci vorrà un po’ prima che possiamo fare in modo che gli stakeholder progettino da soli il prompt per il software.

I product manager sono fondamentali per un’ottima ingegneria del prodotto. I product manager si concentrano sulle risorse di ingegneria e aiutano l’azienda a identificare gli obiettivi più preziosi. Penso che l’ultima cosa di cui abbiamo bisogno in questo momento sia una riduzione del supporto ai prodotti, anche se possiamo assistere alcune delle loro attività quotidiane con l’automazione.

La mia supposizione è che i ruoli di product manager e tech lead saranno i più critici in queste nuove squadre.

Non hai pensato a X o Y o Z

Quasi sicuramente hai ragione. Ma se lo hai fatto, è fantastico! Lasciami un commento, avvia una discussione o, meglio ancora, scrivi un nuovo articolo che spieghi le tue idee su Y o Z. (Ma non X. Non parliamo più di X)

Riassumiamo tutto

Lo scopo di questa intera serie di articoli è stato un’unica preoccupazione: oggi, non sento che abbastanza responsabili di prodotto e tecnologia si stiano attivamente coinvolgendo nella discussione su ciò che potrebbe accadere alle loro squadre se la promessa degli strumenti di codifica generativi AI si avverasse. Non stiamo semplicemente parlando di un piccolo aumento della produttività degli sviluppatori. È possibile che stiamo parlando di un cambiamento nel modo in cui vengono creati i prodotti.

Se anche solo parte di ciò di cui abbiamo discusso è vero, è probabile che le squadre che sviluppano software saranno risorse in modo molto diverso rispetto a oggi, con un impatto significativo sui bilanci del personale tecnico e di prodotto. Ci sono rischi di interruzione in tutta l’industria, soprattutto con una riduzione dei ruoli degli sviluppatori.

Anche se ciò potrebbe essere mitigato dalle aziende che cercano di investire sempre di più nei risultati, c’è un limite a quante linee di valore un’azienda può supportare. Le aziende che prendono il tempo per comprendere e abbracciare i cambiamenti imminenti con cura e decisione potrebbero ottenere un vantaggio competitivo significativo.

C’è anche un aspetto filosofico in questa discussione. Credo che possa esserci un valore ineffabile e irrinunciabile degli ingegneri umani, ma non credo di poterti dire con sicurezza cosa sia.

Sappiamo che gli sviluppatori scrivono codice e possiamo attribuire loro un valore in base a quanto velocemente scrivono il codice e a quanto spesso funziona. Ma questa affermazione non riesce semplicemente a cogliere il vero lavoro di un ingegnere. Per anni è stato facile dimostrare che gli ingegneri umani qualificati erano in grado di fare cose che gli algoritmi non potevano fare, ma questo non è più il caso. Se la linea tra umano e macchina è solo il livello di complessità della soluzione che può essere creata, siamo su sabbie mobili pericolose. Come ho scritto in precedenza:

Gli ingegneri non vengono solo insegnati a programmare. Vengono insegnati a pensare.

Noi, come industria, dobbiamo apprezzare che una vasta gamma di compiti di ingegneria può essere facilmente replicata da questa nuova generazione di strumenti. Nel farlo, dovremmo anche capire che ci sono ancora abilità uniche che gli esseri umani possiedono e che non sono così facilmente replicabili. È compito nostro, come leader, identificare quali sono queste competenze e investire nelle persone per ottimizzarle.

Questo articolo è un appello all’azione. Se sei un responsabile di prodotto o tecnologia, dovresti considerarlo come una sfida per valutare quale sarà l’impatto degli strumenti generativi di AI sulle tue squadre e dovresti coinvolgere le tue squadre nel rispondere a questa domanda.

Dando tempo e spazio per considerare come questi strumenti li aiuteranno, la fonte più probabile di innovazione sarà proprio le tue squadre. Ma, come leader, devi anche riconoscere che le persone potrebbero essere spaventate e riluttanti a impegnarsi a causa della minaccia molto reale per il loro impiego e dovrai sfruttare il loro talento per capire se dovresti effettuare tagli di bilancio. Essere il capo è difficile, ma l’alternativa è che i tuoi concorrenti siano più incrollabili e decisi di te.

Dobbiamo essere chiari sul fatto che i progressi più interessanti, caotici, indisciplinati, impattanti ed entusiasmanti si verificheranno in quelle piccole startup e in squadre al di fuori del settore tecnologico. Non commettere l’errore di ignorare ciò che le persone non tecniche nella tua stessa organizzazione o le piccole aziende nella comunità delle startup stanno facendo.

Inizia educando te stesso e poi gli altri nella tua stessa azienda su quali sono realmente i rischi. Considera le opportunità guardando sia internamente a curiosi early adopter all’interno della tua azienda, che all’esterno a ciò che i giganti tecnologici e le piccole startup stanno facendo. Sii consapevole che questi progressi sono destinati a ridefinire fondamentalmente l’ingegneria dei tuoi prodotti, quindi esci, sii curioso, fai domande e incoraggia le tue squadre a fare lo stesso.

Non sono ancora riuscito a confutare la mia stessa ipotesi, ma ora chiedo il tuo aiuto per progettare l’esperimento.

  • Parte 1
  • Parte 2
  • Parte 3
  • Parte 4
  • Parte 5

P.S. Se ti stanno piacendo questi articoli sulle squadre, dai un’occhiata al mio podcast Teamcraft, dove il mio co-host Andrew Maclaren ed io parliamo con ospiti di ciò che rende le squadre efficaci.