> 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/w27-a-builders-personal-productivity-system.md). # W27-El sistema personal de producción de un builder Hace poco volví a ordenar las herramientas que uso de verdad en mi trabajo diario. Esta colección nació de una revisión del software y los sistemas de herramientas que utilizo habitualmente en mi computadora. Ahora la guardo en Basic Memory y seguiré manteniéndola. No es una lista estática, sino la construcción continua de un sistema personal de producción. Compartir solo qué aplicaciones tengo instaladas no aportaría mucho. Las listas de herramientas caducan pronto y sus diferencias suelen exagerarse. Lo que merece la pena discutir es cómo organiza su flujo de trabajo un builder en la era de la IA: cómo entra la información en el sistema, cómo se aclaran los problemas, cómo se dividen las tareas, cómo se produce y verifica el código y cómo se conserva la experiencia para el siguiente trabajo. Antes, las herramientas se parecían más a periféricos de las personas. El navegador buscaba, la aplicación de notas registraba, el IDE servía para programar y el calendario recordaba las citas. Cada herramienta tenía límites claros y la persona coordinaba lo que ocurría entre ellas. Ahora esa estructura está cambiando. La IA no es solo una herramienta nueva: también convierte los espacios entre herramientas en parte del flujo de trabajo. El papel de la persona ya no consiste únicamente en dar órdenes y trasladar resultados, sino en diseñar un sistema de producción que pueda seguir funcionando. ### Capa de entrada La primera capa de un sistema de producción no es la IA, sino la entrada de información. Muchas ideas no llegan al sistema porque registrarlas cuesta demasiado, no porque carezcan de importancia. Antes dependía sobre todo del teclado. Es preciso, pero lento: sirve para escribir código, redactar versiones finales e introducir comandos, pero no para volcar ideas con rapidez. Por eso ahora separo las formas de entrada en tres clases. La primera es la entrada precisa. El código, los comandos y la redacción definitiva siguen pasando por el teclado. La segunda es la entrada por voz: una idea vaga, una reflexión después de una reunión o un requisito todavía sin estructura. Hablarle a la computadora es una forma de trabajar cada vez más popular en Silicon Valley. Eso sí, en una oficina compartida hay que perder un poco la vergüenza. El método de entrada de Doubao destaca por reconocer la mezcla de chino e inglés y convertir automáticamente el habla en expresión escrita. Yo uso WeType, el método de entrada de WeChat. Sus funciones de voz también evolucionan deprisa y últimamente casi se han puesto al mismo nivel. Primero digo lo que pienso y después dejo que un agente lo comprima, lo organice y elimine el ruido. La tercera es la captura ligera. Uso HapiGo para capturas de pantalla, OCR, traducción e historial del portapapeles. No es una base de conocimiento ni un espacio de trabajo: es una entrada rápida. Su valor está en convertir lo que aparece en la pantalla en texto que pueda usar un agente. Lo importante no es un método de entrada ni una herramienta de capturas concreta, sino un principio: que el costo de capturar una idea no sea tan alto que la haga desaparecer. ### Capa de aclaración Cuando la IA acelera la ejecución, lo que más fácilmente amplifica es una dirección equivocada, antes que la capacidad. Antes, si la dirección era incorrecta, el alto costo de ejecutar podía hacer que el error tardara en hacerse visible. Ahora un agente puede producir enseguida una pila de resultados que parecen completos, y eso puede dificultar aún más detenerse. Por eso doy a la aclaración del problema una capa propia. En el día a día, interactúo sobre todo con Codex y Claude Code. Son mis dos entornos principales de trabajo con agentes: uno se orienta más a la ejecución y verificación de ingeniería; el otro, a pensar, escribir, revisar y aportar perspectivas alternativas. Si el problema todavía es difuso, uso `grill-with-docs` o brainstorming de Superpowers para empezar por una comprensión común. El objetivo es aclarar primero el problema, las restricciones, la meta y los resultados inaceptables, antes de hacer que la IA se ponga a trabajar. Si una idea ya necesita seguimiento, la llevo a Multica. Para mí, Multica es un espacio de trabajo con IA: mediante issue, agent, runtime y squad convierte las tareas en trabajo que se puede asignar, observar y seguir. No es simplemente otro chatbot. El valor de esta capa es pasar de «quiero hacer algo» a «este problema merece resolverse y sus límites están claros». ### Capa de investigación Como builder, es fácil sobreestimar la vigencia de la experiencia propia. Las herramientas, los frameworks, los modelos y las formas de producto cambian deprisa. Una elección técnica razonable hace seis meses quizá ya no sea la mejor. Un producto que antes funcionaba mal puede volverse útil de repente por un cambio en las capacidades del modelo o en el flujo de trabajo. Por eso investigo primero cuando hay hechos externos, selección de herramientas o juicios sobre el mercado. Para investigaciones ligeras uso principalmente Dia, mi navegador habitual. Cuando necesito verificación automatizada, recurro a Browser, Chrome o Playwright. Para ver las conversaciones reales de las últimas semanas, uso `last30days` y busco nuevas señales en GitHub, HN, Reddit y páginas públicas. Para preguntas más abiertas que exigen integrar muchas fuentes, Deep Research de ChatGPT sigue siendo una buena opción. Si la investigación es más compleja, hago participar a agentes de Multica con perfiles como Market Researcher o Product Architect. Su función es quitar de mi atención la recopilación de información y su primera síntesis, sin sustituir mi juicio. La investigación busca actualizar el juicio, no acumular materiales. Solo cuando una conclusión se estabiliza pasa a Basic Memory. ### Capa de planificación Cuantas más herramientas hay, más fácil es que varios flujos de trabajo intenten dirigir la misma tarea. Compound Engineering, por ejemplo, tiene `/ce-plan` y `/ce-work`; Superpowers tiene writing-plans, TDD y systematic debugging; Multica tiene issue, agent y squad. Todos pueden organizar tareas, pero no pueden llevar el control al mismo tiempo. Mi regla es elegir un único flujo principal por tarea. Para trabajos de ingeniería pequeños o medianos, uso por defecto Compound Engineering: primero planificar y después ejecutar. Si necesito más disciplina de desarrollo, uso Superpowers. Si hacen falta seguimiento prolongado, colaboración entre roles o gestión del estado de las tareas, uso Multica. Para uno o dos cambios claros, dejo trabajar directamente a Codex o Claude Code, sin montar un proceso complejo. El valor de planificar es reducir el trabajo que habrá que rehacer, más que escribir planes bonitos. En la era de la IA, lo más caro es corregir el rumbo después de haberse desviado del objetivo, no generar. ### Capa de ejecución Mi capa de ejecución está formada principalmente por Codex, Claude Code, Ghostty, cmux, CodexBar y Multica. Las tareas que siguen un solo hilo suelen resolverse directamente en Codex App o Claude Code. Cuando hay que editar código real, ejecutar pruebas y verificar páginas, Codex es mi espacio principal. Cuando necesito otro ángulo para pensar, examinar una propuesta u ordenar la expresión, uso Claude Code. Ghostty es mi entrada habitual a la terminal. cmux resulta útil para varias tareas de agentes en paralelo: una ventana planifica, otra implementa, otra diagnostica problemas y otra revisa. CodexBar resuelve principalmente la gestión de las cuotas de uso. Lo utilizo para observar el consumo de Codex, Claude Code y Antigravity, y no perder la noción del costo al usar varias herramientas de agentes a la vez. Multica ocupa un lugar más particular. Sirve para tratar a la IA como un «compañero digital», en vez de como una ventana de chat: crear una issue, asignarla a un agent o squad y observar su estado, comentarios y resultados. Es más adecuado que una sola conversación cuando hacen falta división de roles, seguimiento a largo plazo e intervención humana. Uso Recordly sobre todo para presentar productos y prototipos a otras personas. La experiencia de grabación de pantalla es muy buena, con zoom inteligente y seguimiento del cursor que permiten grabar recorridos de producto más claros. Además, es de código abierto, funciona totalmente en local, es gratuito y ofrece una experiencia de uso excelente. También intento evitar una coordinación excesiva. Si una conversación de Codex basta, no hay motivo para introducir cmux o Multica por formalidad. Un sistema de producción no mejora por volverse más complejo: su complejidad debe corresponder al tamaño de la tarea. ### Capa de disciplina Las herramientas de IA reducen el costo de producción, pero no mejoran automáticamente la calidad de ingeniería. El código se genera rápido; los riesgos también. Las herramientas de un builder deben cubrir tanto «producirlo» como «demostrar que es correcto». Por eso incorporo TDD, debugging, code review y browser verification a mi cadena diaria de herramientas, en lugar de añadirlos después como remedio. Ante un bug, empiezo con diagnosing-bugs o systematic debugging y exijo reproducirlo, localizarlo y después corregirlo. Procuro usar TDD en las funcionalidades que se pueden probar. En trabajo de frontend hay que abrir un navegador real y observar el resultado, no limitarse a leer el código. Si la arquitectura se desvía, vuelvo a examinar sus límites con domain-modeling, codebase-design o improve-codebase-architecture. Estas herramientas sirven para contrarrestar la falsa impresión de solidez que puede producir la IA. La IA sabe dar a una respuesta el aspecto de estar completa; la disciplina de ingeniería comprueba si realmente se sostiene. No se trata de formalismo. ### Capa de memoria Si al terminar un trabajo la experiencia solo queda en el historial del chat, en la práctica apenas se ha conservado. Ahora uso Basic Memory como base de conocimiento personal a largo plazo. No es un volcado en bruto ni un depósito indiscriminado de materiales. Es el lugar para guardar conclusiones estables, procedimientos reutilizables, contextos que reaparecen y lecciones de revisiones posteriores. También ha cambiado mi forma de entender la gestión del conocimiento. Antes, tomar notas se parecía a «guardar cosas». Ahora se parece más a «mantener una wiki personal que puedan usar los agentes». Los materiales originales pueden ser imperfectos, pero el conocimiento reutilizable debe ser breve, preciso y fácil de recuperar. Las reglas estables tampoco deberían quedarse solo en la memoria. Si afectan a todo el trabajo posterior de un proyecto, deben ir a `AGENTS.md` o a la documentación del repositorio. La memoria conserva experiencia; los documentos del proyecto establecen restricciones. ### El sistema de herramientas de un builder Al mirar todas estas herramientas juntas, mi flujo actual es aproximadamente este. Primero reduzco el costo de capturar información con la capa de entrada. Voz, capturas, OCR y portapapeles convierten información difusa en material procesable. Después defino el problema con la capa de aclaración. Codex, Claude Code, grill-with-docs, Superpowers brainstorming y Multica me ayudan a convertir ideas en tareas con límites claros. Luego paso a investigar y planificar. Busco información nueva cuando corresponde y divido las tareas cuando hace falta, siempre con un único flujo al mando. Al ejecutar, dejo que el agente entre en el entorno real: escribe código, ejecuta comandos, observa páginas, modifica documentos y abre issues, en lugar de quedarse en la conversación. Al final cierro con disciplina y memoria. Pruebas, diagnóstico, revisión y verificación confirman que el resultado se sostiene; después guardo la experiencia estable en Basic Memory o en la documentación del proyecto. Ninguna herramienta concreta constituye por sí sola la principal ventaja difícil de replicar de este sistema. Codex, Claude, Multica, Basic Memory, cmux, Recordly y HapiGo pueden cambiar o incluso ser sustituidos. Lo que importa es el lugar que ocupan en el conjunto. Acumular herramientas sin más crea costos de cambio entre ellas. Convertirlas en un sistema de producción permite atascarse menos en los detalles y llegar antes al juicio, las decisiones y la verificación. Cada vez creo más que, en la era de la IA, un builder es alguien que sabe diseñar su propio sistema de trabajo, además de usar herramientas. Las herramientas amplifican las acciones. El sistema decide si merece la pena amplificarlas. ### Anexo: enlaces a las herramientas | Herramienta | Uso | Enlaces | | ------------------------------------ | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Basic Memory | Base de conocimiento personal a largo plazo / memoria con prioridad local | [Sitio oficial](https://docs.basicmemory.com/) / [GitHub](https://github.com/basicmachines-co/basic-memory) | | WeType / método de entrada de WeChat | Entrada en chino y por voz | [Sitio oficial](https://z.weixin.qq.com/) / [Homebrew](https://formulae.brew.sh/cask/wetype) | | Método de entrada de Doubao | Entrada por voz / mezcla de chino e inglés | [Sitio oficial](https://shurufa.doubao.com/) / [Descarga para macOS](https://shurufa.doubao.com/pc) | | HapiGo | Capturas, OCR, traducción, portapapeles y lanzador | [Sitio oficial](https://hapigo.com/) / [Homebrew](https://formulae.brew.sh/cask/hapigo) | | Codex | Ejecución de ingeniería, cambios de código y verificación | [Codex App](https://developers.openai.com/codex/app) / [Codex CLI](https://developers.openai.com/codex/cli) | | Claude Code | Comprensión del código, reflexión, revisión y perspectivas alternativas | [Sitio oficial](https://claude.com/product/claude-code) / [GitHub](https://github.com/anthropics/claude-code) | | Multica | Colaboración entre agentes organizada mediante issues | [Sitio oficial](https://www.multica.ai/) / [GitHub](https://github.com/multica-ai/multica) | | Dia | Navegador habitual / investigación ligera | [Sitio oficial](https://www.diabrowser.com/) | | Google Chrome | Entorno de navegador para verificación automatizada | [Sitio oficial](https://www.google.com/chrome/) | | Playwright | Automatización del navegador y verificación de frontend | [Sitio oficial](https://playwright.dev/) / [Documentación de instalación](https://playwright.dev/docs/intro) | | last30days | Investigación de debates públicos de los últimos 30 días | [GitHub](https://github.com/mvanhorn/last30days-skill) | | ChatGPT Deep Research | Investigación que integra múltiples fuentes | [Presentación de OpenAI](https://openai.com/index/introducing-deep-research/) / [Documentación de ayuda](https://help.openai.com/en/articles/10500283-deep-research-in-chatgpt) | | Compound Engineering | Flujo de planificación y ejecución | [GitHub](https://github.com/everyinc/compound-engineering-plugin) / [Introducción](https://every.to/guides/compound-engineering) | | Superpowers | Disciplina de ingeniería: TDD, debugging, review y otras prácticas | [GitHub](https://github.com/obra/Superpowers) | | Matt Pocock skills | Skills como grill-with-docs, diagnosing-bugs, domain-modeling y codebase-design | [GitHub](https://github.com/mattpocock/skills) | | Ghostty | Entrada a la terminal | [Sitio oficial](https://ghostty.org/) | | cmux | Espacio de terminal para agentes en paralelo | [Sitio oficial](https://cmux.com/) / [GitHub](https://github.com/manaflow-ai/cmux) | | CodexBar | Gestión de cuotas de Codex, Claude Code, Antigravity y otras herramientas | [Sitio oficial](https://codexbar.app/) / [GitHub](https://github.com/steipete/CodexBar) | | Google Antigravity | IDE y plataforma de desarrollo centrados en agentes | [Sitio oficial](https://antigravity.google/) / [Descarga](https://antigravity.google/download) | | Recordly | Grabación de pantalla para presentar productos y prototipos | [Sitio oficial](https://recordly.dev/) / [GitHub](https://github.com/webadderallorg/recordly) |