Mapa drogi dla organizacji: od pilotaży do agentowego systemu dostarczania

Mapa drogi transformacji dla całej organizacji to 12-miesięczny plan w pięciu etapach, który prowadzi dział inżynierii od rozproszonych pilotaży AI do agentowego systemu dostarczania oprogramowania. Najpierw finansuje zespół platformowy, potem pilotuje nazwane pętle dostarczania, buduje weryfikację przed przyznaniem autonomii i przesuwa każdą pętlę o jeden szczebel drabiny autonomii dopiero wtedy, gdy spełni ona warunki swojej bramki.

Ta strona jest dla członka zarządu, który finansuje zmianę, oraz dla CTO lub VP Engineering, który ją prowadzi. Sytuacja wyjściowa: pół roku temu każdy inżynier dostał licencję, dashboardy użycia wyglądają na zajęte, a nikt nie potrafi powiedzieć, czy dostarczanie stało się szybsze, tańsze czy bardziej ryzykowne. Jedne zespoły pozwalają agentom scalać zmiany w nocy, inne ich zakazują, a rada nadzorcza chce planu z datami na następny kwartał.

Co daje ci ta mapa transformacji

Plan na 12 miesięcy w pięciu etapach, z właścicielem i bramką wyjścia dla każdego etapu
Tabelę bramek stop/go zapisanych jako przejścia na drabinie dla każdej pętli (od L1 → L2 do L4 → L5), z dowodami wymaganymi na każdym przejściu
Szablon rejestru pętli, który zespół platformowy może zacommitować jeszcze dziś
Metrykę poziomu organizacji: rozkład scalonych zmian między szczeblami drabiny
Ustawienia warstwy kontroli dla Claude Code, Codex i Cursora
Dwa prompty do skopiowania, które zbierają dowody dla bramek z twoich własnych pull requestów

Dlaczego rozdanie licencji to jeszcze nie transformacja

Zakup licencji zmienia to, kto pisze kod. Nie zmienia sposobu, w jaki zmianę się specyfikuje, weryfikuje i wydaje, więc system dostarczania pozostaje taki, jaki był. Raport DORA 2025 (Google Cloud, 23 września 2025) nazywa to ryzyko wprost: „AI doesn’t fix a team; it amplifies what’s already there. Strong teams use AI to become even better and more efficient. Struggling teams will find that AI only highlights and intensifies their existing problems.”

Telemetria mówi to samo. Raport Faros AI z kwietnia 2026, oparty na dwóch latach danych od 22 000 programistów, pokazał przepustowość i jakość idące w przeciwnych kierunkach: liczba ukończonych epików na programistę wzrosła o 66,2%, a jednocześnie liczba incydentów na pull request wzrosła o 242,7%, a mediana czasu w review o 441,5%. DX zmierzył wzrost mediany rozmiaru pull requesta z 44 do 72 linii między lipcem 2025 a czerwcem 2026 (DX, 17 czerwca 2026). Generowanie się przeskalowało, weryfikacja nie.

Dowody na szybkość pojedynczego programisty są słabsze, niż sugerują prezentacje dostawców. Randomizowane badanie METR z 2025 roku wykazało, że doświadczeni programiści z AI potrzebowali o 19% więcej czasu; kontynuacja z 2026 roku dała estymaty punktowe na korzyść AI, ale z przedziałami przechodzącymi przez zero, a samo METR nazywa nowe dane niewiarygodnym sygnałem. Badanie Microsoftu dotyczące wdrożenia Claude Code i GitHub Copilot CLI na początku 2026 roku (arXiv, lipiec 2026) zmierzyło u użytkowników około 24% więcej scalonych pull requestów, z zastrzeżeniem samych autorów: „a merged PR is not the same as the value it delivers”.

Dlatego mapa poniżej przeznacza dwa pierwsze etapy na to, co samo się nie skaluje: wspólny harness, pomiar i weryfikację. Autonomia przychodzi później, pętla po pętli, na podstawie dowodów. Datowane źródła tych liczb zebrano na stronie o stanie inżynierii agentowej.

Czym jest pętla i jak mierzyć poziom organizacji

Pętla to jeden powtarzalny rodzaj zmiany w jednej bazie kodu, z jednym właścicielem: aktualizacje zależności w payments-api, poprawki błędów UI w aplikacji webowej, nowe endpointy w API dla partnerów. Drabina autonomii ocenia pętle, a nie ludzi czy firmy, bo ten sam zespół może bezpiecznie prowadzić aktualizacje zależności na L4, a zmiany w rozliczeniach trzymać na L3.

Poziom organizacji jest więc rozkładem, a nie jedną liczbą. Raportuj go jako udział scalonych zmian na każdym szczeblu, łącznie dla wszystkich zarejestrowanych pętli:

Szczebel	Kto czyta co	Udział scalonych zmian (przykład, miesiąc 0)	Przykład, miesiąc 12
L1–L2	Człowiek czyta każdą linię w trakcie pisania	70%	25%
L3	Agent pracuje bez nadzoru; człowiek czyta każdy diff	30%	45%
L4	Człowiek czyta specyfikację, testy i dowody, nie diff	0%	28%
L5	Nikt nie czyta kodu; decydują wyrocznia testowa i mechanizmy wydania	0%	2%

Te procenty ilustrują kształt rozkładu, nie są celem ani benchmarkiem. Twoje cele wynikają z twojego rejestru pętli. Strona jedna mapa definiuje szczeble, etapy cyklu życia i stacje fabryki w jednej siatce, a czytanie dowodów zamiast kodu wyjaśnia, co zastępuje diff na L4.

Plan na 12 miesięcy w jednej tabeli

Etap	Miesiące	Cel	Odpowiada	Bramka wyjścia (go)
0. Mandat i punkt odniesienia	0–1	Wskazać sponsora, pętle i obecne liczby	Sponsor z zarządu, CTO	Punkt odniesienia dla każdej pętli pilotażowej; podpisany budżet i reguła stopu
1. Platforma i pierwsze pętle	1–3	Uruchomić wspólny harness; przeprowadzić trzy do pięciu pętli z L1–L2 na L3	Lider platformy	Pętle pilotażowe przechodzą bramkę L2 → L3; polityka zarządzana na każdej licencji
2. Weryfikacja przed autonomią	3–6	Chronione testy, pakiety dowodów, review przez agenta; pierwsze pętle na L4	CTO, właściciele pętli	Co najmniej jedna pętla niskiego ryzyka przechodzi bramkę L3 → L4 przez 30 dni
3. Skalowanie pętla po pętli	6–9	Zarejestrować pętle każdego zespołu; rozwinąć harness; zacząć przenoszenie zaufania	Lider platformy, tech leadzi	Większość aktywnych repozytoriów ma zarejestrowane pętle; żadna bramka nie została pominięta
4. Eksploatacja systemu	9–12	Kwartalne przeglądy bramek, raport dla rady, L5 tylko tam, gdzie pozwala wyrocznia	CTO, sponsor z zarządu	Koszt zaakceptowanej zmiany i odsetek nieudanych zmian na poziomie punktu odniesienia lub lepiej

Każdy etap ma okno kalendarzowe, ale kończy się na bramce wyjścia, nigdy na dacie. Etap, który nie przeszedł bramki, trwa dalej, a raport dla rady mówi o tym otwarcie.

Jak przeprowadzić każdy etap

Etap 0 — mandat i punkt odniesienia (miesiąc 0–1). Sponsor z zarządu pisze jednoakapitowe stanowisko wobec AI: co agenci mogą robić, co zostaje po stronie ludzi i że plan zatrzyma pętle, które nie przejdą bramek. DORA wymienia „clear and communicated AI stance” jako pierwszą zdolność w swoim AI Capabilities Model (Google Cloud, 23 września 2025). CTO wybiera następnie trzy do pięciu pętli pilotażowych, zapisuje ich punkt odniesienia metodą z pilotażu, który czegoś dowodzi i wpisuje pełny koszt, łącznie z review i poprawkami, do business case’u. Wyjście: każda pętla pilotażowa ma zapisane co najmniej pięć porównywalnych historycznych zmian.
Etap 1 — platforma i pierwsze pętle (miesiące 1–3). Sfinansuj mały zespół platformowy, na początek dwóch lub trzech inżynierów, którego produktem jest harness: ustawienia zarządzane, wspólne reguły i skille, bramki CI, tożsamości agentów i telemetria. Raport DORA 2025 podaje, że 90% organizacji wdrożyło co najmniej jedną platformę i że istnieje „a direct correlation between a high quality internal platform and an organization’s ability to unlock the value of AI”. Pętle pilotażowe przechodzą na tym harnessie z L1–L2 na L3, repozytorium po repozytorium, według mapy wdrożenia dla jednego repozytorium. Statut zespołu opisuje strona o zespole platformowym agentów, a model operacyjny mówi, kto odpowiada za którą kontrolę.
Etap 2 — weryfikacja przed autonomią (miesiące 3–6). Zanim jakakolwiek pętla opuści L3, jej testy muszą być wyrocznią, której agent nie może po cichu przepisać. Zbuduj siłę wyroczni, ochroń wyrocznię, wymagaj pakietu dowodów przy każdym pull requeście i dodaj review PR przez agenta. Dopiero wtedy przenieś jedną pętlę niskiego ryzyka na L4. Opublikowany opis agentów Stripe’a pokazuje ten wzorzec: działają na „over three million” istniejących testów i dostają „at most two rounds of CI”, zanim gałąź wróci do człowieka (Stripe, 9 i 19 lutego 2026).
Etap 3 — skalowanie pętla po pętli (miesiące 6–9). Każdy zespół rejestruje swoje pętle w tym samym rejestrze i dziedziczy harness platformy. Tech leadzi prowadzą protokół przenoszenia zaufania (review w cieniu, potem review próbkowe, potem same dowody) dla pętli zbliżających się do L4. Zarządzanie przechodzi z notatek do mechanizmów: jedna polityka zarządzana dla wszystkich narzędzi, tożsamości i sekrety agentów, kontrola kosztów, a przy działalności w UE obowiązki z AI Act. Stronę ludzką opisuje przewodzenie zmianie.
Etap 4 — eksploatacja systemu (miesiące 9–12). CTO prowadzi kwartalny przegląd bramek każdej pętli (awans, utrzymanie albo cofnięcie o jeden szczebel) i raportuje rozkład szczebli, koszt zaakceptowanej zmiany oraz trend incydentów według szablonu raportu dla rady. L5 wchodzi w grę tylko dla pętli niskiego ryzyka, których wyrocznia, progresywne wdrażanie i automatyczny rollback wytrzymały pełny kwartał. Plan na drugi rok powstaje z rejestru, a nie z premier dostawców.

Bramki stop/go jako przejścia na drabinie dla każdej pętli

Bramka to dowody, które pętla musi pokazać, zanim wejdzie o jeden szczebel wyżej. Pętle wchodzą po jednym szczeblu; żadna nie przeskakuje z L2 na L4. Właściciel pętli zbiera dowody, wskazana osoba zatwierdza, a sygnał stopu automatycznie cofa pętlę o jeden szczebel.

Przejście	Go: dowody wejścia dla tej pętli	Stop: cofnij o szczebel, gdy	Podpisuje
L1 → L2 (praca w parze)	Polityka zarządzana na każdej licencji; wspólny plik reguł w repozytorium; sekrety poza zasięgiem agenta; inżynierowie przeszkoleni na tej pętli	Sekret lub produkcyjne poświadczenie pojawia się w sesji albo transkrypcie agenta	Lider platformy
L2 → L3 (agent bez nadzoru, człowiek czyta każdy diff)	Agent uruchamia typecheck, lint i testy przed otwarciem pull requesta; odsetek CI zielonego za pierwszym razem na poziomie punktu odniesienia lub wyżej; czas do pierwszego review w ramach SLA zespołu	Mediana czasu w review lub rozmiar pull requesta rośnie przez cztery tygodnie; odsetek nieudanych zmian powyżej punktu odniesienia	Właściciel pętli (tech lead)
L3 → L4 (człowiek czyta specyfikację i dowody, nie diff)	Kryteria akceptacji są wykonywalne; pliki testów chronione przed edycją przez agenta; pakiet dowodów przy każdym pull requeście przez 30 dni; próbkowe review 20 zmian przez człowieka nie znajduje defektu, który przeoczyły dowody; rollback przećwiczony	Jakikolwiek defekt, który uciekł na produkcję i pochodzi z tej pętli; jakakolwiek edycja chronionych testów przez agenta; brak pakietu dowodów przy scalonej zmianie	CTO lub osoba przez niego wskazana oraz właściciel usługi
L4 → L5 (nikt nie czyta kodu)	Niska klasa ryzyka; wyrocznia należy do kogoś innego niż operator agenta; progresywne wdrażanie z automatycznym rollbackiem; pełny kwartał na L4 z odsetkiem nieudanych zmian na poziomie punktu odniesienia lub niżej	Jakikolwiek incydent o wysokim priorytecie wynikający z nieprzeczytanej zmiany	CTO, z akceptacją bezpieczeństwa

Progi w tabeli, na przykład 30 dni i 20 zmian w próbce, to wartości startowe do dopasowania, a nie wyniki badań. Wpisz własne do rejestru przed startem pętli, bo próg wybrany po poznaniu wyników niczego nie dowodzi. Kanoniczne definicje odsetka nieudanych zmian, czasu realizacji i miar specyficznych dla AI znajdziesz na stronie o frameworkach metryk.

Rejestr pętli: mapa drogi jako plik

Mapa drogi żyje jako jeden plik w repozytorium należącym do zespołu platformowego i przechodzi review jak kod. Każdy wpis jest też pozycją portfela w rozumieniu mapy narzędzi AI: hipotezą z właścicielem, budżetem i bramką stopu.

# loop-register.yaml — one entry per loop; reviewed quarterly
- id: payments-api/dependency-updates
  owner: tech-lead-payments          # accountable for the gate evidence
  risk_class: low                     # low | medium | high | critical
  current_rung: L3
  target_rung: L4                     # never more than one rung above current
  target_by: 2027-03-31
  entry_evidence:
    - acceptance checks run in CI on every pull request
    - test files protected; agent edits need the label oracle-change
    - evidence bundle attached to every merged PR for 30 days
    - 20 sampled human reviews with no defect the evidence missed
  stop_signals:
    - any escaped defect traced to this loop
    - change-fail rate above baseline for two consecutive weeks
  rollback_rung: L3
  metrics: [cost_per_accepted_change, lead_time, change_fail_rate, time_in_review]
  baseline: { lead_time_days: 3.1, change_fail_rate: 0.04 }
  next_review: 2026-12-15

Pole baseline przechowuje twoje własne zmierzone wartości; te powyżej to tylko wypełniacze. Zamień tech-lead-payments na imię i nazwisko konkretnej osoby, a nie alias zespołu, żeby każda bramka miała jeden odpowiedzialny podpis.

Kto co zatwierdza

Decyzja	Sponsor z zarządu	CTO / VP Eng	Lider platformy	Właściciel pętli	Bezpieczeństwo	Finanse
Stanowisko wobec AI i budżet na 12 miesięcy	Odpowiada (A)	Wykonuje (R)	Konsultowany	Informowany	Konsultowane	Konsultowane
Rejestr pętli i klasy ryzyka	Informowany	Odpowiada (A)	Wykonuje (R)	Wykonuje (R)	Konsultowane	—
Bramka L2 → L3	—	Informowany	Konsultowany	Odpowiada (A)	—	—
Bramki L3 → L4 i L4 → L5	Informowany	Odpowiada (A)	Konsultowany	Wykonuje (R)	Konsultowane	—
Zatrzymanie pętli lub całego programu	Odpowiada (A)	Wykonuje (R)	Konsultowany	Konsultowany	Konsultowane	Konsultowane

Sygnał stopu może zgłosić każdy z tabeli. Zatrzymaną pętlę może wznowić tylko rola oznaczona jako odpowiedzialna (A).

Skonfiguruj warstwę kontroli w każdym narzędziu

Pierwszym produktem zespołu platformowego w etapie 1 jest polityka, którą dostaje każda licencja i której żaden użytkownik nie może nadpisać. Mechanizm różni się między narzędziami; bramki powyżej już nie. Strona o jednej polityce dla wszystkich agentów kodujących porównuje wszystkie trzy w jednej tabeli.

Claude Code czyta plik managed-settings.json wdrożony w systemowej lokalizacji ustawień, przez MDM albo jako ustawienia zarządzane z serwera, z konsoli administracyjnej Claude w planach Team i Enterprise. Klucze do zarządzania modelami to między innymi availableModels, enforceAvailableModels i maxEffortLevel. Minimalna polityka na etap 1 ogranicza modele i trzyma sekrety poza zasięgiem:

{
  "availableModels": ["opus", "sonnet"],
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  }
}

Dla pętli bez nadzoru na L3 i wyżej uruchamiaj agenta w CI przez anthropics/claude-code-action@v1 albo headless przez claude -p z limitem wydatków, na przykład --max-budget-usd 5. Dashboard analityczny (Team i Enterprise) dostarcza danych o użyciu, ale nie o efektach; połącz go samodzielnie z metrykami pull requestów. Sprawdzone w Claude Code v2.1.283 26 września 2026.

Codex oddziela wartości domyślne od ograniczeń: config.toml przechowuje ustawienia, które użytkownik może zmienić, a administracyjny requirements.toml ograniczenia, których użytkownik nie nadpisze. Minimalny zestaw ograniczeń na etap 1:

# requirements.toml — admin-enforced
allowed_sandbox_modes = ["read-only", "workspace-write"]
allowed_approval_policies = ["untrusted", "on-request"]
allow_managed_hooks_only = true

Jeśli Twoje stanowiska używają profili uprawnień (beta) zamiast starszych trybów sandboxa, ogranicz je kluczem permission_profile w tym samym pliku.

allow_managed_hooks_only = true sprawia, że Codex ignoruje hooki użytkownika, projektu i sesji, więc działają wyłącznie hooki zespołu platformowego. Dla pętli bez nadzoru używaj openai/codex-action@v1 w CI albo codex exec z --output-schema, żeby każde uruchomienie zwracało dowody w formie czytelnej maszynowo. Nazwy kluczy sprawdzone w kodzie źródłowym openai/codex i w CLI 0.157.1 26 września 2026.

Wspólne mechanizmy kontroli w Cursorze to Rules, Hooks (JSON przez stdio) i Plugins, które pakują razem reguły, skille, serwery MCP i hooki. Na potrzeby bramek dowodowych Cursor oferuje Bugbota do review pull requestów oraz PR Routing & Approval, a jego CLI działa headless w GitHub Actions z flagą -p. Pętle bez nadzoru obsługują Cloud Agents i Automations (wyzwalacze: harmonogram, kontrola wersji, Slack, webhook, Linear, Sentry, PagerDuty). Te funkcje sprawdzono w dokumentacji Cursora 28 sierpnia 2026.

Ta strona nie omawia organizacyjnych kontroli administracyjnych Cursora (listy dozwolonych modeli, wymuszanie trybu prywatności, analityka per zespół); potwierdź je w konsoli administracyjnej Cursora, zanim obiecasz je w bramce etapu 1.

Prompty, które zbierają dowody dla bramek

Kwartalny przegląd bramek powinien opierać się na dowodach zebranych przez agenta z repozytorium, a nie na slajdzie ze statusem. Oba prompty działają w Claude Code, Codex i agencie Cursora z uwierzytelnionym GitHub CLI (gh).

Prepare the quarterly stop/go review for the loop "payments-api/dependency-updates".
Read its entry in loop-register.yaml first: current rung, target rung, entry evidence,
stop signals and baseline.

Use the GitHub CLI to collect the last 50 merged pull requests labelled
loop:dependency-updates:
  gh pr list --state merged --label loop:dependency-updates --limit 50 \
    --json number,title,createdAt,mergedAt,additions,deletions,reviews,files

For each PR, compute lead time (created to merged), size (additions + deletions),
review rounds, whether it touched any file under tests/ and whether a later PR reverted it.

Then report, as a Markdown table, each entry-evidence item and each stop signal from the
register with: met / not met / unknown, and the PR numbers that prove it.
End with one recommendation: advance one rung, hold, or roll back one rung, and why.
Do not edit any file. Write "unknown" for anything you cannot compute; never estimate.

Read loop-register.yaml and audit every entry. Flag each loop where:
- the owner is a team alias rather than a named person;
- target_rung is more than one rung above current_rung;
- an entry-evidence item cannot be checked by a machine or a named person;
- stop_signals or rollback_rung is missing;
- risk_class is high or critical and target_rung is L4 or L5;
- next_review is more than 90 days from today or already past.
Output one table: loop id, violation, suggested fix. Then give the current distribution
of loops by current_rung. Do not modify the file.

Skąd wiesz, że mapa drogi działa

Deklaracje o szybkości się nie liczą, jeśli nie utrzymała się jakość. Sprawdzaj te cztery sygnały na każdym kwartalnym przeglądzie, a zysk na dwóch pierwszych przy stracie na dwóch ostatnich traktuj jako porażkę, nie kompromis:

Koszt zaakceptowanej zmiany: licencje, zużycie, CI, czas review, poprawki i koszt incydentów podzielone przez liczbę scalonych zmian, których nie wycofano. Definicję i przykład liczbowy podaje strona o ekonomii oprogramowania budowanego przez agentów.
Czas realizacji od zaakceptowanej specyfikacji do produkcji, dla każdej pętli.
Odsetek nieudanych zmian i defekty, które uciekły na produkcję, dla każdej pętli, w porównaniu z punktem odniesienia z etapu 0.
Czas w review i rozmiar pull requesta, czyli dwie miary, które w danych Faros i DX wzrosły najwyraźniej.

„Procent kodu napisanego przez AI”, liczba licencji i promptów dziennie to aktywność, a nie efekty. Mogą trafić do aneksu, ale nigdy nie decydują o bramce. Bramki opierają się na samej weryfikacji, a nie na człowieku czytającym każdy diff: wykonywalnych kryteriach akceptacji, chronionych testach, pakiecie dowodów i review przez agenta, przy czym każdy szczebel podpisuje konkretna osoba.

Co wykoleja wdrożenie w całej organizacji?

Licencje rozdane, zanim powstał harness. Objaw: użycie rośnie, czas realizacji stoi w miejscu, a każdy zespół konfiguruje agenta inaczej. Naprawa: wstrzymaj przydzielanie nowych licencji, uruchom zespół platformowy, wdróż politykę zarządzaną i zarejestruj pętle, zanim dasz więcej dostępu.

Pilotaż niczego nie dowodzi. Objaw: pilotaż dotyczył poprawek literówek i ochotników, a wynikiem jest ankieta zadowolenia. Naprawa: powtórz go na pętlach istotnych dla produkcji, z punktem odniesienia i regułą decyzji zapisaną z góry, jak opisuje projekt pilotażu.

Autonomia przychodzi przed weryfikacją. Objaw: przepustowość rośnie, a razem z nią incydenty na zmianę i czas review, czyli wzorzec z danych Faros. Naprawa: cofnij dotknięte pętle o jeden szczebel i nie stosuj ponownie bramki L3 → L4, dopóki testy nie są chronione, a pakiet dowodów obowiązkowy.

Zespół platformowy staje się wąskim gardłem. Objaw: każda nowa pętla czeka tygodniami na przegląd platformy. Naprawa: opublikuj dowody bramek jako samoobsługową checklistę; zespół platformowy odpowiada za harness, a nie za zatwierdzanie każdej pętli.

Bramki przechodzą według kalendarza. Objaw: nadchodzi data etapu 2 i pętle awansują, bo „plan mówi o szóstym miesiącu”. Naprawa: raport dla rady pokazuje status etapów według bramek, a etap, który nie przeszedł bramki, jest raportowany jako przedłużony, nie zakończony.

Review staje się nową kolejką. Objaw: agenci otwierają więcej i większych pull requestów, niż recenzenci są w stanie przeczytać. Naprawa: ogranicz rozmiar pull requesta dla każdej pętli, kieruj zmiany według klasy ryzyka i przeprowadzaj kwalifikujące się pętle przez przenoszenie zaufania, zamiast dokładać recenzentów.

Niezarządzani agenci działają poza rejestrem. Objaw: zespół uruchamia nocnego agenta na prywatnym tokenie. Naprawa: unieważnij token, nadaj pętli tożsamość usługową i zarejestruj ją na L3, dopóki nie zasłuży na swoją bramkę.

Dokąd dalej po mapie transformacji

Mapa wdrożenia dla jednego repozytorium Wycinek tego planu na poziomie repozytorium, prowadzony przez tech leada.

Pilotaż, który czegoś dowodzi Punkty odniesienia, kohorty i reguła decyzji dla pętli pilotażowych z etapu 0.

Model operacyjny Kto odpowiada za harness, bramki i ewaluacje.

Raportowanie inżynierii AI zarządowi i radzie nadzorczej Kwartalny raport na jedną stronę zasilany z rejestru pętli.

Jak zmieniają się zespoły, role i zatrudnienie Jak wygląda organizacja, gdy pętle dochodzą do L4.

Mapa narzędzi AI Szablon pozycji portfela dla każdego zakładu na mapie drogi.