Oprogramowanie tworzone poza działem inżynierii

Oprogramowanie tworzone poza działem inżynierii to wewnętrzne narzędzia, raporty i prototypy, które analitycy, pracownicy operacji i eksperci domenowi budują sami agentami kodującymi i kreatorami aplikacji (Lovable, Replit, v0, Bolt). Opłaca się przy prototypach do wyrzucenia i narzędziach jednego zespołu na zatwierdzonych danych. Wszystko, co ma prawdziwych użytkowników, wrażliwe dane lub skutki zewnętrzne, trafia do weryfikowanego procesu dostarczania w inżynierii.

Ta strona jest dla członków zarządu i CTO. Sytuacja, na którą odpowiada: w poniedziałek szefowa operacji pokazuje ci aplikację do grafików, którą zbudowała w weekend w kreatorze aplikacji. Korzysta z niej już 30 osób, czyta dane z systemu kadrowego przez jej prywatny token API, a nikt z inżynierii nie widział kodu. Chcesz więcej takiej energii, nie mniej. Musisz też wiedzieć, co się stanie, gdy ona pójdzie na urlop, a aplikacja przestanie działać.

Co możesz wdrożyć dla oprogramowania spoza inżynierii

Tabelę opłacalności, która mówi, jakie rodzaje takiego oprogramowania warto wspierać, a które od pierwszego dnia należą do inżynierii.
Model czterech ścieżek (do wyrzucenia, kontrolowany pilotaż, produkcja, zakazane), zgodny z polityką prototypów z karty oceny CTO.
Kartę zgłoszenia, którą wkleisz do dowolnego formularza, żeby każde narzędzie miało właściciela, ścieżkę i datę wygaśnięcia od dnia powstania.
Procedurę przejścia na produkcję z gotowymi promptami, która zamienia działający prototyp w kryteria akceptacji, możliwe do zweryfikowania przez inżynierię bez czytania każdej linii.
Czerwone linie, których nie przekracza żadna ścieżka, metryki pokazujące, czy program działa, oraz pytania do CTO lub lidera platformy.

Ta strona opiera się na ekonomii oprogramowania budowanego przez agentów; przeczytaj ją najpierw, żeby wiedzieć, jak liczyć koszt przejścia na produkcję.

Kto dziś buduje oprogramowanie poza inżynierią?

Oprogramowanie poza inżynierią budują trzy grupy i każda potrzebuje innych zabezpieczeń.

Grupa	Typowe narzędzia	Co budują	Czego zwykle brakuje
Użytkownicy kreatorów aplikacji	Lovable, Replit, v0, Bolt: prompt w czacie daje działającą aplikację webową	Panele raportowe, formularze zgłoszeń, małe aplikacje do obiegu pracy, klikalne prototypy	Repozytorium należącego do firmy, testów, wskazanego opiekuna
Użytkownicy agentów spoza inżynierii	Aplikacja desktopowa Claude Code, aplikacja desktopowa Codex, Cursor	Skrypty, potoki danych, integracje, zamienniki arkuszy kalkulacyjnych	Sandboxa, obsługi sekretów, code review
Analitycy	Ci sami agenci plus SQL i notatniki	Raporty, jednorazowe analizy, cykliczne zadania na danych	Kontroli wersji, powtarzalności, klasyfikacji danych

Repozytorium Bolta opisuje pętlę całej kategorii wprost: „Prompt, run, edit, and deploy full-stack web applications” (stackblitz/bolt.new, odczyt 2026-09-26). Plany, ceny i funkcje dla firm w Lovable, Replit, v0 i Bolt często się zmieniają; zanim zatwierdzisz któreś narzędzie, potwierdź je w aktualnej dokumentacji dostawcy (ta strona ich nie podaje, stan na 2026-09-26) i użyj pytań z sekcji jak wybrać zatwierdzony kreator aplikacji.

Andrej Karpathy wyznacza granicę, na której opiera się ta strona: „Vibe coding raises the floor. Agentic engineering is about extrapolating the ceiling” (podsumowanie Sequoia Ascent 2026, 2026-04-30). Wcześniej w tym samym fragmencie mówi: „You are still responsible for your software, just as before.” Twórcy spoza inżynierii podnoszą podłogę. Twoim zadaniem jest zdecydować, gdzie ta podłoga się kończy i kto odpowiada za to, co jest nad nią.

Gdzie oprogramowanie spoza inżynierii się opłaca?

Opłaca się tam, gdzie osoba rozumiejąca problem potrafi też ocenić, czy wynik jest poprawny, a pomyłka pozostaje mała. Tabela porządkuje typowe przypadki.

Zastosowanie	Opłacalność	Dlaczego	Domyślna ścieżka
Klikalny prototyp, który rozstrzyga, co ma robić funkcja	Wysoka	Zastępuje tygodnie dokumentów wymagań czymś, na co użytkownicy reagują; prototyp staje się specyfikacją	Do wyrzucenia
Jednorazowa analiza lub raport na zatwierdzonych danych	Wysoka	Analityk może sprawdzić liczby względem znanego źródła	Do wyrzucenia
Narzędzie wewnętrzne jednego zespołu na danych niewrażliwych	Średnia do wysokiej	Usuwa kolejkę do inżynierii; zespół zauważy, gdy coś jest źle	Kontrolowany pilotaż
Cykliczne zadanie na danych zasilające decyzje innych zespołów	Średnia	Przydatne, ale inni od niego zależą i nie widzą jego błędów	Kontrolowany pilotaż, przegląd przy pierwszym nowym odbiorcy
Automatyzacja zapisująca do systemu źródłowego (CRM, ERP, kadry)	Niska bez inżynierii	Cichy błąd psuje wspólne dane; wycofanie zmian jest trudne	Produkcja od pierwszego dnia
Wszystko, co widzi klient, z logowaniem, płatnościami lub danymi osobowymi	Ujemna bez inżynierii	Bezpieczeństwo, prywatność i odpowiedzialność przerastają to, co twórca może zweryfikować	Produkcja albo zakazane

Opłacalność zależy od dwóch warunków. Po pierwsze, twórca musi umieć sprawdzić wynik względem czegoś, czemu już ufa: znanej sumy, ręcznego procesu, oceny kolegi. Po drugie, narzędzie musi być tanie do wyrzucenia. Gdy któryś warunek nie jest spełniony, wartość przechodzi do inżynierii, bo tylko ona ma testy, review i wycofywanie zmian, dzięki którym oprogramowaniu można ufać.

Zapowiedź raportu DORA 2025 na blogu Google Cloud (2025-09-23) ujmuje stronę organizacyjną tak: „AI doesn’t fix a team; it amplifies what’s already there.” Twórcy spoza inżynierii wzmacniają tę dyscyplinę danych i te nawyki odpowiedzialności, które twoja firma już ma.

Na której ścieżce powinno być dane narzędzie?

Użyj czterech ścieżek z polityki prototypów. Ścieżka wynika z ekspozycji i ryzyka, nigdy z narzędzia, które wygenerowało kod. Tabela dodaje właściciela każdej ścieżki i to, co wolno na niej twórcy.

Ścieżka	Granica	Twórcy wolno	Właściciel	Dowody, zanim ktokolwiek zacznie na tym polegać
Eksploracja do wyrzucenia	Dane syntetyczne lub zatwierdzone, bez użytkowników zewnętrznych, bez zapisów do wspólnych systemów	Zbudować i pokazać demo; wygasa po najwyżej 30 dniach	Twórca	Cel, właściciel i data wygaśnięcia w inwentarzu
Kontrolowany pilotaż	Wskazani użytkownicy w jednym zespole, zatwierdzone dane, odwracalne skutki	Uruchomić narzędzie dla zespołu na zatwierdzonej platformie	Twórca plus wskazany sponsor z inżynierii	Kryteria akceptacji, przebieg testu względem nich, monitoring, notatka o wycofaniu zmian
System produkcyjny	Inne zespoły, klienci, trwałe dane lub istotne skutki	Wnieść prototyp i kryteria akceptacji	Zespół inżynierii	Pełna pętla cyklu życia: specyfikacja, testy, review, pakiet dowodów, wskazany zatwierdzający
Ścieżka zakazana	Sekrety, niezatwierdzone dane osobowe lub regulowane, płatności, dostęp niszczący	Nic; zatrzymaj się i użyj zatwierdzonej drogi	Bezpieczeństwo	Nie dotyczy

30 dni to wartość startowa, nie benchmark. Wybierz własną i zapisz ją. Liczy się to, żeby każde narzędzie do wyrzucenia miało datę wygaśnięcia, więc po jej upływie albo świadomie je przedłużasz, albo usuwasz.

Co powinna zawierać karta zgłoszenia?

Rejestruj każde takie narzędzie w dniu powstania, a nie w dniu awarii. Szablon poniżej pasuje do dowolnego narzędzia do formularzy. Zmieść go na jednym ekranie, inaczej twórcy będą go pomijać.

Nazwa narzędzia:
Twórca (imię i nazwisko, zespół):
Sponsor z inżynierii (wymagany od kontrolowanego pilotażu w górę):
Cel w jednym zdaniu:
Ścieżka: do wyrzucenia | kontrolowany pilotaż | produkcja | zakazana
Obecni użytkownicy (liczba, zespoły):
Dane odczytywane (system, klasyfikacja):
Dane zapisywane (system albo „brak”):
Skutki zewnętrzne (e-mail, płatności, wywołania API firm trzecich albo „brak”):
Użyte poświadczenia (nazwa konta serwisowego, nigdy prywatny token):
Gdzie jest kod (URL repozytorium firmy albo przestrzeni w kreatorze):
Data wygaśnięcia:
Jak twórca sprawdza poprawność (zaufane źródło lub ręczna kontrola):

Ostatnie pole jest najważniejsze. Twórca, który nie potrafi powiedzieć, jak sprawdza wynik, prowadzi narzędzie, którego nikt nie weryfikuje.

Jak prototyp przechodzi na produkcję?

Prototyp przechodzi na produkcję, gdy zadziała wyzwalacz: nowi użytkownicy spoza zespołu, wrażliwe dane, zapisy do wspólnych systemów albo ktoś inny zaczyna od niego zależeć. Przejście zamienia prototyp w specyfikację, którą inżynieria implementuje i weryfikuje, zamiast odziedziczyć kod w ciemno.

Zamroź zachowanie. Twórca zapisuje, co narzędzie robi dziś: ekrany, wejścia, wyjścia oraz trzy do pięciu prawdziwych przykładów z oczekiwanym wynikiem. Przykłady staną się przypadkami testowymi.
Wyciągnij kryteria akceptacji z prototypu. Inżynier albo twórca z inżynierem jako recenzentem uruchamia agenta na kodzie prototypu i przykładach twórcy, żeby przygotować szkic kryteriów akceptacji. Twórca potwierdza, że każde kryterium odpowiada temu, czego użytkownicy naprawdę potrzebują.
Sklasyfikuj ryzyko. Umieść przyszły system w czterech poziomach ryzyka, których używa twoja organizacja inżynierii. Uwierzytelnianie, płatności lub dane produkcyjne oznaczają poziom 3 bez względu na to, jak mało jest kodu.
Zdecyduj: utwardzić na miejscu czy przebudować. Skorzystaj z tabeli decyzyjnej poniżej. Żadna odpowiedź nie jest domyślna.
Zaimplementuj pod bramkami inżynierii. Zespół-właściciel pracuje w repozytorium firmy z CI, testami wyprowadzonymi z kryteriów akceptacji, przeglądem bezpieczeństwa i pakietem dowodów. Twórca potwierdza, że zachowanie się zgadza; właściciel z inżynierii potwierdza, że uruchomienie jest bezpieczne.
Wygaś prototyp. Unieważnij jego poświadczenia, usuń kopie danych, zdejmij domenę i zamknij przestrzeń w kreatorze. Zapisz wygaszenie w inwentarzu.

Sygnał	Utwardzić na miejscu	Przebudować w stosie produkcyjnym
Kod da się przenieść do repozytorium firmy	Tak	Nie, albo tylko jako eksport, którego nikt nie uruchomi
Stos pasuje do czegoś, co twoja platforma już utrzymuje	Tak	Nie
Model danych wytrzyma realny wolumen i reguły dostępu	Tak	Nie albo nie wiadomo
Przegląd bezpieczeństwa znajduje pojedyncze problemy	Tak	Problemy systemowe (uwierzytelnianie, sekrety w kodzie, brak kontroli dostępu)
Główną wartością prototypu jest zachowanie, które pokazuje	Obojętnie	Zwykle przebudować: zachowaj specyfikację, porzuć kod

Przebudowa nie marnuje prototypu. Najdroższą częścią większości narzędzi wewnętrznych jest ustalenie, co mają robić, a prototyp już za to zapłacił.

You are reviewing a prototype built outside engineering. Read the code in
this repository and the file examples.md, which lists real inputs and the
results the builder expects.

1. Describe what the tool does in plain language, screen by screen.
2. Write acceptance criteria in Given/When/Then form, one per behaviour.
   Every example in examples.md must be covered by at least one criterion.
3. List behaviour the code implements that no example covers, and mark
   each one "confirm with builder".
4. List every external system the code reads or writes, with the
   credential it uses and where that credential is stored.

Do not modify any file. Output one markdown document with four sections.

Assess this application for graduation from a prototype to a production
system. Check and cite file and line for each finding:

- Authentication and authorisation: who can reach each page and API route.
- Secrets: any key, token, or password in code, config, or client bundles.
- Data: which personal or confidential fields it stores, where, and for
  how long.
- External effects: emails, payments, writes to other systems.
- Dependencies: every package, flagged if it is unmaintained or if you
  cannot confirm it exists on the public registry.
- Tests: what is covered, and what is not.

Classify the result as: keep disposable, harden in place, or rebuild.
Give the three findings that most affect that decision first. Do not
change any code.

Sprawdzenie zależności w drugim prompcie ma większe znaczenie dla kodu spoza inżynierii niż dla kodu inżynierów. Badacze ustalili, że 19,7% z 2,23 mln próbek kodu z 16 modeli odwoływało się do co najmniej jednego nieistniejącego pakietu (USENIX Security 2025, Spracklen i in., według relacji z drugiej ręki Aikido i Cloud Security Alliance). Twórca, który nigdy nie używał menedżera pakietów, takiego pakietu nie zauważy.

Jak inżynieria prowadzi przegląd w każdym z narzędzi?

Prompty powyżej działają w każdym z trzech agentów. Różni się to, jak utrzymać przegląd w trybie tylko do odczytu i skąd bierze się druga opinia.

Uruchom sesję w trybie planowania, żeby agent czytał i raportował bez edycji: claude --permission-mode plan. Wklej prompt przeglądu. Potem uruchom /security-review, żeby dostać osobny przegląd bezpieczeństwa, a /code-review na pull requeście, gdy powstanie utwardzona wersja. Dla twórcy, który ma tylko czytać i analizować, claude --restricted usuwa wbudowane narzędzia uruchamiające polecenia lub kod, a także WebFetch, i pomija pliki ustawień użytkownika, projektu i lokalne, a ustawienia zarządzane nadal obowiązują (flaga CLI, sprawdzone w v2.1.283).

Dla twórców spoza inżynierii liczy się jedno ustawienie domyślne: od v2.1.283 (kanał latest) interaktywne sesje w terminalu i VS Code startują w trybie auto na obsługiwanych modelach, a w tym trybie akcje zatwierdza klasyfikator, a nie człowiek (claude -p, Agent SDK i sesje na nieobsługiwanych modelach, np. Haiku, nadal startują w trybie Manual). To pasuje inżynierowi, który potrafi przeczytać polecenie powłoki. Dla twórców, którzy tego nie potrafią, zdecyduj świadomie i wyłącz ten tryb dla całej organizacji przez permissions.disableAutoMode: "disable" w ustawieniach zarządzanych.

Najpierw zaimportuj prototyp do repozytorium firmy. Uruchom prompt przeglądu w Codex CLI lub aplikacji desktopowej z profilem uprawnień tylko do odczytu: codex -c default_permissions=":read-only" (profile uprawnień są w wersji beta, sprawdzone w 0.157.1). Po utwardzeniu codex review --base main przegląda gałąź nieinteraktywnie, więc pasuje jako krok CI. Administratorzy mogą przypiąć profile uprawnień i ograniczyć serwery MCP dla wszystkich przez requirements.toml.

Gdzie zarządzanie wyznacza granicę?

Niektóre linie obowiązują na każdej ścieżce, dla każdego twórcy i w każdym narzędziu. Wpisz je do polityki używania AI i egzekwuj technicznie, bo dokument nie zatrzyma wklejonego tokena.

Czerwona linia	Dlaczego	Jak egzekwować
Żadnych prywatnych tokenów API ani poświadczeń produkcyjnych w kreatorach	Prywatny token daje aplikacji pełny dostęp twórcy i odchodzi razem z nim	Konta serwisowe o wąskich uprawnieniach, wydawane w procesie tożsamości i sekretów agentów
Żadnych danych osobowych ani regulowanych bez decyzji o ochronie danych	Dostawca kreatora staje się podmiotem przetwarzającym; liczy się retencja i lokalizacja	Klasyfikacja danych plus ocena dostawcy opisana w prywatności i obsłudze danych
Żadnych płatności ani uwierzytelniania użytkowników zewnętrznych	To te awarie zamieniają się w incydenty i odpowiedzialność prawną	Ścieżka zakazana; buduje to inżynieria
Żadnych zapisów do systemu źródłowego bez właściciela z inżynierii	Ciche uszkodzenie danych rozchodzi się do każdego zespołu dalej w łańcuchu	Bramki API przyjmujące zapisy tylko od zarejestrowanych kont serwisowych
Żadnego publicznego udostępnienia bez przeglądu	Publiczny URL zamienia wewnętrzną zabawkę w powierzchnię ataku	SSO przed każdym zatwierdzonym kreatorem; publikacja publiczna domyślnie wyłączona
Żadnego narzędzia bez właściciela i daty wygaśnięcia	Osierocone narzędzia stają się produkcją bez właściciela	Inwentarz z automatycznymi przypomnieniami o wygaśnięciu

Firmy regulowane dodają własne linie. Jeśli narzędzie dotyka decyzji o ludziach, takich jak rekrutacja, kredyt czy dostęp do usług, sprawdź je pod kątem AI Act, zanim opuści ścieżkę do wyrzucenia.

Jak wybrać zatwierdzony kreator aplikacji?

Zaoferuj każdej grupie jedną zatwierdzoną drogę, żeby ludzie przestali używać tego, co akurat znaleźli. Wytyczne DORA dotyczące polityki AI tłumaczą, dlaczego zatwierdzona droga jest lepsza od zakazu: „Ambiguity creates risk. A clear policy provides the psychological safety developers need to experiment effectively” (blog Google Cloud, 2025-12-10). To samo dotyczy twórców spoza inżynierii.

Zadaj każdemu dostawcy te pytania i zapisz odpowiedzi w dokumentacji zakupowej:

Czy możemy wymusić firmowe SSO i wyłączyć prywatne konta w domenie firmy?
Czy kod synchronizuje się z repozytorium należącym do naszej organizacji i czy eksport działa poza platformą dostawcy?
Czy możemy wyłączyć publiczną publikację albo wymagać SSO przed każdą opublikowaną aplikacją?
Gdzie są przechowywane dane aplikacji i prompty, jak długo i czy służą do trenowania modeli?
Czy możemy ustawić limit wydatków na przestrzeń roboczą i widzieć użycie w podziale na użytkowników?
Czy administratorzy widzą listę wszystkich aplikacji w organizacji z właścicielem i datą ostatniej aktywności?

Kreator, który odpada na pytaniu 1 lub 2, nadal może obsługiwać ścieżkę do wyrzucenia na danych syntetycznych. Nie może obsługiwać kontrolowanego pilotażu.

Dla użytkowników agentów i analityków zatwierdzoną drogą jest zwykle ten sam agent, którego używa inżynieria, skonfigurowany ciaśniejszymi ustawieniami zarządzanymi i bez poświadczeń produkcyjnych. Dzięki temu masz jeden zestaw kontroli, a przejście na produkcję odbywa się w tym samym zestawie narzędzi.

Skąd wiesz, że program działa?

Mierz program, a nie twórców. Każda metryka ma właściciela i definicję, którą możesz przyjąć w tej postaci.

Metryka	Definicja	Właściciel	Pożądany trend
Pokrycie inwentarza	Zarejestrowane narzędzia ÷ narzędzia wykryte (logi SSO, konsole administracyjne kreatorów, rozliczenia wydatków), kwartalnie	Lider platformy lub bezpieczeństwa (w pionie CTO)	Rośnie w stronę wszystkich
Odsetek z właścicielem i datą wygaśnięcia	Zarejestrowane narzędzia ze wskazanym właścicielem i przyszłą datą wygaśnięcia ÷ wszystkie zarejestrowane	Lider platformy	Blisko wszystkich
Czas przejścia na produkcję	Dni od zadziałania wyzwalacza do uruchomienia narzędzia pod bramkami inżynierii albo jego wygaszenia	Sponsor z inżynierii	Stabilny lub malejący
Produkcja bez właściciela	Narzędzia z użytkownikami spoza zespołu twórcy i bez właściciela z inżynierii	CTO	Zero
Incydenty z narzędzi spoza inżynierii	Incydenty bezpieczeństwa lub danych, których przyczyną jest takie narzędzie, kwartalnie	Bezpieczeństwo	Zero, a każdy przeanalizowany
Kompletność wygaszeń	Wygaszone narzędzia ze sprawdzonym usunięciem poświadczeń, danych i domen ÷ wszystkie wygaszone	Lider platformy	Wszystkie

Nie raportuj zarządowi „godzin zaoszczędzonych przez citizen developerów”. Nikt nie mierzy scenariusza alternatywnego, a zaoszczędzony czas to nie zaoszczędzona gotówka, jak wyjaśnia strona o ekonomii oprogramowania budowanego przez agentów. Raportuj metryki z tabeli oraz konkretne narzędzia, które przeszły na produkcję, i to, co zastąpiły.

Co psuje się w oprogramowaniu tworzonym poza inżynierią?

Narzędzie do wyrzucenia staje się produkcją, choć nikt tego nie postanowił. Zyskuje użytkowników, potem dane, potem zależności. Jak to naprawić: uruchamiaj wykrywanie co miesiąc i traktuj każde narzędzie z użytkownikami spoza zespołu jako wyzwalacz, który działa automatycznie.

Prywatny token napędza wspólną aplikację. Twórca odchodzi, token zostaje unieważniony i praca całego zespołu staje z dnia na dzień. Jak to naprawić: najpierw przejdź na konto serwisowe, potem zarejestruj narzędzie i przypisz sponsora.

Inżynieria staje się bramką, którą wszyscy omijają. Jeśli przejście na produkcję trwa kwartał, twórcy przestają rejestrować narzędzia. Jak to naprawić: publikuj czas przejścia, zorganizuj małą rotację sponsorów z inżynierii i spraw, żeby ścieżka do wyrzucenia nie wymagała żadnej zgody.

Inżynieria przebudowuje narzędzie i gubi wiedzę prototypu. Nowa wersja jest czystsza i błędna. Jak to naprawić: przykłady twórcy stają się testami akceptacyjnymi, a przed wydaniem wymagane jest potwierdzenie zachowania przez twórcę.

Rozrost kreatorów. Pięć zespołów używa pięciu kreatorów, każdy z własną kopią danych. Jak to naprawić: zatwierdź jeden kreator na grupę, a resztę migruj przy najbliższym przejściu na produkcję lub wygaśnięciu.

Niespodzianki w kosztach. Plany rozliczane za użycie rosną razem z entuzjazmem, a nie z wartością. Jak to naprawić: limit wydatków na przestrzeń roboczą, przeglądany razem z zarządzaniem kosztami agentów samej inżynierii.

Pytania do CTO lub lidera platformy o narzędzia twórców spoza inżynierii

CTO może użyć tej samej listy do samodzielnej kontroli, zanim zapyta o to zarząd.

Ile narzędzi zbudowanych poza inżynierią dziś działa i skąd wiemy, że ta liczba jest pełna?
Które z nich mają użytkowników spoza zespołu twórcy i kto jest ich właścicielem?
Które kreatory są zatwierdzone i czy przechodzą sześć pytań zakupowych?
Ile trwa przejście na produkcję i ile narzędzi przeszło na produkcję lub zostało wygaszonych w ostatnim kwartale?
Które z tych narzędzi używają prywatnych tokenów lub dotykają danych osobowych?
Co zobaczylibyśmy najpierw, gdyby któreś z nich spowodowało incydent?

Dokąd dalej z oprogramowaniem spoza inżynierii

Polityka prototypów Oceniana polityka CTO: ścieżki, wyzwalacze przejścia na produkcję i dowody akceptacji.

Zarządzanie produktem, gdy budowanie trwa godziny Jak zespoły produktowe piszą intencję i kryteria akceptacji oraz trzymają prototypy z dala od produkcji.

Zarządzanie i autonomia Cztery poziomy ryzyka i kontrole wymagane na każdym z nich.

Jak zmieniają się zespoły, role i zatrudnienie Gdzie w nowym projekcie organizacji siedzą twórcy, weryfikujący i sponsorzy z inżynierii.

Gdy narzędzie przechodzi na produkcję, zespół-właściciel stosuje kryteria akceptacji i pakiet dowodów jak przy każdej innej zmianie.