Pitch: OpenClaw + GitHub + agentes: uma tentativa de orquestrar engenharia · MestreY0d4

Nos últimos meses eu venho explorando um problema que acho interessante: os modelos e agentes evoluíram rápido, mas o workflow de engenharia em volta deles ainda costuma ser muito improvisado.
Para estudar isso, eu desenvolvi o Fabrica, um plugin open source para o OpenClaw.
A proposta é orquestrar um fluxo mais completo de engenharia, passando por:

entrada via Telegram ou CLI
criação e organização de issues
execução por agentes com papéis diferentes
fluxo de PR no GitHub
diagnóstico e recovery quando o pipeline trava ou entra em loop
O objetivo não é vender “autonomia mágica”, e sim experimentar uma camada de orquestração mais observável e previsível para esse tipo de workflow.
Nos últimos ciclos eu foquei principalmente em robustez:
convergência pós-PR
validação de QA evidence
doctor/metrics
setup mais confiável
testes em máquina limpa para reduzir o risco de “só funciona na minha máquina”
Ainda tem bastante coisa em aberto, principalmente:
onde essa automação realmente ajuda
quando ela começa a adicionar complexidade demais
quais limites fazem sentido para autonomia nesse contexto
Se alguém quiser olhar com olhos críticos, eu gostaria bastante de feedback sobre arquitetura, onboarding e casos de uso reais.

Tema interessante. Estou acompanhando a evolução de agentes de IA e separando o que funciona do hype:

O que funciona hoje (abril/2026):

Code review automatizado → escopo limitado, resultado verificável ✅
Geração de testes unitários → padrão repetitivo, fácil validar ✅
Refatoração autônoma de codebase → funciona só pra mudanças mecânicas (renomear, extrair método) ⚠️
"Resolva essa issue do zero" → muitas decisões ambíguas, contexto insuficiente ❌

O problema real da orquestração multi-agente:

Frameworks como CrewAI e AutoGen vendem "monte 5 agentes especializados e eles colaboram". Na prática:

Comunicação entre agentes é lossy — cada um resume o contexto antes de passar pro próximo. Informação se perde.
Custo explode — 5 agentes conversando = 5x mais tokens. Tarefa de R $0,10 vira R$ 2,00.
Debug impossível — resultado final errado, qual dos 5 decidiu errado?

O que eu uso como alternativa:

Workflow determinístico (n8n) que chama LLM só quando precisa de geração de texto. Sem framework de multi-agentes. Cada step tem input/output visível. O fluxo é previsível — só a geração de texto é probabilística. Custa ~R$ 0,15 por execução.

O ponto que pouca gente discute: o MCP (Model Context Protocol) está resolvendo o problema certo — padronizar como LLMs acessam ferramentas (filesystem, banco, APIs). É tipo o LSP para IDEs. Um servidor MCP para PostgreSQL funciona com qualquer LLM que implemente o protocolo. Padronização > implementação proprietária.