Kiedy rozmawiam z innymi deweloperami o AI, prawie zawsze rozmowa schodzi na to samo: „kod tworzony przez AI". „Wpisałem prompta, odpaliłem agenta i dostałem komponent." — to działa, nie ma wątpliwości. Ale pisanie kodu to tylko część całego procesu wytwarzania oprogramowania, warto mieć świadomość, że AI może nam pomóc również w trakcie pozostałych etapów.

Zbieranie wymagań, dokumentacja, planowanie, testowanie, utrzymanie. Rzeczy, które zabierają mnóstwo czasu, a o których w kontekście AI prawie nikt nie mówi. Poniżej opisuję 7 obszarów, w których AI realnie zmienił sposób, w jaki pracuję. Bez marketingowej ściemy - tylko to, czego faktycznie używam.

1. Zbieranie wymagań - pytania, o których zapomniałbym sam

Każdy projekt zaczyna się od rozmowy z klientem. Problem w tym, że klient często sam nie wie, czego dokładnie potrzebuje - i to jest normalne. Gorzej, gdy ja zapomnę o czymś zapytać.

Dlatego przed spotkaniem wrzucam do AI kontekst: branża klienta, wstępny brief, notatki z wcześniejszych rozmów. W odpowiedzi dostaję listę pytań, które warto zadać - w tym takie, na które sam bym nie wpadł.

Jedna pominięta funkcjonalność na etapie zbierania wymagań może łatwo przeistoczyć się w duże wymaganie w trakcie trwania projektu. AI nie eliminuje tego ryzyka, ale mocno je ogranicza.

2. Dokumentacja - pierwszy czytelnik, który nigdy nie jest zmęczony

Pisanie dokumentacji to coś, co wszyscy uważają za ważne i nikt nie lubi robić. Ja też nie. Ale odkąd używam AI jako pierwszego recenzenta, proces wygląda inaczej.

Piszę szkic dokumentu - może niezbyt dopracowany, ale z pełną informacją. AI go czyta i robi coś, na co człowiek po 40 stronach specyfikacji zwykle nie ma już siły: wychwytuje niespójności. „W sekcji 3 piszesz, że użytkownik może anulować zamówienie do 24h, ale w sekcji 7 — do 48h. Który wariant jest poprawny?"

Takie rzeczy potrafią wyjść na jaw dopiero w trakcie developmentu, kiedy koszt poprawki jest wielokrotnie wyższy. AI wyłapuje je na etapie definiowania wymagań.

3. Definiowanie zadań - jakość ma znaczenie

Źle opisane zadanie potrafi zablokować dewelopera, bo brakuje kontekstu, edge case’a albo odniesienia do innego modułu. Znam to z autopsji.

Teraz po spisaniu zadania odpalam AI z promptem, który zawiera: treść taska, powiązaną dokumentację i aktualny stan kodu. AI weryfikuje, czy:

  • nie brakuje kryteriów akceptacji,
  • zadanie nie koliduje z innym otwartym taskiem,
  • wszystkie zależności są uwzględnione.

Efekt jest prosty - jakość opisu zadań jest znacznie wyższa, co przydaje się podczas pracy nad implementacją kodu.

Dodatkowym atutem dobrze zdefiniowanych zadań jest to, że mogą być dobrze wykorzystane przez samo AI do opracowania potrzebnych zmian w kodzie.

4. Zarządzanie backlogiem - porządek, który robi się “sam”

Im dłużej trwa projekt, tym bardziej backlog staje się cmentarzyskiem dobrych intencji. 120 zadań, z czego 30 zdublowanych, 15 nieaktualnych, a priorytety ostatnio aktualizowane „w zeszłym sprincie”.

Zacząłem wyciągać backlog do AI i prosić o analizę: co się powtarza, co blokuje co, jakie zadania straciły sens po ostatnich zmianach w wymaganiach. To nie jest Scrum Master - ale robi robotę porządkową, na którą w codziennym sprincie zwyczajnie brakuje czasu. Dostaję raport z rekomendacjami, a decyzje i tak podejmuję sam.

5. Praca z kodem - dobrze zdefiniowane wymagania, review

Tu wszyscy wiedzą, o co chodzi, więc nie będę udawał odkrywcy. Ale jedna rzecz zasługuje na podkreślenie: AI potrzebuje dobrze zdefiniowanych wymagań, aby działać skutecznie. W praktyce wygląda to bardziej jak pair programming — seria iteracji i review z AI, zanim finalnie dostanie zielone światło do implementacji zmian.

6. Testowanie - scenariusze, których sam bym nie napisał

Testy to obszar, w którym AI zaskakuje mnie najczęściej. Nie chodzi o generowanie prostych unit testów - to potrafi każde IDE z Copilotem.

Chodzi o to, że AI, mając dostęp do wymagań i kodu jednocześnie, potrafi zaproponować scenariusze testowe, o których nie pomyślałem. W jednym z ostatnich projektów wygenerował test na sytuację, w której użytkownik zmienia język interfejsu w trakcie wypełniania formularza wieloetapowego. Nikt tego nie ujął w wymaganiach. A bug by się pojawił.

Nie ufam tym testom ślepo - każdy przeglądam i często modyfikuję. Ale jako punkt wyjścia? Bezcenne.

7. Monitoring i utrzymanie - kompleksowe informacje na temat błędu

Po wdrożeniu zaczyna się etap, który większość deweloperów traktuje jak zło konieczne. Logi, alerty, „czemu ten endpoint zwraca 500 o 3:17 w nocy".

Odpowiednio skonfigurowany AI, monitoruje logi produkcyjne i automatycznie analizuje anomalie. Kiedy wykryje wzrost błędów, zbiera kontekst: stacktrace, ostatnie zmiany w kodzie, powiązane endpointy - i generuje wstępną diagnozę. Dostaję notyfikację z podsumowaniem, a nie z surowym logiem.

Czy to zastępuje klasyczny monitoring? Oczywiście że nie. Ale dodaje warstwę interpretacji, drugą parę oczu, która skraca czas reakcji i oprócz samego komunikatu o błędzie dostarcza kontekst potrzebny do diagnozy.

Na koniec

Żaden z tych punktów nie jest rewolucją sam w sobie. AI nie zastąpiło myślenia, podejmowania decyzji ani odpowiedzialności za kod. Ale zabrało mnóstwo powtarzalnej, żmudnej roboty - i dzięki temu mam więcej czasu na to, co naprawdę wymaga ludzkiej głowy.

Jeśli chcesz porozmawiać o tym, jak AI może realnie odciążyć Twój zespół deweloperski - sprawdź w czym mogę pomóc albo odezwij się. Chętnie podzielę się doświadczeniem przy kawie (albo callu).