La configuración guiada es la forma en que SuperDevSpace cierra ese hueco. El agente abre el sitio en el navegador integrado de la app, hace los clics que tiene permitidos y te pasa la página, con una indicación y una frase, justo cuando el siguiente paso te toca a ti.

Por qué «que lo haga el agente» es la respuesta equivocada

La versión fácil de esta función le daría al agente todo el navegador: leer cada campo, escribir en cada casilla, pulsar cada botón. Sería rápido, y sería mala idea. Un proceso de configuración está lleno de cosas que un agente no debería tocar nunca:

• tu contraseña y el código de un solo uso de tu móvil;
• números de tarjeta, datos bancarios y documentos de identidad;
• las condiciones que aceptas y el pago que apruebas.

Así que el diseño empieza por el otro extremo. El agente hace el trabajo rutinario —navegar, encontrar la página correcta, escribir un nombre de proyecto, pulsar Crear— y todo lo personal o vinculante se queda contigo.

Cómo transcurre una configuración guiada

El bucle es el mismo en todos los sitios, incluso en los que nadie ha escrito instrucciones.

Al terminar, puedes comprobar el resultado sin mostrar ningún secreto en pantalla:

$ grep -o '^PADDLE_[A-Z_]*=' .env
PADDLE_API_KEY=
PADDLE_CLIENT_TOKEN=
PADDLE_WEBHOOK_SECRET=
PADDLE_ENVIRONMENT=

Reglas que impone la app

Son comprobaciones dentro de la app, y el agente no puede desactivarlas:

• Ni entran secretos ni salen secretos. El agente no puede escribir en un campo de contraseña, tarjeta, CVC, IBAN, código de un solo uso o identidad. Cuando lee la página o toma una instantánea, esos valores están ocultos y se eliminan de cualquier texto que lea.
• Las capturas se tapan. Los campos sensibles y cada frame de otro origen —un widget de tarjeta, un recuadro de «Iniciar sesión con Google»— se cubren antes de que un agente vea una imagen.
• Sin scripts en páginas sensibles. Ejecutar JavaScript en la página se rechaza en cualquier página que muestre uno de esos campos.
• El consentimiento y el pago son tuyos. Hacer clic en una casilla de condiciones o en un botón de «Pagar» / «Realizar pedido» se rechaza.
• Todo es visible. Lo que hace el agente en el panel de navegador se te muestra en el banner del panel mientras ocurre.
• Los secretos se quedan fuera de la conversación. Un valor leído como secreto se marca como sensible, y al agente se le indica que nunca lo repita en el chat, en informes, en notas de tareas ni en notificaciones.

Cualquier sitio web, no una lista de integraciones

La configuración guiada es un bucle, no una biblioteca de scripts. Funciona en un sitio para el que nadie ha escrito pistas, porque el agente lee la página que tiene delante. Para algunos servicios incluimos breves archivos de pistas —por ejemplo, el panel sandbox de Paddle y RevenueCat— que le dicen al agente dónde suelen estar los ajustes para desarrolladores. Los paneles mueven sus menús constantemente, así que las pistas lo dicen claro: si la página y la pista no coinciden, manda la página.

Esto importa más de lo que parece. El código de integración que escribe un agente es solo la mitad de una funcionalidad; la otra mitad es la cuenta, la clave y el webhook en el sitio web de otro. Con la configuración guiada, ambas mitades ocurren en la misma sesión, con el mismo agente, y tú dedicas tu tiempo solo a los pasos que solo tú puedes hacer.

Dónde encaja

La configuración guiada forma parte del mismo espacio de trabajo que todo lo demás en SuperDevSpace: el agente que escribe tu integración de pagos es el mismo que te acompaña a crear sus claves, en un panel de navegador junto a su terminal. Si eres nuevo por aquí, por qué creamos SuperDevSpace explica el resto del equipo que lo rodea.

Pruébalo

La prueba dura 14 días de Premium, sin tarjeta. Descarga SuperDevSpace, pídele a un agente que configure un proveedor de pagos o de analítica para tu proyecto y deja que te pase la página cuando te toque.

SuperDevSpace ejecuta un manager y varios workers sobre un mismo repositorio a la vez. Este artículo explica el mecanismo que los mantiene separados —los git worktrees— y las reglas exactas que sigue la app con ellos.

Qué es un git worktree

Un repositorio git tiene normalmente un único directorio de trabajo. git worktree permite que un mismo repositorio tenga varios, cada uno en su propia rama, todos compartiendo la misma base de objetos. No hay un segundo clon ni una segunda copia del historial: un worktree nuevo cuesta los archivos de un checkout y nada más.

Puedes probarlo a mano en cualquier repositorio. Los comandos son los mismos en todas partes; solo cambia el shell:

git worktree add -b agent/frontend-demo ../myrepo-frontend
git worktree list
cd ../myrepo-frontend && git status
cd - && git worktree remove ../myrepo-frontend

git worktree add -b agent/frontend-demo ..\myrepo-frontend
git worktree list
cd ..\myrepo-frontend; git status
cd ..\myrepo; git worktree remove ..\myrepo-frontend

Cada worktree tiene su propio HEAD, su propio índice y sus propios archivos. Dos procesos pueden editar, compilar y testear en dos worktrees a la vez sin ver los cambios a medias del otro. Es justo la propiedad que necesita un equipo de agentes.

Cómo los usa SuperDevSpace

Las reglas son sencillas y las mismas para todas las organizaciones:

• El manager trabaja en tu checkout principal. Planifica, revisa y fusiona; es el único lugar donde se juntan las ramas.
• Cada worker recibe su propio worktree en su propia rama. Cuando el manager contrata a un worker, la app ejecuta git worktree add -b <rama> <ruta> para él. La rama se llama agent/<nombre-del-worker>-<marca> salvo que tú le hayas dado un nombre.
• Los worktrees viven en la carpeta de datos de la app, en worktrees/<organización>/<worker>, nunca dentro de tu repositorio. Tu carpeta de proyecto no se llena de directorios de agentes.
• Cada turno se commitea. Cuando un worker termina un turno, la app hace commit de todo lo que cambió en su worktree (agent(<nombre>): turn). Nada de lo que hizo un worker queda solo en un directorio de trabajo sin commitear.
• La fusión es un squash merge. Cuando el manager acepta el informe de un worker, la rama se fusiona en tu línea con git merge --squash y un solo commit. Si hay conflicto, la app aborta la fusión y deja el repositorio limpio para la siguiente operación, en lugar de dejarte en mitad de un merge con conflictos.
• Una operación de git a la vez por repositorio. Los directorios de los worktrees aíslan los archivos; una cola por repositorio serializa los propios comandos de git, así que dos workers que terminan en el mismo instante nunca compiten por los metadatos de git.

En el tablero, esto se ve como varias tareas en curso a la vez, cada una de un worker distinto, cada una con su propia rama debajo.

Lo que lo hace práctico

Un worktree recién creado solo contiene lo que git rastrea. Eso no suele bastar para ejecutar un proyecto: node_modules, un .env local, archivos generados. Dos detalles lo resuelven.

Un script de preparación por repositorio

Si tu repositorio tiene .super/scripts/setup-worktree.sh, la app lo ejecuta dentro de cada worktree nuevo antes de que arranque el worker, con SUPERDEV_MAIN_REPO apuntando a tu checkout principal. Su salida se muestra en directo —una instalación larga no es una espera a ciegas— y puedes cancelarlo.

#!/usr/bin/env bash
set -euo pipefail
# Copiar archivos solo locales desde el checkout principal
cp "$SUPERDEV_MAIN_REPO/.env" .env 2>/dev/null || true
# Instalar dependencias (pnpm enlaza desde un store compartido, así que es rápido)
pnpm install --frozen-lockfile

Submódulos

git worktree add deja los submódulos vacíos. Si el worktree nuevo tiene un archivo .gitmodules, la app ejecuta en él git submodule update --init --recursive, para que ningún worker compile contra una dependencia que falta sin avisar.

Limpiar sin perder trabajo

Los worktrees se acumulan. La app los recupera, pero con cautela:

Un worktree con cambios sin commitear, o con una rama que tiene trabajo que aún no está en tu línea, se queda donde está. Una carpeta borrada se puede recrear; el trabajo perdido, no. La misma cautela se aplica a las ramas: la app lleva la cuenta de las ramas que creó y solo toca esas.

Qué cambia para ti

Con cada worker en su propia rama, «ejecutar cuatro agentes a la vez» deja de ser una apuesta. Puedes:

• dar al manager una directiva que se divide en tareas independientes y dejar que los workers trabajen en paralelo;
• leer el diff de cualquier worker por separado, junto a la conversación que lo produjo;
• rechazar el cambio de un worker sin molestar a los demás;
• seguir usando tu checkout principal mientras el equipo trabaja.

Es la misma disciplina que usa un equipo humano, aplicada a agentes que no pueden avisarte de que están a punto de pisarse. Si te preguntas por qué construimos toda una app alrededor de esto, el primer artículo cuenta la historia.

Pruébalo

La prueba de 14 días es Premium, sin tarjeta. Descarga SuperDevSpace, apunta una organización nueva a un repositorio y mira cómo aparecen los worktrees a medida que el manager contrata a sus primeros workers.

Por ese hueco creamos SuperDevSpace. Es una app de escritorio que convierte la CLI que ya tienes en un pequeño equipo: un manager que planifica el trabajo y workers que lo hacen, cada uno en su propio terminal y su propio git worktree.

El problema de un agente en un terminal

Trabajar con un solo agente de código es una maravilla para una sola tarea. Se desmorona en cuanto tienes tres cosas que hacer en el mismo repositorio:

• Puedes abrir un segundo terminal, pero entonces ambos agentes editan el mismo checkout. Uno ejecuta la suite de tests mientras el otro está a mitad de un refactor.
• Te conviertes en el jefe de proyecto. Tú repartes el trabajo, tú recuerdas qué terminal tenía qué tarea, tú copias el contexto de una sesión a otra.
• Nadie apunta lo que pasó. Cuando vuelves de comer, el único registro es el scrollback del terminal.

Nada de esto es un problema del modelo. Es un problema de organización, y la organización es algo que el software hace bien.

Qué hace realmente SuperDevSpace

En SuperDevSpace cada repositorio es una organización. Cada organización tiene un manager: una sesión real de una CLI de agentes, en un terminal real que puedes ver y en el que puedes escribir. Le das al manager una directiva en lenguaje natural, escribiéndola o dictándola por voz.

Después, el manager hace lo que haría un líder de equipo:

Puedes intervenir cuando quieras. Cada agente tiene una vista de chat y su terminal real —una sesión, dos formas de verla— y cada cambio aparece como un diff junto a la conversación que lo produjo, para que lo revises antes de que llegue a tu línea principal.

Tu suscripción, tu máquina, tu código

La decisión de diseño más importante es también la más sencilla: SuperDevSpace controla una CLI que ya pagas. Nunca revendemos acceso a modelos, así que nada de lo que ejecutas aparece en una factura nuestra más allá de la propia suscripción a SuperDevSpace.

Esa decisión tiene consecuencias que nos gustan:

• Los agentes se ejecutan como procesos locales en tu máquina, sobre tus repositorios locales. Tu código fuente, tus prompts, la salida del terminal y las rutas de tus archivos nunca se envían a nuestros servidores. Nuestro servicio de cuentas guarda una cuenta, un estado de suscripción y una lista de dispositivos.
• Eliges la CLI por organización. Claude Code, OpenAI Codex, Gemini CLI, Aider, Qwen Code, Cursor CLI y OpenCode se pueden seleccionar. Claude Code es la que la app domina hoy: hooks, reanudación, herramientas MCP, respuestas a permisos. Las otras seis arrancan y funcionan; la app las marca como experimentales y te dice qué extras aún no están conectados en lugar de fallar en silencio.
• Nada queda encerrado en nuestra nube, porque no hay ninguna nube haciendo el trabajo.

Antes de la primera directiva, conviene comprobar que la CLI y el repositorio están donde esperas:

$ claude --version
$ cd ~/code/tu-proyecto
$ git status

Lo que rodea al equipo

Un equipo necesita algo más que terminales. Algunas cosas que vienen con todos los planes:

• Un tablero que dice la verdad. Sprints, tareas, briefs e informes. Un informe dice qué falló, no solo qué salió bien.
• Inspector. Haz clic en un elemento de tu página web en ejecución y envíalo a un agente con el componente, el archivo y la línea. Funciona con Vite, Next.js y sitios estáticos.
• Aprobaciones desde el móvil. Cuando un agente necesita una decisión, te la pide. La app del móvil muestra el tablero, los agentes y las aprobaciones pendientes, para que respondas a una petición de permiso lejos de tu mesa.
• Una pizarra por organización (Excalidraw) que los agentes pueden leer y en la que pueden dibujar.

Premium añade las piezas que llegan más lejos: un modo de diseño basado en Penpot con un agente Designer que dibuja en el archivo, programaciones que ejecutan directivas según un calendario y un enlace entre pares que permite a un manager en tu Mac pasar trabajo a un manager en tu PC con Windows. La página de precios tiene la comparación completa.

Lo que no prometemos

Un equipo de agentes sigue necesitando un jefe: tú decides qué se construye y tú apruebas lo que llega a tu rama principal.

Pruébalo

La prueba dura 14 días de Premium, sin tarjeta. Tu suscripción a la CLI sigue siendo tuya, y tu código también. Si quieres ver al equipo trabajando en tu propio repositorio, descarga SuperDevSpace y dale al manager su primera directiva.