Zbudowałem AI Managera, bo sam nie miałem czasu

Narzędzie zaczęło się od mojej pracy

Przez lata pracy w korporacji nauczyłem się, że dużo czasu zabierają rzeczy, których osobno prawie nie widać. Trzeba zebrać informacje przed rozmową, wrócić do wcześniejszych ustaleń, przygotować status albo porównać materiały od dostawców. Każde z tych zadań ma sens. Problem pojawia się, kiedy wszystkie wymagają odtworzenia kontekstu od początku.

To jest środowisko, w którym powstał mój AI Manager. Nie dostałem zlecenia na zbudowanie systemu dla całego zespołu. Nie zaczynałem od planu sprzedaży produktu. Chciałem mieć narzędzie przydatne we własnej pracy. Takie, które pomaga uporządkować materiał i przejść przez zadanie, a nie tylko wygenerować kolejną odpowiedź.

Ta różnica jest dla mnie ważna. Gdy buduję coś dla siebie, dość szybko wychodzi, czy chcę do tego wrócić. Mogę zachwycić się pierwszą odpowiedzią modelu, ale następnego dnia nadal mam tę samą pracę do wykonania. Jeśli użycie narzędzia wymaga więcej przygotowań niż samo zadanie, trudno na nim oprzeć normalny tydzień.

Nie podaję tu obliczonej oszczędności godzin. Żeby taka liczba coś znaczyła, musiałbym porównać podobne zadania i uwzględnić czas sprawdzania wyniku. W tej historii ważniejsze jest dla mnie pokazanie, jak zmieniłem punkt startu: z luźnego pytania do AI na opisany sposób pracy.

Puste okno czatu zostawia zbyt wiele do pamiętania

Sam dostęp do modelu nie rozwiązuje problemu z kontekstem. W pustym oknie mogę napisać właściwie wszystko. Ta swoboda jest przydatna podczas szukania pomysłów, ale przy powtarzalnym zadaniu oznacza też, że za każdym razem muszę pamiętać o wszystkich wymaganiach.

Kto jest odbiorcą? Co już wiadomo? Jaka decyzja została wcześniej podjęta? Na których materiałach można się oprzeć? Jak długi ma być wynik? Co model powinien zrobić, gdy w notatkach czegoś brakuje? Jeżeli nie odpowiem na te pytania, AI nadal coś napisze. Tyle że część decyzji podejmie za mnie, często bez zaznaczenia tego w tekście.

Właśnie dlatego asystent z menu pracy ma dla mnie sens. Zamiast wymyślać polecenie od nowa, wybieram rodzaj zadania. Za nim mogą już stać wymagania dotyczące materiału, kolejności działania i formatu odpowiedzi. Wciąż mogę je zmienić. Nie muszę jednak za każdym razem budować całej instrukcji z pamięci.

To nie usuwa odpowiedzialności za wynik. Usuwa część przypadkowości na wejściu. Dla mnie to dużo bardziej użyteczna zmiana niż znalezienie jednego efektownego promptu, który dobrze zadziałał na prezentacji.

Kontekst powinien pomagać w konkretnym zadaniu

Łatwo pomylić kontekst z ilością tekstu. Można opisać firmę, rolę, zespół, wszystkie projekty i historię ostatnich miesięcy. Tylko że model nie potrzebuje całej tej wiedzy do każdego pytania. Część informacji będzie zbędna, część nieaktualna, a część w ogóle nie powinna znaleźć się w danym narzędziu.

Dzisiaj patrzę na kontekst przez zadanie. Do czego ma być potrzebny? Jeżeli przygotowuję podsumowanie dla konkretnego odbiorcy, potrzebuję jego perspektywy i oczekiwanego rodzaju decyzji. Potrzebuję też aktualnych materiałów. Opis mojej roli może pomóc dobrać język, ale nie zastąpi danych o tym, co wydarzyło się w projekcie.

Dlatego rozdzieliłbym rzeczy względnie stałe od bieżących. Stałe są na przykład zasady komunikacji i sposób oznaczania braków. Bieżące są notatki, lista zadań i uzgodnienia z danego okresu. Takie rozdzielenie ułatwia zauważenie, co trzeba podmienić przed kolejnym przebiegiem.

Jest jeszcze jeden warunek: materiały muszą być dopuszczone do użycia. Własna wygoda nie jest zgodą na przekazanie informacji firmowych do zewnętrznego modelu. Zanim zacznę pracę na dokumencie, muszę wiedzieć, czy wolno go użyć w tym środowisku. Jeżeli nie, zmieniam materiał albo sposób pracy.

Dobry wynik trzeba opisać przed generowaniem

Najbardziej użyteczna instrukcja nie kończy się na słowach „jesteś doświadczonym managerem”. Taka rola może ustawić perspektywę, ale nie mówi jeszcze, co będzie poprawnym wynikiem. Model nadal może napisać długi, przekonujący tekst, z którego trudno podjąć jakąkolwiek decyzję.

Weźmy przykładowy status projektu. To przykład sposobu myślenia, a nie zapis konkretnej sytuacji z mojej firmy. Można poprosić o podsumowanie postępu. Można też ustalić, że odpowiedź ma pokazać stan na określony dzień, potwierdzone ryzyka, brakujące dane i decyzję potrzebną od odbiorcy. W drugim wariancie jest już do czego przyłożyć gotowy tekst.

Istotne są także rzeczy, których odpowiedź nie może zrobić. Nie może dopisać terminu, którego nie ustalono. Nie może zamienić czyjejś sugestii w zatwierdzoną decyzję. Nie powinna ogłaszać opóźnienia tylko dlatego, że w materiale brakuje informacji o zamknięciu zadania.

Tak rozumiem kryteria jakości. To opis, co sprawdzę w wyniku. Gdy kryteria są zapisane, mogę je zastosować ponownie. Mogę też rozpoznać, czy problem wynika z danych, z instrukcji czy z samej odpowiedzi modelu. Bez tego każda poprawka jest trochę rozmową o wrażeniach.

Sprawdzanie nie może kończyć się na stylu

Ładna odpowiedź jest przyjemna do czytania. W pracy managerskiej to jednak za mało. Najważniejszy błąd może być ukryty w jednym zdaniu: w liczbie, interpretacji albo obietnicy, której nikt nie złożył. Cała reszta tekstu może wyglądać bardzo dobrze.

Dlatego przy ocenie wyniku wracam do źródeł. Skąd jest ta liczba? Czy to fakt, czy wniosek? Czy wniosek rzeczywiście wynika z materiału? Czy rekomendacja została oznaczona jako propozycja? Takie pytania są mniej efektowne niż generowanie, ale właśnie one decydują, czy mogę wykorzystać odpowiedź.

Osobno patrzę na brakujące informacje. Chcę, żeby były widoczne. Jeśli AI nie zna przyczyny problemu, użyteczniejsze jest wskazanie tej luki niż dopisanie najbardziej prawdopodobnego wyjaśnienia. W przeciwnym razie odbiorca może uznać domysł za element stanu faktycznego.

Nie traktuję też kolejnej odpowiedzi tego samego modelu jako niezależnego potwierdzenia. Mogę poprosić go o znalezienie niespójności, ale źródło nadal pozostaje źródłem. Ostatecznie to człowiek ocenia, czy sprawdzenie jest wystarczające dla konsekwencji danej decyzji.

Nie jestem programistą i to wyznacza moje granice

Budowanie z AI daje mi możliwość tworzenia rzeczy, których nie napisałbym sam. Nie oznacza to jednak, że automatycznie potrafię ocenić każdy fragment wygenerowanego kodu. Nie chcę opowiadać tej historii tak, jakbym po prostu zaczął szybciej programować. To byłoby nieprawdziwe.

Moja rola polega przede wszystkim na rozumieniu potrzeby, wyborze zakresu i sprawdzaniu zachowania narzędzia. Potrafię powiedzieć, jaki materiał ma dostać, co powinno z niego powstać i kiedy wynik jest nieprzydatny. W kwestiach, których sam nie umiem zweryfikować, potrzebuję dodatkowych testów albo odpowiedniej wiedzy technicznej.

To wpływa na sposób rozbudowy. Nie każda funkcja powinna powstać dlatego, że AI potrafi ją zaproponować. Jeśli nowy element zwiększa odpowiedzialność za dane, wysyłkę lub decyzje, trzeba ocenić go osobno. Sam fakt, że da się pokazać działający ekran, nie zamyka tego tematu.

Ta granica pomaga mi też w pracy z innymi osobami. Mogę pokazać sposób uporządkowania zadania bez sugerowania, że każdy musi budować aplikację. Czasem wystarczą materiały, dobrze opisana instrukcja i prosty sposób kontroli odpowiedzi. Warto zacząć właśnie od tego.

Dopiero potem pokazałem rozwiązanie innym

W marcu 2026 pokazałem AI Managera grupie managerów i liderów. To ważny punkt tej historii, ale nie jej początek. Najpierw narzędzie powstało na moją potrzebę. Prezentacja była kolejnym krokiem, a nie dowodem, że wcześniej wdrożyłem system dla całej organizacji.

Kiedy pokazuję własne rozwiązanie, chcę umieć wyjaśnić więcej niż to, gdzie należy kliknąć. Po co powstało? Jakich danych potrzebuje? Co robi, kiedy ich nie ma? Co trzeba sprawdzić przed użyciem wyniku? Te pytania pozwalają komuś ocenić, czy sposób pracy ma sens także w jego sytuacji.

Nie wszystko da się przenieść bez zmian. Inny manager może mieć innego odbiorcę, inne zasady danych i inny typ powtarzalnej pracy. Wspólna może być metoda, ale kontekst nadal trzeba zbudować dla konkretnej osoby. Gotowy szkielet pomaga zacząć. Nie zastępuje poznania zadania.

Dlatego nie utożsamiam prezentacji z samodzielnością użytkownika. Ktoś może rozumieć demo, a później utknąć przy własnym materiale. Dopiero kolejny przebieg, wykonany bez autora prowadzącego za rękę, pokazuje, co rzeczywiście zostało przyswojone.

Jak zacząłbym od jednego zadania

Jeżeli masz podobny problem, wybrałbym zadanie, które wraca i ma rozpoznawalny wynik. Nie całe „zarządzanie z AI”, tylko konkretną pracę. Przygotowanie informacji dla odbiorcy, porównanie materiałów albo uporządkowanie notatek. Ważne, żebyś znał ten proces na tyle, by ocenić odpowiedź.

Zapisałbym, z jakich materiałów korzystasz dzisiaj i co robisz z nimi po kolei. Potem wskazałbym miejsce, w którym AI mogłoby pomóc. Nie trzeba od razu oddawać mu całego procesu. Czasem największą wartość daje samo uporządkowanie informacji przed Twoją decyzją.

Przed pierwszą próbą określiłbym także, czego wynik nie może zawierać. To może być dopisywanie faktów, ujawnianie danych albo zmiana znaczenia ustaleń. Po próbie wróciłbym do tych kryteriów. Jeśli coś nie działa, poprawiłbym instrukcję i sprawdził ponownie na podobnym materiale.

Zapisany proces ma sens wtedy, gdy możesz do niego wrócić bez odtwarzania całej historii rozmowy. To jest dla mnie dobry punkt dojścia na początek. Jedno zadanie, które potrafisz wykonać, sprawdzić i powtórzyć. Z takiej potrzeby powstał mój AI Manager i od takiej potrzeby zaczynam pracę w AI po Twojemu.