El impuesto de la vibra

Los agentes de codificación de IA más inteligentes están cada vez más optimizados para encargarse de tareas de software completas de extremo a extremo, pero muchos desarrolladores informan que esto produce código hinchado, andamiaje de pruebas excesivo, costos de tokens desbocados y menos control — un “impuesto de la vibra” para quienes deben revisar cada cambio. Otros replican que, con indicaciones cuidadosas, alcances pequeños y tratando a los modelos como desarrolladores junior dentro de un proceso de ingeniería convencional, logran sistemas grandes y fiables y ganancias significativas de productividad. El intercambio destaca una división creciente entre el “vibe coding” sin manos y los flujos de trabajo asistidos por IA estrictamente gestionados, así como preocupaciones de que los incentivos de los proveedores favorezcan el uso máximo de tokens sobre herramientas amigables para expertos.

Programador en pareja vs. agentes autónomos

  • Muchos quieren IA como un “programador en pareja” estrecho y rápido, que haga pequeñas ediciones precisas bajo নির্দেশ, no un generador de apps de cero a uno.
  • Enfoque recomendado: fuerte modularidad y SRP, interfaces limpias, y dejar que los agentes trabajen solo dentro de componentes pequeños y aislados para limitar el daño.
  • Surgen tres grandes corrientes: nunca usar IA; generación de una sola pasada “lo suficientemente buena”; y uso cuidadoso en el que la IA escribe código que los humanos revisan de cerca. Varios sostienen que solo la tercera es sostenible.

Lo que los comentaristas quieren decir con el “impuesto de la vibra”

  • Los modelos de frontera están cada vez más sesgados hacia un comportamiento de largo horizonte, de extremo a extremo, de “construirlo todo”.
  • Esto a menudo produce:
    • Razonamiento y salida excesivamente largos.
    • Andamiaje, pruebas y refactors excesivos que el usuario no pidió.
    • Uso agresivo de subagentes y herramientas, quemando muchos tokens.
  • Los ejemplos incluyen: revisiones de PR costosas que generan docenas de agentes; contratos elaborados de CI/pruebas que provocan ciclos tipo livelock; y modelos que dedican muchísimo más esfuerzo del necesario a tareas simples.
  • Para los usuarios que deben revisar cada línea, esta actividad extra se experimenta como un “impuesto” sobre tiempo, atención y dinero.

Flujos de trabajo y estrategias de mitigación

  • Algunos defienden flujos de trabajo spec-first: hacer que la IA redacte una especificación detallada, revisarla como humano y luego pedirle a un modelo (posiblemente más pequeño) que la implemente y a otro modelo que la revise.
  • Otros encuentran los flujos guiados por especificaciones más molestos que programar directamente.
  • Varios describen un desarrollo “microgestionado”: planificación paso a paso, tareas pequeñas, revisión continua y tratar a los agentes como desarrolladores junior muy conocedores dentro de un SDLC tradicional.
  • Algunos construyen arneses con múltiples subagentes especializados (redactor de especificaciones, experto de dominio, ingeniero, QA) para controlar el comportamiento.

Calidad, pruebas y crecimiento desmedido del código

  • Quienes lo apoyan: la IA sobresale en herramientas desechables y aplicaciones pequeñas, con más manejo de casos límite y pruebas de lo que los humanos se molestarían en escribir.
  • Quienes lo critican: los agentes sobreproducen pruebas triviales o frágiles y tuberías de CI verbosas; pequeños cambios tocan muchos archivos; la base de código de una empresa, mayoritariamente generada por IA, se describe como desordenada e inmantenible, aunque la dirección la celebre.
  • Existe preocupación de que RLHF y los entornos de entrenamiento insensibles a tokens empujen a los modelos hacia el crecimiento desmedido.

Experiencias y expectativas divergentes

  • Algunos informan de éxito casi sin fricción en proyectos sustanciales usando guardarraíles fuertes y disciplina de refactorización, y no pueden identificarse con las historias de terror.
  • Otros encuentran repetidamente que los agentes autónomos son ineficaces o derrochadores y prefieren flujos de trabajo manuales y estrictamente controlados.
  • Persiste el desacuerdo sobre si el marketing fomenta expectativas irreales de una sola pasada o si los usuarios no están aplicando pensamiento crítico y un proceso adecuado.