Ferramenta como CLI

Um agente que não consegue agir nas ferramentas reais é uma janela de chat sofisticada. Ele escreve o código, e aí eu abro o navegador, entro no GitLab, clico em criar merge request, preencho o formulário do jeito que a casa exige, espero o pipeline, abro outra aba para ver o log, abro o cliente de banco para conferir um dado. O trabalho voltou inteiro para mim, e o ganho ficou no trecho mais barato de todos.

A virada é tornar cada ferramenta endereçável por linha de comando. Em alguns casos isso é adotar o CLI oficial da ferramenta; em outros, foi escrever o meu, porque o oficial não existe ou não fala o vocabulário do parque.

Hoje são sete comandos, distribuídos para a engenharia inteira junto com o resto do ferramental, não configuração da minha máquina.

O que está automatizado

GitLab: abrir merge request já no ritual da casa, ler status de pipeline, disparar e reexecutar job, puxar o diff para revisão. É a superfície que eu mais uso, porque toda entrega passa por ela.

Banco de dados e log: abrir sessão sem senha exposta, rodar consulta parametrizada, e ler o log dos serviços sabendo quais consultas devolvem vazio em silêncio. Essa última parte é conhecimento operacional que só se adquire apanhando, e que agora está codificado em vez de morar na minha cabeça.

Service desk: ler o que o negócio relatou num chamado, baixar o anexo que veio junto, abrir chamado para outra equipe, comentar e mover de estado. É por onde a demanda entra, e era a superfície com mais clique manual por unidade de trabalho.

Gestão de mudança. O chamado que precede toda publicação em produção tem ritual próprio: formulário obrigatório, ordem entre equipe e responsável que se anula se invertida, campos que impedem o encerramento se preenchidos errado. Virou comando justamente porque é o procedimento em que errar custa uma janela de publicação perdida.

Identidade. O provedor central que atravessa praticamente todo serviço que eu mantenho: criar cliente para aplicação nova, papel, escopo, audiência do token, usuário de teste. Só o ambiente de homologação é alcançável, de propósito.

Padrão e versão: conferir código contra as regras escritas da casa, e descobrir em que versão uma aplicação está.

O que muda quando a ferramenta é um comando

Três coisas, e a terceira é a que eu não tinha previsto.

O agente executa a tarefa inteira, não o pedaço textual dela. A unidade de trabalho deixa de ser “escreva esta função” e passa a ser “resolva isto e abra o MR”.

O ritual da casa deixa de depender de memória. O formato de merge request, o que precisa estar descrito, quais checagens rodam antes: tudo isso estava em convenção combinada, que cada pessoa seguia com fidelidade variável. Virou comando, e comando não esquece.

O conhecimento operacional sai da cabeça e vira ferramenta. Cada CLI que eu escrevi codifica alguma coisa que me custou descobrir, inclusive as armadilhas que devolvem resposta errada sem erro nenhum, que são as caras. Isso tem valor mesmo se eu nunca mais usar um agente, e é o argumento que me convenceu a fazer: o artefato sobrevive à ferramenta que motivou ele.

E deixou de ser meu: com o ferramental distribuído, quem entra na engenharia recebe esses comandos já prontos. A armadilha que custou três horas a alguém virou uma linha que ninguém mais paga.

O limite

Automatizar ferramenta é dar poder de ação a algo que erra com confiança. A resposta não é desconfiar de tudo, que anula o ganho, e sim separar o que é reversível do que não é: ler, consultar e diagnosticar são livres; escrever em sistema de terceiro passa por mim. Merge request é aberto, nunca aprovado; o ambiente de identidade alcançável é o de homologação, e produção não é alcançável por design, não por configuração, que alguém muda sem pensar.