Business case dla inżynierii agentowej

Business case dla inżynierii agentowej to notatka decyzyjna, która porównuje cztery opcje (nic nie robić, same licencje, wspólny harness, pilotaż fabryki) ze zmierzonym punktem odniesienia. Zawiera pełny koszt, próg rentowności zamiast mnożnika od dostawcy oraz bramki stopu spisane, zanim wydatek ruszy. Prosi o ograniczony eksperyment, a nie o prognozę produktywności.

Twój CTO chce budżetu na agentów kodujących. Prezentacja dostawcy obiecuje mnożnik, a twój CFO przeczytał, że w randomizowanym badaniu METR z 2025 roku doświadczeni programiści z AI pracowali o 19% dłużej. Żadna z tych liczb nie opisuje twojego kodu, przepustowości code review ani poziomu incydentów. Ta strona daje członkowi zarządu, który zatwierdza wydatek, i CTO, który go broni, notatkę, która przetrwa rozmowę z takim CFO.

Co daje ten szablon business case’u

Jednostronicową notatkę decyzyjną w Markdownie z tabelą opcji, listą kontrolną pełnego kosztu, bramkami stopu i rejestrem ryzyk
Obliczenie progu rentowności, które zastępuje „3x szybciej” zdaniem „to się zwraca, jeśli liczba zaakceptowanych zmian wzrośnie o N% przy tym samym zespole i tej samej jakości”
Dwa prompty: jeden wyciąga punkt odniesienia z twojego repozytorium, drugi atakuje notatkę, zanim zrobi to CFO

Dlaczego business case oparty na mnożniku przegrywa z CFO

Mnożnik przegrywa w chwili, gdy ktoś zapyta o źródło. Dowody niezależne od dostawców wskazują w obie strony:

Źródło	Co mierzono	Co wyszło
METR, badanie randomizowane, 2025-07-10	16 doświadczonych programistów open source, 246 zadań, narzędzia z początku 2025	Zadania z AI trwały o 19% dłużej (przedział od +2% do +39%), a programiści uważali, że AI przyspieszyło ich o 20%.
METR, badanie uzupełniające, 2026-02-24	Ten sam schemat, narzędzia z końca 2025	Oszacowania punktowe wypadają na korzyść AI (ok. 18% i 4% mniej czasu w dwóch kohortach), ale oba przedziały przecinają zero; METR nazywa te dane „an unreliable signal”, a selekcja utrudnia ich interpretację.
DORA, raport 2025, 2025-09-23	Ankieta wśród specjalistów od oprogramowania	„A positive relationship between AI adoption on both software delivery throughput and product performance” oraz „a negative relationship with software delivery stability”.
Faros AI, kwiecień 2026	Telemetria dostawcy: dwa lata, 22 000 programistów, ponad 4000 zespołów	Epiki na programistę +66,2%, zadania na programistę +33,7%, a jednocześnie błędy na programistę +54%, incydenty na pull request +242,7% i mediana czasu w review +441,5%.

Wynikają z tego trzy wnioski:

Deklaracje to nie punkt odniesienia. Programiści w badaniu METR pomylili się co do własnego tempa, i to w złą stronę, więc ankiety o „zaoszczędzonych godzinach” nie uzasadnią pozycji w budżecie.
Wzrost przepustowości przychodzi z rachunkiem za jakość. DORA i Faros pokazują więcej pracy i mniej stabilności w tym samym okresie. DORA nazywa mechanizm: „Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability”.
Uczciwa prośba dotyczy eksperymentu. Żadne badanie nie mierzy twojego kodu, a mnożniki firm doradczych bez populacji i metody czy dane wewnętrzne dostawców tym bardziej. Notatka prosi więc o ograniczony, zmierzony test ze spisaną regułą decyzyjną i podaje koszt pomyłki. Datowane dowody zbiera strona o stanie inżynierii agentowej.

Jakie cztery opcje porównuje notatka?

Porównuj zawsze te same cztery opcje, tak żeby „nic nie robić” wycenić równie poważnie jak wniosek. Poziomy odnoszą się do drabiny autonomii, która ocenia każdą pętlę dostarczania z osobna, a nie firmę.

Opcja	Co kupujesz	Zasięg na drabinie	Co może udowodnić	Główne ryzyko	Odwracalna?
A. Nic nie robić	Brak zatwierdzonych narzędzi	L0–L2, bez zarządzania	Nic	Nieoficjalne użycie (shadow IT), bez kontroli danych i bez pomiaru	Tak
B. Same licencje	Licencja dla każdego inżyniera	L2–L3 na osobę	Adopcję i zadowolenie; słabe dowody na efekty	Więcej diffów, niż recenzenci zdążą przeczytać; wzorzec z Faros	Tak, przy odnowieniu
C. Wspólny harness	Licencje plus wspólne reguły, skille, hooki, bramki CI i agenci do review, z imiennym właścicielem	L3, z drogą do L4 na wybranych pętlach	Koszt zaakceptowanej zmiany i jakość w porównaniu z dobranym zespołem kontrolnym	Praca nad harnessem konkuruje z funkcjami produktu	Tak; harness to pliki w repozytorium
D. Pilotaż fabryki	Jedna wąska pętla bez nadzoru, sprawdzana wyrocznią (np. aktualizacje zależności)	L4 na jednej pętli	Czy pętla może działać na dowodach zamiast czytania kodu linia po linii	Niekontrolowane zużycie; słaba wyrocznia przepuszcza złe zmiany	Tak, jeśli pętlę wyłącza konfiguracja

„Nic nie robić” nie jest opcją bez ryzyka. Raport DORA 2025 podaje, że 90% ankietowanych używa AI w pracy. Bez zatwierdzonego narzędzia inżynierowie używają prywatnych kont bez warunków przetwarzania danych, śladu audytowego i pomiaru: płacisz ryzykiem, a dowodów nie dostajesz.

Rekomenduj C i D razem: C dla zespołów produktowych, D dla jednej pętli z już mocną wyrocznią. Samo B dokłada generowania bez weryfikacji i prowokuje wzorzec „przepustowość w górę, stabilność w dół”.

Jak zbudować business case krok po kroku

Zapisz pytanie decyzyjne i datę decyzji. Na przykład: „Czy finansujemy opcję C dla 12 zespołów w Q1 na podstawie ośmiotygodniowego pilotażu z dwoma zespołami, który kończy się 2026-12-18?”. Notatka bez daty zamienia się w stałą pozycję budżetu.
Zmierz punkt odniesienia z systemów, nie z ankiet. Dla 8–12 tygodni sprzed jakiejkolwiek zmiany weź zaakceptowane zmiany na miesiąc (scalone i niewycofane w ciągu 30 dni), czas realizacji, odsetek zmian kończących się awarią, medianę czasu review, incydenty i poprawki, z definicjami zamrożonymi według przewodnika po frameworkach metryk. Policz dzisiejszy koszt zaakceptowanej zmiany (przewodnik po ekonomii) i pełny miesięczny koszt organizacji dostarczającej.
Wyceń każdą opcję w całości według listy kontrolnej z następnej sekcji. Finanse podają pełny koszt inżyniera, inżynieria podaje użycie, CI i godziny review.
Przedstaw business case jako próg rentowności, tak jak w przykładzie poniżej.
Spisz bramki stopu i regułę decyzyjną przed startem pilotażu. Projekt pilotażu opisuje kohorty, czynniki zakłócające i wielkość próby.
Wypełnij rejestr ryzyk: każde ryzyko dostaje właściciela, wczesny sygnał i sfinansowaną kontrolę.
Zbierz trzy podpisy: CFO pod punktem odniesienia i modelem kosztów, CTO pod bramkami i wyrocznią, a wskazany z nazwiska analityk spoza zespołu pilotażowego pod wynikiem.

Co wchodzi w pełny koszt każdej opcji?

Licencje to najmniejsza ze zmieniających się pozycji; o wyniku decydują użycie, czas review i rachunek za jakość.

Pozycja kosztowa	Skąd liczba	Właściciel	Opcje
Licencje i opłaty za plan	Oferta dostawcy; ceny katalogowe w analizie cen	Zakupy	B, C, D
Użycie rozliczane za zużycie i nadwyżki	Analityka i eksporty narzędzi (zakładki niżej); stawki modeli w hubie modeli	Inżynieria	B, C, D
Moc obliczeniowa CI	Rachunki CI przed i po	Platforma	C, D
Utrzymanie harnessu	Godziny imiennego właściciela reguł, skilli, hooków i bramek	CTO	C, D
Budowa wyroczni	Godziny inżynierów na doprowadzenie testów lub ewaluacji do poziomu, którego wymaga pętla	Tech lead	D
Czas review	Mediana czasu review × zaakceptowane zmiany, po pełnej stawce	Inżynieria	B, C, D
Poprawki	Zmiany wycofane lub przepisane w ciągu 30 dni	Inżynieria	Wszystkie
Incydenty	Incydenty przypisane do zmian × średni koszt incydentu	SRE	Wszystkie
Szkolenia i spadek przy wdrożeniu	Godziny szkoleń; zaplanowany okres niższej przepustowości	Inżynieria	B, C, D
Przegląd bezpieczeństwa, prawny i zakupowy	Godziny jednorazowe plus ewentualne nowe narzędzia	CISO, dział prawny	B, C, D

Jeśli chodzi o użycie, dokumentacja Claude Code od Anthropic podaje, że we wdrożeniach firmowych „the average cost is around $13 per developer per active day and $150-250 per developer per month, with costs remaining below $30 per active day for 90% of users” (sprawdzone 2026-09-26). Traktuj to jako dane dostawcy do planowania i zastąp je danymi z pilotażu. Pętle bez nadzoru kosztują więcej: Tim Sehn z DoltHub opisał około 100 USD w tokenach Claude za godzinę pracy wieloagentowego orkiestratora (2026-01-15) i 3000 USD za tydzień (2026-03-24). To jeden użytkownik i jedna konfiguracja, dlatego opcja D potrzebuje twardego limitu budżetu.

Uwzględnij w budżecie spadek przy wdrożeniu: raport DORA o ROI opisuje krzywą J, czyli początkowy spadek przed zwrotem, według relacji InfoQ z maja 2026 roku (źródło wtórne; raportu nie weryfikowano). Wpisz jego oczekiwaną długość jako założenie, na przykład cztery do sześciu tygodni, i sprawdź je.

Gdzie każde narzędzie raportuje potrzebne dane o kosztach

Koszt zaakceptowanej zmiany wymaga zapisu kosztu z każdego przebiegu agenta. Każde narzędzie zbiera go inaczej.

Panel analityki w planach Team i Enterprise pokazuje adopcję i przypisanie PR-ów, ale nie koszt na użytkownika; koszt w dolarach na użytkownika i na model daje eksport metryki OpenTelemetry claude_code.cost.usage (zobacz zarządzanie kosztami).

W opcji D uruchamiaj każde zadanie bez nadzoru w trybie headless z limitem budżetu. claude -p startuje w trybie uprawnień Manual, więc zatwierdź z góry każde narzędzie, którego potrzebuje pętla, inaczej przebieg zapisze koszt, niczego nie zmieniając:

# Terminal lub CI: jedno zadanie bez nadzoru, limit 5 USD, koszt zapisany z wynikiem
claude -p "Upgrade the date-fns dependency to the latest minor version, fix any failing tests, and stop when npm test passes" \
  --permission-mode acceptEdits --allowedTools "Bash(npm install *)" "Bash(npm test *)" \
  --output-format json --max-budget-usd 5 > run.json
jq '{cost_usd: .total_cost_usd, is_error: .is_error}' run.json

total_cost_usd to szacunek po stronie klienta według cen katalogowych; co miesiąc uzgadniaj go z fakturą.

Plany Codex liczą użycie w pięciogodzinnych i tygodniowych oknach limitu, więc pilotaż „same licencje” pokazuje zapas limitu, a nie koszt. W opcji D uruchamiaj zadania przez codex exec --json: każde zdarzenie turn.completed ma obiekt usage z polami input_tokens, cached_input_tokens, cache_write_input_tokens, output_tokens i reasoning_output_tokens; pomnóż je przez stawki z hubu modeli. Aktualizacja potrzebuje rejestru pakietów, a sandbox workspace-write domyślnie blokuje sieć, więc ten przebieg ją włącza:

# Terminal lub CI: jedno zadanie bez nadzoru, zużycie tokenów na turę zapisane w logu
codex exec --json --sandbox workspace-write -c sandbox_workspace_write.network_access=true \
  "Upgrade the date-fns dependency to the latest minor version, fix any failing tests, and stop when npm test passes" \
  | jq -c 'select(.type == "turn.completed") | .usage' >> usage.jsonl

Nazwy pól i klucz konfiguracji sprawdzono w codex-cli 0.157.1, które nie ma limitu kwotowego na przebieg; ogranicz przebieg limitem czasu zadania CI i bramką limitu wydatków. --sandbox to starszy mechanizm, użyty tutaj, bo dostępu do sieci w profilu uprawnień nie zweryfikowano w 0.157.1; nie łącz go z profilem uprawnień, który OpenAI preferuje jako następcę (uprawnienia i sandboxing).

CLI Cursora uruchamia te same zadania pilotażowe w trybie headless (-p). Jego pól kosztowych, eksportów użycia i rozliczeń planów nie zweryfikowano na dzień 2026-09-26: przed pilotażem poproś Cursor o eksport użycia na użytkownika i na model, który oddziela użycie w ramach planu od nadwyżek.

O ile musi się poprawić wynik, żeby opcja się zwróciła?

Zastąp mnożnik progiem rentowności. Wzór:

próg rentowności (wzrost zaakceptowanych zmian) = dodatkowy miesięczny koszt opcji ÷ pełny miesięczny koszt organizacji dostarczającej

Wynik to procent, o jaki musi wzrosnąć liczba zaakceptowanych zmian przy tym samym zespole i bez naruszenia bramek jakości, żeby uwolniona przepustowość pokryła koszt opcji.

Przykład poniżej używa danych ilustracyjnych dla organizacji z 40 inżynierami. Każdą wartość zastąp liczbami od swojego działu finansów.

Dane wejściowe (ilustracyjne)	Wartość
Pełny miesięczny koszt inżyniera	15 000 USD (ok. 94 USD za godzinę przy 160 godzinach)
Miesięczny koszt organizacji dostarczającej	40 × 15 000 USD = 600 000 USD
Opcja C: licencje plus użycie, wycenione według górnej granicy podanego przez Anthropic przedziału 150–250 USD miesięcznie	40 × 250 USD = 10 000 USD
Opcja C: właściciel harnessu, pół etatu	7 500 USD
Opcja C: dodatkowa moc obliczeniowa CI	1 500 USD
Jednorazowo: szkolenia, 8 godzin na inżyniera	40 × 8 × 94 USD ≈ 30 000 USD
Jednorazowo: przegląd bezpieczeństwa, prawny i zakupowy	15 000 USD
Jednorazowo: spadek przy wdrożeniu, założone cztery tygodnie (dolna granica przedziału powyżej) z przepustowością niższą o 10%	0,10 × 600 000 USD = 60 000 USD
Koszty jednorazowe rozłożone na 12 miesięcy	105 000 USD ÷ 12 = 8 750 USD
Opcja C: dodatkowy koszt miesięczny	27 750 USD
Próg rentowności: wzrost zaakceptowanych zmian	27 750 USD ÷ 600 000 USD ≈ 4,6%

Pozycja użycia zastępuje tu licencje plus użycie; jeśli kupujesz licencje, wstaw cenę z oferty (analiza cen) plus spodziewane nadwyżki. Czas review nie ma osobnej pozycji, bo recenzenci są już w 600 000 USD: dodatkowe obciążenie review widać jako mniej zaakceptowanych zmian, a wyłapuje je bramka obciążenia review.

Poprzeczka wydaje się zawieszona nisko i właśnie to warto powiedzieć CFO: ryzykiem nie jest koszt narzędzi, tylko rachunek za jakość. Jeśli poprawki i incydenty wzrosną tak, jak zmierzył Faros, zjedzą pięcioprocentowy wzrost, zanim ktokolwiek to zauważy, dlatego bramki stopu poniżej to przede wszystkim bramki jakości.

Zapisz oczekiwany wynik jako trzy scenariusze zamiast jednej liczby:

Zerowy: brak mierzalnego wzrostu. Organizacja wydała koszt pilotażu, podany w notatce, i dowiedziała się, gdzie ma słabą weryfikację.
Poniżej progu: kontynuuj tylko wtedy, gdy bramki jakości wytrzymały, a trend rośnie.
Cel osiągnięty: powyżej progu przy utrzymanych bramkach jakości. Skaluj na następną kohortę, nie na wszystkich.

Zaoszczędzony czas to nie zaoszczędzone pieniądze. Notatka mówi, dokąd trafia uwolniona przepustowość: pozycje z backlogu wydane wcześniej, rekrutacja, której nie trzeba robić, zakończony kontrakt z dostawcą. Inaczej oszczędność nie dociera do rachunku wyników.

Bramki stopu: spisz je, zanim ruszą pieniądze

Bramki zamieniają wniosek budżetowy w eksperyment. Dopasuj progi do swojego punktu odniesienia; zachowaj strukturę.

Bramka	Metryka	Próg startowy	Kiedy sprawdzana	Działanie po przekroczeniu
Stabilność	Odsetek zmian kończących się awarią w kohorcie pilotażowej	Najwyżej 2 punkty powyżej punktu odniesienia	Co tydzień	Dwa przekroczenia z rzędu zatrzymują pilotaż
Poprawki	Zaakceptowane zmiany wycofane lub przepisane w ciągu 30 dni	Nie więcej niż w punkcie odniesienia	Co dwa tygodnie	Wstrzymaj nowe pętle; znajdź brakujący test
Obciążenie review	Mediana czasu review na zaakceptowaną zmianę	Najwyżej 20% powyżej punktu odniesienia	Co tydzień	Ogranicz rozmiar pull requestów; dodaj agenta do review, zanim dodasz licencje
Zmiany chronione	Scalenia bez review dotykające uwierzytelniania, płatności, schematu lub migracji	Zero	Stale, wymuszane w CI	Zatrzymaj pętlę, która je wytworzyła
Koszt	Koszt zaakceptowanej zmiany (wszystkie sześć składników z przewodnika po ekonomii)	Nie wyższy niż w punkcie odniesienia do 8. tygodnia	Co miesiąc	Przedłuż raz o cztery tygodnie, potem zakończ
Limit wydatków	Wydatki na użycie na pętlę tygodniowo	Stały limit kwotowy na pętlę	Stale, flagą budżetu lub w LLM gateway	Przebieg się zatrzymuje; operator go przegląda

Reguła decyzyjna, wpisana do notatki przed startem pilotażu, brzmi tak: „Skalujemy opcję C na kolejnych sześć zespołów, jeśli po ośmiu tygodniach liczba zaakceptowanych zmian na inżyniera w kohorcie pilotażowej jest co najmniej o 10% wyższa niż w dobranej kohorcie kontrolnej, koszt zaakceptowanej zmiany nie jest wyższy niż w kontrolnej i żadna bramka jakości nie została przekroczona w dwóch kolejnych cotygodniowych pomiarach. Kończymy, jeśli którakolwiek bramka stabilności lub zmian chronionych zostanie przekroczona dwukrotnie. W pozostałych przypadkach przedłużamy raz o cztery tygodnie i kończymy”.

Próg 10% jest celowo wyższy niż próg rentowności 4,6%: różnica to margines wykrywalności, żeby wahania między tygodniami w dwóch małych kohortach nie udawały zysku. Ustal go z własnej tygodniowej zmienności według przewodnika po projekcie pilotażu, zamiast kopiować 10%.

Rejestr ryzyk dla business case’u inżynierii agentowej

Ryzyko	Wczesny sygnał	Kontrola	Właściciel
Stabilność spada wraz ze wzrostem liczby zmian (DORA 2025; Faros 2026)	Rośnie odsetek zmian kończących się awarią i liczba incydentów na zmianę	Bramki jakości powyżej; testy i fitness functions (funkcje przystosowania) przed autonomią	CTO
Review staje się wąskim gardłem	Rośnie wiek kolejki review i rozmiar pull requestów	Budżet rozmiaru PR; agenci do review; praktyki kolejki review	Tech lead
Przekroczenie kosztów użycia	Tygodniowe wydatki na pętlę powyżej planu	Limity budżetu na przebieg; alerty wydatków; zarządzanie kosztami	Finanse inżynierii
Prompt injection lub wyciek sekretów	Szerokie uprawnienia agentów; niezaufana treść zgłoszeń w promptach	Tożsamości agentów o wąskim zakresie; model zagrożeń dla agentów	CISO
Ekspozycja na roszczenia IP i licencyjne	Brak zasad dotyczących pochodzenia kodu i warunków danych u dostawców	Przegląd warunków dostawców; lista kontrolna prawa i IP	Radca prawny
Uzależnienie od dostawcy lub zmiana cen	Procesy zależą od zamkniętych funkcji jednego dostawcy	Przenośne `AGENTS.md`, skille i MCP; lock-in i przenośność	CTO
Zanik umiejętności, juniorzy przestają się uczyć	Seniorzy nie potrafią wyjaśnić scalonych zmian	Celowa praktyka i rotacja w review; wewnętrzne badanie Anthropic z 2025-12-02 nazywa to „paradox of supervision”	Menedżerowie inżynierii
Pomiar jest naginany lub zakłócony	Zmieniona definicja „zaakceptowanej zmiany”; tylko ochotnicy	Definicje zamrożone w notatce; dobrana kohorta kontrolna; analityk spoza zespołu	CFO

Jak sprawdzić sam business case

Notatkę sprawdza się jak kod: na dowodach, których zespół pilotażowy nie wytworzył sam.

Punkt odniesienia pochodzi z systemu kontroli wersji, CI i systemu incydentów, a CFO podpisuje go jako pierwszy.
Każda zmiana z pilotażu niesie swój pakiet dowodów: zaliczone testy, zapis review, koszt przebiegu.
Wynik liczy zewnętrzny analityk względem dobranej kohorty kontrolnej w tych samych tygodniach.
Decyzja wynika ze spisanej wcześniej reguły; każde uchylenie zapisuje się z powodem.

You are helping me build a baseline for a business case. Work read-only: do not edit, commit or push anything.

In this repository, for the 12 weeks ending today:
1. Use git log on the main branch to count merged changes per week.
2. Find reverts: commits whose message starts with "Revert" or that reference a reverted commit hash. Report the share of merged changes reverted within 30 days.
3. If the GitHub CLI (gh) is authenticated, list merged pull requests with gh pr list --state merged --limit 500 --json number,createdAt,mergedAt,additions,deletions and compute the median hours from creation to merge and the median changed lines per pull request.
4. Output one table with one row per week and these columns: merged changes, reverts, median hours to merge, median pull request size.
5. List every assumption you made and every number you could not compute, with the reason.

Read the attached business-case memo. Act as a CFO who has read METR's 2025 randomised trial, DORA's 2025 report and Faros AI's April 2026 telemetry report, and who approves nothing without a baseline.

List, in order of severity:
1. Every number that has no source, or whose source is the vendor selling the tool.
2. Every cost line that is missing, especially review time, rework, incidents, CI and the adoption dip.
3. Every claim that treats time saved as cash saved without saying where the freed capacity goes.
4. Every stop gate that is missing a threshold, an owner or an action.
5. The three questions you would ask in the budget meeting.

Do not rewrite the memo. Quote the sentence each finding refers to.

Szablon notatki decyzyjnej

Skopiuj go do swojego systemu dokumentów. Notatka to jedna strona plus rejestr ryzyk.

# Notatka decyzyjna: <opcja> dla inżynierii agentowej

Wnioskowana decyzja: <finansowanie opcji X dla N zespołów, kwota, okres>
Data decyzji: <data>   Koniec pilotażu: <data>
Podpisujący: CFO (punkt odniesienia, model kosztów) · CTO (bramki, wyrocznia) · Analityk (wynik): <imię i nazwisko>

## 1. Rozważane opcje
| Opcja | Dodatkowy koszt miesięczny | Co może udowodnić | Główne ryzyko |
| --- | --- | --- | --- |
| A. Nic nie robić | | | |
| B. Same licencje | | | |
| C. Wspólny harness | | | |
| D. Pilotaż fabryki | | | |
Rekomendacja: <opcja>, ponieważ <jedno zdanie>.

## 2. Punkt odniesienia (ostatnie 12 tygodni, z systemów źródłowych)
Zaakceptowane zmiany na miesiąc: ___  Czas realizacji (mediana): ___
Odsetek zmian kończących się awarią: ___  Mediana czasu review na zmianę: ___
Poprawki (wycofane w ciągu 30 dni): ___  Incydenty: ___
Miesięczny koszt dostarczania: ___  Koszt zaakceptowanej zmiany: ___

## 3. Pełny koszt rekomendowanej opcji
Licencje ___ · Użycie ___ · CI ___ · Właściciel harnessu ___ · Budowa wyroczni ___
Review ___ · Szkolenia i spadek przy wdrożeniu ___ · Przegląd bezpieczeństwa i prawny ___

## 4. Próg rentowności i scenariusze
Próg rentowności (wzrost zaakceptowanych zmian): ___%
Zerowy: <co wydajemy i czego się uczymy>  Poniżej progu: <działanie>  Cel osiągnięty: <działanie>
Dokąd trafia uwolniona przepustowość: <pozycje z backlogu / uniknięta rekrutacja / zakończony kontrakt>

## 5. Bramki stopu (patrz tabela) i reguła decyzyjna
<reguła decyzyjna, dosłownie>

## 6. Rejestr ryzyk (patrz tabela)

## 7. Cytowane dowody
<wydawca, tytuł, data dla każdej liczby spoza firmy>

Co zatapia business case inżynierii agentowej na przeglądzie?

Notatka cytuje mnożnik od dostawcy. CFO pyta o populację i metodę. Zastąp go obliczeniem progu rentowności.

Punkt odniesienia zmierzono po wdrożeniu. Prywatne konta skaziły „przed”. Porównuj z kohortą kontrolną i napisz to wprost.

Do pilotażu zgłosili się tylko ochotnicy. Entuzjaści są szybsi z każdym narzędziem, a METR pisze, że selekcja utrudnia interpretację jego danych z 2026 roku. Naprawa: dobierz kohorty według typu zespołu i kodu (projekt pilotażu).

Przepustowość wzrosła, a nikt nie policzył rachunku za jakość. Naprawa: przelicz koszt zaakceptowanej zmiany z poprawkami i incydentami.

Licencje ukryły koszt krańcowy. Wyceń użycie z pilotażu według stawek API w scenariuszu skalowania.

Spadek odczytano jako porażkę. Oceniaj ostatnie cztery tygodnie, nie pierwsze.

Co dalej z business case’em

Ekonomia oprogramowania budowanego przez agentów Koszt zaakceptowanej zmiany, jedyna metoda ROI, której używa ta notatka, z szablonem arkusza.

Pilotaż, który czegoś dowodzi Kohorty, czynniki zakłócające, wielkość próby i reguła decyzyjna, na której opiera się notatka.

Jak zmieniają się zespoły, role i zatrudnienie Dokąd trafia uwolniona przepustowość po zatwierdzeniu business case’u.

Raportowanie inżynierii AI zarządowi i radzie nadzorczej Kwartalna strona, która śledzi zatwierdzony business case po pilotażu.