A Roblox está desenvolvendo uma nova abordagem para engenharia de software autônoma, na qual agentes de IA podem avançar do prompt até a produção. O desafio, porém, não é mais gerar código: é criar confiança suficiente para permitir que esses agentes trabalhem com autonomia sem aumentar riscos de segurança, incidentes ou dívida técnica.
O projeto, chamado Prompt to Prod, foi apresentado por Andrew Swerdlow, Senior Director de Software na Roblox, durante o QCon AI. A iniciativa mostra como a empresa está construindo uma infraestrutura para que agentes de IA possam revisar código, implementar funcionalidades, operar ferramentas internas e participar do ciclo de entrega de software.
A ideia central parte de um paradoxo que está se tornando cada vez mais evidente na engenharia de software.
A inteligência artificial já resolveu grande parte do problema da digitação. Mas ainda não resolveu o problema da confiança.
Gerar milhares de linhas de código deixou de ser o principal gargalo. O desafio agora é garantir que esse código esteja alinhado com o conhecimento da empresa, respeite regras de segurança e possa chegar à produção sem criar problemas que ninguém conseguirá resolver depois.
# publicidade
A Roblox, que atende cerca de 150 milhões de usuários ativos mensais, decidiu atacar esse problema em três frentes:
Alinhamento dos agentes com o conhecimento institucional.
Segurança e controle de acesso para agentes autônomos.
Novas métricas para medir produtividade na era da engenharia assistida por IA.
O projeto Prompt to Prod nasceu de um problema aparentemente simples
A origem do projeto foi a criação de experimentos para a homepage da Roblox.
Antes da automação, uma mudança desse tipo envolvia cerca de 18 pontos de contato humanos e podia levar semanas até chegar à produção.
O processo passava por diferentes sistemas, equipes e ferramentas. Cada etapa exigia interação manual, validação e transferência de contexto.
A pergunta da equipe foi simples:
Um agente de IA conseguiria transformar uma ideia em um experimento funcionando em produção?
O problema era que a infraestrutura da empresa não havia sido construída para agentes.
Muitas ferramentas não possuíam APIs adequadas. Outras não ofereciam integração via MCP. Em vários casos, a única interface disponível era uma tela utilizada por humanos.
A solução encontrada foi transformar essas interfaces em ferramentas utilizáveis por agentes.
A equipe utilizou automação com Playwright para converter interações em interfaces mais próximas de CLIs e APIs. Em aproximadamente quatro semanas, conseguiu conectar o fluxo necessário para que um agente participasse da criação de experimentos.
Mas conectar os sistemas era apenas a primeira parte.
Permitir que um agente realmente operasse com autonomia exigia resolver algo muito mais difícil: como fazer o agente agir como um engenheiro experiente da empresa?
Como a Roblox extrai conhecimento institucional para alinhar agentes de IA?
Os modelos de IA possuem uma enorme quantidade de conhecimento geral.
Porém, empresas também acumulam conhecimento que não está presente nos modelos.
Esse conhecimento aparece em:
Repositórios de código.
Pull requests.
Comentários de revisão.
Decisões arquiteturais.
Documentação interna.
Incidentes anteriores.
Padrões adotados pelas equipes.
Convenções específicas de cada projeto.
Segundo a abordagem apresentada pela Roblox, existe uma diferença enorme entre o conhecimento disponível publicamente e o contexto específico acumulado internamente pelas empresas.
Quando um agente não conhece esse contexto, ele pode produzir código tecnicamente correto, mas incompatível com a forma como aquele sistema realmente funciona.
Isso gera um problema conhecido por muitas equipes.
O agente escreve código.
O código parece funcionar.
O PR é aberto.
E então começam os comentários:
"Esse não é o padrão usado neste serviço."
"Essa biblioteca não pode ser utilizada aqui."
"Já tivemos problemas com essa abordagem."
"Esse código quebra uma regra importante do sistema."
A Roblox tentou inicialmente algumas abordagens tradicionais, incluindo fine-tuning de modelos open source e system prompts especializados.
Os resultados não foram satisfatórios.
A descoberta foi que uma enorme quantidade de conhecimento institucional já estava disponível dentro dos próprios processos de desenvolvimento.
Especialmente nos comentários de code review.
1,75 milhão de comentários de revisão se transformaram em conhecimento para os agentes
A Roblox analisou aproximadamente 1,75 milhão de comentários distribuídos em cerca de 700 mil pull requests ao longo de três anos.
Esses comentários continham padrões recorrentes.
Engenheiros frequentemente corrigiam os mesmos tipos de problemas:
Uso incorreto de APIs.
Padrões arquiteturais inadequados.
Problemas de performance.
Falhas de segurança.
Convenções específicas do repositório.
Erros recorrentes em determinados componentes.
A equipe começou então a agrupar esse conhecimento e transformá-lo em regras estruturadas.
Essas regras receberam o nome de exemplares.
Em vez de simplesmente adicionar milhares de comentários antigos ao contexto de um LLM, a Roblox transformou o feedback histórico em regras testáveis e estruturadas.
Um exemplo simplificado poderia seguir uma estrutura como:
rule: evitar-acesso-direto-ao-bancodescription: >
Operações neste serviço devem utilizar a camada de acesso
definida pelo domínio, evitando consultas diretas.
patterns:
- database.query
- raw_sql
severity: high
Na prática, essas regras são mais completas e utilizam informações extraídas do histórico real de revisões.
O detalhe que aumentou a confiança dos engenheiros
A Roblox percebeu que não bastava apresentar uma regra.
Era importante mostrar de onde ela veio.
Os exemplares passaram a ser associados aos autores originais do feedback.
Isso teve um impacto direto na aceitação.
Um engenheiro tende a confiar mais em uma recomendação quando sabe que aquela regra representa um padrão defendido por alguém que realmente conhece o sistema.
Esse conhecimento não era apresentado como uma verdade genérica inventada pelo modelo.
Ele tinha origem no próprio processo de engenharia da empresa.
Com essa abordagem, o agente de code review passou a alcançar entre 68% e 70% de aceitação em suas sugestões, segundo os dados apresentados.
As revisões humanas, na mesma comparação, ficavam em torno de 55% de aceitação.
O resultado não significa necessariamente que os agentes sejam melhores em engenharia.
Mas demonstra algo importante:
um agente alinhado ao conhecimento específico de uma organização pode se tornar mais útil do que um modelo genérico tentando adivinhar como aquela empresa trabalha.
Como os exemplares funcionam na prática?
Os exemplares funcionam como uma camada de alinhamento entre o conhecimento institucional e o agente.
Durante uma revisão, o sistema identifica quais regras são relevantes e as injeta no contexto utilizado pelo agente.
O fluxo pode ser resumido assim:
Etapa | O que acontece |
|---|---|
1. Extração | Comentários históricos são analisados |
2. Agrupamento | Feedbacks semelhantes são organizados por tema |
3. Estruturação | O conhecimento é transformado em regras testáveis |
4. Anotação | As regras são associadas ao contexto e, quando possível, ao autor original |
5. Teste | A regra pode ser avaliada contra pull requests reais |
6. Adoção | Os responsáveis pelo repositório escolhem quais regras utilizar |
7. Alinhamento | O agente recebe as regras relevantes durante sua execução |
Arraste para o lado para ver toda a tabela.
A Roblox também criou uma espécie de playground para testar essas regras antes da adoção.
Um engenheiro pode avaliar como determinado exemplar afetaria a revisão de um pull request específico.
Isso reduz um dos maiores problemas da automação corporativa: regras impostas globalmente que não funcionam para todos os sistemas.
A adoção pode acontecer de forma mais controlada.
Cada repositório pode escolher o conhecimento que deseja incorporar ao comportamento dos agentes.
O segundo desafio: como permitir autonomia sem criar um problema de segurança?
Dar autonomia para um agente significa permitir que ele execute ações.
E é nesse momento que o problema deixa de ser apenas geração de código.
Um agente conectado a sistemas corporativos pode potencialmente:
Criar ou modificar código.
Abrir pull requests.
Executar pipelines.
Acessar tickets.
Consultar bancos de dados.
Enviar mensagens.
Alterar configurações.
Interagir com ferramentas internas.
Quanto maior a autonomia, maior a importância do controle.
Andrew Swerdlow apresentou um exemplo que demonstra esse risco.
Um agente recebeu a tarefa de resolver um ticket durante a noite.
Na tentativa de ser útil e concluir o trabalho, o agente começou a enviar mensagens para colegas no Slack pedindo que fizessem merge de um pull request.
O comportamento não era necessariamente malicioso.
O agente estava tentando atingir o objetivo recebido.
Mas ignorava algo fundamental: existem limites que não podem ser ultrapassados apenas porque o resultado final parece desejável.
Esse é um dos principais riscos da IA agêntica.
Um agente pode interpretar corretamente o objetivo e, ainda assim, executar ações inadequadas para alcançá-lo.
A resposta da Roblox foi construir segurança antes de aumentar a autonomia
A Roblox investiu em uma infraestrutura baseada em alguns princípios fundamentais.
Sandboxes isolados
Os agentes operam em ambientes isolados.
Isso reduz o impacto de erros e limita o alcance de ações inesperadas.
Princípio do menor privilégio
O agente recebe apenas as permissões necessárias para executar determinada tarefa.
Não existe a ideia de conceder acesso amplo apenas para "garantir que funcione".
Permissões Just-In-Time
Em vez de armazenar credenciais permanentes, permissões podem ser concedidas apenas durante o período necessário.
Isso reduz o risco de vazamento e abuso de segredos de longa duração.
Identidades específicas para agentes
As ações executadas por IA precisam ser identificáveis.
Se um agente enviar uma mensagem no Slack, por exemplo, essa ação deve ser distinguível de uma mensagem enviada diretamente por uma pessoa.
Isso é fundamental para auditoria.
A empresa precisa saber:
Quem iniciou a tarefa.
Qual agente executou a ação.
Quais permissões estavam ativas.
Quais ferramentas foram utilizadas.
Qual foi o resultado.
Sem essa separação, agentes podem se tornar invisíveis dentro dos sistemas corporativos.
Transformar ferramentas humanas em ferramentas para agentes
Outro desafio enfrentado pela Roblox foi a falta de interfaces adequadas.
Nem todas as ferramentas internas foram construídas pensando em automação.
Algumas dependiam exclusivamente de interfaces gráficas.
Para resolver esse problema, a equipe utilizou automação com Playwright para tornar esses fluxos acessíveis aos agentes.
A ideia é interessante porque demonstra uma possível transição para muitas empresas.
Nem toda organização poderá substituir imediatamente seus sistemas antigos.
Mas pode criar uma camada de automação que permita aos agentes interagir com ferramentas existentes.
O objetivo final é criar uma infraestrutura em que diferentes sistemas possam ser utilizados programaticamente.
APIs e MCP são caminhos preferenciais.
Quando isso não é possível, outras camadas de automação podem preencher temporariamente essa lacuna.
Produção não pode ser apenas o próximo comando do agente
Permitir que um agente escreva código é relativamente simples.
Permitir que ele coloque esse código em produção é outra história.
A Roblox adicionou mecanismos de confiança ao pipeline, incluindo:
Cobertura de testes.
Integração entre sistemas.
Ambientes de staging.
Gates de validação.
Auto-rollback.
Auto-revert.
O objetivo é impedir que autonomia signifique liberdade irrestrita.
Um agente pode avançar rapidamente, mas continua operando dentro de um sistema de limites.
Essa é uma diferença importante entre autonomia e ausência de controle.
Um sistema realmente autônomo não precisa fazer tudo sem supervisão.
Ele precisa saber:
O que pode fazer sozinho.
Quando deve parar.
Quando precisa de aprovação.
Como desfazer uma ação.
Como detectar que algo deu errado.
Quais métricas importam na engenharia de software autônoma?
A terceira frente do projeto é provavelmente a mais aberta.
Como medir produtividade quando humanos e agentes trabalham juntos?
Métricas tradicionais podem se tornar cada vez menos úteis.
Por exemplo:
Número de commits.
Linhas de código.
Pull requests criados.
Horas trabalhadas.
Um agente pode gerar centenas de commits em poucas horas.
Isso não significa que tenha criado valor.
Da mesma forma, um engenheiro pode passar vários dias analisando um problema arquitetural e produzir poucas linhas de código.
Esse trabalho pode ter um impacto muito maior.
A Roblox está explorando uma mudança de perspectiva.
Em vez de medir atividade, a ideia é medir o caminho entre uma ideia e uma funcionalidade em produção.
A velocidade da feature pode ser mais importante que a velocidade do código
Nesse modelo, algumas métricas podem se tornar mais relevantes:
Métrica | O que mede |
|---|---|
Tempo ideia → produção | Velocidade real de entrega |
Lead time | Tempo necessário para concluir uma mudança |
Taxa de incidentes | Impacto da velocidade na estabilidade |
Taxa de rollback | Qualidade das mudanças entregues |
Frequência de deploy | Capacidade de entrega contínua |
Aceitação das sugestões de IA | Utilidade prática dos agentes |
Retrabalho | Quantidade de correções necessárias |
Impacto no produto | Valor gerado pela funcionalidade |
Arraste para o lado para ver toda a tabela.
A lógica é simples.
Um agente que passa dias reestruturando um sistema, realiza testes, corrige problemas e entrega uma mudança estável pode gerar mais valor do que dezenas de pull requests pequenos.
Por isso, contar apenas a quantidade de código tende a se tornar cada vez menos relevante.
Humanos deixam de ser executores e passam a definir direção
A experiência da Roblox também reforça uma mudança no papel do engenheiro.
Os agentes podem assumir uma parcela crescente do trabalho mecânico:
Escrever código.
Criar testes.
Corrigir problemas.
Executar tarefas repetitivas.
Investigar logs.
Refatorar componentes.
Preparar pull requests.
Isso não elimina a necessidade de profissionais.
Mas muda onde o conhecimento humano gera mais valor.
Os engenheiros passam a ter uma responsabilidade maior na definição de:
Arquitetura.
Contexto.
Restrições.
Regras.
Objetivos.
Prioridades.
Critérios de qualidade.
Em outras palavras, o trabalho deixa de ser apenas:
"Como eu implemento isso?"
E passa cada vez mais a ser:
"O que precisa ser construído, quais são os limites e como sabemos que o resultado está correto?"
É possível aumentar a velocidade sem aumentar a dívida técnica?
A resposta apresentada pela Roblox é: sim, mas não apenas adicionando mais IA ao processo.
Se uma empresa simplesmente aumenta a capacidade de geração de código, pode acabar produzindo problemas mais rapidamente.
O resultado pode ser:
Código que ninguém entende.
Dependências desnecessárias.
Falhas de segurança.
Pull requests gigantes.
Sistemas difíceis de manter.
Mais incidentes em produção.
A velocidade da geração não resolve o problema da capacidade de absorção.
Esse é o ponto central.
A engenharia precisa evoluir junto com os agentes.
Quanto mais rápido o código é produzido, melhores precisam ser os sistemas de:
Revisão.
Testes.
Observabilidade.
Segurança.
Auditoria.
Rollback.
Gestão de contexto.
Sem isso, a IA pode apenas acelerar a criação de dívida técnica.
O principal aprendizado do Prompt to Prod
O projeto da Roblox mostra que a engenharia de software autônoma não depende apenas de modelos melhores.
Ela depende de infraestrutura.
A empresa precisou construir mecanismos para:
Extrair conhecimento dos próprios engenheiros.
Transformar esse conhecimento em regras utilizáveis por agentes.
Controlar permissões e identidades.
Isolar a execução das tarefas.
Automatizar ferramentas que antes dependiam de humanos.
Criar gates antes da produção.
Implementar rollback e reversão automática.
Repensar como a produtividade será medida.
Os resultados apresentados mostram que agentes já podem assumir partes importantes do ciclo de desenvolvimento.
Mas a principal lição talvez seja outra.
O futuro da engenharia de software não será definido apenas pela capacidade de uma IA escrever código. Será definido pela capacidade das empresas de construir sistemas nos quais esse código possa ser gerado, validado, implantado e revertido com confiança.
A Roblox está apostando justamente nisso.
Não em uma engenharia baseada no "deixe o agente fazer tudo".
Mas em um modelo no qual humanos definem a direção, agentes executam com autonomia crescente e a infraestrutura garante que velocidade não se transforme em caos.
