Ścieżka CTO i VP Engineering: model operacyjny dla oprogramowania budowanego przez agentów
Ścieżka CTO i VP Engineering to plan czytania w AI Developer Toolkit dla liderów inżynierii, którzy ustalają, jak cała organizacja buduje oprogramowanie z Claude Code, Codeksem i Cursorem. Układa dziesięć decyzji w kolejności: od dowodów i mierzalnego pilotażu po autonomię, bezpieczeństwo, koszty, regulacje i raport dla zarządu. Każda decyzja kończy się nazwanym artefaktem z właścicielem.
Każdy zespół już korzysta z agentów, faktury rosną, a dział bezpieczeństwa pyta, kto zatwierdził agenta, który otwiera pull requesty. Zarząd chce liczby, a ty masz liczbę licencji.
Co ścieżka CTO daje twojej organizacji
Dział zatytułowany „Co ścieżka CTO daje twojej organizacji”- Artefakt i kryterium ukończenia dla każdego kroku, więc „gotowe” oznacza dowód, a nie spotkanie.
- Pilotaż przed platformą. Mierzysz jeden zespół, zanim obsadzisz zespół platformowy albo podpiszesz większy kontrakt.
Dlaczego decyzje CTO mają właśnie taką kolejność
Dział zatytułowany „Dlaczego decyzje CTO mają właśnie taką kolejność”Agenci zwiększają liczbę zmian szybciej, niż organizacja potrafi je weryfikować. Raport DORA 2025 (Google Cloud, 23 września 2025) wiąże adopcję AI z wyższą przepustowością i niższą stabilnością dostarczania. Telemetria Faros AI (kwiecień 2026) pokazuje wzrost liczby zadań na programistę o 33,7% przy jednoczesnym wzroście liczby incydentów na pull request o 242,7% i mediany czasu w review o 441,5%. Dlatego pomiar poprzedza model operacyjny.
Jaki artefakt daje każda decyzja CTO?
Dział zatytułowany „Jaki artefakt daje każda decyzja CTO?”| # | Decyzja | Artefakt | Strona kanoniczna |
|---|---|---|---|
| 1 | Co mówią dowody i gdzie są nasze zespoły? | Brief z trzema datowanymi źródłami; mapa organizacji według poziomów drabiny | Stan inżynierii agentowej, jedna mapa, dowody zamiast diffów |
| 2 | Co mierzymy i jak tego dowodzimy? | Definicje metryk v1 podpisane przez inżynierię i finanse; projekt pilotażu v1 z grupą kontrolną i regułą zatrzymania | Ramy metryk, projekt pilotażu |
| 3 | Kto jest właścicielem harnessu, bramek i ewaluacji? | Model operacyjny v1: macierz RACI z imiennymi właścicielami | Model operacyjny |
| 4 | Ile kosztuje zaakceptowana zmiana? | Bazowy koszt zaakceptowanej zmiany dla jednego zespołu | Ekonomia |
| 5 | Które klasy zmian mogą być scalane na podstawie samych dowodów? | Rejestr autonomii v1 | Governance i autonomia |
| 6 | Do czego agent ma dostęp i jako kto działa? | Model zagrożeń agentów v1; jedna ograniczona, przypisywalna tożsamość na agenta | Model zagrożeń, tożsamość i sekrety |
| 7 | Jak egzekwujemy politykę i kto prowadzi platformę? | Zarządzana polityka dla każdego zatwierdzonego narzędzia; karta zespołu platformowego | Zarządzana polityka, zespół platformowy |
| 8 | Czy wydatki są widoczne i czy możemy odejść od dostawcy? | Wydatki na zespół i na zaakceptowaną zmianę w jednym panelu; test wyjścia dla głównego narzędzia | Kontrola kosztów, ryzyko dostawcy |
| 9 | Które obowiązki regulacyjne nas dotyczą? | Lista obowiązków z AI Act przejrzana przez dział prawny | AI Act |
| 10 | Co raportujemy w górę? | Jednostronicowy kwartalny raport dla zarządu | Raportowanie dla zarządu |
Opublikowane kroki mają tę samą kolejność:
-
Dlaczego teraz: Datowane, niezależne dowody, wydawca po wydawcy, przed jakąkolwiek decyzją.
Gotowe, gdy: Umiesz przytoczyć trzy źródła z datami dla zmiany, którą planujesz.
-
Dlaczego teraz: Jedna mapa dojrzałości, procesu i możliwości, na której może umieścić się każdy zespół w organizacji.
Gotowe, gdy: Organizacja opisana jako rozkład scalonych zmian między poziomami.
-
Dlaczego teraz: Zasada działania: ludzie oceniają dowody i ryzyko, a nie każdą linię.
Gotowe, gdy: Zasada przyjęta jako polityka dla co najmniej jednej klasy ryzyka.
-
Dlaczego teraz: Wybierz ramę pomiaru przed pilotażem, żeby pilotaż mógł czegoś dowieść.
Gotowe, gdy: Definicje metryk zatwierdzone przez inżynierię i finanse.
-
Dlaczego teraz: Pilotaż z grupą kontrolną i regułą zatrzymania, a nie demo.
Gotowe, gdy: Projekt pilotażu v1: zespoły, czas trwania, metryki i decyzja, którą zasila.
-
Dlaczego teraz: Zdecyduj, kto jest właścicielem harnessu, bramek i ewaluacji w zespołach.
Gotowe, gdy: Model operacyjny v1 z imiennymi właścicielami.
-
Dlaczego teraz: Zarządzaj kosztem zaakceptowanej zmiany, a nie kosztem stanowiska.
Gotowe, gdy: Bazowy koszt zaakceptowanej zmiany dla jednego zespołu.
-
Dlaczego teraz: Autonomię przyznaje się według klasy ryzyka, z ludźmi przy bramkach.
Gotowe, gdy: Rejestr autonomii v1: które klasy zmian mogą być scalane na podstawie dowodów.
-
Dlaczego teraz: Prompt injection i zasięg szkód to nowe zagrożenia; zamodeluj je przed skalowaniem.
Gotowe, gdy: Model zagrożeń dla pipeline agentów przejrzany przez dział bezpieczeństwa.
-
Dlaczego teraz: Agenci potrzebują własnych tożsamości i ograniczonych poświadczeń, nigdy tokenu programisty.
Gotowe, gdy: Każde poświadczenie agenta ograniczone, rotowane i przypisywalne.
-
Dlaczego teraz: Egzekwuj jedną politykę we wszystkich agentach kodujących, których używa organizacja.
Gotowe, gdy: Zarządzane ustawienia wdrożone dla każdego zatwierdzonego narzędzia.
-
Dlaczego teraz: Prowadź harness jak produkt, z zespołem, który jest jego właścicielem.
Gotowe, gdy: Karta i backlog zespołu platformowego.
-
Dlaczego teraz: Uczyń wydatki widocznymi i przypisywalnymi, zanim staną się niespodzianką w budżecie.
Gotowe, gdy: Miesięczne wydatki na zespół i na zaakceptowaną zmianę w jednym panelu.
-
Dlaczego teraz: Testuj ciągłość działania z każdym dostawcą, a nie jego logo.
Gotowe, gdy: Przeprowadzony test wyjścia dla głównego narzędzia.
-
Dlaczego teraz: Wiedz, które obowiązki dotyczą budowania oprogramowania z agentami w UE.
Gotowe, gdy: Lista obowiązków przejrzana przez dział prawny.
-
Dlaczego teraz: Raportuj zarządowi efekty, ryzyko i wydatki w formie, na podstawie której może działać.
Gotowe, gdy: Jednostronicowy szablon raportu dla zarządu wypełniony twoimi liczbami.
Gdzie każde narzędzie egzekwuje politykę organizacji?
Dział zatytułowany „Gdzie każde narzędzie egzekwuje politykę organizacji?”| Narzędzie | Gdzie żyje polityka organizacji |
|---|---|
| Claude Code | Zarządzane ustawienia: plik managed-settings.json, polityka MDM albo ustawienia zarządzane z serwera przez claude.ai (Team i Enterprise). permissions.disableAutoMode: "disable" wyłącza tryb auto wszystkim. |
| Codex | requirements.toml przechowuje ograniczenia administratora (na przykład approval_policy, mcp_servers, allow_managed_hooks_only), oddzielone od wartości domyślnych w config.toml. |
| Cursor | Ustawienia administratora w planach biznesowych Cursora; jego SDK udostępnia warstwy ustawień team i mdm (@cursor/sdk 1.0.32). Nazwy ustawień sprawdź na cursor.com. |
Fakty o Claude Code sprawdzono 26 września 2026 w wersji 2.1.283, a o Codeksie w wersji 0.157.1.
Jak udowodnić, że model operacyjny działa?
Dział zatytułowany „Jak udowodnić, że model operacyjny działa?”Nie czytasz diffów agentów; jakość potwierdzają dowody, które da się skontrolować. Każdy kwartał zamykają cztery sprawdzenia:
- Zaakceptowana zmiana, nie aktywność. Definicje metryk z decyzji 2 liczą scalone, niewycofane zmiany, które przeszły swoje bramki, a nigdy linie kodu ani „procent kodu napisanego przez AI”.
- Stabilność obok przepustowości. Odsetek nieudanych zmian (change failure rate) i liczba incydentów na zmianę są w tym samym panelu co przepustowość.
- Autonomia powiązana z dowodami. Każda klasa w rejestrze autonomii wskazuje testy, ewaluacje i agentów review, które muszą przejść, oraz człowieka, który zatwierdza wdrożenie na produkcję.
- Artefakty z właścicielami i datami. Wpis w rejestrze decyzji po terminie przeglądu trafia do raportu dla zarządu jako ustalenie.
Gdzie ścieżka CTO najczęściej się zacina?
Dział zatytułowany „Gdzie ścieżka CTO najczęściej się zacina?”- Pilotaż niczego nie dowodzi. Bez punktu odniesienia i grupy kontrolnej pokazuje tylko, że ludzie lubią narzędzie. Wstrzymaj wdrażanie i powtórz pilotaż według projektu z decyzji 2.
- Autonomia przed kontrolami. Agenci dostali prawo scalania, zanim powstały model zagrożeń i ograniczone tożsamości. Najpierw unieważnij poświadczenia agentów, a potem przyznawaj je ponownie według klas ryzyka.
- Procent kodu jako główna liczba. DX podaje średnio 51,9% kodu napisanego przez AI (dane deklaratywne) w ponad 400 firmach (II kwartał 2026, publikacja 17 czerwca 2026), więc sam udział niczym cię nie wyróżnia. Raportuj koszt zaakceptowanej zmiany i stabilność.
- Zespół platformowy staje się bramką. Daj mu poziomy usług wobec zespołów produktowych i jawny backlog.