Propuesta MBGE · Desarrollo Agosto 2026

Consultoría y capacitación en IA para el equipo de desarrollo

Tres sesiones donde su equipo de desarrollo y QA trabaja sus propios proyectos con nuestra guía, y el diagnóstico de su pipeline que sale de ese trabajo.

01   Qué instalamos

Cuatro cosas que quedan en el equipo

No es un curso de teoría. Instalamos una forma de trabajar —harness, contexto, loops y verificación— sobre sus propios proyectos, con su código real. Su equipo hace el trabajo; nosotros guiamos, revisamos y documentamos. El punto de partida es simple: escribir código ya es la parte fácil; la ventaja se movió a cómo se dirige y se verifica al agente.

1

Desarrolladores dirigiendo agentes

Sus 5 developers operando Claude Code y Codex sobre los proyectos del equipo, no sobre ejemplos. Ellos ejecutan; nosotros guiamos en vivo.

  • Context engineering: cómo se le entrega el contexto a un agente —progressive disclosure, los gotchas del repo escritos, no reglas de más— y por qué ahí se decide el resultado, no en el prompt.
  • Harness: el entorno importa más que el modelo. AGENTS.md/CLAUDE.md por módulo, rutinas de arranque de sesión y contratos de trabajo (sprint contracts).
  • Loop engineering: pasar de "promptear" a diseñar un loop —descubrir, planear, ejecutar, verificar, iterar— con criterio de éxito verificable ("los tests de /auth pasan y el lint queda limpio", no "que quede bien").
  • Subagentes y worktrees: paralelismo real —de 12–16 worktrees a cientos de subagentes— y el 90/10: el agente ejecuta, su gente dirige y decide.
2

QA que cierra el loop

Sus 3 personas de QA dejan de ser cuello de botella y pasan a ser quienes cierran el loop —sobre lo interno y sobre lo que entregan los terceros.

  • Codificar los chequeos que hoy hacen a mano para que el agente cierre su propio feedback loop: lo que vive en su cabeza, vuelto reglas ejecutables en el repo.
  • Loops que se auto-verifican: el agente revisa su trabajo contra la fuente —incluido tomarse screenshots de la UI en headless— y reencola lo que falla hasta que pasa.
  • Un verificador separado del ejecutor para revisar código de terceros y heredado, en paralelo (el patrón con el que se encontraron 400+ fixes en 10M de líneas de Firefox).
  • Cada corrección se captura una vez como eval, no se repite en cada revisión. Ese 10% que hoy corrigen a mano es el eval que aún no existe —y ahí vive el criterio de calidad de MBGE.
3

El mapa de modelos y herramientas

Qué modelo y qué herramienta sirve para qué, cuáles conviene conectar y cómo se conectan. Los guiamos; la operación queda en sus manos.

  • Criterio para elegir el modelo según la tarea —Opus 5/4.8, GPT 5.6, Grok, Kimi, Fable— y ajustar el reasoning effort, en lugar de resolver todo con el mismo (el costo de una misma tarea varía hasta 15× según la mezcla).
  • MCP y conectores: qué plataformas que ya usan quedan disponibles para el agente (MCP stateless, OAuth), y cómo escribir sus propias herramientas para él —CLI + skill.
  • La superficie donde ya trabaja el equipo: Claude/GPT en Slack (en Anthropic, 65% del código de producto sale de taguear a Claude en Slack), ChatGPT apps y artifacts multijugador.
  • Panorama de Cloudflare OS: workspaces de agentes y gatekeepers —el agente usa credenciales sin que el modelo las vea—. Hacia dónde va la infraestructura interna.
4

Diagnóstico y roadmap del pipeline

Nuestro entregable. El documento que sale del trabajo real de las tres sesiones, con lectura ejecutiva de 30 minutos.

  • Dónde se atora hoy el ritmo de desarrollo y qué prácticas lo destraban sin depender de terceros para avanzar.
  • Dónde está el cuello de QA y qué chequeos se pueden codificar para que la verificación deje de ser el freno.
  • Roadmap de adopción: pilotos priorizados, criterio de licencias y modelos, y cómo escalar el uso en el equipo.
  • Listo para presentarse a dirección.
Descubrir Planear Ejecutar Verificar QA itera 🔁
El loop de desarrollo: el agente ejecuta, QA verifica y el loop cierra. Quien ejecuta no es quien verifica.

SOBRE SU CÓDIGO

En la primera sesión mapeamos dónde vive el conocimiento del equipo: qué está en los repos, qué en la cabeza de cada quien, y qué llega de los terceros. No se trata de entregarnos su código: se trata de entender dónde está, que es el primer paso para que su pipeline sea legible por agentes.

02   El vocabulario técnico

Un agente son dos cosas: modelo y harness

El curso no es sobre prompts —eso lo enseña un video en seis meses. Es sobre el entorno que rodea al modelo, el loop que le da un trabajo y la verificación que lo hace confiable. La misma tarea, con el mismo modelo, pasa de ~53% a ~66% de acierto en el mismo benchmark solo por cambiar el harness. Ese es el vocabulario que su equipo va a manejar al terminar.

Modelo
El motor —la CPU. Cambiarlo es cambiar de proveedor; casi nunca es lo que mueve el resultado.
Contexto (context window)
La memoria de trabajo —la RAM. Lo que el agente ve decide el resultado, no lo que el modelo "sabe".
Harness
El sistema operativo del agente: AGENTS.md por módulo, sus herramientas, rutinas de arranque y la aduana de permisos (deny rules, hooks, sandbox —testeables, no una súplica en el prompt).
Loop
El trabajo, no la instrucción: descubrir → planear → ejecutar → verificar → iterar. Turn-based, por objetivo (/goal), por tiempo (/loop) o proactivos (triage, migraciones, upgrades sin humano).
Verificación
Quien cierra el loop. Un swarm sin verificador tiene la calidad de su peor agente: volumen sin verificación son errores más rápidos.

Los modelos

Trabajamos el criterio para elegir el modelo según la tarea y ajustar el reasoning effort —Opus 5/4.8, GPT 5.6/Codex, Grok, Kimi y Fable— en lugar de resolver todo con el mismo.

EL CONTRAPESO HONESTO

Los números de ahorro por rutear modelos (−59% de costo, hasta 15× de diferencia) los publica quien vende el router. Por eso el curso no entrega una tabla para memorizar: entrega el criterio y el eval para que su equipo mida en su caso cuál modelo conviene, no en el benchmark de nadie más.

03   Las sesiones

Tres sesiones de trabajo

Dos horas cada una, una por semana. Los proyectos salen de lo que hoy más pesa en su pipeline; developers y QA trabajan juntos, y cada sesión puede avanzar más de uno.

  1. 01

    Arranque

    Mapeamos dónde vive el conocimiento del equipo y elegimos los proyectos. Montamos el espacio de trabajo, el equipo escribe su primer AGENTS.md/CLAUDE.md y arranca un proyecto real con Claude Code y Codex, con nuestra guía. Context engineering desde el primer minuto. Presencial.

  2. 02

    Taller · harness, loops y modelos

    Los developers avanzan sus proyectos diseñando loops en lugar de prompts sueltos. Harness por módulo, subagentes, orquestación en paralelo y criterio para elegir el modelo según la tarea (Opus, GPT, Grok, Kimi, Fable).

  3. 03

    Taller · verificación, QA y superficie

    El bloque de QA: codificar los chequeos que ya hacen a mano, loops que se auto-verifican y un verificador separado para revisar lo interno y lo de terceros, con cada corrección vuelta un eval. Conectamos la superficie del equipo —MCP y conectores, Claude/GPT en Slack, ChatGPT apps, el CLI de la plataforma—, cerramos el criterio en sus archivos de contexto y levantamos el diagnóstico.

CÓMO TRABAJAMOS

Las sesiones son de trabajo guiado: su equipo opera las herramientas y avanza sus propios proyectos con nosotros al lado. Nosotros aportamos el criterio —qué modelo, cómo diseñar el loop, qué conectar, cómo verificar— y el análisis del pipeline. Instalamos una forma tan buena que el equipo no necesita entenderla a fondo para extenderla. Lo que resuelven se queda con ellos y lo saben rehacer.

SOBRE EL ALCANCE

El paquete incluye hasta 8 personas (5 developers + 3 QA). No hay un límite de proyectos: cuántos se cubren lo define el alcance de cada uno, y en una misma sesión pueden avanzar varios. El análisis y la documentación entre sesiones están incluidos. El diagnóstico y el roadmap se entregan al cierre, la semana siguiente a la última sesión.

Es un taller de habilitación: su equipo termina operando estas prácticas sobre sus propios proyectos, y el diagnóstico documenta cómo escalar el uso. Alcance cerrado, sin dependencias abiertas.

04   Calendario

Tres semanas

Una sesión por semana, presencial en su oficina. Las fechas se definen con su equipo al confirmar el arranque.

05   Inversión

Lo que incluye su inversión

Un paquete cerrado: las tres sesiones guiadas, el análisis y la documentación entre ellas, y el diagnóstico con el roadmap del pipeline.

Paquete · Desarrollo MBGE
$44,000 MXN + IVA

Tres sesiones guiadas de dos horas, semanales · hasta 8 personas (5 dev + 3 QA) · presencial · diagnóstico y roadmap documentados. Pago en dos partes: 50% al inicio y 50% al cierre, con la entrega del diagnóstico.
Sesión individual $16,000 · tres sesiones $48,000 · precio de paquete $44,000.

Sesión adicional
$16,000 MXN / sesión + IVA

A partir de la cuarta, si el equipo decide sumar otro frente. Se cotiza y se agenda al momento.

Las licencias corren por su cuenta

El único costo externo del paquete son las licencias de los modelos, que MBGE contrata directamente. Ya cuentan con usuarios activos de Claude.

SOBRE LAS LICENCIAS

Team Premium garantiza por defecto que su código no se use para entrenar modelos, cosa que los planes individuales solo ofrecen como configuración. Recomendación: arrancar con el equipo de desarrollo completo, medir un trimestre y escalar con datos en la mano.

Siguiente paso

Confirmar los proyectos del equipo y agendar las tres sesiones.