ChatGPT 5.1 dla programistów PHP i Laravel: kompletny przewodnik

Czym jest ChatGPT 5.1 i dlaczego ma znaczenie dla programistów PHP i Laravel 12?

Jeśli interesuje Cię ChatGPT 5.1 dla programistów PHP i Laravel, to znaczy, że chcesz mniej klepać boilerplate, a więcej rozwiązywać realne problemy biznesowe. ChatGPT 5.1 to nie tylko „kolejna wersja ChatGPT”, ale nowy model z rodziny GPT-5.1, który stał się domyślnym „mózgiem” ChatGPT: jest inteligentniejszy, lepiej się komunikuje i daje dużo większą kontrolę nad stylem odpowiedzi oraz głębokością rozumowania.

Dla Ciebie jako dev-a PHP/Laravel 12 oznacza to przede wszystkim: szybsze pisanie kodu, sensowniejsze podpowiedzi architektoniczne i lepszą współpracę przy debugowaniu złożonych problemów. Ale po kolei.

GPT-5.1 w skrócie – co to za model i gdzie go spotykasz?

Część rodziny GPT-5, ale z konkretnym upgrade’em

GPT-5.1 to iteracyjna aktualizacja rodziny GPT-5 – nie „rewolucja marketingowa”, tylko realne poprawki w inteligencji, sposobie komunikacji i personalizacji. W ChatGPT to właśnie GPT-5.1 jest używany jako główny model do rozmów, a w API występuje jako flagowy model dla zadań wymagających rozumowania i kodowania.

W praktyce: kiedy odpalasz ChatGPT i wybierasz najnowszy model, pracujesz z GPT-5.1 (w jednej z jego odmian).

Dwa tryby pracy: Instant i Thinking

GPT-5.1 występuje w dwóch głównych wariantach, z którymi będziesz mieć styczność jako dev:

• GPT-5.1 Instant
  • zoptymalizowany pod szybkość i niskie opóźnienia,
  • idealny do prostych pytań, krótkich snippetów, szybkich podpowiedzi,
  • wciąż bardzo dobry w kodowaniu, ale nie „przegrzewa się” nad prostymi sprawami.
• GPT-5.1 Thinking
  • model nastawiony na złożone rozumowanie,
  • lepszy wybór do trudnych bugów, większych refaktoryzacji, projektowania architektury,
  • potrafi poświęcić więcej „czasu na myślenie” tam, gdzie naprawdę jest to potrzebne.

Nowością względem wcześniejszych modeli jest to, że GPT-5.1 stosuje adaptacyjne rozumowanie – sam dopasowuje głębokość analizy do trudności zadania, zamiast zawsze „filozofować” na pełnym gazie.

GPT-5.1 jako model w API – stricte pod kod i automatyzację

W dokumentacji OpenAI GPT-5.1 jest opisywany jako „flagowy model do zadań koderskich i agentowych, z konfigurowalnym rozumowaniem”.

Z punktu widzenia programisty PHP/Laravel oznacza to:

• możliwość kontrolowania poziomu rozumowania (parametr reasoning_effort – od none po wyższe poziomy),
• lepszą współpracę z narzędziami (np. do wykonywania komend, patchowania kodu, itp.),
• lepsze wyniki w zadaniach programistycznych w porównaniu z wcześniejszym GPT-5, przy niższym koszcie i czasie odpowiedzi w prostych przypadkach.

Co nowego wnosi GPT-5.1 z perspektywy programisty PHP i Laravel 12?

Lepsze rozumienie złożonych zadań technicznych

GPT-5.1 ma znacząco poprawione wyniki w zadaniach wymagających wielostopniowego rozumowania, takich jak: złożone bugi, analiza kilku plików naraz, wnioskowanie na podstawie logów i stack trace.

Przykładowo, jeśli:

• wklejasz kilka powiązanych klas z warstwą serwisową i kontrolerami,
• plus fragmenty logów z kolejki / jobów / eventów,

model jest lepiej przygotowany, by:

• rozpoznać zależności między klasami,
• wyciągnąć przyczynę błędu,
• zaproponować realistyczną strategię naprawy (a nie tylko kosmetyczne zmiany).

Inteligentniejsze zarządzanie „czasem myślenia”

Dzięki adaptacyjnemu rozumowaniu GPT-5.1 nie marnuje zasobów na proste rzeczy. Kiedy prosisz o:

• banalny snippet (np. prostą walidację requestu),
• migrację z kilkoma polami,

model odpowie szybko i konkretnie. Ale gdy zadanie jest złożone:

• refaktoryzacja starego modułu billingowego,
• przeprojektowanie architektury event-driven w systemie,
• analiza race condition w jobach,

GPT-5.1 Thinking naturalnie „włącza dłuższe myślenie”, co w praktyce daje lepsze, bardziej spójne odpowiedzi.

Bardziej „ludzki” i sterowalny styl odpowiedzi

Dużo zmian poszło w stronę stylu komunikacji:

• GPT-5.1 jest „cieplejszy” w tonie i lepiej wyjaśnia skomplikowane tematy,
• masz dostęp do presetów osobowości (Professional, Friendly, Efficient, Nerdy, Candid, Cynical itd.),
• możesz łatwiej dostosować styl wypowiedzi pod swój projekt lub zespół.

Dla programisty oznacza to np.:

• w trybie Professional/Efficient – suche, rzeczowe odpowiedzi, idealne do dokumentacji i poważnych PR-ów,
• w trybie Nerdy/Friendly – bardziej „warsztatowy” styl, dobry do tłumaczenia juniorom lub dokumentowania decyzji architektonicznych.

Funkcje przydatne stricte pod kod i koszty

GPT-5.1 wprowadza także:

• „no reasoning” mode – możesz wyłączyć dodatkowe rozumowanie, jeśli chodzi tylko o szybkie generowanie kodu (np. prostych helperów) przy użyciu API,
• nowe narzędzia dla kodu (np. do patchowania i wykonywania komend),
• lepszą wydajność i mniejsze zużycie tokenów w typowych taskach programistycznych – testy early adopters pokazują przyspieszenie 2–3x dla codziennych zadań i duże oszczędności w tokenach przy prostych zapytaniach.

W praktyce: mniejsze rachunki i mniej czekania, więcej czasu na faktyczne myślenie o domenie.

Co to konkretnie oznacza dla programisty PHP i Laravel 12?

GPT-5.1 jako „senior pair-programmer” – ale trzeźwo

Od strony workflow wygląda to tak, że ChatGPT 5.1 dla programistów PHP i Laravel może pełnić rolę:

• szybkiego pomocnika (Instant) – pisze Ci Requesty, Resource’y, drobne migracje, proste testy,
• wirtualnego seniora (Thinking) – z którym konsultujesz:
  • architekturę modułu,
  • wzorce projektowe pod konkretny problem,
  • migrację legacy PHP do Laravel 12,
  • wpływ zmian na wydajność i skalowalność.

Różnica względem wcześniejszych modeli polega na tym, że GPT-5.1 lepiej radzi sobie z „długą ścieżką myślową” – mniej gubi wątki przy bardziej złożonych zadaniach.

Laravel 12 + GPT-5.1 = mniej „klepania”, więcej projektowania

W kontekście Laravel 12 GPT-5.1 dobrze wpisuje się w:

• generowanie boilerplate’u (kontrolery, FormRequesty, Resource’y, migracje, Jobs, Events),
• projektowanie i omawianie:
  • modułów domenowych,
  • strategii cache’owania,
  • podziału odpowiedzialności między warstwami,
• pracę z testami (Pest / PHPUnit) – od generowania szkiców testów po propozycje dodatkowych edge case’ów.

Dzięki lepszemu rozumowaniu wieloetapowemu, możesz np. wklejać:

• definicje modeli,
• fragmenty migracji,
• przykładowe use-case’y biznesowe,

a GPT-5.1 pomoże spiąć to w sensowną całość.

Lepsze debugowanie złożonych problemów w PHP / Laravel

Dzięki usprawnieniom w rozumowaniu GPT-5.1 lepiej sprawdza się przy:

• analizie stack trace z kilku warstw (kontroler → serwis → repo → job),
• szukaniu edge case’ów (np. race conditions w kolejce, problemy z blokadami transakcji, nieoczywiste interakcje middleware’ów),
• analizie logów (np. z systemów monitoringu, logów SQL, logów Redis).

To nadal nie jest debugger w stylu Xdebug, ale inteligentny asystent, który jest w stanie:

• zasugerować, gdzie w kodzie brakuje walidacji albo obsługi błędów,
• zaproponować dodatkowe logowanie / metryki,
• podpowiedzieć, jak napisać test, który odtwarza błąd.

Personalizacja stylu pracy – GPT-5.1, który „myśli” jak Twój zespół

Presety osobowości dopasowane do ról w zespole

Dzięki presetom osobowości w GPT-5.1 możesz dobrać styl pracy modelu do sytuacji:

• Professional + Efficient – idealne, gdy generujesz:
  • fragmenty dokumentacji technicznej,
  • opisy PR-ów,
  • specyfikacje endpointów dla stakeholderów.
• Friendly + Nerdy – świetne przy:
  • onboardingach nowych devów,
  • tłumaczeniu trudnych zagadnień (np. CQRS, event sourcing, Hexagonal),
  • warsztatach wewnętrznych.

Dla Ciebie jako dev-a Laravel 12 to oznacza, że możesz mieć:

• „poważny” styl wypowiedzi do komunikacji na zewnątrz,
• jednocześnie bardziej luźny, warsztatowy styl do codziennego pair-programmingu.

Steerowalność – większa kontrola nad odpowiedziami

GPT-5.1 daje też zwiększoną sterowalność (steerability):

• łatwiej narzucić format odpowiedzi (np. „zawsze dawaj kod + testy + listę edge case’ów”),
• łatwiej wymusić konkretne konwencje (np. PSR-12, typowanie, styl nazw),
• łatwiej ograniczyć wodolejstwo (parametry dot. zwięzłości odpowiedzi w API).

To szczególnie przydatne, jeśli integrujesz GPT-5.1 z własnymi narzędziami (np. CLI do refaktoryzacji kodu, generator szkieletów modułów w Laravel 12).

Mity na start: czego GPT-5.1 nie zrobi za programistę PHP

„AI napisze cały projekt za mnie” – nie.

GPT-5.1 jest mocniejszy od poprzedników, ale nadal:

• nie zna Twojej domeny biznesowej tak dobrze jak Ty,
• nie ogarnia wszystkich niepisanych reguł w projekcie,
• nie bierze odpowiedzialności za bugi na produkcji.

Może:

• przyspieszyć produkcję boilerplate’u,
• poprawić jakość testów i dokumentacji,
• pomóc w projektowaniu architektury.

Ale to Ty:

• definiujesz wymagania,
• podejmujesz decyzje architektoniczne,
• recenzujesz kod i bierzesz odpowiedzialność za całość.

„GPT-5.1 zawsze ma rację” – też nie.

Mimo lepszego rozumowania i wyników na benchmarkach, GPT-5.1 potrafi:

• halucynować (wymyślać rzeczy),
• proponować rozwiązania niezgodne z realiami Twojego projektu,
• upraszczać problemy, które wymagają twardych danych (np. realnych limitów infrastruktury).

Dlatego w tym przewodniku będziemy traktować GPT-5.1 jak mocnego partnera do wspólnego myślenia, a nie „autora kodu, którego nie wolno kwestionować”.

Jak przygotować ChatGPT 5.1 do pracy z PHP i Laravel 12

Żeby ChatGPT 5.1 dla programistów PHP i Laravel był naprawdę przydatny, musi „myśleć jak Twój projekt”. Samo odpalanie nowej rozmowy i rzucanie „napisz mi kontroler” to marnowanie potencjału. Kluczowe są trzy rzeczy:

1. dobrze ustawione instrukcje globalne (Custom Instructions / ustawienia asystenta),
2. sensowny „system prompt” na start sesji programistycznej,
3. spójność – trzymanie się jednego stylu kodu, wersji PHP i Laravel 12 w całym wątku.

Poniżej przeprowadzę Cię krok po kroku przez to, jak to ustawić.

Ustawienia ChatGPT pod programistę PHP / Laravel 12

Dlaczego instrukcje globalne są krytyczne?

ChatGPT 5.1 ma mocno rozbudowaną personalizację – może zapamiętać, kim jesteś i jakiej pomocy oczekujesz. Jeśli od razu powiesz mu, że:

• pracujesz w PHP 8.2 / 8.3 i Laravel 12,
• trzymasz się PSR-12, typowania i konkretnych standardów,
• używasz np. Pest do testów,
• wolisz kod prosty niż „sprytny”,

to model od początku będzie odpowiadał bliżej Twoich realnych potrzeb – zamiast generować losowy styl z głowy.

Co warto wpisać w instrukcjach o Tobie (jako dev PHP / Laravel)

W polu typu „O mnie / Kim jestem / Jakiej pomocy oczekuję” warto zwięźle opisać swój kontekst. Przykładowa treść do adaptacji:

• jesteś programistą PHP (mid/senior),
• pracujesz głównie z Laravel 12,
• target: aplikacje biznesowe / SaaS / CRM / e-commerce (wybierz co pasuje),
• stack: MySQL/PostgreSQL, Redis, kolejki, czasem mikroserwisy.

Przykład (do przerobienia pod siebie):

„Pracuję jako programista PHP (mid/senior), głównie w Laravel 12. Tworzę aplikacje biznesowe (SaaS / CRM), korzystam z MySQL i Redis, kolejek, eventów, modular monolith / czasem mikroserwisy. Odpowiadaj jak do doświadczonego dev-a – możesz pominąć absolutne podstawy PHP, ale zwracaj uwagę na architekturę, czytelność i testowalność.”

To sprawia, że ChatGPT 5.1 nie będzie Ci tłumaczył, co to foreach, tylko skupi się na rzeczach, które mają sens na Twoim poziomie.

Co wpisać w instrukcjach o tym, jak ma odpowiadać

Drugi ważny obszar to styl odpowiedzi. Tu ustalasz:

• standardy kodu,
• formatowanie,
• poziom szczegółowości.

Przykład:

„Zawsze zakładaj PHP 8.2+ i Laravel 12. Stosuj PSR-12, pełne typowanie i sensowne nazwy klas/metod. W odpowiedziach dla kodu:

• pokazuj kompletne klasy (z namespace, use, itp.),
• dodawaj komentarze tylko tam, gdzie to faktycznie pomaga,
• proponuj testy w Pest do kluczowych funkcji.
  Jeśli zapytanie dotyczy architektury – najpierw zaproponuj plan (kroki, warstwy, zależności), a dopiero potem kod. Unikaj zbędnego „wodolejstwa”.”

To jest fundament, który będziemy potem rozszerzać w pierwszym „system promptcie” w danej sesji.

Wybór stylu / „osobowości” modelu pod pracę dev-a

Kiedy włączyć tryb bardziej „Professional/Efficient”

Do codziennej pracy nad projektem komercyjnym najlepiej sprawdza się konfiguracja zbliżona do:

• Professional – ton spokojny, techniczny,
• Efficient – odpowiedzi konkretne, bez zbędnych dygresji.

Taki styl jest idealny, gdy:

• generujesz kod, który trafi do PR-ów,
• tworzysz dokumentację techniczną,
• pracujesz z wymaganiami biznesowymi i chcesz mieć czyste, rzeczowe podsumowania.

Kiedy pozwolić sobie na „Friendly/Nerdy”

Styl Friendly / Nerdy jest świetny, gdy:

• chcesz, żeby ChatGPT 5.1 pełnił rolę mentora / pair-programmera,
• tłumaczysz sobie jakieś nowe koncepty (np. CQRS, event sourcing, architektura heksagonalna w kontekście Laravel 12),
• przygotowujesz materiały szkoleniowe dla zespołu lub juniorów.

Prosta taktyka: do „poważnej” pracy projektowej – Professional + Efficient; do nauki i eksperymentów – Friendly + Nerdy.

Bazowy „system prompt” na początek sesji programistycznej

Nawet przy dobrych instrukcjach globalnych, warto każdą sesję stricte projektową zacząć jednym, porządnym promptem, który ustawi kontekst:

• projekt,
• stack,
• wymagania co do odpowiedzi.

Ogólny szablon system promptu dla Laravel 12

Poniżej propozycja, którą możesz adaptować pod każdy projekt (warto wkleić na początku nowego wątku).

Szablon

„Jesteś seniorem PHP / Laravel, pracującym w realnym projekcie komercyjnym.

Założenia:

• używamy PHP 8.2+ i Laravel 12,
• stosujemy PSR-12, pełne typowanie, klasy serwisowe zamiast „helpersów”,
• testy piszemy w Pest,
• preferujemy prostą, czytelną architekturę nad „sprytne” hacki.
  

Zasady odpowiadania:

• jeśli pytam o kod, zawsze pokazuj kompletne klasy z namespace i use,
• jeśli to możliwe, zaproponuj też przykładowy test w Pest,
• wskazuj potencjalne edge case’y i problemy z bezpieczeństwem,
• jeśli zadanie jest złożone, najpierw zaproponuj plan (kroki), potem kod.

Kontekst projektu:
[TU W 2–5 ZDANIACH OPISZ PROJEKT: typ, główne moduły, domenę, np. system rezerwacji, CRM, sklep, itp.]

Czy rozumiesz kontekst? Jeśli tak, streść go własnymi słowami w maks. 5 punktach, a potem możemy przejść do pierwszego zadania.”

Ten jeden, dobrze przemyślany prompt powoduje, że:

• GPT-5.1 „ustawia się” w roli seniora,
• od razu kojarzy Laravel 12 i PHP 8.2+,
• łapie Twój styl pracy (plan → kod → testy → edge case’y).

Przykład wypełnionego promptu dla aplikacji SaaS

Załóżmy, że tworzysz SaaS do zarządzania projektami.

„Jesteś seniorem PHP / Laravel, pracującym w realnym projekcie komercyjnym.

Założenia:

• używamy PHP 8.2+ i Laravel 12,
• stosujemy PSR-12, pełne typowanie, klasy serwisowe zamiast „helpersów”,
• testy piszemy w Pest,
• preferujemy prostą, czytelną architekturę nad „sprytne” hacki.
  

Zasady odpowiadania:

• jeśli pytam o kod, zawsze pokazuj kompletne klasy z namespace i use,
• jeśli to możliwe, zaproponuj też przykładowy test w Pest,
• wskazuj potencjalne edge case’y i problemy z bezpieczeństwem,
• jeśli zadanie jest złożone, najpierw zaproponuj plan (kroki), potem kod.

Kontekst projektu:
Budujemy SaaS do zarządzania projektami (projekty, zadania, komentarze, załączniki, role użytkowników, uprawnienia). System ma API REST dla frontendu SPA oraz kilka integracji zewnętrznych (webhooki, integracja z systemem fakturującym).

Czy rozumiesz kontekst? Jeśli tak, streść go własnymi słowami w maks. 5 punktach, a potem możemy przejść do pierwszego zadania.”

Taki start sprawia, że kolejne prompty mogą być krótsze, bo model ma już głowę „ustawioną” na Twój projekt.

Co jeszcze warto ustawić na początku sesji

Ustal format odpowiedzi raz, a dobrze

Żeby uniknąć ciągłego powtarzania „pokaż kod + testy + edge case’y”, możesz ustalić format z góry:

„Domyślny format odpowiedzi, gdy proszę o kod:

1. Krótkie wyjaśnienie (maks. 3–4 zdania),
2. Kod (kompletne klasy / pliki),
3. Propozycja 2–5 testów w Pest (kod),
4. Lista potencjalnych edge case’ów / ryzyk.”

Dzięki temu ChatGPT 5.1 będzie zdecydowanie bardziej użyteczny jako partner do developmentu, a nie tylko generator pojedynczych snippetów.

Daj znać, czego nie chcesz

Równie ważne jest powiedzieć, czego model ma unikać. Przykładowo:

„Nie używaj w przykładach zewnętrznych pakietów, chyba że explicite o to poproszę. Nie używaj dd() ani var_dump() w kodzie produkcyjnym. Unikaj skrótów typu Arr::get jeśli możemy użyć natywnych mechanizmów Laravel 12.”

Takie „zakazy” bardzo poprawiają jakość generowanego kodu.

Podstawy skutecznego promptowania w ChatGPT 5.1 dla programistów PHP i Laravel 12

Żeby ChatGPT 5.1 dla programistów PHP i Laravel był czymś więcej niż „generator SQL-i i walidatorów”, musisz opanować jedną rzecz: sztukę zadawania pytań, czyli porządne promptowanie. Dobra wiadomość: to nie jest magia. Zła: „Napisz mi endpoint” to nie jest dobry prompt. 😄

Poniżej przejdziemy przez praktyczny zestaw zasad i schematów, które możesz od razu zastosować w swojej codziennej pracy z Laravel 12.

Schemat dobrego promptu: Kontekst → Zadanie → Ograniczenia → Format

Dlaczego sama prośba o „kod” to za mało?

Model GPT-5.1 jest mocny, ale nie siedzi w Twoim repo. Nie zna:

• wersji PHP / Laravel,
• konwencji w projekcie,
• wymagań biznesowych,
• Twoich standardów jakości.

Jeśli podasz mu tylko: „napisz kontroler logowania”, to zrobi coś „w miarę OK”, ale:

• może użyć starego stylem (Auth::attempt, brak FormRequest),
• pominie testy,
• nie dopasuje się do Twojej architektury.

Dlatego potrzebujemy struktury.

Kontekst → Zadanie → Ograniczenia → Format

To jest Twój nowy, domyślny szablon promptu.

1. Kontekst

Kilka zdań o:

• gdzie będzie użyty kod (API, panel admina, mikroserwis),
• jak wygląda Twój stack (Laravel 12, Pest, architektura),
• jakie są powiązania domenowe (np. „zadania należą do projektów, projekty do organizacji”).

Przykład:

„Buduję API w Laravel 12 dla aplikacji typu SaaS do zarządzania projektami. Mamy modele: Organization, Project, Task. Każdy projekt należy do organizacji, a zadania do projektu. API jest używane przez frontend SPA (Vue).”

2. Zadanie

Jedno, konkretne polecenie. Nie „zrób mi wszystko”, tylko:

• „kontroler do…”,
• „walidator do…”,
• „testy do…”.

Przykład:

„Potrzebuję endpointu POST /api/projects, który tworzy nowy projekt w ramach danej organizacji.”

3. Ograniczenia

Tu narzucasz:

• wersje (PHP 8.2, Laravel 12),
• style (PSR-12, pełne typowanie),
• techniczne wymagania (np. użyj FormRequest, Resource, Sanctum, itp.).

Przykład:

„Użyj Laravel 12, PSR-12, pełnego typowania. Walidację zrób w osobnej klasie StoreProjectRequest. Zwróć dane przez ProjectResource. Użytkownik jest uwierzytelniony przez Sanctum.”

4. Format

Jak ma wyglądać odpowiedź:

• tylko kod / kod + opis,
• ile klas, w jakiej kolejności,
• czy mają być testy.

Przykład:

„Pokaż:

1. trasę w routes/api.php,
2. klasę StoreProjectRequest,
3. klasę ProjectController z metodą store,
4. klasę ProjectResource,
5. przykładowy test w Pest dla tego endpointu.
   Odpowiedź podziel nagłówkami i dodaj krótkie komentarze w kodzie.”

I to jest pełny, dobry prompt.

Zły prompt vs dobry prompt – przykład na endpoint logowania w Laravel 12

Zły prompt (typowy, niestety)

„Napisz mi endpoint do logowania w Laravel.”

Co może pójść nie tak?

• Laravel może nie być w najnowszej wersji,
• brak informacji o mechanizmie auth (Sanctum? Passport? session?),
• brak info o tym, czy chcesz FormRequest, Resource, testy, cokolwiek.

Model musi zgadywać. A jak zgaduje, to czasem trafi, a czasem… nie.

Dobry prompt – szczegółowy przykład

„Pracuję w Laravel 12, PHP 8.2. Uwierzytelnianie realizujemy przez Laravel Sanctum, aplikacja to SPA korzystające z API.

Potrzebuję endpointu logowania POST /api/login, który:

• przyjmuje email i password,
• waliduje dane w osobnej klasie LoginRequest (FormRequest),
• sprawdza dane użytkownika i zwraca:
  • przy sukcesie: token API Sanctum oraz podstawowe dane użytkownika,
  • przy błędzie: odpowiedni komunikat z kodem 422 lub 401.
    

Wymagania techniczne:

• Laravel 12, PSR-12, pełne typowanie,
• błędy walidacji obsługujemy standardowym mechanizmem FormRequest,
• nie używaj żadnych zewnętrznych paczek poza Sanctum.
  

Format odpowiedzi:

1. Trasa w routes/api.php,
2. klasa LoginRequest,
3. kontroler Auth\\LoginController z metodą __invoke,
4. przykładowy test w Pest dla poprawnego logowania i błędnych danych.
   

Dodaj krótkie komentarze tylko przy kluczowych fragmentach kodu.”

Taki prompt:

• nie zostawia miejsca na zgadywanie,
• jasno określa stack i wymagania,
• wymusza testy,
• daje Ci od razu komplet: route + Request + Controller + testy.

Iteracyjne promptowanie – pracuj „w pętlach”, nie „w strzale”

Dlaczego „od razu kod” to słaby pomysł przy większych rzeczach

Przy prostym FormRequest – spoko, strzelasz promptem i bierzesz wynik.
Przy poważniejszych rzeczach:

• moduł płatności,
• system powiadomień,
• import zewnętrzny,

lepiej nie zaczynać od kodu, tylko od… myślenia. I tutaj GPT-5.1 (szczególnie w trybie Thinking) świeci najjaśniej.

Pętla: Plan → Kod → Testy → Refaktoryzacja

Proponowany workflow:

1. Plan „Zaproponuj plan implementacji modułu X w Laravel 12, w maks. 10 krokach. Uwzględnij warstwy, klasy, relacje, potencjalne pułapki.”
2. Kod dla jednego kroku „Zaimplementuj krok 1 planu: migracje i modele. Użyj Laravel 12, pełne typowanie. Pokaż tylko migracje i modele.”
3. Testy „Na bazie tych modeli zaproponuj testy w Pest, które pokryją główne scenariusze.”
4. Refaktoryzacja / krytyka „Oceń powyższy kod według kryteriów: czytelność, testowalność, wydajność, bezpieczeństwo. Zaproponuj konkretne usprawnienia.”
5. Kolejne kroki planu – iterujesz.
   

Dzięki temu:

• w pełni wykorzystujesz adaptacyjne rozumowanie GPT-5.1 – najpierw plan, potem głębsze wejście w kod,
• łatwiej wyłapujesz błędy i antywzorce po drodze,
• masz dokumentację procesu „za darmo” w historii rozmowy.

Przykładowy kompletny prompt – endpoint tworzenia projektu w Laravel 12

Poniżej masz przykład „kanonicznego” promptu, który łączy wszystkie powyższe zasady. Możesz go potraktować jako template do własnych zadań.

Prompt

„Pracuję nad API w Laravel 12 dla aplikacji SaaS do zarządzania projektami.

Kontekst domeny:

• Organization ma wiele Project,
• Project ma wiele Task,
• użytkownik może mieć dostęp do wielu organizacji.
  

Zadanie:
Potrzebuję endpointu POST /api/organizations/{organization}/projects, który tworzy nowy projekt w ramach danej organizacji, przypisanego do aktualnie zalogowanego użytkownika (Laravel Sanctum).

Wymagania techniczne:

• Laravel 12, PHP 8.2+, PSR-12, pełne typowanie,
• walidacja w osobnej klasie StoreProjectRequest (FormRequest),
• odpowiedź JSON z użyciem ProjectResource,
• przy błędach walidacji – standardowy format FormRequest,
• jeśli użytkownik nie ma dostępu do organizacji, zwróć 403.
  

Format odpowiedzi:

1. Definicja trasy w routes/api.php,
2. klasa StoreProjectRequest,
3. klasa ProjectResource,
4. kontroler ProjectController z metodą store,
5. przykładowy test w Pest dla:
   • poprawnego utworzenia projektu,
   • próby utworzenia projektu w organizacji bez uprawnień (403).

Dodaj krótkie komentarze w kodzie tylko przy kluczowych fragmentach (autoryzacja, walidacja, logika domenowa).”

Jak widzisz:

• Kontekst – domena, relacje.
• Zadanie – ściśle określony endpoint.
• Ograniczenia – Laravel 12, Sanctum, FormRequest, Resource, PSR-12.
• Format – jasno wskazane, jakie pliki mają się pojawić i że mają być testy.

To jest dokładnie ten poziom szczegółowości, przy którym ChatGPT 5.1 zaczyna naprawdę błyszczeć w pracy z Laravel 12.

Checklista dobrego promptu dla dev-a Laravel 12

Na koniec tej sekcji – krótka ściąga, którą możesz mieć w notatkach:

• Czy podałem kontekst (projekt, domena, używane technologie)?
• Czy jasno opisałem zadanie (jedno, konkretne)?
• Czy określiłem ograniczenia techniczne (Laravel 12, PHP wersja, style, pakiety)?
• Czy wskazałem format odpowiedzi (pliki, kolejność, testy)?
• Czy zadanie nie jest zbyt szerokie (np. „zrób mi cały moduł płatności”) – jeśli tak, rozbijam na plan + kroki.
• Czy wspomniałem o testach (Pest) i potencjalnych edge case’ach?
  
  Jeśli większość z tych pól jest odhaczona – masz dobry prompt.

Gotowe prompty do codziennych zadań w PHP i Laravel 12

Pora na mięso: konkretne, gotowe prompty, które możesz kopiować do ChatGPT 5.1 i od razu używać w pracy z PHP 8.2+ i Laravel 12 (Laravel 12 wymaga min. PHP 8.2, więc i tak jesteś na współczesnym stacku).

W tej części:

• pokazuję gotowy prompt,
• tłumaczę, po co jest tak skonstruowany,
• dorzucam przykładowe efekty, których możesz oczekiwać (fragmenty kodu z komentarzami).

Traktuj to jak ściągę „copy–paste + modyfikuj pod projekt”.

Prompty do generowania kodu w Laravel 12

Kontroler + FormRequest + Resource (tworzenie zasobu)

Prompt: tworzenie projektu w ramach organizacji

Pracuję nad API w Laravel 12 (PHP 8.2+, PSR-12). Buduję SaaS do zarządzania projektami.

Kontekst domeny:
- Organization ma wiele Project,
- Project ma wiele Task,
- użytkownik może mieć dostęp do wielu Organization.

Zadanie:
Potrzebuję endpointu `POST /api/organizations/{organization}/projects`, który tworzy projekt w ramach wskazanej organizacji.
Założenia:
- użytkownik jest uwierzytelniony przez Laravel Sanctum,
- użytkownik musi mieć dostęp do organizacji, inaczej zwracamy 403.

Wymagania techniczne:
- Laravel 12, pełne typowanie, PSR-12,
- walidacja w osobnej klasie `StoreProjectRequest` (FormRequest),
- odpowiedź JSON przez `ProjectResource`,
- obsłuż podstawowe pola: `name` (string, wymagane, max 255), `description` (nullable string), `due_date` (nullable date).

Format odpowiedzi:
1. Trasa w `routes/api.php`,
2. klasa `StoreProjectRequest`,
3. klasa `ProjectResource`,
4. kontroler `App\Http\Controllers\Api\ProjectController` z metodą `store`,
5. przykładowy test w Pest (feature) dla:
   - poprawnego utworzenia projektu,
   - próby utworzenia projektu w organizacji, do której użytkownik nie ma dostępu (403).

Dodaj komentarze w kodzie tylko przy kluczowych fragmentach (autoryzacja, walidacja, logika domenowa).

Czego możesz oczekiwać od ChatGPT 5.1 (przykładowy kod)

Trasa w routes/api.php:

<?php

use App\Http\Controllers\Api\ProjectController;
use Illuminate\Support\Facades\Route;

Route::middleware('auth:sanctum')
    ->prefix('organizations/{organization}')
    ->group(function (): void {
        Route::post('projects', [ProjectController::class, 'store'])
            ->name('organizations.projects.store');
    });

FormRequest StoreProjectRequest:

<?php

declare(strict_types=1);

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class StoreProjectRequest extends FormRequest
{
    public function authorize(): bool
    {
        // Zakładamy, że sama autoryzacja dostępu do Organization
        // będzie obsłużona w kontrolerze lub polityce.
        // Tu przyjmujemy, że uwierzytelniony użytkownik może próbować wykonać żądanie.
        return $this->user() !== null;
    }

    /**
     * Zasady walidacji danych wejściowych.
     */
    public function rules(): array
    {
        return [
            'name'        => ['required', 'string', 'max:255'],
            'description' => ['nullable', 'string'],
            'due_date'    => ['nullable', 'date'],
        ];
    }
}

Resource ProjectResource:

<?php

declare(strict_types=1);

namespace App\Http\Resources;

use Illuminate\Http\Request;
use Illuminate\Http\Resources\Json\JsonResource;

/**
 * @property int $id
 * @property string $name
 * @property string|null $description
 * @property string|null $due_date
 * @property int $organization_id
 */
class ProjectResource extends JsonResource
{
    /**
     * Transformacja modelu Project do tablicy JSON.
     *
     * @return array<string, mixed>
     */
    public function toArray(Request $request): array
    {
        return [
            'id'             => $this->id,
            'organizationId' => $this->organization_id,
            'name'           => $this->name,
            'description'    => $this->description,
            'dueDate'        => $this->due_date,
            'createdAt'      => $this->created_at?->toIso8601String(),
            'updatedAt'      => $this->updated_at?->toIso8601String(),
        ];
    }
}

Kontroler ProjectController:

<?php

declare(strict_types=1);

namespace App\Http\Controllers\Api;

use App\Http\Controllers\Controller;
use App\Http\Requests\StoreProjectRequest;
use App\Http\Resources\ProjectResource;
use App\Models\Organization;
use App\Models\Project;
use Illuminate\Http\JsonResponse;
use Illuminate\Http\Request;

class ProjectController extends Controller
{
    public function store(StoreProjectRequest $request, Organization $organization): JsonResponse
    {
        /** @var \App\Models\User $user */
        $user = $request->user();

        // Kluczowy fragment: sprawdzenie, czy użytkownik ma dostęp do organizacji.
        if (! $user->organizations()->whereKey($organization->getKey())->exists()) {
            abort(403, 'You do not have access to this organization.');
        }

        $data = $request->validated();

        /** @var Project $project */
        $project = $organization->projects()->create([
            'name'        => $data['name'],
            'description' => $data['description'] ?? null,
            'due_date'    => $data['due_date'] ?? null,
            'owner_id'    => $user->getKey(),
        ]);

        return (new ProjectResource($project))
            ->response()
            ->setStatusCode(201);
    }
}

Test feature w Pest (np. tests/Feature/CreateProjectTest.php):

<?php

declare(strict_types=1);

use App\Models\Organization;
use App\Models\Project;
use App\Models\User;
use function Pest\Laravel\actingAs;
use function Pest\Laravel\postJson;

it('creates a project for organization the user has access to', function (): void {
    /** @var User $user */
    $user = User::factory()->create();

    /** @var Organization $organization */
    $organization = Organization::factory()->create();

    // Zakładamy relację wiele-do-wielu user <-> organization.
    $user->organizations()->attach($organization);

    actingAs($user, 'sanctum');

    $response = postJson(route('organizations.projects.store', [
        'organization' => $organization->getKey(),
    ]), [
        'name'        => 'New Project',
        'description' => 'Test project',
        'due_date'    => '2025-12-31',
    ]);

    $response->assertCreated()
        ->assertJsonFragment([
            'name' => 'New Project',
        ]);

    expect(Project::query()->count())->toBe(1);
});

it('returns 403 when user has no access to organization', function (): void {
    /** @var User $user */
    $user = User::factory()->create();

    /** @var Organization $organization */
    $organization = Organization::factory()->create();

    actingAs($user, 'sanctum');

    $response = postJson(route('organizations.projects.store', [
        'organization' => $organization->getKey(),
    ]), [
        'name' => 'Forbidden Project',
    ]);

    $response->assertForbidden();

    expect(Project::query()->count())->toBe(0);
});

Tego typu odpowiedzi możesz oczekiwać od ChatGPT 5.1 Thinking, jeśli dasz dobry prompt. Instant najczęściej też da radę, ale Thinking lepiej ogarnia złożoną logikę.

Migracja + Model Eloquent z relacjami

Prompt: migracja i model Invoice

Pracuję w Laravel 12 (PHP 8.2+). Potrzebuję modelu faktury.

Kontekst:

• Model Invoice reprezentuje fakturę wystawioną klientowi,
• każda faktura należy do User (owner) i opcjonalnie do Project,
• będziemy często filtrować po status i issue_date.

Zadanie:
Przygotuj:

1. migrację create_invoices_table,
2. model App\Models\Invoice z relacjami do User i Project.

Wymagania:

• Laravel 12, pełne typowanie, PSR-12,
• pola: id, user_id, project_id (nullable), number (string, unikalny), status (string), gross_amount (decimal 10,2), issue_date (date), due_date (date), timestamps,
• dodaj indeksy pod częste zapytania (status, issue_date),
• w modelu dodaj relacje user() i project() oraz proste scope’y: scopePaid() i scopeOverdue().

Dodaj komentarze w kodzie przy indeksach i scope’ach.

Resztę (migrację + model) ChatGPT 5.1 wygeneruje w stylu podobnym do:

$table->index(['status', 'issue_date']);

oraz:

public function scopePaid(Builder $query): Builder
{
    return $query->where('status', 'paid');
}

itd.

Jobs, Events, Listeners, Queue – asynchroniczne zadania

Prompt: wysyłanie powiadomień po utworzeniu zamówienia

Laravel 12, PHP 8.2+, aplikacja e-commerce.

Kontekst:

• Mamy model Order,
• po utworzeniu zamówienia chcemy:
• wysłać e-mail do klienta,
• wysłać e-mail do działu obsługi.

Zadanie:
Zaproponuj asynchroniczną architekturę w Laravel 12:

• event OrderPlaced,
• listener SendOrderNotifications,
• job SendOrderEmail wyzwalany z listenera.

Wymagania:

• event + listener zarejestrowane w EventServiceProvider,
• job implementujący ShouldQueue,
• pokaż przykład użycia eventu w kodzie tworzącym zamówienie (np. w serwisie).

Format:

1. event OrderPlaced,
2. listener SendOrderNotifications,
3. job SendOrderEmail,
4. fragment OrderService, który:

• tworzy zamówienie,
• wywołuje event.

Dodaj komentarze przy miejscach, gdzie decydujemy się na async vs sync.

To jest idealne zadanie dla GPT-5.1 Thinking: dużo elementów, zależności i dobry kandydat na adaptacyjne rozumowanie.

Prompty do debugowania błędów PHP / Laravel

Analiza stack trace + kodu

Prompt: klasyczny bug w serwisie

Pracuję w Laravel 12 (PHP 8.2+). Poniżej masz stack trace oraz fragmenty kodu.

[Wklej tutaj stack trace z logów lub konsoli]

[Wklej tutaj powiązane klasy: kontroler, serwis, ewentualnie model]

Zadanie:

1. Wyjaśnij, co jest prawdopodobną przyczyną błędu, krok po kroku,
2. wskaż dokładnie miejsce w kodzie, które jest problematyczne,
3. zaproponuj poprawkę,
4. zaproponuj test (w Pest), który odtwarza ten błąd.

Wymagania:

• Laravel 12, bez zmiany technologii,
• traktuj mój kod realistycznie (nie przepisuj wszystkiego na nowo, tylko napraw to, co trzeba),
• zwróć szczególną uwagę na:
• null vs brak relacji,
• masowe przypisywanie,
• transakcje,
• potencjalne race conditions.

Odpowiedź sformatuj w sekcjach:

1. Analiza,
2. Miejsce błędu,
3. Poprawka (kod),
4. Propozycja testu w Pest.

To jest złoto przy dziwnych błędach produkcyjnych. Im więcej wkleisz realnego kontekstu, tym lepiej GPT-5.1 sobie poradzi.

Szukanie edge case’ów

Prompt: polowanie na rogi systemu

Poniżej masz metodę serwisową w Laravel 12:

[Wklej metodę lub klasę]

Zadanie:

1. Wypisz potencjalne edge case’y, które mogą wywołać błędy lub niepożądane zachowanie,
2. zaproponuj, jak zabezpieczyć się przed każdym z nich,
3. zaproponuj zestaw testów w Pest (tylko nazwy + opis, bez pełnego kodu, jeśli będzie ich dużo).

Skup się szczególnie na:

• współbieżności (kilka requestów naraz),
• braku danych wejściowych,
• błędach komunikacji z zewnętrznymi usługami,
• nieoczywistych założeniach domenowych.

To jest świetny prompt, gdy chcesz, żeby ChatGPT 5.1 zadziałał jako „audytor” Twojej logiki.

Prompty do testów w Laravel 12 (Pest)

Generowanie testów do istniejącego kodu

Prompt: testy do kontrolera API

Pracuję w Laravel 12. Testy piszemy w Pest.

Poniżej masz kontroler API:

[Wklej kontroler]

Zadanie:

1. Zaproponuj zestaw sensownych scenariuszy testowych,
2. napisz testy w Pest dla tych scenariuszy (używaj helperów typu postJson, getJson itd.).

Wymagania:

• nie używaj komentarzy przy oczywistych asercjach,
• jeśli trzeba, załóż istnienie fabryk (UserFactory, ProjectFactory itd.),
• pamiętaj o:
• scenariuszach sukcesu,
• błędach walidacji,
• braku uprawnień (401/403),
• nietypowych danych (np. skrajne wartości).

Pisanie testów pod edge case’y

Prompt: coverage „z górką”

Poniżej masz klasę serwisową w Laravel 12:

[Wklej klasę]

Zadanie:

1. Oceń, czy obecny kod (bez testów) jest podatny na edge case’y,
2. zaproponuj dodatkowe testy w Pest, które pokryją:

• scenariusze skrajne,
• scenariusze błędów,
• scenariusze z błędami zewnętrznych usług.

Dla każdego testu:

• podaj nazwę (it('...')),
• pokaż pełen kod testu,
• krótko wyjaśnij, po co ten test istnieje.

Prompty do refaktoryzacji legacy PHP → Laravel 12

Refaktoryzacja funkcji proceduralnej do serwisu

Prompt: legacy function → klasa serwisowa

Mam legacy kod w czystym PHP (bez frameworka), który chcę przenieść do Laravel 12.

Poniżej kod:

[Wklej starą funkcję / plik]

Zadanie:

1. Przepisz logikę do klasy serwisowej w Laravel 12 (App\Services\...),
2. zaproponuj sensowną sygnaturę metody (typy parametrów, zwrotka),
3. zaproponuj prosty interfejs, jeśli ma to sens,
4. napisz przykładowe testy w Pest.

Wymagania:

• PHP 8.2+, pełne typowanie,
• prosta, czytelna logika – żadnych „magicznych” helperów,
• nie zmieniaj logiki biznesowej, tylko jej strukturę,
• pokaż również, jak taka klasa mogłaby być wstrzykiwana do kontrolera (constructor injection).

Refaktoryzacja modułu krok po kroku

Prompt: migracja w kilku iteracjach

Mam moduł legacy (PHP), który chcę stopniowo przenosić do Laravel 12.

Poniżej opis modułu i przykładowe pliki:

[Opis + pliki]

Zadanie:

1. Najpierw zaproponuj plan migracji w maks. 7 krokach (bez kodu),
2. dopiero po mojej akceptacji planu – realizuj krok 1 (kod),
3. po zakończeniu kroku 1 – zaproponuj testy, które potwierdzą, że nie zepsuliśmy logiki.

Kryteria:

• minimalizujemy ryzyko regresji,
• nie przepisujemy wszystkiego na raz,
• w każdej iteracji powinniśmy móc wdrożyć kod bez wybuchu produkcji.

Ten styl pracy świetnie wykorzystuje adaptacyjne rozumowanie GPT-5.1 – najpierw plan, potem kawałek po kawałku.

Prompty do dokumentacji, PHPDoc i komunikacji technicznej

Generowanie PHPDoc dla istniejącego kodu

Poniżej masz klasę w Laravel 12 (bez PHPDoc):

[Wklej klasę]

Zadanie:

1. Dodaj sensowny PHPDoc do klasy, do publicznych metod i do właściwości,
2. nie opisuj oczywistości (np. „Metoda zwraca true, jeśli zwraca true”),
3. skup się na:

• parametrach,
• typach zwracanych wartości,
• ważnych założeniach domenowych.

Zachowaj PSR-12 i nie zmieniaj logiki klasy.

Tworzenie krótkiego ADR (Architecture Decision Record)

Oto opis decyzji architektonicznej w punktach:

[Wklej swoje notatki / myśli]

Zadanie:

1. Zamień to na zwięzły ADR (Architecture Decision Record) w formacie:

• Context,
• Decision,
• Consequences (positive/negative),

1. styl: zwięzły, techniczny, do repo w Laravel 12.

Nie wymyślaj dodatkowych argumentów – używaj tylko tego, co podałem, ewentualnie delikatnie doprecyzuj logiczne konsekwencje.

Scenariusze end-to-end: ChatGPT 5.1 jako partner w całym cyklu pracy (Laravel 12)

Do tej pory mieliśmy sporo „mikro-promptów”. Teraz czas spojrzeć szerzej: jak ChatGPT 5.1 dla programistów PHP i Laravel może pracować z Tobą od momentu pomysłu do gotowego feature’a na produkcji.

Poniżej masz trzy typowe scenariusze:

• start nowego projektu w Laravel 12,
• praca z legacy monolitem,
• wdrażanie nowej funkcjonalności krok po kroku.

W każdym przechodzimy logicznie: wymagania → plan → kod → testy → refaktoryzacja / dokumentacja, a ChatGPT 5.1 jest Twoim „senior-partnerem”.

Scenariusz 1: Start nowego projektu w Laravel 12 z pomocą ChatGPT 5.1

Przekucie wymagań biznesowych na model domeny

Zaczynasz od kawałka opisu biznesowego z Jiry / od klienta. Zamiast od razu tworzyć modele, wrzucasz to do ChatGPT 5.1 z konkretnym zadaniem.

Przykładowy prompt – analiza wymagań

Buduję nową aplikację SaaS w Laravel 12 (PHP 8.2+).

Opis biznesowy (od klienta):

• Klient chce system do zarządzania subskrypcjami kursów online.
• Użytkownik może mieć wiele subskrypcji.
• Subskrypcja dotyczy konkretnych kursów, może być miesięczna lub roczna.
• System ma obsługiwać płatności cykliczne, statusy (active, past_due, canceled).
• Potrzebny jest panel administratora do zarządzania kursami i użytkownikami.

Zadanie:

1. Wyciągnij z tego opis uproszczony model domeny (w punktach),
2. zaproponuj główne agregaty / modele w Laravel 12,
3. opisz w maks. 10 punktach, jakie moduły aplikacji widzisz (np. Billing, Courses, Users, Subscriptions).

Efekt: dostajesz listę modeli i modułów, które możesz od razu wykorzystać jako podstawę architektury.

Projekt architektury na podstawie modelu domeny

Masz już wstępny model. Teraz prosisz ChatGPT 5.1 o zaproponowanie konkretnej struktury katalogów, warstw i zależności.

Przykładowy prompt – architektura

Na podstawie poniższego modelu domeny:

[Wklej listę modeli/modułów z poprzedniej odpowiedzi]

Laravel 12, modular monolith.

Zadanie:

1. Zaproponuj strukturę katalogów dla projektu (podszytego pod Laravel 12), np. moduły typu App\Domain\Billing, App\Domain\Courses itd.
2. Opisz, jakie klasy powinny znaleźć się w każdym module (tylko nazwy i odpowiedzialności).
3. Zaproponuj, które elementy powinny być:

• kontrolerami HTTP,
• serwisami aplikacyjnymi,
• encjami / modelami Eloquent,
• eventami domenowymi.

1. Uwzględnij, że będziemy używać Pest do testów – zaproponuj strukturę katalogów testów.

Dostajesz plan architektury, który możesz przyciąć pod swoje standardy, zanim wygenerujesz choćby jedną linijkę kodu.

Szkielet projektu – migracje, modele, podstawowe endpointy

Na tym etapie prosisz ChatGPT 5.1 o konkretny kod, ale nadal w rozsądnych porcjach.

Przykładowy prompt – migracje i modele

Laravel 12, PHP 8.2+, PSR-12.

Na podstawie poniższego modelu domeny:

[Wklej finalny model domeny / listę agregatów]

Zadanie:

1. Zaproponuj migracje dla tabel: users, courses, subscriptions, plans.
2. Zwróć uwagę na:

• relacje między tabelami,
• indeksy pod częste zapytania (np. po statusie subskrypcji),
• przyszłą rozbudowę (np. dodatkowe metadata JSON).

Format odpowiedzi:

• osobne klasy migracji z pełnym kodem,
• krótkie komentarze przy kluczowych decyzjach (indeksy, typy pól).

Przykładowy fragment migracji, której możesz się spodziewać (upraszczając):

<?php

declare(strict_types=1);

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration {
    public function up(): void
    {
        Schema::create('subscriptions', function (Blueprint $table): void {
            $table->id();
            $table->foreignId('user_id')->constrained()->cascadeOnDelete();
            $table->foreignId('plan_id')->constrained()->cascadeOnDelete();
            $table->string('status')->index(); // częste filtrowanie po statusie
            $table->date('starts_at')->index();
            $table->date('ends_at')->nullable()->index();
            $table->string('external_id')->nullable()->unique(); // ID z bramki płatności
            $table->json('metadata')->nullable();
            $table->timestamps();
        });
    }

    public function down(): void
    {
        Schema::dropIfExists('subscriptions');
    }
};

Generowanie pierwszych endpointów i testów

Mając migracje i modele, możesz poprosić o pierwsze endpointy (np. listowanie kursów, tworzenie subskrypcji) oraz od razu testy w Pest.

Przykładowy prompt – endpoint tworzenia subskrypcji

Laravel 12, PHP 8.2+, PSR-12, Pest.

Mamy modele: User, Plan, Subscription (jak wyżej).

Zadanie:

1. Zaproponuj endpoint POST /api/subscriptions, który:

• przyjmuje plan_id,
• tworzy subskrypcję dla zalogowanego użytkownika,
• na razie nie integruje się z bramką płatności (tylko zapis w DB),
• ustawia status pending i datę starts_at na dziś.

1. Użyj:

• FormRequest StoreSubscriptionRequest,
• SubscriptionResource.

Format odpowiedzi:

1. route,
2. FormRequest,
3. Resource,
4. kontroler z metodą store,
5. test feature w Pest.

Zwróć uwagę na walidację i autoryzację (tylko zalogowani użytkownicy).

W praktyce dostajesz pełen szkielet feature’a, który możesz dopracować, zamiast pisać od zera.

Dokumentacja techniczna jako produkt uboczny

Na końcu możesz poprosić ChatGPT 5.1 o zsyntetyzowanie dokumentacji na podstawie dotychczasowych rozmów:

• opis głównych endpointów,
• prosty diagram przepływu (opisowy),
• ADR z decyzjami architektonicznymi.

Przykładowy prompt – dokumentacja API

Na podstawie naszej pracy nad modułem subskrypcji (powyższe endpointy, modele i migracje):

Zadanie:

1. Przygotuj krótką dokumentację API (w Markdown) dla frontend developerów:

• lista endpointów,
• przykładowe requesty i response’y (JSON),
• kody odpowiedzi i typowe błędy.

1. Styl: zwięzły, techniczny, nastawiony na realne użycie.

Masz gotowy plik, który wkładasz do repo / Confluence.

Scenariusz 2: Praca z legacy monolitem w PHP / starym Laravel

Drugi klasyk: dostajesz projekt w Laravel 5.x / 6.x albo – gorzej – w czystym PHP. Nikt nie chce go dotykać, więc oczywiście trafia do Ciebie. Tu ChatGPT 5.1 jest idealnym narzędziem do bezpiecznej, iteracyjnej refaktoryzacji.

Audyt legacy modułu

Zaczynasz od jednego modułu – np. fakturowanie. Wrzucasz do ChatGPT:

• kilka reprezentatywnych plików,
• krótki opis, co moduł robi biznesowo,
• info o docelowej wersji: Laravel 12, nowa architektura.

Przykładowy prompt – audyt

Mam legacy moduł fakturowania w czystym PHP (bez frameworka). Docelowo chcę go przenieść do Laravel 12, ale muszę najpierw zrozumieć, co on robi.

Poniżej przykładowe pliki:

[Wklej 1–3 kluczowe pliki – np. InvoiceManager.php, helpers.php]

Zadanie:

1. Streść w maks. 10 punktach, co ten moduł robi biznesowo,
2. wypisz potencjalne problemy techniczne (brak testów, globalne stany, brak walidacji, itp.),
3. zaproponuj 5–7 kroków refaktoryzacji w kierunku Laravel 12, przy minimalnym ryzyku regresji.

Dostajesz plan migrowania modułu, a nie randomowy refactor „na raz”.

Refaktoryzacja pojedynczej funkcji → serwis w Laravel 12

Kiedy plan jest gotowy, bierzesz konkretny fragment legacy i każesz ChatGPT 5.1 przepisać go w sensowną klasę.

Przykład legacy:

// legacy_invoice_helper.php

function generate_invoice_number($userId)
{
    $prefix = 'INV-';
    $date   = date('Ymd');
    $random = rand(1000, 9999);

    return $prefix . $userId . '-' . $date . '-' . $random;
}

Prompt refaktoryzacyjny

Poniżej masz legacy funkcję w czystym PHP:

[Wklej funkcję]

Zadanie:

1. Przepisz to do klasy serwisowej w Laravel 12 App\Services\InvoiceNumberGenerator,
2. użyj PHP 8.2+, pełne typowanie, PSR-12,
3. zamiast rand() użyj interfejsu do generowania losowych liczb (wstrzykiwanego, żeby dało się to testować),
4. dodaj przykładowy test w Pest, który sprawdza format numeru faktury.

Nie zmieniaj logiki biznesowej (format numeru), tylko sposób jej implementacji.

Przykładowy efekt – klasa serwisowa

<?php

declare(strict_types=1);

namespace App\Services;

use Carbon\CarbonInterface;

interface RandomNumberGenerator
{
    public function generate(int $min, int $max): int;
}

<?php

declare(strict_types=1);

namespace App\Services;

use Carbon\CarbonInterface;

/**
 * Generator numerów faktur w nowej architekturze Laravel 12.
 */
class InvoiceNumberGenerator
{
    public function __construct(
        private readonly RandomNumberGenerator $randomNumberGenerator,
        private readonly CarbonInterface $clock,
    ) {
    }

    public function generateForUser(int $userId): string
    {
        $prefix = 'INV-';
        $date   = $this->clock->format('Ymd');
        $random = $this->randomNumberGenerator->generate(1000, 9999);

        return sprintf('%s%d-%s-%d', $prefix, $userId, $date, $random);
    }
}

Test w Pest (przykład)

<?php

declare(strict_types=1);

use App\Services\InvoiceNumberGenerator;
use App\Services\RandomNumberGenerator;
use Carbon\CarbonImmutable;

it('generates invoice number in expected format', function (): void {
    $fakeRandom = new class implements RandomNumberGenerator {
        public function generate(int $min, int $max): int
        {
            return 1234; // deterministyczna wartość do testów
        }
    };

    $clock = CarbonImmutable::create(2025, 11, 19);

    $generator = new InvoiceNumberGenerator($fakeRandom, $clock);

    $result = $generator->generateForUser(42);

    expect($result)->toBe('INV-42-20251119-1234');
});

Takie podejście pozwala krok po kroku wyciągać logikę z legacy w kierunku czystych, testowalnych klas.

Planowana migracja całego modułu – iteracje zamiast jednego „big bang”

Kiedy masz już kilka takich klas, możesz poprosić ChatGPT 5.1 o:

• rewizję planu,
• propozycję podziału migracji na kolejne sprinty,
• listę testów regresyjnych.

Przykładowy prompt – iteracje

Na podstawie planu migracji i kilku już przepisanych fragmentów (klasy serwisowe, testy):

Zadanie:

1. Zaproponuj podział migracji modułu fakturowania na 3 iteracje,
2. dla każdej iteracji:

• wypisz zakres (co migrujemy),
• ryzyka,
• sugerowane testy regresyjne (manualne + automatyczne),

1. uwzględnij, że system jest produkcyjny i nie możemy zrobić Big Bang Re-write.

Dostajesz zdroworozsądkowy plan, który można pokazać PM-owi / klientowi.

Scenariusz 3: Wdrożenie nowej funkcjonalności krok po kroku (Laravel 12)

Trzeci scenariusz: „normalna” codzienna robota – dostajesz ticket typu „dodaj system kuponów rabatowych”. Zamiast lecieć z głowy, robisz to w kontrolowanej współpracy z ChatGPT 5.1.

Ustrukturyzowanie ticketu z Jiry / od PM-a

Dostajesz opis biznesowy, często chaotyczny. Najpierw prosisz ChatGPT o uporządkowanie.

Prompt – analiza ticketu

Laravel 12, PHP 8.2+.

Poniżej masz opis ticketu (nieuporządkowany):

[Wklej opis z Jiry / slacka / maila]

Zadanie:

1. Zamień to na zestaw jasno opisanych wymagań funkcjonalnych (lista punktów),
2. zaproponuj kryteria akceptacji (Given/When/Then lub w prostych punktach),
3. wypisz potencjalne edge case’y, o które powinienem dopytać produktowca.

Masz już klarowny opis, zamiast „ściany tekstu”.

Projekt modelu danych i kontraktów API

Następnie prosisz o szczegółowy plan pod Laravel 12.

Prompt – projekt danych

Na podstawie tych wymagań funkcjonalnych:

[Wklej listę wymagań]

Laravel 12, aplikacja e-commerce.

Zadanie:

1. Zaproponuj model danych pod system kuponów rabatowych:

• tabele,
• pola,
• relacje z Order i User.

1. Zaproponuj, jak powinno wyglądać API:

• endpoint do sprawdzania ważności kuponu,
• endpoint do przypisywania kuponu do zamówienia.

Nie generuj jeszcze kodu – tylko model danych i opis endpointów (metoda, ścieżka, parametry, odpowiedzi).

Dostajesz plan tabel i endpointów – możesz go jeszcze obgadać z zespołem.

Kodowanie modułu w porcjach – migracje, logika, testy

Kiedy plan jest uzgodniony, prosisz o kolejne kawałki.

Krok 1 – migracje

Na podstawie zaproponowanego modelu danych dla kuponów:

[Wklej model danych, który zaakceptowałeś]

Laravel 12, PHP 8.2+, PSR-12.

Zadanie:
1. Przygotuj migracje dla tabel związanych z kuponami,
2. zwróć uwagę na:
   - unikalność kodów,
   - indeksy pod wyszukiwanie aktywnych kuponów,
   - możliwość przyszłej rozbudowy (np. ograniczenia per user).

Pokaż gotowe klasy migracji z minimalnymi komentarzami przy kluczowych decyzjach.

Krok 2 – logika aplikacyjna (np. serwis CouponValidator)

Laravel 12, PHP 8.2+, PSR-12, Pest.

Mamy już migracje i modele dla kuponów.

Zadanie:

1. Zaimplementuj serwis App\Services\CouponValidator, który:

• przyjmuje kod kuponu i opcjonalnie użytkownika / zamówienie,
• sprawdza:
  • czy kupon istnieje,
  • czy jest aktywny (daty, status),
  • czy nie przekroczono limitu użyć,
• zwraca wynik w postaci obiektu DTO (np. CouponValidationResult).

1. Zaproponuj testy w Pest dla tego serwisu.

Użyj pełnego typowania, prostego, czytelnego API klasy.

Krok 3 – endpointy

Mamy serwis CouponValidator oraz modele kuponów.

Zadanie:

1. Zaimplementuj endpoint POST /api/coupons/validate, który:

• przyjmuje kod kuponu i dane koszyka (np. kwotę),
• używa CouponValidator,
• zwraca:
  • czy kupon jest ważny,
  • ile klient zaoszczędzi,
  • ewentualne komunikaty błędów.

1. Użyj:

• FormRequest,
• Resource.

Dodaj test feature w Pest dla scenariuszy: poprawny kupon, nieważny kupon, kupon po terminie.

Refaktoryzacja i „code review” przez model

Na koniec możesz poprosić ChatGPT 5.1 o przegląd gotowego kodu.

Prompt – pseudo code review

Poniżej masz mój kod modułu kuponów w Laravel 12:

[Wklej serwis, kontroler, część testów]

Zadanie:

1. Oceń ten kod według kryteriów:

• czytelność,
• testowalność,
• wydajność,
• bezpieczeństwo,

1. wypisz listę konkretnych sugestii poprawek (maks. 10),
2. dla krytycznych sugestii pokaż fragment kodu „przed” i „po”.

Nie zmieniaj stacku technologicznego, nie wprowadzaj DDD na siłę – skup się na tym, co daje realną wartość.

Wyniki traktujesz jak input do własnego refactoringu – nie bezkrytycznie.

Dokumentacja i komunikacja z biznesem

Na końcu cyklu prosisz o:

• krótkie podsumowanie techniczne,
• opis funkcjonalności „dla ludzi” (PM, marketing, support),
• listę ryzyk i rzeczy do monitorowania po wdrożeniu.

Prompt – podsumowanie dla PM

Na podstawie całej naszej pracy nad modułem kuponów (załączony kod i opisy):

Zadanie:

1. Napisz krótkie podsumowanie techniczne dla Product Managera (max. 10 zdań),
2. wypisz listę ryzyk technicznych związanych z tym wdrożeniem,
3. zaproponuj, co powinniśmy monitorować po wdrożeniu (metryki, logi, alerty).

To zamyka pętlę: od ticketu → przez projekt → implementację → testy → komunikację.

Podsumowanie

W tych trzech scenariuszach widać wspólny schemat pracy z ChatGPT 5.1 w Laravel 12:

• nie zaczynasz od „napisz mi kod”, tylko od wymagań i planu,
• traktujesz model jak partnera do myślenia i projektowania,
• kod generujesz w małych, kontrolowalnych porcjach,
• na koniec wykorzystujesz go do testów, refaktoryzacji i dokumentacji.

Z takim podejściem ChatGPT 5.1 przestaje być „magicznym generatorem snippetów”, a staje się bardzo konkret narzędziem do ogarniania całych feature’ów i modułów w Laravel 12 – od pierwszego ticketu po gotowy kod z testami.

Integracja ChatGPT 5.1 z narzędziami programisty PHP i Laravel 12

Żeby ChatGPT 5.1 dla programistów PHP i Laravel dawał maksimum wartości, nie wystarczy „gadać z nim w przeglądarce”. Największy efekt jest wtedy, gdy wpinasz go w swój realny workflow:

• przeglądarka (ChatGPT) = centrum dowodzenia,
• IDE (VS Code / PhpStorm) = praca na kodzie live,
• własne skrypty / CLI w PHP = automatyzacja powtarzalnych zadań z użyciem API GPT-5.1.

Poniżej ogarniemy każdy z tych poziomów – z naciskiem na Laravel 12 i realne zastosowania.

ChatGPT 5.1 w przeglądarce jako „centralny senior”

Organizacja wątków – mniej chaosu, więcej kontekstu

Jeśli używasz ChatGPT „na pałę”, jeden wątek do wszystkiego, to nic dziwnego, że model czasem zaczyna mieszać. Zrób sobie prostą dyscyplinę:

Jeden projekt = jeden (lub kilka) dedykowanych wątków

Praktyka, która działa:

• prefix w tytułach wątków, np.
  • L12 – SaaS projekty – architektura,
  • L12 – Billing – bugi produkcyjne,
  • L12 – Legacy CRM – refaktoryzacja.
• W wątku nie skaczesz między projektem A i projektem B – wtedy kontekst (wcześniejsze wiadomości) faktycznie pomaga, zamiast przeszkadzać.

W efekcie GPT-5.1 może korzystać z całej historii rozmowy i lepiej kojarzyć, jakie założenia przyjęliście wcześniej (np. konkretny wzorzec architektury dla danego projektu).

Wklejaj kod porcjami, nie całe repo

Zasada praktyczna:

• mały plik / klasa – ok, wklejasz w całości,
• większy moduł – dzielisz: osobno serwis, osobno kontroler, osobno testy,
• i za każdym razem dodajesz 1–2 zdania kontekstu: „to jest serwis do X”, „to jest test, który odtwarza buga”.

Dzięki temu GPT-5.1 nie dostaje ściany szumu, tylko sensowny, strawny fragment z opisem, po co mu to.

Praca na diffach i PR-ach – ChatGPT jako reviewer

Świetny use-case: code review PR-a z pomocą ChatGPT.

Jak wklejać diff

1. Z Git-a wyciągasz diff w formie unified (git diff lub diff z PR-a).
2. Wklejasz do ChatGPT z promptem w stylu:

Laravel 12, PHP 8.2+.

Poniżej masz diff (PR) w naszym projekcie.
Zadanie:

1. Wypisz potencjalne bugi lub regresje,
2. zwróć uwagę na bezpieczeństwo (SQL, XSS, auth, uprawnienia),
3. zasugeruj uproszczenia kodu, jeśli są oczywiste,
4. nie zmieniaj technologii ani architektury – skup się na jakości kodu.

[Wklej diff]

3. Traktujesz odpowiedź jak drugi komplet oczu – nie jako wyrocznię.

Możesz także poprosić o propozycję opisu PR-a:

Na podstawie tego diffu wygeneruj opis PR-a:

• krótkie podsumowanie,
• lista zmian technicznych,
• potencjalne ryzyka,
• jak testować.

Integracja ChatGPT 5.1 z IDE (VS Code / PhpStorm)

Nie będę tu reklamował konkretnych wtyczek, bo rynek zmienia się szybciej niż Laravel minor release 😄 – ale większość rozszerzeń robi trzy rzeczy:

1. wysyła zaznaczony kod do ChatGPT / API GPT-5.1,
2. wyświetla odpowiedź inline / w panelu,
3. pozwala z jednego kliknięcia wkleić poprawkę.

Typowe scenariusze użycia w IDE

Szybka refaktoryzacja zaznaczonego fragmentu

Workflow:

1. Zaznaczasz metodę / fragment klasy w serwisie.
2. Używasz skrótu „wyślij do ChatGPT” z promptem typu: „Przepisz ten fragment w bardziej czytelny sposób, zachowując logikę. Laravel 12, PHP 8.2, PSR-12, pełne typowanie. Zaproponuj tylko gotowy kod, bez komentarza.”
3. Porównujesz diff, nie wklejasz bezmyślnie.

Generowanie testów wprost z kodu

1. Zaznaczasz serwis / kontroler.
2. Prompt: „Na podstawie tego kodu zaproponuj zestaw testów w Pest (Laravel 12). Pokaż gotowe testy, używając fabryk. Skup się na scenariuszach:
   • sukces,
   • walidacja,
   • brak uprawnień,
   • edge case’y.”
3. Wklejasz testy do odpowiedniego pliku i dopasowujesz do realnych fabryk/fixture’ów.

Dokumentacja z zaznaczonego fragmentu

Przydatne, gdy:

• musisz napisać docs dla integracji zewnętrznej,
• opisujesz serwis domenowy.

Prompt:

„Na podstawie zaznaczonego kodu napisz krótką dokumentację techniczną (Markdown) dla devów:

• co robi ten serwis,
• jakie ma zależności,
• jak go wywołać (przykład w Laravel 12),
• jakie są potencjalne błędy.”

Bezpieczeństwo przy używaniu wtyczek IDE

Kilka zdroworozsądkowych zasad:

• wykluczaj pliki z sekretami z wysyłania (np. .env, klucze, hasła),
• nie wysyłaj pełnych dumpów produkcyjnych danych (anonimizuj),
• nie dawaj wtyczce pełnego dostępu do całego repo, jeśli nie jest to konieczne – wystarczy zaznaczony fragment.

GPT-5.1 jest potężnym narzędziem, ale odpowiedzialność za RODO, NDA i dane klientów zostaje po Twojej stronie.

Własne CLI w PHP z API GPT-5.1 – automatyzacja pod siebie

To jest moment, w którym z programisty-konsumenta ChatGPT stajesz się programistą-budowniczym narzędzi na GPT-5.1.
Zamiast ręcznie kopiować kod do przeglądarki, możesz:

• zbudować prosty skrypt CLI w PHP,
• zintegrować go z artisan albo composer scripts,
• jednym poleceniem wysyłać plik / diff / opis do API GPT-5.1 i dostać odpowiedź w terminalu.

Co daje API GPT-5.1 z perspektywy dev-a PHP?

• model gpt-5.1 jest dostępny w API i przeznaczony m.in. do zadań koderskich, z regulowanym „wysiłkiem rozumowania” (reasoning.effort) oraz parametrem text.verbosity, który kontroluje rozwlekłość odpowiedzi.
• możesz korzystać z nowego endpointu /v1/responses, który jest polecany w nowych projektach i wspiera parametry dla reasoning/verbosity oraz narzędzia koderskie.

Minimalny klient CLI w PHP – przykład

Załóżmy, że chcesz mieć polecenie:

php bin/ai-refactor.php app/Services/UserService.php

które:

• czyta plik,
• wysyła go do GPT-5.1 z prośbą o refaktoryzację,
• wypisuje propozycję nowej wersji w terminalu.

Przygotowanie – klucz API

1. Załóż/ustaw projekt w OpenAI i wygeneruj API key.
2. Ustaw zmienną środowiskową (np. w .bashrc / .zshrc):

export OPENAI_API_KEY="sk-..."

3. Zrestartuj terminal / załaduj ustawienia.

Skrypt bin/ai-refactor.php

Przykładowy, prosty skrypt (bez zewnętrznych bibliotek):

<?php

declare(strict_types=1);

/**
 * Prosty CLI, który wysyła plik PHP do API GPT-5.1
 * z prośbą o propozycję refaktoryzacji pod Laravel 12.
 *
 * Użycie:
 *   php bin/ai-refactor.php app/Services/UserService.php
 */

const OPENAI_API_URL = 'https://api.openai.com/v1/responses';

$filePath = $argv[1] ?? null;

if ($filePath === null) {
    fwrite(STDERR, "Użycie: php bin/ai-refactor.php <ścieżka_do_pliku>\n");
    exit(1);
}

if (! is_file($filePath)) {
    fwrite(STDERR, "Błąd: plik '{$filePath}' nie istnieje.\n");
    exit(1);
}

$apiKey = getenv('OPENAI_API_KEY');

if (! $apiKey) {
    fwrite(STDERR, "Błąd: brak zmiennej środowiskowej OPENAI_API_KEY.\n");
    exit(1);
}

$code = file_get_contents($filePath);

if ($code === false) {
    fwrite(STDERR, "Błąd: nie udało się odczytać pliku.\n");
    exit(1);
}

// Budujemy prompt z kontekstem Laravel 12 + oczekiwania wobec odpowiedzi.
$prompt = <<<PROMPT
Pracujesz jako senior PHP / Laravel 12 w dużym projekcie produkcyjnym.

Oto plik PHP (Laravel 12):

--- FILE START ---
{$code}
--- FILE END ---

Zadanie:
1. Zaproponuj ulepszoną wersję tego pliku:
   - zachowaj logikę biznesową,
   - popraw czytelność, testowalność i zgodność z PSR-12,
   - użyj pełnego typowania (PHP 8.2+).
2. Jeśli to ma sens, zaproponuj wydzielenie części logiki do osobnych metod/klas (krótko wyjaśnij).
3. Na końcu wypunktuj potencjalne edge case’y, które warto przetestować.

Format odpowiedzi:
1. Najpierw krótki komentarz (max 5–7 zdań),
2. potem blok z ulepszonym kodem (jeden blok, gotowy do wklejenia),
3. na końcu lista punktowana edge case’ów.

PROMPT;

$payload = [
    'model' => 'gpt-5.1',
    // Można też podać strukturę rozmowy, ale dla prostoty używamy pojedynczego inputu-tekstu.
    'input' => $prompt,
    // Ustawiamy niewielki wysiłek rozumowania – szybciej, ale nadal „myśląco”.
    'reasoning' => [
        'effort' => 'low', // 'none', 'low', 'medium', 'high' – patrz dokumentacja.
    ],
    // Średnia rozwlekłość odpowiedzi – dobre do kodu z komentarzem.
    'text' => [
        'verbosity' => 'medium', // 'low', 'medium', 'high'
    ],
];

$ch = curl_init(OPENAI_API_URL);

curl_setopt_array($ch, [
    CURLOPT_HTTPHEADER      => [
        'Content-Type: application/json',
        'Authorization: Bearer ' . $apiKey,
    ],
    CURLOPT_POST            => true,
    CURLOPT_RETURNTRANSFER  => true,
    CURLOPT_TIMEOUT         => 60,
    CURLOPT_POSTFIELDS      => json_encode($payload, JSON_THROW_ON_ERROR),
]);

$responseBody = curl_exec($ch);

if ($responseBody === false) {
    fwrite(STDERR, "Błąd HTTP: " . curl_error($ch) . "\n");
    exit(1);
}

$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);

if ($httpCode >= 400) {
    fwrite(STDERR, "Błąd API (HTTP {$httpCode}): {$responseBody}\n");
    exit(1);
}

// Uwaga: struktura odpowiedzi /v1/responses może się zmieniać,
// dlatego na początek wypisujemy surową odpowiedź.
// W docelowym kodzie warto sparsować JSON i wyciągnąć sam tekst.
$data = json_decode($responseBody, true);

if (json_last_error() !== JSON_ERROR_NONE) {
    fwrite(STDERR, "Odpowiedź nie jest poprawnym JSON-em:\n{$responseBody}\n");
    exit(1);
}

// Minimalnie uprzejme wyświetlenie – jeśli OpenAI doda pole output_text, użyj go.
if (isset($data['output_text'])) {
    // Wygodne pole udostępniane przez niektóre SDK/warstwy API.
    fwrite(STDOUT, $data['output_text'] . "\n");
} else {
    // Fallback – pokaż „ładnie” cały JSON.
    fwrite(STDOUT, json_encode($data, JSON_PRETTY_PRINT | JSON_UNESCAPED_UNICODE) . "\n");
}

Kilka uwag:

• To jest minimalny, świadomie prosty przykład – celem jest pokazanie schematu, nie perfekcyjna obsługa całego API.
• W prawdziwym projekcie:
  • sensownie sparsujesz strukturę odpowiedzi wg aktualnej dokumentacji,
  • dodasz logowanie błędów, retry, może prosty cache promptów.
• Parametry reasoning.effort i text.verbosity są typowe dla GPT-5.1 i pozwalają sterować głębokością myślenia i rozwlekłością odpowiedzi.

Integracja z artisan / composer – realny workflow

Gdy masz już działający skrypt, możesz:

Dodać alias w composer.json

{
  "scripts": {
    "ai:refactor": "php bin/ai-refactor.php"
  }
}

I wtedy:

composer ai:refactor app/Services/UserService.php

Zrobić komendę artisan

Możesz też zbudować Artisan Command, które:

• przyjmuje nazwę klasy / pliku,
• odnajduje ją w app/,
• wysyła do GPT-5.1 dokładnie tak jak powyższy skrypt,
• wypisuje wynik albo zapisuje do storage/app/ai-suggestions/....

To już bardziej rozbudowany temat, ale wzorzec jest ten sam: czytasz plik → budujesz prompt → wysyłasz do GPT-5.1 → pokazujesz wynik.

Zaawansowane techniki promptowania z GPT-5.1 w pracy programisty PHP / Laravel 12

Proste „napisz mi kontroler” już ogarnęliśmy. Teraz wjeżdża poziom senior: jak sprawić, żeby ChatGPT 5.1 dla programistów PHP i Laravel nie tylko pisał kod, ale też projektował, krytykował i uczył się Twojego stylu.

W tle pamiętaj, że GPT-5.1 daje większą sterowalność (reasoning.effort, verbosity, lepsze podążanie za instrukcjami), więc zaawansowane techniki promptowania naprawdę robią różnicę.

Role prompting – „zatrudnij sobie seniora Laravel 12”

Role prompting to nic innego jak bardzo jasne określenie, kim ma być model w danej rozmowie: senior Laravelowiec, security engineer, performance freak, reviewer testów itd. Oficjalne poradniki podkreślają, że dobrze zdefiniowana rola + jasne zadanie to jeden z najlepszych „boostów” jakości odpowiedzi.

Bazowa rola – senior PHP / Laravel 12

Możesz ją używać jako wstęp niemal do każdego wątku technicznego:

Jesteś seniorem PHP / Laravel 12, który od lat pracuje nad dużymi systemami produkcyjnymi (SaaS, e-commerce, systemy finansowe).

Założenia:

• używamy PHP 8.2+, Laravel 12,
• stosujemy PSR-12 i pełne typowanie,
• preferujemy prostą, czytelną architekturę nad „sprytne” hacki,
• testy piszemy w Pest.

W swoich odpowiedziach:

• tłumacz kluczowe decyzje techniczne (krótko, konkretnie),
• zawsze sugeruj testy (Pest) dla ważniejszych fragmentów,
• zwracaj uwagę na wydajność i bezpieczeństwo (SQL, XSS, auth, uprawnienia).

To możesz mieć zapisane jako „wklejkę” otwierającą każdy nowy wątek związany z projektem.

Rola specjalistyczna – np. ekspert od bezpieczeństwa Laravel

Czasem chcesz, żeby model patrzył na kod tylko przez jeden filtr – np. bezpieczeństwo. GPT-5.1 naprawdę potrafi przełączyć tryb, jeśli rola jest dobrze zadana.

Przykład:

Jesteś ekspertem od bezpieczeństwa w PHP i Laravel 12 (aplikacje webowe, REST API, systemy finansowe).

Twoim zadaniem jest:

• znajdować luki bezpieczeństwa,
• minimalizować powierzchnię ataku,
• nie skupiać się na kosmetyce kodu, tylko na realnych ryzykach (SQL injection, XSS, CSRF, auth, uprawnienia, masowe przypisanie, injection w logice biznesowej).

Za chwilę wkleję kod – Twoim priorytetem będzie BEZPIECZEŃSTWO, nie estetyka.

Potem dopiero wklejasz kod + konkretne polecenie:

Poniżej masz kontroler w Laravel 12:

[tu kod]

Zadanie:
1. Znajdź potencjalne problemy bezpieczeństwa,
2. wyjaśnij, dlaczego są groźne,
3. zaproponuj poprawki (konkretny kod),
4. zaproponuj testy (Pest), które wykryłyby te problemy.

Rola code reviewera dla PR-ów

Inny wariant roli:

Jesteś seniorem PHP / Laravel 12, który robi code review w dużym projekcie.

Twoje priorytety:

• czytelność,
• testowalność,
• wydajność,
• bezpieczeństwo,
• utrzymanie spójności architektury.

Nie przepisuj wszystkiego na nowo. Szukaj miejsc, gdzie:

• kod jest nadmiernie skomplikowany,
• brakuje testów,
• są „dziury” w walidacji lub autoryzacji.

I dopiero wtedy:

Poniżej masz diff z PR-a:

[diff]

Zadanie:

1. Wypisz listę problemów / uwag (max 15),
2. oznacz, które są krytyczne, a które kosmetyczne,
3. dla 3 najważniejszych problemów zaproponuj konkretne zmiany w kodzie (z fragmentami „przed” i „po”).

Few-shot prompting – naucz GPT-5.1 Twojego stylu (PHP / Laravel)

Few-shot prompting to pokazywanie modelowi 1–3 przykładów, jak coś ma wyglądać, a dopiero potem proszenie o wygenerowanie kolejnego przykładu „w tym samym stylu”. Oficjalne materiały sugerują to jako jedną z kluczowych technik przy bardziej złożonych zadaniach.

Uczenie stylu serwisów / klas

Załóżmy, że masz swój ulubiony pattern serwisów domenowych w Laravel 12. Pokazujesz GPT-5.1 realny przykład z projektu (lekko zanonimizowany) i prosisz o analogiczny dla innej domeny.

Przykład – serwis do tworzenia projektu

<?php

declare(strict_types=1);

namespace App\Domain\Projects\Services;

use App\Domain\Projects\DataTransferObjects\ProjectData;
use App\Models\Organization;
use App\Models\Project;

final class CreateProjectService
{
    public function handle(Organization $organization, ProjectData $data): Project
    {
        // Tworzymy projekt w kontekście organizacji
        /** @var Project $project */
        $project = $organization->projects()->create([
            'name'        => $data->name,
            'description' => $data->description,
            'due_date'    => $data->dueDate,
            'owner_id'    => $data->ownerId,
        ]);

        return $project;
    }
}

Few-shot prompt – „zrób to samo, ale dla zadań (Task)”

Laravel 12, PHP 8.2+, PSR-12, pełne typowanie.

Poniżej masz przykład serwisu, który tworzy projekt:

[tu wklej klasę CreateProjectService]

Zadanie:
1. Na podstawie powyższego przykładu stwórz serwis `CreateTaskService` w tym samym stylu (ta sama konwencja nazw, struktura, sposób mapowania DTO),
2. załóż istnienie `TaskData` (DTO) i relacji `Project::tasks()`.

Pokaż tylko kod nowego serwisu, bez komentarza tekstowego.

Model widzi konkretny wzorzec i dużo łatwiej trafia w Twój styl niż przy suchym opisie słownym.

Few-shot dla testów w Pest

To samo można zrobić z testami – pokazujesz, jak wygląda „ładny” test w Twoim projekcie, a potem prosisz o kolejne w tym stylu.

Przykładowy test – wzorzec

<?php

declare(strict_types=1);

use App\Models\Project;
use App\Models\User;
use function Pest\Laravel\actingAs;
use function Pest\Laravel\postJson;

it('allows owner to create project', function (): void {
    /** @var User $user */
    $user = User::factory()->create();

    actingAs($user, 'sanctum');

    $response = postJson('/api/projects', [
        'name'        => 'Test Project',
        'description' => 'Example',
    ]);

    $response->assertCreated()
        ->assertJsonFragment([
            'name' => 'Test Project',
        ]);

    expect(Project::query()->count())->toBe(1);
});

Few-shot prompt – nowy endpoint w tym samym stylu

Laravel 12, Pest.

Poniżej masz test feature napisany w stylu, który chcę utrzymać w całym projekcie:

[tu wklej test]

Zadanie:
1. Na podstawie powyższego stylu napisz test feature dla endpointu `POST /api/projects/{project}/tasks`,
2. zachowaj:
   - ten sam sposób korzystania z `actingAs` i fabryk,
   - podobny poziom szczegółowości asercji,
3. załóż istnienie modeli `Project` i `Task`.

Pokaż tylko kod testu.

Dzięki few-shot promptom GPT-5.1 „łapie” styl testów, nazewnictwo, strukturę asercji.

Decomposition & plan-first prompting – model jako architekt

W oficjalnych materiałach OpenAI bardzo mocno podkreślają: przy złożonych zadaniach najpierw plan, potem kod. GPT-5.1 jest szczególnie dobry w takim trybie, bo ma lepsze sterowanie rozumowaniem (reasoning.effort) i parametr verbosity, który wpływa na długość/szczegółowość odpowiedzi.

Wzorzec – dwa etapy: „najpierw architekt, potem koder”

Etap 1 – prosisz o plan (bez kodu)

Laravel 12, PHP 8.2+.

Chcę dodać moduł rozliczeń (Billing) do aplikacji SaaS.
Założenia:

• użytkownicy mają subskrypcje,
• rozliczenia miesięczne,
• integracja z zewnętrznym procesorem płatności,
• musimy mieć historię invoice’ów i płatności.

Zadanie:
Jako senior Laravel 12 zaproponuj plan implementacji modułu w maks. 10 krokach, bez pisania kodu.
Uwzględnij:

• strukturę modeli i relacji,
• główne serwisy / klasy domenowe,
• eventy i joby,
• miejsca, gdzie będą potrzebne testy integracyjne.

Na tym etapie mówisz wyraźnie: zero kodu, tylko plan. To bardzo przyspiesza sensowną architekturę.

Etap 2 – implementacja krok po kroku

Po akceptacji planu:

Świetnie, zaakceptujmy plan.

Teraz zrealizuj krok 1 tego planu:

• migracje i modele Eloquent dla Billing.

Laravel 12, PHP 8.2+, PSR-12, pełne typowanie.

Pokaż:

1. Migracje,
2. Modele,
3. krótkie wyjaśnienie kluczowych decyzji (pola, indeksy).

Nie ruszaj jeszcze endpointów ani serwisów.

Potem:

Przejdźmy do kroku 2: warstwa serwisów Billing.

[tu doprecyzowujesz wymagania]

Świadome sterowanie reasoning.effort i verbosity (API)

Jeśli używasz API GPT-5.1 (np. w CLI lub narzędziu wewnętrznym), warto świadomie sterować parametrami:

• reasoning.effort – jak dużo „myślenia” model wykonuje,
• text.verbosity – jak bardzo odpowiedź ma być rozgadana / szczegółowa.

Praktyczna heurystyka:

• Proste rzeczy (mały helper, pojedyncza migracja)
  • reasoning.effort: "none" / "low"
  • text.verbosity: "low" / "medium"
• Złożone rzeczy (architektura modułu, skomplikowany bug)
  • reasoning.effort: "medium" / "high"
  • text.verbosity: "medium" / "high"

Dzięki temu nie przepalasz zasobów na pierdoły, a przy „grubych” tematach pozwalasz modelowi naprawdę się wysilić.

Critic prompts – zrób z GPT-5.1 wymagającego reviewera

Czasem nie chcesz, żeby model coś generował – chcesz, żeby skrytykował Twój kod/projekt. Oficjalne przewodniki sugerują, żeby w takich przypadkach bardzo jasno opisać kryteria oceny i format odpowiedzi.

Krytyka kodu według konkretnych kryteriów

Prompt – code review na 4 filtry

Laravel 12, PHP 8.2+.

Poniżej masz klasę serwisową:

[tu kod]

Zadanie:
Jako senior Laravel 12 oceń ten kod według kryteriów:
1. Czytelność,
2. Testowalność,
3. Wydajność,
4. Bezpieczeństwo.

Dla każdego kryterium:
- daj ocenę w skali 1–10,
- wypisz maks. 5 konkretnych uwag / problemów,
- zaproponuj konkretne poprawki (krótkie fragmenty kodu).

Na końcu wypisz 3 najważniejsze rzeczy, które powinienem poprawić jako pierwsze.

Dzięki takiemu promptowi dostajesz konkretną listę problemów, a nie ogólne „kod mógłby być lepiej napisany”.

Krytyka architektury modułu (nie tylko pojedynczej klasy)

Prompt – ocena modułu

Laravel 12, modular monolith.

Poniżej masz opis architektury modułu (struktura katalogów, główne klasy, zależności):

[tu opis lub fragmenty kodu]

Zadanie:
1. Oceń tę architekturę pod kątem:
   - spójności domenowej,
   - separacji odpowiedzialności,
   - możliwości rozszerzania,
   - ryzyka „god class” / nadmiernych zależności.
2. Wypisz konkretne miejsca, gdzie:
   - warstwy są wymieszane,
   - moduły są zbyt mocno sprzężone,
   - logika domenowa wylądowała w niewłaściwym miejscu (np. kontroler).

Zaproponuj 3–5 zmian o największym wpływie, które można zrobić iteracyjnie (bez przepisywania wszystkiego od zera).

Tu bardziej interesuje Cię architektura, a nie konkretne linijki kodu – prompt to jasno określa.

Critic prompt, a potem „rewrite prompt” (dwustopniowo)

Zamiast od razu prosić: „przepisz mi to”, lepiej:

1. Najpierw critic prompt – niech model powie, co jest źle,
2. dopiero potem rewrite prompt – „na podstawie tej listy problemów zaproponuj poprawioną wersję”.

Przykład przepływu

Krok 1 – krytyka:

Poniżej masz mój serwis:

[tu kod]

Zadanie:
1. Znajdź problemy według kryteriów: czytelność, testowalność, bezpieczeństwo,
2. wypisz listę problemów (max 10), bez proponowania kodu.

Krok 2 – przepisanie kodu:

Na podstawie powyższej listy problemów przepisz serwis tak, aby:
- usunąć wskazane problemy,
- zachować logikę biznesową,
- nie zmieniać publicznego API klasy (sygnatur metod).

Pokaż gotowy kod, z krótkimi komentarzami przy najważniejszych zmianach.

Taki dwustopniowy flow daje Ci lepszą kontrolę – najpierw rozumiesz co jest nie tak, potem dopiero dotykasz kodu.

Bezpieczeństwo, jakość i ryzyka używania ChatGPT 5.1 w kodzie PHP / Laravel 12

ChatGPT 5.1 potrafi Ci realnie przyspieszyć robotę, ale jeśli zaczniesz bezrefleksyjnie kopiować kod do produkcji, to prędzej czy później wylądujesz z pięknym incydentem: wyciek danych, podatne endpointy, albo „magiczny” bug, którego nikt nie rozumie.

Ta część to kubeł zimnej wody: jak bezpiecznie i mądrze używać ChatGPT 5.1 w projektach Laravel 12.

Dane wrażliwe i tajemnice firmowe – czego nie wrzucać do ChatGPT

Nie karm modelu rzeczami, których nie pokazałbyś klientowi / prawnikowi

Zasada prostsza niż PSR-12:

Jeśli nie możesz tego spokojnie pokazać klientowi / compliance / prawnikowi – nie wrzucaj tego do chatu.

W szczególności nie wrzucasz:

• danych osobowych klientów (PESEL, adresy, pełne maile z danymi),
• fragmentów .env (klucze API, hasła do DB, dane do bramek płatności),
• całych dumpów z produkcji (logi, zrzuty baz, payloady z produkcji),
• dokumentów objętych NDA (specyfikacje, wewnętrzne procedury).

Zamiast tego:

• anonimizujesz dane (np. user_1@example.com zamiast realnego maila),
• maskujesz identyfikatory (12345 → USER_ID),
• pokazujesz tylko fragmenty kodu, nie całe repo z configami.

Przykład złej praktyki:

Tu masz pełny plik .env, coś nie działa z konfiguracją Stripe:
[tu .env]

Przykład dobrej praktyki:

Nie działa integracja ze Stripe. Nie wklejam .env, ale:

- APP_ENV=production
- STRIPE_MODE=live
- płatności zwracają błąd 401

Poniżej masz fragment kodu integracji:
[tu kod]

Walidacja odpowiedzi – „zero trust” jako default

ChatGPT 5.1 jest mocny, ale nadal:

• może się mylić,
• może „halucynować” (wymyślać rzeczy, które brzmią prawdopodobnie, ale są fałszywe),
• może proponować rozwiązania niekompatybilne z Twoją wersją paczek / PHP / Laravel.

Złota zasada: nic nie trafia do produkcji bez walidacji

Zawsze:

1. Czytasz wygenerowany kod jak PR od juniora.
2. Uruchamiasz testy / aplikację lokalnie.
3. Przepuszczasz przez:
   • PHPStan / Psalm,
   • larastan (jeśli używasz),
   • testy w Pest / PHPUnit.
4. Myślisz o konsekwencjach (wydajność, bezpieczeństwo, edge case’y).

Jeśli ChatGPT wygeneruje coś takiego:

User::where('email', $email)->first()->update([...]);

To powinno Ci się od razu zapalić w głowie:

• a co jeśli first() zwróci null?
• czemu nie ma transakcji?
• czemu update jest tak luźno napisany?

Model nie ma „instynktu samozachowawczego”. Ty masz.

Bezpieczeństwo aplikacji Laravel 12 a kod z ChatGPT

Typowe niebezpieczne miejsca w kodzie generowanym przez AI

Kilka typów problemów, na które musisz patrzeć jak sokół:

1. Masowe przypisanie (mass assignment)

Częsty błąd:

Project::create($request->all());

Ryzyko:

• ktoś dorzuca pole, którego nie przewidziałeś (is_admin, role, balance),
• jeśli fillable/guarded są źle ustawione – masz problem.

Bezpieczniejszy wzorzec:

$validated = $request->validated();

Project::create([
    'name'        => $validated['name'],
    'description' => $validated['description'] ?? null,
    'due_date'    => $validated['due_date'] ?? null,
]);

W promptach warto wprost wymagać unikania ->all() i ->input() bez walidacji:

2. Autoryzacja i uprawnienia – brak sprawdzeń

Model często generuje kod typu:

public function update(Project $project, Request $request)
{
    $project->update($request->validated());

    return new ProjectResource($project);
}

I nigdzie:

• nie sprawdza, czy użytkownik może aktualizować ten projekt,
• nie używa Gate/Policy.

Pilnuj, żeby w promptach zawsze wymuszać autoryzację:

Załóż, że w projekcie używamy policy dla Project.
W kontrolerze korzystaj z $this->authorize(’update’, $project).

I potem w odpowiedzi spodziewasz się:

$this->authorize('update', $project);

3. SQL injection / niebezpieczne zapytania

GPT zwykle używa Query Buildera / Eloquent, ale czasem może podrzucić:

DB::select("SELECT * FROM users WHERE email = '$email'");

Albo:

DB::statement("DELETE FROM logs WHERE created_at < '$date'");

Ty musisz od razu to przechwycić i poprawić na:

DB::select('SELECT * FROM users WHERE email = ?', [$email]);

lub – lepiej – na Eloquent, jeśli to CRUD na modelach.

4. Dane wejściowe „na dziko” w Blade / HTML

Kolejny klasyk: wkładanie wartości do widoków bez sanity checku.

Źle:

{!! $user->name !!}

Jeśli nie masz pewności, że to bezpieczne – to prosta droga do XSS.

Domyślne {{ $user->name }} jest dużo bezpieczniejsze, bo escapuje HTML.

W promptach możesz wymuszać:

W widokach Blade stosuj {{ }} zamiast {!! !!}, chyba że wyraźnie proszę inaczej.

Jakość kodu – jak nie zrobić sobie „AI spaghetti”

Ryzyka architektoniczne

ChatGPT 5.1 ma jedną „wadę uboczną”: potrafi produkować bardzo sprytne, ale mało czytelne konstrukcje, jeśli nie postawisz granicy.

Typowe pułapki:

• wrzucanie wszystkiego w jedną klasę (serwis-godzilla),
• nadużywanie statycznych helperów,
• nadmiar „magii” (dynamiczne wywołania, refleksja, __call, itp.),
• zbyt ogólne nazwy (Manager, Helper, Service bez konkretu).

Jak się przed tym bronić w promptach

Wręcz wpisz to modelowi do głowy:

Unikaj „magicznych” rozwiązań.
Preferuj proste, jawne klasy o wąskiej odpowiedzialności.
Nie twórz klas typu SomethingManager lub SomethingHelper bez konkretu w nazwie.

A potem patrz, czy się słucha. Jak zacznie generować takie wynalazki – popraw prompt i kod.

Antywzorce korzystania z ChatGPT 5.1 w projektach PHP / Laravel

1. „Ctrl+C → Ctrl+V do produkcji”

Czyli:

• prompt → kod → commit → deploy.

Bez:

• testów,
• code review,
• analizy.

To jest proszenie się o problemy.

Jak powinno być:

• prompt → kod,
• lokalny przegląd (Twój),
• PR / code review (człowiek),
• testy,
• dopiero wtedy merge.

2. „Generuj mi cały moduł na raz”

Prośba typu:

„Napisz cały moduł fakturowania z integracją z Stripe, wszystkimi endpointami, testami i dokumentacją.”

Efekt:

• ściana kodu,
• klasa InvoiceService na 400 linii,
• masa założeń, które nie pasują do Twojej domeny.

Lepiej:

• Plan (jak w poprzednich częściach):
  • osobny prompt: „Zaproponuj plan modułu fakturowania (bez kodu)”,
• później:
  • migracje,
  • serwisy,
  • endpointy,
  • testy,
  • dokumentacja – każde osobnym krokiem.

3. „AI wie lepiej niż ja”

Jeśli łapiesz się na zdaniu:

„Nie rozumiem co on tu zrobił, ale wygląda mądrze, to pewnie tak ma być.”

…to czerwony alarm. Twoim celem jest rozumieć, co trafia do produkcji. Jeśli odpowiedź jest zbyt skomplikowana:

• prosisz o uproszczenie:

To jest zbyt skomplikowane jak na ten przypadek.
Zapropnuj prostsze rozwiązanie, nawet kosztem „sprytu”.

albo o tłumaczenie:

Wyjaśnij krok po kroku, co robi ten fragment kodu, jakbym był nową osobą w projekcie.

4. „Zmienię tech stack, bo AI tak powiedziało”

Model może sugerować:

• inne biblioteki,
• inne wzorce,
• inne podejścia („zrób to jako mikroserwis, bo czemu nie”).

Ty odpowiadasz za:

• spójność projektu,
• koszty utrzymania,
• zgodność z tym, co zespół ogarnia.

Jeżeli GPT 5.1 mówi:

„Najlepiej byłoby przepisać to na event sourcing / CQRS / mikroserwisy / GraphQL.”

To Ty musisz zdecydować, czy:

• to ma sens biznesowy,
• zespół to uniesie,
• pasuje do roadmapy.

Jak wpleść kwestie bezpieczeństwa i jakości w same prompty

Zamiast za każdym razem pamiętać „muszę sprawdzić X, Y, Z”, możesz wbudować to w swoje prompty.

Szablon „bezpiecznego promptu” do generowania kodu

Uzupełnij o swój kontekst:

Laravel 12, PHP 8.2+, PSR-12, pełne typowanie.

Zadanie:
[tu konkretny task: endpoint, serwis, testy, itp.]

Wymagania jakościowe:
- używaj FormRequest do walidacji,
- używaj policy / Gate do autoryzacji tam, gdzie to ma sens,
- nie używaj $request->all() – dane bierz tylko z $request->validated(),
- unikaj masowego przypisania wrażliwych pól,
- nie używaj ręcznie składanych zapytań SQL – jeśli musisz, użyj wiązanych parametrów,
- w widokach Blade korzystaj z {{ }} zamiast {!! !!}, chyba że wyraźnie proszę inaczej.

Na końcu odpowiedzi wypisz:
1. potencjalne ryzyka bezpieczeństwa, które widzisz,
2. edge case’y, o które powinienem zadbać w testach.

Dzięki temu model z automatu myśli też w kategoriach bezpieczeństwa i edge case’ów, a nie tylko „żeby się kompilowało”.

Przykładowy dzień pracy programisty PHP i Laravel 12 z ChatGPT 5.1

Wyobraź sobie, że ChatGPT 5.1 to Twój stały „kolega z biurka obok” – tylko taki, który nie marudzi, nie znika na kawę i jest dostępny 24/7. Poniżej masz przykład, jak może wyglądać typowy dzień pracy mid/seniora w Laravel 12 z aktywnym użyciem ChatGPT 5.1: od porannego planowania, przez development i debugowanie, aż po dokumentację i naukę.

Poranek – plan dnia i ustawienie kontekstu w ChatGPT 5.1

Szybkie ogarnięcie zadań z Jiry / ClickUp / Trello

Masz listę ticketów na dziś, opisaną różnym poziomem chaosu:

• „poprawić walidację formularza X”,
• „dorobić raport Y”,
• „czasem wysypuje się webhook Z”.

Zamiast sortować to w głowie, wrzucasz listę do ChatGPT 5.1 (Instant lub Thinking – Thinking lepszy przy większej ilości zadań) i prosisz o uporządkowanie.

Przykładowy prompt – poranne planowanie:

Pracuję jako programista PHP / Laravel 12.

Poniżej masz listę moich zadań na dzisiaj (wyciągniętych z Jiry, trochę chaotycznych):

[lista tasków]

Zadanie:
1. Pogrupuj je tematycznie (feature / bug / tech debt),
2. zaproponuj kolejność realizacji, biorąc pod uwagę:
   - zależności techniczne,
   - potencjalny impact na biznes,
   - to, że najcięższe rzeczy wolę robić rano.
3. Dla każdego zadania podaj:
   - szacowany czas (1–2h, 2–4h, >4h),
   - 2–3 kluczowe pytania, które powinienem doprecyzować z PM-em / zespołem.

Efekt: zamiast bezmyślnej listy, masz uporządkowany plan dnia.

Ustawienie sesji – kontekst projektu Laravel 12

Na początku dnia warto założyć dedykowany wątek w ChatGPT dla danego projektu, np. L12 – SaaS projekty – 2025-11-19, wrzucić tam kontekst i rolę modelu.

Przykładowy „start dnia” w wątku projektowym:

Dzisiaj będziemy pracować nad projektem w Laravel 12.

Kontekst:
- Aplikacja SaaS do zarządzania projektami (Projects, Tasks, Comments, Attachments),
- API dla SPA (frontend w Vue),
- autoryzacja przez Laravel Sanctum,
- testy w Pest.

Założenia:
- PHP 8.2+, Laravel 12, PSR-12, pełne typowanie,
- preferujemy prostą architekturę (modular monolith),
- testy jako Pest (feature + unit).

Prośba:
1. Podsumuj ten kontekst w max. 5 punktach (żebym mógł to łatwo wkleić do kolejnych promptów),
2. Potem będę podrzucał Ci konkretne taski do ogarnięcia w trakcie dnia.

Dalej w tym wątku pracujesz wyłącznie nad tym projektem – ChatGPT 5.1 ma wtedy logiczny, spójny kontekst.

Przedpołudnie – większy feature w Laravel 12

Przekład z „języka PM” na konkretne wymagania techniczne

Ticket z Jiry zwykle jest mieszanką biznesowego żargonu, skrótów myślowych i screenów. ChatGPT 5.1 może to odcedzić do sensownych wymagań.

Przykładowy prompt – „przetłumacz PM na tech”:

Poniżej masz treść ticketu z Jiry.

[treść zgłoszenia]

Laravel 12, PHP 8.2+.

Zadanie:
1. Wyciągnij z tego listę wymagań funkcjonalnych (bullet pointy),
2. zaproponuj kryteria akceptacji (Given/When/Then albo proste punkty),
3. wypisz niejasności / miejsca, które wymagają doprecyzowania (do omówienia z PM-em).

Po odpowiedzi masz klarowną listę „co dokładnie trzeba zrobić” i listę pytań do PM-a.

Projekt techniczny – model danych, endpointy, zależności

Zanim zaczniesz pisać kod, prosisz ChatGPT 5.1 Thinking o plan techniczny.

Przykładowy prompt – specyfikacja techniczna:

Na podstawie tych wymagań:

[lista wymagań]

Laravel 12, modular monolith.

Zadanie:
1. Zaproponuj model danych (tabele, pola, relacje) potrzebny do realizacji tego feature’a,
2. zaproponuj endpointy (metoda, ścieżka, parametry, odpowiedzi),
3. wypisz w maks. 10 punktach plan implementacji tego zadania (bez pisania kodu).

Nie generuj jeszcze kodu, tylko plan architektury.

Dostajesz:

• listę tabel / kolumn,
• propozycje endpointów,
• plan kroków: migracje → modele → serwisy → endpointy → testy → dokumentacja.

Implementacja w krokach – migracje, serwis, endpointy, testy

Zamiast jednego „napisz mi cały moduł”, dzielisz robotę na logiczne etapy.

Krok 1 – migracje i modele:

Teraz zrealizuj krok 1 z planu: migracje i modele.

Założenia:

• Laravel 12, PHP 8.2+, PSR-12, pełne typowanie.

Format odpowiedzi:

1. klasy migracji,
2. modele Eloquent z relacjami,
3. krótkie wyjaśnienie kluczowych decyzji (np. indeksy, typy pól).

Nie twórz jeszcze kontrolerów ani serwisów.

Krok 2 – serwis domenowy:

Kolejny krok: serwis domenowy.

Zadanie:

1. Na podstawie modelu danych przygotuj klasę serwisową w App\Domain\... odpowiedzialną za główną logikę tego feature’a,
2. zaproponuj publiczne metody, ich parametry i typy zwrotne,
3. przygotuj przykładowe testy unitowe w Pest dla tego serwisu.

Format:

• najpierw klasa serwisowa,
• potem testy.

Krok 3 – endpointy API:

Teraz endpointy API.

Zadanie:

1. Zaimplementuj endpointy opisane w specyfikacji:

• [wymień krótko konkretne endpointy]

1. Użyj:

• FormRequest do walidacji,
• Resource do odpowiedzi,
• policy / Gate do autoryzacji (tam, gdzie potrzebne).

Format:

1. trasy w routes/api.php,
2. klasy FormRequest,
3. klasy Resource,
4. kontrolery.

Na końcu zaproponuj testy feature w Pest (pełny kod).

W efekcie masz pełen zestaw: migracje, modele, serwis, kontrolery, testy – wszystko w logice, nad którą realnie panujesz.

Popołudnie – debugowanie, bugfixy i gaszenie pożarów

Reprodukcja buga – zrozumienie problemu

Masz buga typu „czasem nie zapisuje się płatność”, logi są niejasne. Zamiast gapić się w stack trace pół godziny, wrzucasz go ChatGPT 5.1 Thinking.

Przykładowy prompt – wejście w buga:

Laravel 12, moduł płatności.

Poniżej masz logi z produkcji (zredagowane, bez danych wrażliwych):

[fragment logów + stack trace]

Zadanie:
1. Streść w max. 5 punktach, co się dzieje (Twoja hipoteza),
2. wskaż potencjalne miejsca w kodzie, gdzie warto zacząć szukać przyczyny,
3. zaproponuj plan reprodukcji buga na środowisku dev/stage (scenariusze krok po kroku).

Dostajesz sensowną hipotezę i checklistę, co sprawdzić.

Analiza kodu + stack trace

Potem dorzucasz serwis / kontroler, w którym siedzi bug.

Przykładowy prompt – analiza i poprawka:

Poniżej masz stack trace oraz klasę serwisową, której dotyczy problem.

[stack trace]
[klasa serwisowa]

Zadanie:
1. Wyjaśnij krok po kroku, co doprowadza do tego wyjątku,
2. wskaż dokładne miejsce w kodzie, które powoduje błąd,
3. zaproponuj poprawkę (konkretny kod),
4. zaproponuj test w Pest, który odtwarza ten błąd.

Założenia:
- Laravel 12, PHP 8.2+,
- nie zmieniamy technologii, tylko naprawiamy buga,
- zależy nam na minimalnej, ale solidnej zmianie.

Masz diagnozę + propozycję fixa + test odtwarzający problem.

Polowanie na edge case’y po poprawce

Po fixie warto użyć ChatGPT jako „audytora zmian”.

Przykładowy prompt – sanity check na patchu:

Poniżej masz oryginalną wersję metody oraz poprawioną:

[stary kod]
[nowy kod]

Zadanie:
1. Czy widzisz nowe edge case’y, które mogły zostać wprowadzone tą zmianą?
2. Wypisz 3–5 scenariuszy testowych (Pest), które warto dodać, żeby upewnić się, że poprawka jest stabilna.
3. Oceń, czy w tej metodzie nie przydałaby się dodatkowa walidacja / logging / obsługa wyjątków.

Pomiędzy taskami – małe rzeczy, w których ChatGPT 5.1 błyszczy

Regułki, SQL, regexy, dziwne błędy z Composerem

Zamiast za każdym razem przepalać czas na googlowanie:

• regex do parsowania Budynek 1 K.03,
• hurtowe zapytanie w MySQL 8 z grupowaniem po miesiącu,
• error z composer install na konkretnej wersji paczki,

wrzucasz do modelu (Instant w zupełności wystarczy) krótki prompt:

Mam błąd z composerem:

[log]

Zadanie:
1. Wyjaśnij, co ten błąd oznacza,
2. zaproponuj 2–3 sposoby rozwiązania (bez rozwalania całego lockfile).

Szybkie refaktoryzacje i kosmetyka

Masz kod, który działa, ale wygląda tak sobie:

if ($user->role === 'admin' || $user->role === 'manager') {
    // ...
}

Możesz poprosić:

Laravel 12.

Poniżej masz fragment kodu:

[tu kod]

Zadanie:
1. Zaproponuj prostą, czytelną refaktoryzację,
2. nie zmieniaj logiki biznesowej,
3. nie używaj „magicznych” rozwiązań ani przesadnie skomplikowanych wzorców.

I masz szybkie „odkurzanie” kodu między większymi zadaniami.

Koniec dnia – dokumentacja, podsumowanie, nauka

Changelog techniczny i podsumowanie dla biznesu

Na koniec dnia zrzucasz do ChatGPT 5.1 skrót tego, co zrobiłeś: listę PR-ów, ticketów, commitów.

Przykładowy prompt – podsumowanie dnia:

Dzisiaj zrealizowałem następujące zmiany:

• [lista PR-ów / commitów / ticketów]

Zadanie:

1. Przygotuj changelog techniczny (maks. 10 punktów),
2. przygotuj krótkie podsumowanie „dla biznesu” (2–3 akapity, zrozumiałe dla PM-a / klienta),
3. wypisz 3–5 potencjalnych ryzyk / tematów, do których powinniśmy wrócić w kolejnym sprincie.

Masz gotowy tekst do:

• CHANGELOG.md,
• komentarza w Jirze,
• maila do klienta.

Retrospekcja techniczna – co mogło być lepiej

Jeżeli chcesz potraktować ChatGPT 5.1 jak mentora:

Dzisiaj pracowałem nad:

• [opis feature’a / buga],
• [ewentualne linki do diffów / fragmentów kodu].

Zadanie:

1. Na podstawie tego, co opisałem (i kodu powyżej), wypisz 3–5 rzeczy, które mogłem zrobić lepiej od strony:

• architektury,
• testów,
• komunikacji (opisy PR-ów, ticketów).

1. Zaproponuj mi „zadanie domowe” – co mógłbym przeczytać / przećwiczyć, żeby być lepszym w tym obszarze (Laravel / PHP / architektura).

Masz mini-retro + sugestię kierunku rozwoju.

Nauka „po trochu”, a nie kursy po 30 godzin

Na koniec możesz odpalić micro-learning:

Chcę w Laravel 12 lepiej ogarniać:

• [np. architekturę heksagonalną / CQRS / event sourcing / zaawansowane kolejki]

Zadanie:

1. Wytłumacz mi to w kontekście aplikacji biznesowej (bez akademickiego bełkotu),
2. pokaż mini-przykład w Laravel 12 (kod),
3. zaproponuj 3 małe ćwiczenia, które mogę zrobić jutro w pracy na istniejącym projekcie, żeby to zastosować.

Codziennie po kilka minut i poziom wchodzi naturalnie.

Podsumowanie

Jeśli miałbym streścić cały ten artykuł w jednym zdaniu, brzmiałoby ono mniej więcej tak:
ChatGPT 5.1 nie zastąpi programisty PHP/Laravel 12 – ale może zrobić z Ciebie programistę, który robi więcej, szybciej i z mniejszą ilością głupich błędów.

Przeszliśmy przez cały „ekosystem” pracy z ChatGPT 5.1 z perspektywy dev-a:

• zrozumienie, czym ten model w ogóle jest i co potrafi,
• ustawienie go pod siebie (PHP 8.2+, Laravel 12, PSR-12, Pest, konkretny projekt),
• opanowanie sensownego promptowania (Kontekst → Zadanie → Ograniczenia → Format),
• gotowe prompty do codziennych zadań w Laravel 12,
• scenariusze end-to-end (nowy projekt, legacy, nowy feature),
• integrację z IDE i własnymi narzędziami (API, CLI, artisan),
• zaawansowane techniki (role, few-shot, critic, plan-first),
• oraz bezpieczeństwo, jakość i realne ryzyka.

Wspólny mianownik jest jeden: ChatGPT 5.1 staje się Twoim stałym partnerem, nie generatorami „magicznych snippetów”.

W praktyce oznacza to kilka konkretnych rzeczy, które możesz wdrożyć od razu:

• Przestań zadawać ogólne pytania.
  „Napisz kontroler w Laravel” to proszenie się o średni kod. Używaj schematu:
  • Kontekst projektu,
  • Dokładne zadanie,
  • Ograniczenia techniczne (Laravel 12, wersja PHP, style, polityki bezpieczeństwa),
  • Format odpowiedzi (jakie pliki, w jakiej kolejności, czy mają być testy).
• Traktuj ChatGPT 5.1 jak seniora, nie jak generator.
  Najpierw poproś o plan (architekturę, kroki), dopiero potem o kod.
  Szczególnie przy większych rzeczach: moduły billing, integracje, refaktoryzacja legacy.
• Buduj własną „ściągę z promptów” pod Laravel 12.
  Masz w artykule gotowe wzorce:
  • generowanie kontrolerów + FormRequest + Resource + testów,
  • migracje + modele + relacje,
  • serwisy domenowe,
  • jobs/events/listeners,
  • testy w Pest,
  • refaktoryzacja legacy PHP → czyste klasy,
  • debugowanie na podstawie logów + stack trace’ów.
    Warto trzymać to w jednym pliku w repo i dopasowywać do standardów zespołu.
• Wepnij ChatGPT w realny workflow, a nie tylko w przeglądarkę.
  – osobne wątki per projekt,
  – integracja z IDE do refaktoryzacji i generowania testów,
  – prosty klient CLI / artisan do analizy plików czy diffów przez API GPT-5.1.
  Wtedy ChatGPT staje się częścią procesu, a nie „czasem sobie coś wygeneruję”.
• Bezpieczeństwo i jakość to Twoja odpowiedzialność.
  Model:
  • nie zna Twoich NDA,
  • nie będzie za Ciebie myślał o RODO,
  • nie ponosi odpowiedzialności za wycieki z .env ani masowe przypisanie wrażliwych pól.
    Ty:
  • nie wrzucasz sekretów i danych wrażliwych do chatu,
  • czytasz wygenerowany kod jak PR od juniora,
  • przepuszczasz wszystko przez testy i narzędzia statycznej analizy,
  • pilnujesz autoryzacji, walidacji, mass assignment, SQL/XSS, uprawnień.

Z perspektywy programisty PHP/Laravel 12 największą wartość ChatGPT 5.1 daje tam, gdzie łączy się kilka elementów naraz:

• rozumienie domeny biznesowej (bo dostaje sensowny kontekst),
• projektowanie architektury (bo najpierw prosisz o plan),
• generowanie kodu (bo dokładnie mówisz, czego oczekujesz),
• testowanie i krytyka (bo używasz critic prompts i wymuszasz testy),
• dokumentowanie (bo każesz mu robić changelog, ADR-y, docsy pod devów i PM-ów).

To nie jest „magiczny przycisk do pisania projektów za Ciebie”.
To jest bardzo dobry multiplier Twojej pracy – im lepiej sam ogarniasz PHP/Laravel, tym więcej z niego wyciągniesz.