AI nie psuje kodu. W rękach architekta podnosi jego jakość

Popularna teza brzmi: asystenci AI zwiększają ilość kodu, ale obniżają jego jakość. Więcej duplikacji, mniej zrozumienia, więcej długu technicznego. Przy pracy prowadzonej przez osobę, która nie rozumie systemu, to prawdopodobnie prawda.

Nasza obserwacja z ponad roku pracy z agentami AI przy modernizacji dużej platformy SaaS jest inna. Dla doświadczonego architekta AI nie jest maszynką do pisania kodu. Jest sposobem, żeby wreszcie zrobić pracę, która zawsze była zbyt kosztowna.

Co się zmieniło

W każdym projekcie istnieje lista rzeczy, które „powinno się zrobić”: pełne testy, aktualna dokumentacja, refaktoryzacja modułu, którego wszyscy się boją, testy porównawcze przed migracją. Nie robi się ich nie dlatego, że architekt nie wie jak, tylko dlatego, że każda z nich to dni żmudnej pracy, które przegrywają z pilnymi funkcjami.

Agenci AI zmienili rachunek kosztów tej listy. Liczby z jednej modernizowanej usługi:

• testy automatyczne: od zera w połowie 2025 r. do ponad 200 jesienią 2026 r.,
• dokumentacja techniczna: od zera do 37 dokumentów, w tym plan modernizacji uwierzytelniania (ok. 1800 linii) i opis testów porównawczych starego i nowego systemu (podobnej długości),
• testy porównawcze legacy vs nowy system: rozliczenia, uwierzytelnianie, obsługa błędnych danych i wydajność sprawdzane automatycznie na wspólnej bazie przed przełączeniem ruchu,
• graf wiedzy o kodzie obejmujący sześć powiązanych repozytoriów — ponad 9 tys. węzłów i 12 tys. relacji, z których korzystają kolejne sesje pracy.

Żadna z tych rzeczy nie była wcześniej niemożliwa. Każda była po prostu zbyt droga.

Łatwiejsza akceptacja złożonych zmian

Druga zmiana jest mniej oczywista. Największym ryzykiem w modernizacji nie jest napisanie kodu, tylko przyjęcie dużej zmiany: czy rozumiemy wszystkie jej skutki? Agent, który przed zmianą generuje testy dla obecnego zachowania, a po zmianie pokazuje, które z nich się zmieniły i dlaczego, skraca przegląd z dni do godzin — i czyni go bardziej rzetelnym.

To odwraca typowy problem. Architekt nie unika już ambitnych zmian, bo ich weryfikacja przestała być wąskim gardłem.

Warunki, bez których to nie działa

Uczciwie: AI w rękach kogoś, kto nie rozumie systemu, produkuje dokładnie ten kod, przed którym ostrzega rynek. U nas działa to dzięki kilku zasadom:

1. Plik z zasadami projektu jako kontrakt. Każde repozytorium ma opis architektury, konwencji i zakazów, który agent czyta przed pracą. Każdy błąd agenta kończy się dopisaniem do tego pliku nowej zasady, więc ten sam błąd nie powtarza się w kolejnych sesjach — podobnie jak nowy członek zespołu uczy się na uwagach z code review.
2. Testy przed zmianą. Zanim agent zmieni zachowanie, najpierw opisuje obecne testami.
3. Przegląd przez człowieka. Każdy commit przechodzi przez osobę, która rozumie system. Commity tworzone z udziałem AI są oznaczone.
4. Procedury zamiast improwizacji. Powtarzalne zadania — wdrożenie nowej wersji, ocena ryzyka aktualizacji, uruchomienie procesu — są spisane jako procedury, z których agent korzysta krok po kroku.

Czego nie twierdzimy

Nie twierdzimy, że AI zwiększa liczbę commitów — w części repozytoriów jej nie zwiększyło. Nie twierdzimy też, że zastępuje doświadczenie. Twierdzimy, że zmienia, co opłaca się zrobić. A rzeczy, które nagle zaczęły się opłacać — testy, dokumentacja, weryfikacja — to dokładnie te, które decydują o jakości.

Przykład z tego samego projektu: silnik BPM wpięty w istniejący CRM — 19 commitów, z czego 17 powstało we współpracy z agentem AI, cztery dni do produkcji, z testami od pierwszego dnia.