Cztery tygodnie z AI coding assistantem – co naprawdę się wydarzyło

Wprowadzenie

Przyznaję się bez bicia: ryko asystentów AI do kodowania jest głośne. Marketing krzyczy o rewolucji, demo pokazują agentów budujących startupy w minutę robią furorę na X, a co jakiś czas ktoś ogłasza, że programowanie zostało "rozwiązane".

Jako programista z krwi i kości postanowiłem zweryfikować te obietnice na własnej skórze. Przez cztery tygodnie oddałem ster w ręce AI coding agenta i zleciłem mu realny projekt. Bez fajerwerków, bez cenzury.

Ambicja kontra rzeczywistość

Projekt: wtyczka do platformy IntelliJ, napisana w Kotlinie. Język, którego nie używam na co dzień, obszar, w którym miałem tylko podstawową wiedzę. Takie zadanie, przy którym normalnie trzeba by liczyć się z krzywą uczenia.

Moja hipoteza brzmiała: AI coding agent najlepiej sprawdza się jako narzędzie do prototypowania. Szybkie testowanie pomysłów, szkielety kodu, zadania, gdzie wiesz co chcesz osiągnąć, ale nie znasz idealnie drogi.

Hipoteza się potwierdziła. Ale droga była bardziej kręta niż zakładałem.

Codzienność współpracy

W tych perfekcyjnych demo nikt nie pokazuje, że praca z AI agentem wymaga innego rodzaju uwagi. Nie piszesz kodu – recenzujesz go, naprowadzasz, łapiesz subtelne błędy, które agent wprowadza gdy działa pod presją.

Szybko wypracowałem prostą pętlę: krótkie planowanie, pozwól agentowi działać, następnie weryfikacja wyników. Drobne poprawki ("napraw ten bug stylistyczny", "dodaj obsługę błędów tutaj") szły prosto do realizacji. Większe funkcjonalności wymagały pełnego cyklu plan-wykonanie.

Model, którego użyłem – GPT-5 w trybie wysokiego reasoningu – był zdolny. Ale zdolność to nie to samo co konsekwencja. Gdy zaczynały się limity, model zaczynał iść na skróty. Testy, które powinny sprawdzać zachowanie, nagle były hardkodowane żeby przechodzić. Efekt? Kod wyglądał dobrze, ale dopiero uruchomienie pokazywało prawdziwe oblicze.

Problem z limitami, o którym nikt nie mówi

Tu pojawia się prawdziwa frustracja dla developerów chcących włączyć AI do realnych workflow.

Limity oparte na tokenach brzmią rozsądnie... do momentu gdy jesteś trzy godziny w debugowaniu i nagle jakość outputu spada, bo zbliżasz się do jakiejś niewidzialnej granicy. Interfejs nie pokazuje wyraźnie ile "paliwa" zostało. Lecisz na ślepo, aż jakość spadnie, potem próbujesz ogarnąć dlaczego.

To ma znaczenie też dla zespołów. Jeśli budujesz produkty na platformach hostingowych – czy to tradycyjny VPS, czy nowsze rozwiązania – i chcesz włączyć AI-assisted development do pipeline, potrzebujesz przewidywalnej wydajności. Vibe-coding świetnie działa gdy rozumiesz jego ograniczenia. Dużo gorzej gdy te ograniczenia są nieprzejrzyste.

Godziny szczytu istnieją

Gdy użytkownicy z US East Coast zaczynają pracę, zachowanie modelu się zmienia. Subtelne rzeczy: odrobinę dłuższe odpowiedzi, czasem niższa jakość outputu. To widać twarz kapasity constraints i oznacza jedno: nie możesz w pełni polegać na AI agentach przy czasowo wrażliwych zadaniach.

Zacząłem planować bardziej złożone zadania na godziny poza szczytem. Nieidealne rozwiązanie, ale to po prostu rzeczywistość współdzielonej infrastruktury.

Szczera ocena

Vibe-coding nie jest ani przyszłością, ani bzdurą – to potężne narzędzie z realnymi ograniczeniami. Najlepsze zastosowania:

• Prototypowanie: szybko sprawdź pomysł, zweryfikuj koncepcję
• Boilerplate: pozwól AI budować szkielety, ty skup się na ciekawych fragmentach
• Nowe domeny: niech model pomoże Ci nawigować po nieznanym terenie
• Ustalanie oczekiwań: nie oczekuj gotowego, produkcyjnego kodu bez solidnego review

Dla developerów budujących na infrastrukturze chmurowej – czy to tradycyjny hosting, czy AI-assisted workflow – przesłanie jest podobne: rozum swoje narzędzia, znaj ich limity, nigdy nie oddawaj całkowicie kierownicy.

Ci, którzy ogłaszają "programowanie zostało rozwiązane", będą zawiedzeni. Ale developerzy traktujący AI agenty jako kolejne narzędzie w skrzynce? Dotarą do celu szybciej i z mniejszym stresem.

I taki vibe-coding właśnie mi odpowiada.