Plus de code généré par l'IA n'a pas accéléré l'équipe. Charity Majors visait quand même 2×.

Plus de code généré par l'IA ne rend pas votre équipe plus rapide. Cela peut en fait vous ralentir.

Ce n'est pas une position anti-IA. C'est Charity Majors—co-fondatrice et CTO de Honeycomb—qui décrit ce qui arrive quand la génération scale et que tout en aval ne suit pas. Honeycomb construit des outils d'observabilité pour des systèmes de production complexes. Si quelqu'un doit faire confiance au récit de vitesse, c'est eux. Ils ont quand même choisi un objectif de productivité 2× au lieu de courir après 10×, et ont écrit des valeurs IA avant des mandats.

La partie inconfortable pour la plupart des leads engineering : le goulot n'a jamais été la frappe. C'est livrer le logiciel, le déboguer en production et le maintenir en bon état. Inondez le repo de sorties d'agents et vous n'achetez pas de vélocité—vous achetez de la profondeur de file exactement aux étapes qui faisaient déjà mal.

Écrire du code n'a jamais été la partie difficile

Majors le dit clairement depuis des années, bien avant que l'IA générative ne le rende à la mode : écrire du code n'était pas la contrainte à la livraison. Review, intégration, déploiement, réponse aux incidents et fiabilité visible client l'étaient.

L'IA amplifie ce que vous avez déjà. Une observabilité solide et une discipline de release transforment le codegen en levier. Des fondations faibles en font du bruit que vous devez quand même corriger lors d'alertes on-call nocturnes.

C'est pourquoi une entreprise dont la marque est « voir ce que fait la production » s'inquiète moins des frappes par heure et plus de savoir si quelqu'un peut posséder ce qui part en prod.

Pourquoi Honeycomb a choisi 2×, pas 10×

Honeycomb a adopté un défi 2× à l'échelle de l'entreprise—inspiré d'une poussée similaire chez Intercom—pas comme un stunt, mais comme un plafond honnête. Doubler l'impact avec l'IA sur un an. Pas dix fois les tokens. Pas dix fois les lignes mergées.

Emily Nakashima, VP Engineering chez Honeycomb, a décrit le déploiement en public : un memo fondateur encourageant l'expérimentation, puis la question récurrente des ingénieurs—comment allez-vous mesurer ?

La réponse de Honeycomb est instructive pour quiconque copie-colle un memo « ingénieur 10× » des réseaux sociaux :

• **Désaccentuer les métriques uniques** qui invitent au gaming—dépense en tokens, lignes de code, nombre de PR
• **Faire confiance à l'auto-déclaration** sur si l'IA a vraiment augmenté l'impact, pas seulement l'activité
• **Traiter 2× comme une direction**, pas un quota atteignable en vidant des sorties sans propriétaire dans main

Les récits 10× sonnent audacieux dans un deck. 2× avec responsabilité survit au contact avec la production.

Les valeurs IA battent les mandats IA

Honeycomb ne s'est pas arrêté à un objectif de productivité. L'équipe a écrit des valeurs IA—principes sur transparence, sécurité émotionnelle et ce que « bon » signifie quand les machines rédigent le premier jet.

La phrase qui voyage le plus vite sur engineering Twitter est aussi la plus opérationnelle :

• **Chaque sortie IA doit avoir un propriétaire humain.** Si vous ne voulez pas votre nom dessus, ce n'est probablement pas du bon travail.
• **Qualité d'abord, quantité ensuite.**

Lisez cela comme politique, pas poésie. La propriété, c'est comment empêcher le goulot de passer de « frappe » à « changements de code que personne ne débogue ». Le même instinct que traiter la sortie agent comme du code fournisseur—sauf que le fournisseur, ici, c'est votre propre équipe un bon jour.

Mandats sans valeurs produisent du théâtre : tout le monde utilise l'outil assez pour paraître occupé, personne n'améliore le chemin de release, et les incidents de production s'accumulent à cause de changements de code que personne ne peut expliquer entièrement.

Ce qui déplace vraiment le goulot

Si la génération est bon marché, investissez là où la génération n'a jamais été le problème :

• **Cadence de release et clarté de rollback**—qui peut annuler du code assisté par agent la nuit lors d'une alerte on-call sans le chat ?
• **Observabilité sur les chemins que l'IA touche**—auth, paiements, écritures de données, intégrations tierces
• **Profondeur de review sur l'intégration**, pas la syntaxe—ce changement se comporte-t-il sous trafic réel ?
• **Préparation on-call**—l'ingénieur on-call peut-il expliquer la feature sans ouvrir l'historique des prompts ?

La vision Honeycomb n'est pas accidentelle. L'observabilité, c'est comment déboguer des systèmes que vous n'avez pas entièrement authorship. C'est plus vrai, pas moins, quand l'IA rédige la première version.

Agences web et équipes produit le ressentent à plus petite échelle : une landing client avec formulaire cassé n'est pas un « échec IA ». C'est un échec de livraison qui a commencé dans une fenêtre de chat.

Une checklist 2× pratique pour les équipes web

Vous n'avez pas besoin du stack Honeycomb pour utiliser la même discipline :

• Choisir une expérience **bornée** par sprint—un funnel, une intégration, un fix perf—pas « IA partout »
• Nommer un **propriétaire humain** sur chaque PR assistée par agent avant merge ; pas de propriétaire, pas de ship
• Mesurer le **cycle time vers la production**, pas les mots générés
• Suivre **incidents ou reverts** sur chemins touchés par l'IA mensuellement ; cette courbe compte plus que les graphiques de tokens
• Écrire trois **valeurs IA** que votre équipe partage ; plus court qu'un doc de politique, plus fort qu'un mandat d'outil

Un objectif 2× est réaliste. Un objectif 10× est surtout un titre. Les objectifs réalistes prennent de l'élan avec le temps.

La conclusion à contre-courant

Charity Majors n'a pas dit aux ingénieurs de taper moins. Elle leur a dit de posséder plus—et de viser un impact qui survive au débogage.

Plus de code généré par l'IA sans propriété humaine ne rend pas votre équipe plus rapide. Elle allonge votre file d'incidents. Choisissez 2× avec des valeurs, pas 10× avec des métriques qui paraissent impressionnantes mais ne mesurent pas l'impact réel. Vous voulez un second avis sur où la vitesse agent aide—ou dépasse—votre boucle release et review sur un site marketing ou frontend produit ? Écrivez-nous.