Gordon: O agente de IA da Docker

O log tem 400 linhas. A última diz alguma coisa sobre conexão recusada; a aplicação funciona na sua máquina, exceto que é justamente nela que está falhando. Alguém já escreveu no chat: "consegue colocar isso em pé?".
Nessa hora, um assistente de código ajuda, mas só depois que você entrega metade do trabalho. Ele sugere um Dockerfile, explica um erro que você colou no chat e talvez acerte uma flag. Só não sabe quais containers estão rodando, qual volume foi montado, o que há no compose.yaml ou o que o daemon local acabou de fazer. Você vira o intermediário entre terminal, Docker Desktop, logs e o chat de IA. Um cargo pouco nobre para quem já sabe usar docker ps.
O Gordon é a tentativa do Docker de fechar essa lacuna. É um agente integrado ao Docker Desktop e ao CLI, com acesso ao ambiente de containers e permissão para agir depois da sua aprovação. Não é só outra maneira de perguntar "o que significa exit code 1?". Ele coleta o contexto, propõe o próximo passo e executa quando você aprova.
O que importa aqui é separar o que o Gordon faz do marketing que inevitavelmente aparece quando alguém coloca "agent" no nome.

O problema: o contexto está espalhado

Grande parte do trabalho com containers não é escrever Dockerfile. É descobrir por que aquilo que parecia trivial não funciona no ambiente atual.
Um build deixa de aproveitar cache porque a ordem de um COPY foi ruim. A aplicação sobe, mas não chega no Postgres porque uma variável de ambiente não foi carregada. Um volume encobre um diretório da imagem. O container está saudável na sua cabeça, mas o processo principal encerrou há 15 segundos.
Nada disso pede uma inteligência artificial filosófica. Pede acesso ao estado real, alguém que relacione os sinais e que não obrigue você a procurar a sintaxe de docker system df no meio de um incidente local.

Assistentes de código trabalham, em geral, com o contexto que você oferece. Você cola o erro, descreve a topologia e torce para não esquecer a variável que muda tudo. Gordon parte de outra premissa: ele pode ler logs de containers em execução, imagens, arquivos do Compose e o diretório de trabalho. Depois usa shell, filesystem e o Docker CLI para investigar e preparar a correção.
Ele não elimina o diagnóstico. Só tira da frente a coleta manual e repetitiva de contexto. Parece menos glamouroso do que "IA autônoma", mas é bem mais útil no trabalho diário.

O que o Gordon faz

Gordon é o assistente nativo do Docker para tarefas com containers, imagens e Dockerfile. Está disponível no Docker Desktop 4.74 ou superior e no terminal, pelo comando docker ai.
Você faz um pedido em linguagem natural. Ele olha o ambiente associado à sessão, propõe comandos ou mudanças em arquivos e espera a aprovação. Dá para rejeitar, corrigir a direção ou aprovar.
Isso não é um detalhe. Um agente que executa shell, altera arquivos e opera containers não merece o mesmo tratamento de um autocomplete com esteroides. O Gordon pede aprovação explícita para cada ação; as permissões duram só a sessão, e o Docker mostra comandos e modificações antes de aplicá-los. Há auto-approve para fluxos confiáveis, mas eu não começaria por ele. Não digitar um comando não compensa deixar passar uma exclusão, um prune ou uma configuração ruim.
Em termos práticos, Gordon é um operador assistido para o Docker local. Ele não substitui seu entendimento de containers, a observabilidade de produção ou uma arquitetura decente. Pedir com educação não muda isso.

Usando pelo CLI

No terminal, abra o projeto e execute:

cd ~/repos/minha-apidocker ai

O diretório atual vira o diretório de trabalho do Gordon. É de lá que ele examina Dockerfile, compose.yaml, arquivos de configuração e a estrutura do projeto. Para apontar a outro lugar, use -C:

docker ai -C ~/repos/minha-api

Também é possível passar uma pergunta diretamente:

docker ai "me mostre os containers em execução e explique por que a api está reiniciando"

O CLI abre uma TUI para a conversa, as aprovações e o contexto da sessão. Não é uma integração escondida numa extensão de IDE. É o Docker Desktop levando a interface do agente para o terminal.
No Docker Desktop, o mesmo agente aparece numa aba própria e pode ser chamado a partir de um container, imagem, volume ou build com problema. A escolha entre UI e terminal é operacional: use o lugar onde você já está trabalhando. Não existe medalha por sofrer no terminal quando o diagnóstico visual do Desktop está mais perto do que você quer inspecionar.

Pedidos que fazem sentido

O melhor uso do Gordon não é "escreva todo o meu sistema". Ele serve para encurtar o caminho entre uma intenção específica e uma tarefa que depende do estado atual do Docker.

Quando algo quebra

Esse é o caso mais óbvio. Em vez de copiar log, rodar cinco comandos e contar uma história completa para um chat, peça:

Meu container api continua encerrando. Investigue os logs, o compose e as variáveis necessárias. Proponha a menor correção possível.

O pedido tem escopo de propósito. "Menor correção possível" reduz a chance de o agente transformar uma variável ausente em refatoração de infraestrutura. Gordon verifica logs, status, mounts e configuração; você revisa a proposta antes de ela tocar no ambiente.

Quando o serviço não tem Docker

Também vale usá-lo para criar um ambiente local repetível. Por exemplo:

Analise este projeto .NET 8, crie um Dockerfile multi-stage e um compose para desenvolvimento com Postgres. Não altere arquivos sem mostrar o diff primeiro.

Aqui o trabalho cruza código, dependências, imagem e serviços auxiliares. É o tipo de cenário que o Docker cita: containerizar a aplicação, montar uma stack com Postgres e Redis e rodar tudo localmente.
Aceite o Dockerfile como proposta, não como revelação. Confira a imagem base, o usuário de execução, o .dockerignore, secrets, portas expostas, volumes e como a aplicação lê configuração. A IA pode acelerar os primeiros 80%. Os 20% que sobram costumam ser onde mora a produção e, às vezes, o incidente.

Quando o Dockerfile funciona, mas é ruim

Imagem de 2 GB, cache invalidado a cada mudança de código e build que parece reunião longa: um pedido bem definido ajuda.

Otimize este Dockerfile para builds .NET. Preserve o comportamento, use multi-stage build e explique o impacto de cada alteração no cache e no tamanho da imagem.

O Docker sugere que o Gordon reorganize camadas para aproveitar cache, use uma base menor e inclua health check quando fizer sentido. A ressalva importa. Health check mal definido vira gerador de reinícios; imagem "slim" pode não ter a dependência nativa que seu pacote precisa. Como quase tudo em Docker fora de uma demo, depende do contexto.

Quando a tarefa é simples, mas a sintaxe irrita

Listar imagens, verificar espaço em disco, limpar recursos sem uso, parar uma stack. Você sabe fazer isso. Só não quer gastar energia lembrando qual variação de prune cabe em cada situação.
É um uso honesto do agente: ele monta o comando, mostra o impacto e você aprova. Para limpeza, eu pediria que ele liste antes de remover:

Mostre as imagens, volumes e containers que não estão em uso. Não remova nada ainda.

Depois você decide. docker system prune é prático até apagar a imagem de que você precisa dois minutos antes de uma reunião. Limpar Docker é simples até deixar de ser.

Quando não vale usar

Gordon não substitui seu coding agent e não é um agente de produção. A divisão de papéis é razoável: use Gordon para tarefas de Docker, assistentes de código para lógica e refatoração da aplicação, e os dois quando a tarefa atravessa essas camadas.
Eu evitaria usá-lo como primeira opção quando:

a mudança envolve credenciais, dados sensíveis ou destruição de recursos sem um procedimento bem definido
o problema é exclusivamente de lógica de negócio e não tem relação com o ambiente de containers
você precisa investigar produção. A telemetria, a política de acesso e o raio de impacto são outros. Abrir um shell local inteligente não resolve isso
o time ainda não tem um compose.yaml, Dockerfile e convenções mínimas revisáveis. O agente pode gerar material, mas não cria disciplina operacional por telepatia.

Também não confunda Gordon com Docker Agent, Docker Sandboxes, Model Runner ou o toolkit de MCP. Estão no mesmo conjunto de produtos, mas resolvem problemas diferentes. Gordon é o assistente pronto para tarefas Docker; Docker Agent é um framework para criar equipes de agentes; Sandboxes isolam agentes; Model Runner executa modelos localmente; MCP conecta ferramentas externas.

Como começar sem inventar moda

Instale ou atualize o Docker Desktop para a versão 4.74+, entre com sua conta Docker e teste num repositório descartável ou num problema local de verdade. Segundo o anúncio do Docker, o uso básico é gratuito.
Eu começaria com leitura e diagnóstico. Peça para listar o que está executando, explicar uma falha ou revisar um Dockerfile; exija a proposta antes da execução. Depois, avance para alterações pequenas e reversíveis. Só então considere auto-approve em fluxos muito conhecidos, ainda com escopo limitado.
O Gordon não torna Docker mágico. Docker continua tendo rede, filesystem, cache, processo PID 1, permissões e todas as outras coisas que estragam uma sexta-feira à tarde. A vantagem é pôr um agente onde o contexto existe e encurtar o trajeto entre "algo quebrou" e "entendi o que fazer".
Se ele poupar a caça a logs, a adivinhação de flags e a recontagem do estado do ambiente para outra ferramenta, já valeu o espaço na tela. O julgamento continua sendo seu. Ainda bem.

Meu querido Claude ou Gordon?

O reflexo é perguntar: precisava? Já temos Claude, Copilot e uma pequena indústria de agentes de código capazes de abrir terminal, ler compose.yaml, rodar docker ps e explicar por que o banco não subiu. Colocar o Gordon na conversa parece, à primeira vista, trazer mais uma pessoa para discutir a mesma planilha.

Em boa parte dos casos, a resposta é não. Um agente de código competente, com acesso ao diretório, ao Docker CLI e aos logs, resolve a investigação local sem cerimônia. A ironia é que Gordon começou a ser desenvolvido antes de os agentes de código chegarem a boa parte dessa capacidade operacional. Quando foi lançado, passou a disputar atenção com ferramentas que leem o repositório, usam terminal e investigam o ambiente local sem se importar com a categoria do problema. Não é inútil; só precisa justificar por que existe ao lado de agentes que já cobrem uma parte relevante do trabalho. Vendê-lo como resposta universal para containers, ou como um harness misteriosamente superior, seria exagero. O Docker não publicou base para essa última afirmação, e adjetivo não depura connection refused.

Agentes trabalham tão bem quanto o contexto que conseguem carregar e as ferramentas que têm à mão. A janela de contexto já virou uma novela, o repositório é grande, o histórico foi resumido, o terminal está bloqueado por política ou não existe uma skill de Docker nas instruções do projeto. Nessa situação, o agente principal pode saber bastante e ainda assim olhar para uma fotografia velha do ambiente. Gordon começa de outro lugar: containers, imagens, volumes, builds, arquivos do Compose e o diretório de trabalho. Numa falha de docker compose, isso pode separar a investigação do estado real de uma explicação elegante para o estado imaginado.

É aí que ele deixa de ser redundante. Não como substituto do agente de código, mas como especialista em contexto. Claude ou Copilot ainda são opções melhores para entender a regra de negócio, alterar a aplicação, revisar o diff e rodar testes. Gordon entra quando a pergunta depende do Docker que existe agora, e não do Docker que alguém descreveu quarenta mensagens atrás. Um relaciona o problema ao sistema; o outro evita que essa análise comece com informação faltando.
Isso tampouco vira uma cadeia automática de agentes. O docker ai abre uma TUI e pede aprovações. Um agente principal pode identificar a tarefa, formular um pedido preciso e até iniciar o comando, se tiver acesso ao terminal. Não deve contornar a aprovação do Gordon nem fingir que leu o resultado de uma conversa interativa que não consegue acessar. A delegação funciona como um handoff explícito:

O agente de código decide que o problema é de Docker, não de lógica da aplicação;
ele prepara um pedido curto, com objetivo, escopo e restrições;
você executa ou aprova o docker ai no diretório do projeto;
O resultado, o diff proposto ou o diagnóstico volta para o agente pai, que relaciona aquilo com o código e os testes.

Vale registrar essa regra no copilot-instructions.md, CLAUDE.md ou equivalente: delegue a investigação de estado Docker ao Gordon quando ele estiver disponível, mas mantenha no agente principal a decisão arquitetural e a revisão da mudança. Não é uma hierarquia sofisticada.

É só entregar a pergunta a quem enxerga melhor a parte relevante do problema.