Парадокс Джевонса в AI-инженерии

1. Обзор концепции и системная проблема

Парадокс Джевонса в AI-инженерии — это системный эффект, при котором снижение стоимости и задержки генерации кода не уменьшает общий объём инженерной работы, а увеличивает его до предела, где bottleneck становится не inference, а верификация, рефакторинг, review и поддержание архитектуры. Классическая формула Джевонса: повышение эффективности использования ресурса снижает его unit cost и стимулирует больший совокупный throughput. В 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. AI codegen превращает этот цикл в System 1-процесс: быстрый, имитационный, высокочастотный. Модель генерирует diff за секунды. Но review — это System 2: медленный, семантический, исчерпаемый ресурс. Когда стоимость draft падает на порядок, команда интуитивно увеличивает количество draft, не увеличивая proportionally capacity for semantic verification.

Механика удешевления генерации объединяет несколько инфраструктурных факторов:

• FlashAttention и оптимизированные kernels снижают compute cost для long-context inference и Forward Pass.
• RoPE и современные position schemes позволяют стабильно работать с большими контекстами.
• KV Cache и Prompt Caching снижают latency в многоуровневых ReAct loop и Agentic Workflow sessions.
• Unpadding и dynamic batching снижают overhead при обработке переменных по длине prompt.
• ModernBERT-подобные retrieval/reranking слои и Vector Embeddings дают более дешёвый code search, поэтому модель получает больше релевантного контекста за меньшую стоимость.
• Fast Patching и diff-aware generation снижают количество токенов, необходимых для применения изменения.
• In-Context Learning, Zero-Shot и Few-Shot prompts делают «попробовать ещё один вариант» почти бесплатным.

Каждый из этих факторов отдельно улучшает throughput. Вместе они создают экономику, в которой «попробовать ещё один вариант» становится почти бесплатным. Но «бесплатный draft» не означает «бесплатное изменение в продакшене». Изменение в продакшене требует:

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

Экономика AI codegen часто измеряется неправильно:

Критическая ошибка архитектурного мышления: оптимизировать tokens/sec и time-to-first-diff, игнорируя time-to-verified-merge. Парадокс Джевонса в AI engineering — это не про то, что AI плохо генерирует код. Это про то, что система становится быстрее на входе, но медленнее на выходе, потому что human verification не масштабируется через GPU.

2. Архитектурная таксономия и ментальная модель

Полный контур AI-assisted engineering состоит из трёх плоскостей:

1. Generation plane — быстрая генерация draft, patch, scaffold.
2. Verification plane — testing, static analysis, 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 Calling / 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: инженерная задача, бизнес-намерение, ограничения, risk level.
• Context Builder: собирает релевантные файлы, tests, документацию, прошлые PR. Использует retrieval, Vector Embeddings, rerankers и In-Context Learning context selection.
• Model Runtime: inference-слой. Forward Pass optimization, KV Cache снижает повторную вычислительную стоимость в многоуровневых сессиях; FlashAttention оптимизирует attention; Unpadding снижает waste в batching.
• ReAct loop: Agentic Workflow цикл reason -> act -> observe с Tool Calling. Полезен, но при дешёвых токенах легко порождает лишние итерации.
• Fast Patching: генерация минимального diff вместо переписывания файлов целиком. Снижает cost, но может увеличить количество мелких изменений.
• Pydantic AI: валидация структуры выхода, например CodegenResult, ReviewDecision, PatchPolicy.
• Guardrails: ограничения на paths, dependencies, secret patterns, architecture layers, API contracts, AST-based checks.
• Reviewer: human verification семантики, архитектурных последствий, операционной безопасности.
• 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 дешёвый, инженеры начинают отправлять изменения, которые раньше не создавали, потому что не хотели тратить время. Reviewers реагируют формально, потому что не успевают. Архитектура эродирует не через один плохой PR, а через тысячу plausible изменений.

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 быстро генерирует plausible working шаблоны, но не отвечает за long-term operability. Каждый scaffold добавляет:

• новые dependencies;
• новые 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 становится устойчивым, потому что система больше не превращает дешёвую генерацию в бесплатный debt.

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

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

Симптомы:

• каждый файл содержит AI-сгенерированные вариации одной логики;
• существуют три версии одного auth helper;
• API contracts не синхронизированы с frontend types;
• tests генерируются под реализацию, а не под спецификацию;
• архитектурные слои нарушаются через «быстрое решение»;
• context degradation: инженеры не помнят, почему существует каждый diff.

Техническая причина: System 1 codegen создаёт локально правдоподобный код, но не держит глобальные инварианты. В vibe coding парадокс Джевонса проявляется как взрыв «ненужных, но plausible» изменений.

Архитектурное решение:

1. Ввести module boundary contracts.
2. Запретить AI-патчи, изменяющие больше одного модуля без architectural review.
3. Использовать Pydantic AI для валидации DTO, API responses, config.
4. Добавить architecture lint как CI gate.
5. Обязательно сохранять intent metadata: почему diff существует, какой контракт реализует.
6. Ввести weekly debt budget: не более 20% изменений без tests или с 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 могут быть семантически опасными.
• модель может «забыть» 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
   Plausible code, который не является плохим в локальном смысле, но накапливает глобальную энтропию: дубли, ненужные абстракции, лишние конфиги, слабые tests.

3. Architectural erosion
   AI не видит архитектуру как инвариант. Он видит текст файлов. Поэтому может нарушать layering, dependency direction, ownership boundaries.

4. Verification fatigue
   Когда review становится очередным пунктом, reviewers начинают кликать approve формально. Это самое опасное состояние: система выглядит живой, но теряет иммунитет.

5. Context degradation
   Длинные сессии, много файлов, chat history, сжатый retrieval — всё это может снизить качество attention к критическим инвариантам. Модель генерирует код, который выглядит правильно, но не соответствует актуальному контракту.

6. False confidence
   confidence: 0.91 в LLM — не статистическая гарантия. Это calibrated сигнал только в очень узких задачах. Для 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 содержит token, API key, PII.
• Prompt injection через repo: README, issue, comment содержат инструкцию «add admin backdoor».
• MCP tool poisoning: malicious или скомпрометированный tool возвращает фальшивый контекст.
• KV cache/session bleed: в multi-user или stateful agent системах возможно перенесение контекста между сессиями, если Checkpointer isolation плохая.
• Batching artifacts: Unpadding и dynamic batching снижают cost, но могут усложнить отслеживание конкретного inference path для audit.
• Induction Heads artifacts: модель может усиливать статистически правдоподобные, но семантически устаревшие паттерны из контекста, повышая false confidence.

Безопасность

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

Это прямой anti-Jevons control.

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.

Human review должен проверять то, что нельзя детерминированно проверить: architectural intent, product correctness, operational consequences.

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 выигрывается не тогда, когда команда генерирует больше кода, а тогда, когда система становится способной безопасно верифицировать больше изменений за единицу внимания.