Dyrektor ds. technologii mówi, że sztuczna inteligencja potrzebuje nowego modelu zarządzania

Tyrone Grandison pełnił wiele funkcji na poziomie C w swojej 35-letniej karierze w branży technologicznej, a obecnie jest dyrektorem technologicznym (CTO) w Cornerstone Assurance Corporation. Jest także autorem książek „Rewolucja AI” i „Kultura, która trwa”.

Porozmawialiśmy z Tyrone'em, aby dowiedzieć się, jak sztuczna inteligencja zmienia zarządzanie w organizacjach technologicznych. Oto, co nam powiedział.

35 lat w branży technologicznej

Zarządzam niewielką organizacją technologiczną wspierającą rozwijającą się firmę z branży ubezpieczeniowej i usług finansowych o nazwie Cornerstone Assurance Corporation. Ta rola jest szczególnie interesująca, ponieważ budujemy nowoczesny stos technologiczny, działając jednocześnie w branży o istotnych wymogach regulacyjnych, w której przetwarzane są poufne dane finansowe, występują złożone integracje z ubezpieczycielami, a tolerancja na błędy jest bardzo niska.

Karierę rozpocząłem jako informatyk, na długo przed tym, zanim sztuczna inteligencja stała się tematem każdej rozmowy w zarządach i każdego przemówienia na konferencjach. Z biegiem lat moja praca ewoluowała od tworzenia technologii do kierowania organizacjami w obliczu zmian, które technologia w nich powodowała. Pełniłem funkcje dyrektora ds. sztucznej inteligencji, dyrektora technologicznego, dyrektora ds. informacji oraz zastępcy dyrektora ds. danych. Pracowałem w administracji publicznej, środowisku akademickim, startupach, firmach konsultingowych, organizacjach non profit i dużych przedsiębiorstwach.

Po 35 latach pracy w branży technologicznej miałem przywilej obserwować wprowadzanie wielu rozwiązań określanych jako „technologia, która zmieni wszystko”. Niektóre z nich rzeczywiście to zrobiły.

Każda duża zmiana zmusza liderów do podejmowania decyzji, zanim zdobędą pełne informacje. Wpływa na modele biznesowe, modele operacyjne, kulturę organizacyjną, talenty, zarządzanie, a czasami także na nasze rozumienie tego, na czym właściwie powinny polegać nasze własne stanowiska. Sztuczna inteligencja robi to wszystko jednocześnie.

Jednak to, co szczególnie mnie fascynuje w obecnej sytuacji, to fakt, że wyszliśmy poza etap, na którym sztuczna inteligencja pomagała nam jedynie analizować informacje. Obecnie mamy systemy, które potrafią generować treści, rozumować, planować, tworzyć, pisać kod, korzystać z narzędzi i coraz częściej podejmować działania. To fundamentalnie zmienia rozmowę o przywództwie.

Pytanie brzmiało kiedyś: „Co sztuczna inteligencja potrafi zrobić?”

Myślę, że szybko staje się ono najmniej interesującym pytaniem. A nawet niewłaściwym pytaniem.

O wiele ważniejsze pytania brzmią: Na co powinniśmy jej pozwolić? W których obszarach ludzki osąd pozostaje niezbędny? Jak powinniśmy przeprojektować organizacje, gdy sama wiedza i wnioski stają się powszechnie dostępne? I jak wykorzystać niezwykły potencjał tej technologii, nie tworząc zagrożeń, których nie rozumiemy, ani systemów, nad którymi nie potrafimy sprawować kontroli?

Na tym właśnie koncentruje się dziś moja praca. Współpracuję z kadrą kierowniczą i organizacjami, pomagając im oddzielić istotne informacje od ogromnej ilości szumu wokół sztucznej inteligencji, zrozumieć, co rzeczywiście się zmienia, oraz przełożyć tę wiedzę na strategię, zarządzanie, produkty i wymierne rezultaty biznesowe.

Jak sztuczna inteligencja zmienia cykle życia tworzenia oprogramowania

Jedną z największych zmian, jakie wprowadziłem w Cornerstone Assurance Corporation, było przeprojektowanie naszego cyklu życia tworzenia oprogramowania przy założeniu, że sztuczna inteligencja będzie pisać znaczną część naszego kodu.

Przed tą zmianą stosowaliśmy dość tradycyjny przepływ pracy inżynierskiej. Deweloper podejmował się realizacji wymagania, projektował rozwiązanie, pisał kod, tworzył testy, przesyłał żądanie włączenia zmian, a następnie inny inżynier je sprawdzał. Oczywiście korzystaliśmy z automatyzacji, ale ludzie nadal wykonywali większość pracy poznawczej od określenia wymagania aż po wdrożenie.

Sztuczna inteligencja całkowicie zmieniła ekonomię tego modelu.

Wprowadziliśmy więc wspomagany przez sztuczną inteligencję potok wytwarzania oprogramowania, wykorzystując GitHub Copilot do generowania i refaktoryzacji kodu, ChatGPT i Claude'a do eksploracji architektury prowadzonej przez sztuczną inteligencję, dekompozycji wymagań, debugowania i generowania przypadków testowych, a nasze standardowe narzędzia CI/CD i narzędzia bezpieczeństwa zapewniają deterministyczne mechanizmy kontroli nad pracą wygenerowaną przez sztuczną inteligencję.

Dlaczego kod generowany przez sztuczną inteligencję wymaga nowego modelu zarządzania

Najważniejsza zmiana nie polegała jednak na komunikacie: „Hej, wszyscy, macie teraz Copilota”. Zmieniliśmy model zarządzania.

Bramki zatwierdzania

Obecnie traktujemy kod wygenerowany przez sztuczną inteligencję niemal jak kod przesłany przez bardzo szybkiego młodszego inżyniera, który nigdy nie śpi, przeczytał absurdalnie dużą ilość dokumentacji i od czasu do czasu z ogromną pewnością siebie mówi coś całkowicie błędnego.

Oznacza to, że AI może generować kod, testy jednostkowe, kontrakty API, dokumentację, zapytania do baz danych, definicje infrastruktury i proponowane poprawki, ale nie może zatwierdzać własnej pracy ani mieć niekontrolowanej ścieżki do środowiska produkcyjnego.

Wprowadziliśmy wyraźne bramki akceptacji człowieka dla zmian związanych z bezpieczeństwem, uwierzytelnianiem i autoryzacją, przetwarzaniem danych klientów i danych finansowych, integracjami zewnętrznymi oraz infrastrukturą produkcyjną.

Automatyczne testowanie

Rozszerzyliśmy również automatyczne testowanie i przeglądy kodu, ponieważ wąskie gardło się przesunęło. Gdy AI radykalnie zwiększa szybkość tworzenia kodu, problemem przestaje być generowanie kodu. Problemem staje się udowodnienie, że kod zasługuje na uruchomienie.

Prostym przykładem jest tworzenie testów. Wcześniej inżynier mógł zaimplementować funkcję, a następnie napisać oczywiste testy jednostkowe. Teraz możemy również poprosić AI o wygenerowanie przypadków testowych sprawdzających zachowanie w sytuacjach skrajnych. Co się stanie w przypadku nieprawidłowych danych wejściowych? Co się stanie, gdy API zwróci nieoczekiwaną odpowiedź? Co się stanie na granicy uprawnień? Co się stanie, gdy rekord klienta będzie zawierał niekompletne dane?

To daje inżynierowi nowe zadanie. Zamiast poświęcać cały czas na tworzenie artefaktów, spędza on więcej czasu na kwestionowaniu założeń i weryfikowaniu zachowania kodu.

Zarządzanie AI

Zmieniliśmy również sposób zarządzania samą AI. W odpowiednich przypadkach rejestrujemy aktywność wspomaganą przez AI, nie udostępniamy poufnych informacji o klientach konsumenckim narzędziom AI, kontrolujemy, które modele i usługi mogą uzyskiwać dostęp do danych przedsiębiorstwa, oraz oddzielamy eksperymenty od dostępu do środowiska produkcyjnego. W ubezpieczeniach i usługach finansowych stwierdzenie „model uznał, że to dobry pomysł” nigdy nie będzie strategią zarządzania.

Jak AI zmienia wąskie gardło w inżynierii

Największym rezultatem integracji AI z naszymi procesami pracy inżynierskiej, jaki zaobserwowałem, jest szybkość, ale zawsze dodaję do tej odpowiedzi gwiazdkę, ponieważ szybkość w niewłaściwym kierunku nie jest produktywnością.

AI znacząco skróciła nasz cykl wytwarzania. Obserwujemy, że praca, która wcześniej zajmowała programiście kilka dni, przechodzi od wymagań do implementacji możliwej do przetestowania w ciągu kilku godzin. W przypadku prototypowania szacuję, że skróciliśmy czas cyklu o około 50–70 procent.

Dokumentacja prawdopodobnie przyniosła najmniej efektowny, ale najbardziej bezpośredni wzrost efektywności. Dokumentacja API, informacje o wydaniach, dokumentacja testów, objaśnienia kodu i pierwsze wersje specyfikacji technicznych nie muszą już zaczynać się od migającego kursora. AI tworzy pierwsze 70 lub 80 procent, a mój zespół poświęca czas na poprawianie i udoskonalanie, zamiast tworzyć wszystko od zera.

Istnieje jednak również wada i uważam, że liderzy technologiczni powinni częściej o niej mówić: AI sprawia, że szybkie tworzenie kiepskiego kodu jest niewiarygodnie tanie.

Odkryliśmy, że czynnik ograniczający przesuwa się w dół procesu. Jeśli mogę wygenerować pięć razy więcej kodu, ale ludzie nadal muszą go zrozumieć, zrecenzować, przetestować, zabezpieczyć, wdrożyć, monitorować i utrzymywać, niekoniecznie zwiększyłem przepustowość systemu. Mogłem po prostu utworzyć korek podczas przeglądu kodu.

To prawdopodobnie była dla mnie najcenniejsza lekcja. Nie optymalizuję już przede wszystkim organizacji inżynierskiej pod kątem szybkości, z jaką możemy pisać oprogramowanie. AI szybko utowarawia ten obszar. Optymalizuję ją pod kątem szybkości, z jaką możemy udowodnić, że oprogramowanie zasługuje na uruchomienie w środowisku produkcyjnym. To zupełnie inny rodzaj organizacji inżynierskiej.

Gdzie AI ma głos, a gdzie ma prawo głosu

Stałem się dość świadomy w rozdzielaniu dwóch kwestii: gdzie AI ma głos, a gdzie AI ma prawo głosu. W naszej organizacji AI ma teraz głos na niemal każdym etapie cyklu życia technologii. Nie ma prawa głosu przy każdej decyzji.

Kilka przykładów:

• Architektura: Wykorzystujemy ChatGPT i Claude jako partnerów do dyskusji o architekturze. Jeśli projektujemy nową usługę, mogę przekazać modelowi nasze wymagania, ograniczenia, istniejące interfejsy, granice bezpieczeństwa, oczekiwaną liczbę transakcji i scenariusze awarii. Poproszę go o zaproponowanie kilku architektur, wskazanie kompromisów, zakwestionowanie naszych założeń, a nawet przedstawienie argumentów przeciwko własnej rekomendacji. Nie zrobię natomiast tego, że zapytam: „Jakiej architektury powinniśmy użyć?”, a następnie zbuduję cokolwiek otrzymam w odpowiedzi. Ostateczna decyzja dotycząca architektury pozostaje po stronie człowieka, ponieważ architektura obejmuje kontekst wykraczający daleko poza optymalizację techniczną. Muszę uwzględnić naszą strategię biznesową, obowiązki regulacyjne, dojrzałość operacyjną, tolerancję ryzyka, koszty, dług techniczny oraz to, co mój zespół jest rzeczywiście w stanie wspierać o 2:00 w nocy.
• Kod: W tym obszarze dajemy AI znacznie większą swobodę. Korzystamy z GitHub Copilot do generowania kodu, refaktoryzacji, tworzenia dokumentacji i testów jednostkowych. Używamy również ChatGPT i Claude do diagnozowania defektów, analizowania sposobów implementacji oraz generowania testów adwersarialnych. AI potrafi niezwykle szybko napisać pierwszą implementację. Za żądanie scalenia nadal odpowiada jednak inżynier, który zatwierdza to, co ostatecznie trafia do kodu.
• Testowanie: Ten obszar prawdopodobnie przesunął się najbardziej w stronę AI. Uwielbiam wykorzystywać AI, pytając: „Jak byś to zepsuł?”. Możemy znaleźć przypadki, które deweloper, który właśnie spędził dwa dni na budowaniu funkcji, mógłby nieświadomie przeoczyć. AI staje się bardzo tanim i niezwykle wytrwałym przeciwnikiem.
• Bezpieczeństwo: W tym obszarze celowo odwracam tę zależność. AI pomaga nam identyfikować podatności, analizować wzorce kodu, modelować zagrożenia i generować scenariusze ataków, ale, jak wspomniałem, ludzie zachowują decyzyjność w zakresie akceptacji bezpieczeństwa, decyzji dotyczących tożsamości i dostępu, przetwarzania danych wrażliwych oraz wyjątków. Wstrzykiwanie poleceń i ujawnianie informacji wrażliwych pozostają rozpoznanymi zagrożeniami w aplikacjach LLM, dlatego podłączanie AI do systemów przedsiębiorstwa wymaga większej liczby mechanizmów kontroli, a nie mniejszej.
• Reagowanie na incydenty: Ten obszar znajduje się gdzieś pośrodku. AI może pobierać dzienniki, korelować zdarzenia, podsumowywać tysiące wierszy danych telemetrycznych, proponować prawdopodobne przyczyny źródłowe i rekomendować kroki naprawcze. Może to znacząco skrócić pierwsze 30 minut incydentu. Jeśli jednak ktoś chce wyłączyć usługę produkcyjną, wycofać krytyczne wdrożenie, zmienić zasadę bezpieczeństwa lub podjąć działanie wpływające na klientów, decyzję podejmuje człowiek.
• Priorytetyzacja backlogu: Tutaj stosuję tę samą zasadę. AI może przeanalizować zgłoszenia do pomocy technicznej, nakład pracy zespołu inżynieryjnego, zależności, wykorzystanie produktu i cele biznesowe, a następnie powiedzieć: „Oto jak ustaliłbym priorytety tych 40 elementów i oto dlaczego”. To niezwykle przydatne. AI nie rozumie jednak naszej strategii lepiej niż my. Ostateczną decyzję dotyczącą priorytetów podejmują liderzy produktu i technologii.

Moja zasada jest więc dość prosta: AI otrzymuje większą autonomię, gdy działanie można cofnąć, obserwować i przetestować, a jego konsekwencje są niewielkie. Zakres ludzkiej decyzyjności rośnie, gdy działanie staje się trudniejsze do odwrócenia lub wiąże się z większym wpływem na klientów, finanse, bezpieczeństwo, zgodność z regulacjami albo reputację.

Rzeczywisty przepływ pracy zespołu inżynieryjnego

Oto przykład przepływu pracy „od wymagania do produkcji z AI w pętli”. Załóżmy, że musimy dodać nową funkcję do przepływu pracy agenta, który pobiera informacje o kliencie i polisie, stosuje zestaw reguł biznesowych i rekomenduje odpowiednie następne działanie:

1. Wszystko zaczyna się od wymagania. Zamiast sytuacji, w której inżynier otrzymuje nieprecyzyjnie napisane zgłoszenie i natychmiast zaczyna kodować, używamy ChatGPT lub Claude’a do przeanalizowania wymagania. Przekazujemy mu historyjkę użytkownika, kryteria akceptacji, odpowiednie reguły biznesowe, kontrakty API i ograniczenia techniczne. Następnie prosimy go o wskazanie niejasności, brakujących przypadków brzegowych, zależności, zagrożeń bezpieczeństwa oraz pytań, na które powinniśmy odpowiedzieć, zanim ktokolwiek napisze kod. Brzmi to prosto, ale pozwala wcześnie wykryć zaskakująco wiele kosztownych nieporozumień.
2. Następnie zajmujemy się architekturą i podziałem zadań. Używamy Claude’a i ChatGPT do analizowania opcji implementacji oraz dzielenia wymagań na komponenty. Model może wskazać zmianę w API, zmianę modelu danych, zależność integracyjną, wymagania dotyczące autoryzacji, telemetrię oraz niezbędne przypadki testowe. Prosimy go również o zakwestionowanie zaproponowanej architektury. Decyzję architektoniczną podejmuje człowiek. AI przedstawia opcje. To my ponosimy konsekwencje.
3. Następnie przechodzimy do implementacji. Używamy GitHub Copilot w środowisku programistycznym do generowania kodu szablonowego, implementowania dobrze zdefiniowanych funkcji, refaktoryzowania kodu, tworzenia klientów API, wyjaśniania nieznanych fragmentów bazy kodu oraz generowania dokumentacji. Inżynier przechodzi od wpisywania każdej linii do kierowania implementacją, jej przeglądania i udoskonalania. Ta różnica ma znaczenie. Nie chcę, aby programiści stawali się bardzo drogimi operatorami autouzupełniania. Chcę, aby myśleli o systemie.
4. Następnie przekazujemy ChatGPT lub Claude’owi wymaganie i implementację, mówiąc w zasadzie: „Świetnie. Teraz to zepsuj”. AI pomaga generować scenariusze adwersarialne, a Copilot pomaga przekształcać je w automatyczne testy jednostkowe i integracyjne.
5. Następnie przejmuje działanie deterministyczna infrastruktura. Żądanie scalenia trafia do naszego potoku CI/CD. Uruchamiamy testy automatyczne, analizę statyczną, skanowanie zależności i podatności oraz nasze standardowe bramki jakości. Inżynier dokonuje przeglądu żądania scalenia.
6. Następnie wdrażamy zmianę stopniowo. Zmiana przechodzi przez środowiska programistyczne i testowe, zanim trafi na produkcję. W stosownych przypadkach używamy przełączników funkcji lub kontrolowanych schematów wdrażania, aby ograniczyć ekspozycję, obserwować działanie i szybko wycofać zmianę.
7. I na tym zadanie AI nadal się nie kończy. Gdy funkcja działa, AI staje się asystentem w zakresie obserwowalności. Używamy go do podsumowywania logów, korelowania wzorców błędów, analizowania nieoczekiwanego działania oraz pomagania inżynierom w znacznie szybszym przechodzeniu od stwierdzenia „coś jest nie tak” do prawdopodobnej przyczyny źródłowej.

Jak zmienić sposób pracy inżynierów dzięki AI

Szkoda, że wcześniej nie rozumiałem, iż zapewnienie inżynierom narzędzi AI jest łatwe. Trudną częścią jest zmiana sposobu pracy inżynierów.

Kiedy po raz pierwszy zaczęliśmy używać narzędzi takich jak GitHub Copilot, ChatGPT i Claude, podszedłem do wdrożenia tak, jak robi to wielu liderów technologicznych. Daj utalentowanym inżynierom potężne narzędzia, ustanów rozsądne zabezpieczenia i poczekaj, aż produktywność wzrośnie.

Wzrosła, ale nie w równym stopniu i nie zawsze w sposób, którego oczekiwałem.

Pierwszą rzeczą, której się nauczyłem, było to, że dostęp nie oznacza adopcji, a adopcja nie oznacza biegłości.

Dwóch inżynierów może korzystać dokładnie z tego samego narzędzia AI i uzyskiwać diametralnie różne rezultaty. Jeden traktuje AI jak autouzupełnianie i oszczędza kilka naciśnięć klawiszy. Drugi uczy się dostarczać kontekst, rozkładać problemy na części, kwestionować wyniki, generować testy, analizować alternatywy i wykorzystywać model jako technicznego partnera do dyskusji. Różnica w produktywności między tymi dwiema osobami może stać się ogromna.

Znacznie wcześniej zainwestowałbym w biegłość w zakresie AI oraz wzorce pracy. Nie w „oto dwugodzinny kurs inżynierii promptów”, lecz w praktyczne przykłady oparte na naszej rzeczywistej pracy inżynierskiej.

Komentarze Tyrone’a

Znacznie wcześniej zainwestowałbym w biegłość w zakresie AI oraz wzorce pracy. Nie w „oto dwugodzinny kurs inżynierii promptów”, lecz w praktyczne przykłady oparte na naszej rzeczywistej pracy inżynierskiej.

Jak AI zmienia przywództwo technologiczne

Poświęcamy wiele czasu na zastanawianie się, co AI zrobi z programistami, architektami, analitykami i osobami na innych stanowiskach technicznych. Uważam, że CTO powinni odwrócić to pytanie i skierować je na siebie.

Przez większość mojej kariery przywództwo technologiczne nagradzało znajomość rzeczy, których inni nie wiedzieli. Doświadczenie dawało umiejętność rozpoznawania wzorców. Wiedza techniczna zapewniała autorytet. Można było wejść do pokoju i udzielić odpowiedzi, której znalezienie komuś innemu mogłoby zająć kilka dni.

Teraz mogę oddać niezwykle zaawansowany system AI do dyspozycji każdego. To zmienia przywództwo.

Nie uważam już, że moja wartość jako CTO wynika z posiadania odpowiedzi. Wynika z zadawania lepszych pytań, zapewniania kontekstu, dokonywania kompromisów, wykorzystywania własnego osądu oraz tworzenia środowiska, w którym ludzie i maszyny wzajemnie pomagają sobie stawać się lepszymi.

To wymaga pokory. AI czasami wskaże podejście, którego nie brałem pod uwagę. Młodszy inżynier o świetnych umiejętnościach pracy z AI może zakwestionować założenie, które ktoś z 25-letnim doświadczeniem uważa za oczywiste. Uważam, że świetni liderzy technologiczni powinni to akceptować.

CTO ery AI nie może być po prostu najmądrzejszą technicznie osobą w pomieszczeniu. Musimy stać się ludźmi, którzy projektują to pomieszczenie. Kto ma prawo głosu? O czym może decydować AI? W jakich obszarach ludzki osąd pozostaje niezbędny? Skąd wiemy, że się mylimy?

Na tym polega transformacja przywództwa.

Dlaczego CTO powinni zachować ostrożność wobec wzrostu efektywności

Moja najważniejsza rada dla CTO na ten moment brzmi: nie mylcie szybkiego działania z osiąganiem postępów.

Na liderach technologicznych wywierana jest ogromna presja, aby „coś zrobić z AI”. Zarządy o to pytają. Prezesi o to pytają. Pracownicy już z niej korzystają, niezależnie od tego, czy macie odpowiednią politykę. Każdy dostawca nagle odkrył, że jego produkt od zawsze był „oparty na AI”.

Bardzo łatwo stać się reaktywnym. Uważam jednak, że zadaniem CTO jest obecnie zapewnienie jasności w samym środku tego szumu.

• Po pierwsze, korzystajcie z tej technologii osobiście. I mam na myśli rzeczywiste korzystanie. Nie twórzcie całej strategii AI wyłącznie na podstawie raportów analityków i prezentacji dostawców. Korzystam z narzędzi takich jak ChatGPT, Claude i GitHub Copilot, ponieważ potrzebuję bezpośredniego doświadczenia z tym, w czym są wyjątkowe, gdzie zawodzą i jak szybko przesuwają się te granice. Nie można skutecznie przewodzić transformacji technologicznej, której doświadcza się wyłącznie za pośrednictwem programu PowerPoint.
• Po drugie, zacznijcie od ograniczeń biznesowych, a nie od możliwości AI. O wiele mniej interesuje mnie pytanie: „Gdzie możemy wykorzystać generatywną AI?”, niż pytanie: „Gdzie działamy wolno, drogo lub niespójnie, gdzie mamy ograniczoną przepustowość albo powodujemy frustrację klientów?”. Dopiero wtedy mogę określić, czy AI rzeczywiście należy uwzględnić w rozwiązaniu.
• Po trzecie, naprawcie podstawy. AI nie uratuje złej jakości danych, słabych interfejsów API, niedostatecznego monitorowania, nieistniejącej dokumentacji ani dysfunkcyjnych praktyk inżynieryjnych. Często je dodatkowo wzmocni. AI działa jak wzmacniacz podstawowej organizacji i systemu technicznego.
• Po czwarte, projektujcie zarządzanie wokół konsekwencji, a nie strachu. Nie chcę 47-stronicowej polityki dotyczącej AI, która w praktyce mówi: „Proszę nie robić niczego interesującego”. Chcę mechanizmów kontrolnych proporcjonalnych do ryzyka. Pozwólcie ludziom intensywnie eksperymentować tam, gdzie działania można odwrócić, a ich konsekwencje są niewielkie. Zwiększajcie nadzór człowieka, gdy decyzje zaczynają wpływać na dane klientów, pieniądze, bezpieczeństwo, obowiązki regulacyjne lub systemy produkcyjne.
• Po piąte, a być może jest to najważniejszy punkt, przeprojektujcie pracę zamiast po prostu dodawać AI do pracy. Jeśli mój proces programistyczny ma dwanaście kroków, a AI sprawia, że czwarty krok przebiega o 70 procent szybciej, nie dokonałem transformacji inżynierii. Przyspieszyłem czwarty krok.
• I na koniec: chrońcie ludzki osąd, jednocześnie zdecydowanie eliminując żmudną pracę człowieka.

Uważam, że CTO mają obecnie wyjątkową szansę. Nie pytajcie tylko, jak AI zwiększa efektywność waszej obecnej organizacji. Zapytajcie, jaką organizację zbudowalibyście, gdybyście zaczynali dzisiaj. To bardziej niewygodne pytanie. To również ono oddzieli firmy, które po prostu korzystają z AI, od firm, które faktycznie się dzięki niej transformują.

Śledź na bieżąco

Możesz śledzić pracę Tyrone'a Grandisona na LinkedInie i jego osobistej stronie internetowej. Możesz także zapoznać się z jego książkami: Rewolucja AI oraz Kultura, która trwa.

Więcej wywiadów z ekspertami już wkrótce w The CTO Club!