> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/es/2026/w32-a-builders-mac-also-needs-a-sweeper.md). # W32-El Mac de un Builder también necesita un Sweeper Tengo tres Mac. Mi máquina principal de trabajo es ahora un Mac Studio de escritorio. Lleva un chip M2 Max, una CPU de 12 núcleos y 64GB de memoria, y tiene conectados un monitor 5K y un micrófono Shure MV7+. Los recursos de hardware son bastante abundantes. Los cuellos de botella cotidianos vienen más del entorno de software. Codex, Claude Code, ChatGPT, Antigravity y Multica funcionan en paralelo de forma habitual. Detrás de ellos arrancan navegadores, servidores MCP, sidecars, máquinas virtuales aisladas y todo tipo de subprocesos. Node, Python, Rust, los proxies, las Skills, los elementos de inicio y las cachés también cambian continuamente. La última limpieza del entorno empezó con un pequeño error. La tarea diaria de gestión de Skills mostró `ModuleNotFoundError: No module named 'tomllib'`. Al investigarlo descubrí que el terminal interactivo y la tarea programada utilizaban distintos Python. En el Mac coexistían el Python del sistema, el de Homebrew, el instalado desde python.org y conda. Había problemas similares con Node y Rust. Cuando estos problemas locales se acumulan, el entorno deja poco a poco de ser comprensible. A veces un comando apunta a una versión antigua, no está claro a qué aplicación pertenece un proceso en segundo plano o una tarea funciona en el terminal y falla al ejecutarse de forma programada. Cuanto más rápido actúa un agente, más rápido se desvía el entorno de su estado previsto. Ahora veo el Mac como el sistema de producción de un Builder. Necesita una gestión continua. ### El Builder también debe ejercer de Sweeper Boris Cherny resumió hace poco el trabajo del equipo de Claude Code en cinco roles: Prototyper, Builder, Sweeper, Grower y Maintainer. El Builder convierte prototipos en productos e infraestructura aptos para producción. El Sweeper limpia interfaces, simplifica sistemas, retira funciones que han perdido valor y optimiza el rendimiento. [La publicación original de Boris](https://x.com/bcherny/status/2071379474277613732) propone combinaciones de roles para las distintas etapas de un producto. El Sweeper aparece en todas. Esto encaja muy bien con mi experiencia reciente. Los agentes tienen facilidad para añadir cosas. Pueden instalar herramientas, generar código, agregar configuraciones y crear Skills. El costo marginal de añadir ya es muy bajo; eliminar y consolidar todavía exige criterio. Qué ha dejado de tener valor, qué copias deben unificarse, qué gestor debe controlar el punto de entrada de un entorno de ejecución o qué automatizaciones podrían borrar por error un estado válido: todas estas preguntas requieren un Sweeper. Para un Builder individual, el trabajo del Sweeper también abarca el entorno local. Procesos, cachés, entornos de ejecución, configuraciones de proxy, elementos de inicio, Skills y configuraciones de agentes son recursos. Dependen unos de otros y se desvían continuamente de su estado previsto con el uso. Mi definición de un entorno limpio tiene cuatro puntos: los puntos de entrada importantes tienen un responsable claro, se puede explicar lo que está en ejecución, se pueden detectar las desviaciones y el sistema puede volver a un estado conocido. ### Qué recursos hay en un Mac Mis principales espacios de trabajo son Codex, Claude Code, ChatGPT, Antigravity y Multica. En el terminal uso Ghostty y cmux. Para el conocimiento utilizo sobre todo Basic Memory y Craft. Craft guarda notas, artículos y resultados organizados para la lectura humana. Basic Memory conserva conclusiones estables, procesos reutilizables y contexto que los agentes pueden consultar de forma continua. La capa de navegador y automatización inicia Chrome, Playwright y servidores MCP. También permanecen activos el software de seguridad de la empresa, las herramientas de proxy, los métodos de entrada de texto, los servicios de sincronización y los actualizadores de aplicaciones. Una aplicación de escritorio suele corresponder a un grupo de procesos. Claude Desktop inicia su propia máquina virtual aislada; Codex inicia un sidecar; los navegadores separan los procesos Renderer y GPU; y las herramientas de agentes lanzan subprocesos de Node, Python, MCP y navegadores. Mirar un proceso aislado en el Monitor de Actividad no basta para entender el consumo real de recursos. En mis revisiones agrupo los procesos principales y los Helper por familia de aplicaciones, y combino `memory_pressure`, swap, incrementos de CPU y conexiones de red para determinar si hay anomalías. Estos recursos presentan cuatro tipos de desviación. El primero afecta a procesos y almacenamiento. Una sesión termina, pero sus subprocesos siguen ahí. Las cachés de descargas, los registros y los artefactos de compilación crecen sin parar. La aplicación anfitriona también puede relanzar repetidamente procesos que ya se habían eliminado. El segundo afecta a la configuración y la red. El proxy del sistema, el entorno del shell, el entorno de arranque de la interfaz gráfica, las opciones de proxy propias de cada aplicación, el DNS y el estado de autenticación pueden cambiar de forma independiente. El tercero afecta a los entornos de ejecución. Homebrew, los instaladores oficiales, los gestores de versiones y los proyectos antiguos instalan por separado Node, Python o Rust. Al final, PATH decide cuál se utiliza. El cuarto afecta a los recursos que dan capacidades a los agentes. Distintas herramientas instalan Skills en directorios diferentes; las copias físicas empiezan a divergir; los enlaces simbólicos se rompen; hay actualizaciones en el origen; y el frontmatter o las rutas codificadas dejan de funcionar. Los tres primeros afectan a la estabilidad de los programas. El cuarto afecta a la capacidad del agente para utilizar la función correcta. Todos forman parte del mismo problema de gestión. ### El proxy es un entorno de varias capas El entorno del proxy es la capa con la que más tiempo he tropezado. En macOS existen varias rutas de proxy independientes. El proxy de red del sistema afecta a las aplicaciones que consultan la configuración de macOS. Las variables de proxy de `~/.zshrc` solo afectan al shell actual y a sus subprocesos. Los procesos iniciados desde Finder, el Dock o una aplicación de escritorio suelen heredar el entorno del `launchd` del usuario. Algunos navegadores y herramientas de línea de comandos tienen sus propias opciones de proxy. TUN, DNS y el estado de autenticación pertenecen a otras capas. Me encontré con un caso típico. La CLI de Antigravity ya funcionaba correctamente desde el terminal, pero el mismo entorno de ejecución en Multica seguía devolviendo un error de región no disponible. La primera solución estaba escrita en una función de `.zshrc`, así que solo cubría el terminal interactivo. Multica Desktop iniciaba el daemon desde la interfaz gráfica, sin leer `.zshrc`, y el tráfico terminaba saliendo de forma directa. La evidencia útil vino del proceso en ejecución. El entorno del daemon de Multica no tenía variables de proxy. La región de salida de una petición directa también era distinta de la que pasaba por el proxy local. Al final trasladé la lógica del proxy a un wrapper en el punto de entrada del ejecutable y simulé un arranque no interactivo con un entorno limpio para comprobar que la ruta de invocación real ya funcionaba. De este diagnóstico salió una regla estable: debo verificar el proceso de destino, no solo mi idea de cómo está configurado. Una misma herramienta puede arrancar desde el terminal, una aplicación de escritorio, una tarea programada, MCP u otro agente. Aunque tenga el mismo nombre, su entorno de ejecución puede ser completamente distinto. ### Cada entorno de ejecución debe tener un único responsable El error de `tomllib` terminó revelando cuatro instalaciones de Python. conda activaba `base` automáticamente, y los agentes instalaban paquetes en el entorno global sin que el usuario lo advirtiera. El instalador de python.org añadía su propio PATH a `.zprofile`, Homebrew conservaba otros Python y las tareas no interactivas podían encontrar antes la versión incluida en macOS. También había dos instalaciones de Rust. La de Homebrew aparecía primero en PATH, mientras que la versión administrada por rustup llevaba mucho tiempo sin actualizarse. En Node, el problema estaba en el prefijo global de npm. Cuando fnm cambia la versión de Node, también cambia el directorio global de instalación de npm, pero un wrapper antiguo de Claude Code seguía apuntando mediante una ruta fija a Homebrew. La entrada de ejecución y la de actualización señalaban dos sitios distintos. El comando funcionaba, pero no recibía las actualizaciones correctas. Después de la limpieza asigné un único responsable a cada uno de los tres entornos de ejecución principales. | Entorno de ejecución | Responsable | Función principal | | -------------------- | ------------------------------------------------------ | --------------------------------------------------------------------------------------- | | Node | [fnm](https://github.com/Schniz/fnm) | Gestionar las versiones de Node y cambiarlas según el proyecto | | Python | [uv](https://docs.astral.sh/uv/guides/install-python/) | Instalar Python, fijar la versión del proyecto, crear entornos y gestionar dependencias | | Rust | [rustup](https://rust-lang.github.io/rustup/) | Gestionar stable, beta, nightly, versiones específicas y componentes | Los entornos de ejecución incluidos en el sistema se conservan. Pertenecen a macOS, no forman parte de mi PATH habitual y no alojan dependencias de proyectos personales. Los que Homebrew instala como dependencias de otras formulae pueden seguir existiendo como dependencias internas, pero no deberían ocupar el punto de entrada del usuario. Homebrew es adecuado para gestionar paquetes del sistema, herramientas CLI estables, aplicaciones gráficas y dependencias de bajo nivel, como `ripgrep`, `jq` y `ffmpeg`, así como los propios gestores de versiones, como fnm y uv. Si una herramienta solo necesita la versión estable actual y no requiere cambios por proyecto, tiene sentido dejarla en manos de Homebrew. En los siguientes casos conviene utilizar directamente fnm, uv o rustup. 1. Varios proyectos necesitan versiones major o minor diferentes. 2. El proyecto debe fijar el entorno de ejecución mediante un archivo de versión. 3. Rust necesita las cadenas stable, beta, nightly o una correspondiente a una fecha concreta. 4. Los paquetes globales de Node cambian de prefijo al cambiar la versión. 5. Python necesita aislar las dependencias del proyecto para no contaminar el sistema ni el entorno global. 6. Los agentes, las tareas programadas y los shells no interactivos deben resolver el mismo punto de entrada verificable. Mi regla es sencilla. Homebrew gestiona paquetes; los gestores de versiones, lenguajes; los archivos de proyecto, versiones. PATH solo expone un punto de entrada predeterminado. Antes de retirar un entorno de ejecución antiguo, primero actualizo y verifico al nuevo responsable. En la migración de Rust completé las pruebas de compilación antes de eliminar Rust de Homebrew. En la de Python comprobé primero que el punto de entrada predeterminado de uv funcionara en un entorno limpio y después traté las instalaciones duplicadas de conda, python.org y Homebrew. Este orden asegura que el proceso de gestión no destruya mi capacidad de seguir trabajando. ### Dos rutinas de gestión continua Boris también ha insistido en que los agentes que ejecutan tareas prolongadas deben poder verificar su propio trabajo. En tareas muy largas, un agente en segundo plano puede encargarse de la verificación. También se puede usar un hook Stop para realizar comprobaciones deterministas y devolver los fallos al agente para que siga trabajando. Considera la retroalimentación de la verificación una de las formas más importantes de mejorar la calidad de los resultados, y estima, por experiencia, una mejora de entre dos y tres veces. [Publicación original](https://x.com/bcherny/status/2007179861115511237) Más tarde resumió la evolución de esta forma de trabajar como el paso del código fuente a los agentes y de los agentes a bucles de ejecución continua. El trabajo humano también pasa de escribir prompts en cada ronda a diseñar ciclos capaces de avanzar por sí mismos. En [su conversación en Meta @Scale](https://www.youtube.com/watch?v=Z47vatpsGPI), Boris describió los bucles como un salto de igual importancia. Un bucle eficaz necesita, como mínimo, un objetivo claro, el estado actual, retroalimentación de verificación y condiciones de parada. Después de cada ronda, el agente lee el resultado. Si la verificación falla, continúa; si completa el objetivo o alcanza los límites de presupuesto o riesgo, se detiene. El Sweeper marca la dirección de eliminar continuamente lo que sobra; la ingeniería de bucles hace que eso se repita. Creé dos rutinas en Claude para llevar estos principios de gestión a la operación diaria. La primera gestiona las Skills todos los días. Todas las Skills reutilizables pasan a una misma fuente de verdad administrada con Git, a la que Claude Code y Codex acceden mediante enlaces simbólicos. La rutina repara automáticamente enlaces rotos, directorios vacíos, residuos de caché y enlaces que faltan. Cuando encuentra copias físicas, Skills huérfanas, errores de frontmatter, actualizaciones en el origen o riesgos relacionados con credenciales, se limita a analizarlos e informar. La decisión final queda en mis manos. La segunda gestiona cada semana los recursos básicos del Mac. Primero recopila el estado de la memoria, la CPU, el swap y los procesos. Después agrupa los recursos por familia de aplicaciones e identifica patrones de residuos ya confirmados. Para terminar un proceso deben cumplirse a la vez tres condiciones: llevar activo más tiempo que el umbral, estar inactivo en términos de CPU y no tener sockets de red. La limpieza de cachés solo abarca contenido que puede reconstruirse. Los datos privados de las aplicaciones y los recursos cuya pertenencia no está clara solo se miden y se incluyen en el informe. Ambas rutinas respetan los mismos límites. Los scripts realizan acciones deterministas sin pérdida de información; el modelo analiza los casos que requieren criterio; y las personas se encargan de borrar, sobrescribir y ampliar permisos. Los hallazgos de cada ejecución también se incorporan a las Skills, los materiales de referencia y Basic Memory. La siguiente ronda consulta la fuente de verdad actualizada, de modo que la capacidad de gestión se acumula. ### Mantener la limpieza es una capacidad de ingeniería Antes entendía la configuración del Mac como un trabajo que se hacía una sola vez: instalar programas, configurar el shell y el proxy y empezar a usarlo. Ahora la frecuencia de cambio es mucho mayor. Los agentes instalan dependencias, arrancan servicios, crean cachés, generan Skills y modifican configuraciones. Node, Python y Rust se actualizan continuamente; las aplicaciones de escritorio y las CLI tienen cadenas de actualización diferentes; el proxy y la autenticación también se propagan por distintas rutas de arranque. El Mac necesita su propio plano de control. Debe saber qué recursos importantes existen, quién los administra, cuál es su estado objetivo, cómo detectar desviaciones, qué acciones pueden automatizarse y ante qué decisiones hay que detenerse. El Sweeper se encarga de quitar lo que sobra. El bucle se encarga de que esa labor continúe. A corto plazo, este trabajo no produce funciones nuevas, pero reduce la incertidumbre de cada ejecución futura. Los agentes dejan de encontrar versiones antiguas al azar; las tareas programadas y el terminal obtienen resultados coherentes con más facilidad; los fallos pueden localizarse rápidamente en una capa concreta del entorno; y las herramientas nuevas saben a qué punto de entrada deben conectarse. Para un Builder, es una inversión en infraestructura cuyo rendimiento se acumula. Cuanto más estable es el entorno, más tiempo pueden funcionar los bucles de los agentes. Cuanto más claras son las responsabilidades, más permisos puede recibir la automatización. Cuanto más completos son los registros de gestión, menos cosas habrá que redescubrir en el siguiente diagnóstico. La productividad futura vendrá a la vez de modelos más potentes, mejores herramientas y un entorno local que pueda seguir siendo comprensible, converger a un estado conocido y mantenerse bajo control a largo plazo. El Builder crea. El Sweeper evita que la creación se vea frenada por sus propios residuos. ### Referencias * [Publicación original de Boris Cherny sobre los cinco roles del equipo de Claude Code](https://x.com/bcherny/status/2071379474277613732) * [Publicación original de Boris Cherny sobre tareas prolongadas y retroalimentación de verificación](https://x.com/bcherny/status/2007179861115511237) * [Conversación con Boris Cherny, responsable de Claude Code](https://www.youtube.com/watch?v=Z47vatpsGPI) * [Versiones de formulae de Homebrew](https://docs.brew.sh/Versions) * [fnm, Fast Node Manager](https://github.com/Schniz/fnm) * [Documentación de uv sobre instalación y gestión de Python](https://docs.astral.sh/uv/guides/install-python/) * [Documentación de uv sobre versiones de Python](https://docs.astral.sh/uv/concepts/python-versions/) * [El libro de rustup](https://rust-lang.github.io/rustup/) * [Documentación de rustup sobre cadenas de herramientas](https://rust-lang.github.io/rustup/concepts/toolchains.html)