Globalny szef architektury AI mówi, że AI to zmiana modelu operacyjnego, a nie wdrożenie narzędzia

Manish Jain jest wiceprezesem i globalnym szefem architektury AI w firmie Firstsource, gdzie kieruje zespołem 50 osób. Obecnie koncentruje się na budowaniu systemów agentowych, które potrafią realizować wieloetapowe zadania.

Spotkaliśmy się z Manishem, aby dowiedzieć się, jak AI zmienia jego model operacyjny. Oto, co powiedział.

Od potencjału do gotowych do wdrożenia rozwiązań

Jestem Manish Jain, liderem w dziedzinie AI i technologii, koncentrującym się na pomaganiu organizacjom w przekształcaniu potencjału AI w niezawodne rozwiązania gotowe do użycia produkcyjnego. Swoją pracę opieram na praktycznych realiach transformacji. W ciągu ostatnich kilku lat prowadziłem wiele inicjatyw związanych z AI i ML, ściśle współpracowałem z zespołami biznesowymi oraz zajmowałem się inżynierią i wdrożeniami, w przypadku których sukces zależy od znacznie większej liczby czynników niż tylko wybór odpowiedniego modelu. Architektura, jakość danych, bezpieczeństwo, integracja, akceptacja przez użytkowników i wyraźna wartość biznesowa muszą współgrać.

Obecnie kieruję inicjatywami AI w ramach interdyscyplinarnej organizacji liczącej około 50 osób, w tym inżynierów oprogramowania i platform, specjalistów ds. AI i danych, liderów produktów, partnerów ds. bezpieczeństwa oraz ekspertów dziedzinowych. Prace obejmują wdrażanie AI w przedsiębiorstwach oraz realizację wdrożeń bezpośrednio u klientów. Zespoły ściśle współpracują z klientami i interesariuszami wewnętrznymi, aby prowadzić wartościowe przypadki użycia od etapu analizy po bezpieczne i skalowalne wdrożenie produkcyjne.

Nasze podejście jest celowo niezależne od chmury i modelu. Wdrażamy rozwiązania głównie w Azure i AWS, a z Google Cloud korzystamy wybiórczo, w zależności od środowiska klienta, zasobów danych i potrzeb operacyjnych. Zamiast projektować rozwiązania wokół jednego dostawcy chmury lub modelu bazowego, budujemy modułowe architektury, które pozwalają nam wybierać i rozwijać podstawowe komponenty wraz ze zmianą wymagań. Obejmuje to warstwę modelu, usługi pobierania i danych, platformę orkiestracji, narzędzia do oceny, obserwowalność oraz mechanizmy bezpieczeństwa.

Prawdziwa złożoność nie polega wyłącznie na wyborze modelu LLM. Chodzi o integrację AI z przepływami pracy firmy, obejmującymi rozproszone źródła danych, starsze aplikacje, różne uprawnienia użytkowników oraz rygorystyczne wymagania dotyczące bezpieczeństwa, niezawodności, kosztów i zgodności. Zwykle zaczynamy od skoncentrowanego przypadku użycia i rygorystycznej oceny, a następnie wprowadzamy sprawdzone rozwiązanie do produkcji za pomocą mechanizmów ochronnych, odpowiedniego nadzoru człowieka, monitorowania i ciągłego doskonalenia. Celem jest tworzenie rozwiązań AI, które pozostają elastyczne w miarę zmian technologii i są wystarczająco niezawodne, aby zespoły mogły na nich polegać każdego dnia.

Szczególnie interesuje mnie przejście od pojedynczych asystentów do systemów agentowych, które potrafią realizować wieloetapowe zadania w określonych granicach. Dla liderów technologicznych jest to ogromna szansa, ale jej wykorzystanie wymaga zdyscyplinowanej inżynierii, przemyślanego zarządzania oraz silnego ukierunkowania na rezultaty.

Dlaczego dostarczanie rozwiązań AI z oceną na pierwszym miejscu poprawia rezultaty

W ciągu ostatniego roku przeniosłem dostarczanie rozwiązań AI z podejścia opartego przede wszystkim na prototypach do dyscypliny inżynieryjnej, w której najpierw przeprowadza się ocenę. Rok temu zespoły często szybko budowały imponujące wersje demonstracyjne, łącząc przepływy pracy z pojedynczymi modelami. Jednak czynniki decydujące o wiarygodności AI w środowisku produkcyjnym — jakość, ugruntowanie w danych, kontrola dostępu, obsługa błędów, koszty i odpowiedzialność użytkowników — często były uwzględniane zbyt późno.

Wprowadziliśmy wspólny model dostarczania, w którym każdy przypadek użycia AI rozpoczyna się od jasnego określenia sukcesu, reprezentatywnych danych do oceny, przeglądu bezpieczeństwa i dostępu do danych, możliwości śledzenia oraz bieżącego monitorowania. Zbudowaliśmy również podstawową architekturę niezależną od chmury i modelu. Dzięki temu zespoły mogą oceniać odpowiednie połączenie modeli, metod pobierania danych i wzorców orkiestracji dla każdego przepływu pracy, bez uzależniania produktu od jednego dostawcy lub generacji modelu.

W praktyce przełożyło się to na mniejszą liczbę powtórnych prac i większą pewność podczas wdrożeń produkcyjnych. Zespoły mogą identyfikować pogorszenie jakości lub wzrost kosztów, zanim wpłyną one na użytkowników, podejmować świadome decyzje dotyczące tego, gdzie potrzebna jest weryfikacja przez człowieka, oraz ulepszać systemy na podstawie dowodów, a nie anegdotycznych opinii.

Patrząc w przyszłość, uważam, że stanowi to fundament odpowiedzialnej agentowej AI. Gdy systemy wychodzą poza odpowiadanie na pytania i zaczynają podejmować wieloetapowe działania w ramach firmowych przepływów pracy, nie możemy dodawać oceny, obserwowalności, uprawnień i zarządzania dopiero później. Muszą one stanowić część podstaw inżynieryjnych od pierwszego dnia.

Jak ludzie stają się ważniejsi dzięki inżynierii agentowej

Wykorzystujemy AI w całym cyklu życia produktu. Na etapie analizy przekształca ona informacje od interesariuszy, opinie klientów i istniejącą dokumentację wstępne wymagania, historyjki użytkowników, kryteria akceptacji oraz pytania techniczne. W inżynierii wspiera analizę bazy kodu, tworzenie dokumentacji, implementację, refaktoryzację, przygotowywanie żądań ściągnięcia oraz generowanie testów. W operacjach podsumowuje dzienniki, koreluje alerty z ostatnimi wydaniami, pobiera kontekst wcześniejszych incydentów i zawęża obszar poszukiwań podczas sortowania zgłoszeń. Zespoły poświęcają mniej czasu na gromadzenie kontekstu z różnych narzędzi, a więcej na weryfikowanie decyzji, rozwiązywanie złożonych problemów i sprawne prowadzenie prac.

Utrzymujemy po stronie ludzi odpowiedzialność za architekturę, zatwierdzanie kwestii bezpieczeństwa, decyzje dotyczące dostępu do danych, akceptację wydań oraz kompromisy związane z priorytetami. Decyzje te wymagają kontekstu biznesowego, odpowiedzialności oraz zrozumienia konsekwencji wykraczających poza to, co zawiera zgłoszenie, polecenie lub repozytorium kodu. AI może analizować alternatywy, identyfikować zależności, sygnalizować zagrożenia bezpieczeństwa i gromadzić dowody, ale decyzję podejmuje odpowiedzialny inżynier lub lider.

Celowo wprowadzamy to rozróżnienie, zmierzając w kierunku bardziej agentowego podejścia do inżynierii. Oczekuję, że AI przejmie więcej ograniczonych zadań wykonawczych, takich jak wdrażanie dobrze zdefiniowanych zmian, generowanie i uruchamianie testów, sprawdzanie kryteriów wdrożenia czy proponowanie kroków naprawczych po incydentach. W miarę jak to następuje, rola człowieka staje się ważniejsza, a nie mniej ważna. Inżynierowie definiują intencję, uprawnienia, progi jakości i granice wycofania zmian, a następnie weryfikują, czy system osiągnął zamierzony rezultat.

Jak AI skutecznie wspiera kompleksowe przepływy pracy inżynieryjnej

Oto nasz kompleksowy przepływ pracy, który prowadzi od dobrze zdefiniowanego zapytania produktowego przez projektowanie, implementację i walidację aż po wydanie na produkcję. Rozpoczyna się w momencie, gdy menedżer produktu i lider zespołu inżynieryjnego definiują rezultat dla klienta, ograniczenia oraz kryteria akceptacji. Następnie AI syntetyzuje istotny kontekst biznesowy, istniejącą dokumentację, wzorce architektoniczne i zależności, tworząc wstępny projekt techniczny, plan implementacji oraz strategię testów. Inżynier przegląda ten plan, podejmuje decyzje architektoniczne i dzieli pracę na małe, niezależnie weryfikowalne zmiany.

Podczas implementacji inżynierowie korzystają z AI w obrębie bazy kodu, aby zrozumieć istotne usługi, wygenerować początkowy kod i zmiany konfiguracji, zaktualizować dokumentację oraz utworzyć testy jednostkowe i integracyjne. Każda zmiana nadal przechodzi przez kontrolę wersji, automatyczne testy CI, wzajemny przegląd kodu, skanowanie bezpieczeństwa oraz ustalony proces wydawniczy. Jeśli test zakończy się niepowodzeniem, AI interpretuje błąd, identyfikuje prawdopodobną zależność lub regresję i proponuje poprawkę, ale inżynier weryfikuje rozwiązanie, zanim zmiana zostanie dopuszczona do dalszego etapu.

Po wdrożeniu przepływ pracy jest kontynuowany. AI podsumowuje dzienniki aplikacji, koreluje anomalie z ostatnimi wydaniami i przedstawia inżynierowi dyżurnemu istotne informacje o wcześniejszych incydentach lub procedurach operacyjnych. Cały cykl mierzymy za pomocą czasu realizacji, pokrycia testami, odsetka zmian kończących się niepowodzeniem, częstotliwości wycofywania zmian oraz czasu rozwiązania problemu.

Nie jest to autonomiczne tworzenie oprogramowania. To kierowany przez ludzi system dostarczania wspomagany przez AI, w którym AI skraca czas gromadzenia kontekstu i wykonywania zadań, podczas gdy inżynierowie zachowują odpowiedzialność za projekt, jakość, bezpieczeństwo i rezultat osiągany na produkcji.

Manish mówi

AI znacząco skróciło czas, który inżynierowie poświęcają na gromadzenie kontekstu i tworzenie pierwszej wersji rutynowych zadań. Pomaga zespołom szybciej przejść od początkowego wymagania do uporządkowanego podejścia technicznego, implementacji, pokrycia testami i dokumentacji.

Jak AI usprawnia współpracę między funkcjami

Jeśli chodzi o rezultaty, AI znacząco skróciło czas, który inżynierowie poświęcają na gromadzenie kontekstu i tworzenie pierwszej wersji rutynowych zadań. Pomaga zespołom szybciej przejść od początkowego wymagania do uporządkowanego podejścia technicznego, implementacji, pokrycia testami i dokumentacji. Przyspieszyło tworzenie nowych funkcji i możliwości produktu, szczególnie gdy inżynierowie muszą analizować nieznaną bazę kodu, śledzić zależności lub pracować z wieloma usługami.

AI wspiera również decyzje architektoniczne. Może szybko syntetyzować istniejącą dokumentację systemu, identyfikować zależności, porównywać opcje implementacji, wskazywać prawdopodobne kompromisy i pomagać zespołom tworzyć rejestry decyzji architektonicznych. Ostateczne decyzje architektoniczne podejmują ludzie, ale zespoły przystępują do tych dyskusji z lepszym kontekstem. Mogą poświęcić więcej czasu na omawianie decyzji, które rzeczywiście mają znaczenie, takich jak skalowalność, odporność, bezpieczeństwo, koszty i długoterminowa łatwość utrzymania.

Usprawnienie nie polega wyłącznie na szybszym generowaniu kodu. Obserwujemy lepszy przepływ pracy w całym cyklu życia, ponieważ zespoły produktowe, inżynieryjne, kontroli jakości i operacyjne rozpoczynają pracę z pełniejszym i bardziej spójnym kontekstem. Inżynierowie poświęcają więcej czasu na projektowanie systemu, przypadki brzegowe, złożoność integracji i wpływ na klienta, zamiast ręcznie gromadzić informacje z repozytoriów, zgłoszeń, pulpitów nawigacyjnych, dzienników i opisów wcześniejszych incydentów.

Jak należy mierzyć sukces za pomocą AI

Wyciągnęliśmy również ważne wnioski dotyczące wad. AI może stwarzać fałszywe poczucie szybkości, gdy zespoły akceptują wiarygodne wyniki bez wystarczającej weryfikacji. Może generować kod, który wygląda poprawnie, ale nie pasuje do otaczającej architektury, pomija subtelne reguły biznesowe, wprowadza niepotrzebną złożoność albo powoduje problemy z bezpieczeństwem i utrzymaniem. Wzrost produktywności również nie rozkłada się równomiernie. Najwięcej korzyści odnoszą inżynierowie, którzy rozumieją system, precyzyjnie definiują zadania i rygorystycznie weryfikują wyniki.

Dlatego mierzymy sukces poprzez jakość dostarczania, a nie metryki aktywności AI. Rezultaty, na których nam zależy, to szybsze dostarczanie funkcji, krótszy czas cyklu, stabilne wydania, lepsze pokrycie testami, mniej poprawek, szybsze rozwiązywanie incydentów i utrzymująca się niezawodność. Długoterminowe możliwości są znaczące, ale tylko wtedy, gdy AI poprawia osąd inżynierski i realizację zadań, zamiast zastępować któreś z nich.

Jak nowe ograniczenia zmieniają strukturę zespołów

Generowanie kodu nie jest już ograniczeniem dla tempa pracy inżynierskiej. Rzeczywiste ograniczenia to często niejasne wymagania, rozproszony kontekst biznesowy, zależności architektoniczne, przeglądy bezpieczeństwa, integracja między systemami oraz czas potrzebny na zweryfikowanie, czy zmiana działa bezpiecznie na produkcji. Dane branżowe wskazują na ten sam kierunek: kodowanie stanowi stosunkowo niewielką część dnia pracy inżyniera, a wdrożenie AI do kodowania nie przekłada się automatycznie na proporcjonalny wzrost przepustowości.

Zmieniło to moje podejście do struktury zespołów. Zamiast traktować AI wyłącznie jako sposób na ograniczenie wysiłku związanego z dostarczaniem, zmierzamy w kierunku mniejszych, bardziej interdyscyplinarnych zespołów, z większą odpowiedzialnością od etapu odkrywania po zdobywanie wiedzy na produkcji. Inżynierowie powinni poświęcać mniej czasu na tworzenie pierwszych wersji, a więcej na definiowanie intencji, kształtowanie architektury, weryfikowanie wyników i doskonalenie systemu po wydaniu.

Ponadto nasze podejście do rekrutacji przesunęło się od skupienia na samych efektach kodowania w stronę myślenia systemowego, oceny produktu i weryfikowania pracy wspomaganej przez AI. Cenimy inżynierów, którzy potrafią radzić sobie z niejednoznacznością, podejmować trafne kompromisy dotyczące architektury i bezpieczeństwa oraz odpowiadać za rezultaty na produkcji.

Manish mówi nam

Przyszłość to nie tylko szybsza implementacja. To szybsze uzgadnianie i ciaśniejsza pętla między pomysłem, rezultatem na produkcji a wiedzą, która kształtuje kolejną decyzję.

Przyszłość to nie tylko szybsza implementacja. To szybsze uzgadnianie i ciaśniejsza pętla między pomysłem, rezultatem na produkcji a wiedzą, która kształtuje kolejną decyzję.

Dlaczego testowanie wymaga przeprojektowania w przyszłości wspomaganej przez AI

Testowanie wymaga przeprojektowania.

AI znacznie przyspiesza tworzenie kodu, co oznacza, że zapewnianie jakości musi stać się ciągłe, zautomatyzowane i wbudowane w proces dostarczania, zamiast być traktowane jako końcowa bramka. Zespoły potrzebują wspomaganego przez AI generowania testów, realistycznych zbiorów danych do oceny, kontroli bezpieczeństwa i wydajności, monitorowania produkcji oraz jasno określonej odpowiedzialności człowieka za wyjątki.

W cyklu życia wspomaganym przez AI przewagę konkurencyjną zyska nie ten, kto najszybciej generuje kod, lecz ten, kto potrafi najbezpieczniej weryfikować zmiany i najszybciej wyciągać wnioski z produkcji.

Jak wcześnie unikać problemów związanych z AI

Nie doceniliśmy operacyjnych realiów AI. Zużycie tokenów i limity wykorzystania mogą znacząco ograniczać dostarczanie, szczególnie w agentowych procesach kodowania, które wymagają szerokiego kontekstu bazy kodu lub wielokrotnych iteracji. Obecnie traktujemy wydatki na AI jako decyzję dotyczącą zdolności inżynierskich, zapewniając wgląd w wykorzystanie, kierowanie ruchem do modeli, zarządzanie kontekstem i wytworzoną wartość — a nie tylko koszt licencji. Niezawodność usług również ma znaczenie. Zewnętrzny model lub platforma do kodowania może doświadczać opóźnień, ograniczania szybkości lub problemów z dostępnością, dlatego krytyczne przepływy pracy wymagają modeli awaryjnych, kontrolowanego obniżenia funkcjonalności oraz sposobów umożliwiających inżynierom dalszą pracę bez usługi AI.

Wczesnych problemów można było uniknąć, definiując od początku zatwierdzone narzędzia, jasne granice danych, oczekiwania dotyczące przeglądów, kontrolę kosztów i wzorce awaryjne.

Nie nakazywałbym również zbyt wcześnie korzystania z jednego narzędzia lub przepływu pracy. Technologia zmienia się zbyt szybko. Lepszym podejściem jest zapewnienie bezpiecznego dostępu, wielokrotnego użytku zabezpieczeń, możliwości wzajemnego uczenia się oraz jasnej odpowiedzialności. Inżynier nadal odpowiada za to, co projektuje, recenzuje, scala i obsługuje na produkcji.

Dlaczego AI należy traktować jako zmianę modelu operacyjnego

Moja rada dla dyrektorów technicznych jest taka, aby traktować AI jako zmianę modelu operacyjnego, a nie wdrożenie narzędzia. Zacznij od niewielkiej liczby procesów o wysokiej wartości, w przypadku których można ustalić punkt odniesienia, zmierzyć wpływ i szybko się uczyć. Zbuduj wspólną platformę AI oraz dyscyplinę dostarczania wokół zatwierdzonych modeli, bezpiecznego dostępu do danych, ewaluacji, obserwowalności i wielokrotnego użytku wzorców integracji, a także zadbaj o to, aby architektura była niezależna od chmury i modelu. Dzięki temu każdy zespół nie będzie musiał na nowo opracowywać tych samych mechanizmów kontroli ani zbyt wcześnie uzależniać się od dostawcy.

Równie ważne jest inwestowanie w ludzi. Najwięcej zyskają nie te organizacje, które po prostu generują więcej kodu. Będą to te, które pomagają inżynierom, zespołom produktowym, partnerom ds. bezpieczeństwa i liderom biznesowym nauczyć się jasno definiować pracę, weryfikować wyniki AI oraz obsługiwać systemy agentowe w określonych granicach. Działaj szybko, ale traktuj zaufanie, jakość, bezpieczeństwo i mierzalne rezultaty jako elementy niepodlegające negocjacjom.

AI staje się kluczową warstwą realizacji działań w przedsiębiorstwie, dlatego rolą dyrektora technicznego jest stworzenie architektury, zarządzania i kultury, które pozwolą na odpowiedzialne skalowanie.

Bądź na bieżąco

Możesz śledzić pracę Manisha Jaina na jego stronie Substack oraz profilu LinkedIn.

Na The CTO Club pojawi się więcej wywiadów z ekspertami!