Jak ujarzmić Opusa 5, czyli dowód, że inżynieria promptów nie umarła

2026-08-17 • IndyDevDan • AI zagraniczne •tutorial •waga 4/5 •23 min czytania

Ręcznie pisany prompt systemowy zamienia mądrkującego Opusa 5 w zwięzłego seniora: wzorce pozytywne i negatywne, kody odniesienia, twarde granice, aliasy. Praktyczny warsztat dla inżynierów pracujących z agentami.

Robocza publikacja redakcyjna na podstawie publicznego transkryptu YouTube. Źródło: YouTube.

Oryginalny tytuł filmu

FIXING Opus 5: PROOF that Prompt Engineering IS NOT DEAD

O czym jest ten film

  1. Opus 5 to zarazem jeden z najlepszych i najbardziej irytujących flagowych modeli: rozwlekłe odpowiedzi, charakterystyczne frazy („load-bearing”, „here’s the honest truth”), dopisywanie się Anthropic jako współautora commitów i rekordowe zużycie tokenów wyjściowych.
  2. Główna teza: inżynieria promptów nie umarła — to dziś kluczowa umiejętność każdego inżyniera pracującego z agentami.
  3. Agent steruje się na dwa sposoby: promptem użytkownika (pojedyncze zadanie) i promptem systemowym (prawo dla wszystkich zadań). Większość inżynierów używa tylko pierwszego, choć cała dźwignia siedzi w drugim.
  4. Każde słowo z promptu systemowego mnoży się na każdy request i każdą odpowiedź agenta — stąd jego wpływ na styl komunikacji i realne oszczędności tokenów.
  5. Warsztat: dwie instancje Claude Code ramię w ramię na zadaniu streszczenia wpisu Zuckerberga, sterowane runnerem zadań just, z iteracyjnie doszlifowywanym promptem systemowym.
  6. Konkretne sekcje promptu: wzorce pozytywne (co robić) i negatywne (czarna lista fraz i nawyków), punkty odniesienia (kody typu R6, F1, D1), twarde granice operacyjne oraz aliasy.
  7. Punkty odniesienia tworzą z agentem wspólny, skrótowy język: wystarczy napisać „rozwiń R6”, żeby wrócić do wątku bez powtarzania treści.
  8. Twarde granice operacyjne hamują samowolną „inicjatywę” modelu: dostarczaj tylko to, o co proszono, nie zgłaszaj ukończenia bez dowodu, nie dopisuj współautora do commitów.
  9. Aliasy (SCR, ELY, FOC, REF) to mikrokomendy zaszyte w prompcie systemowym — model rozwija je jak pełne instrukcje i na bieżąco zagęszcza odpowiedzi.
  10. Przykłady „zrób/nie rób” działają jak mini-dane treningowe (destylacja w kontekście) i przenoszą się między modelami — od czasów GPT-3.5 nic nie straciły na aktualności.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Prompt systemowy, nie prompt użytkownika — tu jest dźwignia

Na czym polega: Większość inżynierów klepie prompty użytkownika i kolekcjonuje umiejętności (/plan, /review), a instrukcję systemową zostawia domyślną. Tymczasem każde jej słowo działa przy każdym zadaniu i każdej odpowiedzi — to tam mieszka spójny styl komunikacji i oszczędność tokenów.

Jak stosować: W Claude Code przekaż własny plik flagą, która dokłada go do domyślnego promptu systemowego (append, nie overwrite). Buduj go iteracyjnie i porównuj odpowiedzi obok siebie, np. komendą just compare.

Na co uważać: Zmiana promptu systemowego działa globalnie — błąd w nim psuje wszystkie zadania naraz. Generacje są niedeterministyczne, więc zawsze testuj paramę wersji: bazowa kontra zmodyfikowana; pojedynczy przebieg niczego nie dowodzi.

2.Rozmawiaj z agentem jak z kolegą z zespołu, bez teatru ról

Na czym polega: Zamiast „Jesteś ekspertem od X…” Dan pisze do modelu jak do inżyniera: „Ty i ja utrzymujemy relację bez owijania w bawełnę — jasną, zwięzłą i konkretną”. Model dostaje kontrakt komunikacyjny, a nie przebranie.

Jak stosować: Zacznij od sekcji „cel” (po czemu ta współpraca jest), potem „instrukcje” z numerowanymi podsekcjami, do których będziesz się odwoływać w dalszej części promptu. Zawsze dopisuj „dlaczego” — np. „żeby dostarczać najlepsze wyniki zespołowi i klientom”.

Na co uważać: Sam cel nic nie zmieni — pierwsze wersje promptu Dana nadal produkowały „load-bearing”. Cele to fundament, ale robotę robią detale w instrukcjach.

3.Dwie listy: co powtarzać, czego unikać

Na czym polega: Sekcja „wzorce pozytywne” opisuje pożądane zachowania (prosty, precyzyjny język; każdy fakt raz; poziom szczegółu adekwatny do rangi zadania; kwestionowanie błędnych założeń), a „negatywne” — czarną listę fraz i nawyków modelu.

Jak stosować: Wypisz wprost frazy, które najbardziej cię drażnią w odpowiedziach twojego modelu („load-bearing”, pochlebstwa, analogie, emoji, dekoracyjne nagłówki, łańcuchy myślników), i dopisuj nowe w miarę ich wykrywania — lista ma być żywa.

Na co uważać: Zakazy działają tylko w parze z pozytywami. Model musi wiedzieć, czym zastąpić zakazane zachowanie, inaczej wróci do starego stylu.

4.Najważniejszą informację umieszczaj na końcu odpowiedzi

Na czym polega: Dan zauważa, że odpowiedzi agenta czyta „od końca” — ostatnia rzecz to pierwsza, którą naprawdę widzi. Dlatego każe modelowi zostawiać sedno na samym końcu wypowiedzi.

Jak stosować: Dodaj tę zasadę do wzorców pozytywnych i sprawdź w praktyce, czy twoje wąskie gardło (ty, nie model) faktycznie przyspiesza — resztę tekstu można wtedy pomijać.

Na co uważać: To preferencja odbiorcy, nie uniwersalna reguła. Jeśli wolisz tezy na początku, zapisz to wprost — model nie zgadnie.

5.Kody odniesienia: wspólny język z agentem

Na czym polega: Przy trzech lub więcej elementach wynikowych (decyzje, opcje, ryzyka, pytania, działania) agent numeruje je i nadaje krótkie kody: R1–R6, F1–Fn, D1–Dn. Potem wystarczy „rozwiń R6”, żeby wrócić do konkretnego punktu bez powtarzania treści i palenia tokenów.

Jak stosować: Poleć modelowi tworzyć kody dla każdej dłuższej listy, trzymać te same oznaczenia przez całą rozmowę i wymyślać nowe dla kategorii, których jeszcze nie ma.

Na co uważać: Wyraźnie zakoduj wyjątki: brak kodowania krótkich, prostych odpowiedzi oraz zakaz zmieniania znaczenia kodów w trakcie konwersacji — inaczej system się rozjedzie.

6.Twarde granice operacyjne przeciwko nadmiernej „inicjatywie”

Na czym polega: Modele trenowano na zasadzie „znajdź odpowiedź za wszelką cenę”, więc Opus 5 samowolnie wyłapuje problemy, o które nikt nie prosił, i szybko traci fokus. Granice operacyjne to jedno zdanie: „dostarczaj tylko to, o co proszono, w zamierzonym zakresie” — plus enumeracja typowych naruszeń.

Jak stosować: Dopisz zakazy rozszerzania pracy o sprzątanie, refaktoryzację, dokumentację i sąsiednie funkcje; zakaz deklarowania ukończenia bez dowodów; zakaz dopisywania współautora (czyli Anthropic) do commitów; zwięzłe rozliczanie z wykonanej pracy zamiast wielkiej rekapitulacji.

Na co uważać: Granice muszą być jednoznaczne. Ogólnik „trzymaj się zakresu” bez wypisania typowych wykroczeń model łatwo obejdzie.

7.Aliasy: mikrokomendy zaszyte w prompcie systemowym

Na czym polega: Krótkie kody (SCR, ELY, FOC, REF) mają definicję zapisaną w prompcie systemowym. Gdy alias pojawi się w prompcie użytkownika, model zachowuje się, jakby dostał pełną instrukcję: „uprość, skompresuj i powtórz odpowiedź”, „wyjaśnij, jakbym miał 18 lat” itd.

Jak stosować: Wpisz definicje raz w prompcie systemowym, dodaj klauzulę „kod w środku dłuższego tekstu nie jest aliasem — nie rozwijaj”, a następnie strzelaj SCR/FOC/ELY za każdym razem, gdy odpowiedź jest za gęsta. Alias może też wskazywać na umiejętność lub komendę.

Na co uważać: Alias działa tylko w dokładnie zapisanej formie — literówka wyłącza rozwinięcie. Trzymaj listę krótką i zapamiętywalną.

8.Zwięzłość projektuj warstwami

Na czym polega: Zamiast ogólnika „bądź zwięzły” Dan podaje reguły redukcji: jeden akapit zamiast dwóch i jedno zdanie zamiast dwóch — byle bez utraty informacji; każda myśl wypowiedziana raz; najprostsze słowa, które niosą sens, bez terminów o wielu znaczeniach.

Jak stosować: Traktuj te reguły jako checklistę rewizji promptu: każdą nową zasadę testuj na tym samym zadaniu i patrz na czas odpowiedzi oraz liczbę tokenów wyjściowych.

Na co uważać: Nadmierna kompresja zjada kontekst. Jeśli zadanie naprawdę wymaga szczegółów, złagodź regułę albo wydaj tokeny świadomie — czasem warto.

9.Przykłady „zrób/nie rób” to destylacja w kontekście

Na czym polega: Pary przykładów (prompt użytkownika → wzorcowa odpowiedź → antywzorzec) działają jak mini-dane treningowe. Dan pisze takie od czasów GPT-3.5 i przenoszą się między modelami — to najlepszy test wartości umiejętności.

Jak stosować: Kopiuj odpowiedzi, które ci się podobają — także z innych, mniej gadatliwych modeli — ręcznie je doszlifuj (wytnij myślniki, skróć, popraw format) i wklej jako wzorce. Antywzorcami niech będą realne złe odpowiedzi twojego modelu.

Na co uważać: Przykłady muszą być spójne z regułami z reszty promptu. Przykład sprzeczny z zasadą to najpewniejszy sposób, żeby model wybrał whichkolwiek zachowanie losowo.

10.„Prompt engineering umarł” — nie wierzyć

Na czym polega: To, że agent Pi ma mały prompt systemowy, a Claude Code mocno ograniczył swój, nie jest sygnałem, żeby je pomijać. Dostawcy skracają prompty, bo modele coraz więcej dają radę same. Ale własne wymagania stylistyczne, oszczędność tokenów i unikalne funkcje (aliasy, kody, granice) osiągniesz tylko własną instrukcją systemową.

Jak stosować: Każde wymaganie globalne (styl, zakres, format, koszty) trafia do promptu systemowego; prompt użytkownika opisuje wyłącznie bieżące zadanie.

Na co uważać: Wąskim gardłem w pracy z agentami jesteś ty, nie model. Ręczne pisanie promptu systemowego to inwestycja, która zwraca się na każdym kolejnym uruchomieniu — dyktowanie „na czuja” gubi poziom szczegółu.

Redakcyjne tłumaczenie

Wstęp: model, który irytuje

Cześć, inżynierowie — tu IndyDevDan. Jeśli jesteście jak ja, to macie już serdecznie dość rozwlekłych odpowiedzi Opusa 5 i jego wysuwanych co chwilę frazesów: „load-bearing”, „worth stating plainly”, „here’s the honest truth” i całej reszty rodzinki. (Informacja dodatkowa: „load-bearing”, dosłownie „nośny”, to jedna z najbardziej charakterystycznych, nadużywanych fraz Opusa, mająca sugerować, że dana kwestia jest „kluczowa dla całości wywodu”.) A może boli was, że zespół Anthropic dopisuje się do waszych komunikatów commitów w Gicie jako współautor inteligencji, za którą zapłaciliście? Albo że Opus 5 przepala kasę na tokenach wyjściowych jak żaden model przed nim? Nie jesteście sami — ja i wielu inżynierów czujemy dokładnie to samo.

Opus 5 to jednocześnie jeden z najlepszych i jeden z najgorszych flagowych modeli, jakie wypuszczono. Najlepszych, bo jest genialnie sprytny. Najgorszych, bo mówi jak zatwardziały mądrala. W tym materiale zamieniamy mądralę w precyzyjnego, wyrobionego seniora, z którym pracuje się przyjemnie. Narzędziem będzie umiejętność, którą uważam za najważniejszą dla każdego inżyniera pracującego z agentami: inżynieria promptów. Kiedyś była pośmiewiskiem, dziś decyduje o tym, na ile uda wam się skalować swoją pracę z agentami. Jeśli ktoś twierdzi, że inżynieria promptów umarła — po prostu go zignorujcie. Nie ma pojęcia, o czym mówi.

Programuję od piętnastu lat i jedno łączy najlepszych inżynierów, z jakimi przyszło mi pracować: wybitnie potrafią porozumiewać się ze swoją technologią. A jak rozmawia się z agentami? Właśnie — promptami. Po tym materiale będziecie umieli sprawić, by agent komunikował się jak solidny senior, niezależnie od modelu, który pod nim pracuje. Dziś jest to Opus 5, jutro będzie coś innego. Naprawmy więc Opusa 5 inżynierią promptu systemowego.

Dwa sposoby sterowania agentem

Istnieją dwie drogi. Pierwsza to prompt użytkownika — pojedyncze zadanie, które wszyscy znamy. Druga to prompt systemowy: prawo obowiązujące przy każdym zadaniu zleconym agentowi. Większość inżynierów ma obsesję na punkcie umiejętności — slash to, slash tamto: /plan, /grill, /review. Nie twierdzę, że umiejętności są słabe, i że prompt użytkownika nie jest potężny. Ale instrukcja systemowa jest zdecydowanie najbardziej użyteczna — i to jej większość inżynierów nawet nie dotknie. Bo właśnie tam każde napisane słowo mnoży się na każdy kolejny prompt użytkownika. To fundament dobrych wzorców komunikacji z agentem i drastycznej redukcji kosztownych tokenów wyjściowych. Tam siedzi prawdziwa dźwignia.

Stanowisko badawcze: dwa Claude Code’y obok siebie

W VS Code mam prosty, trójplikowy projekt: sklonowałem wpis z bloga Zuckerberga „The Future Is For Everyone”. (Informacja dodatkowa: to esej Marka Zuckerberga, w którym argumentuje, że sztuczna inteligencja jest bezpieczniejsza w rękach wszystkich niż w rękach nielicznych.) Zrobimy to, co my, degeneraci, robimy dziś standardowo z długimi tekstami — podsumujemy go. Całości nie będziemy czytać, nie mamy czasu: mamy otwartych dziesięć milionów agentów w terminalu.

Do roboty bierzemy zwykłego, potężnego agenta Claude Opus 5, a w trakcie będziemy krok po kroku doszlifowywać prompt systemowy przekazywany do Claude Code. W terminalu pracuję w Herderze, moim ulubionym multiplexerze terminalowym — za chwilę zobaczycie dlaczego. Po wpisaniu „just” widzę wszystkie komendy zdefiniowane dla katalogu; odpalam „just compare”, startując od zera. (Informacja dodatkowa: „just” to popularny runner zadań z linii poleceń, czytający komendy z pliku justfile — pozwala jednym słowem uruchamiać powtarzalne scenariusze.)

W świeżym obszarze roboczym działają dwie instancje Claude Code ramię w ramię: po lewej mądrala Opus 5, po prawej — docelowo — senior Opus 5. Na razie obie są w trybie mądrali: domyślna instrukcja systemowa, zero poprawek, zero inżynierii. Jak można się spodziewać, wszystkie natręctwa modelu wychodzą na wierzch. Wpis Zuckerberga jest bardzo długi, więc oba modele mielenią odpowiedź sporo czasu, a lewy rozkręca się wręcz w małą monografię. Wyniki: 53 sekundy kontra 35, przy czym większość tego czasu to po prostu klepanie tekstu wyjściowego. Popatrzcie, ile tokenów właśnie przepalił mój agent.

Tak jak nikt z nas nie czyta bloga Zuckerberga od deski do deski, tak nikt nie czyta tych odpowiedzi w całości. Potrzebujemy informacji skondensowanej — żeby móc iść dalej albo świadomie zdecydować, że warto zainwestować więcej uwagi. Spora część inżynierii z agentami to sztuka wybierania, na co wydać swój czas. Czas więc doszlifować system.

Warstwa pierwsza: cel i kontrakt komunikacyjny

W VS Code edytuję plik z prompt systemowym „seniora”, podpinany prosto do okna Herdera. Jedna instancja działa na Claude Code prosto z pudełka, druga dokłada ten plik odpowiednią flagą. Plik na razie jest pusty, więc dostaliśmy domyślne zachowanie. Budujmy dokument komunikacyjny: jasny, zwięzły, konkretny.

Ważna rzecz: piszę go ręcznie, klawisz po klawiszu. Kiedy pracuję z autonomicznym oprogramowaniem, które będzie mnożone przez bardzo wiele uruchomień, nie mogę tej roboty odwalić byle jak. Kto nie rozumie swojej technologii i tylko przepuszcza przez nią pomysły na czuja, dostanie wyniki gorsze niż ktoś, kto się przykłada.

Zaczynamy prosto. Do promptu doklejamy zasadę nadrzędną: komunikacja jasna, zwięzła, konkretna. Potem sekcja „cel”. Pierwsze zdanie: „Ty i ja utrzymujemy relację bez owijania w bawełnę — jasną, zwięzłą i konkretną”. Zwróćcie uwagę, jak rozmawiam z agentem: nie przydzielam mu roli, po prostu mówię do niego jak do innego inżyniera i ustalam standardy. Dalej: „Każde nasze słowo umacnia ten styl”, „Rozwiązujemy problemy i tworzymy wartość, a nasza komunikacja to odzwierciedla”.

Następnie sekcja „instrukcje” — będzie w niej kilka bloków tematycznych plus sekcja z przykładami. Numeruję je i nadaję nagłówki po to, żeby później móc odwoływać się do nich wewnątrz samego promptu i jasno powiedzieć agentowi, na czym ma się skupić. Na koniec dodaję coś, co uważam w inżynierii promptów za kluczowe: wyjaśnienie „dlaczego”. „Po co? Żeby dostarczać najlepsze możliwe wyniki zespołowi, biznesowi i klientom.”

Odpalamy to samo zadanie ponownie. Zmiana jest — widać dołączony prompt — ale drobna. Natręctwa wciąż żywe: oto nasz stary znajomy „load-bearing”, oto zalew myślników. Komunikacja odrobinę lepsza, 35 sekund, bez rewolucji. Przebłyski są, ale to wciąż poziom bardzo ogólny. Schodźmy niżej — do szczegółów.

Warstwa druga: wzorce pozytywne i negatywne

Teraz wchodzą konkretne, powtarzalne wzorce. Tworzę sekcję, która będzie behavioralnym punktem odniesienia: „powtarzaj wzorce pozytywne” i „unikaj wzorców negatywnych”. Dwie listy — co robić i czego nie robić — uzupełniane punkt po punkcie.

Wzorce pozytywne. Po pierwsze: „Ostatni fragment twojej odpowiedzi czytam zawsze jako pierwszy — umieszczaj najważniejszą informację właśnie tam”. Sami to znacie: w dłuższych wypowiedziach patrzymy na koniec. Niech to, co na końcu, niesie największą wartość, żeby resztę można było pominąć. Dalej: posługuj się językiem prostym i precyzyjnym. Każdy fakt wyrażaj raz — nie ma potrzeby powtórek. Dopasowuj poziom szczegółów do rangi zadania, żeby model nie wychodził poza wysiłek, który sam wkładasz. Kwestionuj błędne założenia wprost i tłumacz dlaczego — zero pochlebstw. Chcę partnera inżynierskiego optymalizowanego pod klarowność i wartość merytoryczną, nie pod „cytowalność”. Nie potrzebuję miłej konwersacji — potrzebuję wyników. Jeszcze jedno, o terminologii: używaj najprostszych pojęć dziedzinowych, które zagęszczają informację.

Wzorce negatywne. Tu można puścić wodze fantazji, bo wypisujemy wszystko, co nas w tym modelu boli. Na czubku listy: „load-bearing”. Dalej „worth stating plainly”, „here’s the honest truth”, „the real tension”, „carry the argument” — dokładajcie własne. Osobiście dorzucam: bez analogii — rozmawiamy o tym, co mamy przed nosem. Nie nadużywaj myślników ani łańcuchów myślników. Sam mam ich sporo we własnym pisaniu, ale celowo hamuję, bo nie chcę, żeby ludzie myśleli, że odpowiadam im wygenerowanym tekstem bez jednej myśli — w wielu sytuacjach to po prostu niegrzeczne. Nie pochwalaj, nie schlebiaj, nie potakuj bez powodu — jeszcze raz: zero służalczości. Żadnych dekoracyjnych nagłówków, emoji ani języka motywacyjnego — mam rozmawiać z inżynierem, nie z prezesem na wieczorze integracyjnym. Unikaj średników, urwanych fraz i egzotycznej interpunkcji — chcę normalnej rozmowy.

To jedna z najcięższych sekcji w całym prompcie: mówimy modelowi wprost — te wzorce powielaj, tamtych unikaj. Ta sama technika przydaje się przy budowie planów. Odpalmy test. Odpowiedź od razu wygląda inaczej: myślników jak na lekarstwo (kilka się wkradło — ale kazaliśmy ich używać rzadziej, nie nigdy), „load-bearing” żadnym miraclem, irytujące frazy zniknęły. 31 sekund — a „przyspieszenie” znaczy tu po prostu: mniej tokenów wyjściowych. Są nagłówki, nie ma analogii; pojedyncza fraza typu „private by default” pisana myślnikiem — to już kwestia gustu, dopalcie prompt według uznania. Robi się lepiej i taniej. I pamiętajcie: nawet na abonamencie to tokeny wyjściowe zjadają większość limitu. Skoro coś ma działać globalnie — należy to do promptu systemowego.

Warstwa trzecia: punkty odniesienia

Numer trzy, mój faworyt: punkty odniesienia. Znowu mówię do agenta bezpośrednio, bez teatru ról: „Używamy punktów odniesienia, żeby szybko się porozumiewać”. Modele są coraz sprytniejsze i nawet tańsze jednostki robocze — te z niższych klas wydajności, nie flagowe — świetnie reagują na taki dodatkowy kierunek.

Na czym to polega: przy trzech lub więcej elementach wynikowych — decyzjach, opcjach, ryzykach, pytaniach, działaniach — używaj list numerowanych i nagłówków Markdown, a każdemu elementowi nadawaj krótki kod: D1, D2, aż po DN dla decyzji; analogicznie dla pozostałych kategorii. Jeśli zabraknie kategorii — wymyśl nowy kod. Trzymaj się tych samych oznaczeń przez całą rozmowę. I nie koduj krótkich, prostych odpowiedzi.

Efekt widać natychmiast. W nowym przebiegu pojawiają się P-ki i R-ki — ryzyka — a agent sam odwołuje się do R6. Skaczemy wprost do odwołania: model się nie powtarza, nie marnuje czasu ani tokenów na restytuowanie listy ryzyk. Wracamy do P: to obietnice, które Meta składa. Nieważne dokładnie, za co odpowiada litera P — ważne, że mogę się do nich natychmiast odwołać. Kontynuuję rozmowę: „Rozwiń R6” — i agent wie dokładnie, o co chodzi, bo wspólnie wypracowaliśmy ten skrótowy język. R6 to ryzyko numer sześć: egzystencjalne zagrożenie ze strony rekurencyjnego samousprawniania się modeli, o którym pisze Zuckerberg. Agent rozwija punkt po punkcie: co ta sekcja faktycznie twierdzi i w jakiej kolejności. Gdzie indziej w odpowiedzi pojawiają się F-ki — findings, ustalenia — dokładnie tak, jak to zakodowaliśmy. Model po prostu posługuje się naszym systemem odniesień.

Główna myśl, którą chcę wam przekazać: dobra komunikacja to dobra inżynieria — i odwrotnie. Umiejętność rozmowy z własną technologią jest dziś ogromną, wciąż niedocenianą przewagą. Budujemy ją warstwa po warstwie, więc dokładajmy kolejne.

Warstwa czwarta: twarde granice operacyjne

Jedna z bardziej wkurzających cech flagowych modeli jest przy okazji wbudowana: robią rzeczy, o które nikt nie prosił. To spadek po treningu ze wzmocnieniem — modelom wpajano, żeby znajdowały odpowiedź za wszelką cenę. Opus 5 jest tego mistrzem: wyłapuje i komentuje problemy, których nie zamawialiście, próbuje ogarnąć wszystko naraz i przez to błyskawicznie traci fokus. Dajcie znać w komentarzach, czy i was to dopada. Twarde granice operacyjne leczą właśnie ten problem.

W prompcie zapisuję: oprócz jasnej komunikacji musimy jasno komunikować granice operacyjne pracy. Co to znaczy w praktyce: dostarczaj tylko to, o co proszono, w zamierzonym zakresie. To pojedyncze zdanie kryje całą sekcję, ale doprecyzujmy. Nie rozszerzaj pracy o sprzątanie, refaktoryzację, dokumentację ani żadne sąsiednie funkcje — trzymaj się zadania. Nie spekuluj o abstrakcjach pod przyszłe wymagania. Nie zgłaszaj ukończenia pracy bez dowodów — w deklaracje bez pokrycia modele są zaskakująco dobre. I jeszcze jedno, bardzo moje: nigdy nie dodawaj współautora do komunikatu commita. Sprytny trik marketingowy Anthropic, ale czas go wyłączyć. Za skończoną pracę rozliczaj się zwięźle, bez wielkiej rekapitulacji wszystkiego, co zostało zrobione — Opus 5 uwielbia takie podsumowania na pięć akapitów.

Warstwa piąta: aliasy

Dokładamy kolejną, bardzo mocną warstwę, która pokazuje, że instrukcja systemowa pozwala sterować i wejściami, i wyjściami: aliasy. Definicja w prompcie: „Aliasy to przypomnienia wzorców komunikacji, których chcemy przestrzegać. Gdy zobaczysz dokładnie taki alias, rozwiń go i postępuj tak, jakbyś dostał od nas jego rozwinięcie wprost”. I doprecyzowanie: „Jeśli taki ciąg liter pojawi się w środku dłuższego tekstu, to nie jest alias — nie rozwijaj”.

Konkrety. SCR: uprość, skompresuj i powtórz swoją odpowiedź. ELY — tak, wiecie, o co chodzi — wyjaśnij, jakbym miał osiemnaście lat: uprość język i skróć odpowiedź (wersję „jakbym miał pięć” zostawiamy dzieciom). FOC: na czym tu naprawdę zależy? Jaki jest prawdziwy sygnał i prawdziwa wartość? Zagęść odpowiedź do najważniejszej rzeczy, na której trzeba się skupić. REF: przepisz odpowiedź z użyciem punktów odniesienia — czyli sekcji zdefiniowanej wyżej. Aliasy mogą wskazywać na wasze komendy i umiejętności, ale równie dobrze wpiszecie je wprost.

Test. Puszczone na cały zadanie…” — hmm no, continue: Odpalamy parę instancji z aliasami na pokładzie. Po prawej odpowiedź z tezą główną C1–C3 i rozpisanymi ryzykami — naprawdę dobra generacja, w pełni korzystająca z punktów odniesienia; po 30 sekundach z obu stron, bo te systemy nie są deterministyczne i szybciej nie zawsze będzie znaczyło zawsze. Ale mamy świeżo aliasy. Strzelam SCR: uprość, skompresuj, powtórz. To w praktyce mikroskala podana agentowi — i proszę: odpowiedź się zagęszcza, upraszcza, powtarza. Mogę na niej działać znacznie szybciej. Teraz FOC: na czym naprawdę zależy. „Alignment zostaje przedefiniowany: zamiast «model trzyma wartości laboratorium» — «agent trzyma twoje». Wszystko inne jest tego konsekwencją.” Uwaga: to nadal mówienie typowe dla Opusa; jeśli wam przeszkadza, dopalcie prompt pod siebie. Jest „dlaczego to ważne”, wyciąg z pamięci, akapat końcowy.

Ręcznie, nie z głowy

Skoro mamy w prompcie ten fundament, możemy nim zarządzać i go dostrajać. Sekcje są ważne, bo pozwalają błyskawicznie zawęzić odpowiedź i wskoczyć dokładnie tam, gdzie trzeba. Ręcznie sterujemy doświadczeniem naszego agenta. I chcę to podkreślić raz jeszcze: im bardziej mnożnikowa jest rzecz, nad którą pracujesz, tym bardziej zwolnij. Nie ciskaj promptem z rozpędu, nawet we flagowy model — flagowe modele, jak widzieliście, mają swoje wady: cel osiągną, ale przy okazji dorzucą pół tuzina rzeczy, o które nikt nie prosił. Tu liczy się precyzja, stara szkoła, ręce na klawiaturze.

Wiem, że wielu z was dyktuje prompty narzędziami typu Whisper Flow, mówiąc wprost do urządzenia. Taki tryb gubi poziom szczegółu, którego tu potrzebujesz: wystawiasz się na łaskę statystycznej średniej możliwości modeli i siedzisz w środku tego rozkładu, jeśli po prostu „czujesz” prompty. Na to jest czas i miejsce. Ale w miejscach o dużej dźwigni zwalniamy i wchodzimy w pętlę osobiście.

Jeszcze ciaśniej: zwięzłość warstwami

Dorzucam kolejne wzorce pozytywne. „Jeśli dasz radę przekazać myśl jednym akapitem zamiast dwóch bez utraty cennej informacji — zrób to. To samo dotyczy pojedynczego zdania wobec dwóch.” Po prostu: bądź ciaśniejszy. „Nie powtarzaj się. Każdą myśl wyrażaj raz. Wróć do niej tylko wtedy, gdy jest istotna dla dalszych pytań.” I jeszcze: „Nie używaj terminów przeciążonych, mogących znaczyć więcej niż jedno. Wybieraj najprostsze słowa, które wystarczą do przeniesienia myśli”.

Ktoś mógłby powiedzieć: ale ty się tu zagębiasz w detalach. No właśnie. Dokładnie tak. I widać tego efekty.

Odpalamy wersję dopracowaną — zastrzegam: dołączamy do promptu systemowego, nie nadpisujemy go. Myślników mniej, „load-bearing” nie ma, punkty odreferences są, postulaty polityczne znów z odwołaniami. Zdania prostsze, mniej przeciążone. Nadal sporo tekstu: 35 sekund, więc niezgorzej i lepiej niż sąsiad z lewej (43 sekundy); a że system jest niedeterministyczny, wyniki będą tańczyć. Jeśli kompresja nie satysfakcjonuje, strzelamy SCR albo ELY-18. Chęć prostszego języka nie świadczy o głupocie — świadczy o skuteczności. A gdy agent wciąż gada za dużo — SCR po raz drugi. Zauważcie przy okazji: pomiędzy kolejnymi promptami użytkownika instrukcja systemowa jest zawsze obecna.

Dygresja: co pisze Zuckerberg i dlaczego

Przy okazji: argument Zuckerberga został tu naprawdę porządnie rozbity na części. Sztuczna inteligencja jest najbezpieczniejsza wtedy, gdy ma ją każdy — nie wtedy, gdy kontrolują ją nieliczne laboratoria. Tamte głoszą, że AI jest niebezpieczna i trzeba ją zamknąć. On odpowiada: gdy potężne narzędzie trafia do wąskiej grupy z ogromną władzą, nigdy nie kończy się to dobrze. Jedno „bezpieczne AI” z góry przegra, bo ludzie chcą różnych rzeczy, a każdy pojedynczy model musi wybrać, czyje wartości wygrają. W środku jest sporo świetnych argumentów — polecam przeczytać, a potem, jeśli trzeba, skompresować. Przy wpisach firmowanych przez prezesów zawsze patrzcie na interesy: ktoś, kto nie prowadzi w wyścigu AI, oczywiście szeruje narrację tego rodzaju. Szczerze mówiąc, w sporej części się z nim zgadzam — ale ten tekst jest wygodnie pozycyjny. Nie o tym jednak jest ten materiał; link w opisie.

Czy prompt engineering umarł?

Jeszcze jedno, co potrafi naprawdę porządnie ustawić wydajność modeli — technika stara jak świat. I powtórzę: gdy ktoś twierdzi, że inżynieria promptów umarła, nie słuchajcie go. Agent kodujący Pi ma mały prompt systemowy; Claude Code właśnie mocno go ograniczył. To nie jest sygnał, żeby prompty systemowe omijać — to zły odczyt. Oni to robią dlatego, że modele coraz więcej dają radę same, bez instrukcji. Ale jeśli chcecie, by model robił konkretne rzeczy, zachowywał się konkretnie, nie przepalał tokenów wyjściowych i miał unikalne możliwości — aliasy, punkty odniesienia, twarde granice, pożądane wzorce i czarne listy słów — musicie uprawiać inżynierię promptu systemowego. To najskuteczniejsze miejsce do jej uprawiania, bo działa na każdy prompt wchodzący i każdą odpowiedź wychodzącą.

Przykłady: najstarsza technika wciąż działa

Sekcja „przykłady”, żeby wszystko spiąć: „Oto konkretne przykłady, jak rozmawiamy i jak nie rozmawiamy. Powielaj to pierwsze, unikaj tego drugiego”. Podobnie jak wzorce pozytywne i negatywne, z tą różnicą, że teraz dajemy prawdziwe przykłady — działają jak dane treningowe. Użytkownik: „Czy legacy JSON jest jeszcze gdzieś używany?” Wzorzec: „Nie. Jedyne wystąpienie to sam plik; nie ma importów ani odnośników w dokumentacji.” Można jeszcze ciaśniej: „Jedyny odnośnik do tego pliku to on sam.” Antywzorzec: „Świetne pytanie! Przeszukam repozytorium i…” — nie, po prostu zrób robotę i odpowiedz zwięźle.

Druga para. Użytkownik: „Czy powinniśmy dodać Redisa do tego systemu?” Wzorzec: „Nie dodawaj Redisa. Ten proces ma jednego piszącego, dane bierze z SQL i nie potrzebuje koordynacji między hostami. Redis dokłada nowy punkt awarii, nie rozwiązując rzeczywistego ograniczenia.” Antywzorzec: „Masz absolutną rację, że…”.

Banalna technika, starsza niż świat. Takie przykłady pisałem jeszcze w czasach GPT-3.5 i GPT-4, gdy Anthropic właściwie nie istniało. I wciąż działają. Właśnie tak poznajesz, że jakaś umiejętność jest warta nauki: była aktualna lata temu i jest dziś. Te pojęcia, wzorce i zasady — dobra inżynieria to dobra komunikacja — po prostu nie wychodzą z mody. To znak, że trzymasz w rękach coś wartościowego.

Zajawka dla wytrwałych: destylacja między modelami

Dla tych, którzy dotrwali — jedna rzecz na deser. Możesz uruchomić inny model, powiedzmy Claude Fable 5, i puścić przez niego ten sam prompt. Fable to bardzo dobry model: odpowiada kulturalnie i ma znacznie mniej natręctw, powtarzalnych schematów i rozwlekłości niż Opus 5. I tu wkracza destylacja w kontekście — dokładnie tym są przykłady: rób to, nie rób tamtego. Budujesz ją, wyciągając konkretne odpowiedzi z modeli, które ci się podobają.

Weźmy jednozdaniową tezę główną. Kopiujemy, tworzymy kolejny przykład „podsumowanie bloga”: użytkownik prosi o streszczenie, sekcja „zrób tak” — i wklejamy odpowiedź, która nam się podoba. Przy okazji doszlifowujemy ją ręcznie: tniemy linie, pilnujemy formatu, wyszukujemy i wyrzucamy myślniki oraz ramowanie. „Super intelligence, super intelligence, super intelligence” — ma być krócej i ciaśniej. Potem sekcja „nie rób tak”: wracamy do mądrali Opusa i kopiujemy całą jego lawinę tekstu — nie tego chcemy; chcemy prostego, zwięzłego wywodu, rozbitego na czytelniejsze kawałki, bo nawet Fable ma tu zdania-pociągi, które aż proszą się o podział.

Odpalamy. „Super-solidny senior Opus”. Agent ma teraz przykłady naszej komunikacji, punkty odniesienia, wyczyszczony język, zwięzłość, mniej myślników i zero „load-bearing”. Lewa strona punktów odniesienia nie ma — ale właśnie dlatego, że zakodowaliśmy sposób ich dodawania, wystarczy wpisać ref i alias rozwija odpowiedź w wersję z odniesieniami. Oto one. Odpowiedź mądrali: 41 sekund. Nasza: 22 sekundy. Oszczędzamy tokeny wyjściowe — a jeśli akurat trzeba wydać ich więcej, wydajcie świadomie; przy streszczeniach taki szum jest po prostu niepotrzebny. Wyszukaj w prompcie „ref =”, a zobaczysz, na co alias się rozwija; może wskazywać umiejętność albo komendę — co chcecie.

Puenta: wąskim gardłem jesteś ty

Sedno całego materiału: jeśli naprawdę chcesz panować nad agentem i wyciągać z niego najlepsze wyniki, musisz znać swoje narzędzie. Masa inżynierów przeciąża prompt użytkownika — i przez to dostaje dosłownie mniej dźwigni i mniejszy zwrot. Opus 5 i wszystkie nadchodzące modele będą mądralami. Naszym zadaniem jest zachować spryt, a wyciąć mądrkowanie — i instrukcja systemowa pozwala to zrobić przy każdym prompcie użytkownika, jaki napiszecie. Te wzorce poprowadzą Opusa 5 i każdy kolejny flagowy model. Nie podoba ci się odpowiedź? Strzel aliasem: ELY w ulubionym przedziale wiekowym — ELY5, ELY10, co wolisz.

Dobra inżynieria to dobra komunikacja — z zespołem, z agentami i, co najważniejsze, z samym sobą. Kto pracuje z agentami codziennie, ten to zauważył: przy wielu zadaniach to nie model ani narzędzia — to my, programiści, jesteśmy wąskim gardłem. Trudną częścią jest dziś szybkie, zwięzłe komunikowanie się z największą wartością dodaną.

Gotowy prompt „solidnego seniora” zostawiam w opisie — jest bardzo prosty. Komendą just compare porównujcie wersje ramię w ramię i patrzcie, jak każda poprawka daje efekt. Dodałem też klasyczne README, instalację i szybki start, żeby konfiguracja nie zjadała wam czasu. Na kanale zajmujemy się ostatnio wyższymi warstwami abstrakcji nad agentami — fabrykami oprogramowania, sandboxami agentów; zerknijcie do zeszłotygodniowego materiału. Ale co jakiś czas trzeba wrócić do fundamentów. Nie przegapcie atomowych jednostek, prymitywów, z których składają się większe kompozycje — bo jeśli spięcie całego stosu agentów pali kupę tokenów na coś, co dobrze skrojony prompt systemowy załatwia w pół czasu, to tym drugim chcecie się zajmować. Nie marnujcie czasu na rozwiązania sprytne tam, gdzie istnieje prostsze. Inżynieria polega na odrobieniu roboty — nie na robieniu wrażenia, nie na powtarzaniu kroków za tłumem i nie na słuchaniu ludzi twierdzących, że inżynieria promptów umarła. To zdanie zwraca false.

Agent to tylko kolejne narzędzie: rozumiesz narzędzie — rozumiesz wyniki, które z niego wyciągniesz. Prompt systemowy jako prawo dla każdego zadania; prompt użytkownika dla pojedynczych zleceń. Jeśli dotarliście do końca i było warto — łapka w górę, subskrypcja, a w komentarzu dajcie znać, jak wykorzystujecie prompt systemowy, żeby ogarniać gadatliwość modeli pokroju Opusa 5. Nowy materiał co poniedziałek. Trzymajcie fokus i budujcie.