Arregla tu vida con Grok Bot en 1 minuto.

Jorge·约 12 分钟阅读

2026年10月15日10月15日

文章封面：Arregla tu vida con Grok Bot en 1 minuto.

文章目录

Si sos freelancer o indie hacker, tu problema no es la falta de ideas, sino que sos uno solo: uno solo para el código, los mails, las facturas, la propuesta que tenías que mandar ayer y el posteo que nunca sale. El título es un guiño al artículo de Dan Koe sobre cómo arreglar tu vida en un día, que tiene razón en algo importante: quién querés ser lo decidís vos, y no se lo tercerizás a ninguna IA. A mí, ese orden personal me lo dio el Interview Ready de silver.dev, (https://ir.silver.dev/) que me hizo volver al gimnasio, comer bien y ordenar la oficina antes de tocar un solo bot. Lo que sí podés delegar es todo lo que no te deja ser esa persona, y el «1 minuto» es lo que tarda en arrancar el sistema que te devuelve las horas. Este artículo es la guía completa de cómo lo armé, pieza por pieza, para que lo copies.

El problema: sos un procesador de un solo núcleo

Multiplexate

Un freelancer trabaja en serie: termina una cosa y recién ahí arranca la otra, así que mientras escribís código nadie contesta mails, mientras contestás mails nadie vende y mientras vendés el Proyecto C espera "para mañana". En sistemas eso tiene nombre, estás bloqueado, y la solución también lo tiene: multiplexar, que es lograr que un solo canal (vos) atienda muchos flujos a la vez porque cada flujo lo ejecuta otro y vos solamente decidís. El resto del artículo es cómo se arma eso en la práctica, con qué herramientas y con qué reglas para que no se te vaya de las manos.

La arquitectura completa

Antes de ir paso a paso conviene ver el mapa entero, porque cada pieza tiene un trabajo concreto y no se pisan entre sí. Grok Bot es el centro: ahí vive un asistente principal, que es el único al que le hablo, y debajo de él un equipo de bots especializados (CTO, Marketing, Ventas, Finanzas, Email y un dev por proyecto), cada uno con su contexto, su memoria y sus herramientas, más las salas de grupo donde se coordinan y las rutinas que los despiertan solos. ClickUp es el hub donde todo queda escrito: tareas, contenido, contactos, CRM y la cola de trabajo para los agentes de código. Cursor pone los agentes de código en la nube, que toman una tarea, trabajan en su propia máquina y terminan en un pull request en GitHub. Un VPS en Hetzner corre un runner propio de GitHub Actions, al que le dicen "skynet", que se encarga del CI y de los deploys. Y Orca es la herramienta para correr varios agentes de código en paralelo cuando el trabajo es local, en la Mac. Arriba de todo estoy yo, con una sola regla que no se negocia: ningún bot manda nada afuera ni mergea sin mi OK.

Guía paso a paso para armarlo

Paso 1: el asistente principal, tu jefe de gabinete

Todo arranca con un único asistente en Grok Bot, y la clave es que sea el único al que le hablás. No le pedís cosas al bot de Finanzas ni al de Marketing directamente: le decís al principal lo que necesitás, con tus palabras y como te salga, y él entiende qué pediste, lo reparte a quien corresponde y te hace el seguimiento. Para que funcione tenés que conectarle lo básico (mail, calendario, drive, tu gestor de tareas y, si programás, tus repos), porque un asistente que no ve tu bandeja ni tu agenda es un chat más. Lo primero que le pediría es que se presente como tu jefe de gabinete, que te diga qué puede ver y qué no, y que quede escrita desde el día uno la regla de que nada sale a terceros sin tu aprobación. Si te tenés que acordar de qué le pediste a cada bot, no te multiplexaste, te fragmentaste; el asistente principal existe justamente para que esa memoria no esté en tu cabeza.

Paso 2: los bots especializados, uno por rol

Una vez que el principal funciona, sumás bots especializados, y la regla es simple: cuando algo te duela dos veces, hacele un bot. En mi caso la dirección son tres: un CTO, que piensa la arquitectura, prioriza y dirige a los devs; un Marketing (CMO), que se ocupa del blog, las redes y una revisión diaria de cómo viene todo; y Ventas, que arma propuestas, hace seguimiento y mantiene el CRM, apoyándose en Marketing y en el CTO cuando una propuesta toca producto o precio. Después viene la operación, que es todo lo aburrido que te come la semana: Email, que lee la bandeja, separa lo urgente y te deja borradores para revisar; Finanzas, que sigue cobros y facturas; y otros más chicos como compras y archivos. Para el desarrollo tengo un dev por proyecto (Proyecto A, B, C), y es probablemente la decisión que más me ordenó, porque cada uno tiene solamente el contexto de su repo y de su cliente y no mezcla nada. Cuando crees cada bot, pedile al principal que lo arme con cuatro cosas claras: qué rol cumple, qué contexto tiene (y cuál no), qué herramientas puede usar y qué tiene prohibido. Por ejemplo: "Creá un bot de Ventas. Mantiene el CRM en ClickUp, prepara propuestas y seguimientos como borradores, puede pedirle datos al CTO y a Marketing, y nunca le escribe a un cliente sin mi OK."

Paso 3: ClickUp como hub y CRM

Los bots necesitan un lugar común donde dejar las cosas escritas, y para mí ese lugar es ClickUp. La estructura es aburrida a propósito: un espacio por proyecto, y dentro de cada uno las mismas listas, Blog, Social, Outreach y CRM, más una lista especial que se llama "Cursor · Agentes". Así cada bot sabe dónde leer y dónde escribir sin que se lo tengas que repetir: Marketing deja los borradores del blog y de redes en sus listas, Ventas mueve contactos y oportunidades en Outreach y CRM, y los devs y el CTO cargan las tareas de código en "Cursor · Agentes". La magia está en esa última lista: cuando una tarea pasa al estado "asignada a agente", la toma una rutina de los días hábiles a la mañana y le lanza automáticamente un agente de Cursor en la nube. Por eso conviene escribir cada tarea como si se la dieras a alguien nuevo que no conoce el proyecto: qué hay que lograr en una frase, por qué (con el link a la charla donde se decidió), cuándo se considera terminada, en qué repo y qué queda fuera de alcance. Si un humano nuevo no la entendería, el agente tampoco.

Paso 4: salas de grupo por proyecto

Hay trabajo que no es de un solo bot: un lanzamiento necesita que Marketing sepa qué entra, que el CTO diga qué es viable y que el dev del proyecto lo construya. Para eso existen las salas de grupo, una por proyecto, donde junto a los bots que tienen que ponerse de acuerdo y los dejo coordinar entre ellos. Yo entro, tiro el objetivo en dos líneas y me voy; cuando vuelvo, en vez de tener que hacer de mensajero entre tres conversaciones, encuentro un plan escrito en ClickUp, una tarea en "Cursor · Agentes" que al otro día va a ser un PR, y los borradores de contenido esperando mi revisión. La diferencia con trabajar en serie es enorme, porque yo no coordino: decido. Y como cada bot conserva su contexto, el CTO no se llena de tuits ni Marketing de detalles de la base de datos.

Paso 5: rutinas programadas, para que el sistema arranque sin vos

Un equipo que solamente trabaja cuando le hablás sigue dependiendo de vos, así que el siguiente paso son las rutinas: tareas que se disparan solas en un horario. No hacen falta muchas, alcanzan unas pocas por día. La primera que te recomiendo es un resumen a la mañana con qué entró, qué vence hoy y qué está trabado. Después, una revisión diaria de marketing, donde el CMO mira cómo viene todo y propone qué publicar. Y la que más tiempo me ahorra es la rutina de los días hábiles a la mañana que revisa la lista "Cursor · Agentes" de ClickUp y lanza un agente de código por cada tarea en "asignada a agente". El efecto es que el día arranca aunque yo esté en el gimnasio: cuando me siento, ya tengo el resumen, hay agentes trabajando y lo único que me queda son los puntos de decisión, que son revisar PRs y aprobar borradores.

Paso 6: agentes de código en la nube, una tarea igual a un PR

Para el código uso agentes en la nube de Cursor, y la regla es una tarea, un agente, un PR. El flujo completo es así: la tarea vive en "Cursor · Agentes", alguien (yo o un bot) la pasa a "asignada a agente", la rutina de la mañana la detecta y lanza un agente que trabaja en su propia máquina, sin tocar la mía, hasta abrir un pull request en GitHub con su diff. Ahí corre el CI y, casi siempre, una revisión adversarial, que es poner a otro agente a buscarle problemas al trabajo del primero, porque cuatro agentes ven más que dos. Recién después aparezco yo: leo, pido cambios o mergeo, y el merge es lo único que no delego nunca. Lo lindo de esto es el paralelismo, porque cuatro tareas asignadas son cuatro agentes trabajando al mismo tiempo y cuatro PRs esperándome cuando tengo un rato, en lugar de cuatro días de trabajo en fila.

Paso 7: un VPS en Hetzner para el CI y los deploys

El CI y los deploys no corren en los runners compartidos de GitHub sino en un VPS en Hetzner con un runner propio de GitHub Actions, al que le dicen "skynet". Cuando un agente abre un PR, los checks corren ahí, y cuando yo mergeo, el deploy sale de ahí también. La ventaja es tener una máquina propia, siempre prendida y bajo tu control, para todo lo que pasa entre el PR y producción. El consejo que te dejo, aprendido en la práctica: si tenés repos públicos, no dejes que los PRs de forks corran en tu runner propio, porque eso es literalmente dejar que un desconocido ejecute código en tu servidor; limitá qué repos pueden usarlo y pedí aprobación para los workflows de contribuidores externos.

Paso 8: Orca para los agentes locales

No todo es nube. Para el trabajo local en la Mac uso Orca, un entorno de desarrollo pensado para agentes (open source, de Stably) que permite correr varios agentes de código de terminal en paralelo, como Claude Code, Codex o el agente de Cursor, cada uno en su propio git worktree, con terminales, diffs y navegador en la misma app, y con un CLI para que los propios agentes puedan manejar el entorno. Es la contraparte local de los agentes en la nube: sirve cuando quiero ver de cerca cómo trabajan varios agentes sobre el mismo repo sin que se pisen, y comparar sus resultados antes de quedarme con uno.

Paso 9: las compuertas, o cómo dormir tranquilo

Todo lo anterior funciona porque hay una regla de seguridad muy clara: los bots nunca mandan mensajes externos ni mergean sin el OK del humano. Adentro tienen manos libres: pueden leer el mail y el calendario, investigar, redactar borradores, crear y mover tareas en ClickUp, abrir PRs y revisarse entre ellos. Pero cualquier cosa que salga al mundo, sea un mail a un cliente, un posteo, un merge a la rama principal (y por lo tanto un deploy) o algo que toque plata, pasa por mí, y si no hay OK queda en borrador. Esa regla es la que te permite delegar de verdad, porque el peor caso de un bot que se equivoca es un borrador que descartás, no un mail mandado a un cliente. Escribila en cada bot desde el primer día y no hagas excepciones "por esta vez".

Lo que veo en X

No soy el único que lo ve, aunque vale la pena escuchar también a los que advierten. Hetong Li lo resumió así: "The question is no longer 'Can one person do everything?'; it's 'How much can one person orchestrate?'". Y Neo Teng contó el caso de un indie hacker que probó cinco agentes en paralelo y volvió a uno: "By the time I prompt the 5th, the 1st is done—and I forgot what I asked." Las dos cosas son ciertas, y por eso el asistente principal, ClickUp y las rutinas importan tanto: son lo que hace que orquestar no te queme la cabeza. En mi caso el resultado ya es concreto, porque este sistema me ayudó a cerrar una venta que pensaba que no iba a salir.

Cuánto cuesta

Todo mi stack sale unos 400 USD por mes en total, y es lo que me deja trabajar como un equipo. En IA uso ChatGPT Pro, Claude Max, X Ultra (antes grok super heavy); en cloud y desarrollo, Helmcode, Hetzner, Vercel, Cloudflare, GitHub, Google Cloud y AWS; y en productividad, Google Workspace, Microsoft 365, ClickUp, iCloud+ y Google One. Finanzas: @wallbit_app y Lannis para el monotributo. Igual, no necesitás todo esto para arrancar: con un asistente y un par de herramientas ya te multiplexás.

Setup en 1 minuto

No arranques con doce bots; arrancá con uno.

Primero conectá lo básico (mail, calendario, drive, tu gestor de tareas y, si programás, tu repo), después pedí tu primer bot con algo así como "Creá un bot de Email. Que lea mi bandeja todos los días, me separe lo urgente, me prepare borradores para revisar y nunca mande nada sin mi OK", y por último programá una rutina: "Todos los días a las 8 mandame un resumen: qué entró, qué vence hoy y qué está trabado." Listo, eso es el minuto.

A partir de ahí vas creciendo con la misma regla de siempre: si te duele vender, armá un bot de Ventas; si te duele cobrar, uno de Finanzas; si tenés tres proyectos abiertos, un dev por proyecto; si dos bots se tienen que poner de acuerdo, una sala de grupo; y cuando el código empiece a acumularse, una lista en ClickUp que lance agentes.

Cerrando

Las tres reglas que me quedaron después de todo esto son simples: vos decidís y ellos ejecutan, con los merges, los mensajes que salen y la plata siempre pasando por tu aprobación; un contexto por bot, porque un bot que hace de todo hace todo mal; y revisiones adversariales, porque un agente que revisa lo que hizo otro encuentra lo que el primero no vio. Primero tenés que ser la persona que vive la vida que querés, y eso no lo hace ningún bot; pero una vez que lo sos, dejar de ser el cuello de botella de tu propio trabajo es cuestión de armar el equipo. Una persona, muchos hilos, en paralelo.

Referencias