--- title: "Con qué trabajamos realmente" description: "Un editor, dos familias de modelos en paralelo y una capa de recetas, reglas y barreras duras. La parte de la que menos se habla y la que más sostiene." author: "Matthias Meyer" published: 2026-08-05 updated: 2026-09-30 updates: - date: 2026-09-30 note: "Precisados accesos, revisión de modelos, barreras y recuperación verificable de advertencias." language: es tags: ["maschinenraum", "arbeitsweise", "werkzeuge", "claude", "codex"] canonical: "https://studiomeyer.io/es/blog/arbeitssystem-editor-modelle-werkzeuge" markdown_versions: ["https://studiomeyer.io/de/blog/arbeitssystem-editor-modelle-werkzeuge.md", "https://studiomeyer.io/en/blog/arbeitssystem-editor-modelle-werkzeuge.md", "https://studiomeyer.io/es/blog/arbeitssystem-editor-modelle-werkzeuge.md"] publisher: "StudioMeyer, https://studiomeyer.io (llms.txt: https://studiomeyer.io/llms.txt)" --- # Con qué trabajamos realmente De los modelos se habla mucho. Del entorno casi nada. Y en el trabajo diario es el entorno lo que decide. Lo que se describe aquí no es un producto ni algo que vendamos. Es la respuesta a la pregunta que más nos hacen en las conversaciones, sobre todo gente que trabaja con IA: cómo lo tenéis montado. ## El editor es el escenario Se trabaja en un editor de código normal, no en una ventana de chat del navegador. Esa es la diferencia individual más importante. Para nuestro sistema importaba el acceso directo a archivos, comandos y verificaciones. Los asistentes de navegador también pueden usar archivos, conectores y herramientas de nube; la ventana de chat no determina los accesos. En el editor está el entorno local: cambiar archivos, ejecutar pruebas y revisar resultados. Por eso elegimos ese camino. ## Dos familias de modelos, a propósito En paralelo corren asistentes de dos casas distintas. No es indecisión sino la palanca de calidad más eficaz que hemos encontrado. Los modelos de una familia pueden cometer errores similares. Otro modelo no es automáticamente un revisor independiente por abrir otro chat. Para tareas importantes usamos otra familia, preguntas críticas y pruebas concretas. Puede reducir puntos ciegos comunes, pero no garantiza revisión completa. Si haces correr un modelo de otra familia sobre el mismo trabajo, con el encargo expreso de refutarlo, vuelven hallazgos distintos. No más hallazgos, distintos. Ese es ya nuestro camino estándar para todo lo que no es trivial: uno construye, un segundo ataca, y sigue hasta que no vuelve nada sustancial. ## Recetas en vez de explicar otra vez La segunda capa son recetas para procedimientos recurrentes. Un despliegue, un artículo de blog, el alta de un cliente, una revisión de servidor. El sentido no es la automatización. El sentido es que cada receta lleva dentro las trampas en las que ya caímos. Para publicar una web, por ejemplo, lleva dentro el orden de comprobaciones que tocan antes de conmutar. Ese conocimiento si no desaparece. Vive en la cabeza de alguien que ese día no está. En una receta está escrito y se sigue la próxima vez, también por un asistente que no conoce la historia de fondo. ## Barreras que no preguntan con educación La tercera capa es la que más disgustos nos ha ahorrado. Son bloqueos duros que impiden técnicamente ciertas acciones en vez de desaprobarlas. La diferencia es decisiva. Una instrucción como "no uses nunca esta herramienta contra un servidor" es un ruego. Funciona casi siempre y algún día no, porque está en una sesión larga bajo mucho otro texto. Una barrera técnica puede bloquear las acciones que realmente cubre. La usamos en operaciones importantes: cambios de servidor, mensajes salientes y borrados. Probamos vías de ejecución y fallos relevantes. Un hook o regla no garantiza globalmente todas las herramientas. La lección de fondo es más general que la herramienta: **una regla sin cumplimiento forzoso es una nota.** Cuando lo mismo ha pasado dos veces, el texto al respecto queda refutado y hace falta un mecanismo. ## y la memoria por debajo Todo eso cuelga de la memoria descrita en otro artículo de esta serie. Conserva decisiones, errores y patrones durante meses, y entre sesiones. El beneficio llega si el asistente recupera la advertencia documentada cuando toca. Comprobamos no solo que se guardó el error, sino que la próxima tarea relevante lo encuentra. Siguen haciendo falta barreras técnicas; recordar no evita por sí solo repetirlo. ## Qué de esto es trasladable No le reconstruimos este montaje a nadie, sería absurdo. Pero tres cosas de aquí valen independientemente de las herramientas. Primera: el asistente va donde está el trabajo, no al lado. Segunda: revisar lo tiene que hacer alguien distinto del que construye, y cuanto más distinto mejor. Tercera: lo que ya salió mal necesita una barrera, no un recordatorio. El resto es gusto y costumbre. ## Seguir leyendo, Sala de máquinas - [Cada empresa tiene su propio agente de IA](https://studiomeyer.io/es/blog/meetmyagent-jeder-hat-einen-agenten.md) - [Una plataforma de aprendizaje llevada por agentes](https://studiomeyer.io/es/blog/academy-von-agenten-betrieben.md) - [Varios agentes, una tarea: separar roles y revisión](https://studiomeyer.io/es/blog/crew-mehrere-agenten-eine-aufgabe.md)