Por qué los equipos de IA publican más rápido pero lanzan peor: el problema de la deuda de intención

La IA hizo que escribir código fuera casi gratuito. Decidir qué escribir se volvió más difícil. Esa brecha es la deuda de intención, y se acumula más rápido que cualquier base de código heredada.

Garry Tan reporta publicar 37.000 líneas de código al día en cinco proyectos mientras dirige Y Combinator a tiempo completo. Los propios ingenieros de Anthropic acumularon 47 días de regresiones silenciosas en Claude Code antes de detectarlas en un postmortem público el 23 de abril de 2026. Ambas cifras describen el mismo problema desde extremos opuestos.

Si su equipo escribe más código que nunca pero obtiene peores resultados que hace un año, está observando cómo se acumula la deuda de intención en tiempo real. La deuda técnica era el impuesto por programar despacio. La deuda de intención es el impuesto por decidir despacio. Este artículo nombra el cuello de botella, explica por qué sus capas de revisión y evaluación no pueden detectarlo, y presenta las cuatro acciones que permiten saldarlo.

• La IA comprimió el tiempo de codificación entre 30 y 100 veces. El tiempo de decisión se comprimió entre 3 y 5 veces. Esa brecha es el nuevo cuello de botella.

• La deuda de intención vive por encima de toda capa de revisión. Los revisores de código con IA, las evaluaciones y los agentes de QA detectan código deficiente; no detectan algo incorrecto construido correctamente.

• La regresión silenciosa de 47 días de Anthropic en Claude Code es un postmortem de deuda de intención disfrazado de problema de evaluación. La desviación no estaba en el código, sino en lo que el equipo estaba prestando atención.

• La solución es estructural, no táctica. No se puede salir publicando más. Solo se puede salir decidiendo más rápido y más temprano.

• webvise trata la captura de intención como el entregable, no como una actividad previa de ventas sin coste. Vea dónde aplica esto en su equipo.

Qué es realmente la deuda de intención

La deuda técnica fue el término que Ward Cunningham acuñó en 1992 para describir el coste futuro de elegir una solución rápida sobre una limpia. El intercambio tenía una economía clara. Se publicaba antes, se pagaban intereses en forma de un mantenimiento más costoso después, y el principal permanecía en la base de código como algo que podía refactorizarse cuando hubiera tiempo.

La deuda de intención tiene la misma forma. El intercambio es código más rápido a cambio de decisiones más difusas. Se publica antes porque la IA escribió la implementación en 30 minutos en lugar de tres días, y los intereses son todo lo que sucede después cuando el equipo nunca llegó a definir cuál debía ser el resultado correcto.

El vocabulario es inexistente porque el intercambio es nuevo. Los escritos de Martin Fowler sobre nomenclatura e intención de diseño parten de un mundo donde escribir el código era el paso costoso, por lo que definir bien el diseño se amortizaba con menos reescritura.

Esa suposición se invirtió en 2024. Cuando reescribir lleva un día, el paso de diseño deja de amortizarse como antes. Los equipos lo notan y omiten el diseño, que era precisamente donde la intención quedaba comprimida en algo que la siguiente persona podía razonar.

Dos modos de fallo que he observado personalmente.

El primero: una funcionalidad se publica en tres días cuando antes de la IA habría tardado tres semanas. Funciona. También resuelve un problema que los usuarios no tenían, porque la especificación era un mensaje de Slack y el implementador era un agente de Cursor. El coste de construirla era tan bajo que el equipo nunca volvió a cuestionar si valía la pena.

El segundo: un ingeniero sénior elimina seis direcciones de producto en un año. Ninguna muere por razones técnicas. Todas mueren en la fase de preventa, y el ingeniero sigue saltándosela porque escribir código le parece más productivo. Ese ingeniero soy yo, y el coste del postmortem de esas seis direcciones fue mayor que cualquier deuda técnica que haya saldado jamás.

Ambas historias son deuda de intención con evidencias. La mayoría de los equipos de ingeniería siguen intentando resolverlo en la capa de construcción: otro revisor, otra evaluación, otro linter. La solución está una capa más arriba. Si su equipo está acumulando evidencias como estas, webvise fue construido en torno a esa inversión.

Los números detrás del cambio

Los datos de primera mano más claros sobre la asimetría provienen del archivo gstack ETHOS de Garry Tan, publicado en abril de 2026. Tan publica un kit de herramientas de agentes de código abierto desde Y Combinator e instrumenta sus agentes con ratios de compresión humano-IA explícitos para cada tipo de tarea.

Lea la tabla columna por columna. El boilerplate se comprime 100x, la escritura de tests 50x, el desarrollo de funcionalidades 30x. La arquitectura y la investigación se comprimen 5x y 3x.

Las tres últimas filas son trabajo de intención. Se comprimen, pero a una décima parte de la velocidad de las tres primeras. Esa es la fuente estructural de la deuda de intención: codificar es ahora casi gratuito; decidir sigue siendo costoso.

Para concretarlo: si su equipo solía dedicar el 80% de la jornada de ingeniería a código y el 20% a decisiones, la nueva proporción tras una compresión de 30x en código es aproximadamente del 12% código y el 88% decisiones. La mayoría de los equipos mantuvieron la misma plantilla, la misma cadencia de reuniones y la misma estructura de revisión, y luego observaron cómo la segunda columna se desbordaba.

Ese desbordamiento es lo que parece la deuda de intención en la práctica.

Tres síntomas de que ya la está acumulando

La deuda de intención es invisible hasta que se nombra. Tres síntomas aparecen de forma recurrente en los equipos con los que trabajo.

Reflejo de recorte de alcance en trabajo de coste completado

Se encuentra escribiendo tres pruebas en lugar de diez, omitiendo la documentación, llamando suficiente al 80%. El instinto tenía sentido cuando el tiempo humano era el recurso limitante. Con IA en el proceso, la versión completa cuesta los mismos minutos que el atajo.

El reflejo es ahora pensamiento heredado, aplicado de forma automática. El coste es el hábito de decisión que dice que publicar antes es mejor que publicar bien, cuando publicar antes ya no le ahorra ningún tiempo.

Más revisiones, menos decisiones

Elie Steinbock publicó una tesis el 20 de abril de 2026 que nombra la revisión como el nuevo cuello de botella. Enumera siete capas de defensa, desde revisores de código con IA como Cubic y CodeRabbit hasta agentes de QA dedicados y observabilidad delimitada. Los equipos adoptan las capas y la superficie de revisión absorbe más tiempo de la jornada.

La deuda de intención vive por encima de todas estas herramientas. Los revisores con IA detectan código deficiente; no detectan algo incorrecto construido correctamente. Un agente de QA que recorre cada flujo en cada lanzamiento le dirá que el flujo funciona, no si el flujo debería existir.

Deriva silenciosa que solo se detecta en postmortems

Anthropic publicó un postmortem el 23 de abril de 2026 documentando 47 días de regresiones silenciosas en Claude Code. El marco principal era que las evaluaciones no detectan la deriva. El marco más profundo es que la deriva se acumula en la brecha entre lo que el equipo pretendía y lo que el sistema estaba haciendo realmente.

Todo equipo que utiliza desarrollo asistido por IA tiene su propia ventana de 47 días abierta en este momento. La mayoría de los equipos solo la descubrirán en un postmortem.

Por qué las revisiones y evaluaciones no pueden detectarla

Las herramientas de revisión responden a la pregunta de si el código hizo lo que decía la especificación. Las suites de evaluación responden si el modelo se comportó como esperaba la evaluación. Ambas son preguntas correctas y acotadas. Ambas tratan la especificación y la evaluación como verdad absoluta.

La deuda de intención se acumula en la capa superior. El coste vive en la brecha entre lo que el cliente necesitaba, lo que decía el briefing y lo que capturaba la especificación. Para cuando el código llega ante una herramienta de revisión, la especificación ya ha bloqueado la intención. El revisor no puede detectar un defecto de especificación; solo puede señalar defectos de implementación frente a una especificación defectuosa.

Esta es la misma forma que tiene la deriva de Anthropic. El equipo de Claude Code tenía evaluaciones. Las evaluaciones pasaban.

La deriva estaba en lo que medían las evaluaciones frente a lo que los usuarios experimentaban realmente. 47 días de luz verde, usuarios reales encontrando una regresión cada día. La solución es un feedback más cercano entre las personas que deciden qué medir y las que observan la señal en producción.

El pensamiento centrado en el cuello de botella de revisión trata esto como un problema de herramientas. Es un problema de capas. Complemente este artículo con el anterior sobre por qué el software generado por IA sigue necesitando revisión de ingeniería para la mitad del argumento correspondiente a la capa de construcción. Para saldar la deuda de intención, hay que hacer una pregunta diferente, antes.

La capa de decisión no se comprime como el código

El marco de Tan para explicar por qué esto es estructural: el criterio lo aporta usted mientras habla con el agente. El agente aporta completitud. La persona aporta dirección y juicio. El criterio no funciona con la misma curva de compresión que el código.

Tres componentes del criterio que la generación de código no puede reemplazar.

Elegir el problema correcto

La tesis de servicios como software de Alex Vacca, publicada a través del socio de Sequoia Julien Bek en abril de 2026, captura la versión más amplia de esto. Los vendedores de software que venden la herramienta compiten con el modelo para siempre. Las empresas que son dueñas del trabajo y usan el modelo para entregarlo mejoran cada vez que el modelo mejora.

La misma lógica aplica dentro de los equipos. Los ingenieros que eligen el problema correcto mejoran cada vez que el modelo mejora. Los que solo ejecutan contra especificaciones recibidas se vuelven un commodity de la noche a la mañana.

Saber cuándo detenerse

Las herramientas de IA nunca le dicen que se detenga. Un LLM abordará el decimoséptimo ángulo del mismo problema con el mismo entusiasmo que el primero, y cada respuesta parecerá un avance. Sin una condición de salida externa, el bucle corre indefinidamente.

Los ingenieros experimentados imponían la salida aburriéndose o quedándose sin tiempo. Ambos presupuestos son ahora infinitos. La condición de salida debe establecerse explícitamente de antemano, antes del primer prompt.

La disidencia que aportan los ingenieros sénior

El resultado de primera mano más difícil que produce un ingeniero sénior es la disidencia: el mensaje de que esto es lo incorrecto que hay que construir, que cancela un trimestre de ejecución. Los agentes de IA no disienten. Construyen lo que se les pide, completamente, con una curva de compresión de 100x.

Se obtiene lo que se pidió, y solo después se descubre que se pidió lo incorrecto.

Cuatro acciones para saldar la deuda de intención

Estas son tácticas. Suponen que su equipo ya ha nombrado el problema y ha dejado de intentar absorberlo en la capa de revisión.

Prevenda antes de abrir el editor

Esta es la acción que tuve que reaprender a la fuerza. Si está construyendo algo para alguien más que usted mismo, obtenga un compromiso verbal, un depósito o una carta de intención antes de que cualquier agente escriba una línea.

El entusiasmo verbal, los votos de lanzamiento y una lista de espera sin nada en juego son señales de demanda débiles. El coste de construcción es tan bajo que el único filtro que queda es si el cliente pagará.

Trate la especificación como el artefacto duradero

Antes de la IA, la especificación era un documento de trabajo y el código era el artefacto. Después de la IA, el código es regenerable y la especificación es lo duradero.

Escriba especificaciones que nombren al cliente, los modos de fallo y la métrica de éxito de forma explícita. Almacénelas bajo control de versiones junto al código. Cuando la especificación cambia, la regeneración es trivial; cuando la especificación es incorrecta, ninguna regeneración lo salvará.

Ejecute una revisión de decisión con dos modelos

Un solo LLM puede racionalizar cualquier dirección; un segundo modelo invitado a disentir detecta la mitad de las malas decisiones. El patrón funciona para la revisión de código, donde uso Claude más Codex más Gemini con verificación cruzada en cada funcionalidad publicada.

El uso de mayor valor es la revisión de decisiones. Muestre dos modelos a la especificación, pídale que disentan, evalúe el desacuerdo antes de construir. El coste es mínimo comparado con construir lo incorrecto.

Mantenga un archivo de direcciones descartadas

Todo producto, funcionalidad o campaña que se descartó antes de publicarse va en un documento con el motivo. El motivo importa más que el recuento. Léalo antes de empezar cualquier cosa nueva.

El patrón de por qué mueren las direcciones es el saldo de deuda de intención más barato disponible, y casi todos los equipos lo omiten. Si está evaluando dónde aplicar estas acciones en su equipo, webvise puede ayudar.

Elegir un socio web en la era de la IA

El error más costoso que comete un equipo en la era de la IA es contratar una agencia que solo es dueña de la capa de construcción. Construir es ahora la parte barata. La capa de decisión (qué publicar, cuándo abandonar, quién es realmente el usuario) es donde reside el multiplicador.

La mayoría de las agencias siguen poniendo precio a la construcción porque eso es lo que su modelo de margen sabe hacer. webvise fue construido en torno a esa inversión.

Los proyectos de automatización con IA y aplicaciones full-stack comienzan con un sprint de descubrimiento que produce una especificación escrita, un listado de direcciones descartadas y una revisión de decisión con dos modelos para cada elemento de alcance comprometido. Una funcionalidad puede publicarse en un día. No se publicará ninguna hasta que el equipo haya acordado cómo es el éxito en producción.

Si ha publicado más código que nunca este trimestre y se siente más lejos de un producto funcional que hace seis meses, reserve una llamada de descubrimiento. La forma más rápida de saldar la deuda de intención es dejar de acumular más.