Stan na marzec 2026
Przez ostatnie miesiące bardzo mocno pogrążyłem się w modelach językowych (jak pewnie każdy). Najpierw używałem ich do drobnych rzeczy: poprawienia komponentu, dopisania testów, przygotowania refaktoru, odnalezienia miejsca w repo. Potem przyszła naturalna chęć po więcej. Skoro AI potrafi zrobić mały kawałek kodu, to może dowiezie cały widok. Skoro dowiezie widok, to może cały przepływ biznesowy. A skoro przepływ, to może całą funkcjonalność od A do Z jednym promptem.
I właśnie o tej ścianie chcę napisać. Nie z pozycji sceptyka, który AI nie używa. Albo działu sprzedaży, który wygenerował prostego CRM-a. Wręcz przeciwnie. Piszę to jako ktoś, kto używa go codziennie i kto naprawdę dał się porwać temu, jak bardzo te narzędzia przyspieszyły pracę.
Na co dzień pracuję jako Head of Front-end Dev przy projekcie Sinum w Tech Sterowniki - polskiego systemu smart home. Pracujemy w monorepo, które ma 50 paczek i około 800 tysięcy linii kodu - nie licząc kodu wygenerowanego (np. typy z Swaggera). To nie jest MVP, a dość zaawansowane struktury, nad którymi codziennie czuwa 10 developerów (pozdro, jak to czytacie). Od początku 2025 roku coraz intensywniej korzystam z Cursora do generowania i analizowania kodu, a dzisiaj, w marcu 2026, mam już dość klarowny obraz tego, gdzie AI realnie dowozi, a gdzie kończy się marketingowy hype.
Rok 2025 naprawdę zmienił wszystko
Końcówka 2024 była dla mnie etapem side-projectów, które ostatecznie porzucałem. Nie dlatego, że brakowało mi pomysłów, tylko dlatego, że generowanie kodu jeszcze wtedy nie było wystarczająco dojrzałe, a ja nie miałem czasu ręcznie prostować każdej ścieżki. Jednak w 2025 poczułem mega duży skok jakościowy.
Przełomowym momentem był dla mnie maj 2025. Wtedy OpenAI pokazało Codex jako chmurowego agenta software engineering. Dla mnie ważne było nie samo „pisanie kodu”, ale to, że agent potrafił działać w odizolowanym środowisku, edytować pliki, uruchamiać komendy, odpalać testy, lintery i type checkery. W tym samym czasie Cursor bardzo dojrzewał: jego Tab sugerował już większe edycje i „jumps”, agent korzystał z narzędzi do przeszukiwania repo, edycji plików i terminala, a workflow wzbogacały reguły projektowe oraz integracje przez MCP. To był moment, w którym AI przestało być dla mnie „sprytnym autouzupełnianiem”, a zaczęło przypominać realnego operatora w repozytorium.
Przez wiele miesięcy eksperymentowałem z praktykami, które w 2025 były świeże i ekscytujące: MCP, dokumentami z instrukcjami dla agentów, regułami projektowymi, coraz lepszym Tabem i kolejnymi wariantami trybu agentowego. To bardzo łatwo budowało entuzjazm. Bo szczerze mówiąc: było czym się zachłysnąć.
Im większe zaufanie, tym boleśniejsze zderzenie
Mój problem zaczął się dokładnie tam, gdzie zaczął rosnąć mój poziom zaufania. Skoro AI dowoziło małe i średnie zadania, zacząłem oczekiwać, że dowiezie również bardzo duże funkcjonalności. Coraz częściej łapałem się na tym, że wpisuję coś w stylu: „zrób to od A do Z”, a potem czekam na gotowy rezultat.
I właśnie wtedy dotarłem do ściany.
W naszym repozytorium żaden agent nie radzi sobie dobrze z pełnym kontekstem i złożonością paczek. Problemem nie jest wyłącznie liczba linii kodu. Problemem są zależności, historia systemu, abstrakcje na poziomie typów, struktury danych, mnogość urządzeń i ich ustawień oraz logika dzielona między aplikacjami na dwóch platformach. Dodatkowo dochodzi do tego znajomość domeny biznesowej i realia naszego biznesu. Dla człowieka to jest trudne, ale uchwytne. Dla agenta to często jest po prostu za szeroki obraz.
Efekt? Kod wygenerowany po poleceniu „zrób to od A do Z” prawie zawsze popełniał jakiś błąd i - co gorsza - brnął w niego z pełnym przekonaniem. Agent tworzył utilsy, które już gdzieś mieliśmy. Tworzył nowe serwisy w TanStack. Odtwarzał patterny, które w naszym kodzie już istnieją. Omijał istniejące abstrakcje i budował własne minirozwiązania obok systemu, zamiast w systemie.
Najgorsze w tym wszystkim nie jest nawet to, że AI się myli. Najgorsze jest to, że myli się drogo. Bo kiedy agent wygeneruje dużo kodu naraz, ktoś ten kod potem musi przeczytać. I to nie pobieżnie. Trzeba go zrozumieć, prześledzić, zdebugować, porównać z istniejącą architekturą. W pewnym momencie zorientowałem się, że irytuje mnie czytanie i naprawianie takiego kodu bardziej niż napisanie go samemu od początku.
POC działa. Produkcyjny kod - już niekoniecznie
Tu jest bardzo zdradliwa pułapka. Gdy chcę szybko zbudować POC, bardzo łatwo wpaść w tryb: „nie będę teraz czytał kodu, zobaczę tylko, czy to działa w UI”. I uczciwie: do tego AI nadaje się świetnie.
Potrafi błyskawicznie postawić ekran, złożyć przepływ, spiąć kilka interakcji i dać coś, co na pierwszy rzut oka wygląda bardzo dobrze. Problem w tym, że ten kod w ogromnej liczbie przypadków jest później do wyrzucenia. Nie obejmuje wszystkich brzegowych scenariuszy. Nie uwzględnia ograniczeń domenowych. Nie pamięta o tych „nudnych” szczegółach, o których doświadczony programista pamięta odruchowo, bo wie, gdzie system lubi pękać.
Dlatego dziś patrzę na POC wygenerowane przez AI trochę jak na bardzo szybki szkic. Świetny do myślenia, kiepski jako finalny materiał konstrukcyjny.
Są też „głupie dni” modeli
Mam też swoją małą teorię spiskową (to oczywiście żart): gdzieś u dostawców modeli istnieje pokrętło z napisem „intelligence”, i czasem ktoś po prostu skręca je w lewo.
Są dni, kiedy agent jest błyskotliwy. Trafia w intencję, dobrze rozumie kontekst, nie trzeba go prowadzić za rękę. Ale są też dni, kiedy ten sam styl pracy nagle przestaje działać. Model zaczyna wymyślać rzeczy, ignoruje ważne założenia, ignoruje oczywiste wskazówki albo wpada w dziwne pętle rozumowania. W praktyce nauczyło mnie to jednego: przełączanie modeli nie jest dziś kaprysem, tylko normalnym elementem workflow. Cursor wspiera modele wielu dostawców i pozwala zmieniać je z poziomu selektora modelu, więc ratowanie się innym modelem stało się po prostu częścią codziennej pracy. Domyślam się, że to kwestia obciążenia danych modeli w danym czasie.
Inżynier wciąż potrzebny
Na tej podstawie mam też dość mocny wniosek: osoba bez wiedzy technicznej nie jest dziś w stanie długofalowo prowadzić projektu informatycznego wyłącznie dzięki AI.
Tak, da się wygenerować prostą stronę. Da się postawić prosty CRUD. Da się zrobić formularz do zapisu klientów, panel, dashboard, prostą logikę biznesową. I to naprawdę działa super. Problem pojawia się chwilę później, kiedy po pierwszym sukcesie naturalnie rośnie apetyt. Dochodzą kolejne funkcje, wyjątki, integracje, role użytkowników, migracje, ograniczenia wydajnościowe, niuanse domeny biznesowej. Wtedy cały ten „łatwy” system przestaje być łatwy.
Bez zmysłu architektonicznego taki codebase zaczyna bardzo szybko zmierzać w stronę spaghetti. I tu widać jedną z największych słabości obecnych modeli: one bardzo rzadko się cofają. Kiedy popełnią błąd projektowy, rzadko wracają do źródła problemu i porządnie go naprawiają. Zamiast tego dokładają kolejne if-y, dodatkowe warunki i kolejne warstwy zabezpieczeń. Często zabezpieczają też przypadki irracjonalne, które w praktyce wcale nie występują. Efekt jest taki, że kod robi się coraz bardziej skomplikowany, coraz mniej czytelny i coraz trudniejszy w utrzymaniu.
Ktoś nadal musi umieć powiedzieć: tę abstrakcję trzeba wyrzucić, ten kierunek był zły, ten moduł trzeba uprościć, a nie obudowywać łatami. I właśnie dlatego nie kupuję narracji, że „nietechniczni przejmą IT”. Mogą bardzo szybko zbudować coś prostego. Ale bez wiedzy technicznej bardzo szybko dobudują do tego chaos.
Gdzie AI naprawdę dowozi
Żeby było jasne: to nie jest tekst przeciwko AI. Moja dzisiejsza praca jest w ogromnej mierze budowana z pomocą AI i to działa naprawdę dobrze.
Jest jednak jeden haczyk: ja nad tym panuję. Znam stack. Rozumiem architekturę. Wiem, co chcę osiągnąć. Potrafię wydawać polecenia bardzo konkretnie, potrafię szybko wyłapać, kiedy agent odjeżdża, i wiem, kiedy trzeba go zatrzymać, zawęzić kontekst albo wrócić do prostszego kroku. Na małym, kontrolowanym stacku AI radzi sobie doskonale. W takim środowisku jest znakomitym wykonawcą: szybkim, cierpliwym i bardzo produktywnym.
Oczywiście, nie znaczy to, że nie popełniam błędów. Popełniam. Ale skala projektu i poziom kontroli są zupełnie inne niż w dużym, żyjącym monorepo enterprise.
Mój wniosek na marzec 2026
Na dziś nie wierzę w mit „jednego promptu” dla dużych, złożonych funkcjonalności w projekcie enterprise. Nie w takim środowisku jak nasze. Nie przy takim poziomie złożoności domeny. Nie przy takim ciężarze architektury i istniejących zależności.
Wierzę za to bardzo mocno w AI jako asystenta. Wierzę w AI do refaktoryzacji. Do zadawania pytań o kod. Do szybkiego budowania POC. Do iteracyjnego posuwania się naprzód małymi krokami. Do przygotowania pierwszej wersji rozwiązania, którą człowiek potem świadomie prowadzi dalej. Nie wierzę w out-of-the-box produkt dowieziony jednym poleceniem. Wierzę w dobrze poprowadzony dialog, w zawężanie zakresu, w precyzję i w cierpliwe dochodzenie do celu.
Najkrócej mówiąc, AI nie zastępuje wiedzy domenowej i inżynierskiego fachu. Ono tylko zmienia tempo pracy. Dobry programista dzięki niemu staje się szybszy. Słaby - szybciej produkuje bałagan.
I chyba właśnie to jest najuczciwsze podsumowanie stanu na marzec 2026: AI już potrafi pisać dużo kodu. Nadal nie potrafi wziąć odpowiedzialności za architekturę. To wciąż rola człowieka.
