Al otorgar a un agente de inteligencia artificial acceso a un entorno aislado (Sandbox), surge una pregunta fundamental sobre cómo organizar los archivos en los que trabajará el agente. La plataforma Docker Sandbox (conocida como sbx) ofrece tres modelos principales para gestionar el código fuente, cada uno con un impacto directo en el flujo de trabajo del desarrollador y su interacción con el agente.
1. Montajes compartidos (Shared Mounts)
Esta opción permite compartir la ruta de trabajo actual desde la máquina host directamente con el entorno aislado. Al ejecutar sbx run desde la carpeta del proyecto, el directorio se monta en la misma ruta absoluta dentro del entorno. Este modelo es ideal para una colaboración estrecha en una sola tarea, ya que el desarrollador puede ver los cambios en su editor local inmediatamente y los servidores de desarrollo local pueden capturar las modificaciones mediante la función de recarga en caliente (Hot Reload).
Advertencia: Se debe tener cuidado con los conflictos de dependencias; los paquetes que contienen binarios nativos (Native Binaries) pueden funcionar en el entorno aislado de Linux y fallar en macOS o Windows, por lo que se recomienda unificar el entorno de ejecución o separar la instalación de dependencias.
2. Uso de árboles de trabajo de Git (Git Worktrees)
Esta opción es adecuada para ejecutar múltiples tareas al mismo tiempo. Asigna a cada tarea su propia carpeta y rama (Branch), permitiendo que cada árbol de trabajo se conecte en un entorno aislado independiente. La ventaja aquí es el aislamiento completo de las tareas, pero persiste una limitación técnica: el archivo .git apunta a metadatos fuera del alcance del montaje, lo que significa que operaciones como la verificación de estado (git status) o el cambio entre ramas deben realizarse desde la máquina host.
3. Modo de clonación (Clone Mode)
En este modo, la herramienta sbx crea una copia independiente del código dentro del entorno aislado, montando el código del host como solo lectura. Esto le otorga al agente acceso completo a Git dentro del entorno, haciéndolo completamente independiente en la gestión de ramas y confirmaciones (Commits). Una vez finalizado el trabajo, el desarrollador puede recuperar los cambios a través del repositorio remoto de Git (Remote).
¿Qué cambia esto en el flujo de trabajo del desarrollador?
Elegir el método adecuado depende de la naturaleza de la tarea y de su deseo de intervención directa:
- Colaboración cercana: Utilice el montaje directo si desea supervisar el trabajo del agente momento a momento.
- Independencia: Utilice el modo de clonación o los entornos aislados sin montaje (Mountless) si desea dar al agente espacio para gestionar tareas sin afectar su entorno de trabajo local.
- Gestión de múltiples proyectos: Se pueden utilizar herramientas de gestión de espacios de trabajo (Workspace Managers) para agrupar varios repositorios en un solo entorno, facilitando que el agente maneje proyectos interconectados (como frontend y backend).
Recuerde que los entornos aislados que no dependen del montaje de archivos del host (Mountless) requieren una gestión manual de puertos (Ports) para acceder a los servidores de desarrollo desde su navegador local, una práctica que aumenta la seguridad del aislamiento pero añade algunos pasos adicionales de configuración.