PRs abertos por agentes saltam de 20% para 70% na PostHog

Engenheiros não desaparecem, mudam de papel

Ian Vanagas, da PostHog, argumenta que, embora a IA esteja caminhando para escrever todo o código, os engenheiros não vão deixar de existir - eles passam a pilotar o loop de produto. Como evidência do momento, ele cita que nos últimos quatro meses a PostHog saltou de cerca de 20% para 70% dos PRs do monorepo abertos por agentes. Ele também observa que, mesmo com a Anthropic afirmando que 'coding is largely solved', a empresa mantém 208 vagas abertas com 'engineer' no título.

As cinco funções do novo engenheiro

1. Monitorar a situação. Engenheiros passam tempo observando agentes em execução, corrigindo erros, respondendo a clientes, avaliando concorrentes e acompanhando PRs. A IA amplificou essa prática: aumentou a informação que um engenheiro processa e as expectativas de produtividade. Na PostHog, equipes criaram standup bots, scouts de resumo de repositório, configurações customizadas para monitorar PRs, surveys de feedback e alertas de anomalia.

2. Definir direção. Escolher entre centenas de caminhos possíveis, antes papel de PMs e executivos, recai cada vez mais sobre engenheiros. O autor usa como exemplo os RFCs da empresa - quase 1.000 decisões de direção registradas - e detalha um RFC de unificação de páginas de saúde, que filtra informação por experiência pessoal, importância para usuários e clientes, viabilidade técnica (com Dagster e Postgres) e encaixe no cenário competitivo.

3. Decidir como construir. Mesmo sem escrever código, engenheiros definem escopo e decisões de implementação, o que exige conhecer o codebase, as capacidades e os pontos cegos dos agentes. O autor, que é marketer, ilustra com um pedido próprio (enviar entrevistas de IA por link): o engenheiro Paul apontou detalhes que ele não saberia incluir, como aceitar distinct_id e session_id como parâmetros de query e limitar requisições - sem isso, agentes gastariam mais tokens ou introduziriam bugs e vetores de ataque.

4. Avaliar o trabalho dos agentes. Code review continua necessário e virou gargalo: com 20 PRs por dia, ler linha a linha é inviável. Engenheiros da PostHog criaram sistemas próprios, como o Talyn, de Tom, uma 'mission control' para PRs, e VMs velozes para pré-visualizar mudanças. O volume saltou de 1.441 PRs mesclados em janeiro para 4.869 em agosto, com aumento de apenas 10% no headcount de engenharia.

5. Melhorar o loop inteiro. As etapas se retroalimentam: o que se observa informa a direção, o que é construído informa decisões futuras e o que é lançado valida a direção. A consequência é que engenheiros trabalham mais no sistema que constrói o produto do que no produto em si - constroem a 'fábrica de software' em vez do software.

Produtos self-driving e a conclusão

O autor descreve um caso real em que grande parte do loop é pulada: um Scout, agente de longa duração, observou feedback e taxas de erro do MCP server, agrupou observações, acionou um agente que escreveu uma correção, revisada por outro agente (que encontrou dois problemas 'must fix' antes da revisão humana) e validada por um agente de avaliação posterior. A direção era implícita e o produto melhorou sem intervenção humana direta.

Ainda assim, Vanagas sustenta que tudo isso depende das habilidades do engenheiro: escrever código pode ser barato, mas o sistema de construir produto não é - fontes de informação, direção, conhecimento de implementação e avaliação tornam-se o diferencial. Ele conclui que isso é uma versão do OODA loop de John Boyd e que continua sendo trabalho de engenharia, apenas com outra aparência.