Przerost formy nad treścią – jak AI i „dobre praktyki” zabijają prostotę kodu

Opublikowano przez

W ostatnich latach frontend i backend przeszedł prawdziwą rewolucję. Frameworki, wzorce projektowe, standardy, dependency injection, interfejsy, architektury warstwowe – wszystko to miało ułatwić nam życie. A jednak wielu programistów, w tym ja, zaczyna zadawać sobie pytanie:

Czy poziom skomplikowania, jaki sami tworzymy, nie prowadzi nas do absurdu?

Kod piękny, ale bezużyteczny

Wielokrotnie spotkałem się z sytuacją, w której AI (np. Claude) wygenerowało świetnie wyglądający kod. Interface’y, repozytoria, separacja odpowiedzialności, komentarze, testy jednostkowe – wszystko wygląda jak z książki o czystej architekturze.

Tyle że ten kod… nie działa.

Albo nie rozwiązuje problemu. Albo wymaga 40 plików do obsłużenia jednego żądania GET /wyniki z prostego API lotto. Całość mogłaby zostać napisana w 30 minut — a pochłania dziesiątki godzin przez samą strukturę.

AI i akademickie podejście do prostych problemów

AI dziś nie pisze kodu kontekstowo. Pisze kod zgodny ze „standardem”, który istnieje w próżni. Dla świata, nie dla Ciebie. Dla idealnego projektu, nie MVP. Kod jest zbyt generyczny, zbyt wzorcowy, zbyt abstrakcyjny.

Efekt? Jako programista zamiast rozwiązywać problem — debuguję łańcuch zależności stworzony przez AI, które nigdy nie uruchomiło tego kodu.

Czyli… wracamy do jQuery?

Nie o to chodzi. Chodzi o zdrowy pragmatyzm. jQuery jest symbolem prostoty — takiej, która dla wielu projektów nadal jest wystarczająca. Nie potrzebujesz SPA, Reacta, Reduxów, TypeScripta i DI, żeby pokazać listę produktów z API. Wystarczy fetch() i odrobina rozsądku.

To nie znaczy, że nie warto znać wzorców. Warto. Ale trzeba wiedzieć, kiedy z nich zrezygnować.

Złoty środek

  • Architektura powinna rosnąć z projektem. Nie odwrotnie.
  • DI, CQRS i interfejsy? Tylko jeśli masz więcej niż jedną implementację.
  • Frameworki? Tak, ale tylko jeśli problem naprawdę tego wymaga.
  • AI? Tak, ale w oparciu o własne zasady, nie gotowe „idealne” schematy.

Podsumowanie

Kod ma działać. Ma rozwiązywać problem. Ma być zrozumiały dla człowieka, który go jutro będzie utrzymywać. Jeśli coś można zrobić w 30 minut, nie komplikuj tego dla zasady.

Nie bój się iść pod prąd. Najlepszy kod to nie ten, który wygląda jak z podręcznika – tylko ten, który działa, jest czytelny i ma sens tu, gdzie naprawdę go potrzebujesz.

Powiązane wpisy:

Brak powiązanych wpisów.