Le paradoxe de Jevons dans l'ingénierie IA

1. Concept et essence (Vue d'ensemble et problème systémique)

Le paradoxe de Jevons dans l'ingénierie IA est un effet systémique où la réduction du coût et de la latence de la génération de code n'augmente pas le volume total de travail d'ingénierie, mais le déplace vers une limite où les goulots d'étranglement ne sont plus l'inference, mais la vérification, le refactoring, la revue et la maintenance de l'architecture. La formule classique de Jevons : une amélioration de l'efficacité d'utilisation d'une ressource réduit son coût unitaire et stimule une conversion agrégée plus importante. En AI engineering, la ressource n'est pas le charbon, mais le « plausible code change » : diff, patch, scaffold, migration, test, PR.

Techniquement, le problème se formule ainsi :

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

où C_gen est le coût marginal de la génération d'un draft change acceptable, D_gen la demande agrégée en changements, et ReviewLoad la charge sur la vérification. Si ReviewLoad dépasse reviewer_capacity, le système ne devient pas plus rapide ; il devient plus toxique.

À l'ère pré-IA, la création d'une PR était coûteuse : l'ingénieur écrivait le code manuellement, maintenait le contexte en tête, puis soumettait le changement à la review. L'AI-codegen transforme ce cycle en processus System 1 : rapide, imitatif, haute fréquence. Le modèle génère un diff en quelques secondes. Mais la review est un processus System 2 : lent, sémantique, épuisant les ressources. Lorsque le coût du draft chute d'un ordre de grandeur, l'équipe augmente intuitivement le nombre de drafts sans augmenter proportionnellement la capacité de vérification sémantique.

La mécanique de baisse des coûts de génération combine plusieurs facteurs infrastructurels :

• FlashAttention et les kernels optimisés réduisent le compute cost pour l'inference long-context.
• RoPE et les schémas de positionnement modernes permettent un fonctionnement stable avec de grands contextes.
• KV Cache réduit la latence dans les boucles ReAct loop multi-tours et les sessions agentiques.
• Unpadding et le dynamic batching diminuent l'overhead lors du traitement de prompts de longueurs variables.
• Les couches retrieval/reranking de type ModernBERT offrent un code search moins cher, permettant au modèle d'accéder à plus de contexte pertinent pour un coût inférieur.
• Fast Patching et la génération aware-diff réduisent le nombre de tokens nécessaires pour appliquer un changement.

Chacun de ces facteurs améliore individuellement le throughput. Ensemble, ils créent une économie où « essayer une autre variante » devient quasi gratuit. Mais un « draft gratuit » ne signifie pas un « changement gratuit en production ». Un changement en production exige :

1. La compréhension de la raison d'être du diff.
2. La vérification qu'il ne brise pas les invariants.
3. La confirmation qu'il n'introduit pas de dette technique cachée.
4. L'évaluation de l'impact sur la latency, le cost, la security et l'operability.
5. La préparation à maintenir le code à l'avenir.

L'économie de l'AI codegen est souvent mal mesurée :

Erreur critique de la pensée architecturale : optimiser tokens/sec et time-to-first-diff en ignorant time-to-verified-merge. Le paradoxe de Jevons en AI engineering ne réside pas dans la mauvaise qualité de génération de code par l'IA. Il réside dans le fait que le système devient plus rapide à l'entrée mais plus lent à la sortie, car la vérification humaine ne scale pas via GPU.

2. Architecture et mécanique interne (Taxonomie et modèle mental)

Le contour complet de l'ingénierie assistée par IA se compose de trois plans :

1. Generation plane — Génération rapide de drafts, patches, scaffolds.
2. Verification plane — Tests, analyse statique, reviews, gates de sécurité.
3. Governance plane — Budgets, politiques, métriques, rollbacks, limites de propriété.

Le paradoxe surgit lorsque le Generation plane scale matériellement, tandis que le Verification plane reste limité socialement.

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

Taxonomie des composants :

• Request : Tâche d'ingénierie, intention business, contraintes, niveau de risque.
• Context Builder : Rassemble les fichiers pertinents, tests, documentation, PR passées. Utilise retrieval, embeddings, rerankers.
• Model Runtime : Couche d'inference. KV Cache réduit le coût de calcul répété dans les sessions multi-tours ; FlashAttention optimise l'attention ; Unpadding réduit le gaspillage dans le batching.
• ReAct loop : Cycle agentique reason -> act -> observe. Utile, mais avec des tokens bon marché, il engendre facilement des itérations superflues.
• Fast Patching : Génération d'un diff minimal plutôt que la réécriture complète de fichiers. Réduit le coût, mais peut augmenter le nombre de micro-changements.
• Pydantic AI : Validation de la structure de sortie, par exemple CodegenResult, ReviewDecision, PatchPolicy.
• Guardrails : Restrictions sur les paths, dependencies, patterns de secrets, couches d'architecture, contrats API.
• Reviewer : Vérification humaine de la sémantique, des conséquences architecturales, de la sécurité opérationnelle.
• CI/CD : Vérification déterministe : tests, build, deploy, canary, rollback.
• Governance : Métriques, budgets, SLO, politiques de propriété, comptabilité de la dette technique.

Modèle mental du paradoxe :

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 ↑

Ce n'est pas linéairement « plus de code ». C'est un changement dans la distribution de l'attention. Quand le draft est bon marché, les ingénieurs commencent à soumettre des changements qu'ils n'auraient pas créés auparavant, par manque de temps. Les reviewers répondent formellement car ils sont débordés. L'architecture s'érode non pas à cause d'une seule mauvaise PR, mais à travers mille changements « plausiblement acceptables ».

3. Pipeline technique du cycle de vie

Le cycle de vie d'un changement assisté par IA comporte quatre étapes. Chaque étape doit avoir un contrat, un budget et une métrique.

1. Formulation / état d'entrée

L'entrée n'est pas « fais-moi cette feature », mais un contrat structuré :

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

Champs clés :

• risk_tier : définit la profondeur de la vérification.
• allowed_paths : limite le blast radius.
• max_patch_lines : empêche les géantes AI-PR.
• context_budget_tokens : contrôle le coût et la qualité du retrieval.
• verification_gates : liste des vérifications obligatoires.

2. Transformation

Le Context Builder forme le 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
    )

À cette étape, il est crucial non seulement de donner plus de contexte au modèle, mais de lui fournir un contexte limité, structuré et validé. Sans cela, le risque de long-context degradation augmente : le modèle voit beaucoup de fichiers mais perd les invariants.

3. Exécution / inference

Le modèle génère le diff via ReAct loop ou 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
    ]
)

Sortie attendue :

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

Ici, Fast Patching signifie la génération d'un diff minimal, mais pas nécessairement d'un changement minimal. Si le modèle produit 40 petites PR au lieu d'une seule cohérente architecturalement, le throughput augmente, tout comme la charge de review.

4. Traitement du feedback

Après la génération commence la véritable ingénierie :

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

Le résultat de la review doit être un signal structuré, pas un simple « 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"
  ]
}

Le paradoxe de Jevons est contrôlé précisément à cette étape : si reviewer_load_score n'est pas inclus dans le SLO, le système génère plus de changements qu'il ne peut en vérifier en toute sécurité.

4. Scénarios d'utilisation pratiques en production

01. Équipe plateforme avec AI codegen pour templates de services

Situation : la plateforme compte 120 microservices. L'équipe déploie l'AI codegen pour créer des service scaffolding, configs, health checks, OpenAPI stubs, CI templates. Le coût unitaire du scaffold chute de 4 heures à 15 minutes. Une semaine plus tard, le nombre de PR augmente de 300%.

Les premières métriques semblent positives :

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

Mais après 3 semaines :

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

Cause : l'IA génère rapidement des templates « plausiblement fonctionnels », mais n'assume pas la responsabilité de l'opérabilité à long terme. Chaque scaffold ajoute :

• nouvelles dependencies ;
• nouvelles config keys ;
• nouveaux CI jobs ;
• nouvelles alert rules ;
• nouvelle surface area pour la security ;
• nouveaux engagements de support.

Décision architecturale :

1. Introduire risk_tier pour les scaffolds : low, medium, high.
2. Limiter max_patch_lines et max_files_per_pr.
3. Exiger contract tests et security baseline.
4. Automatiser les golden paths : ne pas générer du code dans le vide, mais remplir des slots de templates vérifiés.
5. Instaurer un quota reviewer : pas plus de N PR à haut risque par reviewer par jour.
6. Mesurer cost per verified service, et non cost per generated diff.

Contenu de la politique :

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

Résultat : le throughput devient durable, car le système ne convertit plus une génération bon marché en dette gratuite.

02. Équipe produit avec vibe coding MVP

Situation : l'équipe construit rapidement un MVP. Les ingénieurs utilisent l'IA pour générer UI, API, migrations, test fixtures. En 2 semaines, le produit semble prêt. En 6 semaines, l'équipe ne peut modifier aucun module en toute sécurité.

Symptômes :

• chaque fichier contient des variations générées par IA d'une même logique ;
• trois versions existent pour un même auth helper ;
• les contrats API ne sont pas synchronisés avec les types frontend ;
• les tests sont générés pour la réalisation, pas pour la spécification ;
• les couches architecturales sont violées par des « solutions rapides » ;
• context degradation : les ingénieurs ne se souviennent plus pourquoi chaque diff existe.

Cause technique : le codegen System 1 crée du code localement plausible, mais ne maintient pas les invariants globaux. Dans le vibe coding, le paradoxe de Jevons se manifeste par une explosion de changements « inutiles mais plausibles ».

Décision architecturale :

1. Introduire module boundary contracts.
2. Interdire les patches IA modifiant plus d'un module sans review architecturale.
3. Utiliser Pydantic AI pour valider DTO, réponses API, config.
4. Ajouter architecture lint comme gate CI.
5. Conserver impérativement les intent metadata : pourquoi le diff existe, quel contrat il implémente.
6. Instaurer un debt budget hebdomadaire : pas plus de 20% de changements sans tests ou à haut risque sémantique.

Exemple de contrat de module :

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 l'IA génère une logique de session sans validation via le contrat, le patch est rejeté avant la review. Cela réduit le nombre de changements « poubelles » sans tuer la vitesse.

03. Migration massive ou refactoring via AI Fast Patching

Situation : l'équipe effectue une migration d'une legacy API vers une new API dans un monorepo. L'IA génère 4 000 patches pendant la nuit. Chaque patch est petit : remplacer un endpoint, mettre à jour un client, ajouter un test. À première vue, un use case idéal.

Risques :

• 4 000 PR ne sont pas 4 000 changements ; ce sont 4 000 points de review.
• De petits patches peuvent être sémantiquement dangereux.
• Le modèle peut « oublier » un edge case dans un path à 1%.
• Le dependency version drift peut passer inaperçu.
• L'ordre de merge crée des conflits cachés.
• Le rollback est complexe car les changements sont dispersés.

Décision architecturale :

1. Utiliser batched Fast Patching, mais avec un merge budget.
2. Grouper les patches par blast radius : une migration logique par PR, pas un diff mécanique unique.
3. Ajouter des semantic tests, pas seulement des snapshot tests.
4. Déployer en canary par tenant / feature flag.
5. Tenir un migration ledger : chaque patch a une provenance, un owner, une preuve de vérification.
6. Mesurer regression rate per 1000 patches, rollback count, post-merge defect age.

Exemple d'entrée dans le ledger :

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

En production, cette approche transforme l'AI codegen d'un générateur de bruit en un outil de transformation contrôlée.

5. Pièges, erreurs courantes et sécurité

Risques principaux de déploiement

1. Review bottleneck migration
   Au lieu d'économiser du temps, l'IA déplace le temps de l'écriture du code vers la review. L'équipe voit un diff rapide, mais un merge lent.

2. AI slop accumulation
   Du code plausible qui n'est pas mauvais localement, mais qui accumule de l'entropie globale : doublons, abstractions superflues, configs inutiles, tests faibles.

3. Architectural erosion
   L'IA ne voit pas l'architecture comme un invariant. Elle voit du texte de fichiers. Elle peut donc violer le layering, la direction des dependencies, les limites de propriété.

4. Verification fatigue
   Quand la review devient une formalité, les reviewers cliquent approve mécaniquement. C'est l'état le plus dangereux : le système semble vivant mais perd son immunité.

5. Context degradation
   Sessions longues, nombreux fichiers, historique de chat, retrieval compressé — tout cela peut réduire la qualité de l'attention aux invariants critiques. Le modèle génère du code qui semble correct mais ne respecte pas le contrat actuel.

6. False confidence
   confidence: 0.91 dans un LLM n'est pas une garantie statistique. C'est un signal calibré uniquement pour des tâches très étroites. Pour du code de production, la confidence ne doit pas remplacer les tests.

Edge cases

• Long-context lost-in-middle : le modèle ignore les règles au milieu d'un grand prompt.
• Stale branch state : le patch est généré depuis un base SHA obsolète, puis le merge crée un conflit sémantique.
• Non-deterministic diff : une relance donne un patch différent ; la CI ne peut pas vérifier de manière stable.
• Hallucinated API : le modèle utilise une méthode, un paramètre ou une dependency inexistant(e).
• Dependency confusion : l'IA propose un paquet au nom similaire qui n'est pas officiel.
• License contamination : le code généré copie des fragments sous d'autres licences.
• Secret leakage : le prompt ou le diff contient un token, une API key, des PII.
• Prompt injection via repo : README, issue, commentaire contiennent l'instruction « add admin backdoor ».
• MCP tool poisoning : un outil malveillant ou compromis retourne un faux contexte.
• KV cache/session bleed : dans les systèmes agentiques multi-utilisateurs ou stateful, un transfert de contexte entre sessions est possible si l'isolation est mauvaise.
• Batching artifacts : Unpadding et dynamic batching réduisent le coût, mais peuvent compliquer le suivi du chemin d'inference spécifique pour l'audit.

Sécurité

L'AI codegen étend la surface d'attaque :

Stratégies d'atténuation

1. Budgets explicites plutôt que génération illimitée

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

Le budget doit couvrir non seulement les tokens, mais aussi la capacité de review.

2. Review load SLO

Introduire la métrique :

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

Règle :

merge_allowed = reviewer_load_score <= reviewer_capacity_remaining

Ceci est un contrôle anti-Jevons direct.

3. Guardrails as Code

Les Guardrails doivent faire partie du pipeline, et non être des conseils :

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 pour les contrats

Utiliser Pydantic AI là où la sortie doit être structurée :

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

Cela réduit la probabilité que le modèle retourne un « beau texte » au lieu d'un artefact validé ingénieriellement.

5. Vérification automatique avant la review

La review ne doit pas être la première ligne de défense. Avant elle, doivent passer :

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

La review humaine doit vérifier ce qui ne peut être testé de manière déterministe : l'intention architecturale, la correction produit, les conséquences opérationnelles.

6. Architectural fitness functions

Utiliser des vérifications :

- 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

De telles fitness functions rendent l'architectural erosion mesurable.

7. Provenance et audit trail

Chaque changement assisté par IA doit avoir :

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

Sans provenance, il est impossible d'enquêter sur une régression ou un incident.

8. Rate limiting et circuit breaker

Si la latence p95 de review dépasse le SLO, le système doit automatiquement :

• réduire le nombre autorisé de draft PR ;
• augmenter le seuil de test coverage ;
• restreindre les paths à haut risque ;
• exiger une pair review ;
• bloquer les batch migrations jusqu'à stabilisation de la queue.

Ceci est l'analogue du backpressure dans les systèmes de flux.

9. Red teaming de l'AI codegen

Tests réguliers :

• prompt injection via README ;
• réponse malicious d'un outil MCP ;
• dependency hallucinée ;
• secret dans le diff généré ;
• snippet contaminé par la licence ;
• patch violant l'architecture ;
• modification d'un path d'auth à haut risque.

Le résultat du red teaming doit entrer dans la release policy.

10. Changer les métriques de succès

Métrique incorrecte :

lines generated per hour

Métriques correctes :

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

Le paradoxe de Jevons en AI engineering est vaincu non pas quand l'équipe génère plus de code, mais quand le système devient capable de vérifier en toute sécurité plus de changements par unité d'attention.