Hace unos días me encontré con el CEO de una empresa a la que le hice una auditoría hace unos meses. Recordando aquella conversación, me dijo en confianza (y tengo su autorización para compartir esto):

“¿Por qué siempre todo tiene que ser tan difícil? Llevo mucho tiempo en tecnología y los proyectos que nos llegan siempre son muy complicados.”

Mi respuesta, después de unas cervezas y con toda franqueza, fue:

“Es que tu negocio está basado en limpiar la mierda de los demás.”

Y es verdad. Cuando tu modelo de negocio depende de rescatar proyectos fallidos, heredas decisiones que no tomaste, deuda técnica que no creaste, y problemas que no causaste.

Es lo opuesto al estoicismo: en lugar de enfocarte en lo que puedes controlar, tu día a día gira alrededor de lo que otros no pudieron controlar.

Esa conversación me llevó a tomar un café y recordar todas las veces que me encontré en esa situación: llega un proyecto y no tienes idea por dónde empezar.

El mundo antes de los LLMs era otro deporte.

Horas y horas en Stack Overflow buscando ese error críptico que solo 3 personas en el mundo habían visto. Cavando en issues de GitHub de hace 4 años, rezando para que alguien hubiera encontrado la solución. Leyendo documentación desactualizada. Probando combinaciones absurdas de versiones de bibliotecas hasta que algo funcionara.

Y cuando finalmente lo resolvías, sentías que habías conquistado el Everest. Pero también habías perdido medio día (o más) en algo que hoy se resuelve en 30 segundos.

No sé si era mejor o peor. Pero definitivamente era más difícil.

Lo que venía incluido

No extraño el sufrimiento. Había mucho que era simplemente innecesario: documentación desactualizada, errores crípticos, bibliotecas abandonadas por sus creadores. Fricción mal diseñada que no enseñaba nada.

Pero había algo que venía incluido, sin que lo pidieras: comprensión.

Cuando no había atajos, tenías que entender. No podías copiar una solución de Stack Overflow sin leer los comentarios que decían “esto rompe en producción”. No podías usar una biblioteca sin revisar cuándo fue el último commit. No podías avanzar sin saber por qué algo funcionaba.

Esa comprensión te daba criterio. Saber cuándo una solución era sólida y cuándo era una bomba de tiempo. Cuándo un error era síntoma de algo más profundo. Cuándo insistir y cuándo abandonar.

Hoy puedes saltarte esa parte. Y muchos lo hacen.

TikTok para C-Level

En el post anterior hablé del golpe de dopamina que dan los agentes de código. Puedes tener un API funcionando en horas. Features “listas” para el demo del viernes.

Es casi un TikTok para los C-Level: gratificación instantánea, scroll infinito de features.

Pero hay una trampa: si dejas que el LLM corra sin supervisión, sin criterio, sin alguien que entienda por qué las cosas funcionan (o no), lo que produces es más código. Más rápido. Con más deuda técnica escondida.

Más mierda.

Criterio es ver un PR de 800 líneas generado por un agente y saber en dos minutos que hay que tirarlo porque la abstracción está mal desde el inicio. Criterio es entender que “funciona” no significa “está bien”.

Y sin criterio, esa mierda termina en el escritorio de alguien como el CEO de la historia. Empresas enteras construidas sobre rescatar proyectos que parecían “listos” porque un agente los generó en una tarde de vibe coding.

El círculo

Ahí está la ironía:

  • El mundo pre-LLM era lento y doloroso, pero te daba criterio.
  • El mundo post-LLM es rápido y adictivo, pero sin criterio solo acelera la producción de desastres.
  • Y alguien tiene que limpiar esos desastres.

El CEO no estaba atrapado en un mal modelo de negocio por accidente. Estaba en el lugar exacto donde termina todo lo que se construye sin criterio. Cada proyecto “urgente” que llegaba a su escritorio era el resultado de alguien que generó código sin entender por qué funcionaba — o por qué iba a dejar de funcionar.

Sin criterio, no puedes diseñar sistemas que toleren fallos, porque no entiendes dónde van a fallar. Y cuando fallan, alguien más paga el costo.

Cierre

No estoy diciendo que volvamos a Stack Overflow como única fuente de verdad. Los LLMs cambiaron el juego y no hay vuelta atrás.

Pero el criterio —saber qué vale la pena, qué preguntar, qué descartar— eso no lo genera un prompt.

Lo genera haber entendido por qué las cosas fallan. Haberlo visto de cerca. Haber tenido que arreglarlo.

Y si no lo desarrollas, vas a terminar en uno de dos lugares: generando trabajo para alguien más, o siendo el que lo recibe.

El CEO de la historia eligió lo segundo. Le va bien. Pero cada vez que un proyecto llega a su escritorio, está pagando el costo del criterio que alguien más no tuvo.

Último consejo

Hace un tiempo fui a terapia. En una sesión le pregunté a mi psicóloga cómo hacía para escuchar todos los días tantos problemas de tantas personas y lucir como si eso no le afectara.

Su respuesta fue clara: no se llevaba eso para la casa. Ponía límites.

Así que la próxima vez que veas una arquitectura o un código que quieres tirar a la basura, primero haz las paces contigo. Entiende que todo eso que vas a limpiar no es culpa tuya.

Marco Aurelio y Epicteto estarían muy enojados de que te lo lleves a casa. Pero bueno, son estoicos. Ellos no pudieron controlar que aceptaras el contrato.