Par de programação que aprende
Um programador em par com IA que melhora a cada uso.
O problema
Cada sessão de programação com IA começa do zero. O agente não lembra o que construiu ontem, as decisões que tomou nem os padrões que estabeleceu. Cada sessão perde tempo redescobrindo o mesmo contexto.
E se o seu programador em par com IA lembrasse cada decisão arquitetural e ficasse mais inteligente com o tempo?
A config
learning_pair.toml define um quorum: um sistema multiagente com um planner que lembra e um coder que implementa. O planner carrega ferramentas de conhecimento; o coder carrega ferramentas de edição. Separação de responsabilidades no nível do agente.
Configuração do quorum
[quorum] cwd = "." db = "/tmp/learning_pair.db" # Persistent knowledge store delegation = true # Enable planner -> coder delegation verification = false snapshot_policy = "diff" # Track file changes via git diff delegation_wait_policy = "all" max_parallel_delegations = 1
Planner: o orquestrador com conhecimento
[planner] provider = "anthropic" model = "claude-sonnet-4-5-20250929" tools = [ "delegate", # Send tasks to the coder # Knowledge lifecycle — the planner's unique capability "knowledge_ingest", "knowledge_query", "knowledge_consolidate", "knowledge_list_unconsolidated", "knowledge_stats", # Planning & exploration (read-only) "read_tool", "index", "search_text", "glob", "ls", "create_task", "todowrite", "todoread", "question", ]
O planner é o único agente com ferramentas de conhecimento. Consulta decisões passadas antes de planear e depois ingere novas lições após rever o trabalho do coder. O coder não tem estado: é implementação pura. Essa separação mantém o conhecimento limpo e consolidado.
Middleware do planner: modo de agente
[[planner.middleware]] type = "context" warn_at_percent = 80 compact_at_percent = 90 fallback_max_tokens = 128000 [[planner.middleware]] type = "agent_mode" default = "plan" reminder = """# Plan Mode — Knowledge-Driven Orchestrator You are the planner. You must NOT edit files. 1. Query knowledge before planning 2. Break work into concrete tasks 3. Delegate implementation to coder 4. Ingest decisions and lessons"""
O middleware agent_mode injeta um lembrete de sistema em cada turno e mantém o planner em modo "plan". Ele não começará a escrever código por acidente: esse é o trabalho do coder. Alterne modos pelo dashboard com Ctrl+M.
Resumo de delegação: modelo barato para resultados
[quorum.delegation_summary] provider = "anthropic" model = "claude-haiku-4-5-20251001" # Cheaper model
Quando o coder termina uma tarefa, um modelo mais barato resume o resultado antes de enviá-lo de volta ao planner. Isso mantém baixos os custos de contexto: o planner vê um resumo, não o diff completo.
Delegado coder: implementação pura
[[delegates]] id = "coder" provider = "anthropic" model = "claude-sonnet-4-5-20250929" description = "Implementation specialist..." capabilities = ["rust", "python", "typescript", "shell"] tools = [ "edit", "write_file", "read_tool", "index", "glob", "search_text", "ls", "shell", "todowrite", "todoread", ]
Middleware do coder: limites + verificação de duplicados
[[delegates.middleware]] type = "limits" max_steps = 80 max_turns = 25 [[delegates.middleware]] type = "context" warn_at_percent = 80 compact_at_percent = 90 # Detect duplicate code in coder output [[delegates.middleware]] type = "dedup_check" threshold = 0.85 # 85% similarity threshold min_lines = 10 # Only check blocks >= 10 lines
O middleware dedup_check detecta quando o coder está prestes a escrever código com similaridade de 85% ou mais em relação ao código existente do projeto. Captura padrões de copiar e colar e incentiva uma implementação DRY.
Ciclo de vida em múltiplas sessões
A mágica acontece entre sessões. O conhecimento persiste no SQLite. O planner fica mais inteligente a cada vez.
Planner consulta conhecimento: vazio (primeira vez)
Planner analisa o codebase com ferramentas só de leitura
Planner planeia: "É necessária uma camada de middleware, token bucket, testes"
Planner delega para coder -> coder implementa
Planner revê e ingere: "Usamos uma abordagem token bucket com backend Redis. Middleware colocado antes da camada de auth."
Planner consulta conhecimento: encontra "token bucket, backend Redis, middleware antes de auth" de ontem
Planner planeia informado por decisões passadas: "Colocar o middleware de auth depois do rate limiter, coerente com o padrão existente"
Planner delega -> coder implementa (coerente com a arquitetura existente)
Planner ingere: "Auth usa JWT, middleware coerente com o padrão de rate limiting"
O fluxo de delegação
Funcionalidades-chave
- Ciclo de vida do conhecimento — ingestão, consulta e consolidação entre sessões
- Quorum multiagente — planner delega para um coder especializado
- Resumo de delegação — um modelo barato resume a saída do coder para o planner
- Middleware de modo de agente — mantém o planner em modo "plan", não "build"
- Dedup check — detecta código duplicado antes de escrevê-lo
- Delegação com contexto — o conhecimento passado molda os planos atuais
Experimente
# Run the learning pair cargo run --example qmtcode --features dashboard -- \ confs/learning_pair.toml --dashboard # Session 1: Ask it to build something # "Add rate limiting to the API" # Session 2 (restart, same db): Ask it to build something related # "Add authentication to the API" # Notice: the planner uses knowledge from session 1 # Optional: Create a consolidation schedule # Trigger: Interval, 3600s (hourly) # Prompt: "Run knowledge consolidation..." # Max runs: 24