El código no se ejecuta en tu máquina, sino en la VM aislada del proveedor — paralelo, disparado por eventos, no se detiene aunque cierres el portátil
El código nunca sale — el agente trabaja en tu propia shell, delante de tus ojos, con acceso directo a tu red interna
No hay una única respuesta correcta, pero el árbol de decisión es claro: si tienes una tarea que involucra código de cliente, datos personales sujetos a normativa de protección de datos, o acceso a la red interna/VPN, el agente local — o el modo self-hosted del agente en la nube — es en la práctica la única vía segura. Incluso Cursor mantiene la opción de self-hosted machines para cargas de trabajo sensibles; esto es prueba de que la afirmación de que "la nube siempre es segura" ni siquiera el propio proveedor la sostiene como absoluta. En proyectos de código abierto, proyectos personales y tareas de alto paralelismo tipo "10 PRs independientes durante toda la noche", el agente en la nube gana — pero el precio de esa victoria suele ser una suscripción de nivel Pro+/Ultra. La respuesta real de 2026 es una mezcla de ambos, no una profecía, y es visible en la propia arquitectura de producto de los tres grandes proveedores: en el lanzamiento de Projects de Cursor el 10 de septiembre, el coordinador se ejecuta en la nube pero "activa automáticamente un agente local cuando algo necesita probarse en tu máquina". Claude Code separa la misma sesión como concepto de primera clase con las etiquetas `cloud` y `local`. Tú debes pensar esta dualidad no al elegir el producto, sino al elegir la tarea: que la decisión y los datos sensibles se queden en local, y que el volumen y el trabajo repetitivo disparado por eventos se ejecute en la nube.
| Categoría | Bulut ajanları (cloud agents) | Yerel terminal ajanları (local agents) |
|---|---|---|
| Rendimiento | 8/10 | 7/10 |
| Facilidad de aprendizaje | 7/10 | 8/10 |
| Ecosistema | 8/10 | 7/10 |
| Comunidad | 7/10 | 8/10 |
| Mercado laboral | 7/10 | 8/10 |
| A prueba de futuro | 9/10 | 7/10 |
// Agente en la nube — configuración del entorno de GitHub Copilot cloud agent
// Este archivo de workflow añadido al repositorio define con qué
// dependencias se levantará el entorno en la nube efímero (respaldado por GitHub Actions).
// Ruta del archivo: .github/workflows/copilot-setup-steps.yml
name: "Copilot Setup Steps"
on:
workflow_dispatch:
push:
paths:
- .github/workflows/copilot-setup-steps.yml
pull_request:
paths:
- .github/workflows/copilot-setup-steps.yml
jobs:
# El nombre del job DEBE SER "copilot-setup-steps" —
# el entorno del cloud agent ejecuta este job automáticamente al levantarse.
copilot-setup-steps:
runs-on: ubuntu-latest
permissions:
contents: read
steps:
- name: Checkout repository
uses: actions/checkout@v6
- name: Setup Node.js
uses: actions/setup-node@v7
with:
node-version: "22"
cache: "npm"
- name: Install dependencies
run: npm ci
- name: Warm build cache
run: npm run build --if-present# Agente de terminal local — trabajo en una sola máquina con Aider
# La instalación es un solo comando, el entorno es tu máquina; hay
# acceso directo a la red interna/localhost, el secreto/código no sale.
# 1) Instalación
python -m pip install aider-install
aider-install
# 2) Config persistente en la raíz del proyecto (.aider.conf.yml)
cat > .aider.conf.yml <<'CONF'
model: sonnet # alias integrado de aider (docs/config/model-aliases)
auto-commits: true
dark-mode: true
test-cmd: npm test
lint-cmd: npm run lint
CONF
# 3) Ejecutar en la terminal sobre archivos específicos
# (síncrono, sesión única — todos los diffs aparecen al instante en tu pantalla)
aider src/api/auth.ts src/api/session.ts \
--message "Añade rate-limit a la rotación de refresh tokens, actualiza los tests"
# 4) Acceso directo al servicio localhost de la red interna
# (no se necesita túnel/allowlist adicional — el agente corre en tu propia shell)
pg_isready -h localhost -p 5432 && aider --message "Añade el health check de la DB al CI"No hay una única respuesta correcta, pero el árbol de decisión es claro: si tienes una tarea que involucra código de cliente, datos personales sujetos a normativa de protección de datos, o acceso a la red interna/VPN, el agente local — o el modo self-hosted del agente en la nube — es en la práctica la única vía segura. Incluso Cursor mantiene la opción de self-hosted machines para cargas de trabajo sensibles; esto es prueba de que la afirmación de que "la nube siempre es segura" ni siquiera el propio proveedor la sostiene como absoluta. En proyectos de código abierto, proyectos personales y tareas de alto paralelismo tipo "10 PRs independientes durante toda la noche", el agente en la nube gana — pero el precio de esa victoria suele ser una suscripción de nivel Pro+/Ultra. La respuesta real de 2026 es una mezcla de ambos, no una profecía, y es visible en la propia arquitectura de producto de los tres grandes proveedores: en el lanzamiento de Projects de Cursor el 10 de septiembre, el coordinador se ejecuta en la nube pero "activa automáticamente un agente local cuando algo necesita probarse en tu máquina". Claude Code separa la misma sesión como concepto de primera clase con las etiquetas `cloud` y `local`. Tú debes pensar esta dualidad no al elegir el producto, sino al elegir la tarea: que la decisión y los datos sensibles se queden en local, y que el volumen y el trabajo repetitivo disparado por eventos se ejecute en la nube.
Solicita una consultoría gratuitaDepende — sí, pero no incondicionalmente. La propia postura oficial de Cursor ofrece la opción de self-hosted machines en lugar del modo estándar en la nube para código sensible ('keep tool execution entirely in your own network'); es decir, ni el propio proveedor dice que sea 'siempre seguro'. Para proyectos de código abierto o personales, el modo estándar en la nube se puede usar con confianza; si hay código de cliente o datos sensibles, debe preferirse el modo self-hosted o el agente local.