Quando escrever código fica mais rápido, o que muda no trabalho de engenharia?

Em 4 de novembro, eu e Marcelo fizemos no Serena Cafeteria, em São Paulo, um warmup para o OpenAI DevDay Exchange. A proposta era preparar a comunidade para o encontro. A conversa acabou mostrando uma tensão que já aparece no trabalho: a IA reduz o esforço de implementar, mas ainda precisamos decidir o que testar, o que aceitar e o que manter de pé.

O encontro reuniu Rodrigo Terron, da NewHack, e Marcelo Okano, da OKN Technology. A Open Class foi seguida pela Community Night. A edição aconteceu em colaboração com o iMasters e teve patrocínio de Agora, FalaBoss, Nuvia e Notion.

Testar mais alternativas muda a decisão

No Serena, contei uma conversa que tive com um profissional de engenharia durante uma visita à Netflix. Ele descreveu uma mudança no jeito de testar: antes, a equipe prototipava algumas alternativas, escolhia uma para implementar e só voltava às outras se a primeira falhasse. No exemplo que ele compartilhou comigo, passou a ser possível implementar e testar as quatro alternativas em paralelo.

O ganho interessante está no que a equipe consegue descobrir. Quando implementar uma opção custa caro, é comum decidir cedo demais com base na melhor hipótese disponível. Se for possível comparar mais opções, a decisão pode se apoiar em resultados observados. Isso também exige definir de antemão o que seria uma melhora e cuidar para que os testes produzam resultados comparáveis.

O detalhe que mais me interessou é que testar mais alternativas também exige mais energia. Se cada versão muda várias coisas ao mesmo tempo, fica difícil saber por que uma funcionou. E se ninguém sabe qual resultado decidiria a escolha, a equipe termina com quatro implementações e a mesma dúvida. A velocidade abre espaço para experimentar. A qualidade da pergunta define se isso vira aprendizado.

Uma aplicação prática é escolher uma decisão que a equipe normalmente toma por intuição. Antes de pedir ao agente que implemente variantes, registre o comportamento que se quer melhorar e como medi-lo. Se duas versões funcionarem igualmente bem, o custo de manter cada uma pode orientar a escolha.

O Marcelo trouxe o outro lado dessa aceleração. Ele contou que já chegou a uma conversa comercial com boa parte de um projeto pronta, antes de o cliente aprovar a proposta. O exemplo levanta uma questão para quem vende software ou serviços: uma implementação rápida pode tornar o projeto viável, mas ainda resta entender o que o cliente precisa, ajustar o que foi feito e assumir a entrega.

Especificar e revisar também é trabalho de engenharia

Okano descreveu uma forma de trabalhar em que o desenvolvedor dedica mais tempo a discutir a especificação com a IA, ler o que foi proposto e aprovar o caminho antes de delegar a implementação. Na conversa, ele relacionou essa mudança a fundamentos de engenharia e à capacidade de entender o problema que se está resolvendo.

Na conversa, eu retomei um problema que já tinha mostrado em um workshop: começar a pedir alterações antes de esclarecer o que se quer construir. A primeira versão sai rápido, mas aí se pede para mudar, inverter e refazer. A especificação ajuda a trazer a dúvida para um momento em que ainda é barato mudar de ideia.

Uma especificação útil dá ao agente condições de acertar e à equipe condições de perceber quando ele erra. Para uma alteração pequena, pode bastar dizer o que muda, o que precisa continuar funcionando e qual teste demonstra que a tarefa terminou. Um pedido como melhorar o cadastro ganha precisão quando a equipe aponta qual etapa gera abandono, quais campos precisam ser preservados e o que deve acontecer se a gravação falhar.

O mesmo cuidado vale na revisão. Um agente pode ajudar a localizar um problema ou levantar hipóteses sobre um sistema, como apareceu na conversa. A equipe ainda precisa conferir se a explicação bate com os registros, se a correção cobre o caso e se pode ser revertida quando necessário.

Quanto custa chegar a uma mudança aceita?

O custo apareceu quando falamos de tokens e de retrabalho. Duas equipes podem entregar a mesma funcionalidade consumindo quantidades muito diferentes de recursos. E a conta do modelo é só parte do custo: também entram o tempo de quem formula o pedido, revisa o código, roda os testes e corrige o que escapou.

Se eu fosse medir o resultado em uma equipe, começaria por uma tarefa que já acontece toda semana, como corrigir um erro recorrente. Compararia o tempo e os recursos até a mudança passar em revisão e teste. Se a primeira resposta ficou pronta em minutos, mas a equipe levou uma tarde para entender a alteração, ainda há trabalho para melhorar o fluxo.

Como quem está começando ganha experiência?

Uma pergunta do público trouxe a tensão que faltava: se agentes assumem tarefas que antes eram delegadas a profissionais juniores, onde essas pessoas vão aprender a tomar decisões de engenharia? Eu sugeri começar com projetos concretos e passar pela experiência de colocá-los para rodar. É nesse momento que aparecem problemas que um exercício isolado não mostra, da configuração do ambiente ao comportamento da aplicação nas mãos de alguém.

Para equipes que contratam e formam pessoas, isso abre espaço para redesenhar as primeiras tarefas. Em uma alteração de baixo risco, um profissional júnior pode usar o agente para implementar e depois explicar, com apoio de alguém mais experiente, o que mudou, como testou e como investigaria uma falha. Assim, o trabalho entregue também vira uma oportunidade de praticar revisão e diagnóstico.

A oportunidade aparece na operação

Também trouxe um contraste que ajuda a sair da discussão entre desenvolvedores. Basta olhar para negócios em que uma parte da operação ainda está no papel, em sistemas difíceis de usar ou na cabeça de quem atende. Para quem está ali, uma solução de IA só começa a fazer diferença quando entra no fluxo de trabalho sem criar mais uma etapa para a equipe administrar.

Para uma equipe que está começando, o primeiro teste pode ser acompanhar uma tarefa real, da entrada do pedido à entrega. Onde alguém copia informação? Onde espera por aprovação? O que acontece quando o caso foge do padrão? Essas respostas ajudam a decidir se vale construir algo, ajustar um fluxo existente ou simplificar uma etapa antes de automatizá-la.

Saí do warmup com uma pergunta para levar ao DevDay Exchange: qual decisão conseguimos tomar melhor agora que implementar ficou mais rápido? Pode ser escolher entre alternativas de produto, revisar uma mudança com menos retrabalho ou decidir se uma tarefa merece ser automatizada. O ganho aparece quando a equipe consegue mostrar o que aprendeu e usar isso na próxima decisão.