Odpowiedź już jest. A kto zorganizował pracę?

Jak zmienić AI z rozmówcy w środowisko pracy — przy umowach, biznesplanach i nie tylko

Sergey Avdeichik · DOBROVOLA · 12 września 2026 roku

Wyobraźmy sobie: na biurku leży biznesplan nowej piekarni. Dwadzieścia starannie przygotowanych stron, prognoza przychodów, strategia marketingowa i przekonujący wniosek: warto otworzyć drugi punkt. Tekst przygotowała AI. Osoba kierująca firmą zadaje jedno pytanie: „Skąd to się wzięło?”

Skąd wzięła się liczba klientów? Dlaczego przyjęto taki czynsz? Czy uwzględniono straty związane z niesprzedanym pieczywem? Kto sprawdził, czy pieniędzy wystarczy do czasu ustabilizowania się sprzedaży?

Ta sama scena w pracy prawniczej. Umowa wygląda profesjonalnie, ale nie wiadomo, które warunki uzgodniły strony, skąd wziął się termin płatności i na jakim brzmieniu przepisów oparł się autor.

Problem nie polega na estetyce tekstu. Gotowy dokument po prostu nie oznacza jeszcze, że wykonano niezbędną pracę.

Proponuję zmienić sam przedmiot rozmowy z AI. Nie tylko „proszę przygotować wynik”, lecz „zorganizujmy proces, w którym ten wynik będzie można sprawdzić”. Potrzebne są do tego źródła, jasna koncepcja, kolejność zadań, zasady pracy i człowiek podejmujący decyzje.

Metoda, która wyrosła z praktyk studenckich

Organizując praktyki dla studentów, chciałem pokazać nie tylko nowy sposób pisania kodu. Zależało mi na tym, by zdobyli doświadczenie pracy w środowisku, w którym obok ludzi działa agent AI: pomaga analizować pomysł, opracowuje dokumenty, wykonuje zadania i przedstawia wynik.

Bliskie jest mi tu doświadczenie Andreja Karpathy’ego z MenuGen — aplikacją, która tworzy obrazy potraw na podstawie zdjęcia restauracyjnego menu. W swoim opisie pokazał, jak szybko powstał pierwszy interfejs i ile dodatkowej pracy wymagały integracje oraz doprowadzenie aplikacji do stanu używalności. Między efektownym początkiem a gotowym produktem pojawiła się całkiem konkretna praca inżynierska. [1]

Na potrzeby praktyk zaproponowałem następującą kolejność: omówienie pomysłu, blueprint, analiza możliwych rozwiązań, specyfikacja techniczna, kamienie milowe, zadania, praca agenta i odbiór. Student miał rozumieć nie tylko to, co powstało, ale także dlaczego pracę zorganizowano właśnie w ten sposób.

Potem okazało się, że w tej kolejności bardzo niewiele elementów dotyczy wyłącznie programowania. Zamiast aplikacji wynikiem może być umowa, model finansowy, badanie rynku, kurs albo procedura działania firmy kurierskiej.

Rola zawodowa przy tym się poszerza. Prawnik musi trochę zaprojektować proces, przedsiębiorca — zrozumieć dane, a nauczyciel — sformułować kryteria jakości. Nie oznacza to, że każdy staje się jednocześnie specjalistą we wszystkich dziedzinach. Pozwala jednak prowadzić zadanie od początku do końca, angażując agenta i odpowiednich ekspertów na wybranych etapach.

Współpraca to nie tylko „człowiek i AI”, lecz także „człowiek — człowiek — agent”. Zleceniodawca wyjaśnia sytuację, specjalista sprawdza część merytoryczną, a agent pomaga wykonać pracę. Wspólne dokumenty utrwalają ich ustalenia.

To autorskie podejście do pracy, a nie obietnica jedynej słusznej metodologii. Zachowuje sprawdzone atuty profesjonalnego działania: dokumentację, kontrolę wersji, weryfikację danych wejściowych i odpowiedzialność wykonawcy. Zmienia się sposób, w jaki łączymy je w dostępne środowisko pracy.

Zacząć od rozmowy, nie od idealnego polecenia

Pierwszy etap to zrozumienie, co właściwie trzeba zrobić. Pomysł zazwyczaj nie przypomina jeszcze specyfikacji technicznej. Łączy w sobie chęć działania, niejasne wyobrażenie wyniku, kilka ograniczeń i kilkanaście niewypowiedzianych pytań.

Zalecam rozpoczęcie od rozmowy głosowej z modelem. Dla mnie to wygodny sposób rozwijania myśli: przypomnieć sobie przykład, podać coś w wątpliwość, zmienić punkt widzenia, wyjaśnić swoje obawy. Nie trzeba z góry zamieniać każdej wypowiedzi w dopracowane polecenie.

Na tym etapie warto poprosić agenta nie o wykonanie zadania, lecz o zbadanie problemu: zadawanie pytań, proponowanie alternatyw i dostrzeganie sprzeczności. „Proszę jeszcze nie pisać dokumentu. Proszę pomóc mi zrozumieć, jakiego dokumentu potrzebujemy i jakich informacji brakuje” — to całkiem dobry początek.

Przewaga nie wynika ze szczególnej magii modelu głosowego. Tak samo otwartą rozmowę można prowadzić tekstowo. Głos jest moim sposobem na wcześniejsze wydobycie myśli, które w przeciwnym razie pozostałyby niewypowiedziane.

Na podstawie transkrypcji model tekstowy pomaga przygotować blueprint — zrozumiały opis koncepcji. Dla kogo wykonujemy pracę? Na jakie pytanie ma ona odpowiedzieć? Co obejmuje jej zakres? Jakie informacje są potrzebne? Po czym poznamy, że wynik jest przydatny?

Transkrypcja daje szeroki kontekst, ale nie staje się automatycznie zbiorem wymagań. Trzeba oddzielić uzgodnione decyzje od założeń, propozycji modelu i odrzuconych wariantów. Przypadkowe „a można by jeszcze…” nie powinno niepostrzeżenie zmieniać się w obowiązkowe zadanie. Sam blueprint człowiek czyta, poprawia i zatwierdza.

Kolejny krok to tekstowa analiza wariantów. W projekcie studenckim dotyczy ona architektury aplikacji, przechowywania danych, technologii i uruchomienia. W pracy prawniczej — kolejności analizy, zestawu źródeł, kontroli i uzgodnień. W biznesplanie — struktury obliczeń, dostępnych danych, sposobów weryfikacji popytu i budowania scenariuszy.

Wynik tego etapu nazywam „chmurą wiedzy”: człowiek nie dokonał jeszcze wszystkich ostatecznych wyborów, ale rozumie już przestrzeń możliwych rozwiązań. Teraz wraca do rozmowy głosowej przygotowany i omawia, jak praca będzie przebiegać w praktyce.

Następnie model może ułożyć prompt do przygotowania specyfikacji. Do innego modelu tekstowego trafiają zatwierdzony blueprint, notatki z analizy, transkrypcja ustalonych decyzji i ten prompt. Wynikiem jest projekt specyfikacji technicznej. Dla odbiorców spoza inżynierii prościej nazwać go opisem zadania i procesu: materiały wejściowe, działania, ograniczenia, wynik i warunki odbioru.

Osobny prompt nie jest przydatny jako zaklęcie. To zapisana instrukcja tworzenia dokumentu: inny uczestnik będzie mógł zrozumieć, z jakich materiałów i według jakich zasad go przygotowano. Ostateczna kontrola sensu pozostaje po stronie człowieka.

GitHub, Linear i agent: trzy zrozumiałe role

Nazwy narzędzi mogą sprawiać wrażenie, że dalej zaczyna się praca wyłącznie dla programistów. Tymczasem przeznaczenie każdego z nich można wyjaśnić bez technicznego słownika.

GitHub to miejsce na pliki i historię ich zmian. Repozytorium można wyobrazić sobie jako folder projektu, w którym widać, co się zmieniło i kto to zrobił. Przechowuje się tam nie tylko kod: GitHub obsługuje pliki, współpracę i historię wersji. [2]

W moim podejściu projekt ma dwa repozytoria. W pierwszym rozwija się koncepcja: blueprint, analizy, dyskusje, specyfikacje i podjęte decyzje. W drugim powstaje wynik: kod aplikacji, projekt umowy, obliczenia lub materiały kursu.

Pierwsze repozytorium to swoista przestrzeń odkrywania i dokumentowania nowych kierunków projektu. Można tu swobodnie myśleć, zachowywać nowe pomysły i odrzucone warianty, nie zamieniając ich od razu w zadania. Drugie pokazuje, co faktycznie zrobiono. Uzgodnionych wymagań nie trzeba kopiować w kilka miejsc: lepiej łączyć dokumenty i wyniki odnośnikami.

Wersję roboczą należy oznaczyć jako roboczą, zatwierdzony dokument powinien mieć datę i numer wersji, a nieaktualny nie może udawać aktualnego. Czytelny plik startowy z mapą materiałów jest bardziej przydatny niż ogromne archiwum bez drogowskazów. Ważne objaśnienia wygodnie przechowywać jako zwykły tekst, a złożone arkusze i dokumenty — wraz z krótkim opisem zmian.

Linear to centrum koordynacji pracy. Widać w nim, co trzeba zrobić, do którego kamienia milowego należy zadanie, co już sprawdzono i co blokuje dalszy postęp. Kamienie milowe w Linear pozwalają grupować zadania według etapów projektu i śledzić ich realizację. [3]

Agent AI to wykonawca działający w przygotowanym środowisku. W tej roli można wykorzystać na przykład Codex lub Claude Code. Codex potrafi pracować z plikami, wprowadzać zmiany i uruchamiać dostępne narzędzia. Na tych możliwościach można oprzeć nie tylko programowanie, ale też przetwarzanie danych czy przygotowywanie dokumentów. To sposób wykorzystania środowiska agentowego, a nie obietnica gotowego rozwiązania dla konkretnej branży. [4]

Połączenia dają agentowi dostęp do zewnętrznych narzędzi i kontekstu; ich możliwości zależą od konkretnej integracji i przyznanych uprawnień. [5] Agent może więc pomóc skonfigurować projekt, uporządkować materiały i przygotować zadania, ale samo jego zapewnienie nie dowodzi, że dostęp już działa. Potrzebny jest prosty test: czy faktycznie przeczytał właściwy plik, utworzył kartę we właściwym projekcie i zwrócił link do wyniku?

GitHub nie powinien stać się magazynem wszystkich tajemnic firmy. Nieprzetworzone dokumenty klientów, dane osobowe i eksporty finansowe mogą pozostać w zatwierdzonym firmowym repozytorium danych, a w projekcie można prowadzić ich rejestr i kontrolowane odnośniki. O miejscu przechowywania danych decyduje się przed ich przesłaniem, nie po nim.

Dwa repozytoria to mój zalecany sposób rozdzielenia tych obszarów, ale nie cel sam w sobie. W pierwszej niewielkiej próbie wystarczą dwa foldery i prosta lista zadań. Ważne, by zachować granicę między koncepcją a wykonaniem. Po jej zrozumieniu łatwiej przejść do pełnego środowiska, zamiast uczyć się kilku usług naraz tylko po to, by odhaczyć kolejne narzędzia.

Przykład pierwszy: umowa, którą można sprawdzić

Załóżmy, że niewielka piekarnia kupuje urządzenia. Trzeba przygotować projekt umowy dostawy. To przykład edukacyjny pokazujący organizację pracy, a nie opinia prawna dotycząca konkretnej transakcji.

Najprostsza droga to poprosić model o napisanie umowy. Najpierw warto jednak ustalić, co dokładnie jest kupowane, kto jest dostawcą, gdzie znajdują się strony, kto zainstaluje urządzenia i jak zostanie potwierdzona ich sprawność. Co jest dla kupującego najważniejsze: termin dostawy, uruchomienie przed otwarciem, serwis czy możliwość rezygnacji z zakupu?

Najpierw — blueprint procesu

Cel można sformułować tak: przygotować projekt umowy, który odzwierciedla uzgodnione warunki transakcji, wskazuje kwestie sporne i nadaje się do przekazania prawnikowi do sprawdzenia.

Blueprint określa uczestników, prawo właściwe, istotne daty, materiały wejściowe i zakres analizy. W przypadku już istniejącego sporu trzeba osobno ustalić daty zdarzeń i wspólnie z prawnikiem określić, jakie brzmienie przepisów ma do nich zastosowanie. Przy przyszłej transakcji — uwzględnić znane zmiany, które mogą wpłynąć na jej wykonanie. Nie można milcząco pozostawić modelowi wyboru kraju, daty i porządku prawnego.

Tutaj też ustalamy zasadę: najpierw gromadzimy fakty i podstawy, potem formułujemy wnioski. Oferta handlowa, korespondencja stron i specyfikacja urządzeń są potrzebne obok źródeł prawa. Z ustawy nie dowiemy się, jaki termin dostawy strony rzeczywiście uzgodniły.

Następnie — zadanie dotyczące źródeł i weryfikacji

Po przeanalizowaniu wariantów i omówieniu decyzji powstaje opis zadania i procesu. Agent ma znaleźć odpowiednie akty prawne w oficjalnych źródłach, zapisać dozwolone kopie w folderze projektu lub zatwierdzonym miejscu przechowywania i sporządzić rejestr. Jeśli dla danej kwestii istotne jest orzecznictwo, jego wyszukiwanie zleca się osobno.

Na przykład dla prawa polskiego punktem wyjścia może być państwowy portal ELI. Rozróżnia on teksty ogłoszone, teksty jednolite oraz wersje przygotowane do celów informacyjnych; już dlatego nie wystarczy pobrać pierwszego znalezionego pliku i nazwać go „ustawą”. [6]

Każdy dokument w rejestrze wymaga tytułu, oficjalnego adresu, wersji, istotnych dat oraz wyjaśnienia, dlaczego został uwzględniony. Data pobrania nie zastępuje daty wejścia przepisu w życie. Dla wniosku znaczenie mają konkretny artykuł, ustęp lub punkt, zastosowanie do danej sytuacji i ewentualne wyjątki. Wszystko to podlega sprawdzeniu przez specjalistę.

Zatwierdzony opis zadania zabrania wymyślania brakujących danych i przedstawiania proponowanych warunków jako uzgodnionych. Nieznany termin płatności musi pozostać pytaniem do stron. Każdy istotny wniosek prawny wskazuje konkretną podstawę; tam, gdzie podstaw brakuje, pojawia się oznaczenie niepewności.

Zgromadzone źródła pozwalają opierać pracę na czymś więcej niż tylko na pamięci modelu. Jednak brak dokumentów nie jest jedyną przyczyną zmyślonych odpowiedzi: modele potrafią mylić się z dużą pewnością i powinny móc przyznać się do niepewności. [7] Sam folder z ustawami nie stanowi więc gwarancji. Trzeba sprawdzić zarówno to, jaki tekst wykorzystano, jak i to, czy rzeczywiście uzasadnia on wniosek.

Kamienie milowe opisują wynik, nie zajętość

W tym procesie wystarczą trzy zrozumiałe kamienie milowe: „Fakty i podstawy prawne zweryfikowane”, „Projekt umowy i lista spornych warunków przygotowane”, „Prawnik sprawdził projekt, decyzje stron zostały zapisane”.

Na razie szczegółowo rozpisujemy tylko pierwszy. Może on obejmować cztery zadania: zebrać materiały transakcji; znaleźć źródła prawa; sprawdzić wersje i zastosowanie przepisów; przygotować listę braków dla prawnika i zleceniodawcy.

Odbiór pierwszego kamienia milowego nie polega na komunikacie „przepisy przeanalizowane”. Oznacza dostępne dokumenty, rejestr podstaw, potwierdzone fakty i otwarte pytania. Krytycznej luki nie można zamknąć ogólną obietnicą „doprecyzujemy później”: wymaga ona decyzji prawnika i zleceniodawcy. Dopiero potem powstaje konkretne zadanie przygotowania projektu umowy.

Podczas końcowej kontroli warto przechodzić od każdego ważnego postanowienia wstecz: czy wynika ono z przepisu, z korespondencji, czy jest propozycją, którą dopiero trzeba omówić? Kto potwierdził cenę? Gdzie opisano odbiór urządzeń? Czy między umową a załącznikiem pozostały sprzeczności?

Wynikiem jest projekt do świadomego uzgodnienia, a nie automatycznie podpisana umowa. Przekazanie dokumentu kontrahentowi i podpisanie go pozostają odrębnymi działaniami upoważnionego człowieka. Czasem przydatnym wynikiem będzie decyzja, by nie zatwierdzać transakcji, dopóki warunki dostawy lub serwisu nie zostaną wyjaśnione.

Przykład drugi: biznesplan, który może powiedzieć „nie otwierać”

Teraz właściciel tej samej piekarni myśli o drugim punkcie. Chce otrzymać biznesplan, model finansowy i propozycje marketingowe. To kolejny scenariusz edukacyjny; wszystkie liczby poniżej są przykładowe i nie opisują rzeczywistej piekarni ani rynku.

W rozmowie z agentem warto zmienić sformułowanie celu. Nie „uzasadnić otwarcie”, lecz „ustalić, w jakich warunkach otwarcie ma sens i jakie ryzyko firma może zaakceptować”. W przeciwnym razie oczekiwany wniosek łatwo staje się niepisanym wymaganiem wobec całej analizy.

Blueprint zaczyna się od decyzji właściciela

Trzeba określić, na jakie pytanie odpowiadamy, jakie warianty porównujemy i jakie mamy ograniczenia. Nowy punkt może konkurować o pieniądze z rozbudową pierwszego, dostawami albo wymianą urządzeń. Ważne, by z góry wskazać dopuszczalne nakłady, rezerwę gotówkową i warunki zatrzymania projektu.

Następnie rozpoczyna się analiza tekstowa: jakie dane będą potrzebne, jak sprawdzić popyt, jakie koszty bywają pomijane właśnie w tym modelu. Po omówieniu wariantów właściciel przedstawia wybrany sposób działania, a na podstawie tych decyzji powstaje opis zadania i procesu.

Może on wymagać modelu na dwanaście miesięcy, kilku scenariuszy popytu, planu kosztów początkowych, przepływów pieniężnych i osobnej listy założeń. Plan marketingowy staje się częścią weryfikacji ekonomiki przedsięwzięcia, a nie samodzielnym, efektownym załącznikiem.

Źródła są ważniejsze niż pewnie brzmiąca prognoza

Agent zbiera dopuszczone do wykorzystania eksporty sprzedaży pierwszego punktu, informacje o zakupach i stratach niesprzedanego pieczywa, oferty lokali i urządzeń oraz kalkulację kosztów personelu. W otwartych źródłach może szukać dostępnych ofert najmu i informacji o konkurencji. Każda liczba powinna mieć wskazane pochodzenie i datę.

Stawka czynszu z ogłoszenia nie jest jednak tym samym co ostateczne warunki umowy. Sprzedaż w pierwszym punkcie nie dowodzi popytu pod nowym adresem. Gdy brakuje danych, przydatnym wynikiem zadania jest nazwanie luki i zaproponowanie sprawdzenia: obserwacji ruchu pieszych, niewielkiego testu sprzedaży lub zapytania o ofertę handlową.

Pierwszy kamień milowy może nosić nazwę „Dane wejściowe zebrane, kluczowe założenia wyodrębnione”. Wewnątrz są cztery zadania: sprawdzić sprzedaż i koszty; zebrać oferty dotyczące lokalizacji i uruchomienia; opisać weryfikację popytu; uzgodnić parametry wejściowe. Odbiór nie wymaga określonej liczby plików, lecz jasnego rozróżnienia: fakt, wstępna oferta, obliczenie albo hipoteza.

Jedna liczba zmienia cały wniosek

Przyjmijmy przykładowy model. Średni przychód na jedną transakcję wynosi 25 zł netto, bez VAT. Punkt działa 30 dni w miesiącu. Koszty zmienne stanowią 45% przychodów; przyjęte stałe wydatki pieniężne, w tym wynagrodzenia i czynsz, wynoszą 45 000 zł miesięcznie.

Przy 100 transakcjach dziennie miesięczne przychody wyniosą:

100 × 25 × 30 = 75 000 zł.

Po odjęciu kosztów zmiennych pozostanie 55% przychodów, czyli 41 250 zł. Po odjęciu kosztów stałych wynik wyniesie minus 3 750 zł.

Przy 140 transakcjach dziennie przychody wzrosną do 105 000 zł, a wynik tego samego uproszczonego modelu wyniesie plus 12 750 zł. Różnicę spowodowało jedno założenie — liczba zakupów dziennie.

Próg pokrycia tych kosztów oblicza się następująco:

45 000 ÷ (25 × 0,55 × 30) ≈ 109,1 transakcji dziennie.

Orientacyjnie jest to około 110 transakcji dziennie. Nie jest to próg zwrotu wszystkich nakładów ani zysk netto: nie uwzględniono tu inwestycji początkowych, amortyzacji, finansowania, podatków i specyfiki przepływów pieniężnych. Przed decyzją o otwarciu trzeba rozpatrzyć je osobno.

Wraca teraz pytanie z początku artykułu: skąd wzięło się założenie 140 transakcji? Potwierdzają je obserwacje, test sprzedaży czy tylko nadzieja właściciela?

Model może bezbłędnie wykonać obliczenia, a mimo to doprowadzić do złej decyzji, jeśli założenie wejściowe nie wytrzymuje weryfikacji. Dlatego obliczenia należy wykonywać w arkuszu lub programie z jawnymi formułami, a najważniejsze wyniki — niezależnie przeliczać.

Marketing też musi zgadzać się z rachunkiem

Propozycja „przyciągać klientów reklamą” nie odpowiada jeszcze na pytanie, ile będzie kosztował dodatkowy popyt. Jeśli do kosztów stałych dodamy 5 000 zł miesięcznego budżetu reklamowego, przy pozostałych warunkach bez zmian próg pokrycia kosztów wzrośnie do około 122 transakcji dziennie.

Zadanie marketingowe powinno więc przedstawiać nie tylko atrakcyjny plan promocji, lecz także sprawdzalną hipotezę: jaki kanał, jakie koszty, jaki oczekiwany wynik, jak go mierzymy i kiedy kończymy nieskuteczny eksperyment.

Po odbiorze danych wejściowych można uszczegółowić kolejny kamień milowy — „Scenariusze obliczone, wrażliwość modelu i zapotrzebowanie na gotówkę zrozumiałe”. Ostatnim kamieniem milowym jest decyzja właściciela z zapisanymi warunkami. Podczas odbioru zmienia się popyt, czynsz i koszty zakupów, by sprawdzić, jak wpływa to na obliczenia i rezerwę gotówkową.

Wynik może brzmieć: „otwieramy pod tymi warunkami”, „najpierw sprawdzamy popyt” albo „ten lokal się nie nadaje”. Dobry biznesplan nie musi wspierać pierwotnego zamiaru właściciela.

Planować kolejny kamień milowy na podstawie rzeczywistości

W obu przykładach obowiązuje jedno ograniczenie: nie trzeba z góry zamieniać całego projektu w sto szczegółowych zadań.

Najpierw opisujemy ogólną drogę i zależności. Następnie szczegółowo rozpisujemy najbliższy kamień milowy. Na początek zalecam, w miarę możliwości, nie więcej niż pięć zadań — tyle, by człowiek mógł utrzymać w głowie ich sens i powiązania. To praktyczne ograniczenie złożoności, a nie naukowo ustalona liczba.

Pięć zadań nie może jednak stać się pięcioma workami bez dna. Jeśli któregoś nie da się jasno wyjaśnić i sprawdzić, lepiej zmniejszyć zakres kamienia milowego. Pojawiające się błędy i pytania należy uczciwie odnotowywać, a nie ukrywać dla ładnej liczby kart.

Każde zadanie powinno odpowiadać na proste pytania: co ma powstać, na jakich materiałach pracujemy, co nie wchodzi w zakres i jak wynik zostanie sprawdzony? W przykładzie prawniczym „sprawdzić źródła” oznacza przedstawić rejestr i uwagi, a w finansowym „obliczyć scenariusze” — przekazać odtwarzalne obliczenia z formułami.

Dopóki brakuje doświadczenia w zarządzaniu agentami, zalecam nie prowadzić kilku kamieni milowych równolegle. Najpierw trzeba nauczyć się kończyć jeden. Następny uszczegóławia się po odbiorze poprzedniego — z uwzględnieniem znalezionych źródeł, przygotowanych plików, wykonanych zadań i ujawnionych ograniczeń.

W tym celu agent otrzymuje aktualne materiały obu repozytoriów oraz stan zadań w Linear. Prosimy go o wskazanie, co rzeczywiście przeanalizował, zamiast zakładać, że podłączony folder automatycznie został przeczytany.

Nowa informacja może zmienić plan. Jeśli okaże się, że brakuje potrzebnych danych o popycie, kolejnym zadaniem staje się sprawdzenie popytu, a nie dopracowywanie prognozy. To nie błąd metody, lecz jej normalne działanie.

Rozwijać trzeba dwie pętle pracy

Taka praca daje dwa wyniki. Pierwszy to sam wytwór działania: umowa, kalkulacja, analiza, aplikacja. Drugi to ulepszone środowisko, w którym będzie wykonywana następna podobna praca.

Środowisko agentowe ma własne instrukcje. W Codex używa się plików AGENTS.md, a w Claude Code — CLAUDE.md. Określają one kontekst projektu i zasady pracy. To zwykłe dokumenty tekstowe, a nie materiał dostępny wyłącznie programistom. [8, 9]

W naszej piekarni zasady mogą brzmieć tak: nie przedstawiać założeń jako faktów; nie zmieniać uzgodnionych danych wejściowych bez osobnego wpisu; dołączać formuły do obliczeń; przekazywać sporne kwestie prawne specjaliście; nie wysyłać dokumentów odbiorcom zewnętrznym bez zgody.

Role też mogą być proste: zbadać, wykonać, sprawdzić. Przy pierwszym projekcie nie trzeba uruchamiać trzech agentów jednocześnie. Jeden agent może pomagać na różnych etapach, a człowiek — podejmować decyzje i angażować specjalistę tam, gdzie potrzebna jest weryfikacja merytoryczna.

Powtarzające się procedury można zapisywać jako umiejętności agenta, czyli skills: na przykład sposób tworzenia rejestru źródeł albo sprawdzania arkusza finansowego. W narzędziach agentowych skill łączy instrukcje i materiały pomocnicze do określonego zadania. [10]

Zasady tekstowe nie zastępują jednak technicznych uprawnień dostępu. Zapis „nie wysyłać dokumentów” nie jest tym samym co ograniczenie możliwości ich wysyłania. Dostępy, zatwierdzanie istotnych działań i limity wydatków trzeba konfigurować osobno. Dokumentacja Claude Code wyraźnie odróżnia instrukcje kontekstowe od technicznie egzekwowanych ustawień. [9]

Po każdym kamieniu milowym proponuję krótki przegląd: co zadziałało, jakie założenie okazało się błędne, gdzie straciliśmy czas, co się powtarzało. Jeśli produktywność spada wcześniej, nie trzeba czekać do końca etapu. Jeżeli agent systematycznie korzysta ze starej wersji dokumentu, należy poprawić nie tylko odpowiedź, ale też sposób dostępu do aktualnych materiałów.

Nie warto przy tym tłumaczyć każdej porażki „złym promptem”. Przyczyna może leżeć w sformułowaniu zadania, źródłach, dostępach, narzędziu, obliczeniu albo kontroli. Bierzemy jeden konkretny przypadek, analizujemy jego przebieg i dopiero potem zmieniamy regułę. Usuwamy sprzeczności, zamiast bez końca dopisywać instrukcje.

Rozwijają się dwie pętle: to, co robimy, i to, jak to robimy. Ulepszenie drugiej sprawdzamy na następnym porównywalnym zadaniu: czy jest mniej powtarzających się błędów, ręcznych poprawek i kosztów?

„Gotowe” to nie status w narzędziu do zadań

Zamknięta karta sama w sobie niczego nie dowodzi. Odbiór oznacza wcześniej uzgodnioną obserwację: można otworzyć źródło, powtórzyć obliczenie, wyjaśnić sporny warunek lub odtworzyć główny scenariusz.

Przy umowie ważne jest pokazanie powiązania faktów, przepisów, wybranych warunków i decyzji prawnika. Przy biznesplanie — pochodzenia liczb, formuł, wrażliwości i ograniczeń modelu. Agent może pomóc w kontroli, ale jego druga pewnie brzmiąca wiadomość nie jest niezależnym potwierdzeniem pierwszej.

Na końcu każdego kamienia milowego proponuję dwa pytania.

Czy potrafię prostymi słowami wyjaśnić obecny kamień milowy i jego zadania osobie spoza projektu?

Jeśli jutro agent stanie się niedostępny, czy zrozumiem, co zrobiono i dlaczego właśnie tak?

Drugie pytanie nie wymaga samodzielnego zastąpienia wszystkich specjalistów i przepisania wszystkich programów. Sprawdza, czy rozumienie procesu należy do ludzi, czy pozostało wewnątrz rozmowy, która może zniknąć.

Zacząć od jednego procesu, nie od „transformacji AI”

Do pierwszego wdrożenia wybrałbym ograniczoną, powtarzalną pracę: przygotowanie pakietu dokumentów do umowy, uzgodnienie danych wejściowych do raportu, analizę przyczyn opóźnień dostaw albo zebranie materiałów na zajęcia. Nie cały dział prawny, finanse lub sieć logistyczną naraz.

Przed rozpoczęciem warto opisać obecny sposób działania: kto wykonuje pracę, ile zaangażowania ona wymaga, które błędy są dotkliwe i kto ma prawo odebrać wynik. Następnie przejść jeden pełny cykl z agentem i porównać nie tylko szybkość pierwszej odpowiedzi, ale też łączny czas wraz z kontrolą i poprawkami.

W produkcji może to być przygotowanie raportu o odchyleniach jakościowych, w usługach — analiza powtarzających się zgłoszeń, w logistyce — zbadanie przyczyn niedotrzymania terminów. To propozycje ograniczonych pilotaży, a nie twierdzenie, że jedna konfiguracja sprawdza się jednakowo w każdej branży.

Właśnie wokół takiego procesu warto budować szkolenie pracowników. Pracownik uczy się nie kolekcjonowania promptów, lecz definiowania zadania, gromadzenia kontekstu, sprawdzania podstaw, dostrzegania granic automatyzacji i ulepszania zasad pracy. W zespole pozostaje nie tylko doświadczenie rozmowy z modelem, ale też odtwarzalna procedura.

Nie każde krótkie zadanie wymaga blueprintu, dwóch repozytoriów i narzędzia do planowania. Im mniejszy koszt błędu i potrzeba powtarzania pracy, tym prostsza powinna być jej organizacja. Metoda przydaje się tam, gdzie praca trwa dłużej niż jedna rozmowa, wykorzystuje kilka źródeł, przechodzi między ludźmi lub wymaga decyzji, którą można wyjaśnić.

Czasem najlepszy wynik to zrezygnować z działania

Na końcu procesu prawnego może pojawić się decyzja, by nie podpisywać umowy w proponowanym brzmieniu. Na końcu finansowego — by nie otwierać drugiego punktu pod wybranym adresem. Jeśli decyzja opiera się na sprawdzonych podstawach, nie jest to porażka agenta ani nieudany projekt.

Przecież nie zaczynaliśmy od zadania wyprodukowania jak największej ilości tekstu. Chcieliśmy lepiej zrozumieć sytuację i podjąć decyzję, której konsekwencje poniosą ludzie.

Dlatego proponuję patrzeć na AI nie tylko jak na rozmówcę, którego można o coś zapytać, lecz także jak na uczestnika zorganizowanej pracy. Na końcu powinny pozostać dwie rzeczy: sprawdzalny wynik i ulepszony sposób jego uzyskiwania.

Wtedy pytanie „Skąd to się wzięło?” przestaje być niemiłą niespodzianką. Można spokojnie odpowiedzieć: oto źródła, oto założenia, oto przeprowadzone kontrole — a oto decyzja podjęta przez człowieka.

O autorze

Sergey Avdeichik — inżynier systemów AI, badacz i twórca produktów cyfrowych. Prowadzi praktyki studenckie, opracowuje autorskie metody pracy z agentami AI, szkoli pracowników i wdraża procesy wykorzystujące AI w firmach. W centrum tej pracy znajdują się konkretne zadanie, przygotowanie ludzi, możliwość weryfikacji wyniku i zachowanie kompetencji wewnątrz zespołu.

Strona: dobrovola.dev · LinkedIn · Facebook

Który proces w Państwa pracy już prosi się o takie środowisko — i na jakim etapie najtrudniej Państwu sprawdzić wynik? Chętnie omówię konkretne przykłady.

Źródła i materiały

Kolejność pracy opisana w artykule to autorska metodyka. Źródła zewnętrzne objaśniają możliwości narzędzi i wybrane ograniczenia. Oba przykłady mają charakter edukacyjny; obliczenia opierają się na wyraźnie wskazanych, przykładowych danych. Strony źródłowe sprawdzono 12 września 2026 roku.

[1] Andrej Karpathy. Vibe coding MenuGen. Autorski opis tworzenia aplikacji, 27 kwietnia 2025 roku. Otwórz materiał.

[2] GitHub Docs. About repositories. Pliki, współpraca i historia zmian. Oficjalna dokumentacja.

[3] Linear Docs. Project milestones. Kamienie milowe projektu i powiązane zadania. Oficjalna dokumentacja.

[4] OpenAI. Codex CLI. Praca z plikami, poleceniami i powtarzalnymi procedurami. Oficjalna dokumentacja.

[5] OpenAI. Model Context Protocol. Podłączanie narzędzi i zewnętrznego kontekstu. Oficjalna dokumentacja.

[6] ELI, Polska. European Legislation Identifier. Oficjalne źródła prawa i oznaczenia wersji tekstów. Portal państwowy.

[7] OpenAI. Why language models hallucinate. Przyczyny pewnie brzmiących, błędnych odpowiedzi i przyznawanie się do niepewności, 5 września 2025 roku. Materiał badawczy.

[8] OpenAI. Custom instructions with AGENTS.md. Kontekst i instrukcje projektu dla Codex. Oficjalna dokumentacja.

[9] Anthropic. How Claude remembers your project. CLAUDE.md; różnica między instrukcjami a ograniczeniami egzekwowanymi technicznie. Oficjalna dokumentacja.

[10] OpenAI. Skills. Instrukcje wielokrotnego użytku i pliki pomocnicze dla agenta. Oficjalna dokumentacja.