O merge costumava ser a linha de chegada. Você abria um pull request, alguém revisava, ele entrava e a mudança estava pronta. Os agentes de programação moveram essa linha sem alarde. Quando um agente pega uma issue no Linear, escreve o código e abre um merge request enquanto você está numa reunião, o merge deixa de ser o fim do trabalho — é o começo de tudo o que o merge toca.
O merge deixou de ser a linha de chegada
Um merge nunca é só um merge. Cada mudança se apoia nos sistemas ao redor: a issue que agora deveria ser fechada, a documentação que desde hoje de manhã descreve algo levemente falso, o CI um pouco mais vermelho que ontem, as notas de versão que ninguém escreveu, a conversa de suporte ainda esperando por uma correção que na verdade saiu horas atrás.
Quando uma pessoa entregava um punhado de mudanças por semana, esse trabalho posterior cabia nas frestas. Você fechava a issue enquanto estava com o pull request aberto; lembrava da doc porque acabara de mexer no código. Quando um agente — ou uma frota deles — entrega muitas mudanças por dia, as frestas transbordam. O código não é mais o gargalo. É tudo o que vem depois do código.
O modelo de manutenção não mudou
O desenvolvimento ficou mais rápido. A manutenção não. As ferramentas que usamos para manter um projeto coerente ainda são, em sua maioria, manuais, e ainda dependem de alguém lembrar de usá-las na hora certa:
- Um merge request entra, mas a issue do Linear que ele resolve continua aberta.
- A documentação ainda descreve o comportamento antigo, e ninguém sabe bem em qual página.
- O CI está falhando de forma intermitente há uma semana e todo mundo aprendeu a ignorar.
- Um feature flag de três meses atrás não tem responsável nem data de remoção.
- O suporte responde um ticket com um contorno para um bug que foi corrigido na terça.
- Alguém pergunta o que saiu nesta versão, e a resposta honesta é "deixa eu ler o git log".
Nada disso é novo, e nada disso é de fato um problema do agente. É a entropia comum de um projeto de software. O agente apenas acelera o ritmo até que o sistema informal que antes absorvia isso deixa de dar conta.
A limpeza sob demanda não escala
A correção óbvia é pedir que o agente também faça a limpeza, e você pode. Mencione @taskgoblin no merge request e diga para atualizar a documentação, fechar a issue, redigir a nota de versão. Funciona. Mas depende do recurso mais escasso de todo o ciclo: uma pessoa lembrar de pedir, toda vez, na hora certa.
Manutenção não é uma tarefa pontual; é um ciclo. "Conferir se a documentação está em dia" não é algo que se faz uma vez. "Garantir que as issues resolvidas sejam fechadas" não é algo que se faz uma vez. Qualquer coisa que espere uma pessoa perceber que é hora de rodar o ciclo será rodada de forma inconsistente — porque pessoas percebem de forma inconsistente, ainda mais quando o sentido do agente era, justamente, parar de carregar tudo isso na cabeça. A limpeza sob demanda move o trabalho para o agente, mas deixa o agendamento do trabalho exatamente onde estava: em você.
Por que construímos as Loops
Uma execução normal do agente é disparada por um evento: a atribuição de uma issue, uma menção, um novo pull request. Um Loop é disparado pelo tempo. Você dá ao agente uma instrução permanente e uma cadência — toda manhã de dia útil, toda segunda, no primeiro dia do mês — e ele se executa sozinho, em um sandbox, com as mesmas ferramentas e o mesmo acesso de qualquer outra execução.
A instrução é a tarefa inteira, e as boas se leem como uma descrição de cargo, não como um desejo: o que olhar, em qual repositório, o que fazer, o que não fazer e — a parte que a torna segura para rodar sem supervisão — o que fazer quando não há nada a fazer, que é nada.
Todo dia útil às 09:00, olhe os merge requests que entraram no último dia em
grupo/repoe feche qualquer issue do Linear que eles resolvam e ainda esteja aberta. Se não houver nenhuma, não faça nada.
Isso é um ciclo de manutenção com responsável. Ele não espera você lembrar. Como uma execução agendada é uma execução completa do agente, ela pode ir até o fim: não só sinalizar a doc desatualizada, mas abrir o merge request que a corrige; não só perceber que ficaram issues abertas, mas fechá-las — e então reportar onde você vai de fato ver: como comentário na issue do Linear, como mensagem no canal do Slack que você indicou, ou como e-mail se não houver lugar melhor.
E porque reutiliza tudo o que uma execução normal já faz, as arestas estão resolvidas. O tempo perdido é pulado, não recuperado, então um agendador que ficou fora do ar por uma hora não acorda e dispara cem execuções atrasadas. Cada execução tem seu próprio orçamento e suas travas de segurança. Enviamos um conjunto de modelos iniciais para exatamente esses ciclos — manter issues e merges em sincronia, vigiar um CI vermelho por tempo demais, perseguir feature flags que sobreviveram ao dono, redigir notas de versão conforme as coisas saem — porque os úteis são os mesmos na maioria dos times. Você preenche o seu repositório e o seu canal; as travas já estão escritas.
O trabalho do engenheiro sobe um nível
Embaixo de tudo isso há um receio: o de que automatizar a manutenção signifique automatizar o julgamento. Não significa. Ele sobe o julgamento um nível. Quando os ciclos se executam sozinhos, você deixa de ser a pessoa que lembra de fechar issues e passa a ser a pessoa que decide quais ciclos devem existir, quais são suas travas de segurança e o que "pronto" significa para cada um. Você revisa a instrução permanente em vez de fazer o recado.
Essa é, de qualquer forma, a versão mais sênior do trabalho. O agente barateou escrever o código; o que sobra é decidir o que deve ser verdade sobre o sistema e garantir que continue verdade. As Loops são como você mantém isso verdadeiro sem carregar tudo na cabeça — o agente cria o trabalho, e um ciclo permanente o mantém.
