Eu Dexei uma IA Instalar Minha Esteira CI/CD do Zero. O Que Aconteceu?

Subir um cluster Kubernetes com pipeline de deploy automático é complicado. Mas e se você deixasse uma IA fazer isso — e só respondesse às perguntas dela?

O Desafio

Todo DevOps já passou por isso: você tem um servidor, quer subir algo novo, e sabe que vai ser um buraco sem fundo. Kubernetes, pipeline, TLS, DNS, registry, firewall… Cada pedaço depende do outro, e um erro no início vira um bug misterioso lá na frente.

Eu tinha um VPS Ubuntu com 4 núcleos e 8GB de RAM. Rodava algumas aplicações em Docker — GitLab, um proxy reverso, WordPress, umas coisinhas. Funcionava, mas era tudo manual. Cada deploy era SSH no servidor, docker compose pull, torcer.

Minha pergunta era: e se eu deixasse uma inteligência artificial montar isso tudo?

Não uma IA que gera um tutorial genérico da internet. Uma IA que acessa meu servidor, lê o que já existe, planeja a arquitetura, utiliza mcps, cria os scripts, executa, lê erro, corrige, e vai até o final.

A resposta curta: levou 5 sessões de trabalho.

A resposta longa é essa história.

O Que Eu Entreguei para a IA

Não foi um “faz pra mim” e sair de cena. O processo foi mais parecido com contratar um consultor remoto — só que esse consultor nunca dorme, nunca esquece o que disse, e trabalha na velocidade da luz.

O que eu fiz:

Dei acesso SSH ao servidor (via Tailscale, tudo pela rede privada)
Defini o escopo: quero Kubernetes, pipeline de CI/CD, TLS automático, DNS automático
Respondi perguntas: qual domínio? qual provedor DNS? quantos ambientes? qual stack das aplicações?
Tomei decisões de arquitetura: quando a IA me apresentava opções, eu escolhia

O que a IA fez:

Leu o estado atual do servidor — o que já estava rodando, como estava configurado, quais portas estavam em uso
Planejou a arquitetura — e me apresentou um diagrama antes de mexer em qualquer coisa
Criou os scripts e configs — Ansible playbooks, Helm charts, templates de pipeline
Executou tudo — instalação, configuração, deploy
Diagnosticou erros — quando algo quebrava, lia os logs, entendia a causa, corrigia

Sessão 1: O Planejamento ( Dia 1, ~2 horas )

A primeira sessão foi a mais importante. A IA passou quase uma hora lendo o servidor inteiro. Verificou o que estava rodando, quais portas estavam ocupadas, como o firewall estava configurado, qual a versão do Ubuntu, quanto de RAM livre.

Depois me apresentou uma proposta:

“O servidor já tem Nginx Proxy Manager na porta 80/443. Não posso tirar ele. Vou instalar o k3s desabilitando o Traefik nativo para não conflitar. O Ingress-NGINX vai rodar em portas diferntes, e o NPM continua como borda TLS. ExternalDNS vai sincronizar os registros no Cloudflare automaticamente.”

Eu disse: “pode ir.”

Ela criou o inventory Ansible, os primeiros playbooks, e começou a instalação. O k3s subiu. O Ingress-NGINX subiu. O ExternalDNS começou a sincronizar.

Mas aí veio o primeiro obstáculo: o GitLab Runner não registrava. A IA lia o erro, tentava uma correção, lia o novo erro, tentava outra. Foi um ciclo que durou cerca de 40 minutos até descobrir que o token de registro tinha expirado.

Lição aprendida: a IA não desiste. Ela fica tentando até acertar. Mas às vezes precisa de uma pista sua.

Sessão 2: O TLS que Não Funcionava (Dia 2, ~1h30)

Com a infraestrutura base rodando, o próximo passo era TLS. Eu queria certificados automáticos para os ambientes de desenvolvimento e homologação.

A IA sugeriu criar proxy hosts individuais no NPM para cada subdomínio. Funcionou no papel. Na prática, a API do NPM não servia os desafios ACME do Let’s Encrypt corretamente para o Kubernetes.

Foram quase 20 tentativas. A lia o log do certbot, verificava a configuração do NPM, testava a conectividade, tentava novamente. Cada tentativa levava uns 3 minutos. Foram 20 tentativas.

Até que a IA parou e me perguntou:

“O plugin certbot-dns-cloudflare não está instalado no container do NPM. A imagem oficial não traz ele. Preciso criar uma imagem customizada. Posso?”

Eu autorizei. Ela criou um Dockerfile de 7 linhas que herdava do NPM oficial e instalava o plugin. Reconstruiu o container. Emitiu os certificados wildcards via DNS-01. Resolveu.

Essa sessão me mostrou algo importante: a IA não sabe tudo de primeira. Mas ela sabe pesquisar, ler documentação, e adaptar o plano original.

Sessão 3: Os 4 Bugs Silenciosos (Dia 3, ~3 horas)

Essa foi a sessão mais longa e frustrante. A esteira estava montada, os ambientes configurados, e eu achei que bastava fazer push para o código ir pro ar.

Não foi bem assim.

Bug 1: DNS no Alpine Linux. Os containers de build falhavam ao baixar pacotes. A IA investigou e descobriu que o k3s configura ndots:5 no DNS, e o Alpine usa uma biblioteca C diferente que não lida bem com isso. Correção: configuração customizada de DNS nos pods.

Bug 2: Frontend compilado faltando. O Laravel precisava dos assets do Vite, mas eles não estavam no container. A IA leu o .gitlab-ci.yml, viu que não havia estágio de build do frontend, e criou um.

Bug 3: Probes travando o deploy. O Kubernetes configurou liveness probes que batiam num endpoint retornando erro 500. O pod reiniciava infinitamente. O Helm esperava estabilizar e dava timeout em 5 minutos. A IA desabilitou os probes temporariamente, diagnosticou, e reconfigurou.

Bug 4: Registry privado. As imagens eram privadas e o Kubernetes não conseguia puxar. A IA criou o secret imagePullSecrets no namespace correto.

Cada bug levou entre 30 minutos e 1 hora para resolver. A IA lia logs, pesquisava, tentava, lia mais logs, tentava de novo. Não era um loop infinito — era progresso linear, resolvendo barreiras uma a uma.

Para quem assistia de fora, parecia que a IA estava travada. Mas ela estava progredindo. Cada erro eliminado era uma camada a menos de problema.

Sessão 4: O Pipeline Funcionando (Dia 4, ~2 horas)

Com os bugs resolvidos, a IA montou o pipeline completo:

Estágio compile:assets: Compila o frontend com Node
Estágio build:kaniko: Cria a imagem Docker leve
Estágio deploy: Faz o deploy via Helm no Kubernetes

O fluxo era elegante: push para develop → deploy automático em dev. Merge para homolog → deploy automático em hom. Merge para main → deploy manual em produção.

A IA também criou um Makefile para gerar novos projetos:

make new-project NAME=meuapp

Um comando gerava toda a estrutura de arquivos, os values.yaml para cada ambiente, e o template do pipeline. De uma linha saía um projeto pronto para deploy.

Sessão 5: Validação e Documentação (Dia 5, ~1 hora)

A última sessão foi de validação. A IA fez push de um projeto piloto, acompanhou o pipeline inteiro, verificou se o site respondia, se o TLS estava válido, se o DNS estava correto.

Tudo funcionou. O site respondeu com HTTP/2 200 OK e certificado Let’s Encrypt válido.

Depois criou a documentação: runbooks de operação, como adicionar novos projetos, como rotacionar segredos, como fazer rollback. Tudo em markdown, tudo no repositório.

Quanto Tempo Levou?

Sessão	Foco	Duração
1	Planejamento e infra base	~2 horas
2	TLS e certificados	~1h30
3	Bugs de rede e container	~3 horas
4	Pipeline de CI/CD	~2 horas
5	Validação e docs	~1 hora
Total		~9 horas e 30 minutos

Menos de 10 horas de trabalho distribuídas em 5 dias.

Comparado com o tempo que eu levaria fazendo isso manualmente — pesquisando cada componente, testando cada configuração, resolvendo cada bug sozinho — a estimativa é que levaria 2 a 3 semanas de trabalho intermitente.

A IA não fez em 10 horas o que eu faria em 10 horas. Ela fez em 10 horas o que eu faria em semanas, porque:

Ela não esquece contexto entre sessões (usando um sistema de especificações)
Ela testa e corrige em loop sem ficar frustrada
Ela já conhece os padrões de Kubernetes, Ansible, Helm, GitLab CI
Ela não pesquisa no Google — ela já sabe

O Que Eu Aprendi

A IA é uma Ferramenta, Não um Substituto

Eu ainda precisei tomar decisões. Qual domínio usar. Se queria Wildcard ou certs individuais. Se o deploy em produção seria automático ou manual. A IA executa, mas você decide.

O Segredo é o Escopo Bem Definido

A IA funciona melhor quando você diz “quero X com Y e Z” em vez de “faça algo legal”. Quanto mais específico o pedido, menos tempo perdido em tentativa e erro.

Erros São Parte do Processo

A IA vai errar. Vai quebrar coisas. Vai entrar em loops aparentes. Isso não é falha — é o processo de descoberta. A diferença é que ela não desiste.

A Documentação é Automática

Uma das coisas mais valiosas foi a documentação gerada pela IA. Runbooks, procedimentos, diagramas. Coisa que eu normalmente faria depois (ou nunca faria), a IA fez junto com a implementação.

5 Sessões Não São 5 Dias

Cada sessão foi curta — no máximo 3 horas. Dá para fazer em horário de almoço, antes de dormir, em pausas do trabalho. A IA trabalha quando você tem tempo.

Vale a Pena?

Para mim, valeu cada minuto.

Eu saí de um servidor com Docker standalone e zero automação para uma plataforma completa de Kubernetes com pipeline de CI/CD, TLS automático, DNS automático, e documentação profissional.

O custo? Algumas horas do meu tempo respondendo perguntas e tomando decisões. A IA cuidou de tudo mais.

Se você tem um projeto parecido — um servidor que precisa de modernização, uma esteira que precisa ser criada, uma infraestrutura que precisa ser automatizada — considere dar uma IA a chance. Não como mágica, mas como uma parceria onde você sabe o quer e ela sabe como fazer.

O resultado pode te surpreender.

Artigo baseado em uma experiência real de configuração de plataforma DevOps com auxílio de inteligência artificial (Claude, Gemini e OpenCode) usando a metodologia OpenSpec para handoff de contexto entre sessões.

Tags: Inteligência Artificial, DevOps, Kubernetes, CI/CD, Automação, Ansible, GitLab, IA para DevOps, Produtividade