Jak utrzymać zespół na bieżąco, gdy narzędzia zmieniają się co tydzień

Utrzymanie zespołu na bieżąco z agentami AI do kodowania wymaga trzech rutyn: rotacyjnego, cotygodniowego dyżuru, który dzieli nowości na zmiany łamiące (breaking changes), zmiany domyślnych, kandydatów i szum; ścieżki, która wpuszcza nową funkcję do wspólnego harnessu dopiero po ocenionym pilotażu; oraz dokumentacji, w której każdy fakt o narzędziu ma wersję, kanał i datę sprawdzenia.

Claude Code opublikował 52 wydania między 4 sierpnia a 25 września 2026, a Codex 21 między 7 sierpnia a 26 września (rejestr npm, odczyt 26 września 2026). W tych samych tygodniach Codex usunął codex exec --full-auto, Claude Code zmienił model domyślny, a na kanale latest Claude Code rozszerzył auto mode jako startowy tryb uprawnień na każdy plan i każdego dostawcę. AGENTS.md twojego zespołu nadal każe używać flagi, której już nie ma, dwie osoby są na innym kanale wydań niż CI, a jedyna osoba, która to zauważyła, przesłała dalej link do changelogu. Ta strona jest dla tech leada, który musi zamienić to w rutynę zajmującą godzinę tygodniowo.

Co daje zespołowi dyżur nad wydaniami

Grafik dyżurów z limitem 45 minut, stałą listą źródeł dla każdego narzędzia i plikiem podsumowania, który czyta cały zespół.
Tabelę z czterema klasami zmian, która mówi, co zrobić z każdą zmianą i do kiedy.
Ścieżkę wdrażania z rejestrem decyzji, która nie wpuszcza odkrycia jednego entuzjasty do wspólnego harnessu, dopóki nie przejdzie pilotażu.
Przypinanie wersji w każdym narzędziu, żeby programiści i CI używali wersji, którą przetestowałeś.
Konwencję datowania zespołowej dokumentacji, wzorowaną na tym, jak ta strona datuje własne fakty, oraz dwa testy w CI, które padają, gdy fakt jest przeterminowany albo wycofana flaga nadal jest w użyciu.
Trzy prompty do skopiowania: przegląd wydań z tygodnia, projekt pilotażu i audyt harnessu pod kątem dryfu.

Jak szybko zmieniają się narzędzia agentowe?

Tempo dobrze widać na pięciu dniach roboczych od 21 do 25 września 2026:

Data	Narzędzie i wersja	Zmiana	Co to znaczyło dla zespołu
2026-09-22	Claude Code v2.1.280 (`latest`)	Claude Opus 5.5 został modelem domyślnym na każdym płatnym planie	Zmienił się koszt i zachowanie każdej sesji na ustawieniach domyślnych; ewaluacje na starym modelu przestały opisywać narzędzie
2026-09-23	Claude Code v2.1.281 (`latest`)	Czytanie `AGENTS.md`, gdy projekt nie ma `CLAUDE.md`, także na Bedrock, Google Cloud, Foundry i bramkach	Sesje Claude Code u tych dostawców zaczęły czytać instrukcje z repozytorium, które ma tylko `AGENTS.md`
2026-09-23	Codex CLI 0.156.1	GPT-6 Sol i GPT-6 Luna w wyborze modelu	Tańsza opcja do pilotażu na rutynowych pętlach; bez zmian dla kogoś, kto nic nie robi
2026-09-25	Claude Code v2.1.283 (`latest`)	Auto mode stał się startowym trybem uprawnień w interaktywnych sesjach w terminalu i VS Code na każdym planie i u każdego dostawcy	Sesje Enterprise, API i u dostawców chmurowych (Pro/Max/Team już od 14 sierpnia) startowały w auto mode, o ile ustawienia go nie wyłączają; `claude -p` i nieobsługiwane modele nadal startują w trybie Manual

26 września 2026 kanał stable Claude Code był wciąż na v2.1.274 (dist-tagi npm), więc żaden z trzech wierszy o Claude Code nie dotyczył zespołu na stable. Ten rozjazd to pierwsza rzecz, którą dyżur musi kontrolować. Aktualna lista modeli i ceny są w przeglądzie modeli; ta strona odsyła tam zamiast je powtarzać.

Ustaw grafik dyżurów nad wydaniami

Co tydzień dyżur ma jedna wskazana osoba, a dyżury rotują w zespole. Rotacja rozkłada wiedzę na cały zespół i przetrwa urlopy.

Wyznacz dyżurnego i termin. Jedna osoba na tydzień, w stałym 45-minutowym okienku w poniedziałek rano, wpisanym do planu sprintu jako zadanie. Przy pierwszych dwóch dyżurach juniora dołącz do niego seniora.
Ustal listę źródeł. Dyżurny czyta tylko źródła z tabeli poniżej, od przypiętej wersji zespołu do najnowszego wydania.
Zaklasyfikuj każdą zmianę do jednej z czterech klas z następnej sekcji. Wszystko, co niejasne, trafia do kandydatów z pytaniem, a nie do szumu.
Napisz podsumowanie w docs/agents/release-watch/<rok>-W<tydzień>.md w repozytorium i otwórz pull request. Podsumowanie jest krótkie: zmiany łamiące, zmiany domyślnych, kandydaci i jedna linijka z liczbą pozycji szumu.
Przekaż dalej. Każda zmiana łamiąca dostaje właściciela i datę naprawy, zanim skończy się okienko. Kandydaci idą do tech leada, który wybiera najwyżej jednego na dwa tygodnie do pilotażu.

Źródło	Co czytać	Jak czytać
Claude Code	Changelog i wersje na kanałach	`npm view @anthropic-ai/claude-code dist-tags` w terminalu; `/release-notes` w sesji
Codex	Wydania `openai/codex` na GitHubie i wbudowany katalog modeli	`npm view @openai/codex version`; `codex features list`; `codex debug models --bundled`
Cursor	Changelog Cursora	Przeglądarka; zapisz datę, do której przeczytałeś, a nie wersję
Modele	Wycofywanie modeli Claude i katalog Codeksa wyżej	Każda data wycofania w ciągu najbliższych 90 dni to zmiana łamiąca
Standardy	Blog MCP (wpis o wydaniu specyfikacji 2026-07-28)	Tylko gdy wychodzi nowa wersja specyfikacji; zobacz co zmieniło się w MCP 2026-07-28

Przeczytaj zmiany z tygodnia w każdym narzędziu

Porównuj to, co narzędzie mówi o sobie samo, zamiast ufać streszczeniom: zapisz migawkę jego interfejsu, gdy przypinasz wersję, a potem porównaj z nią nową wersję.

# Terminal: which versions are on each channel today
npm view @anthropic-ai/claude-code dist-tags

# Snapshot the flags and subcommands of the pinned version, then diff after an upgrade
claude --version > docs/agents/snapshots/claude-version.txt
claude --help > docs/agents/snapshots/claude-help.txt
# after upgrading on the watcher's machine only:
claude --help | diff docs/agents/snapshots/claude-help.txt - || true

W sesji polecenie /release-notes pokazuje notatki z ostatnich wersji. Czytaj wszystkie wpisy między przypiętą wersją zespołu a docelową, nie tylko najnowszy — Claude Code wydaje mniej więcej jedną wersję dziennie.

# Terminal: current release and the feature flags of this binary
npm view @openai/codex version
codex --version > docs/agents/snapshots/codex-version.txt
codex features list > docs/agents/snapshots/codex-features.txt
codex debug models --bundled | jq -r '.models[] | "\(.slug) \(.visibility)"' \
  > docs/agents/snapshots/codex-models.txt
# after upgrading on the watcher's machine only:
codex features list | diff docs/agents/snapshots/codex-features.txt - || true

codex features list wypisuje każdą flagę funkcji z jej etapem (under development, experimental, stable, deprecated albo removed) i informacją, czy jest włączona. Flaga, która przechodzi do stable, to kandydat; flaga ustawiana w waszej konfiguracji, która przechodzi do deprecated, trafia do podsumowania jako zmiana łamiąca z terminem na przyszły miesiąc; taka, która przechodzi do removed, to zmiana łamiąca już teraz. Wbudowany katalog to nie wszystko: od Codex CLI 0.154.0 nowe sesje używają domyślnego modelu z serwera, chyba że ustawisz go sam, więc model może się zmienić bez żadnego wydania Codeksa.

You are this week's release watcher for our team. Do not edit any file except
the digest you create.
1. Read our pinned versions from docs/agents/snapshots/claude-version.txt and
   docs/agents/snapshots/codex-version.txt.
2. Read the release notes from those versions up to the newest release:
   the Claude Code changelog at https://code.claude.com/docs/en/changelog.md
   and the GitHub releases of openai/codex. Run
   `npm view @anthropic-ai/claude-code dist-tags` and
   `npm view @openai/codex version` to get the newest versions.
3. Read our shared agent files: CLAUDE.md, AGENTS.md, .claude/settings.json,
   .codex/config.toml, .github/workflows/*.yml and docs/agents/*.md.
4. Classify every change as BREAK (removes or renames something our files
   use), DEFAULT SHIFT (changes a default model, permission mode, instruction
   file or pricing behaviour), CANDIDATE (a capability that could replace
   something we do by hand) or NOISE.
5. For each BREAK, quote the line in our files it affects, with file and line
   number, and the replacement named in the release notes.
6. Write docs/agents/release-watch/<ISO year>-W<ISO week>.md with sections
   Breaks, Default shifts, Candidates and a one-line noise count. Link each
   item to its release note. Mark anything you could not confirm from the
   release notes as "unconfirmed" instead of guessing.

Zaklasyfikuj każdą zmianę do jednej z czterech klas

Klasa decyduje o terminie. Bez niej każda zmiana jest tak samo pilna, czyli w praktyce żadna.

Klasa	Kryterium	Działanie	Termin i właściciel
Zmiana łamiąca	Usuwa lub zmienia nazwę flagi, polecenia, ustawienia, modelu albo pliku, którego używa nasz harness	Pull request z poprawką harnessu; stary termin trafia na listę wycofanych	Zanim ktokolwiek zaktualizuje; dyżurny, review tech leada
Zmiana domyślnych	Zmienia domyślne ustawienie, na którym polega zespół: model, effort, tryb uprawnień, plik instrukcji, sandbox	Uruchom zestaw ewaluacyjny zespołu na nowej wersji, zanim przesuniesz przypięcie; powiedz zespołowi, co się dla nich zmienia	Zanim przypięcie się przesunie; decyduje tech lead
Kandydat	Nowa możliwość, która może zastąpić ręczną pracę albo domowy skrypt	Zapisz; tech lead wybiera najwyżej jednego na dwa tygodnie do pilotażu	Najbliższe okienko na pilotaż; ochotnik
Szum	Poprawki i funkcje, które nie dotykają niczego, czego używa zespół	Policz w podsumowaniu	Brak

Zespoły najczęściej przegapiają zmiany domyślnych, bo nic nie pada. Gdy Codex 4 września 2026 (CLI 0.153.4) ustawił GPT-6 Astra jako wbudowany model domyślny, zespół, którego config.toml nie ustawiał modelu, dostał inny model w dniu aktualizacji. Testy przeszły; koszt i zachowanie się zmieniły. Traktuj zmianę domyślnych jak zmianę, którą zespół robi celowo: najpierw ewaluacje, potem przesunięcie przypięcia. Przypadek nowego modelu szczegółowo opisuje procedura wdrażania nowego modelu.

Wprowadź funkcję do wspólnego harnessu

Wspólny harness to wszystko, w czym działają agenci zespołu: pliki instrukcji, ustawienia, hooki, skille, pluginy i serwery MCP zapisane w repozytorium albo w polityce zarządzanej centralnie. Warstwy opisuje przegląd harnessu. Funkcja trafia do harnessu tylko ścieżką opisaną niżej, bo zmiana harnessu zmienia agenta każdej osoby w zespole naraz.

Zauważona. Dyżurny zapisuje funkcję jako kandydata w podsumowaniu, z notatką z wydania i minimalną wersją, której wymaga.
Pilotaż. Jeden ochotnik używa funkcji na jednej pętli przez najwyżej dwa tygodnie, w worktree albo gałęzi, w normalnym trybie uprawnień zespołu. Przed startem zapisuje hipotezę i ewaluację: które niedawne zadania albo katy uruchomi ponownie i jaki wynik uzna za lepszy. Decyduje wynik ewaluacji, a nie wrażenie ochotnika.
Pull request do harnessu. Jeśli pilotaż wypadł dobrze, ochotnik otwiera jeden pull request, który dodaje funkcję do wspólnego harnessu: linię w CLAUDE.md albo AGENTS.md, klucz w .claude/settings.json albo .codex/config.toml, skill albo plugin w zespołowym marketplace. Pull request zawiera rejestr decyzji poniżej, próg wersji („wymaga Claude Code v2.1.283 lub nowszego, kanał latest”) i jednolinijkowe wycofanie. CODEOWNERS na ścieżkach harnessu kieruje go do tech leada.
Pokaż. Ochotnik poświęca funkcji 10 minut na najbliższej sesji review nastawionej na naukę z programu rozwoju kompetencji zespołu. Funkcja, której nikt inny nie umie użyć, nie została wdrożona.
Przegląd po 90 dniach. Rejestr decyzji ma datę przeglądu. Tego dnia właściciel zostawia, zmienia albo wycofuje funkcję i zapisuje decyzję w podsumowaniu.

Rejestr decyzji trzymaj w opisie pull requestu i w docs/agents/decisions/:

feature: "GPT-6 Sol for the dependency-bump loop in Codex"
observed_in: "docs/agents/release-watch/2026-W39.md"
needs: "Codex CLI 0.156.1 or later"
hypothesis: "Sol passes the same dependency-bump evals as the default model at lower usage"
trial:
  owner: "m.wisniewska"
  loop: "weekly dependency bumps, services/billing"
  window: "2026-09-28 to 2026-10-09"
  eval: "re-run the last 8 merged dependency-bump tickets; hidden tests must pass on all 8"
  result: "8 of 8 passed; review findings unchanged"   # filled in at the end of the trial
decision: adopt            # adopt | reject | extend-trial
harness_change: ".github/workflows/deps.yml: codex exec -m gpt-6-sol"
rollback: "remove -m gpt-6-sol from the deps job"
approved_by: "tech-lead-billing"
review_on: 2027-01-09

Our release watch logged this candidate feature:
<paste the digest entry and the release-note link>
Design a two-week trial that a single volunteer can run on one loop.
1. Name the loop in this repository where the feature is most likely to
   help, based on git history of the last 90 days. Prefer a loop with tests
   that decide success.
2. Write a falsifiable hypothesis in one sentence.
3. Pick 5 to 8 recently merged tickets on that loop to re-run as the eval,
   list them by pull request number, and say what result counts as better,
   the same, or worse. Use test outcomes, review findings and rework, not
   impressions.
4. List the settings or files the trial changes, and confirm none of them is
   shared by the rest of the team.
5. Fill in a decision record in the format of
   docs/agents/decisions/*.yaml, leaving result and decision empty.
Do not change the team's permission mode, sandbox or managed settings for
the trial.

Funkcja, której zespół nie może wyłączyć jedną linijką, w ogóle nie trafia do harnessu. Odrzucone i przedłużone pilotaże tech leada zasilają zakłady technologiczne organizacji w mapie drogowej narzędzi AI.

Przypnij wersje, żeby zespół i CI używały tego, co przetestowałeś

Wdrożenie funkcji niewiele znaczy, jeśli połowa zespołu ma inną wersję. Przypnij wersję, na której przeszedł zestaw ewaluacyjny, wszędzie, i przesuwaj przypięcie świadomie.

Claude Code ma dwa kanały wydań. latest dostaje każde wydanie; stable jest „zwykle około tygodnia w tyle” i pomija wydania z poważnymi regresjami (dokumentacja instalacji Claude Code, sprawdzone 26 września 2026). Wybierz jeden dla całego zespołu.

{
  "autoUpdatesChannel": "stable",
  "requiredMinimumVersion": "2.1.274"
}

Umieść to w managed settings, a nie w ustawieniach użytkownika każdej osoby, żeby obowiązywało wszystkich; dystrybucję opisuje strona o jednej polityce dla wszystkich agentów. Schemat ustawień w Claude Code 2.1.283 opisuje requiredMinimumVersion i requiredMaximumVersion jako egzekwowane wyłącznie z managed settings: wersja spoza zakresu kończy działanie przy starcie z instrukcją instalacji zatwierdzonej wersji. requiredMinimumVersion zatrzymuje tylko maszyny, które zostały w tyle; dodaj też requiredMaximumVersion, jeśli chcesz, żeby automatyczne aktualizacje zatrzymały się na wersji, na której przeszły ewaluacje; wtedy każde przesunięcie przypięcia jest zmianą w managed settings.

Na pojedynczej maszynie claude install stable albo claude install 2.1.274 instaluje kanał albo dokładną wersję. W CI instaluj dokładnie tę wersję, którą przypiął zespół, na przykład npm install -g @anthropic-ai/claude-code@2.1.274 dla powyższego przypięcia do stable, i przypnij model ustawieniem model, jeśli od niego zależą twoje ewaluacje.

Codex nie ma kanału stable: tag npm latest wskazywał 26 września 2026 wersję 0.157.1, a wersje przedpremierowe wychodzą pod osobnym tagiem alpha (tego dnia 0.159.0-alpha.9), którego nikt w zespole nie powinien instalować. Przypnij dokładną wersję na maszynach programistów i w CI i przesuwaj ją dopiero, gdy zestaw ewaluacyjny przejdzie na nowej:

# Terminal and CI: install the version the team tested
npm install -g @openai/codex@0.157.1
codex --version   # codex-cli 0.157.1

codex update przenosi maszynę na najnowszą wersję, więc to polecenie dla maszyny dyżurnego, a nie zespołu. Ponieważ nowe sesje używają domyślnego modelu z serwera, chyba że ustawisz go sam (CLI 0.154.0 i nowsze), ustaw model w zespołowym .codex/config.toml albo w nazwanym profilu dla każdej pętli, której ewaluacje zależą od konkretnego modelu. Ograniczenia administracyjne w requirements.toml kontrolują polityki zatwierdzania, sandboksy i serwery MCP; w pliku binarnym Codex 0.157.1 nie znaleźliśmy ustawienia minimalnej ani maksymalnej wersji (sprawdzone 26 września 2026), więc wersję egzekwuj narzędziami instalacyjnymi.

Cursor to edytor, który aktualizuje się sam, a ta strona nie mogła zweryfikować ustawienia Cursora do przypinania ani opóźniania aktualizacji (cursor.com niedostępny 26 września 2026). Traktuj Cursora tak, jakby działał na latest: jego changelog czytasz co tydzień, a zmiany domyślnych w Cursorze idą od razu do etapu ewaluacji, zamiast czekać na przesunięcie przypięcia. Użycie skryptowe przez @cursor/sdk (1.0.32 w npm na 26 września 2026) przypinasz w package.json.

Datuj zespołową dokumentację agentów tak, jak robi to ta strona

Ta strona trzyma każdą nazwę modelu, cenę, ustawienie domyślne i flagę w jednym arkuszu faktów, a każdy wiersz ma źródło i datę sprawdzenia. Cztery zasady z tego arkusza przenoszą się wprost do zespołowej dokumentacji agentów:

Każdy fakt ma datę sprawdzenia i źródło. Fakt jest prawdziwy tylko w dniu sprawdzenia.
Każde twierdzenie zależne od wersji podaje wersję i kanał. Pisz „od v2.1.283 (kanał latest)”, nigdy „Claude Code teraz…”.
Każde twierdzenie przeczące podaje wersję, na której je sprawdzono. Pisz „Codex CLI 0.157.1 nie ma flagi --full-auto (sprawdzone 26 września 2026)”, nigdy „Codex nie ma --full-auto”.
Wycofane terminy trafiają na listę zakazanych razem z tym, co je zastępuje, żeby nieaktualną instrukcję wyłapała maszyna, a nie zdezorientowana nowa osoba w zespole.

W repozytorium zespołu zasady 1–3 stają się jedną tabelą, a zasada 4 jednym plikiem tekstowym. Tabelę trzymaj w docs/agents/tool-facts.md:

| Fact | Tool and version | Source | Checked | Re-check by |
| --- | --- | --- | --- | --- |
| Default model is Claude Opus 5.5 on paid plans and the Anthropic API (not Foundry) | Claude Code v2.1.280+ (`latest`) | https://code.claude.com/docs/en/model-config.md | 2026-09-26 | 2026-10-26 |
| `-a` accepts only `on-request` and `never` | Codex CLI 0.157.1 | `codex --help` | 2026-09-26 | 2026-10-26 |
| Team pin: Claude Code `stable`, Codex 0.157.1 | Team decision | docs/agents/decisions/ | 2026-09-26 | 2026-10-26 |

Listę zakazanych terminów trzymaj w docs/agents/retired-terms.txt, jedno rozszerzone wyrażenie regularne na linię, z komentarzem, co je zastępuje:

# One extended regex per line. The comment above each says what replaces it,
# since which version, and when the team checked it.
# Codex: `codex exec --full-auto` removed in 0.147.0 (2026-08-07); use a permission profile.
--full-auto
# Codex: cannot run as an MCP server since 0.154.0 (2026-09-09); use codex exec or the Codex SDK.
codex mcp-server
# Codex: -a accepts only on-request and never (checked on 0.157.1, 2026-09-26).
(-a|--ask-for-approval)[ =](on-failure|untrusted)
# Claude Code: /ultraplan left the command reference in v2.1.222; use /plan.
/ultraplan
# Cursor: Background Agents are now Cloud Agents (name checked 2026-08-28).
Background Agents?

Dwa skrypty zamieniają oba pliki w bramki. Pierwszy pada, gdy wspólny plik agenta nadal używa wycofanego terminu:

#!/usr/bin/env bash
# Fails when a shared agent file still uses a term the team has retired.
set -euo pipefail
terms=docs/agents/retired-terms.txt
mapfile -t files < <(git ls-files -- '*CLAUDE.md' '*AGENTS.md' '.claude/*' '.codex/*' '.cursor/*' '.github/workflows/*')
[ "${#files[@]}" -eq 0 ] && exit 0
if grep -nE -f <(grep -vE '^[[:space:]]*(#|$)' "$terms") -- "${files[@]}"; then
  echo "Retired agent terms found. See $terms for what replaces each one." >&2
  exit 1
fi
echo "No retired agent terms in ${#files[@]} shared agent files."

Drugi pada, gdy fakt jest po terminie ponownej weryfikacji:

// Fails when a row in docs/agents/tool-facts.md is past its re-check date.
import { readFileSync } from 'node:fs';

const today = new Date().toISOString().slice(0, 10);
const rows = readFileSync('docs/agents/tool-facts.md', 'utf8')
  .split('\n')
  .filter((line) => /^\|.*\|\s*\d{4}-\d{2}-\d{2}\s*\|\s*$/.test(line));

const stale = rows.filter((line) => {
  const cells = line.split('|').map((c) => c.trim()).filter(Boolean);
  return cells.at(-1) < today; // last column: Re-check by (ISO dates compare as strings)
});

for (const line of stale) console.error(`STALE: ${line}`);
console.log(`${rows.length} dated facts, ${stale.length} past their re-check date.`);
process.exit(stale.length ? 1 : 0);

Uruchamiaj oba przy każdym pull requeście i raz w tygodniu przed dyżurem, z tokenem tylko do odczytu:

name: harness-freshness
on:
  pull_request:
  schedule:
    - cron: '17 6 * * 1' # Mondays 06:17 UTC, before the release watch
permissions:
  contents: read
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - run: bash scripts/check-harness-drift.sh
      - run: node scripts/check-tool-facts.mjs

Najważniejsze jest uruchomienie z harmonogramu: fakt wygasa w konkretnym dniu, a nie przy commicie, więc poniedziałkowy błąd trafia prosto w okienko dyżurnego.

Audit our shared agent files for undated or stale tool facts. Do not change
any file; report only.
Files: CLAUDE.md, AGENTS.md (all of them), .claude/settings.json,
.codex/config.toml, docs/agents/*.md.
1. List every sentence that states a tool fact: a model name, a default, a
   flag, a command, a setting key, a version or a price.
2. For each, say whether it has a version, a release channel (for Claude
   Code) and a checked date nearby, and whether it appears in
   docs/agents/tool-facts.md.
3. Flag every negative claim ("X has no Y", "X does not support Y") that
   does not name the version it was checked against.
4. Run `claude --version`, `codex --version`, `claude --help` and
   `codex --help`, and flag any flag or command in our files that does not
   appear in the help output of the installed version.
5. Output a Markdown table: file, line, fact, missing stamp, suggested
   tool-facts.md row. Mark anything you could not check as "unchecked".

Skąd wiesz, że dyżur nad wydaniami działa?

Te miary pokazują, czy rutyna cokolwiek zmienia, i każda ma właściciela.

Miara	Definicja	Cel i właściciel
Czas naprawy zmiany łamiącej	Dni od daty wydania ze zmianą łamiącą do scalonej poprawki harnessu, dla wydań nowszych niż przypięcie zespołu	Poprawka przed przesunięciem przypięcia, za każdym razem; dyżurny z danego tygodnia
Nieplanowane zmiany łamiące	Zmiany łamiące, które zespół odkrył przez błąd, a nie z podsumowania	Zero na kwartał; tech lead omawia je na retrospektywie
Błędy bramek dryfu	Błędy `check-harness-drift.sh` i `check-tool-facts.mjs` w poniedziałkowym uruchomieniu	Naprawione w okienku dyżuru; dyżurny
Skuteczność pilotaży	Odsetek pilotaży w kwartale zakończonych rejestrem decyzji z wynikiem ewaluacji	Każdy pilotaż; pilotaż bez wyniku to pilotaż nieudany, a nie zaliczony
Rozjazd wersji	Osoby lub zadania CI na innym kanale Claude Code albo innej wersji Codeksa niż przypięcie zespołu, z wyników `claude --version` i `codex --version` zebranych podczas dyżuru	Zero; tech lead

Podpisy są stałe. Dyżurny podpisuje podsumowanie. Tech lead zatwierdza każdy pull request do harnessu, każde przesunięcie przypięcia i każdą decyzję o zmianie domyślnych. Właściciel platformy albo CTO zatwierdza wszystko, co zmienia politykę zarządzaną centralnie dla więcej niż jednego zespołu; tę granicę wyznacza model operacyjny.

Jak to odpowiada na pytanie scorecardu tech leada o bycie na bieżąco?

Pytanie 21 w scorecardzie tech leada dotyczy tego, jak utrzymujesz zespół na bieżąco, gdy narzędzia się zmieniają, a najwyżej punktowana odpowiedź to „przypisany radar + sandbox + decyzje o wdrożeniu”. Na tej stronie dyżur to przypisany radar, dwutygodniowy pilotaż to sandbox, a klasy zmian, przypięcia i rejestry decyzji to decyzje o wdrożeniu.

Co się psuje, gdy zespół próbuje być na bieżąco

Dyżur zamienia się w przesyłanie changelogów. Dyżurny wkleja linki na kanał zespołu i nikt nic z nimi nie robi. Aby to naprawić, wymagaj pliku podsumowania w pull requeście oraz właściciela i daty dla każdej zmiany łamiącej przed końcem okienka.

Automatyczna aktualizacja psuje CI we wtorek. Zadanie CI instaluje najnowsze CLI, używana flaga zniknęła i każde zadanie agenta pada. Aby to naprawić, przypnij dokładną wersję w CI, dodaj flagę do retired-terms.txt i przesuwaj przypięcie w CI tylko w tym samym pull requeście, który przesuwa przypięcie zespołu.

Połowa zespołu jest na innym kanale. Część osób zainstalowała z kanału latest, a część przez menedżer pakietów, który śledzi stable. 26 września 2026 oznaczało to, że jedna grupa miała Opus 5.5 jako model domyślny i czytała AGENTS.md, a druga używała Opus 5 albo Sonnet 5 i ignorowała AGENTS.md; na stanowiskach Enterprise, API i u dostawców chmurowych tylko grupa na latest startowała w auto mode. Wyniki review przestają być porównywalne. Aby to naprawić, ustaw autoUpdatesChannel i requiredMinimumVersion w managed settings i co tydzień sprawdzaj rozjazd wersji.

Zmiana domyślnych przechodzi niezauważona. Nic nie pada, ale po aktualizacji albo zmianie domyślnego modelu po stronie serwera zmienia się koszt lub zachowanie. Aby to naprawić, uruchamiaj zestaw ewaluacyjny przy każdym przesunięciu przypięcia i ustawiaj model jawnie dla każdej pętli, której ewaluacje od niego zależą.

Entuzjasta scala funkcję prosto do wspólnego harnessu. Nowy hook albo skill ląduje w .claude/, bo raz zadziałał jednej osobie. Aby to naprawić, dodaj CODEOWNERS na ścieżkach harnessu, wróć do ostatniego zatwierdzonego stanu i przepuść funkcję przez pilotaż. Poprzeczkę review dla każdego typu opisują strony o zarządzaniu wspólnymi hookami i wspólnych skillach.

Dyżury się rozmywają. Po dwóch urlopach i jednym terminie nikt od miesiąca nie przeczytał changelogu. Aby to naprawić, trzymaj dyżur jako zadanie w sprincie z imiennym właścicielem, pozwól poniedziałkowemu check-tool-facts.mjs głośno paść i nadrabiaj, czytając od przypiętej wersji do przodu, a nie przeglądając tylko ostatni tydzień.

Dokąd dalej, jeśli chcesz utrzymać zespół na bieżąco

Podnoszenie kompetencji zespołu w inżynierii agentowej Program i sesje review nastawione na naukę, na których pokazuje się wdrożoną funkcję.

Wspólne reguły agentów: jeden rdzeń, przetestowane adaptery Jak zbudowane i testowane są pliki instrukcji, które zmienia wdrożenie funkcji.

Jedna polityka dla wszystkich agentów do kodowania Managed settings, które niosą przypięcie wersji i wybór modeli zespołu.

Wdrażanie nowego modelu bez psucia pętli Procedura z ewaluacjami na pierwszym miejscu dla zmian domyślnych, które znajduje dyżur.

Dzielenie się wiedzą: wersjonuj dowody, nie triki Gdzie trzymać wyniki pilotaży i rejestry decyzji, żeby przetrwały osobę, która je prowadziła.

Ścieżka tech leada Ścieżka czytania, do której należy ta strona.

Najczęstsze pytania

Jak zespół ma nadążać za narzędziami AI, które wychodzą co tydzień?

Jedna osoba, zmieniana co tydzień, ma ograniczony czasowo dyżur nad wydaniami. Czyta changelog każdego narzędzia od przypiętej wersji, dzieli nowości na zmiany łamiące (breaking changes), zmiany domyślnych, kandydatów i szum, i pisze krótkie podsumowanie. Zmiany łamiące naprawia się w tym samym tygodniu, a kandydaci trafiają do wspólnego harnessu dopiero po pilotażu.

Jak nowa funkcja agenta trafia do wspólnej konfiguracji zespołu?

Przez pięć etapów: zauważona w podsumowaniu, sprawdzona w pilotażu przez jednego ochotnika na jednej pętli na zestawie ewaluacyjnym zespołu, dodana do wspólnego harnessu w przejrzanym pull requeście z progiem wersji i jednolinijkowym wycofaniem, pokazana na najbliższej sesji review i oceniona ponownie po 90 dniach.

Czy zespół powinien używać kanału stable czy latest Claude Code?

Wybierz jeden i przypnij go wszystkim, łącznie z CI. 26 września 2026 kanał latest miał wersję v2.1.283, a stable v2.1.274, i kilka zachowań (Opus 5.5 jako model domyślny, czytanie AGENTS.md oraz auto mode jako tryb startowy na stanowiskach Enterprise, API i u dostawców chmurowych) istniało tylko na latest. Zespół na dwóch kanałach pracuje z dwoma różnymi agentami.

Jak nie dopuścić, żeby zespołowa dokumentacja agentów się zestarzała?

Każdy fakt o narzędziu oznacz wersją, kanałem i datą sprawdzenia, daj każdemu wierszowi datę ponownej weryfikacji i uruchom w CI dwa testy: jeden pada, gdy fakt jest po terminie weryfikacji, drugi, gdy wspólny plik agenta nadal używa flagi lub polecenia, które zespół wycofał.