Zarządzanie AI nie może być kwestią drugorzędną

Abhishek Ranjan jest dyrektorem ds. technologii w firmach Apna i Blue Machines, gdzie jest głęboko zaangażowany w transformację zarówno ludzkiej siły roboczej, jak i siły roboczej opartej na sztucznej inteligencji.

Usiedliśmy z nim, aby porozmawiać o zarządzaniu przepływami pracy AI. Oto, co powiedział.

Technologia u boku ludzi

Nazywam się Abhishek Ranjan. Jestem dyrektorem ds. technologii w firmach Apna i Blue Machines. Dwa bardzo powiązane, a jednocześnie różne światy ukształtowały moją drogę do obecnego momentu transformacji opartej na AI.

W Apna tworzymy rozwiązania dla ludzkiej siły roboczej. Apna jest jednym z najszybciej rozwijających się indyjskich jednorożców, z ponad 60 milionami użytkowników na platformie. Przy takiej skali bardzo dokładnie obserwujemy indyjską siłę roboczą. Widzimy miliony ludzi poszukujących lepszych możliwości, pracodawców próbujących szybciej zatrudniać pracowników, różne języki, różne poziomy umiejętności oraz zróżnicowany poziom dostępu do technologii cyfrowych i pewności siebie w korzystaniu z nich.

W Blue Machines tworzymy rozwiązania dla siły roboczej opartej na AI. Koncentrujemy się na głosowej AI dla przedsiębiorstw, obsługując codziennie miliony minut połączeń. Tworzymy coś więcej niż tylko boty odpowiadające na pytania. Budujemy pracowników AI, którzy mogą rozmawiać z klientami, rozumieć kontekst, przyjmować informacje zwrotne, doskonalić się z czasem i realizować rzeczywiste procesy biznesowe.

Widziałem, jak technologia pomaga ludziom znaleźć pracę, rozwijać się i uczestniczyć w gospodarce. Teraz widzę, jak sama AI staje się nowym rodzajem siły roboczej, która może współpracować z ludźmi.

Dlatego ten moment nie dotyczy dla mnie wyłącznie wykorzystywania AI do zwiększania produktywności czy szybszego pisania kodu. Chodzi o ponowne wyobrażenie sobie sposobu funkcjonowania firm i samego przebiegu pracy.

Architektura dwóch bardzo różnych firm

Architektura Apna jest zbudowana jak duża platforma marketplace. Mamy systemy konsumenckie, systemy pracodawców, platformy danych, systemy AI i dopasowywania, wyszukiwanie, komunikację, warstwy ochrony przed oszustwami i budowania zaufania, a także — obecnie — funkcje rekrutera AI i przygotowania do rozmów kwalifikacyjnych z wykorzystaniem AI. Model wdrażania jest oparty przede wszystkim na chmurze, wysoce skalowalny i zaprojektowany z myślą o wysokiej dostępności, ponieważ z platformy korzystają miliony użytkowników i tysiące firm.

Organizacja inżynieryjna liczy ponad 100 osób pracujących w zespołach inżynierii produktu, backendu, frontendu, aplikacji mobilnych, danych, AI, infrastruktury, bezpieczeństwa i platformy. Koncentrujemy się nie tylko na tworzeniu funkcji, lecz także na budowaniu niezawodnych systemów, które mogą działać na ogromną skalę.

Blue Machines to organizacja technologiczna innego rodzaju. Koncentruje się na głosowej AI dla przedsiębiorstw i autonomicznych przepływach pracy. Budujemy pracowników AI, którzy mogą rozmawiać, rozumować, podejmować działania, integrować się z systemami biznesowymi i doskonalić się dzięki informacjom zwrotnym. Już dziś działamy na poważną skalę, obsługując codziennie miliony minut głosowej AI.

Architektura Blue Machines jest bardziej oparta na działaniu w czasie rzeczywistym i natywnie wykorzystuje AI. Obejmuje infrastrukturę głosową, telefonię, rozpoznawanie mowy, rozumowanie z wykorzystaniem LLM, syntezę mowy, orkiestrację przepływów pracy, integracje, analitykę, obserwowalność oraz systemy oceny. Złożoność produktu jest wysoka, ponieważ głosowa AI dla przedsiębiorstw musi działać produkcyjnie, w prawdziwych rozmowach, przy niskich opóźnieniach, wysokiej dokładności, zabezpieczeniach zgodności z przepisami i jasno określonych rezultatach biznesowych.

W Blue Machines podstawowy zespół czterech inżynierów zbudował rozproszoną platformę orkiestracji głosu w ciągu zaledwie kilku tygodni. Mamy również bardzo doświadczony zespół badawczy, który dogłębnie zajmuje się głosową AI, oceną agentów, rozumowaniem, opóźnieniami, systemami wielojęzycznymi i doskonaleniem agentów w czasie. Ta głęboka wiedza badawcza jest ważna, ponieważ głosowej AI dla przedsiębiorstw nie da się rozwiązać wyłącznie poprzez łączenie modeli. Wymaga ona silnej inżynierii produktu, silnej inżynierii systemów i zaawansowanych badań stosowanych nad AI.

Ogólnie rzecz biorąc, organizacja technologiczna, którą kieruję, znajduje się na styku platform działających na dużą skalę i systemów natywnie wykorzystujących AI.

Jak dobrze zarządzana AI usprawnia cykl życia oprogramowania

W ciągu ostatniego roku AI zmieniła sposób, w jaki tworzymy, testujemy i wdrażamy technologie.

Wcześniej nasz proces wydawania oprogramowania był bardziej tradycyjny. Inżynierowie tworzyli funkcje, zgłaszali żądania PR, przechodzili wzajemne przeglądy, uruchamiali przypadki testowe, a następnie wdrażali zmiany za pośrednictwem standardowego potoku wdrożeniowego. Działało to, ale tempo zależało od cykli przeglądów przeprowadzanych przez ludzi, ręcznego zapewniania jakości i zaufania zespołu do wydania.

Gdy programowanie wspomagane przez AI stało się większą częścią pracy inżynierskiej, przyjęliśmy je — i wkrótce zdaliśmy sobie sprawę, że sama poprawa szybkości nie wystarczyła. AI może pomóc inżynierom szybciej pisać kod, ale jeśli zarządzanie nie zostanie usprawnione, może również prowadzić do powstawania większej liczby ukrytych błędów, pomijania przypadków brzegowych lub stosowania słabych abstrakcji.

Dlatego zmieniliśmy model operacyjny.

1. Dodaliśmy warstwę przeglądu PR wspomaganego przez AI. Każdy PR był sprawdzany pod kątem ryzykownej logiki, brakujących przypadków brzegowych, naruszeń kontraktów API, problemów z bezpieczeństwem, ryzyka związanego z migracją oraz niewystarczającego pokrycia testami — jeszcze przed przeglądem dokonanym przez człowieka. Ograniczyło to liczbę oczywistych przeoczeń przed rozpoczęciem przeglądu.
2. Wzmocniliśmy bramki CI. Zmiana nie mogła przejść wyłącznie dlatego, że kod wyglądał poprawnie. Musiała przejść testy jednostkowe, testy integracyjne, lintowanie, kontrole bezpieczeństwa, testy kontraktów API oraz zestawy testów regresji dla obszaru produktu, którego dotyczyła.
3. Stworzyliśmy bardziej rozbudowane zestawy testów regresji dla krytycznych przepływów pracy. Obejmowały one na przykład przypadki testowe dla rzeczywistych scenariuszy użytkowników, przypadków brzegowych, obsługi wielu języków, obsługi błędów oraz rezultatów biznesowych.
4. Zmieniliśmy zasady zarządzania promptami. Więcej na ten temat za chwilę.
5. Wprowadziliśmy obowiązkowe wdrożenia kanarkowe dla obszarów wysokiego ryzyka. Zamiast udostępniać zmianę wszystkim, kierujemy ją do niewielkiego odsetka ruchu, monitorujemy błędy, opóźnienia, konwersję, rezygnacje, jakość agentów i wpływ na klientów, a następnie zwiększamy zakres wdrożenia lub wycofujemy zmianę.
6. Dodaliśmy lepszą obserwowalność. Gdy coś się psuło, chcieliśmy dokładnie wiedzieć, która wersja kodu, wersja promptu, model, przepływ pracy lub zależność była tego przyczyną.

Wpływ tych zmian jest bardzo widoczny. Nasze tempo wydawania oprogramowania znacząco wzrosło. Zespoły, które wcześniej dostarczały większe, łączone wydania, przechodzą teraz na mniejsze i częstsze wydania. W niektórych obszarach częstotliwość wydań wzrosła niemal 2- do 3-krotnie, ponieważ kontrole są bardziej zautomatyzowane, a poziom pewności jest wyższy. To właśnie dzięki temu czteroosobowy zespół zbudował złożoną, rozproszoną platformę w ciągu zaledwie kilku tygodni.

Liczba problemów na produkcji również spadła, ponieważ każde wydanie jest mniejsze, lepiej przetestowane i łatwiejsze do wycofania. Odnotowujemy znaczący spadek liczby błędów produkcyjnych, zwłaszcza w obszarach, w których zautomatyzowane testy regresji i wdrożenia kanarkowe są teraz obowiązkowe. Obecnie liczba defektów jest niemal o 40% niższa niż pierwotnie.

Samo AI zapewnia szybkość. AI połączone z zarządzaniem zapewnia szybkość i jakość.

Dlaczego prompty należy traktować jak kod

Abhishek dzieli się

\u003cstrong\u003eW przypadku systemów AI również zaczęliśmy traktować prompty jak kod… Było to ważne usprawnienie. Wiemy, który prompt był aktywny, co się zmieniło, co uległo poprawie i czy rezultaty osiągane przez klientów stały się lepsze.\u003c/strong\u003e

W przypadku systemów AI również zaczęliśmy traktować prompty jak kod.

Obecnie wersjonujemy, przeglądamy, testujemy i promujemy prompty między środowiskami, a także wdrażamy je etapami. Prompty nie są już traktowane jak drobne aktualizacje konfiguracji. Przechodzą testowe rozmowy, sprawdzanie przypadków brzegowych, kontrole obsługi wielu języków, kontrole opóźnień, kontrole zgodności oraz kontrole rezultatów biznesowych.

Możemy najpierw udostępnić nowy prompt lub przepływ pracy agenta niewielkiemu odsetkowi ruchu, obserwować rezultaty, a następnie zwiększyć zakres wdrożenia, jeśli wskaźniki wyglądają lepiej.

Było to ważne usprawnienie. Wcześniej trudno było stwierdzić, czy zmiana promptu usprawniła działanie agenta, czy tylko zmieniła jego zachowanie. Teraz możemy bardziej obiektywnie porównywać wersje. Wiemy, który prompt był aktywny, co się zmieniło, co uległo poprawie i czy rezultaty osiągane przez klientów stały się lepsze.

Większa zmiana polega na tym, że cały system technologiczny stał się bardziej zautomatyzowany, mierzalny i objęty lepszym zarządzaniem.

Przepływ pracy związany z wydawaniem oprogramowania przez zespoły inżynierskie wykorzystujące agentów

Korzystamy z przepływu pracy związanego z wydawaniem oprogramowania przez zespoły inżynierskie wykorzystujące agentów, przy czym ludzie są zaangażowani w kluczowych punktach.

Ten przepływ pracy nie sprawdza się w przypadku każdego wydania. Przy bardzo złożonych zmianach platformy, głębokich zmianach architektury lub wrażliwych systemach nadal korzystamy z bardziej tradycyjnego procesu prowadzonego przez ludzi. Jednak w niektórych obszarach produktu, zwłaszcza w przypadku szybciej zmieniających się przepływów pracy, stał się on domyślnym sposobem tworzenia.

Oto ten przepływ pracy:

1. Proces rozpoczyna się, gdy pojawia się wymaganie dotyczące produktu lub problem inżynieryjny. Agent AI do planowania odczytuje wymaganie, dzieli je na zadania, identyfikuje zależności, wskazuje obszary ryzyka i proponuje plan implementacji. Inżynier analizuje plan, koryguje założenia i decyduje o ostatecznym podejściu.
2. Następnie agent programistyczny generuje kod, refaktoryzuje moduły, tworzy kod szablonowy oraz testy jednostkowe i integracyjne. Agent dokonujący przeglądu sprawdza pull request pod kątem ryzykownej logiki, pominiętych przypadków brzegowych, problemów z bezpieczeństwem, naruszeń kontraktów API oraz luk w testach.
3. Kolejnym krokiem jest utworzenie przez agenta testowego scenariuszy regresji i sprawdzenie przypadków brzegowych. W przypadku przepływów pracy AI uruchamia on również testy promptów, testy konwersacji, kontrole wielojęzyczności, kontrole opóźnień oraz kontrole rezultatów biznesowych.
4. Następnie agent wydań rekomenduje, czy zmiana jest bezpieczna do wdrożenia kanarkowego, biorąc pod uwagę wyniki testów, obszar wpływu, wcześniejsze awarie oraz gotowość systemów obserwowalności. Ludzie nadal zatwierdzają jednak krytyczne wdrożenia, zwłaszcza jeśli zmiana wpływa na przychody, doświadczenia klientów, bezpieczeństwo lub podstawową infrastrukturę.
5. Po wdrożeniu agent monitorujący obserwuje błędy, opóźnienia, konwersję, rezygnacje, jakość agenta i wpływ na klientów. Jeśli coś wygląda nieprawidłowo, rekomenduje wycofanie zmiany, otwiera incydent, podsumowuje dzienniki i tworzy pierwszy projekt analizy przyczyn źródłowych.

Ten przepływ pracy jest agentowy, ale nie autonomiczny w sposób bezkrytyczny. Agenci AI planują, programują, dokonują przeglądów, testują, wdrażają, monitorują i tworzą podsumowania. Ludzie zatwierdzają, kwestionują, ustalają priorytety i podejmują ostateczne decyzje.

W czym Claude Code i Cursor sprawdzają się najlepiej

Moimi ulubionymi narzędziami są Claude Code i Cursor, zależnie od przepływu pracy.

Cursor sprawdza się najlepiej, gdy inżynierowie chcą, aby AI było głęboko zintegrowane z ich środowiskiem IDE i wspierało codzienne programowanie, refaktoryzację, rozumienie bazy kodu oraz szybszą implementację.

Claude Code okazuje się niezwykle przydatny w przypadku bardziej agentowych zadań: rozumienia większych baz kodu, wprowadzania zmian w wielu plikach, generowania testów, naprawiania problemów i iteracyjnej pracy niczym partner inżynieryjny.

Dlaczego AI zapewnia wsparcie, a ludzie dostarczają osądu

Obecnie w dużym stopniu polegamy na AI w przypadku wszystkiego, co poprawia szybkość, zakres lub spójność, ale nie w przypadku zadań wymagających osądu, odpowiedzialności lub długoterminowych kompromisów.

AI pomaga nam obecnie na przykład w przeglądach kodu, generowaniu przypadków testowych, zapewnianiu pokrycia regresją, dokumentacji, debugowaniu, analizie dzienników, a nawet w kategoryzacji incydentów. Potrafi szybko identyfikować ryzykowne ścieżki kodu, pominięte przypadki brzegowe, potencjalne problemy z bezpieczeństwem lub wzorce występujące w awariach produkcyjnych. W systemach AI pomaga nam również porównywać wersje promptów, oceniać konwersacje i rozumieć, gdzie agent popełnia błędy.

Jednak ostateczne decyzje nadal podejmują ludzie. Oto kilka przykładów:

• Decyzje dotyczące architektury muszą pozostać domeną ludzi, ponieważ obejmują kompromisy związane ze skalą, kosztami, niezawodnością, możliwościami zespołu i długoterminowym kierunkiem rozwoju produktu.
• Analiza przyczyn źródłowych od początku do końca może być wspomagana przez AI, ale ludzie nadal muszą połączyć fakty, zweryfikować hipotezę i zdecydować o sposobie naprawy.
• Ustalanie priorytetów backlogu pozostaje zadaniem ludzi, ponieważ wymaga kontekstu klienta, strategii biznesowej i osądu dotyczącego tego, co naprawdę ma znaczenie.
• Podczas przeglądów bezpieczeństwa wykorzystuje się AI, ale niezbędny jest ekspercki osąd. AI może wskazywać problemy, ale może również generować fałszywe alarmy lub przeoczyć ryzyka związane z kontekstem biznesowym. Odpowiedzialność pozostaje po stronie ludzi, ponieważ ryzyko i odpowiedzialność są zbyt duże.

Przykłady niepowodzeń AI w zakresie osądu technicznego z rzeczywistego świata

Oto kilka przykładów znaczenia ludzkiego osądu.

Pierwszy dotyczył skoków opóźnienia na poziomie milisekund w naszym potoku głosowym. AI prawidłowo skomentowała problem i zidentyfikowała, że opóźnienie w jednej ze ścieżek może stać się problemem. Jednak zaproponowany przez nią kod był błędny. Wyglądał przejrzyście, ale pod obciążeniem doprowadziłby do powstania innego wąskiego gardła. Wkroczył inżynier, zrozumiał działanie środowiska uruchomieniowego i właściwie naprawił problem.

Inny przykład pojawił się podczas analizy problemu na produkcji. Wiele systemów zależnych ulegało awariom, a AI wciąż analizowała te systemy niezależnie i proponowała optymalizacje. Wiedzieliśmy jednak, że rzeczywistym problemem była zależność nadrzędna, która uległa awarii jako pierwsza. AI myliła widoczne awarie z ich przyczyną źródłową.

W tym obszarze AI wciąż ma trudności. Potrafi odczytywać logi, podsumowywać ślady, sugerować poprawki i przyspieszać debugowanie. Jednak w złożonych systemach rozproszonych może nie dostrzegać związków przyczynowych, zależności czasowych ani kontekstu na poziomie całego systemu.

Dlaczego zespoły stają się mniejsze, a jednocześnie bardziej wszechstronne

AI zmieniła profil zatrudnianych osób bardziej niż strukturę organizacyjną.

Wcześniej zatrudnialiśmy osoby o węższej specjalizacji funkcjonalnej: backend, frontend, QA, DevOps, dane itd. Te umiejętności nadal są ważne, ale teraz bardziej cenię inżynierów, którzy potrafią działać w całym stosie technologicznym, dogłębnie korzystać z AI i przechodzić od problemu do produkcji przy znacznie mniejszym wsparciu.

Najlepsi inżynierowie nie zajmują się dziś wyłącznie pisaniem kodu. Projektują przepływy pracy, wykorzystują AI do implementacji, generują testy, weryfikują rezultaty, szybciej debugują i myślą o jakości wdrożeń.

Dlatego poprzeczka rekrutacyjna przesunęła się w stronę inżynierów o wysokim poczuciu odpowiedzialności i umiejętności trafnej oceny sytuacji. Potrzebujemy osób, które potrafią zadawać właściwe pytania, weryfikować rezultaty AI, dogłębnie rozumieć systemy i samodzielnie dostarczać rozwiązania.

Zmniejszyło to również zapotrzebowanie na duże zespoły w niektórych obszarach. Mniejszy zespół, odpowiednio wykorzystujący AI, może dziś wykonać pracę, która wcześniej wymagała znacznie większej liczby osób.

Dlaczego AI utrudnia szkolenie początkujących inżynierów

Abhishek dzieli się

Nie uważam, że zakazanie AI lub zmuszanie ludzi do programowania tak, jakby był rok 2010, jest właściwym rozwiązaniem. Byłoby to błędem. Nie sądzę jednak również, że w pełni rozwiązaliśmy problem budowania głębokiego osądu inżynierskiego w sytuacji, gdy AI wykonuje tak dużą część pracy wstępnej. Na razie najlepszą odpowiedzią jest dla mnie uczynienie zrozumienia widocznym.

Jak szkolić początkujących inżynierów w erze AI? Nie mam jeszcze idealnej odpowiedzi.

Kiedy zaczynaliśmy, pomagały nam środowiska IDE. Później pomagał nam Google. Następnie pomagał nam Stack Overflow. Jednak na każdym z tych etapów nadal trzeba było samodzielnie zmierzyć się z problemem. Trzeba było zrozumieć odpowiedź, dostosować ją, zdebugować i nauczyć się, dlaczego działała.

Dzięki AI i programowaniu intuicyjnemu możemy pominąć tę trudną część. Początkujący inżynier może wygenerować działający kod bez rzeczywistego zrozumienia systemu, kompromisów ani scenariuszy awarii. To mnie niepokoi.

Nie uważam, że zakazanie AI lub zmuszanie ludzi do programowania tak, jakby był rok 2010, jest właściwym rozwiązaniem. Byłoby to błędem. Nie sądzę jednak również, że w pełni rozwiązaliśmy problem budowania głębokiego osądu inżynierskiego w sytuacji, gdy AI wykonuje tak dużą część pracy wstępnej.

Na razie najlepszą odpowiedzią jest dla mnie uczynienie zrozumienia widocznym. Inżynierowie powinni potrafić wyjaśnić, dlaczego kod działa, gdzie może zawieść, które testy mają znaczenie, co dzieje się przy dużej skali oraz jak debugowaliby go na produkcji.

Jak zarządzać wykorzystaniem tokenów

Koszt również stanowi wyzwanie związane z AI.

Wykorzystanie tokenów na początku wydaje się niegroźne, ale gdy AI pojawia się w programowaniu, przeglądach, testowaniu, debugowaniu i procesach z udziałem agentów, koszty mogą bardzo szybko wzrosnąć.

Dlatego musimy teraz mierzyć zwrot z inwestycji dla poszczególnych przepływów pracy i stosować inteligentniejszą orkiestrację. Nie każde zadanie wymaga najdroższego modelu.

Przyszłość polega na używaniu właściwego modelu do właściwego zadania.

Dlaczego dyrektorzy ds. technologii muszą działać szybko — z zachowaniem kontroli

Oto moja rada: Budujcie szybko. Eksperymentujcie szybko. Wprowadzajcie AI do rzeczywistych procesów inżynieryjnych, produktowych, wsparcia, sprzedaży, operacji i pracy wewnętrznej. Nie udawajcie, że to nie działa. To działa, czasem zaskakująco dobrze.

Nie stawajcie się jednak bezkrytycznymi wyznawcami. AI jest potężna, ale nie jest magią. Potrzebujecie kontroli, zarządzania, testowania, obserwowalności i jasno określonej odpowiedzialności. W przeciwnym razie stworzycie jedynie chaos — szybciej.

Właściwe podejście nie polega ani na przekonaniu, że „AI zastąpi wszystko”, ani na twierdzeniu, że „AI jest przereklamowana”. Właściwe pytanie brzmi: „jak mogę wykorzystać to rozwiązanie, aby zwiększyć możliwości mojej organizacji dziesięciokrotnie?”

Śledź dalszy ciąg

Śledź Abhisheka Ranjana na LinkedIn. Zajrzyj też do jego newslettera Hacktivate.

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