Ada: IA como produto da engenharia na Alice

Na Alice, acreditamos que inteligência artificial tem o potencial de aumentar drasticamente a velocidade de entrega de produtos. Mas fluência em IA não escala por boa vontade. Distribuir licenças de ferramentas de IA pro time inteiro e esperar que cada pessoa descubra sozinha como usá-la bem produz resultados desiguais: alguns devs viram referência, a maioria fica na superfície e o conhecimento não circula.

A nossa resposta foi tratar IA na engenharia como um produto de plataforma, com um framework que o time inteiro usa, a Ada. Este post é sobre o que a Ada é, as decisões de arquitetura que a sustentam e onde estamos na adoção.

De onde vem o nome

Ada é sigla de Alice Development Approach, a forma como a Alice desenvolve software. O nome também homenageia Ada Lovelace, que escreveu o primeiro algoritmo da história em 1843, descrevendo um fluxo para uma máquina executar. É exatamente o que a plataforma sistematiza hoje: a forma como descrevemos trabalho para o Claude Code (ou qualquer outro coding agent) executar.

O que é a Ada

Desde o início do ano, o time de engenharia não escreve mais código à mão: descreve o que precisa, revisa e decide, e quem escreve o código é o Claude Code. A Ada é um plugin do Claude Code, no marketplace privado da Alice, que distribui para o time um conjunto de fluxos de trabalho versionados. Todos os desenvolvedores instalam com um comando, rodam os mesmos comandos sobre as mesmas regras, e recebem atualizações de forma centralizada.

A Ada cobre o ciclo de desenvolvimento de ponta a ponta, onde uma feature passa por uma sequência de etapas bem definidas. Há fluxos paralelos para investigação de bugs com análise de causa raiz, revisão de Pull Request e correções pequenas que não justificam a cerimônia completa.

O que importa aqui é menos em cada comando isolado e mais o fato de que todo o time roda os mesmos. Quando refinamos o fluxo de review, ele melhora para todo mundo na próxima atualização do plugin. Quando um padrão de teste se firma, ele entra no /execute e deixa de depender de quem está codando. É isso que transforma um conjunto de prompts num produto: a melhoria fica centralizada e a distribuição acontece de forma automática.

O que a Ada faz

A Ada organiza o trabalho em comandos. Cada um cobre uma etapa, e /feature costura o caminho completo de ponta a ponta. Por baixo, os comandos acionam subagentes especialistas (mapeamento de módulo, revisores por dimensão, detecção de squad), mas o dev interage só com os comandos abaixo.

Ciclo de desenvolvimento de uma feature

/feature orquestra o caminho completo, com um gate entre cada etapa.
/spec transforma um brief em especificação, com user stories, critérios de aceite e requisitos. É o início de qualquer trabalho novo.
/plan lê a spec, gera um plano de implementação e todas as tasks que o agente deverá executar.
/execute implementa o plano com TDD, atualiza as tasks conforme avança e verifica a cada fase.
/verify roda lint, typecheck, testes e build no escopo do que mudou, e devolve aprovado ou rejeitado.
/deploy-dev verifica e sobe a branch para os ambientes de dev para validação.
/ship gera a descrição do PR a partir da spec e do plano, abre o PR e dispara o review.

Gates opcionais, quando a feature ainda tem incerteza

/brainstorm explora o problema e propõe abordagens quando a ideia ainda está vaga. Roda antes da spec.
/research dispara pesquisa em paralelo sobre APIs, exemplos e padrões do código quando a feature mexe com algo desconhecido. Roda antes do plano.
/discuss varre a spec atrás de ambiguidade, edge cases e integrações indefinidas, e faz perguntas ao desenvolvedor para melhorar a spec. Roda entre a spec e o plano.

Bugs e suporte

/bug investiga um ticket de suporte de ponta a ponta: define a squad responsável, faz a análise da causa raiz, valida as hipóteses contra os dados no Metabase e devolve um veredito.

Review de PR

/review roda o review canônico da Alice, com classificação simples ou complexo, revisores especialistas em paralelo, calibração de severidade e um veredito explícito. É o que sustenta o auto review.
/pr-review-digest resume os comentários de review (Ada, PR-Agent e pessoas) numa tabela do que ainda está em aberto.

Atalho e apoio

/quick é o fast-track para mudanças triviais, um fix pequeno ou um ajuste de config, que não justificam a cerimônia de spec e plan.
/feedback registra fricção na sessão com o usuário ou capacidade faltante da própria Ada, abre automaticamente um issue no github que alimenta o roadmap das próximas versões.
/scan-pii adiciona uma camada extra de verificação de dados pessoais nos dados de avaliação de um PR.

Onde mora cada regra

É mais difícil decidir onde cada regra deve viver do que escolher o que automatizar. Uma instrução escrita no lugar errado ou vira ruído (aparece em contextos onde não se aplica) ou vira lixo (ninguém a encontra quando precisa).

A Ada resolve isso por meio de duas perguntas:

A regra é específica a um repositório? Se sim, ela mora no próprio repositório, num arquivo de convenções local. A Ada lê esse arquivo quando trabalha ali. Exemplo: a convenção de nomenclatura de migrations de um repositório backend não tem por que estar no plugin, ela pertence ao repositório backend.
A regra é agnóstica de repositório e envolve código executável? Se sim, ela mora na Ada como capacidade compartilhada. Senão, vai pra camada de helpers genéricos.

Essa separação é o que mantém a Ada enxuta. O plugin carrega o que é genuinamente transversal, como revisar um PR ou estruturar uma spec, e delega ao repositório tudo que é local àquele código. Cada repo continua dono das suas próprias regras, e a Ada não tenta saber tudo sobre todos.

Há uma consequência de design importante aqui: a Ada é stack-aware. A Alice tem backend em Kotlin e vários frontends em Vue e React. O mesmo comando /spec ou /verify funciona nos dois mundos porque a Ada resolve a stack ativa a partir de um registro e aplica os comandos de verificação certos pra cada uma. O dev não precisa saber qual mecanismo roda por baixo. Ele roda /verify e a Ada sabe se chama o build do backend, frontend, mobile ou outras stacks.

Como construímos

Em vez de adotar um framework fechado, combinamos o que funcionava melhor de seis referências do mercado numa abordagem própria, desenhada pro nosso contexto.

A Ada não tem uma squad dedicada. Ela é construída por um grupo transversal de staff engineers e engineering managers que não saem das próprias squads, e isso funcionou melhor do que concentrar tudo num time só pra isso. Quem desenha os fluxos é quem sente a dor deles entregando produto todo dia.

A Ada captura fricção do próprio uso, com um feedback loop embutido. Quando um fluxo falha ou frustra, isso vira um registro estruturado via github issue que alimenta a próxima iteração do plugin. O produto melhora a partir de como ele é usado de verdade.

Onde estamos

Acompanhamos a adoção por três indicadores.

Código escrito com o Claude Code: 100%. O time de engenharia não escreve mais código à mão. Todos os devs têm commits feitos com o Claude Code, e essa é a forma padrão de trabalhar.
Adoção da Ada: 90%. A maioria dos devs já roda os fluxos da Ada, além do Claude Code padrão. Os restantes são os que codam em alguma stack que a Ada ainda não reconhece.
Review automático de PR. Um agente revisa os PRs, acelerando o processo de code review para evitar gargalos, dado o maior volume de código sendo produzido.

Chegar a 100% de uso de IA é relativamente fácil quando a ferramenta está disponível. Chegar a 90% de uso de um produto de plataforma, com fluxos versionados e compartilhados, é o sinal de um ganho organizacional, que circula pelo time inteiro em vez de ficar concentrado em alguns devs.

Remote Agents

Além disso, construímos agentes que atuam diretamente no fluxo de pull requests e bug report. Um revisa cada PR automaticamente. O outro avalia se a mudança está apta a ir pro ar. Outro investiga e resolve bugs reportados.

Auto Review

Assim que um PR é aberto, a Ada lê o código inteiro e devolve uma revisão estruturada em cerca de quatro minutos. Classifica a complexidade da mudança, sinaliza o que é crítico e sugere melhorias, com o código pronto para corrigir em cada ponto. São recomendações, e o autor decide o que aplicar. O ganho está em toda PR receber esse olhar, sempre. Hoje o auto review roda em 100% dos PRs de backend, frontend e mobile.

Auto-merge

O auto-merge é uma camada mais rígida, voltada para a segurança. Ele roda uma checklist de doze critérios antes de dizer se a PR pode ser mergeado: não ser rascunho, apontar pra main, não ter migração de banco, mudanças restritas a um único domínio, revisão aprovada, autor é codeowner, e assim por diante. O sinal verde só aparece quando todos passam e o PR é mergeado. Estamos sendo bem conservadores nesse primeiro momento, a maioria das nossas mudanças ainda pedem o olhar de uma pessoa antes do merge.

Bug-triage

O bug-triage é o primeiro a olhar um ticket de suporte. Ele lê o que foi reportado, identifica qual squad é responsável e consulta a base de conhecimento daquela squad pra entender se aquilo já apareceu antes. No fim, classifica o ticket em uma de cinco categorias: bug conhecido, bug novo, dúvida, não pertinente ou inconclusivo. É essa decisão que define o que acontece a seguir. O resultado da triagem são dois comentários no próprio ticket: um técnico, escrito para a squad responsável, e outro em português claro para a pessoa que reportou com a explicação que ela precisa. Se for um bug já conhecido, o usuário recebe o workaround na mesma hora. Se for algo que precisa de mais contexto, o agente pergunta. O ganho é que o ticket deixa de esperar dias até alguém de engenharia ter tempo de olhar — a primeira resposta sai em minutos.

Bug-solver

O bug-solver entra só quando o bug-triage diz que é um bug novo. A ideia é simples: se o bug é genuíno, não é necessário esperar um agente humano começar a investigar. Ele clona o repositório certo, lê as convenções daquele código e investiga a causa do bug vasculhando arquivos, procurando padrões, montando uma hipótese. Quando chega a uma conclusão, propõe a correção em forma de pull request, com a explicação do que mudou e por quê. Antes de o PR ir pro ar, passa pelo review automático da Ada e por uma checagem de dados sensíveis. Só depois disso o PR aparece no GitHub, pronto para o squad revisar, testar e decidir o que fazer.

Ada como remote agent. Esses agentes rodam como remote agents: o próprio evento de abertura do PR dispara a Ada remotamente, sem ninguém precisar iniciar nada. Alertas no Datadog e tickets de report de bugs no JIRA disparam os agentes de bug. Além de viver como plugin no terminal de cada dev, a Ada opera de forma autônoma dentro do fluxo de código, no momento exato em que o trabalho acontece. É o tipo de automação de IA em produção que aumenta drasticamente a capacidade de entrega do time de engenharia da Alice.

Como medimos o uso

Os números de adoção vêm de três fontes: os commits e PRs no GitHub, incluindo os trailers que marcam quando o Claude Code ou a Ada participaram de cada mudança; e o volume por dev. Isso dá uma leitura confiável, mas depende de coleta manual e de juntar as fontes a cada rodada.

O próximo passo é tornar essa medição contínua. Estamos construindo o ada-mcp, um servidor interno de Developer Experience que funciona como ponto único de entrada para métricas geradas por qualquer coding agent. Ele cobre duas frentes:

Telemetria de uso. Cada vez que alguém roda um fluxo da Ada, o evento vai pro ada-mcp, que encaminha pro Datadog, sem depender de coleta manual.
Métricas do próprio dev. Cada pessoa consulta o que rodou, por exemplo quantos /spec fez na semana.

Tem um detalhe que fecha o ciclo: o ada-mcp está sendo construído com a própria Ada, passando por /spec, /plan, /execute, /verify e /ship. Ada constrói Ada.

O que isso significa

Tratar IA como produto de engenharia significa assumir que o trabalho não acaba quando a ferramenta está disponível. Ele apenas começa. As decisões de onde cada regra mora, de quem constrói, e de como medimos uso real são o que separa “ter IA” de “fazer engenharia com IA”. É isso que a Ada é pra Alice, e seguimos construindo.