A evolução da automação: de scripts shell a organizações de IA

A tecnologia muda, mas o acordo básico não: invista uma vez para não ter de repetir o mesmo trabalho para sempre.

Faço software há muito tempo e, em todo esse período, uma coisa sobre automação permaneceu notavelmente constante: a tecnologia muda, mas a lógica não. Se me pego fazendo a mesma coisa repetidamente, quase sempre chega um ponto em que vale a pena investir tempo adiantado para automatizar.

No fim dos anos 1900, isso podia significar escrever um script de shell. Se eu precisasse renomear um monte de arquivos, processar dados de forma repetível, copiar coisas entre sistemas ou rodar os mesmos comandos várias vezes, eu podia continuar no manual ou gastar o tempo para escrever aquilo uma vez. Criar o script às vezes demorava mais do que fazer a tarefa uma única vez, mas nunca foi essa a questão. O retorno vinha de cada repetição seguinte.

Essa equação básica não mudou. O que mudou foi a escala daquilo que conseguimos automatizar.

Primeiro, automatizamos tarefas

As primeiras formas de automação com que trabalhei eram pequenas e locais. Um script de shell substituía uma série de comandos. Um cron fazia algo acontecer em horário marcado. Um script em Perl ou Python transformava um fluxo repetitivo em algo repetível.

Os exemplos típicos eram coisas como:

• Renomear ou mover grandes lotes de arquivos
• Processar dados sempre da mesma maneira
• Copiar arquivos entre sistemas
• Executar comandos repetitivos de implantação
• Agendar tarefas recorrentes de manutenção

A abstração era simples: sei exatamente o que quero que o computador faça, consigo descrever isso com precisão suficiente e prefiro gastar o tempo ensinando uma vez a continuar fazendo aquilo para sempre. Às vezes significava gastar duas horas automatizando uma tarefa que levava cinco minutos no manual, o que parece ridículo se você pretende fazê-la só uma vez. Se pretende fazê-la centenas ou milhares de vezes, fica óbvio.

Esse mesmo padrão se repetiu à medida que os sistemas de software foram ficando mais complicados.

Depois, automatizamos a infraestrutura

A computação em nuvem ampliou o escopo do que podia ser roteirizado. Em vez de automatizar uma tarefa dentro de uma máquina, passamos a automatizar a criação e a configuração das próprias máquinas.

O Terraform nos deixou descrever infraestrutura como código. O Kubernetes nos deixou descrever como aplicações distribuídas deveriam rodar, escalar, reiniciar e se comunicar. Sistemas de CI/CD automatizaram o caminho do software do controle de versão até a produção.

De repente, coisas que tradicionalmente exigiam um trabalho operacional manual considerável podiam ser declaradas e recriadas:

• Servidores
• Redes
• Bancos de dados
• Balanceadores de carga
• Permissões
• Implantações de aplicações
• Regras de escalonamento
• Ambientes inteiros

O que antes envolvia gente clicando por consoles, configurando sistemas na mão e coordenando implantações virou, aos poucos, algo que podia ser versionado, revisado, testado e reproduzido.

O custo inicial cresceu porque aquilo que se automatizava cresceu. Uma boa automação de infraestrutura é mais difícil do que um script de shell de dez linhas. Exige mais reflexão, mais tratamento de casos extremos, mais depuração e mais manutenção. O retorno, porém, escala junto com a complexidade. Uma vez que um ambiente esteja bem definido, sistemas inteiros que exigiam horas ou dias de configuração manual podem ser recriados com pouquíssimo esforço humano.

O princípio da automação continuou exatamente o mesmo. Só subimos um nível.

Agora, estamos automatizando fluxos de trabalho

Os agentes de IA estão empurrando essa abstração para cima de novo. No início, o uso óbvio era tratar o agente como um script muito capaz: dar uma tarefa, deixar que ele a execute e receber o resultado.

Isso é útil, mas também é um jeito bem estreito de pensar no que está acontecendo. A mudança maior é que agora podemos automatizar não apenas tarefas isoladas, mas a coordenação de tarefas entre vários trabalhadores inteligentes.

Um fluxo agêntico moderno pode se parecer com isto:

• Um agente escreve o código.
• Outro revisa a implementação.
• Outro roda os testes.
• Outro procura problemas de segurança.
• Outro verifica se os requisitos originais foram de fato atendidos.
• Um fluxo decide o que acontece quando algo falha.
• Portões de aprovação determinam o que exige uma pessoa e o que pode seguir automaticamente.

Nesse ponto, você já não está roteirizando o trabalho. Está roteirizando o sistema que organiza o trabalho. Isso é um salto muito maior do que simplesmente trocar uma tarefa manual por uma tarefa de IA. A fronteira da automação está se deslocando da execução para a coordenação.

Orgabot é a versão mais recente da mesma ideia

É assim que penso no Orgabot. É fácil olhar para a orquestração de agentes de IA e achar que é algo fundamentalmente diferente das ferramentas de automação anteriores, mas, num plano abstrato, é o mesmo padrão que uso há décadas.

A progressão é bem direta:

• Um script de shell automatizava comandos que eu não queria digitar repetidamente.
• Infraestrutura como código automatizava sistemas que eu não queria configurar repetidamente.
• CI/CD automatizava fluxos de implantação que eu não queria coordenar na mão.
• A orquestração de agentes automatiza trabalho que eu não quero gerenciar passo a passo.
• O Orgabot leva isso na direção de automatizar a própria estrutura em torno dos trabalhadores.

A diferença é a escala. Com algo como o Orgabot, aquilo que se automatiza já não é um comando nem mesmo um pipeline de implantação. Pode ser um fluxo completo de desenvolvimento de software, envolvendo múltiplos agentes especializados, permissões, portões de revisão, etapas de verificação e lógica de implantação.

A transição vai de roteirizar uma tarefa do tipo «construa esta funcionalidade» para definir um sistema capaz de decidir repetidamente como as funcionalidades devem ser construídas, quem deve construí-las, como o trabalho deve ser revisado e quando está pronto para sair. Isso começa a parecer menos automatizar um desenvolvedor e mais automatizar partes de uma organização.

A automação continua subindo a pilha de abstrações

Olhando para trás, a progressão é notavelmente consistente:

• Automatizamos comandos.
• Depois automatizamos tarefas repetitivas.
• Depois automatizamos implantações.
• Depois automatizamos a infraestrutura.
• Depois automatizamos pipelines e fluxos de trabalho.
• Agora automatizamos os trabalhadores dentro desses fluxos.
• E, cada vez mais, automatizamos a coordenação entre esses trabalhadores.

Cada passo empurra a fronteira da automação para cima. O interessante é que toda etapa parece ser o topo. Quando a infraestrutura virou programável, aquilo pareceu um salto enorme de abstração. Quando agentes de IA começaram a escrever software, era fácil imaginar que tínhamos chegado ao ponto final natural: basta dizer à IA o que você quer e deixá-la construir.

Mas até isso já começa a parecer um passo intermediário. Em vez de dizer a um agente o que fazer, estamos construindo sistemas que decidem quais agentes devem trabalhar, como devem colaborar, como o trabalho deve ser avaliado e o que deve acontecer em seguida. O que levanta a pergunta óbvia: o que existe acima da orquestração automatizada?

O que será roteirizável daqui a dez anos?

Se o padrão continuar, a próxima abstração pode ser bem maior do que qualquer coisa que hoje chamamos de fluxo de trabalho. Talvez a unidade que automatizamos passe a ser uma organização inteira.

Você poderia descrever um objetivo de negócio e ter um sistema montando os equivalentes de:

• Desenvolvimento de produto
• Engenharia
• Infraestrutura
• Marketing
• Suporte ao cliente
• Finanças
• Processos jurídicos
• Analytics
• Operações

A entrada pode acabar ficando menos procedimental e mais intencional. Em vez de especificar tarefas, fluxos ou agentes, você talvez apenas expresse um objetivo do tipo «acho que deveria existir um produto que faça isto», e o sistema descubra tudo o que é preciso para tornar essa ideia real.

Há aqui também um padrão histórico mais amplo. A interação entre pessoas e computadores segue subindo para níveis mais altos de intenção:

• O código de máquina virou linguagens de programação.
• As linguagens de programação ganharam bibliotecas e frameworks.
• Servidores viraram declarações de infraestrutura.
• Comandos viraram prompts.
• Prompts estão virando objetivos.

O desfecho lógico é gastarmos menos tempo descrevendo como algo deve acontecer e mais tempo descrevendo o que queremos que exista. Talvez daqui a dez anos até a ideia de orquestrar agentes explicitamente pareça primitiva. Talvez a gente simplesmente expresse intenção e deixe um sistema montar por baixo a combinação de agentes, ferramentas, fluxos, infraestrutura, organizações e processos que for necessária.

No extremo, a interface pode parecer menos programação e mais manifestação: pensar em algo, descrever e ver um sistema automatizado transformar essa intenção em algo real. Soa dramático, mas toda camada de abstração anterior teria soado dramática antes de existir.

A economia da automação nunca mudou de verdade

O que acho mais interessante é que, apesar de todo esse avanço, o acordo continua quase idêntico ao que eu fazia escrevendo scripts de shell décadas atrás. Automação ainda exige investimento inicial. É preciso definir o processo, construir o sistema, tratar casos extremos, depurar falhas e decidir o que deve acontecer quando a realidade não corresponde às suas suposições.

O trabalho manual costuma parecer mais fácil no começo porque evita esse investimento inicial. Depois a automação começa a funcionar, as repetições se acumulam e o retorno fica evidente.

Isso era verdade quando a automação era um script de dez linhas. Era verdade quando virou milhares de linhas de configuração de infraestrutura. É verdade agora, quando começamos a orquestrar times de agentes de IA. A escala não para de crescer, mas o princípio quase não mudou: gaste o esforço uma vez para não precisar gastá-lo para sempre.

E se esse padrão continuar, a pergunta mais interessante não é o que conseguimos automatizar hoje. É o que ainda vai parecer grande demais para automatizar amanhã.