O Duolingo habilitou aprovação automática de pull requests de baixo risco por um bot de IA e viu o tempo mediano de merge cair de cerca de 18 horas para 12 horas, sem aumento relevante na taxa de defeitos. O caso foi apresentado por Sarah Deitke, engenheira de software da empresa, na QCon London, em palestra publicada pelo InfoQ: o ponto central é que nem tooling nem agentes bastam, a adoção de IA é, antes de tudo, uma mudança de cultura viabilizada por educação.
Deitke trabalha há cerca de dois anos no Duolingo, a maior parte no time chamado DevEx AI. Diferente de um time tradicional de developer experience, focado em merge queues e CI/CD, o grupo dela existe para habilitar os engenheiros a usar IA de forma efetiva nos fluxos de trabalho.
A tese da apresentação: boa parte das organizações já dá acesso a ferramentas como Cursor e Claude Code, mas poucas têm um time dedicado a fazer essas ferramentas renderem.
Por que a adoção de IA trava nas empresas
Sarah Deitke lista quatro obstáculos recorrentes na adoção de IA dentro de engenharia. O primeiro é o ceticismo dos próprios engenheiros, para quem a mudança quebra o que aprenderam e praticaram por anos. O segundo é que sistemas centrais, como code review, são tratados como sagrados, boas práticas lapidadas por anos, agora pressionadas pelo gargalo criado quando a IA escreve código mais rápido do que humanos revisam.
O terceiro ponto é a accountability: quando um dos lados da revisão é a IA, quem responde pelo problema? O quarto é a confiança, lenta para construir e rápida para perder. Segundo Deitke, essas barreiras não se resolvem comprando mais ferramentas, e sim com um programa explícito de alfabetização em IA.
# publicidade
Como o duolingo construiu alfabetização em IA
O programa do DevEx AI tem cinco frentes. A primeira são workshops práticos em formato de laboratório, que os engenheiros percorrem no próprio ritmo, cobrindo temas como servidores MCP, regras do Cursor, requisições em lote a LLMs e avaliações (evals).
O dado apresentado: em um all-hands da empresa, 95% da engenharia relatou ter aprendido algo novo e recomendaria o formato. Deitke destaca que conteúdo pré-validado internamente gera mais confiança do que treinamento genérico trazido por um fornecedor.
A segunda frente são dashboards de observabilidade de IA. O time começou com um gráfico simples de usuários ativos diários de um ou dois fornecedores e evoluiu para cortes por função (engenharia, design, finanças), por comunidade de desenvolvedores (iOS, Android, backend), IDEs, linguagens, consumo de tokens, custo e família de modelo. Os próprios dashboards são mantidos por vibe coding: para criar um gráfico novo, o time pede à IA que o adicione. Como isso ajuda na prática? Os picos de uso viram gatilho para convidar pessoas a compartilhar aprendizados com o restante da organização.
Office hours e aprendizado compartilhado
A terceira frente são office hours ao vivo, slots de 15 minutos que qualquer pessoa da empresa pode reservar para tirar dúvidas sobre IA.
O público surpreendeu: não são só engenheiros, mas também learning designers que passaram a fazer vibe coding e precisam aprender GitHub, e equipes de suporte de QA escalando automações.
A quarta frente combina um canal de Slack de engenharia construindo com IA com um encontro quinzenal, ambos com tom de baixa pressão, onde compartilhar fracassos é tão bem-vindo quanto sucessos.
Relação com fornecedores como alavanca
A quinta frente é investir no relacionamento com vendors de IA.
A parceria com o Cursor, por exemplo, deu acesso antecipado ao recurso de team rules, que resolveu uma dor real: informar aos agentes qual plataforma de CI/CD a empresa usa, quais as boas práticas de Python e quais bibliotecas internas existem.
O Duolingo ativa betas com aval dos times jurídico e de segurança, devolve feedback aos fornecedores e aproveita as conversas para identificar onde está atrás das práticas do mercado, como aconteceu com evals.
Info: segundo Deitke, o Duolingo chegou a 100% de adoção de ferramentas de IA entre os engenheiros, depois de um período em torno de 80%, e relata redução do medo e da incerteza no uso diário.
O caso: bot de risco que aprova pull requests
O estudo de caso principal é o PR Risk Assessment, sistema que classifica mudanças de código em baixo, médio e alto risco (ou indeterminado, quando o PR estoura o limite de tokens).
Se a mudança cai no balde de baixo risco e cumpre outros critérios, um bot de auto-aprovação libera o merge sem revisor humano.
O mecanismo funciona como um check de CI: a cada push no pull request, dispara o pipeline de pontuação de risco, que envia título, passos de verificação, diff e um prompt de classificação a um LLM e recebe de volta o nível de risco com explicação.
PR push -> risk-scoring pipeline
inputs: título, verification steps, diff, prompt de risco
LLM -> { risk_tier: low|medium|high, explanation }
-> CI check + aprovação do bot (se low risk e critérios ok)Deitke credita à Meta Engineering (engineering.fb.com) a pioneira do conceito, o diff risk score, mas explica que a versão do Duolingo é bem mais enxuta: a engenharia da empresa tem cerca de 300 pessoas, não 300 mil. Os princípios centrais são os mesmos. Uma diferença de propósito: na Meta, o score serve para gatekeeping de mudanças arriscadas em horários mais seguros; no Duolingo, empresa que gosta de experimentar e entregar rápido, adicionar atrito não era aceitável, então o sistema foi pivotado para acelerar o lado de baixo risco.
O que entra em cada faixa de risco
A classificação cobre cenários concretos. Baixo risco inclui mudanças em arquivos Markdown, alterações de código pequenas e diretas e mudanças de metadados e configuração já pré-aprovadas pelos donos.
Médio risco cobre atualização de versões de API do app de aprendizado, componentes fundacionais como autenticação e logging, e features novas porém simples. Alto risco reúne permissões de usuário, infraestrutura em larga escala e funcionalidades centrais do app, além de casos específicos da empresa, como as animações do mascote Duo.
| Risco | Exemplos | Destino |
|---|---|---|
| Baixo | Markdown, mudanças pequenas, metadados pré-aprovados | Auto-aprovação pelo bot |
| Médio | Versões de API, auth, logging, features simples | Revisão humana |
| Alto | Permissões, infraestrutura, features centrais | Revisão humana obrigatória |
| Indeterminado | PR acima do limite de tokens | Revisão humana |
Arraste para o lado para ver toda a tabela.
Guardrails e resultados
As proteções incluem restringir o bot a code owners (tipicamente 5 ou 6 pessoas respondem por 80% das mudanças de um repo), inclusão e exclusão de diretórios (CI/CD financeiro bloqueado, CI/CD de testes liberado), desativação total para mudanças em recursos AWS e para repositórios com exigências de auditoria como SOX e ISO no Duolingo English Test, bloqueio durante o onboarding de novos engenheiros e notificações diárias opt-in, inspiradas no modelo ship, show, ask.
O bot também é opcional: Deitke estima que 20% a 30% das pessoas às vezes rejeitam a auto-aprovação porque querem a mentoria de uma revisão humana.
"Temos cerca de 200 pull requests por dia e, se minha conta estiver certa, talvez um ou dois sejam reversões de mudanças do bot de auto-aprovação", afirmou Sarah Deitke, engenheira de software do Duolingo, na QCon London.
Os resultados: a fatia de PRs mergeados pelo bot subiu de 0% para cerca de 10% em seis meses, considerando todos os PRs da organização, não só os elegíveis.
Na mesma janela, o tempo mediano de merge caiu de 18 para 12 horas, e o efeito cascata atingiu também PRs de médio e alto risco, porque a fila de revisão ficou menos carregada.
A pesquisa prévia de Deitke mostrou que cerca de 30% das mudanças já recebiam aprovação sem nenhum comentário, sinal de que a revisão humana ali era carimbo.
Sem incidentes relevantes atribuídos ao sistema, o projeto sobreviveu ao crivo mais duro: "provavelmente teria sido encerrado quase de imediato se tivéssemos visto uma taxa de defeitos significativa", disse ela.
Dica: o Duolingo mantém um canal de Slack onde qualquer pessoa reporta classificações erradas do bot. Cada report vira um item de eval e o prompt de risco é refinado de forma retrocompatível. Vale replicar: feedback estruturado do usuário como conjunto de avaliação.
O feedback loop que sustenta a autonomia
O canal proj-pr-risk-score recebe algumas mensagens por semana com correções: "este PR deveria ser alto risco porque mexe em serviços" ou "isto deveria ser auto-aprovado e não foi". Esses relatos viram um dataset de evals com palavras-chave extraídas das explicações do modelo, usado para refinar o prompt de risco ao longo do tempo. Na avaliação do Mercado de TI, o ponto mais relevante do caso é esse: a aceitação do sistema não veio do bot em si, mas do fato de engenheiros treinados confiarem o suficiente para apontar erros em vez de rejeitar a ferramenta, um padrão que dialoga com o que outras empresas descrevem ao levar agentes de IA para migrações guiadas por testes em produção e com a discussão sobre segurança e identidade em agentes de IA autônomos.
Além do code review, Deitke cita outros agentes criados por times do Duolingo: um bot de suporte interno para perguntas e respostas, um agente que corrige bugs simples do app e uso de IA na geração de conteúdo, incluindo o recurso Video Call with Lily. O roteiro de escala que ela propõe segue uma ordem: acesso, experimentação (hackathons), alfabetização (workshops), observabilidade (dashboards), guardrails com segurança e jurídico, e só então autonomia. Frameworks recentes como o Eve, da Vercel, para agentes de IA em produção mostram que essa arquitetura de agentes supervisionados está virando padrão de mercado.
O que o caso do duolingo sinaliza para quem lidera engenharia
Na avaliação do Mercado de TI, o recado do Duolingo é que o diferencial competitivo não é qual modelo ou IDE a empresa compra, mas se existe alguém responsável por transformar acesso em competência.
Para o profissional brasileiro, a lição prática é direta: times de plataforma e DevEx tendem a absorver essa função de "DevEx AI", e habilidades como avaliação de LLMs, desenho de guardrails e observabilidade de consumo de IA viram requisito, não diferencial.
Atenção: os números do Duolingo vêm de uma engenharia de cerca de 300 pessoas com forte cultura de experimentação. Reproduzir o modelo exige adaptar faixas de risco, guardrails e requisitos de auditoria ao seu contexto, não copiar a configuração.
Deitke fecha com quatro perguntas para quem quer automatizar: a organização construiu alfabetização em IA, e não apenas acesso? Os engenheiros se sentem no controle dos sistemas? O aprendizado é visível e incentivado? A IA parece empoderadora, e não imposta? Quem responder não a qualquer uma delas ainda não está pronto para entregar o merge a um bot.
Fonte: Infoq
