BITÁCORA / LABORATORIO DE IA
Pasé de pedir ayuda a una IA, a dirigir modelos especializados y conservar su conocimiento entre proyectos, sesiones y dispositivos.
Esta es una bitácora personal sobre cómo pasé de pedir ayuda a modelos dentro de ventanas de chat a dirigir modelos especializados, agentes, skills, MCPs y memoria portable. No es una vitrina de servicios.
01 / ODISEA
Cómo pasé de ventanas de chat a un harness real
La cronología distingue cambios de modelo, interfaz y autoridad. Es una narración personal; el trabajo privado para empleadores y sus métricas son autorreportados y no se verifican de forma independiente en este portafolio público.
CRONOLOGÍA
XtendOps: construir IA antes de programar con IA
Ayudé a construir una plataforma configurable de agentes que usaba GPT, Amazon Bedrock y otras tecnologías según el cliente.
HelloFresh fue cliente de XtendOps; no fue mi empleador directo y la herramienta no era exclusiva para HelloFresh.
Un caso RAG devolvía información en tiempo real, fragmentos de términos y condiciones reales y enlaces a las fuentes.
Trabajé alrededor de variables, pausa del chat y experiencia del usuario.
En esa época GitHub Copilot aparecía como autocompletado dentro del IDE, no como agente.
Sekura: ChatGPT web y contexto acotado
Construí una aplicación de gestión de siniestros con React Native y Metro.
Llegó a producción con un ciclo acelerado de entrega y tuvo una adopción relevante para el cliente.
Creé un sistema reutilizable de componentes basado en React Native Paper.
El trabajo profesional con IA ocurría en ChatGPT web: copiaba y pegaba bloques específicos.
Aprendí que un contexto pequeño y directo producía menos alucinaciones.
Cuando el modelo perdía el hilo diagnosticaba manualmente y regresaba con instrucciones acotadas.
Los primeros agentes de IDE durante esta etapa fueron experimentos personales, no parte del trabajo de oficina.
Claude y Gemini: cambiar de proveedor por claridad
En Zorya, un cambio del onboarding de Meta requirió trabajar con C# cuando todavía era nuevo en el lenguaje.
Claude 3.5 Sonnet resolvió y explicó el cambio con suficiente claridad para que moviera mi suscripción principal de OpenAI a Anthropic.
Claude 3 Opus fue apoyo ocasional.
Gemini 3 Pro se convirtió en herramienta cotidiana por el ecosistema de Google; recargaba la página esperando su lanzamiento.
Gemini 3.1 Pro llegó después como apoyo y segunda opinión de arquitectura.
De interfaz a harness
Claude Code Desktop fue el puente desde mi preferencia por interfaces gráficas.
El CLI aportó control, visibilidad, subagentes y configuración.
OpenCode Desktop llegó antes que OpenCode Go.
Mi primera pareja deliberada: GLM-5.1 como planificador y Kimi K2.6 como implementador.
MiMo-V2.5-Pro reemplazó a Kimi K2.6 como implementador.
MiniMax y la orquestación real
Adopté MiniMax M3 el día de su salida y pagué MiniMax Token Plan ese mismo día.
MiniMax M3 comenzó como planificador e implementador.
Después usé Claude Code con Claude Opus 4.8 o Fable 5 como planificador y OpenCode conectado a minimax.io como implementador, ambos sobre el mismo repo.
Más adelante volví a MiniMax M3 como planificador e implementador, alcanzando aproximadamente 1.07B tokens en un periodo mensual.
El siguiente flujo usó GLM-5.2 mediante Z.AI como planificador y MiniMax M3 mediante minimax.io como implementador, todo dentro de OpenCode.
GLM-5.2 fue el primer planificador al que dejé trabajar durante horas mientras estaba fuera o dormía.
Dejé de evaluar proveedores por marca y país de origen como un solo bloque y pasé a asignar modelos por rol. GLM tomó el asiento de planificador. MiMo y después MiniMax tomaron el asiento de implementador. Kimi salió de la rotación tras su etapa.
Aquí apareció la primera orquestación diseñada: el planificador no podía escribir código y delegaba a subagentes especializados sobre el mismo espacio de trabajo.
Codex y Sol
Sol es el planificador raíz y arquitecto.
En Codex V2 sin agent_type, MiniMax M3 recibe implementación mediante el ejecutor directo de minimax-builder.
El evaluador de agentes (agent_evaluator) y el cazador de fallas silenciosas (silent_failure_hunter) tienen ejecutores de solo lectura.
Los agentes genéricos de Codex no se describen como MiniMax.
Las fases se detienen ante compuertas humanas.
02 / CÓMO PROGRAMO
Cinco reglas que salieron de la odisea
-
Acoto el contexto antes de pedir código
Las reglas del repo, las decisiones previas y los contratos de dependencias llegan al modelo antes que la petición.
-
Diagnostico manualmente cuando el modelo pierde el hilo
Si la respuesta deriva, vuelvo a abrir el problema y estrecho el alcance en lugar de pedir una continuación.
-
Separo arquitectura de implementación
Las decisiones de arquitectura viven en el rol de planificador; las unidades de implementación viajan por briefs acotados a un implementador.
-
Verifico configuración, despacho, inferencia, telemetría y comportamiento del producto como revisiones separadas
Una respuesta verde de una capa nunca se toma como prueba de que la siguiente funciona.
-
Mantengo aprobación humana cuando una transición puede cambiar alcance, datos, costo o producción
Todo lo que mueve dinero, usuarios, esquemas o estado de producción se detiene en una compuerta humana.
03 / SKILLS
De práctica repetida a skill portable
Cuando una práctica se repite, la convierto en una skill versionada que viaja entre modelos y sesiones. La lista de abajo es una muestra curada, no una pared de insignias.
EJEMPLOS PÚBLICOS DE SKILLS
- frontend-design
- Crear interfaces frontend con criterio de diseño, no con plantillas genéricas.
- design-review
- Auditoría de 7 fases con WCAG 2.1 AA, diseño adaptable y pulido visual.
- copywriting
- Escribir y revisar textos de marketing con estructura comprobable.
- stop-slop
- Eliminar patrones típicos de prosa de IA.
- context7-mcp
- Traer documentación vigente de librerías antes de escribir código.
- graphify
- Convertir el código en un grafo de conocimiento navegable.
- minimax-builder
- Ejecutar implementaciones acotadas contra MiniMax M3 con briefs auditables.
- minimax-role-runners
- Asignar roles a ejecutores con autoridad delimitada.
04 / AGENTES Y SUBAGENTES
De un planificador único a una jerarquía con autoridad explícita
El harness pasó de un planificador único a roles con autoridad acotada, auditorías de solo lectura y compuertas humanas.
Primera versión del harness
Cuatro roles estables para planeación, implementación, commit y memoria.
- Planificador
planner - Implementador
builder - Creador de commits
commit_creator - Memorista del vault
vault_memorist
Expansión posterior
Tres roles más para auditoría y publicación.
- Evaluador de agentes
agent_evaluator - Cazador de fallas silenciosas
silent_failure_hunter - Redactor de notas de versión
release_noter
CAMBIOS DE AUTORIDAD
Leer el estudio técnico: cómo funciona este sistema →05 / RUTAS LATERALES
Local, remoto y exploraciones inconclusas
Probé correr modelos fuera del flujo principal. Algunas rutas se quedaron abiertas; otras quedaron como aprendizaje sin utilidad clara.
MacBook Pro M2 con 8 GB de memoria unificada
Inferencia local con Ollama. Servía un modelo cuantizado no identificado de Qwen, cercano a 5 GB.
Otra PC consumiendo el servidor
Otra PC consumía el servidor local de Ollama.
Pruebas en VPS
Probé un VPS para operar agentes de forma remota.
OpenClaw y bots de Telegram
OpenClaw y los bots de Telegram usaron MiniMax M3 con la misma clave de API del Token Plan. Todavía no encuentran una utilidad clara dentro de mi flujo y quedan como exploraciones inconclusas.
Mistral como ruta europea planeada
Evalué Mistral como un posible proveedor europeo. La motivación fue soberanía de datos, diversificación de proveedor, ubicación del alojamiento y menor dependencia de proveedores estadounidenses. Nunca llegó a producción en mi pila tecnológica.
Modelos desarrollados en China, evaluados por rol
No los trato como un bloque homogéneo. Qwen corrió en una prueba local con Ollama. GLM tomó el asiento de planificador. Kimi y MiMo sirvieron como implementadores antes de salir de la rotación. MiniMax tomó los asientos de planificador e implementador y corre el entorno de ejecución de agentes. Cada modelo ganó su lugar por calidad de razonamiento, retención de contexto, integración con herramientas, costo, la autoridad que le asigné y continuidad operativa.
06 / MCPs, ENGRAM Y KNOWLEDGE-VAULT
Una capa portable que sobrevive a modelos, máquinas y sesiones
- ORIGEN
- Engram proviene de Gentleman Programming. Llegó casi al mismo tiempo que mi necesidad de compartir memoria entre laptops.
- CAPA PORTABLE QUE CONSTRUÍ ENCIMA
- Instrucciones, agentes, skills y registros
- Scripts de instalación, restauración y portabilidad
- Memoria persistente de Mavis
- Convenciones entre entornos de ejecución
- ENTORNOS DE EJECUCIÓN QUE COMPARTEN MEMORIA
- Codex, OpenCode, Claude Code y Mavis comparten la misma base de Engram.
- RESPALDOS
- Los respaldos de Engram se cifran con age y viven en Google Drive.
- COMPARE-AND-SWAP
- El mecanismo compare-and-swap evita que una laptop desactualizada sobrescriba el respaldo remoto más nuevo.
ORDEN ORGÁNICO DEL VAULT
- Historia y forma de programar
- Skills
- Agentes y subagentes
- MCPs
- Memoria
- Continuidad operativa
COMMITS PUBLICADOS DEL VAULT
- 2ff433e
- registro CLI
- 8763e00
- políticas y documentación Codex
- 1756f02
- instalador y registro de ejecutores
- 23562a2
- implementador y ejecutores de MiniMax
Al cierre de la entrega origin/main y HEAD coincidían en 23562a2. graphify-out/ y __pycache__/ permanecen excluidos.
07 / FALLAS
Cinco incidentes que vale la pena contar
INC-01
- SITUACIÓN
- Las solicitudes grandes provocaban alucinaciones; el modelo perdía el hilo a mitad de camino.
- CORRECCIÓN
- Reduje el alcance y regresaba con bloques diagnosticados manualmente.
- EVIDENCIA
- Los prompts cortos y acotados volvieron a producir respuestas útiles.
INC-02
- SITUACIÓN
- Un agente respondió READY mientras el proveedor seguía mostrando 0% de uso.
- CORRECCIÓN
- La configuración estática y la inferencia real se volvieron pruebas separadas.
- EVIDENCIA
- Una llamada sustantiva confirmó el modelo y un consumo medible de tokens.
INC-03
- SITUACIÓN
- Codex V2 no expuso un selector seguro para roles personalizados; el despacho genérico podía heredar el modelo equivocado.
- CORRECCIÓN
- Detuve el despacho genérico y construí un ejecutor directo con una lista exacta de archivos permitidos.
- EVIDENCIA
- El ejecutor valida diffs unificados y corre git apply --check antes de cualquier cambio.
INC-04
- SITUACIÓN
- Un evaluador de 13 archivos devolvió JSON inválido.
- CORRECCIÓN
- Dividí la auditoría en cuatro subsistemas coherentes y reintenté solo la unidad fallida.
- EVIDENCIA
- Cuatro tarjetas de evaluación válidas, instantáneas idénticas del espacio de trabajo y una revisión transversal independiente cerraron la auditoría.
INC-05
- SITUACIÓN
- Las cuotas disponibles me obligaron durante meses a dosificar cada flujo.
- CORRECCIÓN
- Ajusté el alcance y el ritmo de cada flujo a la cuota disponible.
- EVIDENCIA
- Fue una restricción operativa sostenida durante meses, no una métrica externa.
08 / INSTANTÁNEA
Una foto fechada del volumen de uso
FECHA 16 de julio de 2026
MÉTRICAS DE USO
- tokens en GLM
- 101,686,799
- tokens totales en MiniMax
- 1.95B
- tokens en MiniMax, últimos 30 días
- 1.53B
- tokens en MiniMax, últimos 7 días
- 698.20M
- pico en MiniMax
- 317.95M
El volumen no equivale a calidad. Es una foto del uso, no una prueba de valor.
09 / RESPONSABILIDAD HUMANA
Lo que sigue siendo mío
- Alcance
- Decidir qué problema vale la pena atacar y qué no-objetivos defender.
- Datos
- Elegir qué datos entran al modelo y cómo se aíslan.
- Costo
- Aprobar suscripciones, planes y concesiones de presupuesto.
- Producción
- Aprobar despliegues y rutas que tocan usuarios reales.
- Diagnóstico
- Volver a abrir el problema cuando el modelo pierde el hilo.
- Aprobación final
- Decir sí o no antes de cada transición que cambia algo material.
