Od dostosowywania poleceń do pętli informacyjnych: DSPy, GEPA i Claude Code

Przez lata standardowym rozwiązaniem problemów z słabymi wynikami modeli LLM było proste: dostosować prompt i spróbować ponownie. W przypadku systemów agentowych prompt często nie jest tym elementem, który wymaga poprawek.

Wyobraźmy sobie błąd w produkcji, który pojawia się dopiero po zmianie konfiguracji. Przekazajmy go dwóm różnym rozwiązaniom opartym na sztucznej inteligencji. Pierwsze otrzymuje ścieżkę błędu oraz starannie sformułowane instrukcje i zwraca poprawkę. Drugie może otworzyć repozytorium, przeczytać zasady projektu, odtworzyć błąd, zmienić kod, uruchomić testy, sprawdzić, co poszło nie tak, i zacząć od nowa.

W obu przypadkach istotny jest model. To, co ma drugie rozwiązanie, a nie pierwsze, to wykonalny cykl zwrotny.

Gdy taka pętla już istnieje, sformułowanie promptu staje się tylko jednym z wielu elementów do dostosowania. Można również regulować sposób dzielenia zadań, to, co jest pobierane, jakie narzędzia są dostępne, przykłady, proces weryfikacji, zasady ponawiania prób, sposób izolacji wykonywania oraz narzędzie oceniające, które decyduje, czy praca jest rzeczywiście poprawna.

To właśnie ta koncepcja łączy badania Stanfordu nad DSPy, MIPRO, STORM i GEPA z pracami produkcyjnymi Anthropic nad Claude Code oraz Model Context Protocol. Nie chodzi tu o jedną architekturę – pod spodem leży wspólna idea: inżynieria sztucznej inteligencji przechodzi od doskonalenia pojedynczych promptów do budowania systemów, które działają, mierzą wyniki i ulepszają program otaczający model.

Prompt jest teraz jednym parametrem

Aplikacja typu one-shot ma bardzo niewiele możliwości regulacji:

Task → Prompt → Model → Result

Dla zadań ograniczonych w zakresie to w porządku. Staje się kruche, gdy praca wymaga kilku etapów, informacji z zewnątrz, rzeczywistych skutków ubocznych, weryfikacji lub naprawy błędnej decyzji w trakcie jej wykonywania.

System stworzony do użycia w produkcji wygląda bardziej w ten sposób:

 Task
  ↓
Program / Planner
  ↓
Context + Retrieval
  ↓
Tools + Environment
  ↓
Execution Trace
  ↓
Evaluator
  ↓
Retry, Repair, or Optimize
  ↓
Result

Kiepski wynik może mieć wiele możliwych przyczyn. Model może nie być wystarczająco silny. Proces wydobycia informacji mógł przynieść niewłaściwy kontekst. Planer może źle podzielić zadania. Narzędzie mogło zwrócić przestarzałe dane. Sprawdzacz mógł zignorować nieważną odpowiedź. Albo instrukcje rzeczywiście wymagają poprawy.

Dlatego inżynieria promptów nie znika – staje się jedną z części szerszego problemu debugowania i optymalizacji.

DSPy: uczynić program jawny

Pierwszym ważnym pomysłem DSPy było zaprzestanie traktowania pipeline modeli językowych jako zbioru ręcznie dostosowywanych ciągów zapytań. Oryginalny artykuł przedstawia zastosowania modeli językowych jako grafy obliczeniowe składające się z deklaratywnych modułów oraz dodaje kompilator, który optymalizuje te moduły pod kątem określonej metryki. Obecna dokumentacja wyraża to jaśniej: należy zdefiniować ustrukturyzowane sygnatury i moduły, dostarczyć przykłady oraz funkcję oceny, a następnie skompilować program zamiast ręcznie dostosowywać każde zapytanie.

Niewielki program w DSPy wygląda tak:

import dspy

class Diagnose(dspy.Signature):
    """Identify the most likely root cause from an issue and repository evidence."""
    issue: str = dspy.InputField()
    evidence: str = dspy.InputField()
    diagnosis: str = dspy.OutputField()

program = dspy.ChainOfThought(Diagnose)

optimizer = dspy.GEPA(
    metric=score_diagnosis,
    auto="medium",
)

optimized = optimizer.compile(
    program,
    trainset=historical_incidents,
)

Syntaksa nie jest tu kluczowa. Ważne jest to, że cztery elementy, które zwykle są ze sobą powiązane w jednym poleceniu, teraz są oddzielne: to, co system musi wygenerować, sposób jego wykonywania, przykłady, które go kierują, oraz sposób oceny sukcesu.

To zmienia zadanie inżyniera. Zamiast tracić cały budżet na iteracje na dyskusję o tym, czy „bądź zwięzły” powinno stać się „rozważ dokładnie przed odpowiedzią”, można postawić lepsze pytanie: jakie zachowanie powinno się poprawić i jak je zmierzyć?

Bez sensownej metryki optymalizacja automatyczna sprawia jedynie, że system staje się lepszy w niewłaściwym kierunku.

MIPRO: dostrojenie wielu etapów to problem poszukiwawczy

Sytuacja staje się trudniejsza, gdy program składa się z kilku modułów. Weźmy proces naprawy błędu obejmujący diagnozę, generowanie poprawek i ich weryfikację, w którym ostateczne testy zawodzą. Który moduł jest przyczyną? Która instrukcja powinna zostać zmieniona? Czy jeden z przykładów typu few-shot jest mylący? Czy lepszy krok diagnostyczny pogorszyłby generowanie poprawek?

To jest problem przydziału zasobów, którym zajmuje się MIPRO. Artykuł o MIPRO wykracza poza prostą edycję pojedynczego promptu – dostosowuje on pisane instrukcje oraz przykłady typu few-shot dla każdego modułu, łącząc propozycje instrukcji uwzględniające zarówno program, jak i dane, ocenę na małych zbiorach danych oraz model zastępczy, który kieruje poszukiwania w stronę obiecujących kombinacji.

W skrócie:

Bootstrap useful demonstrations
          ↓
Propose task-grounded instructions
          ↓
Search instruction + demo combinations
          ↓
Evaluate the whole program

Z użyciem Llama-3-8B optymalizator przewyższył swoje bazowe wartości w pięciu z siedmiu programów wieloetapowych, przy czym w najlepszym przypadku osiągnięto wzrost dokładności o aż 13%.

To bardziej umiarkowane stwierdzenie niż „automatyczne prompty przewyższają ludzi”. Ważniejszy wniosek dotyczy struktury: gdy instrukcje i przykłady stają się parametrami programu wieloetapowego, jego udoskonalanie polega na wyszukiwaniu w systemie, a nie na pisaniu pojedynczej treści.

STORM: struktura przed optymalizacją

Żaden optymalizator nie może uratować źle zaprojektowanego procesu pracy. Dobrym przykładem jest STORM z Stanfordu, którego nacisk kładzie się na układ całego procesu, a nie na to, który prompt będzie skuteczniejszy.

Jedyny model, który wykonywałby wszystkie badania i pisanie tekstów rozbudowanych za jednym razem, stanowiłby wersję naiwną; STORM oddziela fazę przygotowawczą na osobne kroki. Znajduje różne perspektywy na dany temat, wykorzystuje je do formułowania pytań opartych na źródłach, organizuje zebrane materiały w szkic, a dopiero potem pisze.

W porównaniu z bazą odzyskiwania informacji opartą na szkicu, artykuły przygotowane za pomocą STORM wykazują wzrost efektywności organizacji o 25 punktów procentowych oraz większą szerokość tematyczną o 10 punktów. Repozytorium STORM jasno wskazuje na ograniczenia: generowane artykuły nie są gotowe do publikacji i często wymagają intensywnego edytowania.

Lekcja, która z tego wynika, to nie „dodawanie więcej agentów”. Chodzi o to, że dekompozycja pozwala na oddzielną kontrolę kontekstu, dowodów, radzenia sobie z błędami oraz oceny. Zanim optymalizujesz proces pracy, upewnij się, że jego etapy odpowiadają sposobom, w jakie faktycznie występują błędy.

GEPA: uczyć się na tym, co naprawdę się wydarzyło

Jedna ocena może wskazać, że występ był przeciętny. Zazwyczaj nie potrafi jednak wyjaśnić dlaczego. Prawdziwa realizacja pozostawia znacznie bogatsze dowody:

input
  ↓
retrieval choice
  ↓
reasoning
  ↓
tool call
  ↓
tool result
  ↓
constraint failure
  ↓
final output

GEPA, skrót od Genetic-Pareto i opublikowany w lipcu 2025 roku, wykorzystuje ten sygnał. Próbkuje trajektorie wykonywania zadań, analizuje je w języku naturalnym, proponuje modyfikacje promptów, ocenia kandydatów oraz utrzymuje granicę Pareto, aby nie odrzucać strategii wzajemnie uzupełniających się.

Jedna granica ma ogromne znaczenie w środowisku produkcyjnym. GEPA optymalizuje trajektorie, które już zaobserwowano. Nie jest to zezwolenie na to, by agent działający w czasie rzeczywistym mógł sam siebie przepisywać po każdej prośbie użytkownika. Zanim jakikolwiek zoptymalizowany kandydat trafi do użycia, powinien mieć wersję, być oceniany w przypadkach, w których nigdy nie był szkoleny, mieć określony budżet optymalizacji oraz przejść wyraźny etap promocji w ramach starannie dobranego zestawu do oceny. To właśnie jest granica pomiędzy przydatną samodoskonaleniem a niekontrolowaną samomodyfikacją.

Claude Code: pętla w rzeczywistym środowisku

DSPy podchodzi do tego problemu z perspektywy optymalizacji programu. Claude Code rozwiązuje go z punktu widzenia czasu wykonywania. W ujęciu Anthropic jest to agent, który znajduje się w twoim repozytorium: pobiera własne instrukcje projektu, modyfikuje pliki, wykonywa komendy w shellu oraz zestawy testów, i ciągle dostosowuje się na podstawie uzyskanych wyników. W jego zaawansowanych materiałach omawiane są metody dzielenia pracy pomiędzy podagentami, uruchamiania funkcji pomocniczych pomiędzy poszczególnymi krokami oraz łączenia wewnętrznych usług firmy za pośrednictwem MCP.

Architektura nie polega na „rozmowie z mądrzejszym programistą”. Jest bliższa temu:

Repository + Project Rules + Task
              ↓
            Model
       ↙      ↓      ↘
     Read    Edit   Execute
       ↘      ↓      ↙
      Tests / Runtime Evidence
              ↓
         Next Decision

Te dane z czasu wykonywania zmieniają to, co model może robić. Nieudana próba jest lepszą informacją zwrotną niż „proszę o ponowne rozważenie”. Błąd kompilatora jest lepszy niż sytuacja, w której model ocenia własne poprawki. Można mechanicznie sprawdzić, czy różnica pozostaje w granicach, zamiast pytać innego modelu, czy zmiana ma odpowiedni zakres.

Wewnętrzne dane dotyczące produktywności firmy Anthropic są interesujące, ale łatwe do błędnego interpretowania. Ich analiza z 2026 roku pokazuje, że do drugiego kwartału tego roku liczba linii kodu na inżyniera dziennie wzrosła mniej więcej o osiem razy w porównaniu z wcześniejszymi okresami, przy czym wyraźnie ostrzegają, że liczba linii kodu przecenia rzeczywistą produktywność. Ten okres obejmuje również duże zmiany zarówno w modelach, jak i w Claude Code, więc te dane nie pokazują, że samą tylko orkiestracją osiągnięto ten wzrost. Jaśniejszym sygnałem jest to, że nowoczesne systemy programistyczne ciągle przekształcają wyniki modeli w działania, obserwacje, a następnie w kolejne decyzje.

MCP łączy narzędzia; nie koordynuje ich działania

Często łączy się MCP z agentami, używaniem narzędzi oraz procesem koordynacji, jakby były to to samo. Tak nie jest. Architektura MCP to specyfikacja typu klient-serwer: aplikacja AI łączy się z serwerami i dowiaduje się, jakie narzędzia, zasoby oraz polecenia one udostępniają, a następnie korzysta z nich w jednolity sposób. Host koordynuje klienty i odpowiada za uprawnienia, zarządzanie kontekstem, politykę bezpieczeństwa oraz sposób podłączania modeli językowych.

Zatem MCP obejmuje tylko jedną warstwę większego zestawu komponentów:

Model                  capability envelope
Program / graph         task decomposition
Context / state         what the model can see
Tools / MCP             what the system can access or do
Runtime / harness       where actions execute
Evaluator               what counts as success
Optimizer               how the program improves
Observability           why a run succeeded or failed

Żadne pojedyncze narzędzie nie obejmuje tego wszystkiego, i to właśnie dlatego myślenie systemowe przynosi korzyści.

Optymalizuj pętlę naprawiania błędów, a nie sam prompt

Wróćmy do błędu od samego początku. Zamiast jednej instrukcji mówiącej „znajdź problem i go napraw”, opisz dokładnie proces pracy:

  Issue + Repository
        ↓
    Diagnosis
        ↓
      Patch
        ↓
Tests + Lint + Runtime Checks
        ↓
    Diff Review
        ↓
  Accept or Revise

Każdy etap generuje teraz dowody: logi czasu wykonywania pokazujące, które pliki zostały odczytane, które polecenia zostały wykonywane, patchy, które zawiodły, wyniki testów oraz ostateczną różnicę.

Sprawdzenia deterministyczne obejmują to, co można udowodnić mechanicznie: wymagane testy przechodzą, narzędzia do analizy kodu nie wykrywają błędów, do zakazanych plików nie ma dostępu, a patch pozostaje w swoim dozwolonym zakresie. Ocena oparta na modelu jest przeznaczona dla pytań o charakterze semantycznym, takich jak to, czy diagnoza wyjaśnia prawdopodobną przyczynę problemu.

Z upływem czasu wcześniejsze przypadki stają się zbiorem do oceny. MIPRO może przeszukiwać instrukcje i przykłady w modułach diagnostycznych i naprawczych. GEPA może wykorzystać nieudane ścieżki działania oraz informacje zwrotne od oceniających, aby zaproponować lepszy tekst programu. Jednak optymalizacja należy do etapu poza granicami wersji wydawniczej:

Production traces
      ↓
Curated evaluation set
      ↓
Offline optimizer
      ↓
Candidate program
      ↓
Held-out validation
      ↓
Controlled promotion

Tutaj badania i produkcja w końcu się łączą. Silnik działania agenta generuje działania i ślady ich wykonywania. Narzędzie oceny przekształca te ślady w dowody. Optymalizator proponuje lepszy program. Proces wdrożenia decyduje, czy jest bezpiecznie go wydać.

Co to oznacza dla inżynierów sztucznej inteligencji

Pytania sterujące nie stały się bez znaczenia – po prostu istnieje więcej przydatnych miejsc, gdzie można interweniować. Gdy proces pracy nie działa prawidłowo, nie zaczynaj od od razu poprawiania sformułowań. Najpierw sprawdź, który warstwa zawiodła:

• Czy model bazowy w ogóle mógł poradzić sobie z tym zadaniem?
• Czy proces wyszukiwania dostarczył odpowiedniego kontekstu?
• Czy zadanie zostało podzielone na sensowne części?
• Czy narzędzia zwróciły dowody, którym można zaufać?
• Czy wykonywanie zadań było izolowane i możliwe do obserwacji?
• Czy narzędzie oceny mierzy zachowanie, które naprawdę nas interesuje?
• Czy optymalizator poprawia jakość w warunkach rzeczywistego użycia, czy tylko dostosowuje się do danych treningowych?

Przyjrzenie się całemu systemowi ujawnia również kompromisy, które tendencja do przesadywania pomija. Otoczenie słabego modelu grafem nie czyni go modelem najnowocześniejszym. Zła metryka sprzyja optymalizacji niewłaściwego zachowania. Im więcej narzędzi, tym więcej możliwych błędów i większa powierzchnia podatna na ataki. Każda operacja optymalizacji zużywa tokeny i czas na ocenę. Najgorsze jest to, że agent, który edytuje sam siebie bez historii wersji i bez nietkniętych przypadków testowych, może stać się bardziej niestabilny, mimo że na papierze wydaje się bardziej niezależny.

Zatem wniosek nie jest taki, że model przestał mieć znaczenie. Jakość modelu określa górny limit jego możliwości. Projekt systemu decyduje o tym, jak duża część tych możliwości przekłada się na niezawodną pracę.

To jest prawdziwy związek pomiędzy badaniami na Stanfordzie a narzędziami Anthropic. Dzięki DSPy program przestaje być ukryty w ciągach tekstowych promptów. MIPRO umożliwia wyszukiwanie instrukcji i przykładów z różnych etapów. STORM przypomina, że kształt procesu pracy jest najważniejszy. GEPA analizuje pełne ślady wykonywania zadań w celu znalezienia ulepszeń. Claude Code umieszcza model w praktycznym środowisku inżynieryjnym, a standard MCP ujednolica jedną z granic z możliwościami zewnętrznymi. Różne projekty na różnych poziomach, wszystkie skierowane w tym samym kierunku.

Następnym razem, gdy system AI zawiedzie, „jakiego promptu powinienem spróbować?” nie powinno być jedynym pytaniem. Zadaj sobie pytanie, która część systemu się zepsuła i jakie dowody pomogą ci ją naprawić.

Literatura pokrewna

• Harness produkcyjny dla Claude Code: sześć warstw od Slack do połączonego MR — Jak sześciowarstwowy harness przekształca zgłoszenia z Slack w połączony kod: przyjmowanie zdarzeń, pętle agentów z kontrolą dostępu, trwały stan, samoregeneracja, możliwości obserwacji oraz kontrola operatora.
• Pętle kodowania agentic: od jednolinijki w Bash do /goal, Checks i Hard Stops — Praktyczny przewodnik po pętlach agentów: pętla ralph, polecenia goal i loop w Claude Code, weryfikacja zewnętrzna, trzy limity wydatków oraz umiejętności warte zachowania, wraz z planem na pierwszy tydzień.