Lope para presupuestos, papers académicos y memos al consejo

Lope es un runner de sprints con un ensemble de validadores multi-CLI. Cuando la gente ve “sprint”, asume “código”. Esa suposición es incorrecta, y es lo que más quiero corregir en el primer mes de este lanzamiento.

Lope funciona para ingeniería, negocio e investigación. Mismo bucle central, diferente rol del validador. Un flag --domain cambia el prompt, las etiquetas y la persona del revisor. El ensemble que detecta race conditions en tu middleware de auth también detecta brechas en tu presupuesto de Q2, tu protocolo de revisión sistemática y tu statement of work para el cliente.

Este post te muestra cómo se ve eso en la práctica.

El cambio

lope negotiate "Añadir rate limiting al API gateway"
lope negotiate "Campaña de marketing Q2 para el segmento enterprise" --domain business
lope negotiate "Revisión sistemática de técnicas de alineación de LLMs" --domain research

Tres flags, tres personas diferentes de revisor bajo el capó.

Dominio	Rol del validador	Etiqueta de artefactos	Etiqueta de comprobaciones	Revisa
engineering (defecto)	Ingeniero staff senior	Archivos	Tests	bugs, regresiones, casos límite, cobertura de tests
business	Responsable de operaciones senior	Entregables	Métricas de Éxito	plazos, presupuesto, targeting, estrategia de canal, KPIs
research	Investigador principal	Artefactos	Criterios de Validación	metodología, muestreo, validez, ética, plan de análisis

La forma estructural del documento de sprint es la misma: un objetivo, un bloque de contexto, fases, entregables por fase, criterios de éxito por fase. Lo que cambia es lo que buscan los validadores cuando lo leen.

Ejemplo 1: brief de campaña de marketing

Estás lanzando una campaña enterprise para Q2. Tienes presupuesto, tres canales, un equipo de contenidos y un CMO que quiere ver un plan antes del viernes. Esto es lo que hace lope negotiate con eso.

lope negotiate \
    "Campaña de lanzamiento de producto Q2 para segmento enterprise" \
    --domain business \
    --context "Target: CTOs en empresas de más de 500 empleados. Presupuesto: 150K€. Canales: LinkedIn, email, serie de webinars."

Lope redacta un sprint doc con fases como:

1. Investigación de audiencia y confirmación de ICP
2. Producción creativa (anuncios, landing pages, copy de email)
3. Activación de canales y calendario
4. Medición, iteración y reporting

Cada fase tiene Entregables (brief, creatividades para anuncios, landing pages, secuencias de email, guión de webinar) y Métricas de Éxito (CTR, CPL, conversión de MQL, atribución de pipeline).

Luego los validadores intervienen. En una prueba real, la primera ronda volvió con NEEDS_FIX:

• La asignación de presupuesto es ambigua entre LinkedIn paid y producción de webinar. Desglosar partidas.
• No hay plan de contingencia si el CTR cae por debajo del 0,8 por ciento en la primera semana. Añadir un trigger de pivote.
• El plan de medición confunde MQLs y SQLs. Definir cada uno, elegir uno como KPI primario.
• Sin paso de revisión legal para claims en el copy de anuncios. Añadir un gate antes de la activación de canales.

Esas son exactamente las brechas que un responsable de operaciones senior detectaría en una revisión manual. Lope las detectó en 90 segundos, a través de tres validadores LLM diferentes, con una puntuación de confianza. El drafter revisó. La segunda ronda pasó con 0,91 de confianza. Presentas un brief más sólido al CMO.

Ejemplo 2: cierre financiero trimestral

Los equipos financieros ejecutan el mismo proceso cada trimestre. También introducen errores en ese proceso cada trimestre porque el proceso vive en la cabeza de una persona y nadie lo revisa estructuralmente. Esto ocurre en startups de Madrid, en corporaciones de Ciudad de México y en fondos de Santiago de Chile por igual.

lope negotiate \
    "Proceso de cierre Q2 2026" \
    --domain business \
    --context "3 filiales (España, México, Colombia), reporting bajo normas locales + consolidación IFRS, migración SAP en curso"

Las fases vuelven como:

1. Reconciliación pre-cierre (banco, clientes, proveedores, inventario)
2. Acumulaciones y ajustes
3. Eliminación intercompañía
4. Reporting consolidado
5. Aprobación y entrega a auditoría externa

Con Entregables como balance de prueba, calendario de ajustes, paquete de eliminación, libro de consolidación, memo de aprobación firmado. Y Métricas de Éxito como varianza no reconciliada cero, cierre dentro de cinco días hábiles, entrega limpia a auditoría externa.

¿Qué señalaron los validadores en nuestra prueba? Uno captó la nota sobre la migración SAP en el contexto y preguntó: “¿Alguna fase necesita validación de doble entrada durante el período de transición de la migración?” Esa es la pregunta que hace un buen controller. Es también la pregunta que no se hace nunca hasta que alguien en auditoría encuentra la discrepancia tres meses después. Lope la sacó a la superficie en la primera ronda.

Ejemplo 3: revisión sistemática de literatura

Si alguna vez has escrito una revisión sistemática, conoces el dolor de darte cuenta en el tercer mes de que tu estrategia de búsqueda omitió toda una sub-literatura. Las guías PRISMA existen específicamente para prevenir eso, y aún así se pasan por alto porque la revisión ocurre a lo largo de meses y nadie somete el protocolo a stress test por adelantado.

lope negotiate \
    "Revisión sistemática de técnicas de alineación de LLMs 2023-2026" \
    --domain research \
    --context "Foco en RLHF, DPO, IA Constitucional. Cumplimiento PRISMA."

Fases:

1. Estrategia de búsqueda (bases de datos, palabras clave, criterios de inclusión)
2. Screening (título/resumen, texto completo, acuerdo inter-evaluador)
3. Evaluación de calidad (herramientas de sesgo, tablas de riesgo de sesgo)
4. Extracción de datos (hoja de codificación, variables, piloto de extracción)
5. Síntesis (narrativa, meta-análisis si aplica, diagrama de flujo PRISMA)

Cada fase lleva Artefactos y Criterios de Validación. Los validadores, jugando el rol de investigador principal, comprueban: ¿están definidos operativamente los criterios de inclusión? ¿Está especificado el objetivo de fiabilidad inter-evaluador (kappa > 0,8)? ¿Es la herramienta de sesgo adecuada para los diseños de estudio esperados? ¿Hay consideración de comité de ética para los datos extraídos?

En nuestra prueba, el ensemble de validadores detectó que el borrador no tenía ningún plan para manejar papers en idiomas distintos al inglés. Dos de tres validadores lo señalaron de forma independiente. El borrador se revisó para justificar la restricción solo en inglés en la estrategia de búsqueda o comprometerse a traducción para una muestra. Ese es el tipo de brecha que los revisores descubren seis meses después y obligan a una enmienda del protocolo.

Ejemplo 4: statement of work de consultoría

Eres consultora de estrategia y estás redactando un SOW para un cliente retail. El entregable es un roadmap de transformación digital. Tu reputación depende de si lo que entregas en ocho semanas coincide con lo que el cliente creyó que estaba comprando.

lope negotiate \
    "Roadmap de transformación digital para cliente retail" \
    --domain business \
    --context "$(cat BRIEF-CLIENTE.md)" \
    --max-rounds 5

Cinco rondas en lugar de tres para entregables de alto riesgo. Los validadores someten a stress test las suposiciones, los riesgos de scope creep, las dependencias ocultas, las brechas de alineación con stakeholders. El tipo de escrutinio que querrías que un socio senior diera al SOW antes de que llegue al cliente, excepto que el socio senior está ocupado y lope corre en menos de dos minutos.

Ejemplo 5: auditoría de cumplimiento normativo

El trabajo legal y de cumplimiento se beneficia especialmente de la revisión multi-modelo porque distintos modelos tienen distintas distribuciones de entrenamiento y detectan distintas brechas de cumplimiento. Esto aplica tanto al RGPD europeo como a marcos regulatorios latinoamericanos como la Ley Fintech de México o la regulación de protección de datos de Brasil (LGPD).

lope negotiate \
    "Auditoría de cumplimiento RGPD Q2 en productos cara al consumidor" \
    --domain business \
    --context "Foco en retención de datos, consentimiento, derechos de acceso del interesado."

El punto ciego de modelo único importa más cuando la consecuencia es una multa del 4 por ciento de facturación. Ejecuta tres validadores. Deja que discrepen. Deja que el ensemble vote. Usa los desacuerdos como superficie para lo que la auditoría pasó por alto.

Por qué el mismo bucle funciona en todos los dominios

El bucle es:

1. Redactar un documento estructurado con fases, entregables y criterios de éxito.
2. Validar con uno o más revisores independientes que tienen un prompt de rol claro.
3. Iterar con correcciones específicas y accionables hasta alcanzar consenso.
4. Ejecutar fase a fase, con validación después de cada fase.
5. Auditar con un scorecard.

Ese bucle no le importa si el output es código, un presupuesto, un protocolo de investigación o un checklist de cumplimiento. Le importa que el trabajo esté suficientemente estructurado para comprobarse contra criterios. Si puedes escribir cómo se ve “terminado”, lope puede validarlo.

El breakthrough para mí fue darme cuenta de que “sprint con validadores” no es una metodología de desarrollo. Es una metodología de trabajo estructurado de propósito general. La ingeniería de software resulta ser el lugar donde existe el vocabulario. Todos los demás campos también tienen sprints; simplemente los llaman “planes de proyecto” o “workbacks” o “briefs de proyecto” o “programas de auditoría”.

Pruébalo

Pega esto en cualquier agente de IA que ya uses:

Read https://raw.githubusercontent.com/traylinx/lope/main/INSTALL.md and follow the instructions to install lope on this machine natively.

Tu agente obtiene las instrucciones, instala lope y conecta slash commands en el CLI que uses. Después:

alias lope='PYTHONPATH=~/.lope python3 -m lope'
lope configure
lope negotiate "Tu prioridad de Q2" --domain business

Si trabajas en marketing, finanzas, investigación, legal o consultoría, ejecuta lope contra algo que de otro modo redactarías a mano esta semana. Observa lo que los validadores detectan. Luego dime si el bucle pertenece a tu flujo de trabajo.

El repo está en github.com/traylinx/lope. Licencia MIT. v0.3.0 (primer lanzamiento público). Cero dependencias Python.

— Sebastian