Jeremy Freeman, Co-Founder og CTO af Allstacks – Interviewserie

Jeremy Freeman, Co-Founder og CTO af Allstacks, er en softwareingeniør, teknologiarkitekt og iværksætter med en karriere, der spænder over softwareudvikling, hardwareteknik, maskinlæring og produktinnovation. Siden han co-foundede Allstacks i 2017, har han ledet arkitekturen og udviklingen af virksomhedens kernplatform, hvilket har hjulpet med at transformere softwareleveringsstyring gennem prædikativ analyse og AI-drevet prognose. Før Allstacks havde Freeman ledende roller i Ravioli Labs og CertiRx, hvor han arbejdede med softwareingeniørarbejde, forskning, anti-counterfeiting-teknologier og produktudvikling. Tidligere i sin karriere fik han erfaring på tværs af startups, virksomheder og akademiske institutioner, herunder undervisning i webudvikling på Wake Technical Community College. Hans tekniske baggrund omfatter indlejrede systemer, hardware-design, store softwareplatforme, maskinlæring og ingeniørledelse, hvilket giver ham en unik perspektiv på opbygning af data-drevne produkter, der hjælper organisationer med at forbedre softwareleveringsresultater.

Allstacks er en softwareingeniør-intelligens og værdikæde-styringsplatform, der hjælper organisationer med at forbedre forudsigeligheden og effektiviteten af softwareudvikling. Platformen integrerer data fra værktøjer, der bruges på tværs af softwareudviklingslivscyklussen, herunder projektstyring, kildekontrol og installationsystemer, og derefter anvender AI og maskinlæring til at identificere risici, forudsige leveringsresultater og fremhæve handlebare indsighter. Ved at give ingeniør- og produktledere indsigt i projektets sundhed, teampræstation og udviklingstendenser, gør Allstacks det muligt for organisationer at træffe mere informerede beslutninger, reducere leveringsusikkerhed og bedre afstemme ingeniørarbejdet med forretningsmål. Teknologien er designet til at hjælpe virksomheder med at gå ud over intuition-drevet planlægning ved at udnytte realtidsoperationelle data til at forbedre softwareleveringspræstation og strategisk gennemførelse.

Du har haft en unik rejse fra at lede forsknings- og ingeniørhold til at anvende maskinlæring på softwareudviklingsdata til at co-funde Allstacks i 2017. Hvad var de specifikke huller eller gentagne problemer, du observerede, der til sidst fik dig til at bygge virksomheden?

Da vi startede Allstacks, tilbragte vi meget tid på at udføre kundespecifikation, og mønsteret, der dukkede op, var konsekvent: virksomhed efter virksomhed havde enorme mængder af data og havde alligevel ingen idé om, hvad der faktisk skete. Levering af software var uforudsigelig, selvom de havde nogle af de smarteste mennesker i rummet. Det problem var ikke blevet løst.

Hvad blev klart ret hurtigt, var, at dette ikke var et rapporteringsproblem eller et integrationsproblem. Det var et relationsproblem. For at vide, om noget er på vej til at gå galt, skal du vide, hvordan et arbejdsitem er forbundet til en gren, grenen er forbundet til en PR, PR’en er forbundet til en sprintmål, og sprintmålet er forbundet til en forretningsinitiativ. Den graf findes ikke som standard i den almindelige værktøjskæde. Du skal bygge den. Og at bygge den ordentligt er fundamentalt et inferensproblem, hvilket er, hvor maskinlæringsbaggrunden blev direkte nyttig.

Vores mål fra starten var ikke at gøre en enkelt udvikler hurtigere på funktion X. Det var at gøre hele organisationen bedre. Hvordan kan man afstemme ingeniørarbejde til forretningsresultater? Hvordan kan man gøre ingeniørarbejde til at tjene forretningsformålet i stedet for bare at eksistere ved siden af det? Du skal have en bedre forståelse af dataforholdene for at besvare disse spørgsmål. Det er disse spørgsmål, der har drevet næsten alle produktbeslutninger, vi har truffet.

Allstacks fokuserer på at analysere data på tværs af hele softwareudviklingslivscyklussen. Hvad er de typer af signaler eller mønstre, der er mest forudsigelige, når det kommer til at identificere leveringsrisiko tidligt?

Jeg tror ikke, der er en enkelt sæt af metrikker, der forudsiger godt og dårligt, men snarere mønstre for forskellige faser og typer af organisationer. Hvad jeg har fundet mere nyttigt er at erkende, at ingeniørorganisationer går gennem forbedringsperioder. Denne måned er det databaseydeevne. Næste måned er det tværs-teamkommunikation. Så er det “hvorfor kan vi ikke lukke nogen PR’er?” Så er det overvågning. Som ingeniørleder er du omgivet af signaler: nogle diagnostiske, nogle overvågnings- og mange, der bare er støj.

Hvad hjælper, er at starte med problemet, du faktisk ser. Hvis du spørger “hvorfor føles det, som om vi leverer mindre end sidste år”, er det det rigtige udgangspunkt. Derfra tror jeg, du skal have tre typer af metrikker: først, hvordan ved du, at problemet er virkeligt (måske PR-tælling pr. udvikler over tid); anden, hvad ændringer gør du, og hvordan sporer du dem undervejs (såsom adoption af en AI-PR-gennemgåelse, hvis det er din intervention); og tredje, hvor vigtigt er dette problem for forretningsformålet. Din intuition kan være rigtig, at du skibber 20 procent mindre kode, men den virkelige historie kan være, at QA nu tager tre gange længere. Du skal have alle tre linser for at vide, om du løser det rigtige.

Du har arbejdet på tværs af brancher som sundhedsvesen, energi og teknologi. Hvordan adskiller udfordringerne i softwarelevering sig på tværs af disse sektorer, og hvordan har det formet Allstacks-platformen?

Jeg værdsætter virkelig min erfaring i ikke-rene teknologi-sektorer. I SaaS-virksomheder er det let at blive fanget i idéen om, at softwaren i sig selv er målet. Når du er i en forretning, hvor du ikke direkte sælger softwaren, bliver din rolle meget klarere: teknologi er der for at støtte forretningsformålet. Jeg siger ofte, at hvis forretningsformålet kunne opnå alt på samme hastighed uden at skulle have med mig at gøre, ville de vælge den mulighed uden at blinke.

Denne perspektiv er faktisk nyttig. Den kontekstualiserer, hvad vi alle gør i denne branche, og den sætter mange teknologidebatter tilbage i deres rette perspektiv. Forretningsformålet bekymrer sig ikke om, hvorvidt du bruger Python eller Go. At bruge cyklusser på den omskrivning er sandsynligvis ikke, hvor den virkelige afkast er.

Hvad der forbliver konsekvent på tværs af alle brancher, er dog fragmenteringsproblemet. Uanset sektor har hver enkelt ingeniørorganisation data spredt over en snes værktøjer med begrænset sammenhæng mellem dem. Det specifikke varierer: regulerede brancher har længere planlægningscyklusser og lavere tolerance for usikkerhed i krav, fordi omkostningerne ved at bygge noget forkert er højere. Højhastigheds-teknologivirksomheder akkumulerer skjult gæld hurtigere. Men det grundlæggende fejlmode er det samme. Teams kan fortælle dig, hvad der er skibet. De kan ikke spore, hvorfor noget gled, hvad det kostede eller hvor risikoen var synlig, før det blev et problem. Det er dét, der har formet, hvordan vi byggede platformen.

Der er en voksende narrativ, der siger, at AI accelererer kodningen i sig selv, mens det afslører svagheder andre steder. Hvorfor bliver krav, planlægning og specifikationsklarhed de virkelige flaskehalse?

Vi ser dette hver dag. Med en god agent og en solid harness omkring den kan du gå fra idé, nogle gange direkte fra en kundes mund, til produktion på få timer.

En del af, hvad der gør denne ændring så betydningsfuld, er ændringen i feedback-løkken. Med copilot-lignende værktøjer er mennesket i løkken på hver forslag. AI’en tilbyder en afslutning; du accepterer eller afviser det med det samme. Når det er forkert, fanger du det hurtigt. Blast-radius af et dårligt forslag er en linje kode. Agentic coding fungerer anderledes: du giver agenten et mål, den dekomponerer arbejdet, udfører en multi-trinsplan og leverer en fungerende modul. Mennesket gennemgår output, ikke hver enkelt trin. Når specifikationen er forkert, bygger agenten hele implementationen til den forkerte specifikation, og du finder ud af det under gennemgang.

Det lyder som ren gevinst, indtil du erkender, hvad den tidligere forsinkelse faktisk gjorde. Forsinkelsen tjente et virkeligt formål. Flere runder af smarte mennesker, der gennemgik, planlagde, testede og arbejdede med idéer for at producere et bedre system.

Fristelsen nu er at vibe noget ud og bypass alt det. Men agenter og harnesser er ikke klar til den fulde SDLC endnu. Hastigheden er virkelig. Kvalitetsporten, der tidligere skete over alle de langsommere skridt, er ikke blevet erstattet. Det er hullet.

Mange organisationer måler stadig produktivitet ved hjælp af forældede metrikker. Hvad får ledere fundamentalt forkert om produktivitet i en AI-drevet udviklingsmiljø?

Mennesker har udviklet sig betydeligt på dette område, siden vi startede Allstacks. Måling er flyttet mod ting, der virkelig betyder noget, og rammerne er blevet mere sofistikerede. AI vælter alt det omkuld.

Traditionel softwareudvikling var fundamentalt begrænset af, hvor hurtigt en udvikler kunne skrive kode, der opfyldte forretningsformålets og den underliggende teknologis krav. Den omkostning nærmer sig zero. Hvad vi bevæger os mod, er noget, der ligner en enkelt udvikler som en manager af agenter. Den model kræver en helt anden tilgang til at måle produktivitet, en, der er grundlagt i noget andet end tokens genereret eller udvikler-timer brugt.

En del af farerne med de nuværende metrikker er, at de skjuler, hvad der faktisk sker på teamniveau. Senior-ingeniører med AI-værktøjer kompenserer deres fordel: de har kodebasen kontekst og dommen til at styre agent-output og fange dens fejl. Tidligere karriere-ingeniører genererer den samme kodevolumen, men bruger mere tid på at gennemgå output, de ikke fuldt ud kan evaluere. Samlet hastighed ser fin ud, måske endda forbedret. Gapet mellem disse to grupper vises ikke noget sted i en standard-dashboard. Det rette spørgsmål at starte med at spørge er ikke “hvor meget hurtigere går vi” men “hvor meget af, hvad vi skibede, var rigtigt fra starten”.

Vi har ikke branchensensus om den rette målemodel endnu, men teams, der starter med at spore outputkvalitet og omarbejdningssats, ikke kun gennemløb og adoption, vil være bedre positioneret end teams, der venter på, at nogen andre skal løse det.

Din platform forbinder data fra værktøjer som projektstyringssystemer og kode-repositorier. Hvor vigtigt er det at samle disse fragmenterede datakilder, og hvad sker der, når organisationer ikke gør det?

Allstacks har været succesfuld i denne branche, fordi vi har bygget kontekstgrafer, siden før det var et begreb. Vi erkendte tidligt, at forbinding af alle data sammen var nødvendigt for at besvare de spørgsmål, kunderne faktisk stillede.

Når den forbindelse ikke eksisterer, kan AI, der opererer på din ingeniørdata, kun se en del af billedet. Den kan analysere, hvad der er i dit projektstyringssystem. Den kan analysere, hvad der er i dit kode-repositorie. Hvad den ikke kan gøre, er at spore en leveringsforsinkelse tilbage til en blokeret afhængighed på tværs af tre værktøjer, fordi forholdet mellem disse signaler ikke eksisterer i datalaget. Du får overfladisk analyse på bedste, og selvbevisende, forkerte anbefalinger på værste. Modelkvalitet løser ikke dette. Du kan sætte den mest kapable model til rådighed på toppen af rå API-integrationer og stadig ikke få fat i den virkelige årsag til et problem, fordi data ikke kodificerer forholdet mellem signalerne. Skrald ind, skrald ud, uanset hvor intelligent modellen er.

Den forbindelse er fundamentet. Det er, hvad der har enablede os til at være først på markedet med kapaciteter, der stadig ikke er blevet reproduceret.

Når AI-agenter bliver mere integreret i udviklingsarbejdsgange, hvordan ser en vel-forberedt ingeniørorganisation ud i forhold til en, der ikke er parat?

Ironisk nok er det ikke så forskelligt fra at være parat til at bringe en klasse af sommerpraktikanter ind. Du skal have stærke automatiserede test-suiter, solid dokumentation, en moden CI/CD-pipeline og de samme sikkerhedsforanstaltninger, du ville have, hvis du tilføjede en tillidsværdig, men uerfaren udvikler til teamet.

Hvad der også er vigtigt, og folk har en tendens til at undervurdere, er at komme tilbage regelmæssigt for at gennemgå grundlaget: dine agentregler, dine AGENTS.MD-filer. Du kan gøre en solid første omgang, men det er let at komme i en rytme af at skibe på den nye måde og glemme, at du faktisk kan træne væk en masse dårlige standardindstillinger. Ting som at lære agenten til at køre tests, før hver commit, bør ikke kræve en menneskelig påmindelse hver gang.

En diagnostisk spørgsmål, jeg ville stille til enhver ingeniørleder: kan du fortælle mig, hvad dine agenter producerede sidste sprint, hvilken af den output blev accepteret som-er, og hvor revisionen var koncentreret? Hvis du kan svare på det, har du instrumenteringen til at forbedre. Hvis du ikke kan, flyver du på følelse.

Du har understreget vigtigheden af at afstemme ingeniørarbejde med forretningsresultater. Hvordan kan organisationer brobygge dette gap på en praktisk og målbart måde?

Jeg har set to hovedfejlmodi. Den første er virksomheder, der ikke parrer ingeniørteams med produkter. Mange teamstrukturer er arv og har været på plads i lang tid. Et team kan eje en del af tre forskellige produkter, mens et andet team kan eje fire helt andre. Ingeniørinvestering kommer primært ned til headcount, og når teams ikke er afstemt med produkter, bliver det meget svært at se, hvor forretningsforventninger afviger fra virkeligheden.

Den anden fejlmode er ikke at tage hensyn til al den arbejde, der går ind i at bygge og vedligeholde software. Der er en enorm kategori af forretnings-usynlig ingeniørarbejde. Mit yndlings eksempel er at holde pakker opdateret. Ikke-tekniske forretningsledere har ofte svært ved at forstå værdien eller hvorfor det er en løbende og uforudsigelig proces. Men de kan forstå investeringskategorier. Hvis du rammer det som “kritiske sikkerhedsopdateringer” og viser, hvor meget kapacitet det gennemsnitligt forbruger, taler du et sprog, de kan arbejde med.

Hvis du spørger en salgsleder om at vælge mellem nogle npm-pakkeopdateringer og funktionen, de har brug for for at lukke en handel, vinder funktionen hver gang. Men hvis du rammer det som “vi falder ud af SOC-overensstemmelse eller vi skiber funktionen”, viser du dem to valg, de kan faktisk evaluere. Denne omformulering er hele spillet. Vi har set kunder skære deres R&D-kapitaliseringstid ned med mere end to tredjedele bare ved at gøre det arbejde automatisk i stedet for manuelt. Mekanismen er den samme, uanset om målet er kapitalisering, headcount eller AI-afkast: forbundne data erstatter korrelerede regneark.

Med din baggrund i både hånd-til-hånd-ingeniørarbejde og undervisning i webudvikling, hvordan ser du på udviklingen af udviklernes rolle, når AI overtager mere af kodningsarbejdet?

Ærligt talt er jeg en smule bekymret, selvom jeg har tillid til, at smarte mennesker vil løse det.

Mine bekymringer er reelle. Førsteårsstuderende vil snart komme ind i arbejdsmarkedet uden nogensinde at have kodet i en verden uden kodningsagenter. Er uddannelsen ført i takt med det? Værktøjerne bevæger sig hurtigt; højere uddannelse flytter sig ikke altid i takt med dem. Den anden ændring, jeg overvåger, er udviskningen af grænserne mellem senior-ingeniører og senior-produktfolk. De mest succesfulde praktikere i den nye model er ingeniører, der er dybt engageret i produkt-tænkning.

Hvad der bliver mere værdifuldt, er dommen: evnen til at definere et problem præcist nok til, at en agent kan løse det, evaluere, om løsningen er korrekt, og fange de subtile fejl, der passerer CI, men skaber arkitektoniske problemer senere. Senior-ingeniører kompenserer deres fordel: de har kodebasen kontekst og dommen til at styre agent-output og fange dens fejl. Bekymringen er for den tidlige karrierebane. Den traditionelle måde at bygge den dom på var at skrive en masse kode og lære af fejlene. Den feedback-løkke ændrer sig på måder, branchen endnu ikke fuldt ud har arbejdet igennem.

Det sagde, tilbyder historien noget beroligelse. Der var en betydelig kontingent af mennesker, der troede, at compilere ville sætte assembly-udviklere ud af arbejde. Teknologiskiftet skete, som de forudsagde. Hvad skete der med udviklerne, der ikke fulgte det samme manuskript? Over den følgende årti voksede det samlede antal udviklere. Mange af disse assembly-programmerere lærte et nyt sprog og excellerede på grund af deres grundlæggende viden. Jeg tror, en version af det mønster gentager sig.

Med udsyn til fremtiden, hvordan ser du på AI, der former softwareudviklingslivscyklussen over de næste tre til fem år, og hvor vil virksomheder få den største konkurrencemæssige fordel?

Vi vil opleve en funktion-arms-race, der ikke har noget at gøre med noget, vi har set før. Da omkostningen ved at bygge nærmer sig zero, står virksomheder, selv store, over for en ny begrænsning: at indsamle og validere nok kunde-tilbagemeldinger til at fortsætte med at bygge kvalitetsprodukter i stor målestok.

Ændringen, der skal ske, er, at standarden for, hvad der bliver bygget, skal gå op. Den nuværende begrænsning i de fleste ingeniørorganisationer er simpel: fem top-prioriteter, måske to leveret. Med agenter flipper forholdet. Du kan have fem top, ti næste og tyve måske på listen og skibe hundred. Spørgsmålet, ingen har fuldt ud besvaret endnu, er, hvordan du holder de sidste 65 fra at være dårligt konceptualiseret og dårligt udført.

To ting, jeg er ret sikker på for det tre-til-fem-års-vindue. Først vil den konkurrencemæssige fordel i ingeniør-AI komme fra kontekst-dybde og -bredde, ikke modelkvalitet. Modellerne bliver table stakes; hvert værktøj vil have kapable. Hvad vil differentiere de førende platforme er, hvor dybt de forstår din specifikke organisation: dine repos, din teamstruktur, din leveringshistorik, dine installationsmønstre. Værktøjerne, der kender dit system, vil producere fundamentalt forskellige svar end dem, der ikke gør. Anden, skiftet fra reaktiv til proaktiv. I dag svarer værktøjerne på spørgsmål, når de stilles. Om få år vil de førende værktøjer observere kontinuerligt og fremhæve risiko, før du spørger. Organisationer, der bygger den kontekstlag nu, kompenserer en fordel. Den næste generation af værktøjer må løse kvalitetsproblemet i stor målestok, og de organisationer, der løser det først, vil have en reel fordel.

Tak for det gode interview, læsere, der ønsker at lære mere, skal besøge Allstacks.