Samodoskonaląca się App: zamknięta pętla ulepszeń

1. Po co App potrzebny jest zamknięty cykl ulepszeń

Każdy LLM‑App żyje w zmieniającym się świecie. Pojawiają się nowi użytkownicy i scenariusze, OpenAI wypuszcza nowe modele i mechanizmy ochronne, sami aktualizujecie serwer MCP, Agents SDK, widżet UI… I nawet jeśli cały kod byłby napisany idealnie (tak, tak, wiem, że prawie tak robicie), jedna zmiana modelu lub promptu może niezauważalnie zepsuć połowę przypadków.

Bez cyklu ulepszeń życie wygląda tak. Użytkownik pisze do wsparcia: „GiftGenius zaczął proponować prezenty droższe niż budżet” albo „wisi i ‘myśli’ po 15 sekund”. Otwieracie logi, coś poprawiacie w system promptcie, przełączacie model, wdrażacie. Po tygodniu wszystko się powtarza, ale w innym miejscu. W efekcie — chroniczny pożar i masa „magicznych” zmian, których nikt nie potrafi wyjaśnić.

Z cyklem wszystko wygląda inaczej. Macie:

• zrozumiały zestaw sygnałów z obszaru techniki, pieniędzy, produktu i jakości;
• regularny rytuał: patrzeć na nie i wybierać hipotezy;
• kontrolowane zmiany w code/config;
• automatyczne sprawdzenia: golden‑cases + LLM‑evals + eksperymenty.

Wtedy App zmienia się z „zastygłego promptu” w żywy system, który:

• pokazuje, gdzie boli i dlaczego;
• podpowiada, co dokładnie można poprawić;
• chroni przed cichą degradacją po „niewinnej” zmianie promptu.

Plus bonus: taki cykl świetnie układa się na wszystko, co już zrobiliście w poprzednich modułach. Logi i SLO z M17 dają sygnały techniczne, instrumentacja kosztów i AARRR z M19 — ekonomiczne i produktowe, golden‑cases i LLM‑evals z M20.1–2 — sygnały jakości. Zostaje tylko spiąć to w zrozumiały cykl operacyjny.

2. Mapa sygnałów dla ulepszeń

Aby App mógł sam podpowiadać, gdzie go poprawiać, trzeba jasno rozumieć, jakie sygnały w ogóle macie i skąd się biorą. Wygodnie myśleć o czterech grupach.

Sygnały techniczne przychodzą z waszego stosu observability: logi tool_invocation, metryki latency i error‑rate, health‑checki MCP/ACP, błędy OAuth. Odpowiadają na pytanie „czy serwis żyje i na ile jest stabilny”.

Sygnały ekonomiczne pochodzą z instrumentacji kosztów i billingów: cost_per_tool_call, cost_per_task, cost_per_user, niespodziewane skoki kosztów w konkretnych narzędziach lub scenariuszach. Mówią: „palimy tokeny i pieniądze bardziej niż oczekiwaliśmy” albo przeciwnie, „mamy zapas, można poprawiać jakość”.

Sygnały produktowe formują się ze zdarzeń takich jak app_opened, workflow_started, workflow_completed, checkout_*. To activation‑rate, konwersje między krokami lejka, retention po kohortach. Pokazują, co dzieje się z realnym zachowaniem ludzi.

Sygnały jakości i zachowania obejmują wyniki LLM‑evals na golden‑cases (punkty za correctness/helpfulness/style/safety), wybiórcze ręczne review dialogów, thumbs up/down, skargi i opinie w Store. To najbardziej zbliżone do odczucia „App stał się mądrzejszy/głupszy”.

Wygodnie zebrać to w tabelę:

Kluczowy punkt: wszystkie te sygnały są logowane z przypisaniem do konkretnego scenariusza i wersji App. To znaczy, że w zdarzeniach pojawiają się co najmniej scenario, appVersion i experimentId. Wtedy, widząc, że helpfulness w golden‑cases spadł z 8.5 do 6.2, możecie powiedzieć nie po prostu „jest gorzej”, lecz „jest gorzej w scenariuszu "gift_selection" po wydaniu "1.3.0", w wariancie eksperymentu "B"”.

W kodzie można nawet wprowadzić prostą strukturę do opisu sygnału:

// lib/improvement/signals.ts
export type SignalKind = "slo" | "cost" | "product" | "quality";

export type ImprovementSignal = {
  kind: SignalKind;
  scenario: string;       // e.g. "gift_selection"
  metric: string;         // e.g. "p95_latency_ms", "cost_per_task"
  value: number;
  previous?: number;      // wartość "przed"
};

Takie obiekty wygodnie podawać zarówno dashboardom, jak i waszemu przyszłemu asystentowi ulepszeń.

3. Kanoniczny feedback‑loop: 4 kroki

Teraz złóżmy kanoniczny cykl ulepszeń, na którym będziecie mogli opierać się za każdym razem. Jest maksymalnie przyziemny: cztery kroki.

flowchart TD
  A[Sygnał: coś boli
albo jest szansa wzrostu] --> B[Hipoteza:
co i jak zmieniamy]
  B --> C[Kontrolowana zmiana
w code/config]
  C --> D[Weryfikacja:
offline + online]
  D --> A

Krok 1. Wykryć problem lub szansę

Na tym etapie odpowiadacie na pytanie „gdzie patrzeć”. Przykłady:

• LLM‑eval na golden‑cases z budżetem pokazuje spadek helpfulness.
• p95 latency dla narzędzia "suggest_gifts" wzrosło z 1.2s do 3.8s.
• cost_per_task w scenariuszu "gift_selection" wzrósł o 40% po przejściu na model reasoning.
• Konwersja workflow_completed → checkout_success spadła o 5 p.p. po zmianie UX‑kreatora.
• W Store w ciągu tygodnia pojawiło się 10 skarg „prezenty droższe niż wskazany limit”.

Ważna uwaga: czasem sygnał mówi nie „źle”, lecz „może być lepiej”. Na przykład widzicie, że cost_per_task jest wyraźnie niższy od dopuszczalnego progu, a quality‑score już 9/10. Znaczy to, że można spróbować droższego modelu albo „mądrzejszego” scenariusza — może konwersja wzrośnie.

Krok 2. Sformułować hipotezę

Hipoteza to nie „przepiszemy prompt”, lecz „uważamy, że konkretna zmiana X w komponencie Y poprawi metrykę Z, ponieważ…”. Bez „ponieważ” to nie hipoteza, a życzenie.

Przykłady:

• „Jeśli wprowadzimy zasadę ścisłego przestrzegania budżetu w system promptcie i poprosimy o zawsze wyjaśnianie, jak użyto budżet, helpfulness w case’ach z budżetem wzrośnie co najmniej o 2 punkty”.
• „Jeśli zamienimy drogi model na "gpt-mini" w kroku rerank, cost_per_task spadnie o 30%, a konwersja nie spadnie więcej niż o 1 p.p.”.
• „Jeśli uprościmy kreator (połączymy dwa kroki w jeden) i przepiszemy CTA, activation‑rate wzrośnie o 5 p.p.”.

W kodzie taką hipotezę wygodnie opisać jawnie, choćby jako obiekt:

// lib/improvement/hypothesis.ts
export type ImprovementHypothesis = {
  id: string;
  scenario: string;
  description: string;   // "Co zmieniamy i po co"
  targetMetric: string;  // np. "quality.helpfulness" lub "conversion.checkout"
  successCriteria: string;
};

Tak, to prawie jak ticket w Jira, ale przynajmniej w typizowanej formie.

Krok 3. Wprowadzić kontrolowaną zmianę

Tu ważne są dwa słowa: kontrolowana i oddzielna.

Kontrolowana znaczy, że zmiana jest w formie PR/commit, powiązana z hipotezą, ma changelog i, jeśli to możliwe, feature‑flaga lub wersję. Nie „podrasowaliście promptu na produkcji”, tylko możecie wskazać, jakie konkretnie wydanie to przyniosło.

Oddzielna oznacza, że staracie się nie mieszać w jednym wydaniu trzech różnych hipotez naraz. Jeśli jednocześnie:

• zmienicie model,
• przepiszecie połowę system‑promptu,
• i dodacie nowy krok w UX,

to nawet przy poprawie metryk trudno będzie zrozumieć, co dokładnie zadziałało. Znacznie uczciwiej działać małymi porcjami.

Z technicznego punktu widzenia zmiany mogą być gdziekolwiek:

• system‑prompt agenta (lib/prompt/systemPrompt.ts);
• opisy narzędzi MCP (description, inputSchema, annotations);
• config agenta (limity kroków reasoning, wybór modelu dla konkretnego tool);
• kod widżetu (CTA, kolejność kroków, teksty błędów).

Krok 4. Sprawdzić, czy jest lepiej

Weryfikacja dzieli się na offline i online.

Weryfikacja offline — to przepuszczenie golden‑cases przez nową wersję App bez realnych użytkowników. Macie tu już:

• LLM‑evals (moduł 20.1);
• logikę threshold/baseline (moduł 20.2).

Patrzycie, jak zmieniły się quality‑score dla docelowych scenariuszy: wzrosły, spadły, zostały takie same. Sprawdzacie też safety‑cases: wszelkie poprawki w prompecie najpierw muszą przejść zestaw safety.

Weryfikacja online — to eksperyment na realnym ruchu. W najprostszym wariancie włączacie nową wersję dla N% użytkowników i porównujecie:

• konwersję na działanie docelowe (checkout, ponowne uruchomienie scenariusza);
• cost_per_task;
• skargi/feedback.

Po tym cykl albo się zamyka (hipoteza potwierdzona/obalona i udokumentowana), albo rodzi nową hipotezę.

4. Wewnętrzny „asystent ulepszeń” jako osobny agent

Teraz najciekawsze: dajmy modelowi LLM jeszcze jedną rolę — nie tylko odpowiadać użytkownikom, ale też pomagać wam ulepszać App. To wewnętrzny agent, oddzielny od użytkowego GiftGenius.

Co to jest

Ten asystent żyje w waszym wewnętrznym środowisku (w tym samym repo, w Dev Mode, w osobnym ChatGPT App). On:

• czyta logi i próbki dialogów;
• patrzy na metryki;
• analizuje system‑prompt i opisy tools;
• pomaga formułować problemy i propozycje zmian.

W praktyce dostajecie „wirtualnego product managera/analityka”, który:

• nie męczy się czytaniem dialogów;
• szybko znajduje powtarzające się wzorce;
• umie pisać szkice promptów i changelog.

Jakie wejście przyjmuje

Warto sformalizować wejście, żeby agentowi było łatwiej. Na przykład typ:

// lib/improvement/assistant.ts
export type BadDialogExample = {
  id: string;
  userMessages: string[];
  appMessages: string[];
  qualityScore?: number;
};

export type ImprovementInput = {
  scenario: string;
  signals: ImprovementSignal[];      // z poprzedniej sekcji
  examples: BadDialogExample[];
  systemPrompt: string;
  toolsDescription: string;
};

Możecie złożyć taki obiekt, zrzucając z logów 10–20 nieudanych dialogów dla scenariusza "gift_selection" i dołączając aktualny system‑prompt i opisy narzędzi.

Jaki powinien być wynik

Wygodnie też ustalić oczekiwaną odpowiedź:

export type ImprovementSuggestion = {
  patterns: string[];     // powtarzające się problemy
  promptPatches: string[]; // propozycje fragmentów dla system-prompt
  toolsPatches: string[];  // pomysły do opisów tools
  uxCopyIdeas: string[];   // warianty tekstów UX
  changelog: string[];     // krótka lista "co zmienić"
};

Meta‑prompt dla takiego agenta będzie mniej więcej:

• „przeanalizuj przykłady i sygnały”;
• „opisz 2–3 wzorce problemów”;
• „zaproponuj po 1–2 zmiany w prompecie, opisach tools i w tekstach UX”;
• „zwróć wszystko w ściśle określonym JSON”.

Potem już ręcznie bierzecie te fragmenty, omawiacie w zespole, wplatacie w kod i przepuszczacie przez evale i eksperymenty. Ważna zasada: ten asystent niczego sam nie zmienia na produkcji. Generuje pomysły i tekst, a nie commity.

5. Typy zmian: co w ogóle można „stroić”

Gdy pojawia się taki asystent i zrozumiały cykl, bardzo łatwo sprowadzić wszystko do „podrzuć mi nową wersję system‑promptu”. W praktyce obszar ulepszeń jest dużo szerszy.

Prompt i instrukcje

System‑prompt ustawia rolę, ton, priorytety i twarde reguły (np. budżet, safety, kolejność kroków). Można go:

• upraszczać, usuwając sprzeczne lub zdublowane instrukcje;
• wzmacniać, dodając brakujące reguły (jak w przykładzie z budżetem);
• adaptować do różnych scenariuszy (osobne pod‑prompty dla "gift_selection", "post_purchase_help" itd.).

Opisy tools pomagają modelowi zrozumieć, kiedy wywołać konkretne narzędzie i co ono robi. Tu ulepszenia często sprowadzają się do:

• bardziej jawnych „Use this when… / Do not use when…”;
• doprecyzowania sformułowań (zmniejszenie nakładania się z innymi tools);
• dodania informacji o konsekwencjach (destructiveHint, isConsequential).

Zasady safety — to część promptu/opisów, która odpowiada za zachowanie w trudnych domenach. Lepiej je ruszać dopiero po solidnych safety‑evalach.

Architektura zachowań (behavior)

Czasem problemu nie da się rozwiązać prompecie: trzeba zmienić kolejność działań.

Przykłady:

• dodać obowiązkowy krok doprecyzowania parametrów przed wywołaniem drogiego tool;
• wynieść część obliczeń do osobnego, tańszego kroku (np. wstępna filtracja w backendzie);
• ograniczać liczbę kolejnych wywołań tools w jednym scenariuszu.

Te zmiany zwykle opisuje się w configu agenta albo warstwie MCP, a nie tylko w prompecie.

UX i copywriting

Tak, teksty na przyciskach i w błędach — to też część jakości. GiftGenius, który pisze:

„Błąd 500. Skontaktuj się z administratorem”,

tworzy zupełnie inne wrażenie niż:

„Nie udało się uzyskać odpowiedzi od sklepu. Twoje wybrane pomysły nigdzie nie zniknęły, spróbuj sfinalizować zakup nieco później”.

Ekrany pośrednie, podpowiedzi, struktura kreatorów — to wszystko wpływa na ten activation‑rate i konwersje, które mierzycie.

Ekonomia

Tu gramy w dobrze znaną grę „jakość ↔ koszt”:

• wybór modelu (drogi z reasoning, szybki/tani);
• głębia reasoning/kroków agenta (ile iteracji dopuszczamy);
• limity dialogu (np. nie więcej niż N przeliczeń propozycji w jednej sesji);
• „tanie” tryby fallback, gdy budżet na tokeny/limity jest wybity.

Sygnały stąd idą do cost_per_task, cost_per_user, marży i łączą się z quality‑score.

6. Guardrails: czego nie oddawać LLM

Gdy w systemie pojawia się „asystent ulepszeń” i wygodny cykl, bardzo kusi przycisk „Auto‑optymalizacja” i pójście na kawę. Ustalmy od razu, gdzie taki przycisk jest zabroniony.

Zmiany w uprawnieniach (OAuth scopes, narzędzia MCP, dostępy do danych) — to zawsze strefa human‑in‑the‑loop. Żaden model nie powinien sam decydować, że teraz App może czytać zamówienia, dotykać płatności lub wysyłać maile do użytkowników. To samo dotyczy flow commerce: wszelkie zmiany wokół ACP/Stripe, limitów, typów płatności i zwrotów przechodzą przez ludzkie review i testy.

Profil safety App (w jakich domenach ma prawo doradzać, a gdzie musi odmawiać) — to też nie jest coś, co warto przekazywać LLM. Model może pomóc sformułować tekst zasad, ale decyzja, jakim tematom ufacie App, zostaje po waszej stronie.

Polityka danych i logowania (co logujemy, jak długo przechowujemy, jak odpowiadamy na żądania usunięcia danych) — w tym samym zestawie. LLM może podpowiedzieć strukturę Privacy Policy, ale nie powinien zmieniać retention w kodzie bez waszego udziału.

Co można pół‑zautomatyzować? Formułowania i wording promptów, opisów tools i tekstów UX, priorytety narzędzi (w rozsądnych granicach), dodatkowe pytania doprecyzowujące. To wszystko można powierzyć asystentowi jako źródłu pomysłów, ale ostatnie słowo i sprawdzenie należą do człowieka i skryptów eval.

7. End‑to‑end przykład cyklu ulepszeń (GiftGenius)

Wróćmy do naszego bohatera.

Problem

Użytkownik podaje budżet, ale GiftGenius często proponuje prezenty droższe niż ten limit. W logach widać dużo kontynuacji dialogu „nie, to za drogie” i „zrób taniej”.

Sygnały

Najpierw widzicie jakość: LLM‑eval na golden‑cases typu „dobierz prezent do 50$” daje helpfulness około 6/10. Sędzia regularnie pisze w reason, że „prezenty przekraczają budżet” albo „nie wyjaśniono, jak uwzględniono budżet”.

Równolegle przychodzą sygnały produktowe i ekonomiczne:

• konwersja do checkout_success w scenariuszach z podanym limitem jest niższa niż bez limitu;
• część użytkowników porzuca scenariusz po zobaczeniu zbyt drogich opcji;
• cost_per_task dla takich scenariuszy jest wyższy, bo App wykonuje kilka przeliczeń prezentów na prośbę „zrób taniej”.

Analiza z pomocą asystenta ulepszeń

Zbieracie 20 dialogów, gdzie użytkownicy skarżyli się na cenę, i formujecie ImprovementInput:

• scenario = "gift_selection_with_budget";
• signals ze spadkiem helpfulness i konwersji;
• examples z dialogami;
• aktualny system‑prompt i opisy tools.

Karmicie tym wewnętrznego agenta ulepszeń. W odpowiedzi dostajecie na przykład:

• Wzorce:
  • budżet sformułowany jako „mniej więcej do 50$” jest traktowany zbyt swobodnie;
  • system‑prompt nie zawiera wyraźnego wymagania „nigdy nie proponuj prezentów powyżej limitu”;
  • odpowiedzi nie wyjaśniają użytkownikowi, jak dokładnie uwzględniono budżet.
• Propozycje:
  • dodać do system‑promptu instrukcję o ścisłym przestrzeganiu limitu;
  • poprosić model, by zawsze mówił, że „wszystkie opcje ≤ X”;
  • dodać pytanie doprecyzowujące, jeśli budżet brzmi nieprecyzyjnie („mniej więcej”, „około”).

Hipoteza i zmiana

Formułujecie hipotezę:

„Jeśli jasno zapiszemy ścisłe przestrzeganie limitu i poprosimy o wyjaśnianie wykorzystania budżetu, helpfulness w case’ach z budżetem wzrośnie co najmniej do 8/10, a konwersja do zakupu — o 3 p.p.”.

Wprowadzacie do system‑promptu taki fragment:

export const budgetRule = `
Jeśli użytkownik podaje budżet (np. "do 50$" lub "około 30€"),
traktuj tę kwotę jako ŚCISŁY górny limit.

Nigdy nie proponuj opcji droższych niż ten limit.
W każdej odpowiedzi wyraźnie powiedz, że wszystkie opcje mieszczą się w budżecie
i w jaki sposób (np.: "wszystkie prezenty nie droższe niż 45$").
`.trim();

I dodajecie budgetRule do ogólnego system‑promptu GiftGenius.

Weryfikacja offline

Przepuszczacie zestaw golden‑cases „prezenty z budżetem” przez nową wersję:

• LLM‑eval helpfulness rośnie z 6.0 do 8.5;
• correctness też rośnie: budżet jest przestrzegany;
• safety nie pogarsza się (przynajmniej na razie).

Jeśli odwrotnie — helpfulness nie rośnie lub safety spada — zmiana nie przechodzi, a hipoteza jest rewidowana.

Test online

Dalej uruchamiacie eksperyment:

• 10% użytkowników dostaje nową wersję promptu (wariant B);
• pozostałe 90% — starą (wariant A).

Po tygodniu patrzycie:

• konwersja workflow_completed → checkout_success dla B wynosi powiedzmy 13% zamiast 10% u A;
• cost_per_task prawie się nie zmienił;
• odsetek dialogów ze skargami na „za drogo” spadł.

Eksperyment uznany za udany.

Utrwalenie

Po tym:

• rozszerzacie nowy prompt na 100% ruchu;
• dodajecie nowy golden‑case „miękki budżet do 50$” do zestawu regresyjnego;
• utrwalacie wynik w changelogu i, być może, w tech notes: żeby za pół roku było jasne, czemu w prompecie jest tak twarda formuła o budżecie.

Cykl zamknięty. Następna iteracja może dotyczyć na przykład rekomendacji dla osób z bardzo rzadkimi zainteresowaniami albo optymalizacji kosztu doboru.

8. Mini‑mapa drogowa samodoskonalącej się App

Żeby nie wyglądało to jak „jeszcze 100500 zadań z góry”, warto zobaczyć, jaki minimalny zestaw jest potrzebny, by App już uchodziła za samodoskonalącą się, a co można dodać później.

Wersja 1.0: minimalny improvement‑loop

Na pierwszym etapie wystarczą trzy rzeczy.

Po pierwsze, strukturalne logi i podstawowe SLO. Już potraficie logować tool_invocation, workflow_completed, checkout_* z requestId, userId, scenario, appVersion, costEstimateUsd. Na tym buduje się SLO: latency, error‑rate, sukces checkout.

Po drugie, 10–20 golden‑cases i skrypt LLM‑eval. Niewielki, ale dobrze dobrany zestaw przykładów dla kluczowych scenariuszy + safety‑cases. Jeden skrypt CLI, który przepuszcza je przez App i sędziego i zwraca oceny w JSON.

Po trzecie, prosty rytuał co 2 tygodnie. Usiąść (samemu lub z zespołem), otworzyć:

• 2–3 dashboardy dla SLO, kosztów, metryk produktowych;
• raport LLM‑eval dla golden‑cases;

i wybrać 1–2 hipotezy na kolejny cykl. Sformułować, udokumentować, zrobić małe wydanie, sprawdzić.

Wersja 2.0: „inteligentny” improvement‑loop

Na kolejnym poziomie pojawiają się:

Wewnętrzny asystent ulepszeń. To osobno opisany agent (lub ChatGPT App), który przyjmuje ImprovementInput i zwraca ImprovementSuggestion. Pomaga nie tracić godzin na ręczne przeglądanie dialogów.

Zautomatyzowane raporty. Na podstawie logów i evali można generować:

• klastry problematycznych case’ów (np. wszystkie przypadki, gdy użytkownik przepisywał budżet);
• ready‑to‑use szkice zmian promptów i opisów tools;
• krótki changelog.

Hooki CI. Każda zmiana promptów, configów agentów, opisów narzędzi automatycznie uruchamia:

• funkcjonalny golden‑suite;
• safety‑suite.

Jeśli safety‑cases padają albo jakość kluczowych scenariuszy przestaje spełniać progi — build jest czerwony, nie ma wydania.

9. Praktyka

Ćwiczenie 1. Mini‑feedback‑loop dla swojego App

Weźcie jeden kluczowy scenariusz waszej aplikacji. Dla GiftGenius wybraliśmy już „dobór i zakup prezentu”, możecie wziąć podobny scenariusz lub własny.

Opiszcie w wolnej formie (albo załóżcie mały improvement-plan.md):

Jakie sygnały będziecie śledzić. Po jednym:

• techniczny: na przykład p95 latency dla narzędzia, które wykonuje główną pracę;
• ekonomiczny: cost_per_task dla tego scenariusza;
• produktowy: konwersja workflow_started → workflow_completed albo do działania docelowego;
• jakościowy: średni quality_score dla kilku golden‑cases dla tego scenariusza.

Następnie ustalcie, jakie progi uważacie za degradację. Nie „kiedyś zobaczymy”, lecz całkiem konkretnie:

• p95 > 5 sekund — źle;
• cost_per_task wzrósł o więcej niż 30% bez wzrostu przychodu — alarm;
• quality_score spadł poniżej 7 — trzeba się przyjrzeć.

I sformułujcie pierwszą hipotezę. Na przykład:

„Podejrzewam, że zadajemy zbyt wiele pytań doprecyzowujących. Jeśli skrócić kreator o jeden krok i zrobić pytania nieco bardziej ogólne, to activation‑rate wzrośnie, a helpfulness prawie nie ucierpi. Sprawdzę to przez niewielką zmianę UX i eksperyment A/B”.

To już nie tylko „poprawimy UX”, ale całkiem konkretny krok w cyklu.

Ćwiczenie 2. Meta‑prompt dla asystenta ulepszeń

Spróbujcie naszkicować tekst promptu dla wewnętrznego agenta ulepszeń waszego App. Można zacząć od prostego:

• Opisać, kim jest: „Jesteś analitykiem jakości App N, który…”
• Wymienić, jakie wejście dostaje: dialogi, sygnały, system‑prompt, opisy.
• Sformułować zadania:
  • znaleźć 2–3 wzorce problemów;
  • zaproponować po 1–2 zmiany w prompecie, tools, tekstach UX;
  • zebrać krótki changelog.
• Opisać format odpowiedzi: strukturyzowany JSON z polami patterns, suggestions, changelog.

Nawet jeśli na razie nie będziecie wywoływać tego agenta z kodu, sam taki prompt pomoże wam lepiej ustrukturyzować myślenie o tym, jak ulepszacie App.

10. Typowe błędy przy budowaniu cyklu ulepszeń

Błąd nr 1: optymalizacja tylko pod jedną metrykę.
Skupić się na czymś jednym jest bardzo kusząco. Można gonić tylko za cost, cieszyć się spadkiem rachunku od OpenAI — i nie zauważyć, jak quality‑score, konwersje i retention zaczęły spadać. Cykl ulepszeń musi patrzeć na pakiet metryk: jakość ↔ pieniądze ↔ zachowanie użytkowników.

Błąd nr 2: „magiczne” zmiany promptu bez pomiarów.
Fraza „przepisałem system‑prompt, teraz powinno być lepiej” bez golden‑cases i evali — to sposób na niespodziankę za parę tygodni. Każda zmiana promptu — zwłaszcza na produkcji — powinna przechodzić przez jasny pipeline: zestaw case’ów, LLM‑eval przed/po, w razie potrzeby — eksperyment online. Inaczej nie ulepszacie App, tylko rozrzucacie jakość w losowym kierunku.

Błąd nr 3: auto‑deploy zmian od asystenta LLM.
Nawet jeśli asystent ulepszeń pisze niewiarygodnie ładne fragmenty promptu i przekonujące opisy narzędzi, to nie powód, by pchać je na produkcję bez review. Model może nie widzieć wszystkich ograniczeń biznesowych, ryzyk safety, kontekstu waszych metryk. Jego rola — konsultant, a nie DevOps z prawem do releasu.

Błąd nr 4: brak powiązania zmian z hipotezą i sygnałami.
Zdarza się, że zespoły robią poprawki „na czuja” i nie zapisują, jaki sygnał doprowadził do zmiany i jaką hipotezę weryfikują. W efekcie po miesiącu nikt nie pamięta, po co pojawił się dziwny akapit w prompecie i komu był w ogóle potrzebny. Dobry PR dotyczący jakości powinien odpowiadać co najmniej na trzy pytania: „co bolało?”, „co zmieniamy?”, „po której metryce poznamy, że jest lepiej?”.

Błąd nr 5: zapominanie o safety przy ulepszeniach.
W pogoni za użytecznością łatwo poluzować ograniczenia safety, usunąć z promptu „zbędne odmowy” lub zapomnieć przepuścić safety‑cases. Każda zmiana system‑promptu, opisów tools i behavioru agenta powinna najpierw przechodzić przez zestaw safety‑eval. Jeśli choć jeden case, który wcześniej przechodził, teraz pada — to sygnał stop, choćby reszta metryk wyglądała pięknie.

Błąd nr 6: chęć „optymalizowania wszystkiego naraz”.
Przepisać połowę promptu, zmienić model, dodać jeszcze jedno narzędzie MCP i nowy kreator — wszystko w jednym wydaniu — brzmi produktywnie, ale całkowicie zabija możliwość zrozumienia, która zmiana dała efekt. Cykl ulepszeń jest skuteczny tylko wtedy, gdy jest iteracyjny i skupiony: jedna–dwie hipotezy, mały zestaw zmian, jasny plan rollbacku.

Błąd nr 7: zamienianie cyklu ulepszeń w rzadki „generalny dzień porządków”.
Jeśli raz na pół roku urządzacie wielki „dzień jakości”, a pozostałe miesiące żyjecie bez evali i analizy metryk, App przez większość czasu będzie „płynąć z nurtem”. O wiele bardziej przydatny jest mały, ale regularny rytuał: co tydzień/dwa patrzeć na sygnały, aktualizować hipotezy i robić małe kroki. Właśnie tak wasz ChatGPT App przestaje być statyczny i zaczyna naprawdę samodoskonalić się.