Skip to content
All writing
/desenvolvimento-software 10 min read

O trabalho do engenheiro sénior acabou de mudar

O trabalho do engenheiro sénior mudou. Código é grátis, gosto não é. Porque construir o harness à volta do agente vale mais do que escrever código tu próprio.

Código é grátis. Gosto não é. Depois de um ano a construir agent harnesses à volta do meu próprio trabalho, acho que o trabalho do engenheiro sénior mudou em silêncio: deixou de ser escrever código e passou a ser engenharia agêntica, desenhar o sistema que produz o código. A alavancagem subiu uma camada, e a maioria dos developers ainda anda a discutir qual o melhor modelo enquanto o trabalho a sério já foi para outro sítio.

Passei o último ano a montar skills do Claude Code, templates de planeamento, deploy lanes e regras de lint à volta dos meus projectos. O output subiu. As horas não. O que mudou não foi o modelo. Foi o harness.

Índice

Onde começou o meu raciocínio

Em Agosto passado escrevi sobre vibe coding e os dois lados da IA no software. Na altura já me sentia desconfortável com a ideia de “IA como autocomplete”. Faltava qualquer coisa. Via dois campos: gente a tratar o Claude como um motor de busca chique, e gente a deixá-lo escrever apps inteiras sem guardrails e a publicar slop.

Ao longo dos doze meses seguintes derivei para um terceiro campo sem lhe dar nome. Comecei a escrever skills. Depois templates de planeamento. Depois um release gate. Depois deploy templates. Depois um sistema de memória. Cada peça resolvia uma classe de problema que me estava a consumir atenção síncrona. Nenhuma é impressionante isoladamente. Juntas, mudaram o que consigo entregar numa semana.

Não tinha uma palavra para o que andava a fazer até ver duas talks seguidas na AI Engineer 2026.

As duas frases que fizeram o clique

“Vibe coding is about raising the floor for everyone. Agentic engineering is about preserving the quality bar of what existed before in professional software.”

Andrej Karpathy

É esta a linha. Vibe coding deixa qualquer pessoa publicar um protótipo. Engenharia agêntica é o que os profissionais fazem assim que entram no edifício. É disciplina, não é vibe. O agente é poderoso e um bocadinho estocástico, e o teu trabalho é coordená-lo sem sacrificar qualidade.

A segunda frase, do Peter Steinberger a falar do OpenCode:

“You still need to ask the right questions, otherwise that makes the difference between good code and slop.”

Peter Steinberger

As duas frases apontam para a mesma viragem. O modelo deixou de ser o limite. A tua capacidade de especificar, estruturar e guiar é que é o limite. O ofício do engenheiro sénior mudou de escrever código para construir o sistema que produz código correcto.

O que “harness” quer mesmo dizer

O Ryan Lopopolo, da OpenAI, deu a talk mais directa sobre isto. Chama-lhe harness engineering: o software, as estruturas e as instruções que pões à volta do agente para que ele faça o trabalho inteiro sem precisares de meter as mãos no loop. O enquadramento dele foi o mais limpo que ouvi:

“Code is free. We have an abundance of code to solve the problems that we come across. Each engineer today has access to five, fifty, or five thousand engineers worth of capacity. The only thing that needs to happen is to figure out how to productively deploy these resources.”

Ryan Lopopolo, OpenAI

Se o código é grátis, então os recursos escassos hoje são outros. O Lopopolo identifica três: tempo humano, atenção humana e do modelo, e a janela de contexto do modelo. Cada parte do teu setup ou alimenta esses recursos escassos ou desperdiça-os. Um bom harness alimenta-os. Um mau drena-os.

É por isto que acho que a escolha de modelo se tornou uma distracção. Trocar Claude por GPT dentro de um harness bem feito quase não muda o output. Trocar um harness bem feito por “vou só colar no ChatGPT” muda tudo.

O harness em camadas para engenharia agêntica na prática

O meu harness é feito por camadas. Cada camada passa o testemunho à seguinte através de artefactos estruturados que o agente consegue ler.

Camada 1: Skills (workflows codificados)

Todo o workflow que faço mais de duas vezes vai parar a uma skill. Slash commands, frontmatter, scripts. A skill é o prompt que eu ia ter de reescrever. Aqui está o frontmatter de uma das minhas, que constrói demos pré-contratação para leads do Codeable:

---
name: lab-demo
description: Interview-driven workflow to build a pre-hire Astro+Tailwind
  demo from a client's Figma design and deploy it to {client-slug}.lab.pluginslab.com
  on Cloudflare Pages. Triggers on phrases like "lab demo for task X",
  "build a demo of this design".
---

Assim que isto existe, “constrói uma demo para este cliente” deixa de ser uma conversa de setup de 30 minutos e passa a ser uma frase. O agente lê a skill, corre os passos, e só me pergunta o que a skill ainda não responde.

Camada 2: Documentos de planeamento

Cada projecto recebe quatro ficheiros: architecture.md, concept.md, plan.md, progress.md. O agente escreve-os comigo no início. Lê-os a cada passo. São a memória do projecto entre sessões, e sobrevivem ao despejar da janela de contexto do modelo.

Esta é a parte que a maioria dos meus colegas experts subestima mais, na minha opinião. Querem que o agente “faça só código”. Mas o agente não faz ideia do que é sucesso no teu negócio se tu não o escreveste. O plan document é a job description do agente.

Camada 3: Release gates e deploy lanes

A camada chata. A que apanha mesmo os erros. Cada push para main em cada projecto activo corre o mesmo release gate, que falha se eu não fiz bump à versão ou não escrevi uma entrada no changelog:

if [[ "$CURRENT" == "$PREVIOUS" ]]; then
  echo "ERROR: version in $SOURCE not bumped (still $CURRENT)." >&2
  exit 1
fi

if [[ ! -f CHANGELOG.md ]]; then
  echo "ERROR: CHANGELOG.md missing at repo root" >&2
  exit 1
fi

Trinta linhas de bash que eliminaram, de forma duradoura, uma classe de erros “ah, esqueci-me de dar bump” que eu cometia de duas em duas semanas. É exactamente o padrão “Garbage Collection Friday” do Lopopolo: agarras numa classe de slop recorrente, eliminas uma vez, e nunca mais gastas atenção com ela.

Por trás do gate estão duas deploy lanes. A Lane A cola um script de Ploi (uso o ploi.io para gerir os meus droplets da DigitalOcean e recomendo-o muito a toda a gente). A Lane B é um workflow de GitHub Actions que entra na Tailscale e faz SSH para o home server:

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 2 }
      - name: Validate release (version bump + changelog)
        run: ./scripts/validate-release.sh

Dois templates. Cada app custom usa um deles. Acabou-se o debug de deploys feitos à medida.

Nenhuma destas camadas é genial isoladamente. Empilhadas, deixam-me correr mais projectos do que conseguia tomar conta antes, e o agente raramente sai dos carris porque cada camada lhe entrega o prompt seguinte com contexto estruturado.

As objecções que vou ouvindo

A maior parte dos colegas experts do Codeable com quem falo responde com a mesma frase: “não tenho tempo para montar isso tudo, eu só quero entregar”. Continuam a fazer copy-paste do ChatGPT. Duas objecções mais sérias aparecem com frequência.

“Isto só funciona para developers solo e equipas pequenas”

A versão mais forte da objecção: numa empresa de 50 engenheiros não podes reescrever o SDLC por tua conta. Justo. Não podes.

Mas o Ryan Lopopolo está a correr exactamente este playbook na OpenAI. O projecto dele acabou com 750 packages PNPM, review agents por persona, e um ritual semanal dedicado (“Garbage Collection Friday”) em que os engenheiros encontram modos de falha recorrentes e eliminam-nos de forma duradoura. O padrão à escala não é “cada engenheiro constrói o seu harness”. É “um engenheiro documenta o que é bom, e um review agent obriga o resto da equipa a cumprir”. Isto é alavancagem, não é gatekeeping.

À escala, o harness fica mais importante, não menos. A codebase tem de se tornar legível para agentes da mesma forma que tem de ser legível para quem entra de novo na equipa.

“Os modelos vão acabar por absorver o harness”

A objecção da bitter lesson. Daqui a doze meses o Claude ou o Codex vão planear, fazer lint e fazer deploy sozinhos, portanto a tua pasta de skills é um artefacto de transição.

O Lopopolo responde a isto directamente: “Context is a thing that I don’t think will ever be obsoleted. The models must be told the requirements of the task, which guardrails to pay attention to.” Os requisitos não funcionais da tua equipa, o teu plano de QA, as tuas deploy lanes, a forma como o teu sistema de billing trata reembolsos. Nada disto está no modelo. Nunca vai estar. É um facto sobre o teu negócio, não é uma propriedade dos pesos.

O Karpathy diz a mesma coisa noutro registo: o trabalho sobe na stack. Hoje são lints e skills. Amanhã são specs, critérios de aceitação e review prompts. Os artefactos ficam mais abstractos, mas o trabalho de engenharia não desaparece. Como o Karpathy disse, “You can outsource your thinking, but you can’t outsource your understanding.”

Onde isto não se aplica

Dois casos em que acho que o argumento do harness deixa de fazer sentido.

Scripts descartáveis e protótipos one-shot. Construir um harness para um script de 50 linhas é over-engineering. A história do menu-genen do Karpathy é a referência: vibe code, publica, segue em frente. Se o artefacto é descartável, o harness é overhead.

Iniciantes. Se estás a começar em programação, ainda não sabes o que é “bom”. Não consegues escrever quality bars para problemas que nunca resolveste. Vibe coding é o ponto de entrada certo. A camada do harness vem depois, quando já entregaste o suficiente para teres opiniões que valha a pena codificar.

O que fazer já na segunda de manhã

Duas acções concretas.

1. Codifica um workflow como uma skill. Escolhe a coisa que fazes todas as semanas. Review de PR, deploy, scaffolding de um projecto novo, escrever um post no blog. Abre um ficheiro novo. Escreve os passos da forma como os explicarias a um júnior. Mete um bloco de frontmatter. Pronto, é uma skill. Para de reescrever as instruções.

2. Trata o teu repo como um prompt. Cada estrutura de ficheiros, regra de lint, mensagem de erro e README é contexto que estás a entregar a um agente. Lê o teu repo com essa lente. O agente vai ler as tuas mensagens de erro e tentar agir em cima delas. Se o teu linter diz “unexpected any”, o agente não sabe o que queres. Se diz “don’t use any here, this type is derived from a Zod schema, replace with the inferred type”, o agente arranja a coisa certa à primeira.

É esta a mudança de mentalidade. Deixa de perguntar “qual é o melhor modelo”. Começa a perguntar “que contexto é que o modelo precisaria para fazer isto sem mim”. Para uma leitura mais vertical sobre a mesma ideia, vê o meu texto sobre agentic development para developers de WordPress.

Continuamos engenheiros, o que construímos é que mudou

O enquadramento ao qual volto sempre: continuamos engenheiros. O trabalho não desapareceu. Subiu uma camada. Antes construíamos software. Agora construímos os sistemas que constroem software.

Não é um trabalho mais pequeno. É um trabalho mais interessante. System design, gosto, saber a que dizer que não, escrever o que é bom para que cem corridas do agente convirjam todas para a mesma quality bar. Estas são competências de engenharia sénior. Sempre tiveram valor. Agora são as únicas que compõem juros.

Uma nota de transparência para fechar. Sou expert no Codeable e founder da Pluginslab. Vendo trabalho de engenharia. Entregar mais depressa é mais receita para mim. Portanto não sou neutro na afirmação de que é na camada do harness que está a alavancagem. Leva este post como sinal do que estou a fazer nos meus próprios projectos, não como pitch comercial. A versão mais forte do argumento é a que testas contra a tua própria semana. Escolhe um workflow. Codifica-o. Vê o que muda.

Depois volta e diz-me o que partiu. O harness fica melhor quando mais gente o parte.

Vê as talks

Estas três talks da conferência AI Engineer moldaram o argumento deste post. Vale a pena ver na íntegra.

Relacionado: Stop Writing WordPress Boilerplate, o kit de agentic dev que este argumento me levou a construir.