Czy architektura ma znaczenie,
gdy kod pisze AI?

Najpierw warunki porównania

Dwa pytania. Dwie osobne próby

W pierwszej próbie sprawdzałem, czy sposób podziału systemu zmienia wynik pracy GitHub Copilot. W drugiej interesowało mnie, jak przy jednej architekturze zachowują się różne konfiguracje narzędzia oraz modelu.

Każda próba ma własny zakres. Zestawiam wyniki wewnątrz próby. Kosztów oraz czasu nie porównuję bezpośrednio między tymi dwoma eksperymentami.

Eksperyment 01

Najkrótszy czas nie dał najlepszego wyniku

Przygotowałem ten sam zakres: 14 epików oraz 151 zadań. Zadania były automatycznie przypisywane do agenta. Proces tworzył pull requesty oraz je scalał. Zmieniała się struktura rozwiązania.

Modularny monolit miał wyznaczone granice modułów oraz ich odpowiedzialności. N-Layer porządkował kod w warstwach. W wariancie YOLO nie narzuciłem tych granic. Agent sam wybierał strukturę. To nadal była jakaś architektura, tyle że decyzję o niej zostawiłem agentowi.

YOLO skończyło pracę w 43 godziny 30 minut. N-Layer potrzebował 51 godzin 32 minut. Wariant bez narzuconych granic był więc około 16% szybszy oraz 14% tańszy od N-Layer. Gdy sprawdziłem zachowanie systemu w 40 scenariuszach przygotowanych z pomocą ChatGPT, wynik YOLO był jednak najniższy.

N-Layer miał też najniższą gęstość problemów jakości zgłoszonych przez Sonar: 11,66 na 1000 linii kodu. YOLO miało 30,61, czyli około 2,6 razy więcej. W skanie Snyk wariant YOLO miał sześć zgłoszeń high oraz dwa medium. Pozostałe warianty miały wyłącznie zgłoszenia medium.

Modularny monolit wymagał najwięcej czasu oraz najwyższego zarejestrowanego kosztu. Miał jednak najniższą maksymalną złożoność według NDepend: 24 wobec 39 dla N-Layer oraz 56 dla YOLO. Z kolei YOLO miało najniższy raportowany dług techniczny: 0,90% wobec około 1,5% w pozostałych wariantach. Repozytoria różniły się rozmiarem. Jedna korzystna metryka nie opisuje całego rozwiązania.

Różnice procentowe obliczyłem na podstawie czasu oraz kosztu z tabeli. W tym eksperymencie N-Layer był najbardziej przekonującym kompromisem. Ta próba nie ustala najlepszej architektury dla każdego systemu.

Eksperyment 02

Ten sam podział systemu. Trzy konfiguracje

W drugiej próbie zostawiłem N-Layer. Każda konfiguracja wykonywała kolejno 133 zadania przy tym samym zakresie technicznym oraz tych samych instrukcjach, w tym pliku AGENT.md. Każda utworzyła 133 pull requesty.

W porównaniu z Codex oraz GPT-5.1-Codex-Max konfiguracja Copilot z Sonnet 4.6 potrzebowała około 16% mniej czasu. Jej zarejestrowany koszt był około 29% niższy. Claude z Haiku 4.5 miał najniższy koszt godziny pracy, ale pracował najdłużej. Dlatego cena godziny sama nie wystarcza do oceny całego zadania.

Claude z Haiku 4.5 miał najmniej problemów jakości Sonar w przeliczeniu na 1000 linii kodu. Jednocześnie miał najwyższą wartość zbiorczego wskaźnika Snyk „All”. Codex miał najniższą wartość tego wskaźnika Snyk, ale najwyższą gęstość problemów utrzymywalności Sonar. Copilot miał najniższą gęstość zgłoszeń Bug w Sonar. To różne sygnały, których nie składam w jedną ocenę.

Dla wskaźnika Snyk „All” materiał nie podaje jednostki. Zachowuję wartości ze źródła. Nie opisuję ich jako liczby podatności ani liczby zgłoszeń na 1000 linii. Wiersz Sonar Vulnerability pokazuje liczbę zgłoszeń, a pozostałe wskazane wiersze Sonar pokazują gęstość.

Moja interpretacja

Metryka ma pomóc w decyzji

Dla mnie te wyniki pokazują, dlaczego przed uruchomieniem agenta warto ustalić granice rozwiązania oraz sposób sprawdzenia wyniku. W próbie architektur różnice pojawiły się zarówno w metrykach kodu, jak też w zachowaniu systemu. Sam licznik wykonanych zadań tego nie pokazywał.

Nie wyciągam z tego zasady, że więcej modułów zawsze pomaga. Modularny monolit był najdroższy w tej próbie. Nie traktuję też mniejszej liczby linii kodu jako dowodu lepszego projektu. Mniej kodu może oznaczać prostsze rozwiązanie. Może również oznaczać pominiętą część zachowania. To trzeba sprawdzić.

Zanim policzę oszczędność na generowaniu kodu, chcę wiedzieć, które zachowanie systemu zostało sprawdzone.

Podobnie czytam wyniki skanerów. Zgłoszenia Sonar, Snyk oraz NDepend opisują różne właściwości kodu. Brak zgłoszeń w jednej kategorii nie oznacza, że cały system jest bezpieczny. Niższa gęstość zgłoszeń nie potwierdza też, że proces klienta działa prawidłowo.

Do zastosowania w projekcie

Jak przygotowałbym własną próbę

Zacząłbym od procesu, za który ktoś w firmie odpowiada. Jeżeli rozwiązanie ma skrócić obsługę zamówienia, zapisuję obecny czas oraz oczekiwaną zmianę. Dopiero potem wybieram fragment pracy dla agenta. Wtedy mam punkt odniesienia dla kosztu.

To propozycja sposobu pracy, a nie dodatkowy wynik eksperymentu. Dopiero taki pomiar pozwoliłby mi oszacować, czy niższy koszt generowania kodu przekłada się na korzyść w konkretnym projekcie. W biznesie chcę wiedzieć, skąd bierze się ta korzyść oraz kto może ją potwierdzić.