Jeremy Freeman, Współzałożyciel i CTO Allstacks – Seria Wywiadów

Jeremy Freeman, współzałożyciel i dyrektor techniczny Allstacks, jest inżynierem oprogramowania, architektem technologicznym i przedsiębiorcą z karierą obejmującą rozwój oprogramowania, inżynierię sprzętu, uczenie maszynowe i innowacje produktowe. Od czasu współzałożenia Allstacks w 2017 roku, kierował architekturą i rozwojem podstawowej platformy firmy, pomagając przekształcić zarządzanie dostawą oprogramowania za pomocą analizy predykcyjnej i prognozowania opartego na sztucznej inteligencji. Przed dołączeniem do Allstacks, Freeman pełnił role kierownicze w Ravioli Labs i CertiRx, gdzie pracował nad inżynierią oprogramowania, badaniami, technologiami przeciwnieżądającymi i rozwojem produktów. Na początku swojej kariery, zdobył doświadczenie w startupach, firmach technologicznych i środowisku akademickim, w tym ucząc rozwój sieci web na Wake Technical Community College. Jego tło techniczne obejmuje systemy wbudowane, projektowanie sprzętu, platformy oprogramowania w dużym stopniu, uczenie maszynowe i przywództwo inżynieryjne, dając mu unikalną perspektywę na budowę produktów opartych na danych, które pomagają organizacjom poprawiać wyniki dostawy oprogramowania.Allstacks to platforma inteligencji inżynierii oprogramowania i zarządzania strumieniem wartości, która pomaga organizacjom poprawić przewidywalność i wydajność rozwoju oprogramowania. Platforma integruje dane z narzędzi używanych w całym cyklu życia rozwoju oprogramowania, w tym systemów zarządzania projektami, kontroli źródła i wdrożenia, a następnie stosuje sztuczną inteligencję i uczenie maszynowe w celu identyfikacji ryzyka, prognozowania wyników dostawy i przedstawiania działających wniosków. Poprzez zapewnienie liderom inżynierii i produktów wglądu w stan projektu, wydajność zespołu i trendy rozwoju, Allstacks umożliwia organizacjom podejmowanie bardziej świadomych decyzji, redukowanie niepewności dostawy i lepsze dopasowanie wysiłków inżynierskich do celów biznesowych. Jej technologia jest zaprojektowana, aby pomóc firmom wyjść poza planowanie oparte na intuicji, wykorzystując dane operacyjne w czasie rzeczywistym do poprawy wydajności dostawy oprogramowania i strategicznego wykonania.

Miałaś wyjątkową podróż od kierowania zespołami badawczo-inżynierskimi stosującymi uczenie maszynowe do danych rozwoju oprogramowania do współzałożenia Allstacks w 2017 roku. Jakie konkretnie luki lub powtarzające się problemy zaobserwowałeś, co ostatecznie skłoniło cię do budowy firmy?

Kiedy zaczynaliśmy Allstacks, spędziliśmy dużo czasu na wstępnych badaniach rynku, a wyłaniający się wzorzec był spójny: firma po firmie miała ogromne ilości danych i nadal nie wiedziała, co tak naprawdę się dzieje. Dostarczanie oprogramowania było nieprzewidywalne, pomimo posiadania jednych z najmądrzejszych ludzi w pokoju. Ten problem nie został rozwiązany.

To, co stało się jasne dość szybko, to to, że nie był to problem raportowania ani integracji. To był problem relacji. Aby wiedzieć, czy coś jest narażone na ryzyko, musisz wiedzieć, jak element pracy łączy się z gałęzią, gałąź łączy się z PR, PR łączy się z celem sprintu, a cel sprintu łączy się z inicjatywą biznesową. Ten graf nie istnieje domyślnie nigdzie w standardowym łańcuchu narzędzi. Musisz go zbudować. A budowanie go dobrze jest fundamentalnie problemem inferencyjnym, co jest gdzie tło z uczenia maszynowego stało się bezpośrednio użyteczne.

Naszym celem od samego początku nie było zrobienie pojedynczego developera szybszego w funkcji X. To było zrobienie całej organizacji lepszej. Jak wyrównać wysiłek inżynierski z wynikami biznesowymi? Jak zrobić inżynierię, aby prawdziwie służyła biznesowi, a nie tylko istniała obok niego? Potrzebujesz lepszego zrozumienia relacji danych, aby odpowiedzieć na te pytania. To są pytania, które napędzały prawie każdą decyzję produktową, którą podjęliśmy.

Allstacks koncentruje się na analizowaniu danych w całym cyklu życia rozwoju oprogramowania. Jakie typy sygnałów lub wzorców są najbardziej przewidywalne, gdy chodzi o identyfikację ryzyka dostawy wcześnie?

Nie myślę, że istnieje jeden zestaw metryk, który przewiduje dobre i złe, ale raczej wzorce dla różnych faz i typów organizacji. To, co uważam za bardziej użyteczne, to rozpoznanie, że organizacje inżynierskie przechodzą przez sezony poprawy. Ten miesiąc to wydajność bazy danych. Następny miesiąc to komunikacja między zespołami. Potem to „dlaczego nie możemy zamknąć żadnych PR?” Potem obserwowalność. Jako lider inżynierski, pływasz w sygnałach: niektóre diagnostyczne, niektóre monitorujące i wiele, które jest po prostu szumem.

To, co pomaga, to rozpoczęcie od problemu, który widzisz, a nie metryki, którą chcesz poprawić. Jeśli pytasz „dlaczego wydaje się, że dostarczamy mniej niż w zeszłym roku”, to jest to właściwy punkt startu. Stamtąd uważam, że potrzebujesz trzech typów metryk: po pierwsze, jak wiesz, że problem jest realny (może liczba PR na developera w czasie); po drugie, jakie zmiany wprowadzasz i jak śledzisz je na bieżąco (powiedzmy, przyjęcie recenzenta PR AI, jeśli to jest twoja interwencja); i po trzecie, jak istotny jest ten problem dla biznesu. Twoja intuicja może być słuszna, że dostarczasz 20 procent mniej kodu, ale prawdziwa historia może być taka, że QA zajmuje teraz trzy razy więcej czasu. Potrzebujesz wszystkich trzech soczew, aby wiedzieć, czy rozwiązujesz właściwą rzecz.

Pracowałeś w branżach takich jak opieka zdrowotna, energia i technologia. Jak wyzwania w dostawie oprogramowania różnią się w tych sektorach i jak to ukształtowało platformę Allstacks?

Bardzo cenię swoje doświadczenie w sektorach nieczysto technologicznych. W firmach SaaS łatwo jest zgubić się w idei, że samo oprogramowanie jest celem. Gdy jesteś w biznesie, w którym nie sprzedajesz bezpośrednio oprogramowania, twoja rola staje się znacznie bardziej klarowna: technologia jest tam, aby wspierać biznes. Często żartuję, że gdyby biznes mógł osiągnąć wszystko w tym samym tempie bez konieczności zajmowania się mną, wybraliby tę opcję bez mrugnięcia okiem.

Ta perspektywa jest naprawdę użyteczna. Kontekstualizuje to, co wszyscy robimy w tej branży i umieszcza wiele debat technologicznych z powrotem w ich miejscu. Biznes nie dba o to, czy używasz Pythona czy Go. Spędzanie cykli na tym przepisaniu prawdopodobnie nie jest tam, gdzie jest prawdziwy zwrot.

To, co pozostaje spójne we wszystkich branżach, to problem fragmentacji. Niezależnie od sektora, każda organizacja inżynierska ma dane rozproszone w kilkunastu narzędziach z ograniczoną tkanką łączącą je. Szczegóły różnią się: branże regulowane mają dłuższe cykle planistyczne i niższą tolerancję na niepewność w wymaganiach, ponieważ koszt budowy czegoś złego jest wyższy. Sklepy technologiczne z wysoką prędkością gromadzą ukryty dług szybciej. Ale podstawowy tryb awaryjny jest taki sam. Zespoły mogą powiedzieć, co zostało dostarczone. Nie mogą śledzić, dlaczego coś się przesunęło, co to kosztowało, czy gdzie ryzyko było widoczne przed tym, zanim stało się problemem. To ukształtowało, jak zbudowaliśmy platformę.

Istnieje rosnąca narracja, że AI przyspiesza samo kodowanie, jednocześnie narażając słabości gdzie indziej. Dlaczego wymagania, planowanie i gotowość specyfikacji stają się prawdziwymi wąskimi gardłami?

Widzimy to codziennie. Z dobrym agentem i solidnym uchwytem wokół niego, możesz przenieść się od pomysłu, czasem bezpośrednio z ust klienta, do produkcji w literalne godziny.

Część tego, co sprawia, że ten przesunięcie jest tak znaczące, to zmiana w pętli sprzężenia zwrotnego. Z narzędziami typu copilot, człowiek jest w pętli na każdą sugestię. AI oferuje uzupełnienie; akceptujesz lub odrzucasz je natychmiast. Gdy jest to błędne, łapiesz to szybko. Promień rażenia złej sugestii jest jedną linią kodu. Kodowanie agenticzne działa inaczej: dajesz agentowi cel, on dekomponuje pracę, wykonuje wieloetapowy plan i dostarcza działający moduł. Człowiek przegląda dane wyjściowe, a nie każdy krok. Gdy specyfikacja jest błędna, agent buduje całą implementację do tej złej specyfikacji, a dowiadujesz się o tym na przeglądzie.

To brzmi jak czysta korzyść, dopóki nie rozpoznasz, co poprzedni czas opóźnienia tak naprawdę robił. Opóźnienie służyło prawdziwemu celowi. Wielokrotne rundy inteligentnych ludzi przeglądających, planujących, testujących i pracujących nad pomysłami, aby wyprodukować lepszy system.

Temptacja teraz jest taka, aby wyczuć coś i pominąć wszystko to. Ale agenci i uchwyty nie są jeszcze gotowi do pełnego SDLC. Szybkość jest realna. Brakowało bramki jakościowej, która wcześniej miała miejsce w tych wolniejszych krokach. To jest luka.

Wiele organizacji wciąż mierzy produktywność przy użyciu przestarzałych metryk. Co liderzy mają fundamentalnie nie tak o produktywności w środowisku rozwoju napędzanym przez AI?

Ludzie dojrzeli znacznie na tym temacie od czasu, gdy zaczynaliśmy Allstacks. Pomiary przesunęły się w stronę rzeczy, które naprawdę mają znaczenie, a ramy zostały udoskonalone. AI wywraca wszystko do góry nogami.

Tradycyjny rozwój oprogramowania był fundamentalnie ograniczony przez to, jak szybko deweloper mógł napisać kod, który spełniał wymagania biznesu i podstawowej technologii. Ten koszt zbliża się do zera. To, ku czemu zmierzamy, to coś bliższego posiadaniu indywidualnego developera jako menedżera agentów. Ten model wymaga całkowicie innego podejścia do pomiaru produktywności, które opiera się na czymś innym niż tokenach wygenerowanych lub godzinach deweloperskich.

Część niebezpieczeństwa związana z bieżącymi metrykami polega na tym, że ukrywają one, co naprawdę się dzieje na poziomie zespołu. Doświadczeni inżynierowie z narzędziami AI powiększają swoją przewagę: mają kontekst codebase i osąd, aby skierować dane wyjściowe agenta i złapać ich awarie. Wczesniejsi inżynierowie w swojej karierze generują tę samą objętość kodu, ale spędzają więcej czasu na audycie danych wyjściowych, których nie mogą w pełni ocenić. Agregatowa prędkość wygląda dobrze, może nawet poprawiona. Przerwa między tymi dwiema grupami nie pojawia się nigdzie w standardowym dashboardzie. Prawidłowe pytanie do zadania każdemu liderowi inżynierskiemu: czy możesz mi powiedzieć, co twoi agenci wyprodukowali w zeszłym sprincie, które z tego wyjścia zostały zaakceptowane jako takie, a które zostały zmienione, i gdzie zostały skoncentrowane nakłady na rewizję? Jeśli możesz odpowiedzieć na to, masz instrumenty, aby się poprawić. Jeśli nie, latasz na wyczucie.

Nie mamy jeszcze konsensusu branżowego na temat właściwego modelu pomiarowego, ale zespoły, które zaczną śledzić jakość danych wyjściowych i stopę przepracowania, a nie tylko przepustowość i przyjęcie, będą lepiej przygotowane niż zespoły, które czekają, aż ktoś inny to rozwiąże.

Twoja platforma łączy dane z narzędzi takich jak systemy zarządzania projektami i repozytoria kodu. Jak ważne jest to, aby ujednolicić te fragmentowane źródła danych, i co się dzieje, gdy organizacje nie robią tego?

Allstacks odniósł sukces w tym obszarze, ponieważ budowaliśmy grafy kontekstowe od czasu, zanim stało się to terminem. Rozpoznaliśmy wcześnie, że połączenie wszystkich danych jest konieczne, aby odpowiedzieć na pytania, które klienci naprawdę zadawali.

Gdy to połączenie nie istnieje, AI działający na twoich danych inżynierskich może zobaczyć tylko część obrazu. Może analizować to, co jest w twoim systemie zarządzania projektami. Może analizować to, co jest w twoim repozytorium kodu. To, czego nie może zrobić, to śledzenie opóźnienia dostawy z powrotem do zablokowanej zależności w trzech narzędziach, ponieważ relacja między tymi sygnałami nie istnieje w warstwie danych. Otrzymujesz płytką analizę co najwyżej, i pewne, błędne rekomendacje w najgorszym przypadku. Jakość modelu nie rozwiązuje tego. Możesz umieścić najbardziej zdolny model dostępny na surowe integracje API i nadal przegapić rzeczywistą przyczynę problemu, ponieważ dane nie kodują relacji między sygnałami. Śmieci w, śmieci w, niezależnie od tego, jak inteligentny jest model.

To połączenie jest fundamentem. To umożliwiło nam być pierwszymi na rynku z możliwościami, które nie zostały jeszcze skopiowane.

Jak organizacja inżynierska, która jest dobrze przygotowana do AI, różni się od tej, która nie jest gotowa?

Ironicznie, nie jest to tak różne, jak być przygotowanym do wprowadzenia klasy letnich stażystów. Potrzebujesz solidnych, zautomatyzowanych zestawów testowych, solidnej dokumentacji, dojrzałej rury CI/CD i barier, które umieściłbyś, gdy dodajesz zaufanego, ale nieprzeszkolonego developera do zespołu.

Co jest również ważne, a ludzie tendencję do zaniżania, to regularne powracanie do podstaw: twoich reguł agenta, twoich plików AGENTS.MD. Możesz zrobić solidny pierwszy przejazd, ale łatwo jest dostać się w rytm dostarczania nowego i zapomnieć, że możesz tak naprawdę wytrenować wiele złych domyślnych ustawień. Rzeczy takie jak nauczenie agenta uruchamiania testów przed każdym commitem nie powinny wymagać przypomnienia ludzkiego za każdym razem.

Jedno diagnostyczne pytanie, które bym postawił każdemu liderowi inżynierskiemu: czy możesz mi powiedzieć, co twoi agenci wyprodukowali w zeszłym sprincie, które z tego wyjścia zostały zaakceptowane jako takie, a które zostały zmienione, i gdzie zostały skoncentrowane nakłady na rewizję? Jeśli możesz odpowiedzieć na to, masz instrumenty, aby się poprawić. Jeśli nie, latasz na wyczucie.

Podkreślałeś wagę wyrównania pracy inżynierskiej z wynikami biznesowymi. Jak organizacje mogą przezwyciężyć tę lukę w praktyczny i mierzalny sposób?

Widziałem dwa główne tryby awaryjne. Pierwszy to firmy, które nie łączą zespołów inżynierskich z produktami. Wiele struktur zespołowych jest spuścizną i istnieje od dłuższego czasu. Jeden zespół może posiadać część trzech różnych produktów, podczas gdy inny posiada cztery całkowicie. Inwestycje inżynierskie w dużej mierze sprowadzają się do liczby głów, a gdy zespoły nie są wyrównane do produktów, staje się bardzo trudno zobaczyć, gdzie oczekiwania biznesowe odbiegają od rzeczywistości.

Drugi tryb awaryjny to nieuwzględnienie wszystkich prac, które idą w budowę i utrzymanie oprogramowania. Istnieje ogromna kategoria pracy inżynierskiej niewidocznej dla biznesu. Mój ulubiony przykład to aktualizacja pakietów. Liderzy biznesu niebędący technicznymi często mają trudności z zrozumieniem wartości lub dlaczego jest to ciągłe i nieprzewidywalne. Ale mogą zrozumieć kategorie inwestycyjne. Jeśli ramifikujesz to jako „krytyczne uaktualnienia bezpieczeństwa” i pokażesz średnio, jak dużo pochłania to pojemności, mówisz w języku, z którym mogą pracować.

Jeśli poprosisz lidera sprzedaży, aby wybrał między niektórymi aktualizacjami pakietu npm a funkcją, której potrzebuje, aby zamknąć deal, funkcja wygrywa zawsze. Ale jeśli ramifikujesz to jako „wypadnięcie z zgodności SOC lub dostarczenie tej funkcji”, teraz pokazujesz im dwa kompromisy, które mogą ocenić. To przeprojektowanie jest całą grą. Widzieliśmy, jak klienci skracają czas raportowania kapitałów badawczo-rozwojowych o ponad dwie trzecie, tylko automatyzując tę klasyfikację pracy zamiast ręcznej. Mechanizm jest taki sam, niezależnie od tego, czy celem jest raportowanie kapitałów, uzasadnienie headcountu, czy udowodnienie zwrotu z AI: połączone dane zastępują skorelowane arkusze kalkulacyjne.

Biorąc pod uwagę twoje doświadczenie w obu rękach na inżynierię i nauczanie rozwoju webowego, jak widzisz ewolucję roli developerów, gdy AI bierze na siebie więcej obciążenia kodowania?

Szczerze mówiąc, jestem trochę zaniepokojony, chociaż ufam, że mądrzy ludzie to rozwiążą.

Moje obawy są realne. Świeżo upieczeni absolwenci wkrótce wejdą na rynek pracy, nigdy nie kodując w świecie bez agentów kodowania. Czy edukacja nadążyła za tym? Narzędzia poruszają się szybko; wyższe wykształcenie nie zawsze porusza się wraz z nimi. Inna zmiana, której jestem świadomy, to zacieranie się granic między starszymi inżynierami a starszymi ludźmi produkcyjnymi. Najbardziej udani praktycy w nowym modelu to inżynierowie, którzy są głęboko zaangażowani w myślenie o produkcie.

To, co staje się bardziej cenne, to osąd: zdolność do zdefiniowania problemu dokładnie enough, aby agent mógł go rozwiązać, ocenić, czy rozwiązanie jest poprawne, i złapać subtelne awarie, które przechodzą CI, ale tworzą późniejsze problemy architektoniczne. Doświadczeni inżynierowie powiększają swoją przewagę, ponieważ mogą skierować dane wyjściowe agenta i wiedzą, które dane wyjściowe są godne zaufania. Obawa dotyczy wcześniejszej ścieżki kariery. Tradycyjny sposób budowania tego osądu był taki, że pisałeś dużo kodu i uczyłeś się z błędów. Ta pętla sprzężenia zwrotnego się zmienia w sposób, który branża jeszcze nie w pełni rozpracowała.

To powiedziawszy, historia oferuje pewną pewność. Była znacząca grupa ludzi, którzy wierzyli, że kompilatory wyeliminują deweloperów asemblera. Przesunięcie technologiczne nastąpiło tak, jak przewidywali. Co się stało z deweloperami, którzy nie podążali za tym samym scenariuszem? W ciągu następnej dekady całkowita liczba deweloperów wzrosła. Wielu z tych programistów asemblera nauczyło się nowego języka i wyróżniło się dzięki swojej wiedzy podstawowej. Uważam, że jakaś wersja tego wzorca się powtórzy.

Spójrzając w przyszłość, jak widzisz AI zmieniając cykl życia rozwoju oprogramowania w ciągu najbliższych trzech do pięciu lat, i gdzie firmy zyskają największą przewagę konkurencyjną?

Będziemy świadkami wyścigu zbrojeń funkcjonalności, jakiego jeszcze nie widzieliśmy. Gdy koszt budowy zbliża się do zera, firmy, nawet duże, stają twarzą w twarz z nowym ograniczeniem: zbieraniem i walidacją wystarczającej ilości opinii klientów, aby nadal budować jakościowe rzeczy na dużą skalę.

Przesunięcie, które musi nastąpić, to to, że poprzeczka dla tego, co się buduje, musi iść w górę. Ograniczenie w większości organizacji inżynierskich jest proste: pięć priorytetów na górze, może dwa dostarczone. Z agentami, współczynnik odwraca się. Możesz mieć pięć priorytetów na górze, dziesięć następnych i dwadzieścia może na liście, i dostarczyć setkę. Pytanie, które nikt jeszcze w pełni nie odpowiedział, to, jak utrzymać te ostatnie sześćdziesiąt od bycia źle pomyślanymi i źle wykonanymi.

Dwie rzeczy, co do których jestem dość pewny w oknie trzech do pięciu lat. Po pierwsze, przewaga konkurencyjna w inżynierii AI przyjdzie z głębi i szerokości kontekstu, a nie jakości modelu. Modele stają się standardem; każde narzędzie będzie miało zdolne. To, co różnicuje wiodące platformy, to to, jak głęboko rozumieją twoją konkretną organizację: twoje repozytoria, strukturę zespołu, historię dostaw, wzorce wdrożenia. Narzędzia, które znają twój system, wyprodukują fundamentalnie różne odpowiedzi niż te, które nie. Po drugie, przesunięcie z reaktywnego do proaktywnego. Dziś narzędzia odpowiadają na pytania, gdy są zadawane. W ciągu kilku lat wiodące narzędzia będą obserwować ciągle i ujawniać ryzyko, zanim je poprosisz. Organizacje, które zbudują tę warstwę kontekstu teraz, kumulują przewagę. Następne pokolenie narzędzi musi rozwiązać problem jakości na dużą skalę, a organizacje, które to rozwiążą jako pierwsze, będą miały realną przewagę.

Dziękuję za wspaniałe wywiady, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić Allstacks.