DEV Community: William Scussel

Parei de usar IA como chatbot. Virei ela em infraestrutura.

William Scussel — Thu, 02 Jul 2026 11:14:03 +0000

A maioria usa IA assim: abre o chat, cola a pergunta, copia a resposta, volta pro editor, repete. A IA não sabe nada do seu mundo. Toda conversa começa do zero.

Há um tempo parei de fazer isso. Hoje a IA vive no meu terminal, lê meus repositórios, conhece meus clientes, roda meus scripts e abre pull request. O contexto já está lá quando eu chego.

Não é sobre achar o prompt mágico perfeito. É sobre montar um sistema em volta da IA: contexto, ferramentas e um loop que se repete. Vou mostrar como isso se parece na prática.

A base: meu mundo num repositório versionado

Tudo começa com um repositório que guarda o contexto que a IA lê. Versionado, porque evolui comigo, não vive na minha cabeça nem some quando troco de máquina.

tools/
├─ AI_DEFAULT.md    # instruções centrais, toda IA lê
├─ CLAUDE.md        # aponta p/ AI_DEFAULT
├─ projects.yml     # registro: alias de cliente → repo certo
├─ TOOLS.md         # catálogo de todos os scripts
├─ RUNBOOK.md       # deploy, settings, troubleshooting
├─ brand/           # cores, fontes, logos, templates
├─ clickup/         # tasks via terminal
└─ media/           # scripts de slides e vídeo

A peça central é um arquivo de instruções que toda IA lê antes de trabalhar: como fazer commit, convenções de branch, tom de voz, onde mora cada coisa. Escrevo a regra uma vez, ela vale pra sempre.

Frente 1: tarefa chata vira script

Toda repetição manual virou comando. E foi a própria IA que escreveu e mantém esses scripts.

Um resumo do meu dia (tarefas + agenda) cai no meu WhatsApp toda manhã, sozinho.
Crio e consulto tasks direto do terminal, sem abrir o navegador.
Scaffolds geram um projeto de infra ou uma apresentação inteira em um comando.

A regra que sigo: se fiz à mão duas vezes, a terceira é um script.

Frente 2: eu estendo a própria IA

Comandos e agents customizados ensinam a IA a trabalhar do meu jeito. Os que mais uso:

/implement pega uma task, cria a branch, escreve o código e abre o PR.
code-reviewer é um agent que revisa o diff antes de cada commit.
Comandos pequenos pro trivial: criar lembrete, resolver um alias de cliente.

A IA não é uma caixa fechada. É uma plataforma que dá pra programar.

Frente 3: IA no código de verdade, não em brinquedo

Isso roda em código de cliente, não em projeto de fim de semana. Por isso o fluxo tem trava:

Implementação de front e back em paralelo a partir de uma task.
Um gate de qualidade bloqueante: nada entra no repo sem o agent revisar.
Commits pequenos e focados, uma mudança lógica por commit.
PR pronto pra review, sem rastro de "isso foi IA".

O ponto não é a IA escrever rápido. É ela escrever dentro das minhas regras.

Frente 4: a IA conhece meu mundo

Planos e documentação ficam onde a IA lê e escreve.
Um registro de workspace resolve "fala do cliente X" pro repositório certo na hora.
Memória persistente: ela lembra decisões entre sessões.
Runbooks deixam a operação documentada e reutilizável.

Eu digo um apelido. Ela resolve o cliente, acha os repos certos e já sabe o que é front e o que é back. Zero explicação.

O padrão por trás de tudo

As quatro frentes parecem diferentes, mas são a mesma receita:

Contexto: a IA enxerga seu mundo (repos, docs, clientes, memória).
Ferramentas: ela executa (scripts, git, APIs). Não só fala, faz.
Loop: faz, verifica, corrige, com gate de qualidade fechando o ciclo.

Acerte os três e qualquer tarefa repetitiva vira automação. Erre um e você volta pro chatbot.

O efeito composto

São cerca de 5 horas por semana que voltam pra mim, dezenas de PRs abertos por um único comando, e o número cresce toda semana porque cada automação libera tempo pra construir a próxima.

Como você começa hoje

Não precisa replicar meu setup. Comece com um passo:

Escolha uma tarefa chata que você repete toda semana.
Peça pra IA virar script e versione no repositório.
Dê contexto: um arquivo de instruções que ela lê sempre.
Feche o loop: deixe ela rodar, verificar e corrigir.
Repita. Cada automação paga a próxima.

A pergunta não é "a IA consegue?". É "o que eu paro de fazer à mão hoje?".

O bug de 16 minutos: quando 'dado faltando' é uma corrida contra o relógio

William Scussel — Wed, 24 Jun 2026 19:51:59 +0000

"Seu sistema está perdendo dados"

Um cliente abriu o chamado, convicto. O relatório de retorno bancário enviado por e-mail toda manhã tinha 423 linhas. O mesmo relatório, gerado sob demanda no portal, tinha 1.351.

928 linhas, sumidas. É o tipo de número que faz você presumir o pior.

No fim, nada foi perdido. O bug tinha 16 minutos de largura.

Passo 1: comparar antes de debugar

Nada de código ainda. Primeiro dei um diff nos dois arquivos.

Mesmo dia.
Mesmo banco.
Mesmo filtro de status.
Toda linha do arquivo do e-mail estava contida no arquivo do portal.

Ou seja, o dado não estava errado. Estava ausente. Problema diferente.

Passo 2: matar hipóteses com prova, não com opinião

Três causas plausíveis, cada uma derrubada em produção com queries read-only:

"Está dividido entre bancos / anexos."
Não. Todas as 1.351 linhas pertenciam ao mesmo código de banco.

"O dedup contra o dia anterior é agressivo demais."
O relatório subtrai faturas já vistas no dia anterior:

$diff = array_diff(
    array_column($hoje, 'invoice'),
    array_column($ontem, 'invoice')
);

Repliquei contra os dados de produção. Removeu zero linhas. Não era o culpado.

"Os dois relatórios filtram colunas de data diferentes."
Não. Os dois filtravam a mesma coluna transaction_created_at, para a mesma data.

Passo 3: a mesma query, rodada agora, retorna tudo

Foi aqui que a ficha caiu. Com os filtros exatos que o job do e-mail usa:

SELECT COUNT(DISTINCT invoice)
FROM   bank_returns
WHERE  DATE(occurrence_date) = '2026-06-23'
  AND  bank_code = 33
  AND  credit_date IS NOT NULL;   -- "somente pagos"
-- → 1351

O e-mail tinha enviado 423. O banco de dados agora guarda 1.351. Com filtros idênticos. Nada na query mudou. Algo no tempo mudou.

Passo 4: seguir os timestamps

07:15:45  job do relatório roda, monta e envia o e-mail
07:31:02  sistema importa o arquivo de retorno do banco (~12.700 lançamentos do dia)

O relatório roda às 07:15. O arquivo com a maior parte das baixas confirmadas do dia chega às 07:31. O e-mail é gerado 16 minutos antes de o dado existir no banco.

Separe as faturas por esse corte e o gap bate exato:

-- importadas até 07:15  → o que o e-mail viu   → 423
-- importadas após 07:15 → "faltando"           → 928
-- total                                        → 1351

O portal "viu mais" por um motivo chato: foi consultado às 08:23, depois da importação.

O bug de verdade

Não é lógica. É acoplamento temporal entre uma tarefa agendada e a chegada de um dado externo. O relatório assume que os pagamentos de ontem já estão totalmente carregados às 07:15. O banco discorda.

Correções, da mais barata para a melhor:

Rodar o relatório depois da importação matinal.
Melhor: disparar o relatório ao fim da importação, em vez de um horário fixo.
Defensivo: o relatório validar que a importação esperada rodou antes de reportar.

A lição

"Menos linhas" quase nunca é "perdemos dados". Geralmente é "olhei no momento errado".

Antes de anexar um debugger, faça duas perguntas:

Quando esse dado nasce?
Quando eu o leio?

A maioria dos bugs de "dado faltando" morre aí mesmo.

[Boost]

William Scussel — Wed, 17 Dec 2025 13:20:25 +0000

Jenkins na AWS + Docker

William Scussel ・ Dec 3

#devops #jenkins #aws #docker

Jenkins na AWS + Docker

William Scussel — Wed, 03 Dec 2025 20:33:52 +0000

Olá, sou William Líder de squad na InnSpire.dev, quero começar a escrever sobre minhas experiencias no mundo da tecnologia, já que são mais de 20 anos trabalhando nessa area, quero compartilhar meus conhecimentos, sim, um pouco tarde para isso, mas como dizem: antes tarde do que mais tarde ainda.

E escolhi começar com uma das ferramentas que mais me deu dor de cabeça — e também as maiores vitórias: Jenkins.

Já perdi dados, já quebrei pipelines, já fiquei até de madrugada resolvendo build travado… mas hoje tenho uma infraestrutura estável, barata e eficiente rodando na AWS.

Neste artigo, quero mostrar como estruturamos Jenkins + Docker + AWS e talvez te dar alguns insights para montar algo parecido.

Bom vamos lá, atualmente nosso servidor está dentro da AWS, na região da Virginia, é uma instancia do tipo t3a.medium com 2vCPU e 4GB de memória, e dentro dela tenho uma instalação do Ubuntu 24.04 Server, gosto muito de trabalhar com essa distro em servidores, é muito versátil, mas isso pode ser um assunto para outro artigo quem sabe.

Como podem notar no print do servidor, já está rodando a algum tempo sem nenhuma interrupção, mas apesar da memória estar bem usada, todos os serviços que estão rodando dentro da maquina rodam bem, e está tudo dentro de containers, temos atualmente 21 containers rodando dentro deste servidor.

Dentro dos 21 containers que temos, 2 são para instalações do Jenkins, só que com jobs diferentes, propósitos diferentes, 2 para agentes de build do Jenkins (1 para cada instalação), e outros dois containers muito importantes para auxiliar nesse fluxo todo, Nginx para gerenciar o roteamento, e o Portainer para verificar a saude de todos os containers que estão no servidor.

A idéia de separar em dois containers diferentes, foi mais para dois times distintos conseguirem atuar de forma totalmente separada e poder destruir seu ambiente sem afetar o outro time, e com docker isso é muito mais simples.

Agora de fato sobre a configuração do Jenkins, no docker-compose eu tenho mapeado os diretórios que serão acessados pelo Jenkins e o agente, e uma peculiaridade é o mapeamento do arquivo docker.sock, isso foi necessário pois dentro de alguns jobs eu precisava fazer o restart de algum container, e sem isso não era possível acessar os containers 🫠

# docker-compose.yml

services:
  jenkins:
    build: .
    container_name: jenkins-innova
    restart: always
    privileged: true
    ports:
      - "3001:8080"
      - "50000:50000"
    volumes:
      - jenkins_home:/var/jenkins_home
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - innova-network

  jenkins-innova-agent:
    image: jenkins/inbound-agent
    container_name: jenkins-innova-agent
    networks:
      - innova-network
    volumes:
      - /srv/jenkins-innova:/home/jenkins/agent-workspace
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      JENKINS_URL: "http://jenkins-innova:8080"
      JENKINS_AGENT_NAME: "agent"
      JENKINS_SECRET: "chave"
    restart: unless-stopped

volumes:
  jenkins_home:

networks:
  innova-network:
    external: true




# Dockerfile

FROM jenkins/jenkins:alpine3.21-jdk21

USER root

# Instalar dependências sem modificar o Java existente
RUN apk add --no-cache \
    sudo \
    docker-cli \
    git \
    bash \
    curl \
    ttf-dejavu

# Adicionar usuário Jenkins ao grupo Docker
RUN addgroup -S docker && adduser jenkins docker \
    && echo "jenkins ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/jenkins

USER jenkins

E daqui para frente é só sucesso, configurar e sair usando, se quiser que eu comente mais como são configurados os jobs que temos, comenta ai!