Por qué rechazo el código de la IA incluso cuando funciona (y no soy el único)
El cuello de botella ya no es escribir código, es revisarlo. Cuando la IA genera más líneas de las que puedes entender, decir que no es lo responsable.
El otro día leí un artículo de Vinicius Brasil que me provocó un déjà vu inmediato. "When I reject AI code even if it works". 134 puntos en Hacker News y 77 comentarios después, está claro que tocó un nervio expuesto.
El argumento es directo y duele: los coding agents te generan código a una velocidad absurda. El infierno ahora es revisarlo. Y no hablo de PRs de compañeros — hablo de tu propio git diff después de soltarle un prompt a tu agente y aceptar lo que escupe.
Me pasa. Incluso siendo disciplinado —plan mode, tareas partidas en fases, cambios pequeños— acabo con la cabeza saturada revisando cosas que no he pensado yo.
Brasil da cinco motivos por los que manda el código de IA a la papelera aunque compile:
- Cuando no sé explicar el enfoque con mis propias palabras. Si no puedo defender por qué el código hace lo que hace como lo hace, no es mío.
- Cuando el diff es más grande que el problema. Si un cambio de tres líneas muta en 200 porque al agente le dio por "refactorizar" tres archivos de paso, lo descarto. Sin pestañear.
- Cuando mete abstracciones antes de que hagan falta. Las abstracciones prematuras eran un mal endémico antes de la IA. Ahora son peores, porque los modelos las regurgitan con una seguridad que asusta.
- Cuando el código funciona en local pero hace el sistema más opaco. Que compile y pase CI no significa que sea mantenible. "Code that runs and makes the CI green can still be a bad solution".
- Cuando confío más en el output que en mi criterio. Este es el punto más peligroso de todos. Si aceptas sugerencias porque "total, la IA sabrá más", has soltado el volante.
La discusión en HN fue un espejo incómodo. Ingenieros con meses usando agentes han desarrollado un olfato para el "olor a LLM" —y lo rechazan sistemáticamente. Otros defienden que los agentes ya son mejores que el desarrollador enterprise medio: nunca han visto a un modelo generar una clase FooImpl de 10.000 líneas en un solo archivo, pero sí a humanos hacerlo durante décadas.
"Si estoy de guardia resolviendo un problema que causó otro ingeniero, le pregunto qué pasó y me dice 'ni idea, lo escribió la IA', voy a pedir que lo echen mañana."
— Comentario en Hacker News
Los números no ayudan a los evangelistas ciegos. GitHub dice que los usuarios de Copilot "aceptan el 30% de las sugerencias". Vale. Pero aceptar no es acertar, y acertar no es aportar valor. El estudio de Uplevel en 2024 comparó equipos con y sin asistentes de IA: cero diferencias estadísticamente significativas en throughput de pull requests. Más líneas escritas, sí. Mejor software entregado, la cosa no está clara.
Martin Fowler y Thoughtworks publicaron hace unos días el case study de PRINCE, el sistema de IA que Bayer construyó para investigación farmacéutica. Su receta para sistemas de IA fiables: "context engineering" (controlar qué ve cada agente), "harness engineering" (orquestación, reintentos, validación, bucles de reflexión) y, por encima de todo, revisión humana obligatoria. Sin human-in-the-loop, no hay sistema que se sostenga.
Yo lo he vivido con Hermes, el sistema que mueve La Frontera IA. He tirado outputs a la basura por decenas. He reescrito prompts a las tantas. He visto al modelo generar HTML con variables vacías que reventaban la homepage entera. La IA es una herramienta espectacular, pero si no entiendes lo que suelta, eres pasajero, no piloto.
No va de ser un ludita. Va de que el código que entregas lleva tu nombre. Y cuando algo explote un domingo a las 3 de la mañana, el que va a abrir ese diff eres tú. El modelo ya estará ocupado generándole código a otro.