Jak zespół z agentami AI buduje aplikację dla firmy — role, bramki i co zostaje przy człowieku?

Co realnie powstaje, gdy przy aplikacji pracują agenci AI?

Powstaje kod, migracje bazy, testy i teksty — ale nie w jednym kotle, tylko w rozdzielonych rolach. W raporcie DORA ogłoszonym 23 września 2025 r. 90% respondentów deklarowało korzystanie z AI w pracy, a 30% — małe zaufanie albo brak zaufania do generowanego kodu.

Agent dobrze robi to, co ma wzorzec: pierwszą wersję ekranu z opisu, testy do istniejącej funkcji, migrację ze spisanego zakresu, przepisanie fragmentu według reguły, dokumentację tego, co już działa. Wynik przychodzi w minutach zamiast w godzinach.

Role są rozdzielone i na tym polega różnica: autor pisze, weryfikator sprawdza, redaktor decyduje, czy to wchodzi. Jedna maszyna, która sama siebie sprawdza i sama sobie stawia ocenę, nie jest procesem — jest opinią.

Dostawcy narzędzi mówią to samo wprost. Dokumentacja GitHuba o przeglądzie kodu przez Copilota: „Copilot nie gwarantuje, że wychwyci wszystkie problemy w zgłoszeniu zmian. Czasem popełnia błędy. Zawsze uważnie sprawdzaj jego uwagi. Uzupełnij je przeglądem człowieka” (tłumaczenie własne, odczyt 31 sierpnia 2026 r.).

Czego z agenta nie wyjmiesz: decyzji, co wchodzi do pierwszej wersji, kto ma widzieć który rekord i skąd bierze się informacja o wpłacie. Model odpowie na każde z tych pytań — tylko nikt nie poniesie za tę odpowiedź konsekwencji.

U nas pracuje to na kilkunastu aplikacjach i serwisach zbudowanych na tym samym stosie, w skali setek kont w pojedynczej aplikacji dla firm. Zespół pracuje z agentami AI pod nadzorem człowieka i stąd wiemy, gdzie leży granica.

Gdzie przebiega granica między agentem a człowiekiem?

Granica nie biegnie po trudności zadania, tylko po tym, kto poniesie skutek błędu. Ekran poprawia się w dziesięć minut. Źle ustawiona polityka dostępu oddaje cudze dane i nie zostawia po sobie żadnego śladu na ekranie.

Dlatego w każdym obszarze pytamy o dwie rzeczy: do jakiego progu wynik agenta wystarcza i co po tym progu musi zrobić człowiek. Tabela niżej jest tą granicą rozpisaną na warstwy, z których składa się aplikacja dla firmy.

Ostatni wiersz nie jest ozdobą. Obowiązki przejrzystości z aktu o sztucznej inteligencji stosuje się od 2 sierpnia 2026 r.; pozostałe terminy zebrał kalendarz w innym serwisie i tutaj ich nie powtarzamy.

Jeden przepis mówi wprost, co zostaje przy człowieku. Przy tekście publikowanym po to, by informować społeczeństwo o sprawach w interesie publicznym, obowiązek ujawnienia odpada między innymi wtedy, gdy treść przeszła weryfikację człowieka albo kontrolę redakcyjną i gdy odpowiedzialność redakcyjną ponosi osoba fizyczna lub prawna.

Ten tekst jest tego przykładem. Przygotował go agent AI, a pod artykułem stoi podpis wskazujący, kto odpowiada za fakty. To nie jest gest wobec czytelnika, tylko dokładnie ten warunek, o którym mówi przepis.

Bramki: co odrzuca maszyna, zanim spojrzy człowiek?

Bramka nie ocenia, czy funkcja jest dobra. Odrzuca to, co da się rozstrzygnąć regułą, żeby człowiek patrzył na resztę. U nas trzy bramki są maszynowe, a czwarta ludzka.

• Lint. Program czyta kod i treść według spisanych reguł: zakazane konstrukcje, brakujące pola, złamany format. Wynik jest zerojedynkowy i nie zależy od tego, kto akurat patrzy i w jakim jest nastroju.
• Testy. Ścieżki, na których błąd kosztuje pieniądze albo dane — logowanie, funkcja główna, płatność — przechodzą automatem przed wdrożeniem, a nie raz na kwartał przy okazji większej zmiany.
• Parytet. Sprawdzenie, czy dwa miejsca, które mają mówić to samo, faktycznie mówią to samo. Rozjazd między nimi to błąd, którego nie widać na żadnym ekranie, dopóki ktoś nie porówna obu.
• Przegląd innej roli. Wynik czyta ktoś, kto go nie pisał. To jedyna bramka, której nie da się zautomatyzować, i jedyna, która wyłapuje błąd sensu, a nie formy.

Zasada „autor nie zatwierdza sam siebie” jest dziś wpisana w narzędzia. Dokumentacja GitHuba o agencie chmurowym Copilota mówi, że agent nie może oznaczyć swojego zgłoszenia jako gotowego do przeglądu ani go zatwierdzić lub scalić.

Dalej: zgłoszenia od agenta muszą zostać przejrzane i scalone przez człowieka, a osoba, która zleciła agentowi pracę, nie może sama jej zatwierdzić. Domyślnie testy nie ruszą, dopóki ktoś z prawem zapisu nie kliknie zgody na ich uruchomienie.

Po stronie repozytorium ta sama zasada jest zwykłym ustawieniem: reguła wymaganych zatwierdzeń przyjmuje wartość od 0 do 10, a osobna reguła nie przepuszcza zmiany, dopóki wymagane testy nie przejdą (dokumentacja GitHuba, odczyt 31 sierpnia 2026 r.).

Po co to wszystko, skoro model pisze poprawny kod? Bo najczęściej pisze prawie poprawny. W badaniu Stack Overflow z 2025 roku najczęściej wskazywaną frustracją było „rozwiązanie prawie dobre, ale nie do końca” — 66% z 31 476 odpowiedzi.

„Prawie” jest tu gorsze niż „źle”. Kod, który się nie uruchamia, zatrzymuje się na pierwszej bramce maszynowej. Kod, który działa, ale w jednym warunku brzegowym oddaje cudze dane, przechodzi wszystko poza przeglądem człowieka.

Kiedy przepisać to, co wyszło spod agenta?

Sygnałów jest sześć i każdy znaczy to samo: proces skrócono w miejscu, w którym skracać go nie wolno. Żaden z nich nie dotyczy tego, jak dobry był model.

• Cykl zamknęła jedna rola. Ten sam agent napisał i zatwierdził. Nie ma znaczenia, jak dobry jest wynik — nie ma drugiego spojrzenia, więc nie ma na czym oprzeć zaufania.
• Warstwa uprawnień powstała przy okazji. Dokumentacja Supabase mówi wprost: tabela w odsłoniętym schemacie bez polityk dostępu jest do odczytu i zapisu dla każdej roli, która ma do niej uprawnienie.
• Płatność zalicza się z przekierowania. Bez weryfikacji podpisu powiadomienia ktoś obcy może wysłać fałszywe zdarzenie i wywołać realizację zamówienia albo nadanie dostępu — ostrzega przed tym dokumentacja Stripe.
• Nikt nie umie powiedzieć, dlaczego to działa. Kodu, którego nikt nie przeczytał, nikt też nie naprawi pod presją czasu. Awarie mają zwyczaj zdarzać się w piątek po południu.
• Migracja poszła na żywych danych bez próby odtworzenia kopii. Punkt odtworzenia i czas odtworzenia zapisuje się, zanim będą potrzebne. Po awarii nie ma czasu na ustalanie, ile danych wolno stracić.
• Integracja z cudzym systemem nie ma obsługi błędów. Cudze API zmienia się bez pytania. Agent pisze ścieżkę, która działa dziś; człowiek dopisuje, co ma się stać, gdy przestanie działać.

Przepisania wymaga zwykle warstwa decydująca o dostępie i o pieniądzach, a nie ekrany. Gdzie ta sama granica przebiega przy generatorach „vibe coding”, opisuje osobny tekst — razem z wynikami testów bezpieczeństwa.

Jak sprawdzić wykonawcę, który pracuje z AI — pięć pytań?

Każde z tych pytań ma odpowiedź sprawdzalną, a nie deklaratywną. Jeśli pada „mamy to pod kontrolą”, to znaczy, że odpowiedzi nie ma. Zadaj je przed podpisaniem umowy, nie po pierwszej awarii.

1. Kto podpisuje wynik i kto odpowiada za fakty? Ma paść imię i nazwisko albo nazwa firmy, nie słowo „zespół”. Odpowiedzialność, której nie da się przypisać konkretnej osobie, nie istnieje.
2. Jakie bramki maszynowe stoją między napisaniem a wdrożeniem? Poproś o ich nazwy i o pokazanie wyniku ostatniego przebiegu. Bramka, której wyniku nikt nigdy nie widział, nie jest bramką.
3. Czy sprawdza inna rola niż ta, która pisała? Jeśli tak — dopytaj, jak to jest wymuszone. Ustawienie w repozytorium jest odpowiedzią, dobra wola nie jest.
4. Czy w gotowej aplikacji widać, gdzie działa AI? Chodzi o funkcje, z którymi rozmawia użytkownik, i o treści, które aplikacja generuje. To wymóg prawa, nie kwestia stylu.
5. Kto odpowiada za uprawnienia, płatności i sekrety? Te trzy warstwy czyta człowiek zawsze, niezależnie od tego, kto napisał pierwszą wersję. Błąd w każdej z nich widać dopiero na produkcji.

Dwa rachunki należą do innych serwisów i tutaj ich nie robimy: czyj jest kod napisany przez AI oraz jak wyglądają limity kont w narzędziach agentowych.