Más código generado por IA no hizo al equipo más rápido. Charity Majors apuntó a 2× igualmente.

Más código generado por IA no hace a tu equipo más rápido. Puede hacerte más lento.

No es una postura anti-IA. Es Charity Majors—cofundadora y CTO de Honeycomb—describiendo qué pasa cuando la generación escala y todo lo demás no. Honeycomb construye herramientas de observabilidad para sistemas de producción complejos. Si alguien debe confiar en la narrativa de velocidad, son ellos. Aun así eligieron un objetivo de productividad 2× en lugar de perseguir 10×, y escribieron valores de IA antes que mandatos.

La parte incómoda para la mayoría de líderes de ingeniería: el cuello de botella nunca fue teclear. Es liberar software, depurarlo en producción y mantenerlo funcionando bien. Inunda el repo con salida de agentes y no compras velocidad—compras profundidad de cola en los pasos que ya dolían.

Escribir código nunca fue la parte difícil

Majors lo ha dicho con claridad durante años, mucho antes de que la IA generativa lo pusiera de moda: escribir código no era la restricción al enviar. Revisión, integración, despliegue, respuesta a incidentes y fiabilidad visible para el cliente lo eran.

La IA amplifica lo que ya tienes. Observabilidad fuerte y disciplina de release convierten el codegen en palanca. Bases débiles lo convierten en ruido que igual debes arreglar durante alertas on-call nocturnas.

Por eso una empresa cuya marca es «ver qué hace producción» se preocupa menos por pulsaciones por hora y más por si alguien puede ser dueño de lo que se envía.

Por qué Honeycomb eligió 2×, no 10×

Honeycomb adoptó un reto 2× en toda la empresa—inspirado en un impulso similar en Intercom—no como truco, sino como techo honesto. Doblar el impacto con IA en un año. No diez veces los tokens. No diez veces las líneas fusionadas.

Emily Nakashima, VP de Ingeniería de Honeycomb, ha descrito el despliegue en conversaciones públicas: un memo de fundadores que anima a experimentar, luego la pregunta recurrente de los ingenieros—¿cómo lo medirán?

La respuesta de Honeycomb es instructiva para quien copia un memo de «ingeniero 10×» de redes sociales:

• **Desenfatizar métricas únicas** que invitan a hacer trampa—gasto en tokens, líneas de código, conteo de PR
• **Confiar en la auto-información** sobre si la IA aumentó el impacto de verdad, no solo la actividad
• **Tratar 2× como dirección**, no como cuota que alcanzas volcando salida sin dueño en main

Las narrativas 10× suenan audaces en un deck. 2× con responsabilidad sobrevive al contacto con producción.

Los valores de IA vencen a los mandatos de IA

Honeycomb no se quedó en un objetivo de productividad. El equipo escribió valores de IA—principios sobre transparencia, seguridad emocional y qué significa «bueno» cuando las máquinas redactan el primer borrador.

La frase que viaja más rápido en Twitter de ingeniería también es la más operativa:

• **Toda salida de IA debe tener un dueño humano.** Si no quieres tu nombre en ella, probablemente no es buen trabajo.
• **Calidad primero, cantidad segundo.**

Léelo como política, no como poesía. La propiedad es cómo evitas que el cuello de botella pase de «teclear» a «cambios de código que nadie depura». El mismo instinto que tratar la salida del agente como código de proveedor—salvo que aquí el proveedor es tu propio equipo en un buen día.

Mandatos sin valores producen teatro: todos usan la herramienta lo suficiente para parecer ocupados, nadie mejora la ruta de release, y los incidentes de producción se acumulan por cambios de código que nadie puede explicar por completo.

Qué mueve de verdad el cuello de botella

Si generar es barato, invierte donde generar nunca fue el problema:

• **Cadencia de release y claridad de rollback**—¿quién puede revertir código asistido por agente de noche durante una alerta on-call sin el chat?
• **Observabilidad en rutas que la IA toca**—auth, pagos, escrituras de datos, integraciones de terceros
• **Profundidad de revisión en integración**, no sintaxis—¿se comporta este cambio bajo tráfico real?
• **Preparación on-call**—¿puede el ingeniero on-call explicar la función sin abrir el historial de prompts?

La visión de Honeycomb no es casual. La observabilidad es cómo depuras sistemas que no autorizaste por completo. Eso se vuelve más cierto, no menos, cuando la IA redacta la primera versión.

Agencias web y equipos de producto lo sienten a menor escala: una landing de cliente con formulario roto no es un «fallo de IA». Es un fallo de envío que empezó en una ventana de chat.

Una checklist 2× práctica para equipos web

No necesitas el stack de Honeycomb para usar la misma disciplina:

• Elige un experimento **acotado** por sprint—un funnel, una integración, un arreglo de rendimiento—no «IA en todas partes»
• Nombra un **dueño humano** en cada PR asistido por agente antes del merge; sin dueño, sin envío
• Mide **tiempo de ciclo a producción**, no palabras generadas
• Rastrea **incidentes o reverts** en rutas tocadas por IA mensualmente; esa curva importa más que gráficos de tokens
• Escribe tres **valores de IA** en los que tu equipo esté de acuerdo; más cortos que un doc de política, más fuertes que un mandato de herramienta

Un objetivo 2× es realista. Un objetivo 10× es sobre todo un titular. Los objetivos realistas ganan impulso con el tiempo.

La conclusión a contracorriente

Charity Majors no dijo a los ingenieros que teclearan menos. Les dijo que fueran dueños de más—y que apuntaran a impacto que sobreviva la depuración.

Más código generado por IA sin propiedad humana no hace a tu equipo más rápido. Alarga tu cola de incidentes. Elige 2× con valores, no 10× con métricas que parecen impresionantes pero no miden el impacto real. ¿Segunda opinión sobre dónde la velocidad del agente ayuda o supera tu bucle de release y revisión en un sitio de marketing o frontend de producto? Escríbenos.