Paradoja de Jevons en la ingeniería de IA

1. Visión general del concepto y problema sistémico

La Paradoja de Jevons en la ingeniería de IA es un efecto sistémico en el que la reducción del costo y la latencia de generación de código no disminuye el volumen total de trabajo de ingeniería, sino que lo aumenta hasta el punto en que el cuello de botella deja de ser la inference y pasa a ser la verification, el refactor, el review y el mantenimiento de la arquitectura. La fórmula clásica de Jevons: mayor eficiencia en el uso de un recurso reduce su costo unitario y estimula una conversión agregada mayor. En AI engineering, el recurso no es carbón, sino un plausible code change: diff, patch, scaffold, migration, test, PR.

Técnicamente, el problema se formula así:

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

donde C_gen es el marginal cost de generar un draft change aceptable, D_gen es la demanda agregada de cambios y ReviewLoad es la carga de verification. Si ReviewLoad supera reviewer_capacity, el sistema no se vuelve más rápido; se vuelve más tóxico.

En la era pre-AI, crear un PR era caro: el ingeniero escribía código a mano, mantenía el contexto en la cabeza y solo después enviaba el cambio a review. La AI codegen convierte este ciclo en un proceso System 1: rápido, imitativo, alta frecuencia. La model genera un diff en segundos. Pero el review es System 2: lento, semántico, recurso exhaustible. Cuando el costo del draft cae un orden de magnitud, el equipo aumenta intuitivamente el número de drafts sin aumentar proporcionalmente la capacidad de semantic verification.

La mecánica de abaratamiento de la generación combina varios factores de infraestructura:

• FlashAttention y kernels optimizados reducen el compute cost de la Forward Pass para long-context inference.
• RoPE y esquemas modernos de posición permiten trabajar de forma estable con contextos grandes.
• KV Cache reduce la latency en ReAct loop y sesiones de agentes multi-turno; Prompt Caching reutiliza el prefill en patrones repetidos de Tool Calling.
• Unpadding y dynamic batching reducen el overhead al procesar prompts de longitud variable.
• Capas de retrieval/reranking tipo ModernBERT, junto con Vector Embeddings, ofrecen code search más barato, de modo que la model recibe más contexto relevante por menor costo.
• Los Induction Heads pueden mejorar patrones de copia y retrieval dentro del contexto, pero no garantizan invariants globales.
• Fast Patching y diff-aware generation usan AST para reducir los tokens necesarios para aplicar un cambio.

Cada uno de estos factores, por separado, mejora el throughput. Juntos crean una economía en la que “probar otra variante” se vuelve casi gratuito. Pero un free draft no significa un free production change. Un cambio en producción exige:

1. Entender por qué existe el diff.
2. Verificar que no rompe invariants.
3. Confirmar que no añade hidden technical debt.
4. Evaluar el impacto en latency, cost, security y operability.
5. Estar listo para mantener el código en el futuro.

La economía de AI codegen suele medirse incorrectamente:

El error crítico del pensamiento arquitectónico es optimizar tokens/sec y time-to-first-diff ignorando time-to-verified-merge. La Paradoja de Jevons en AI engineering no consiste en que la IA genere mal el código. Consiste en que el sistema se vuelve más rápido en la entrada y más lento en la salida, porque la verificación humana no escala a través de la GPU.

2. Taxonomía arquitectónica y modelo mental

El contorno completo de la AI-assisted engineering se compone de tres planos:

1. Generation plane — generación rápida de drafts, patches y scaffolds.
2. Verification plane — testing, static analysis, review, security gates.
3. Governance plane — budgets, políticas, métricas, rollbacks, owner boundaries.

La paradoja surge cuando el Generation plane escala hardwaremente, pero el Verification plane sigue limitado socialmente.

┌────────────────────────────┐
│ Engineer / Product Request │
└─────────────┬──────────────┘
              │ task + constraints + repo state
              ▼
┌────────────────────────────┐
│ Context Builder            │
│ - code search / ModernBERT │
│ - Vector Embeddings        │
│ - MCP resources            │
│ - dependency graph         │
│ - policy manifest          │
└─────────────┬──────────────┘
              │ prompt bundle + token budget
              ▼
┌──────────────────────────────────────────────┐
│ Model Runtime                                │
│ FlashAttention | RoPE | KV Cache | Unpadding │
│ Prompt Caching | Tool Calling | Checkpointer │
│ ReAct loop / Agentic Workflow / draft gen    │
└─────────────┬────────────────────────────────┘
              │ 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     │
└────────────────────────────┘

Taxonomía de componentes:

• Request: tarea de ingeniería, intención de negocio, restricciones, nivel de riesgo.
• Context Builder: reúne archivos relevantes, tests, documentación y PR históricos. Construye el bundle para In-Context Learning usando retrieval, Vector Embeddings y rerankers.
• Model Runtime: capa de inference. KV Cache reduce el costo computacional repetido en sesiones multi-turno; FlashAttention optimiza la atención; Unpadding reduce el waste en batching; Prompt Caching reutiliza prefill; Checkpointer persiste el estado del Agentic Workflow; Tool Calling conecta acciones externas vía MCP.
• ReAct loop: ciclo de agente reason -> act -> observe. Es útil, pero con tokens baratos puede generar iteraciones innecesarias.
• Fast Patching: generación de un diff mínimo en lugar de reescribir archivos completos. Reduce el costo, pero puede aumentar el número de cambios pequeños.
• Pydantic AI: valida la estructura de salida, por ejemplo CodegenResult, ReviewDecision, PatchPolicy.
• Guardrails: restricciones sobre paths, dependencies, secret patterns, capas de arquitectura y API contracts.
• Reviewer: verificación humana de semántica, consecuencias arquitectónicas y seguridad operativa.
• CI/CD: verificación determinista: tests, build, deploy, canary, rollback.
• Governance: métricas, budgets, SLO, owner policies y tech debt accounting.

Modelo mental de la paradoja:

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 ↑

No es un crecimiento lineal de “más código”. Es un cambio en la distribución de la atención. Cuando el draft es barato, los ingenieros empiezan a enviar cambios que antes no creaban porque no querían gastar tiempo. Los reviewers responden formalmente porque no alcanzan. La arquitectura se erosiona no por un PR malo, sino por miles de cambios “plausiblemente aceptables”.

3. Pipeline técnico y mecánica interna

El ciclo de vida de un cambio asistido por IA tiene cuatro etapas. Cada etapa debe tener contrato, budget y métrica.

1. Formulación / estado de entrada

La entrada no es “hazme una feature”, sino un contrato estructurado:

{
  "task_id": "T-8842",
  "repo": "payments-service",
  "base_sha": "a7f3c91",
  "objective": "Agregar idempotency key a la API de refunds",
  "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"
  ]
}

Campos clave:

• risk_tier: define la profundidad de la verificación.
• allowed_paths: limita el blast radius.
• max_patch_lines: evita AI-PR gigantes.
• context_budget_tokens: controla el costo y la calidad del retrieval.
• verification_gates: lista de verificaciones obligatorias.

2. Transformación

El Context Builder forma el 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
    )

En esta etapa, lo importante no es dar a la model más contexto, sino dar un contexto limitado, estructurado y validado. Sin ello, aumenta el riesgo de long-context degradation: la model ve muchos archivos, pero pierde invariants. Un prompt Zero-Shot o Few-Shot puede parecer correcto, pero no sostiene contratos arquitectónicos.

3. Ejecución / inference

La model genera el diff mediante ReAct loop o 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
    ]
)

Salida esperada:

{
  "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 aquí significa generar un diff mínimo, pero no necesariamente un cambio mínimo. Si la model produce 40 PR pequeños en lugar de un cambio arquitectónicamente coherente, el throughput crece y la review load también.

4. Procesamiento de retroalimentación

Después de la generación comienza la ingeniería real:

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

El resultado del review debe ser una señal estructurada, no un “LGTM”:

{
  "patch_id": "P-10492",
  "verdict": "request_changes",
  "review_minutes": 34,
  "semantic_risk": 0.71,
  "reviewer_load_score": 0.83,
  "issues": [
    "idempotency key no validada contra tenant_id",
    "contract test ausente para duplicate request",
    "error response cambia la forma de la API pública"
  ]
}

La Paradoja de Jevons se controla precisamente en esta etapa: si reviewer_load_score no está dentro del SLO, el sistema genera más cambios de los que puede verificar con seguridad.

4. Escenarios prácticos de ingeniería en producción

01. Equipo de plataforma con AI codegen para service scaffolding

Situación: la plataforma tiene 120 microservicios. El equipo implementa AI codegen para generar service scaffolding, config, health checks, OpenAPI stubs y CI templates. El unit cost del scaffold cae de 4 horas a 15 minutos. En una semana, el volumen de PR aumenta 300%.

Las métricas iniciales parecen positivas:

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

Pero a las 3 semanas:

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

Causa: la IA genera rápidamente templates “plausiblemente funcionales”, pero no responde por la long-term operability. Cada scaffold añade:

• nuevas dependencies;
• nuevas config keys;
• nuevos CI jobs;
• nuevas alert rules;
• nueva surface area para security;
• nuevas obligaciones de soporte.

Decisión arquitectónica:

1. Introducir risk_tier para scaffold: low, medium, high.
2. Limitar max_patch_lines y max_files_per_pr.
3. Exigir contract tests y security baseline.
4. Automatizar golden paths: no generar código en el vacío, sino completar template slots validados.
5. Introducir reviewer quota: no más de N high-risk PR por reviewer al día.
6. Medir cost per verified service, no cost per generated diff.

Contenido de la política:

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

Resultado: el throughput se vuelve sostenible porque el sistema deja de convertir generación barata en deuda gratuita.

02. Equipo de producto con vibe coding MVP

Situación: el equipo construye un MVP rápidamente. Los ingenieros usan IA para generar UI, API, migrations y test fixtures. En 2 semanas, el producto parece listo. En 6 semanas, el equipo no puede cambiar con seguridad ningún módulo.

Síntomas:

• cada archivo contiene variaciones generadas por IA de una misma lógica;
• existen tres versiones del mismo auth helper;
• los API contracts no están sincronizados con los frontend types;
• los tests se generan para la implementación, no para la especificación;
• las capas de arquitectura se rompen por “quick fixes”;
• context degradation: los ingenieros no recuerdan por qué existe cada diff.

Causa técnica: la codegen System 1 produce código localmente plausible, pero no mantiene invariants globales. En vibe coding, la Paradoja de Jevons se manifiesta como una explosión de cambios “innecesarios, pero plausibles”.

Decisión arquitectónica:

1. Introducir module boundary contracts.
2. Prohibir AI patches que modifiquen más de un módulo sin architectural review.
3. Usar Pydantic AI para validar DTO, API responses y config.
4. Añadir architecture lint como CI gate.
5. Conservar obligatoriamente intent metadata: por qué existe el diff y qué contrato implementa.
6. Introducir un weekly debt budget: no más de 20% de cambios sin tests o con high semantic risk.

Ejemplo de contrato de módulo:

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

Si la IA genera session logic sin validación a través del contrato, el patch se rechaza antes del review. Esto reduce la cantidad de cambios de AI slop sin matar la velocidad.

03. Migración masiva o refactor mediante AI Fast Patching

Situación: el equipo realiza una migración de legacy API a new API en un monorepo. La IA genera 4,000 patches durante la noche. Cada patch es pequeño: reemplazar endpoint, actualizar client, añadir test. A primera vista, es el use case ideal.

Riesgos:

• 4,000 PR no son 4,000 cambios; son 4,000 puntos de review.
• los patches pequeños pueden ser semánticamente peligrosos.
• la model puede “olvidar” un edge case en un path del 1%.
• dependency version drift puede pasar desapercibido.
• el merge order crea hidden conflicts.
• el rollback es complejo porque los cambios están dispersos.

Decisión arquitectónica:

1. Usar batched Fast Patching, pero con merge budget.
2. Agrupar patches por blast radius: una migración lógica por PR, no un diff mecánico.
3. Añadir semantic tests, no solo snapshot tests.
4. Usar canary deploy por tenant / feature flag.
5. Mantener un migration ledger: cada patch debe tener provenance, owner y verification evidence.
6. Medir regression rate per 1000 patches, rollback count y post-merge defect age.

Ejemplo de ledger entry:

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

En producción, este enfoque convierte la AI codegen de generador de ruido en una herramienta de transformación controlada.

5. Errores comunes, trampas y seguridad

Principales riesgos de despliegue

1. Review bottleneck migration
   En lugar de ahorrar tiempo, la IA desplaza el tiempo de escribir código al review. El equipo ve un diff rápido, pero no ve un merge lento.

2. AI slop accumulation
   Código plausible que no es malo en sentido local, pero acumula entropía global: duplicados, abstracciones innecesarias, configs sobrantes y tests débiles.

3. Architectural erosion
   La IA no ve la arquitectura como un invariant. Ve texto de archivos. Por eso puede violar layering, dependency direction y ownership boundaries.

4. Verification fatigue
   Cuando el review se vuelve un trámite, los reviewers empiezan a aprobar formalmente. Es el estado más peligroso: el sistema parece vivo, pero pierde inmunidad.

5. Context degradation
   Sesiones largas, muchos archivos, historial de chat y retrieval comprimido pueden reducir la calidad de la atención hacia invariants críticos. La model genera código que parece correcto, pero no coincide con el contrato actual. Los Induction Heads pueden copiar patrones locales sin sostener reglas globales.

6. False confidence
   confidence: 0.91 en una LLM no es una garantía estadística. Es una señal calibrada solo en tareas muy estrechas. En production code, confidence no debe reemplazar tests.

Edge cases

• Long-context lost-in-middle: la model ignora reglas en el centro de un prompt grande.
• Stale branch state: el patch se genera desde un base SHA desactualizado y el merge crea semantic conflict.
• Non-deterministic diff: una segunda corrida produce otro patch; CI no puede verificar de forma estable.
• Hallucinated API: la model usa un método, parámetro o dependency inexistente.
• Dependency confusion: la IA propone un paquete con nombre similar que no es oficial.
• License contamination: el código generado copia fragmentos con otras licencias.
• Secret leakage: el prompt o el diff contiene token, API key o PII.
• Prompt injection through repo: README, issue o comment contienen instrucciones como “add admin backdoor”.
• MCP tool poisoning: una tool maliciosa o comprometida devuelve contexto falso.
• KV cache/session bleed: en sistemas multiusuario o stateful agent, puede haber fuga de contexto entre sesiones si la aislamiento es pobre.
• Checkpointer contamination: si el Checkpointer del Agentic Workflow no está aislado por tenant o sesión, puede filtrar estado entre flujos.
• Batching artifacts: Unpadding y dynamic batching reducen el costo, pero pueden dificultar el rastreo de un inference path específico para audit.

Seguridad

La AI codegen amplía la attack surface:

Estrategias de mitigación

1. Budgets explícitos en lugar de generación ilimitada

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

El budget no debe ser solo de tokens, sino también de review capacity.

2. Review load SLO

Introducir la métrica:

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

Regla:

merge_allowed = reviewer_load_score <= reviewer_capacity_remaining

Es un control directo anti-Jevons.

3. Guardrails como código

Los Guardrails deben ser parte del pipeline, no una recomendación:

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 para contratos

Usar Pydantic AI donde la salida deba ser estructurada:

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

Esto reduce la probabilidad de que la model devuelva “texto bonito” en lugar de un artefacto de ingeniería validado.

5. Verificación automática antes del review

El review no debe ser la primera línea de defensa. Antes de él deben pasar:

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

El review humano debe verificar lo que no puede determinarse de forma automática: intención arquitectónica, corrección de producto y consecuencias operativas.

6. Architectural fitness functions

Usar verificaciones como:

- 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

Estas fitness functions hacen medible la architectural erosion.

7. Provenance y audit trail

Cada AI-assisted change debe tener:

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

Sin provenance, es imposible investigar una regresión o un incidente.

8. Rate limiting y circuit breaker

Si p95 review latency supera el SLO, el sistema debe automáticamente:

• reducir el número permitido de draft PR;
• elevar el umbral de test coverage;
• restringir high-risk paths;
• exigir pair review;
• bloquear batch migrations hasta estabilizar la queue.

Es el análogo de backpressure en sistemas de streaming.

9. Red teaming de AI codegen

Pruebas regulares:

• prompt injection vía README;
• malicious MCP tool response;
• hallucinated dependency;
• secret en diff generado;
• license-contaminated snippet;
• architecture-violating patch;
• modificación de high-risk auth path.

El resultado del red teaming debe entrar en la release policy.

10. Cambiar la métrica de éxito

Métrica incorrecta:

lines generated per hour

Métricas correctas:

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

La Paradoja de Jevons en AI engineering se gana cuando el sistema es capaz de verificar con seguridad más cambios por unidad de atención, no cuando el equipo genera más código.