Termin "context engineering" krąży po LinkedIn od miesięcy: posty formatowane jako ponumerowane listy ze strzałkami, motywujący język o ustrukturyzowanych przepływach pracy z AI. Wygląda na wypełniacz.

A potem pojawia się Get Shit Done: 52k gwiazdek na GitHubie, 4 400 forków, 473 punkty na Hacker News po premierze w marcu 2026, wydanie v1.35.0 dwa dni temu. Cokolwiek robi marketingowa warstwa, popyt pod spodem jest realny.

Problem, który rozwiązuje

Zespół inżynierski Anthropic opublikował bezpośrednie wyjaśnienie we wrześniu 2025: w miarę jak okno kontekstu LLM się zapełnia, jakość modelu spada. Nazywają to "context rot", czyli gnicie kontekstu. Architektura transformera traktuje każdy token jako powiązany z każdym innym tokenem, więc im więcej tokenów wciśniesz, tym bardziej rozmywa się budżet uwagi. Okno kontekstu o rozmiarze 200k tokenów to nie 200k tokenów równie dobrego rozumowania.

Każdy, kto używał Claude Code lub Cursora na projekcie dłużej niż kilka godzin, widział to na własne oczy. Agent zaprzecza decyzjom, które podjął wcześniej. Gubi wymagania, które potwierdził dwie fazy temu. Sugeruje zmiany, które psują rzeczy, które już naprawił.

Odpowiedź GSD: każde zadanie w planie budowy dostaje własne, świeże okno kontekstu.

Jak to wygląda w praktyce

npx get-shit-done-cc@latest

Działa na 14 środowiskach uruchomieniowych w wersji v1.35.0, w tym Claude Code, Gemini CLI, Cursor, Copilot, Windsurf i dziewięciu innych (Cline, CodeBuddy, Qwen Code, OpenCode, Kilo, Codex, Antigravity, Augment, Trae).

Gwoli pełnej uczciwości: pracuję nad sąsiadującą warstwą tego problemu w PromptScript, gdzie pojedyncze źródło .prs kompiluje się do natywnych plików instrukcji dla 38+ agentów, więc te same standardy projektu trafiają do CLAUDE.md, AGENTS.md, .cursorrules i reszty bez forka per środowisko. Inna warstwa stosu niż GSD, ale fan-out na wiele runtime'ów rozpoznaję od razu z drugiej strony. Opiszę ten kontrast w osobnym artykule.

Przepływ pracy składa się z sześciu faz:

/gsd-new-project       przechwytuje wizję, wymagania, roadmapę
/gsd-discuss-phase N   wyciąga decyzje projektowe przed budowaniem
/gsd-plan-phase N      generuje atomowe plany zadań w formacie XML
/gsd-execute-phase N   wykonuje zadania w falach, świeży kontekst per zadanie
/gsd-verify-work N     testuje wyniki, generuje plany naprawcze przy błędach
/gsd-ship N            atomowe commity git, tworzenie PR

Faza 4 to miejsce, gdzie dzieje się praca strukturalna. "Wykonanie falowe" oznacza, że niezależne zadania uruchamiają się równolegle, każde z czystym oknem kontekstu. Zadania zależne czekają. Stan persystuje przez restarty kontekstu dzięki plikom PROJECT.md, REQUIREMENTS.md, STATE.md, a od wersji v1.34.0 katalogowi .planning/intel/ z ustrukturyzowaną inteligencją kodu w formacie JSON. Agent nie musi odkrywać na nowo tego, co już wie. Czyta pliki.

v1.35.0 (11 kwietnia 2026) dodaje Cline, CodeBuddy i Qwen Code do listy wspieranych środowisk, kreator wyboru frameworka AI i ponad 25 poprawek błędów obejmujących bezpieczeństwo worktree i integralność plików.

Krytyka warta przytoczenia

GSD zebrał 473 punkty na HN, ale najcelniejszy komentarz z dyskusji na GitHubie ujmuje sedno wprost: "GSD is a highly overengineered piece of software that unfortunately does not get shit done, burns limits and takes ages while doing so."

Inny komentujący w wątku o konfiguracji Claude Code wrócił do zwykłego promptowania po tym, jak GSD stworzył "iluzję" struktury bez proporcjonalnych rezultatów. Trzecia osoba nazwała go "nieco przeprojektowanym", przyznając jednocześnie, że zawiera "ziarno dobrego pomysłu."

To ziarno jest prawdziwe. Inżynieria wokół niego jest jednak ciężka: sześć faz z komendami, zadania w formacie XML, kilka plików stanu, bramki pilnujące driftu schematu, bezpieczeństwa i zakresu. Na weekendowy projekt: za dużo. Dla czegoś z więcej niż trzema fazami i kilkoma agentami działającymi równolegle prawdopodobnie się opłaca.

Lista otwartych zgłoszeń potwierdza, że to jeszcze niedopracowany produkt: problemy z rozwiązywaniem ścieżek w WSL i Dockerze, błędy uprawnień przy świeżych instalacjach, bug pętli konfiguracji przy niektórych kombinacjach środowisk. Maintainer aktywnie triażuje, ale szorstkie krawędzie są widoczne.

Co zmieniło się w kwietniu

v1.34.0 wprowadził globalny magazyn wiedzy: informacje z jednego projektu persystują i można je odpytywać w przyszłych projektach. v1.34.2 obniżył wymagania Node.js z 24 z powrotem do 22 (LTS do października 2026), co po cichu psuło instalacje. v1.35.0 dodał kreator wyboru frameworka, który pyta o używane środowisko przed konfiguracją, naprawiając poprzednią sytuację, w której trzeba było znać właściwą nazwę pakietu dla każdego edytora.

Tempo wydań (pięć wersji w ciągu ośmiu dni, 4-11 kwietnia) sugeruje albo bardzo aktywny projekt, albo bardzo niestabilny. Prawdopodobnie jedno i drugie.

Źródła: Repozytorium GitHub, Blog inżynierski Anthropic, Dyskusja na HN