Tu automatización puede estar entregando la mitad de lo que promete y reportarte que todo salió bien.
La mía lo hizo durante dos meses. Un proceso que traía a la gente que reaccionaba a un post de LinkedIn devolvía 100 personas cuando existían 157. Perdía el 36% en cada corrida, sin un solo mensaje de error.
Hace unos días escribí sobre el ingeniero de crecimiento y los seis sistemas que arma. Este post es la otra mitad: construí esos seis sistemas y esto es lo que se rompió.
¿Por qué mi automatización dice que funciona si no veo resultados?
Porque "terminó sin error" y "hizo bien su trabajo" son dos cosas distintas, y casi ningún sistema te avisa cuál de las dos pasó.
El proceso de arriba llama a un servicio externo que tiene tope de 100 resultados por página. Le pedía un post, me devolvía 100, y se detenía ahí. La corrida salía verde y la lista se veía completa.
Se veía completa porque una lista de 100 nombres se ve igual de completa que una de 157 cuando no sabes que faltan 57.
Hubo otro caso peor en el mismo sistema. Los datos de los usuarios se guardaban en un archivo dentro del servidor, y ese servidor recrea su disco cada vez que publico código nuevo. Cada publicación borraba la información de todos, en silencio, y quien entraba al día siguiente veía su cuenta vacía sin explicación.
La operación de guardado siempre respondió que sí. Guardaba, nada más que en un lugar que dejaba de existir.
¿Cómo detecto que un proceso está fallando en silencio?
Pregúntale a cada fuente si de verdad trajo datos, no si terminó.
Mi generador de contenido leía los commits de la semana para tener material sobre qué escribir. Esa lectura apuntaba a dos rutas escritas a mano, del tipo c:/Users/Usuario/…, que solo existen en mi computadora.
En el servidor esas rutas no existen. El comando fallaba, el bloque que atrapa errores se lo tragaba, y la función devolvía texto vacío. Cada corrida, durante meses.
El generador nunca se quejó. Siguió escribiendo posts, solo que sin material.
Hoy esa ruta sale de una variable de configuración y viene vacía por default. Una fuente apagada que lo dice vale más que una prendida que miente.
El segundo lugar donde buscar es tu propia revisión de calidad. El comando que yo corría antes de dar algo por bueno se llamaba check y sonaba a que revisaba todo. Revisaba los tipos del código y nada más: las 22 pruebas del proyecto no se corrían nunca, ni en mi máquina ni en el servidor.
Verde en cada corrida, durante semanas, con la mitad de mis pruebas dormidas.
Te dejo algo gratis para arrancar. La guía completa para montar tu primer agente, 18 artículos paso a paso, está en gabrielneuman.com/como-instalar-claude-code. De cero a tenerlo funcionando en un par de horas, sin costo.
¿Cuánto cuesta de verdad una falla que nadie ve?
Cuando la falla toca algo que se paga por unidad, cuesta dinero en cada corrida.
postLeads, el sistema con el que trabajo esto, junta a quien reacciona y a quien comenta un post de LinkedIn, y después busca el correo de trabajo de cada persona. Ese correo se paga por contacto.
Las dos fuentes identifican a la misma persona con direcciones distintas: una manda un identificador opaco y la otra la dirección legible. Si eliminas repetidos comparando direcciones, no eliminas ninguno.
Resultado medido en un post real: 39 personas repetidas sobre 279. Cada una, un correo comprado dos veces en la misma corrida.
Hay una segunda capa del mismo problema que apareció al medirlo con calma. Sin quitar los acentos al comparar, "Juan Pérez" y "Juan Perez" eran dos personas distintas, y dos cobros.
El otro costo no se paga en dinero sino en credibilidad. El 2 de septiembre publiqué un texto de 2,786 caracteres en LinkedIn e Instagram al mismo tiempo. El sistema reportó ambas publicaciones correctas.
Instagram corta el texto en 2,200 caracteres. No rechazó el post: lo publicó cortado a media frase, terminando en "…el changelog en los ~". Se perdieron los últimos 586 caracteres, que eran el remate, y nada avisó.
Un post rechazado se nota y se corrige. Uno cortado sale y se ve mal.
¿Cómo verifico que la IA cumple las reglas que le di?
Sacando la regla del prompt y poniéndola como una revisión que corre después de generar.
Yo tenía una regla de voz: nada de muletillas de inteligencia artificial. Vivía como una petición dentro del prompt, que es la forma más débil de tenerla.
Un prompt pide, no verifica. El modelo recita la regla y la rompe en la misma respuesta, igual que pasa cuando le pides que escriba un blog que posicione sin sonar a IA y sale un texto correcto y vacío.
Ahora esa lista de frases vive como una constante del código con dos usos. El prompt la enumera y una revisión posterior la verifica, con el mismo conjunto de patrones. Hay una prueba que toma las frases que el prompt enumera y comprueba que la revisión rechace cada una.
Escribir esa prueba destapó dos huecos reales: un patrón que por un detalle técnico no coincidía nunca con nada, y una palabra que el prompt daba como prohibida y que ninguna regla verificaba.
Lo que dejé fuera de la lista importa igual. "Hoy en día" y "la clave está en" son español legítimo, y cazarlos volvería la revisión ruidosa. Una revisión ruidosa se apaga a los tres días.
Vale la pena contar cómo terminó esto. Pasé el borrador de este post por esa misma guarda y lo rechazó en el primer intento, porque yo estaba citando frases prohibidas como ejemplo y la revisión no distingue entre usar una frase y mencionarla. Reescribí el párrafo.
Ese es el estado correcto de las cosas: la regla me estorbó a mí antes de dejar salir un texto flojo.
¿Qué reviso antes de construir la siguiente automatización?
Cinco cosas, en este orden.
Que cada fuente diga cuándo está vacía. El bloque que atrapa errores y devuelve un valor en blanco es el enemigo. Una fuente sin datos tiene que gritarlo.
Qué corre de verdad tu comando de calidad. Ábrelo y lee qué ejecuta. El mío decía check y revisaba un tercio de lo que yo creía.
Un conteo manual de un caso. Toma una corrida, cuenta a mano lo que debió traer y compáralo. Treinta segundos de aritmética contra dos meses de datos incompletos.
Las reglas que te importan, en código. Si la regla vive solo en el prompt, es una sugerencia.
Mide antes de apilar la siguiente capa. Yo agregué flujos, revisiones y bots encima de un generador al que le faltaba materia prima.
Ahí está el remate honesto de todo esto. Tapé los seis agujeros, cada uno con su prueba, y el sistema hace lo que prometí que iba a hacer.
Los resultados de contenido no se movieron por eso. Cuando medí mi blog completo con Search Console, el 88% de las páginas no recibía un solo clic, y arreglar la maquinaria no cambió ese número.
El cuello no estaba en la máquina. Estaba en la materia prima que le daba de comer, y eso es otro trabajo.
Si estás armando algo parecido y quieres comparar notas sobre dónde se te está mintiendo el tuyo, escríbeme.
