Voy a contarte algo que no me deja en buen lugar. Hace dos años automaticé un proceso de clasificación de documentos en TramitApp. Me llevó tres semanas montarlo. Funcionaba genial. Era elegante. Estaba orgulloso. El problema es que el proceso manual que reemplazaba le llevaba a una persona quince minutos al día. Quince minutos. Haz las cuentas: tres semanas de mi tiempo (el del CTO, que no es precisamente barato) para ahorrar quince minutos diarios de un empleado.
Lo peor no es la matemática absurda. Lo peor es que tardé meses en darme cuenta de que había hecho el imbécil.
La seducción de automatizar
La verdad es que automatizar es adictivo. Hay algo profundamente satisfactorio en construir algo que funciona solo. Ver cómo los datos fluyen, las decisiones se toman y los resultados aparecen sin que tú hagas nada. Es como ver caer las fichas de dominó. Es bonito. Es hipnótico. Y es una trampa.
Porque la pregunta correcta nunca es "puedo automatizar esto". La respuesta a eso siempre es sí. La pregunta correcta es "debería automatizar esto". Y esa pregunta es mucho más difícil de responder.
Tengo ochenta agentes de IA en producción. Lo que no cuento en la versión bonita de esa historia es que por cada agente que funciona hay al menos dos que construí y tiré a la basura. Agentes que automatizaban cosas que no merecían ser automatizadas. Agentes que creaban más problemas de los que resolvían. Agentes que funcionaban perfectamente pero que nadie necesitaba.
Los tres tipos de automatización inútil
Después de años haciendo esto, he identificado tres formas de perder el tiempo automatizando. Las tres me han pillado. Algunas más de una vez.
La primera: automatizar lo que es más rápido hacer a mano. Ese ejemplo del principio. Quince minutos al día. Pero es que además esos quince minutos los hacía una persona que disfrutaba haciéndolo, que conocía las excepciones, que detectaba anomalías que ningún algoritmo habría pillado. Al automatizarlo, no solo desperdició mi tiempo: perdimos un punto de control humano que tenía valor real.
La segunda: automatizar lo que cambia constantemente. Esto me ha pasado con scrapers web, con integraciones de APIs de terceros, con flujos que dependían de formatos de datos que cambiaban cada dos meses. Automatizas algo que funciona hoy y mañana se rompe porque la otra parte ha cambiado algo. Y acabas dedicando más tiempo a mantener la automatización que el que habrías dedicado a hacer la tarea a mano.
Tengo un scraper de cómics que es el ejemplo perfecto. Funciona, descarga, importa, cataloga. Genial. Hasta que la web cambia su estructura HTML. Entonces hay que reescribir el parser. En tres meses lo he reescrito cuatro veces. Un amigo me dijo: "tío, ¿no sería más fácil descargarlos manualmente?" y la verdad es que tenía razón. Pero claro, el ego del ingeniero no te deja aceptar eso fácilmente.
La tercera: automatizar lo que no entiendes del todo. Esta es la más peligrosa. Automatizar un proceso que haces "más o menos así" sin haberlo analizado a fondo. Sin conocer todos los casos borde, todas las excepciones, todos los caminos alternativos. Lo que ocurre es previsible: la automatización cubre el camino feliz y falla en todo lo demás. Y como el fallo es silencioso —el agente no se queja, simplemente hace las cosas mal—, a veces tardas semanas en descubrir el desastre.
Cuando los agentes rompen cosas
Te cuento tres historias reales sin maquillar.
Un agente de sincronización de datos entre sistemas se comió un campo de metadatos por un error en el mapeo. No se cayó. No dio error. Simplemente sobreescribió información correcta con información vacía. En silencio. Durante cuatro días. Cuando nos dimos cuenta, había que restaurar manualmente cientos de registros. Nos llevó un día entero arreglarlo.
Otro agente estaba configurado para borrar automáticamente archivos duplicados de una biblioteca. El criterio de "duplicado" tenía un fallo sutil: consideraba duplicados archivos que tenían el mismo título pero eran ediciones distintas. Borró cuarenta y siete archivos únicos antes de que me diera cuenta. Algunos los recuperé de backup. Otros no.
Siempre digo que hay que entender cómo funciona la herramienta. Pues bien, eso aplica doblemente cuando la herramienta toma decisiones por ti. Porque un chatbot que se equivoca te da una respuesta mala y tú la corriges. Un agente que se equivoca actúa sobre datos reales antes de que puedas intervenir.
Y la tercera: un agente de importación automática que, por un bug en la lógica de clasificación, importó trescientos archivos al sistema equivocado. No al sistema de literatura, sino al de gaming. Trescientos libros de novela romántica aparecieron de pronto en la biblioteca de reglamentos de rol. Mis hijos se lo pasaron en grande cuando lo descubrieron. Yo, menos.
La regla del dolor real
Después de todos estos tropezones, ahora tengo una regla que aplico antes de automatizar cualquier cosa. La llamo la regla del dolor real: solo automatizo algo si el dolor de hacerlo manualmente es real, frecuente y cuantificable.
Real: no me vale "sería guay automatizar esto". Tiene que haber un problema tangible. Tiempo perdido, errores recurrentes, cuellos de botella que bloquean a otras personas.
Frecuente: si algo me pasa una vez al mes, probablemente no merece automatización. Si me pasa todos los días, es candidato. La frecuencia es clave porque el retorno de la automatización depende directamente de cuántas veces se ejecuta.
Cuantificable: tengo que poder ponerle números. Cuánto tiempo me lleva, cuántas veces falla, cuánto cuesta cada error. Si no puedo medirlo, no puedo saber si la automatización ha merecido la pena. Y sin esa medición, caigo en la trampa de pensar que todo lo automatizado es bueno por definición.
Hay un gráfico de XKCD que debería ser obligatorio para todo el que quiera automatizar algo. Muestra cuánto tiempo puedes invertir en automatizar una tarea según la frecuencia con que la haces y el tiempo que te ahorra cada vez. Es la tabla de la verdad de la automatización. Y la mayoría de las cosas que automatizamos caen del lado de "no merece la pena".
Lo que sí merece la pena automatizar
Dicho todo esto, no quiero que se entienda que automatizar es malo. No. Automatizar es buenísimo cuando se hace bien. El problema es que "bien" no significa "elegante" ni "completo". Significa "en el sitio correcto".
Las cosas que mejor funcionan automatizadas en mi experiencia son:
Las tareas con reglas claras y datos limpios. Si puedes describir el proceso como un diagrama de flujo sin asteriscos ni "depende", probablemente es buen candidato. Si necesitas tres párrafos de excepciones para explicar cómo funciona, probablemente no lo es.
Las tareas donde el error humano es frecuente. Copiar datos entre sistemas, verificar formatos, validar campos obligatorios. Cosas donde la gente se equivoca no por incompetencia sino por aburrimiento o fatiga. Ahí la automatización brilla de verdad.
Las tareas que escalan mal. Si hoy te lleva diez minutos pero el mes que viene serán treinta y en seis meses serán dos horas, automatizar tiene sentido aunque hoy no parezca urgente. Piensa en la tendencia, no en el momento.
El coste oculto que nadie menciona
Hay algo que los evangelistas de la automatización nunca dicen: todo lo automatizado hay que mantenerlo. Y el mantenimiento no es gratis.
Cada agente que construyes es una cosa más que puede fallar. Que necesita monitorización. Que requiere actualizaciones cuando cambian las dependencias. Que hay que revisar cuando algo se comporta raro. Cada automatización es un compromiso a largo plazo, no un proyecto que terminas y olvidas.
Cuando hablé de dejar de competir y empezar a construir, me refería también a esto: construir significa hacerte responsable de lo que construyes. Y a veces la decisión más inteligente es no construir.
De mis ochenta agentes, calculo que dedico unas tres o cuatro horas por semana a mantenerlos. Eso incluye revisar logs, arreglar cosas que se rompen, actualizar lógica cuando cambian los requisitos. No es mucho si lo comparas con lo que me ahorran. Pero es una inversión continua que hay que tener en cuenta.
Gergely Orosz escribe mucho sobre este tema: la deuda técnica de la automatización. Cada sistema automatizado que no se mantiene se degrada. Y un sistema degradado no es simplemente menos eficiente: es peligroso, porque sigue funcionando pero produce resultados incorrectos. Es peor que no tener automatización, porque al menos sin ella sabes que estás haciendo las cosas a mano.
Mi framework actual (después de muchas hostias)
Hoy, antes de automatizar cualquier cosa, paso por esta checklist:
Uno: ¿cuánto tiempo me lleva hacerlo a mano? Si es menos de treinta minutos a la semana, no lo automatizo. Punto.
Dos: ¿cuántas veces al mes va a ejecutarse? Si es menos de diez, probablemente no merece la pena.
Tres: ¿los datos de entrada son fiables y estables? Si dependen de un tercero que puede cambiar su formato cuando quiera, cuidado.
Cuatro: ¿puedo describir todas las reglas sin ambigüedad? Si necesito decir "depende" más de dos veces, no está listo para automatizar.
Cinco: ¿quién lo va a mantener? Si la respuesta es "nadie porque es automático", mal empezamos.
Seis: ¿qué pasa cuando falle? Porque va a fallar. ¿Hay un plan B? ¿Hay alertas? ¿Hay forma de detectar el fallo antes de que cause daño?
Si pasa las seis, adelante. Si no, más vale hacer las cosas a mano y dedicar ese tiempo a algo que sí merezca la pena.
La automatización madura es saber decir "esto lo hago a mano"
Escribí hace poco sobre la curiosidad como disciplina. Pues la automatización madura también es una disciplina. Y la parte más difícil de esa disciplina no es construir sistemas. Es resistir la tentación de construir sistemas cuando no hacen falta.
Porque hay un orgullo muy concreto del técnico que dice "lo he automatizado todo". Y hay un orgullo más difícil de alcanzar que dice "he automatizado solo lo que tiene sentido y el resto lo hago a mano porque es más eficiente así".
La verdad es que no automatizo todo. Ni de lejos. Hay cosas que hago a mano todas las semanas porque el contexto cambia demasiado, porque el criterio humano es insustituible o porque simplemente es más rápido. Y no me da ninguna vergüenza.
El objetivo nunca fue automatizarlo todo. El objetivo siempre fue trabajar mejor. Y a veces, trabajar mejor significa cerrar el editor de código y hacer las cosas con las manos.
Deja un comentario ¡Tu opinión me interesa!