5 typowych wzorców powodujących awarie systemów AI

Adam Horner budował zespoły inżynieryjne w sektorze fintech i w branży oprogramowania dla przedsiębiorstw. Obecnie jest założycielem The CTO Playbook, gdzie prowadzi działalność edukacyjną i pracuje jako CTO na część etatu.

Usiedliśmy z nim, aby dowiedzieć się, jakie wzorce dostrzega za sukcesami i porażkami we wdrażaniu AI. Oto, co nam powiedział.

Jakaś wersja tego samego wyzwania

Nazywam się Adam Horner, jestem coachem CTO i CTO na część etatu w The CTO Playbook. Wcześniejszą część kariery spędziłem jako inżynier i współzałożyciel pełniący funkcję CTO, budując i kierując zespołami inżynieryjnymi w sektorze fintech i w branży oprogramowania dla przedsiębiorstw, w tym przez kilka lat w Palantir, gdzie byłem jednym z pierwszych pracowników firmy w Wielkiej Brytanii.

Przejście do coachingu wynikało z prostej obserwacji: zostanie skutecznym liderem technologicznym jest naprawdę trudne, a większość osób radzi sobie z tym bez mapy drogowej ani nikogo u boku, kto już przez to przeszedł. Tym właśnie zajmuję się teraz, pomagając CTO przekroczyć to, co nazywam przepaścią CTO.

Wątek AI nie jest dla mnie odrębnym tematem. Przewija się niemal w każdej rozmowie coachingowej, którą prowadzę, ponieważ każdy CTO, z którym pracuję, mierzy się z jakąś wersją tego samego wyzwania: jak poprowadzić organizację przez transformację o takiej skali, na konkretnym etapie jej rozwoju, z konkretnym zespołem, i wyjść z niej jako silniejsza firma?

Trudny środek krzywej wzrostu

Moja własna organizacja jest mała i celowo odchudzona — to czteroosobowy zespół założycielski budujący firmę w całości w oparciu o AI, dzięki czemu możemy pozostawać blisko realiów tworzenia produktów na wczesnym etapie. Pracuję również jako CTO na część etatu ze startupem fintech, który nie uzyskał jeszcze akredytacji, mierząc się ze szczególnymi presjami związanymi z wprowadzaniem regulowanego produktu na rynek przy wykorzystaniu zewnętrznego zespołu deweloperskiego.

Szerszy obraz, a zarazem prawdziwa głębia mojego doświadczenia z organizacjami, wynika jednak z pracy z CTO, których wspieram coachingowo. Są wśród nich zespoły założycielskie i młode startupy finansowane ze środków własnych, szybko rozwijające się firmy wspierane przez fundusze venture capital i private equity, średniej wielkości przedsiębiorstwa zarządzające rzeczywistą złożonością organizacyjną, a także przedsiębiorstwa z wieloma działami działające na dużą skalę.

Najwięcej czasu spędzam w trudnym środku krzywej wzrostu i właśnie tam wyzwania przywódcze bywają najbardziej dotkliwe.

Jak AI pozwala inżynierom spojrzeć na szerszy obraz

Dla mnie najważniejsza zmiana nie dotyczyła narzędzia ani procesu, lecz oczekiwań. Kiedy jako lider dajesz zespołowi pozwolenie — a co ważniejsze, obowiązek — ponownego przeanalizowania całego cyklu dostarczania produktu od podstaw, zakres tej analizy ma znaczenie. Nie chodzi tylko o to, jak pisze się i wdraża kod, lecz o wszystko, czego dotyka proces dostarczania: obsługę klienta, wartość dla użytkownika oraz cel biznesowy stojący za konkretnym zadaniem.

Kiedy koszt pisania i utrzymywania kodu był wysoki, ścisłe skupienie inżynierów na problemie technicznym miało pewien sens. Jednak ten koszt gwałtownie spadł. Czynnikiem ograniczającym nie jest już szybkość tworzenia, lecz to, jak jasno wszyscy zaangażowani rozumieją, co rzeczywiście warto zbudować i dlaczego.

Inżynierowie, którzy rozumieją produkt, klienta i cele biznesowe stojące za zmianą, mogą podejmować decyzje i działać w sposób, który wcześniej po prostu nie był możliwy. Poprawie nie uległ żaden wskaźnik. Zmieniła się jakość pytań, które zespół zaczął zadawać przed napisaniem choćby jednej linijki kodu.

Przemyślenia Adama

Czynnikiem ograniczającym nie jest już szybkość tworzenia, lecz to, jak jasno wszyscy zaangażowani rozumieją, co rzeczywiście warto zbudować i dlaczego.

Jak dzięki AI można skrócić cykle analizy i naprawy

Jeden z przykładów dotyczył ponownego przemyślenia sposobu współpracy obsługi klienta i zespołu inżynieryjnego w związku z potwierdzonymi błędami. Wcześniej cykle analizy i naprawy liczono w dniach lub tygodniach, a zespoły wsparcia przez cały ten czas zajmowały się sfrustrowanymi klientami, podczas gdy inżynierowie ponosili koszt rozproszenia uwagi przez bieżące problemy, równolegle z innymi obowiązkami. Gdy ponownie przeanalizowano cykl dostarczania produktu, uwzględniając tworzenie wspomagane przez AI, cykle naprawy uległy znacznemu skróceniu, a duża część procesu została zautomatyzowana.

Na początku oznaczało to więcej pracy po stronie obsługi klienta — konieczne było jasne rejestrowanie i kategoryzowanie problemów — ale efektem było ich rozwiązywanie w ciągu godzin, a nie dni. Inżynierowie mogli zachować koncentrację. Klienci szybciej otrzymywali odpowiedzi. Okazało się, że sposób współpracy między dwiema funkcjami, który zawsze po prostu uznawano za powolny, można było całkowicie wynegocjować na nowo.

Dlaczego organizacje nie powinny stosować AI do wszystkiego

Jeśli chodzi o to, co powinno być zadaniem człowieka, a co zadaniem AI, wygląda to inaczej w każdej organizacji. Właściwym punktem wyjścia nie jest lista działań, lecz jasne zrozumienie, gdzie znajduje się wartość organizacji i gdzie koncentruje się ryzyko.

Elementy procesu, które są kluczowe dla działalności firmy — logika, wyróżniki oraz obszary, w których porażka jest widoczna lub kosztowna — wymagają udziału człowieka i ludzkiego nadzoru. Wszystko inne mieści się na pewnym spektrum.

Firma zajmująca się cyberbezpieczeństwem poświęci wiele ludzkiej uwagi właściwościom bezpieczeństwa swojego kodu, ponieważ na tym polega jej działalność. Firma zajmująca się automatyzacją przepływów pracy może skupić taką samą uwagę na logice podejmowania decyzji w ramach krytycznego przepływu pracy, a jednocześnie uznać narzędzia bezpieczeństwa za coś, z czym AI może sobie odpowiednio poradzić.

Błędem jest stosowanie ogólnej polityki w którymkolwiek z tych kierunków. Pytanie, które należy zadać, nie brzmi: „Czy AI może to zrobić?”, lecz: „Jaki będzie koszt, jeśli coś pójdzie nie tak?”.

I jeszcze jedno: zaskakująco duża część złożoności, którą ludzie chcą automatyzować, wynika w rzeczywistości z nierozwiązanego zadłużenia procesowego. Najpierw uporządkujcie tę kwestię. Dzięki temu późniejsze wdrażanie AI będzie prostsze i tańsze.

Adam opowiada

Właściwym punktem wyjścia nie jest lista działań, lecz jasne zrozumienie, gdzie znajduje się wartość organizacji i gdzie koncentruje się ryzyko.

Dlaczego dyrektorzy ds. technologii muszą zacząć od automatyzacji dostarczania, a nie kodu

Naprawdę trudno porównywać rezultaty stosowania AI w różnych organizacjach, ponieważ większość liderów — zarówno w obszarze technologii, jak i w szerszej działalności biznesowej — nadal ma trudności z jasnym mierzeniem wpływu i zwrotu z inwestycji w AI. Bez tego trudno określić, jak właściwie wygląda dobry rezultat, a jeszcze trudniej uzasadnić potrzebę dalszego zwiększania skali takich działań.

Ogólnie rzecz biorąc, zakres rezultatów osiąganych dzięki AI jest jednak szeroki. Z jednej strony współpracowałem z organizacjami, które praktycznie wyeliminowały zaległości i obecnie pracują bezpośrednio w oparciu o wartość dla klienta oraz cele biznesowe. Oznacza to fundamentalną zmianę w sposobie, w jaki inżynieria współdziała z resztą firmy.

Zauważyłem wspólny wzorzec w organizacjach, które to osiągnęły: żadna z nich nie zaczynała od lewej strony cyklu życia oprogramowania. Nie rozpoczynały od generowania kodu. Zaczynały od prawej strony: potoków CI/CD, pewności wdrażania i zautomatyzowanego przeglądu kodu. Najpierw należało sprawić, by końcowy etap procesu dostarczania był solidny i godny zaufania — to stworzyło warunki do podjęcia wszystkich pozostałych działań. Następnie uwaga przesunęła się na testy, ograniczenia i kontrole wykonywane przed generowaniem oraz na strukturę zamiast szybkości.

Największe postępy osiągały zespoły działające w sposób najbardziej autonomiczny — nie dlatego, że wyeliminowały ludzką ocenę, lecz dlatego, że zakodowały jej wystarczającą część w swoich procesach, aby móc z przekonaniem podejmować się realizacji znacznie większych zakresów prac. Zaległości nie zniknęły dlatego, że zespoły szybciej pisały kod. Zniknęły, ponieważ cała relacja między zamiarem a dostarczeniem stała się jednoznaczna.

Z drugiej strony obserwowałem rzeczywisty odpływ pracowników spowodowany rosnącą przepaścią między osobami, które szybko wykorzystują AI, a tymi, które tego nie robią. Gdy rozpoczyna się wdrażanie AI, niemal zawsze pojawia się niewielka grupa osób działających szybko oraz większa grupa, która tego nie robi, a naturalnym odruchem jest pozwolenie tym pierwszym na samodzielne działanie. To, co po cichu i szybko powstaje w jego wyniku, to tarcia, brak zaufania i podejrzliwość między zespołami, które niwelują korzyści szybciej, niż początkowy postęp zdąży je zgromadzić. Rada, której obecnie udzielam na początku każdego zlecenia, jest zawsze taka sama: nie zostawiaj nikogo w tyle. Tempo wdrażania powinno wyznaczać to, jak szybko można zabrać ze sobą całą organizację, a nie to, jak szybko najbardziej entuzjastyczni inżynierowie mogą działać indywidualnie.

Organizacja działająca w dwóch tempach z perspektywy czoła wygląda na robiącą postępy. Z tyłu wygląda to jak pozostawanie w tyle — a to odczucie ma swoje konsekwencje.

Dlaczego bazę wiedzy organizacji trzeba przeprojektować z myślą o AI

Najwyraźniejszą lukę, jaką dostrzegam w możliwościach AI, stanowi podejmowanie decyzji w warunkach niepewności.

AI jest zasadniczo silnikiem predykcyjnym, a przewidywanie to nie to samo co osąd. AI nie ponosi konsekwencji swoich decyzji, nie ma poczucia ich skutków ani odpowiedzialności za rezultat. Oczekiwanie, że będzie podejmować decyzje w naszym imieniu, zawsze będzie zależeć od jej zdolności do przewidywania, która w naprawdę niepewnych lub nowych sytuacjach jest ograniczona. Organizacje, które najbardziej rozczarowały się AI, to zwykle te, które polegały na niej właśnie w takich momentach.

Innym obszarem, w którym wpływ AI okazuje się mniejszy — bardziej po cichu, ale równie znacząco — są sytuacje, gdy konsekwencje wynikające z okien kontekstowych nie są właściwie rozumiane. Jeśli dostarczysz AI niepełny lub źle uporządkowany kontekst, i tak udzieli Ci pewnej siebie odpowiedzi. Rozpoznanie różnicy między dobrze poinformowanym wynikiem a takim, który tylko brzmi wiarygodnie, wymaga ludzkiego osądu, którego nie wykształciło jeszcze wystarczająco wiele zespołów.

Z tego powodu baza wiedzy organizacji ma kluczowe znaczenie. Mam na myśli cały kontekst, który obecnie istnieje w głowach ludzi: sposób, w jaki zawsze wykonywano dane zadania, domyślne podejścia oraz niepisane zasady faktycznego funkcjonowania organizacji. AI nie może korzystać z wiedzy instytucjonalnej, która nigdy nie została uzewnętrzniona, a większość organizacji dysponuje jej ogromnymi zasobami.

Dobra wiadomość jest taka, że wydobycie tej wiedzy nie wymaga jej idealnego uporządkowania. Multimodalna AI potrafi wykorzystać zarówno nagranie instruktażowe, zgrubny schemat, jak i nieedytowany dokument. Priorytetem jest najpierw uzewnętrznienie wiedzy, a dopiero potem jej uporządkowanie.

Nieustannie przekonuję się, że samo wydobycie tego kontekstu z głów ludzi i przeniesienie go do dowolnej formy dokumentacji jest wartościowe, zanim AI w ogóle go dotknie. Ujawnia rozbieżności, obnaża błędne założenia i pokazuje niesprawne przepływy pracy, których nikt wcześniej nie zauważył, ponieważ wszyscy byli w nie zbyt mocno zaangażowani.

Ta podstawa zwielokrotnia następnie wszystko, co AI może zrobić. To jedna z najbardziej efektywnych inwestycji czasu, jakie CTO może obecnie podjąć, a zarazem jedna z najczęściej pomijanych, mimo że sprzedawcy automatyzacji procesów biznesowych mówią nam o tym od lat!

Jak zapobiec spowalnianiu organizacji przez sceptycznych programistów

Częsty problem, który dostrzegam, nie jest tak naprawdę porażką AI. Jest porażką procesu wdrażania i zwykle przebiega według rozpoznawalnego schematu.

Sceptyczny programista — a jest ich zaskakująco wielu — podejmuje połowiczną próbę, dostarczając minimalny kontekst, otrzymuje słaby rezultat, a następnie przedstawia go jako dowód, że AI nie potrafi wykonać danego zadania. Wniosek zostaje przedstawiony z pełnym przekonaniem. Metodologia rzadko podlega analizie. Tym, co sprawia, że nie jest to tylko indywidualna frustracja, są dalsze konsekwencje.

Integracja AI z zespołem lub cyklem życia oprogramowania to sport zespołowy, a kilku inżynierów zmotywowanych do udowodnienia, że to nie działa, może spowolnić całą organizację, a nie tylko ograniczyć własną wydajność.

Wniosek, jaki z tego wyciągam, nie dotyczy ograniczeń AI. Chodzi o to, że wdrażanie jest w równym stopniu wyzwaniem przywódczym, co technicznym. Jakość rezultatów uzyskiwanych przez AI jest nierozerwalnie związana z jakością kontekstu i intencji, które jej przekazujesz, a budowanie takiego zrozumienia w całym zespole wymaga równie świadomego wysiłku jak każda inna istotna zmiana sposobu pracy. Właśnie tak zmieniamy postrzeganie AI z wadliwej „magii” na użyteczną „zaawansowaną technologię”.

Adam dzieli się

Sceptyczny programista podejmuje połowiczną próbę, dysponując minimalnym kontekstem, uzyskuje słaby wynik i przedstawia go jako dowód na to, że AI nie potrafi wykonać tego zadania. Wniosek zostaje przedstawiony z pełnym przekonaniem. Metodologia rzadko podlega analizie.

Dlaczego małe zespoły są przewagą w pracy z AI

Założenie, że sprawny i produktywny zespół inżynierski potrzebował określonej liczby osób, aby dysponować wystarczającym kontekstem i działać w znaczącym tempie, nie wytrzymało konfrontacji z rzeczywistością rozwoju wspomaganego przez AI.

Czynnikiem ograniczającym w każdym zespole zawsze były możliwości poznawcze: ile kontekstu każda osoba jest w stanie utrzymać, jak jasno potrafi przekazać go otaczającym ją ludziom oraz ile energii pochłania ta komunikacja. Zmieniło się to, że jednostką wykonującą pracę nie jest już tylko człowiek. Każda osoba w zespole uruchamia wiele agentów, a agenci ci przenoszą i stosują kontekst w sposób, który całkowicie zmienia rachunek. Zasada dwóch pizz Amazona była rozsądną heurystyką w świecie sprzed AI.

Oto przykład.

Jedna z organizacji, z którymi współpracuję, od dawna chciała mieć wewnętrzny interfejs administracyjny dla swojej platformy, ale nigdy nie była w stanie uzasadnić tej inwestycji. Wcześniej oszacowano, że jego stworzenie wymagałoby pracy całego zespołu przez kilka miesięcy. Zamiast tego przydzielono do zadania dwie osoby: obie doskonale znające firmę i istniejącą platformę, o wysokim poziomie samodzielności i jasno określonych ograniczeniach, w ramach których miały pracować. Sześć tygodni później dysponowały działającą pierwszą wersją.

Znajomość firmy przez te dwie osoby okazała się równie ważna jak narzędzia AI. Mniej pytań, mniej narzutów, szybsze decyzje. Jednak cenniejszym rezultatem nie było samo narzędzie. Było nim to, czego organizacja nauczyła się o pracy w ten sposób.

Zespoły, które obecnie obserwuję i które działają najskuteczniej, liczą od dwóch do trzech osób, przy czym każda z nich uruchamia wielu agentów — i nie jest to ograniczenie. W przypadku odpowiedniego rodzaju pracy jest to przewaga.

Dlaczego częsta komunikacja ma kluczowe znaczenie w procesach pracy wspomaganych przez AI

Współpraca może stać się trudna w pracy z AI.

Potrzebna jest znacznie częstsza komunikacja, ponieważ wszystko dzieje się szybciej. To jeden z powodów, dla których mniejsze zespoły obecnie sprawdzają się lepiej.

Utrzymywanie stanu i spójności w dużym zespole, gdy każda osoba prowadzi wiele równoległych, agentowych procesów kodowania, wydaje się po prostu zbyt wyczerpujące. Niektóre zespoły, z którymi współpracuję, przeszły na dwa codzienne spotkania typu stand-up, aby zachować spójność.

Dlaczego CTO muszą uważać na AI w cieniu

AI w cieniu to znany wcześniej problem informatyki w cieniu, któremu nadano nowy budżet i nową nazwę.

Niekontrolowane i nieograniczone korzystanie z narzędzi AI w całym przedsiębiorstwie może łatwo zwiększyć ryzyko utraty danych i własności intelektualnej — „eksfiltracji”, jak nazywa to CISO — często całkowicie nieumyślnie ze strony użytkowników.

Większość organizacji szybko wychodzi obecnie z etapu 1 modelu CMM (fazy eksperymentowania na „dzikim zachodzie”), wprowadzając zasady i ograniczenia techniczne w celu zmniejszenia ryzyka.

Dlaczego CTO muszą koncentrować się na własnym rozwoju

Przemyślenia Adama

Liderzy, którzy wyjdą z tego okresu najsilniejsi, niekoniecznie będą tymi, którzy mają najlepsze narzędzia lub największe zespoły. Będą nimi ci, którzy rozwijają swój osąd, wpływ i klarowność myślenia, aby dobrze przewodzić w sytuacji, gdy nikt nie ma jasnej mapy.

W branży panuje obecnie wiele obaw dotyczących tego, co AI oznacza dla zespołów inżynierskich, liczby pracowników i samej roli.

To, czy te obawy są uzasadnione, jest niemal kwestią drugorzędną. Liczy się to, że znajdujemy się w okresie znaczących i szybkich zmian, a dobre przeprowadzenie przez nie wymaga liderów, którzy aktywnie rozwijają własne możliwości, a nie tylko zarządzają zmianami zachodzącymi wokół nich.

Biorąc pod uwagę wszystko, co się dzieje, wciąż zaskakuje mnie, jak wielu CTO i starszych liderów technologicznych działa bez żadnych dedykowanych inwestycji we własny rozwój. Bez coacha, bez uporządkowanego rozwoju, bez partnera do wspólnego myślenia. Popełniłem ten błąd już wcześniej, a błędy, które popełniłem, i czas, który straciłem, nie były nieuniknione.

Liderzy, którzy wyjdą z tego okresu najsilniejsi, niekoniecznie będą tymi, którzy mają najlepsze narzędzia lub największe zespoły. Będą nimi ci, którzy rozwijają swój osąd, wpływ i klarowność myślenia, aby dobrze przewodzić w sytuacji, gdy nikt nie ma jasnej mapy.

Śledź dalszy ciąg

Możesz śledzić pracę Adama Hornera na LinkedIn. Aby skorzystać z coachingu 1:1, kursów grupowych i podcastu, odwiedź stronę The CTO Playbook. Jeśli natomiast szukasz bezpłatnego, 5-dniowego kursu e-mailowego dla CTO na wczesnym etapie kariery, zajrzyj na Early CTO Map.

Wkrótce pojawią się kolejne wywiady z ekspertami w The CTO Club!