Jeremy Freeman, medgrundare och CTO på Allstacks – Intervjuserie

Jeremy Freeman, medgrundare och CTO på Allstacks, är en programvaruutvecklare, teknisk arkitekt och entreprenör med en karriär som omfattar programvaruutveckling, hårdvarukonstruktion, maskinlärning och produktinnovation. Sedan han medgrundade Allstacks 2017 har han lett arkitekturen och utvecklingen av företagets kärnplattform, vilket har hjälpt till att förvandla programvarudistribution genom prediktiv analys och AI-drivna prognoser. Före Allstacks hade Freeman ledande roller på Ravioli Labs och CertiRx, där han arbetade med programvaruutveckling, forskning, antikontrofieringstekniker och produktutveckling. Tidigare i sin karriär fick han erfarenhet från startupföretag, företag inom enterprise-teknik och akademi, inklusive undervisning i webbutveckling på Wake Technical Community College. Hans tekniska bakgrund omfattar inbäddade system, hårdvarukonstruktion, storskaliga programvaruplattformar, maskinlärning och ingenjörsledning, vilket ger honom en unik syn på att bygga data-drivna produkter som hjälper organisationer förbättra programvarudistributionsresultat.

Allstacks är en plattform för programvaruutvecklingsintelligens och värdeflödeshantering som hjälper organisationer förbättra förutsägbarheten och effektiviteten i programvaruutvecklingen. Plattformen integrerar data från verktyg som används under hela programvaruutvecklingslivscykeln, inklusive projekthantering, källkodsstyrning och distributionsystem, och tillämpar sedan AI och maskinlärning för att identifiera risker, förutsäga leveransresultat och ge handlingsbara insikter. Genom att ge chefer inom teknik och produkt ledning synlighet i projektets hälsa, lagprestation och utvecklingstrender, möjliggör Allstacks för organisationer att fatta mer informerade beslut, minska leveransosäkerheten och bättre anpassa tekniska ansträngningar till affärsmål. Dess teknik är utformad för att hjälpa företag gå bortom intuition-baserad planering genom att utnyttja realtidsoperativa data för att förbättra programvarudistributionsprestanda och strategiskt genomförande.

Du har haft en unik resa från att leda forsknings- och ingenjörsgrupper som tillämpar maskinlärning på programvaruutvecklingsdata till att medgrundade Allstacks 2017. Vilka specifika luckor eller återkommande problem observerade du som till slut fick dig att bygga företaget?

När vi startade Allstacks, tillbringade vi mycket tid med att göra kunduppdrag, och mönstret som framträdde var konsekvent: företag efter företag hade enorma mängder data och hade fortfarande ingen aning om vad som faktiskt hände. Programvarudistribution var oförutsägbar trots att ha några av de smartaste personerna i rummet. Det problemet hade inte lösts.

Vad som blev tydligt ganska snabbt var att detta inte var ett rapporteringsproblem eller ett integrationsproblem. Det var ett relationsproblem. För att veta om något är i fara, måste du veta hur en arbetspost är kopplad till en gren, grenen är kopplad till en PR, PR: n är kopplad till ett sprintmål och sprintmålet är kopplad till ett affärsinitiativ. Den grafen finns inte som standard i någon verktygskedja. Du måste bygga den. Och att bygga den väl är i grunden ett inferensproblem, vilket är där maskinlärningsbakgrunden blev direkt användbar.

Vårt mål från början var inte att göra en enskild utvecklare snabbare på funktion X. Det var att göra hela organisationen bättre. Hur kan du anpassa tekniska ansträngningar till affärsresultat? Hur kan du göra att tekniken genuint tjänar affären snarare än bara existerar bredvid den? Du behöver en bättre förståelse för datarelationerna för att besvara dessa frågor. Det är dessa frågor som har drivit nästan varje produktbeslut vi har fattat.

Allstacks fokuserar på att analysera data över hela programvaruutvecklingslivscykeln. Vilka typer av signaler eller mönster är mest förutsägbara när det gäller att identifiera leveransrisk tidigt?

Jag tror inte att det finns en enda uppsättning mått som förutsäger bra och dåliga, utan snarare mönster för olika faser och typer av organisationer. Vad jag har funnit mer användbart är att erkänna att tekniska organisationer går igenom förbättringssäsonger. Den här månaden är det databasprestanda. Nästa månad är det kommunikation mellan team. Sedan är det “varför kan vi inte stänga några PR: er?” Sedan är det observerbarhet. Som en teknisk ledare, simmar du i signaler: vissa diagnostiska, vissa övervakade och många som bara är brus.

Vad som hjälper är att börja med problemet du faktiskt ser, inte ett mått du vill förbättra. Om du frågar “varför känns det som att vi levererar mindre än förra året”, det är rätt startpunkt. Därifrån tror jag att du behöver tre typer av mått: först, hur vet du att problemet är verkligt (kanske PR-räkning per utvecklare över tid); andra, vad är du gör och hur spårar du dem på vägen (säg antagande av en AI-PR-granskare om det är din intervention); och tredje, hur betydelsefullt är det här problemet för affären. Din instinkt kan vara rätt att du skickar 20 procent mindre kod, men den verkliga historien kan vara att QA nu tar tre gånger längre. Du behöver alla tre linser för att veta om du löser rätt sak.

Du har arbetat inom branscher som hälsovård, energi och teknik. Hur skiljer sig utmaningarna i programvarudistribution sig mellan dessa sektorer, och hur har det format Allstacks-plattformen?

Jag värdesätter verkligen min erfarenhet i icke-ren tekniska sektorer. I SaaS-företag är det lätt att förlora sig i idén att programvaran i sig är målet. När du är i ett företag där du inte direkt säljer programvaran, blir din roll mycket tydligare: tekniken finns där för att stödja affären. Jag skämtar ofta om att om affären kunde uppnå allt på samma sätt utan att behöva hantera mig, skulle de välja det alternativet utan att blinka.

Den perspektiven är faktiskt användbar. Den sätter allt i perspektiv och sätter många tekniska debatter tillbaka på plats. Affären bryr sig inte om du använder Python eller Go. Att spendera cyklar på den ombyggnaden är troligen inte där den verkliga avkastningen är.

Vad som förblir konsekvent över alla branscher är fragmenteringsproblemet. Oavsett sektor har varje teknisk organisation data spridd över ett dussin verktyg med begränsad sammanhållande vävnad mellan dem. Detaljerna varierar: reglerade branscher har längre planeringscykler och lägre tolerans för tvetydighet i kraven eftersom kostnaden för att bygga fel sak är högre. Hög-hastighetsteknikbutiker ackumulerar dold skuld snabbare. Men det grundläggande felmoduset är detsamma. Lag kan berätta vad som har skeppats. De kan inte spåra varför något gled, vad det kostade eller var risken var synlig innan det blev ett problem. Det är vad som formade hur vi byggde plattformen.

Det finns en växande berättelse om att AI accelererar kodningen i sig samtidigt som den exponerar svagheter på andra områden. Varför blir kraven, planeringen och specifikationsklarheten de verkliga flaskhalsarna?

Vi ser detta dagligen. Med en bra agent och en solid harness runt den kan du gå från idé, ibland direkt från en kunds mun, till produktion på bara några timmar.

En del av vad som gör den här förändringen så betydelsefull är förändringen i återkopplingscykeln. Med copilot-liknande verktyg är människan i cykeln för varje förslag. AI: n erbjuder en slutföring; du accepterar eller avvisar det omedelbart. När det är fel, fångar du det snabbt. Sprängverkan av ett dåligt förslag är en rad kod. Agentkod fungerar annorlunda: du ger agenten ett mål, den bryter ner arbetet, utför en flerstegsplan och levererar en fungerande modul. Människan granskar utdata, inte varje steg. När specifikationen är fel, bygger agenten hela implementeringen till den felaktiga specifikationen och du upptäcker det vid granskning.

Det låter som ren vinst tills du erkänner vad den tidigare fördröjningen faktiskt gjorde. Fördröjningen tjänade ett verkligt syfte. Flera omgångar av smarta människor som granskade, planerade, testade och arbetade igenom idéer för att producera ett bättre system.

Frestelsen nu är att vibba ut det och kringgå allt det. Men agenter och harness är inte redo för hela SDLC ännu. Hastigheten är verklig. Kvalitetsgranskningen som använde att hända över alla de långsammare stegen har inte ersatts. Det är luckan.

Många organisationer mäter fortfarande produktivitet med föråldrade mått. Vad får ledare fundamentalt fel om produktivitet i en AI-driven utvecklingsmiljö?

Människor har mognat på det här området avsevärt sedan vi startade Allstacks. Mätningen har flyttat mot saker som faktiskt betyder något, och ramverken har blivit mer sofistikerade. AI vänder allt detta upp och ner.

Traditionell programvaruutveckling var i grunden begränsad av hur snabbt en utvecklare kunde skriva kod som uppfyllde affärens och den underliggande teknologins krav. Den kostnaden närmar sig noll. Vad vi går mot är något som är närmare en enskild utvecklare som en chef för agenter. Den modellen kräver en helt annan approach till att mäta produktivitet, en som är grundad i något annat än token genererad eller utvecklartimmar tillbringade.

En del av faran med de nuvarande måtten är att de döljer vad som faktiskt händer på lagets nivå. Seniora ingenjörer med AI-verktyg förstärker sin fördel: de har kodbasen och omdömet att styra agentutdata och fånga dess misslyckanden. Tidigare karriärsvägar genererar samma kodvolym men tillbringar mer tid med att granska utdata som de inte kan fullt ut värdera. Aggregerad hastighet ser bra ut, kanske till och med förbättrad. Gapet mellan de två grupperna visas inte någonstans i en standardinstrumentpanel. Rätt fråga att börja ställa är inte “hur mycket snabbare är vi” utan “hur mycket av vad vi skeppade var rätt från början”.

Vi har inte konsensus i branschen om den rätta mätningsmodellen ännu, men lag som börjar spåra utdatakvalitet och ombyggnadsfrekvens, inte bara genomströmning och antagande, kommer att vara bättre positionerade än lag som väntar på att någon annan ska lösa det.

Din plattform ansluter data från verktyg som projekthanteringssystem och kodrepositoryer. Hur viktigt är det att förena dessa fragmenterade datakällor, och vad händer när organisationer misslyckas med att göra det?

Allstacks har varit framgångsrika inom det här området eftersom vi har byggt kontextgrafer sedan innan det var ett begrepp. Vi erkände tidigt att anslutning av all data tillsammans var nödvändig för att besvara de frågor kunderna faktiskt ställde.

När den anslutningen inte finns, kan AI som körs på dina tekniska data bara se en del av bilden. Den kan analysera vad som finns i ditt projekthanteringssystem. Den kan analysera vad som finns i ditt kodrepository. Vad den inte kan göra är att spåra en leveransförsening tillbaka till en blockerad beroende över tre verktyg, eftersom relationen mellan dessa signaler inte finns i datalagret. Du får ytlig analys i bästa fall och självsäkra, felaktiga rekommendationer i värsta fall. Modellkvalitet löser inte det här. Du kan lägga den mest kapabla modellen som finns tillgänglig ovanpå råa API-integrationer och fortfarande missa den verkliga orsaken till ett problem eftersom datan inte kodar relationen mellan signalerna. Skräp in, skräp ut, oavsett hur smart modellen är.

Den anslutningen är grunden. Det är vad som gjorde det möjligt för oss att vara först på marknaden med funktioner som fortfarande inte har replikerats.

När AI-agenter blir mer inbäddade i utvecklingsflöden, vad ser en väl förberedd teknisk organisation ut jämfört med en som inte är redo?

Ironiskt nog är det inte så annorlunda än att vara redo att ta in en klass sommarselever. Du behöver starka automatiserade testsviter, solid dokumentation, en mogen CI/CD-pipeline och de skyddsräcken du skulle sätta på plats när du lägger till en pålitlig men outbildad utvecklare i laget.

Vad som också är viktigt, och människor tenderar att underskatta det, är att komma tillbaka regelbundet för att granska grunderna: dina agentregler, dina AGENTS.MD-filer. Du kan göra en solid första omgång, men det är lätt att komma in i en rytm av att skeppa i den nya vägen och glömma att du faktiskt kan träna bort många dåliga standarder. Saker som att lära agenten att köra tester före varje commit borde inte kräva en mänsklig påminnelse varje gång.

En diagnostisk fråga jag skulle ställa till varje teknisk ledare: kan du berätta vad dina agenter producerade förra sprinten, vilken av den utdatan som accepterades som den var och var revisionen koncentrerades? Om du kan svara på det, har du instrumenteringen för att förbättra. Om du inte kan, flyger du på känsla.

Du har betonat vikten av att anpassa tekniska ansträngningar till affärsresultat. Hur kan organisationer överbrygga den klyftan på ett praktiskt och mätbart sätt?

Jag har sett två huvudsakliga felmodeller. Den första är företag som inte parar tekniska team med produkter. Många teamstrukturer är arv och har funnits under lång tid. Ett team kan äga en del av tre olika produkter medan ett annat äger fyra helt. Tekniskt investeringsbeslut kommer i huvudsak ner till personalstyrka, och när team inte är anpassade till produkter, blir det mycket svårt att se var affärstillväntningar avviker från verkligheten.

Den andra felmodellen är att inte ta hänsyn till allt arbete som går in i att bygga och underhålla programvara. Det finns en stor kategori affärsosynlig tekniskt arbete. Mitt favoritexempel är att hålla paket uppdaterade. Icke-tekniska affärsledare har ofta svårt att förstå värdet eller varför det är pågående och oförutsägbart. Men de kan förstå investeringskategorier. Om du rammar in det som “kritiska säkerhetsuppdateringar” och visar i genomsnitt hur mycket kapacitet det förbrukar, talar du ett språk de kan arbeta med.

Om du frågar en försäljningsledare att välja mellan några npm-paketuppdateringar och funktionen de behöver för att stänga ett avtal, vinner funktionen alltid. Men om du rammar in det som “vi faller ur SOC-efterlevnad eller vi skeppar den här funktionen”, visar du dem två avvägningar de faktiskt kan utvärdera. Den omramningen är hela spelet. Vi har sett kunder skära ner sin R&D-kapitaliseringsrapporteringstid med mer än två tredjedelar bara genom att göra det arbetet automatiskt snarare än manuellt. Mekanismen är densamma, oavsett om målet är kapitaliseringsrapportering, personalbehov, eller bevisande AI-avkastning: ansluten data ersätter korrelerade kalkylblad.

Med tanke på din bakgrund i både hands-on-teknik och undervisning i webbutveckling, hur ser du på utvecklingen av utvecklarens roll när AI tar på sig mer av kodningsarbetet?

Ärligt talat är jag lite orolig, även om jag litar på att smarta människor kommer att lösa det.

Mina bekymmer är verkliga. Nyutexaminerade kommer snart att gå in på arbetsmarknaden utan att ha kodat i en värld utan kodagenter. Har utbildningen hunnit med det? Verktygen flyttar snabbt; högre utbildning flyttar inte alltid i takt med dem. En annan förändring jag ser är suddningen av gränserna mellan seniora ingenjörer och seniora produktmänniskor. De mest framgångsrika praktikerna i den nya modellen är ingenjörer som är djupt engagerade i produkttänkande.

Vad som blir mer värdefullt är omdöme: förmågan att definiera ett problem tillräckligt exakt för att en agent ska kunna lösa det, utvärdera om lösningen är korrekt och fånga de subtila misslyckanden som passerar CI men skapar arkitektoniska problem senare. Seniora ingenjörer förstärker sin fördel: de har kodbasen och omdömet att styra agentutdata och veta vilka utdata som ska lita på. Bekymret är för tidigare karriärvägar. Den traditionella vägen att bygga det omdömet var att skriva mycket kod och lära sig av misstagen. Den återkopplingscykeln förändras på sätt som branschen ännu inte har arbetat igenom.

Historien erbjuder dock någon tröst. Det fanns en betydande kontingent av människor som trodde att kompilatorer skulle sätta assembly-utvecklare ur arbete. Teknologiskiftet hände som de förutsåg. Vad hände med utvecklarna som inte följde samma manus? Under det följande decenniet ökade det totala antalet utvecklare. Många av dessa assembly-programmerare lärde sig ett nytt språk och utmärkte sig på grund av sin grundläggande kunskap. Jag tror att en version av det mönstret upprepar sig igen.

Om du ser framåt, hur ser du på AI som omformar programvaruutvecklingslivscykeln under de kommande tre till fem åren, och var kommer företag att få den största konkurrensfördelen?

Vi kommer att se en funktionell kapplöpning som inte har setts tidigare. När kostnaden för att bygga närmar sig noll, står företag, även stora, inför en ny begränsning: att samla in och validera tillräckligt med kundfeedback för att fortsätta bygga kvalitetsprodukter i stor skala.

Förändringen som måste ske är att ribban för vad som byggs måste höjas. Den nuvarande begränsningen i de flesta tekniska organisationer är enkel: fem topprioriteringar, kanske två levererade. Med agenter vänder förhållandet. Du kan ha fem topp, tio nästa och tjugo kanske på listan, och skeppa hundra. Frågan som ingen har besvarat ännu är hur du håller de sista sextiofem från att vara dåligt konceptualiserade och dåligt genomförda.

Två saker jag är ganska säker på för den tre-till-femårsperioden. Först kommer den största konkurrensfördelen inom teknisk AI att komma från kontextdjup och -bredd, inte modellkvalitet. Modellerna blir tabellstak; varje verktyg kommer att ha kapabla. Vad som kommer att differentiera de ledande plattformarna är hur djupt de förstår din specifika organisation: dina repos, ditt teamstruktur, din leveranshistorik, dina distributionsmönster. Verktygen som känner till ditt system kommer att producera grundläggande olika svar än de som inte gör det. För det andra, skiftet från reaktiv till proaktiv. Idag svarar verktygen på frågor när de ställs. Om några år kommer de ledande verktygen att observera kontinuerligt och yta risk innan du frågar. Organisationer som bygger den kontextskiktet nu förstärker sin fördel. Den nästa generationens verktyg måste lösa kvalitetsproblemet i stor skala, och de organisationer som löser det först kommer att ha en verklig fördel.

Tack för den underbara intervjun, läsare som vill lära sig mer bör besöka Allstacks.