Jeremy Freeman, spoluzakladatel a technický ředitel Allstacks – Interview Series

Jeremy Freeman, spoluzakladatel a technický ředitel Allstacks, je softwarový inženýr, technologický architekt a podnikatel s kariérou, která zahrnuje softwarový vývoj, hardwarové inženýrství, strojové učení a produktové inovace. Od spoluzaložení Allstacks v roce 2017 vedl architekturu a vývoj jádrové platformy společnosti, která pomáhá transformovat řízení softwarového vývoje pomocí prediktivní analýzy a AI poháněného forecastingu. Před Allstacks zastával Freeman vedoucí role v Ravioli Labs a CertiRx, kde pracoval na softwarovém inženýrství, výzkumu, technologiích proti padělkům a produktovém vývoji. Na počátku své kariéry získal zkušenosti napříč startupy, podniky s technologiemi a akademickou sférou, včetně výuky webového vývoje na Wake Technical Community College. Jeho technické zázemí zahrnuje vestavěné systémy, hardwarový design, velké softwarové platformy, strojové učení a inženýrské vedení, což mu dává jedinečný pohled na budování datově řízených produktů, které pomáhají organizacím zlepšit výsledky softwarového vývoje.

Allstacks je platforma pro inteligenci softwarového inženýrství a řízení hodnotového toku, která pomáhá organizacím zlepšit předvídatelnost a efektivitu softwarového vývoje. Platforma integruje data z nástrojů používaných v celém životním cyklu softwarového vývoje, včetně systémů projektového managementu, zdrojového kódu a nasazení, a poté aplikuje AI a strojové učení na identifikaci rizik, předpověď výsledků dodávky a poskytování akčních informací. Poskytováním leaderům inženýrství a produktů přehledu o zdraví projektů, výkonu týmu a trendech vývoje umožňuje Allstacks organizacím činit informovanější rozhodnutí, snižovat nejistotu dodávky a lépe sladit úsilí inženýrství s obchodními cíli. Jeho technologie je navržena tak, aby pomohla společnostem překonat intuici poháněné plánování využíváním reálných provozních dat ke zlepšení výkonu softwarového vývoje a strategického provedení.

Měli jste jedinečnou cestu od vedení výzkumných a inženýrských týmů aplikujících strojové učení na data softwarového vývoje až po spoluzaložení Allstacks v roce 2017. Jaké konkrétní mezery nebo opakující se problémy jste pozorovali, které vás nakonec vedly k vybudování společnosti?

Když jsme začali Allstacks, strávili jsme spoustu času na počátku zákaznickým objevováním, a vzorec, který se objevil, byl konzistentní: společnost za společností měla enormní množství dat a přesto neměla žádnou představu o tom, co se vlastně děje. Dodání softwaru bylo nepředvídatelné, přestože v místnosti byli někteří z nejchytřejších lidí. Ten problém nebyl vyřešen.

Co se brzy stalo zřejmým, bylo to, že to nebyla zpráva nebo integrační problém. To byla vztah problém. Abyste věděli, zda něco je ohroženo, musíte vědět, jak pracovní položka souvisí s větví, větev souvisí s PR, PR souvisí se sprintovým cílem a sprintový cíl souvisí s obchodním úsilím. Ten graf neexistuje nikde ve standardním nástroji. Musíte ho postavit. A postavení ho dobře je fundamentálně inferenční problém, kde se mi hodí zázemí ve strojovém učení.

Naším cílem od začátku nebylo udělat jednotlivého developera rychlejšího na funkci X. Bylo to udělat celou organizaci lepší. Jak sladit úsilí inženýrství s obchodními výsledky? Jak udělat inženýrství skutečně sloužit obchodu, místo aby jen existovalo vedle něj? K tomu potřebujete lepší pochopení vztahů dat. To jsou otázky, které poháněly téměř každé produktové rozhodnutí, které jsme učinili.

Allstacks se zaměřuje na analýzu dat napříč celým životním cyklem softwarového vývoje. Jaké typy signálů nebo vzorců jsou nejvíce předpovědné, pokud jde o identifikaci rizika dodávky brzy?

Nemyslím si, že existuje jediná sada metrik, která předpovídá dobré a špatné, ale spíše vzorce pro různé fáze a typy organizací. Co jsem našel více užitečným, je uznání, že inženýrské organizace procházejí sezonami zlepšování. Tento měsíc je to výkon databáze. Příští měsíc je to mezitýmová komunikace. Pak je to „proč nemůžeme zavřít žádný PR?“ Pak je to pozorovatelnost. Jako inženýrský leader jste obklopen signály: některé diagnostické, některé monitorovací a mnoho z nich je jen hluk.

Co pomáhá, je začít s problémem, který skutečně vidíte, ne metrikou, kterou chcete zlepšit. Pokud se ptáte „proč se zdá, že dodáváme méně než loni“, je to správný výchozí bod. Odtud si myslím, že potřebujete tři typy metrik: první, jak víte, že problém je reálný (možná počet PR na developera za čas); druhý, jaké změny děláte a jak je sledujete po cestě (řekněme přijetí AI PR recenzenta, pokud je to vaše zásah); a třetí, jak významný je tento problém pro obchod. Vaše instinkt může být správný, že dodáváte o 20 procent méně kódu, ale skutečný příběh může být, že QA nyní trvá třikrát déle. Potřebujete všechny tři čočky, abyste věděli, zda řešíte správnou věc.

Pracovali jste napříč odvětvími, jako je zdravotnictví, energie a technologie. Jak se problémy s dodávkou softwaru liší napříč těmito sektory a jak to formovalo platformu Allstacks?

Velmi si vážím své zkušenosti v nepure technických sektorech. Ve společnostech SaaS je snadné se ztratit v myšlence, že software sám o sobě je cílem. Když jste v podniku, kde neprodáváte software přímo, vaše role se stává mnohem jasnější: technologie je tam, aby podporovala podnik. Často žertuji, že kdyby podnik mohl dosáhnout všeho ve stejné rychlosti, aniž by musel mít co do činění se mnou, zvolil by tuto možnost bez váhání.

Ten pohled je vlastně užitečný. Kontextualizuje, co všichni děláme v tomto odvětví, a vrátí mnoho technických debat zpět do jejich místa. Podnik se nezajímá o to, zda používáte Python nebo Go. Trávit cykly na této přepisu je pravděpodobně ne tam, kde je skutečný návrat.

Co zůstává konzistentní napříč každým odvětvím, je problém fragmentace. Bez ohledu na sektor má každá inženýrská organizace data rozptýlená napříč desítkami nástrojů s omezenou spojovací tkání mezi nimi. Specifika se liší: regulovaná odvětví mají delší plánovací cykly a nižší toleranci k nejistotě v požadavcích, protože cena budování špatné věci je vyšší. Vysokorychlostní technické dílny akumulují skrytý dluh rychleji. Ale základní selhání je stejné. Týmy mohou říci, co bylo dodáno. Nemohou vysledovat, proč něco uklouzlo, co to stálo, nebo kde bylo riziko viditelné, než se stalo problémem. To je to, co formovalo, jak jsme postavili platformu.

Existuje rostoucí narativ, že AI urychluje samotné kódování, zatímco odhaluje slabosti jinde. Proč se požadavky, plánování a připravenost specifikací stávají skutečnými úzkými místy?

Vidíme to denně. S dobrým agentem a solidním uchopením kolem něj můžete přejít z ideje, někdy přímo z úst zákazníka, do produkce v doslovných hodinách.

Část toho, co činí tuto změnu tak významnou, je změna ve zpětné vazbě. S nástroji typu copilot můžete mít člověka ve smyčce na každé návrh. AI nabízí dokončení; přijmete nebo odmítnete jej okamžitě. Když je to špatně, chytnete to rychle. Blast radius špatného návrhu je jeden řádek kódu. Agentic kódování funguje jinak: dáte agentovi cíl, rozloží práci, provede více krokový plán a dodá funkční modul. Člověk přezkoumá výstup, ne každý krok. Když je specifikace špatná, agent postaví celou implementaci na tu špatnou specifikaci a dozvíte se o tom při přezkumu.

To zní jako čisté plus, dokud si neuvědomíte, co předchozí zpoždění vlastně dělalo. Zpoždění sloužilo skutečnému účelu. Více kol inteligentních lidí, kteří přezkoumávají, plánují, testují a pracují na ideách, aby vytvořili lepší systém.

Pokušení je nyní obejít všechno to. Ale agenti a uchopení nejsou připraveni pro celý životní cyklus softwarového vývoje yet. Rychlost je reálná. Kvalita brány, která se dříve děla napříč všemi těmi pomalejšími kroky, nebyla nahrazena. To je mezera.

Mnohé organizace stále měří produktivitu pomocí zastaralých metrik. Co vedoucí dostávají fundamentálně špatně o produktivitě ve vývojovém prostředí poháněném AI?

Lidé dospěli v této otázce značně od doby, kdy jsme začali Allstacks. Měření se posunulo směrem k věcem, které skutečně záleží, a rámce se staly sofistikovanějšími. AI převrací vše.

Tradiční softwarový vývoj byl fundamentálně omezen rychlostí, s jakou mohl developer psát kód, který splňoval požadavky podniku a základních technologií. Ta cena se blíží nule. Čím se blížíme, je něco bližšího individuálnímu developerovi jako manažerovi agentů. Ten model vyžaduje úplně jiný přístup k měření produktivity, který je založen na něčem jiném než tokenech generovaných nebo developer-hodinách strávených.

Část nebezpečí spojeného se současnými metrikami je, že skrývají, co se skutečně děje na úrovni týmu. Senioři s AI nástroji zvyšují svou výhodu: mají kontext kódbáze a úsudku, aby směrovali výstup agenta a chytili jeho selhání. Ranější kariérní inženýři často generují stejný objem kódu, ale tráví více času auditem výstupu, který nemohou plně vyhodnotit. Agregovaná rychlost vypadá v pořádku, možná dokonce zlepšená. Mezera mezi těmito dvěma skupinami se neobjeví nikde ve standardním dashboardu. Správná otázka, kterou byste měli začít klást, není „jak rychle jsme“, ale „kolik z toho, co jsme dodali, bylo správné poprvé“.

Nemáme 아직 konsensu v odvětví o správném měřicím modelu, ale týmy, které začnou sledovat kvalitu výstupu a míru přepisu, nejenom propustnost a přijetí, budou lépe umístěny než týmy, které čekají, až někdo jiný to vyřeší.

Vaše platforma spojuje data z nástrojů, jako jsou systémy projektového managementu a repozitáře kódu. Jak důležité je sjednotit tyto fragmentované zdroje dat, a co se stane, když organizace selhávají?

Allstacks byl úspěšný v tomto prostoru, protože jsme stavěli kontextové grafy, ještě předtím, než to byl termín. Rozpoznali jsme brzy, že propojení všech dat dohromady bylo nezbytné k odpovědi na otázky, které zákazníci skutečně kladli.

Když toto propojení neexistuje, AI, které funguje na vašich inženýrských datech, může vidět pouze část obrazu. Může analyzovat, co je ve vašem systému projektového managementu. Může analyzovat, co je ve vašem repozitáři kódu. Co nemůže udělat, je vysledovat zpoždění dodávky zpět k zablokované závislosti napříč třemi nástroji, protože vztah mezi těmito signály neexistuje ve vrstvě dat. Získáte povrchní analýzu nejlepším případě a sebevědomé, špatné doporučení v nejhorším případě. Kvalita modelu toto neřeší. Můžete umístit nejkapacitnější model dostupný na top raw API integrací a stále minout skutečnou příčinu problému, protože data neobsahují vztah mezi signály. Garbage in, garbage out, bez ohledu na to, jak chytrý je model.

To propojení je základem. To je to, co nám umožnilo být první na trhu s funkcemi, které dosud nebyly replikovány.

Jak se organizace připravují na to, aby se staly inženýrskými organizacemi, které jsou dobře připraveny na AI agenty, které se stávají více zabudovanými do vývojových toků?

Ironicky, není to tak odlišné od toho, být připraven přivést třídu letních stážistů. Potřebujete silné automatizované testovací sady, solidní dokumentaci, zralou CI/CD pipeline a zábrany, které byste umístili, když přidáváte důvěryhodného, ale nevyškoleného developera do týmu.

Co je také důležité, a lidé tendenci podceňovat, je návrat k základům: vaše agentic pravidla, vaše AGENTS.MD soubory. Můžete udělat solidní první průchod, ale je snadné se dostat do rytmu dodání v novém způsobu a zapomenout, že můžete skutečně vycvičit mnoho špatných výchozích nastavení. Věci, jako učení agenta spustit testy před každým commitem, by neměly vyžadovat lidskou připomínku každý čas.

Jedna diagnostická otázka, kterou bych položil každému inženýrskému leaderovi: můžete mi říci, co vaše agenty produkovaly minulý sprint, který z toho výstupu byl přijat jako-is versus revidován, a kde byla úsilí o revizi koncentrováno? Pokud můžete odpovědět, máte instrumentaci ke zlepšení. Pokud ne, létáte podle pocitu.

Vy jste zdůraznili důležitost sladění inženýrské práce s obchodními výsledky. Jak mohou organizace mostem tuto mezeru v praktickém a měřitelném způsobem?

Viděl jsem dva hlavní typy selhání. První je společnosti, které nepárují inženýrské týmy s produkty. Mnoho týmů je dědictvím a bylo na místě po dlouhou dobu. Jeden tým může vlastnit kus tří různých produktů, zatímco jiný tým vlastní čtyři úplně. Inženýrské investice se většinou snížují na headcount, a když týmy nejsou sladěny s produkty, stává se velmi obtížným vidět, kde se obchodní očekávání rozcházejí s realitou.

Druhý typ selhání je nezohlednění veškeré práce, která jde do budování a údržby softwaru. Existuje obrovská kategorie obchodně neviditelné inženýrské práce. Mým oblíbeným příkladem je udržování balíčků aktualizovaných. Ne-techničtí obchodní leaderové často zápasí s pochopením hodnoty nebo proč je to pokračující a nepředvídatelné. Ale mohou pochopit investiční kategorie. Pokud to rámcujete jako „kritické bezpečnostní aktualizace“ a ukazujete v průměru, kolik kapacity spotřebuje, mluvíte jazykem, se kterým mohou pracovat.

Pokud prodejnímu leaderovi nabídnete výběr mezi některými aktualizacemi npm balíčků a funkcí, kterou potřebují k uzavření obchodu, funkce vyhraje vždy. Ale pokud to rámcujete jako „vypadneme z SOC shody nebo dodáme tuto funkci“, nyní jim ukazujete dvě kompromisy, které mohou skutečně vyhodnotit. To rámcování je celá hra. Viděli jsme zákazníky, kteří snížili čas reportování R&D kapitálu o více než dvě třetiny, pouze tím, že učinili tuto klasifikaci práce automatickou místo manuální. Mechanismus je stejný, ať je cílem reportování R&D kapitálu, ospravedlnění headcountu nebo prokázání AI ROI: propojená data nahrazují korelované tabulky.

Podle vašeho zázemí v ručních inženýrských a učení webového vývoje, jak se role developera vyvíjí, když AI přebírá více kódovacího úkolu?

Upřímně, jsem trochu znepokojen, i když důvěřuji, že chytrý lidé to vyřeší.

Mé obavy jsou reálné. Noví absolventi brzy vstoupí do pracovního prostředí, aniž by kdy kódovali ve světě bez kódovacích agentů. Zachytila vzdělání tuto skutečnost? Nástroje se pohybují rychle; vysokoškolské vzdělání se ne vždy pohybuje spolu s nimi. Další posun, který sleduji, je zmatení senior inženýrů a senior produktových lidí. Nejúspěšnější praktici v novém modelu jsou inženýři, kteří jsou hluboce investováni do produktového myšlení.

Co se stává více cenným, je úsudek: schopnost definovat problém přesně enough pro agenta, aby ho vyřešil, vyhodnotit, zda řešení je správné, a chytit jemné selhání, které projdou CI, ale vytvoří architektonické problémy později. Senioři zvyšují svou výhodu, protože mohou směrovat výstup agenta a vědět, které výstupy důvěřovat. Obava je pro ranější kariérní cestu. Tradiční způsob, jak budovat ten úsudek, byl psát hodně kódu a učit se z chyb. Ta zpětná vazba se mění způsoby, které odvětví ještě plně nepracovalo.

Říká se, že historie nabízí jistou jistotu. Byla zde významná skupina lidí, kteří věřili, že kompilátory vyřadí vývojáře assembly. Technologický posun se udál, jak předpokládali. Co se stalo s developery, kteří nešli stejnou cestou? Během následujícího desetiletí se celkový počet developerů zvýšil. Mnozí z těch assembly programátorů se naučili nový jazyk a vynikli, protože měli základní znalosti. Myslím, že verze tohoto vzoru sehraje znovu.

Pohledem do budoucna, jak budete vidět AI měnící se životní cyklus softwarového vývoje v příštích třech až pěti letech, a kde budou společnosti získávat největší konkurenční výhodu?

Budeme svědky zbrojního závodu funkcí, jakého jsme ještě neviděli. Jakmile se cena budování blíží nule, společnosti, dokonce i velké, čelí novému omezení: shromažďování a ověřování dostatečné zákaznické zpětné vazby, aby mohli pokračovat ve stavbě kvalitních věcí v měřítku.

Posun, který se musí stát, je, že laťka pro to, co se staví, musí jít nahoru. Současné omezení většiny inženýrských organizací je jednoduché: pět top priorit, možná dvě dodané. S agenty se poměr otočí. Můžete mít pět top, deset další a dvacet možná na seznamu, a dodat sto. Otázka, kterou nikdo dosud plně nezodpověděl, je, jak budete udržovat těch posledních šedesát, aby nebyly špatně navržené a špatně provedené.

Dvě věci, o kterých jsem poměrně jistý pro tří až pětileté okno. První, konkurenční výhoda v inženýrském AI bude pocházet z hloubky a šíře kontextu, ne z kvality modelu. Modely se stávají tabulkou; každý nástroj bude mít schopné. Co bude odlišovat vedoucí platformy je, jak hluboce rozumí vaší konkrétní organizaci: vašim repozitářům, struktuře týmu, historii dodávek, nasazení. Nástroje, které znají váš systém, budou produkovat fundamentálně odlišné odpovědi než ty, které je neznají. Druhé, posun z reaktivního na proaktivní. Dnes nástroje odpovídají na otázky, když jsou kladeny. Za několik let budou vedoucí nástroje pozorovat kontinuálně a vyhledávat riziko, než se zeptáte. Organizace, které postaví tu kontextovou vrstvu nyní, budou zvyšovat svou výhodu. Příští generace nástrojů musí vyřešit problém kvality v měřítku, a organizace, které to vyřeší první, budou mít skutečnou výhodu.

Děkuji za skvělý rozhovor, čtenáři, kteří chtějí se dozvědět více, by měli navštívit Allstacks.