Jeremy Freeman, mede-oprichter en CTO van Allstacks – Interviewreeks

Jeremy Freeman, mede-oprichter en CTO van Allstacks, is een software-ingenieur, technisch architect en ondernemer met een carrière die software-ontwikkeling, hardware-engineering, machine learning en productinnovatie omvat. Sinds de oprichting van Allstacks in 2017, heeft hij de architectuur en ontwikkeling van het kernplatform van het bedrijf geleid, waarmee softwareleveringbeheer wordt getransformeerd door middel van predictieve analytics en AI-gedreven forecasting. Voordat hij bij Allstacks kwam, had Freeman leidinggevende functies bij Ravioli Labs en CertiRx, waar hij werkte aan software-engineering, onderzoek, anti-neptechnologieën en productontwikkeling. Eerder in zijn carrière verwierf hij ervaring bij startups, enterprise-technologiebedrijven en academische instellingen, waaronder het geven van webdevelopmentlessen aan Wake Technical Community College. Zijn technische achtergrond omvat ingebedde systemen, hardware-ontwerp, grote softwareplatforms, machine learning en leiderschap in de technologie, waardoor hij een uniek perspectief heeft op het bouwen van datagedreven producten die organisaties helpen bij het verbeteren van de resultaten van softwarelevering.

Allstacks is een platform voor software-engineeringintelligentie en value stream management dat organisaties helpt bij het verbeteren van de voorspelbaarheid en efficiëntie van software-ontwikkeling. Het platform integreert gegevens uit tools die worden gebruikt in de software-ontwikkelingscyclus, waaronder projectmanagement-, broncode- en implementatiesystemen, en past vervolgens AI en machine learning toe om risico’s te identificeren, leveringsresultaten te voorspellen en actiegerichte inzichten te bieden. Door engineering- en productleiders zicht te geven in projectgezondheid, teamprestaties en ontwikkelingstrends, stelt Allstacks organisaties in staat om meer geïnformeerde beslissingen te nemen, de onzekerheid van levering te verminderen en engineeringinspanningen beter af te stemmen op bedrijfsdoelstellingen. De technologie is ontworpen om bedrijven te helpen overstappen van intuïtief naar planning op basis van real-time operationele gegevens om de prestaties van softwarelevering en strategische uitvoering te verbeteren.

U hebt een unieke reis gehad van het leiden van onderzoeks- en engineeringteams die machine learning toepassen op software-ontwikkelingsgegevens tot het mede-oprichten van Allstacks in 2017. Welke specifieke lacunes of terugkerende problemen hebt u waargenomen die u uiteindelijk ertoe hebben aangezet om het bedrijf op te richten?

Toen we Allstacks startten, hebben we veel tijd besteed aan klantonderzoek, en het patroon dat naar voren kwam was consistent: bedrijf na bedrijf had enorme hoeveelheden gegevens en had nog steeds geen idee wat er eigenlijk gebeurde. Software leveren was onvoorspelbaar, ondanks het feit dat er slimme mensen in de kamer waren. Dat probleem was niet opgelost.

Wat al snel duidelijk werd, was dat dit geen rapportageprobleem of integratieprobleem was. Het was een relatieprobleem. Om te weten of iets risico loopt, moet u weten hoe een werkitem verbonden is met een tak, de tak verbonden is met een PR, de PR verbonden is met een sprintdoel en het sprintdoel verbonden is met een bedrijfsinitiatief. Die grafiek bestaat niet standaard in de standaardtoolketen. U moet het bouwen. En het goed bouwen is fundamenteel een inferentieprobleem, waarbij de ML-achtergrond direct nuttig werd.

Ons doel vanaf het begin was niet om een individuele ontwikkelaar sneller te maken op functie X. Het was om de hele organisatie beter te maken. Hoe kunt u engineeringinspanningen afstemmen op bedrijfsresultaten? Hoe kunt u ervoor zorgen dat engineering echt dienstbaar is aan het bedrijf in plaats van alleen naast het te bestaan? U hebt een beter begrip van de gegevensrelaties nodig om die vragen te beantwoorden. Het zijn die vragen die bijna elke productbeslissing hebben gestuurd die we hebben genomen.

Allstacks richt zich op het analyseren van gegevens in de hele software-ontwikkelingscyclus. Welke soorten signalen of patronen zijn het meest voorspellend als het gaat om het identificeren van leveringsrisico’s op tijd?

Ik denk niet dat er een enkele set metrische gegevens is die goed en slecht voorspelt, maar eerder patronen voor verschillende fasen en soorten organisaties. Wat ik nuttiger heb gevonden, is het erkennen dat engineeringorganisaties door seizoenen van verbetering gaan. Deze maand is het databaseprestaties. Volgende maand is het communicatie tussen teams. Dan is het “waarom kunnen we geen PR’s sluiten?” Dan is het observatie. Als engineeringleider zwemt u in signalen: sommige diagnostisch, sommige bewakend en veel lawaai.

Wat helpt, is beginnen met het probleem dat u daadwerkelijk ziet, niet met een metrisch dat u wilt verbeteren. Als u vraagt “waarom lijkt het alsof we minder leveren dan vorig jaar”, is dat het juiste startpunt. Van daaruit denk ik dat u drie soorten metrische gegevens nodig hebt: ten eerste, hoe weet u of het probleem echt is (misschien PR-telling per ontwikkelaar in de tijd); ten tweede, welke veranderingen brengt u aan en hoe volgt u deze op (zeg, adoptie van een AI-PR-beoordelaar als dat uw interventie is); en ten derde, hoe belangrijk is dit probleem voor het bedrijf. Uw instinct kan juist zijn dat u 20 procent minder code levert, maar het echte verhaal kan zijn dat QA nu drie keer langer duurt. U hebt alle drie lenzen nodig om te weten of u het juiste ding oplost.

U hebt in verschillende branches gewerkt, zoals de gezondheidszorg, energie en technologie. Hoe verschillen de uitdagingen in softwarelevering tussen deze sectoren, en hoe heeft dat de Allstacks-platform beïnvloed?

Ik waardeer mijn ervaring in niet-pure technologiebranches. In SaaS-bedrijven is het gemakkelijk om te verdwalen in het idee dat de software zelf het doel is. Wanneer u in een bedrijf bent waar u de software niet rechtstreeks verkoopt, wordt uw rol veel duidelijker: technologie is er om het bedrijf te ondersteunen. Ik maak vaak de grap dat als het bedrijf alles op hetzelfde tempo kon bereiken zonder met mij te hoeven omgaan, ze die optie zonder aarzeling zouden kiezen.

Dat perspectief is eigenlijk nuttig. Het contextualiseert wat we allemaal in deze branche doen, en het zet veel technische debatten terug in hun plaats. Het bedrijf maalt niet om of u Python of Go gebruikt. Tijd besteden aan die herschrijving is waarschijnlijk niet waar de echte rendementen liggen.

Wat overal consistent blijft, is het fragmentatieprobleem. Ongeacht de branche, heeft elke engineeringorganisatie gegevens verspreid over een dozijn tools met beperkte verbindingen tussen hen. De details verschillen: gereguleerde branches hebben langere planningscycli en een lagere tolerantie voor onzekerheid in vereisten, omdat de kosten van het bouwen van de verkeerde dingen hoger zijn. High-velocity technologiebedrijven accumuleren verborgen schulden sneller. Maar de kernfoutmodus is hetzelfde. Teams kunnen u vertellen wat is geleverd. Ze kunnen niet traceren waarom iets gleed, wat het kostte of waar het risico zichtbaar was voordat het een probleem werd. Dat is hoe we het platform hebben gebouwd.

Er is een groeiend verhaal dat AI de codering zelf versnelt en zwakheden elders blootlegt. Waarom worden vereisten, planning en specificatieklaarheid de echte bottlenecks?

We zien dit dagelijks. Met een goede agent en een solide harnas eromheen, kunt u van idee, soms rechtstreeks vanuit de mond van een klant, naar productie gaan in letterlijke uren.

Een deel van wat deze verschuiving zo significant maakt, is de verandering in de feedbacklus. Met copilot-achtige tools is de mens in de lus voor elke suggestie. De AI biedt een voltooiing; u accepteert of wijt het af. Wanneer het verkeerd is, vangt u het snel op. De blaststraal van een slechte suggestie is één regel code. Agentic coding werkt anders: u geeft de agent een doel, het decomponeert het werk, voert een multi-stapplan uit en levert een werkend module. De mens bekijkt de output, niet elke stap. Wanneer de specificatie verkeerd is, bouwt de agent de hele implementatie naar die verkeerde specificatie en ontdekt u het pas bij de beoordeling.

Dat klinkt als pure upside totdat u erkent wat de vorige vertragingstijd eigenlijk deed. De vertraging diende een echt doel. Meerdere rondes van slimme mensen die beoordelen, plannen, testen en werken aan ideeën om een beter systeem te produceren.

De verleiding nu is om iets uit te voeren en al die stappen te omzeilen. Maar agenten en harnassen zijn nog niet klaar voor de volledige SDLC. De snelheid is echt. De kwaliteitsbewaking die eerder plaatsvond in al die langzamere stappen is niet vervangen. Dat is de kloof.

Veel organisaties meten productiviteit nog steeds met verouderde metrische gegevens. Wat doen leiders fundamenteel verkeerd over productiviteit in een AI-gedreven ontwikkelomgeving?

Mensen zijn aanzienlijk volwassener geworden op dit onderwerp sinds we Allstacks zijn begonnen. Meting is verplaatst naar dingen die echt belangrijk zijn, en frameworks zijn meer geavanceerd geworden. AI keert alles om.

Traditionele software-ontwikkeling was fundamenteel beperkt door hoe snel een ontwikkelaar code kon schrijven die voldoet aan de vereisten van het bedrijf en de onderliggende technologie. Die kosten naderen nul. Waar we naartoe gaan, is iets dichter bij een individuele ontwikkelaar als manager van agenten. Dat model vereist een heel andere aanpak van productiviteitsmeting, een die gebaseerd is op iets anders dan gegenereerde tokens of bestede ontwikkelaarsuren.

Een deel van het gevaar met de huidige metrische gegevens is dat ze verhullen wat er echt gebeurt op teamniveau. Senior engineers met AI-tools compeneren hun voordeel: ze hebben de codebase-context en het oordeel om agentoutput te sturen en hun fouten te vangen. Vroegere carrièremogelijkheden genereren dezelfde codevolume, maar besteden meer tijd aan het auditen van output die ze niet volledig kunnen evalueren. Aggregate velocity ziet er goed uit, misschien zelfs verbeterd. De kloof tussen die twee groepen komt nergens in een standaarddashboard tevoorschijn. De juiste vraag om te beginnen is niet “hoeveel sneller gaan we” maar “hoeveel van wat we hebben geleverd was goed vanaf het begin”.

We hebben nog geen industriebrede consensus over het juiste metingmodel, maar teams die beginnen met het volgen van outputkwaliteit en herbouwpercentage, niet alleen doorvoer en adoptie, zullen beter gepositioneerd zijn dan teams die wachten tot iemand anders het uitvindt.

Uw platform verbindt gegevens uit tools zoals projectmanagement-systemen en code-repositories. Hoe belangrijk is het om deze gefragmenteerde gegevensbronnen te verenigen, en wat gebeurt er als organisaties hierin falen?

Allstacks is succesvol geweest in deze ruimte omdat we contextgrafieken hebben gebouwd sinds voordat dat een term was. We erkenden vroeg dat het verbinden van alle gegevens samen noodzakelijk was om de vragen te beantwoorden die klanten daadwerkelijk stelden.

Wanneer die verbinding niet bestaat, kan AI die op uw engineeringgegevens werkt alleen een deel van het plaatje zien. Het kan het projectmanagement-systeem analyseren. Het kan de code-repository analyseren. Wat het niet kan doen, is een leveringsvertraging terug traceren naar een geblokkeerde afhankelijkheid over drie tools, omdat de relatie tussen die signalen niet in de datalaag bestaat. U krijgt oppervlakkige analyse op zijn best en vertrouwde, verkeerde aanbevelingen op het ergste. Modelkwaliteit lost dit niet op. U kunt de meest capabele model beschikbaar bovenop raw API-integraties plaatsen en nog steeds het werkelijke probleem missen, omdat de gegevens de relatie tussen de signalen niet coderen. Garbage in, garbage out, ongeacht hoe slim het model is.

Die verbinding is de basis. Het is wat ons in staat stelde om als eerste op de markt te komen met capaciteiten die nog steeds niet zijn gerepliceerd.

Naarmate AI-agenten meer ingebed raken in ontwikkelingsworkflows, hoe ziet een goed voorbereide engineeringorganisatie eruit in vergelijking met een die niet klaar is?

Ironisch genoeg is het niet zo anders dan klaar zijn om een klas zomervakantie-internen aan te nemen. U hebt sterke geautomatiseerde testsuites nodig, solide documentatie, een volwassen CI/CD-pijplijn en de railing die u zou plaatsen wanneer u een vertrouwd maar ongetraind ontwikkelaar aan het team toevoegt.

Wat ook belangrijk is, en mensen onderschatten dit, is terugkeren naar de basis: uw agentregels, uw AGENTS.MD-bestanden. U kunt een solide eerste ronde doen, maar het is gemakkelijk om in een ritme te komen van leveren op de nieuwe manier en te vergeten dat u veel slechte standaardinstellingen kunt trainen. Dingen zoals het leren van de agent om tests uit te voeren voordat elke commit, zou geen menselijke herinnering elke keer moeten vereisen.

Een diagnostische vraag die ik aan elke engineeringleider zou stellen: kunt u me vertellen wat uw agenten vorige sprint hebben geproduceerd, welke output als-is is geaccepteerd versus herschreven en waar de revisie-inspanning geconcentreerd was? Als u dat kunt beantwoorden, hebt u de instrumentatie om te verbeteren. Als u dat niet kunt, vliegt u op gevoel.

U hebt de nadruk gelegd op het belang van het afstemmen van engineeringwerk op bedrijfsresultaten. Hoe kunnen organisaties die kloof bruggen in een praktische en meetbare manier?

Ik heb twee hoofdfoutmodi gezien. De eerste zijn bedrijven die engineeringteams niet koppelen aan producten. Veel teamstructuren zijn legacy en zijn al lang geleden ingesteld. Een team kan een deel van drie verschillende producten bezitten, terwijl een ander team vier helemaal bezit. Engineeringinvesteringen komen grotendeels neer op headcount, en wanneer teams niet zijn afgestemd op producten, wordt het moeilijk om te zien waar bedrijfsverwachtingen afwijken van de realiteit.

De tweede foutmodus is het niet meenemen van alle werk dat nodig is om software te bouwen en te onderhouden. Er is een enorme categorie bedrijfszichtbaar engineeringwerk. Mijn favoriete voorbeeld is het bijwerken van pakketten. Niet-technische bedrijfsleiders worstelen vaak met het begrijpen van de waarde of waarom het voortdurend en onvoorspelbaar is. Maar ze kunnen investeringscategorieën begrijpen. Als u het kaderen als “kritieke beveiligingsupgrades” en toont hoeveel capaciteit het gemiddeld verbruikt, spreekt u een taal die ze kunnen werken.

Als u een salesleider vraagt om te kiezen tussen een aantal npm-pakketupdates en de functie die ze nodig hebben om een deal te sluiten, wint de functie elke keer. Maar als u het kaderen als “we vallen uit de SOC-compliance of we leveren deze functie”, toont u hen twee afwegingen die ze echt kunnen evalueren. Die herformulering is het hele spel. We hebben klanten gezien die hun R&D-kapitalisatierapportagetijd met meer dan twee derde hebben verlaagd door alleen maar het werk automatisch te classificeren in plaats van handmatig. Het mechanisme is hetzelfde, of het doel nu kapitalisatierapportage, headcountrechtvaardiging of AI-ROI-bewijs is: verbonden gegevens vervangen gecorreleerde spreadsheets.

Gegeven uw achtergrond in zowel hands-on engineering als het geven van webdevelopmentlessen, hoe ziet u de rol van ontwikkelaars evolueren naarmate AI meer van de coderingswerklast overneemt?

Eerlijk gezegd, maak ik me een beetje zorgen, hoewel ik vertrouw dat slimme mensen het wel zullen uitvinden.

Mijn zorgen zijn reëel. Afgestudeerden zullen binnenkort de arbeidsmarkt betreden zonder ooit te hebben gecodeerd in een wereld zonder codeeragenten. Is onderwijs hierop voorbereid? De tools bewegen snel; hoger onderwijs beweegt niet altijd mee. De andere verschuiving die ik zie, is het vervagen van senior engineers en senior productmensen. De meest succesvolle beoefenaars in het nieuwe model zijn engineers die diep in productdenken zijn geïnvesteerd.

Wat meer waarde krijgt, is oordeel: de mogelijkheid om een probleem precies genoeg te definiëren voor een agent om het op te lossen, te evalueren of de oplossing correct is en de subtiele fouten te vangen die CI passeren, maar later architecturale problemen creëren. Senior engineers compeneren hun voordeel omdat ze agentoutput kunnen sturen en weten welke outputs te vertrouwen. De zorg is voor de vroegere carrièrepaden. De traditionele manier om dat oordeel op te bouwen was om veel code te schrijven en van de fouten te leren. Die feedbacklus verandert op manieren die de industrie nog niet volledig heeft uitgewerkt.

Dat gezegd hebbende, biedt de geschiedenis enige geruststelling. Er was een aanzienlijke contingent van mensen die geloofden dat compilers assembly-ontwikkelaars buiten spel zouden zetten. De technologieverschuiving gebeurde zoals ze voorspelden. Wat gebeurde er met de ontwikkelaars die hetzelfde script niet volgden? In de loop van het volgende decennium groeide het totale aantal ontwikkelaars. Veel van die assembly-programmeurs leerden een nieuwe taal en excelleerden omdat ze een solide kennisbasis hadden. Ik denk dat een versie van dat patroon zich opnieuw afspeelt.

Kijkend naar de toekomst, hoe ziet u AI de software-ontwikkelingscyclus veranderen in de komende drie tot vijf jaar, en waar zullen bedrijven de grootste concurrentievoordeel behalen?

We gaan een functie-armsrace zien zoals we nog nooit eerder hebben gezien. Aangezien de kosten om te bouwen naderen tot nul, staan bedrijven, zelfs grote, voor een nieuwe beperking: het verzamelen en valideren van voldoende klantfeedback om kwaliteitsproducten op schaal te blijven bouwen.

De verschuiving die moet gebeuren, is dat de lat voor wat wordt gebouwd omhoog moet. De huidige beperking in de meeste engineeringorganisaties is simpel: vijf topprioriteiten, misschien twee geleverd. Met agenten keert het ratio om. U kunt vijf topprioriteiten hebben, tien volgende en twintig misschien op de lijst, en honderd leveren. De vraag die niemand nog volledig heeft beantwoord, is hoe u die laatste vijfenzestig ervan weerhoudt om slecht geconceptioneerd en slecht uitgevoerd te zijn.

Twee dingen waar ik redelijk zeker van ben voor het tijdvak van drie tot vijf jaar. Ten eerste, zal het concurrentievoordeel in engineering-AI komen van contextdiepte en -breedte, niet van modelkwaliteit. De modellen worden een standaard; elk gereedschap zal capabele hebben. Wat de leidende platforms zal onderscheiden, is hoe diep ze uw specifieke organisatie begrijpen: uw repositories, uw teamstructuur, uw leveringsgeschiedenis, uw implementatiepatronen. De tools die uw systeem kennen, zullen fundamenteel andere antwoorden produceren dan degenen die dat niet doen. Ten tweede, de verschuiving van reactief naar proactief. Vandaag de dag beantwoorden tools vragen wanneer ze worden gesteld. Over een paar jaar zullen de leidende tools continu observeren en risico’s naar boven brengen voordat u vraagt. Organisaties die die contextlaag nu opbouwen, compeneren een voordeel. De volgende generatie van gereedschappen moet het kwaliteitsprobleem op schaal oplossen, en de organisaties die het eerst uitvinden, zullen een echt voordeel hebben.

Bedankt voor het geweldige interview, lezers die meer willen leren, moeten Allstacks bezoeken.