Pioneiro de DevOps alerta: a adoção de agentes de IA exige mudanças em nível de sistema, não apenas ferramentas

Não corrija mais o código gerado pelo Agent; corrija o sistema que gera esse código.

Autor e fonte do artigo: InfoQ

Se um desenvolvedor não consegue usar bem o Agent, o problema pode não estar no desenvolvedor, mas sim no fato de que a empresa ainda não preparou um sistema funcional para o Agent.

Muitas empresas chamam isso de transformação em IA, mas ainda se limitam a comprar ferramentas como Cursor e Claude Code para desenvolvedores, realizar algumas sessões de treinamento e deixar que todos descubram por conta própria. Se, no final, os Agentes não apresentarem bons resultados, a culpa recai sobre os usuários.

Mas Patrick Debois, o criador do termo DevOps, acredita: “Os desenvolvedores precisam fazer uma importante mudança de mentalidade: quando o agente não concluir a tarefa conforme esperado, não modifique o código gerado por ele, mas melhore todo o sistema, e não apenas o prompt.”

Para Debois, essa é uma transformação inevitável à medida que a engenharia de software passa de sistemas determinísticos para sistemas e fluxos de trabalho não determinísticos e probabilísticos. Ela envolve não apenas tecnologia, mas também reestrutura a maneira como desenvolvedores, equipes e toda a organização trabalham. No entanto, essa mudança não pode ser realizada por um único engenheiro nem limitada ao nível de uma única equipe. Assim como o DevOps, só se torna real quando escalada e implementada em larga escala.

O núcleo da questão não é apenas se os desenvolvedores saberão usar Agent, mas se a empresa poderá reorganizar equipes, plataformas e formas de colaboração em torno do Agent.

Os pontos principais são os seguintes:

• Não corrija mais o código gerado pelo Agent; corrija o sistema que gera esse código.
• Se ainda houver alguém na sua equipe usando esse método amador de “YOLO (corre primeiro, depois vê)” para fazer vibe coding, você deve interromper imediatamente. Práticas de engenharia são essenciais não apenas para você manter o sistema, mas também para que o Agente continue melhorando continuamente.
• A fábrica escura pode não ser totalmente escura, mas manter um pouco de luz fraca (dim factory), o que significa que você precisa decidir o nível de risco para cada função, pois nem todas as funções são adequadas para autonomia total.
• A pessoa que você está procurando é aquela que consegue usar AI de forma extrema, possui sólida base em engenharia e está disposta a compartilhar e colaborar.
• Sua vantagem competitiva é capturar o conhecimento acumulado, aqueles contextos de negócios que você agora injeta no skill, no Context e até nas restrições do Harness.

Em 2009, muitas pessoas me disseram que a ideia de entrega contínua era loucura.

Nota do tradutor: Em 2009, a indústria adotava amplamente o modelo de lançamento concentrado de grandes versões a cada vários meses, sendo comumente aceito que quanto mais frequentes as publicações, maior o risco. Além disso, havia barreiras rígidas entre desenvolvimento e operações, infraestruturas automatizadas como contêineres e nuvem ainda não estavam maduras, e faltavam ferramentas padronizadas de pipeline. Ao mesmo tempo, os mecanismos tradicionais de teste e aprovação de alterações buscavam eliminar tantos defeitos quanto possível antes do lançamento, enquanto a entrega contínua introduziu uma abordagem de alta frequência, incremental e sempre pronta para lançamento, desafiando a percepção convencional sobre riscos e controle de processos no lançamento de software, tornando-a, para a maioria das empresas, algo quase impossível e extremamente louco.

E agora, a Dark Factory enfrentou exatamente o mesmo obstáculo.

Translator's note: The Dark Factory refers to an AI-driven autonomous software production model, where humans input only the SPEC, and AI autonomously completes coding, testing, and deployment without requiring manual line-by-line code review, differing from traditional software factories that still require substantial engineer involvement in the process.

Ouço repetidamente a mesma frase em diversos contextos: “Isso não funciona aqui.” Mas a mensagem real por trás dessa frase não é que a tecnologia não funciona, e sim “não estamos prontos”. Eles não querem evitar implementar isso; é que a estrutura atual da organização ainda não suporta esse modelo.

Muitas pessoas estão falando agora sobre como otimizar Agentes com ciclos e como montar Harnesses, o que é ótimo. Mas quero dizer que, em última análise, todos alcançaremos esse nível técnico, e um dia eles se tornarão algum tipo de produto padrão, até mesmo oferecidos como serviço por algum laboratório de ponta. Nesse dia, não haverá mais barreiras tecnológicas. A verdadeira diferenciação estará em como sua organização reestruturará a forma de colaboração em torno disso.

Então, suponho que todos nós estamos nos direcionando para a fábrica escura. O que observei na Tessl e em outras empresas é que, quando as pessoas começam a adotar essas tecnologias, a dinâmica de colaboração muda completamente. Se vocês estão familiarizados com a Lei de Conway, sabem que existe uma relação de moldagem mútua entre a forma como organizamos e as ferramentas que usamos — como você organiza as pessoas, assim será o sistema que produzirá. Mas hoje não quero falar sobre como tornar seu Agente melhor; quero falar sobre como isso altera sua dinâmica de equipe, sua plataforma e toda a sua organização.

Suponho que a maioria de vocês aqui trabalhe em alguma equipe, e não sozinhos; trabalhar em equipe é completamente diferente de digitar sozinho para o Claude Code.

Agora todos gostam de dizer que os desenvolvedores acabarão se tornando maestros, organizadores de Agentes. Acho que essa afirmação está correta; essa é realmente a trajetória em que estamos. Estamos nos tornando cada vez mais gestores de Agentes, precisando lidar com os relacionamentos entre nós e os Agentes.

Mas o problema é que ouço muitos desenvolvedores dizerem em particular: não entramos nessa área para fazer isso; não imaginávamos que passaríamos tanto tempo otimizando prompts e escrevendo especificações melhores. Somos engenheiros, trabalhamos com tecnologia, e isso nos causa uma sensação de conflito identitário, levando-nos a nos perguntar constantemente: esse é realmente o papel que quero desempenhar?

Posteriormente, surgiu o conceito de “engenharia de contexto”, que acabou dando aos desenvolvedores uma justificativa. Ele afirma que não se trata apenas de chamar prompts; você também precisa testar, avaliar, distribuir e otimizar prompts, o que realmente tem um toque de engenharia. Mas, honestamente, muitos desenvolvedores ainda sentem que lidar apenas com prompts e specs é vazio, como se tivessem se transformado de engenheiros em “administradores de prompts”.

Mas observei um ponto de virada muito interessante na prática. Quando começamos a introduzir Harness, ciclos e até levar toda a organização a um nível maior de autonomia, um novo caminho técnico se abriu. De repente, os desenvolvedores precisavam criar ferramentas para os Agentes — e isso imediatamente reacendeu o entusiasmo de muitas pessoas. Desenvolvedores que antes pensavam “isso não é coisa para mim” de repente se animaram. Eles disseram: sim, podemos fazer isso! Nós temos esse conhecimento! Podemos usar programação para tornar esse sistema melhor. Então é interessante: enquanto falávamos continuamente sobre “abstrair, abstrair, abstrair”, o senso de “artesanato” ressurgiu em outro lugar, criando novo espaço para trabalhos de engenharia mais técnicos.

Muitas pessoas me perguntam: como lidar com aqueles que são céticos? Minha resposta é sempre a mesma: essas pessoas são na verdade seus tesouros. Elas possuem uma grande quantidade de conhecimento implícito e julgamento, e você precisa incorporar tudo isso no Agente. Você pode dizer a elas: “Por favor, traga todo o seu conhecimento e seu espírito crítico”, o que tornará o Agente e o Harness melhores. Se encontrar alguém resistente que se queixa diariamente: “O código gerado por isso é de péssima qualidade”, use essa pessoa como combustível — transforme essa raiva e ceticismo em impulso para aprimorar o sistema.

Agora, gostaria de dar uma sugestão aos desenvolvedores da empresa: faça uma grande mudança de mentalidade — pare de corrigir o código gerado pelo Agente e comece a corrigir o sistema que produz esse código. Como alguém disse há alguns anos: “Não construa aquilo; construa o que constrói aquilo.” Estamos agora nesse nível de abstração, criando “o que constrói coisas” por meio de Contexto, Harness e ciclos. Muitas pessoas ainda estão presas no estágio de “Human in the Loop”, preenchimento automático e ajuste de prompts — precisam refletir sobre como elevar-se para uma perspectiva de sistema.

O que realmente precisamos fazer é minimizar a intervenção humana por meio de boas práticas de engenharia. No início, todos achavam que “vibe coding” era incrível: lançar um prompt, obter um resultado e seguir em frente, não importa o quê. Mas agora fica cada vez mais claro que não estamos apenas dando instruções ao agente por meio de prompts; na verdade, estamos dizendo: “Por favor, escreva junto com os testes”, “Por favor, atualize a documentação”, “Por favor, siga as diretrizes de código”. Tudo o que costumávamos dizer a um bom engenheiro, agora estamos dizendo exatamente da mesma forma ao agente. Se ainda houver alguém na sua equipe usando esse método “YOLO (funciona, então tá bom)” de vibe coding, você deve interromper imediatamente. As práticas de engenharia são cruciais não apenas para a manutenção do seu sistema, mas também para o aprimoramento contínuo do próprio agente.

Comecei a observar, em algumas equipes mais avançadas, um novo ritual: elas ainda realizam reuniões de planejamento e retrospectivas, mas o conteúdo das discussões mudou completamente. Nas retrospectivas, em vez de dizerem “o que deu errado no código?”, passaram a perguntar: “o que deu errado no sistema?”

Também observei uma divisão interessante na reunião de planejamento. As tarefas definidas de forma muito clara e com escopo suficientemente específico podem ser diretamente atribuídas ao Agente, pois o Harness está ficando cada vez melhor e consegue processar tarefas bem definidas. Já as questões com fronteiras ambíguas, que exigem discussão, permanecem com os humanos. Assim, surgiu uma divisão natural na reunião de planejamento: esses cartões seguem diretamente pela linha de produção do Agente, enquanto aqueles cartões discutimos nós.

Desenvolvedores geralmente passam por um ciclo de aprendizado: primeiro aprendem Prompt, depois melhoram o SPEC, em seguida abordam Context, Harness e iterações, e toda a indústria está subindo por esse ciclo. Mas o que o líder da equipe pode fazer é definir o ritmo e as restrições para esse processo, por exemplo, dizer a eles: “Parem de ajustar o Prompt e tornem o Context reutilizável.” “Ótimo, essa etapa foi concluída; vamos avançar para a próxima.” O valor do líder da equipe está justamente em estabelecer esse ritmo; se você simplesmente disser “descubra sozinho”, isso não funcionará.

Há também um efeito cascata: assim que a produtividade da sua equipe começar a disparar, as equipes a jusante, como as de GTM (Go to Market), não conseguirão acompanhar, e até os usuários poderão ficar para trás. Por isso, você precisa usar automação para ajudá-los — seu framework não pode parar na etapa de codificação, mas precisa se estender até eles. O mesmo vale para as entradas de requisitos a montante: se os requisitos não chegarem rápido o suficiente, a equipe ficará travada, e essas etapas também precisam ser integradas a esse novo fluxo de trabalho.

Há muitos indicadores no mercado hoje, como gastos com tokens e outros. Mas comecei a acreditar cada vez mais em dois indicadores reais que medem a produtividade. O primeiro: conte quantas intervenções humanas ainda são necessárias para fazer um Agente realizar corretamente uma tarefa. Esse número deve diminuir continuamente. Quanto melhor for seu Harness, melhor seu Contexto e mais clara for sua orientação, menor será esse número. O segundo indicador é o efeito multiplicador que ocorre quando você passa de um modelo individual para um sistema compartilhado. Quando você conserta algo em um lugar, todos se beneficiam. Não se trata de uma pessoa se tornar dez vezes mais eficiente, mas sim de uma única otimização no sistema de Agentes gerar um efeito multiplicador em todos.

Você pode começar em um repositório ou dentro de uma pequena equipe, compartilhando o Context e melhorando juntos o Harness. Mas o que você realmente deseja fazer é expandir esse efeito para toda a organização. Nesse momento, precisamos falar sobre equipes de plataforma.

A equipe da plataforma é tipicamente uma organização compartilhada e, atualmente, pode estar focada em infraestrutura, serviços em nuvem, gateway MCP e coisas semelhantes, sem prestar muita atenção ao componente de Agent. No entanto, uma série de novos elementos estão surgindo e precisam ser adotados por eles, como um repositório de habilidades (não se pode permitir que cada um invente seu próprio conjunto de habilidades em seu canto), um sistema de avaliação de Contexto (este Contexto realmente tem utilidade? É possível quantificá-lo?) e mecanismos de segurança e gerenciamento de identidade específicos para agents de codificação (com qual identidade o Agent envia o código? Quais são os limites de permissão?). Portanto, a equipe da plataforma precisa de apoio para evoluir e assumir esse novo papel central.

Isso é difícil; você precisa de um owner claro para impulsionar. Mas quem deveria ser? A equipe da plataforma? A equipe de experiência do desenvolvedor? A primeira geralmente não lida com coisas de nível de desenvolvimento, enquanto a segunda não lida muito com infraestrutura, então é necessário algum tipo de fusão — mas essa fusão não acontecerá automaticamente. Você precisa garantir que haja uma pessoa responsável por impulsionar esse trabalho centralizado; caso contrário, sua equipe apenas se limitará a suas próprias áreas, e não haverá uma “Paved Road”.

Por que cada equipe precisa inventar seu próprio método de integração com o sistema de autenticação? Isso é um componente compartilhado e deveria ser colocado no registro. Por que cada um monta seu próprio Harness? Se todos usarmos o mesmo linter e as mesmas ferramentas de varredura de segurança, isso se torna um componente reutilizável. Acho que isso seguirá o mesmo caminho da implantação da infraestrutura em nuvem, gradualmente se concentrando no registro da plataforma.

Mas o problema é que, se qualquer pessoa puder simplesmente adicionar coisas a esse repositório central, ele crescerá rapidamente de forma descontrolada. Por exemplo, se alguém publicar uma skill, quem a manterá? Outra pessoa pode fazer um fork de uma skill semelhante — então, qual delas eu devo escolher? Portanto, é necessário que alguém tenha propriedade clara de cada área, garantindo que o componente seja testável e modular, permitindo que outros ampliem a parte de varredura de segurança no Context ou no Harness. Você precisa fazer isso de forma centralizada, e não simplesmente passar de pessoa para pessoa dentro da organização.

Construir consenso é difícil. Não é tão famoso quanto a disputa entre tabs e espaços, mas às vezes parece algo parecido. Se você pedir a dois times de desenvolvedores que cheguem a um consenso sobre como trabalhar, será necessário muito comunicação e mediação. Por isso, no final, é provável que você não tenha apenas uma estrada pavimentada, mas três ou quatro, das quais eles possam escolher. Se eles quiserem criar seu próprio sistema, podem fazer isso, mas será com seu próprio orçamento. A via mantida centralmente é a “rota fácil”, usada para atrair todos a segui-la.

Se as pessoas usarem cegamente essas capacidades compartilhadas, você precisa fazer com que vejam o custo. Desde que você torne os gastos visíveis, elas naturalmente buscarão otimizá-los. É responsabilidade da equipe da plataforma tornar os gastos transparentes: quanto foi gasto? Em que medida ajudou? Se eu puder reduzir o número de iterações do Agente, isso será uma otimização. Mas se eu não conseguir ver essa métrica e só vir o resultado final, não terei como agir — a visualização é a base de toda otimização.

Então, minha tese central é: devemos passar de desenvolvedores trabalhando isoladamente para um nível de equipe com contexto e componentes compartilhados, e finalmente para um “sistema de jogo multiplayer” dentro de toda a organização. O efeito alavancagem explodirá lá, pois teremos uma roda de impulso em que as melhorias podem irradiar simultaneamente em múltiplas direções.

No nível acima, como o VP de Engenharia pensa sobre isso? Consigo prever aproximadamente a história que ocorrerá na sua organização: um hackathon ou uma sessão de almoço compartilhada, apresentação de casos de sucesso, criação de um canal compartilhado no Slack, implementação de um programa de campeões. São todas abordagens genéricas de transformação. A transformação Agile fez isso, o DevOps também fez — nada de novo.

Por outro lado, também sabemos que a estratégia de “emitir licenças, oferecer treinamentos, permitir que todos atuem livremente e deixar mil flores florescerem” nunca funcionou. O resultado de mil flores geralmente é mil ervas daninhas: florescimento abundante, mas nenhuma delas produz frutos. Por isso, defendo que, na organização, seja feita uma autorização clara para que os líderes de equipe e a equipe de plataforma assumam essa tarefa. Não é algo que pode ser feito por um único superindivíduo; é necessário que alguém seja formalmente autorizado a impulsioná-la.

Pedir ajuda também é uma dor de cabeça. Os títulos de cargo atuais são uma bagunça: engenheiro de produto de IA, engenheiro forward deployed, engenheiro agentic, engenheiro de IA... Esses termos na verdade não têm significado real. Você não pode julgar a maturidade de alguém pelo título, pois toda a indústria ainda é imatura. No entanto, ao publicar uma vaga, esses termos realmente transmitem alguns sinais e atraem candidatos com intenções específicas, mas por si só não indicam que a pessoa realmente possua as habilidades correspondentes. Já ouvi histórias ainda mais absurdas: alguns candidatos usam IA para fornecer respostas em tempo real nos ouvidos durante entrevistas — quando o entrevistador faz uma pergunta, uma sugestão da IA vem pelos AirPods.

Então tenho ouvido cada vez mais empresas adotarem esse tipo de processo seletivo. Na primeira etapa, dão um exercício para que os candidatos usem IA livremente, explorando ao máximo. Se a IA conseguir ajudá-los a resolver o problema, isso justamente demonstra que eles são proficientes em utilizar IA. Na segunda etapa, pedem que eles revisem sua própria solução e expliquem: “Por que você escolheu essa abordagem? Como você validou que está correta?”. Nesse momento, você está testando sua capacidade de avaliação e julgamento técnico. A primeira parte avalia a habilidade de usar IA; a segunda, a base técnica. Por fim, observe como eles colaboram: estão dispostos a compartilhar? São abertos ou preferem trabalhar sozinhos? Algumas pessoas têm ótima técnica, mas querem controlar tudo sozinhas — nessa era dos Agentes, essas pessoas acabam se tornando gargalos.

A pessoa que você está procurando é aquela que combina o uso extremo de IA, uma sólida base em engenharia e a disposição para compartilhar e colaborar. Não se trata de alguém que apenas estudou ML ou IA, nem de um especialista em decodificação, mas sim de uma mistura dessas qualidades. É provável que você não encontre alguém que preencha todos os três critérios perfeitamente — e isso não importa. Por exemplo, um candidato pode ser excepcional em um aspecto, mas precisar de orientação em outro. Além disso, não misture essas habilidades rotulando-as como “iniciante” ou “avançado”; são dimensões distintas de habilidades: uma pessoa pode ter capacidade de utilização de IA “avançada”, mas disposição para colaboração “iniciante”.

O VP do departamento de engenharia ainda precisa prestar contas. Compramos tantas licenças — conseguimos provar o retorno sobre o investimento? A entrega ficou mais rápida? Talvez haja promessas, mas é difícil comprovar. A qualidade melhorou? Também é difícil afirmar. Mas voltando aos dois indicadores que mencionei anteriormente, você pode mostrar quantas interações foram reduzidas, quantas melhorias foram feitas e em quanto aumentou a taxa de reutilização. Isso é muito mais fácil e mais convincente do que tentar comparar a produtividade de codificação “com e sem Agent”.

Então, quando alguém se queixa de que o Agente está gastando muito e quer limitar o orçamento, sua reação instintiva não deveria ser “vamos cortar todos os gastos”, mas sim “como podemos otimizar os gastos”? A abordagem mais simples é escolher o modelo correto — nem todas as tarefas precisam do modelo mais poderoso; algumas podem ser executadas perfeitamente com modelos mais baratos. Eduque os desenvolvedores sobre qual modelo usar em cada cenário e, além disso, forneça a eles Contexto e Harness melhores — isso fará com que o Agente evite caminhos errados e reduza drasticamente os custos.

Há ainda o tema do tamanho da equipe. Ter um talento geral que faz tudo é o sonho supremo. Mas, se você fizer as contas com cuidado: essa pessoa geralmente precisa de habilidades complementares, como um gerente de produto ou designer. Então, você também precisa considerar pessoas de reserva (backup), caso alguém tire férias? Isso já retorna a três pessoas. Depois, talvez alguém precise monitorar a produção e os tickets; se você for realmente extremamente eficiente, pode ser a mesma equipe fazendo isso em paralelo. Mas assim que você começar a corrigir bugs, a velocidade de desenvolvimento de novas funcionalidades diminui. E ainda há os novatos: você precisa preparar o caminho para eles, mostrando o que é “bom”. Por isso, ainda acredito que, em uma organização, não é possível realmente reduzir cada equipe a uma ou duas pessoas.

Por fim, a fábrica escura pode não ser totalmente escura, mas manter um leve brilho (dim factory), o que significa que você precisa decidir o nível de risco a assumir para cada funcionalidade — nem todas são adequadas para autonomia total. Você pode investir mais em auditoria, como rastreabilidade: quem alterou o código? Foi uma pessoa ou um agente? Adicione validadores para verificar se o código realmente funciona e invista em capacidade de contexto quando os processos automáticos falharem. Existe todo um espectro entre gerenciamento microscópico completo (cada linha de código revisada por humanos) e aprovação totalmente autônoma (assumindo que todos os resultados do agente estão corretos). O que você precisa fazer é escolher o nível de automação adequado para cada tipo de alteração, conforme o nível de risco.

E acho que sua vantagem competitiva é capturar o conhecimento acumulado — aqueles contextos de negócios que você agora injeta no skill, no Context e até nas restrições do Harness. Para mim, isso realmente transforma a entrega contínua em aprendizado contínuo. Pergunte-se: quão rápido conseguimos inserir algo novo no sistema e remover algo antigo? Essa é sua capacidade de reação. Se você puder melhorar continuamente essa capacidade, a questão central não será mais “como tornar todo o sistema mais confiável?”, mas sim “consigo manter a confiabilidade do sistema enquanto altero cada vez mais suas partes?”.

Se você levar apenas uma frase, deve ser esta: os vencedores não serão aqueles jogadores solitários superiores, mas sim aqueles que sabem como melhorar organizações em múltiplos níveis.