Redefinindo DevOps: Pessoas, Processos, Ferramentas e Agentes
A definição funcionava. Até que um quarto participante apareceu.
DevOps sempre foi definido por uma equação simples e poderosa: Pessoas + Processos + Ferramentas. Essa fórmula capturou algo essencial sobre como o software moderno é construído e entregue. Ela derrubou barreiras entre desenvolvimento e operações. Deu às organizações um modelo mental para diagnosticar o que estava errado quando as coisas andavam devagar demais, falhavam com frequência demais ou criavam atrito demais.
Por mais de uma década, esse modelo de três pilares serviu bem à indústria. E o fez porque se apoiava em uma suposição que ninguém questionava: todo participante no ciclo de vida de entrega de software era humano.
Essa suposição não se sustenta mais.
Agentes de IA agora escrevem código, abrem pull requests, fazem triagem de incidentes, propõem mudanças de infraestrutura, geram documentação e coordenam fluxos de trabalho de múltiplas etapas em repositórios. Eles não são convidados ocasionais no ciclo de vida de entrega. Estão se tornando participantes regulares.
Em publicações anteriores, explorei as dimensões táticas dessa mudança: como as bases de DevOps preparam os sistemas para agentes, como os pipelines de CI/CD devem evoluir, como construir e governar uma equipe de agentes de IA, e como o papel da engenharia está mudando. Essas publicações são específicas e práticas. Esta publicação é o framework conceitual que une todas elas.
O argumento é direto: a equação de DevOps precisa de um quarto termo. Não porque os três primeiros estejam errados, mas porque são incompletos. O modelo atualizado é Pessoas + Processos + Ferramentas + Agentes, e entender o que muda em cada camada é essencial para qualquer organização que queira se beneficiar dos agentes de IA em vez de ser desestabilizada por eles.
A equação original e por que funcionava
Antes de propor mudanças, vale a pena entender por que "Pessoas + Processos + Ferramentas" se tornou o framework dominante em primeiro lugar.
DevOps surgiu como resposta a um problema específico: equipes de desenvolvimento e equipes de operações trabalhando isoladamente, com incentivos conflitantes, ferramentas diferentes e sem responsabilidade compartilhada pelos resultados. Desenvolvedores otimizavam para lançar funcionalidades. Operações otimizavam para estabilidade. O resultado era atrito, culpa e entrega lenta.
O modelo de três pilares abordou isso tornando cada dimensão explícita:
Pessoas representava a mudança cultural. Propriedade compartilhada. Postmortems sem culpa. Equipes multifuncionais. O reconhecimento de que a estrutura organizacional e os incentivos importam tanto quanto a arquitetura técnica.
Processos representava a disciplina operacional. Integração contínua. Entrega contínua. Testes automatizados. Gestão de mudanças. Ciclos de feedback que conectam o que é implantado ao que é observado em produção.
Ferramentas representava os habilitadores técnicos. Sistemas de controle de versão, plataformas de CI/CD, infraestrutura de monitoramento, frameworks de infraestrutura como código, orquestradores de contêineres. A maquinaria prática que torna possíveis as mudanças culturais e de processos.
Esse modelo funcionava porque os três pilares assumiam o mesmo tipo de participante: um ser humano que entende o contexto, exerce julgamento, se comunica com colegas de equipe e assume responsabilidade pelos resultados. Todo o movimento DevOps foi construído para tornar humanos mais eficazes na entrega de software juntos.
Cada processo foi projetado para a velocidade humana, os padrões de erro humanos e a tomada de decisão humana. Cada ferramenta foi projetada com um usuário humano em mente. Cada norma cultural assumia que as pessoas envolvidas podiam ser argumentadas, treinadas e responsabilizadas da maneira que as organizações humanas funcionam.
Essa suposição nunca foi declarada explicitamente, porque nunca precisou ser.
O quarto pilar: Agentes
Agentes de IA não são simplesmente ferramentas melhores. Esta é a distinção mais importante de toda a publicação, e é a que a maioria das organizações erra.
Ferramentas são passivas. Um pipeline de CI/CD faz exatamente o que sua configuração manda. Um linter verifica exatamente as regras que lhe foram dadas. Um script de implantação executa exatamente os passos definidos nele. Ferramentas não têm iniciativa, nem interpretação, nem autonomia. São instrumentos determinísticos operados por humanos.
Agentes são diferentes. Um agente recebe uma intenção, a interpreta, toma decisões sobre como cumpri-la, gera artefatos e interage com outros sistemas. Quando você atribui uma tarefa ao GitHub Copilot coding agent, ele não executa um script predefinido. Ele lê o repositório, entende o contexto, decide quais arquivos modificar, escreve código, cria testes e abre um pull request. Ele faz escolhas ao longo do caminho que um humano não especificou explicitamente.
Essa distinção importa porque muda fundamentalmente três modelos que sustentam como as organizações entregam software:
| Modelo | Apenas com ferramentas | Com agentes |
|---|---|---|
| Confiança | Humanos confiam que as ferramentas executem corretamente. A verificação é mecânica. | Humanos devem confiar que os agentes interpretem corretamente. A verificação requer julgamento sobre julgamento. |
| Responsabilidade | O humano que invocou a ferramenta é responsável pelo resultado. Cadeia clara. | Um humano autorizou o agente, mas o agente tomou decisões específicas. A responsabilidade requer trilhas de atribuição. |
| Governança | Governada por controles de acesso e regras de pipeline. | Requer permissões com escopo definido, barreiras constitucionais e protocolos de delegação. |
Agentes ocupam uma nova posição no modelo organizacional: entre pessoas e ferramentas. Têm mais autonomia que ferramentas, mas menos julgamento que pessoas. Podem operar na velocidade de ferramentas, mas produzem artefatos semelhantes aos de pessoas (código, documentação, propostas arquitetônicas). Interagem diretamente com a camada de ferramentas, mas requerem estruturas de governança que se parecem mais com as que construímos para pessoas.
Tratar agentes como ferramentas significa subgoverná-los. Tratar agentes como pessoas significa confiar demais neles. Nenhum dos dois funciona. Eles precisam de seu próprio pilar.
Como as "Pessoas" mudam quando os agentes se juntam
Quando os agentes lidam com mais do trabalho de execução, o papel humano não diminui. Ele se transforma. Os engenheiros se parecem menos com trabalhadores de linha de montagem e mais com treinadores, revisores e governadores.
De executor a orquestrador
O fluxo de trabalho de engenharia tradicional era: receber uma tarefa, projetar uma solução, implementá-la, testá-la, enviá-la para revisão, abordar o feedback, enviá-la para produção. O engenheiro era o executor principal em cada etapa.
Com agentes no circuito, o fluxo de trabalho se torna: definir a intenção claramente, configurar o escopo e as restrições do agente, delegar a tarefa, revisar a saída, verificar se atende aos requisitos, aprovar ou rejeitar, iterar. O valor do engenheiro passa de escrever código para garantir que o código certo seja escrito.
Este não é um ajuste menor. Requer habilidades genuinamente diferentes:
| Habilidade tradicional | Habilidade emergente |
|---|---|
| Escrever código do zero | Escrever especificações que os agentes possam interpretar sem ambiguidade |
| Depurar lendo código linha por linha | Avaliar a saída do agente contra a intenção e os padrões arquitetônicos |
| Testes manuais e exploração | Projetar critérios de verificação e validação automatizada |
| Revisão de código por correção | Revisão de código por alinhamento com a intenção, postura de segurança e adequação arquitetônica |
| Aprender novos frameworks | Aprender a configurar, restringir e guiar agentes efetivamente |
Explorei a habilidade de especificação em profundidade em De Prompts a Especificações. A ideia central é que comunicar a intenção aos agentes requer especificações estruturadas, versionadas e testáveis, não prompts ad hoc. Engenheiros que dominam essa habilidade amplificam seu impacto significativamente.
O desafio da calibração de confiança
A mudança cultural mais difícil é a calibração de confiança. O código gerado por agentes compila, passa nos testes e frequentemente parece indistinguível do código escrito por humanos. A tentação é tratá-lo como inerentemente confiável porque parece correto e a máquina parece confiante.
Isso é perigoso. Agentes podem produzir código que é sintaticamente perfeito, mas semanticamente errado: implementação correta do comportamento errado, soluções arquitetonicamente desalinhadas, ou problemas sutis de segurança que nenhuma verificação automatizada detecta.
Como discuti em Humanos e Agentes: Padrões de Colaboração, a colaboração eficaz requer que os humanos mantenham um ceticismo saudável calibrado ao risco da mudança. Um ajuste cosmético na interface do usuário justifica um escrutínio mais leve do que uma mudança na lógica de autenticação, independentemente de ter sido produzido por um humano ou por um agente.
Novas normas culturais
As equipes precisam desenvolver novas normas:
- A saída do agente é sempre revisada. Não aprovada automaticamente. Revisada com o mesmo rigor aplicado ao código de um novo membro da equipe.
- A delegação é explícita. Quando um agente recebe uma tarefa, há um registro claro de quem a autorizou, que escopo foi dado e que restrições foram estabelecidas.
- O desenvolvimento de habilidades muda. Orçamentos de treinamento e programas de desenvolvimento profissional devem incluir design de especificações, configuração de agentes e validação de saída, não apenas linguagens de programação e frameworks.
Como os "Processos" mudam quando os agentes se juntam
Processos projetados para colaboradores humanos assumiam certas características: humanos trabalham em certo ritmo, cometem certos tipos de erros, se comunicam por certos canais e podem ser responsabilizados por estruturas organizacionais. Agentes quebram muitas dessas suposições.
Velocidade e volume
Humanos produzem código a uma taxa limitada pelo pensamento, digitação, troca de contexto, reuniões e necessidades biológicas. Agentes produzem código a uma taxa limitada pela latência da API e disponibilidade de computação. Um único agente pode gerar dezenas de pull requests no tempo em que um humano produz um.
Isso não é simplesmente mais rápido. É qualitativamente diferente. Processos que funcionavam quando uma equipe produzia dez pull requests por dia precisam funcionar quando agentes adicionam mais cinquenta. Processos de revisão, estratégias de merge, infraestrutura de testes e pipelines de implantação enfrentam pressão de throughput para a qual os processos existentes não foram projetados.
Diferentes modos de falha
Erros humanos tendem a ser reconhecíveis: erros de digitação, erros de lógica, casos extremos esquecidos, artefatos de copiar e colar. Revisores pares têm décadas de reconhecimento de padrões para esses modos de falha.
Erros de agentes parecem diferentes. Frequentemente estão confidentemente errados: código sintaticamente correto que implementa o comportamento errado, soluções arquitetonicamente plausíveis que violam convenções não declaradas, ou código adjacente à segurança que passa em varreduras automatizadas, mas introduz vulnerabilidades sutis. Como explorei em Pipelines de CI/CD para a Era Agêntica, as estratégias de verificação devem evoluir para capturar esses modos de falha.
Novas camadas de processo
Os processos precisam de várias novas camadas que não existiam no modelo exclusivamente humano:
Protocolos de delegação. Antes de um agente agir, deve haver um protocolo claro: quem autorizou o agente a trabalhar nesta tarefa? Que especificação ou instrução governou seu comportamento? Que limites de escopo o restringiram? Sem protocolos de delegação, você tem agentes autônomos fazendo mudanças que ninguém solicitou ou aprovou.
Rastreamento de atribuição. Cada artefato que um agente produz precisa ser rastreável até o humano ou sistema que iniciou a ação. Isso não é apenas para responsabilidade. É para depuração, auditoria e compreensão de por que uma decisão particular foi tomada. Quando um incidente ocorre em produção, "um agente mudou este arquivo" não é suficiente. Você precisa saber qual agente, sob quais instruções, autorizado por quem e revisado por quem.
Limites de escopo. Agentes devem ter limites explícitos sobre o que podem tocar. Um agente encarregado de atualizar dependências não deve poder modificar a lógica de autenticação. Um agente gerando documentação não deve poder alterar o código de infraestrutura de produção. Esses limites precisam estar codificados na configuração do agente e ser aplicados pela cadeia de ferramentas.
Portas de verificação. Além das verificações tradicionais de "compila e passa nos testes?", os processos precisam de portas de verificação que validem a saída do agente contra a especificação ou intenção que a desencadeou. O agente realmente fez o que foi pedido? Permaneceu dentro do escopo autorizado? Introduziu padrões que conflitam com as convenções arquitetônicas do repositório?
Como as "Ferramentas" mudam quando os agentes se juntam
A camada de ferramentas sempre foi o pilar mais tangível de DevOps. Controle de versão, plataformas de CI/CD, sistemas de monitoramento, frameworks de infraestrutura como código. Essas ferramentas foram projetadas com operadores humanos em mente: dashboards para olhos humanos, CLIs para mãos humanas, notificações para atenção humana.
Quando agentes se tornam participantes ativos, a camada de ferramentas deve se tornar consciente dos agentes.
Repositórios como espaços de trabalho compartilhados
Um repositório não é mais apenas um lugar onde humanos armazenam e colaboram em código. É um espaço de trabalho compartilhado onde tanto humanos quanto agentes operam. Isso significa que os repositórios precisam de elementos estruturais que os agentes possam interpretar:
- Arquivos de instrução (
.github/copilot-instructions.md,.github/instructions/) que codificam as convenções do projeto, padrões de codificação e restrições arquitetônicas em um formato que os agentes possam consumir - Diretórios de especificações (
specs/) onde documentos de intenção estruturados residem, fornecendo aos agentes requisitos claros em vez de prompts ambíguos - Configurações de agentes (
.github/agents/) que definem personas especializadas de agentes com experiência e limites definidos - Documentos constitucionais (
.specify/memory/constitution.md) que estabelecem princípios não negociáveis que todos os agentes devem seguir
Descrevi essa arquitetura de repositório em Construindo Sua Equipe de Agentes de IA e Projetando Software para um Mundo Agent-First. A ideia-chave é que a estrutura do repositório não é mais apenas uma conveniência organizacional. É uma interface da qual tanto humanos quanto agentes dependem, e sua qualidade afeta diretamente a qualidade da saída do agente.
Pipelines de CI/CD como infraestrutura de confiança
Como discuti em detalhe em Pipelines de CI/CD para a Era Agêntica, os pipelines devem evoluir de simples guardiões para sistemas de verificação abrangentes. Mas a mudança vai além da configuração do pipeline. O papel fundamental da plataforma de CI/CD muda.
No modelo exclusivamente humano, CI/CD era um acelerador de qualidade. Detectava erros humanos mais rápido do que os processos manuais conseguiam.
No modelo que inclui agentes, CI/CD se torna o mecanismo principal de confiança. É o sistema que valida se a saída do agente atende aos padrões que a organização exige. Pense nele como a última linha de defesa entre as decisões autônomas de um agente e a produção.
Isso significa que as ferramentas de CI/CD precisam de novas capacidades:
| Capacidade | Propósito |
|---|---|
| Rastreamento de procedência | Saber se um commit veio de um humano ou de um agente, e de qual agente |
| Validação de escopo | Verificar que as mudanças permaneçam dentro dos limites em que o agente foi autorizado a operar |
| Correspondência de especificações | Verificar que a implementação corresponde à especificação que desencadeou o trabalho |
| Detecção de alucinações | Capturar referências a APIs, pacotes ou padrões inexistentes |
| Escrutínio diferencial | Aplicar diferentes profundidades de verificação com base na fonte e no perfil de risco da mudança |
Observabilidade que inclui ações de agentes
Os sistemas de monitoramento e observabilidade foram projetados para rastrear o comportamento dos aplicativos e o estado da infraestrutura. Quando agentes estão ativos no ciclo de vida de entrega, a observabilidade precisa se estender ao comportamento dos agentes.
Quantos pull requests os agentes abriram hoje? Qual foi sua taxa de merge versus taxa de rejeição? Quais mudanças geradas por agentes causaram incidentes? Quanto da base de código foi escrito por agentes versus humanos? Os agentes estão se desviando de seu comportamento configurado ao longo do tempo?
Essas perguntas não são acadêmicas. São necessidades operacionais. Sem observabilidade sobre o comportamento dos agentes, as equipes operam às cegas em um sistema onde uma porcentagem crescente de mudanças é feita por atores não humanos.
A nova equação de confiança
No modelo DevOps original, a confiança era principalmente uma construção cultural. As equipes construíam confiança por meio da responsabilidade compartilhada, postmortems sem culpa, comunicação transparente e prova incremental de que o sistema funcionava. Isso era fundamentalmente interpessoal: humanos aprendendo a confiar em outros humanos através de fronteiras organizacionais.
Quando agentes entram no circuito, a confiança deve ser estendida a participantes não humanos que não podem ser treinados, não podem participar de postmortems e não podem internalizar valores organizacionais da maneira que os humanos fazem. A confiança deve ser construída por meio de mecanismos em vez de relacionamentos.
A nova equação de confiança de DevOps pode ser expressa como:
Confiança = Bases Sólidas x Delegação Clara x Verificação Automatizada x Supervisão Humana nos Pontos de Decisão
Cada fator é multiplicativo, não aditivo. Se qualquer fator for zero, a confiança colapsa:
Bases Sólidas. Os fundamentos de DevOps: controle de versão, testes automatizados, CI/CD, monitoramento, varredura de segurança. Sem eles, os agentes amplificam o caos. Com eles, os agentes amplificam a capacidade. Esta é a premissa de A Engenharia de Software Agêntica Precisa de Bases Sólidas de DevOps.
Delegação Clara. Cada ação do agente deve ser rastreável até um escopo autorizado por um humano. Quem pediu ao agente para agir? Que especificação governou o trabalho? Que limites restringiram a autonomia do agente? Delegação sem clareza é abdicação.
Verificação Automatizada. A saída do agente deve passar por verificações automatizadas que vão além de "compila?". Conformidade com especificações, validação de escopo, conformidade arquitetônica, análise de segurança e detecção de alucinações. O pipeline é a verdade objetiva.
Supervisão Humana nos Pontos de Decisão. Não cada ação, mas cada decisão consequente. Aprovações de implantação, mudanças relacionadas à segurança, mudanças arquitetônicas, adições de dependências. Humanos retêm autoridade onde o julgamento é insubstituível.
Essa equação é prática, não teórica. Cada organização pode avaliar sua posição atual em cada fator e identificar onde existe o elo mais fraco. A maioria descobrirá que a delegação e a verificação são as menos maduras, porque essas capacidades não eram necessárias quando todos os participantes eram humanos.
Um modelo de maturidade para Pessoas + Processos + Ferramentas + Agentes
Nem toda equipe está pronta para a integração completa de agentes, e tudo bem. O progresso acontece em etapas. Entender onde sua equipe está, e o que é necessário para avançar, ajuda a definir expectativas realistas e priorizar investimentos.
Etapa 1: Assistência
Agentes ajudam com tarefas discretas e bem delimitadas dentro dos processos existentes. Desenvolvedores usam assistentes de codificação de IA para autocompletar, sugestões em linha e perguntas e respostas baseadas em chat. Agentes trabalham inteiramente dentro da sessão do desenvolvedor. Sem pull requests autônomos, sem fluxos de trabalho de múltiplas etapas, sem delegação.
O que caracteriza esta etapa:
- Agentes são ferramentas dentro do IDE, não atores independentes
- Toda saída é imediatamente revisada e modificada pelo desenvolvedor
- Processos, pipelines e estruturas de governança existentes permanecem inalterados
- Confiança não é um problema porque o humano está sempre no circuito
O que a maioria das equipes acerta nesta etapa: Adoção rápida e ganhos de produtividade mensuráveis para tarefas individuais.
O que a maioria das equipes deixa de lado: Assumir que este é o estado final. Assistência é o começo, não o teto.
Etapa 2: Aumentação
Agentes gerenciam fluxos de trabalho de múltiplas etapas com supervisão humana em pontos de controle chave. O GitHub Copilot coding agent recebe uma tarefa, trabalha em uma branch autonomamente e abre um pull request para revisão. Agentes geram não apenas código, mas testes, documentação e às vezes mudanças de infraestrutura. A delegação é explícita. A revisão é obrigatória.
O que caracteriza esta etapa:
- Agentes operam fora da sessão imediata do desenvolvedor
- Pull requests de agentes são revisados com o mesmo rigor que contribuições humanas
- O desenvolvimento orientado por especificações emerge como prática (veja De Prompts a Especificações)
- Pipelines de CI/CD começam a diferenciar entre contribuições humanas e de agentes
- Configurações de agentes e arquivos de instrução são versionados
O que a maioria das equipes acerta nesta etapa: Configurar fluxos de trabalho iniciais de agentes e experimentar ganhos significativos de produtividade para tarefas rotineiras.
O que a maioria das equipes deixa de lado: Investir insuficientemente em verificação, atribuição e controles de escopo. A tentação é confiar na saída do agente porque compila e os testes passam. Equipes nesta etapa precisam construir ativamente o músculo de governança que a Etapa 3 exige.
Etapa 3: Orquestração
Agentes se coordenam entre si e com humanos ao longo de todo o ciclo de vida. Múltiplos agentes especializados lidam com diferentes aspectos do processo de entrega: um agente escreve código a partir de especificações, outro revisa, outro atualiza documentação, outro propõe mudanças de infraestrutura. Agentes operam dentro de barreiras constitucionais, perfis de habilidades com escopo definido e verificação automatizada. Humanos governam o sistema em vez de realizar tarefas individuais.
O que caracteriza esta etapa:
- Coordenação multi-agente com clara separação de papéis
- Documentos de governança constitucional definem limites não negociáveis
- Verificação automatizada de conformidade com especificações
- Rastreamento completo de procedência para todas as ações de agentes
- Dashboards de observabilidade que incluem métricas de agentes
- Humanos funcionam principalmente como governadores, arquitetos e tratadores de exceções
O que a maioria das equipes acerta nesta etapa: As equipes que chegam a esta etapa geralmente têm culturas de engenharia fortes e práticas DevOps maduras desde o início.
O que a maioria das equipes deixa de lado: Complicar excessivamente a camada de orquestração. Os melhores sistemas multi-agente são compostos de agentes simples, bem delimitados, com limites claros, não um agente onisciente tentando fazer tudo.
Onde a maioria das equipes está hoje
A maioria das organizações está em algum lugar entre a Etapa 1 e a Etapa 2. Adotaram assistentes de codificação de IA e estão começando a experimentar com fluxos de trabalho autônomos de agentes. A diferença entre a Etapa 2 e a Etapa 3 é significativa e requer investimento em infraestrutura de governança, verificação e observabilidade que a maioria das equipes ainda não começou a construir.
O caminho adiante é incremental. Cada etapa se constrói sobre a anterior. Tentar pular diretamente da Assistência para a Orquestração sem construir as camadas de governança e verificação da Aumentação é uma receita para incidentes, dívida técnica e confiança erodida.
O que não muda
Com toda a ênfase no que é novo, é importante ser claro sobre o que perdura.
DevOps nunca foi realmente sobre ferramentas. Era sobre cultura, colaboração e ciclos de feedback. O ciclo infinito de Planejar, Codificar, Construir, Testar, Lançar, Implantar, Operar, Monitorar ainda se aplica. Cada princípio que tornou DevOps valioso (propriedade compartilhada, melhoria contínua, feedback rápido, aprender com o fracasso) permanece essencial.
O que muda é quem (ou o quê) realiza cada etapa e como a responsabilidade flui.
Considere este mapeamento das práticas tradicionais de DevOps para o modelo de quatro pilares:
| Princípio DevOps | Ainda se aplica? | O que muda |
|---|---|---|
| Propriedade compartilhada | Sim | A propriedade agora se estende a governar o comportamento e a saída dos agentes |
| Integração contínua | Sim | CI deve lidar com maior volume e distinguir tipos de colaboradores |
| Testes automatizados | Sim | Testes devem validar a saída do agente contra especificações, não apenas funcionalidade |
| Infraestrutura como código | Sim | Templates de IaC se tornam entradas que agentes podem modificar, exigindo revisão mais rigorosa |
| Monitoramento e observabilidade | Sim | Observabilidade deve incluir atividade de agentes e rastreamento de decisões |
| Postmortems sem culpa | Sim | Postmortems devem rastrear decisões de agentes e as delegações que as autorizaram |
| Melhoria contínua | Sim | Melhoria agora inclui refinar configurações de agentes, especificações e governança |
A ideia central é que agentes amplificam qualquer cultura que você já tenha. Culturas fortes com práticas maduras, responsabilidade clara e comprometimento genuíno com a qualidade descobrirão que os agentes as tornam ainda mais fortes. Equipes com bases fracas, propriedade pouco clara, testes ausentes e pipelines frágeis descobrirão que os agentes escalam suas fraquezas mais rápido que suas forças.
Este não é um aviso hipotético. É a experiência vivida de cada equipe que introduziu agentes sem primeiro investir nos fundamentos. Agentes não consertam processos quebrados. Eles executam processos quebrados em escala.
O quarto membro
A indústria está se movendo de DevOps para o que alguns chamam de "AgentOps" ou "DevOps Agêntico". O rótulo importa menos do que o reconhecimento de que a entrega de software agora tem um quarto tipo de participante.
Por dez anos, a comunidade DevOps trabalhou para unir desenvolvedores e operações. Esse trabalho foi sobre fechar uma lacuna entre dois grupos de pessoas que compartilhavam o mesmo objetivo, mas trabalhavam isoladamente. A união de Pessoas, Processos e Ferramentas foi o framework para fechar essa lacuna.
A próxima década será sobre integrar um tipo de participante fundamentalmente novo: um que opera na velocidade da máquina, produz artefatos legíveis por humanos, tem mais autonomia do que qualquer ferramenta anterior, mas carece do julgamento, contexto e valores que os humanos trazem.
Organizações que reconhecerem essa mudança e atualizarem suas pessoas, processos e ferramentas em conformidade liderarão. Entregarão mais rápido, com menos defeitos e com melhor postura de segurança, porque terão aproveitado as forças dos agentes enquanto contêm suas limitações.
Organizações que tentarem encaixar agentes em um framework exclusivamente humano descobrirão uma verdade desconfortável: agentes escalam fraquezas mais rápido que forças. Sem delegação clara, agentes agem sem autorização. Sem verificação automatizada, erros de agentes chegam à produção sem controle. Sem supervisão humana nos pontos de decisão, escolhas consequentes são feitas por sistemas que otimizam para a letra do prompt em vez do espírito da intenção.
A equação tem quatro termos agora. Construa para todos eles.