Jeremy Freeman, Co-Fondatore e CTO di Allstacks – Serie di Interviste

Jeremy Freeman, Co-Fondatore e CTO di Allstacks, è un ingegnere software, architetto tecnologico e imprenditore con una carriera che copre lo sviluppo software, l’ingegneria hardware, l’apprendimento automatico e l’innovazione di prodotti. Dal 2017, quando ha co-fondato Allstacks, ha guidato l’architettura e lo sviluppo della piattaforma core dell’azienda, aiutando a trasformare la gestione della consegna software attraverso l’analisi predittiva e la previsione guidata dall’AI. Prima di Allstacks, Freeman ha ricoperto ruoli di leadership in Ravioli Labs e CertiRx, dove ha lavorato su ingegneria software, ricerca, tecnologie anti-contraffazione e sviluppo di prodotti. All’inizio della sua carriera, ha acquisito esperienza in startup, aziende tecnologiche e ambito accademico, incluso l’insegnamento di sviluppo web al Wake Technical Community College. La sua formazione tecnica copre sistemi embedded, progettazione hardware, piattaforme software su larga scala, apprendimento automatico e leadership ingegneristica, dandogli una prospettiva unica sulla costruzione di prodotti basati sui dati che aiutano le organizzazioni a migliorare i risultati della consegna software.

Allstacks è una piattaforma di intelligenza ingegneristica software e gestione del flusso di valore che aiuta le organizzazioni a migliorare la prevedibilità e l’efficienza dello sviluppo software. La piattaforma integra dati da strumenti utilizzati in tutta la vita dello sviluppo software, compresi sistemi di gestione dei progetti, controllo del codice sorgente e sistemi di distribuzione, quindi applica l’AI e l’apprendimento automatico per identificare rischi, prevedere i risultati della consegna e fornire informazioni azionabili. Fornendo ai leader di ingegneria e prodotti la visibilità sulla salute del progetto, le prestazioni della squadra e le tendenze di sviluppo, Allstacks consente alle organizzazioni di prendere decisioni più informate, ridurre l’incertezza della consegna e allineare meglio gli sforzi di ingegneria con gli obiettivi aziendali. La sua tecnologia è progettata per aiutare le aziende a superare la pianificazione basata sull’intuizione sfruttando i dati operativi in tempo reale per migliorare le prestazioni della consegna software e l’esecuzione strategica.

Ha avuto un percorso unico, passando dalla guida di team di ricerca e ingegneria che applicano l’apprendimento automatico ai dati di sviluppo software alla co-fondazione di Allstacks nel 2017. Quali lacune o problemi ricorrenti ha osservato che alla fine l’hanno spinto a costruire l’azienda?

Quando abbiamo iniziato Allstacks, abbiamo trascorso molto tempo in fase di discovery dei clienti, e il modello che è emerso era coerente: azienda dopo azienda aveva enormi quantità di dati e ancora non aveva idea di cosa stesse realmente accadendo. La consegna del software era imprevedibile nonostante avere alcune delle persone più intelligenti nella stanza. Quel problema non era stato risolto.

Ciò che è diventato chiaro abbastanza rapidamente è che non si trattava di un problema di reporting o di integrazione. Era un problema di relazione. Per sapere se qualcosa è a rischio, devi sapere come un elemento di lavoro si collega a un ramo, il ramo si collega a una PR, la PR si collega a un obiettivo sprint e l’obiettivo sprint si collega a un’iniziativa aziendale. Quel grafico non esiste per impostazione predefinita da nessuna parte nella catena di strumenti standard. Devi costruirlo. E costruirlo bene è fondamentalmente un problema di inferenza, che è dove la formazione sull’apprendimento automatico è diventata direttamente utile.

Il nostro obiettivo fin dall’inizio non era quello di rendere più veloce uno sviluppatore individuale su una funzionalità X. Era quello di rendere migliore l’intera organizzazione. Come si allineano gli sforzi di ingegneria con i risultati aziendali? Come si fa in modo che l’ingegneria serva realmente l’azienda anziché semplicemente esistere accanto ad essa? Devi avere una comprensione migliore delle relazioni dei dati per rispondere a quelle domande. Sono quelle domande che hanno guidato quasi ogni decisione di prodotto che abbiamo preso.

Allstacks si concentra sull’analisi dei dati in tutta la vita dello sviluppo software. Quali sono i tipi di segnali o modelli più prevedibili quando si tratta di identificare il rischio di consegna anticipatamente?

Non credo che ci sia un insieme di metriche che prevede il buono e il cattivo, ma piuttosto modelli per diverse fasi e tipi di organizzazioni. Quello che ho trovato più utile è riconoscere che le organizzazioni di ingegneria attraversano stagioni di miglioramento. Questo mese, è la prestazione del database. Il mese prossimo, è la comunicazione tra team. Poi è “perché non possiamo chiudere nessuna PR?” Poi l’osservabilità. Come leader di ingegneria, sei sommerso di segnali: alcuni diagnostici, alcuni di monitoraggio e molti che sono solo rumore.

Ciò che aiuta è iniziare con il problema che stai realmente vedendo, non con una metrica che vuoi migliorare. Se stai chiedendo “perché sembra che stiamo consegnando meno dell’anno scorso”, quella è la giusta partenza. Da lì, credo che tu debba avere tre tipi di metriche: primo, come fai a sapere che il problema è reale (forse il conteggio PR per sviluppatore nel tempo); secondo, quali cambiamenti stai facendo e come li stai tracciando lungo la strada (ad esempio, adozione di un revisore PR AI se quella è la tua intervento); e terzo, quanto è significativo questo problema per l’azienda. La tua intuizione potrebbe essere giusta che stai spedendo il 20 percento in meno di codice, ma la vera storia potrebbe essere che la QA sta ora prendendo tre volte più a lungo. Devi avere tutte e tre le lenti per sapere se stai risolvendo la cosa giusta.

Ha lavorato in settori come sanità, energia e tecnologia. Come differiscono le sfide nella consegna software tra questi settori e come ha plasmato la piattaforma Allstacks?

Apprezzo molto la mia esperienza in settori non puramente tecnologici. In aziende SaaS, è facile perdere di vista l’idea che il software stesso sia l’obiettivo. Quando sei in un’azienda dove non stai vendendo direttamente il software, il tuo ruolo diventa molto più chiaro: la tecnologia è lì per supportare l’azienda. Spesso scherzo sul fatto che se l’azienda potesse raggiungere tutto alla stessa velocità senza dover affrontare me, sceglierebbe quell’opzione senza esitazione.

Quella prospettiva è in realtà utile. Contestualizza ciò che stiamo facendo in questo settore e rimette molte discussioni tecnologiche al loro posto. L’azienda non si cura se usi Python o Go. Trascorrere cicli su quel refactor non è probabilmente dove è il vero ritorno.

Ciò che rimane costante in tutti i settori, tuttavia, è il problema della frammentazione. Indipendentemente dal settore, ogni organizzazione di ingegneria ha dati sparsi in una dozzina di strumenti con tessuto connettivo limitato tra loro. I dettagli variano: i settori regolamentati hanno cicli di pianificazione più lunghi e una tolleranza più bassa per l’ambiguità nelle richieste perché il costo di costruire la cosa sbagliata è più alto. Le aziende tecnologiche ad alta velocità accumulano debito nascosto più velocemente. Ma il modo di fallimento fondamentale è lo stesso. I team possono dirti cosa è stato spedito. Non possono tracciare perché qualcosa è scivolato, quanto è costato o dove il rischio era visibile prima di diventare un problema. È questo che ha plasmato come abbiamo costruito la piattaforma.

C’è una narrazione crescente che l’AI sta accelerando la codifica stessa mentre espone debolezze altrove. Perché le specifiche, la pianificazione e la prontezza delle specifiche stanno diventando i veri collo di bottiglia?

Stiamo vedendo questo quotidianamente. Con un buon agente e una solida guarnizione attorno ad esso, puoi passare dall’idea, a volte direttamente dalla bocca di un cliente, alla produzione in poche ore.

Parte di ciò che rende questo cambiamento così significativo è il cambiamento nel feedback loop. Con strumenti come copilot, l’umano è nel loop su ogni suggerimento. L’AI offre un completamento; accetti o rifiuti immediatamente. Quando è sbagliato, lo cogli in fretta. La portata di un suggerimento sbagliato è una riga di codice. Gli agenti funzionano in modo diverso: dai all’agente un obiettivo, decomponi il lavoro, esegui un piano multi-step e consegni un modulo funzionante. L’umano revisiona l’output, non ogni passaggio. Quando la specifica è sbagliata, l’agente costruisce l’intera implementazione a quella specifica sbagliata e scopri solo in fase di revisione.

Sembra un puro vantaggio fino a quando non riconosci cosa stava facendo realmente il tempo di ritardo precedente. Il ritardo serviva uno scopo reale. Molti round di persone intelligenti che revisionano, pianificano, testano e lavorano attraverso le idee per produrre un sistema migliore.

La tentazione ora è quella di bypassare tutto ciò e saltare direttamente alla soluzione. Ma gli agenti e le guarnizioni non sono pronti per l’intero ciclo di vita di sviluppo software. La velocità è reale. La porta di controllo della qualità che un tempo si verificava in tutte quelle fasi più lente non è stata sostituita. Quello è il gap.

Molte organizzazioni misurano ancora la produttività utilizzando metriche obsolete. Cosa stanno ottenendo fondamentalmente sbagliato i leader sulla produttività in un ambiente di sviluppo guidato dall’AI?

Le persone hanno maturato notevolmente su questo argomento da quando abbiamo iniziato Allstacks. La misurazione si è spostata verso cose che realmente contano, e i framework sono diventati più sofisticati. L’AI capovolge tutto.

Lo sviluppo software tradizionale era fondamentalmente limitato da quanto velocemente uno sviluppatore poteva scrivere codice che soddisfacesse le esigenze dell’azienda e della tecnologia sottostante. Quel costo si avvicina a zero. Ci stiamo muovendo verso qualcosa di più vicino a uno sviluppatore individuale come un manager di agenti. Quel modello richiede un approccio completamente diverso alla misurazione della produttività, basato su qualcosa di diverso dai token generati o dalle ore dello sviluppatore trascorse.

Parte del pericolo con le metriche attuali è che nascondono ciò che sta realmente accadendo a livello di team. Gli ingegneri senior con strumenti AI stanno aumentando il loro vantaggio: hanno il contesto del codice base e il giudizio per guidare l’output dell’agente e cogliere i suoi fallimenti. Gli ingegneri alle prime armi generano lo stesso volume di codice ma trascorrono più tempo verificando l’output che non possono valutare appieno. La velocità aggregata sembra buona, forse addirittura migliorata. Il divario tra quei due gruppi non si mostra da nessuna parte in un cruscotto standard. La domanda giusta da iniziare a porre non è “quanto più velocemente stiamo andando” ma “quanto di ciò che abbiamo spedito era giusto fin dalla prima volta”.

Non abbiamo ancora un consenso di settore sul modello di misurazione giusto, ma i team che iniziano a tracciare la qualità dell’output e il tasso di rilavorazione, e non solo il throughput e l’adozione, saranno meglio posizionati rispetto ai team che aspettano che qualcun altro lo risolva.

La sua piattaforma collega dati da strumenti come sistemi di gestione dei progetti e repository di codice. Quanto è importante unificare queste fonti di dati frammentate e cosa succede quando le organizzazioni non ci riescono?

Allstacks ha avuto successo in questo spazio perché abbiamo iniziato a costruire grafi di contesto prima che fosse un termine. Abbiamo riconosciuto presto che collegare tutti i dati insieme era necessario per rispondere alle domande che i clienti stavano realmente facendo.

Quando quel collegamento non esiste, l’AI che opera sui dati di ingegneria può vedere solo una parte dell’immagine. Può analizzare ciò che è nel tuo sistema di gestione del progetto. Può analizzare ciò che è nel tuo repository di codice. Ciò che non può fare è tracciare un ritardo nella consegna a una dipendenza bloccata attraverso tre strumenti, perché la relazione tra quei segnali non esiste nel livello dei dati. Ottieni un’analisi superficiale al massimo e raccomandazioni sbagliate e sicure al peggio. La qualità del modello non risolve questo. Puoi mettere il modello più capace disponibile su raw API integrations e ancora perdere la causa reale del problema perché i dati non codificano la relazione tra i segnali. Spazzatura dentro, spazzatura fuori, indipendentemente da quanto intelligente sia il modello.

Quel collegamento è la base. È ciò che ci ha permesso di essere i primi sul mercato con capacità che non sono state ancora replicate.

Man mano che gli agenti AI diventano più integrati nei flussi di lavoro di sviluppo, cosa assomiglia un’organizzazione di ingegneria ben preparata rispetto a una che non è pronta?

Ironia della sorte, non è molto diverso dall’essere pronti a portare dentro una classe di stagisti estivi. Devi avere suite di test automatiche solide, documentazione solida, una pipeline CI/CD matura e le barriere che metteresti in atto quando stai aggiungendo uno sviluppatore affidabile ma non addestrato al team.

Ciò che è anche importante, e la gente tende a sottovalutare, è tornare regolarmente a rivedere le basi: le tue regole dell’agente, i tuoi file AGENTS.MD. Puoi fare un solido primo passo, ma è facile cadere in un ritmo di spedizione nel nuovo modo e dimenticare che puoi effettivamente addestrare via molti cattivi default. Cose come insegnare all’agente a eseguire test prima di ogni commit non dovrebbero richiedere un promemoria umano ogni volta.

Una domanda diagnostica che porrei a qualsiasi leader di ingegneria: puoi dirmi cosa ha prodotto il tuo agente nell’ultimo sprint, quale di quel output è stato accettato così com’è rispetto a quello rivisto, e dove lo sforzo di revisione è stato concentrato? Se puoi rispondere a quella domanda, hai lo strumento per migliorare. Se non puoi, stai volando a vista.

Ha sottolineato l’importanza di allineare il lavoro di ingegneria con i risultati aziendali. Come possono le organizzazioni colmare quel divario in modo pratico e misurabile?

Ho visto due modi principali di fallimento. Il primo sono aziende che non accoppiano i team di ingegneria con i prodotti. Molti team structure sono legacy e sono stati in atto per molto tempo. Un team potrebbe possedere un pezzo di tre prodotti diversi mentre un altro possiede quattro interamente. Gli investimenti di ingegneria si riducono in gran parte al numero di dipendenti, e quando i team non sono allineati ai prodotti, diventa molto difficile vedere dove le aspettative aziendali divergono dalla realtà.

Il secondo modo di fallimento è non tenere conto di tutto il lavoro che va nel costruire e mantenere il software. C’è una grande categoria di lavoro di ingegneria invisibile all’azienda. Il mio esempio preferito è l’aggiornamento dei pacchetti. I leader aziendali non tecnici spesso lottano per capire il valore o perché è un lavoro in corso e imprevedibile. Ma possono capire le categorie di investimento. Se lo inquadri come “aggiornamenti di sicurezza critici” e mostri in media quanto capacità consuma, stai parlando un linguaggio con cui possono lavorare.

Se chiedi a un leader di vendita di scegliere tra alcuni aggiornamenti del pacchetto npm e la funzionalità di cui hanno bisogno per chiudere un affare, la funzionalità vince ogni volta. Ma se lo inquadri come “usciamo dalla conformità SOC o spediamo questa funzionalità”, ora stai mostrando loro due compromessi che possono effettivamente valutare. Quella riformulazione è l’intero gioco. Abbiamo visto i clienti ridurre il tempo di reporting del capitale di R&D di oltre due terzi solo rendendo automatico il lavoro di classificazione anziché manuale. Il meccanismo è lo stesso sia che l’obiettivo sia il reporting del capitale, la giustificazione del numero di dipendenti o la dimostrazione del ROI dell’AI: i dati collegati sostituiscono fogli di calcolo correlati.

Considerata la sua esperienza sia nell’ingegneria pratica che nell’insegnamento dello sviluppo web, come vede evolversi il ruolo degli sviluppatori man mano che l’AI assume più del carico di lavoro di codifica?

Sinceramente, sono un po’ preoccupato, anche se credo che le persone intelligenti troveranno una soluzione.

Le mie preoccupazioni sono reali. I neolaureati entreranno presto nel mercato del lavoro senza aver mai codificato in un mondo senza agenti di codifica. L’istruzione ha colmato quel divario? Gli strumenti si muovono rapidamente; l’istruzione superiore non sempre si muove parallelamente. L’altro cambiamento che sto osservando è l’offuscare dei confini tra ingegneri senior e persone senior del prodotto. I praticanti più di successo nel nuovo modello sono ingegneri profondamente coinvolti nel pensiero sul prodotto.

Ciò che diventa più prezioso è il giudizio: la capacità di definire un problema in modo sufficientemente preciso perché un agente possa risolverlo, valutare se la soluzione è corretta e cogliere i fallimenti sottili che superano il CI ma creano problemi architettonici in seguito. Gli ingegneri senior aumentano il loro vantaggio perché possono guidare l’output dell’agente e sapere quali output fidarsi. La preoccupazione è per il percorso di carriera iniziale. Il modo tradizionale per costruire quel giudizio era scrivere molto codice e imparare dagli errori. Quel loop di feedback sta cambiando in modi che il settore non ha ancora completamente lavorato.

Detto questo, la storia offre un po’ di rassicurazione. C’è stata una contingente significativa di persone che credevano che i compilatori avrebbero messo gli sviluppatori di assembly fuori dal mercato del lavoro. Il cambiamento tecnologico è avvenuto come avevano previsto. Cosa è successo agli sviluppatori che non hanno seguito la stessa sceneggiatura? Nel decennio successivo, il numero totale di sviluppatori è cresciuto. Molti di quegli sviluppatori di assembly hanno imparato un nuovo linguaggio ed eccelso perché della loro conoscenza fondamentale. Credo che una versione di quel modello si ripeta.

Guardando avanti, come vede l’AI ridisegnare il ciclo di vita dello sviluppo software nei prossimi tre o cinque anni e dove le aziende guadagneranno il più grande vantaggio competitivo?

Stiamo per vedere una corsa agli armamenti delle funzionalità senza precedenti. Man mano che il costo di costruire si avvicina a zero, le aziende, anche le grandi, affrontano una nuova limitazione: raccogliere e convalidare abbastanza feedback dei clienti per continuare a costruire cose di qualità su larga scala.

Il cambiamento che deve avvenire è che la barra per ciò che viene costruito deve salire. La limitazione attuale nella maggior parte delle organizzazioni di ingegneria è semplice: cinque priorità in cima, forse due consegnate. Con gli agenti, il rapporto si capovolge. Potresti avere cinque in cima, dieci prossimi e venti forse sulla lista, e spedire cento. La domanda che nessuno ha ancora risposto completamente è come tenere quegli ultimi sessantacinque lontani dall’essere concepiti male e eseguiti male.

Due cose di cui sono abbastanza sicuro per la finestra di tre-cinque anni. Primo, il vantaggio competitivo nell’ingegneria AI verrà dalla profondità e dall’ampiezza del contesto, non dalla qualità del modello. I modelli stanno diventando un requisito di base; ogni strumento avrà quelli capaci. Ciò che differenzierà le piattaforme leader è quanto profondamente capiscono la tua organizzazione specifica: i tuoi repository, la tua struttura di team, la tua storia di consegna, i tuoi modelli di distribuzione. Gli strumenti che conoscono il tuo sistema produrranno fondamentalmente risposte diverse da quelli che non lo fanno. Secondo, il passaggio da reattivo a proattivo. Oggi gli strumenti rispondono alle domande quando vengono poste. In pochi anni, gli strumenti leader osserveranno continuamente e porteranno a galla il rischio prima che tu lo chieda. Le organizzazioni che costruiscono quel livello di contesto ora stanno aumentando il loro vantaggio. La prossima generazione di strumenti deve risolvere il problema della qualità su larga scala, e le organizzazioni che lo risolvono per prime avranno un vero vantaggio.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Allstacks.