Czy potrzebujesz AI, czy wystarczy prosty skrypt?

Zacznij od charakteru zadania, nie od nazwy narzędzia

Najpierw ustal, czy wynik ma być zawsze taki sam dla tych samych danych, czy trzeba interpretować język, obraz albo niepełny kontekst. Reguła typu „jeśli faktura ma status opłacona, przenieś ją do archiwum” nie potrzebuje modelu językowego. Klasyfikowanie niejednoznacznych wiadomości albo wydobywanie informacji z różnie napisanych dokumentów może już uzasadniać AI.

Drugie pytanie dotyczy konsekwencji błędu. Inaczej projektuje się narzędzie, które przygotowuje propozycję do zatwierdzenia, a inaczej mechanizm, który automatycznie wysyła pieniądze, usuwa dane albo zmienia status klienta. Im droższa pomyłka, tym ważniejsze są deterministyczność, logi i możliwość cofnięcia.

To nie jest zasada, że prostsze rozwiązanie zawsze wygrywa. To praktyczna heurystyka: im bardziej przewidywalne są dane i im łatwiej odwrócić skutek, tym mniej powodów, żeby zaczynać od modelu. Gdy wejście jest niejednoznaczne, a błąd kosztowny, potrzebujesz nie tylko AI, ale również procesu oceny wyniku.

Eurostat podał, że w 2025 roku AI wykorzystywało 19,95% badanych przedsiębiorstw w UE i 8,36% w Polsce. To dane dla przedsiębiorstw objętych badaniem, a nie dla wszystkich firm ani dowód jakości wdrożeń. Pokazują jednak, że AI nie jest jeszcze domyślnym elementem każdego procesu — warto najpierw znaleźć konkretne zastosowanie.

• Czy wejście jest ustrukturyzowane i można opisać je regułami?
• Czy wynik musi być identyczny i powtarzalny?
• Czy człowiek może zatwierdzić wynik przed skutkiem?
• Czy błąd jest odwracalny, czy zmienia dane albo relację z klientem?

Cron i prosty skrypt nadal są dobrym rozwiązaniem

Skrypt uruchamiany raz dziennie, webhook po zmianie rekordu albo mała usługa synchronizująca dwa systemy nie brzmią tak efektownie jak agent, ale często dokładnie odpowiadają na problem. Ich działanie łatwiej opisać, przetestować i przekazać kolejnej osobie. W tym kontekście traktuję prostotę jako element bezpieczeństwa dopiero wtedy, gdy proces ma logi, blokadę przed podwójnym uruchomieniem, timeout, retry lub alert oraz sposób ręcznego uruchomienia i wycofania.

AI może pomóc taki skrypt napisać, wyjaśnić albo rozbudować o obsługę wyjątków. Nie musi jednak być częścią samego procesu. Oddzielenie „AI pomogła przygotować kod” od „AI decyduje w działającym systemie” pozwala korzystać z nowego narzędzia bez dokładania zmienności tam, gdzie nie jest potrzebna.

SaaS, API czy własna integracja?

SaaS zwykle skraca start przy standardowym problemie, API daje większą kontrolę kosztem integracji, a własny kod może uzasadniać się specyficznym procesem lub danymi. To heurystyka architektoniczna, nie reguła wynikająca z jednego badania. Eurostat podał, że w 2025 roku płatnych usług chmurowych używało 52,7% badanych przedsiębiorstw w UE — korzystanie z gotowych usług jest normalną decyzją techniczną, nie brakiem ambicji.

Porównaj każdą opcję przez horyzont odpowiadający planowanemu życiu rozwiązania; jako praktyczny arkusz można przyjąć 24–36 miesięcy, ale nie jest to uniwersalny próg. Uwzględnij abonament, limity, eksport danych, zmianę dostawcy, uprawnienia, integracje, ręczną pracę, monitoring i osobę odpowiedzialną za utrzymanie. Własna integracja może być najlepsza, ale nie wtedy, gdy jej jedyną przewagą jest to, że można ją napisać od zera.

Koszt automatyzacji to także koszt złego wyniku

Nie licz tylko tokenów, abonamentu albo czasu napisania pierwszej wersji. Dodaj testowanie jakości, ponowienia, wyjątki, ręczną weryfikację, monitoring, zmianę dostawcy i sytuację, w której trzeba wyjaśnić klientowi, dlaczego system podjął złą decyzję. W raporcie DORA 2025, opartym na odpowiedziach prawie 5 tysięcy profesjonalistów, 90% deklarowało używanie AI, ponad 80% uważało, że zwiększa ich produktywność, ale 30% miało małe lub żadne zaufanie do kodu AI. DORA opisał dodatni związek adopcji AI z przepustowością dostarczania i wydajnością produktu oraz ujemny związek ze stabilnością dostarczania; nie jest to dowód, że samo AI powoduje awarie.

Zacznij od jednej rzeczywistej operacji i zmierz cały przebieg: przygotowanie danych, wywołanie, sprawdzenie, zapisanie i ewentualną korektę. W randomizowanym eksperymencie METR z początku 2025 roku 16 doświadczonych developerów wykonało 246 zadań w dużych repozytoriach open source; zadania z dozwolonym użyciem AI zajęły średnio o 19% więcej czasu, z przedziałem niepewności od 2% do 39%. To wąski wynik dla konkretnego typu pracy, nie uniwersalna kara ani obietnica oszczędności. Tym bardziej warto mierzyć własny proces.

Najpierw mały test, potem decyzja o architekturze

Nie musisz rozstrzygać od razu, czy powstanie własny system. Przygotuj małą próbkę danych, porównaj prostą regułę z API albo modelem i zapisz, co jest dla Ciebie ważniejsze: dokładność, szybkość, koszt, kontrola danych czy łatwość przekazania. Taki test ujawnia również, czy problem jest w ogóle wystarczająco częsty.

Warto poprosić o kontrapunkt, gdy narzędzie jest wybierane głównie dlatego, że jest modne albo poleca je asystent. W ankiecie Stack Overflow Developer Survey 2025 46% respondentów deklarowało brak zaufania do dokładności AI, a 75% zwróciłoby się do człowieka, gdyby nie ufało odpowiedzi. To nie jest audyt jakości modeli, ale dobry opis praktycznej potrzeby: ktoś powinien zakwestionować założenia, zapytać, czy prostszy cron nie rozwiązuje sprawy lepiej, i ustalić, kto będzie odpowiadał za system za rok.