Harness segundo Fowler: 4 camadas no backend

Todo mundo hoje fala em “harness” para agente. Antes de gastar tempo montando um do zero, vale abrir o artigo sobre Continuous Integration de Martin Fowler (revisado por último em janeiro de 2024) e ler com esse vocabulário na cabeça. O texto descreve, sem usar a palavra, exatamente os quatro harness que seu backend já roda em produção agora. Você só chama isso de outra coisa.

Este texto é sobre um recorte específico: a lente de Fowler, aplicada ao backend real de 2026. Não é o artigo sobre “Agent = Modelo + Harness” (aquele é a leitura da LangChain), nem sobre os “Seis Componentes de um Harness” (aquele é a leitura anatômica). Aqui a pergunta é diferente: quando Fowler escreveu sobre CI (originalmente em 2000, com rewrites em 2006 e 2023-2024), o que ele já estava descrevendo?

O que Fowler escreveu

O artigo de Fowler abre com esta definição:

Continuous Integration is a software development practice where each member of a team merges their changes into a codebase together with their colleagues changes at least daily.

Note a estrutura: integrar frequentemente + verificar automaticamente cada integração. O texto não diz “harness”. Mas se você lê “verificar automaticamente” e escreve o que isso significa em código, sai um harness. Uma malha de checagens que roda sem alguém rodar.

A parte que envelheceu bem é o item Automate the Build (o segundo da lista de práticas):

Turning the source code into a running system can often be a complicated process involving compilation, moving files around, loading schemas into databases, and so on. However like most tasks in this part of software development it can be automated - and as a result should be automated.

Fowler estava descrevendo o embrião do que hoje é um workflow de GitHub Actions. Ele não tinha a palavra .yml na cabeça. Tinha make e Ant. A ideia era a mesma: um sistema que reduz o gap entre “eu escrevi código” e “sabemos se o código quebrou alguma coisa”.

Se você reler o artigo em 2026 mentalmente substituindo “build” por “harness”, quase nada precisa mudar.

Os quatro harness que seu backend já tem

Peguei um repositório médio de backend Node.js de um projeto que ajudei a arrumar, listei as verificações automáticas ativas, e agrupei por camada. Deu quatro. Não é um número mágico: é o que apareceu naturalmente na hora de mapear “quem verifica o quê, e em que momento”.

1. Pre-commit hook

Roda no laptop do desenvolvedor, antes do commit ir para o repositório. Formatter, linter, type checker parcial. husky + lint-staged em Node, pre-commit framework em Python.

O que Fowler dizia: “detect integration errors as quickly as possible”. O harness mais rápido é o que roda antes de o código sair da sua máquina. Você nem chama de harness — chama de “hook”. Mesma coisa.

2. CI (GitHub Actions / GitLab CI / Bitbucket Pipelines)

Roda quando o commit chega no servidor de código. Roda os testes completos, build de produção, checagem de segurança em dependências. O que a máquina do desenvolvedor não conseguiu fazer em tempo aceitável, o CI faz em paralelo em runners.

# .github/workflows/ci.yml — um recorte comum
name: CI
on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm test -- --coverage

Isso é um harness. Ele tem entrada (o PR), verificação (lint + type + test), e um veredito público (o status na PR). Fowler descreveu esse formato em prosa antes de o GitHub existir.

3. Deploy gate

Roda no momento da promoção para staging ou produção. Executa smoke tests, verifica migration compatível, roda canary por 5 minutos antes de expandir tráfego. É menos comum de ver escrito em .yml porque muitas equipes fazem manualmente ou dentro de scripts internos.

Mesmo quando é manual (por exemplo, “só publica se o Kaio aprovar no Slack”) ainda é um harness. A checagem existe, tem critério, e bloqueia a próxima etapa. A automação é o objetivo; a existência do gate é o que importa.

4. Observability alerting

Roda em produção, depois do código ter subido. Prometheus + Grafana ou Datadog com alertas que dizem “a taxa de erro 5xx desse endpoint passou de 1% nos últimos 3 minutos”. Isso é feedback loop do estado do sistema real.

Fowler não escreveu sobre isso na versão original de 2000 (não tinha SRE ainda como disciplina nomeada). Mas leia o item “Fix Broken Builds Immediately” do artigo e substitua “build” por “produção”. A ideia de “detectar rápido + corrigir rápido” é a mesma. Observability é o harness da camada mais externa.

Por que reconhecer os quatro importa

Você provavelmente já tem os quatro rodando. O ganho de reconhecê-los como harness é operacional:

• Cada camada tem um SLA de detecção diferente. Pre-commit: segundos. CI: minutos. Deploy gate: minutos-a-hora. Observability: minutos-a-dia. Se você move uma checagem para a camada errada (por exemplo, roda testes de integração no pre-commit), o SLA quebra e ninguém entende por quê.
• Duplicação de verificação vira custo. Se o linter roda no pre-commit e de novo no CI e de novo no deploy gate, você pagou três vezes por uma checagem que era para rodar uma vez só. Um mapeamento explícito das quatro camadas evita esse desperdício.
• Buracos aparecem. Quando você desenha as quatro camadas lado a lado, fica visível que sua stack tem CI e observability mas não tem deploy gate. Aí você sabe onde investir a próxima hora de trabalho de plataforma.

O AGENTS.md que a equipe usa para orientar agente de IA se beneficia disso também. Escrever “o agente pode fazer commit direto após pre-commit passar” é uma frase pequena, mas ela só faz sentido quando você já mapeou explicitamente qual camada de harness cobre o quê.

O que Fowler não previu

Uma parte do artigo envelheceu. Fowler assumia que o build era operado por humanos: o item “Fix Broken Builds Immediately” cita Kent Beck (“nobody has a higher priority task than fixing the build”) e sugere que “a couple of people” revertam o commit faltoso. Em 2026 o agente que quebra o build costuma ser um bot que abriu 15 PRs de update de dependência às 3h da manhã. O harness precisa ser desenhado para lidar com bots que operam mais do que humanos.

O outro ponto que Fowler não tinha em mente é o custo de rodar CI em runner pago. Em 2000 build era grátis (rodava na máquina do dev ou num servidor da própria empresa). Em 2026, cada push custa alguns centavos de runner e alguns segundos de vida. Um harness que roda 40 minutos por PR não é apenas lento: é caro. Otimizar tempo de CI virou parte do design de harness, o que não aparece em Fowler.

Mas o esqueleto conceitual “verificar automaticamente + detectar rápido + corrigir rápido” se sustenta. A palavra “harness” é nova. A prática vem do artigo original de 2000.

Referência

• Continuous Integration, Martin Fowler (revisado em jan/2024)
• Versão original do artigo (2003)

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews