Harness Engineering en legacy : agent écrit du code

# Harness Engineering : Comment un agent IA rédige du code de production dans un monorepo legacy

Chez Harness Engineering, les humains définissent les frontières architecturales, les scénarios de tests et valident les résultats, tandis que l'agent IA génère tout le code de production. Une expérience sur un monorepo legacy comptant 310 000 lignes de Scala/Java a prouvé que cette approche fonctionne pour des tâches courantes comme l'extraction d'un module sans altérer le comportement. Le rôle de l'ingénieur évolue vers la gestion du contexte et du processus, l'agent s'occupant des tâches mécaniques fastidieuses.

Monorepo : 25 modules SBT, 8 ans d'historique, système à forte charge. Tâche : Extraire le traitement des webhooks Channel X vers un service autonome, en suivant le modèle des adaptateurs existants.

Configuration de l'expérience et rôles

Les humains ne rédigent pas de code de production. Les rôles sont clairement séparés :

• Humain : Frontières architecturales, décomposition des tâches, exigences, tests, revues, validation finale.
• Agent : Création/modification de code, déplacement de composants, exécution de tests basés sur scénarios, mise en place d'infrastructure, corrections de bugs.

Tâche typique : Extraction mécanique avec câblage et adaptations de dépendances, sans refactorisation de logique métier. Vérifiable via tests unitaires et E2E.

Préparation du contexte : La documentation comme interface de contrôle

La documentation devient l'outil clé : les ADRs esquissent les options, les plans définissent les étapes. L'agent respecte strictement les cadres fournis, sans improvisation.

Exemple d'ADR :

# ADR-42 : Extraction du traitement des webhooks Channel X du monolithe

## Contexte
Channel X est actuellement géré au sein du cœur. Les autres canaux fonctionnent déjà comme des services séparés derrière un courtier de messages.

## Options
1. Wrapper léger : Déplacer le code existant avec des ajustements minimaux (paquets, câblage).
2. Réécrire le gestionnaire de zéro sur une pile différente.
3. Laisser tel quel.

## Décision
Option 1 : Minimise la perte de comportements implicites lors de l'extraction ; aligne l'architecture avec les autres canaux.

## Conséquences
+ Modèle cohérent pour tous les canaux  
− Duplication temporaire de code ; refactorisation en tâche séparée

Des plans étagés réduisent les erreurs : Du squelette à la boucle E2E complète.

Étapes et prompts : Contrôle de l'agent pas à pas

La décomposition en étapes assure la supervision. Exemples de prompts :

• Plan architectural :

Étudiez le fonctionnement des adaptateurs Channel A et B : Comment ils s'abonnent au courtier et publient les événements entrants.
Localisez le traitement des webhooks Channel X dans le monolithe.
Rédigez une ADR avec trois options : wrapper / réécriture / garder dans le cœur. Recommandez le wrapper et détaillez les conséquences.
Placez les fichiers dans architecture/adr/, ne touchez pas au code pour l'instant.

• Tests comme contrat :

Dans la classe WebhookHandler, il y a une branche par type de chat. Extrayez-la vers une fonction pure routeEvent(...).
N'améliorez pas le comportement — copiez les branches telles quelles. Rédigez des tests unitaires : chat privé, groupe, type inconnu, corps vide.
Succès : `sbt test` pour le module passe au vert.

• Nouveau module :

Créez le module sbt channel-x-adapter selon la SPEC de l'ADR-42.
Copiez les fichiers listés du monolithe ; modifiez uniquement les paquets, imports et dépendances pour une compilation propre sans `dependsOn(core)`.
Règle : Pas de refactorisation de logique métier à cette étape.

• Boucle E2E :

Ajoutez le répertoire e2e/ avec pytest + testcontainers : Conteneur courtier, PostgreSQL, mock d'API externe sur un port séparé.
Rédigez un test : POST webhook avec texte "ping" → Le courtier reçoit l'événement sur le sujet attendu avec texte=ping.

Les tests guident l'agent : Il vise un sbt test ou pytest au vert.

Forces de l'agent : Routine sous contrôle

L'agent excelle dans :

• Extraction et adaptation de code.
• Réplication de patterns à partir d'exemples.
• Génération de boilerplate.
• Construction d'infrastructure de tests.
• Lots d'éditions similaires.

Exemple de test E2E avec pytest + testcontainers :

# Fixtures : Conteneur courtier, adaptateur, mock d'API HTTP externe

def test_incoming_webhook_publishes_to_broker(e2e):
    e2e.http.post("/webhook/channel-x", json={"message": {"text": "hello", "chat": {"id": 42}}})
    msg = e2e.broker.await_message("inbound.channel-x", timeout_s=5)
    assert msg["text"] == "hello"
    assert msg["chat_id"] == 42

def test_outgoing_command_reaches_external_api(e2e):
    e2e.broker.publish("outbound.channel-x", {"chat_id": "42", "text": "hi"})
    calls = e2e.external_mock.wait_for_requests(method="POST", path_contains="sendMessage")
    assert any(b"hi" in c.body for c in calls)

Vérifie non seulement la compilation, mais le comportement intégré : Courtier, DB, mock d'API.

Limites et frontières

L'agent n'assume pas les décisions architecturales mais accélère les mécaniques. Risques : Régressions masquées (tests verts cachent des problèmes), besoin de bornes strictes. Adapté aux legacy avec patterns, pas aux projets greenfield ou R&D.

Les devs divergent : Économies sur routine vs. surcharge contextuelle.

Enseignements clés

• Harness Engineering : Environnement agent contrôlé — règles, outils, feedback.
• Succès sur extraction/adaptation de code et infra tests dans projets legacy.
• Tests : Interface de contrôle centrale, pas rituel.
• Frontières : Tâches routinières avec exemples, pas d'innovation architecturale.
• Secteur : Anthropic (90 % code IA), Meta, Amazon — virage vers dev natif IA.

— Editorial Team