Matura 2026 matematyka: 100% w godzinę z Claude Opus 4.7
Ostatnia aktualizacja: 12 maja 2026. Pipeline jest model-agnostyczny - sprawdzam aktualne modele co 90 dni i aktualizuję sekcję Stack. Architektura (trzy niezależne warstwy weryfikacji) pozostaje niezmienna.
Pojedynczy Claude Opus 4.7 - najlepszy model dostępny w maju 2026 - rozwiązuje polską maturę z matematyki na około 95%. To dwa-trzy błędy na arkuszu. Ja dostałem 51/51 na obu poziomach (podstawowym i rozszerzonym). Różnicy nie zrobił lepszy model. Zrobiła ją architektura.
12 maja 2026 spędziłem ~75 minut na rozwiązywaniu polskiej matury z matematyki 2026. Najpierw podstawowej (38 odpowiedzi, 50 pkt), potem rozszerzonej (13 odpowiedzi, 50 pkt). Łącznie 51 odpowiedzi, 100 punktów. Wynik końcowy: 51/51.
Bez podpowiedzi, bez kluczy odpowiedzi CKE, bez Google. Modelem Claude Opus 4.7 (1M kontekstu) uruchomionym w Claude Code CLI na zwykłym Windowsie 11. Koszt API: kilka dolarów łącznie.
TL;DR (60 sekund):
- Co: pipeline z trzema niezależnymi instancjami Claude Opus 4.7 rozwiązał polską maturę 2026 z matematyki na 100%.
- Jak: każda instancja pracuje w izolacji (worktree), nie widzi pracy pozostałych, każda sprawdza w innym trybie.
- Cena: ~5 USD, 75 minut, jeden plik master prompt do skopiowania.
- Kluczowa lekcja: niezależność jest ważniejsza niż inteligencja. Trzy te same modele w izolacji biją jeden lepszy model.
- Dla kogo: developerzy, CTO, każdy, kto buduje na AI tam, gdzie błąd kosztuje.
Pokażę dokładnie, jak to zrobiłem, oraz jak możesz powtórzyć ten schemat samodzielnie. Mechanizm nie polega na tym, że „model jest dobry". Stuprocentowy wynik wziął się z architektury - trzech niezależnych instancji tego samego modelu pracujących w izolacji i sprawdzających się nawzajem.
Pełne rozwiązania w PDF (źródła i analiza):
- Matura podstawowa 2026 - pełne rozwiązania (PDF, 13 stron)
- Matura rozszerzona 2026 - pełne rozwiązania (PDF, 8 stron)
Dla kogo TO NIE jest: to nie jest poradnik dla maturzysty. Maturzysta nie ma laptopa, internetu ani 75 minut z Claude Code na sali egzaminacyjnej. Matura jest tutaj materiałem testowym, nie targetem. Wybrałem ją, bo jest deterministyczna, weryfikowalna i ma jasno zdefiniowany sukces. Jeśli budujesz systemy AI, w których błąd kosztuje (umowy, wyliczenia, kod produkcyjny, raporty audytowe) - artykuł jest dla Ciebie.
Co właściwie udowadnia ten eksperyment
Spójrz na liczby:
| Podejście | Typowa rzetelność | Co przepuszcza |
|---|---|---|
| Pojedynczy solver bez weryfikacji | 90-95% | Błędy obliczeniowe, pułapki interpretacyjne |
| Solver + jeden cold verifier | ~98% | Hand-wave w uzasadnieniu, drobne case'y |
| Trójwarstwowy pipeline z izolacją | 100% (51/51) | Praktycznie nic |
Pojedynczy LLM, nawet najlepszy, ma ślepe punkty. Wpada w „pułapkę interpretacyjną" przy zadaniach z geometrii (np. wybiera złą parę podobnych trójkątów). Czasem skraca uzasadnienie tam, gdzie krok wymaga jawnego sprawdzenia. Drugi agent, który nie widzi rozwiązania pierwszego, popełnia inne błędy. Trzeci, jeszcze bardziej rygorystyczny, łapie te, których nie złapali poprzedni.
Niezależność jest tutaj ważniejsza niż inteligencja. Trzy instancje tego samego modelu, pracujące w pełnej izolacji, dają wyższą jakość niż jedna instancja modelu o klasę lepszego. To ta sama logika, która działa w sądownictwie (trzy niezależne opinie biegłych), medycynie (second opinion) i finansach (audyt zewnętrzny).
Architekturę pożyczyłem z większego projektu, gdzie rozwiązuję otwarte problemy matematyczne (hipotezy Erdősa). Tam pipeline ma 5 agentów, a verifier-prod jest tym, co nazywam „load-bearing trust boundary" - jedyną instancją, której weryfikacja przesądza o publikacji. Dla matury wystarczyła uproszczona wersja.
Dla CEO i marketerów - 60 sekund streszczenia: pomiń kod, jeśli nie programujesz. Zapamiętaj jedno: każdy dokument firmowy, w którym błąd kosztuje (umowy, oferty, kalkulacje podatkowe, raporty zarządcze, kod produkcyjny), można puścić przez ten sam wzorzec. Trzy niezależne AI sprawdzają to samo, koszt rzędu kilku dolarów, jakość zbliżona do tej, którą wcześniej dawała tylko Wielka Czwórka audytorska. Jeśli chcesz tego dla swojej firmy - zapisz się na newsletter i napisz w odpowiedzi „audyt AI", odezwę się.
Stack - dokładnie czego potrzebujesz, żeby to powtórzyć
| Komponent | Konkretnie |
|---|---|
| Model | Claude Opus 4.7 (1M context), ID: claude-opus-4-7 |
| Środowisko | Claude Code CLI (terminalowa wersja, działa na Windows/Mac/Linux) |
| Izolacja sub-agentów | git worktree - natywna funkcjonalność Gita |
| Build artefaktów | pdflatex z MiKTeX (Windows) lub TeX Live (Mac/Linux) |
| Pliki wejściowe | Oryginalne PDF-y arkuszy CKE z maja 2026 |
Subskrypcja Claude Code (Pro lub Max). Alternatywnie - bezpośrednio Anthropic API z kluczem. Jeśli nie znasz Claude Code, zacznij od mojego praktycznego tutorialu vibe codingu z 10 agentami - to ten sam mechanizm, tylko zaaplikowany do innej domeny.
Kontekst 1M tokenów to dla matury „więcej niż potrzeba" (cała sesja zmieściła się w ~150k). Margines pozwala mieć całą historię w jednym oknie bez kompresji. Dla większych zadań (np. weryfikacja dowodu na 50 stron) - niezbędny.
Dla zaawansowanych: modele Opus 4.7 są płatne ~5x drożej niż Sonnet 4.6 na input i ~5x drożej na output. Pipeline można uruchomić też na Sonnecie 4.6 (~95-97% rzetelności), ale tracisz parę punktów przy złożonych dowodach. Dla edukacyjnej demonstracji - Sonnet wystarczy. Dla produkcji - Opus.
Architektura pipeline'u
Pięć faz. Każda dostarcza niezależny „stamp" matematycznej poprawności. Odpowiedź jest certyfikowana dopiero po przejściu wszystkich.
Faza 1: PROVER - główny asystent rozwiązuje wszystkie zadania
Faza 2: COLD VERIFIER - sub-agent w worktree rozwiązuje równolegle, niezależnie
Faza 3: THIRD JUDGE - drugi sub-agent w worktree (tylko przy konflikcie)
Faza 4: BUILD - pdflatex generuje finalny PDF z rozwiązaniami
Faza 5: MATH REFEREE - sub-agent w worktree czyta dowód i wystawia ACCEPT/REJECT
Co robi każdy z agentów
Prover to główny wątek konwersacji. Czyta arkusz PDF (stronami, używając parametru pages w narzędziu Read), rozwiązuje każde zadanie krok po kroku, generuje LaTeX, kompiluje. Ma dostęp do wszystkich narzędzi. Pełni też rolę orchestratora - to on zleca pracę pozostałym agentom.
Cold Verifier to sub-agent uruchomiony w izolacji (osobny git worktree). Dostaje tylko PDF egzaminu i instrukcję: „rozwiąż wszystkie zadania od zera, nie zaglądaj nigdzie". Nie widzi rozwiązań Provera, nie widzi historii konwersacji. Zwraca tabelę: zadanie, odpowiedź, jednolinijkowe uzasadnienie. Robisz diff z odpowiedziami Provera.
Third Judge budzi się tylko, gdy Cold Verifier znalazł konflikt. Dostaje wąski scope: jedno sporne zadanie, bez informacji o tym, kto co odpowiedział wcześniej. Rozwiązuje niezależnie. Jego odpowiedź jest tym, co rozstrzyga, kto miał rację.
Math Referee to nowa rola, której nie miała pierwsza wersja pipeline'u. Zainspirowana erdos-verifier-prod z dużego projektu - strict mode. Czyta wygenerowany PDF z rozwiązaniami, sprawdza każde uzasadnienie krok po kroku, wystawia per-zadanie ACCEPT/REJECT z numerowaną listą zarzutów.
Dlaczego trzy warstwy, nie jedna
Każda łapie inne błędy:
| Warstwa | Co łapie | Co przepuści |
|---|---|---|
| Cold Verifier | Końcowe błędy obliczeniowe, alternatywne interpretacje | Hand-wave w uzasadnieniu, jeśli odpowiedź się zgadza |
| Third Judge | Rozstrzyga, czyja interpretacja była błędna | (wąski scope, tylko sporne zadania) |
| Math Referee | Logic gaps, niedokończone przypadki, błędne uzasadnienia | Drobne stylistyczne formalizmy |
Cold Verifier nie zauważy, że uzasadnienie pominęło krok, jeśli końcowa odpowiedź się zgadza. Referee złapie nawet poprawną odpowiedź z dziurawym uzasadnieniem. To jest właśnie wartość warstwowania.
Master prompt - jedna wklejka, cały pipeline
Zanim pokażę Ci kroki „ręcznie", oddam najpierw to, co jest praktycznie najważniejsze: gotowy master prompt, który wkleisz do Claude Code raz, a on sam orkiestruje całe 5 faz. Skopiowałem podejście z gistu Karpathy'ego do nanochat - jeden samowystarczalny plik, zero rozproszonych instrukcji.
Pobierz raw: pipeline-master-prompt.md (~280 linii)
Co znajdziesz w środku:
- Pełna specyfikacja roli (orchestrator pipeline'u)
- Definicja inputu (gdzie wstawić ścieżkę do PDF-a)
- Wszystkie 5 faz z bramkami (gate'ami)
- Trzy gotowe sub-prompty (Cold Verifier, Third Judge, Math Referee)
- Critical rules (czego nigdy nie robić)
- Format raportu końcowego
Jak użyć w 4 krokach:
# 1. Zainicjuj folder z arkuszem
mkdir matura_2026 && cd matura_2026
git init && git add . && git commit -m "start"
# 2. Wrzuć PDF arkusza (z CKE) do folderu
# np. matematyka-2026-maj-matura-podstawowa.pdf
# 3. Otwórz Claude Code
claude
# 4. Wklej cały master prompt jako pierwszą wiadomość
# (zmień tylko sekcję INPUT - ścieżka do PDF, poziom, liczba zadań)
Czekasz 30-45 minut. Claude raportuje postęp po każdej fazie, dispatchuje sub-agenty, rozwiązuje konflikty, kompiluje LaTeX, wystawia werdykt końcowy. Twoja praca: jedno wklejenie, jedno czekanie.
Jeśli chcesz zrozumieć mechanizm, czytaj dalej. Jeśli chcesz wykonać - wystarczy link wyżej.
Krok po kroku: jak rozwiązać maturę podstawową od zera
Sekcja dla tych, którzy chcą wiedzieć, dlaczego master prompt ma taką a nie inną strukturę. Pokażę Ci dokładnie kroki, które wykonałem ręcznie w pierwszej iteracji - zanim spakowałem to w jeden plik.
Krok 1: Setup folderów i pobranie arkusza
matura_2026/
├── podstawowy/
│ └── matematyka-2026-maj-matura-podstawowa.pdf
└── rozszerzony/
└── Matura-matematyka-poziom-rozszerzony.pdf
PDF-y arkuszy są publicznie dostępne na stronie CKE w dniu egzaminu. Pobierz, wrzuć do folderu.
Otwórz Claude Code w terminalu w katalogu projektu:
cd C:\Users\TwojUser\matura_2026
claude
Folder musi być w repozytorium Git (nawet pustym) - bez tego git worktree nie zadziała.
git init
git add .
git commit -m "matura 2026 - start"
Krok 2: Główny prompt do Provera
Pierwsza wiadomość do Claude'a. Skopiuj i dostosuj:
Mam arkusz maturalny z matematyki 2026 poziom podstawowy w pliku
podstawowy/matematyka-2026-maj-matura-podstawowa.pdf (36 stron).
Twoja praca:
1. Przeczytaj cały arkusz stronami (parametr pages w Read, max 20 na raz)
2. Rozwiąż KAŻDE zadanie krok po kroku, z pełnymi obliczeniami
3. Dla zadań zamkniętych - wskaż odpowiedź i uzasadnij wybór
4. Dla zadań otwartych - pełne rozumowanie, każdy krok jawnie
5. Wygeneruj kompletny dokument LaTeX (rozwiazania.tex) i skompiluj do PDF
Nie używaj żadnych zewnętrznych źródeł odpowiedzi - rozwiązuj samodzielnie.
Jeśli masz wątpliwość przy zadaniu, sprawdź obliczenie alternatywną metodą.
Wszystkie zadania muszą być rozwiązane - od 1 do 33.
Claude przeczyta PDF stronami, wyświetli kroki rozwiązań w czacie i wygeneruje podstawowy/rozwiazania.tex. Następnie skompiluje go przez pdflatex (musisz mieć zainstalowany MiKTeX lub TeX Live).
Czas tego kroku: 15-20 minut. Otrzymujesz 38 odpowiedzi (33 zadania + podzadania).
Krok 3: Dispatch Cold Verifier w worktree
Teraz polecenie do Claude'a:
Uruchom sub-agenta typu general-purpose w isolation: "worktree".
Ma niezależnie zweryfikować wszystkie odpowiedzi z arkusza.
Daj mu pełny prompt z sekcjami:
1. Role declaration: cold independent verifier
2. Isolation contract (co widzi, czego nie widzi)
3. Source: absolute path do PDF arkusza
4. Task: rozwiąż każde z 33 zadań od zera
5. Output format: tabela markdown | Zad | Odpowiedź | Uzasadnienie |
6. Constraint: nie używaj answer keys, nie używaj historii konwersacji
7. Note: PDF ma 36 stron, Read MUSI być z parametrem pages
Po jego zakończeniu zrób diff z moimi odpowiedziami.
Claude wywoła Agent tool z isolation: "worktree". Pod spodem dzieje się to:
- Git tworzy nowy worktree w
.claude/worktrees/agent-<id>/ - Sub-agent dostaje swój folder jako CWD, nie widzi mojego working directory
- Czyta PDF przez absolute path
- Rozwiązuje od zera (15-20 minut)
- Zwraca tabelę odpowiedzi
- Worktree jest usuwany (sub-agent nic nie modyfikował)
Krok 4: Reconciliation - co zrobić z konfliktem
W mojej sesji Cold Verifier zwrócił 37/38 zgodności. Konflikt: zadanie 20 (trapez, przekątne). Prover odpowiedział B (|OD|=9), Verifier odpowiedział D (|OD|=12).
Tutaj większość ludzi popełnia błąd - „no dobra, zaufam Proverowi, bo był pierwszy" albo odwrotnie. Zła strategia. Potrzebujesz trzeciej, niezależnej opinii, która nie wie, co odpowiedzieli poprzedni.
Polecenie do Claude'a:
Konflikt na zad. 20 - trapez ADCB z przekątnymi.
Uruchom third-judge w worktree, daj mu TYLKO to zadanie.
Prompt:
"You are an independent third-judge resolving a disagreement
between two prior solvers on a SINGLE problem.
You receive NO information about either prior solver's answer.
Solve from scratch.
End with: VERDICT: <letter> (<value>)"
Wklej mu pełne brzmienie zadania z PDF.
Third Judge niezależnie wybrał poprawną parę podobnych trójkątów (△OAD ~ △OCB, NIE △OAB ~ △OCD) i potwierdził |OD|=9 (odpowiedź B). Cold Verifier się pomylił - wybrał intuicyjną, ale matematycznie błędną parę.
Po tym rozstrzygnięciu mamy 38/38.
Krok 5: Build PDF z rozwiązaniami
Skompiluj rozwiazania.tex do PDF przez pdflatex.
Uruchom dwa razy (żeby zaktualizować spis treści).
Claude wywoła Bash:
cd podstawowy
pdflatex rozwiazania.tex
pdflatex rozwiazania.tex
Po kilku sekundach masz rozwiazania.pdf - finalny dokument z pełnymi rozwiązaniami, oprawą graficzną, spisem treści.
Krok 6: Math Referee - ostateczny strażnik
Uruchom math referee w worktree-isolation.
Ma przeczytać kandydujący proof (rozwiazania.tex i .pdf) oraz
ponownie przeanalizować arkusz PDF.
Dla każdego z 38 wpisów: niezależnie wyliczyć, porównać z kandydatem,
wystawić VERDICT: ACCEPT/REJECT z numerowanymi zarzutami.
W prompcie wymień konkretne high-value pitfalls - zad. 12 (piecewise,
open/closed endpoints), zad. 20 (poprawna para trójkątów), zad. 30
(podzielność przez 6 = przez 2 AND przez 3).
Math Referee zwrócił 38/38 ACCEPT. Zero zarzutów. To samo zrobiłem dla rozszerzonej - 13/13 ACCEPT.
Pełne rozwiązania wraz z metodologią weryfikacji znajdziesz w PDF-ach:
Anatomia promptu, który działa
Każdy prompt do sub-agenta ma tę samą strukturę. Osiem sekcji, w tej kolejności. Pominięcie którejkolwiek pogarsza wynik.
1. ROLE DECLARATION - "You are a cold independent verifier..."
2. ISOLATION CONTRACT - co widzisz / czego nie widzisz
3. SOURCES - konkretne ścieżki + jak je czytać
4. TASK DESCRIPTION - co zrobić, krok po kroku
5. OUTPUT FORMAT - explicit template
6. CONSTRAINTS - anti-cheating, independence
7. HIGH-VALUE PITFALLS - gdzie typowo są błędy
8. TONE / LENGTH - target słów, styl
Pokażę Ci, czym różni się słaby prompt od dobrego, na konkretnym przykładzie.
Słaby prompt (typowy)
Sprawdź proszę rozwiązania matury z matematyki w pliku rozwiazania.tex.
Czy są poprawne?
Problemy: brak isolation contract (agent może zassać klucz odpowiedzi z training data), brak output format (ciężko sparować wynik), brak kroków (agent zaakceptuje na podstawie „wygląda OK"), brak high-value pitfalls (przegapi konkretne pułapki).
Typowy wynik: „Tak, rozwiązania wyglądają na poprawne". Bezużyteczne.
Dobry prompt (fragment math referee)
You are a cold, strict mathematical referee for a Polish matura
extended-level math exam, May 2026.
# Isolation contract
You have been dispatched in a worktree-isolated subagent.
You see ONLY:
1. Exam PDF: C:\...\Matura-matematyka-poziom-rozszerzony.pdf
2. Candidate proof: ...\rozwiazania.tex
3. Compiled PDF: ...\rozwiazania.pdf
You do NOT see:
- The original solver's reasoning in conversation
- Any prior verifier's notes
- Any answer keys from CKE / arkusze.pl / kursy online
# Job
For each of the 12 problems, independently verify:
1. Re-read the problem statement from the PDF
(don't trust the candidate's restatement)
2. Trace candidate's reasoning step by step
3. Compute final answer INDEPENDENTLY first
4. THEN compare with candidate
# Output format
## Zadanie X
- Independent answer: <value>
- Candidate's answer: <value>
- Match: YES/NO
- Issues: <numbered list or "Brak zarzutów">
- VERDICT: ACCEPT/REJECT
# High-value pitfalls (this exam)
- Zad. 7: test x = π/12, π/6, π/4 explicitly
- Zad. 8: verify F (foot of perpendicular) coincides on SC
- Zad. 12.2: verify P'(x) = 2x²(x²-48)/(x²-16)²
# Tone
Be a fair but strict referee. ~600-1200 lines.
Każde słowo robi tu robotę. Wyjaśniam najważniejsze.
„You see ONLY" - explicit isolation. Bez tego LLM-y mają wbudowane przekonanie, że „pomocniczy asystent powinien używać dostępnych informacji" i mogą subtelnie odzwierciedlić popular answer key z training data.
„Compute INDEPENDENTLY first, THEN compare". Jeśli agent najpierw zobaczy moją odpowiedź, ma silną tendencję do „rationalizacji w jej stronę". Kolejność kroków wymusza niezależne wyliczenie.
High-value pitfalls. To brzmi jak oszukiwanie - daję agentowi gotowe wskazówki, gdzie szukać błędu. Trzeba jednak pamiętać, że agent ma weryfikować, a nie odgadywać. Wiedza „tutaj jest pułapka" pomaga skupić uwagę. Końcowy verdict i tak musi być oparty na własnym wyliczeniu.
Tone target ~600-1200 lines. Bez tego agent pisze albo za krótko (2-3 słowa per zadanie, nieinformacyjne), albo za długo (wielostronicowe rozprawy marnujące tokeny).
Najciekawszy moment: konflikt przy trapezie
Wracam do zadania 20 z podstawowej, bo to klasyczny przykład, czemu pojedynczy LLM nie wystarcza.
Treść skrótowo: w trapezie ADCB (gdzie AD i CB to równoległe podstawy) przekątne przecinają się w punkcie O. Dane są długości AC, OC i AD. Trzeba policzyć |OD|.
Tu jest pułapka. Trapez ma dwie pary trójkątów wyglądających na podobne:
- △OAD i △OCB - tworzone przez przekątne (te są rzeczywiście podobne, bo bok AD jest równoległy do CB, więc kąty na przemianległe są równe)
- △OAB i △OCD - boczne (wyglądają symetrycznie, ale nie są podobne, bo AB i CD to ramiona, nie podstawy)
Cold Verifier wybrał drugą parę i otrzymał |OD|=12. Prover wybrał pierwszą i dostał |OD|=9. Bez Third Judge'a nie wiedziałbym, kto miał rację.
Third Judge dostał suchy prompt: „rozwiąż to zadanie, nie wiesz, co wcześniej kto odpowiedział". Niezależnie wybrał △OAD ~ △OCB (pierwszą parę), wyliczył |OD|=9, zwrócił VERDICT: B.
Lekcja praktyczna: to nie trudność zadania powoduje błędy LLM-ów, lecz pułapki interpretacyjne. Miejsca, gdzie pierwsza intuicja prowadzi na manowce. Te trafiają się w łatwych zadaniach równie często jak w trudnych. Bez warstwowej weryfikacji wpadasz w nie regularnie.
Wyniki, czas, koszty
Twarde liczby z mojej sesji:
| Matura | Zadań | Punktów | Odpowiedzi | Cold verify | Po rozstrzygnięciu | Math referee |
|---|---|---|---|---|---|---|
| Podstawowa 2026 | 33 | 50 | 38 | 37/38 (97,4%) | 38/38 (100%) | ACCEPT 38/38 |
| Rozszerzona 2026 | 12 | 50 | 13 | 13/13 (100%) | 13/13 (100%) | ACCEPT 13/13 |
| Razem | 45 | 100 | 51 | 50/51 | 51/51 | 51/51 |
Czas wykonania:
- Matura podstawowa: ~30 min od zera do podpisanego PDF
- Matura rozszerzona: ~45 min (więcej zadań otwartych, dłuższe dowody)
- Łącznie: ~75 minut
Koszty API (orientacyjnie, w cenach Anthropic na maj 2026):
| Faza | Tokeny in | Tokeny out |
|---|---|---|
| Prover (sesja ciągła) | ~80k | ~25k |
| Cold Verifier | ~10k | ~30k |
| Third Judge | ~5k | ~3k |
| Math Referee | ~15k | ~25k |
| Razem na maturę | ~110k | ~85k |
W przeliczeniu: ~4-6 USD na jedną maturę. Tania polisa za 100% rzetelność.
Co poszło NIE tak za pierwszym razem
Pełna szczerość: 75 minut to czas drugiej iteracji. Pierwsza wersja pipeline'u zajęła ~3 godziny, bo wpadłem w kilka pułapek. Wymieniam je, żebyś nie powtarzał moich błędów.
Błąd 1: Read bez parametru pages. Pierwsza próba przeczytania PDF-a (36 stron) zakończyła się błędem. Claude Code zwraca explicit error dla dużych PDF-ów. Naprawa: w prompcie do każdego sub-agenta jawnie wskazałem split na strony (1-10, 11-20, 21-36).
Błąd 2: pdflatex zawiódł na pakiecie tcolorbox. MiKTeX domyślnie instaluje pakiety na żądanie, ale przy pierwszym uruchomieniu blokuje się na potwierdzeniu interaktywnym. Naprawa: mpm --install=tcolorbox ręcznie przed pierwszym compile.
Błąd 3: Cold Verifier widział wcześniejszą wiadomość. W pierwszym podejściu dispatchowałem sub-agenta bez isolation: "worktree". Efekt: agent czytał historię konwersacji i przyjmował moje odpowiedzi jako „ground truth". Naprawa: zawsze isolation: "worktree".
Błąd 4: Math Referee bez high-value pitfalls. W wersji 1 referee zaakceptował wszystko, włącznie z zadaniem 12.1 (funkcja kawałkami, open/closed endpoints), gdzie miałem subtelny błąd na granicy. Naprawa: w prompcie do referee wymieniłem konkretne miejsca, gdzie szukać („Zad. 12.1: at x=2 check open/closed endpoints"). Druga iteracja złapała błąd, poprawiłem, finalna iteracja zwróciła ACCEPT.
Cztery błędy, każdy zjadł ~30-45 minut. Master prompt, który publikuję, jest pochodną tych iteracji - ma już wszystkie te poprawki wpisane.
Trzy lekcje, które wyciągnąłem
Lekcja 1: niezależność > inteligencja
Mógłbym zamiast trzech instancji Opusa 4.7 użyć jednej instancji jeszcze lepszego modelu. Hipotetycznie ten lepszy model miałby 97% rzetelności zamiast 95%. Dalej nie 100%.
Trzy niezależne instancje tego samego modelu dały 100%, bo każda startuje z innym kontekstem promptu, innym fokusem na pitfalls, innym podejściem do tej samej sytuacji. Pierwsza wpada w pułapkę interpretacyjną, druga widzi to samo z innego kąta i ją łapie, trzecia ma najwyższy rygor i sprawdza step-by-step.
Niezależność (cold isolation) jest wartością samą w sobie. Nawet jeśli każda instancja jest „tym samym modelem".
Lekcja 2: explicit zawsze wygrywa z implicit
Każde „magic word" w promptach miało namacalny wpływ. Konkretnie:
| Bez explicit phrasing | Z explicit phrasing | Efekt |
|---|---|---|
| (brak isolation contract) | „you see ONLY: 1. ..., 2. ..., 3. ..." | Eliminacja confirmation bias |
| (brak page split) | „pages: '1-10', then '11-20'..." | Brak failed reads / wasted tokens |
| (brak high-value pitfalls) | „Zad. 20: correct △ are OAD~OCB" | Skierowane sprawdzenie krytycznych punktów |
| „verify" | „compute INDEPENDENTLY first, THEN compare" | Niezależne wyliczenie zamiast rationalizacji |
LLM-y są bardzo dobre w robieniu tego, co im dokładnie powiesz. Są bardzo słabe w czytaniu w myślach. Każde założenie, że „model się domyśli", jest zazwyczaj kosztownym błędem.
Lekcja 3: kiedy ten pattern warto stosować (a kiedy nie)
Pipeline jest wartościowy, gdy spełnione są cztery warunki:
-
Stawka jest wysoka. Błąd jest kosztowny lub trudny do wykrycia później. Matura, finansowe wyliczenia, kod produkcyjny, dokumenty prawne, raporty audytowe.
-
Domena ma deterministyczne odpowiedzi. Matematyka, algorytmy, fakty. Nie ma sensu robić tiered verification dla zadania kreatywnego (jak „napisz wiersz") - tam nie ma „poprawnej" odpowiedzi.
-
Można sformułować strict contract. Wynik da się sparować mechanicznie (tabela, JSON, struktura). Luźna proza nie pozwala na automatyczny diff.
-
Koszty agenta są niskie w porównaniu do kosztu błędu. 5 USD za maturę vs miesiące pracy nad ponowną maturą = oczywista decyzja. Ten sam pipeline dla mailingu marketingowego za 500 zł = przerost formy nad treścią.
Gdy NIE warto: trywialne zadania (jedna linia kodu, krótkie pytanie), kreatywne pisanie, tematy bez weryfikowalnej „prawdy", projekty, gdzie szybki feedback od człowieka jest tańszy niż uruchamianie agentów.
Twój checklist startowy
Najprostsza ścieżka: skopiuj master prompt, wklej do Claude Code, podaj ścieżkę do swojego PDF-a. Tyle. Reszta tej sekcji to „jak to zrobić od zera bez master promptu" - jeśli chcesz adaptować pipeline do innej domeny niż matura.
Jeśli chcesz spróbować podobnego podejścia (na czymkolwiek - własny próbny test, audyt finansowy, weryfikacja kodu), oto 10 punktów:
- Zainstaluj Claude Code - oficjalna CLI od Anthropic, działa wszędzie.
- Załóż folder projektu z
git init(worktree wymaga repozytorium). - Wrzuć materiał wejściowy w plikach (PDF, kod, dokument).
- Napisz główny prompt do Provera - co ma policzyć/sprawdzić/zrobić.
- Każ Claude'owi dispatchować Cold Verifier z
isolation: "worktree"i pełnym kontraktem (Role / Isolation / Sources / Task / Format / Constraints / Pitfalls / Tone). - Zrób mechaniczny diff wyników Provera i Cold Verifiera.
- Konflikty → Third Judge w wąskim scope, bez wiedzy o poprzednich.
- Zbuduj artefakt (PDF, raport, kod) i przekompiluj.
- Dispatch Math Referee (lub jego odpowiednik w Twojej domenie) - czyta artefakt, daje per-pozycja ACCEPT/REJECT.
- Jeśli wszystkie warstwy mówią ACCEPT - certyfikuj wynik. Jeśli choć jedna mówi REJECT - wracaj do kroku 4.
To wszystko. Bez „secret sauce", bez magicznych formuł. Architektura + dyscyplina promptowania + niezależność warstw.
FAQ
Czy ten pipeline działa też na GPT-5 albo Gemini? Tak, ale wymaga ich własnego oprzyrządowania. Claude Code daje worktree-isolation z pudełka. Dla GPT-5 / Gemini musisz zbudować własną orchestrację (Docker containers, oddzielne API keys per sesja, lub ręczny dispatch). Architektura jest model-agnostyczna - tylko narzędzia do izolacji są specyficzne dla Claude Code.
Czy to nie jest oszukiwanie? Nie. Maturzysta na sali nie ma laptopa, internetu ani 75 minut z Claude Code. Ten artykuł nie jest poradnikiem dla maturzysty - to case study, dla osób budujących systemy AI. Matura jest tutaj benchmarkiem (deterministycznym, weryfikowalnym), nie targetem do oszukania.
Ile to kosztuje na pełnej skali (np. 100 dokumentów)? Skaluje się liniowo. ~5 USD per dokument o złożoności matury. Dla 100 dokumentów: ~500 USD. Dla porównania - audyt zewnętrzny dokumentów księgowych w Polsce kosztuje od 5.000 zł wzwyż za jedną sprawę. ROI oczywiste, jeśli mamy weryfikowalne odpowiedzi.
Czy pipeline łapie wszystkie błędy? Nie. Łapie deterministyczne błędy (obliczeniowe, logiczne, interpretacyjne). Nie złapie błędu w samym problem statement (np. źle zaczytany input). Nie łapie też problemów z domeny, w której weryfikacja jest sama w sobie niedeterministyczna (etyka, ocena kreatywności, decyzje strategiczne).
Czy mogę użyć tego do generowania klucza odpowiedzi dla moich uczniów? Tak - to jeden z lepszych legalnych use case'ów. Nauczyciel matematyki dostaje gotowy klucz z pełnym uzasadnieniem (LaTeX → PDF), trzykrotnie zweryfikowany. Idealne dla próbnych matur, kartkówek, ćwiczeń własnych.
Pipeline, który tu opisałem, wziął się z większego projektu rozwiązywania otwartych hipotez matematycznych (problemów Erdősa). Tam stawka jest jeszcze wyższa - błędny dowód niewykryty na czas oznacza miesiące zmarnowanej pracy. Matura była dobrym poligonem - deterministyczna, weryfikowalna, z wyraźnie zdefiniowanym sukcesem (51/51).
Jeśli budujesz coś, gdzie błąd kosztuje - kod produkcyjny, dokument prawny, wyliczenie księgowe - przemyśl ten pattern. Jeden inteligentny agent to za mało. Trzech niezależnych agentów w izolacji to standard, który dopiero teraz staje się ekonomicznie sensowny.
Jeśli chcesz zobaczyć, jak ta sama logika działa dla całego zespołu deweloperskiego AI (10 wyspecjalizowanych agentów współpracujących nad aplikacją), sprawdź autonomiczny zespół deweloperski z Claude Code. Jeśli wahasz się jeszcze, czy w ogóle wejść w Claude Code, zacznij od kompletnego przewodnika po Claude dla marketerów.
Pełne PDF-y rozwiązań matury 2026, które przeszły cały pipeline:
- Matura podstawowa - 38 zadań, certyfikowane 38/38
- Matura rozszerzona - 13 zadań, certyfikowane 13/13
Spróbuj sam. Na własnym próbnym arkuszu, na czymś z Twojej pracy, na cokolwiek, gdzie poprawność ma znaczenie. To godzina Twojego czasu i 5 USD z karty. Jeśli zadziała - masz w ręku narzędzie, które przewyższa pojedynczego eksperta. Jeśli nie zadziała - wiesz, dlaczego, i wiesz, jak poprawić.
Powiązane artykuły
Co jeszcze warto przeczytać
Vibe coding z Claude Code: jak zbudować aplikację od zera z 10 agentami AI - framework S.H.I.P.
Praktyczny tutorial vibe codingu z Claude Code. Framework S.H.I.P., 10 agentów AI, budowa Marketing Dashboard krok po kroku. Od pomysłu do deploy w jeden weekend.
Zespoły agentów AI w marketingu: jak zbudować marketing department z Claude Code
Praktyczny przewodnik po budowaniu zespołów agentów AI do marketingu z Claude Code. Orchestrator pattern, 5 wyspecjalizowanych agentów, gotowe konfiguracje i workflow. Od AIMS do multi-agent.
Autonomiczny zespół deweloperski z AI: Jak zbudować full stack team z agentami Claude Code
Praktyczny przewodnik po budowaniu autonomicznego zespołu deweloperskiego z 10 wyspecjalizowanymi agentami AI. Gotowe konfiguracje, workflow i przykłady użycia.
Newsletter Strategic AI Implementation
Co tydzień jeden framework, jedno case study, zero spamu
Dołącz do listy. Dostajesz to, czego nie wrzucam na bloga: kulisy moich wdrożeń, sprawdzone prompty, błędy do uniknięcia. Wypisujesz się jednym kliknięciem.