---
name: iterative-refinement-loop
title: Pętla Iteracyjnego Doskonalenia
description: "Pętla Buduj → Krytykuj → Dopracuj na wypadek, gdy „wystarczająco dobre\" nie wystarczy. Zamiast liczyć na idealny pierwszy output, planuj 2-3 iteracje od początku. Każda runda ma konkretny fokus: pierwsza na strukturę i poprawność, druga na jakość i edge case'y, trzecia na szlif i wydajność. Działa dla kodu, pisania, architektury i designu."
category: general
tags:
  - iteracja
  - feedback
  - jakość
  - workflow
  - krytyka
  - doskonalenie
source: https://madejski.ai/pl/promptoteka/iterative-refinement-loop
locale: pl
license: MIT
---

# Pętla Iteracyjnego Doskonalenia

## Główna idea

Nie oczekuj perfekcji od pierwszego podejścia. Planuj iteracje od początku. Każde przejście ma inny fokus:

**Przejście 1: Struktura** — Ustaw kształt. Poprawne, kompletne, działające.
**Przejście 2: Jakość** — Utwardź. Edge case'y, obsługa błędów, testy.
**Przejście 3: Szlif** — Zrób to świetnym. Wydajność, czytelność, dokumentacja.

## Dlaczego to działa

Pierwszy output z AI (lub od ludzi) ma przewidywalne słabości:
- Happy path działa, edge case'y nie
- Struktura jest dobra, szczegóły złe
- Działa, ale nie jest utrzymywalne
- Rozwiązanie jest poprawne, ale nieeleganckie

Planowanie iteracji pozwala pierwszemu przejściu być szybkim i kreatywnym bez presji na perfekcję. Kolejne przejścia są skupione i chirurgiczne.

## Pętla

```
┌─→ Buduj (szybko, kreatywnie, niech działa)
│     ↓
│   Krytykuj (co jest źle? czego brakuje? co jest kruche?)
│     ↓
│   Dopracuj (napraw ustalenia krytyki, popraw)
│     ↓
│   Wystarczająco dobre? ──Nie──┘
│     │
│    Tak
│     ↓
│   Shipuj
```

## Przejście 1: Struktura i poprawność

**Cel:** Niech działa. Wszystkie wymagania spełnione. Bez crashy.

**Pytania krytyki:**
- Czy spełnia wszystkie wymagania ze specyfikacji?
- Czy happy path działa end-to-end?
- Czy ogólna architektura jest solidna?
- Czy są problemy strukturalne, które będzie drogo naprawić później?

**Akcja:** Napraw tylko problemy strukturalne. Nie szlifuj.

## Przejście 2: Jakość i solidność

**Cel:** Niech będzie solidne. Obsługuj edge case'y. Dodaj testy.

**Pytania krytyki:**
- Co się dzieje z nullem/pustym/brakującym inputem?
- Co się dzieje z bardzo dużym inputem?
- Co się dzieje gdy zewnętrzne serwisy zawodzą?
- Czy błędy są obsługiwane gracefully?
- Czy jest pokrycie testami dla krytycznych ścieżek?
- Czy są podatności bezpieczeństwa?

**Akcja:** Dodaj obsługę błędów, edge case'y, walidację, testy.

## Przejście 3: Szlif i wydajność

**Cel:** Niech będzie świetne. Optymalizuj. Posprzątaj.

**Pytania krytyki:**
- Czy kod jest czytelny dla kogoś widzącego go po raz pierwszy?
- Czy są wąskie gardła wydajności?
- Czy jest martwy kod lub niepotrzebna złożoność?
- Czy nazwy są opisowe?
- Czy dokumentacja jest aktualna?
- Czy byłbyś dumny pokazując to seniorowi?

**Akcja:** Optymalizuj, refaktoryzuj, dokumentuj, posprzątaj.

## Kiedy przestać

Przestań iterować gdy:
- Wszystkie kryteria akceptacji przechodzą
- Nie ma ustaleń KRYTYCZNYCH ani WYSOKICH
- Następne przejście przyniosłoby malejące zyski
- Time box się skończył

Nie przestawaj bo:
- „Działa" (działanie to Przejście 1, nie koniec)
- Masz dość patrzenia na to (wtedy właśnie bugi się chowają)
- Deadline jest jutro (obcinaj zakres, nie jakość)

## Zastosowanie w różnych domenach

### Kod
- Przejście 1: Działająca implementacja, główny test przechodzi
- Przejście 2: Testy edge case'ów, obsługa błędów, review bezpieczeństwa
- Przejście 3: Optymalizacja wydajności, czyszczenie kodu, dokumentacja

### Pisanie
- Przejście 1: Struktura i treść kompletna, wszystkie punkty pokryte
- Przejście 2: Sprawdzenie faktów, logiczny przepływ, kalibracja pod odbiorcę
- Przejście 3: Styl, zwięzłość, formatowanie, korekta

### Architektura
- Przejście 1: Zidentyfikowane komponenty, zmapowany przepływ danych, zdefiniowane interfejsy
- Przejście 2: Tryby awarii, skalowalność, analiza bezpieczeństwa
- Przejście 3: Optymalizacja kosztów, kwestie operacyjne, dokumentacja

### Design
- Przejście 1: Layout, hierarchia informacji, przepływ użytkownika
- Przejście 2: Edge case'y (puste stany, błędy, ładowanie), dostępność
- Przejście 3: Wizualny szlif, mikro-interakcje, responsywność

## Antywzorce

- Szlifowanie w Przejściu 1 (strata czasu jeśli struktura się zmieni)
- Pomijanie krytyki (dopracowanie bez feedbacku to po prostu przepisywanie)
- Za dużo przejść (3 zwykle wystarczą; 5+ oznacza, że spec był zły)
- Ta sama krytyka co przejście (każde przejście powinno znajdować NOWE problemy, nie powtarzać starych)
- Dopracowywanie bez jasnych kryteriów „gotowe" (nieskończona pętla)