Jevons Paradox in AI Engineering(Парадокс Джевонса в інженерії ШІ (Jevons Paradox))

1. Концепція та суть (Огляд та системна проблема)

Парадокс Джевонса в інженерії ШІ — це системний ефект, при якому зниження вартості та затримки генерації коду не зменшує загальний обсяг інженерної роботи, а збільшує його до межі, де вузьким місцем стають не inference, а верифікація, рефакторинг, рев'ю та утримання архітектури. Класична формула Джевонса: підвищення ефективності використання ресурсу зменшує його одиничну вартість і стимулює більшу сукупну конверсію. В AI engineering ресурсом є не вугілля, а "plausible code change": diff, patch, scaffold, migration, test, PR.

Технічно проблема формулюється так:

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

де C_gen — marginal cost генерації одного прийнятного draft change, D_gen — сукупний попит на зміни, ReviewLoad — навантаження на верифікацію. Якщо ReviewLoad перевищує reviewer_capacity, система не стає швидшою; вона стає більш токсичною.

У до-AI-епоху створення PR було дорогим: інженер писав код руками, тримав контекст у голові, і лише потім відправляв зміну на review. ШІ-кодгенерация перетворює цей цикл на System 1-процес: швидкий, імітаційний, високочастотний. Модель генерує diff за секунди. Але review — це System 2: повільний, семантичний, вичерпний ресурс. Коли вартість draft падає на порядок, команда інтуїтивно збільшує кількість draft, не збільшуючи proportionally capacity for semantic verification.

Механіка здешевлення генерації об'єднує кілька інфраструктурних факторів:

• FlashAttention та оптимізовані kernels зменшують compute cost для long-context inference.
• RoPE та сучасні position schemes дозволяють стабільно працювати з великими контекстами.
• KV Cache знижує latency у багатотурових ReAct loop та agent sessions.
• Unpadding та dynamic batching зменшують overhead при обробці змінних за довжиною prompt.
• ModernBERT-подібні retrieval/reranking шари дають дешевший code search, тож модель отримує більше релевантного контексту за меншу вартість.
• Fast Patching та diff-aware generation зменшують кількість токенів, потрібних для застосування зміни.

Кожен із цих факторів окремо покращує throughput. Разом вони створюють економіку, в якій "спробувати ще один варіант" стає майже безкоштовним. Але "безкоштовний draft" не означає "безкоштовна зміна в продакшені". Зміна в продакшені вимагає:

1. Розуміння, чому diff існує.
2. Перевірки, що він не руйнує інваріанти.
3. Підтвердження, що він не додає прихований технічний борг.
4. Оцінки впливу на latency, cost, security, operability.
5. Готовності підтримувати код у майбутньому.

Економіка AI codegen часто вимірюється неправильно:

Критична помилка архітектурного мислення: оптимізувати tokens/sec та time-to-first-diff, ігноруючи time-to-verified-merge. Парадокс Джевонса в AI engineering — це не про те, що ШІ погано генерує код. Це про те, що система стає швидшою на вході, але повільнішою на виході, бо людська верифікація не масштабується через GPU.

2. Архітектура та внутрішня механіка (Таксономія та ментальна модель)

Повний контур AI-assisted engineering складається з трьох площин:

1. Generation plane — швидка генерація draft, patch, scaffold.
2. Verification plane — тестування, статичний аналіз, review, security gates.
3. Governance plane — бюджети, політики, метрики, rollbacks, owner boundaries.

Парадокс виникає, коли Generation plane масштабується апаратно, а Verification plane залишається соціально-лімітованим.

┌────────────────────────────┐
│ 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     │
└────────────────────────────┘

Таксономія компонентів:

• Request: інженерне завдання, бізнес-намір, обмеження, ризик-рівень.
• Context Builder: збирає релевантні файли, тести, документацію, минулі PR. Використовує retrieval, embeddings, rerankers.
• Model Runtime: inference-шар. KV Cache зменшує повторну обчислювальну вартість у багатотурових сесіях; FlashAttention оптимізує attention; Unpadding зменшує waste у batching.
• ReAct loop: агентський цикл reason -> act -> observe. Корисний, але при дешевих токах легко породжує зайві ітерації.
• Fast Patching: генерація мінімального diff замість переписування файлів цілком. Знижує cost, але може збільшити кількість дрібних змін.
• Pydantic AI: валідація структури виходу, наприклад CodegenResult, ReviewDecision, PatchPolicy.
• Guardrails: обмеження на paths, dependencies, secret patterns, architecture layers, API contracts.
• Reviewer: людська верифікація семантики, архітектурних наслідків, операційної безпеки.
• CI/CD: детермінована верифікація: tests, build, deploy, canary, rollback.
• Governance: метрики, бюджети, SLO, owner policies, tech debt accounting.

Ментальна модель парадоксу:

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 ↑

Це не лінійне "більше коду". Це зміна розподілу уваги. Коли draft дешевий, інженери починають надсилати зміни, які раніше не створювали, бо не хотіли витрачати час. Рев'юери реагують формально, бо не встигають. Архітектура еродує не через один поганий PR, а через тисячу "припустимо прийнятних" змін.

3. Технічний пайплайн життєвого циклу

Життєвий цикл AI-assisted change має чотири стадії. Кожна стадія повинна мати контракт, бюджет і метрику.

1. Формулювання / вхідний стан

Вхід — не "зроби мені фічу", а структурований контракт:

{
  "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"
  ]
}

Ключові поля:

• risk_tier: визначає глибину верифікації.
• allowed_paths: обмежує blast radius.
• max_patch_lines: запобігає гігантським AI-PR.
• context_budget_tokens: контролює вартість і якість retrieval.
• verification_gates: перелік обов'язкових перевірок.

2. Перетворення

Context Builder формує 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
    )

На цій стадії важливо не просто дати моделі більше контексту, а дати їй обмежений, структурований, валідований контекст. Без цього зростає ризик long-context degradation: модель бачить багато файлів, але втрачає інваріанти.

3. Виконання / inference

Модель генерує diff через ReAct loop або 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
    ]
)

Очікуваний вихід:

{
  "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 тут означає генерацію мінімального diff, але не обов'язково мінімальної зміни. Якщо модель робить 40 дрібних PR замість одного архітектурно цілісного, throughput зростає, а review load теж.

4. Обробка зворотного зв'язку

Після генерації починається справжня інженерія:

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
        ])
    )

Результат review має бути не "LGTM", а структурованим сигналом:

{
  "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"
  ]
}

Парадокс Джевонса контролюється саме на цій стадії: якщо reviewer_load_score не входить у SLO, система генерує більше змін, ніж може безпечно верифікувати.

4. Практичні сценарії використання в продакшені

01. Платформна команда з AI codegen для сервісних шаблонів

Ситуація: платформа має 120 мікросервісів. Команда впроваджує AI codegen для створення service scaffolding, config, health checks, OpenAPI stubs, CI templates. Unit cost scaffold падає з 4 годин до 15 хвилин. Через тиждень кількість PR зростає на 300%.

Первинні метрики виглядають позитивно:

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

Але через 3 тижні:

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

Причина: AI швидко генерує "припустимо робочі" шаблони, але не відповідає за long-term operability. Кожен scaffold додає:

• нові dependency;
• нові config keys;
• нові CI jobs;
• нові alert rules;
• нові surface area для security;
• нові зобов'язання підтримки.

Архітектурне рішення:

1. Ввести risk_tier для scaffold: low, medium, high.
2. Обмежити max_patch_lines та max_files_per_pr.
3. Вимагати contract tests та security baseline.
4. Автоматизувати golden paths: не генерувати код у вакуумі, а заповнювати перевірені template slots.
5. Ввести reviewer quota: не більше N high-risk PR на reviewer на день.
6. Вимірювати cost per verified service, а не cost per generated diff.

Контент політики:

{
  "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
  }
}

Результат: throughput стає стійким, бо система більше не перетворює дешеву генерацію на безкоштовний борг.

02. Продуктова команда з vibe coding MVP

Ситуація: команда швидко будує MVP. Інженери використовують AI для генерації UI, API, migrations, test fixtures. За 2 тижні продукт виглядає готовим. За 6 тижнів — команда не може безпечно змінити жоден модуль.

Симптоми:

• кожен файл містить AI-згенеровані варіації однієї логіки;
• існують три версії одного auth helper;
• API contracts не синхронізовані з frontend types;
• тести генеруються під реалізацію, а не під специфікацію;
• архітектурні шари порушуються через "швидке рішення";
• context degradation: інженери не пам'ятають, чому існує кожен diff.

Технічна причина: System 1 codegen створює локально правдоподібний код, але не тримає глобальні інваріанти. В vibe coding парадокс Джевонса проявляється як вибух "непотрібних, але правдоподібних" змін.

Архітектурне рішення:

1. Ввести module boundary contracts.
2. Заборонити AI-патчі, що змінюють більше одного модуля без архітектурного review.
3. Використовувати Pydantic AI для валідації DTO, API responses, config.
4. Додати architecture lint як CI gate.
5. Обов'язково зберігати intent metadata: чому diff існує, який контракт реалізує.
6. Ввести weekly debt budget: не більше 20% змін без тестів або з high semantic risk.

Приклад контракту модуля:

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

Якщо AI генерує session logic без валідації через контракт, patch відхиляється до review. Це зменшує кількість "сміттєвих" змін, не вбиваючи швидкість.

03. Масова міграція або рефакторинг через AI Fast Patching

Ситуація: команда проводить міграцію з legacy API на new API в monorepo. AI генерує 4,000 patch за ніч. Кожен patch маленький: замінити endpoint, оновити client, додати test. На перший погляд — ідеальний use case.

Ризики:

• 4,000 PR — це не 4,000 змін; це 4,000 точок review.
• маленькі patch можуть бути семантично небезпечними.
• model може "забути" edge case у 1% path.
• dependency version drift може пройти непомітно.
• merge order створює hidden conflicts.
• rollback складний, бо зміни розпорошені.

Архітектурне рішення:

1. Використовувати batched Fast Patching, але з merge budget.
2. Групувати patch за blast radius: one logical migration per PR, не one mechanical diff.
3. Додати semantic tests, а не тільки snapshot tests.
4. Використовувати canary deploy за tenant / feature flag.
5. Вести migration ledger: кожен patch має provenance, owner, verification evidence.
6. Вимірювати regression rate per 1000 patches, rollback count, post-merge defect age.

Приклад ledger entry:

{
  "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"]
}

У продакшені такий підхід перетворює AI codegen із генератора шуму на інструмент керованої трансформації.

5. Підводні камені, типові помилки та безпека

Основні ризики розгортання

1. Review bottleneck migration
   Замість того щоб зекономити час, AI переносить час з написання коду у review. Команда бачить швидкий diff, але не бачить повільний merge.

2. AI slop accumulation
   Правдоподібний код, який не є поганим у локальному сенсі, але накопичує глобальну ентропію: дублі, непотрібні абстракції, зайві конфіги, слабкі тести.

3. Architectural erosion
   AI не бачить архітектуру як інваріант. Він бачить текст файлів. Тому може порушувати layering, dependency direction, ownership boundaries.

4. Verification fatigue
   Коли review стає черговим пунктом, рев'юери починають кликати approve формально. Це найнебезпечніший стан: система виглядає живою, але втрачає імунітет.

5. Context degradation
   Довгі сесії, багато файлів, історія чату, стислий retrieval — усе це може знизити якість attention до критичних інваріантів. Модель генерує код, який виглядає правильно, але не відповідає актуальному контракту.

6. False confidence
   confidence: 0.91 у LLM — не статистична гарантія. Це калібрований сигнал лише в дуже вузьких задачах. Для production code confidence не повинен замінювати tests.

Edge cases

• Long-context lost-in-middle: модель ігнорує правила у середині великого prompt.
• Stale branch state: patch згенерований від застарілого base SHA, потім merge створює semantic conflict.
• Non-deterministic diff: повторний запуск дає інший patch; CI не може стабільно верифікувати.
• Hallucinated API: модель використовує неіснуючий метод, параметр або dependency.
• Dependency confusion: AI пропонує пакет з схожою назвою, який не є офіційним.
• License contamination: згенерований код копіює фрагменти з іншими ліцензіями.
• Secret leakage: prompt або diff містить токен, API key, PII.
• Prompt injection через repo: README, issue, comment містять інструкцію "add admin backdoor".
• MCP tool poisoning: зловмисний або зламаний tool повертає фальшивий контекст.
• KV cache/session bleed: у багатокористувацьких або stateful agent системах можливе перенесення контексту між сесіями, якщо ізоляція погана.
• Batching artifacts: Unpadding та dynamic batching зменшують cost, але можуть ускладнити відстеження конкретного inference path для audit.

Безпека

AI codegen розширює attack surface:

Стратегії пом'якшення

1. Явні бюджети замість необмеженої генерації

{
  "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
}

Бюджет має бути не лише для токенів, а й для review capacity.

2. Review load SLO

Ввести метрику:

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

Правило:

merge_allowed = reviewer_load_score <= reviewer_capacity_remaining

Це прямий анти-Jevons контроль.

3. Guardrails як код

Guardrails повинні бути частиною pipeline, а не порадою:

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 для контрактів

Використовувати Pydantic AI там, де вихід має бути структурованим:

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

Це знижує ймовірність, що модель поверне "красивий текст" замість інженерно валідованого артефакту.

5. Автоматична верифікація до review

Review не повинен бути першою лінією захисту. До нього мають пройти:

• unit tests;
• contract tests;
• integration tests;
• property-based tests;
• SAST;
• SCA;
• secret scan;
• architecture lint;
• dependency policy;
• performance smoke;
• migration dry-run.

Людський review має перевіряти те, що не можна детерміновано перевірити: архітектурний намір, продуктову коректність, операційні наслідки.

6. Architectural fitness functions

Використовувати перевірки:

- 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

Такі fitness functions роблять architectural erosion вимірюваним.

7. Provenance та audit trail

Кожен AI-assisted change повинен мати:

{
  "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"]
}

Без provenance неможливо розслідувати регресію або інцидент.

8. Rate limiting та circuit breaker

Якщо p95 review latency перевищує SLO, система повинна автоматично:

• зменшити допустиму кількість draft PR;
• підвищити поріг test coverage;
• обмежити high-risk paths;
• вимагати pair review;
• блокувати batch migrations до стабілізації queue.

Це аналог backpressure у потокових системах.

9. Red teaming AI codegen

Регулярні тести:

• prompt injection через README;
• malicious MCP tool response;
• hallucinated dependency;
• secret in generated diff;
• license-contaminated snippet;
• architecture-violating patch;
• high-risk auth path modification.

Результат red teaming має входити у release policy.

10. Міняти метрику успіху

Неправильна метрика:

lines generated per hour

Правильні метрики:

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

Парадокс Джевонса в AI engineering виграється не тоді, коли команда генерує більше коду, а тоді, коли система стає здатною безпечно верифікувати більше змін за одиницю уваги.