Jeremy Freeman, współzałożyciel i CTO Allstacks – seria wywiadów

Jeremy Freeman, współzałożyciel i CTO 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 założenia Allstacks w 2017 roku kierował architekturą i rozwojem platformy centralnej, pomagając przekształcić zarządzanie dostawą oprogramowania za pomocą analizy predykcyjnej i prognozowania opartego na sztucznej inteligencji. Przed Allstacks Freeman pełnił role kierownicze w Ravioli Labs i CertiRx, gdzie pracował nad inżynierią oprogramowania, badaniami, technologiami przeciwdziałania podrabianiu i rozwojem produktów. Na początku swojej kariery zdobył doświadczenie w startupach, firmach technologicznych i środowiskach akademickich, w tym nauczając rozwój webu w 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żynierskie, dając mu unikalną perspektywę na budowanie produktów opartych na danych, które pomagają organizacjom poprawiać wyniki dostawy oprogramowania.

Allstacks to platforma inteligencji inżynierskiej i zarządzania strumieniem wartości, która pomaga organizacjom poprawiać 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 systemów wdrożeniowych, a następnie stosuje sztuczną inteligencję i uczenie maszynowe, aby identyfikować ryzyko, prognozować wyniki dostawy i ujawniać działania podejmowane w celu uzyskania wglądu. Zapewniając liderom inżynierskim i produktowym wgląd 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. Technologia jest zaprojektowana, aby pomóc firmom wyjść poza planowanie oparte na intuicji, wykorzystując dane operacyjne w czasie rzeczywistym, aby poprawić wyniki dostawy oprogramowania i wykonanie strategiczne.

Miałeś 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 konkretnych luk lub powtarzających się problemów zaobserwowałeś, co ostatecznie skłoniło cię do budowy firmy?

Kiedy rozpoczęliśmy Allstacks, spędziliśmy dużo czasu na wstępie, robiąc odkrycia klientów, a wzorzec, który się pojawił, 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 niektórych z najbardziej inteligentnych ludzi w pokoju. Ten problem nie został rozwiązany.

Co stało się jasne dość szybko, to to, że nie jest to problem raportowania ani integracji. To problem relacji. Aby wiedzieć, czy coś jest zagrożone, 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 tam, gdzie tło z uczenia maszynowego stało się bezpośrednio przydatne.

Naszym celem od samego początku nie było uczynienie poszczególnego developera szybszym w funkcji X. To było uczynienie całej organizacji lepszą. Jak wyrównać wysiłek inżynierski z wynikami biznesowymi? Jak uczynić 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 te pytania, które napędzały niemal każdą decyzję produktową, którą podjęliśmy.

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

Nie sądzę, aby istniał jeden zestaw metryk, które przewidują dobre i złe, ale raczej wzorce dla różnych faz i typów organizacji. Co znalazłem bardziej przydatne, to rozpoznanie, że organizacje inżynierskie przechodzą przez sezony poprawy. W tym miesiącu jest to wydajność bazy danych. W następnym miesiącu jest to komunikacja między zespołami. Potem jest 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 hałasem.

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 odpowiednie punkt startowy. Stamtąd sądzę, ż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 po drodze (powiedzmy, przyjęcie recenzenta PR AI, jeśli to twoja interwencja); i po trzecie, jak istotny jest ten problem dla biznesu. Twoja intuicja może być taka, że masz rację, że dostarczasz 20 procent mniej kodu, ale prawdziwa historia może być taka, że QA zajmuje teraz trzy razy dłużej. Potrzebujesz wszystkich trzech soczew, aby wiedzieć, czy rozwiązujesz odpowiednią 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ę moje doświadczenie w sektorach nieczysto technologicznych. W firmach SaaS łatwo jest zatracić się w idei, że samo oprogramowanie jest celem. Kiedy jesteś w firmie, w której nie sprzedajesz bezpośrednio oprogramowania, twoja rola staje się znacznie wyraźniejsza: technologia jest tam, aby wspierać firmę. Często żartuję, że gdyby firma mogła osiągnąć wszystko w tym samym tempie bez konieczności zajmowania się mną, wybrałaby tę opcję bez mrugnięcia oka.

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

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 ograniczonym połączeniem między nimi. Szczegóły różnią się: branże regulowane mają dłuższe cykle planowania i niższą tolerancję na niepewność w wymaganiach, ponieważ koszt budowy czegoś złego jest wyższy. Wysoko-prędkościowe sklepy technologiczne 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 to ukształtowało, jak zbudowaliśmy platformę.

Istnieje rosnąca narracja, że sztuczna inteligencja przyspiesza samo programowanie, jednocześnie ujawniają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 przejść od pomysłu, czasem bezpośrednio z ust klienta, do produkcji w ciągu kilku godzin.

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

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

Oto kuszenie, aby wykonać coś i pominąć wszystko to. Ale agenci i uchwyty nie są jeszcze gotowe do pełnego SDLC. Szybkość jest realna. Brak bramki jakości, który wcześniej występował w tych wolniejszych krokach, nie został zastąpiony. To luka.

Wiele organizacji wciąż mierzy produktywność przy użyciu przestarzałych metryk. Co liderzy popełniają podstawowe błędy dotyczące produktywności w środowisku rozwoju opartym na sztucznej inteligencji?

Ludzie dojrzeli znacznie na tym temacie od czasu, gdy rozpoczęliśmy Allstacks. Pomiary przesunęły się w stronę rzeczy, które naprawdę mają znaczenie, a ramy zostały udoskonalone. Sztuczna inteligencja 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. Co do tego, co się zmierza, to coś bliższego indywidualnemu deweloperowi jako menedżerowi agentów. Ten model wymaga całkowicie innego podejścia do pomiaru produktywności, które opiera się na czymś innym niż tokeny wygenerowane lub godziny deweloperów spędzone.

Część niebezpieczeństwa związana z bieżącymi metrykami polega na tym, że ukrywają one, co tak naprawdę się dzieje na poziomie zespołu. Doświadczeni inżynierowie z narzędziami AI kumulują swoją przewagę: mają kontekst kodu i osąd, aby skierować dane wyjściowe agenta i złapać ich awarie. Wczesno-kariery inżynierowie często generują taki sam volumen 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. Różnica między tymi dwiema grupami nie pojawia się nigdzie w standardowym pulpicie.