Jeremy Freeman, medgrunnlegger og CTO i Allstacks – Intervju-serie

Jeremy Freeman, medgrunnlegger og CTO i Allstacks, er en programvareingeniør, teknologiarkitekt og entreprenør med en karriere som spenner over programvareutvikling, maskinlæring og produktinnovasjon. Siden han grunnla Allstacks i 2017, har han ledet arkitekturen og utviklingen av selskapets kjerneplattform, og hjulpet med å transformere programvarelevering gjennom prediktiv analyse og AI-drevet prognostisering. Før Allstacks, hadde Freeman ledende roller i Ravioli Labs og CertiRx, der han arbeidet med programvareutvikling, forskning, anti-etterlevelses-teknologier og produktutvikling. Tidligere i sin karriere fikk han erfaring over flere start-ups, bedrifter og akademiske institusjoner, inkludert undervisning i webutvikling ved Wake Technical Community College. Hans tekniske bakgrunn omfatter innbygde systemer, maskindesign, store programvareplattformer, maskinlæring og ingeniørledelse, noe som gir ham en unik perspektiv på å bygge data-drevne produkter som hjelper organisasjoner med å forbedre programvareleveringsresultatene.

Allstacks er en programvareingeniør-intelligens og verdikjedeledningsplattform som hjelper organisasjoner med å forbedre forutsigbarheten og effektiviteten i programvareutviklingen. Plattformen integrerer data fra verktøy som brukes over hele programvareutviklingslivssyklusen, inkludert prosjektledelse, kildekontroll og deploy-systemer, og anvender deretter AI og maskinlæring for å identifisere risikoer, prognostisere leveringsresultater og fremheve håndterbare innsikter. Ved å gi ingeniør- og produktledere innsikt i prosjektets helse, teamets ytelse og utviklingstrender, muliggjør Allstacks at organisasjoner kan ta mer informerte beslutninger, redusere leveringsusikkerhet og bedre tilpasse ingeniørinnsatsen med bedriftsmål. Teknologien er designet for å hjelpe selskaper med å gå utenom intuisjonsbasert planlegging ved å utnytte sanntidsoperasjonsdata for å forbedre programvareleveringsytelsen og strategisk gjennomføring.

DU har hatt en unik reise fra å lede forsknings- og ingeniørteam med maskinlæring til programvareutviklingsdata til å grunnlegge Allstacks i 2017. Hva var de spesifikke hullene eller gjentakende problemene du observerte som til slutt førte til at du bygde selskapet?

Når vi startet Allstacks, tilbrakte vi mye tid på å gjøre kundesøk, og mønsteret som dukket opp var konsistent: selskap etter selskap hadde enorme mengder data og visste likevel ikke hva som virkelig skjedde. Levering av programvare var uforutsigbar til tross for å ha noen av de smarteste menneskene i rommet. Det problemet var ikke løst.

Hva som ble klart ganske raskt var at dette ikke var et rapporteringsproblem eller et integreringsproblem. Det var et relasjonsproblem. For å vite om noe er i fare, må du vite hvordan en arbeidsenhet kobles til en gren, grenen kobles til en PR, PR-en kobles til en sprintmål, og sprintmålet kobles til en bedriftsinitiativ. Den grafen finnes ikke som standard i noen av verktøyene i standardverktøykjedene. Du må bygge den. Og å bygge den godt er i grunn et inferensproblem, som er der ML-bakgrunnen ble direkte nyttig.

Vårt mål fra starten var ikke å gjøre en enkelt utvikler raskere på funksjon X. Det var å gjøre hele organisasjonen bedre. Hvordan kan du tilpasse ingeniørinnsatsen til bedriftsresultater? Hvordan kan du gjøre ingeniørarbeid som virkelig tjener bedriften, i stedet for bare å eksistere ved siden av den? Du trenger en bedre forståelse av dataforholdene for å svare på disse spørsmålene. Det er disse spørsmålene som har drevet nesten alle produktbeslutninger vi har tatt.

Allstacks fokuserer på å analysere data over hele programvareutviklingslivssyklusen. Hva slags signaler eller mønster er mest prediktive når det gjelder å identifisere leveringsrisiko tidlig?

Jeg tror ikke det finnes en enkelt sett med målinger som forutsier godt og dårlig, men snarere mønster for ulike faser og typer organisasjoner. Hva jeg har funnet mer nyttig er å erkjenne at ingeniørorganisasjoner går gjennom forbedringsperioder. Denne måneden er det database-ytelse. Neste måned er det kryss-teamkommunikasjon. Så er det “hvorfor kan vi ikke lukke noen PR-er?” Så er det observasjon. Som en ingeniørleder, svømmer du i signaler: noen diagnostiske, noen overvåkings-, og mye som bare støy.

Hva som hjelper, er å starte med problemet du faktisk ser, ikke en måling du ønsker å forbedre. Hvis du spør “hvorfor føles det som om vi leverer mindre enn i fjor”, er det riktig utgangspunkt. Derfra tror jeg du trenger tre typer målinger: først, hvordan vet du at problemet er reelt (kanskje PR-telling per utvikler over tid); andre, hva endringer gjør du og hvordan sporer du dem underveis (sier, adopsjon av en AI-PR-gjennomgående hvis det er din inngripen); og tredje, hvor viktig er dette problemet for bedriften. Din instinkt kan være riktig at du skipper 20 prosent mindre kode, men den virkelige historien kan være at QA nå tar tre ganger lengre. Du trenger alle tre linser for å vite om du løser det riktige.

DU har arbeidet over flere bransjer som helse, energi og teknologi. Hvordan skilles utfordringer i programvarelevering fra hverandre over disse sektorene, og hvordan har det formet Allstacks-plattformen?

Jeg setter stor pris på min erfaring i ikke-rene teknologisektorer. I SaaS-selskaper er det lett å gå glipp av at programvaren i seg selv er målet. Når du er i en bedrift der du ikke direkte selger programvaren, blir din rolle mye klarere: teknologien er der for å støtte bedriften. Jeg sier ofte at hvis bedriften kunne oppnå alt på samme hastighet uten å måtte håndtere meg, ville de velge det uten å blinke.

Denne perspektiven er faktisk nyttig. Den setter ting i perspektiv og gjør at mange teknologidiskusjoner kommer tilbake på plass. Bedriften bryr seg ikke om du bruker Python eller Go. Å bruke sykluser på den omskrivningen er sannsynligvis ikke der den virkelige avkastningen er.

Hva som forblir konsistent over alle bransjer, er fragmenteringsproblemet. Uavhengig av sektor, har hver ingeniørorg en data spredt over en dusin verktøy med begrenset sammenheng mellom dem. Spesifikke varierer: regulerte industrier har lengre planleggingsperioder og lavere toleranse for usikkerhet i krav fordi kostnaden ved å bygge feil er høyere. Høyhastighetsteknologiselskaper akkumulerer skjult gjeld raskere. Men det grunnleggende feilmodusen er den samme. Team kan fortelle deg hva som ble levert. De kan ikke spore hvorfor noe gikk galt, hva det kostet eller hvor risikoen var synlig før det ble et problem. Det er det som har formet hvordan vi bygde plattformen.

Det er en voksende fortelling om at AI akselerer kodingen selv mens den avdekker svakheter andre steder. Hvorfor blir krav, planlegging og spesifikasjonsklarhet de virkelige flasklenekkene?

Vi ser dette daglig. Med en god agent og en solid harness rundt den, kan du gå fra idé, noen ganger direkte fra en kundes munne, til produksjon på noen timer.

En del av hva som gjør denne skiftet så betydelig er endringen i tilbakemeldingsløkken. Med copilot-lignende verktøy er mennesket i løkken på hver forslag. AI-en tilbyr en fullføring; du aksepterer eller avviser det umiddelbart. Når det er feil, fanger du det raskt. Eksplosjonsradiusen av et dårlig forslag er en linje med kode. Agent-koding fungerer annerledes: du gir agenten et mål, den dekomponerer arbeidet, utfører en multi-trinnsplan og leverer en fungerende modul. Mennesket gjennomgår utdata, ikke hver enkelt trinn. Når spesifikasjonen er feil, bygger agenten hele implementeringen til feil spesifikasjon og du finner ut det under gjennomgang.

Det høres ut som ren upside til du erkjenner hva den tidligere forsinkelsen faktisk gjorde. Forsinkelsen tjente en virkelig hensikt. Flere runder av smarte mennesker som gjennomgikk, planla, testet og arbeidet gjennom ideer for å produsere et bedre system.

Frisken nå er å vibe noe ut og hoppe over all dette. Men agenter og harnesser er ikke klare for hele SDLC ennå. Hastigheten er virkelig. Kvalitetsportvakten som tidligere skjedde over alle de langsommere trinnene, er ikke erstattet. Det er gapet.

Mange organisasjoner måler fortsatt produktivitet med utdaterte målinger. Hva er ledere får fundamentalt feil om produktivitet i en AI-drevet utviklingsmiljø?

Folk har moden på dette temaet betraktelig siden vi startet Allstacks. Måling har flyttet mot ting som faktisk betyr noe, og rammer har blitt mer sofistikerte. AI snur alt dette opp ned.

Tradisjonell programvareutvikling var fundamentalt begrenset av hvor raskt en utvikler kunne skrive kode som møtte kravene til bedriften og den underliggende teknologien. Den kostnaden nærmer seg null. Hva vi beveger oss mot er noe nærmere en enkelt utvikler som en manager for agenter. Den modellen krever en helt annen tilnærming til å måle produktivitet, en som er grunnlagt i noe annet enn token generert eller utvikler-timer brukt.

En del av faren med de nåværende målingene er at de skjuler hva som faktisk skjer på teamnivå. Senior-ingeniører med AI-verktøy kompenserer sin fordel: de har kodebasen kontekst og dommen til å styre agent-utdata og fange deres feil. Tidligere karriere-ingeniører genererer samme kodevolum, men bruker mer tid på å gjennomgå utdata de ikke fullt ut kan evaluere. Aggregat-hastighet ser fin ut, kanskje enda forbedret. Gapet mellom disse to gruppene vises ikke noe sted i en standard dashboard. Riktig spørsmål å starte å spørre er ikke “hvor raskt er vi?” men “hvor mye av hva vi levert var riktig fra første gang”.

Vi har ikke industriell konsensus på riktig målingsmodell ennå, men team som starter å spore utdatakvalitet og omarbeidingshastighet, ikke bare gjennomstrømming og adopsjon, vil være bedre posisjonert enn team som venter på at noen andre skal finne ut.

Din plattform kobler data fra verktøy som prosjektledningssystemer og kode-repositorier. Hvor viktig er det å forene disse fragmenterte datakildene, og hva skjer når organisasjoner ikke gjør det?

Allstacks har vært suksessfull i denne rommen fordi vi har bygget kontekst-graf siden før det var et begrep. Vi erkjente tidlig at å koble all data sammen var nødvendig for å svare på spørsmålene kundene faktisk spurte.

Når den koblingen ikke eksisterer, kan AI som opererer på dine ingeniørdata bare se en del av bildet. Den kan analysere hva som er i ditt prosjektledningssystem. Den kan analysere hva som er i ditt kode-repositorium. Hva den ikke kan gjøre er å spore en leveringsforsinkelse tilbake til en blokkert avhengighet over tre verktøy, fordi forholdet mellom disse signalene ikke eksisterer i datalaget. Du får overfladisk analyse på beste, og selv sikre feil anbefalinger på verste. Modellkvalitet løser ikke dette. Du kan plassere den mest kapable modellen tilgjengelig på toppen av rå API-integrasjoner og likevel misse den virkelige årsaken til et problem fordi data ikke koder forholdet mellom signalene. Avfall inn, avfall ut, uavhengig av hvor smart modellen er.

Den koblingen er grunnlaget. Det er hva som har enablet oss å være først på markedet med kapasiteter som fortsatt ikke er blitt replisert.

Når AI-agenter blir mer integrert i utviklingsarbeidsflyten, hva ser en vel-forberedt ingeniørorganisasjon ut i forhold til en som ikke er klar?

Ironisk nok er det ikke så forskjellig fra å være forberedt på å bringe inn en klasse sommer-studenter. Du trenger sterke automatiserte test-suiter, solid dokumentasjon, en moden CI/CD-pipeline og retningslinjene du ville plassere når du legger til en trusted, men uerfaren utvikler til teamet.

Hva som også er viktig, og folk tenderer å undervurdere, er å komme tilbake jevnlig for å gjennomgå grunnleggende ting: dine agent-regler, dine AGENTS.MD-filer. Du kan gjøre en solid første pass, men det er lett å komme inn i en rytme av å levere på ny måte og glemme at du faktisk kan trene vekk mye dårlig default. Ting som å lære agenten å kjøre tester før hver commit, bør ikke kreve en menneskelig påminnelse hver gang.

En diagnostisk spørsmål jeg ville stille til enhver ingeniørleder: kan du fortelle meg hva dine agenter produserte forrige sprint, hvilken av den utdata ble akseptert som-er versus revidert, og hvor revisjonsinnsatsen var konsentrert? Hvis du kan svare på det, har du instrumenteringen for å forbedre. Hvis du ikke kan, flyr du på følelse.

DU har betonet viktigheten av å tilpasse ingeniørarbeid med bedriftsresultater. Hvordan kan organisasjoner brotrekke dette gapet på en praktisk og målbar måte?

Jeg har sett to hoved feilmodus. Den første er selskaper som ikke parer ingeniørteam med produkter. Mange team-strukturer er legacy og har vært på plass i lang tid. Et team kan eie en del av tre forskjellige produkter, mens et annet eier fire helt. Ingeniør-investering kommer i stor grad ned til headcount, og når team ikke er tilpasset produkter, blir det svært vanskelig å se hvor bedriftsforventninger avviker fra virkeligheten.

Den andre feilmodusen er ikke å regne med all arbeid som går inn i å bygge og vedlikeholde programvare. Det er en stor kategori for bedrift-usynlig ingeniørarbeid. Mitt favoritteksempel er å holde pakker oppdatert. Ikke-tekniske bedriftsledere sliter ofte med å forstå verdien eller hvorfor det er pågående og uforutsigbart. Men de kan forstå investeringskategorier. Hvis du rammer det som “kritiske sikkerhetsoppgraderinger” og viser på gjennomsnitt hvordan mye kapasitet det forbruker, snakker du et språk de kan jobbe med.

Hvis du ber en salgsleder om å velge mellom noen npm-pakkeoppgraderinger og funksjonen de trenger for å lukke en avtale, vinner funksjonen hver gang. Men hvis du rammer det som “vi faller ut av SOC-samsvar eller vi leverer funksjonen”, viser du dem to valg de faktisk kan vurdere. Denne omrammingen er hele spillet. Vi har sett kunder kutte sin R&D-kapitaliseringsrapporteringstid med over to tredeler bare ved å gjøre denne arbeidsklassifiseringen automatisk i stedet for manuell. Mekanismen er den samme uavhengig av om målet er kapitaliseringsrapportering, headcount-berettigelse eller å bevise AI-avkastning: koblet data erstatter korrelerte regneark.

Med din bakgrunn i både hånd-til-hånd-ingeniørarbeid og undervisning i webutvikling, hvordan ser du på utviklerrollen som utvikler seg mens AI tar over mer av kodingen?

Ærlig talt, jeg er en litt bekymret, selv om jeg har tillit til at smarte mennesker vil finne ut av det.

Mine bekymringer er reelle. Ferske studenter vil snart gå inn i arbeidsstyrken uten å ha kodet i en verden uten koding-agenter. Har utdannelsen holdt tritt med det? Verktøyene beveger seg raskt; høyere utdanning beveger seg ikke alltid like raskt. En annen skiftning jeg ser på, er utviskingen av senior-ingeniører og senior-produktfolk. De mest suksessfulle praktikerne i den nye modellen er ingeniører som er dypt investert i produkttenkning.

Hva som blir mer verdifullt er dommen: evnen til å definere et problem presist nok for en agent til å løse det, evaluere om løsningen er korrekt og fange de subtile feilene som passerer CI, men skaper arkitektoniske problemer senere. Senior-ingeniører kompenserer sin fordel: de har kodebasen kontekst og dommen til å styre agent-utdata og fange deres feil. Bekymringen er for tidligere karrierevei. Den tradisjonelle måten å bygge den dommen på var å skrive mye kode og lære av feilene. Den tilbakemeldingsløkken er i ferd med å endre seg på måter industrien ikke har fullt ut arbeidet gjennom ennå.

Det er sagt, historien tilbyr noen trygg. Det var en betydelig kontingent av mennesker som trodde kompilatorer ville sette assembly-utviklere ut av arbeid. Teknologiskiftet skjedde som de forutså. Hva skjedde med utviklerne som ikke fulgte samme manus? Over de påfølgende ti årene økte det totale antallet utviklere. Mange av disse assembly-programmererne lærte et nytt språk og utmerket seg på grunn av deres grunnleggende kunnskaper. Jeg tror en versjon av det mønsteret spiller ut igjen.

Ser du fremover, hvordan ser du på AI som omformer programvareutviklingslivssyklusen over de neste tre til fem årene, og hvor vil selskaper få den største konkurransefordelen?

Vi kommer til å se en funksjonskappløpsløp ulikt noe vi har sett før. Mens kostnaden ved å bygge nærmer seg null, står selskaper, selv store, overfor en ny begrensning: å samle inn og validere tilstrekkelig kundetilbakemelding for å fortsette å bygge kvalitetsprodukter i stor skala.

Skiftet som må skje er at standarden for hva som blir bygget, må gå opp. Den nåværende begrensningen i de fleste ingeniørorganisasjoner er enkel: fem topprioriteter, kanskje to levert. Med agenter, snur forholdet. Du kan ha fem topp, ti neste og tyve kanskje på listen, og levere hundre. Spørsmålet ingen har fullt ut svart på ennå er hvordan du holder de siste seksti fra å være dårlig konseptualisert og dårlig utført.

To ting jeg er ganske sikker på for det tre-til-fem-års-vinduet. Først, konkurransefordel i ingeniør-AI kommer fra kontekst-dybde og -bredde, ikke modellkvalitet. Modellene blir tabell-stakes; hver verktøy vil ha kapable. Hva som vil skille de ledende plattformene er hvor dypt de forstår din spesifikke organisasjon: dine repos, teamstruktur, leveringshistorikk, deploy-mønster. Verktøyene som kjenner din system vil produsere fundamentalt forskjellige svar enn de som ikke gjør det. For det andre, skiftet fra reaktivt til proaktivt. I dag svarer verktøyene på spørsmål når de spørres. Om noen år vil de ledende verktøyene observere kontinuerlig og fremheve risiko før du spør. Organisasjoner som bygger den kontekstlaget nå, kompenserer en fordel. Neste generasjons verktøy må løse kvalitets-problemet i stor skala, og organisasjonene som finner ut av det først, vil få en virkelig fordel.

Takk for det flotte intervjuet, lesere som ønsker å lære mer, bør besøke Allstacks.