Agent pisze kod. A kto projektuje pracę?

Codex, Claude Code, GitHub i Linear: budujemy środowisko, w którym agent doprowadza zadania do weryfikowalnego rezultatu

Sergey Avdeichik · DOBROVOLA · 15 września 2026 r.

Wyobraźcie sobie: wychodzicie na obiad, a agent nadal programuje. Wracacie — dziesiątki zmienionych plików, nowe testy, schludny raport. Pięknie. Zostało tylko jedno drobne pytanie: czy użytkownik może teraz zrobić to, po co w ogóle zaczęliśmy tę pracę?

Czasem tak. A czasem agent po prostu bardzo aktywnie spędził ostatnią godzinę.

To nie jest już rozmowa wyłącznie w gronie entuzjastów nowych narzędzi. Martin Fowler opisuje agentic programming — tworzenie oprogramowania, w którym człowiek kieruje agentem i sprawdza jego pracę. Addy Osmani proponuje myśleć nie o pojedynczym promptcie, lecz o pętli wykonania i oceny. Robert Martin i Justin Martin pokazują proces wieloagentowy, w którym pisanie kodu otaczają wyspecjalizowane kontrole. To różne podejścia, a nie jeden manifest. Łączy je jednak pytanie: jak organizować pracę inżynierską, gdy kod tworzy już nie tylko człowiek? [1] [2] [3]

I właśnie tutaj zaczyna się najciekawsza część dla studenta. Można uczyć się uzyskiwać efektowne odpowiedzi. Można też nauczyć się budować mały system inżynierski, który zamienia pomysł w rezultat możliwy do sprawdzenia.

W poprzednich materiałach rozmawialiśmy o Software 3.0 oraz o drodze od rozmowy do blueprintu, researchu, specyfikacji technicznej i odbioru. Teraz idziemy krok dalej: intencja jest już zrozumiała — jak zorganizować sam proces developmentu? Powiązany materiał o pracy weryfikowalnej znajduje się w źródłach. [23]

Dalej opisuję własną metodykę pracy, a nie obowiązkowy regulamin OpenAI czy Anthropic. Oddzielam możliwości platform od własnych rekomendacji. Przykłady projektu, zadań i liczb są dydaktyczne — nie przedstawiam ich jako wyników kontrolowanego eksperymentu.

1. Środowisko pracy to nie okno Codex

Kiedy ktoś pyta mnie, gdzie pracuje mój agent, odpowiedź „w Codex” jest zbyt krótka. To trochę tak, jakby powiedzieć, że inżynier pracuje w edytorze tekstu. Technicznie prawda, ale z obrazu znikają projekt, wymagania, współpracownicy, testy i samo rozwiązanie.

W moim modelu projekt ma dwa repozytoria i przestrzeń zadań w Linear.

Repozytorium dokumentacji przechowuje zamysł: blueprint, research wariantów, specyfikację techniczną, zadania dla kamieni milowych, decyzje architektoniczne i notatki. Tutaj można myśleć szeroko. Ale każdy dokument powinien mieć status: pomysł, szkic, zatwierdzony, zastąpiony nowszą wersją. Wczorajsze „a może dodajmy jeszcze…” nie staje się wymaganiem tylko dlatego, że trafiło do pliku Markdown.

Repozytorium aplikacji przechowuje to, co faktycznie wdrożono: kod, testy, konfigurację builda i instrukcje uruchomienia. Historia zmian pokazuje, co naprawdę weszło do produktu, a nie tylko zostało obiecane na czacie.

Linear przechowuje stan pracy: który kamień milowy realizujemy, co przydzielono, co jest zablokowane, gdzie znajdują się dowody rezultatu i jaka decyzja została podjęta. Sama platforma pozwala łączyć zadania w kamienie milowe projektu; zamiana tej struktury w „tory” dla agentów to już nasz sposób organizacji pracy. [4]

Codex lub Claude Code to narzędzie wykonawcze działające wewnątrz tego środowiska. Dzisiaj jedno, jutro drugie. Jeżeli cała logika projektu żyła wyłącznie w sesji, która później zniknęła, straciliśmy nie narzędzie, lecz kontrolę nad projektem.

Proponuję następujący podział. Dokumentacja odpowiada na pytanie „co i dlaczego budujemy?”, repozytorium aplikacji — „co już zbudowano?”, Linear — „co dzieje się teraz?”. Zadania i kamienie milowe wyznaczają duży kierunek. AGENTS.md, CLAUDE.md, role i skille są precyzyjniejszymi pokrętłami: jak działać i co sprawdzać w danym obszarze. Żadna warstwa nie zastępuje pozostałych. Dwa repozytoria nie są jedyną możliwą architekturą przechowywania. W małym ćwiczeniu można zacząć od dwóch sekcji w jednym repozytorium. Granicę między zamysłem a wykonaniem warto jednak zachować od pierwszego dnia.

Schemat 1. Środowisko jest większe niż narzędzie.

>

Blueprint i specyfikacja w project-docs → kamień milowy i zadania w Linear → praca agenta → zmiany i kontrole w project-app → decyzja człowieka.

>

Komentarze w Linear łączą zlecenie, rezultat i kolejny krok. Codex i Claude Code znajdują się wewnątrz tego procesu, a nie zastępują go.

Jak nie stworzyć trzech konkurencyjnych wersji prawdy

Nie kopiujcie tego samego wymagania do pięciu miejsc. W zadaniu wskażcie konkretną sekcję specyfikacji i jej wersję. W pull requeście — dalej PR — wskażcie zadanie. W komentarzu z rezultatem wskażcie PR i dokładny commit, który został sprawdzony.

Szczególnie ważne jest techniczne połączenie obu repozytoriów. Link do dokumentacji nie oznacza jeszcze, że agent ją przeczytał. W kontekście startowym podajcie adres repozytorium, potrzebną wersję i dostępny sposób odczytu — na przykład katalog obok lub zatwierdzone narzędzie. Poproście agenta o wskazanie plików, które rzeczywiście otworzył. Niedostępna specyfikacja jest blockerem, a nie zaproszeniem do odtworzenia jej „z sensu”.

2. Co tak naprawdę otrzymuje model

Słowo harness można rozumieć jako „obudowę” lub „warstwę wykonawczą” wokół modelu. To oprogramowanie, które przekazuje kontekst, organizuje wywołania narzędzi i zwrot wyników oraz utrzymuje pętlę pracy. W inżynierskim opisie OpenAI dobrze widać, że model i pętla agenta to nie to samo. [5]

Tu pojawia się ważne rozróżnienie. Istnieje semantyczna organizacja projektu oraz techniczny sposób składania wejścia dla modelu. Łatwo je pomylić.

W semantycznej organizacji zatwierdzony blueprint jest ważniejszy niż przypadkowa notatka, a przydzielone zadanie ważniejsze niż nagła ochota agenta na refaktoryzację. Ale to nasza dyscyplina projektowa. Linear nie staje się wiadomością z rolą system tylko dlatego, że nazwaliśmy go „torami”.

W opublikowanym przez OpenAI opisie Codex wejście początkowe obejmuje instrukcje bazowe, wiadomości deweloperskie o środowisku i ustawieniach, kontekst użytkownika z plików projektu i informacje o skillach, a następnie bieżące zadanie. To opis konkretnego rozwiązania opublikowany 23 stycznia 2026 r., a nie obietnica niezmiennej kolejności dla wszystkich przyszłych klientów. [5]

Nie będziemy rekonstruować pełnego ukrytego promptu startowego każdej zamkniętej platformy. Potrzebujemy praktycznej mapy: co narzuca platforma, co dodajemy my, jakie materiały agent faktycznie przeczytał i jakie działania są technicznie dozwolone.

Codex i Claude Code mają podobne cele, ale różne mechanizmy

W Codex instrukcje projektu są składane z AGENTS.md i, jeśli istnieje, AGENTS.override.md. Brane są pod uwagę ustawienia użytkownika oraz ścieżka od katalogu głównego projektu do bieżącego katalogu roboczego; instrukcje bardziej lokalne są dodawane później. Nie należy zakładać, że wszystkie pliki ze wszystkich podkatalogów od razu trafiają do kontekstu. Dokumentacja osobno opisuje limit objętości i sposób budowania łańcucha instrukcji przy starcie. [6]

Claude Code korzysta z CLAUDE.md, reguł projektu i pamięci. Dokumentacja wyraźnie oddziela je od wymuszanej konfiguracji. Pliki z katalogów nadrzędnych mogą być ładowane przy starcie, a instrukcje z katalogów zagnieżdżonych — w miarę odczytywania powiązanych plików. Obsługiwane są importy w rodzaju @ścieżka. Sam fakt istnienia pliku nie dowodzi jeszcze, że został prawidłowo podłączony. [7]

Schemat 2. Dwa różne obwody sterowania.

>

Kontekst modelu: instrukcje platformy → podłączone reguły projektu → bieżące zadanie → faktycznie przeczytane materiały i wyniki narzędzi.

>

Techniczne granice działań: dozwolone narzędzia, izolacja systemu plików, dostęp sieciowy, uprawnienia kont usługowych, zasady merge.

>

To schemat koncepcyjny, a nie uniwersalna tabela priorytetów. Każdy klient ma własny mechanizm ładowania. Granice techniczne nie są po prostu kolejnym akapitem promptu.

Instrukcja, uprawnienie i ograniczenie to trzy różne rzeczy

„Nie zmieniajcie głównej gałęzi” to instrukcja. Możliwość zapisu do repozytorium to uprawnienie. Reguła branch protection blokująca bezpośredni zapis to ograniczenie techniczne.

Dlatego zapis w AGENTS.md nie zastępuje kontroli dostępu. Anthropic opisuje containment jako połączenie zachowania modelu, ograniczeń środowiska i kontroli dostępnych zasobów. Dokument czytany przez agenta także może zawierać złośliwe instrukcje: dostępne źródło nie staje się automatycznie zaufaną instrukcją. [8]

W projekcie studenckim rekomenduję osobne dane testowe, minimalne potrzebne uprawnienia i brak automatycznego wydania bez uzgodnionego etapu kontroli. GitHub może wymagać PR, checków i review przed merge; dostępność konkretnych reguł zależy od planu i rodzaju repozytorium. Warto też sprawdzić, czy administrator lub konto usługowe może je ominąć. [9]

Jeszcze jedna subtelność: lokalnego sandboxa nie należy automatycznie traktować jako ochrony dla zewnętrznego narzędzia MCP. Usługa zdalna musi sama egzekwować swoje prawa i dozwolone operacje. Ta granica została również zaznaczona w opisie Codex. [5]

3. Najpierw pakiet startowy. Nie konstytucja na dwieście stron

Mój zwykły proces nie zaczyna się od polecenia „stwórz aplikację”. Najpierw przekazuję modelowi tekstowemu zatwierdzony blueprint, specyfikację i własne preferencje projektowe. W mojej praktyce często jest to GPT w trybie Pro. Proszę o przejrzenie aktualnej dokumentacji wybranej platformy agentowej i przygotowanie początkowego zestawu plików.

Kluczowe słowo to startowy.

Nie znamy jeszcze wszystkich przyszłych problemów. Próba napisania idealnych instrukcji dla całego projektu przed pierwszym zadaniem przypomina tworzenie instrukcji na każdy możliwy błąd studenta jeszcze przed pierwszymi zajęciami. Dużo tekstu, mało użytecznych drogowskazów.

Pakiet startowy powinien wyjaśniać, skąd biorą się wymagania, jak uruchamiać kontrole, jakich granic nie wolno zmieniać i jakie dowody należy przedstawić przy odbiorze. Szczegóły kolejnego kamienia milowego powstaną wtedy, gdy do niego dojdziemy.

To podejście nie jest przywiązane do Pythona

Uniwersalne są zamysł, granice zadania, porządek pracy, dowody rezultatu i warunki zatrzymania. Zmieniają się język, struktura aplikacji i polecenia weryfikacyjne.

Dla Pythona profil stosu może zawierać pytest, ruff, zasady typowania i układ modułów. Dla TypeScript — menedżer pakietów, polecenia kontroli typów, testów i builda. Zapis pnpm test ma sens tylko wtedy, gdy taki skrypt naprawdę istnieje w projekcie. Skopiowanie cudzego pliku nie tworzy brakującej infrastruktury.

Dlatego oddzielam rdzeń procesu, profil stosu i adapter platformy. To rekomendacja dotycząca naszego pakietu, a nie wbudowana terminologia Codex.

Schemat 3. Co przenosi się między projektami.

>

Rdzeń: źródła wymagań, role, przekazanie pracy, odbiór.

>

Profil stosu: język, zależności, struktura, polecenia uruchomienia i testów.

>

Adapter platformy: rozpoznawane pliki instrukcji, format skilli, konfiguracja agentów i narzędzi.

>

Przy przejściu z Pythona na TypeScript nie trzeba od nowa wymyślać zarządzania pracą. Trzeba jednak ponownie sprawdzić polecenia i strukturę projektu.

Minimalny układ może wyglądać tak:

workspace/
  project-docs/                 # osobne repozytorium Git
    blueprint.md
    specifications/project.md
    milestones/M1.md
    decisions/
    agent-design/roles/
    agent-design/skills/
  project-app/                  # osobne repozytorium Git
    AGENTS.md
    CLAUDE.md
    PROJECT_CONTEXT.md
    STACK.md
    src/
    tests/
    .gitignore

PROJECT_CONTEXT.md to nasza mapa wejścia: adresy repozytoriów, wersje dokumentów, aktywny kamień milowy i sposób dostępu. STACK.md zawiera prawdziwe polecenia i konwencje. Katalogi agent-design/roles i agent-design/skills są naszymi materiałami źródłowymi, a nie magicznymi nazwami automatycznie czytanymi przez każdego agenta.

Zlecenie dla modelu, który buduje pakiet

Przeanalizuj zatwierdzony blueprint i specyfikację. Oddziel decyzje od otwartych pytań. Na podstawie aktualnej dokumentacji wybranej platformy przygotuj minimalny pakiet startowy: instrukcje projektu, dwie role, jeden skill weryfikacji dostawy, profil stosu i mapę źródeł. Wskaż, które pliki platforma wykrywa automatycznie, a które trzeba podłączyć jawnie. Nie wymyślaj uprawnień ani poleceń. Nie opisuj szczegółowo przyszłych kamieni milowych. Dołącz manifest plików i instrukcję bezpiecznego wdrożenia pakietu.

Wynikowy ZIP nadal trzeba przeczytać. Szczególną uwagę zwróćcie na uprawnienia, działania zewnętrzne, uruchamianie skryptów oraz definicję „gotowe”. Kontrola człowieka dotyczy także instrukcji, nie tylko kodu.

Zlecenie dla agenta, który wdraża pakiet

Przygotuj wyłącznie środowisko, bez logiki produktowej. Najpierw sprawdź zawartość archiwum i istniejące katalogi; nie nadpisuj plików po cichu i nie uruchamiaj nieznanych skryptów. Utwórz uzgodnioną strukturę, .gitignore, przykłady konfiguracji bez sekretów oraz minimalny test uruchomienia. Inicjalizuj Git tylko tam, gdzie jeszcze go nie ma. Podłącz repozytoria wyłącznie do jawnie wskazanych i dozwolonych adresów. Publikacja, zmiana uprawnień i deployment wymagają osobnej zgody. Przedstaw utworzone pliki, wyniki kontroli i blockery.

Przy odbiorze chcę zobaczyć więcej niż „środowisko gotowe”: powtarzalne uruchomienie, działające kontrole, poprawne adresy repozytoriów, brak sekretów w śledzonych plikach oraz dostępną dokumentację. Przygotowane środowisko jest osobnym rezultatem. Aplikacja nie została jeszcze napisana — i to jest w porządku.

4. Jak pisać AGENTS.md, role i skille bez magii

Częsta pułapka polega na tym, że każdy z tych plików zaczyna powtarzać pozostałe. Agent dostaje trzy podobne, ale trochę różne regulaminy. Nie ma sensu urządzać mu egzaminu z rozwiązywania naszych sprzeczności.

Instrukcje ogólne odpowiadają na pytanie: „Jakie reguły obowiązują zawsze?” Rola — „Za jaki rezultat odpowiadasz teraz?” Skill — „Jak wykonać powtarzalną procedurę?”

Cienki AGENTS.md

Poniżej dydaktyczny szablon. Linki i polecenia w prawdziwym projekcie muszą prowadzić do istniejących zasobów.

# Praca w projekcie

Przed rozpoczęciem przeczytaj PROJECT_CONTEXT.md i STACK.md.
Pracuj wyłącznie nad przydzielonym zadaniem bieżącego kamienia milowego.
Sprawdź wersję specyfikacji i kryteria odbioru w Linear.

Nie zmieniaj wymagań ani kryteriów tylko po to, aby testy przeszły.
Jeśli dokumenty są sprzeczne, zatrzymaj sporną część pracy
i zadaj konkretne pytanie w komentarzu do zadania.

Nie dodawaj niezamówionych funkcji ani refaktoryzacji.
Nie publikuj sekretów. Nie wykonuj release bez zgody.

W raporcie podaj zadanie, commit, PR, wykonane polecenia,
faktyczne wyniki kontroli, ograniczenia i kolejny krok.
Kontrola, której nie uruchomiono, musi być oznaczona jako nieuruchomiona.

Nie trzeba wypisywać tutaj wszystkich endpointów aplikacji. Plik ma pomagać znaleźć właściwe reguły, a nie konkurować ze specyfikacją.

Dla Claude Code można przygotować niewielki CLAUDE.md, który importuje wspólną bazę, a niżej zawiera wyłącznie różnice klienta:

@AGENTS.md

# Specyfika Claude Code
Przed rozpoczęciem sprawdź dostępność potrzebnych narzędzi.
Rolę i zadanie otrzymasz w zleceniu startowym.

Claude Code obsługuje taki import. Po konfiguracji sprawdźcie załadowany kontekst mechanizmami klienta; sam fakt zapisania pliku nie jest dowodem, że został zastosowany. [7]

Rola to nie lista wszystkich zalet idealnego programisty

Dla wykonawcy wystarczy jasne zadanie: zrealizować uzgodnioną pracę, utrzymać zmiany w jej granicach, odtworzyć kontrole i przedstawić rezultat.

Kierownik ma inną pracę: porównuje realny postęp z celem kamienia milowego, wykrywa luki w dowodach i wydaje konkretne korekty. Nie „bądź najlepszym senior principal staff architect”, tylko sprawdzaj określone rzeczy.

W razie potrzeby obie role mogą korzystać ze specjalistycznych pomocników. Jeden analizuje kod, drugi sprawdza scenariusze testowe, trzeci szuka ryzyka naruszenia kontraktu API. Liczba ról ma wynikać z pracy, a nie z urody diagramu.

Na dzień weryfikacji Codex obsługuje projektowe definicje własnych agentów w .codex/agents/*.toml, a Claude Code — w .claude/agents/*.md z nagłówkiem konfiguracyjnym. To różne formaty. Nasz opis roli trzeba jawnie przekazać do sesji lub dostosować do odpowiedniego adaptera. [12] [13]

Skill: kiedy, z czym i do jakiego rezultatu

Na obu platformach skill opiera się na SKILL.md. Opis pomaga wybrać procedurę, a szczegóły są dołączane w miarę potrzeby. Dla umieszczenia projektowego dokumentacja Codex wskazuje .agents/skills/, a Claude Code — .claude/skills/. Wspólna idea nie oznacza identyczności wszystkich pól dodatkowych ani sposobów podłączania. [10] [11]

Przykład własnej procedury:

---
name: verify-delivery
description: Weryfikacja rezultatu zadania przed przekazaniem człowiekowi.
---

Wejście: zadanie, kryteria odbioru, commit do sprawdzenia,
lista zmienionych plików i wyniki CI.

1. Powiąż każde kryterium z weryfikowalnym dowodem.
2. Sprawdź scenariusz główny, pusty i błędny.
3. Porównaj zmiany z granicami zadania.
4. Używaj tylko dozwolonych poleceń z STACK.md.
5. Oddziel defekty od niezweryfikowanych założeń.

Wyjście: spełnione kryteria, defekty, punkty niezweryfikowane,
linki do dowodów i rekomendacja kolejnego kroku.

Nie poprawiaj kodu w ramach tego skilla.
Nie zmieniaj kryteriów i nie wykonuj merge ani release.

To instrukcja weryfikacji, a nie gwarancja niezależności. Jeśli pierwszy agent wymyśli błędne oczekiwanie, a drugi przyjmie je jako prawdę, obaj mogą powielić ten sam błąd. Dlatego oczekiwane rezultaty powinny wynikać z wymagań i przygotowanych przykładów, a ważne kontrole muszą być odtwarzalne.

Testujcie również same skille. Dajcie procedurze PR z celowo pominiętym scenariuszem, a potem poprawny PR. W pierwszym przypadku powinna zauważyć lukę, w drugim — nie wymyślać defektu tylko po to, aby raport wyglądał przekonująco. Testować można nie tylko aplikację, ale i sposób pracy nad nią.

5. Jeden kamień milowy — jeden zrozumiały rezultat

Weźmy dydaktyczną aplikację ReadingLab. Student zapisuje sesje nauki: datę, temat i czas trwania. Chcemy dodać raport za wybrany okres. W tym przykładzie rejestrowanie sesji już istnieje; pierwszy omawiany kamień milowy dotyczy wyłącznie raportu.

Zły kamień milowy: „Zbudować system analityki aktywności edukacyjnej”.

Lepszy: „Użytkownik otwiera raport za wybrany okres i widzi poprawne dane, w tym uczciwie pokazane braki.”

Zadanie przestaje być workiem możliwości. Możemy nazwać jego granice. Na przykład w tym kamieniu milowym tworzymy ekran i obliczenia; rekomendacje modelu, eksport PDF i porównanie z innymi studentami pozostają poza zakresem.

W środku wystarczy kilka zadań wykonywanych po kolei: uzgodnić kontrakt i przykłady; zaimplementować obliczenia i wydawanie danych; podłączyć ekran; wykonać końcową kontrolę scenariusza. Liczba zadań jest narzędziem zarządzalności, a nie kultem małych kart. Jeśli zadania nadal nie da się jasno wyjaśnić i sprawdzić, zmniejszcie kamień milowy.

Jak wygląda karta, według której można pracować

Przykładowe zadanie READ-12:

Rezultat: raport za wybrany okres pokazuje sesje oraz sumę znanych czasów trwania.

>

Podstawa: zatwierdzona sekcja specyfikacji i wersja zestawu przykładów.

>

Granice: bez rekomendacji, eksportu i zmian w sposobie przechowywania rekordów źródłowych.

>

Kryteria: okres traktowany jest jako przedział półotwarty [początek, koniec) w uzgodnionej strefie czasowej; uwzględniane są wyłącznie rekordy bieżącego użytkownika. Dla przykładu „20 minut, 35 minut, czas trwania niepodany” wynik to 55 znanych minut oraz jeden rekord z nieznanym czasem. Brak nie zamienia się w zero. Pusty okres daje poprawny pusty raport, a nie błąd.

>

Dowody: testy obliczeń i granic okresu, kontrola izolacji danych użytkowników, odtworzenie scenariusza ekranu, link do PR i commita.

Część tych decyzji można było podjąć inaczej. Trzeba je jednak podjąć zanim agent zrobi to za nas po cichu. Teraz jasne są zarówno funkcjonalność, jak i sposób jej sprawdzenia.

Nie mylcie „testy są zielone” z „zadanie rozwiązane”

Potrzebujemy różnych poziomów obserwacji. Test funkcji potwierdza obliczenia. Test integracyjny — że dane prawidłowo przechodzą przez komponenty. Scenariusz użytkownika — że człowiek rzeczywiście może otworzyć właściwy raport. Kontrola uprawnień — że rekordy innego użytkownika nie trafiają do wyniku.

Każda kontrola odpowiada na inne pytanie. Sto testów funkcji pomocniczych nie kompensuje braku sprawdzenia głównego scenariusza. A zrzut ekranu ładnego interfejsu nie dowodzi poprawności sumy.

Schemat 4. Od zadania do dostawy.

>

Kryterium → przykład z oczekiwanym wynikiem → zmiana kodu → kontrola konkretnego commita → PR → decyzja człowieka → merge do main → sprawdzenie uzgodnionego środowiska.

>

Kolejny kamień milowy planujemy szczegółowo na podstawie zaakceptowanego rezultatu poprzedniego. Merge i deployment to dwa różne zdarzenia.

Początkującym rekomenduję jeden aktywny kamień milowy. To nie zabrania badać przyszłych pomysłów. Chodzi o to, aby najpierw nauczyć się kończyć pracę, zanim zaczniemy jednocześnie zarządzać kilkoma niedokończonymi historiami.

6. Nieproduktywne kodowanie: pliki się zmieniają, produkt nie

Znana scena: agent dodaje klasę pomocniczą, poprawia handler, zmienia nazwę modułu, pisze nowe testy. Potem ulepsza ulepszenia. Wszystko wygląda rozsądnie. Użytkownik nadal nie może dostać raportu.

Nazywam to nieproduktywnym kodowaniem: aktywność wokół kodu zastępuje postęp w stronę zaakceptowanego rezultatu.

To nie znaczy, że refaktoryzacja i research są bezużyteczne. Czasem prawidłowym wynikiem researchu jest decyzja, by nie pisać planowanej funkcji. Czasem trzeba naprawić defekt architektoniczny, aby móc cokolwiek dostarczyć. Ale związek powinien być widoczny: jaką przeszkodę usunęliśmy, jaką decyzję zweryfikowaliśmy, do którego kryterium się zbliżyliśmy?

Dlatego nie patrzę na liczbę commitów. Pytam: co stało się dostępne dla użytkownika? Jakie ryzyko spadło? Co przeszkadza zakończyć zadanie? Ile czasu i powtórnych uruchomień kosztował zaakceptowany rezultat?

Jeśli agent już drugi cykl dyskutuje architekturę fabryki raportów, a my nadal nie ustaliliśmy, co ma znaczyć pusty okres, problem może nie leżeć w mocy modelu. Być może zadanie jest po prostu za mało precyzyjne.

Instrukcje zmieniają się również w trakcie kamienia milowego

Nie trzeba czekać do końca, aby poprawić regułę, która nie działa. Ale dopisywanie po każdym incydencie kolejnego „nigdy” także jest złą strategią.

Proponuję małą pętlę: znaleźć konkretny epizod → ustalić przyczynę → zmienić właściwy element środowiska → powtórzyć kontrolę.

Agent zamienia brak czasu trwania na zero? Najpierw sprawdźcie kontrakt danych i przykład oczekiwanego rezultatu. Być może trzeba poprawić specyfikację i test, a nie ogólną rolę. Agent po każdej drobnej zmianie uruchamia ciężką weryfikację? Być może potrzebny jest uzgodniony porządek szybkich i pełnych kontroli. Agent czyta starą specyfikację? Naprawcie mapę źródeł i sposób wyboru wersji.

Zmiana instrukcji także powinna mieć powód i wersję. Przy przejściu między kamieniami milowymi ponownie oceńcie potrzebne kompetencje: przy imporcie danych ważniejsze będą walidacja i błędy; przy interfejsie — scenariusze użytkownika i dostępność. Nie przenoście automatycznie całej narosłej konfiguracji.

Sprawdźcie też, czy zmiany rzeczywiście weszły w życie. Codex dokumentuje budowanie łańcucha AGENTS.md przy starcie; w działającej sesji nie można po prostu założyć, że nowy plik zastąpił stary kontekst. Restart albo wspierane przez klienta odświeżenie kontekstu powinny być częścią procedury. [6]

7. Kierownik i wykonawca: rozdzielamy uwagę, a nie stanowiska

Teraz użyteczny wzorzec dla dłuższej pracy. Jeden agent realizuje zadanie. Drugi jest celowo wyłączony z bieżącego pisania produktu i sprawdza, czy nie zgubiliśmy celu.

Nazywam ich kierownikiem i wykonawcą. To role zbiorcze. Wykonawca może poprosić pomocnika o review kodu, kierownik — specjalistę od testowania. Wzorzec nie wymaga dokładnie dwóch modeli i nie zabrania subagentów.

Wymaga jednak jednej jasnej granicy: wykonawca posuwa implementację do przodu; kierownik sprawdza postęp i jakość podstaw do wniosków.

Dobry wariant startowy to dwie osobne sesje. Kierownik dostaje bieżący kamień milowy i zadanie, czyta źródła i formułuje zlecenie. Wykonawca je realizuje i przedstawia rezultat. Kierownik sprawdza, zwraca konkretne uwagi albo rekomenduje przekazanie pracy człowiekowi.

Możliwości natywnych subagentów, dziedziczenie kontekstu i dopuszczalna głębokość zagnieżdżenia zależą od klienta. Nasz wzorzec organizacyjny nie wymaga, by subagent potrafił bez końca tworzyć kolejne subagenty. Dokumentacja platform opisuje osobne mechanizmy specjalizacji i ograniczeń narzędzi — trzeba je konfigurować jawnie. [12] [13]

Wspólna pamięć procesu — komentarze w Linear

Czat jest wygodny do uruchomienia pracy. Ale zlecenie, wynik i korekta powinny pozostać w karcie zadania. W przeciwnym razie kolejny uczestnik będzie musiał zgadywać, co ustalono w zamkniętej rozmowie.

Proponuję krótki protokół komentarzy. To nasza konwencja, a nie wbudowany standard Linear:

ZLECENIE / wersja 2
Zadanie: READ-12. Specyfikacja: wersja i sekcja.
Cel i granice: ...
Kryteria: ...
Punkt kontrolny i warunki zatrzymania: ...

WYNIK / odpowiedź na zlecenie wersji 2
Gałąź, PR, commit do sprawdzenia: ...
Co zmieniono: ...
Polecenia i faktyczne wyniki kontroli: ...
Czego nie sprawdzono i dlaczego: ...
Blockery i kolejny krok: ...

KONTROLA / tego samego commita
Potwierdzono: ...
Defekty z reprodukcją: ...
Korekta albo rekomendacja dla człowieka: ...

Nie ma potrzeby wklejać całego logu terminala. Zachowujcie krótkie podsumowanie i linki do dostępnych dowodów. Jeżeli commit zmienił się po kontroli, poprzednia rekomendacja nie staje się automatycznie ważna dla nowego kodu.

Każde zlecenie powinno mieć jednego właściciela. Wykonawca potwierdza przyjętą wersję, a kierownik nie wydaje jednocześnie sprzecznych korekt. W komentarzach powinno być widoczne, które polecenie zastąpiło poprzednie. To szczególnie pomaga po restarcie sesji.

Schemat 5. Kontrola bez drugiego wykonawcy.

>

Człowiek wyznacza cel i odbiera rezultat.

>

Kierownik → zlecenie w Linear → wykonawca → PR i dowody w Linear → kontrola kierownika → decyzja człowieka.

>

Obaj agenci mogą korzystać ze specjalistycznych pomocników. Kierownik nie poprawia produktu po cichu za plecami wykonawcy i nie odbiera pracy zamiast człowieka.

Co dokładnie sprawdza kierownik

Nie „czy raport brzmi przekonująco”, tylko zgodność z kryteriami, kompletność prawdziwego scenariusza użytkownika, brak niezamówionych zmian i wiarygodność zadeklarowanych kontroli.

Na przykład: „Test sumy przechodzi, ale nie sprawdzono nieznanego czasu trwania. Odtwórz przykład ze specyfikacji. Nie przebudowuj całego API: popraw obsługę braku i dodaj potrzebną kontrolę.” To jest bardziej użyteczne niż „podnieś jakość, działaj profesjonalnie”.

Delegowanie także ma granicę. Druga opinia modelu nie jest niezależną prawdą. Kierownik powinien sam otworzyć zmiany i dowody, a nie czytać wyłącznie samoopis wykonawcy. Człowiek przy odbiorze powinien umieć wyjaśnić, jak funkcja działa i czym to potwierdzono.

8. Długi cykl: najpierw ręcznie, potem automatycznie

Agent może długo pracować nad dużym zadaniem, ale czas pracy nie jest miarą jakości. Przydatne są punkty kontrolne: przed rozszerzeniem zakresu, po istotnej zmianie, po powtarzającej się porażce oraz przed przekazaniem rezultatu.

Później można dodać rytm czasowy — na przykład kontrolę co 15, 30 lub 60 minut. To przykład polityki nadzoru, a nie obietnica, że każdy interfejs obsługuje każde możliwe harmonogramowanie.

Samo napisanie „sprawdzaj wykonawcę co pół godziny” nie wystarczy. Potrzebny jest prawdziwy scheduler, działające środowisko, dostęp do rezultatów wykonawcy i kanał przekazywania korekt. Kierownik nie uzyskuje dostępu do innej zamkniętej sesji tylko dlatego, że nazwaliśmy go kierownikiem.

Dokumentacja OpenAI rozróżnia zaplanowane zadania w interfejsie webowym i aplikacji desktopowej; przy pracy lokalnej znaczenie ma dostępność komputera i plików. Nie należy automatycznie zakładać, że CLI i IDE mają ten sam interfejs harmonogramowania. Sprawdzajcie aktualne możliwości swojego klienta i konta. [14]

W Claude Code udokumentowano /loop, także z interwałem. To mechanizm sesyjny: wykonanie zależy od życia sesji, zajętości agenta i reguł schedulera; możliwe są opóźnienia, a zadania cykliczne mają ograniczony czas życia. To nie jest timer czasu rzeczywistego. [15]

Dydaktyczny przykład dla osobnej sesji kierownika, przy wcześniej skonfigurowanych dostępach:

/loop 30m Sprawdź nowe dowody dla READ-12 w Linear
i powiązany PR. Nie zmieniaj kodu. Porównaj postęp
z kryteriami. Dodaj korektę tylko wtedy, gdy pojawił się
nowy defekt, blocker albo odchylenie od celu.

W produkcyjnym zleceniu dodajcie limit kosztów, limit kolejnych nieudanych cykli i warunek wyłączenia nadzoru. Po zakończeniu zadania harmonogram trzeba anulować wspieranym narzędziem i sprawdzić anulowanie. Jeśli nic się nie zmieniło, nie uruchamiajcie kosztownego review tego samego commita po raz kolejny.

Osobno sprawdźcie kanał dostarczania korekt. Komentarz w Linear nie musi natychmiast przerwać wykonawcy, który już pracuje. Można umówić się na odczytywanie nowych instrukcji w punktach kontrolnych albo podłączyć obsługiwany mechanizm zdarzeniowy. Awaryjne zatrzymanie wymaga realnego kanału sterowania, a nie nadziei, że agent w porę zauważy komentarz.

Automatyczny kierownik jest użyteczny wtedy, gdy zmniejsza wasze obciążenie. Jeżeli zaczynacie pilnować wykonawcy, kierownika i jeszcze ich sporu, dodatkowa złożoność na razie się nie opłaciła.

9. Dla ciekawych: OpenAI Symphony

W tym miejscu warto wyjść poza ręczne przełączanie się między sesjami czatu. OpenAI ma projekt Symphony — nie Symfony, framework PHP, lecz inny projekt o podobnej nazwie.

Repozytorium Symphony zawiera specyfikację i eksperymentalną implementację orkiestratora. Autorzy pozycjonują go jako engineering preview dla zaufanych środowisk. To materiał do studiowania i adaptacji, a nie obietnica uniwersalnego systemu produkcyjnego. [16]

Idea jest prosta: orkiestrator pobiera odpowiednie zadanie z trackera, przygotowuje osobne środowisko robocze, uruchamia agenta i śledzi cykl życia pracy. W specyfikacji rozdzielono konfigurację wykonania od tekstu zadania; reguły mogą być przechowywane w wersjonowanym WORKFLOW.md. Uwzględniono też współbieżność, ponowienia i uzgadnianie stanu. [17]

W przykładowym workflow ważną część komunikacji z Linear wykonuje sam agent za pomocą dostępnych narzędzi. Nie oznacza to, że pojedynczy plik WORKFLOW.md automatycznie podłączy konto i wszystkie uprawnienia. Przykład nadal wymaga świadomej konfiguracji integracji. [18]

Schemat 6. Orkiestrator i kierownik to nie to samo.

>

Orkiestrator: wybierz dopuszczalne zadanie → przydziel workspace → uruchom → obserwuj stan → ponów lub zakończ.

>

Agent-kierownik: oceń sens rezultatu → znajdź odchylenie → zaproponuj korektę.

>

Te funkcje można łączyć. Sam scheduler nie daje jeszcze merytorycznej kontroli produktu.

Początkującym nie polecałbym zaczynać od „fabryki agentów”. Najpierw zakończcie jeden kamień milowy ręcznie. Potem zautomatyzujcie proces, który już rozumiecie. Dopiero później decydujcie, czy taki poziom orkiestracji jest naprawdę potrzebny.

Przed użyciem cudzego workflow sprawdźcie stany, przejścia, uprawnienia i warunki przekazania pracy człowiekowi. W szczególności pomyślne zakończenie pracy agenta może oznaczać gotowość do kontroli przez człowieka, a nie automatyczny merge i release. Dla naszej metodyki ta różnica jest fundamentalna. [17] [18]

10. Co naprawdę się zmienia: publikacje i obserwacje

Pracuję stale z Codex i Claude Code i widzę, jak zmieniają się nie tylko modele, lecz także środowiska wokół nich. Z mojego doświadczenia wynika, że aktualizacje harnessu coraz częściej pozwalają przekazywać agentowi dłuższy odcinek pracy. To obserwacja autora, a nie zmierzona statystyka częstotliwości wydań.

Są też weryfikowalne sygnały kierunku zmian. 10 września 2026 r. OpenAI ogłosiło publiczną betę Agents API: zarządzane wykonanie oparte na harnessie Codex i infrastrukturze dla agentów działających przez dłuższy czas. To osobny komunikat produktowy, a nie nowa komenda istniejącego CLI. Deklaracje dotyczące długości pracy pochodzą z opisu producenta, a nie z naszych testów projektu studenckiego. [19]

25 maja 2026 r. Anthropic opublikowało inżynierski materiał o containment — ograniczaniu tego, do czego agent w ogóle może uzyskać dostęp. Sam akcent jest ważny: długa praca wymaga nie tylko dobrych instrukcji, lecz także wcześniej zaprojektowanych granic środowiska. [8]

Wcześniejsze materiały — tekst OpenAI o harness engineering z 11 lutego oraz artykuł Anthropic o długotrwałym developmentcie aplikacji z 24 marca 2026 r. — pokazują podstawy tego podejścia. Środowisko, feedback i organizacja dłuższej pracy stają się samodzielnym problemem inżynierskim. To przydatne materiały bazowe, ale nie należy przedstawiać ich jako publikacji z ostatnich czterech miesięcy. [20] [21]

Z tych źródeł nie wynika, że wszyscy dostawcy włączyli maksymalną autonomię domyślnie ani że kontrola człowieka przestała być potrzebna. Ostrożniejszy wniosek brzmi: platformy rozszerzają fragment pracy, który można delegować, i rozwijają mechanizmy zarządzania tym fragmentem.

Trzy świeże głosy — i jedno użyteczne wcześniejsze ostrzeżenie

Martin Fowler, 21 maja 2026 r. W tekście Agentic Programming rozróżnia pracę z agentem pod świadomą kontrolą programisty od podejścia, w którym człowieka przestaje interesować kod będący rezultatem. Dla naszego kursu to ważna granica: delegowanie implementacji nie oznacza rezygnacji ze zrozumienia systemu. Weryfikacja, rozumienie i kierowanie pracą nadal mają znaczenie. [1]

Dlaczego warto przeczytać: pomaga uporządkować pojęcia i nie ogłaszać każdego czatu generującego kod nową metodologią inżynierską.

Addy Osmani, 7 czerwca 2026 r. W Loop Engineering nacisk przesuwa się na organizację powtarzalnej pętli: wykonanie, ocena, zachowanie stanu i następny krok. To bliskie naszej idei dłuższej pracy w ramach kamienia milowego. Artykuł nie mówi jednak, że dowolna liczba autonomicznych cykli jest z definicji dobra. Pętla musi generować weryfikowalny postęp, a koszt zarządzania nią powinien się zwracać. [2]

Dlaczego warto przeczytać: pozwala spojrzeć na automatyzację szerzej niż przez pojedynczy prompt, a jednocześnie zobaczyć koszt źle zaprojektowanej pętli.

Robert Martin i Justin Martin, czerwiec 2026 r. Publiczny opis szóstego odcinka Agentic Discipline pokazuje Swarm Forge: oddzielne etapy definiowania zadania, implementacji, porządkowania, review architektonicznego i kontroli jakości. Otwarty opis daje interesujący przykład rozdzielenia kompetencji inżynierskich między agentów; pełne nagranie jest dostępne osobno. [3]

Dlaczego warto przeczytać: pokazuje, jak dyscyplina inżynierska może zostać zakodowana w konstrukcji procesu agentowego. Nie byłoby poprawne przypisywanie temu materiałowi tezy „zasady clean code nie są już potrzebne”. Podczas przygotowywania artykułu nie udało mi się znaleźć wiarygodnego źródła pierwotnego dla popularnej parafrazy „książka jest nieaktualna”.

Kent Beck, 23 kwietnia 2026 r. — wcześniejsza uwaga. W Nobody Wants Agents opisuje nieprzyjemny efekt: chciał zmienić program, a zamiast tego dostał pracę polegającą na koordynowaniu kilku agentów. To osobisty opis konkretnego doświadczenia, a nie uniwersalny zakaz multi-agent systems. Daje jednak świetne kryterium: narzędzie ma pomagać osiągać rezultat, a nie tworzyć nowy obowiązek obsługi samego siebie. [22]

Dlaczego warto przeczytać: to test zdrowego rozsądku dla wzorca kierownik–wykonawca. Jeśli obciążenie poznawcze rośnie, system trzeba uprościć.

Społeczność nie wypracowała jednego przepisu. I dobrze — jest co badać. Z tych głosów wyłania się jednak produktywne pytanie: nie ile agentów potrafimy uruchomić, ale jaką pracę inżynierską dzięki nim wykonujemy lepiej.

11. Autonomia zwiększa koszt niejasnego zamysłu

Kiedy agent wykonuje małe działanie, człowiek szybko zauważa odchylenie. Kiedy agent dostaje długi odcinek pracy, niejasność początkowego zadania ma czas zamienić się w dużą implementację.

Nie ma jasnego blueprintu? Nie wiadomo, który rezultat jest ważniejszy. Specyfikacja jest rozmyta? Agent sam wypełnia luki. Granice zadania są niewyraźne? Do środka zaczynają wchodzić sąsiednie ulepszenia. Brakuje przykładów i kryteriów? Nie mamy stabilnego sposobu odróżnienia dobrego rezultatu od jedynie wiarygodnie wyglądającego.

Pojawia się wiele dopuszczalnych interpretacji. To nie znaczy, że każda droga jest naprawdę optymalna. To znaczy, że nie daliśmy wystarczających podstaw, by preferować drogę, której oczekujemy, nad pozostałymi.

Schemat 7. Zostawić swobodę implementacji, usunąć niejednoznaczność rezultatu.

>

Niejasny cel → wiele nieporównywalnych interpretacji → trudny odbiór.

>

Jasny cel + granice + przykłady + kontrole → kilka dopuszczalnych implementacji → weryfikowalny wybór.

>

Nie ograniczamy każdego kroku agenta. Ograniczamy wymagane właściwości wyniku i konsekwencje działań.

Dlatego środek ciężkości developmentu się przesuwa. Coraz ważniejsza jest umiejętność opisania aplikacji, zbadania wariantów, przygotowania specyfikacji, dekompozycji pracy, przygotowania kontekstu i zaprojektowania weryfikacji.

Nie zwalnia nas to z nauki języków programowania, algorytmów, baz danych i bezpieczeństwa. Bez tej wiedzy trudno zauważyć, że agent pięknie zrealizował zły pomysł. Zmiana polega na tym, że kompetencja inżynierska ujawnia się już nie tylko w tym, co napisaliście ręcznie, ale także w tym, jaką pracę potrafiliście zdefiniować, ograniczyć i zweryfikować.

Nie zamieniajcie środowiska w więzienie zbudowane z tysiąca instrukcji. Dobre zadanie zostawia wykonawcy swobodę wyboru implementacji — ale nie pozostawia dwuznaczności co do obowiązkowego rezultatu.

12. Mały eksperyment zamiast wielkiej wiary

W praktyce proponuję następujące ćwiczenie. Wybierzcie jedną użyteczną funkcję swojego projektu. Przygotujcie kamień milowy, kilka zadań i przykłady odbioru. Zbudujcie minimalny zestaw instrukcji. Przejdźcie cały cykl — do sprawdzonego rezultatu, a nie do ładnej wiadomości od agenta.

Następnie wybierzcie porównywalne kolejne zadanie i zmieńcie jeden element środowiska: na przykład dodajcie skill sprawdzający braki albo osobnego kierownika. Zapiszcie model, wersję klienta, materiały wejściowe, koszt uruchomień i czas własnego udziału. Porównajcie defekty, poprawki i zaakceptowany rezultat.

Dwa uruchomienia nie dadzą naukowo ścisłego wniosku: zadania się różnią, a zachowanie modeli jest zmienne. Dadzą jednak sensowny punkt startowy. Następnie można powtórzyć eksperyment na kilku podobnych zadaniach i sprawdzić, czy efekt się utrzymuje.

W raporcie studenckim oczekiwałbym trzech rzeczy: działającej funkcji, łańcucha dowodów od wymagania do kontroli oraz krótkiej analizy tego, co trzeba było zmienić w środowisku. Najciekawsze zwykle nie są triumfalne hasła, lecz niespodzianki: gdzie agent zrozumiał zadanie inaczej, który test niczego nie dowodził, która reguła okazała się zbędna.

Przed oddaniem projektu spróbujcie wyjaśnić go osobie, która nie widziała waszego czatu: czego wymagano, gdzie to zrealizowano, dlaczego uważacie wynik za poprawny i czego jeszcze nie sprawdzono.

Jeśli potraficie to zrobić, nie zajmujecie się już tylko generowaniem kodu. Projektujecie pracę. Agent może pomóc wykonać ją szybciej, w szerszym zakresie i — przy dobrze zaprojektowanej weryfikacji — bardziej niezawodnie.

Nauczyć się szybko otrzymywać kod to dobry początek. Nauczyć się doprowadzać cudzą pracę — również maszynową — do zrozumiałego, zaakceptowanego rezultatu jest znacznie ciekawsze.

Źródła i ścieżki dalszej lektury

Linki sprawdzono 15 września 2026 r. Możliwości klientów się zmieniają; przed konfiguracją projektu sprawdźcie dokumentację używanej wersji. Okres „świeżych publikacji” dla tego artykułu to 15 maja — 15 września 2026 r. Starsze materiały oznaczono osobno. Jeśli strona referencyjna nie ma daty publikacji, podana data oznacza datę sprawdzenia.

Jak zmienia się praca programisty

[1] Martin Fowler — Agentic Programming. 21.05.2026. https:/​/​martinfowler.com/​bliki/​AgenticProgramming.html

Dlaczego warto przeczytać: porządkuje różnicę między świadomym delegowaniem a pracą, w której programista przestaje interesować się kodem będącym rezultatem.

[2] Addy Osmani — Loop Engineering. 07.06.2026. https:/​/​addyosmani.com/​blog/​loop-engineering/​

Dlaczego warto przeczytać: proponuje patrzeć na zarządzaną pętlę, a nie na pojedynczy udany prompt.

[3] Robert Martin, Justin Martin — Agentic Discipline 6: Swarm Forge Demonstration. Czerwiec 2026. https:/​/​cleancoders.com/​episode/​agentic-discipline-6

Dlaczego warto przeczytać: publiczny opis pokazuje rozdzielenie kompetencji inżynierskich między agentów. Pełny odcinek jest płatny; wnioski artykułu ograniczają się do opisu publicznego.

Zbudować środowisko pracy

[4] Linear — Project milestones. Dokumentacja. https:/​/​linear.app/​docs/​project-milestones

Dlaczego warto przeczytać: zamienia słowo „kamień milowy” w konkretną strukturę zadań i pomaga nie mylić procentu w interfejsie z odbiorem produktu.

[5] OpenAI — Unrolling the Codex agent loop. 23.01.2026; materiał bazowy. https:/​/​openai.com/​index/​unrolling-the-codex-agent-loop/​

Dlaczego warto przeczytać: wyjaśnia składanie kontekstu oraz granicę między modelem, harnessem i narzędziami w konkretnej implementacji.

[6] OpenAI — Custom instructions with AGENTS.md. Dokumentacja. https:/​/​learn.chatgpt.com/​docs/​agent-configuration/​agents-md

Dlaczego warto przeczytać: pozwala sprawdzić kolejność wykrywania plików, zakres działania i moment ładowania instrukcji zamiast zgadywać na podstawie nazw.

[7] Anthropic — How Claude remembers your project. Dokumentacja. https:/​/​code.claude.com/​docs/​en/​memory

Dlaczego warto przeczytać: wyjaśnia CLAUDE.md, importy, reguły lokalne i różnicę między kontekstem a wymuszanymi ograniczeniami.

[8] Anthropic — How we contain Claude across products. 25.05.2026. https:/​/​www.anthropic.com/​engineering/​how-we-contain-claude

Dlaczego warto przeczytać: przenosi bezpieczeństwo z życzenia „niech agent zachowuje się dobrze” do projektu uprawnień i izolacji.

[9] GitHub — About protected branches. Dokumentacja. https:/​/​docs.github.com/​en/​repositories/​configuring-branches-and-merges-in-your-repository/​managing-protected-branches/​about-protected-branches

Dlaczego warto przeczytać: pomaga technicznie wymusić review i kontrole przed zmianą głównej gałęzi.

[10] OpenAI — Build skills. Dokumentacja. https:/​/​learn.chatgpt.com/​docs/​build-skills

Dlaczego warto przeczytać: pokazuje format SKILL.md, wykrywanie skilli i dołączanie szczegółów tylko wtedy, gdy są potrzebne.

[11] Anthropic — Extend Claude with skills. Dokumentacja. https:/​/​code.claude.com/​docs/​en/​skills

Dlaczego warto przeczytać: pomaga dostosować procedurę do Claude Code bez zakładania pełnej wymienności konfiguracji między platformami.

[12] OpenAI — Subagents. Dokumentacja. https:/​/​learn.chatgpt.com/​docs/​agent-configuration/​subagents

Dlaczego warto przeczytać: wyjaśnia, jak logiczną rolę zamienić w faktycznie skonfigurowanego wyspecjalizowanego agenta.

[13] Anthropic — Create custom subagents. Dokumentacja. https:/​/​code.claude.com/​docs/​en/​sub-agents

Dlaczego warto przeczytać: pomaga zdefiniować osobny kontekst, cel i narzędzia pomocnika; format należy sprawdzać dla używanej wersji klienta.

Automatyzować tylko proces, który rozumiemy

[14] OpenAI — Scheduled tasks. Dokumentacja. https:/​/​learn.chatgpt.com/​docs/​automations?surface=app

Dlaczego warto przeczytać: pokazuje różnice między interfejsami oraz warunki, w których zaplanowana praca faktycznie się wykona.

[15] Anthropic — Run prompts on a schedule. Dokumentacja. https:/​/​code.claude.com/​docs/​en/​scheduled-tasks

Dlaczego warto przeczytać: wyjaśnia /loop, ograniczenia harmonogramu sesyjnego, opóźnienia i zatrzymywanie powtarzalnych uruchomień.

[16] OpenAI — Symphony, oficjalne repozytorium. Engineering preview. https:/​/​github.com/​openai/​symphony

Dlaczego warto przeczytać: daje architektoniczny punkt wyjścia do wykonywania zadań z trackera, a nie obietnicę gotowej fabryki software’u.

[17] OpenAI — Symphony Specification. https:/​/​github.com/​openai/​symphony/​blob/​main/​SPEC.md

Dlaczego warto przeczytać: pozwala przeanalizować stany, workspace’y, ponowienia i kontrakt WORKFLOW.md niezależnie od języka implementacji.

[18] OpenAI — Symphony: przykład WORKFLOW.md. https:/​/​github.com/​openai/​symphony/​blob/​main/​elixir/​WORKFLOW.md

Dlaczego warto przeczytać: pokazuje konkretny workflow do adaptacji; szczególną uwagę warto zwrócić na przejścia, uprawnienia i przekazanie pracy człowiekowi.

Zrozumieć kierunek — bez obietnic magii

[19] OpenAI — Introducing the Agents API. 10.09.2026. https:/​/​openai.com/​index/​introducing-the-agents-api/​

Dlaczego warto przeczytać: świeży przykład tego, jak dużą część długotrwałego wykonania dostawca przenosi do zarządzanej platformy.

[20] OpenAI — Harness engineering: leveraging Codex in an agent-first world. 11.02.2026; materiał bazowy. https:/​/​openai.com/​index/​harness-engineering/​

Dlaczego warto przeczytać: pokazuje, dlaczego struktura repozytorium i pętle feedbacku stają się częścią pracy inżynierskiej z agentami.

[21] Anthropic — Harness design for long-running application development. 24.03.2026; materiał bazowy. https:/​/​www.anthropic.com/​engineering/​harness-design-long-running-apps

Dlaczego warto przeczytać: daje przykład organizacji dłuższej pracy zamiast nieskończonego wydłużania jednego promptu.

[22] Kent Beck — Genie Lessons: Nobody Wants Agents. 23.04.2026; wcześniejsze doświadczenie autora. https:/​/​newsletter.kentbeck.com/​p/​genie-lessons-nobody-wants-agents

Dlaczego warto przeczytać: pomaga zauważyć moment, w którym zarządzanie agentami staje się nowym problemem zamiast rozwiązać stary. Autor informuje, że opisywana sesja była sponsorowana przez Augment Code.

[23] Sergey Avdeichik — Dostaliście odpowiedź. A kto zorganizował pracę? 12.09.2026. https:/​/​dobrovola.dev/​pl/​writing/​from-ai-answers-to-verifiable-work

Dlaczego warto przeczytać: opisuje wcześniejszy etap metodyki — rozmowę, research, blueprint, specyfikację i weryfikowalny rezultat.