AI SVG LLM Claude Code Cursor Gemini case study Reczniki Haftowane React Laravel

Jak zbudować z AI coś, czego nie ma w repozytoriach

AI nie zbuduje za ciebie czegoś czego nie rozumie. Najpierw musisz to zrozumieć sam — i zapisać w sposób który maszyna może przeczytać.

Kreator personalizacji zestawu ręczników haftowanych — podgląd na żywo

Jak zbudować z AI coś, czego nie ma w repozytoriach

Gotowych kreatorów personalizacji jest setki. Ale miałem wymaganie które wykraczało poza to, co można złożyć z gotowych klocków.

Zestaw ślubny: cztery ręczniki. Każdy osobno — inny wzór haftu, inne inicjały, inny kolor nici, inna czcionka. Wszystko widoczne na żywo, zanim kupujący kliknie "dodaj do koszyka". I to samo musi wygenerować się jako plik do produkcji.

Trzy systemy. Jeden wynik. Identyczny wszędzie.

AI tego nie zbudował od razu. Nie dlatego że nie umiał — dlatego że na początku nikt nie umiał mu tego precyzyjnie opisać.

Dlaczego AI utknął na początku

Pierwsze podejście było klasyczne. Opisałem problem, AI zaczął pisać kod. Trzy dni, dużo poprawek, coraz więcej chaosu.

Każdy wzór haftu ma sloty — miejsca gdzie może trafić tekst. Slot to nie jest "wpisz coś". Slot ma pozycję na ręczniku, rozmiar, limit znaków, czcionkę, kolor. Inny wzór — inne sloty, inne zasady.

Próbowałem to wytłumaczyć słowami. AI słuchał, generował kod, kod był — mglisty. Bo opis był mglisty.

Rozbiłem pracę na dwóch agentów: jeden dla frontendu, drugi dla backendu. Oba dostały ten sam opis. Oba powiedziały "rozumiem". Efekt? Dwa różne obrazy haftu.

AI robi dokładnie to, co dostanie. Nie domyśla się, nie zakłada. Jeśli opis jest niejednoznaczny — każdy agent zinterpretuje go inaczej.

Co zrobiłem zanim wróciłem do właściwego kodowania

Zatrzymałem się. Razem z AI napisałem narzędzie w Pythonie — ale tym razem z jasnym celem: nie pisać od razu kreator, tylko zbudować narzędzie do definiowania wzorów haftu.

Narzędzie pozwalało opisać każdy wzór: gdzie są sloty, jakie mają pozycje, limity, czcionki, kolory. Jedno źródło prawdy. Liczby, nie słowa.

Następnie kazałem AI wygenerować z tego narzędzia dokładną specyfikację — plik który opisuje każdy wzór w formacie który inne systemy mogą przeczytać bez interpretacji. Nie "gdzieś po środku, trochę większe". Tylko: pozycja X, pozycja Y, rozmiar, limit znaków.

Dopiero wtedy wróciłem do właściwego zadania.

Dałem frontendowi specyfikację i powiedziałem: "Zrób podgląd zgodnie z tym." Dałem backendowi tę samą specyfikację i powiedziałem: "Wygeneruj plik zgodnie z tym."

Za pierwszym razem oba systemy renderowały to samo w ~95%.

Główna lekcja

AI nie zastępuje myślenia. AI wykonuje myślenie które już zostało zrobione.

Zanim AI może napisać kod, ktoś musi:

  • Zrozumieć problem na tyle dobrze żeby go zapisać precyzyjnie
  • Zdecydować co jest źródłem prawdy i gdzie jest przechowywane
  • Przetłumaczyć wymagania na format który maszyna może przeczytać bez interpretacji

To jest praca przed AI. I to jest praca której AI za ciebie nie wykona — ale może ci w niej towarzyszyć, jeśli wiesz czego szukasz.

W tym projekcie ta praca zajęła więcej czasu niż samo kodowanie. Ale każda godzina spędzona na specyfikacji zaoszczędziła trzy godziny debugowania.

Jak to wygląda w praktyce

Trzy systemy musiały mówić jednym językiem:

Python — właściciel definicji. Tu opisujesz wzory i ich sloty. Stąd AI generuje specyfikację.

Frontend — czyta specyfikację i renderuje podgląd na żywo. Kupujący widzi każdy ręcznik osobno, zmienia co chce, efekt pojawia się natychmiast.

Backend — czyta tę samą specyfikację i generuje plik graficzny do produkcji. Identyczny z tym co widział kupujący.

Żaden z tych systemów nie interpretuje. Każdy implementuje. Różnica jest ogromna.

Kreator działa na reczniki-haftowane.pl.


Budujesz coś gdzie kilka systemów musi pokazywać to samo? Napisz — pomogę to poukładać zanim zaczniesz pisać kod.

Czytaj też