Título del artículo: Bot de Paper-Trading Multi-LLM con Claude Opus como Ingeniero Principal y Gemini como Estratega: Desglose de Arquitectura

Un desarrollador ha compartido un bot autónomo de paper-trading que funciona en Alpaca y utiliza una arquitectura multi-LLM con roles acotados y un proceso de veto documentado. El proyecto abarca aproximadamente 4.900 líneas de código en cinco módulos de Python y es completamente de código abierto en GitHub.

Arquitectura: Tres Roles, Alcance Acotado

• Comandante (humano): Autoridad sobre el capital y aprobación de tesis. Cualquier aspecto que involucre dinero requiere aprobación humana.
• Estratega (Gemini Pro): Limitado únicamente a la adjudicación de tesis. No se le permite tomar decisiones de implementación, elegir el SDK del bróker ni decidir la arquitectura.
• Ingeniero Principal (Claude Opus 4): Escribe todo el código. Audita las directivas del Estratega y tiene poder de veto sobre aquellas que no sobreviven al contacto con la realidad de la ingeniería. Los vetos quedan registrados.

Ninguna parte puede implementar de forma autónoma. Cada desacuerdo se registra en un documento llamado "Strategist Codex" que ya cuenta con más de 270 entradas. El codex nunca oculta los cambios de opinión: si un principio se ve superado posteriormente, ambas versiones permanecen con sus fechas.

Por qué funciona el Multi-LLM aquí

El creador argumenta que un solo LLM no tiene incentivos para discrepar consigo mismo. Dos LLMs de diferentes proveedores con alcances acotados y una ruta de veto documentada producen algo más cercano a un proceso real de revisión de ingeniería. La fricción fuerza los desacuerdos a la fase de diseño, evitando que aparezcan en la fase post-mortem.

Ejemplo real: Desacuerdo sobre un campo del SDK del bróker

Directiva del Estratega: anclar un reloj de decadencia de posición de 14 días a Position.created_at del SDK del bróker. Claude (Ingeniero) verificó dir(Position) con el SDK vivo de Alpaca y descubrió que el campo no existe. Implementó un libro de contabilidad del lado del estado y registró la actualización de la doctrina con la justificación: "el bróker no proporcionaba el campo que la adjudicación original suponía". Durante la revisión de arquitectura, Claude refactorizó aún más porque la primera versión mantenía un bloqueo de estado a través de N llamadas al bróker. Ambas versiones quedan registradas en el Codex.

Para quién es esto

Desarrolladores que construyen flujos de trabajo multi-LLM, especialmente para automatización financiera o cualquier dominio donde las pistas de auditoría y la revisión adversarial sean críticas. También relevante para quienes exploran sistemas multiagente coordinados con registro explícito de vetos.

Repositorio y paper completo de arquitectura de 9 páginas: https://github.com/ALGEM-hub/Whitepaper