Pod koniec stycznia 2026 zbudowałem kompletny CRM dla freelancerów. Laravel 11, Livewire 3, 22 zaimplementowane funkcjonalności - od Kanban board po REST API. Nie w sensie prototypu. Działający produkt z dashboardem, time trackingiem, pipeline'em sprzedaży i codziennym email briefingiem.
Cały development trwał kilka dni. Korzystałem z Ralph-TUI - narzędzia do orkiestracji agentów AI, które autonomicznie implementuje user stories jedna po drugiej.
W tym artykule opisuję jak to wyglądało od środka. Co faktycznie robi AI, gdzie się sprawdza, a gdzie trzeba było interweniować ręcznie.
Punkt wyjścia: PRD z 22 user stories
Zanim cokolwiek ruszyło, napisałem PRD (Product Requirements Document). 22 user stories z acceptance criteria. Każda opisuje jedną funkcjonalność:
- US-01: Dashboard z KPI
- US-02: CRUD klientów
- US-03: Pipeline Kanban z drag & drop
- ...aż do...
- US-22: Konfiguracja ustawień
PRD to wejście dla Ralph-TUI. Agent czyta user story, implementuje ją, uruchamia testy, commituje i przechodzi do następnej. Autonomicznie, bez mojego udziału.
To brzmi za dobrze żeby było prawdą. Częściowo jest.
Co poszło dobrze
Generowanie kodu CRUD
Większość funkcjonalności CRM to operacje CRUD: dodaj klienta, edytuj deal, usuń przypomnienie. AI radzi sobie z tym bez problemu. Model Eloquent, migracja, Livewire komponent, widok Blade - generowane poprawnie przy pierwszym podejściu.
22 user stories, z czego 15 to warianty CRUD. Te 15 wymagało minimalnej interwencji.
Livewire + Alpine.js interakcje
Kanban board z drag & drop? AI zaimplementowało go prawidłowo: Alpine.js do obsługi drag events, Livewire do aktualizacji backendu. Karty przesuwają się między kolumnami, stan zapisuje się w bazie. Bez manualnego debugowania JS.
Dokumentacja i testy
Każda user story miała wygenerowaną dokumentację i zestaw testów. Nie musiałem o to prosić - Ralph-TUI ma to wbudowane w workflow. Po każdej implementacji: test, commit, następna story.
REST API z Sanctum
Lead API do przyjmowania leadów z zewnętrznych formularzy. Autoryzacja przez tokeny, rate limiting, walidacja - wszystko standardowe dla Laravel Sanctum. AI wygenerowało endpoint, middleware, resource class i dokumentację API w jednym przebiegu.
Co poszło źle
MySQL strict mode
AI wygenerowało zapytania SQL z GROUP BY które działają na SQLite (domyślna baza w testach) ale nie na MySQL w trybie strict. Produkcja używa MySQL. Efekt: testy przechodzą, aplikacja rzuca błędy.
Fix był prosty (dodanie wszystkich kolumn do GROUP BY), ale AI go nie złapało bo testy przechodziły na SQLite.
Lekcja: testy muszą biec na tej samej bazie co produkcja.
Duplikaty w bazie
Przy imporcie danych testowych AI nie sprawdzało unikalności. Klient "Jan Kowalski" pojawił się 3 razy bo skrypt seedera uruchomił się wielokrotnie. Brak firstOrCreate w seederach.
Spójność stylów między stronami
Dashboard wyglądał inaczej niż lista klientów, a ta inaczej niż time tracking. Każda user story implementowała UI niezależnie - AI nie miało kontekstu wizualnego z poprzednich stron. Musiałem ręcznie ujednolicić: spacing, kolory przycisków, rozmiary nagłówków.
To chyba największa słabość AI-assisted development: brak pamięci wizualnej. AI widzi kod, nie widzi efektu w przeglądarce.
Morning briefing - edge case'y
Codzienny email z podsumowaniem: zaległe zadania, dzisiejsze spotkania, pipeline stats. AI zaimplementowało happy path. Problem: co gdy nie ma żadnych zaległych zadań? Email wysyłał pusty blok. Co gdy jest 50 zaległych? Email był nieczytelny. Edge case'y musiałem wyłapać ręcznie.
Co z tego wynika
AI-assisted development działa, ale nie w sposób "wrzuć PRD i idź na kawę". Realnie wyglądało to tak:
| Etap | Kto | Czas |
|---|---|---|
| Napisanie PRD (22 user stories) | Ja | 3-4h |
| Implementacja przez Ralph-TUI | AI (autonomicznie) | 10-12h |
| Code review + fixy | Ja | 4-5h |
| Ujednolicenie UI | Ja | 2-3h |
| Testy na MySQL + debugging | Ja | 2h |
Razem: kilka dni. Tradycyjnie ten sam projekt to 3-4 tygodnie solo.
Przyspieszenie nie bierze się z tego, że AI pisze kod szybciej. Bierze się z tego, że AI pisze 80% kodu poprawnie za pierwszym razem, a ja skupiam się na pozostałych 20% - edge case'ach, spójności wizualnej, production readiness.
Kiedy AI-assisted development ma sens
Sprawdza się:
- Aplikacje CRUD-heavy (CRM, ERP, dashboardy)
- Projekty z jasno zdefiniowanymi wymaganiami (PRD)
- Standardowe stacki (Laravel, Rails, Next.js) - AI ma dużo danych treningowych
- Solo developer lub mały zespół (AI zastępuje dodatkową parę rąk)
Nie sprawdza się:
- Projekty z nietypową architekturą (AI nie ma wzorców)
- UI/UX-critical (AI nie widzi efektu wizualnego)
- Systemy z dużą ilością integracji (każda ma swoje edge case'y)
- Legacy code refactoring (AI potrzebuje kontekstu którego nie ma)
Stack
| Warstwa | Technologia |
|---|---|
| Backend | PHP 8.4, Laravel 11 |
| Frontend | Livewire 3, Alpine.js, Tailwind CSS |
| Baza danych | MySQL/MariaDB |
| Infrastruktura | Docker, Docker Compose |
| AI Orchestration | Ralph-TUI |
| DomPDF | |
| API Auth | Laravel Sanctum |
Efekt końcowy
22 z 22 user stories zaimplementowane. Dashboard z KPI, pipeline Kanban, time tracking z raportami PDF, system przypomnień, morning briefing email, REST API do leadów.
Produkt działa. Czy użyłbym tego podejścia ponownie? Tak - dla następnego projektu z jasnym PRD i standardowym stackiem.
Buduję aplikacje webowe i systemy z agentami AI - więcej o tym na stronach backend development i agenci AI.
