Roadmapa toolingu AI — szablon pozycji portfela zakładów o nowe zdolności

Pozycja roadmapy toolingu AI to jeden sfinansowany zakład o nową zdolność (capability): ograniczenie dostarczania w nazwanej pętli, falsyfikowalna hipoteza, budżet liczony w pełnym koszcie, metryki ochronne (guardrails) i bramka stop, która w wyznaczonym dniu przeglądu rozstrzyga: awans, kontynuacja, zawężenie albo stop. Takie pozycje są warstwą narzędziową mapy transformacji organizacji, a nie drugą roadmapą obok niej.

Ta strona jest dla CTO lub VP Engineering, który odpowiedział na pytanie Q24 w CTO Scorecard („Czy masz roadmapę AI tooling na 6–12 miesięcy?”) i chce dostać najwyższą ocenę. Typowa sytuacja: na slajdzie z roadmapą widnieje „Q1 rollout Cursora, Q2 ocena zadań w chmurze Codex, Q3 MCP do Jiry”, zarząd pyta, co dały pierwsze dwie pozycje, i nikt nie umie wskazać, którą linię zatrzymać. Ta strona daje szablon, który naprawia każdą linię; plan, do którego te linie należą, to mapa transformacji.

Co daje ci portfel toolingu

• Szablon pozycji portfela w YAML, który zespół platformowy może zacommitować jeszcze dziś
• Tabelę decyzji: awans, kontynuacja, zawężenie i stop, wraz z tym, co każda z nich zmienia
• Listę kontrolną wygaszania, żeby zatrzymany zakład nie zostawił aktywnych poświadczeń
• Trzy prompty do skopiowania: szkic pozycji, audyt portfela i przygotowanie przeglądu bramki
• Tabelę luk dla Q24: jaką odpowiedź dałeś i jaki jeden krok prowadzi do następnej

Jak portfel toolingu wpisuje się w mapę transformacji?

Mapa transformacji przesuwa pętle w górę drabiny autonomii, po jednym szczeblu, i zapisuje je w rejestrze pętli. Pętla to jeden powtarzalny rodzaj zmiany w jednym repozytorium, z jednym właścicielem, na przykład poprawki błędów UI w aplikacji webowej. Zakład o tooling istnieje tylko po to, żeby zarejestrowana pętla przeszła swoją następną bramkę. Każda pozycja portfela wskazuje więc pętlę, której służy, i przejście, które odblokowuje, na przykład web-app/ui-bug-fixes, L3 → L4.

Już ta zasada eliminuje większość zakupów narzędzi „na zapas”. „Ocenić nowego agenta” bez pętli i bez bramki to nie pozycja portfela, tylko ciekawość. Jej miejsce jest w piaskownicy z limitem czasu, w procesie wyjątków z polityki narzędzi.

Artefakt	Odpowiada na pytanie	Właściciel	Gdzie żyje
Mapa transformacji	Na jakim etapie jest organizacja i które pętle wchodzą wyżej?	CTO, sponsor w zarządzie	Mapa transformacji
Rejestr pętli	Na którym szczeblu jest każda pętla i jakie dowody ją przesuną?	Lider platformy, właściciele pętli	loop-register.yaml
Portfel toolingu (ta strona)	Jaką zdolność kupujemy, budujemy lub testujemy, żeby odblokować bramkę, i kiedy przestajemy?	CTO, jeden właściciel na pozycję	tooling-portfolio.yaml
Business case	Czy cały program jest wart finansowania?	CTO, finanse	Business case

Czego brakuje każdej odpowiedzi na Q24?

Q24 należy do sekcji Strategia i ROI w CTO Scorecard. Znajdź swoją odpowiedź i uzupełnij lukę z jej wiersza. Każdy wiersz to jeden krok.

Twoja odpowiedź	Punkty	Czego brakuje	Następny krok
Nie — reagujemy	0	Jakakolwiek lista zamierzonych zdolności	Spisz ograniczenia, które blokują następne bramki twoich pętli pilotażowych; każde z nich to kandydat na pozycję
Backlog „jak znajdziemy czas”	1	Właściciel, budżet i termin przeglądu	Przepisz każdą linię backlogu na szablon poniżej; usuń linie, które nie wskazują pętli
Roadmapa istnieje, owner jest, kwartalne review	2	Hipotezy, mierzalne kryteria awansu i stop, jawny budżet	Dodaj do każdej pozycji hypothesis, decision_rule i budget, podpisane przed startem testu
Roadmapa z ownerem, hipotezami capability, mierzalnymi kryteriami awansu i stop, kwartalnym review oraz jawnym budżetem	3	Nic dla Q24; pilnuj, żeby pozostała uczciwa	Na każdym przeglądzie pokazuj zatrzymane pozycje i łącz każdą pozycję z rejestrem pętli

Szablon pozycji portfela

Jeden plik, którego właścicielem jest zespół platformowy, przeglądany jak kod. Każdy wpis to jeden zakład. Przykład sprawdza, czy dowody z przeglądarki zebrane przez serwer Playwright MCP (@playwright/mcp, wersja 0.0.82 w npm, sprawdzone 2026-09-26) pozwolą pętli UI zrezygnować z review diffu linia po linii.

# tooling-portfolio.yaml — one entry per capability bet; reviewed quarterly
- id: browser-evidence-for-ui-fixes
  owner: jane.doe                      # one named person, never a team alias
  serves_loop: web-app/ui-bug-fixes    # must exist in loop-register.yaml
  unblocks: L3 -> L4                   # the gate this bet helps the loop pass
  constraint: >
    UI fixes wait for a human to click through the change; median time in
    review is the loop's largest delay.
  hypothesis: >
    If the agent attaches a browser trace and screenshots of every acceptance
    scenario to the evidence bundle, reviewers can approve on evidence and
    accepted lead time falls without more escaped UI defects.
  capability: browser verification (Playwright MCP in CI and local sessions)
  scope: { repos: [web-app, admin-ui], risk_class: low, window_weeks: 6 }
  outcome_metric: accepted_lead_time_median
  guardrails: [escaped_ui_defects, revert_rate, time_in_review, data_policy_events]
  budget:                              # full cost, see strategy/economics
    licenses_usd: 0
    usage_usd_cap: 1500
    ci_minutes_cap: 20000
    setup_and_review_hours: 60
    exit_hours: 8
  decision_rule: >
    Graduate if median accepted lead time is at least 20% below the loop's
    baseline over 30 merged changes and no guardrail is worse than baseline.
    Stop if any guardrail is worse for two consecutive weekly checks or the
    usage cap is reached before week 4. Otherwise narrow or continue once.
  signed_before_start: 2026-10-01
  exit_plan: remove MCP config and CI job, revoke test-account credentials, keep traces
  status: trial                        # candidate | trial | graduated | narrowed | stopped
  next_review: 2026-11-15

Progi (20%, 30 zmian, dwa kolejne cotygodniowe pomiary) to wartości startowe do dopasowania, a nie wyniki badań. Ustal je na podstawie bazowej wartości i zmienności własnej pętli, korzystając z projektowania pilotażu, i podpisz, zanim okno testu się otworzy: próg zapisany po poznaniu wyników niczego nie dowodzi.

Co musi zawierać każde pole i kiedy odrzucić pozycję

Pole	Zawiera	Odrzuć pozycję, gdy
serves_loop, unblocks	Identyfikator pętli z rejestru i jedno przejście na drabinie	Pętla nie jest zarejestrowana albo pozycja przeskakuje szczebel
constraint	Opóźnienie, awarię lub koszt widoczny w danych o dostarczaniu	Źródłem jest premiera dostawcy albo demo
hypothesis	Zmianę jednej metryki wyniku spowodowaną przez jedną zdolność	Nazywa narzędzie, ale nie mierzalną zmianę
guardrails	Miary jakości, bezpieczeństwa i danych, które nie mogą się pogorszyć	Wymienia tylko miary szybkości lub użycia
budget	Licencje, użycie, CI, czas wdrożenia i review oraz pracę przy wyjściu	Wypełniona jest tylko linia licencji
decision_rule	Progi awansu i stopu z datą sprzed startu	Brakuje progów albo mają datę późniejszą niż start testu
exit_plan	Co unieważnić, usunąć i zachować, jeśli zakład zostanie zatrzymany	Brzmi „n/d”

Składniki kosztu są zgodne z kosztem zaakceptowanej zmiany, więc pozycja portfela i dowody ROI całego programu używają jednej definicji. Definicje metryk pochodzą z frameworków metryk.

Jak poprowadzić jeden zakład od kandydata do decyzji

1. Zacznij od rejestru pętli. Wybierz pętle, których następna bramka jest zablokowana. Opisz blokujące ograniczenie na podstawie danych o dostarczaniu: kolejek review, nieudanych przebiegów CI, incydentów, trudności w onboardingu i kosztów. Ogłoszenie dostawcy może podsunąć zdolność, ale nigdy nie jest ograniczeniem.

2. Ustal ewaluację, zanim wybierzesz narzędzie. Najpierw zapisz hypothesis, outcome_metric, guardrails i decision_rule. Dopiero potem porównuj kandydujące narzędzia względem tego kontraktu. Narzędzia mogą się zmienić w trakcie okna testu; kontrakt decyzyjny się nie zmienia.

3. Policz budżet całego eksperymentu. Uwzględnij przegląd bezpieczeństwa i prawny proporcjonalny do danych, których dotyka narzędzie (kwestionariusz zakupowy), integrację, szkolenia, pomiar i pracę przy wyjściu. Ustaw twardy limit wydatków na użycie dla każdej pozycji.

4. Podpisz i zarejestruj. Właściciel pozycji, właściciel pętli i CTO podpisują wpis przez przejrzany pull request do tooling-portfolio.yaml. Data scalenia jest dowodem dla pola signed_before_start.

5. Przeglądaj według kalendarza i wyzwalaczy. Przeglądaj każdą pozycję na kwartalnym przeglądzie bramek, a wcześniej, gdy zmieniają się ceny, warunki, trasa danych, istotna zdolność albo ryzyko. Zapisz decyzję i dowody we wpisie.

6. Wykonaj decyzję w tym samym tygodniu. Awansuj, zawęź albo zatrzymaj według tabeli poniżej. Decyzja zapisana, ale niewykonana, zostawia pozycję, która ma status stopped, a nadal generuje koszty.

Awans, kontynuacja, zawężenie czy stop: która decyzja obowiązuje?

Dowody na przeglądzie	Decyzja	Co się zmienia
Wynik osiągnął próg, każda metryka ochronna na poziomie bazowym lub lepszym	Awans	Zespół platformowy przejmuje odpowiedzialność operacyjną; polityka narzędzi wpisuje narzędzie jako domyślne; dochodzą kontrole, wsparcie i kryterium wygaszenia; rejestr pętli odnotowuje nową zdolność
Wynik osiągnięty częściowo, metryki ochronne utrzymane, próbka za mała	Kontynuacja, jeden raz	Przedłuż okno jeden raz z tymi samymi progami; druga „kontynuacja” oznacza stop
Wynik osiągnięty tylko w jednym repozytorium lub jednej klasie ryzyka	Zawężenie	Przepisz zakres na to, gdzie zadziałało; otwórz nowe okno z nową regułą decyzyjną
Metryka ochronna pogorszona dwa razy, limit użycia wyczerpany za wcześnie albo brak mierzalnej zmiany	Stop	Przejdź listę kontrolną wygaszania; zapisz powód; zachowaj dowody

Zdrowy portfel pokazuje zatrzymane pozycje. Jeśli każdy zakład awansuje, progi są za luźne albo przegląd nie czyta dowodów.

Wygaś zatrzymany zakład tak, żeby nic nie zostało aktywne

• Unieważnij klucze API, konta usługowe, uprawnienia OAuth i poświadczenia kont testowych utworzone na potrzeby pozycji
• Usuń wpisy serwerów MCP, zadania CI, hooki, pluginy i wyjątki w ustawieniach zarządzanych
• Anuluj licencje lub zobowiązania na użycie; potwierdź ostatnią fakturę z działem finansów
• Wyeksportuj przydatne artefakty (prompty, skille, przypadki ewaluacyjne, ślady) do repozytorium
• Zachowaj dowody decyzji i podlinkuj je we wpisie
• Zaktualizuj politykę narzędzi i wytyczne zespołów, które wspominały narzędzie

Wyjście na poziomie dostawcy, eksport danych i testy planu awaryjnego opisują zarządzanie ryzykiem dostawcy oraz strona o unikaniu uzależnienia od dostawcy.

Skąd brać dowody kosztu i użycia dla każdego zakładu

Szablon jest taki sam dla każdego narzędzia. Różni się tylko źródło rzeczywistych wartości w polu budget. Pełne instrukcje eksportu dla każdego narzędzia są w przewodniku po ekonomii.

Cursor

Dane o użyciu bierz z raportów administracyjnych twojego planu i zapisz w pozycji plan oraz tryb rozliczeń. Planów i raportowania administracyjnego Cursora nie dało się zweryfikować na cursor.com 2026-09-26, więc sprawdź, co pokazuje twoja konsola, zanim wpiszesz limit użycia do reguły decyzyjnej.

Claude Code

Każdy przebieg headless, który zakład dodaje do CI, ograniczaj przez claude -p --max-budget-usd 5 "…"; flaga działa tylko z --print (sprawdzone w Claude Code 2.1.283). Wydatki na użytkownika bierz z metryk kosztu OpenTelemetry (claude_code.cost.usage) eksportowanych do własnego stosu albo kieruj użycie przez gateway; dashboard analityki na planach Team i Enterprise pokazuje adopcję i atrybucję PR, ale nie koszt na użytkownika (kontrola kosztów).

Codex

Kroki CI uruchamiaj przez codex exec --json i zapisuj zdarzenia JSONL razem z numerem pull requesta; dodaj --output-schema, gdy zakład potrzebuje wyniku czytelnego maszynowo (sprawdzone w Codex CLI 0.157.1). Zapisz, czy CI uwierzytelnia się kluczem API (codex login --with-api-key), czy logowaniem ChatGPT, bo w każdym z tych przypadków użycie trafia na inne konto; dolicz oba do linii użycia.

Prompty do budowania i przeglądu portfela

Prompt do skopiowania: zamień ograniczenie w pozycję portfela

Read loop-register.yaml and tooling-portfolio.yaml. For the loop "web-app/ui-bug-fixes",
draft one new tooling-portfolio.yaml entry that unblocks its next gate.
Use this constraint from our delivery data: REVIEW_QUEUE_NUMBERS.
Fill every field of the existing entries' schema. Do not choose a vendor yet: write
the capability generically. The decision_rule must name graduate and stop thresholds
relative to the loop's baseline in loop-register.yaml, and the budget must include
usage, CI, setup and review hours, and exit work, not only licenses.
Mark any value you cannot derive from the files as TODO instead of estimating it.
Output the YAML only; do not edit any file.

W miejsce REVIEW_QUEUE_NUMBERS wklej zmierzone ograniczenie tej pętli, na przykład medianę czasu oczekiwania na review i odsetek nieudanych przebiegów CI z ostatnich 30 dni, razem ze źródłem.

Prompt do skopiowania: audyt portfela przed kwartalnym przeglądem

Read tooling-portfolio.yaml and loop-register.yaml. Flag every portfolio item where:
- serves_loop is not a loop id in loop-register.yaml;
- unblocks skips a rung or does not match the loop's current_rung;
- owner is a team alias rather than a named person;
- hypothesis names a tool but no measurable change in outcome_metric;
- guardrails lists only speed or usage measures;
- budget has no usage cap or no exit work;
- decision_rule is missing a graduate or a stop threshold;
- signed_before_start is later than the trial start, or next_review is past;
- two items test the same capability for the same loop.
Output one table: item id, violation, suggested fix. Then count items by status,
including stopped. Do not modify any file.

Prompt do skopiowania: przygotuj jedną decyzję na bramce

Prepare the review of portfolio item "browser-evidence-for-ui-fixes".
Read its entry in tooling-portfolio.yaml: decision_rule, guardrails, budget.
Use the GitHub CLI to list merged PRs for its loop since signed_before_start (2026-10-01):
  gh pr list --state merged --label loop:ui-bug-fixes --limit 100 \
    --search "merged:>=2026-10-01" \
    --json number,createdAt,mergedAt,reviews,files
Use only PRs merged on or after signed_before_start; drop any earlier PR.
Compute median lead time (created to merged) and compare it with the loop baseline
in loop-register.yaml. For each guardrail, report the value and the PR numbers behind it,
or "unknown" if it cannot be computed from these sources.
Recommend graduate, continue, narrow or stop strictly by the decision_rule. Separate
observed facts, assumptions and open risks. Do not edit any file.

Ostatni prompt wymaga uwierzytelnionego GitHub CLI (gh) i etykiety loop:* na pull requestach każdej pętli. Działa bez zmian w Claude Code, Codex i agencie Cursora.

Jak zweryfikować portfel bez ręcznego czytania każdego wpisu?

Traktuj tooling-portfolio.yaml jak kod i przerzuć ciężar na kontrole:

1. Kontrola schematu i odwołań w CI. Przy każdym pull requeście, który zmienia plik, waliduj tooling-portfolio.yaml względem JSON Schema i uruchamiaj mały skrypt, który sprawdza każdą pozycję z loop-register.yaml; ustaw obie kontrole jako wymagane. Pozycja wskazująca niezarejestrowaną pętlę, bez progu stopu albo bez planu wyjścia nie przechodzi kontroli i nie może zostać scalona. Prompt audytowy działa obok jako przegląd doradczy, a nie bramka, bo werdykt modelu może się różnić między uruchomieniami.
2. Podpisy w historii. Scalenie wpisu, przejrzanego przez właściciela pozycji, właściciela pętli i CTO, datuje regułę decyzyjną. Późniejsza zmiana progu jest widoczna jako diff i wymaga tych samych recenzentów.
3. Uzgodnienie z działem finansów. Raz na kwartał finanse porównują rzeczywiste koszty użycia i licencji każdej pozycji z fakturami. Typowa luka to klucz API rozliczany poza raportami samych narzędzi.
4. Decyzje sprawdzone z rejestrem pętli. Pozycja po awansie musi figurować jako zdolność swojej pętli; zatrzymana pozycja musi mieć odhaczoną listę kontrolną wygaszania.

Zatwierdzanie: właściciel pozycji odpowiada za dowody, dział finansów podpisuje linie kosztów, a ty jako CTO odpowiadasz za każdą decyzję o awansie i stopie.

Co psuje roadmapę toolingu AI?

Roadmapa jest inwentarzem. Lista „Claude Code, Cursor, Codex, MCP i agenci” z datami docelowymi nie mówi, co się poprawi ani kiedy przestać. Naprawa: przepisz każdą linię na szablon; linia, która nie wskazuje pętli ani bramki, wypada z roadmapy.

Druga roadmapa konkuruje z mapą transformacji. Daty narzędzi sterują planem, a pętle czekają na narzędzia zamiast odwrotnie. Naprawa: ustawiaj kolejność pozycji wyłącznie według bramek pętli, które odblokowują, i przeglądaj je na tym samym kwartalnym przeglądzie bramek.

Koszty utopione podtrzymują zakład. Pozycja od trzech kwartałów „dobrze rokuje”. Naprawa: stosuj zasadę jednej kontynuacji; druga kontynuacja to stop, a nowy pomysł dostaje nowy wpis z nową regułą decyzyjną.

Awans bez właściciela. Test kończy się dobrze, entuzjasta przechodzi do innego projektu i nikt nie aktualizuje serwera MCP ani nie odnawia konta. Naprawa: awans nie jest zakończony, dopóki zespół platformowy nie przejmie na piśmie odpowiedzialności operacyjnej, jak opisuje karta zespołu platformowego agentów.

Stop, który jest tylko zmianą statusu. We wpisie widnieje status stopped, ale konto usługowe nadal ma dostęp do repozytorium. Naprawa: przejdź listę kontrolną wygaszania i podlinkuj dowody, zanim status może się zmienić.

Dwa zakłady testują tę samą zdolność. Dwa zespoły testują dwa narzędzia do weryfikacji w przeglądarce dla tej samej pętli i żadne nie osiąga wielkości próbki. Naprawa: połącz je w jedną pozycję z jedną regułą decyzyjną albo rozdziel według pętli.

Dokąd dalej po Q24

Q23 poprzedza to pytanie i dostarcza dowodów ROI; Q25 sprawdza, czy każdy awansowany zakład ma przetestowane wyjście.

Mapa transformacji dla całej organizacji Etapy, rejestr pętli i bramki na drabinie, którym służy każda pozycja portfela.

Mapa adopcji dla jednego repozytorium Wycinek dla repozytorium, w którym prowadzi się bramki pętli.

Q23 · ROI toolingu AI Pakiet dowodów, od którego zależy decyzja o awansie.

Q25 · Zarządzanie ryzykiem dostawcy Testy planu awaryjnego, trybu ograniczonego, eksportu i odtwarzania dla awansowanych narzędzi.