Paradoks Jevonsa w inżynierii AI

1. Koncepcja i istota (Przegląd i problem systemowy)

Paradoks Jevonsa w inżynierii AI to efekt systemowy, w którym obniżenie kosztów i opóźnień generowania kodu nie zmniejsza całkowitego wolumenu pracy inżynierskiej, lecz zwiększa go do granic, gdzie wąskim gardłem staje się nie inference, ale weryfikacja, refaktoryzacja, code review oraz utrzymanie architektury. Klasyczna formuła Jevonsa: wzrost efektywności wykorzystania zasobu obniża jego jednostkowy koszt i stymuluje większą łączną konwersję. W AI engineering zasobem nie jest węgiel, lecz „plausible code change": diff, patch, scaffold, migracja, test, PR.

Technicznie problem można sformułować następująco:

C_gen ↓  =>  D_gen ↑↑  =>  ReviewLoad ↑↑  =>  ReviewLatency ↑↑  =>  Burnout ↑↑ + TechDebt ↑↑

gdzie C_gen to krańcowy koszt wygenerowania jednego akceptowalnego draft change, D_gen to łączny popyt na zmiany, a ReviewLoad to obciążenie procesu weryfikacji. Jeśli ReviewLoad przekracza reviewer_capacity, system nie staje się szybszy; staje się bardziej toksyczny.

W epoce przed-AI tworzenie PR było kosztowne: inżynier pisał kod ręcznie, utrzymywał kontekst w głowie i dopiero potem wysyłał zmianę do review. Generowanie kodu przez AI przekształca ten cykl w proces typu System 1: szybki, imitacyjny, wysokoczęstotliwościowy. Model generuje diff w ciągu sekund. Ale review to System 2: powolny, semantyczny, wyczerpujący zasób. Gdy koszt draftu spada o rząd wielkości, zespół intuicyjnie zwiększa liczbę draftów, nie zwiększając proporcjonalnie capacity for semantic verification.

Mechanika taniejącej generacji łączy kilka czynników infrastrukturalnych:

• FlashAttention i zoptymalizowane kernels zmniejszają compute cost dla long-context inference.
• RoPE i nowoczesne schematy pozycji pozwalają stabilnie pracować z dużymi kontekstami.
• KV Cache redukuje latency w wieloetapowych ReAct loop i sesjach agentowych.
• Unpadding i dynamic batching zmniejszają overhead przy przetwarzaniu promptów o zmiennej długości.
• Warstwy retrieval/reranking przypominające ModernBERT zapewniają tańszy code search, dzięki czemu model otrzymuje więcej relewantnego kontekstu za mniejsze pieniądze.
• Fast Patching i generowanie uwzględniające diff zmniejszają liczbę tokenów potrzebnych do zastosowania zmiany.

Każdy z tych czynników z osobna poprawia throughput. Razem tworzą ekonomię, w której „sprawdzenie kolejnej opcji" staje się niemal darmowe. Ale „darmowy draft" nie oznacza „darmowej zmiany w produkcji". Zmiana w produkcji wymaga:

1. Zrozumienia, dlaczego dany diff istnieje.
2. Sprawdzenia, że nie łamie invariantów.
3. Potwierdzenia, że nie wprowadza ukrytego długu technicznego.
4. Oceny wpływu na latency, cost, security, operability.
5. Gotowości do utrzymania kodu w przyszłości.

Ekonomię AI codegen często mierzy się błędnie:

Krytyczny błąd myślenia architektonicznego: optymalizacja tokens/sec i time-to-first-diff przy ignorowaniu time-to-verified-merge. Paradoks Jevonsa w AI engineering nie polega na tym, że AI źle generuje kod. Polega na tym, że system staje się szybszy na wejściu, ale wolniejszy na wyjściu, ponieważ ludzka weryfikacja nie skaluje się przez GPU.

2. Architektura i wewnętrzna mechanika (Taksonomia i model mentalny)

Pełny kontur AI-assisted engineering składa się z trzech płaszczyzn:

1. Generation plane – szybkie generowanie draftów, patchy, scaffoldów.
2. Verification plane – testowanie, analiza statyczna, review, bramki bezpieczeństwa.
3. Governance plane – budżety, polityki, metryki, rollbacki, granice odpowiedzialności (owner boundaries).

Paradoks pojawia się, gdy Generation plane skaluje się sprzętowo, a Verification plane pozostaje ograniczony społecznie.

┌────────────────────────────┐
│ Engineer / Product Request │
└─────────────┬──────────────┘
              │ task + constraints + repo state
              ▼
┌────────────────────────────┐
│ Context Builder            │
│ - code search / ModernBERT │
│ - MCP resources            │
│ - dependency graph         │
│ - policy manifest          │
└─────────────┬──────────────┘
              │ prompt bundle + token budget
              ▼
┌──────────────────────────────────────────────┐
│ Model Runtime                                │
│ FlashAttention | RoPE | KV Cache | Unpadding │
│ ReAct loop / tool calls / draft generation   │
└─────────────┬────────────────────────────────┘
              │ raw diff / patch / files
              ▼
┌────────────────────────────┐
│ Fast Patching + Normalizer │
│ - split large diff         │
│ - enforce patch size       │
│ - add provenance           │
└─────────────┬──────────────┘
              │ CodegenResult
              ▼
┌────────────────────────────┐
│ Verification Plane         │
│ Pydantic AI | Guardrails   │
│ unit/integration tests     │
│ SAST/SCA/secret scan       │
│ reviewer queue             │
└─────────────┬──────────────┘
              │ pass / fail / request changes
              ▼
┌────────────────────────────┐
│ Merge / Deploy / Telemetry │
└─────────────┬──────────────┘
              │ feedback: latency, defects, churn
              ▼
┌────────────────────────────┐
│ Governance Plane           │
│ budgets, quotas, rollback  │
│ review load, tech debt     │
└────────────────────────────┘

Taksonomia komponentów:

• Request: zadanie inżynierskie, intencja biznesowa, ograniczenia, poziom ryzyka.
• Context Builder: zbiera relewantne pliki, testy, dokumentację, poprzednie PR. Wykorzystuje retrieval, embeddings, rerankers.
• Model Runtime: warstwa inference. KV Cache zmniejsza powtarzalny koszt obliczeniowy w wieloetapowych sesjach; FlashAttention optymalizuje attention; Unpadding redukuje waste w batchingu.
• ReAct loop: cykliczny agent reason -> act -> observe. Przydatny, ale przy tanich tokenach łatwo generuje zbędne iteracje.
• Fast Patching: generowanie minimalnego diff zamiast przepisywania całych plików. Obniża koszt, ale może zwiększyć liczbę drobnych zmian.
• Pydantic AI: walidacja struktury wyjścia, np. CodegenResult, ReviewDecision, PatchPolicy.
• Guardrails: ograniczenia dotyczące ścieżek, zależności, wzorców sekretów, warstw architektury, kontraktów API.
• Reviewer: ludzka weryfikacja semantyki, konsekwencji architektonicznych, bezpieczeństwa operacyjnego.
• CI/CD: deterministyczna weryfikacja: tests, build, deploy, canary, rollback.
• Governance: metryki, budżety, SLO, polityki właścicieli, rozliczanie długu technicznego.

Model mentalny paradoksu:

Unit cost of draft ↓
Perceived risk of draft ↓
Retry frequency ↑
Draft volume ↑
Review queue ↑
Reviewer attention per PR ↓
Acceptance of shallow diffs ↑
Hidden coupling ↑
Future change cost ↑

To nie liniowe „więcej kodu". To zmiana rozkładu uwagi. Gdy draft jest tani, inżynierowie zaczynają wysyłać zmiany, których wcześniej nie tworzyli, bo nie chcieli marnować czasu. Recenzenci reagują formalnie, bo nie nadążają. Architektura eroduje nie przez jeden zły PR, ale przez tysiąc „przybliżonych, akceptowalnych" zmian.

3. Techniczny pipeline cyklu życia

Cykl życia AI-assisted change ma cztery etapy. Każdy etap powinien mieć kontrakt, budżet i metrykę.

1. Formułowanie / stan wejściowy

Wejście to nie „zrób mi feature", ale ustrukturyzowany kontrakt:

{
  "task_id": "T-8842",
  "repo": "payments-service",
  "base_sha": "a7f3c91",
  "objective": "Add idempotency key to refund API",
  "risk_tier": "high",
  "allowed_paths": [
    "src/refund/**",
    "tests/refund/**",
    "openapi/refund.yaml"
  ],
  "forbidden_paths": [
    "src/auth/**",
    "infra/iam/**"
  ],
  "constraints": {
    "max_patch_lines": 180,
    "context_budget_tokens": 24000,
    "max_new_tokens": 4096,
    "required_tests": true,
    "require_backward_compatible_api": true,
    "no_new_external_dependencies": true
  },
  "verification_gates": [
    "unit",
    "contract",
    "security",
    "arch_lint",
    "reviewer"
  ]
}

Kluczowe pola:

• risk_tier: określa głębokość weryfikacji.
• allowed_paths: ogranicza blast radius.
• max_patch_lines: zapobiega gigantycznym AI-PR.
• context_budget_tokens: kontroluje koszt i jakość retrieval.
• verification_gates: lista obowiązkowych sprawdzeń.

2. Transformacja

Context Builder formuje prompt bundle:

def build_context(request: CodegenRequest) -> PromptBundle:
    relevant_files = code_search(
        query=request.objective,
        repo=request.repo,
        top_k=12,
        reranker="modernbert-code-v2"
    )
    dependency_graph = load_dependency_graph(request.repo, request.base_sha)
    policy = load_policy(request.repo, request.risk_tier)

    return PromptBundle(
        task=request,
        files=relevant_files,
        graph=dependency_graph,
        policy=policy,
        token_budget=request.constraints.context_budget_tokens
    )

Na tym etapie ważne jest nie tylko podanie modelowi więcej kontekstu, ale podanie mu ograniczonego, ustrukturyzowanego, zwalidowanego kontekstu. Bez tego rośnie ryzyko long-context degradation: model widzi wiele plików, ale gubi inwarianty.

3. Wykonanie / inference

Model generuje diff poprzez ReAct loop lub direct patch generation:

from pydantic_ai import Agent

agent = Agent(
    model="openai:gpt-5.2",
    output_type=CodegenResult,
    system_prompt=CODEGEN_SYSTEM_PROMPT
)

result: CodegenResult = agent.run_sync(
    prompt_bundle.render(),
    tools=mcp_tools,
    guardrails=[
        patch_size_guard,
        allowed_paths_guard,
        secret_detector_guard,
        dependency_policy_guard
    ]
)

Oczekiwane wyjście:

{
  "patch_id": "P-10492",
  "task_id": "T-8842",
  "diff": "diff --git a/src/refund/api.py b/src/refund/api.py\n...",
  "changed_files": [
    "src/refund/api.py",
    "tests/refund/test_idempotency.py"
  ],
  "tokens_used": {
    "input": 18420,
    "output": 2140
  },
  "cost_usd": 0.0214,
  "p95_latency_ms": 1420,
  "confidence": 0.82,
  "guardrail_flags": [],
  "verification_plan": [
    "unit",
    "contract",
    "security"
  ]
}

Fast Patching oznacza tu generowanie minimalnego diff, ale niekoniecznie minimalnej zmiany. Jeśli model robi 40 drobnych PR zamiast jednego spójnego architektonicznie, throughput rośnie, ale load review również.

4. Obsługa feedbacku

Po generacji zaczyna się prawdziwa inżynieria:

def verify_patch(result: CodegenResult, request: CodegenRequest) -> VerificationDecision:
    structural = validate_structure(result)
    security = run_security_gates(result.diff, request)
    tests = run_required_tests(result, request)
    architecture = check_architecture_rules(result, request)
    reviewer_load = estimate_review_load(result)

    return VerificationDecision(
        patch_id=result.patch_id,
        structural_ok=structural.ok,
        security_ok=security.ok,
        tests_ok=tests.ok,
        architecture_ok=architecture.ok,
        reviewer_load_score=reviewer_load.score,
        merge_allowed=all([
            structural.ok,
            security.ok,
            tests.ok,
            architecture.ok,
            reviewer_load.score < request.risk_tier.review_threshold
        ])
    )

Wynik review powinien być nie „LGTM", ale ustrukturyzowanym sygnałem:

{
  "patch_id": "P-10492",
  "verdict": "request_changes",
  "review_minutes": 34,
  "semantic_risk": 0.71,
  "reviewer_load_score": 0.83,
  "issues": [
    "idempotency key not validated against tenant_id",
    "contract test missing for duplicate request",
    "error response changes public API shape"
  ]
}

Paradoks Jevonsa jest kontrolowany właśnie na tym etapie: jeśli reviewer_load_score nie mieści się w SLO, system generuje więcej zmian, niż może bezpiecznie zweryfikować.

4. Praktyczne scenariusze użycia w produkcji

01. Zespół platformowy z AI codegen dla szablonów serwisowych

Sytuacja: Platforma obsługuje 120 mikrousług. Zespół wdraża AI codegen do tworzenia service scaffolding, config, health checks, OpenAPI stubs, CI templates. Jednostkowy koszt scaffolda spada z 4 godzin do 15 minut. Po tygodniu liczba PR rośnie o 300%.

Pierwotne metryki wyglądają pozytywnie:

median time-to-first-diff: 4h -> 12m
cost per scaffold generation: $0.03
p95 inference latency: 1.6s
PR volume: +310%

Ale po 3 tygodniach:

p95 review latency: 2d -> 6d
reviewer utilization: 55% -> 108%
defect escape rate: 0.7% -> 2.9%
churn within 14d: 8% -> 27%

Przyczyna: AI szybko generuje „prawdopodobnie działające" szablony, ale nie odpowiada za long-term operability. Każdy scaffold dodaje:

• nowe dependency;
• nowe klucze konfiguracji;
• nowe joby CI;
• nowe reguły alertów;
• nową surface area dla security;
• nowe zobowiązania do utrzymania.

Rozwiązanie architektoniczne:

1. Wprowadź risk_tier dla scaffoldów: low, medium, high.
2. Ogranicz max_patch_lines oraz max_files_per_pr.
3. Wymagaj contract tests oraz security baseline.
4. Automatyzuj golden paths: nie generuj kodu w próżni, ale wypełniaj sprawdzone template slots.
5. Wprowadź quota dla reviewerów: nie więcej niż N high-risk PR na recenzenta dziennie.
6. Mierz cost per verified service, a nie cost per generated diff.

Treść polityki:

{
  "policy_id": "platform-scaffold-v3",
  "max_patch_lines": 220,
  "max_files_per_pr": 18,
  "required_tests": ["unit", "contract", "security"],
  "forbidden_paths": ["infra/iam/**", "secrets/**"],
  "reviewer_quota": {
    "high_risk_pr_per_day": 4,
    "medium_risk_pr_per_day": 8
  }
}

Wynik: throughput staje się stabilny, ponieważ system przestaje zamieniać tanią generację w darmowy dług.

02. Zespół produktowy z vibe coding MVP

Sytuacja: Zespół szybko buduje MVP. Inżynierowie używają AI do generowania UI, API, migracji, fixture'ów testowych. Po 2 tygodniach produkt wygląda na gotowy. Po 6 tygodniach – zespół nie może bezpiecznie zmienić żadnego modułu.

Objawy:

• każdy plik zawiera AI-wygenerowane wariacje tej samej logiki;
• istnieją trzy wersje tego samego auth helpera;
• kontrakty API nie są zsynchronizowane z typami frontendowymi;
• testy są generowane pod implementację, a nie pod specyfikację;
• warstwy architektury są łamane przez „szybkie rozwiązania";
• context degradation: inżynierowie nie pamiętają, dlaczego istnieje każdy diff.

Przyczyna techniczna: System 1 codegen tworzy lokalnie prawdopodobny kod, ale nie utrzymuje globalnych invariantów. W vibe coding paradoks Jevonsa objawia się eksplozją „zbędnych, ale prawdopodobnych" zmian.

Rozwiązanie architektoniczne:

1. Wprowadź module boundary contracts.
2. Zabroń patchom AI zmieniającym więcej niż jeden moduł bez architektonicznego review.
3. Używaj Pydantic AI do walidacji DTO, odpowiedzi API, konfiguracji.
4. Dodaj architecture lint jako gate w CI.
5. Obowiązkowo przechowuj intent metadata: dlaczego diff istnieje, jaki kontrakt realizuje.
6. Wprowadź tygodniowy debt budget: nie więcej niż 20% zmian bez testów lub z wysokim ryzykiem semantycznym.

Przykład kontraktu modułu:

class UserSessionContract(BaseModel):
    user_id: UUID
    tenant_id: UUID
    issued_at: datetime
    expires_at: datetime
    scopes: set[Literal["read:profile", "write:profile"]]

    @model_validator(mode="after")
    def validate_expiry(self):
        if self.expires_at <= self.issued_at:
            raise ValueError("expires_at must be after issued_at")
        return self

Jeśli AI generuje logikę sesji bez walidacji przez kontrakt, patch jest odrzucany przed review. Zmniejsza to liczbę „śmieciowych" zmian, nie zabijając prędkości.

03. Masowa migracja lub refaktoryzacja przez AI Fast Patching

Sytuacja: Zespół przeprowadza migrację z legacy API na new API w monorepo. AI generuje 4,000 patchy nocą. Każdy patch jest mały: zamień endpoint, zaktualizuj client, dodaj test. Na pierwszy rzut oka – idealny use case.

Ryzyka:

• 4,000 PR to nie 4,000 zmian; to 4,000 punktów review.
• Małe patche mogą być semantycznie niebezpieczne.
• Model może „zapomnieć" edge case w ścieżce 1%.
• Drift wersji zależności może przejść niezauważony.
• Kolejność merge tworzy ukryte konflikty.
• Rollback jest skomplikowany, ponieważ zmiany są rozproszone.

Rozwiązanie architektoniczne:

1. Używaj batched Fast Patching, ale z merge budget.
2. Grupuj patche według blast radius: jedna logiczna migracja na PR, nie jeden mechaniczny diff.
3. Dodaj semantic tests, a nie tylko snapshot tests.
4. Używaj canary deploy według tenant / feature flag.
5. Prowadź migration ledger: każdy patch musi mieć provenance, owner, dowód weryfikacji.
6. Mierz regression rate per 1000 patches, rollback count, post-merge defect age.

Przykład wpisu w ledgerze:

{
  "migration_id": "MIG-2026-04",
  "patch_id": "P-10492",
  "logical_change": "replace legacy refund endpoint with idempotent v2",
  "blast_radius": "payments-service/refund",
  "tests": ["unit", "contract", "e2e"],
  "canary_percent": 5,
  "rollback_target": "a7f3c91",
  "verified_by": ["ci", "reviewer-42", "security-bot"]
}

W produkcji takie podejście przekształca AI codegen z generatora szumu w narzędzie zarządzanej transformacji.

5. Podwodne skały, typowe błędy i bezpieczeństwo

Główne ryzyka wdrożenia

1. Review bottleneck migration
   Zamiast oszczędzać czas, AI przenosi czas z pisania kodu do review. Zespół widzi szybki diff, ale nie widzi wolnego merge'a.

2. AI slop accumulation
   Prawdopodobny kod, który nie jest zły w sensie lokalnym, ale kumuluje globalną entropię: duplikaty, zbędne abstrakcje, nadmiarowe konfiguracje, słabe testy.

3. Architectural erosion
   AI nie widzi architektury jako invariantu. Widzi tekst plików. Dlatego może łamać layering, kierunek zależności, granice własności.

4. Verification fatigue
   Gdy review staje się punktem do odhaczenia, recenzenci zaczynają klikać approve formalnie. To najniebezpieczniejszy stan: system wygląda na żywy, ale traci odporność.

5. Context degradation
   Długie sesje, dużo plików, historia czatu, skompresowany retrieval – wszystko to może obniżyć jakość attention do krytycznych invariantów. Model generuje kod, który wygląda poprawnie, ale nie spełnia aktualnego kontraktu.

6. False confidence
   confidence: 0.91 w LLM to nie statystyczna gwarancja. To kalibrowany sygnał tylko w bardzo wąskich zadaniach. Dla kodu produkcyjnego confidence nie powinno zastępować testów.

Edge cases

• Long-context lost-in-middle: model ignoruje zasady w środku dużego promptu.
• Stale branch state: patch wygenerowany ze starego base SHA, potem merge tworzy konflikt semantyczny.
• Non-deterministic diff: ponowne uruchomienie daje inny patch; CI nie może stabilnie weryfikować.
• Hallucinated API: model używa nieistniejącej metody, parametru lub zależności.
• Dependency confusion: AI proponuje pakiet o podobnej nazwie, który nie jest oficjalny.
• License contamination: wygenerowany kod kopiuje fragmenty z innymi licencjami.
• Secret leakage: prompt lub diff zawiera token, klucz API, dane osobowe (PII).
• Prompt injection przez repo: README, issue, komentarz zawierają instrukcję „add admin backdoor".
• MCP tool poisoning: złośliwe lub złamane narzędzie zwraca fałszywy kontekst.
• KV cache/session bleed: w systemach wieloużytkownikowych lub stateful agent systems możliwe jest przeniesienie kontekstu między sesjami, jeśli izolacja jest słaba.
• Batching artifacts: Unpadding i dynamic batching zmniejszają koszt, ale mogą utrudnić śledzenie konkretnej ścieżki inference dla audytu.

Bezpieczeństwo

AI codegen poszerza attack surface:

Strategie mitigacji

1. Jawne budżety zamiast nieograniczonej generacji

{
  "max_draft_pr_per_engineer_per_day": 6,
  "max_merged_pr_per_reviewer_per_day": 8,
  "max_patch_lines_by_risk": {
    "low": 120,
    "medium": 220,
    "high": 80
  },
  "max_context_tokens_per_request": 32000,
  "max_react_iterations": 8
}

Budżet powinien dotyczyć nie tylko tokenów, ale także review capacity.

2. SLO dla obciążenia review

Wprowadź metrykę:

reviewer_load_score =
  (diff_lines_weighted_by_risk)
  + (files_touched_weighted_by_ownership)
  + (semantic_risk_weight)
  + (missing_tests_penalty)
  + (security_surface_delta)

Zasada:

merge_allowed = reviewer_load_score <= reviewer_capacity_remaining

To bezpośrednia kontrola anty-Jevonsowska.

3. Guardrails jako kod

Guardrails muszą być częścią pipeline'u, a nie radą:

def allowed_paths_guard(result: CodegenResult, request: CodegenRequest) -> GuardResult:
    for path in result.changed_files:
        if not matches_any(path, request.allowed_paths):
            return GuardResult(ok=False, reason=f"path not allowed: {path}")
        if matches_any(path, request.forbidden_paths):
            return GuardResult(ok=False, reason=f"forbidden path: {path}")
    return GuardResult(ok=True)

4. Pydantic AI dla kontraktów

Używaj Pydantic AI tam, gdzie wyjście musi być ustrukturyzowane:

• CodegenRequest
• CodegenResult
• ReviewDecision
• PatchPolicy
• VerificationPlan
• MigrationLedgerEntry

Zmniejsza to prawdopodobieństwo, że model zwróci „ładny tekst" zamiast inżyniersko zwalidowanego artefaktu.

5. Automatyczna weryfikacja przed review

Review nie powinien być pierwszą linią obrony. Przed nim muszą przejść:

• unit tests;
• contract tests;
• integration tests;
• property-based tests;
• SAST;
• SCA;
• secret scan;
• architecture lint;
• polityka zależności;
• performance smoke;
• dry-run migracji.

Ludzki review powinien sprawdzać to, czego nie da się zweryfikować deterministycznie: intencję architektoniczną, poprawność produktową, konsekwencje operacyjne.

6. Funkcje sprawności architektonicznej (Architectural fitness functions)

Używaj sprawdzeń:

- dependency direction must not violate layer map
- public API changes require contract diff
- no new cross-module private imports
- no new secrets in config
- no unowned files in production paths
- no duplicate helper implementations above threshold

Takie fitness functions czynią architectural erosion mierzalnym.

7. Provenance i ślad audytowy

Każda zmiana wspomagana przez AI powinna mieć:

{
  "patch_id": "P-10492",
  "model": "gpt-5.2",
  "prompt_hash": "sha256:...",
  "context_hash": "sha256:...",
  "base_sha": "a7f3c91",
  "tools_used": ["mcp:github", "mcp:ci"],
  "guardrail_results": [],
  "reviewer_id": "u-42",
  "verification_evidence": ["ci-run-8821", "security-scan-991"]
}

Bez provenance niemożliwe jest zbadanie regresji lub incydentu.

8. Rate limiting i circuit breaker

Jeśli p95 review latency przekracza SLO, system powinien automatycznie:

• zmniejszyć dopuszczalną liczbę draft PR;
• podnieść próg pokrycia testami;
• ograniczyć high-risk paths;
• wymagać pair review;
• blokować batch migrations do momentu stabilizacji kolejki.

To analogia backpressure w systemach strumieniowych.

9. Red teaming AI codegen

Regularne testy:

• prompt injection przez README;
• malicious response z narzędzia MCP;
• hallucinated dependency;
• sekrety w wygenerowanym diff;
• snippet zanieczyszczony licencją;
• patch naruszający architekturę;
• modyfikacja ścieżki auth wysokiego ryzyka.

Wynik red teamingu powinien wchodzić w skład polityki release.

10. Zmiana metryki sukcesu

Błędna metryka:

lines generated per hour

Prawidłowe metryki:

verified changes per reviewer-hour
defect escape rate per 1000 AI-assisted merges
time-to-verified-merge p95
reviewer load saturation
architecture violation count
rollback rate per AI-assisted deploy
cost per production-ready change

Paradoks Jevonsa w AI engineering zostaje pokonany nie wtedy, gdy zespół generuje więcej kodu, ale wtedy, gdy system staje się zdolny bezpiecznie weryfikować więcej zmian na jednostkę uwagi.