Tenía un escenario de Make que publicaba mis posts en LinkedIn. Funcionaba bien, la mayoría de las veces. Hasta que un día no funcionaba: una conexión caducada, un permiso que la plataforma había cambiado sin avisar, un módulo que esperaba un campo que ya no existía. Y entonces el post que tenía que salir a las nueve salía a las once, después de media hora revisando un diagrama de burbujas conectadas.

No es una crítica a Make ni a n8n. Son herramientas magníficas y siguen teniendo su sitio. Pero para algo tan concreto como difundir un artículo que ya está escrito, me di cuenta de que había construido una pequeña fábrica para hacer un trabajo que cabía en una frase.

Esa frase hoy es: «Publícalo».

El problema real no es escribir, es difundir

Quien escribe con cierta regularidad lo sabe. El artículo te puede llevar dos horas, pero lo que viene después se come otra media hora que nadie ve:

• Abrir LinkedIn, pegar el texto, revisar que los saltos de línea no se hayan roto, subir la imagen, añadir los hashtags.
• Copiar la URL del post, ir a un acortador, generar el enlace corto.
• Pensar una frase distinta para X, porque allí no caben cuatro párrafos ni funciona el mismo tono.
• Repetir la jugada en Threads, con otro matiz.
• Comprobar que todo ha salido y que los enlaces llevan a donde tienen que llevar.

Son tareas pequeñas, pero tienen un problema: cortan el ritmo. Y cuando algo corta el ritmo, se aplaza. Y lo que se aplaza, muchas veces no se hace. He visto buenos artículos quedarse en la web sin que nadie los leyera porque a su autor —a veces yo— le dio pereza el último paso.

Un artículo que no se difunde es como una tienda bonita en una calle sin paso.

Lo que ha cambiado

Hasta hace poco, la única forma de quitarte ese trabajo era la que yo usaba: montar un flujo de automatización. Conectar cuentas, mapear campos, programar disparadores y mantenerlo vivo cada vez que una plataforma cambiaba algo.

Lo que ha cambiado es que Claude puede manejar el navegador por mí. No a través de una integración especial con cada red social, sino del mismo modo en que lo haría yo: abriendo LinkedIn en mi Chrome, con mi sesión iniciada, escribiendo en el cuadro de publicación y pulsando el botón.

Eso tiene una consecuencia enorme, y es que ya no necesito que exista un conector para cada cosa. Si yo puedo hacerlo con el ratón y el teclado, Claude también puede hacerlo, siguiendo unas instrucciones que he dejado escritas una sola vez.

Cómo es el flujo, paso a paso

Imagina que el artículo ya está listo y revisado, con su texto para LinkedIn, su imagen y sus hashtags. A partir de ahí, el recorrido es este:

1. Publicación en LinkedIn. Claude abre LinkedIn en el navegador, pega el texto respetando el formato, sube la imagen y publica. No inventa nada: publica exactamente el texto que yo he aprobado.

2. Enlace corto. Con la URL de la publicación ya creada, va al acortador y genera un enlace corto. Así el enlace es limpio, cabe en cualquier sitio y, de paso, me permite medir cuántos clics llegan desde cada red.

3. Un claim para cada red. Aquí está la parte que más me gusta. No se trata de copiar el post de LinkedIn en X. Claude escribe un claim corto y llamativo, adaptado a cada plataforma: más directo y con algo de tensión en X; más conversacional en Threads. Una frase que haga que alguien se pare y quiera saber más.

4. Difusión en X y Threads. Publica cada claim con el enlace corto en su red. El objetivo de estas publicaciones no es contar el artículo entero, sino llevar tráfico hacia él.

5. Comprobación. Al terminar, me devuelve los enlaces de cada publicación para que pueda verlas con un clic.

Todo empieza con una sola palabra. Todo el proceso, que antes me llevaba media hora repartida entre pestañas, ocurre mientras yo hago otra cosa.

Lo que gano (y no es solo tiempo)

El ahorro de tiempo es evidente, pero no es lo más importante. Lo que de verdad he ganado son tres cosas.

Constancia. Al eliminar el último paso incómodo, publico con más regularidad. Y en cualquier estrategia de contenido, la constancia vale más que la brillantez ocasional.

Coherencia. Cada red recibe un mensaje pensado para ella, pero todos apuntan al mismo sitio y cuentan la misma historia. Antes, con las prisas, acababa pegando el mismo texto en todas partes.

Sin mantenimiento. No hay escenarios que se rompan ni tokens que caduquen a las tres de la madrugada. Si LinkedIn cambia de sitio un botón, Claude lo ve, igual que lo vería yo.

Lo que no hace (y no debe hacer)

Conviene ser honesto con los límites, porque es ahí donde se decide si una herramienta es útil o peligrosa.

• No publica sin mi permiso. El flujo arranca solo cuando yo lo pido, y sobre un texto que yo he aprobado. Nada sale porque a la máquina «le parezca buena idea».
• Necesita mi sesión. Trabaja en mi navegador, con mis cuentas. Si no he iniciado sesión en una red, no puede publicar en ella, y eso es exactamente lo que quiero.
• No sustituye al criterio. Puede escribir un buen claim, pero la decisión de qué contar, a quién y en qué tono sigue siendo mía. La IA ejecuta; la dirección no se delega.
• No reemplaza a Make o n8n en todo. Si necesitas publicar cien piezas programadas al mes, cruzar datos con un CRM o disparar acciones sin que nadie esté delante, un flujo de automatización clásico sigue siendo la herramienta adecuada.

La pregunta no es si la IA puede publicar por ti. Es qué parte del trabajo merece tu atención y qué parte solo te la está robando.

Por qué esto importa más allá de las redes

Podría parecer un truco para ahorrarse unos minutos de LinkedIn. Pero lo que hay detrás es un cambio de forma de trabajar que va mucho más allá.

Durante años, automatizar algo exigía traducir el trabajo al lenguaje de la máquina: campos, disparadores, condiciones, módulos. Quien no sabía hacer esa traducción, dependía de alguien que sí. Ahora la dirección se invierte: la máquina entiende el trabajo tal y como lo describimos nosotros. Le explicas el proceso una vez, en tu idioma, y lo repite.

En una pyme, eso cambia las reglas. Hay decenas de tareas parecidas a esta —cortas, repetitivas, entre varias pantallas— que nunca se automatizaron porque no compensaba montar un flujo para ellas. Ahora sí compensa, porque el coste de montarlo es poco más que escribir bien las instrucciones.

Si quieres probarlo

Mi consejo es empezar pequeño y con algo que ya hagas a mano todas las semanas:

• Escribe el proceso tal y como lo haces, paso a paso, como si se lo explicaras a una persona nueva en el equipo.
• Define los puntos de control: qué tiene que aprobar una persona antes de que algo salga fuera.
• Pruébalo varias veces mirando, antes de dejarlo correr solo.
• Mide el resultado. Con el enlace corto sabrás si X o Threads te traen lectores de verdad o si es mejor centrar el esfuerzo en otra red.

Este mismo artículo ha salido así. Lo escribí, lo revisé y dije una palabra. El resto, como ves, ya ha llegado hasta ti.

¿Y tú? ¿Qué tarea repetitiva le quitarías hoy mismo de encima a tu equipo si bastara con explicarla una vez?