Monolit, który już dowiozłeś

Dowiozłem testy Playwright na dziewięciu systemach produkcyjnych. Dwa lata, około 3000 testów, wciąż działają.

Jestem też osobą, która jeden z tych zestawów zbudowała w monolit tak zaplątany, że dodanie jednego testu znaczyło przeczytać czterysta linii, żeby znaleźć gdzie mieszka jeden lokator.

Te same ręce. Obie historie. To jest wersja uczciwa i od niej zaczyna się ten odcinek.

God object to nie jest problem wzorca

God object to problem wzrostu.

Każda struktura testów degeneruje się tak samo, kiedy presja dowozu wyprzedza dyscyplinę. Page Object Model jest po prostu miejscem, gdzie większość z nas spotyka go pierwszy raz, bo POM jest domyślny, a po domyślne sięgasz, kiedy sprint się pali. Z tym wyborem nie ma nic złego. Entropia i tak przyjdzie po każdy wybór.

Przychodzi zawsze w tych samych czterech kształtach.

Klasa, która zaczęła jako wypełnij-formularz-i-wyślij, puchnie do pięćdziesięciu lokatorów i trzydziestu metod. Klasa po cichu zjadła cały feature.

Lokatory, logika biznesowa, asercje, pętle retry i zapomniany console.log dzielą jedną metodę. Kiedy to pada, nie wiesz który z pięciu obowiązków padł, bo to ta sama linia.

Chcesz pół flow. Wypełnij formularz, ale nie wysyłaj. Struktura nie daje czystego szwu, więc albo eksponujesz wnętrzności, albo kopiujesz metodę. Jedno i drugie gnije dalej.

Zmienia się selektor, więc grepujesz. Zmienia się reguła biznesowa, grepujesz mocniej. Zmieniają się oba w jednym tygodniu i wypuszczasz regresję, bo rozdwojona jaźń pozwoliła poprawić jedną połowę i przeoczyć drugą.

Nic z tego nie jest egzotyczne. Jeśli dowoziłeś testy na skali, przeżyłeś co najmniej dwa z tych punktów. Ja przeżyłem wszystkie cztery, w jednym repo, w jednym kwartale.

Dlaczego w 2026 to waży więcej

Oto co się zmieniło.

Zanim wycelujesz agenta AI w swój zestaw testów, architektura musi się trzymać sama. Agent nie przynosi dyscypliny. Przynosi prędkość. Prędkość przyłożona do god-objectu daje większy god-object, szybciej. Ten sam zaplątany monolit, razy dziesięć, w jedno popołudnie.

Agent dobrze pisze syntax i boilerplate. Nie zdecyduje gdzie należy dany obowiązek, jeśli twój kod nigdy tego nie zdecydował. To nie jest ograniczenie AI. To ograniczenie kontekstu. Model nie ma stabilnego kontraktu, pod który mógłby pisać, więc zgaduje, a zgaduje w kształcie tego bałaganu, który dostał.

Kontekst najpierw. Determinizm najpierw. Architektura jest warunkiem, który decyduje, czy AI w QA cię przyspiesza, czy mnoży bałagan.

Więc pytanie się zmienia

Pytanie nie brzmi “który wzorzec jest poprawny”.

Pytanie brzmi, czy twoja struktura daje człowiekowi, albo modelowi, jedno oczywiste miejsce na każdą decyzję. Gdzie mieszka lokator. Gdzie mieszka flow. Gdzie mieszka asercja. Jeśli odpowiedź brzmi “zależy, przeczytaj klasę”, to nie masz architektury. Masz nawyk.

CDAT to jedna deterministyczna odpowiedź na to pytanie. Cztery pliki na feature, każdy z jednym zadaniem, jednokierunkowy graf zależności. Nudne celowo. Nudne jest dokładnie tym, co zmęczony człowiek o 18:00, albo agent o dowolnej godzinie, potrafi ogarnąć bez czytania czterystu linii.

Część 2 rozkłada to na czynniki. Cztery warstwy, kontrakty między nimi, i ten sam test logowania napisany dwa razy, żebyś zobaczył szew.

From the Field to jest to, co realnie buduję, co się psuje i czego się uczę. Realne projekty, realne liczby, realne bugi. Bez tutoriali.