Por que a IA é central na estratégia da Lerian
A Lerian enfrenta um desafio comum a empresas de tecnologia em crescimento: escalar a capacidade de desenvolvimento sem comprometer a qualidade. A resposta tradicional, contratar mais desenvolvedores, traz limitações conhecidas: integração demorada de novos membros, inconsistência de padrões e o famoso "fator ônibus", no qual o conhecimento crítico se concentra em poucas pessoas.
A abordagem da Lerian foi diferente: codificar o conhecimento institucional em agentes de IA.
Em vez de depender de documentação estática que ninguém lê, ou de esperar que os desenvolvedores sigam convenções, a Lerian criou o Ring, uma biblioteca de habilidades e fluxos de trabalho que transforma boas práticas em comportamentos obrigatórios.
O resultado? As equipes relatam:
- Redução em problemas de "funciona na minha máquina"
- Ciclos de depuração mais rápidos
- Mínimo de 85% de cobertura de testes unitários (imposto pelo TDD obrigatório)
O que é o Ring
O Ring é um sistema de habilidades e agentes autônomos para Claude Code que impõe práticas comprovadas de engenharia de software. Atualmente, consiste em 9 plugins ativos com 91 habilidades, 44 agentes especializados e 36 comandos.
A arquitetura central é simples: definições em Markdown com frontmatter YAML, descobertas automaticamente na inicialização da sessão e executadas através das ferramentas nativas do Claude Code/Droid.
Mas a inovação não está na tecnologia, está na filosofia de design.
O princípio fundamental: agentes são executores, não decisores
O insight central do Ring é que os problemas de qualidade em código gerado por IA não são técnicos, são comportamentais. A IA tende naturalmente a:
- Pular testes e ir direto para a implementação
- Fazer mudanças sem entender a causa raiz
- Declarar tarefas como concluídas sem verificação
- Repetir erros conhecidos
A solução não são prompts melhores. A solução são fluxos de trabalho estruturados que previnem atalhos.
O Ring impõe uma separação estrita de papéis:
O orquestrador nunca lê o código-fonte diretamente. Essa restrição previne o desperdício de contexto e garante que agentes especializados carreguem os padrões corretos do Ring.
Vou explicar os dois principais plugins do Ring que utilizamos no dia a dia, o PM-team e o Dev-team.
Como o PM-Team funciona: planejamento antes do código
O plugin pm-team (Product Management Team) implementa um princípio inegociável: os requisitos de negócio devem estar completamente definidos antes das decisões técnicas.
Duas trilhas de planejamento
O fluxo de trabalho de 9 gates (funcionalidades grandes)
- Gate 0: Pesquisa - Agentes paralelos investigam padrões, documentação e práticas.
- Gate 1: PRD - Requisitos de negócio (O QUÊ/PORQUÊ, nunca O COMO).
- Gate 2: Mapa de Funcionalidades - Relacionamentos e ordem de implementação.
- Gate 3: TRD - Arquitetura técnica (padrões abstratos).
- Gate 4: Design de API - Contratos e operações.
- Gate 5: Modelo de Dados - Relacionamentos entre entidades.
- Gate 6: Mapa de Dependências - Escolhas tecnológicas explícitas.
- Gate 7: Divisão de Tarefas - Tarefas com critérios de sucesso.
- Gate 8: Subtarefas - Passos atômicos de 2 a 5 minutos.
Por que essa separação?
A tendência natural é misturar "o que construir" com "como construir". Isso cria documentos que são simultaneamente vagos demais para implementar e específicos demais para mudar.
O PM-Team impõe que o PRD (Product Requirements Document) contenha apenas:
- Problema: O que está errado hoje?
- Usuários: Quem sofre com isso?
- Impacto: Quanto isso custa?
- Sucesso: Como medimos que resolvemos o problema?
Detalhes técnicos como "usar PostgreSQL" ou "implementar em Go" são proibidos no PRD. Eles pertencem ao TRD (Technical Requirements Document), que só começa após a aprovação do PRD.
Como o Dev-Team funciona: qualidade imposta por design
O plugin dev-team (Development Team) gerencia a execução de código através de um ciclo de 6 gates orquestrado por agentes especializados.
Os 6 Gates de desenvolvimento
O Gate 4: revisão de código paralela
O Gate 4 é onde o Ring mais se diferencia. Em vez de um revisor único, três agentes especializados analisam o código simultaneamente:
Os três revisores devem aprovar para que o código avance. Achados críticos requerem correção imediata, voltando aos agentes de implementação e reexecutando todos os revisores novamente.
O Gate 5: validação humana obrigatória
O Gate 5 é o ponto de verificação final e requer intervenção humana explícita. O usuário deve responder com:
- APPROVED para aceitar a implementação
- REJECTED: [motivo] para rejeitar com uma justificativa
O silêncio não é aprovação. O sistema aguarda indefinidamente por uma resposta explícita.
Anti-racionalização: como prevenir que a IA tome atalhos
A inovação mais importante do Ring são as tabelas de anti-racionalização. Elas reconhecem que a IA tende a "ajudar", tomando decisões autônomas que parecem razoáveis, mas violam os fluxos de trabalho.
Exemplos reais do Ring
Prevenindo a não adoção de padrões:
Prevenindo o contorno dos gates:
Resistência à pressão
O Ring reconhece que humanos pressionam a IA a pular etapas. As tabelas de "Pressão vs. Resposta" definem exatamente como reagir:
O princípio central:
Zero exceções multiplicado por qualquer combinação de pressão = zero exceções.
A Importância da validação humana
O Ring é explícito: a IA não substitui o julgamento humano em decisões críticas.
Onde a validação humana é obrigatória
1. Aprovação do PRD (Gate 1): O problema descrito é o problema real?
2. Aprovação do TRD (Gate 3): A arquitetura proposta faz sentido?
3. Aprovação da Implementação (Gate 5): O código entregue resolve o problema?
Por que não automatizar tudo?
Testes automatizados verificam se o código funciona. A validação humana verifica se o código resolve o problema certo.
Um sistema pode passar em 100% dos testes e ainda:
- Resolver o problema errado
- Ter uma UX confusa
- Violar expectativas de negócio não documentadas
- Criar débito técnico não óbvio
O Ring garante que os humanos permaneçam no ciclo para decisões que requerem contexto além do código.
Autoaprovação é proibida
Uma regra crítica: o agente que implementou o código não pode aprová-lo. Isso previne o viés de confirmação, no qual quem escreveu naturalmente acredita que está correto.
Padrões centralizados: fonte única de verdade
O Ring usa arquivos de padrões centralizados que todos os agentes referenciam:
A regra dos 4 arquivos
Quando os padrões são modificados, 4 arquivos devem ser atualizados simultaneamente:
- O arquivo de padrões (standards/{file}.md)
- O índice de conteúdo no mesmo arquivo
- A tabela de cobertura (standards-coverage-table.md)
- O agente que o referencia (agents/{agent}.md)
Isso previne o desvio, onde padrões e agentes ficam dessincronizados.
Conclusão: fluxo de trabalho como garantia de qualidade
O Ring representa uma mudança de paradigma: em vez de confiar que a IA seguirá boas práticas, impõe fluxos de trabalho que tornam atalhos impossíveis.
Os mecanismos centrais são:
1. Fluxos de Trabalho Obrigatórios: Cada tarefa flui por gates; pular é impossível.
2. Agentes Especializados: Cada gate tem um agente com padrões pré-carregados.
3. Anti-Racionalização: Desculpas comuns são explicitamente rejeitadas.
4. Validação Humana: Certas decisões requerem aprovação humana explícita.
Para a Lerian, isso significa que o conhecimento institucional não depende de pessoas específicas. Novos membros da equipe trabalham com os mesmos padrões desde o primeiro dia. E a qualidade não é uma esperança, é uma consequência do sistema.
Além do PM-team e Dev-team apresentados neste artigo, a Lerian desenvolveu outros plugins especializados que expandem as capacidades do Ring para diferentes áreas da organização:
O Ring está disponível como código aberto em github.com/LerianStudio/ring.
Artigo escrito para desenvolvedores e líderes técnicos interessados em como a IA pode escalar o desenvolvimento sem sacrificar a qualidade.