Po co w ogóle „prompt engineering” specjalistom IT
Różnica między zadaniem pytania a zaprojektowaniem zapytania
Model językowy można potraktować jak wyszukiwarkę: wpisać coś na szybko, nacisnąć Enter i brać to, co wyskoczy. W praktyce IT takie podejście kończy się najczęściej marnowaniem czasu, generowaniem kodu, którego nikt nie rozumie, albo odpowiedziami tak ogólnymi, że nie da się na ich podstawie podjąć decyzji. Prompt engineering to świadome projektowanie zapytań do AI tak, aby wynik dało się bezpiecznie zastosować w realnej pracy technicznej.
Przy tej samej wiedzy domenowej różnica między: „zadałem pytanie” a „zaprojektowałem zapytanie” jest ogromna. W pierwszym przypadku prosisz: „napisz skrypt do backupu w Bash”, w drugim: „jesteś seniorem Linux/DevOps, zaprojektuj skrypt do backupu katalogu X na serwer Y, z logowaniem błędów i testem dry-run, zgodnie z poniższymi standardami…”. Treść skryptu wygeneruje ten sam model, ale jakość, czytelność i bezpieczeństwo obu rozwiązań będą diametralnie różne.
Dobrze skonstruowany prompt przenosi twoją wiedzę domenową z głowy do tekstu: opisuje kontekst, ograniczenia, standardy projektowe i oczekiwaną formę wyniku. Dzięki temu model przestaje zgadywać, „o co ci chodzi”, i może sensownie pracować w ramach zdefiniowanej ramy. To nie magia, tylko inżynieria komunikacji technicznej.
Typowe zastosowania prompt engineeringu dla osób z IT
Specjaliści IT używają modeli językowych do wielu powtarzalnych, „tekstowych” zadań. Najczęstsze obszary, w których dobrze zaprojektowane prompty robią ogromną różnicę:
Debugowanie i analiza logów – wyciąganie z chaosu stack trace’ów kilku sensownych hipotez oraz planu następnych kroków; filtrowanie szumu.
Pomoc w kodowaniu – podpowiedzi kodu, generowanie testów, refaktoryzacja fragmentów, migracje między frameworkami lub wersjami bibliotek.
Projektowanie architektury – porównywanie wariantów, analiza kompromisów, wypunktowanie ryzyk w konkretnym kontekście systemu.
DevOps / SRE – analiza konfiguracji CI/CD, manifestów Kubernetes, plików Terraform, polityk bezpieczeństwa, logów z produkcji.
Komunikacja z biznesem – tłumaczenie żargonu technicznego na język zrozumiały dla Product Ownera, tworzenie zarysów maili, user stories, notatek z analizy.
W każdym z tych zastosowań jakość efektu nie zależy wyłącznie od modelu. Równie mocno zależy od tego, jak dokładnie opiszesz problem, jak zadasz pytanie i czy wyraźnie określisz, w jakiej formie chcesz otrzymać wynik.
Co AI potrafi już dziś, a gdzie człowiek i tak jest konieczny
Modele językowe bardzo dobrze radzą sobie z zadaniami typu „przetwórz tekst X w formę Y w kontekście Z”. Znakomicie reformatują, porządkują, streszczają, rozbijają problem na kroki. Potrafią też wygenerować sensowny kod dla popularnych technologii, jeżeli dostaną wystarczająco precyzyjny opis środowiska i ograniczeń.
Słabiej radzą sobie z:
aktualnym stanem twojej infrastruktury – nie zobaczą, co naprawdę działa na produkcji, jeśli im tego nie pokażesz (albo nie podłączysz ich przez API do systemu monitoringu),
wiedzą poufną i domenową – nie znają twoich specyficznych procesów, nazewnictwa, dziwnych obejść i historycznych decyzji architektonicznych,
tworzeniem twardych faktów – generują treść, ale nie są oraklem prawdy; bez weryfikacji łatwo wprowadzą błąd.
Człowiek jest konieczny w trzech miejscach: przy podaniu kontekstu (prompt), przy krytycznej ocenie odpowiedzi (review) i przy decyzji, co rzeczywiście wdrożyć (odpowiedzialność). Prompt engineering nie zastąpi zdrowego rozsądku ani code review, ale pozwala mocno skrócić drogę od problemu do przyzwoitego szkicu rozwiązania.
Prompt engineering jako inżynieria komunikacji, nie „hackowanie AI”
Wokół prompt engineeringu narosło sporo mitów: sekretnych formułek, „magicznych” prefiksów, tricków w stylu „udawaj, że jesteś X” jako uniwersalnego klucza do jakości. Część z nich działa w ograniczonym stopniu, ale sedno leży gdzie indziej. Model nie staje się nagle genialny, bo każesz mu „być seniorem z 20-letnim doświadczeniem”. Zmienia się raczej to, jak sam precyzujesz oczekiwania.
W praktyce prompt engineering dla ludzi z IT przypomina projektowanie dobrze napisanych ticketów w Jirze, request for comments albo specyfikacji API. Trzeba jasno określić: zakres, kontekst, oczekiwany rezultat, kryteria akceptacji i ograniczenia. Jeżeli umiesz pisać sensowne opisy zadań dla zespołu, umiesz też projektować prompty. Różnica polega tylko na tym, że zamiast do człowieka, kierujesz je do modelu probabilistycznego.
Źródło: Pexels | Autor: Matheus Bertelli
Jak działają modele językowe z perspektywy praktyka IT
Model przewiduje kolejne tokeny, a nie „zna prawdę”
Model językowy nie jest bazą wiedzy ani kompilatorem logiki. To duża funkcja statystyczna uczona na tekstach, która przewiduje kolejne tokeny na podstawie dotychczasowego ciągu. Token to niekoniecznie cały wyraz – może być jego fragmentem. Z punktu widzenia praktyka IT kluczowe jest to, że model optymalizuje się pod kątem „podobieństwa do ludzkiego tekstu”, a nie „prawdziwości” czy „poprawności formalnej”.
Jeżeli więc poprosisz o kod funkcji, model wygeneruje taką sekwencję tokenów, która statystycznie przypomina kod realizujący twoje polecenie. Nie znaczy to, że kod będzie optymalny, bezpieczny albo zgodny z twoimi standardami. Odpowiedź jest wynikiem uczenia na przykładach, nie wnioskowania symbolicznego.
Konsekwencje: halucynacje, konfabulacje i pozorna pewność
Skoro model przewiduje tekst, a nie „odtwarza fakty”, pojawiają się typowe zjawiska:
Halucynacje – model generuje rzeczy nieprawdziwe lub nieistniejące (np. wymyślone endpointy, klasy, opcje konfiguracji), ale robi to w sposób bardzo przekonujący stylistycznie.
Konfabulacje – tam, gdzie nie ma danych, „dopowiada” resztę na podstawie skojarzeń z podobnymi tekstami, zamiast przyznać: „nie wiem”.
Pozorna pewność odpowiedzi – forma wypowiedzi jest stanowcza, wygląda jak ekspercka opinia, mimo że stoi za tym jedynie wysoka pewność predykcji kolejnego tokena.
Dla ludzi z IT szczególnie zdradliwe są „ładne, ale błędne” fragmenty kodu i konfiguracji. Odpowiedź wygląda sensownie, przechodzi szybki rzut oka, ale np. używa nieistniejącej opcji w YAML-u, starej wersji API albo łamie subtelną regułę bezpieczeństwa. Prompt engineering powinien redukować pole do halucynacji przez jasne ograniczenia, prośby o uzasadnienie i określony format wyników.
Ograniczenia: brak pamięci, ograniczony kontekst, brak dostępu do systemów
Modele działające w przeglądarce lub przez API mają kilka istotnych ograniczeń, które trzeba wziąć pod uwagę przy projektowaniu promptów:
Brak trwałej pamięci między sesjami – jeżeli narzędzie nie ma dedykowanej funkcji pamięci, model nie będzie „pamiętał” twoich poprzednich rozmów. Każda sesja to osobny kontekst.
Okienko kontekstu – model może uwzględnić tylko określoną liczbę tokenów wejściowych i wyjściowych łącznie. Długie pliki, wielkie logi, kilka wersji konfiguracji łatwo przekraczają ten limit, więc trzeba je streszczać lub fragmentować.
Brak dostępu do bieżących systemów – bez świadomej integracji przez API model nie „zajrzy” do twojej bazy, repozytorium, Prometheusa czy Jiry. Jedynym światem, jaki zna, jest treść zadania i ogólna wiedza wyniesiona z treningu.
Dobry prompt jest świadomy tych ograniczeń. Zamiast wrzucać „wszystko jak leci”, trzeba najpierw wybrać istotne fragmenty i jasno opisać, co to za dane (np. „fragment logów z serwera X, wersja aplikacji 1.2.3, środowisko staging”). Im mniej niejednoznaczności, tym mniejsza szansa na błąd wynikający z błędnego założenia modelu o kontekście.
Kiedy traktować model jak „sprytnego juniora”, a kiedy jak „asystenta do brudnej roboty”
Praktyczny model mentalny jest prosty: model to bardzo szybki, szeroko oczytany, ale nie do końca odpowiedzialny junior. Świetnie zna typowe wzorce kodu, konfiguracje i dobre praktyki, ale potrafi się mylić i rzadko otwarcie przyznaje się do niewiedzy. Potrzebuje review. Jeśli będziesz od niego oczekiwać nieomylności, zawiedzie. Jeżeli użyjesz go jako narzędzia do generowania szkiców i alternatyw, zrobi ogrom pracy za ciebie.
Drugi sposób myślenia: asystent do brudnej roboty tekstowej. Modele doskonale:
porządkują chaotyczne notatki w checklistę kroków,
tworzą pierwszą wersję dokumentu, którą później tylko poprawiasz,
konwertują konfigurację z jednego formatu na inny,
generują powtarzalne fragmenty kodu (boilerplate, testy, mocki).
Rolą specjalisty IT jest zdecydować, kiedy model jest partnerem w dyskusji architektonicznej (wtedy trzeba go mocno prowadzić promptami), a kiedy po prostu automatem do przepisywania treści (wtedy chodzi głównie o jasne formaty wejścia i wyjścia). W obu przypadkach zły prompt potrafi zmarnować potencjał narzędzia.
Skuteczny prompt dla specjalisty IT rzadko jest jednym zdaniem. Najczęściej ma kilka wyraźnych elementów, które można z grubsza podzielić na cztery filary:
Kontekst – w jakim środowisku, projekcie, technologii działasz, czego dotyczą dane, jakie są istotne szczegóły domenowe.
Rola modelu – jakiego typu perspektywy oczekujesz: senior developer, SRE, technical writer, QA itp.
Cel – co ma być efektem: lista hipotez, plan, fragment kodu, propozycja architektury, streszczenie, porównanie.
Ograniczenia i forma – czego model ma nie robić, jakie są granice (technologie, standardy, bezpieczeństwo) i w jakim formacie chcesz wynik.
Jeżeli któryś z tych elementów jest pominięty lub niejasny, model zaczyna zgadywać. Czasem trafi, ale w powtarzalnej pracy zawodowej poleganie na zgadywaniu nie jest rozsądne. Konkretny, ustrukturyzowany opis tych czterech filarów to najprostsza definicja prompt engineeringu w praktyce.
Przekładanie realnego zadania na język promptu
Wyobraź sobie, że dostajesz zadanie: „przejrzyj ten PR z migracją REST → gRPC”. Człowiekowi z zespołu tłumaczysz w kilku zdaniach, czego oczekujesz: na co zwrócić uwagę, jakie są szerokie założenia architektury, jakie mamy standardy. AI też tego potrzebuje.
Zamiast lakonicznego: „Sprawdź ten kod migracji z REST na gRPC”, można napisać:
„Działasz jako senior backend developer w projekcie pisanym w Kotlin + Spring Boot. Migracja dotyczy zastąpienia istniejących endpointów REST nowymi interfejsami gRPC w ramach tego samego mikroserwisu. Celem jest sprawdzenie, czy nowa implementacja:
zachowuje dotychczasowe kontrakty biznesowe,
nie wprowadza dodatkowych punktów awarii,
odpowiada naszym standardom logowania i obsługi błędów (opisane niżej).”
Dalej dołączasz fragment kodu, opis standardów i prosisz np. o: listę potencjalnych problemów, propozycję pytań do autora PR, sugestie testów regresyjnych. Różnica w jakości takiego „review” jest zwykle kolosalna.
Ustalanie granic: co AI ma robić, a czego nie
Modele mają tendencję do „dopowiadania” brakujących elementów. W kontekście IT oznacza to np. wymyślanie nazw klas, parametrów, plików konfiguracyjnych. Jeżeli chcesz tego uniknąć, trzeba jasno zakomunikować granice:
„Nie wymyślaj nowych nazw klas ani metod, jeżeli nie są podane w kodzie źródłowym.”
„Nie zmieniaj logiki biznesowej, nawet jeśli uważasz, że można ją uprościć.”
„Nie używaj bibliotek spoza listy: …”
„Zakładaj, że system działa w środowisku on-premise, bez dostępu do usług chmurowych.”
Precyzowanie poziomu szczegółowości i stylu odpowiedzi
Bez wyraźnego określenia szczegółowości model będzie lawirował między ogólnikami a przydługimi elaboratami. Dla pracy IT ma to bezpośrednie skutki: zamiast konkretnych snippetów i komend dostajesz esej o „zalecanych praktykach”. Da się to dość łatwo ograniczyć.
Przydatne są krótkie doprecyzowania:
„Odpowiadaj na poziomie senior developera, bez tłumaczenia podstaw.”
„Podaj tylko konkretny kod, bez komentarza słownego.”
„Najpierw skrócone podsumowanie (max 3 zdania), potem szczegóły techniczne.”
„Wymień 3–5 najważniejszych punktów, bez pełnej listy wszystkich możliwości.”
Takie ograniczenia potrafią radykalnie zmienić strukturę odpowiedzi. Zamiast ogólnej lekcji „czym jest Kubernetes” pojawia się zestaw konkretnych kubectl, manifestów i pułapek specyficznych dla danego use case’u.
W projektach, gdzie generujesz dużo treści (np. dokumentacja API), warto od razu doprecyzować styl:
„Styl: zwięzły, techniczny, bez marketingu, bez przymiotników typu ‚innowacyjny’, ‚nowoczesny’.”
„Dokumentacja po polsku, nazwy własne (klasy, metody, endpointy) zostaw w oryginale po angielsku.”
„Używaj języka neutralnego, bez trybu rozkazującego, np. ‚możesz użyć’, zamiast ‚użyj’.”
Rozbijanie złożonych próśb na kroki
Jedno z częstszych nieporozumień: „zadam jedno bardzo długie pytanie, model zrobi wszystko naraz”. Da się, ale zwykle jakość spada. Modele lepiej radzą sobie, gdy prowadzisz je krok po kroku i jasno sygnalizujesz etapy.
Zamiast jednego, przeładowanego promptu typu: „Przeanalizuj logi, zaproponuj hipotezy, wybierz najbardziej prawdopodobną, wygeneruj plan naprawczy i gotowy skrypt deploya”, sensowniejsze jest rozdzielenie:
Analiza danych – „Na podstawie tych logów wypisz możliwe przyczyny błędu X w formie listy hipotez (max 5), uporządkowane od najbardziej do najmniej prawdopodobnej. Uzasadnij każdą w 1–2 zdaniach.”
Wybór hipotezy – „Skup się na dwóch najbardziej prawdopodobnych hipotezach. Wypisz, jakie dodatkowe dane logów lub metryki trzeba sprawdzić, aby je zweryfikować.”
Plan działań – „Załóżmy, że prawdziwa jest hipoteza nr 1. Zaproponuj plan naprawczy podzielony na: szybki workaround, docelową poprawkę, regresję.”
Taka sekwencja nie jest „ładniejsza” tylko dla człowieka. Model ma też mniej okazji do halucynacji, bo na każdym etapie zawężasz zakres i korygujesz kierunek. W praktyce SRE takie prowadzenie modelu bywa szybsze niż ręczne pisanie całej diagnozy od zera, choć nadal wymaga zdrowego sceptycyzmu.
Techniki dopytywania i iteracyjnego zawężania problemu
Prompt engineering nie kończy się na pierwszym zapytaniu. Większość wartości rodzi się w kolejnych iteracjach. Zamiast uznać pierwszą odpowiedź za „wyrok”, lepiej traktować ją jako szkic do doprecyzowania.
Typowe, użyteczne dogrywki:
„Pokaż minimalny, kompletny przykład (MCVE) ilustrujący Twój pomysł.” – redukuje wodolejstwo i ogólniki.
„Które fragmenty Twojej propozycji są najsłabiej ugruntowane (najbardziej spekulatywne)?” – zmusza model do autorefleksji i często obnaża fragmenty „z palca”.
„Załóż, że masz do dyspozycji wyłącznie X i Y (podane biblioteki/narzędzia). Jak zmienia się Twoja odpowiedź?” – ograniczasz technologiczne rozjechanie się z realnym środowiskiem.
„Podaj alternatywną propozycję, która maksymalnie upraszcza implementację kosztem części funkcji.” – dobrze sprawdza się przy przegadanych, zbyt rozbudowanych architekturach.
W jednym z zespołów backendowych, po wprowadzeniu zasady „min. 2 iteracje z AI do każdego większego RFC”, czas przygotowania rozsądnego szkicu rozwiązania spadł zauważalnie. Klucz nie leżał w pierwszym promcie, tylko w konsekwentnym dopytywaniu, aż propozycja stała się wystarczająco konkretna, by ją realnie zreviewować.
Kontrola halucynacji przez jawne żądanie niepewności
Domyślnie model wypowiada się stanowczo. Nawet gdy „zgaduje”, brzmi pewnie. Da się to częściowo rozbroić, formułując prośby wprost pod kątem niepewności:
„Jeżeli nie jesteś pewien odpowiedzi, wskaż to explicite i zaproponuj, jakie dane trzeba zebrać.”
„Wypisz osobno: (1) elementy oparte na ogólnej wiedzy, (2) elementy, w których zgadujesz na podstawie podobnych przypadków.”
„Zamiast wymyślać brakujące szczegóły, wypisz listę pytań, które zadałbyś zespołowi.”
Takie sformułowania nie wyłączą halucynacji całkowicie, ale często zmieniają ton wypowiedzi z „tak ma być” na „prawdopodobnie tak, pod warunkami…”. Dla inżyniera to istotna różnica.
Dodatkowo, można wymusić strukturę, która eksponuje możliwe błędy:
„Na końcu odpowiedzi wypisz osobną sekcję: ‚Ryzyka i ograniczenia tej propozycji’.”
„Wypisz 3 sposoby, w jakie Twoja propozycja może okazać się błędna.”
Modele zaskakująco dobrze radzą sobie z takim „adwokatem diabła”, o ile wprost o to poprosisz. Bez tego zwykle przesadnie eksponują pewność i „gładkość” rozwiązania.
Weryfikacja kodu i konfiguracji wygenerowanej przez AI
Najbardziej niebezpieczne są fragmenty, które „wyglądają poprawnie”. Krótki, sensowny kod w PR-ze, wygenerowany przez AI, często przechodzi pobieżny review. Kilka prostych nawyków w promptach ogranicza ten problem.
Przy prośbach o kod lub konfigurację:
„Najpierw zaproponuj podejście w pseudokodzie, dopiero po akceptacji wygeneruj docelowy kod.”
„Dodaj scenariusze testowe (unit/integration), które powinny przejść, jeśli Twoje rozwiązanie jest poprawne.”
„Wskaż, które fragmenty wymagają weryfikacji w dokumentacji oficjalnej (podaj dokładne słowa kluczowe do wyszukania).”
Przy konfiguracji (Terraform, Helm, Ansible, CI/CD yaml):
„Podaj minimalny działający przykład, bez opcji domyślnych i zbędnych pól.”
„Oznacz w komentarzach fragmenty, które opierasz na ogólnej wiedzy o narzędziu, nie na konkretnej wersji.”
„Nie używaj żadnych opcji oznaczonych jako ‚deprecated’ w dokumentacji narzędzia; jeśli ich używasz, wyraźnie je oznacz.”
Przy dobrze sformułowanym promcie, model częściej sam od siebie napisze: „dokładna nazwa tej opcji może się różnić w zależności od wersji”, co jest sygnałem, że trzeba sięgnąć do dokumentacji. Bez takich ograniczeń łatwo o konfiguracje, które działają tylko „w opowieści” modelu.
Projektowanie promptów do refaktoryzacji i review istniejącego kodu
Praca z istniejącym kodem jest bardziej podatna na nieporozumienia niż generowanie nowego. Jeżeli nie ustalisz roli AI i zakresu zmian, model będzie „ulepszał” wszystko naraz – od formatowania po logikę biznesową.
Bezpieczniej jest sprecyzować zakres wprost:
„Skup się wyłącznie na poprawie czytelności i redukcji duplikacji, bez zmiany logiki biznesowej.”
„Nie modyfikuj podpisów publicznych metod ani kontraktów API.”
„Twoim celem jest usunięcie kodu martwego i zbędnych zależności, nic więcej.”
Przy większych modułach sensowne jest rozdzielenie na etapy:
„Najpierw wypisz główne problemy z tym kodem (max 10 punktów), posegregowane na: architektura, wydajność, czytelność, bezpieczeństwo.”
„Zaproponuj refaktoryzację tylko dla kategorii ‚czytelność’ z minimalną zmianą struktur.”
„Na końcu zaproponuj plan dalszej refaktoryzacji, którą zespół może wykonać ręcznie.”
Ten sposób ogranicza pokusę „przepisania wszystkiego od zera”, którą modele lubią, gdy widzą kod odbiegający od idealnych wzorców z dokumentacji.
Prompt jako formalizacja standardów zespołu
Dużą przewagą w zespołach jest zamiana miękkich „tak się u nas robi” w twarde fragmenty promptów. Zamiast za każdym razem ręcznie dopisywać kontekst, można przygotować zestaw szablonów odzwierciedlających wewnętrzne standardy.
Przykładowe elementy takiego „wewnętrznego kontraktu” z AI:
Standard logowania – poziomy logów, struktura komunikatów, zakaz logowania danych wrażliwych.
Standard błędów – sposób mapowania wyjątków na kody HTTP lub statusy gRPC, pola w odpowiedzi błędu.
Standard bezpieczeństwa – np. „domyślnie zakładaj, że endpointy są prywatne i zabezpieczone OAuth2; jeśli proponujesz coś innego, wyraźnie to zaznacz”.
Standard testów – minimalny zestaw testów do każdej nowej funkcji lub endpointu.
Te zasady można w praktyce skopiować do jednego pliku i dołączać do promptów przy kodowaniu, review czy pisaniu dokumentacji. Modele dobrze „uczulają się” na takie reguły, jeżeli są zapisane jasno i jednoznacznie, najlepiej w punktach.
Praca z długimi plikami, logami i dokumentacją
W realnych systemach nawet mała awaria generuje logi długości kilkuset linii. Wrzucenie wszystkiego do jednego promptu najczęściej kończy się tym, że model ignoruje część danych lub łapie pierwszy lepszy wzorzec błędu.
Bardziej skuteczna jest strategia „najpierw struktura, potem analiza”. Najprostszy szablon:
Segmentacja – „Podziel te logi na logiczne fragmenty (np. według requestów / wątków / instancji) i wypisz krótkie streszczenie każdego segmentu.”
Wskaźniki problemów – „Dla każdego segmentu wypisz podejrzane wzorce: powtarzające się stack trace’y, time-outy, błędy sieciowe, komunikaty z GC.”
Hipotezy – „Na podstawie tych wzorców wypisz 3 najbardziej prawdopodobne przyczyny głównego symptomu X.”
W przypadku dokumentacji (np. RFC, specyfikacja API) sensowne jest wymuszenie formatów, które modelowi łatwo się trzyma:
„Stwórz tabelę: endpoint → metoda → opis → pola obowiązkowe → kody błędów.”
„Z tego dokumentu wyciągnij tylko ograniczenia ‚MUST’ i ‚MUST NOT’ w formie listy punktów.”
Takie podejście jest mniej efektowne niż „zdiagnozuj problem z tych logów”, ale w praktyce prowadzi do odpowiedzi, które można realnie audytować. Odpowiada też bardziej temu, jak człowiek senior faktycznie analizuje dane – krok po kroku.
Specjalizacja promptów pod różne role techniczne
Ten sam model potrafi skutecznie wcielić się w różne role, ale wymaga to precyzyjnego opisania perspektywy. Inaczej będzie wyglądał prompt dla SRE, inaczej dla QA czy architekta.
Przykładowe „role techniczne” i ich typowe akcenty w promcie:
SRE / DevOps – „Skup się na niezawodności, obserwowalności i strategiach rollout/rollback. Załóż, że uptime jest ważniejszy niż szybkość wdrożenia nowych funkcji.”
QA / Test engineer – „Twoim celem jest znalezienie luk w scenariuszach testowych i zaproponowanie przypadków skrajnych. Nie optymalizujesz kodu, patrzysz wyłącznie z perspektywy kruchości systemu.”
Security engineer – „Zakładaj, że użytkownik jest złośliwy. Wypisz możliwe wektory ataku, naruszenia zasad least privilege, problemy z walidacją danych wejściowych.”
Technical writer / dokumentacja – „Priorytetem jest jasność i spójność dokumentu. Utrzymuj jednolitą terminologię, zaznaczaj wymagania twarde i opcjonalne.”
Ustalając rolę, dobrze jest też powiedzieć, czego dana rola nie robi. Np. dla QA: „Nie proponuj zmian w architekturze, jeśli nie są konieczne do testowania”. Ogranicza to wyskakiwanie z „nadgorliwymi” poradami wykraczającymi poza zakres.
Iteracyjne doprecyzowywanie promptów zamiast „strzału idealnego”
Jednorazowy, perfekcyjny prompt to bardziej mit niż praktyka. Z modelem pracuje się raczej jak z młodszym członkiem zespołu: trzeba korygować, zawężać, dopowiadać. Świadomie zaprojektowany cykl iteracji zwykle daje lepszy efekt niż godzina „dopieszczenia” pojedynczego zapytania.
Przydatny jest prosty schemat trzyetapowy:
Szkic – krótki prompt, który sprawdza, czy model „rozumie problem mniej więcej dobrze”.
Doprecyzowanie – dociążenie kontekstu, dopisanie ograniczeń, poprawa roli modelu.
Kontrola jakości – dodatkowe pytania pomocnicze, wymuszenie ryzyk, testów, alternatyw.
W praktyce może to wyglądać tak:
Najpierw: „Potraktuj to jako szkic. Opisz ogólną strategię rozwiązania problemu X (max 10 zdań). Bez kodu.”
Gdy kierunek jest sensowny, dopiero wtedy: „Rozwiń punkt 3 i 4 w formie konkretnej implementacji w języku Y, zakładając framework Z w wersji 2.x.”
Po wygenerowaniu: „Wypisz 5 pytań kontrolnych, które powinienem zadać, zanim uznam to rozwiązanie za akceptowalne w produkcji.”
Taka sekwencja od razu ustawia model w trybie „roboczej rozmowy”, a nie jednorazowej wyroczni. Zwykle wychodzą wtedy na wierzch założenia, których w pojedynczym, długim promcie i tak by nie doprecyzowano.
Prompt engineering w pracy z architekturą i decyzjami technicznymi
Przy decyzjach projektowych największym ryzykiem jest to, że AI zsyntetyzuje „średnią z internetu” – ładnie brzmiącą, ale oderwaną od twoich realnych ograniczeń. Żeby temu przeciwdziałać, prompty muszą wyraźnie narzucać kontekst organizacyjny i techniczny.
Zamiast ogólnego „Zaproponuj architekturę systemu X”, bardziej przydatne są polecenia typu:
„Zaproponuj architekturę systemu X, przy założeniach: (1) zespół ma mocne kompetencje w Javie i Kubernetes, (2) mamy ograniczone wsparcie do utrzymania baz NoSQL, (3) downtime planowany w nocy jest akceptowalny.”
„Podaj 2–3 warianty architektury zróżnicowane pod względem: koszt utrzymania, złożoność operacyjna, czas wdrożenia. Dla każdego wariantu wskaż, kiedy byłby złą decyzją.”
„Traktuj ten projekt jak system, który będzie utrzymywany przez 5+ lat przez zmieniające się zespoły. Priorytety: prostota i przewidywalność nad ‚fajnością’ technologii.”
Dodatkowo warto wymusić jawne wypisanie założeń, które model przyjmuje „w tle”:
„Wypisz wszystkie ukryte założenia, które poczyniłeś, opisując tę architekturę – szczególnie dotyczące ruchu, danych, SLA, kompetencji zespołu.”
Bez takiego punktu często dostajesz opis „idealnego świata”, który rozpada się po pierwszym zderzeniu z rzeczywistym SLA, budżetem albo brakiem ludzi od konkretnego stacku.
Łączenie kilku perspektyw w jednym promcie
W złożonych tematach przydaje się spojrzenie z kilku stron jednocześnie: deweloperskiej, operacyjnej, bezpieczeństwa. Model radzi sobie z tym całkiem nieźle, jeśli jasno nazwiesz perspektywy i ich priorytety.
Przykładowa struktura dla projektu nowego komponentu:
Perspektywa bezpieczeństwa – autoryzacja, dane wrażliwe, integracje z zewnętrznymi systemami.
Z promta może to wyglądać tak:
„Przeanalizuj ten projekt z trzech perspektyw: (1) backend developer, (2) SRE, (3) security engineer. Dla każdej perspektywy wypisz osobną listę ryzyk i braków. Nie proponuj rozwiązań, tylko zidentyfikuj problemy.”
„Następnie zaproponuj poprawki priorytetowe: najpierw bezpieczeństwo, potem niezawodność, na końcu ergonomia API. Jeśli coś poprawia ergonomię kosztem bezpieczeństwa – wyraźnie to oznacz.”
Kluczowe jest tu ułożenie kolejności priorytetów. Bez tego model ma tendencję do „wygładzania” wszystkiego naraz, co w praktyce kończy się zbiorem ogólnikowych rekomendacji.
Współpraca z AI przy migracjach i pracy z legacy
Legacy to obszar, gdzie AI potrafi być zarówno realną pomocą, jak i źródłem groźnych uproszczeń. Modele chętnie „prostują” starą architekturę do nowoczesnych wzorców, ignorując wszystkie powody, dla których system jeszcze działa.
Przy pracy z legacy lepiej traktować AI jako narzędzie do mapowania i katalogowania niż generator gotowych planów migracji. Użyteczne są m.in. takie wzorce promptów:
„Na podstawie tego fragmentu kodu i konfiguracji spróbuj odtworzyć: (1) jakie systemy zewnętrzne są używane, (2) jakie są główne przepływy danych, (3) gdzie są potencjalne punkty sprzężenia.”
„Zidentyfikuj miejsca, w których to zachowanie może być zależne od historycznych bugów lub nietypowych konfiguracji. Oznacz je jako ‚podejrzane obszary migracji’.”
„Zaproponuj plan migracji w minimalnych krokach, tak aby po każdym etapie system był w stanie działać w produkcji. Unikaj ‚big bang rewrite’.”
Dobrą praktyką jest też proszenie o „kontrplan” – co może pójść nie tak:
„Załóż, że ten system ma nieudokumentowanych konsumentów i kruchą integrację batchową. W jaki sposób plan migracji może zniszczyć takie zależności? Jakie dodatkowe testy/regresje trzeba zaplanować?”
Jeżeli model zaczyna proponować całkowite przepisywanie modułów bez argumentów w stylu „niższy koszt utrzymania w długim okresie”, dobrze jest to brutalnie przyciąć:
„Nie proponuj przepisania całego modułu od zera. Skup się wyłącznie na krokach, które można wykonać w sprintach 1–2 tygodniowych z pełnym rollbackiem.”
Budowanie osobistej „biblioteki promptów” dla specjalisty IT
Tak jak utrzymuje się prywatny zestaw snippetów czy dotfiles, podobnie można zbudować własny katalog promptów. Chodzi mniej o „magiczne formułki”, bardziej o powtarzalne ramy rozmowy z modelem.
Praktycznie sprawdza się prosty podział na kategorie:
„Analiza problemu” – logi, błędy, stack trace, nietypowe zachowania systemu.
„Projektowanie” – decyzje architektoniczne, dobór technologii, API design.
„Review i refaktoryzacja” – code review, porządkowanie, poprawa czytelności.
„Dokumentacja i komunikacja” – RFC, ADR, komentarze do PR, notatki z incydentów.
Dla każdej kategorii można mieć po kilka szablonów z miejscem na kontekst. Przykład dla analizy błędów:
<ROLA>: Doświadczony SRE
<CEL>: Zawężenie hipotez przy błędzie X
<KROKI>:
1. Streść logi (max 10 zdań).
2. Wypisz powtarzające się symptomaty.
3. Zaproponuj 3–5 hipotez.
4. Dla każdej hipotezy wypisz konkretne dane/logi/metryki, które mogą ją potwierdzić lub obalić.
Taki „szkielet” łatwo kopiować między narzędziami i sesjami. Co istotne – da się go z czasem korygować na podstawie realnych wpadek, a nie teoretycznych zasad.
Strategie ograniczania szumu informacyjnego w odpowiedziach
Modele mają silną skłonność do rozwlekłych, „ładnie brzmiących” odpowiedzi. W praktyce przeszkadza to szczególnie wtedy, gdy trzeba szybko przejrzeć kilka wariantów i podjąć decyzję. Zbyt ogólny prompt typu „opisz” często kończy się ścianą tekstu.
Kilka prostych sposobów na przycięcie szumu:
Limity długości – „max 10 zdań”, „max 15 punktów”, „max 200 słów”. Bez tego model potrafi „popłynąć”.
Wymuszona struktura – prośba o konkretne sekcje: „Założenia”, „Zalety”, „Wady”, „Ryzyka”, zamiast swobodnego eseju.
Odrzucenie banałów – „Nie powtarzaj oczywistych porad typu ‚dodaj logowanie’ lub ‚pisz testy jednostkowe’, chyba że są specyficzne dla tego kontekstu.”
Akcent na różnice – „Skup się na tym, czym te opcje się różnią, a nie na tym, co mają wspólnego.”
Jeśli model mimo wszystko generuje zbyt obszerną odpowiedź, można zastosować kontr-prompt:
„Zredukuj swoją poprzednią odpowiedź do 5 najważniejszych punktów z perspektywy <rola> (np. SRE, architekt). Usuń wszystko, co nie wnosi nowej informacji.”
Takie „docinanie” odpowiedzi jest w praktyce bardziej efektywne niż próby idealnego zaplanowania pierwszego promta pod kątem długości.
Łączenie AI z dokumentacją i źródłami zewnętrznymi
Modele lubią „udawać dokumentację” – odwołują się do nieistniejących klas, opcji konfiguracyjnych, flag CLI. Żeby ograniczyć ten efekt, prompty powinny jasno rozdzielać to, co pochodzi z realnych źródeł, od tego, co jest wiedzą ogólną modelu.
Przy pracy z konkretnym frameworkiem czy narzędziem przydatne są m.in. takie dyspozycje:
„Odpowiadaj wyłącznie na podstawie załączonego fragmentu dokumentacji. Jeśli czegoś w nim nie ma, napisz wprost: ‚brak informacji w załączonej dokumentacji’.”
„Jeśli używasz wiedzy ogólnej (poza załączonym tekstem), oznacz takie fragmenty jako ‚domniemanie na podstawie ogólnych wzorców’.”
„Podaj konkretne frazy, które powinienem wyszukać w oficjalnej dokumentacji narzędzia X, żeby zweryfikować tę konfigurację.”
W jednej z większych organizacji przyspieszyło to realnie onboarding nowych osób: do RFC dołączano fragmenty promptów, które wymuszały odróżnianie „twardych źródeł” od uogólnień modelu. Mniej czasu szło na odkręcanie konfiguracji, które „prawie” istniały.
Projektowanie promptów pod pracę zespołową
Jeżeli z AI pracuje cały zespół, a nie pojedyncza osoba, brak wspólnych wzorców promptów powoduje klasyczny chaos: każdy „wychowuje” sobie model po swojemu, a efekty trudno porównać czy zreprodukować.
Można temu przeciwdziałać, traktując prompty jak element procesów zespołowych:
„Dla generowania nowych endpointów REST używamy szablonu X. Każdy PR musi zawierać prompt i odpowiedź AI, z której korzystano.”
„Przy analizie incydentów produkcyjnych korzystamy z szablonu Y do wstępnej segmentacji logów i hipotez.”
„Do migracji baz danych mamy oddzielny zestaw promptów, w których zawsze pojawia się sekcja ‚Ryzyka danych historycznych’.”
W praktyce można wręcz traktować prompty jak mini-„runbooki”. W codebase lub wiki zespołowym trzyma się pliki typu prompt_incydenty.md, prompt_nowe_api.md, a w nich standardowe struktury. Z biegiem czasu aktualizuje się je tak samo, jak linie bazowe CI/CD czy checklisty release’u.
Rozpoznawanie, kiedy nie eskalować do AI
Istnieją sytuacje, w których dalsze dopieszczanie promptów jest gorsze niż zwykłe sięgnięcie do dokumentacji lub rozmowa z człowiekiem z zespołu. Klucz to świadomie rozpoznać takie przypadki, zamiast ślepo wierzyć, że „może jeszcze jedno przeformułowanie coś da”.
Kilka typowych sygnałów ostrzegawczych:
Rozbieżne odpowiedzi przy minimalnych zmianach promta – model podaje za każdym razem inne „pewne” twierdzenia o tej samej opcji konfiguracyjnej czy flagach CLI.
Brak pokrycia w znanych materiałach – odpowiedzi stoją w sprzeczności z oficjalną dokumentacją lub praktyką zespołu, a model nie jest w stanie podać żadnych słów kluczowych do weryfikacji.
Zbyt duża waga decyzji – np. zmiana polityk bezpieczeństwa, RPO/RTO, zasad retencji danych. W takich obszarach AI może wspierać analizę, ale nie powinna być głównym źródłem prawdy.
W promcie da się to częściowo ująć wprost:
Najczęściej zadawane pytania (FAQ)
Co to jest prompt engineering i czym różni się od „zadania pytania” AI?
Prompt engineering to świadome projektowanie zapytania do modelu językowego tak, żeby wynik dało się bezpiecznie wykorzystać w realnej pracy technicznej. Chodzi o to, by przekuć własną wiedzę domenową w tekst: podać kontekst, ograniczenia, standardy i oczekiwaną formę odpowiedzi.
Zwykłe „zadanie pytania” to prośba typu: „napisz skrypt do backupu w Bash”. Prompt zaprojektowany inżyniersko opisuje więcej: środowisko, katalogi, serwer, wymagania dot. logowania, tryb dry-run, zgodność ze standardami w projekcie. Ten sam model wygeneruje kod, ale różnica w jakości, czytelności i bezpieczeństwie będzie bardzo duża.
Jak pisać skuteczne prompty do generowania kodu (dla programistów)?
Skuteczny prompt do kodu opisuje konkretny kontekst techniczny, a nie tylko język programowania. Zamiast „napisz funkcję do logowania”, lepiej użyć czegoś w stylu: „piszesz w Pythonie 3.11, framework FastAPI, logowanie przez standardowy logger, integracja z Prometheusem, kod ma być kompatybilny z poniższym fragmentem…”. Model ma wtedy mniej przestrzeni na zgadywanie.
Pomaga też:
danie przykładu istniejącego kodu jako wzorca stylu,
jasne określenie formatu wyniku (np. „tylko kod, bez komentarza”, „kod + krótkie uzasadnienie decyzji projektowych”),
Bez tego łatwo o „ładny, ale błędny” kod, który przejdzie szybki rzut oka, a wyłoży się w produkcji.
Jak używać AI do debugowania i analizy logów, żeby nie dostać losowych hipotez?
Przy logach najważniejsze jest ograniczenie szumu. Zamiast wklejać cały log z serwera, lepiej streścić sytuację: „aplikacja X, środowisko staging, problem: timeouty przy zapisie do bazy, poniżej fragment logów z godzin Y–Z” i dopiero potem dodać najważniejsze stack trace’y. Wprost poproś o: kilka hipotez, ich krótkie uzasadnienie i propozycję kolejnych kroków diagnostycznych.
Dobry prompt może brzmieć: „na podstawie poniższych logów wygeneruj maksymalnie 3 najbardziej prawdopodobne przyczyny, opisz, jakie dane jeszcze powinienem sprawdzić i które hipotezy są najsłabsze”. Dzięki temu model nie próbuje „udawać wszechwiedzącego”, tylko zachowuje się bliżej inżyniera, który myśli w kategoriach scenariuszy i priorytetów.
Czy AI może zaprojektować architekturę systemu bez udziału człowieka?
Modele językowe potrafią sensownie porównać warianty, wypunktować typowe kompromisy i zidentyfikować standardowe ryzyka, jeśli dostaną konkretny kontekst: obciążenie, wymagania niefunkcjonalne, istniejącą infrastrukturę, ograniczenia organizacyjne. To bywa użyteczne jako „druga para oczu” czy generator pomysłów.
Nie widzą jednak rzeczy, których im nie pokażesz: realnego stanu środowisk, historycznych decyzji w projekcie, specyficznych obejść i polityk firmy. Dlatego AI może pomóc przy szkicu architektury lub review, ale decyzja o finalnym kształcie musi zostać po stronie człowieka, który zna system i ponosi odpowiedzialność za konsekwencje.
Jak ograniczyć halucynacje AI przy pracy z konfiguracją, YAML-em, Kubernetesem itp.?
Halucynacje pojawiają się m.in. wtedy, gdy model ma za dużo swobody i za mało twardych danych. Przy konfiguracjach lepiej wkleić konkretny fragment (z opisem wersji narzędzia, np. „Kubernetes 1.29, Helm 3.x”) i jasno określić zadanie: „znajdź nieprawidłowe opcje”, „porównaj z oficjalną dokumentacją i wypisz tylko pola, które są przestarzałe”. To zawęża pole do zgadywania.
Dobrym nawykiem jest też proszenie o:
podanie źródła lub wersji, do której model się odnosi („jakiej wersji API dotyczy ta konfiguracja?”),
wyraźne oznaczenie fragmentów, co do których model ma niższą pewność,
oddzielne wypisanie zmian „koniecznych” vs „opcjonalnych”.
Nawet wtedy konfigurację trzeba zweryfikować w dokumentacji i w testowym środowisku – AI nie ma dostępu do twojej działającej infrastruktury.
Czy wystarczy, że napiszę w promptcie „zachowuj się jak senior developer”?
Takie formułki czasem pomagają, bo zmieniają styl odpowiedzi: model generuje bardziej rozbudowane uzasadnienia, używa terminologii eksperckiej, częściej proponuje kompromisy. Nie oznacza to jednak, że nagle „ma” doświadczenie seniora – nadal przewiduje tekst na podstawie przykładów z treningu.
Znacznie ważniejsze jest to, co doprecyzujesz oprócz tego: zakres zadania, oczekiwaną głębokość analizy, kontekst projektu, a także format odpowiedzi (np. „najpierw analiza podejść, potem rekomendacja, na końcu lista ryzyk”). „Udawaj, że jesteś seniorem” bez tych elementów daje głównie efekt kosmetyczny i może uśpić czujność, bo odpowiedź brzmi bardzo pewnie.
Jakie są praktyczne ograniczenia AI, o których powinien pamiętać specjalista IT?
Z perspektywy praktyka najistotniejsze są trzy rzeczy: brak trwałej pamięci (jeśli narzędzie nie ma dedykowanego mechanizmu), ograniczone okno kontekstu oraz brak bezpośredniego dostępu do twoich systemów. Model nie „pamięta” poprzednich sesji, nie przejrzy całego monolitu, jeśli ten nie mieści się w limitach tokenów, i nie zajrzy sam z siebie do Jiry czy Prometheusa.
W praktyce oznacza to konieczność:
selekcji i streszczania danych wejściowych (logów, kodu, dokumentacji),
świadomej integracji przez API, jeśli chcesz operować na żywych danych,
traktowania odpowiedzi jako szkicu do zweryfikowania, a nie „prawdy z chmury”.
Bez tego łatwo zbudować workflow oparty na założeniach, których model po prostu nie spełnia.
