Jeremy Freeman, Co-Fondator și CTO al Allstacks – Seria de Interviuri

Jeremy Freeman, Co-Fondator și CTO al Allstacks, este un inginer de software, arhitect de tehnologie și antreprenor cu o carieră care acoperă dezvoltarea de software, ingineria hardware, învățarea automată și inovația de produs. De la co-fondarea Allstacks în 2017, el a condus arhitectura și dezvoltarea platformei principale a companiei, ajutând la transformarea managementului livrării de software prin analize predictive și previziuni bazate pe inteligență artificială. Înainte de a se alătura Allstacks, Freeman a ocupat funcții de conducere la Ravioli Labs și CertiRx, unde a lucrat la ingineria software, cercetare, tehnologii anti-contrafacere și dezvoltare de produse. La începutul carierei sale, el a câștigat experiență în cadrul startup-urilor, firmelor de tehnologie din sectorul întreprinderilor și în mediul academic, inclusiv predând dezvoltarea web la Wake Technical Community College. Fondul său de cunoștințe tehnice acoperă sisteme înglobate, proiectare de hardware, platforme software la scară largă, învățarea automată și conducerea inginerească, oferindu-i o perspectivă unică asupra construirii de produse bazate pe date care ajută organizațiile să îmbunătățească rezultatele livrării de software.

Allstacks este o platformă de inteligență inginerească și management al fluxului de valori care ajută organizațiile să îmbunătățească previzibilitatea și eficiența dezvoltării software. Platforma integrează date din instrumentele utilizate pe parcursul ciclului de viață al dezvoltării software, inclusiv sisteme de management de proiect, control al surselor și sisteme de implementare, apoi aplică inteligență artificială și învățarea automată pentru a identifica riscuri, a face previziuni privind rezultatele livrării și a oferi informații cu valoare acțională. Prin oferirea liderilor de inginerie și produs cu vizibilitate asupra sănătății proiectului, performanței echipei și tendințelor de dezvoltare, Allstacks permite organizațiilor să ia decizii mai informate, să reducă incertitudinea livrării și să alinieze mai bine eforturile de inginerie cu obiectivele de afaceri. Tehnologia sa este proiectată pentru a ajuta companiile să treacă dincolo de planificarea bazată pe intuiție, prin valorificarea datelor operaționale în timp real pentru a îmbunătăți performanța livrării de software și execuția strategică.

Ați avut o călătorie unică de la conducerea echipelor de cercetare și inginerie care aplică învățarea automată datelor de dezvoltare software la co-fondarea Allstacks în 2017. Care au fost lacunele specifice sau problemele recurente pe care le-ați observat și care v-au determinat în final să construiți compania?

Când am început Allstacks, am petrecut mult timp înainte efectuând descoperiri de clienți, și modelul care a apărut a fost consecvent: companie după companie avea cantități uriașe de date și, totuși, nu aveau nici o idee despre ce se întâmpla cu adevărat. Livrarea software era imprevizibilă, în ciuda faptului că aveau unele dintre cele mai deștepte persoane din cameră. Acea problemă nu fusese rezolvată.

Ce a devenit clar destul de repede a fost că aceasta nu era o problemă de raportare sau de integrare. Era o problemă de relație. Pentru a ști dacă ceva este la risc, trebuie să știți cum o unitate de lucru se conectează la o ramură, ramura se conectează la o solicitare de extragere, solicitarea de extragere se conectează la un obiectiv de sprint și obiectivul de sprint se conectează la o inițiativă de afaceri. Acest grafic nu există din oficiu în lanțul standard de instrumente. Trebuie să îl construiți. Și construirea lui este, în mod fundamental, o problemă de inferență, ceea ce face ca fondul de învățare automată să fie direct util.

Scopul nostru de la început nu a fost să facem un dezvoltator individual mai rapid la caracteristica X. A fost să facem întreaga organizație mai bună. Cum aliniați efortul de inginerie cu rezultatele de afaceri? Cum faceți ca ingineria să servească cu adevărat afacerii, în loc să existe doar lângă aceasta? Aveți nevoie de o înțelegere mai bună a relațiilor de date pentru a răspunde la aceste întrebări. Sunt acele întrebări care au condus aproape fiecare decizie de produs pe care am luat-o.

Allstacks se concentrează pe analiza datelor de-a lungul întregului ciclu de viață al dezvoltării software. Care sunt tipurile de semnale sau modele care sunt mai predictive atunci când vine vorba de identificarea riscului de livrare din timp?

Nu cred că există un singur set de metrice care prezice bine și rău, ci mai degrabă modele pentru diferite faze și tipuri de organizații. Ce am găsit mai util este recunoașterea faptului că organizațiile de inginerie trec prin sezoane de îmbunătățire. Luna aceasta, este vorba despre performanța bazei de date. Luna viitoare, este vorba despre comunicarea între echipe. Apoi, este vorba despre “de ce nu putem închide nici o solicitare de extragere?” Apoi, observabilitatea. Ca lider de inginerie, sunteți înconjurat de semnale: unele diagnostice, unele de monitorizare și multe care sunt doar zgomot.

Ce ajută este să începeți cu problema pe care o vedeți cu adevărat, nu cu o metrică pe care doriți să o îmbunătățiți. Dacă întrebați “de ce pare că livrăm mai puțin decât anul trecut”, aceea este punctul de plecare corect. De acolo, cred că aveți nevoie de trei tipuri de metrice: prima, cum știți că problema este reală (poate numărul de solicitări de extragere pe dezvoltator în timp); a doua, ce schimbări faceți și cum le urmăriți pe parcurs (spuneți, adoptarea unui reviewer de solicitări de extragere bazat pe inteligență artificială, dacă aceea este intervenția dvs.); și a treia, cât de semnificativă este această problemă pentru afaceri. Instinctul dvs. ar putea fi corect că sunteți livrând cu 20 la sută mai puțin cod, dar adevărata poveste ar putea fi că testarea QA durează acum de trei ori mai mult. Aveți nevoie de toate cele trei lentile pentru a ști dacă rezolvați problema corectă.

Ați lucrat în industrii precum sănătate, energie și tehnologie. Cum diferă provocările de livrare de software în aceste sectoare și cum a influențat acest lucru platforma Allstacks?

Apreciem foarte mult experiența mea în sectoare non-pure de tehnologie. În companiile SaaS, este ușor să vă pierdeți în ideea că software-ul însuși este scopul. Când sunteți într-o afaceri unde nu vindeți direct software, rolul dvs. devine mult mai clar: tehnologia este acolo pentru a sprijini afacerile. Îmi place să glumesc că, dacă afacerile ar putea realiza totul la aceeași viteză fără a trebui să aibă de-a face cu mine, ar alege acea opțiune fără a clipi.

Această perspectivă este de fapt utilă. Ea contextualizează ceea ce facem cu toții în această industrie și pune multe dezbateri tehnice înapoi în locul lor. Afacerile nu se sinchisesc dacă utilizați Python sau Go. Cheltuirea de cicluri pe acea rescriere este probabil nu acolo unde este returnul real.

Ce rămâne constant în toate industriile, totuși, este problema fragmentării. Indiferent de sector, fiecare organizație de inginerie are date dispersate în jur de o duzină de instrumente, cu țesuturi de legătură limitate între ele. Specificul variază: industriile reglementate au cicluri de planificare mai lungi și o toleranță mai scăzută la ambiguitate în cerințe, deoarece costul construirii lucrului greșit este mai mare. Atelierele de tehnologie cu viteză ridicată acumulează datorii ascunse mai repede. Dar modul de eșec fundamental este același. Echipele pot spune ce a fost livrat. Nu pot urmări de ce a alunecat ceva, ce a costat sau unde a fost riscul vizibil înainte de a deveni o problemă. Acesta este modul în care am construit platforma.

Există o narativă în creștere care spune că inteligența artificială accelerează însăși codificarea, în timp ce expune slăbiciuni în altă parte. De ce cerințele, planificarea și pregătirea specificațiilor devin blocajele reale?

Vedem acest lucru zilnic. Cu un agent bun și o husă solidă în jurul lui, puteți trece de la idee, uneori direct din gura unui client, la producție în câteva ore.

Partea care face această schimbare atât de semnificativă este schimbarea buclei de feedback. Cu instrumentele de tip copilot, omul este în buclă la fiecare sugestie. Inteligența artificială oferă o completare; acceptați sau respingeți-o imediat. Când este greșită, prindeți-o repede. Raza de acțiune a unei sugestii proaste este o linie de cod. Codificarea agenților funcționează diferit: îi dați agentului un obiectiv, el descompune lucrul, execută un plan cu mai multe etape și livrează un modul care funcționează. Omul examinează ieșirea, nu fiecare pas. Când specificația este greșită, agentul construiește întreaga implementare la acea specificație greșită și aflați la examinare.

Sună ca un avantaj pur până când recunoașteți ce făcea, de fapt, întârzierea anterioară. Întârzierea a servit un scop real. Mai multe runde de oameni deștepți care examinau, planificau, testau și lucrau prin idei pentru a produce un sistem mai bun.

Tentația acum este să ocoliți toate acestea și să treceți direct la execuție. Dar agenții și husile nu sunt gata încă pentru întregul ciclu de viață al dezvoltării software. Viteza este reală. Poarta de calitate care se întâmpla în toate acele etape mai lente nu a fost înlocuită. Acesta este decalajul.

Multe organizații încă măsoară productivitatea utilizând metrice învechite. Ce fac liderii fundamental greșit despre productivitate într-un mediu de dezvoltare condus de inteligență artificială?

Oamenii au evoluat considerabil pe acest subiect de la începutul Allstacks. Măsurarea s-a mutat către lucruri care contează cu adevărat, iar cadrul a devenit mai sofisticat. Inteligența artificială răstoarnă totul.

Dezvoltarea software tradițională a fost fundamental limitată de cât de repede putea un dezvoltator să scrie cod care să îndeplinească cerințele afacerii și tehnologiei subiacente. Acest cost se apropie de zero. Ne îndreptăm către ceva mai apropiat de un dezvoltator individual ca manager de agenți. Acest model necesită o abordare complet diferită a măsurării productivității, una care se bazează pe altceva decât token-urile generate sau orele de dezvoltator cheltuite.

Partea periculoasă a metricilor actuale este că ascund ce se întâmplă cu adevărat la nivel de echipă. Inginerii seniori cu instrumente de inteligență artificială își compensează avantajul: au contextul bazei de cod și judecata pentru a direcționa ieșirea agentului și pentru a prinde eșecurile sale. Inginerii de la începutul carierei generează același volum de cod, dar petrec mai mult timp auditând ieșirile pe care nu le pot evalua pe deplin. Viteza agregată pare în regulă, poate chiar îmbunătățită. Decalajul dintre aceste două grupuri nu apare nicăieri într-un tablou de bord standard. Întrebarea corectă de a începe să o puneți oricărui lider de inginerie: puteți să-mi spuneți ce a produs agenții dvs. în ultimul sprint, care din acea ieșire a fost acceptată ca atare și care a fost revizuită, și unde a fost concentrat efortul de revizuire? Dacă puteți răspunde, aveți instrumentarea pentru a vă îmbunătăți. Dacă nu, zburați după senzație.

Nu avem încă un consens al industriei cu privire la modelul de măsurare corect. Dar echipele care încep să urmărească calitatea ieșirii și rata de re lucru, și nu doar debitul și adoptarea, vor fi mai bine poziționate decât echipele care așteaptă ca altcineva să rezolve.

Platforma dvs. conectează date din instrumente precum sisteme de management de proiect și depozite de cod. Cât de importante sunt unificarea acestor surse de date fragmentate și ce se întâmplă atunci când organizațiile nu reușesc să facă acest lucru?

Allstacks a fost de succes în acest spațiu pentru că am construit grafice de context de la început. Am recunoscut devreme că conectarea tuturor datelor împreună a fost necesară pentru a răspunde la întrebările pe care clienții le-au pus cu adevărat.

Când acea conexiune nu există, inteligența artificială care funcționează pe datele dvs. de inginerie poate vedea doar o parte a imaginii. Poate analiza ceea ce este în sistemul dvs. de management de proiect. Poate analiza ceea ce este în depozitul dvs. de cod. Ceea ce nu poate face este să urmărească o întârziere a livrării înapoi la o dependență blocată de-a lungul a trei instrumente, pentru că relația dintre aceste semnale nu există în stratul de date. Obțineți o analiză superficială, în cel mai bun caz, și recomandări încrezătoare și greșite, în cel mai rău caz. Calitatea modelului nu rezolvă această problemă. Puteți pune cel mai capabil model disponibil deasupra integrărilor API brute și totuși să pierdeți cauza reală a unei probleme, pentru că datele nu codifică relația dintre semnale. Gunoi în, gunoi afară, indiferent de cât de deștept este modelul.

Această conexiune este fundamentul. Acesta ne-a permis să fim primii pe piață cu capacități care încă nu au fost replicate.

Cum arată o organizație de inginerie bine pregătită comparativ cu una care nu este gata, pe măsură ce agenții de inteligență artificială devin mai încorporați în fluxurile de lucru de dezvoltare?

Ironically, nu este foarte diferit de a fi pregătit să aduceți o clasă de interni de vară. Aveți nevoie de suite de teste automate solide, documentație solidă, o conductă de integrare continuă matură și bariera pe care ați pune-o în loc atunci când adăugați un dezvoltator de încredere, dar nefamiliarizat, cu echipa.

Ce este, de asemenea, important, și oamenii tind să subestimeze acest lucru, este să reveniți regulat la examinarea bazelor: regulile dvs. de agent, fișierele dvs. AGENTS.MD. Puteți face o trecere solidă inițială, dar este ușor să cădeți într-un ritm de expediere în noul mod și să uitați că puteți, de fapt, antrena departe multe setări proaste. Lucruri precum învățarea agentului să ruleze teste înainte de fiecare angajament nu ar trebui să necesite o amintire umană la fiecare întâlnire.

O întrebare de diagnostic pe care aș pune-o oricărui lider de inginerie: puteți să-mi spuneți ce a produs agenții dvs. în ultimul sprint, care din acea ieșire a fost acceptată ca atare și care a fost revizuită, și unde a fost concentrat efortul de revizuire? Dacă puteți răspunde, aveți instrumentarea pentru a vă îmbunătăți. Dacă nu, zburați după senzație.

Ați subliniat importanța alinierii muncii de inginerie cu rezultatele de afaceri. Cum pot organizațiile să facă acest lucru într-un mod practic și măsurabil?

Am văzut două moduri principale de eșec. Primul este companiile care nu asociază echipele de inginerie cu produse. Multe structuri de echipe sunt moștenite și au fost în vigoare de mult timp. O echipă ar putea deține o parte a trei produse diferite, în timp ce alta deține patru complet diferite. Investiția în inginerie se bazează în mare măsură pe numărul de angajați, și atunci când echipele nu sunt aliniate cu produsele, devine foarte greu să vedeți unde așteptările de afaceri se abat de la realitate.

Al doilea mod de eșec este să nu luați în considerare toată munca care merge către construirea și întreținerea software-ului. Există o categorie uriașă de muncă de inginerie invizibilă pentru afaceri. Exemplul meu preferat este menținerea pachetelor actualizate. Liderii de afaceri non-tehnici tind să lupte pentru a înțelege valoarea sau de ce este în curs de desfășurare și imprevizibil. Dar pot înțelege categoriile de investiții. Dacă îl încadrați ca “actualizări critice de securitate” și arătați, în medie, cât consumă de capacitate, vorbesc o limbă cu care pot lucra.

Dacă întrebați un lider de vânzări să aleagă între actualizarea unor pachete npm și funcția de care au nevoie pentru a închide o afacere, funcția va câștiga de fiecare dată. Dar dacă îl încadrați ca “vă scoateți din conformitatea SOC sau livrați această funcție”, acum le arătați două compromisuri pe care le pot evalua cu adevărat. Această reîncadrare este tot jocul. Am văzut clienți care au tăiat timpul de raportare a capitalului de cercetare și dezvoltare cu mai mult de două treimi, doar prin faptul că au făcut automată clasificarea muncii, și nu manuală. Mecanismul este același, indiferent dacă scopul este raportarea capitalului, justificarea numărului de angajați sau dovedirea randamentului investiției în inteligență artificială: datele conectate înlocuiesc foi de calcul corelate.

Având în vedere fundalul dvs. în inginerie practică și predarea dezvoltării web, cum vedeți evoluția rolului dezvoltatorilor pe măsură ce inteligența artificială preia mai mult din încărcătura de codificare?

Sunt sincer îngrijorat, deși am încredere că oamenii deștepți vor găsi o soluție.

Îngrijorările mele sunt reale. Absolvenții proaspăt intrați în forța de muncă vor fi intrat într-o lume în care agenții de codificare există deja. S-a adaptat educația la acest lucru? Uneltele se mișcă rapid; învățământul superior nu se mișcă întotdeauna alături de ele. O altă schimbare pe care o urmăresc este estomparea granițelor între ingineri seniori și oameni de produs seniori. Practicienii cei mai de succes în noul model sunt ingineri care sunt profund implicați în gândirea de produs.

Ce devine mai valoros este judecata: capacitatea de a defini o problemă suficient de precis pentru ca un agent să o rezolve, de a evalua dacă soluția este corectă și de a prinde eșecurile subtile care trec testele CI, dar creează probleme arhitecturale mai târziu. Inginerii seniori își compensează avantajul, deoarece pot direcționa ieșirea agentului și știu care ieșiri să încredințeze. Îngrijorarea este pentru calea de carieră timpurie. Modul tradițional de construire a acestei judecăți a fost să scrieți mult cod și să învățați din greșeli. Această buclă de feedback se schimbă în moduri pe care industria nu le-a lucrat încă pe deplin.

Spune istoria oferă o anumită liniște. A existat un contingent semnificativ de oameni care au crezut că compilatoarele vor pune dezvoltatorii de assembly afară din muncă. Schimbarea tehnologică s-a întâmplat așa cum au prezis. Ce s-a întâmplat cu dezvoltatorii care nu au urmat același scenariu? Pe parcursul deceniului următor, numărul total de dezvoltatori a crescut. Mulți dintre acești programatori de assembly au învățat un nou limbaj și au excelat datorită cunoștințelor lor de bază. Cred că o versiune a acestui model se va repeta din nou.

Privind înainte, cum vedeți inteligența artificială remodelând ciclul de viață al dezvoltării software în următorii trei până la cinci ani, și unde vor obține companiile cel mai mare avantaj competitiv?

Vom asista la o cursă a caracteristicilor, fără precedent. Pe măsură ce costul de construire se apropie de zero, companiile, chiar și cele mari, se confruntă cu o nouă constrângere: colectarea și validarea feedback-ului suficient al clienților pentru a continua să construiască lucruri de calitate la scară.

Schimbarea care trebuie să aibă loc este că bara pentru ceea ce se construiește trebuie să crească. Constrângerile actuale în majoritatea organizațiilor de inginerie sunt simple: cinci priorități de top, poate două livrate. Cu agenți, raportul se inversează. Puteți avea cinci de top, zece următoare și douăzeci de posibile pe listă și puteți livra o sută. Întrebarea pe care nimeni nu a răspuns încă pe deplin este cum să păstrați ultimele șaizeci și cinci de a fi prost concepute și prost executate.

Sunt două lucruri de care sunt destul de sigur pentru perioada de trei până la cinci ani. Primul, avantajul competitiv în ingineria inteligenței artificiale va veni din profunzimea și lățimea contextului, nu din calitatea modelului. Modelele devin piese de schimb; fiecare instrument va avea unele capabile. Ceea ce va diferenția platformele de top va fi cât de bine înțeleg organizația dvs. specifică: depozitele dvs., structura dvs. de echipă, istoricul dvs. de livrare, modelele dvs. de implementare. Uneltele care cunosc sistemul dvs. vor produce răspunsuri fundamental diferite decât cele care nu o fac. Al doilea, schimbarea de la reactiv la proactiv. Uneltele de astăzi răspund la întrebări atunci când li se cere. În câțiva ani, uneltele de top vor observa în mod continuu și vor aduce la suprafață riscuri înainte de a fi întrebați. Organizațiile care construiesc acest strat de context acum se compensează un avantaj. Următoarea generație de unelte trebuie să rezolve problema calității la scară, și organizațiile care o rezolvă primul vor avea un adevărat avantaj.

Mulțumim pentru acest interviu minunat. Citiitorii care doresc să afle mai multe despre Allstacks ar trebui să viziteze Allstacks.