Um desenvolvedor sábio não inicia um novo projeto abrindo uma solicitação pull gigante. Eles passam por brainstorming, discussão com colegas de equipe, prototipagem, diagramas, propostas, ADRs, MRs/PRs e GitOps — com um Review Bot em cada mudança — e, quando a escala exige, a arquitetura multiagente do Workstation para montar uma excelente equipe de desenvolvimento que entrega rapidamente o trabalho de nível de produção.
1. O que “sábio” significa em um novo projeto
Sabedoria é aprender barato cedo e erros raros e caros tarde. A sequência abaixo é ordenada de forma que cada etapa reduza o raio de explosão da próxima:
Brainstorm → Discuss with workmates → Prototype → Diagram → Propose → ADR
→ Implement in small slices → MR/PR + Review Bot → Merge
→ GitOps promote (dev → staging → prod) → Observe → Iterate
Optional scale-up:
Workstation multi-agent crew (Planner / Builders / Reviewers / Ops)
with human gates on risky actions
2. Brainstorming
Antes de gastar o tempo de outras pessoas, passe de 30 a 90 minutos sozinho:
- Resultado - o que deve ser verdade para o negócio quando terminarmos?
- Restrições — tempo, conformidade, plataformas, habilidades, orçamento.
- Não-objetivos - o que v1 explicitamente não incluirá.
- Riscos — dados, segurança, desempenho, aprisionamento, carga operacional.
- Métricas de sucesso – escolha dois (por exemplo, latência + adoção ou custo + taxa de erro).
Escreva abaixo docs/ideas/. Brainstorms não escritos evaporam.
3. Discussões com colegas de trabalho
Convide o menor círculo útil: um implementador peer, um proprietário de um sistema adjacente e segurança/SRE quando o risco o justificar.
- Caixa de tempo (25–45 minutos). Termine com decisões ou perguntas abertas.
- Opções de força: A vs B vs adiar – não um acordo vago.
- Designe um escriba; a nota semeia a proposta.
- Capture o desconforto como riscos para o ADR – sem vetos silenciosos.
RFCs assíncronos funcionam bem se alguém fechar o ciclo.
4. Prototipagem
Aumente quando a incerteza for alta. Regras sábias:
- Rotule-o como um pico; definir uma parada no calendário (normalmente de 1 a 3 dias).
- Guarde-o em um galho descartável ou
spikes/- não polir. - Escreva dez marcadores sobre o que você aprendeu (especialmente as falhas).
- Decida: promover, reescrever ou abandonar - nunca “torne-se silenciosamente um estímulo”.
5. Diagramas
Geralmente, três esboços são suficientes:
| Diagrama | Respostas |
|---|---|
| Contexto (C4 L1) | Quem fala com o quê? Confiar nos limites? |
| Sequência | Caminho feliz + um caminho de fracasso |
| Implantação | Onde corre; fluxo de configuração e segredos |
Armazene Mermaid ou SVG ao lado da proposta. Atualize quando os ADRs mudarem.
6. Propostas
Mantenha a RFC curta (1–3 páginas): problema, opções (pelo menos duas), recomendação, impacto (segurança/custo/operações), implementação e reversão, perguntas abertas. Quando aprovada, transforme a decisão em ADR.
7. ADR – Registros de Decisão de Arquitetura
# ADR-00XX: Title Status: Proposed | Accepted | Superseded by ADR-00YY Date: YYYY-MM-DD Deciders: @alice @bob ## Context ## Decision ## Consequences ## Alternatives considered
Mantenha ADRs no git (docs/adr/). Vincule-os aos PRs. Substituir em vez de reescrever a história.
8. MR e PR — a unidade de entrega
SENHOR (Solicitação de mesclagem) e RP (Pull Request) têm a mesma ideia: um conjunto de alterações revisável.
- Pequeno (prefira <400 linhas de diferença significativa); uma intenção por mudança.
- Descrição: por que, como testar, arriscar, reverter.
- Links: ticket + ADR + diagrama.
- Faça um rascunho antecipado para feedback; nunca force a mesclagem em torno de CI vermelho ou descobertas de bot de alta gravidade sem uma exceção por escrito.
## Summary ## Test plan - [ ] Unit / contract tests - [ ] Manual path … ## Risk & rollback ## References (ADR, ticket)
9. Review Bot – comentários automáticos que protegem a produção
Um Review Bot é um primeiro revisor automatizado. Não substitui os humanos; ele antecipa o que é chato e perigoso, para que os desenvolvedores gastem tempo no design e nos riscos do produto.
9.1 O que deve comentar
- Segurança: injeção, lacunas de autorização, vazamento de segredo, padrões inseguros
- Correção: caminhos nulos, corridas, migrações interrompidas
- Testes: falta cobertura em novas agências
- API/contratos: alterações significativas sem alterações de versão
- Operações: tempos limite ausentes, novas tentativas ilimitadas, gravações não idempotentes
9.2 Como isso agiliza a vida do desenvolvedor
- O autor abre PR → comentários do bot em minutos.
- O autor corrige ou responde antes de perguntar aos humanos.
- Humano lê o resumo do bot + concentra-se na arquitetura e no raio de explosão.
- Menos rodadas de nit; menos armas de fogo escapadas na produção.
9.3 Política que mantém o bot útil
- Gravidade: bloqueador / deveria corrigir / nit — lêndeas não devem bloquear mesclagem.
- Ignore os caminhos gerados; sintonize falsos positivos mensalmente.
- Exigir aprovação humana em
auth/,infra/, IAM e caminhos de dinheiro. - Nunca deixe o bot ser o único revisor de serviços críticos para a produção.
Wire SaaS bots (por exemplo, CodeRabbit), Cursor Bugbot ou um Action + LLM personalizado sobre o diferencial de PR. Camada lint → SAST → LLM para uma postura mais forte.
10. Melhores práticas de GitOps para qualidade de nível de produção
O estado desejado reside no git. Um reconciliador (Argo CD, Flux, etc.) faz a correspondência do cluster. A promoção é uma fusão; a reversão é uma reversão.
- Separe o código do aplicativo e a configuração do ambiente (ou limpe
envs/dev|staging|prodsobreposições). - Não ad hoc
kubectl applycutucar como o caminho feliz - apenas quebra de vidro, auditado. - Entrega progressiva: sincronização automática de ambientes inferiores; sincronização fechada para produção.
- Resumos de imagens sobre tags mutáveis em prod.
- Política como código (OPA/Kyverno) para privilégios e registros.
- Observe após a sincronização; pratique a reversão.
A qualidade do código não se trata apenas de funções limpas — é também como a mudança entra na produção.
11. Arquitetura multiagente de estação de trabalho – construindo ótimas equipes de desenvolvimento
Um único desenvolvedor sábio ainda precisa de alavancagem. A arquitetura multiagente da estação de trabalho (pacotes de estações de trabalho Agentic AI e OpenClaw for Business onde você precisa de equipes de agentes incorporadas ou especializadas) permite que você construir automaticamente uma equipe de desenvolvimento em torno de um resumo de negócios - não de um organograma estático.
11.1 O ciclo de composição
- Apresentação — resultado das partes interessadas, restrições, SLA.
- Compor — mapeie funções para habilidades (Planejador, Construtor, Revisor, Operações, Conformidade).
- Inicialização — tempo de execução do agente + ferramentas MCP + memória + trilha de auditoria.
- Executar — os agentes puxam o trabalho, implementam de acordo com as especificações/AC e revisam cada etapa.
- Revise até limpar — Review Bot + agentes revisores + portões humanos.
- Enviar — GitOps promove o ambiente que importa.
11.2 Mapa de funções (humano + agente)
| Papel | Agente faz | Humano ainda possui |
|---|---|---|
| Planejador | Épicos, histórias, AC de Spec | Cortes de prioridade e escopo |
| Construtores | Implementação paralela, testes | Julgamento de domínio em arestas duras |
| Revisores | Conformidade com especificações, revisão da triagem do bot | Arquitetura e aprovação do produto |
| Operações | Sincronização de GitOps, observação de SLO, reversão de rascunho | Comando de ativação e incidente |
| Portão HITL | Escalar gravações/gastos arriscados | Aprovar ou rejeitar |
11.3 Por que isso cria ótimas equipes
- Especialização — cada agente tem um emprego; a qualidade aumenta quando os papéis não se confundem.
- Rendimento sem caos — construtores paralelos por trás de um único Spec and Review Bot.
- Memória compartilhada de decisões — O histórico de ADRs + Spec + PR torna-se a memória de longo prazo da equipe.
- Os mesmos portões dos humanos — CI, Review Bot, CODEOWNERS, GitOps — os agentes não ignoram a disciplina de produção.
- Velocidade de negócios – horas para formar uma equipe capaz, em vez de semanas para contratar para cada pico.
11.4 Como isso se conecta ao caminho sábio
Brainstorm e discussão ainda acontecem com humanos. Protótipos e diagramas ainda acontecem. A tripulação multiagente acelera elaboração de propostas, estrutura de ADR, fatias de implementação, triagem de Review Bot e promoção de GitOps – enquanto os humanos mantêm o julgamento sobre os resultados e os riscos. Esse é o modelo de estação de trabalho: estações de trabalho agentes e pacotes OpenClaw configurados para seus fluxos de trabalho, não uma janela de bate-papo fingindo ser uma equipe.
12. Portões de qualidade de ponta a ponta
Local: pre-commit (fmt, lint, secrets) + unit tests PR open: CI + Review Bot comments PR merge: human approve + branch protection + required checks Main: immutable artifact (image digest) GitOps: update env overlay → sync → verify Agents: Planner/Builder/Reviewer/Ops stay inside the same gates Prod: SLOs + alerts + runbook linked from ADR/PR
13. Lista de verificação inicial
- Criar
docs/ideas/,docs/architecture/,docs/adr/ - Adicionar modelo PR/MR + CODEOWNERS + proteção de ramificação
- Habilitar verificações obrigatórias de pré-confirmação + CI
- Instale o bot de revisão; ajustar filtros de caminho e gravidades
- Escreva ADR-0001: “Usamos GitOps para implantação”
- Defina regras de promoção ambiental e um dia de jogo de reversão
- Se a entrega for escalonada: equipe multiagente da estação de trabalho em pé (planejadores/construtores/revisores/operações) com portas HITL
14. Antipadrões
- PRs gigantes “WIP, por favor, aprove”
- Arquitetura apenas no Slack – nunca no ADR
- Protótipo mesclado como produto sem testes
- Desativando o Review Bot porque ele incomoda
- Agentes com acesso de gravação e sem porta humana
- Hotfix para produção fora do GitOps sem plano de reversão
15. Fechamento
Um desenvolvedor sábio trata um novo projeto como uma sequência de artefatos de aprendizagem – notas, diagramas, propostas, ADRs – e depois entrega por meio de pequenos MRs/PRs assistidos por um Review Bot e promovidos pelo GitOps. A arquitetura multiagente da estação de trabalho estende essa sabedoria a uma equipe de desenvolvimento completa: agentes especializados, especificações compartilhadas, julgamento humano onde for importante e portas de nível de produção em todos os caminhos da vida. É assim que a qualidade do código permanece otimizada para produção enquanto o negócio avança rapidamente.
Publicado por Estação de trabalho.
