Daniel

polecam przeczytać

mały rant na temat modelu mentalnego wdrażania ai pośród ludzi decyzyjnych w dużych firmach - zainspirowany poniższym postem niestety choroba chwalenia się ilością przepalonych tokenów, a tym samym przepalonej kasy, rozpowszechnia się bardzo szybko. nawet wśród ludzi, u których podejrzewałbym trochę więcej rozgarnięcia biznesowego (c-levels) z którymi mam do czynienia ale czego można się spodziewać, skoro dla kogoś decyzyjnego w firmie, w której pracują setki albo nawet tysiące ludzi, metryką sukcesu jest liczba wydanych licencji na jakiegoś sidekicka pokroju claude code, albo to że nagle każdy buduje swoje rozwiązania w kompletnym odłączeniu od innych stąd umiejętność przeprowadzenia gruntownej transformacji procesów pod nowe możliwości, jakie daje ai, jest ważniejsza niż samo „ogarnianie” claude code czy gpt próba zautomatyzowania procesów w takiej formie, w jakiej istnieją obecnie, zawsze kończy się niepowodzeniem i nieosiągnięciem pełnego potencjału, a co za tym idzie, maksymalnego ROI transformacja ai jest cholernie trudna i mozolna, ale gdy się przy tym wytrwa i zrobi się to porządnie, ROI jest niesamowite. i to dla każdego pracującego w danej firmie, a nie tylko dla tych, którzy mają największy kawałek tortu a jeżeli ktoś uważa że dobrym rozwiązaniem po takiej transformacji jest zwalnianie ludzi, to w mojej ocenie jest debilem i nie rozumie kompletnie jak bardzo wartościowi są eksperci domenowi, w CAŁYM procesie tej transformacji. ludzie też są i nadal będą jednym z lewarów skalowania biznesu „zautomatyzowanie czy też wdrożenie ai w gówniane procesy powoduje tylko to, że gówno płynie szybciej”

czego nauczyłem się wdrażając ai do firm nie da się sensownie tego przeprowadzić jako jakiś byt w izolacji. mam na myśli to, że ai musi mieć wgląd w kilka działów naraz, bo realne procesy naturalnie tak przebiegają. przykładem są same przekazania między działami, które marnują dużo czasu nie radzę ufać ludziom, którzy „specjalizują się” w transformacji ai w konkretnym departamencie, dlatego że nie ma czegoś takiego jak „departamentowy agent" np. agent działający TYLKO w dziale finansów nie radzę tym samym zamykać czy też izolować ai w jakiejś konkretnej roli albo departamencie. ograniczenie agenta do tylko jednego konkretnego zadania jest marnowaniem jego potencjału. nie widzę żadnych przesłanek, żeby ograniczać ai tak, jak ograniczamy ludzi my jako ludzie mamy po prostu takie przyzwyczajenie, że nadajemy sobie konkretne role w konkretnych działach ze względu na nasze limity umiejętności. nie jesteśmy tak wszechstronni i elastyczni jak ai. czemu więc zasady, które egzekwujemy wobec nas, mają być dla ai najlepszymi praktykami? jeżeli ktoś chce wdrożyć ai w finansach swojej albo czyjejś firmy, to nie może ograniczać się tylko do procesów typowo finansowych, takich jak AP czy AR. powinien też rozciągać możliwości ai horyzontalnie, obejmując konkretne części innych działów, które bezpośrednio łączą się z danym procesem finansowym, np. dział operacji, sprzedaży albo HR nie ma w firmach człowieka od tych wszystkich działów. nie ma żadnego kleju, który naturalnie je łączy. stąd właśnie duża szansa dla ai. wasi agenci muszą mieć możliwości pracy między różnymi działami, bo po prostu są do tego zdolni i mają takie umiejętności, w przeciwieństwie do nas dlatego też, gdy jesteśmy na samym początku wdrażania ai, zawsze polecam startować od działu, ALE mapować cały proces wraz z innymi etapami, które działają przed nim i po nim: - przed danym procesem (upstream), np. zakupy i przyjęcie towaru wpływają na zobowiązania wobec dostawców - po danym procesie (downstream), np. obsługa wyjątków opóźnia lub blokuje zamknięcie miesiąca nie startujemy od pojedynczego workflow ani od całej firmy. wybieramy dział na podstawie jego metryk, takich jak: - ilość wykonywanej pracy - koszt - zasięg (ile innych działów dotyka) kolejny raz przypomnę, transformacja ai to: 1. przeprojektowanie istniejących procesów pod nowe możliwości, tak by usunąć zbędne kroki 2. rozdzielenie pracy na deterministyczny kod, agentów ai oraz ludzi 3. danie ludziom możliwości kontroli nad całym systemem 4. ścisła współpraca na każdym etapie transformacji (projektowaniu, budowy i ewaluacji) z ekspertami domenowymi 5. wdrażanie ai w istniejących narzędziach firmy i pomiędzy nimi (jak najbardziej w tle), tak żeby nie wprowadzać kolejnych systemów/interfejsów, ani nie zmuszać ludzi do migracji danych i nowych szkoleń 6. świadome przekraczanie granic działów wewnątrz firmy, bo to tam jest masa wartości do zagospodarowania

polecam lekturę w kontekście sporu o to, czy czytać kod ai, nie chodzi o to, czy go czytać, tylko kiedy to robić, a przede wszystkim jak lepiej zrozumieć to, co budujemy code review, tak jak opisuje to Addy, powinno mieć kilka poziomów. każdy z nich wyłapuje co innego i przepuszcza to, co wyłapie dopiero następny poziom ale Addy wspomina też o fundamentalnej rzeczy, jaką jest zrozumienie tego, co w ogóle budujemy (a bardziej tego, co buduje dla nas ai) i czy warto to budować. dlatego tak ważne jest tworzenie narzędzi, które wspierają utrzymanie wspólnego rozumienia między człowiekiem a ai przykładem są dopracowane graficzne explainery, o których też mowa w artykule. niektórzy idą dalej tworząc krótkie filmiki, których zadaniem było właśnie bycie takim explainerem zagadnienia X już pare miesięcy temu (w świecie ai lata temu) pisałem o tym, jak zwiększyć poziom zrozumienia tego, co budujemy z ai, w o wiele przyjemniejszy sposób niż przez czytanie diffów: teapawt.net/MAXIMISEART/status/207… nie idźcie na skróty w procesie zrozumienia waszej pracy

świetny gość, fajny wykład, dobrze spędzone 45 min na temat jak działają proaktywni always on agenci np. grok bot na pewno lepsze niz scrollowanie tiktoka czy innych reelsów polecam